프로비저닝된 용량과 온디맨드 용량

DynamoDB는 처리량을 읽기 용량 단위(RCU)와 쓰기 용량 단위(WCU)로 측정합니다. RCU 1개는 최대 4KB인 항목에 대해 초당 강한 일관성 읽기 1회(또는 최종 일관성 읽기 2회)를 허용합니다. WCU 1개는 최대 1KB인 항목에 대해 초당 쓰기 1회를 허용합니다.

항목이 더 크면 비용도 비례하여 증가합니다. 예를 들어 10KB 쓰기에는 WCU 10개가 필요하고, 10KB 강한 일관성 읽기에는 RCU 3개가 필요합니다(ceil(10/4) = 3). 용량 단위를 이해하는 것은 비용을 추정하고 ProvisionedThroughputExceededException 조절 오류를 진단하는 데 필수적입니다.

프로비저닝 용량 모드에서는 테이블이 지원해야 하는 RCU와 WCU의 정확한 수를 지정합니다. DynamoDB는 해당 처리량을 예약하고 실제 사용 여부와 관계없이 요금을 부과합니다. 애플리케이션이 프로비저닝된 용량을 초과하면 요청이 조절되고 ProvisionedThroughputExceededException이 반환됩니다.

프로비저닝 모드는 예측 가능하고 안정적인 트래픽이 발생하는 워크로드에 적합합니다. 단위당 비용이 온디맨드 모드보다 낮으며, DynamoDB 예약 용량을 구매하여 비용을 더 줄일 수도 있습니다(최대 76% 할인, 1년 또는 3년 약정).

온디맨드 모드에서 DynamoDB는 용량을 사전에 계획하지 않아도 모든 수준의 트래픽을 수용하도록 자동으로 확장됩니다. 실제로 소비한 요청 단위별로 요금을 지불합니다. 즉, 읽기 요청 단위(RRU)와 쓰기 요청 단위(WRU)를 기준으로 과금됩니다. 관리해야 할 프로비저닝 용량이 없으며 프로비저닝 한도에 따른 조절도 발생하지 않습니다.

온디맨드 모드는 예측할 수 없거나 급증하는 워크로드, 트래픽을 알 수 없는 새 테이블, 액세스가 드문 개발 및 테스트 환경에 적합합니다. 요청당 비용은 프로비저닝 모드보다 높으므로 안정적으로 높은 처리량이 필요한 워크로드에는 프로비저닝 모드가 더 경제적입니다.

콘솔이나 CLI를 사용하여 언제든지 테이블을 프로비저닝 모드와 온디맨드 모드 사이에서 전환할 수 있습니다. 그러나 모드 전환은 24시간에 한 번만 가능합니다. 온디맨드로 전환한 후에도 테이블은 이전에 프로비저닝된 최대 용량을 초기 처리량 수준으로 유지하므로, 트래픽이 이미 높은 경우에도 즉각적인 조절을 방지할 수 있습니다.

일반적인 전략은 트래픽 패턴을 알 수 없는 초기 출시 단계에서는 온디맨드를 사용하고, 트래픽이 예측 가능해지면 자동 확장이 적용된 프로비저닝 모드로 전환하여 비용을 줄이는 것입니다.

DynamoDB 자동 확장은 실제 트래픽에 따라 프로비저닝된 RCU와 WCU를 자동으로 조정합니다. 목표 사용률(예: 70%)과 최소/최대 용량 범위를 정의하면 됩니다. 애플리케이션 자동 확장 정책이 테이블의 소비 용량을 모니터링하고 목표 사용률을 유지하도록 프로비저닝 용량을 조정합니다.

자동 확장은 지속적인 트래픽 변화에 반응하며 확장에 몇 분이 걸릴 수 있습니다. 갑작스러운 트래픽 급증에는 잘 대응하지 못하므로, 이러한 상황에는 용량을 수동으로 미리 준비하거나 온디맨드 모드를 대신 사용하십시오.

DynamoDB는 사용되지 않은 프로비저닝 용량을 최대 5분 동안 버스트 용량으로 보관합니다. 테이블의 트래픽이 잠시 프로비저닝 수준을 초과하면 DynamoDB는 버스트 풀에서 용량을 가져와 조절 없이 추가 요청을 처리합니다. 버스트 풀이 소진되면 이후의 초과 요청은 조절됩니다.

버스트 용량은 단기적인 완충 수단일 뿐, 올바른 용량 계획을 대신할 수는 없습니다. ConsumedReadCapacityUnits 및 ConsumedWriteCapacityUnits CloudWatch 지표를 모니터링하여 워크로드가 버스트 용량을 지속적으로 소비하는 시점을 감지하고 그에 맞게 프로비저닝 처리량을 조정하십시오.

