다이나모DB
더 많은 작업
아마존 DynamoDB는 서버를 프로비저닝하거나 관리할 필요가 없는 완전 관리형 분산 NoSQL 데이터베이스이다. 사용자 10명이든 1억 명이든 일정한 한 자릿수 밀리초 응답을 목표로 하며, 테이블 크기에 사실상 제한이 없다. 데이터는 기본으로 리전 안의 3개 가용 영역에 자동 복제되고, 단일 리전 테이블은 99.99%, 글로벌 테이블은 99.999% 가용성 SLA가 붙는다. 장바구니, 사용자 세션, 게임 상태, IoT 기기 상태, 서버리스 애플리케이션의 백엔드처럼 키로 찾는 접근이 대부분이고 규모와 트래픽 변동이 큰 운영 작업에 쓴다.
| 구성 요소 | 설명 |
|---|---|
| 테이블 | 항목(item)의 모음. 스키마는 기본 키만 정하고 나머지 속성은 항목마다 자유롭다. |
| 항목 | 관계형 DB의 행에 해당. 속성(attribute)의 모음이며 중첩된 문서(맵, 리스트)도 담는다. |
| 파티션 키 | 단순 기본 키. 값을 내부 해시 함수에 넣어 저장될 파티션을 정한다. 파티션 키만 쓰는 테이블에서는 같은 값이 두 번 나올 수 없다. |
| 파티션 키 + 정렬 키 | 복합 기본 키. 같은 파티션 키의 항목들이 정렬 키 순서로 함께 저장되어 범위 조회(예: 한 고객의 최근 주문)가 가능하다. |
접근 패턴을 먼저 정하고 키를 설계하는 것이 핵심이다. 파티션 키 값이 고르게 퍼지지 않으면 특정 파티션에 요청이 몰리는 핫 파티션이 생긴다. 조인이 없으므로 함께 읽을 데이터는 같은 항목이나 같은 파티션에 모으는 방식으로 설계한다.
| 구분 | 온디맨드 | 프로비저닝 |
|---|---|---|
| 과금 | 읽기·쓰기 요청 수만큼(pay-per-request). 트래픽이 없으면 처리량 요금 없음 | 초당 읽기 용량 단위(RCU)·쓰기 용량 단위(WCU)를 미리 정하고 그만큼 과금 |
| 확장 | 자동, 용량 계획 불필요. 이전에 도달한 수준까지 즉시 수용 | Auto Scaling(Application Auto Scaling 목표 추적)으로 최소·최대 범위 안에서 조정 |
| 맞는 경우 | 새 애플리케이션, 예측 불가하거나 들쭉날쭉한 트래픽, AWS 권장 기본값 | 예측 가능하고 꾸준한 트래픽, 비용 최적화 |
- 1 RCU: 4KB 이하 항목에 대해 초당 강력한 일관성 읽기 1회 또는 최종 일관성 읽기 2회
- 1 WCU: 1KB 이하 항목에 대해 초당 쓰기 1회
- 예: 3KB 항목을 초당 80개 강력한 일관성으로 읽으려면 항목당 1 RCU(3KB/4KB 올림)이므로 80 RCU, 최종 일관성이면 40 RCU가 필요하다.
- 최종 일관성 읽기(eventually consistent, 기본값): 방금 끝난 쓰기가 바로 반영되지 않을 수 있지만 잠시 뒤에는 최신 값이 나온다. 강력한 일관성 읽기의 절반 비용이다.
- 강력한 일관성 읽기(strongly consistent):
ConsistentRead를 true로 주면 성공한 모든 이전 쓰기를 반영한 값을 돌려준다. 테이블과 LSI에서만 되고 GSI와 스트림에서는 안 된다.
기본 키가 아닌 속성으로 조회하려면 보조 인덱스를 만든다.
| 구분 | 글로벌 보조 인덱스(GSI) | 로컬 보조 인덱스(LSI) |
|---|---|---|
| 키 | 테이블과 다른 파티션 키·정렬 키 가능 | 테이블과 같은 파티션 키, 다른 정렬 키 |
| 조회 범위 | 테이블 전체(모든 파티션) | 같은 파티션 키 값 안 |
| 생성 시점 | 테이블 생성 때나 나중에 추가·삭제 가능 | 테이블 생성 때만. 나중에 추가·삭제 불가 |
| 일관성 | 최종 일관성만 | 최종 또는 강력한 일관성 |
| 처리량 | 인덱스 자체의 용량 사용 | 테이블의 용량 사용 |
| 크기 제한 | 없음 | 파티션 키 값 하나당 인덱싱된 항목 합계 10GB 이하 |
| 개수 | 테이블당 기본 20개(할당량) | 테이블당 5개 |
- DynamoDB Streams: 테이블 항목의 변경(생성·수정·삭제)을 시간 순서대로 최대 24시간 보관하는 로그이다. 변경 전후 이미지를 담을 수 있고 각 레코드는 스트림에 정확히 한 번 나타난다. AWS Lambda 트리거로 연결해 주문이 들어오면 알림을 보내거나, 다른 저장소와 동기화하는 이벤트 기반 아키텍처를 만든다.
- TTL(Time to Live): 항목마다 만료 시각 속성을 두면 만료 후 보통 며칠 안에 DynamoDB가 쓰기 용량을 쓰지 않고 자동 삭제한다. 세션, 임시 토큰, 오래된 로그 정리에 쓴다. 삭제는 스트림에 서비스 삭제로 기록되므로 Lambda로 받아 S3에 보관할 수도 있다.
글로벌 테이블은 여러 리전에 복제본 테이블을 두고 모든 리전에서 읽기와 쓰기를 받는 다중 활성(multi-active) 복제 기능이다. 각 리전 사용자는 가까운 리전에서 짧은 지연으로 읽고 쓰며, 리전 장애 때 다른 리전으로 트래픽을 돌린다.
- 다중 리전 최종 일관성(MREC, 기본값): 리전 간 복제가 비동기이며 충돌 시 마지막 쓰기가 이긴다.
- 다중 리전 강력한 일관성(MRSC): 어느 리전에서든 최신 데이터를 읽을 수 있다. 같은 계정 구성에서만 되며, 만든 뒤에는 일관성 모드를 바꿀 수 없다.
DynamoDB Accelerator(DAX)는 DynamoDB 전용 인메모리 캐시이다. 최종 일관성 읽기의 응답 시간을 한 자릿수 밀리초에서 마이크로초로 줄이고, 반복 읽기를 테이블에서 덜어 낸다. DynamoDB API와 호환되므로 애플리케이션 코드를 거의 고치지 않는다. 다만 강력한 일관성 읽기가 필요하거나 마이크로초 응답이 필요 없는 애플리케이션에는 맞지 않는다. 범용 캐시가 필요하면 아마존 ElastiCache를 쓴다.
TransactWriteItems와 TransactGetItems로 여러 테이블의 여러 항목을 모두 성공하거나 모두 실패하는 단위로 묶는다. 계좌 이체, 재고 차감과 주문 생성처럼 여러 항목을 함께 바꿔야 할 때 쓴다. 트랜잭션 기능 자체에 추가 요금은 없지만, 항목마다 준비와 커밋 두 번의 읽기·쓰기가 일어나 일반 요청보다 용량을 두 배 쓴다.
- 특정 시점 복구(PITR): 켜 두면 최대 35일(1~35일로 조정 가능) 안의 원하는 시각으로 초 단위 복구한다. 복원은 새 테이블로 만들어지며, 다른 리전으로 복원할 수도 있다.
- 온디맨드 백업: 원하는 때 전체 백업을 만들고 장기 보관한다. AWS Backup으로 다른 서비스와 함께 관리할 수 있다.
- 트래픽이 예측 불가하고 어떤 규모에서도 일정한 밀리초 응답, 서버 관리 없음이 요구되면 DynamoDB를 고른다. 복잡한 조인과 SQL 분석이 필요하면 RDS·Aurora나 Redshift이다.
- 트래픽을 예측할 수 없거나 새 서비스면 온디맨드, 꾸준하고 예측 가능하면 프로비저닝과 Auto Scaling이 비용 효율적이다.
- 읽기 응답을 마이크로초로 줄이라는 요구는 DAX이다. ElastiCache를 붙이는 선택지보다 코드 변경이 적다.
- 여러 리전에서 낮은 지연으로 읽고 쓰는 전 세계 애플리케이션은 글로벌 테이블이다.
- 항목 변경 시 Lambda로 후속 처리를 하려면 DynamoDB Streams, 오래된 항목을 비용 없이 자동 삭제하려면 TTL을 쓴다.
- 기본 키가 아닌 속성으로 조회해야 하는데 테이블이 이미 있으면 GSI를 추가한다. LSI는 테이블 생성 때만 만들 수 있다.