AWS 특수 목적 데이터베이스
더 많은 작업
- AWS Purpose-built Databases; AWS 목적별 데이터베이스; AWS 특수 목적 데이터베이스
- 하나의 범용 DB에 모든 데이터를 넣지 않고, 데이터 모델과 접근 패턴에 맞춰 만든 데이터베이스를 골라 쓰는 AWS의 데이터베이스 설계 방식과 그에 해당하는 서비스 묶음
예전에는 대부분의 데이터를 관계형 데이터베이스 하나에 담았다. 하지만 초당 수백만 건의 단순 조회, 친구의 친구를 찾는 관계 탐색, 센서 값의 시계열 집계, 페타바이트 분석은 요구하는 저장 구조와 확장 방식이 서로 다르다. AWS는 이런 요구별로 관계형, 키-값, 인메모리, 문서, 그래프, 와이드 컬럼, 시계열, 데이터 웨어하우스 데이터베이스를 따로 제공한다. 마이크로서비스마다 자기 데이터 성격에 맞는 DB를 고르는 것이 기본 전략이다.
SAA 시험에서는 "이 데이터와 요구에 가장 맞는 DB 서비스는?"이라는 문제가 자주 나온다. 아래 표의 '고르는 신호'를 문제 문장의 단서와 연결하면 된다.
| 유형 | 서비스 | 데이터 모델·호환 | 고르는 신호 |
|---|---|---|---|
| 관계형 | 아마존 RDS, 아마존 Aurora | 테이블, SQL, 조인, 트랜잭션. RDS는 MySQL·PostgreSQL·MariaDB·Oracle·SQL Server·Db2, Aurora는 MySQL·PostgreSQL 호환 | 정형 데이터, 복잡한 조인·트랜잭션, 기존 상용 DB 이전 |
| 키-값 | 아마존 DynamoDB | 키-값·문서, 서버리스 | 어떤 규모에서도 한 자릿수 밀리초 응답, 예측 불가 트래픽, 세션·장바구니·게임 상태 |
| 인메모리(캐시) | 아마존 ElastiCache | Valkey·Redis OSS·Memcached | DB 앞의 캐시, 세션 저장소, 마이크로초 응답 |
| 인메모리(주 DB) | 아마존 MemoryDB | Valkey·Redis OSS 호환, 다중 AZ 내구성 | 캐시가 아니라 데이터가 남아야 하는 초고속 주 데이터베이스 |
| 문서 | 아마존 DocumentDB | MongoDB 호환 JSON 문서 | MongoDB 애플리케이션 이전, 스키마가 유연한 콘텐츠·카탈로그·사용자 프로필 |
| 그래프 | 아마존 Neptune | 속성 그래프(Gremlin, openCypher), RDF(SPARQL) | 관계 탐색: 소셜 네트워크, 추천, 사기 탐지, 지식 그래프 |
| 와이드 컬럼 | 아마존 Keyspaces | Apache Cassandra 호환(CQL), 서버리스 | Cassandra 워크로드 이전, 대량 쓰기, 서버 관리 없음 |
| 시계열 | 아마존 Timestream | 시간 순서 측정값 | IoT 센서, 애플리케이션 지표, 산업 장비 텔레메트리 |
| 데이터 웨어하우스 | 아마존 Redshift | 열 기반 MPP, SQL | 대규모 분석, BI 대시보드, OLAP |
아마존 DocumentDB(with MongoDB compatibility)는 MongoDB와 호환되는 관리형 문서 데이터베이스이다. MongoDB에서 쓰던 애플리케이션 코드, 드라이버, 도구를 그대로 쓸 수 있다.
- 인스턴스 기반 클러스터는 Aurora처럼 컴퓨팅과 스토리지를 분리한 구조이다. 같은 스토리지를 공유하는 복제본을 최대 15개까지 두어 읽기를 확장하고, 장애 시 다른 가용 영역의 복제본으로 자동 장애 조치한다. 리더 엔드포인트로 읽기를 분산한다.
- 엘라스틱 클러스터(elastic clusters)는 샤딩으로 초당 수백만 건의 읽기·쓰기와 페타바이트 저장 용량을 지원한다.
- 보존 기간(최대 35일) 안의 특정 시점으로 복구하는 연속 백업과 KMS 암호화를 지원한다.
아마존 Neptune은 관계가 촘촘하게 얽힌 데이터를 저장하고 수십억 개의 관계를 밀리초 단위로 탐색하는 관리형 그래프 데이터베이스이다.
- 속성 그래프 모델은 Apache TinkerPop Gremlin과 openCypher로, RDF 모델은 W3C 표준 SPARQL로 쿼리한다.
- 공유 클러스터 볼륨에 여러 가용 영역의 사본을 두고, 읽기 복제본을 최대 15개까지 둔다.
- 추천 엔진, 사기 탐지, 지식 그래프, 네트워크 보안 분석에 쓴다. SQL로 여러 단계의 자기 조인을 해야 하는 문제를 그래프 탐색으로 단순하게 만든다.
- 대량의 그래프 데이터를 메모리에서 빠르게 분석하는 Neptune Analytics도 있다.
아마존 Keyspaces(for Apache Cassandra)는 Apache Cassandra와 호환되는 서버리스 와이드 컬럼 데이터베이스이다.
- 기존 Cassandra 애플리케이션 코드와 CQL(Cassandra Query Language) 도구를 그대로 쓰고, 서버 프로비저닝·패치·클러스터 운영을 하지 않는다.
- 읽기·쓰기 용량 모드는 온디맨드와 프로비저닝(자동 조정 가능) 중에서 고른다.
- 데이터 사본 3개를 여러 가용 영역에 저장한다. 저장 데이터 암호화가 기본으로 켜지고 모든 연결에 TLS를 요구한다.
아마존 Timestream은 시간 순서로 쌓이는 측정값을 저장하고 분석하는 시계열 데이터베이스 서비스이다. 두 가지 형태가 있다.
- Timestream for LiveAnalytics: 서버리스 시계열 DB로, 최근 데이터는 메모리 저장소에, 오래된 데이터는 비용 최적화 저장소에 자동으로 옮기며 시계열 분석 함수를 내장한다. 다만 2025년 6월 20일부터 신규 고객에게 열려 있지 않다. 기존 고객은 계속 쓸 수 있다.
- Timestream for InfluxDB: 오픈소스 InfluxDB를 관리형으로 제공한다. AWS는 신규 고객에게 LiveAnalytics 대신 이 옵션을 검토하라고 권한다. 실시간 분석에서 한 자릿수 밀리초 쿼리 응답을 낸다.
시계열 데이터를 관계형 DB에 넣으면 시간 범위 집계와 오래된 데이터 정리가 비싸지는데, 시계열 DB는 이 패턴에 맞게 저장 계층과 함수를 갖추고 있다.
아마존 MemoryDB는 Valkey·Redis OSS와 호환되는 내구성 있는 인메모리 데이터베이스이다.
- 모든 데이터를 메모리에 두어 읽기는 마이크로초, 쓰기는 한 자릿수 밀리초 지연을 낸다.
- 쓰기를 여러 가용 영역에 걸친 트랜잭션 로그에 기록해 노드 장애나 재시작에도 데이터가 남는다.
- 캐시와 별도 영구 DB를 따로 운영하지 않고 MemoryDB 하나를 마이크로서비스의 주 데이터베이스로 쓴다.
| 구분 | ElastiCache | MemoryDB |
|---|---|---|
| 역할 | 다른 DB 앞의 캐시(주로) | 주 데이터베이스 |
| 내구성 | 캐시 성격, 데이터 유실을 감수하거나 원본에서 재생성 | 다중 AZ 트랜잭션 로그로 데이터 보존 |
| 쓰기 지연 | 더 낮음 | 한 자릿수 밀리초(로그 기록 때문) |
- 아마존 QLDB(원장 데이터베이스)는 서비스가 종료되어 현재 시험 범위 서비스 목록에도 없다. 변경 이력 검증용 원장 문제를 만나면 QLDB를 정답으로 고르지 않는다.
- Timestream for LiveAnalytics는 위에서 설명한 대로 신규 고객 접근이 닫혔다.
- 대규모 분석·집계·BI인가? 그렇다면 Redshift(S3 데이터를 가끔 조회하면 아마존 아테나).
- 관계 탐색이 핵심인가? 그렇다면 Neptune.
- 시간 순서 측정값인가? 그렇다면 Timestream.
- 기존 MongoDB·Cassandra를 옮기는가? 그렇다면 DocumentDB·Keyspaces.
- 조인과 복잡한 트랜잭션이 필요한 정형 데이터인가? 그렇다면 RDS·Aurora.
- 키로 찾는 단순 접근을 어떤 규모에서도 빠르게 처리해야 하는가? 그렇다면 DynamoDB.
- 마이크로초 응답이 필요한가? 캐시면 ElastiCache, 데이터가 남아야 하면 MemoryDB.
- "MongoDB 호환", "기존 MongoDB 이전"은 DocumentDB, "Cassandra"는 Keyspaces, "그래프", "관계", "소셜 네트워크", "사기 탐지"는 Neptune을 고른다.
- "IoT 센서 데이터", "시계열"은 Timestream이지만, 신규 구성에서는 Timestream for InfluxDB가 현행 선택지라는 점을 기억한다.
- "Redis 호환 + 내구성 + 주 데이터베이스"는 MemoryDB, "DB 앞 캐시"는 ElastiCache로 구분한다.
- 관계형 데이터를 DynamoDB로, 키-값 대량 접근을 RDS로 처리하는 식으로 데이터 모델과 DB 유형이 어긋난 선택지는 오답이다.
- 비용 최적화 문제에서는 열 형식(분석)은 Redshift, 시계열 형식은 Timestream처럼 데이터 형식에 맞춘 DB가 범용 DB보다 싸고 빠르다는 논리를 쓴다.