Amazon DynamoDB 테이블에 대한 읽기 또는 쓰기 작업이 조절되어 애플리케이션에서 오류가 발생합니다. 하지만 Amazon CloudWatch에는 사용된 용량 유닛이 프로비저닝된 용량 유닛을 초과하지 않는 것으로 표시됩니다. 이 문제가 발생하는 원인은 무엇이고 어떻게 해결합니까?  

파티션이 조절되는 이유는 대개 다운스트림 애플리케이션이 다른 파티션보다 해당 파티션을 훨씬 자주 액세스하거나("사용 빈도가 높은" 파티션) 처리하는 워크로드가 단시간에 리소스를 많이 사용하기 때문입니다(읽기 또는 쓰기 작업의 "급증").

이 같은 사용 빈도가 높은 파티션과 조절 문제를 방지하려면 DynamoDB 모범 사례에서 설명하는 모범 사례 전략에 따라 테이블과 파티션 구조를 최적화해야 합니다.

다음 해결 방법을 하나 이상 활용할 수 있습니다.

  • 읽기 또는 쓰기 작업량이 일시적으로 급증하는 경우에 대비해 테이블의 읽기 또는 쓰기 용량을 늘립니다. 나중에 추가 용량이 더 이상 필요 없다고 판단되면 다시 용량을 줄입니다.
    참고: 읽기 또는 쓰기 용량을 얼마나 늘릴지를 결정하기 전에 워크로드를 균등하게 분산하도록 파티션 키 설계의 모범 사례를 고려하십시오.
  • 오류 재시도 및 지수 백오프를 구현합니다. 연속적인 오류 응답의 재시도 간격을 점진적으로 늘려 애플리케이션의 안정성을 높이는 방법입니다. AWS SDK를 사용하는 경우 이 로직은 기본 제공됩니다. 그렇지 않은 경우 수동으로 구현할 수 있습니다.
  • 읽기 작업과 쓰기 작업을 전체 테이블에 최대한 균등하게 배포합니다. "사용 빈도가 높은" 파티션은 테이블의 전반적인 성능을 저하시킬 수 있습니다.
  • DynamoDB Accelerator(DAX) 또는 Amazon ElastiCache 같은 캐싱 솔루션을 구현합니다. DAX는 애플리케이션에 빠른 인메모리 성능을 제공하는 DynamoDB 호환 캐싱 서비스입니다. 워크로드가 대부분 정적 데이터에 대한 읽기 액세스인 경우 데이터베이스가 아니라 잘 설계된 캐시에서 서비스하면 쿼리 결과의 속도가 향상될 수 있습니다.

단기적인 워크로드 불균형 문제를 완화하기 위해 적응형 용량이 5~30분 내에 활성화됩니다. 하지만 각 파티션에는 1,000개의 쓰기 용량 유닛 및 3,000개의 읽기 용량 유닛 제한이 계속 적용되므로 테이블 또는 파티션 설계에서 발생하는 더 큰 용량 문제는 적응형 용량으로 해결할 수 없습니다.


페이지 내용이 도움이 되었습니까? | 아니요

AWS 지원 지식 센터로 돌아가기

도움이 필요하십니까? AWS 지원 센터를 방문하십시오.

게시된 날짜: 2016년 8월 17일

업데이트된 날짜: 2018년 05월 29일