Amazon DynamoDB 테이블이 제한되는 이유는 무엇입니까?

4분 분량
0

Amazon DynamoDB 테이블의 읽기 또는 쓰기 작업이 제한되고 있습니다. -또는- DynamoDB 테이블에서 읽기 또는 쓰기 작업을 수행할 때 ProvisionedThroughputExceededException가 발생합니다.

간략한 설명

다음과 같은 몇 가지 일반적인 제한 문제가 발생할 수 있습니다.

  • DynamoDB 테이블에는 적절한 프로비저닝 용량이 있지만 대부분의 요청에 제한이 발생합니다.
  • DynamoDB에 대해 AWS 애플리케이션 자동 확장을 활성화했지만 DynamoDB 테이블에 제한이 발생합니다.
  • DynamoDB 테이블이 온디맨드 용량 모드에 있지만 테이블에 제한이 발생합니다.
  • 테이블에 핫 파티션이 있습니다.
  • 테이블의 트래픽이 계정 처리량 할당량을 초과하고 있습니다.

해결 방법

제한 이벤트 중에 모니터링해야 하는 DynamoDB 지표에 대한 자세한 내용은 DynamoDB 지표 및 차원을 참조하세요. 이러한 지표를 사용하면 제한이 발생하는 요청을 만드는 작업을 찾고 제한의 원인을 파악하는 데 도움이 될 수 있습니다. 사용 사례에 따라 다음 문제 해결 옵션 중 하나 이상을 사용합니다.

DynamoDB 테이블에는 적절한 프로비저닝 용량이 있지만 대부분의 요청에 제한이 발생합니다.

DynamoDB는 분 단위 지표를 Amazon CloudWatch에 보고합니다. 지표는 1분 동안의 합계로 계산된 다음 평균을 구합니다. 하지만 DynamoDB 속도 제한은 초당 적용됩니다. 예를 들어 DynamoDB 테이블에 60개의 쓰기 용량 유닛을 프로비저닝한 경우 1분 내에 3,600개의 쓰기를 수행할 수 있습니다. 하지만 나머지 시간 동안 요청 없이 1초 내에 3,600개의 요청을 모두 구동하면 제한이 발생할 수 있습니다. 분당 읽기 용량 단위 또는 쓰기 용량 단위의 총 수는 테이블의 프로비저닝된 처리량보다 적을 수 있습니다. 그러나 모든 워크로드가 몇 초 내에 떨어지면 요청에 제한이 발생할 수 있습니다.

이 문제를 해결하려면 테이블에 트래픽을 처리할 수 있는 충분한 용량이 있는지 확인하고 지수 백오프를 사용하여 제한된 요청을 다시 시도하세요. AWS SDK를 사용하는 경우 이 로직이 기본값으로 구현됩니다. 자세한 내용은 오류 재시도 및 지수 백오프를 참조하세요.

참고: 초당 소비된 용량이 프로비저닝된 용량을 초과한 후에는 DynamoDB에서 테이블 제한을 시작하지 않아도 됩니다. 버스트 용량 기능을 통해 DynamoDB는 사용량 급증을 처리하기 위해 나중에 처리량을 버스트할 수 있도록 미사용 용량의 일부를 예약합니다.

AWS Application Auto Scaling을 활성화했지만 테이블에 여전히 제한이 발생합니다.

AWS Application Auto Scaling은 DynamoDB 테이블의 갑작스러운 트래픽 급증을 해결하는 데 적합한 솔루션이 아닙니다. Application Auto Scaling은 사용된 용량 단위에 대한 두 개의 연속된 데이터 요소가 1분 범위 내에 구성된 목표 사용률 값을 초과하는 경우에만 확장을 시작합니다. Application Auto Scaling은 사용된 용량이 일정한 2분 동안 목표 사용률보다 높은 경우에만 프로비저닝된 용량을 자동으로 조정합니다. 또한 CloudWatch에서 사용된 용량에 대한 15개의 연속 데이터 요소가 목표 사용률보다 낮을 때 축소 이벤트가 시작됩니다. Application Auto Scaling이 시작된 후 UpdateTable API 호출이 호출됩니다. 이 호출은 DynamoDB 테이블 또는 인덱스의 프로비저닝된 용량을 업데이트하는 데 몇 분 정도 걸릴 수 있습니다. Application Auto Scaling에서는 DynamoDB 테이블의 프로비저닝된 용량을 확장하기 위해 목표 사용률 값이 더 높은 연속적인 데이터 포인트가 필요합니다. 이 기간 동안 테이블의 프로비저닝된 용량을 초과하는 모든 요청에 제한이 발생합니다. 따라서 Application Auto Scaling을 사용하여 DynamoDB에서 급증하는 워크로드를 처리하는 것은 모범 사례가 아니며, 이 사용 사례에서는 온디맨드 모드로 전환하는 것을 고려할 수 있습니다. 자세한 내용은 DynamoDB Auto Scaling을 통한 처리량 자동 관리를 참조하세요.

