DynamoDB 프로비저닝된 용량 테이블의 설정 관리

Amazon DynamoDB에서 프로비저닝된 테이블을 새로 생성할 때는 프로비저닝된 처리 용량을 지정해야 합니다. 이는 테이블에서 지원할 수 있는 읽기 및 쓰기 활동의 양입니다. DynamoDB는 이 정보를 사용하여 처리량 요구 사항에 맞는 충분한 시스템 리소스를 예약합니다.

참고

서버, 스토리지 또는 처리량에 대한 용량 설정을 관리할 필요가 없도록 온디맨드 모드 테이블을 대신 생성할 수 있습니다. DynamoDB는 이전에 도달한 트래픽 수준까지 확장 또는 축소할 때 즉시 워크로드를 수용합니다. 워크로드 트래픽 수준이 새로운 피크를 기록할 경우에는 DynamoDB가 워크로드를 수용하기 위해 신속하게 조정을 수행합니다. 자세한 설명은 온디맨드 모드 섹션을 참조하세요.

아니면 DynamoDB Auto Scaling에서 테이블의 처리 용량을 관리하도록 허용할 수도 있습니다. 그러나 그렇게 해도 테이블을 생성할 때 읽기 및 쓰기 용량의 초기 설정은 지정해야 합니다. DynamoDB Auto Scaling은 이러한 초기 설정을 출발점으로 하여 애플리케이션의 요구 사항에 따라 동적으로 이를 조정합니다. 자세한 설명은 DynamoDB Auto Scaling을 사용하여 자동으로 처리량 용량 관리 섹션을 참조하세요.

애플리케이션의 데이터 및 액세스 요구 사항이 변화함에 따라 테이블의 처리량 설정을 조정해야 합니다. DynamoDB Auto Scaling을 사용하는 경우 실제 워크로드에 맞게 처리량 설정이 자동으로 조정됩니다. 또한 UpdateTable 작업을 사용하여 테이블의 처리 용량을 수동으로 조정할 수도 있습니다. 기존 데이터 스토어에서 새 DynamoDB 테이블로 데이터를 대량 로드해야 할 경우 이러한 방식을 선택할 수 있습니다. 쓰기 처리량 설정을 크게 하여 테이블을 생성한 다음, 데이터 대량 로드가 완료되면 이 설정을 줄여도 됩니다.

처리량 요구 사항을 애플리케이션에서 초당 읽거나 써야 하는 데이터 양인 용량 단위를 기준으로 지정합니다. 필요하면 나중에 이러한 설정을 수정하거나 DynamoDB Auto Scaling을 활성화하여 자동으로 수정할 수 있습니다.

읽기 용량 단위

읽기 용량 단위 1은 초당 강력히 일관된 읽기 1 또는 초당 최종적으로 일관된 읽기 2(최대 4KB 크기 항목의 경우)를 나타냅니다.

참고

DynamoDB 읽기 일관성 모델에 대한 자세한 내용은 읽기 정합성 단원을 참조하세요.

예를 들어 할당된 읽기 용량 단위 10개로 테이블을 생성한다고 가정하겠습니다. 이렇게 하면 최대 4KB의 항목에 대해 초당 강력히 일관된 읽기 10회 또는 초당 최종적으로 일관된 읽기 20회를 수행할 수 있습니다.

4KB보다 큰 항목을 읽을 때는 읽기 용량 단위가 더 많이 소비됩니다. 예를 들어, 8KB(4KB × 2)인 항목의 강력히 일관된 읽기에는 읽기 용량 단위 2가 소비됩니다. 같은 항목의 최종적 일관된 읽기에서는 읽기 용량 단위 1개만 소비합니다.

읽기 항목 크기는 다음 4KB 배수로 반올림됩니다. 예를 들어, 3,500바이트의 항목을 읽으려면 4KB 항목을 읽을 때와 동일한 처리량이 소비됩니다.

읽기 용량 단위 소비량

다음은 DynamoDB 읽기 작업이 어떻게 읽기 용량 단위를 소비하는지에 대한 설명입니다.

• GetItem - 테이블에서 단일 항목을 읽습니다. GetItem에 사용되는 용량 단위 수를 결정하려면 항목 크기를 가져와서 다음 4KB 경계로 올림합니다. 강력한 일관된 읽기를 지정한 경우, 이 값이 필요한 용량 단위 개수가 됩니다. 최종적 일관된 읽기(기본값)의 경우, 이 숫자를 2로 나눕니다.

  예를 들어, 크기가 3.5KB인 항목 하나를 읽는 경우 DynamoDB가 항목 크기를 4KB로 올림합니다. 그리고 크기가 10KB인 항목 하나를 읽는다면 DynamoDB가 항목 크기를 12KB로 올림합니다.

