1- 키 범위 처리량 초과(핫 파티션) - Amazon DynamoDB
키 범위 처리량 초과 완화 조치공통 진단 및 모니터링해결 절차추가 리소스

1- 키 범위 처리량 초과(핫 파티션)

Amazon DynamoDB는 테이블과 글로벌 보조 인덱스(GSI) 모두에 대해 파티션 수준에서 특정 처리량 제한을 적용합니다. 각 파티션은 초당 최대 읽기 용량 단위(RCU) 및 쓰기 용량 단위(WCU)를 가집니다. 파티션이 이러한 제한을 초과하는 집중된 트래픽을 수신하면 스로틀링이 발생하며, 다른 작업은 활용도가 낮은 상태로 남아 '핫 파티션'이 생성될 수 있습니다. DynamoDB의 파티션 수준 스로틀링은 읽기와 쓰기가 독립적으로 작동합니다. 즉, 파티션이 읽기를 스로틀하는 동안 쓰기는 정상적으로 계속될 수 있으며, 그 반대의 경우도 가능합니다. 이 스로틀링은 테이블이나 GSI에 충분한 전체 용량이 있는 경우에도 발생할 수 있습니다. 자세한 내용을 다음을 참조하세요.

개별 파티션이 처리량 한도를 초과하면 DynamoDB는 스로틀링 예외에서 KeyRangeThroughputExceeded 스로틀링 원인 유형을 반환합니다. 이 정보는 특정 파티션에서 트래픽이 과도하게 발생하고 있는지와 어떤 작업 유형(읽기 또는 쓰기)이 문제를 일으키고 있는지 식별합니다.

키 범위 처리량 초과 완화 조치

이 섹션에서는 파티션 수준 스로틀링 시나리오에 대한 해결 방법 지침을 제공합니다. 이 가이드를 사용하기 전에 애플리케이션의 예외 처리에서 특정 스로틀링 사유를 확인하고 영향을 받은 리소스의 Amazon 리소스 이름(ARN)을 파악했는지 확인하세요. 스로틀링 사유 검색 및 스로틀된 리소스 식별에 대한 정보는 DynamoDB 스로틀링 진단 프레임워크 섹션을 참조하세요.

특정 스로틀링 시나리오를 살펴보기 전에 먼저 문제가 자동으로 해결되는지 확인합니다.

  • DynamoDB는 자동 분할 메커니즘을 통해 핫 파티션에 맞게 조정되는 경우가 많습니다. 짧은 시간 후 중단되는 스로틀링 이벤트가 관찰된다면, 테이블이 핫 파티션을 분할하여 이미 조정되었을 수 있습니다. 파티션이 분할되면 각 새 파티션이 키스페이스의 더 작은 영역을 처리하게 되어 부하를 더 균등하게 분산하는 데 도움이 됩니다. 대부분의 경우 DynamoDB가 자동으로 문제를 해결하므로 추가 조치가 필요하지 않습니다.

    split-for-heat 메커니즘에 대한 자세한 내용은 추가 리소스 섹션을 참조하세요.

스로틀링이 지속될 경우 아래의 해당 스로틀링 시나리오를 참조하여 대상 수정 옵션을 확인합니다.

TableReadKeyRangeThroughputExceeded

이 스로틀링이 발생하는 경우

DynamoDB 테이블의 하나 이상의 파티션 소비율이 해당 파티션의 읽기 처리량 한도를 초과합니다. 이 스로틀링은 테이블의 총 프로비저닝된 용량과 무관하게 발생하며, 프로비저닝된 테이블과 온디맨드 테이블 모두에 영향을 미칩니다. 공통 진단 및 모니터링에서 CloudWatch 지표로 스로틀링 이벤트를 분석할 수 있습니다.

문제 해결 옵션

스로틀링 이벤트를 해결하려면 다음 단계를 고려하세요.

