AWS 소규모 아키텍트 (4) - 데이터베이스 선택
우리는 EC2 생성을 통해 서버를 제작하고, 그에 따른 Load Balancing 수행 및 AMI제작, 보안 규칙에 대해 알아보았습니다.
이렇게 서버를 제작했지만 또 하나, 데이터베이스가 남았습니다.
S3나 EC2당 EBS볼륨이 하나씩 제작되어 있는 것을 보면 이미 데이터를 저장할 수 있는 곳인데 굳이 데이터베이스 서버를 제작해야 하는 이유는 무엇일까요?
EC2에 있는 EBS볼륨에는 제약이 있습니다. 많은 데이터를 보관할 수 있는 것도 아니며 더군다나 데이터를 효과적으로 활용하기 위해서는 데이터베이스의 사용이 필수입니다. 하지만 언제나 그랬듯 우리는 서비스에 맞는 가장 효율적인 데이터베이스를 선택해야 하며, 그 안에서도 버전 및 성능에 대해서 선택해야 합니다.
관계형(Relational) 데이터베이스
관계형 데이터베이스는 어떤 데이터들이 일정한 규칙에 의거하여 저장되는 데이터베이스를 의미합니다. 예를 들어, 학생에 대한 데이터를 저장한다고 했을 때 학번은 오로지 숫자로 이루어져 있으며, 이름은 String형태로 저장되어 있고 이는 또한 10글자 미만이라는 규칙을 삽입하여 관리할 수 있을 것입니다. 또한 수강신청 안의 데이터들은 하나의 수업에 어떤 학생들이 신청했는지 알기 위해 학생 데이터가 실제로 존재하는 것들만 들어올 수 있도록 제약을 만들 수도 있어야 합니다.
이러한 규칙에 의거하여 정확히 데이터들을 관리하고, 관계를 지정하는 것을 필요로할 때 관계형 데이터베이스를 사용합니다.
RDS
RDS에서는 관계형 데이터베이스를 사용할 수 있으며 Postgres, MySQL, MariaDB, Oracle 등의 데이터베이스를 사용할 수 있습니다. 이와 같은 RDS서비스를 사용하는 이유는 데이터베이스의 프로비저닝, 운영체제의 패치 자동화, 백원 및 복원 옵션, 모니터링 대시보드 등의 기능을 사용할 수 있기 때문입니다. 또한 유지보수 기간 설정과 스케일링이 가능하기 때문에 유용합니다.
프로비저닝이란 사용자가 요구하는 어떤 자원이나 상태를 미리 할당 / 배포하고, 요청이 들어올 때 바로 사용가능하도록 준비하는 것을 의미합니다.
하지만 SSH를 통해 직접적으로 인스턴스에 접근할 수 없으며 데이터베이스 내부에서 어떤 일이 발생하는지 확인할 수 없습니다.
우리는 지금까지 배운 Elastic Load Balancer에 의해 생성된 EC2 여러 대가 하나의 RDS를 통해 데이터베이스가 관리되어지고, 애플리케이션 로직을 수행할 수 있는 아키텍트를 구현할 수 있게 됩니다.
Aurora
Aurora는 AWS에서 자체적으로 제작되었으며 Postgres, MySQL 두가지 언어가 지원됩니다. 하지만 각각 3배, 5배의 성능을 향상시켰으며 스토리지는 자동으로 증가하는 구조입니다. 20%가량 RDS보다 비싸지만 효율이 높으므로 실질적인 비용면에서는 유리합니다.
ElastiCache
캐시는 높은 성능과 짧은 지연 시간을 자랑하는 인 메모리 데이터베이스입니다. 따라서 in-memory database라는 글귀를 보면 ElastiCache를 떠올리면 될 것 같습니다. 이는 읽기 집중적인 워크로드의 데이터베이스로부터 워크로드를 줄일 때 용이하게 사용됩니다.
많은 쿼리 작업을 수행할 때에 항상 동일한 쿼리를 다루게 되면 RDS 내에 막대한 부하가 발생하게 되기 때문에 캐시를 사용하여 ElastiCache를 통해 캐시가 직접 전송되도록 하여 데이터베이스의 부하를 줄일 수 있습니다. 이 또한 관계형 데이터베이스이기 때문에 AWS가 모든 운영 체제의 유지 보수와 패치 작업, 최적화 설정 등의 백업을 담당합니다.
ElastiCache의 속도가 빠르다보니 기존의 RDS의 부하를 줄여줄 때에, 또는 RDS의 일부 값을 ElastiCache에 보내 빠른 반환을 사용해야 할 때에 사용하는 데이터베이스입니다.
아 참, in-memory라고 하는 것은 메모리 내에서 데이터의 저장 뿐만이 아닌, 연산을 수행하는 것을 의미합니다!
비관계형(NoSQL) 데이터베이스
비관계형 데이터베이스는 특정 데이터 모델을 염두에 두고 특정한 목적을 위해 구축되어 유연한 스키마를 가지고 있습니다. 여기서 스키마는 데이터의 모양을 의미하며, 이는 데이터 모델을 개선하기도 쉽고 확장이 용이하여 분산서버를 추가하면 스케일 아웃이 가능하도록 설계되었습니다. 예를 들어, S3나 IAM을 통해 권한규칙을 추가하고 제거할 때에 JSON을 사용했습니다.
AdministratorAccess의 IAM권한 정책을 살펴보면 다음과 같습니다.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
]
}Version에는 어떠한 시간의 버전인지, Statement안에는 또 다른 데이터를 가진 형태가 존재하는데 어느 리소스에 대해 동작을 수행시킬 것인지에 대한 정보가 나와있습니다. 비교적 형식으로부터 자유로워 수평적 확장이 가능합니다.
관계형 데이터베이스는 서버를 추가로 확장하기가 어려워 성능만을 높이는 수직적 확장을 이용하는 방법 뿐이지만, 비관계형 데이터베이스에서는 서버를 추가로 만드는 수평적 확장도 가능합니다.
DynamoDB
NoSQL 데이터베이스이며 EC2와 마찬가지로 Database에서 대표적인 상품 중 하나라고 할 수 있습니다. 특징으로는 막대한 작업량과 분산된 서버리스 데이터베이스 입니다. 이전에 프로비저닝에 대한 개념을 확인했고 이것이 RDS상에서 ElastiCache와 같이 사용할 때에 가능하다는 것을 알게되었습니다. 그러나 DynamoDB는 서버에 프로비저닝할 필요가 없습니다. 서버리스 데이터베이스라고 불리는 이유입니다.
또한, 초당 수백만 건의 요청과 수백 테라바이트 스토리지까지 확장해도 신속한 성능을 보여줍니다. 따라서 검색 지연 시간이 한 자릿수 밀리초인 성능이 필요로 할 때에 적합한 데이터베이스입니다. 즉, 서버리스의 키워드나 저지연시간 이라는 키워드를 보게되면 DynamoDB를 떠올리시면 됩니다.
DynamoDB는 인 메모리 캐시 기능을 갖고 있어 테이블에 액세스하려고 할 때에 가장 최근에 얽힌 객체를 캐시에 저장할 수 있습니다. 이는 ElastiCache와는 달리 DynamoDB 전용 캐시이며 이 서비스 내에서만 사용할 수 있습니다. 이것이 ElastiCache와의 차이점 입니다. 아까 RDS와 ElastiCache는 같이 사용할 수 있다고 한 부분에서 말이죠.
RDS와의 차이로는 DynamoDB에서는 모든 테이블을 단 하나의 테이블에서 관리하며 또 다른 테이블과의 결합이 불가능하다는 것입니다. 따라서 메인 테이블에 모든 관련 정보가 올바른 양식으로 입력되었는지 확인해보아야 합니다.
DocumentDB
MySQL, PostgreSQL의 경우 Aurora를 사용하면 RDS 보다 3~5배의 성능을 향상시킬수 있다고 했던 것 혹시 기억하시나요? 이와 마찬가지로 MongoDB에서 Aurora의 역할을 수행하는 것이 있습니다. 바로 DocumentDB입니다. 이는 NoSQL에 속하며 MongoDB 기술을 차용하여 만들어졌습니다.
DocumentDB의 배포 원리도 Aurora와 동일하며 이 또한 완전 관리형 데이터베이스이며 가용성이 높습니다.
완전관리형 데이터베이스
Neptune
완전 관리형 그래프 데이터베이스입니다. 그래프 데이터셋의 예로 소셜 네트워크를 들 수 있습니다. 사용자는 코멘트를 달고, 이 코멘트가 어떤 게시물과 연관되어 있고, 다른 사람도 이를 좋아요 또는 공유를 할 수 있습니다. 이 모든 것들이 서로 연결되어있으니 그래프를 생성할 수 있게 되고, 이것이 Neptune이 그래프 데이터셋에 가장 적합한 이유입니다. 소셜 네트워크와 같이 고도로 연결된 데이터셋을 다루는 애플리케이션을 구축 및 실행할 때 사용됩니다.
최대 수십억 개의 관계를 데이터베이스에 저장할 수 있으며 밀리초를 자랑하는 지연 시간 안에 그래프를 쿼리할 수 있습니다.
QLDB (Quantum Ledger Database)
QLDB는 금융 거래를 기록하는 장부의 역할을 합니다. 시간이 지남에 따라 발생한 애플리케이션 데이터의 모든 변경 내역을 살펴볼 때에 사용하므로 Ledger(원장)이라는 이름이 붙여졌습니다. 변경이 불가능한 시스템이기에 데이터베이스에 작성하고 나면 그 후 삭제하거나 수정할 수 없습니다.
이 외에
Redshift
그림에서 보이다시피 RedShift는 데이터베이스라고 칭하기 보다는 데이터베이스 서비스 중 분석을 담당하는 서비스라고 생각하시면 됩니다. RedShift의 특징으로는 OLTP, OLAP가 있는데요 OLTP는 Online Transaction Processing, OLAP는 Online Analytical Processing입니다. 이를 정리해보자면
OLTP는 데이터에 대한 갱신위주라서 어떤 일들이 대량으로 처리될 때에 그것을 어떻게 오류없이 조회하고 갱신시킬 것인가에 대한 일이며 OLAP는 데이터에 대한 조회위주라서 운영하고 있는 데이터에 대한 분석, 고객 데이터 패턴 등을 분석하는 것을 의미합니다. 이러한 전체 행위를 데이터베이스가 웨어하우징된다고 칭합니다.
데이터를 분석하고 일부 연산을 수행하는데에 적합하며, 대규모 병령 쿼리 실행에 적합합니다. 또한 쿼리를 수행하기 위한 SQL 인터페이스도 제공합니다.
EMR (Elastic MapReduce)
EMR또한 RedShift처럼 데이터베이스가 아닌 빅 데이터 작업을 하고자 할 때에 사용하는 Hadoop(방대한 양의 데이터를 분석하고 처리) 클러스터를 생성합니다.
EMR은 모든 EC2 인스턴스의 프로비저닝과 구성을 담당하며 이들 모두 원활하게 작동하여 빅 데이터 관점에서 데이터를 분석할 수 있도록 지원합니다. 또한 오토 스케일링이 가능하며 스팟 인스턴스와 통합됩니다.
Athena
Athena는 서버리스 쿼리 서비스로 S3에 저장된 객체에 대한 분석을 수행합니다. SQL 쿼리언어를 통해 파일을 생성하면 이들을 따로 로드할 필요 없이 S3에 그대로 두면 Athena가 분석을 수행하는 것입니다. 사용자가 S3에 데이터를 로드하면 Athena가 이에 대해 쿼리 작업을 수행하고 데이터를 분석하는 원리입니다. 원하는 경우 Athena에 대한 보고를 살펴볼 수 있는데 이 때에는 Amazon QuickSight를 활용합니다.
Athena는 압축된 데이터나 열 형식으로 저장된 데이터를 다룰 때에는 데이터 스캔을 줄일 수 있으므로 비용을 절감할 수 있습니다. 또한 비즈니스 인텔리전스나 분석, 보고, VPC흐름 로그나 ELB 로그 등의 AWS 로그 분석시에 사용하는데에 적합합니다.
QuickSight
데이터베이스에 대시보드를 만들어 데이터를 시각적으로 나타내고 비즈니스 사용자가 원하는 인사이트를 보여줍니다. 속도도 빠르고 자동으로 확장되어 내장 설정이 가능하고 세션별로 가격을 책정하여 서버를 프로비저닝할 필요가 없습니다. 비즈니스 분석이나 시각화를 구축하고, 임시 분석을 수행할 때에 활용하며 Aurora, Athena, Redshift, S3등의 기반에서도 작동합니다.