DynamoDB 온디맨드 처리량: 측정 결과

새 DynamoDB 온디맨드 테이블은 얼마나 많은 처리량을 받을까?

완전히 새로운 On-demand capacity 테이블은 초당 약 4,130건의 쓰기를 처리합니다 — AWS 문서상 수치는 4,000입니다 — 그리고 최소 초당 최종적 일관성이 있는 읽기 12,700건을 처리합니다. 두 수치 모두 2026-08-27에, 몇 분 전 생성한 테이블을 대상으로 측정했습니다. 베이스라인을 넘어서는 모든 부하에서 쓰기는 4,130 ±2/s에 고정되었고, 읽기는 우리 자체 부하 생성기가 한계에 도달하기 전까지 단 한 번도 스로틀링되지 않았습니다.

이 두 수치와 이 페이지의 다른 모든 내용은 문서를 그대로 옮긴 것이 아니라 실제 서비스에 실제 요청을 보내고 그 결과를 센 것입니다. 측정 방법과 원본 데이터, 그리고 세 번의 실패한 시도는 벤치마크 이야기에 정리되어 있습니다. 이 페이지는 그 수치들이 살아 있는 기준점입니다.

새 테이블의 쓰기 상한

트래픽을 한 번도 받은 적 없는 테이블을 대상으로, 30초 단위 구간마다 부하를 점점 올렸습니다. 모든 요청은 균등 분포로 무작위인 키를 가진 약 1KB 항목을 실었습니다 — Hot partition은 개입하지 않았습니다.

문서화된 4,000 쓰기/s 베이스라인은 유지되며, 그 위로 약 3%의 여유가 있습니다. 상한은 놀라울 만큼 평평합니다. 5,000, 6,000, 8,000을 제공했을 때 달성한 초당 쓰기는 각각 4,132, 4,131, 4,134였습니다. 상한을 넘어서도 지연 시간은 나빠지지 않습니다 — p50 쓰기 지연 시간은 모든 구간에서 리전 내 4–5ms를 유지했습니다. 서비스는 느려지지 않습니다. 거부할 뿐입니다.

스로틀링이 실제로 반환하는 것

첫 거부는 베이스라인을 넘어선 각 구간이 시작되고 0.9–3.8초 뒤에 도착했습니다(제공한 비율이 높을수록 더 빨리 왔습니다). 그대로 옮기면:

ThrottlingException: Throughput exceeds the current capacity of your table or index. DynamoDB is automatically scaling your table or index so please try again shortly. If exceptions persist, check if you have a hot key: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-partition-key-design.html

계획해 둘 것이 두 가지 있습니다. 이것은 5xx가 아니라 HTTP 400입니다 — 5xx만 지켜보는 재시도 정책이나 경보는 온디맨드 스로틀링을 완전히 놓칩니다 (SDK는 기본적으로 이를 재시도합니다. Exponential backoff 참고). 그리고 핫 키 힌트는 진단이 아니라 기본 제안일 뿐입니다 — 우리 키는 균등 분포 무작위였으므로, 작은 규모에서는 이 메시지의 첫 번째 용의자가 키 스키마가 아니라 테이블 수준의 상한입니다. 네 가지 서로 다른 스로틀링 원인은 별도 가이드에 있습니다.

읽기 상한

읽기는 1,000개 항목을 미리 채운 두 번째 새 테이블을 대상으로, Eventually consistent read GetItem(약 1KB, 각각 0.5 읽기 단위)으로 실행했습니다:

모든 비율에서 스로틀링이 전혀 없었습니다. 문서화된 12,000 읽기/s 베이스라인은 유지되며, 실제 한계는 찾지 못했습니다. 16,000/s를 제공했을 때 우리 러너 8개 중 5개가 클라이언트 쪽에서 포화 상태가 되었으므로, 12,762/s는 DynamoDB가 아니라 우리 플릿이 한계에 도달한 지점입니다. 읽기는 리전 내 p50 2–4ms로 응답했습니다.

지속적인 부하에서 상한은 어떻게 늘어나는가

