3- 계정 한도 초과 - Amazon DynamoDB
계정 한도 초과 완화 조치공통 진단 및 모니터링해결 절차

3- 계정 한도 초과

온디맨드 테이블은 프로비저닝된 용량 수준을 관리하지 않지만, DynamoDB는 계정 수준의 처리량 한도를 적용하여 실행이 과도하게 증가하는 것을 방지하고 모든 사용자에게 공정한 리소스 사용을 보장합니다. 이러한 테이블당 계정 한도는 각 계정과 리전 조합별로 설정되는 조정 가능한 안전 장치 역할을 합니다. 읽기 또는 쓰기 소비율이 이러한 한도를 초과하면 DynamoDB는 스로틀링 예외에서 AccountLimitExceeded 스로틀링 사유 유형을 반환합니다. 테이블에 사용자 지정 최대 처리량 설정이 구성되지 않은 경우 기본 테이블당 계정 한도가 자동으로 적용됩니다. 보다 정밀한 비용 관리 및 예측 가능성을 위해 최대 처리량 설정을 선택적으로 구성하거나, 애플리케이션 요구 사항이 기본 한도를 초과하는 경우 Amazon DynamoDB의 할당량 콘솔을 통해 할당량 증액을 요청할 수 있습니다.

계정 한도 초과 완화 조치

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

특정 스로틀링 시나리오를 살펴보기 전에 먼저 조치가 실제로 필요한지 판단합니다.

  • 성능 영향 평가: 스로틀링에도 불구하고 애플리케이션이 여전히 성능 요구 사항을 충족하는지 확인합니다. 특히 대량 작업이나 데이터 마이그레이션 시 많은 애플리케이션이 계정 한도 근처에서 성공적으로 작동합니다.

  • 스로틀링 패턴 검토: 스로틀링이 간헐적으로 발생하고 애플리케이션이 재시도를 효과적으로 처리한다면 현재 한도가 워크로드에 충분할 수 있습니다.

가끔 계정 한도에 도달하더라도 애플리케이션 성능이 허용 가능한 수준이라면 즉각적인 변경을 적용하기보다 상황을 모니터링하는 방식을 선택할 수 있습니다.

스로틀링으로 인해 허용할 수 없는 성능 문제나 안정성 문제가 발생한다고 판단되면 아래의 특정 스로틀링 사유를 선택하여 권장되는 완화 옵션을 확인하세요

TableReadAccountLimitExceeded

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

테이블의 읽기 소비량이 해당 리전의 계정 수준 테이블당 읽기 처리량 할당량을 초과했습니다. 공통 진단 및 모니터링에서 CloudWatch 지표로 스로틀링 이벤트를 분석할 수 있습니다.

해결 방법 접근 방식

다음 단계를 따라 이 스로틀링을 해결합니다.

  • 할당량 증가 요청:

    테이블당 읽기 처리량 한도(할당량 코드 L-CF0CBE56) 증가를 요청합니다. 요청을 제출하는 방법에 대한 자세한 단계는 테이블당 할당량 증가 요청을 참조하세요.

TableWriteAccountLimitExceeded

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

테이블의 쓰기 소비량이 해당 리전의 계정 수준 테이블별 쓰기 처리량 할당량을 초과했습니다. 공통 진단 및 모니터링에서 CloudWatch 지표로 스로틀링 이벤트를 분석할 수 있습니다.

해결 방법 접근 방식

다음 단계를 따라 이 스로틀링을 해결합니다.

  • 할당량 증가 요청: 테이블당 쓰기 처리량 한도(할당량 코드 L-AB614373) 증가를 요청합니다. 요청을 제출하는 방법에 대한 자세한 단계는 테이블당 할당량 증가 요청을 참조하세요.

IndexReadAccountLimitExceeded

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

글로벌 보조 인덱스(GSI)를 대상으로 하는 읽기 작업이 현재 AWS 리전에서 계정의 테이블당 읽기 할당량 허용량을 초과하는 처리량을 소비하고 있습니다. 계정 수준의 테이블당 읽기 처리량 할당량은 테이블과 해당 테이블의 모든 GSI를 합산하여 적용됩니다. 공통 진단 및 모니터링에서 CloudWatch 지표로 스로틀링 이벤트를 분석할 수 있습니다.

해결 방법 접근 방식

계정의 용량 분배에 따라 적절한 해결 방법을 선택합니다.

  • 할당량 증가 요청: 테이블당 읽기 처리량 한도(할당량 코드 L-CF0CBE56) 증가를 요청합니다. 요청을 제출하는 방법에 대한 자세한 단계는 테이블당 할당량 증가 요청을 참조하세요.

  • GSI 사용량 최적화: 불필요한 읽기 용량 소비를 줄이기 위해 GSI 설계 및 쿼리 패턴 검토합니다.

IndexWriteAccountLimitExceeded

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

기본 테이블에 대한 쓰기 작업은 GSI에 대한 해당 업데이트를 생성하며, 이들이 합쳐져 AWS 리전의 계정 수준 테이블당 쓰기 처리량 할당량을 초과합니다. GSI로 인덱싱된 속성을 포함하는 기본 테이블 항목에 대한 모든 쓰기는 해당 GSI에 대한 대응하는 쓰기 작업을 트리거합니다. 이렇게 결합된 쓰기 작업은 테이블당 쓰기 처리량 할당량에 포함됩니다. 공통 진단 및 모니터링에서 CloudWatch 지표의 모니터링을 통해 이러한 스로틀링 이벤트의 패턴과 시점을 분석하고 과도한 GSI 쓰기 활동을 유발하는 작업을 식별할 수 있습니다.

