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

DynamoDB는 처리량을 두 가지 방식으로 청구합니다. 온디맨드는 요청당 청구합니다 — 사용한 만큼 지불하며 0까지 축소됩니다. 프로비저닝은 사용하든 안 하든 지불하는 고정 읽기/쓰기 속도를 단위당 훨씬 낮은 가격으로 예약합니다. 잘못된 쪽을 고르는 것은 과지출하는 가장 쉬운 방법 중 하나입니다.

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

DynamoDB 온디맨드와 프로비저닝 용량 중 어느 것을 사용해야 할까요?

온디맨드는 요청당 청구하고 0까지 축소되므로, 급변하거나 신규이거나 예측 불가능한 트래픽에 대한 안전한 기본값입니다. 프로비저닝은 고정 읽기/쓰기 속도를 훨씬 낮은 단위당 가격으로 예약하며, 지속적이고 안정적인 트래픽이 해당 예약을 충분히 활용할 때만 유리합니다. 트래픽이 검증되고 예측 가능하지 않다면 온디맨드를 선택하세요.

• 온디맨드 = 요청당 지불, 0까지 축소. 계획할 용량이 없으며, 읽기/쓰기당 더 높은 가격을 내지만 트래픽이 발생할 때만 냅니다.
• 프로비저닝 = 일정한 속도를 예약, 항상 지불. 속도가 잘 활용되면 단위당 훨씬 저렴하지만, 유휴 용량의 비용을 떠안습니다.
• 불규칙 / 알 수 없는 트래픽 → 온디맨드. 안정적이고 예측 가능하며 대용량 트래픽 → 프로비저닝(선택적으로 오토스케일링과 함께).
• 모드를 전환할 수 있지만, 24시간당 제한된 횟수만 가능합니다 — 요청별로 켰다 껐다 하는 토글이 아닙니다.

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

프로비저닝 용량으로는, 예를 들어 초당 1,000 쓰기 단위를 약정합니다. 감사 로그가 평균 초당 50 쓰기인데 사고 당일 피크에 맞춰 프로비저닝했다면, 하루 종일 1,000을 지불하면서 그중 20분의 1을 사용합니다. 대신 평균에 맞춰 프로비저닝하면 사고 당일의 쏟아짐이 스로틀링됩니다 — 쓰기가 거부됩니다.

따라서 고정 용량은 불규칙한 트래픽에 나쁜 거래를 강요합니다: 계속 과지출하거나, 아니면 과소 프로비저닝하여 가장 중요한 순간에 쓰기를 떨어뜨리거나. 온디맨드는 바로 그 거래를 없애기 위해 존재합니다.

두 모드의 작동 방식

온디맨드는 실제로 소비한 읽기 및 쓰기 요청 단위에 대해 청구하며, 구성할 용량이 없습니다 — 트래픽 급증을 즉시 수용하고 유휴 상태일 때 0까지 축소됩니다. 그 탄력성에 대해 요청당 프리미엄을 지불합니다.

프로비저닝은 초당 일정 수의 Read Capacity Units(RCU)와 Write Capacity Units(WCU)를 예약합니다. 단위당 가격은 훨씬 낮지만, 사용하든 안 하든 예약에 대해 지속적으로 지불합니다. 이를 초과하면 DynamoDB가 스로틀링하는데, 단 구성된 범위 내에서 용량을 늘리는 오토스케일링이 활성화되어 있으면 예외입니다 — 다만 오토스케일링은 수 분에 걸쳐 반응하므로, 갑작스러운 급증은 따라잡기 전에 여전히 스로틀링될 수 있습니다.

분기점은 활용도입니다. 대략적으로: 지속적이고 예측 가능한 트래픽이 프로비저닝 용량을 잘 활용한다면 프로비저닝이 가격에서 이깁니다. 트래픽이 불규칙하거나 폭발적이거나 알 수 없다면, 유휴 예약에 청구하지 않는 온디맨드가 이깁니다.

실전 예시: 감사 로그의 청구서

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

프로비저닝에서는 폭발에 맞춰 예약하거나(이를 하루 종일 지불) 사고 당일의 쏟아짐을 스로틀링할 위험을 감수해야 합니다 — 감사 쓰기를 떨어뜨릴 최악의 순간에 말입니다. 온디맨드에서는 조용한 시간이 거의 비용이 들지 않고 폭발이 자동으로 흡수됩니다. 실제로 발생한 쓰기에 대해서만 정확히 지불합니다.

이 워크로드에는 온디맨드가 올바른 기본값입니다. 일반 규칙: 새롭거나 불규칙한 테이블이라면 온디맨드로 시작하고, 트래픽이 예약을 활용할 만큼 충분히 안정적이라는 것이 입증된 뒤에만 프로비저닝으로 옮기세요.

직접 숫자를 넣어보세요 — 초당 읽기/쓰기, 항목 크기, 스토리지 — 그러면 한 리전에 대한 두 모드를 나란히 볼 수 있습니다:

프리 티어가 적용된 전체 멀티 리전 그림은 DynamoDB 요금 계산기를 사용하세요.

DynoTable에서 해보기

용량 결정은 실제 숫자에서 시작합니다: 항목이 얼마나 큰지, 몇 개나 있는지, 얼마나 빨리 쓰여지고 있는지. 이를 추측하는 것이 테이블을 잘못 프로비저닝하게 되는 원인입니다.

샘플 이벤트를 실제로 소비하는 RCU/WCU로 환산하려면 항목 크기 계산기를 통해 실행하세요. 그런 다음 실제 테이블로 결정을 뒷받침하세요: DynoTable은 그 메타데이터 — 항목 수와 크기 — 를 표시하고 대표적인 항목을 검사하게 해주므로 정확하게 크기를 측정할 수 있습니다.

함정과 다음 단계

• 모드 전환은 횟수가 제한됩니다. 온디맨드와 프로비저닝 사이를 변경할 수 있지만 24시간당 제한된 횟수만 가능합니다 — 막 돌리는 다이얼이 아니라 신중히 고려한 결정으로 다루세요.
• 오토스케일링은 즉각적이지 않습니다. 수 분에 걸쳐 반응하므로, 프로비저닝에서 날카로운 급증은 용량이 늘기 전에 스로틀링될 수 있습니다. 진정으로 폭발적인 트래픽에는 온디맨드가 급증을 직접 흡수합니다.
• 핫 파티션은 모드와 무관하게 스로틀링됩니다. 온디맨드조차 파티션별 한도가 있습니다 — 고르지 않은 키는 테이블이 용량 미달로 보여도 스로틀링될 수 있습니다. 핫 파티션을 참고하세요.
• GSI에는 자체 용량이 있습니다. 각 인덱스는 별도로 청구되며, 과소 프로비저닝되면 기본 테이블 쓰기를 스로틀링할 수 있습니다 — GSI가 기본 테이블 쓰기를 스로틀링하는 이유를 참고하세요.

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

용량 모드를 확정하기 전에 테이블의 실제 크기와 항목 수를 읽으려면 DynoTable을 다운로드하세요.