• BatchGetItem - 하나 이상의 테이블에서 최대 100개의 항목을 읽습니다. DynamoDB는 배치의 각 항목을 개별 GetItem 요청으로 처리하므로 먼저 각 항목의 크기를 다음 4KB 배수로 올림한 후 전체 크기를 계산합니다. 계산 결과는 모든 항목의 전체 크기와 반드시 동일하지는 않습니다. 예를 들어, BatchGetItem 작업으로 1.5KB 항목 하나와 6.5KB 항목 하나를 읽어올 경우 DynamoDB에서는 8KB(1.5KB + 6.5KB)가 아닌 12KB(4KB + 8KB)로 크기를 계산합니다.

• Query - 파티션 키 값이 동일한 여러 항목을 읽습니다. 반환되는 모든 항목이 단일 읽기 작업으로 처리됩니다. 이 경우 DynamoDB가 모든 항목의 총 크기를 계산한 후 다음 4KB 경계로 올림합니다. 예를 들어, 쿼리가 10개 항목을 반환하여 전체 크기가 40.8KB라고 가정하겠습니다. 이 경우 DynamoDB는 작업 항목 크기를 44KB로 올림합니다. 그리고, 쿼리가 각각 64byte인 항목 1,500개를 반환한다면 누적 크기는 96KB가 됩니다.

• Scan - 테이블의 모든 항목을 읽습니다. DynamoDB는 스캔에서 반환된 데이터의 크기가 아니라 평가되는 데이터의 크기를 고려합니다.

존재하지 않는 항목에 대해 읽기 작업을 실행하면 DynamoDB가 프로비저닝된 읽기 처리량을 소비합니다. 즉, 강력히 일관된 읽기 요청이 읽기 용량 단위 1개를 소비하는 반면 최종적으로 일관된 읽기 요청은 읽기 용량 단위 0.5개를 소비합니다.

항목을 반환하는 모든 작업에서 검색할 속성의 하위 집합을 요청할 수 있습니다. 그러나 이렇게 해도 항목 크기 계산에 영향이 미치지 않습니다. 또한 Query나 Scan 작업은 속성 값이 아닌 항목 수를 반환하기도 합니다. 항목 수를 가져올 때도 사용되는 읽기 용량 단위의 수는 동일하며, 항목 크기 계산도 똑같이 적용됩니다. 이는 DynamoDB가 수를 늘리기 위해 각 항목을 읽어야 하기 때문입니다.

읽기 작업 및 읽기 정합성

위의 계산들은 모두 강력히 일관된 읽기 요청을 전제로 합니다. 최종적 일관된 읽기 요청이라면 위 용량 단위의 50%만 소비합니다. 즉 전체 항목 크기가 80KB라면 최종적 일관된 읽기로 소비되는 용량 단위는 10개만 해당됩니다.

쓰기 용량 단위

쓰기 용량 단위 1은 최대 1KB 크기의 항목에 대해 초당 1회 쓴다는 의미입니다.

예를 들어, 쓰기 용량 단위 10개로 테이블을 생성한다고 가정하겠습니다. 이렇게 하면 초당 최대 1KB 크기의 항목에 대해 초당 쓰기 10회를 수행할 수 있습니다.

쓰기 항목 크기는 다음 1KB 배수로 반올림됩니다. 예를 들어, 500바이트의 항목을 쓰려면 1KB 항목을 쓸 때와 동일한 처리량이 소비됩니다.

쓰기 용량 단위 소비량

다음은 DynamoDB 쓰기 작업이 어떻게 읽기 용량 단위를 소비하는지에 대한 설명입니다.

• PutItem - 테이블에 단일 항목을 씁니다. 이때 기본 키가 동일한 항목이 테이블에 존재하면 이 항목까지 바뀝니다. 프로비저닝된 처리량 소비를 계산할 경우 둘 중 항목 크기가 더 큰 것이 적용됩니다.

• UpdateItem - 테이블에서 단일 항목을 수정합니다. DynamoDB는 업데이트 전후에 표시되는 항목의 크기를 고려합니다. 이때 할당 처리량을 소비하려면 크기가 더 큰 항목이 반영됩니다. 항목 속성의 하위 집합을 업데이트하더라도 UpdateItem은 할당 처리량("사전" 항목 크기와 "사후" 항목 크기 중 더 큰 것)을 모두 소비합니다.

