DynamoDB 적응형 용량: 할 수 있는 일과 없는 일
DynamoDB는 테이블을 여러 파티션에 걸쳐 분산하지만, 트래픽이 고르게 분산되는 일은 드뭅니다. 버스트 용량과 적응형 용량은 치우친 워크로드가 스로틀링되는 것을 막는 두 가지 자동 메커니즘입니다 — 하드 리밋에 부딪히기 전까지는요.
DynamoDB 적응형 용량이란 무엇인가요?
DynamoDB 적응형 용량은 사용되지 않는 처리량을 쪽으로 이동시켜, 나머지 테이블이 놀고 있는 동안 치우친 키가 스로틀링되지 않게 하는 자동 메커니즘입니다. 버스트 용량과 짝을 이뤄 급증과 지속적인 치우침을 무료로 흡수합니다 — 하지만 단일 키를 파티션 상한 너머로 밀어붙일 수는 없습니다.
- 버스트 용량은 짧은 급증을 넘기도록 사용되지 않은 처리량을 최대 5분(300초)까지 빌려줍니다. 조정하는 기능이 아니라 버퍼입니다.
- 적응형 용량은 의 처리량을 — 테이블의 나머지 사용되지 않은 용량에서 끌어와 — 자동으로 높여서, 치우친 키가 스로틀링되지 않게 합니다.
- 핫 항목을 자체 파티션으로 격리하기까지 합니다. 단일 키에 파티션 상한인 3,000 RCU / 1,000 WCU까지 줍니다.
- 키 설계를 무시해도 된다는 면허가 아닙니다. 파티션당 상한을 넘어서면 빌려올 곳이 남지 않습니다 — 진짜로 뜨거운 키는 여전히 스로틀링됩니다.
먼저 파티션 상한을 알아두세요
모든 파티션은 독립적으로 제한됩니다: 초당 읽기 유닛 3,000개와 쓰기 유닛 1,000개. 그 한계는 프로비저닝된 것이 아니라 물리적입니다 — 프로비저닝된 테이블과 온디맨드 테이블 모두에서 성립합니다. (AWS, Burst and adaptive capacity.)
SQL에서 오면 전체 서버 부하로 추론합니다. DynamoDB에서 스로틀링되는 단위는 단일 파티션이고, 치우친 키 하나가 테이블이 90% 놀고 있는 동안 녹아내릴 수 있습니다. 그것이 두 메커니즘이 메우려 존재하는 공백입니다.
버스트 용량은 짧은 급증을 흡수합니다
파티션의 처리량을 다 쓰지 않을 때마다, DynamoDB는 남은 것을 적립합니다. 그 사용되지 않은 용량의 최대 300초분이 예비로 보관되며, 갑작스러운 버스트가 평소의 초당 속도보다 빠르게 그것을 소진할 수 있습니다.
이것은 보이지 않고 자동입니다. 크기를 정할 수 없고, DynamoDB가 자체 백그라운드 작업에 일부를 조용히 쓸 수도 있습니다. 버스트가 심한 트래픽을 위한 완충으로 취급하세요 — 계획해서 의지할 여유분으로 여기지 마세요.
적응형 용량은 핫 파티션을 부스트합니다
버스트 용량은 짧은 급증을 처리합니다. 적응형 용량은 지속적인 치우침을 처리합니다. 한 파티션이 뜨거운데 이웃들이 놀고 있으면, DynamoDB는 처리량을 뜨거운 파티션 쪽으로 — 테이블 전체 합계와 파티션 상한까지 — 이동시킵니다.
VEHICLE#<id>(파티션)와 TS#<epoch>(정렬)로 키를 잡은 차량 텔레메트리 테이블을
운영한다고 합시다. 플래시 세일 구역의 배달 밴 하나가 다른 어떤 차량보다 10배의 핑을
내보냅니다. 그 파티션은 뜨겁고, 다른 200대 밴의 파티션은 거의 놀고 있습니다.
적응형 용량은 이를 알아채고 그 한 파티션의 처리량을 끌어올리며, 차가운 파티션들의 사용되지 않은 용량에서 끌어옵니다. 설정도, 비용도, 워밍업도 없습니다 — 2019년 5월부터 그 부스트는 사실상 즉각적입니다. (AWS Database Blog, "How DynamoDB adaptive capacity accommodates uneven access patterns".)
뜨거운 밴의 파티션은 150 WCU가 필요하지만 균등 분배된 몫 100 WCU로는 스로틀링됩니다. 적응형 용량이 차가운 파티션들에서 노는 WCU를 빌려와 그것을 감당합니다.
격리: 문제가 단일 항목일 때
치우침이 항상 키 단위인 것은 아닙니다 — 때로는 _단일 항목_이 새하얗게 뜨겁습니다.
끊임없는 트래픽이 VEHICLE#HOT 항목 하나를 몰아붙이면, DynamoDB의 split-for-heat가
파티션을 재조정해 자주 액세스되는 항목이 홀로 떨어지게 합니다.
일단 격리되면, 그 단일 항목의 키는 온전한 파티션 상한: 3,000 RCU와 1,000 WCU를 끌어올 수 있습니다. 그것이 한 키의 절대 천장입니다 — 그 위에 다른 메커니즘은 없습니다. (AWS, Key range throughput exceeded.)
짚어둘 만한 주의점 하나: 적응형 용량은 테이블에 가 있으면 을 파티션 간에 분할하지 않습니다. LSI는 컬렉션을 한 파티션에 묶습니다 — 이유는 GSI vs LSI를 참고하세요.
적응형 용량이 여러분을 구하지 못할 때
이것이 함정입니다. 두 메커니즘 모두 처리량을 옮길 뿐, 어느 쪽도 파티션이 물리적으로 허용하는 것보다 더 많이 만들어내지는 않습니다.
| 시나리오 | 버스트 | 적응형 | 결과 |
|---|---|---|---|
| 짧은 급증, 테이블에 여유 있음 | 감당함 | — | 스로틀링 없음 |
| 지속적 치우침, 차가운 이웃 | — | 핫을 부스트 | 스로틀링 없음 |
| 한 항목, < 3K RCU / 1K WCU | — | 격리함 | 스로틀링 없음 |
| 한 항목, > 파티션 상한 | 빠르게 소진 | 천장에 도달 | 스로틀링됨 — 재설계 필요 |
| 많은 키가 동시에 핫, 테이블 최대 | 빠르게 소진 | 놀 게 없음 | 스로틀링됨 — 재설계 필요 |
단일 키가 정당하게 초당 1,000개 넘는 쓰기가 필요하다면, 어떤 자동 메커니즘도 구해주지 않습니다 — 부하를 더 많은 키에 분산해야 합니다.
쓰기 샤딩이 흔한 해법입니다: 접미사(VEHICLE#HOT#0 … #9)를 붙여 쓰기가
파티션 전반으로 퍼지게 한 다음, 읽기를 다시 팬인합니다.
그 팬인 자체가 의도적으로 모델링해야 할 액세스 패턴입니다. 단일 테이블 설계에서 쿼리 경로를 계획하듯이 말입니다 — 적응형 용량은 시간을 벌어줄 뿐, 키 설계에 대한 무임승차권이 아닙니다.
여러분 자신의 테이블에서 확인하기
적응형 용량은 설계상 보이지 않으므로, 하나의 증상 — 어떤 키가 뜨거운가 — 을 통해
추론합니다. 샤딩된 쓰기 경로를 구축할 때,
Expression Builder가 접미사가 붙은 키의
PutItem과 Query 문법을 생성합니다.
키가 실제로 데이터 전반에 어떻게 분포하는지 지켜보려면, DynoTable을 다운로드해 SQL Workbench에서 파티션 키에 GROUP BY를 실행하고, 적응형 용량이 다 처리해 줄 거라고 가정하기 전에 항목이 키별로 어떻게 쌓이는지 확인하세요. 치우침의 읽기 측면은 Query vs Scan을 참고하세요.