2- 프로비저닝된 처리량 초과 - Amazon DynamoDB

2- 프로비저닝된 처리량 초과

프로비저닝된 용량 제한은 애플리케이션의 소비율이 테이블 또는 글로벌 보조 인덱스에 대해 구성된 읽기 또는 쓰기 용량 단위(RCU/WCU)를 초과할 때 발생합니다. DynamoDB는 일시적인 트래픽 급증을 처리하기 위해 버스트 용량을 제공하지만, 프로비저닝된 한도를 초과하는 지속적인 요청은 스로틀링을 유발합니다. 이 경우 DynamoDB는 스로틀링 예외에서 ProvisionedThroughputExceeded 스로틀링 사유 유형을 반환합니다. 이 사유는 문제가 읽기 작업인지 쓰기 작업인지, 기본 테이블에 영향을 미치는지, 글로벌 보조 인덱스에 영향을 미치는지를 식별합니다.

스로틀링은 Auto Scaling이 활성화되었는지 여부와 관계없이 발생할 수 있습니다. Auto Scaling은 소비량 증가에 따라 조정되지만 즉시 반응하지 않으며, 사용자가 구성한 최대 용량 한도에 의해 제약을 받습니다. 갑작스러운 트래픽 급증 시 또는 소비량이 최대 Auto Scaling 한도를 초과할 때에도 스로틀링이 여전히 발생할 수 있음을 의미합니다.

프로비저닝된 처리량 초과 완화 조치

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

특정 스로틀링 시나리오를 살펴보기 전에, 해당 스로틀링이 실제로 해결이 필요한 문제인지 먼저 고려합니다.

  • 적절하게 최적화된 DynamoDB 애플리케이션에서는 가끔 발생하는 스로틀링이 정상적이고 예상되는 현상입니다. 스로틀링은 단순히 프로비저닝한 용량을 100% 소비하고 있음을 의미합니다. 애플리케이션이 재시도를 통해 스로틀링을 원활하게 처리하고 전체 성능이 요구 사항을 충족한다면, 스로틀링에 대해 즉시 조치를 취하지 않아도 될 수 있습니다.

  • 그러나 스로틀링으로 인해 허용할 수 없는 클라이언트 측 지연이 발생하거나 사용자 경험이 저하되거나 중요한 작업이 제때 완료되지 않는다면 아래 완화 옵션을 진행합니다.

스로틀링 문제를 해결해야 할 경우, 먼저 스로틀링의 원인이 다음 중 어느 것인지 확인합니다.

  • 일시적인 트래픽 급증: 프로비저닝된 용량을 초과하지만 지속되지 않는 트래픽의 단기적 증가입니다. 여기에는 지속적이고 높은 트래픽과는 다른 전략이 필요합니다.

  • 지속적이고 높은 트래픽: 프로비저닝된 용량을 일관되게 초과하는 지속적인 워크로드입니다.

트래픽 급증의 경우, 추가 리소스Handle traffic spikes with Amazon DynamoDB provisioned capacity 블로그에 제시된 전략을 고려하세요.

지속적이고 높은 트래픽 발생 시 아래에 있는 용량 조정 옵션을 고려합니다.

TableReadProvisionedThroughputExceeded

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

애플리케이션의 읽기 소비율이 테이블에 구성된 프로비저닝된 읽기 용량 단위(RCU)를 초과했습니다. 공통 진단 및 모니터링에서 CloudWatch 지표로 스로틀링 이벤트를 분석할 수 있습니다.

해결 방법 접근 방식

읽기 용량 스로틀링을 해결하려면 다음 전략을 고려합니다.

TableWriteProvisionedThroughputExceeded

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

애플리케이션의 쓰기 소비율이 테이블에 구성된 프로비저닝된 쓰기 용량 단위(WCU)를 초과했습니다. 공통 진단 및 모니터링에서 CloudWatch 지표로 스로틀링 이벤트를 분석할 수 있습니다.

해결 방법 접근 방식

쓰기 용량 스로틀링을 해결하려면 다음 전략을 고려합니다.

IndexReadProvisionedThroughputExceeded

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

글로벌 보조 인덱스(GSI)의 읽기 소비량이 GSI의 프로비저닝된 읽기 용량 단위(RCU)를 초과합니다. 공통 진단 및 모니터링에서 CloudWatch 지표로 스로틀링 이벤트를 분석할 수 있습니다.

해결 방법 접근 방식

GSI 읽기 용량 스로틀링을 해결하려면 다음 전략을 고려합니다.

IndexWriteProvisionedThroughputExceeded

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

기본 테이블의 항목 업데이트로 인해 GSI에 대한 쓰기 작업이 발생하며, 이는 GSI의 프로비저닝된 쓰기 용량을 초과합니다. 이는 기본 테이블 쓰기에 대한 백 프레셔 스로틀링을 유발합니다. 공통 진단 및 모니터링에서 CloudWatch 지표로 스로틀링 이벤트를 분석할 수 있습니다.

해결 방법 접근 방식

GSI 쓰기 용량 스로틀링을 해결하려면 다음 전략을 고려합니다.

공통 진단 및 모니터링

처리량 오를 해결할 때 여러 CloudWatch 지표 활용하면 근본 원인을 파악하는 데 도움이 될 수 있습니다.

필수 CloudWatch 지표

프로비저닝된 용량 스로틀링을 진단하려면 다음 핵심 지표를 모니터링합니다.

해결 절차

테이블 처리량 용량 증가