• DeleteItem - 테이블에서 단일 항목을 제거합니다. 할당된 처리량 소비는 삭제된 항목의 크기를 기준으로 합니다.

• BatchWriteItem - 하나 이상의 테이블에 최대 25개의 항목을 씁니다. DynamoDB는 배치의 각 항목을 개별 PutItem 또는 DeleteItem 요청으로 처리합니다(업데이트는 지원되지 않음). 따라서 DynamoDB가 먼저 각 항목의 크기를 다음 1KB 배수로 올림한 후 전체 크기를 계산합니다. 계산 결과는 모든 항목의 전체 크기와 반드시 동일하지는 않습니다. 예를 들어, BatchWriteItem이 500바이트 항목과 3.5KB 항목을 쓰는 경우 DynamoDB는 크기를 4KB(500바이트 + 3.5KB)가 아니라 5KB(1KB + 4KB)로 계산합니다.

PutItem, UpdateItem 및 DeleteItem 작업의 경우 DynamoDB는 항목 크기를 다음 1KB로 올림합니다. 예를 들어 크기가 1.6KB인 항목 하나를 업로드하거나 삭제한다면 DynamoDB가 항목 크기를 2KB로 반올림합니다.

PutItem, UpdateItem 및 DeleteItem은 대부분 조건부 쓰기가 가능합니다. 이 경우 사용자가 지정한 표현식이 true로 평가되어야만 작업이 성공적으로 완료됩니다. 표현식이 false로 평가되더라도 DynamoDB는 계속 테이블에서 쓰기 용량 단위를 소비합니다. 소비되는 양은 항목의 크기(테이블에 있는 기존 항목인지 또는 새로 만들거나 업데이트하려는 새 항목인지 여부)에 따라 달라집니다. 예를 들어 기존 항목이 300kb이고 새로 만들거나 업데이트하려는 항목이 310kb인 경우 소비되는 쓰기 용량 단위는 310kb 항목이 됩니다.

제한 및 버스트 용량 요청

애플리케이션이 테이블에서 지원되는 것보다 빠른 속도로 읽기 또는 쓰기를 수행하는 경우 DynamoDB는 해당 요청을 제한하기 시작합니다. DynamoDB는 읽기 또는 쓰기를 제한할 때 호출자에게 ProvisionedThroughputExceededException을 반환합니다. 그러면 애플리케이션에서는 잠깐 동안 기다렸다가 요청을 재시도하는 등 적절한 조치를 취할 수 있게 됩니다.

참고

소프트웨어 AWS 개발에는 SDK를 사용하는 것이 좋습니다. AWS SDK는 조정된 요청 재시도를 기본적으로 지원하므로 이 로직을 직접 작성할 필요는 없습니다. 자세한 설명은 오류 재시도 횟수 및 지수 백오프 섹션을 참조하세요.

DynamoDB 콘솔은 테이블에 대한 CloudWatch Amazon 지표를 표시하므로 병목 현상이 발생한 읽기 요청 및 쓰기 요청을 모니터링할 수 있습니다. 조절이 과도한 경우에는 테이블의 할당된 처리량 설정을 늘리는 것을 고려해야 합니다.

DynamoDB는 테이블의 처리량 설정을 초과하는 읽기 또는 쓰기를 수용하기 위해 경우에 따라 버스트 용량을 사용하기도 합니다. 원래는 조절되어야 하는 예상치 못한 읽기 또는 쓰기 요청도 버스트 용량으로 해결할 수 있습니다. 자세한 설명은 효과적으로 버스트 용량 사용 섹션을 참조하세요.

제한 및 조정 용량 요청

DynamoDB는 클라우드의 여러 서버에 저장되는 파티션에 데이터를 자동으로 배포합니다 (자세한 내용은 참조). AWS 파티션 및 데이터 배포 항상 읽기와 쓰기 작업을 골고루 배포할 수 있는 것은 아닙니다. 데이터 액세스가 불균형할 때, '핫' 파티션은 다른 파티션보다 볼륨이 많은 읽기와 쓰기 트래픽을 받을 수 있습니다. 조정 용량은 더 많은 트래픽을 받는 파티션의 처리량 용량을 자동으로 증가시킵니다. 자세한 설명은 DynamoDB 조정 용량 이해 섹션을 참조하세요.

초기 처리량 설정 선택

데이터베이스에서 읽기 및 쓰기 위한 요구 사항은 애플리케이션마다 다릅니다. DynamoDB 테이블의 초기 처리량 설정을 결정할 때는 다음과 같은 입력값을 고려해야 합니다.