테이블은 온디맨드 용량 모드를 사용하지만 테이블은 여전히 제한되고 있습니다.

테이블이 온디맨드 용량 모드를 사용하는 경우 다음 조건이 충족되는 한 테이블이 제한되지 않습니다.

  • 액세스 패턴은 핫 파티션과 관련된 문제를 방지하기 위해 여러 파티션에 고르게 분산됩니다.
  • 이 테이블은 이전 피크 트래픽의 두 배를 초과하지 않습니다.

온디맨드 테이블의 경우 DynamoDB는 트래픽 볼륨이 증가함에 따라 자동으로 더 많은 용량을 할당하여 워크로드에 제한이 발생하지 않도록 합니다. 그러나 트래픽 볼륨이 30분 이내에 이전 피크의 두 배 이상인 경우 제한이 발생할 수 있습니다. 자세한 내용은 피크 트래픽 및 조정 속성을 참조하세요.

테이블에 핫 파티션이 있습니다.

DynamoDB에서 높은 카디널리티가 없는 파티션 키는 몇 개의 파티션만 대상으로 하는 요청이 많아 핫 파티션이 생성될 수 있습니다. 핫 파티션은 초당 파티션 제한 3,000 RCU 또는 1,000WCU(또는 둘의 조합)를 초과할 경우 제한이 발생할 수 있습니다.

테이블에서 가장 많이 액세스되고 제한된 항목을 찾으려면 Amazon CloudWatch Contributor Insights를 사용하세요. Amazon CloudWatch Contributor Insights는 DynamoDB 테이블의 트래픽 추세에 대한 요약 보기를 제공하고 가장 자주 액세스하는 파티션 키를 식별할 수 있게 도와주는 진단 도구입니다. 이 도구를 사용하면 테이블의 항목 액세스 패턴에 대한 그래프를 지속적으로 모니터링할 수 있습니다. 핫 파티션은 테이블의 전체 성능을 저하할 수 있습니다. 이러한 성능 저하를 방지하려면 읽기 및 쓰기 작업을 테이블 전체에 고르게 분산합니다. 자세한 정보는 워크로드를 균일하게 분산하기 위한 파티션 키 설계올바른 DynamoDB 파티션 키 선택 단원을 참조하세요.

참고: DynamoDB에 CloudWatch Contributor Insights 도구를 사용하면 추가 요금이 발생합니다. 자세한 내용은 DynamoDB 결제에 대한 CloudWatch Contributor Insights를 참조하세요.

테이블의 트래픽이 계정 처리량 할당량을 초과하고 있음

테이블 수준 읽기 처리량 및 테이블 수준 쓰기 처리량 할당량이 모든 리전의 계정 수준에서 적용됩니다. 이러한 할당량은 프로비저닝된 용량 모드와 온디맨드 용량 모드가 모두 있는 테이블에 적용됩니다. 기본적으로 테이블에 할당되는 처리량 할당량은 40,000개의 읽기 요청 유닛과 40,000개의 쓰기 요청 유닛입니다. 테이블에 대한 트래픽이 이 할당량을 초과하면 테이블이 제한될 수 있습니다. 이 문제를 해결하려면 Service Quotas 콘솔을 사용하여 계정에 대한 테이블 수준 읽기 및 쓰기 처리량 할당량을 늘립니다.


관련 정보

쓰기 샤딩을 사용하여 워크로드를 균등하게 분산

AWS 공식
AWS 공식업데이트됨 2년 전