쿠키 기본 설정 선택

당사는 사이트와 서비스를 제공하는 데 필요한 필수 쿠키 및 유사한 도구를 사용합니다. 고객이 사이트를 어떻게 사용하는지 파악하고 개선할 수 있도록 성능 쿠키를 사용해 익명의 통계를 수집합니다. 필수 쿠키는 비활성화할 수 없지만 '사용자 지정' 또는 ‘거부’를 클릭하여 성능 쿠키를 거부할 수 있습니다.

사용자가 동의하는 경우 AWS와 승인된 제3자도 쿠키를 사용하여 유용한 사이트 기능을 제공하고, 사용자의 기본 설정을 기억하고, 관련 광고를 비롯한 관련 콘텐츠를 표시합니다. 필수가 아닌 모든 쿠키를 수락하거나 거부하려면 ‘수락’ 또는 ‘거부’를 클릭하세요. 더 자세한 내용을 선택하려면 ‘사용자 정의’를 클릭하세요.

프로비저닝된 모드의 제한 문제 해결

포커스 모드
프로비저닝된 모드의 제한 문제 해결 - Amazon DynamoDB

테이블 또는 인덱스에 대해 프로비저닝된 처리량을 애플리케이션에서 초과할 경우 요청 조정이 적용됩니다. 조절 기능은 애플리케이션에서 용량 단위를 너무 많이 사용하지 않도록 방지합니다. DynamoDB는 읽기 또는 쓰기 작업을 제한할 때 호출자에게 ProvisionedThroughputExceededException을 반환합니다. 그러면 애플리케이션에서는 잠깐 동안 기다렸다가 요청을 재시도하는 등 적절한 조치를 취할 수 있게 됩니다.

제한과 관련된 것으로 보이는 문제를 해결하려면 먼저 제한이 DynamoDB과 애플리케이션 중 무엇에서 발생하는지 확인하는 것이 중요합니다.

이 주제에서는 프로비저닝된 용량 모드의 일반적인 제한 문제를 해결하는 방법을 설명합니다. 다음은 몇 가지 일반적인 시나리오와 이를 해결하는 데 도움이 될 수 있는 단계입니다.

DynamoDB 테이블에 프로비저닝된 용량이 충분한 것으로 보이지만 요청이 제한되고 있음

이는 처리량이 분당 평균보다 낮지만 초당 사용 가능한 양을 초과할 때 발생할 수 있습니다. DynamoDB는 분 단위 수준의 지표만 CloudWatch에 보고하며, 이 지표는 1분 동안의 합계로 계산되어 평균화됩니다. 하지만 DynamoDB 자체는 초당 속도 제한을 적용합니다. 따라서 이 1분 중 작은 부분(예: 몇 초 이하)에서 해당 처리량이 너무 많이 발생하는 경우 1분의 나머지 시간에 대한 요청이 제한될 수 있습니다.

예를 들어 테이블에 60WCU를 프로비저닝한 경우 1분 안에 3,600회의 쓰기 작업을 수행할 수 있습니다. 그러나 3,600개의 WCU 요청이 모두 같은 초에 발생하면 1분의 나머지 시간은 제한됩니다.

이 시나리오를 해결하는 한 가지 방법은 API 호출에 지터와 지수 백오프를 추가하는 것입니다. 자세한 내용은 백오프 및 지터에 대한 게시물을 참조하세요.

AutoScaling이 활성화되었지만 테이블에 여전히 제한이 발생함

이는 트래픽이 급증할 때 발생할 수 있습니다. 2개의 데이터 포인트가 1분 범위 이내에 구성된 목표 사용률 값을 위반하면 Auto Scaling이 트리거될 수 있습니다. 따라서 일관된 2분 동안 소비된 용량이 목표 사용률을 초과하므로 Auto Scaling이 발생할 수 있습니다. 하지만 급증 간격이 1분보다 크면 Auto Scaling이 트리거되지 않을 수 있습니다.

마찬가지로 15개의 연속 데이터 포인트가 목표 사용률보다 낮을 때 스케일 다운 이벤트가 트리거될 수 있습니다. 두 경우 모두 Auto Scaling이 트리거된 후 UpdateTable API 작업이 간접적으로 호출됩니다. 그런 다음 테이블 또는 인덱스의 프로비저닝된 용량을 업데이트하는 데 몇 분 정도 걸릴 수 있습니다. 이 기간 동안 테이블의 이전 프로비저닝된 용량을 초과하는 모든 요청은 제한됩니다.

요약하면 Auto Scaling이 DynamoDB 테이블을 스케일 업하기 위해서는 목표 사용률 값이 위반된 연속적인 데이터 포인트가 필요합니다. 이러한 이유로 Auto Scaling은 급증한 워크로드를 처리하기 위한 솔루션으로 권장되지 않습니다. 자세한 내용은 Auto Scaling 비용 최적화 설명서를 참조하세요.

핫키로 인해 제한 문제가 발생할 수 있음

DynamoDB에서 카디널리티가 높지 않은 파티션 키는 몇 개의 파티션만을 대상으로 하는 요청이 많을 수 있습니다. 이 결과 생성된 핫 파티션이 파티션 제한인 초당 3,000RCU 또는 1,000WCU를 초과하면 제한이 발생할 수 있습니다. 진단 도구인 CloudWatch Contributor Insights(CCI)는 각 테이블의 항목 액세스 패턴에 대한 CCI 그래프를 제공하여 이를 디버깅하는 데 도움이 될 수 있습니다. DynamoDB 테이블의 가장 자주 액세스하는 키와 기타 트래픽 추세를 지속적으로 모니터링할 수 있습니다. CloudWatch Contributor Insights에 대한 자세한 내용은 CloudWatch Contributor Insights for DynamoDB를 참조하세요. 자세한 내용은 DynamoDB에 워크로드가 배포되도록 파티션 키 설계올바른 DynamoDB 파티션 키 선택을 참조하세요.

테이블로 향하는 트래픽이 테이블 수준의 처리량 할당량을 초과하고 있음

테이블 수준 읽기 처리량 할당량 및 테이블 수준 쓰기 처리량 할당량은 어느 리전에서나 테이블 수준에서 적용됩니다. 이러한 할당량은 프로비저닝된 용량 모드 테이블 및 온디맨드 용량 모드 테이블에 모두 적용됩니다. 기본적으로 테이블에 할당되는 처리량 할당량은 4만 개의 읽기 요청 단위와 4만 개의 쓰기 요청 단위입니다. 테이블에 대한 트래픽이 이 할당량을 초과하면 테이블에 제한이 발생할 수 있습니다. 이를 방지하는 방법에 대한 자세한 내용은 운영 인식을 위한 DynamoDB 모니터링을 참조하세요.

이 문제를 해결하려면 Service Quotas 콘솔을 사용하여 계정의 테이블 수준 읽기 또는 쓰기 처리량 할당량을 늘리세요.

프라이버시사이트 이용 약관쿠키 기본 설정
© 2025, Amazon Web Services, Inc. 또는 계열사. All rights reserved.