Amazon DynamoDB 성능/특성 정리: 키 설계로 핫 파티션/비용/스로틀링 줄이기

Amazon DynamoDB 성능/특성 정리: 키 설계로 핫 파티션/비용/스로틀링 줄이기

이 글은 Amazon DynamoDB를 성능/운영 관점에서 길게 정리한 개인 노트입니다. 목표는 "지금 느린 이유"를 증거로 좁히고, 재발을 줄이는 체크리스트를 갖추는 것입니다.

전제: 성능은 DB만으로 결정되지 않습니다. 쿼리 패턴, 데이터 분포, 인덱스/스키마, 애플리케이션 트랜잭션 경계, 인프라(IO/네트워크)가 함께 결정합니다. 그래서 이 글은 '성능 모델(어디서 시간이 쓰이나) -> 설계/쿼리 -> 설정 -> 운영' 순서로 정리합니다.

DynamoDB는 '키 분포 + 용량 모델(RCU/WCU) + 인덱스 비용(GSI)' 3개를 동시에 이해해야 합니다. 스로틀링은 대부분 설계에서 시작합니다.

이 DB를 언제 선택하나

정답은 항상 케이스 바이 케이스지만, 선택을 빠르게 만들기 위해 기준을 먼저 둡니다. 아래에 해당이 많을수록 이 DB를 고려할 만합니다.

- 완전 관리형으로 운영 부담을 최소화하고 싶을 때
- 대규모 트래픽에서 수평 확장과 예측 가능한 지연이 필요할 때
- 조인 없이 액세스 패턴이 키 기반으로 명확한 도메인

성능 모델: 어디서 시간이 쓰이나

DynamoDB 성능은 파티션 키 분포로 결정됩니다. 같은 파티션 키로 트래픽이 몰리면 핫 파티션이 생기고 지연/스로틀링이 나타납니다.

RCU/WCU는 읽기/쓰기 용량 단위라서 아이템 크기, 읽기 유형(강한 일관성/결과 크기)에 따라 실제 소비가 달라집니다. 비용과 성능이 같은 모델에 묶여 있으니 설계 단계에서 계산하는 습관이 필요합니다.

GSI는 조회 패턴을 늘려주지만 쓰기 비용과 복제 비용을 추가합니다. 즉 GSI는 기능이 아니라 비용 구조입니다.

핵심 용어 빠른 사전

성능/장애 분석에서 자주 쓰는 단어는 팀마다 다르게 이해되기 쉽습니다. 용어를 짧게 정의하고, 어떤 지표/증상과 연결되는지 같이 적어둡니다.

용어	설명	실무에서 연결되는 것
Hot partition	특정 파티션에 트래픽 집중	지연/스로틀링의 가장 흔한 원인
RCU/WCU	읽기/쓰기 용량 단위	용량 부족/비용 증가와 직결
GSI	보조 인덱스	조회 패턴 확장, 대신 쓰기 비용 증가
Adaptive capacity	핫 파티션을 완화하는 내부 메커니즘	만능이 아니며 키 설계가 우선
Throttling	용량 초과로 요청 제한	재시도 폭주/지연 증가로 이어짐

옵션/핵심 요소(3~6)

자주 부딪히는 핵심 요소를 표로 먼저 고정해 두면, 장애/튜닝 때 팀 커뮤니케이션이 빨라집니다.

항목	의미	언제 쓰는지(실무 상황)
Partition Key	분산의 기준 키	핫 키를 피하고 트래픽을 골고루 분산할 때
Sort Key	파티션 내 정렬/범위	시간순/버전별 범위 조회를 만들 때
RCU/WCU	용량/비용 단위	스로틀링/비용을 설명하고 조정할 때
GSI	보조 인덱스	추가 조회 패턴이 필요할 때(비용 증가 동반)
On-Demand/Provisioned	용량 모드	트래픽 예측 가능성에 따라 비용 모델 선택

실무 튜닝 포인트(설정/옵션별)

설정에는 정답이 없습니다. 워크로드(읽기/쓰기/동시성/데이터 크기) 기준으로 관측하고 조정합니다. 아래는 실무에서 가장 자주 만지는 레버를 '항목별'로 정리한 것입니다.

partition key design
의미: 키 분포 설계
언제 만지나: 트래픽이 몰리는 키를 분산해야 할 때
주의/트레이드오프: 무작정 랜덤을 섞으면 조회/집계가 어려워질 수 있음

key sharding
의미: 핫 키 분산 기법
언제 만지나: 단일 키에 트래픽이 몰릴 때
주의/트레이드오프: 조회/정렬/집계가 복잡해질 수 있음

GSI projection
의미: GSI 복제 속성 선택
언제 만지나: GSI 크기/비용을 줄일 때
주의/트레이드오프: 필요 속성을 빼면 추가 Get이 필요

capacity mode
의미: 온디맨드/프로비저닝
언제 만지나: 비용/피크를 관리할 때
주의/트레이드오프: 버스트/반응 시간 고려

auto scaling
의미: 용량 자동 조절
언제 만지나: 트래픽 변화가 있는 서비스
주의/트레이드오프: 스케일 반응 시간이 있어 버스트에 취약할 수 있음

