DynamoDB는 얼마나 빠른가요?
빠릅니다. DynamoDB는 어떤 규모에서도 일관된 한 자릿수 밀리초의 읽기·쓰기 지연 시간을 제공합니다. 인메모리 캐시인 DynamoDB Accelerator(DAX)를 더하면 최종적 일관성 읽기가 마이크로초로 줄어듭니다. 읽기가 스캔이 아니라 파티션 키를 직접 겨누기 때문에 테이블이 커져도 성능이 평탄하게 유지되며, 지연 시간이 데이터 양에 따라 나빠지지 않습니다.
규모가 커져도 빠른 이유
GetItem이나 Query는 파티션 키를 해시해서 올바른 물리 파티션으로 곧장 갑니다. 테이블 전체를 훑지 않으므로, 테이블에 항목이 수천 개든 수십억 개든 응답 시간은 대체로 일정합니다.
DAX로 하는 마이크로초 읽기
DAX는 여러분의 테이블 앞에 서는 완전 관리형 DynamoDB 호환 인메모리 캐시입니다. 최종적 일관성 읽기를 마이크로초로 — 밀리초 대비 최대 10배 개선으로 — 돌려주며, 관리할 캐시 무효화가 없습니다. 강력한 일관성 읽기가 필요한 워크로드에는 맞지 않습니다.
사용자가 실제로 보는 숫자
한 자릿수 밀리초는 DynamoDB endpoint에서 측정한 값입니다. 여러분의 애플리케이션이 겪는 것은 거기에 네트워크를 더한 것이고, 대개 네트워크 쪽이 훨씬 큰 절반입니다.
2026-07-28에 스페인의 머신 한 대에서, 리전마다 아홉 번씩 표본을 잡아 각 리전 DynamoDB endpoint까지의 TCP 핸드셰이크 중앙값을 측정했습니다. 요청 바이트를 하나도 보내기 전인 왕복 한 번입니다:
| 리전 | TCP 핸드셰이크 중앙값 |
|---|---|
| eu-central-1 (프랑크푸르트) | 46.6 ms |
| eu-south-2 (스페인) | 49.1 ms |
| eu-west-1 (아일랜드) | 53.8 ms |
| us-east-1 (북버지니아) | 113.6 ms |
| ap-northeast-1 (도쿄) | 259.5 ms |
머신 하나, ISP 하나, 오후 한나절이므로 벤치마크가 아니라 자릿수로 읽으세요. 그 안에서 두 가지는 일반적으로 성립합니다. 대서양을 건너는 왕복은 그것이 실어 나르는 읽기의 열 배가 넘으므로, 그 거리에서 DynamoDB의 지연 시간은 여러분의 지연 시간에서 반올림 오차입니다. 그리고 머신에서 지리적으로 가장 가까운 리전이 가장 빠른 리전은 아니었습니다. eu-south-2는 스페인에 있는데 프랑크푸르트보다 나을 게 없었습니다. 거리가 아니라 라우팅이 결정하기 때문입니다.
실용적으로 옮기면, 테이블과 컴퓨트를 같은 곳에 두는 것이 여러분이 할 수 있는 어떤 DynamoDB 튜닝보다 낫습니다. 테이블과 같은 리전의 Lambda 함수는 위 수치의 일부만 내고, 다른 대륙의 노트북이나 CI 작업은 연결할 때마다 전부를 냅니다. SDK 연결 재사용이 보이는 것보다 더 중요한 이유이기도 합니다.
무엇이 여러분을 느리게 만드나
- 스캔과 필터 — 테이블 전체를 읽는 것은 느리고 비쌉니다. 대신 키 기반 액세스를 설계하세요.
- 핫 파티션 — 하나의 파티션 키가 자기 몫보다 훨씬 많은 트래픽을 끌어당기면, 테이블 전체 용량이 멀쩡한데도 그 파티션에 대한 요청이 스로틀링됩니다.
DynamoDB를 빠르게 유지하는 것은 더 많은 하드웨어가 아니라 좋은 키 설계입니다.
더 알아보기
query vs scan을 읽고 핫 파티션을 피하세요. 어떤 읽기가 Query로, 어떤 읽기가 Scan으로 실행되는지 보려면 DynoTable을 다운로드하세요.
참고 자료
- Fast NoSQL Key-Value Database — Amazon DynamoDB — AWS
- In-memory acceleration with DynamoDB Accelerator (DAX) — Amazon DynamoDB Developer Guide
- What is Amazon DynamoDB? — Amazon DynamoDB Developer Guide
- Core components of Amazon DynamoDB — Amazon DynamoDB Developer Guide
위에 링크된 공식 AWS 문서를 기준으로 2026-07-13에 마지막으로 검증했습니다.
지연 시간 수치는 2026-07-28에 스페인의 머신 한 대에서 curl로, 리전마다 아홉 번씩 요청해 https://dynamodb.<region>.amazonaws.com에 대한 time_connect 빼기 time_namelookup의 중앙값으로 측정했습니다. 두 번의 독립 실행이 3 ms 이내로 일치했습니다.