• 항목 크기. 크기가 작아서 용량 단위 하나를 사용하여 읽거나 쓸 수 있는 항목도 있습니다. 그보다 큰 항목에는 용량 단위가 여러 개 필요합니다. 테이블에 들어갈 항목의 크기를 예측하여 해당 테이블의 할당된 처리량을 정확히 설정할 수 있습니다.

• 예상되는 읽기 및 쓰기 요청 속도. 항목 크기 외에, 초당 수행해야 하는 읽기 및 쓰기 횟수도 예측해야 합니다.

• 읽기 일관성 요구 사항. 읽기 용량 단위의 기준이 되는 강력한 일관된 읽기 작업은 최종적 일관된 읽기보다 데이터베이스 리소스를 두 배나 더 많이 소비합니다. 애플리케이션에 필요한 것이 강력한 일관된 읽기인지, 아니면 이러한 요구 사항을 완화하여 그 대신 최종적 일관된 읽기를 수행할 수 있는지 여부를 결정해야 합니다. (기본적으로 DynamoDB의 읽기 작업은 최종적으로 일관된 읽기입니다. 필요한 경우 이러한 작업에 대해 강력히 일관된 읽기를 요청할 수 있습니다.)

예를 들어, 테이블에서 초당 80개의 항목을 읽으려고 하며, 항목 크기는 3KB이고, 강력한 일관된 읽기(Strongly Consistent Read)를 수행하려 합니다. 이 시나리오에서, 각 읽기는 할당된 읽기 용량 단위 1을 요구합니다. 이 수를 구하려면, 다음 예와 같이 작업의 항목 크기를 4KB로 나눈 다음 가장 가까운 정수로 올림합니다.

• 3KB/4KB = 0.75 또는 읽기 용량 단위 1

이 시나리오의 경우 테이블의 할당된 읽기 처리량을 읽기 용량 단위 80으로 설정해야 합니다.

• 항목당 읽기 용량 단위 1 × 초당 읽기 80회 = 읽기 용량 단위 80

이번에는 초당 100개의 항목을 테이블에 쓰려 하고 항목 크기는 512KB인 경우를 예로 들어 보겠습니다. 이 시나리오에서, 각 쓰기에는 할당된 쓰기 용량 단위 1이 필요합니다. 이 수를 구하려면, 작업의 항목 크기를 1KB로 나눈 다음, 가장 가까운 정수로 올림합니다.

• 512바이트/1KB = 0.5 또는 1

이 시나리오의 경우 테이블의 프로비저닝된 쓰기 처리량을 쓰기 용량 유닛 100으로 설정합니다.

• 항목당 쓰기 용량 단위 1 × 초당 쓰기 100회 = 쓰기 용량 단위 100

참고

할당된 처리량 권장 사항 및 관련 주제에 대한 자세한 내용은 효과적으로 파티션 키를 설계해 사용하는 모범 사례 단원을 참조하십시오.

처리량 설정 수정

테이블에 대해 DynamoDB Auto Scaling을 활성화한 경우 실제 사용량에 따라 처리 능력이 동적으로 조정됩니다. 따라서 수동 개입은 필요 없습니다.

또는 작업을 사용하여 테이블의 프로비저닝된 처리량 설정을 수정할 수 있습니다. AWS Management Console UpdateTable 하루당 처리량 증가 및 감소에 대한 자세한 내용은 Amazon DynamoDB의 서비스, 계정 및 테이블 할당량 단원을 참조하십시오.

제한 문제 해결

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

다음은 몇 가지 일반적인 시나리오와 이를 해결하는 데 도움이 될 수 있는 단계입니다.

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

이는 처리량이 분당 평균보다 낮지만 처리량이 초당 사용 가능한 양을 초과할 때 발생할 수 있습니다. DynamoDB는 분 수준 지표만 보고하며, 이 CloudWatch 지표는 1분 동안의 합계로 계산되어 평균을 구합니다. 하지만 DynamoDB 자체는 초당 속도 제한을 적용합니다. 따라서 이 1분 중 작은 부분(예: 몇 초 이하)에서 해당 처리량이 너무 많이 발생하는 경우 1분의 나머지 시간에 대한 요청이 제한될 수 있습니다. 예를 들어 테이블에 60WCU를 프로비저닝한 경우 1분 안에 3,600회의 쓰기를 수행할 수 있습니다. 그러나 3,600개의 WCU 요청이 모두 같은 초에 발생하면 1분의 나머지 시간은 제한됩니다.

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

AutoScaling이 활성화되었지만 테이블에 여전히 제한이 발생합니다.