프로비저닝된 모드 및 온디맨드 모드:

  • 사전 워밍 용량: 스로틀링이 지속될 경우 테이블이 DynamoDB 웜 처리량 이해 용량 한도가 설정되어 있는지 확인합니다. 예상되는 트래픽 증가에 대비하여 사전에 워밍 처리량을 사용하거나 읽기 프로비저닝된 용량을 늘립니다. 워밍 처리량을 늘리면 스로틀링이 발생하기 전에 테이블이 갑작스러운 트래픽 급증을 처리하는 능력이 향상됩니다. 시간이 지남에 따라 실제 처리량이 지속적으로 예상 처리량 수준에 근접할 경우 DynamoDB는 관측된 사용 패턴을 기반으로 부하가 높은 파티션을 분할할 수 있습니다.

  • 핫 키 식별: 테이블이 자동으로 해결하지 못했고 워밍 처리량이 높거나 처리량을 높여도 효과가 없다면, 특정 핫 키를 식별해야 합니다. CloudWatch Contributor Insights를 사용한 핫 키 식별을 사용하여 특정 파티션 키 값이 핫 키지 확인합니다. 이는 완화 노력을 효과적으로 집중하기 위한 첫 단계입니다. 식별 작업은 항상 명확하지 않을 수 있습니다. 특히 롤링 핫 파티션(시간이 지남에 따라 서로 다른 파티션이 핫 상태가 되는 경우)이나 스캔과 같은 작업으로 인해 스로틀링이 트리거되는 경우 더욱 명확하지 않습니다. 이러한 복잡한 시나리오에서는 애플리케이션의 액세스 패턴을 분석하고 이를 스로틀링 이벤트 발생 시점과 연관 지어야 할 수 있습니다.

  • 사용 사례에 따라 최종적으로 일관된 읽기를 사용하는 것이 좋습니다. 강력히 일관된 읽기에서 최종적으로 일관된 읽기로 전환하면 RCU 사용량을 절반으로 줄이고 효과적인 읽기 용량을 즉시 두 배로 늘릴 수 있습니다. 읽기 용량 소비를 줄이기 위한 최종적으로 일관된 읽기 구현 모범 사례는 DynamoDB 읽기 일관성 섹션을 참조하세요.

  • 파티션 키 설계 개선: 장기적인 해결책으로 파티션 키 설계 개선을 고려하여 파티션 간 액세스를 더 균등하게 분산하는 것이 좋습니다. 이 접근 방식은 근본 원인을 해결하여 핫 파티션 문제에 대한 가장 포괄적인 해결 방법을 제공하는 경우가 많습니다. 그러나 상당한 마이그레이션 과제가 수반되므로 신중한 계획이 필요합니다.

TableWriteKeyRangeThroughputExceeded

이 스로틀링이 발생하는 경우

DynamoDB 테이블의 하나 이상의 파티션 소비율이 해당 파티션의 쓰기 처리량 한도를 초과합니다. 이 스로틀링은 테이블의 총 프로비저닝된 용량과 무관하게 발생하며, 프로비저닝된 테이블과 온디맨드 테이블 모두에 영향을 미칩니다. 공통 진단 및 모니터링에서 CloudWatch 지표로 스로틀링 이벤트를 분석할 수 있습니다.

문제 해결 옵션

스로틀링 이벤트를 해결하려면 다음 단계를 고려하세요.