AWS 문서에 따르면 온디맨드 용량은 이전 최고치의 최대 2배까지 수용하도록 늘어나며, 30분 이내에 이전 최고치의 2배를 넘기면 스로틀링될 수 있습니다. 우리는 테이블 하나에 34분 연속으로 8,000 쓰기/s의 부하를 제공했고(1분 미만의 휴지기를 사이에 둔 8분짜리 구간 4개), 상한이 분 단위로 움직이는 모습을 지켜봤습니다:

타임라인을 읽어 보면:

• 첫 번째 상한은 잘 움직이지 않습니다. 처음 8분 내내 테이블은 ~4,000/s 베이스라인을 유지했습니다 — 그 구간 안에서는 지속적인 초과 수요도 상한을 움직이지 못했습니다.
• 증가는 완만한 램프가 아니라 ~1,000/s 단위로 계단식으로 옵니다. 상한은 9분쯤에 ~5,000/s로, 26분쯤에 ~6,000/s로, 그리고 1분 뒤 ~7,000/s로 뛰었고, 이후 끝까지 7,000/s를 그대로 유지했습니다. 각 단계는 1분 사이에 갑작스럽게 나타납니다. 세 단계 중 둘은 우리 구간 경계 근처에서 나타났으므로, 1분 미만의 휴지기가 증가 메커니즘과 상호작용했을 가능성이 있습니다 — 관찰된 그대로 시점을 보고합니다.
• 30분간의 지속적인 수요도 상한을 두 배로 만들지는 못했습니다. 34분 동안 8,000/s를 제공한 뒤 테이블은 7,000/s를 처리했습니다 — 시작 상한의 1.75배로, 제공한 비율에도 못 미치고 정확히 두 배도 아닙니다. 용량이 늘어나면서 스로틀링된 요청은 구간마다 줄어들었습니다(190만 → 50만).

출시일 트래픽이 새 테이블에서 ~4,000 쓰기/s를 넘어설 것 같다면 미리 예열하세요. 이벤트 전에 합성 부하를 흘려보내거나, 테이블의 최대 온디맨드 처리량을 직접 지정해 AWS가 그에 맞춰 프로비저닝하게 하면 됩니다. 온디맨드 대 프로비저닝됨 가이드는 각 모드가 언제 유리한지 다루고, 오토 스케일링은 여기서 자동으로 벌어지는 걸 지켜본 것의 프로비저닝됨 버전에 해당합니다.

우리를 놀라게 한 두 가지 수치

• 생성부터 ACTIVE까지 걸리는 시간은 3배까지 차이 납니다. 새 온디맨드 테이블이 한 번은 7.4초, 다른 두 번은 22초 만에 ACTIVE에 도달했습니다. 같은 리전, 같은 스키마였습니다. 테넌트별 테이블이나 테스트별 테이블을 설계할 때는 느린 경우를 기준으로 여유를 두세요.
• 전체 벤치마크 비용은 $0.97였습니다. 청구된 쓰기 672,116건과 읽기 108만 건입니다. 34분간의 지속 성장 실행에는 $12.67가 추가로 들었습니다. 서비스를 직접 측정하는 비용은 잘못된 용량 결정 한 번보다 저렴합니다 — 이런 워크로드는 DynamoDB 가격 계산기로 미리 가격을 매겨볼 수 있습니다.

범위와 방법, 솔직하게

위 내용은 모두 단계별 테이블 하나, 하루, 리전 하나(us-east-1), 약 1KB 항목, 균등 분포 무작위 키를 기준으로 합니다. 파티션당 한계(초당 읽기 3,000 유닛 / 쓰기 1,000 유닛)는 여기서 측정한 테이블 수준의 동작보다 낮으며 자체적인 실패 모드를 가지고 있습니다. 계정 수준 쿼터와 엄격한 서비스 한계는 같은 방식으로 측정한 DynamoDB 한계 레퍼런스에 있습니다. DynamoDB로 매일 작업한다면, DynoTable이 이를 위한 저희 데스크톱 클라이언트입니다 — 같은 팀이 만들었고, 주장을 반복하기 전에 실제 서비스에 대고 확인하는 같은 습관을 가지고 있습니다.