이는 트래픽이 급증할 때 발생할 수 있습니다. 1분 내에 두 데이터 포인트가 구성된 목표 사용률 값을 위반하는 경우 Auto Scaling이 트리거될 수 있습니다. 따라서 2분 동안 사용된 용량이 목표 사용률을 초과하기 때문에 Auto Scaling이 발생할 수 있습니다. 그러나 스파이크 간격이 1분 이상이면 Auto Scaling이 트리거되지 않을 수 있습니다. 마찬가지로 15개의 연속 데이터 포인트가 목표 사용률보다 낮을 때 스케일 다운 이벤트가 트리거될 수 있습니다. 두 경우 모두 Auto Scaling이 트리거된 후 UpdateTable호출이 호출됩니다. 그러면 테이블 또는 인덱스의 프로비저닝된 용량을 업데이트하는 데 몇 분이 걸릴 수 있습니다. 이 기간 동안 이전에 프로비저닝된 테이블 용량을 초과하는 모든 요청은 병목 현상이 발생합니다.

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

테이블이 "온디맨드" 용량 모드이지만 여전히 제한이 발생합니다.

온디맨드 테이블의 경우 DynamoDB는 트래픽 볼륨이 증가함에 따라 자동으로 더 많은 용량을 할당합니다. 액세스가 파티션 간에 균등하게 분산되고 테이블이 이전 피크 트래픽의 2배를 초과하지 않는 한 전체 테이블은 제한되지 않습니다. 하지만 처리량이 동일한 30분 이내에 이전 피크의 2배를 초과할 경우 여전히 제한이 발생할 수 있습니다. 자세한 내용은 OnDemand 스케일링을 참조하십시오.

핫키로 인해 제한 문제가 발생할 수 있습니다.

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

CloudWatch 지표를 사용하여 스로틀링 조사하기

아래는 제한 이벤트 중에 모니터링해야 하는 몇 가지 DynamoDB 지표로, 어떤 작업이 제한된 요청을 생성하는지 파악하고 근본 문제를 식별하는 데 도움이 됩니다.

1. ThrottledRequests

• 하나의 제한된 요청에는 여러 개의 제한된 이벤트가 포함될 수 있으므로 이벤트를 검사하는 것이 더 적절할 수 있습니다.

  예를 들어 테이블의 항목을 GSI로 업데이트하는 경우 테이블에 쓰기, 각 인덱스에 쓰기 등과 같은 여러 이벤트가 발생합니다. 이러한 이벤트 중 하나 이상이 병목 현상이 발생하더라도 이벤트는 하나뿐입니다. ThrottledRequest

2. ReadThrottleEvents

• 테이블 또는 GSI에 프로비저닝된 RCU를 초과하는 요청이 있는지 확인합니다.

3. WriteThrottleEvents

• 테이블 또는 GSI에 프로비저닝된 WCU를 초과하는 요청이 있는지 확인합니다.

4. OnlineIndexConsumedWriteCapacity

• 테이블에 새 GSI를 추가할 때 소비되는 WCU 수에 주의합니다. GSI의 ConsumedWriteCapacityUnits에는 인덱스 생성 중에 소비되는 WCU는 포함되지 않는다는 점에 유의합니다.

• GSI의 WCU를 너무 낮게 설정하면 채우기 단계에서 수신되는 쓰기 작업이 제한될 수 있습니다.

5. OnlineIndexThrottleEvents

• 새 GSI를 테이블에 추가할 때 발생하는 쓰기 제한 이벤트의 수를 검토합니다.

• WCU가 너무 낮게 설정되어 제한되고 있는 경우, 채우기 중에도 GSI의 WCU 값을 업데이트할 수 있습니다.

6. Provisioned Read/Write

• 지정된 기간 동안 테이블 또는 지정된 글로벌 보조 인덱스에 대해 소비된 프로비저닝된 읽기 또는 쓰기 용량 단위 수를 확인합니다.

• TableName 차원은 기본적으로 테이블에 대한 ProvisionedReadCapacityUnits만 반환한다는 점에 유의하세요. 글로벌 보조 인덱스에 대해 프로비저닝된 읽기 또는 쓰기 용량 단위 수를 보려면 TableName 및 GlobalSecondaryIndexName을 모두 지정해야 합니다.

7. Consumed Read/Write

• 지정된 기간 동안 사용된 읽기 또는 쓰기 용량 단위 수를 볼 수 있습니다.

CloudWatch DynamoDB 지표에 대한 자세한 내용은 지표 및 차원을 참조하십시오.