프로비저닝된 모드 및 온디맨드 모드:

  • 사전 워밍 용량: 스로틀링이 지속될 경우 테이블이 DynamoDB 웜 처리량 이해 용량 한도가 설정되어 있는지 확인합니다. 예상되는 트래픽 증가에 대비하여 사전에 워밍 처리량을 사용하거나 쓰기 프로비저닝된 용량을 늘립니다. 워밍 처리량을 늘리면 스로틀링이 발생하기 전에 테이블이 갑작스러운 트래픽 급증을 처리하는 능력이 향상됩니다. 시간이 지남에 따라 실제 처리량이 지속적으로 예상 처리량 수준에 근접할 경우 DynamoDB는 관측된 사용 패턴을 기반으로 부하가 높은 파티션을 분할할 수 있습니다.

  • 핫 키 식별: 테이블이 자동으로 해결하지 못했고 워밍 처리량이 높거나 처리량을 높여도 효과가 없다면, 특정 핫 키를 식별해야 합니다. CloudWatch Contributor Insights를 사용한 핫 키 식별을 사용하여 특정 파티션 키 값이 핫 키지 확인합니다. 이는 완화 노력을 효과적으로 집중하기 위한 첫 단계입니다. 다음과 같은 일반적인 패턴을 고려하세요.

    • 스로틀링 데이터에서 동일한 파티션 키가 자주 나타나는 경우, 이는 집중된 핫 키를 나타냅니다.

    • 반복되는 키는 보이지 않지만 순차적인 타임스탬프나 키스페이스 순서를 따르는 스캔 기반 작업과 같이 정렬된 방식으로 데이터를 작성하는 경우, 쓰기가 키스페이스를 통과함에 따라 시간이 지남에 따라 서로 다른 키가 핫해지는 롤링 핫 파티션이 있을 가능성이 높습니다.

    BatchWriteItem과 같은 작업이나 여러 항목에 동시에 영향을 미치는 트랜잭션에서도 쓰기 스로틀링이 발생할 수 있습니다. BatchWriteItem 요청 내 개별 항목이 스로틀링될 경우, DynamoDB는 이러한 스로틀링 오류를 애플리케이션 코드에 전달하지 않습니다. 대신 DynamoDB는 응답에 처리되지 않은 항목에 대한 정보를 반환하며, 애플리케이션은 해당 특정 항목을 재시도하여 처리해야 합니다. 트랜잭션의 경우, 단일 항목이라도 스로틀링이 발생하면 전체 작업이 TransactionCanceledException 예외와 함께 실패합니다. 이러한 복잡한 시나리오에서는 애플리케이션의 쓰기 패턴과 데이터 수집 워크플로를 분석하고, 스로틀링 이벤트 발생 시점과 연관 지어 적절한 재시도 처리 전략을 구현해야 할 수 있습니다.

  • 파티션 키 설계 개선: 장기적인 해결책으로 파티션 키 설계 개선을 고려하여 파티션 간 액세스를 더 균등하게 분산하는 것이 좋습니다. 이 접근 방식은 근본 원인을 해결하여 핫 파티션 문제에 대한 가장 포괄적인 해결 방법을 제공하는 경우가 많습니다. 그러나 상당한 마이그레이션 과제가 수반되므로 신중한 계획이 필요합니다.

IndexReadKeyRangeThroughputExceeded

이 스로틀링이 발생하는 경우

DynamoDB GSI의 하나 이상의 파티션 소비율이 해당 파티션의 읽기 처리량 한도를 초과합니다. 이 스로틀링은 GSI의 총 프로비저닝된 용량과 무관하게 발생하며, 프로비저닝된 테이블과 온디맨드 테이블 모두에 영향을 미칩니다. 공통 진단 및 모니터링에서 CloudWatch 지표로 스로틀링 이벤트를 분석할 수 있습니다.

문제 해결 옵션

스로틀링 이벤트를 해결하려면 다음 단계를 고려하세요.

  • 사전 워밍 용량: 스로틀링이 지속될 경우 GSI가 DynamoDB 웜 처리량 이해 용량 한도가 설정되어 있는지 확인합니다. 예상되는 트래픽 증가에 대비하여 사전에 워밍 처리량을 사용하거나 읽기 프로비저닝된 용량을 늘립니다. 워밍 처리량을 늘리면 스로틀링이 발생하기 전에 GSI가 갑작스러운 트래픽 급증을 처리하는 능력이 향상됩니다. 시간이 지남에 따라 실제 처리량이 지속적으로 예상 처리량 수준에 근접할 경우 DynamoDB는 관측된 사용 패턴을 기반으로 부하가 높은 파티션을 분할할 수 있습니다.

  • 핫 키 식별: GSI가 자동으로 해결하지 못했고 워밍 처리량이 높거나 처리량을 높여도 효과가 없다면, 특정 핫 키를 식별해야 합니다. CloudWatch Contributor Insights를 사용한 핫 키 식별을 사용하여 특정 파티션 키 값이 핫 키지 확인합니다. 이는 완화 노력을 효과적으로 집중하기 위한 첫 단계입니다. GSI의 경우 파티션 키 분포가 기본 테이블과 크게 다를 수 있어 다른 핫 키 패턴이 생성될 수 있습니다.

  • GSI 파티션 키 재설계: GSI 키 설계로 인해 소수의 파티션에 읽기가 집중되는 인위적인 핫스팟(예: 상태 플래그, 날짜 전용 키 또는 부울 속성)이 생성될 수 있는지 고려합니다. 낮은 카디널리티 속성과 높은 카디널리티 속성을 결합한 복합 키 사용을 고려합니다(예: 'ACTIVE' 대신 'ACTIVE#customer123'). 또는 GSI 분포에 영향을 미치는 기본 테이블 항목에 DynamoDB 테이블에서 작업 부하를 균등하게 분산시키기 위한 쓰기 샤딩을 사용해 DynamoDB 테이블에 워크로드를 고르게 배포 기법을 적용하여 쓰기를 여러 파티션에 분산합니다. 샤딩된 데이터 쿼리 시 결과 집계를 위한 추가 애플리케이션 로직이 필요하지만, 이 접근 방식은 액세스 패턴을 더 균등하게 분산시켜 스로틀링을 방지합니다.