Auto Scaling이 활성화되지 않은 상태에서 즉시 용량 증가가 필요한 경우 이 절차를 사용합니다.

  1. DynamoDB 콘솔, AWS CLI 또는 SDK를 사용하여 테이블의 프로비저닝된 용량을 업데이트합니다.

    • 읽기 용량: DynamoDB가 요청을 스로틀링하기 전에 초당 소비되는 강력 일관성 읽기의 최대 수를 지정하는 ReadCapacityUnits 파라미터를 늘립니다.

    • 쓰기 용량: DynamoDB가 요청을 스로틀링하기 전에 초당 소비되는 쓰기의 최대 수를 지정하는 WriteCapacityUnits 파라미터를 늘립니다.

  2. 새 용량 설정이 테이블당 처리량 할당량을 초과하지 않는지, 총 계정 사용량이 해당 리전의 계정당 처리량 할당량을 초과하지 않는지 확인합니다. 이러한 한도에 근접하는 경우 대신 온디맨드 용량 모드로 전환하는 것을 고려합니다.

테이블 또는 GSI의 읽기/쓰기 용량을 조정하도록 테이블 Auto Scaling 구성

트래픽 패턴에 따라 읽기 또는 쓰기 용량을 자동으로 조정하도록 DynamoDB Auto Scaling을 구성합니다. 테이블과 GSI 모두에 대해 읽기 및 쓰기 용량 단위를 별도로 제어하며 Auto Scaling을 독립적으로 구성할 수 있습니다.

  1. 테이블 또는 GSI에서 읽기 용량, 쓰기 용량 또는 둘 다에 대해 Auto Scaling을 활성화합니다.

  2. 트래픽 급증을 위한 여유를 두고 목표 활용률 백분율을 설정합니다.

    참고

    목표 사용률을 낮추면 비용과 규모 조정 빈도가 증가합니다. 40% 미만의 목표는 과도한 프로비저닝을 유발할 수 있습니다. 사용 패턴과 비용을 모니터링하여 성능과 효율성의 균형을 맞춥니다.

  3. 용량 경계를 다음과 같이 설정합니다.

    • 최소 RCU/WCU: 트래픽이 적은 기간 동안 충분한 용량을 유지합니다.

    • 최대 RCU/WCU: 최대 트래픽 수요를 수용하고 급격한 확장 사태로부터 보호합니다.

DynamoDB Auto Scaling 구성 및 관리에 대한 지침은 DynamoDB Auto Scaling을 사용하여 자동으로 처리량 용량 관리를 참조하세요.

참고

Auto Scaling은 일반적으로 트래픽 변화에 대응하는 데 몇 분이 소요됩니다. 갑작스러운 트래픽 급증 시, Auto Scaling이 조정되는 동안 테이블의 버스트 용량이 즉각적인 보호 기능을 제공합니다. 규모 조정 작업에 필요한 시간을 확보하고 예상치 못한 수요에 대비해 버스트 용량을 유지하려면 충분한 여유를 두고 목표 사용률을 구성합니다.

테이블이나 인덱스의 읽기 또는 쓰기 Auto Scaling 설정 최적화

Auto Scaling이 활성화되었음에도 스로틀링이 발생하는 경우 이 절차를 사용합니다. 테이블과 글로벌 보조 인덱스(GSI) 모두에 대해 읽기 및 쓰기 용량 단위를 별도로 제어하여 Auto Scaling을 독립적으로 조정할 수 있습니다.

  • 목표 사용률 조정: 스로틀링이 발생하기 전에 규모 조정이 더 빨리 트리거되도록 테이블 또는 GSI의 목표 사용률을 낮추는 것을 고려하는 것이 좋습니다. 이러한 조정을 수행한 후 트래픽을 모니터링해야 합니다. 용량 소비 및 비용 영향에 대한 자세한 내용은 테이블 또는 GSI의 읽기/쓰기 용량을 조정하도록 테이블 Auto Scaling 구성 섹션을 참조하세요.

  • 용량 경계 검토: 최소 및 최대 용량 설정이 실제 워크로드 패턴과 일치하는지 확인합니다.

온디맨드 용량 모드로 전환

용량 모드 전환에 대한 일반적인 내용은 DynamoDB에서 용량 모드 전환 시 고려 사항 섹션을 참조하세요. 모드 전환 시 특정 제약 조건에 대해서는 Service Quotas를 참조하세요.

GSI 처리량 용량 증가

GSI에 Auto Scaling이 활성화되지 않은 상태에서 즉시 용량 증가가 필요한 경우 이 절차를 사용합니다.

  1. DynamoDB 콘솔, AWS CLI 또는 SDK를 사용하여 GSI의 프로비저닝된 용량을 업데이트합니다.

    • 읽기 용량: 특정 GSI의 ReadCapacityUnits 파라미터를 늘립니다. 이 파라미터는 DynamoDB가 요청을 스로틀링하기 전에 GSI가 초당 소비할 수 있는 최대 읽기 횟수를 지정합니다. GSI는 최종 일관성 읽기만 지원합니다.

    • 쓰기 용량: 특정 GSI의 WriteCapacityUnits 파라미터를 늘립니다. 이 파라미터는 DynamoDB가 요청을 스로틀링하기 전에 GSI가 초당 소비할 수 있는 최대 쓰기 횟수를 지정합니다.

  2. GSI의 프로비저닝된 처리량 용량이 계정당 및 테이블당 처리량 할당량 범위 내에 유지되도록 합니다.

추가 리소스