# DynamoDB 스로틀링 해결 가이드
이 섹션에서는 DynamoDB가 반환할 수 있는 각 특정 스로틀링 사유에 대한 구체적인 해결 지침을 제공합니다. 각 항목에는 모범 사례를 기반으로 한 권장 해결 방안과 모니터링할 해당 CloudWatch 지표가 포함됩니다.
DynamoDB는 네 가지 주요 범주에 걸쳐 16가지의 서로 다른 스로틀링 사유를 구현합니다. 애플리케이션 예외의 스로틀링 사유를 활용하여 관련 지침으로 바로 이동하세요.
## 키 범위 처리량 초과(핫 파티션)
이러한 스로틀링 사유는 개별 파티션이 처리량 한도를 초과할 때 발생하며, 프로비저닝 모드와 온디맨드 모드 모두에 영향을 미칩니다.
+ [TableReadKeyRangeThroughputExceeded](throttling-key-range-limit-exceeded-mitigation.md#throttling-table-read-keyrange)
+ [TableWriteKeyRangeThroughputExceeded](throttling-key-range-limit-exceeded-mitigation.md#throttling-table-write-keyrange)
+ [IndexReadKeyRangeThroughputExceeded](throttling-key-range-limit-exceeded-mitigation.md#throttling-index-read-keyrange)
+ [IndexWriteKeyRangeThroughputExceeded](throttling-key-range-limit-exceeded-mitigation.md#throttling-index-write-keyrange)
## 프로비저닝된 처리량 초과
이러한 스로틀링 사유는 프로비저닝 모드에서 소비율이 프로비저닝된 용량 한도를 초과할 때 발생합니다.
+ [TableReadProvisionedThroughputExceeded](throttling-provisioned-capacity-exceeded-mitigation.md#throttling-table-read-provisioned)
+ [TableWriteProvisionedThroughputExceeded](throttling-provisioned-capacity-exceeded-mitigation.md#throttling-table-write-provisioned)
+ [IndexReadProvisionedThroughputExceeded](throttling-provisioned-capacity-exceeded-mitigation.md#throttling-index-read-provisioned)
+ [IndexWriteProvisionedThroughputExceeded](throttling-provisioned-capacity-exceeded-mitigation.md#throttling-index-write-provisioned)
## 계정 한도 초과
이러한 스로틀링 사유는 AWS 리전에서 소비 율이 계정 수준의 처리량 할당량을 초과할 때 발생합니다:
+ [TableReadAccountLimitExceeded](throttling-account-limit-exceeded-mitigation.md#throttling-table-read-account-limit)
+ [TableWriteAccountLimitExceeded](throttling-account-limit-exceeded-mitigation.md#throttling-table-write-account-limit)
+ [IndexReadAccountLimitExceeded](throttling-account-limit-exceeded-mitigation.md#throttling-index-read-account-limit)
+ [IndexWriteAccountLimitExceeded](throttling-account-limit-exceeded-mitigation.md#throttling-index-write-account-limit)
## 온디맨드 최대 처리량 초과
이러한 스로틀링 사유는 온디맨드 모드에서 소비율이 구성된 최대 처리량 한도를 초과할 때 발생합니다.
+ [TableReadMaxOnDemandThroughputExceeded](throttling-ondemand-capacity-exceeded-mitigation.md#throttling-diagnostic-table-read-max-ondemand)
+ [TableWriteMaxOnDemandThroughputExceeded](throttling-ondemand-capacity-exceeded-mitigation.md#throttling-diagnostic-table-write-max-ondemand)
+ [IndexReadMaxOnDemandThroughputExceeded](throttling-ondemand-capacity-exceeded-mitigation.md#throttling-diagnostic-index-read-max-ondemand)
+ [IndexWriteMaxOnDemandThroughputExceeded](throttling-ondemand-capacity-exceeded-mitigation.md#throttling-diagnostic-index-write-max-ondemand)
# 1- 키 범위 처리량 초과(핫 파티션)
Amazon DynamoDB는 테이블과 글로벌 보조 인덱스(GSI) 모두에 대해 파티션 수준에서 특정 처리량 제한을 적용합니다. 각 파티션은 초당 최대 읽기 용량 단위(RCU) 및 쓰기 용량 단위(WCU)를 가집니다. 파티션이 이러한 제한을 초과하는 집중된 트래픽을 수신하면 스로틀링이 발생하며, 다른 작업은 활용도가 낮은 상태로 남아 '핫 파티션'이 생성될 수 있습니다. DynamoDB의 파티션 수준 스로틀링은 읽기와 쓰기가 독립적으로 작동합니다. 즉, 파티션이 읽기를 스로틀하는 동안 쓰기는 정상적으로 계속될 수 있으며, 그 반대의 경우도 가능합니다. 이 스로틀링은 테이블이나 GSI에 충분한 전체 용량이 있는 경우에도 발생할 수 있습니다. 자세한 내용을 다음을 참조하세요.
+ 핫 파티션 방지를 위한 DynamoDB 파티션 제한 및 효과적인 파티션 키 설계에 대해서는 [DynamoDB에서 효과적으로 파티션 키를 설계해 사용하는 모범 사례입니다](bp-partition-key-design.md)를 참조하세요.
+ 일반적인 파티션 개념 및 데이터 분산에 대해서는 [DynamoDB의 파티션](HowItWorks.Partitions.md)을 참조하세요.
+ 파티션 키 및 처리량 관리에 대한 추가 지침과 실제 시나리오는 [추가 리소스](#key-range-additional-resources)를 참조하세요.
개별 파티션이 처리량 한도를 초과하면 DynamoDB는 스로틀링 예외에서 `KeyRangeThroughputExceeded` 스로틀링 원인 유형을 반환합니다. 이 정보는 특정 파티션에서 트래픽이 과도하게 발생하고 있는지와 어떤 작업 유형(읽기 또는 쓰기)이 문제를 일으키고 있는지 식별합니다.
## 키 범위 처리량 초과 완화 조치
이 섹션에서는 파티션 수준 스로틀링 시나리오에 대한 해결 방법 지침을 제공합니다. 이 가이드를 사용하기 전에 애플리케이션의 예외 처리에서 특정 스로틀링 사유를 확인하고 영향을 받은 리소스의 Amazon 리소스 이름(ARN)을 파악했는지 확인하세요. 스로틀링 사유 검색 및 스로틀된 리소스 식별에 대한 정보는 [DynamoDB 스로틀링 진단 프레임워크](throttling-diagnosing-workflow.md#throttling-diagnosing) 섹션을 참조하세요.
특정 스로틀링 시나리오를 살펴보기 전에 먼저 문제가 자동으로 해결되는지 확인합니다.
+ DynamoDB는 자동 분할 메커니즘을 통해 핫 파티션에 맞게 조정되는 경우가 많습니다. 짧은 시간 후 중단되는 스로틀링 이벤트가 관찰된다면, 테이블이 핫 파티션을 분할하여 이미 조정되었을 수 있습니다. 파티션이 분할되면 각 새 파티션이 키스페이스의 더 작은 영역을 처리하게 되어 부하를 더 균등하게 분산하는 데 도움이 됩니다. 대부분의 경우 DynamoDB가 자동으로 문제를 해결하므로 추가 조치가 필요하지 않습니다.
*split-for-heat 메커니즘*에 대한 자세한 내용은 [추가 리소스](#key-range-additional-resources) 섹션을 참조하세요.
스로틀링이 지속될 경우 아래의 해당 스로틀링 시나리오를 참조하여 대상 수정 옵션을 확인합니다.
+ [TableReadKeyRangeThroughputExceeded](#throttling-table-read-keyrange)
+ [TableWriteKeyRangeThroughputExceeded](#throttling-table-write-keyrange)
+ [IndexReadKeyRangeThroughputExceeded](#throttling-index-read-keyrange)
+ [IndexWriteKeyRangeThroughputExceeded](#throttling-index-write-keyrange)
### TableReadKeyRangeThroughputExceeded
**이 스로틀링이 발생하는 경우**
DynamoDB 테이블의 하나 이상의 파티션 소비율이 해당 파티션의 읽기 처리량 한도를 초과합니다. 이 스로틀링은 테이블의 총 프로비저닝된 용량과 무관하게 발생하며, 프로비저닝된 테이블과 온디맨드 테이블 모두에 영향을 미칩니다. [공통 진단 및 모니터링](#key-range-exceeded-diagnosis-monitoring)에서 CloudWatch 지표로 스로틀링 이벤트를 분석할 수 있습니다.
**문제 해결 옵션**
스로틀링 이벤트를 해결하려면 다음 단계를 고려하세요.
**프로비저닝된 모드 및 온디맨드 모드:**
+ **사전 워밍 용량:** 스로틀링이 지속될 경우 테이블이 [DynamoDB 웜 처리량 이해](warm-throughput.md) 용량 한도가 설정되어 있는지 확인합니다. 예상되는 트래픽 증가에 대비하여 사전에 워밍 처리량을 사용하거나 읽기 프로비저닝된 용량을 늘립니다. 워밍 처리량을 늘리면 스로틀링이 발생하기 전에 테이블이 갑작스러운 트래픽 급증을 처리하는 능력이 향상됩니다. 시간이 지남에 따라 실제 처리량이 지속적으로 예상 처리량 수준에 근접할 경우 DynamoDB는 관측된 사용 패턴을 기반으로 부하가 높은 파티션을 분할할 수 있습니다.
+ **핫 키 식별:** 테이블이 자동으로 해결하지 못했고 워밍 처리량이 높거나 처리량을 높여도 효과가 없다면, 특정 핫 키를 식별해야 합니다. [CloudWatch Contributor Insights를 사용한 핫 키 식별](#key-range-identify-hot-keys)을 사용하여 특정 파티션 키 값이 핫 키인지 확인합니다. 이는 완화 노력을 효과적으로 집중하기 위한 첫 단계입니다. 식별 작업은 항상 명확하지 않을 수 있습니다. 특히 롤링 핫 파티션(시간이 지남에 따라 서로 다른 파티션이 핫 상태가 되는 경우)이나 스캔과 같은 작업으로 인해 스로틀링이 트리거되는 경우 더욱 명확하지 않습니다. 이러한 복잡한 시나리오에서는 애플리케이션의 액세스 패턴을 분석하고 이를 스로틀링 이벤트 발생 시점과 연관 지어야 할 수 있습니다.
+ **사용 사례에 따라 최종적으로 일관된 읽기를 사용하는 것이 좋습니다.** 강력히 일관된 읽기에서 최종적으로 일관된 읽기로 전환하면 RCU 사용량을 절반으로 줄이고 효과적인 읽기 용량을 즉시 두 배로 늘릴 수 있습니다. 읽기 용량 소비를 줄이기 위한 최종적으로 일관된 읽기 구현 모범 사례는 [DynamoDB 읽기 일관성](HowItWorks.ReadConsistency.md) 섹션을 참조하세요.
+ **파티션 키 설계 개선:** 장기적인 해결책으로 [파티션 키 설계 개선](#key-range-improve-partition-key-design)을 고려하여 파티션 간 액세스를 더 균등하게 분산하는 것이 좋습니다. 이 접근 방식은 근본 원인을 해결하여 핫 파티션 문제에 대한 가장 포괄적인 해결 방법을 제공하는 경우가 많습니다. 그러나 상당한 마이그레이션 과제가 수반되므로 신중한 계획이 필요합니다.
### TableWriteKeyRangeThroughputExceeded
**이 스로틀링이 발생하는 경우**
DynamoDB 테이블의 하나 이상의 파티션 소비율이 해당 파티션의 쓰기 처리량 한도를 초과합니다. 이 스로틀링은 테이블의 총 프로비저닝된 용량과 무관하게 발생하며, 프로비저닝된 테이블과 온디맨드 테이블 모두에 영향을 미칩니다. [공통 진단 및 모니터링](#key-range-exceeded-diagnosis-monitoring)에서 CloudWatch 지표로 스로틀링 이벤트를 분석할 수 있습니다.
**문제 해결 옵션**
스로틀링 이벤트를 해결하려면 다음 단계를 고려하세요.
**프로비저닝된 모드 및 온디맨드 모드:**
+ **사전 워밍 용량:** 스로틀링이 지속될 경우 테이블이 [DynamoDB 웜 처리량 이해](warm-throughput.md) 용량 한도가 설정되어 있는지 확인합니다. 예상되는 트래픽 증가에 대비하여 사전에 워밍 처리량을 사용하거나 쓰기 프로비저닝된 용량을 늘립니다. 워밍 처리량을 늘리면 스로틀링이 발생하기 전에 테이블이 갑작스러운 트래픽 급증을 처리하는 능력이 향상됩니다. 시간이 지남에 따라 실제 처리량이 지속적으로 예상 처리량 수준에 근접할 경우 DynamoDB는 관측된 사용 패턴을 기반으로 부하가 높은 파티션을 분할할 수 있습니다.
+ **핫 키 식별:** 테이블이 자동으로 해결하지 못했고 워밍 처리량이 높거나 처리량을 높여도 효과가 없다면, 특정 핫 키를 식별해야 합니다. [CloudWatch Contributor Insights를 사용한 핫 키 식별](#key-range-identify-hot-keys)을 사용하여 특정 파티션 키 값이 핫 키인지 확인합니다. 이는 완화 노력을 효과적으로 집중하기 위한 첫 단계입니다. 다음과 같은 일반적인 패턴을 고려하세요.
+ 스로틀링 데이터에서 동일한 파티션 키가 자주 나타나는 경우, 이는 집중된 핫 키를 나타냅니다.
+ 반복되는 키는 보이지 않지만 순차적인 타임스탬프나 키스페이스 순서를 따르는 스캔 기반 작업과 같이 정렬된 방식으로 데이터를 작성하는 경우, 쓰기가 키스페이스를 통과함에 따라 시간이 지남에 따라 서로 다른 키가 핫해지는 롤링 핫 파티션이 있을 가능성이 높습니다.
`BatchWriteItem`과 같은 작업이나 여러 항목에 동시에 영향을 미치는 트랜잭션에서도 쓰기 스로틀링이 발생할 수 있습니다. `BatchWriteItem` 요청 내 개별 항목이 스로틀링될 경우, DynamoDB는 이러한 스로틀링 오류를 애플리케이션 코드에 전달하지 않습니다. 대신 DynamoDB는 응답에 처리되지 않은 항목에 대한 정보를 반환하며, 애플리케이션은 해당 특정 항목을 재시도하여 처리해야 합니다. 트랜잭션의 경우, 단일 항목이라도 스로틀링이 발생하면 전체 작업이 `TransactionCanceledException` 예외와 함께 실패합니다. 이러한 복잡한 시나리오에서는 애플리케이션의 쓰기 패턴과 데이터 수집 워크플로를 분석하고, 스로틀링 이벤트 발생 시점과 연관 지어 적절한 재시도 처리 전략을 구현해야 할 수 있습니다.
+ **파티션 키 설계 개선:** 장기적인 해결책으로 [파티션 키 설계 개선](#key-range-improve-partition-key-design)을 고려하여 파티션 간 액세스를 더 균등하게 분산하는 것이 좋습니다. 이 접근 방식은 근본 원인을 해결하여 핫 파티션 문제에 대한 가장 포괄적인 해결 방법을 제공하는 경우가 많습니다. 그러나 상당한 마이그레이션 과제가 수반되므로 신중한 계획이 필요합니다.
### IndexReadKeyRangeThroughputExceeded
**이 스로틀링이 발생하는 경우**
DynamoDB GSI의 하나 이상의 파티션 소비율이 해당 파티션의 읽기 처리량 한도를 초과합니다. 이 스로틀링은 GSI의 총 프로비저닝된 용량과 무관하게 발생하며, 프로비저닝된 테이블과 온디맨드 테이블 모두에 영향을 미칩니다. [공통 진단 및 모니터링](#key-range-exceeded-diagnosis-monitoring)에서 CloudWatch 지표로 스로틀링 이벤트를 분석할 수 있습니다.
**문제 해결 옵션**
스로틀링 이벤트를 해결하려면 다음 단계를 고려하세요.
+ **사전 워밍 용량:** 스로틀링이 지속될 경우 GSI가 [DynamoDB 웜 처리량 이해](warm-throughput.md) 용량 한도가 설정되어 있는지 확인합니다. 예상되는 트래픽 증가에 대비하여 사전에 워밍 처리량을 사용하거나 읽기 프로비저닝된 용량을 늘립니다. 워밍 처리량을 늘리면 스로틀링이 발생하기 전에 GSI가 갑작스러운 트래픽 급증을 처리하는 능력이 향상됩니다. 시간이 지남에 따라 실제 처리량이 지속적으로 예상 처리량 수준에 근접할 경우 DynamoDB는 관측된 사용 패턴을 기반으로 부하가 높은 파티션을 분할할 수 있습니다.
+ **핫 키 식별:** GSI가 자동으로 해결하지 못했고 워밍 처리량이 높거나 처리량을 높여도 효과가 없다면, 특정 핫 키를 식별해야 합니다. [CloudWatch Contributor Insights를 사용한 핫 키 식별](#key-range-identify-hot-keys)을 사용하여 특정 파티션 키 값이 핫 키인지 확인합니다. 이는 완화 노력을 효과적으로 집중하기 위한 첫 단계입니다. GSI의 경우 파티션 키 분포가 기본 테이블과 크게 다를 수 있어 다른 핫 키 패턴이 생성될 수 있습니다.
+ **GSI 파티션 키 재설계:** GSI 키 설계로 인해 소수의 파티션에 읽기가 집중되는 인위적인 핫스팟(예: 상태 플래그, 날짜 전용 키 또는 부울 속성)이 생성될 수 있는지 고려합니다. 낮은 카디널리티 속성과 높은 카디널리티 속성을 결합한 복합 키 사용을 고려합니다(예: 'ACTIVE' 대신 'ACTIVE\$1customer123'). 또는 GSI 분포에 영향을 미치는 기본 테이블 항목에 DynamoDB 테이블에서 작업 부하를 균등하게 분산시키기 위한 [쓰기 샤딩을 사용해 DynamoDB 테이블에 워크로드를 고르게 배포](bp-partition-key-sharding.md) 기법을 적용하여 쓰기를 여러 파티션에 분산합니다. 샤딩된 데이터 쿼리 시 결과 집계를 위한 추가 애플리케이션 로직이 필요하지만, 이 접근 방식은 액세스 패턴을 더 균등하게 분산시켜 스로틀링을 방지합니다.
### IndexWriteKeyRangeThroughputExceeded
**이 스로틀링이 발생하는 경우**
DynamoDB GSI의 하나 이상의 파티션 소비율이 해당 파티션의 쓰기 처리량 한도를 초과합니다. 이 스로틀링은 GSI의 총 프로비저닝된 용량과 무관하게 발생하며, 프로비저닝된 테이블과 온디맨드 테이블 모두에 영향을 미칩니다. [공통 진단 및 모니터링](#key-range-exceeded-diagnosis-monitoring)에서 CloudWatch 지표로 스로틀링 이벤트를 분석할 수 있습니다.
**문제 해결 옵션**
스로틀링 이벤트를 해결하려면 다음 단계를 고려하세요.
+ **GSI 파티션 키 재설계:** GSI 파티션 키 설계를 검토하여 쓰기 작업을 균등하게 분산시키기에 충분한 카디널리티(고유성)를 갖는지 확인합니다. GSI 쓰기 스로틀링의 일반적인 원인은 낮은 카디널리티 속성을 GSI 파티션 키로 사용하는 것입니다(예: 가능한 값이 몇 개 안 되는 상태 플래그). 기본 테이블의 파티션 키가 잘 분산되어 있더라도, GSI의 파티션 키가 소수의 값으로 쓰기를 집중시키면 핫 파티션 현상이 발생할 수 있습니다. 예를 들어, 항목의 80%가 status='ACTIVE'인 경우, 상태 기반 GSI에서 심각한 핫 파티션 현상이 발생합니다. 낮은 카디널리티 속성과 높은 카디널리티 속성을 결합한 복합 키 사용을 고려합니다(예: 'ACTIVE' 대신 'ACTIVE\$1customer123'). 또는 GSI 분포에 영향을 미치는 기본 테이블 항목에 DynamoDB 테이블에서 작업 부하를 균등하게 분산시키기 위한 [쓰기 샤딩을 사용해 DynamoDB 테이블에 워크로드를 고르게 배포](bp-partition-key-sharding.md) 기법을 적용하여 쓰기를 여러 파티션에 분산합니다. 샤딩된 데이터 쿼리 시 결과 집계를 위한 추가 애플리케이션 로직이 필요하지만, 이 접근 방식은 액세스 패턴을 더 균등하게 분산시켜 스로틀링을 방지합니다.
+ **사전 워밍 용량:** GSI가 [DynamoDB 웜 처리량 이해](warm-throughput.md) 용량 한도가 설정되어 있는지 확인합니다. 예상되는 트래픽 증가에 대비하여 사전에 워밍 처리량을 사용하거나 쓰기 프로비저닝된 용량을 늘립니다. 워밍 처리량을 늘리면 스로틀링이 발생하기 전에 GSI가 갑작스러운 트래픽 급증을 처리하는 능력이 향상됩니다. 시간이 지남에 따라 실제 처리량이 지속적으로 예상 처리량 수준에 근접할 경우 DynamoDB는 관측된 사용 패턴을 기반으로 부하가 높은 파티션을 분할할 수 있습니다.
+ **GSI 프로젝션 최적화:** [GSI 프로젝션 최적화](#key-range-optimize-gsi-projections) 기법을 적용하여 GSI에 대한 쓰기 볼륨을 줄입니다. 더 적은 속성을 프로젝션하면 각 GSI 업데이트가 소비하는 쓰기 용량을 크게 줄일 수 있습니다.
## 공통 진단 및 모니터링
파티션 수준 스로틀링 문제 해결 시, 여러 CloudWatch 지표들을 활용하면 핫 파티션을 식별하고 근본 원인을 확인할 수 있습니다.
**필수 CloudWatch 지표**
파티션 수준 스로틀링을 진단하기 위해 다음 핵심 지표를 모니터링합니다.
+ **파티션 수준 스로틀링 이벤트:** [https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#ReadKeyRangeThroughputThrottleEvents](https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#ReadKeyRangeThroughputThrottleEvents) 및 [https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#WriteKeyRangeThroughputThrottleEvents](https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#WriteKeyRangeThroughputThrottleEvents)는 개별 파티션이 처리량 한도를 초과할 때 추적합니다. [https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#ReadThrottleEvents](https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#ReadThrottleEvents) 및 [https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#WriteThrottleEvents](https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#WriteThrottleEvents)는 읽기 또는 쓰기 요청이 프로비저닝된 용량을 초과할 때 추적합니다.
+ **용량 소비량:** [https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ConsumedReadCapacityUnits](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ConsumedReadCapacityUnits) 및 [https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ConsumedWriteCapacityUnits](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ConsumedWriteCapacityUnits)는 전체 사용 패턴을 보여줍니다.
## 해결 절차
### CloudWatch Contributor Insights를 사용한 핫 키 식별
이 절차를 사용하여 제한을 유발하는 파티션 키를 식별합니다.
1. 테이블 또는 GSI에서 [CloudWatch Contributor Insights](contributorinsights_HowItWorks.md)를 활성화하여 가장 많이 스로틀된 키를 추적합니다. 실시간 스로틀링 알림을 위해 *스로틀된 키* 모드를 사용하여 CloudWatch Contributor Insights를 지속적으로 활성화하는 것이 좋습니다. 이 모드는 스로틀링이 발생할 때만 이벤트를 처리함으로써 스로틀된 요청에만 집중합니다. 이 대상 모니터링은 스로틀링 문제에 대한 지속적인 가시성을 유지하는 비용 효율적인 방법입니다.
1. 핫 파티션 문제를 일으키는 키를 식별합니다.
1. (전체 *액세스된 키 및 스로틀된 키* 모드가 활성화된 경우) 시간 경과에 따른 액세스 패턴을 분석하여 핫 키가 일관되게 발생하거나 특정 기간 동안 발생하는지 확인합니다.
### 파티션 키 설계 개선
테이블 스키마를 수정하여 트래픽을 파티션 간에 더 효과적으로 분산할 수 있을 때 이 접근 방식을 사용합니다. 가능하다면, 이는 핫 파티션 문제에 대한 가장 효과적인 장기적 해결책입니다. 파티션 키 설계는 초기 테이블 설계 단계에서 신중하게 고려하는 것이 가장 좋습니다.
파티션 키 재설계는 전체 애플리케이션 에코시스템에 영향을 미치는 데이터 모델의 근본적인 변화를 나타냅니다. 이 접근 방식을 진행하기 전에 다음과 같은 중요한 제한 사항을 신중하게 고려하세요.
+ **데이터 마이그레이션 복잡성:** 파티션 키를 재설계하려면 기존 데이터를 모두 마이그레이션해야 하며, 이는 대규모 테이블의 경우 리소스 집약적이고 시간이 많이 소요될 수 있습니다.
+ **애플리케이션 코드 변경:** 테이블을 읽거나 쓰는 모든 애플리케이션 코드는 새로운 키 구조를 사용하도록 업데이트되어야 합니다.
+ **프로덕션 영향:** 새로운 키 설계로 마이그레이션하려면 전환 기간 동안 가동 중지 시간이나 복잡한 이중 기록 전략이 종종 필요합니다.
파티션 키 설계에 대한 포괄적인 지침 및 원칙은 [DynamoDB에서 효과적으로 파티션 키를 설계해 사용하는 모범 사례입니다.](bp-partition-key-design.md) 및 [DynamoDB에 워크로드가 배포되도록 파티션 키 설계](bp-partition-key-uniform-load.md) 섹션을 참조하세요
### GSI 프로젝션 최적화
애플리케이션의 쿼리 패턴을 검토하여 GSI를 쿼리할 때 정확히 어떤 속성이 필요할지 판단하고, 프로젝션을 해당 속성들로만 제한합니다. GSI에 프로젝션되지 않은 속성을 업데이트할 경우 해당 GSI에 대한 쓰기 작업이 발생하지 않아 업데이트 중 쓰기 처리량 소비가 감소합니다. 이 대상 프로젝션 전략은 애플리케이션의 쿼리 요구 사항을 지원하면서도 성능과 비용을 모두 최적화합니다. 속성을 더 적게 프로젝션하면 쓰기 용량 소비량이 줄어들지만 추가 기본 테이블 읽기가 필요할 수 있습니다.
효율적인 프로젝션 전략에 대한 자세한 내용은 [DynamoDB의 보조 인덱스 사용에 대한 모범 사례](bp-indexes-general.md)를 참조하세요.
## 추가 리소스
다음 블로그 게시물에서는 본 가이드에서 다루는 개념에 대한 실습 예제와 실무적 세부 사항을 제공합니다.
+ DynamoDB 규모 조정 및 핫 파티션 관리에 대한 실습 가이드를 보려면 [Part 1: Scaling DynamoDB - How partitions, hot keys, and split for heat impact performance](https://aws.amazon.com/blogs/database/part-1-scaling-dynamodb-how-partitions-hot-keys-and-split-for-heat-impact-performance/)를 참조하세요.
+ DynamoDB의 열 분산 메커니즘 작동 방식, 이점 및 구현 세부 사항에 대한 자세한 정보 [Part 3: Summary and best practices](https://aws.amazon.com/blogs/database/part-3-scaling-dynamodb-how-partitions-hot-keys-and-split-for-heat-impact-performance/)를 참조하세요.
+ 자세한 쓰기 샤딩 전략은 [쓰기 샤딩을 사용해 DynamoDB 테이블에 워크로드를 고르게 배포](bp-partition-key-sharding.md) 섹션을 참조하세요.
# 2- 프로비저닝된 처리량 초과
프로비저닝된 용량 제한은 애플리케이션의 소비율이 테이블 또는 글로벌 보조 인덱스에 대해 구성된 읽기 또는 쓰기 용량 단위(RCU/WCU)를 초과할 때 발생합니다. DynamoDB는 일시적인 트래픽 급증을 처리하기 위해 버스트 용량을 제공하지만, 프로비저닝된 한도를 초과하는 지속적인 요청은 스로틀링을 유발합니다. 이 경우 DynamoDB는 스로틀링 예외에서 `ProvisionedThroughputExceeded` 스로틀링 사유 유형을 반환합니다. 이 사유는 문제가 읽기 작업인지 쓰기 작업인지, 기본 테이블에 영향을 미치는지, 글로벌 보조 인덱스에 영향을 미치는지를 식별합니다.
스로틀링은 Auto Scaling이 활성화되었는지 여부와 관계없이 발생할 수 있습니다. Auto Scaling은 소비량 증가에 따라 조정되지만 즉시 반응하지 않으며, 사용자가 구성한 최대 용량 한도에 의해 제약을 받습니다. 갑작스러운 트래픽 급증 시 또는 소비량이 최대 Auto Scaling 한도를 초과할 때에도 스로틀링이 여전히 발생할 수 있음을 의미합니다.
## 프로비저닝된 처리량 초과 완화 조치
이 섹션에서는 프로비저닝된 용량 스로틀링 시나리오에 대한 해결 방법 지침을 제공합니다. 이 가이드를 사용하기 전에 애플리케이션의 예외 처리에서 특정 스로틀링 사유를 확인하고 영향을 받은 리소스의 Amazon 리소스 이름(ARN)을 파악했는지 확인합니다. 스로틀링 사유 검색 및 스로틀된 리소스 식별에 대한 정보는 [DynamoDB 스로틀링 진단 프레임워크](throttling-diagnosing-workflow.md#throttling-diagnosing) 섹션을 참조하세요.
특정 스로틀링 시나리오를 살펴보기 전에, 해당 스로틀링이 실제로 해결이 필요한 문제인지 먼저 고려합니다.
+ 적절하게 최적화된 DynamoDB 애플리케이션에서는 가끔 발생하는 스로틀링이 정상적이고 예상되는 현상입니다. 스로틀링은 단순히 프로비저닝한 용량을 100% 소비하고 있음을 의미합니다. 애플리케이션이 재시도를 통해 스로틀링을 원활하게 처리하고 전체 성능이 요구 사항을 충족한다면, 스로틀링에 대해 즉시 조치를 취하지 않아도 될 수 있습니다.
+ 그러나 스로틀링으로 인해 허용할 수 없는 클라이언트 측 지연이 발생하거나 사용자 경험이 저하되거나 중요한 작업이 제때 완료되지 않는다면 아래 완화 옵션을 진행합니다.
스로틀링 문제를 해결해야 할 경우, 먼저 스로틀링의 원인이 다음 중 어느 것인지 확인합니다.
+ **일시적인 트래픽 급증:** 프로비저닝된 용량을 초과하지만 지속되지 않는 트래픽의 단기적 증가입니다. 여기에는 지속적이고 높은 트래픽과는 다른 전략이 필요합니다.
+ **지속적이고 높은 트래픽:** 프로비저닝된 용량을 일관되게 초과하는 지속적인 워크로드입니다.
트래픽 급증의 경우, [추가 리소스](#throttling-additional-resources)의 *Handle traffic spikes with Amazon DynamoDB provisioned capacity* 블로그에 제시된 전략을 고려하세요.
지속적이고 높은 트래픽 발생 시 아래에 있는 용량 조정 옵션을 고려합니다.
+ [TableReadProvisionedThroughputExceeded](#throttling-table-read-provisioned)
+ [TableWriteProvisionedThroughputExceeded](#throttling-table-write-provisioned)
+ [IndexReadProvisionedThroughputExceeded](#throttling-index-read-provisioned)
+ [IndexWriteProvisionedThroughputExceeded](#throttling-index-write-provisioned)
### TableReadProvisionedThroughputExceeded
**이 스로틀링이 발생하는 경우**
애플리케이션의 읽기 소비율이 테이블에 구성된 [프로비저닝된 읽기 용량 단위](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_ProvisionedThroughput.html#DDB-Type-ProvisionedThroughput-ReadCapacityUnits)(RCU)를 초과했습니다. [공통 진단 및 모니터링](#provisioned-capacity-exceeded-diagnosis-monitoring)에서 CloudWatch 지표로 스로틀링 이벤트를 분석할 수 있습니다.
**해결 방법 접근 방식**
읽기 용량 스로틀링을 해결하려면 다음 전략을 고려합니다.
+ **온디맨드 용량 모드로 전환:** 트래픽 급증으로 인한 스로틀링이 자주 발생한다면 [테이블을 온디맨드 모드로 전환](#procedure-switch-ondemand)하는 것도 좋습니다. 온디맨드 모드는 프로비저닝 문제를 제거하고 워크로드에 따라 자동으로 확장됩니다.
+ **프로비저닝된 모드를 유지하고 Auto Scaling이 활성화되지 않은 경우:**
+ [테이블 읽기 용량을 증가](#provisioned-capacity-exceeded-increase-table-throughput)시키는 것도 좋습니다.
+ 테이블의 [읽기 용량에 대해 Auto Scaling을 활성화](#provisioned-capacity-configure-autoscaling)합니다.
+ **Auto Scaling이 활성화된 경우(콘솔에서 생성된 테이블의 기본값):**
+ [테이블의 읽기 Auto Scaling 파라미터를 최적화](#provisioned-capacity-optimize-autoscaling-settings)합니다.
### TableWriteProvisionedThroughputExceeded
**이 스로틀링이 발생하는 경우**
애플리케이션의 쓰기 소비율이 테이블에 구성된 [프로비저닝된 쓰기 용량 단위](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_ProvisionedThroughput.html#DDB-Type-ProvisionedThroughput-WriteCapacityUnits)(WCU)를 초과했습니다. [공통 진단 및 모니터링](#provisioned-capacity-exceeded-diagnosis-monitoring)에서 CloudWatch 지표로 스로틀링 이벤트를 분석할 수 있습니다.
**해결 방법 접근 방식**
쓰기 용량 스로틀링을 해결하려면 다음 전략을 고려합니다.
+ **온디맨드 용량 모드로 전환:** 트래픽 급증으로 인한 스로틀링이 자주 발생한다면 [테이블을 온디맨드 모드로 전환](#procedure-switch-ondemand)하는 것도 좋습니다. 온디맨드 모드는 프로비저닝 문제를 제거하고 워크로드에 따라 자동으로 확장됩니다.
+ **프로비저닝된 모드를 유지하고 Auto Scaling이 활성화되지 않은 경우:**
+ [테이블 쓰기 용량을 증가](#provisioned-capacity-exceeded-increase-table-throughput)시키는 것도 좋습니다.
+ 테이블의 [쓰기 용량에 대해 Auto Scaling을 활성화](#provisioned-capacity-configure-autoscaling)합니다.
+ **Auto Scaling이 활성화된 경우(콘솔에서 생성된 테이블의 기본값):**
+ [테이블의 쓰기 Auto Scaling 파라미터를 최적화](#provisioned-capacity-optimize-autoscaling-settings)합니다.
### IndexReadProvisionedThroughputExceeded
**이 스로틀링이 발생하는 경우**
글로벌 보조 인덱스(GSI)의 읽기 소비량이 GSI의 [프로비저닝된 읽기 용량 단위](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_ProvisionedThroughput.html#DDB-Type-ProvisionedThroughput-ReadCapacityUnits)(RCU)를 초과합니다. [공통 진단 및 모니터링](#provisioned-capacity-exceeded-diagnosis-monitoring)에서 CloudWatch 지표로 스로틀링 이벤트를 분석할 수 있습니다.
**해결 방법 접근 방식**
GSI 읽기 용량 스로틀링을 해결하려면 다음 전략을 고려합니다.
+ **온디맨드 용량 모드로 전환:** 트래픽 급증으로 인한 스로틀링이 자주 발생한다면 [기본 테이블을 온디맨드 모드로 전환](#procedure-switch-ondemand)하는 것도 좋습니다. 온디맨드 모드는 프로비저닝 문제를 제거하고 워크로드에 따라 자동으로 확장됩니다.
+ **프로비저닝된 모드를 유지하고 Auto Scaling이 활성화되지 않은 경우:**
+ [GSI 읽기 용량을 증가](#provisioned-capacity-exceeded-increase-index-throughput)시키는 것도 좋습니다.
+ GSI의 [읽기 용량에 대해 Auto Scaling을 활성화](#provisioned-capacity-configure-autoscaling)합니다.
+ **Auto Scaling이 활성화된 경우(콘솔에서 생성된 테이블의 기본값):**
+ [GSI의 읽기 Auto Scaling 파라미터를 최적화](#provisioned-capacity-optimize-autoscaling-settings)합니다.
### IndexWriteProvisionedThroughputExceeded
**이 스로틀링이 발생하는 경우**
기본 테이블의 항목 업데이트로 인해 GSI에 대한 쓰기 작업이 발생하며, 이는 [GSI의 프로비저닝된 쓰기 용량](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_ProvisionedThroughput.html#DDB-Type-ProvisionedThroughput-WriteCapacityUnits)을 초과합니다. 이는 기본 테이블 쓰기에 대한 [백 프레셔 스로틀링](gsi-throttling.md)을 유발합니다. [공통 진단 및 모니터링](#provisioned-capacity-exceeded-diagnosis-monitoring)에서 CloudWatch 지표로 스로틀링 이벤트를 분석할 수 있습니다.
**해결 방법 접근 방식**
GSI 쓰기 용량 스로틀링을 해결하려면 다음 전략을 고려합니다.
+ **온디맨드 용량 모드로 전환:** 트래픽 급증으로 인한 스로틀링이 자주 발생한다면 [기본 테이블을 온디맨드 모드로 전환](#procedure-switch-ondemand)하는 것도 좋습니다. 온디맨드 모드는 프로비저닝 문제를 제거하고 워크로드에 따라 자동으로 확장됩니다.
+ **프로비저닝된 모드를 유지하고 Auto Scaling이 활성화되지 않은 경우:**
+ [GSI 쓰기 용량을 증가](#provisioned-capacity-exceeded-increase-index-throughput)시키는 것도 좋습니다.
+ GSI의 [쓰기 용량에 대해 Auto Scaling을 활성화](#provisioned-capacity-configure-autoscaling)합니다.
+ **Auto Scaling이 활성화된 경우(콘솔에서 생성된 테이블의 기본값):**
+ [GSI의 쓰기 Auto Scaling 파라미터를 최적화](#provisioned-capacity-optimize-autoscaling-settings)합니다.
## 공통 진단 및 모니터링
처리량 오를 해결할 때 여러 CloudWatch 지표 활용하면 근본 원인을 파악하는 데 도움이 될 수 있습니다.
**필수 CloudWatch 지표**
프로비저닝된 용량 스로틀링을 진단하려면 다음 핵심 지표를 모니터링합니다.
+ **스로틀링 이벤트:** [https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#ReadProvisionedThroughputThrottleEvents](https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#ReadProvisionedThroughputThrottleEvents) 및 [https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#WriteProvisionedThroughputThrottleEvents](https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#WriteProvisionedThroughputThrottleEvents)는 이러한 사유로 요청이 스로틀링될 때를 추적합니다. [https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#ReadThrottleEvents](https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#ReadThrottleEvents) 및 [https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#WriteThrottleEvents](https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#WriteThrottleEvents)는 읽기 또는 쓰기 요청이 프로비저닝된 용량을 초과할 때를 추적합니다.
+ **용량 소비량:** [https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ConsumedReadCapacityUnits](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ConsumedReadCapacityUnits) 및 [https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ConsumedWriteCapacityUnits](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ConsumedWriteCapacityUnits)는 실제 사용량을 표시합니다.
+ **프로비저닝된 용량:** [https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ProvisionedReadCapacityUnits](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ProvisionedReadCapacityUnits) 및 [https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ProvisionedWriteCapacityUnits](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ProvisionedWriteCapacityUnits)는 구성된 한도를 표시합니다.
## 해결 절차
### 테이블 처리량 용량 증가
Auto Scaling이 활성화되지 않은 상태에서 즉시 용량 증가가 필요한 경우 이 절차를 사용합니다.
1. DynamoDB 콘솔, AWS CLI 또는 SDK를 사용하여 테이블의 프로비저닝된 용량을 업데이트합니다.
+ **읽기 용량:** DynamoDB가 요청을 스로틀링하기 전에 초당 소비되는 강력하게 일관된 읽기의 최대 수를 지정하는 [https://docs.aws.amazon.com//amazondynamodb/latest/APIReference/API_ProvisionedThroughput.html](https://docs.aws.amazon.com//amazondynamodb/latest/APIReference/API_ProvisionedThroughput.html) 파라미터를 늘립니다.
+ **쓰기 용량:** DynamoDB가 요청을 스로틀링하기 전에 초당 소비되는 쓰기의 최대 수를 지정하는 [https://docs.aws.amazon.com//amazondynamodb/latest/APIReference/API_ProvisionedThroughput.html](https://docs.aws.amazon.com//amazondynamodb/latest/APIReference/API_ProvisionedThroughput.html) 파라미터를 늘립니다.
1. 새 용량 설정이 [테이블당 처리량 할당량](ServiceQuotas.md)을 초과하지 않는지, 총 계정 사용량이 해당 리전의 [계정당 처리량 할당량](ServiceQuotas.md)을 초과하지 않는지 확인합니다. 이러한 한도에 근접하는 경우 대신 [온디맨드 용량 모드로 전환](#procedure-switch-ondemand)하는 것을 고려합니다.
### 테이블 또는 GSI의 읽기/쓰기 용량을 조정하도록 테이블 Auto Scaling 구성
트래픽 패턴에 따라 읽기 또는 쓰기 용량을 자동으로 조정하도록 DynamoDB [Auto Scaling](AutoScaling.md)을 구성합니다. 테이블과 GSI 모두에 대해 읽기 및 쓰기 용량 단위를 별도로 제어하며 Auto Scaling을 독립적으로 구성할 수 있습니다.
1. 테이블 또는 GSI에서 읽기 용량, 쓰기 용량 또는 둘 다에 대해 Auto Scaling을 활성화합니다.
1. 트래픽 급증을 위한 여유를 두고 목표 활용률 백분율을 설정합니다.
**참고**
목표 사용률을 낮추면 비용과 규모 조정 빈도가 증가합니다. 40% 미만의 목표는 오버프로비저닝을 유발할 수 있습니다. 사용 패턴과 비용을 모니터링하여 성능과 효율성의 균형을 맞춥니다.
1. 용량 경계를 다음과 같이 설정합니다.
+ **최소 RCU/WCU:** 트래픽이 적은 기간 동안 충분한 용량을 유지합니다.
+ **최대 RCU/WCU:** 최대 트래픽 수요를 수용하고 급격한 확장 사태로부터 보호합니다.
DynamoDB Auto Scaling 구성 및 관리에 대한 지침은 [DynamoDB Auto Scaling을 사용하여 자동으로 처리량 용량 관리](AutoScaling.md)를 참조하세요.
**참고**
Auto Scaling은 일반적으로 트래픽 변화에 대응하는 데 몇 분이 소요됩니다. 갑작스러운 트래픽 급증 시, Auto Scaling이 조정되는 동안 테이블의 버스트 용량이 즉각적인 보호 기능을 제공합니다. 규모 조정 작업에 필요한 시간을 확보하고 예상치 못한 수요에 대비해 버스트 용량을 유지하려면 충분한 여유를 두고 목표 사용률을 구성합니다.
### 테이블이나 인덱스의 읽기 또는 쓰기 Auto Scaling 설정 최적화
[Auto Scaling](AutoScaling.md)이 활성화되었음에도 스로틀링이 발생하는 경우 이 절차를 사용합니다. 테이블과 글로벌 보조 인덱스(GSI) 모두에 대해 읽기 및 쓰기 용량 단위를 별도로 제어하여 Auto Scaling을 독립적으로 조정할 수 있습니다.
+ **목표 사용률 조정:** 스로틀링이 발생하기 전에 규모 조정이 더 빨리 트리거되도록 테이블 또는 GSI의 목표 사용률을 낮추는 것을 고려하는 것이 좋습니다. 이러한 조정을 수행한 후 트래픽을 모니터링해야 합니다. 용량 소비 및 비용 영향에 대한 자세한 내용은 [테이블 또는 GSI의 읽기/쓰기 용량을 조정하도록 테이블 Auto Scaling 구성](#provisioned-capacity-configure-autoscaling) 섹션을 참조하세요.
+ **용량 경계 검토:** 최소 및 최대 용량 설정이 실제 워크로드 패턴과 일치하는지 확인합니다.
### 온디맨드 용량 모드로 전환
용량 모드 전환에 대한 일반적인 내용은 [DynamoDB에서 용량 모드 전환 시 고려 사항](bp-switching-capacity-modes.md) 섹션을 참조하세요. [모드 전환 시 특정 제약 조건](troubleshooting-throttling-diagnostics.md)에 대해서는 Service Quotas를 참조하세요.
### GSI 처리량 용량 증가
GSI에 Auto Scaling이 활성화되지 않은 상태에서 즉시 용량 증가가 필요한 경우 이 절차를 사용합니다.
1. DynamoDB 콘솔, AWS CLI 또는 SDK를 사용하여 GSI의 프로비저닝된 용량을 업데이트합니다.
+ **읽기 용량:** 특정 GSI의 [https://docs.aws.amazon.com//amazondynamodb/latest/APIReference/API_GlobalSecondaryIndexUpdate.html](https://docs.aws.amazon.com//amazondynamodb/latest/APIReference/API_GlobalSecondaryIndexUpdate.html) 파라미터를 늘립니다. 이 파라미터는 DynamoDB가 요청을 스로틀링하기 전에 GSI가 초당 소비할 수 있는 최대 읽기 횟수를 지정합니다. GSI는 최종 일관성 읽기만 지원합니다.
+ **쓰기 용량:** 특정 GSI의 [https://docs.aws.amazon.com//amazondynamodb/latest/APIReference/API_GlobalSecondaryIndexUpdate.html](https://docs.aws.amazon.com//amazondynamodb/latest/APIReference/API_GlobalSecondaryIndexUpdate.html) 파라미터를 늘립니다. 이 파라미터는 DynamoDB가 요청을 스로틀링하기 전에 GSI가 초당 소비할 수 있는 최대 쓰기 횟수를 지정합니다.
1. GSI의 프로비저닝된 처리량 용량이 [계정당 및 테이블당 처리량 할당량](ServiceQuotas.md) 범위 내에 유지되도록 합니다.
## 추가 리소스
+ DynamoDB 프로비저닝 용량 테이블에서 트래픽 급증을 처리하는 방법에 대한 자세한 정보(Auto Scaling 및 버스트 용량 활용부터 전략적 스로틀링 관리에 이르는 다양한 전략 포함)는 [Handle traffic spikes with Amazon DynamoDB provisioned capacity](https://aws.amazon.com/blogs//database/handle-traffic-spikes-with-amazon-dynamodb-provisioned-capacity/)를 참조하세요.
+ 규모 조정 정책을 예약하기 위해 cron 표현식을 사용하는 방법에 대한 정보는 [Optimize costs by scheduling provisioned capacity for DynamoDB](https://aws.amazon.com/blogs/database/optimize-costs-by-scheduling-provisioned-capacity-for-amazon-dynamodb/)를 참조하세요.
+ 프로비저닝된 용량 모드에서 DynamoDB 테이블의 처리량 사용 패턴을 모니터링하고 분석하는 실습 정보는 [How to evaluate throughput utilization for Amazon DynamoDB tables in provisioned mode](https://aws.amazon.com/blogs/database/how-to-evaluate-throughput-utilization-for-amazon-dynamodb-tables-in-provisioned-mode/)을 참조하세요.
# 3- 계정 한도 초과
온디맨드 테이블은 프로비저닝된 용량 수준을 관리하지 않지만, DynamoDB는 계정 수준의 처리량 한도를 적용하여 실행이 과도하게 증가하는 것을 방지하고 모든 사용자에게 공정한 리소스 사용을 보장합니다. 이러한 테이블당 계정 한도는 각 계정과 리전 조합별로 설정되는 조정 가능한 안전 장치 역할을 합니다. 읽기 또는 쓰기 소비율이 이러한 한도를 초과하면 DynamoDB는 스로틀링 예외에서 `AccountLimitExceeded` 스로틀링 사유 유형을 반환합니다. 테이블에 사용자 지정 최대 처리량 설정이 구성되지 않은 경우 기본 테이블당 계정 한도가 자동으로 적용됩니다. 보다 정밀한 비용 관리 및 예측 가능성을 위해 최대 처리량 설정을 선택적으로 구성하거나, 애플리케이션 요구 사항이 기본 한도를 초과하는 경우 [Amazon DynamoDB의 할당량](ServiceQuotas.md) 콘솔을 통해 할당량 증액을 요청할 수 있습니다.
## 계정 한도 초과 완화 조치
이 섹션에서는 계정 한도 스로틀링 시나리오에 대한 해결 방법 지침을 제공합니다. 이 가이드를 사용하기 전에 애플리케이션의 예외 처리에서 특정 스로틀링 사유를 확인하고 영향을 받은 리소스의 Amazon 리소스 이름(ARN)을 파악했는지 확인하세요. 스로틀링 사유 검색 및 스로틀된 리소스 식별에 대한 정보는 [DynamoDB 스로틀링 진단 프레임워크](throttling-diagnosing-workflow.md#throttling-diagnosing) 섹션을 참조하세요.
특정 스로틀링 시나리오를 살펴보기 전에 먼저 조치가 실제로 필요한지 판단합니다.
+ **성능 영향 평가:** 스로틀링에도 불구하고 애플리케이션이 여전히 성능 요구 사항을 충족하는지 확인합니다. 특히 대량 작업이나 데이터 마이그레이션 시 많은 애플리케이션이 계정 한도 근처에서 성공적으로 작동합니다.
+ **스로틀링 패턴 검토:** 스로틀링이 간헐적으로 발생하고 애플리케이션이 재시도를 효과적으로 처리한다면 현재 한도가 워크로드에 충분할 수 있습니다.
가끔 계정 한도에 도달하더라도 애플리케이션 성능이 허용 가능한 수준이라면 즉각적인 변경을 적용하기보다 상황을 모니터링하는 방식을 선택할 수 있습니다.
스로틀링으로 인해 허용할 수 없는 성능 문제나 안정성 문제가 발생한다고 판단되면 아래의 특정 스로틀링 사유를 선택하여 권장되는 완화 옵션을 확인하세요
+ [TableReadAccountLimitExceeded](#throttling-table-read-account-limit)
+ [TableWriteAccountLimitExceeded](#throttling-table-write-account-limit)
+ [IndexReadAccountLimitExceeded](#throttling-index-read-account-limit)
+ [IndexWriteAccountLimitExceeded](#throttling-index-write-account-limit)
### TableReadAccountLimitExceeded
**이 스로틀링이 발생하는 경우**
테이블의 읽기 소비량이 해당 리전의 계정 수준 테이블당 읽기 처리량 할당량을 초과했습니다. [공통 진단 및 모니터링](#account-limit-exceeded-diagnosis-monitoring)에서 CloudWatch 지표로 스로틀링 이벤트를 분석할 수 있습니다.
**해결 방법 접근 방식**
다음 단계를 따라 이 스로틀링을 해결합니다.
+ **할당량 증가 요청:**
테이블당 읽기 처리량 한도(할당량 코드 L-CF0CBE56) 증가를 요청합니다. 요청을 제출하는 방법에 대한 자세한 단계는 [테이블당 할당량 증가 요청](#account-limit-request-per-table-quota)을 참조하세요.
### TableWriteAccountLimitExceeded
**이 스로틀링이 발생하는 경우**
테이블의 쓰기 소비량이 해당 리전의 계정 수준 테이블별 쓰기 처리량 할당량을 초과했습니다. [공통 진단 및 모니터링](#account-limit-exceeded-diagnosis-monitoring)에서 CloudWatch 지표로 스로틀링 이벤트를 분석할 수 있습니다.
**해결 방법 접근 방식**
다음 단계를 따라 이 스로틀링을 해결합니다.
+ **할당량 증가 요청:** 테이블당 쓰기 처리량 한도(할당량 코드 L-AB614373) 증가를 요청합니다. 요청을 제출하는 방법에 대한 자세한 단계는 [테이블당 할당량 증가 요청](#account-limit-request-per-table-quota)을 참조하세요.
### IndexReadAccountLimitExceeded
**이 스로틀링이 발생하는 경우**
글로벌 보조 인덱스(GSI)를 대상으로 하는 읽기 작업이 현재 AWS 리전에서 계정의 테이블당 읽기 할당량 허용량을 초과하는 처리량을 소비하고 있습니다. 계정 수준의 테이블당 읽기 처리량 할당량은 테이블과 해당 테이블의 모든 GSI를 합산하여 적용됩니다. [공통 진단 및 모니터링](#account-limit-exceeded-diagnosis-monitoring)에서 CloudWatch 지표로 스로틀링 이벤트를 분석할 수 있습니다.
**해결 방법 접근 방식**
계정의 용량 분배에 따라 적절한 해결 방법을 선택합니다.
+ **할당량 증가 요청:** 테이블당 읽기 처리량 한도(할당량 코드 L-CF0CBE56) 증가를 요청합니다. 요청을 제출하는 방법에 대한 자세한 단계는 [테이블당 할당량 증가 요청](#account-limit-request-per-table-quota)을 참조하세요.
+ **GSI 사용량 최적화:** 불필요한 읽기 용량 소비를 줄이기 위해 [GSI 설계 및 쿼리 패턴 검토](#account-limit-optimize-gsi-projections)합니다.
### IndexWriteAccountLimitExceeded
**이 스로틀링이 발생하는 경우**
기본 테이블에 대한 쓰기 작업은 GSI에 대한 해당 업데이트를 생성하며, 이들이 합쳐져 AWS 리전의 계정 수준 테이블당 쓰기 처리량 할당량을 초과합니다. GSI로 인덱싱된 속성을 포함하는 기본 테이블 항목에 대한 모든 쓰기는 해당 GSI에 대한 대응하는 쓰기 작업을 트리거합니다. 이렇게 결합된 쓰기 작업은 테이블당 쓰기 처리량 할당량에 포함됩니다. [공통 진단 및 모니터링](#account-limit-exceeded-diagnosis-monitoring)에서 CloudWatch 지표의 모니터링을 통해 이러한 스로틀링 이벤트의 패턴과 시점을 분석하고 과도한 GSI 쓰기 활동을 유발하는 작업을 식별할 수 있습니다.
**해결 방법 접근 방식**
계정의 용량 분배에 따라 적절한 해결 방법을 선택합니다.
+ **할당량 증가 요청:** 기본 테이블 작업으로 인한 높은 GSI 쓰기 트래픽을 수용하기 위해 [테이블당 쓰기 처리량 한도](#account-limit-request-per-table-quota)(할당량 코드 L-AB614373) 증가를 요청합니다. 테이블당 쓰기 처리량 할당량은 해당 테이블 전체(모든 GSI 포함)에 적용됩니다. 요청을 제출하는 방법에 대한 자세한 단계는 [테이블당 할당량 증가 요청](#account-limit-request-per-table-quota)을 참조하세요.
+ **GSI 프로젝션 최적화:** [GSI 프로젝션 검토 및 설계](#account-limit-optimize-gsi-projections)를 통해 GSI로의 쓰기 볼륨을 줄입니다.
## 공통 진단 및 모니터링
계정 한도 초과로 인한 스로틀링 이벤트를 해결할 때, 여러 CloudWatch 지표들을 활용하면 테이블당 한도인지 계정 전체 한도인지 확인하고 용량 분배 패턴을 파악하는 데 도움이 됩니다.
**필수 CloudWatch 지표**
계정 한도 스로틀링을 진단하려면 다음 핵심 지표를 모니터링합니다.
+ **계정 한도 스로틀링 이벤트:** [https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#ReadAccountLimitThrottleEvents](https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#ReadAccountLimitThrottleEvents) 및 [https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#WriteAccountLimitThrottleEvents](https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#WriteAccountLimitThrottleEvents)는 계정 수준 한도로 인해 요청이 스로틀링되는 시점을 추적합니다. [https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#ReadThrottleEvents](https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#ReadThrottleEvents) 및 [https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#WriteThrottleEvents](https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#WriteThrottleEvents)는 모든 읽기 또는 쓰기 요청이 프로비저닝된 용량을 초과할 때를 추적합니다.
+ **리소스별 용량 소비량:** [https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ConsumedReadCapacityUnits](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ConsumedReadCapacityUnits) 및 [https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ConsumedWriteCapacityUnits](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ConsumedWriteCapacityUnits)는 각 테이블 및 GSI의 개별 리소스 사용량을 표시합니다.
+ **계정 전체 소비량:** CloudWatch 지표 수학 표현식을 사용하여 모든 테이블 및 GSI의 사용된 용량을 합산하여 총 계정 사용량을 모니터링합니다.
## 해결 절차
### 테이블당 할당량 증가 요청
애플리케이션이 현재 테이블당 처리량 한도를 초과하여 운영해야 하는 경우 아래 절차에 따라 할당량 증가 요청을 제출해야 합니다. AWS 계정의 각 DynamoDB 테이블(관련된 모든 GSI 포함)은 특정 리전 내에서 이러한 처리량 할당량의 적용을 받습니다. 이러한 할당량은 개별 테이블과 해당 GSI가 함께 사용할 수 있는 최대 읽기 또는 쓰기 용량을 나타내며, 계정의 모든 테이블에 대해 통합 적용되는 것이 아니라 각 테이블에 독립적으로 적용됩니다.
선택적으로 테이블당 또는 GSI별로 최대 온디맨드 처리량 설정을 구성하여 하한을 설정할 수도 있습니다.
1. 증가해야 할 특정 할당량을 식별합니다.
+ **테이블당 읽기 처리량 한도**(할당량 코드 L-CF0CBE56): 테이블당 기본 40,000RCU
+ **테이블당 쓰기 처리량 한도**(할당량 코드 L-AB614373): 테이블당 기본 40,000WCU
1. 한도 증가를 요청하려면 [AWS Service Quotas 콘솔](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)을 사용합니다.
+ Service Quotas에서 DynamoDB 서비스로 이동
+ 할당량 코드를 사용하여 적절한 할당량 찾기
+ 예상 최대 사용량에 따라 증가 요청
1. 다음을 포함하여 증가에 대한 근거를 제공합니다.
+ 현재 사용 패턴 및 최대 사용량 트래픽 요구 사항
+ 용량 증가에 대한 비즈니스 근거
+ 증가된 용량이 필요한 시기
**참고**
할당량 증가는 일반적으로 처리하는 데 24\$148시간이 소요됩니다. 요청 시 이를 고려하여 계획하고, 승인 대기 중 임시 완화 전략을 고려합니다.
### GSI 프로젝션 및 설계 최적화
글로벌 보조 인덱스(GSI) 프로젝션 및 설계를 최적화하여 용량 소비를 줄이고 성능을 향상하ㅂ니다.
**선택적 프로젝션 전략**
쿼리가 몇 가지 속성만 액세스해야 하는 경우, 해당 속성만 프로젝션하면 기본 테이블 항목이 변경될 때 GSI에 기록되는 데이터 양이 줄어듭니다. 프로젝션 유형에 대한 자세한 내용은 [글로벌 보조 인덱스의 프로젝션](https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/GSI.html#GSI.Projections)을 참조하세요.
1. 쿼리 패턴 분석: 애플리케이션의 쿼리 패턴을 검토하여 GSI를 통해 실제로 액세스되는 속성을 식별합니다.
1. 선택적 프로젝션 사용: 쿼리에서 실제로 필요한 속성만 프로젝션하여 쓰기 볼륨을 줄입니다.
1. `KEYS_ONLY` 고려: 쿼리에 키 속성만 필요한 경우 `KEYS_ONLY` 프로젝션을 사용하여 쓰기 볼륨을 최소화합니다.
1. 읽기 및 쓰기 장단점 균형 조정: 더 적은 속성을 프로젝션하면 쓰기 용량 소모는 줄지만 기본 테이블 추가 읽기가 필요할 수 있습니다.
**스파스 GSI 구현**
희소 GSI는 기본 테이블의 모든 항목이 아닌 인덱싱된 속성을 가진 항목만 포함합니다. 이는 특정 데이터 하위 집합을 자주 쿼리할 때 파티션 밀도를 줄이고 성능을 향상시킵니다.
1. 특정 속성 값을 가진 항목만 포함하는 GSI를 설계합니다.
1. 인덱싱해야 할 항목에만 GSI 파티션 키 속성을 설정하여 조건부 인덱싱을 구현합니다.
1. 스파스 GSI에서 복합 키(예: status\$1timestamp)를 사용하여 인덱싱된 항목 하위 집합 내 트래픽을 추가로 분산합니다.
이러한 전략 구현에 대한 자세한 내용은 [DynamoDB의 보조 인덱스 사용에 대한 모범 사례](https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/bp-indexes.html)를 참조하세요.
# 4- 온디맨드 최대 처리량 초과
[온디맨드](on-demand-capacity-mode.md) 테이블 또는 GSI를 구성할 때, 비용이 급증하는 것을 방지하거나 다운스트림 시스템이 과부하되는 것을 막기 위해 테이블 또는 인덱스 수준에서 최대 처리량 한도([https://docs.aws.amazon.com//amazondynamodb/latest/APIReference/API_OnDemandThroughput.html#DDB-Type-OnDemandThroughput-MaxReadRequestUnits](https://docs.aws.amazon.com//amazondynamodb/latest/APIReference/API_OnDemandThroughput.html#DDB-Type-OnDemandThroughput-MaxReadRequestUnits) 및 [https://docs.aws.amazon.com//amazondynamodb/latest/APIReference/API_OnDemandThroughput.html#DDB-Type-OnDemandThroughput-MaxWriteRequestUnits](https://docs.aws.amazon.com//amazondynamodb/latest/APIReference/API_OnDemandThroughput.html#DDB-Type-OnDemandThroughput-MaxWriteRequestUnits))를 선택적으로 설정할 수 있습니다. 최대 처리량에 대한 자세한 내용은 [온디맨드 테이블의 최대 처리량](on-demand-capacity-mode-max-throughput.md) 섹션을 참조하세요.
읽기 또는 쓰기 사용량이 이러한 자체 설정 한도를 초과하면 한도를 초과할 추가 요청에 대해 신속한 스로틀링 응답이 발생합니다. DynamoDB는 `MaxOnDemandThroughputExceeded` 스로틀링 원인 유형의 예외를 반환하여 어떤 리소스가 처리량 한도에 도달했는지 표시합니다.
## 온디맨드 최대 처리량 초과 스로틀링
이 섹션에서는 온디맨드 최대 처리량 초과 스로틀링 시나리오에 대한 해결 방법 지침을 제공합니다. 이 가이드를 사용하기 전에 애플리케이션의 예외 처리에서 특정 스로틀링 사유를 확인하고 영향을 받은 리소스의 Amazon 리소스 이름(ARN)을 파악했는지 확인하세요. 스로틀링 사유 검색 및 스로틀된 리소스 식별에 대한 정보는 [DynamoDB 스로틀링 진단 프레임워크](throttling-diagnosing-workflow.md#throttling-diagnosing) 섹션을 참조하세요.
특정 스로틀링 시나리오를 살펴보기 전에 먼저 조치가 실제로 필요한지 고려하세요.
+ **최대 처리량 설정 평가:** 이러한 한도는 의도적으로 비용을 제어하거나 다운스트림 시스템을 보호하도록 구성되었습니다. `MaxOnDemandThroughputExceeded` 스로틀링 이벤트를 수신하는 경우, 한도가 설계된 대로 작동되고 있는 것입니다. 이러한 한도를 늘리는 것이 원 비용 제어 또는 시스템 보호 목표와 부합하는지 고려하세요.
+ **애플리케이션 영향 평가:** 스로틀링이 실제로 애플리케이션이나 사용자에게 문제를 일으키는지 판단합니다. 애플리케이션이 재시도를 효과적으로 처리하고 가끔 발생하는 스로틀링에도 성능 요구 사항을 충족한다면 현재 제한을 유지하는 것이 적절한 선택일 수 있습니다.
+ **트래픽 패턴 검토:** 스로틀링이 예상된 트래픽 패턴인지, 아니면 비정상적인 급증인지 분석합니다. 예측 가능하고 반복적으로 한도를 초과하는 트래픽 패턴의 경우 최대 처리량 설정 조정이 필요할 수 있습니다. 일시적인 급증의 경우 한도 상향보다 더 나은 요청 분산 전략 구현이 더 적합할 수 있습니다.
검토 후 최대 처리량 설정 조정이 필요하다고 판단되면, 아래의 특정 스로틀링 시나리오를 참조하여 대상 수정 옵션을 확인하세요.
+ [TableReadMaxOnDemandThroughputExceeded](#throttling-diagnostic-table-read-max-ondemand)
+ [TableWriteMaxOnDemandThroughputExceeded](#throttling-diagnostic-table-write-max-ondemand)
+ [IndexReadMaxOnDemandThroughputExceeded](#throttling-diagnostic-index-read-max-ondemand)
+ [IndexWriteMaxOnDemandThroughputExceeded](#throttling-diagnostic-index-write-max-ondemand)
### TableReadMaxOnDemandThroughputExceeded
**이 스로틀링이 발생하는 경우**
온디맨드 테이블이 구성된 최대 읽기 처리량 용량을 초과했습니다. [공통 진단 및 모니터링](#ondemand-capacity-exceeded-diagnosis-monitoring)에서 CloudWatch 지표로 스로틀링 이벤트를 분석할 수 있습니다.
**문제 해결 옵션**
스로틀링 이벤트를 해결하려면 다음 단계를 고려하세요.
+ **최대 처리량 한도 증가:** [DynamoDB 콘솔](https://console.aws.amazon.com/dynamodb), [AWS CLI](/amazondynamodb/latest/developerguide/AccessingDynamoDB.html#Tools.CLI) 또는 DynamoDB `[UpdateTable](https://docs.aws.amazon.com//amazondynamodb/latest/APIReference/API_UpdateTable.html)` API를 사용하여 영향을 받는 테이블의 [https://docs.aws.amazon.com//amazondynamodb/latest/APIReference/API_OnDemandThroughput.html#DDB-Type-OnDemandThroughput-MaxReadRequestUnits](https://docs.aws.amazon.com//amazondynamodb/latest/APIReference/API_OnDemandThroughput.html#DDB-Type-OnDemandThroughput-MaxReadRequestUnits) 값을 증가시킨 후 모니터링하고 조정합니다. 렇게 하면 스로틀링이 발생하기 전에 테이블이 더 높은 읽기 처리량을 처리할 수 있습니다.
+ **최대 한도 제거:** `MaxReadRequestUnits`를 `-1`로 설정하여 상한선을 제거하면 계정 수준 처리량 할당량까지 수요에 따라 확장할 수 있습니다. 이렇게 하면 사용자 지정 한도는 제거되지만 AWS의 계정 수준 보호 장치는 유지됩니다. 그러나 이 한도를 제거한 후에는 테이블이 계정 수준 할당량에 도달하기 전에 훨씬 더 많은 용량을 소비할 수 있으므로 지출을 면밀히 모니터링하는 것이 중요합니다.
### TableWriteMaxOnDemandThroughputExceeded
**이 스로틀링이 발생하는 경우**
온디맨드 테이블이 구성된 최대 쓰기 처리량 용량을 초과했습니다. [공통 진단 및 모니터링](#ondemand-capacity-exceeded-diagnosis-monitoring)에서 CloudWatch 지표로 스로틀링 이벤트를 분석할 수 있습니다.
**문제 해결 옵션**
스로틀링 이벤트를 해결하려면 다음 단계를 고려하세요.
+ **최대 처리량 한도 증가:** [DynamoDB 콘솔](https://console.aws.amazon.com/dynamodb), [AWS CLI](/amazondynamodb/latest/developerguide/AccessingDynamoDB.html#Tools.CLI) 또는 DynamoDB `[UpdateTable](https://docs.aws.amazon.com//amazondynamodb/latest/APIReference/API_UpdateTable.html)` API를 사용하여 영향을 받는 테이블의 [https://docs.aws.amazon.com//amazondynamodb/latest/APIReference/API_OnDemandThroughput.html#DDB-Type-OnDemandThroughput-MaxWriteRequestUnits](https://docs.aws.amazon.com//amazondynamodb/latest/APIReference/API_OnDemandThroughput.html#DDB-Type-OnDemandThroughput-MaxWriteRequestUnits) 값을 증가시킨 후 모니터링하고 조정합니다.
+ **최대 한도 제거:** `MaxWriteRequestUnits`를 `-1`로 설정하여 상한선을 제거하면 계정 수준 처리량 할당량까지 수요에 따라 확장할 수 있습니다. 이렇게 하면 사용자 지정 한도는 제거되지만 AWS의 계정 수준 보호 장치는 유지됩니다. 그러나 이 한도를 제거한 후에는 테이블이 계정 수준 할당량에 도달하기 전에 훨씬 더 많은 용량을 소비할 수 있으므로 지출을 면밀히 모니터링하는 것이 중요합니다.
### IndexReadMaxOnDemandThroughputExceeded
**이 스로틀링이 발생하는 경우**
온디맨드 모드에서 GSI에 대한 읽기 요청이 GSI의 구성된 최대 읽기 처리량 용량을 초과했습니다. [공통 진단 및 모니터링](#ondemand-capacity-exceeded-diagnosis-monitoring)에서 CloudWatch 지표로 스로틀링 이벤트를 분석할 수 있습니다.
**문제 해결 옵션**
스로틀링 이벤트를 해결하려면 다음 단계를 고려하세요.
+ **GSI 최대 처리량 한도 증가:** [DynamoDB 콘솔](https://console.aws.amazon.com/dynamodb), [AWS CLI](/amazondynamodb/latest/developerguide/AccessingDynamoDB.html#Tools.CLI) 또는 DynamoDB `[UpdateTable](https://docs.aws.amazon.com//amazondynamodb/latest/APIReference/API_UpdateTable.html)` API를 사용하여 영향을 받는 GSI의 [https://docs.aws.amazon.com//amazondynamodb/latest/APIReference/API_OnDemandThroughput.html#DDB-Type-OnDemandThroughput-MaxReadRequestUnits](https://docs.aws.amazon.com//amazondynamodb/latest/APIReference/API_OnDemandThroughput.html#DDB-Type-OnDemandThroughput-MaxReadRequestUnits) 값을 증가시킨 후 모니터링하고 조정합니다.
+ **GSI 최대 한도 제거:** GSI의 `MaxReadRequestUnits`를 `-1`로 설정하여 상한선을 제거하면 계정 수준 처리량 할당량까지 수요에 따라 확장할 수 있습니다. 이렇게 하면 사용자 지정 한도는 제거되지만 AWS의 계정 수준 보호 장치는 유지됩니다. 그러나이 한도를 제거한 후에는 지출을 면밀히 모니터링하는 것이 중요합니다.
### IndexWriteMaxOnDemandThroughputExceeded
**이 스로틀링이 발생하는 경우**
기본 테이블의 항목 업데이트는 GSI의 구성된 최대 쓰기 처리량 용량을 초과하는 쓰기를 온디맨드 모드의 GSI로 트리거하여 [백 프레셔 스로틀링](gsi-throttling.md)을 유발합니다. [공통 진단 및 모니터링](#ondemand-capacity-exceeded-diagnosis-monitoring)에서 CloudWatch 지표로 스로틀링 이벤트를 분석할 수 있습니다.
**문제 해결 옵션**
스로틀링 이벤트를 해결하려면 다음 단계를 고려하세요.
+ **GSI 최대 처리량 한도 증가:** [DynamoDB 콘솔](https://console.aws.amazon.com/dynamodb), [AWS CLI](/amazondynamodb/latest/developerguide/AccessingDynamoDB.html#Tools.CLI) 또는 DynamoDB `[UpdateTable](https://docs.aws.amazon.com//amazondynamodb/latest/APIReference/API_UpdateTable.html)` API를 사용하여 영향을 받는 GSI의 [https://docs.aws.amazon.com//amazondynamodb/latest/APIReference/API_OnDemandThroughput.html#DDB-Type-OnDemandThroughput-MaxWriteRequestUnits](https://docs.aws.amazon.com//amazondynamodb/latest/APIReference/API_OnDemandThroughput.html#DDB-Type-OnDemandThroughput-MaxWriteRequestUnits) 값을 증가시킨 후 모니터링하고 조정합니다.
+ **GSI 최대 한도 제거:** GSI의 `MaxWriteRequestUnits`를 `-1`로 설정하여 상한선을 제거하면 계정 수준 처리량 할당량까지 수요에 따라 확장할 수 있습니다. 이렇게 하면 사용자 지정 한도는 제거되지만 AWS의 계정 수준 보호 장치는 유지됩니다. 그러나이 한도를 제거한 후에는 지출을 면밀히 모니터링하는 것이 중요합니다.
## 공통 진단 및 모니터링
온디맨드 최대 처리량 초과 스로틀링 이벤트를 해결할 때, 여러 CloudWatch 지표들을 통해 근본 원인과 확장 패턴을 파악할 수 있습니다.
**필수 CloudWatch 지표**
온디맨드 최대 처리량 초과로 인한 스로틀링을 진단하려면 다음 주요 지표들을 모니터링합니다.
+ **최대 처리량 스로틀링 이벤트:** [https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ReadMaxOnDemandThroughputThrottleEvents](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ReadMaxOnDemandThroughputThrottleEvents) 및 [https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#WriteMaxOnDemandThroughputThrottleEvents](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#WriteMaxOnDemandThroughputThrottleEvents)는 요청이 최대 한도를 초과하여 스로틀링되는 시점을 추적합니다. [https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#ReadThrottleEvents](https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#ReadThrottleEvents) 및 [https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#WriteThrottleEvents](https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#WriteThrottleEvents)는 읽기 또는 쓰기 요청이 프로비저닝된 용량을 초과하는 시점을 추적합니다.
+ **테이블 또는 글로벌 보조 인덱스에 대해 현재 구성된 최대 처리량:** [https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#OnDemandMaxReadRequestUnits](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#OnDemandMaxReadRequestUnits) 및 [https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#OnDemandMaxWriteRequestUnits](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#OnDemandMaxWriteRequestUnits)는 현재 최대 용량 한도를 표시합니다.
+ **실제 용량 사용량:** [https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ConsumedReadCapacityUnits](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ConsumedReadCapacityUnits) 및 [https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ConsumedWriteCapacityUnits](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ConsumedWriteCapacityUnits)는 실제 사용 패턴을 보여줍니다.
**분석 접근 방식**
온디맨드 최대 처리량 초과 진단을 확인하려면 다음 단계를 따르세요.
1. 소비된 용량을 최대 용량 한도와 비교 - 소비량이 지속적으로 최대 한도에 근접하거나 초과하는지 확인합니다.
1. 스로틀링 이벤트 빈도와 시점을 검토하여 패턴을 식별합니다. 스로틀링 이벤트와 동시에 발생한 소비 용량이 급증하는 부분을 찾습니다.
1. [CloudWatch Contributor Insights](contributorinsights_HowItWorks.md)를 사용하여 가장 많은 용량을 소비하는 항목 또는 파티션 키를 식별합니다.