DynamoDB 온디맨드 대 프로비저닝 용량

DynamoDB는 처리량을 두 가지 방식으로 과금합니다. 온디맨드는 요청당 과금합니다. 사용한 만큼 지불하며 0까지 확장됩니다. 프로비저닝은 사용 여부와 관계없이 지불하는 고정된 읽기/쓰기 속도를 예약하며, 단위당 가격은 훨씬 낮습니다. 잘못된 것을 고르는 것은 과다 지불하는 가장 쉬운 방법 중 하나입니다.

감사 로그가 이 선택을 구체적으로 만듭니다. 감사 쓰기는 급증하고 예측 불가능합니다. 밤새 조용하다가, 고객이 대량 작업을 실행하거나 사고가 수천 개의 이벤트를 생성하면 홍수가 됩니다. 그 트래픽 형태가 결정 전체입니다.

DynamoDB 온디맨드와 프로비저닝 용량 중 어느 것을 써야 하나요?

온디맨드는 요청당 과금하며 0까지 확장되므로, 급증하거나 새롭거나 예측 불가능한 트래픽에 안전한 기본값입니다. 프로비저닝은 훨씬 낮은 단위당 가격으로 고정된 읽기/쓰기 속도를 예약하며, 꾸준하고 일정한 트래픽이 그 예약을 충분히 활용할 때만 유리합니다. 볼륨이 검증되고 예측 가능하지 않은 한 온디맨드를 고르세요.

• 온디맨드 = 요청당 과금, 0까지 확장. 계획할 용량이 없습니다. 읽기/쓰기당 더 높은 가격을 내지만 트래픽이 발생할 때만입니다.
• 프로비저닝 = 일정한 속도를 예약, 언제나 지불. 속도가 충분히 활용되면 단위당 훨씬 저렴합니다. 유휴 용량의 비용을 감수합니다.
• 급증하거나 알 수 없는 트래픽은 온디맨드를 부릅니다. 꾸준하고 예측 가능하며 대량인 트래픽은 프로비저닝을 부릅니다(선택적으로 오토 스케일링과 함께).
• 모드를 전환할 수 있지만, 한도는 비대칭적입니다. 프로비저닝에서 온디맨드로는 24시간당 네 번으로 제한되고, 온디맨드에서 프로비저닝으로는 제한이 없습니다. 요청당 토글이 아닙니다.

문제: 쓰지 않는 용량에 지불하기

프로비저닝 용량으로는 이를테면 초당 1,000 쓰기 단위를 커밋합니다. 감사 로그가 평균 초당 50 쓰기지만 사고 당일의 피크에 맞춰 프로비저닝했다면, 하루 종일 1,000에 대해 지불하면서 그 20분의 1을 씁니다. 대신 평균에 맞춰 프로비저닝하면 사고 당일의 홍수가 스로틀링됩니다. 쓰기가 거부됩니다.

그래서 고정 용량은 급증하는 트래픽에 나쁜 절충을 강요합니다. 늘 과다 지불하거나, 과소 프로비저닝하여 가장 중요할 때 쓰기를 떨어뜨리거나. 온디맨드는 바로 그 절충을 없애기 위해 존재합니다.

두 모드의 작동 방식

온디맨드는 실제로 소비한 읽기와 쓰기 요청 단위에 대해 과금하며, 구성할 용량이 없습니다. 이전 트래픽 피크의 두 배까지 급증을 즉시 수용하고, 유휴일 때는 0까지 확장됩니다. 짧은 시간 창 안의 그 2배 도약을 넘어서면 램프업하는 동안 여전히 스로틀링할 수 있습니다. 그 탄력성에 대해 요청당 프리미엄을 지불합니다.

프로비저닝은 초당 일정 개수의 읽기 용량 단위(RCU)와 쓰기 용량 단위(WCU)를 예약합니다. 단위당 가격은 훨씬 낮지만, 쓰든 안 쓰든 그 예약에 대해 지속적으로 지불합니다. 이를 초과하면 오토 스케일링이 활성화되어 구성된 범위 내에서 용량을 키우지 않는 한 DynamoDB가 스로틀링합니다. 다만 오토 스케일링은 분 단위로 반응하므로, 갑작스러운 급증은 따라잡기 전에 여전히 스로틀링할 수 있습니다.