프로비저닝 용량을 초과하고 버스트 용량까지 소진되면 DynamoDB는 ProvisionedThroughputExceededException을 반환합니다. AWS SDK에는 지수 백오프와 지터를 사용하는 재시도 로직이 기본으로 포함되어 있어 조절된 요청을 자동으로 다시 시도합니다.

조절을 진단하려면 SystemErrors 및 ThrottledRequests CloudWatch 지표를 확인하십시오. 전체 테이블 사용률은 낮은데 특정 파티션 키에서 조절이 발생한다면 핫 파티션 문제입니다. 이 경우 파티션 키를 다시 설계하거나 정렬 키를 추가하거나 쓰기 샤딩을 사용하십시오.

프로비저닝 모드의 용량을 추정하려면 다음을 수행하십시오.

• 초당 최대 쓰기 수 × 평균 항목 크기 / 1KB(올림) = 필요한 WCU
• 초당 최대 읽기 수 × 평균 항목 크기 / 4KB(올림) = 필요한 RCU(강한 일관성 기준); 최종 일관성 읽기라면 절반으로 계산
• 버스트 용량이 소진되기 전에 급증을 흡수할 수 있도록 최대 사용량보다 20~30%의 여유 용량을 추가

예: 2KB 항목을 초당 1,000개 쓰면 WCU 2,000개가 필요합니다. 8KB 항목을 최종 일관성으로 초당 5,000번 읽으면 ceil(8/4) × 5,000 / 2 = RCU 5,000개가 필요합니다.

DynamoDB 예약 용량을 사용하면 1년 또는 3년 동안 사용할 고정 수의 RCU와 WCU를 구매할 수 있으며, 온디맨드 요금보다 최대 76% 할인된 금액을 선불로 지불합니다. 예약 용량은 한 리전의 모든 프로비저닝 테이블에 적용되며 시간당 요금에 자동으로 반영됩니다.

예약 용량은 프로비저닝 모드에만 적용되며 온디맨드 모드에서는 사용할 수 없습니다. 1~3년 동안의 사용량을 확실하게 예측할 수 있는 안정적이고 예측 가능한 워크로드에 가장 적합한 비용 절감 방법입니다.

다음 의사 결정 가이드를 SAA-C03 용량 모드 문제에 활용하십시오.

• 온디맨드: 예측할 수 없는 트래픽, 새 애플리케이션, 드문 액세스, 급증하는 워크로드, 용량 관리를 전혀 하지 않으려는 경우
• 프로비저닝: 일관되고 예측 가능한 트래픽, 비용에 민감한 경우, 용량을 관리할 의향이 있는 경우, 예약 용량 할인 대상인 경우
• 프로비저닝 + 자동 확장: 예측 가능한 기본 트래픽에 어느 정도 변동성이 있고, 수동 변경 없이 자동 조정을 원하는 경우

시험에서는 '급증하는', '예측할 수 없는', '최소한의 운영 오버헤드'와 같은 키워드가 온디맨드를 나타내며, '안정적인 트래픽'이나 '비용 최적화'는 프로비저닝을 나타냅니다.

DynamoDB의 적응형 용량은 유휴 파티션에서 핫 파티션으로 처리량을 실시간으로 자동 재분배합니다. 한 파티션 키가 할당된 몫보다 많은 트래픽을 받으면 적응형 용량이 사용률이 낮은 파티션에서 처리량을 빌려 핫 파티션을 지원합니다. 단, 전체 테이블 용량을 초과하지 않아야 합니다.

적응형 용량은 항상 활성화되어 있으며 별도의 구성이 필요하지 않습니다. 액세스 패턴이 어느 정도 불균등한 경우 핫 파티션 조절을 줄여 줍니다. 하지만 워크로드가 심하게 편중된 경우(예: 한 파티션 키가 전체 트래픽의 90%를 받는 경우)에는 적응형 용량만으로 충분하지 않으므로 파티션 키를 다시 설계하거나 쓰기 샤딩을 사용해야 합니다.

이 단원에서 다룬 AWS 솔루션 아키텍트(SAA-C03) 개념에 대한 이해도를 확인해 보십시오.

이 단원에서는 예측 가능한 워크로드에 대해 프로비저닝 모드가 고정된 RCU/WCU를 설정하여 더 낮은 비용을 제공한다는 것, 온디맨드 모드가 예측할 수 없는 트래픽에 맞춰 자동으로 확장되지만 요청당 비용이 더 높다는 것, 그리고 자동 확장이 목표 사용률에 따라 프로비저닝 용량을 조정한다는 것을 배웠습니다. 다음 단원에서는 다른 쿼리 패턴을 위한 Global Secondary Index와 Local Secondary Index를 살펴봅니다.