IndexWriteKeyRangeThroughputExceeded

이 스로틀링이 발생하는 경우

DynamoDB GSI의 하나 이상의 파티션 소비율이 해당 파티션의 쓰기 처리량 한도를 초과합니다. 이 스로틀링은 GSI의 총 프로비저닝된 용량과 무관하게 발생하며, 프로비저닝된 테이블과 온디맨드 테이블 모두에 영향을 미칩니다. 공통 진단 및 모니터링에서 CloudWatch 지표로 스로틀링 이벤트를 분석할 수 있습니다.

문제 해결 옵션

스로틀링 이벤트를 해결하려면 다음 단계를 고려하세요.

  • GSI 파티션 키 재설계: GSI 파티션 키 설계를 검토하여 쓰기 작업을 균등하게 분산시키기에 충분한 카디널리티(고유성)를 갖는지 확인합니다. GSI 쓰기 스로틀링의 일반적인 원인은 낮은 카디널리티 속성을 GSI 파티션 키로 사용하는 것입니다(예: 가능한 값이 몇 개 안 되는 상태 플래그). 기본 테이블의 파티션 키가 잘 분산되어 있더라도, GSI의 파티션 키가 소수의 값으로 쓰기를 집중시키면 핫 파티션 현상이 발생할 수 있습니다. 예를 들어, 항목의 80%가 status='ACTIVE'인 경우, 상태 기반 GSI에서 심각한 핫 파티션 현상이 발생합니다. 낮은 카디널리티 속성과 높은 카디널리티 속성을 결합한 복합 키 사용을 고려합니다(예: 'ACTIVE' 대신 'ACTIVE#customer123'). 또는 GSI 분포에 영향을 미치는 기본 테이블 항목에 DynamoDB 테이블에서 작업 부하를 균등하게 분산시키기 위한 쓰기 샤딩을 사용해 DynamoDB 테이블에 워크로드를 고르게 배포 기법을 적용하여 쓰기를 여러 파티션에 분산합니다. 샤딩된 데이터 쿼리 시 결과 집계를 위한 추가 애플리케이션 로직이 필요하지만, 이 접근 방식은 액세스 패턴을 더 균등하게 분산시켜 스로틀링을 방지합니다.

  • 사전 워밍 용량: GSI가 DynamoDB 웜 처리량 이해 용량 한도가 설정되어 있는지 확인합니다. 예상되는 트래픽 증가에 대비하여 사전에 워밍 처리량을 사용하거나 읽기 프로비저닝된 용량을 늘립니다. 워밍 처리량을 늘리면 스로틀링이 발생하기 전에 GSI가 갑작스러운 트래픽 급증을 처리하는 능력이 향상됩니다. 시간이 지남에 따라 실제 처리량이 지속적으로 예상 처리량 수준에 근접할 경우 DynamoDB는 관측된 사용 패턴을 기반으로 부하가 높은 파티션을 분할할 수 있습니다.

  • GSI 프로젝션 최적화: GSI 프로젝션 최적화 기법을 적용하여 GSI에 대한 쓰기 볼륨을 줄입니다. 더 적은 속성을 프로젝션하면 각 GSI 업데이트가 소비하는 쓰기 용량을 크게 줄일 수 있습니다.