교차점은 활용도입니다. 대략: 꾸준하고 예측 가능한 트래픽이 프로비저닝 용량을 충분히 활용하면 프로비저닝이 가격에서 이깁니다. 트래픽이 급증하거나 폭발적이거나 알 수 없으면, 유휴 예약에 과금하지 않음으로써 온디맨드가 이깁니다.

실전 예제: 감사 로그의 요금

감사 로그는 평균 초당 약 50개의 이벤트를 쓰지만 사고 중에는 수천으로 폭증하며, 읽기 트래픽은 훨씬 낮습니다(규정 준수 내보내기, 가끔 있는 조사). 각 이벤트는 작습니다. 1 KB에 훨씬 못 미칩니다.

프로비저닝에서는 폭증에 맞춰 예약하거나(하루 24시간 그것에 대해 지불) 사고 당일의 홍수를 스로틀링할 위험을 감수해야 합니다. 감사 쓰기를 떨어뜨리기에 가장 나쁜 때입니다. 온디맨드에서는 조용한 시간이 거의 비용이 들지 않고, 최근 피크의 두 배까지의 폭증은 구성 없이 흡수됩니다. 발생한 쓰기에 대해 정확히 지불합니다.

이 워크로드에는 온디맨드가 올바른 기본값입니다. 일반 규칙: 새롭거나 급증하는 모든 테이블은 온디맨드에서 시작하고, 트래픽이 예약을 활용할 만큼 충분히 꾸준하다고 검증된 후에만 프로비저닝으로 옮기세요.

여러분의 숫자를 넣어 보세요 — 초당 읽기/쓰기, 항목 크기, 스토리지 — 한 리전에 대한 두 모드를 나란히 보려면요.

프리 티어를 적용한 전체 멀티 리전 그림을 보려면 DynamoDB 요금 계산기를 사용하세요.

DynoTable에서 해보기

용량 결정은 실제 숫자에서 시작합니다. 항목이 얼마나 큰지, 몇 개인지, 얼마나 빠르게 쓰이는지. 그것을 추측하는 것이 테이블이 잘못 프로비저닝되는 경위입니다.

샘플 이벤트를 실제로 소비하는 RCU/WCU로 바꾸려면 항목 크기 계산기로 돌려 보세요. 그런 다음 실제 테이블에 결정을 뿌리내리세요. DynoTable은 메타데이터 — 항목 수와 크기 — 를 드러내고 대표 항목을 검사하게 해 주므로 정확하게 크기를 잴 수 있습니다.

함정과 다음 단계

• 모드 전환은 속도 제한이 있고, 비대칭적입니다. 프로비저닝에서 온디맨드로는 24시간당 네 번으로 제한되고, 온디맨드에서 프로비저닝으로는 제한이 없습니다. 돌리는 다이얼이 아니라 신중히 검토한 결정으로 다루세요.
• 오토 스케일링은 즉각적이지 않습니다. 분 단위로 반응하므로, 프로비저닝에서 급격한 급증은 용량이 자라기 전에 스로틀링할 수 있습니다. 진정으로 폭발적인 트래픽에는 온디맨드가 급증을 더 잘 처리합니다 — 이전 피크의 두 배까지 즉시요. 급증이 그것을 초과할 것을 안다면(출시나 세일), 폭증 여유를 미리 프로비저닝하도록 테이블에 사전에 웜 스루풋을 설정하세요.
• 핫 파티션은 모드와 관계없이 스로틀링합니다. 온디맨드조차 파티션당 한도가 있습니다. 고르지 않은 키는 테이블이 용량에 여유가 있어 보여도 스로틀링할 수 있습니다. 핫 파티션을 보세요.
• GSI는 자체 용량을 가집니다. 각 인덱스는 별도로 과금되며 과소 프로비저닝되면 베이스 테이블 쓰기를 스로틀링할 수 있습니다. GSI가 베이스 테이블 쓰기를 스로틀링하는 이유를 보세요.

용량 모드는 한 리전에서 테이블을 운영하는 데 지불할 비용을 정합니다. 다음: DynamoDB Global Tables로 여러 리전에 걸쳐 복제하기.

용량 모드에 커밋하기 전에 DynoTable을 다운로드해서 테이블의 실제 크기와 항목 수를 읽으세요.