consistent read
의미: 강한 일관성 읽기
언제 만지나: 쓰기 직후 읽기 정합성이 필요할 때
주의/트레이드오프: RCU 비용 증가

item size
의미: 아이템 크기
언제 만지나: 비용/지연을 줄이고 싶을 때
주의/트레이드오프: 큰 아이템은 RCU/WCU를 급격히 소모

retry/backoff
의미: 재시도/백오프
언제 만지나: 스로틀링을 견디도록 클라이언트를 설계할 때
주의/트레이드오프: 무작정 재시도는 폭주를 만든다

쿼리/스키마 설계에서 성능이 갈리는 지점

DynamoDB는 테이블 = 조회 패턴이라는 관점이 안전합니다. 사용자별 최근 N개, 상태별 조회, 기간별 조회 같은 패턴을 먼저 정하고, 그 패턴이 PK/SK로 표현되게 설계합니다.

핫 파티션은 인기글/공지/랭킹 같은 도메인 특성에서 자주 나옵니다. 이런 데이터는 키를 분산하거나 별도 테이블/캐시로 분리해 트래픽을 분산해야 합니다.

# 예: USER#id + createdAt
PK = USER#42
SK = 2026-03-02T10:11:12Z

# 상태 조회가 필요하면 GSI
GSI1PK = STATUS#PAID
GSI1SK = 2026-03-02T10:11:12Z

# 핫 키 완화 예(샤드 접두사)
PK = USER#42#SHARD#03

진단 명령/쿼리 모음(바로 실행용)

장애 때는 문서 찾을 시간이 없습니다. 아래는 현장에서 자주 쓰는 '첫 5분' 진단 명령/쿼리만 모은 것입니다. 환경/권한에 따라 일부는 제한될 수 있습니다.

# 테이블 상태/인덱스 확인(AWS CLI)
aws dynamodb describe-table --table-name YOUR_TABLE

# CloudWatch에서 우선 확인할 지표(콘솔에서 확인)
- ThrottledRequests
- ConsumedReadCapacityUnits / ConsumedWriteCapacityUnits
- SuccessfulRequestLatency(p99)
- ReturnedItemCount / ReturnedBytes

# 스로틀링이 있을 때는 재시도(backoff) 정책도 같이 점검

자주 하는 실수(운영/튜닝)

실수 체크리스트:
- 핫 키가 될 수 있는 도메인(랭킹/공지/인기)을 단일 파티션 키로 모델링한다
- RCU/WCU를 계산하지 않고 on-demand/provisioned를 감으로 선택한다
- Throttling 발생 시 무한 재시도로 폭주를 만든다(backoff 없음)
- GSI를 '공짜 인덱스'처럼 추가해 쓰기 비용/지연을 키운다
- read-after-write가 필요한 기능을 일관성 정책 없이 구현한다
- 아이템 크기를 방치해 RCU/WCU 소비가 급증한다

운영/모니터링 체크리스트

운영에서는 throttling, consumed capacity, latency(p99), 그리고 GSI 관련 지표를 핵심으로 둡니다. 스로틀링이 보이면 1) 핫 키인지, 2) 용량이 부족한지, 3) GSI가 병목인지 순서대로 좁힙니다.

공통 체크리스트:
- 느린 쿼리 top N을 지속 수집(시간/호출수/총시간)
- 지연(p95/p99)과 오류율을 애플리케이션 지표와 함께 본다
- 캐시/메모리/디스크 IO 중 무엇이 병목인지 먼저 분리한다
- 복제/HA를 쓰면 일관성 요구가 높은 기능을 분리한다
- 튜닝/변경 후에는 동일 조건으로 재측정해 회귀를 막는다

트러블슈팅 루틴(순서 고정)

장애 때는 선택지가 너무 많아서 흔히 길을 잃습니다. 아래 순서를 팀 표준으로 정해두면, 원인 추적이 빨라지고 '감으로 설정만 만지는' 일을 줄일 수 있습니다.

1) Throttling/latency 증가를 확인한다
2) Consumed RCU/WCU와 용량 모드/오토스케일을 확인한다
3) 핫 파티션(특정 키 집중)을 의심한다
4) 키 샤딩/모델 변경 또는 용량 조정
5) GSI가 병목이면 projection/패턴을 줄이거나 재설계
6) 변경 후 비용과 지연을 같이 재평가한다

문제 상황(정확히 1개)

상황 -> 랭킹 페이지 트래픽이 몰리는 시간에만 스로틀링이 발생한다.
원인 -> 랭킹을 단일 파티션 키에 저장해 핫 파티션이 생겼다.
해결 -> 랭킹 데이터를 샤딩하거나 캐시/별도 저장소로 분리하고, 필요 시 용량/오토스케일을 조정한다.
예방 팁 -> 핫 키가 될 수 있는 도메인 데이터를 설계 단계에서 분리하고 throttling을 조기 경보로 운영한다.

참고/출처

정확한 동작/버전별 차이는 공식 문서를 기준으로 확인합니다. 실무에서는 버전 차이가 곧 성능/장애 차이입니다.

• Amazon DynamoDB Developer Guide
• DynamoDB: Best Practices