공통 진단 및 모니터링

파티션 수준 스로틀링 문제 해결 시, 여러 CloudWatch 지표들을 활용하면 핫 파티션을 식별하고 근본 원인을 확인할 수 있습니다.

필수 CloudWatch 지표

파티션 수준 스로틀링을 진단하기 위해 다음 핵심 지표를 모니터링합니다.

해결 절차

CloudWatch Contributor Insights를 사용한 핫 키 식별

이 절차를 사용하여 제한을 유발하는 파티션 키를 식별합니다.

  1. 테이블 또는 GSI에서 CloudWatch Contributor Insights를 활성화하여 가장 많이 스로틀된 키를 추적합니다. 실시간 스로틀링 알림을 위해 스로틀된 키 모드를 사용하여 CloudWatch Contributor Insights를 지속적으로 활성화하는 것이 좋습니다. 이 모드는 스로틀링이 발생할 때만 이벤트를 처리함으로써 스로틀된 요청에만 집중합니다. 이 대상 모니터링은 스로틀링 문제에 대한 지속적인 가시성을 유지하는 비용 효율적인 방법입니다.

  2. 핫 파티션 문제를 일으키는 키를 식별합니다.

  3. (전체 액세스된 키 및 스로틀된 키 모드가 활성화된 경우) 시간 경과에 따른 액세스 패턴을 분석하여 핫 키가 일관되게 발생하거나 특정 기간 동안 발생하는지 확인합니다.

파티션 키 설계 개선

테이블 스키마를 수정하여 트래픽을 파티션 간에 더 효과적으로 분산할 수 있을 때 이 접근 방식을 사용합니다. 가능하다면, 이는 핫 파티션 문제에 대한 가장 효과적인 장기적 해결책입니다. 파티션 키 설계는 초기 테이블 설계 단계에서 신중하게 고려하는 것이 가장 좋습니다.

파티션 키 재설계는 전체 애플리케이션 에코시스템에 영향을 미치는 데이터 모델의 근본적인 변화를 나타냅니다. 이 접근 방식을 진행하기 전에 다음과 같은 중요한 제한 사항을 신중하게 고려하세요.

  • 데이터 마이그레이션 복잡성: 파티션 키를 재설계하려면 기존 데이터를 모두 마이그레이션해야 하며, 이는 대규모 테이블의 경우 리소스 집약적이고 시간이 많이 소요될 수 있습니다.

  • 애플리케이션 코드 변경: 테이블을 읽거나 쓰는 모든 애플리케이션 코드는 새로운 키 구조를 사용하도록 업데이트되어야 합니다.

  • 프로덕션 영향: 새로운 키 설계로 마이그레이션하려면 전환 기간 동안 가동 중지 시간이나 복잡한 이중 기록 전략이 종종 필요합니다.

파티션 키 설계에 대한 포괄적인 지침 및 원칙은 DynamoDB에서 효과적으로 파티션 키를 설계해 사용하는 모범 사례입니다. 및 DynamoDB에 워크로드가 배포되도록 파티션 키 설계 섹션을 참조하세요

GSI 프로젝션 최적화

애플리케이션의 쿼리 패턴을 검토하여 GSI를 쿼리할 때 정확히 어떤 속성이 필요할지 판단하고, 프로젝션을 해당 속성들로만 제한합니다. GSI에 프로젝션되지 않은 속성을 업데이트할 경우 해당 GSI에 대한 쓰기 작업이 발생하지 않아 업데이트 중 쓰기 처리량 소비가 감소합니다. 이 대상 프로젝션 전략은 애플리케이션의 쿼리 요구 사항을 지원하면서도 성능과 비용을 모두 최적화합니다. 속성을 더 적게 프로젝션하면 쓰기 용량 소비량이 줄어들지만 추가 기본 테이블 읽기가 필요할 수 있습니다.

효율적인 프로젝션 전략에 대한 자세한 내용은 DynamoDB의 보조 인덱스 사용에 대한 모범 사례를 참조하세요.

추가 리소스

다음 블로그 게시물에서는 본 가이드에서 다루는 개념에 대한 실습 예제와 실무적 세부 사항을 제공합니다.