해결 방법 접근 방식

계정의 용량 분배에 따라 적절한 해결 방법을 선택합니다.

  • 할당량 증가 요청: 기본 테이블 작업으로 인한 높은 GSI 쓰기 트래픽을 수용하기 위해 테이블당 쓰기 처리량 한도(할당량 코드 L-AB614373) 증가를 요청합니다. 테이블당 쓰기 처리량 할당량은 해당 테이블 전체(모든 GSI 포함)에 적용됩니다. 요청을 제출하는 방법에 대한 자세한 단계는 테이블당 할당량 증가 요청을 참조하세요.

  • GSI 프로젝션 최적화: GSI 프로젝션 검토 및 설계를 통해 GSI로의 쓰기 볼륨을 줄입니다.

공통 진단 및 모니터링

계정 한도 초과로 인한 스로틀링 이벤트를 해결할 때, 여러 CloudWatch 지표들을 활용하면 테이블당 한도인지 계정 전체 한도인지 확인하고 용량 분배 패턴을 파악하는 데 도움이 됩니다.

필수 CloudWatch 지표

계정 한도 스로틀링을 진단하려면 다음 핵심 지표를 모니터링합니다.

해결 절차

테이블당 할당량 증가 요청

애플리케이션이 현재 테이블당 처리량 한도를 초과하여 운영해야 하는 경우 아래 절차에 따라 할당량 증가 요청을 제출해야 합니다. AWS 계정의 각 DynamoDB 테이블(관련된 모든 GSI 포함)은 특정 리전 내에서 이러한 처리량 할당량의 적용을 받습니다. 이러한 할당량은 개별 테이블과 해당 GSI가 함께 사용할 수 있는 최대 읽기 또는 쓰기 용량을 나타내며, 계정의 모든 테이블에 대해 통합 적용되는 것이 아니라 각 테이블에 독립적으로 적용됩니다.

선택적으로 테이블당 또는 GSI별로 최대 온디맨드 처리량 설정을 구성하여 하한을 설정할 수도 있습니다.

  1. 증가해야 할 특정 할당량을 식별합니다.

    • 테이블당 읽기 처리량 한도(할당량 코드 L-CF0CBE56): 테이블당 기본 40,000RCU

    • 테이블당 쓰기 처리량 한도(할당량 코드 L-AB614373): 테이블당 기본 40,000WCU

  2. 한도 증가를 요청하려면 AWS Service Quotas 콘솔을 사용합니다.

    • Service Quotas에서 DynamoDB 서비스로 이동

    • 할당량 코드를 사용하여 적절한 할당량 찾기

    • 예상 최대 사용량에 따라 증가 요청

  3. 다음을 포함하여 증가에 대한 근거를 제공합니다.

    • 현재 사용 패턴 및 최대 사용량 트래픽 요구 사항

    • 용량 증가에 대한 비즈니스 근거

    • 증가된 용량이 필요한 시기

참고

할당량 증가는 일반적으로 처리하는 데 24~48시간이 소요됩니다. 요청 시 이를 고려하여 계획하고, 승인 대기 중 임시 완화 전략을 고려합니다.

GSI 프로젝션 및 설계 최적화

글로벌 보조 인덱스(GSI) 프로젝션 및 설계를 최적화하여 용량 소비를 줄이고 성능을 향상하ㅂ니다.

선택적 프로젝션 전략

쿼리가 몇 가지 속성만 액세스해야 하는 경우, 해당 속성만 프로젝션하면 기본 테이블 항목이 변경될 때 GSI에 기록되는 데이터 양이 줄어듭니다. 프로젝션 유형에 대한 자세한 내용은 글로벌 보조 인덱스의 프로젝션을 참조하세요.

  1. 쿼리 패턴 분석: 애플리케이션의 쿼리 패턴을 검토하여 GSI를 통해 실제로 액세스되는 속성을 식별합니다.

  2. 선택적 프로젝션 사용: 쿼리에서 실제로 필요한 속성만 프로젝션하여 쓰기 볼륨을 줄입니다.

  3. KEYS_ONLY 고려: 쿼리에 키 속성만 필요한 경우 KEYS_ONLY 프로젝션을 사용하여 쓰기 볼륨을 최소화합니다.

  4. 읽기 및 쓰기 장단점 균형 조정: 더 적은 속성을 프로젝션하면 쓰기 용량 소모는 줄지만 기본 테이블 추가 읽기가 필요할 수 있습니다.

스파스 GSI 구현

스파스 GSI는 기본 테이블의 모든 항목이 아닌 인덱싱된 속성을 가진 항목만 포함합니다. 이는 특정 데이터 하위 집합을 자주 쿼리할 때 파티션 밀도를 줄이고 성능을 향상시킵니다.

  1. 특정 속성 값을 가진 항목만 포함하는 GSI를 설계합니다.

  2. 인덱싱해야 할 항목에만 GSI 파티션 키 속성을 설정하여 조건부 인덱싱을 구현합니다.

  3. 스파스 GSI에서 복합 키(예: status#timestamp)를 사용하여 인덱싱된 항목 하위 집합 내 트래픽을 추가로 분산합니다.

이러한 전략 구현에 대한 자세한 내용은 DynamoDB의 보조 인덱스 사용에 대한 모범 사례를 참조하세요.