적절한 규모의 프로비저닝을 위해 프로비저닝된 용량 평가 - Amazon DynamoDB

적절한 규모의 프로비저닝을 위해 프로비저닝된 용량 평가

이 섹션에서는 DynamoDB 테이블에 적절한 규모의 프로비저닝이 있는지 평가하는 방법을 간략히 살펴봅니다. 워크로드가 발전함에 따라 운영 절차를 적절하게 수정해야 합니다. 특히 DynamoDB 테이블이 프로비저닝 모드로 구성되어 있고 테이블을 과다 프로비저닝하거나 과소 프로비저닝할 위험이 있는 경우에는 더욱 그렇습니다.

아래에 설명된 절차에는 프로덕션 애플리케이션을 지원하는 DynamoDB 테이블에서 캡처해야 하는 통계 정보가 필요합니다. 애플리케이션 동작을 이해하려면 애플리케이션의 데이터 계절성을 포착할 수 있을 만큼 충분히 중요한 기간을 정의해야 합니다. 예를 들어 애플리케이션이 주간 패턴을 보이는 경우 3주 기간을 사용하면 애플리케이션 처리량 요구 사항을 분석할 시간을 충분히 확보할 수 있습니다.

어디서부터 시작해야 할지 모르겠다면 아래 계산에 최소 한 달 분량의 데이터 사용량을 사용해 보세요.

DynamoDB 테이블은 용량을 평가하는 동안 읽기 용량 단위(RCU)쓰기 용량 단위(WCU)를 별개로 구성할 수 있습니다. 테이블에 글로벌 보조 인덱스(GSI)가 구성된 경우 소비할 처리량을 지정해야 합니다. 이 처리량은 기본 테이블의 RCU 및 WCU와도 별개입니다.

참고

로컬 보조 인덱스(LSI)는 기본 테이블의 용량을 소비합니다.

DynamoDB 테이블에서 소비 지표를 검색하는 방법

테이블 및 GSI 용량을 평가하려면 다음 CloudWatch 지표를 모니터링하고 적절한 차원을 선택하여 테이블 또는 GSI 정보를 검색하세요.

읽기 용량 단위 쓰기 용량 단위

ConsumedReadCapacityUnits

ConsumedWriteCapacityUnits

ProvisionedReadCapacityUnits

ProvisionedWriteCapacityUnits

ReadThrottleEvents

WriteThrottleEvents

AWS CLI 또는 AWS Management Console을 통해 이 작업을 할 수 있습니다.

AWS CLI

테이블 소비 지표를 검색하기 전에 먼저 CloudWatch API를 사용하여 일부 과거 데이터 포인트를 캡처해야 합니다.

먼저 두 개의 파일(write-calc.jsonread-calc.json)을 만듭니다. 이러한 파일은 테이블 또는 GSI에 대한 계산을 나타냅니다. 아래 표에 표시된 대로 일부 필드를 환경에 맞게 업데이트해야 합니다.

필드 이름 정의
<table-name> 분석하려는 테이블 이름 SampleTable
<period> 사용률 목표를 평가하는 데 사용할 기간(초 단위) 1시간인 경우 3,600 지정
<start-time> 평가 간격의 시작 부분으로, ISO8601 형식으로 지정 2022-02-21T23:00:00
<end-time> 평가 간격의 끝부분으로, ISO8601 형식으로 지정 2022-02-22T06:00:00

쓰기 계산 파일은 지정된 날짜 범위에 해당하는 기간 동안 프로비저닝되고 소비된 WCU 수를 검색합니다. 또한 분석에 사용할 사용률도 생성합니다. write-calc.json 파일의 전체 콘텐츠는 다음과 같아야 합니다.

{ "MetricDataQueries": [ { "Id": "provisionedWCU", "MetricStat": { "Metric": { "Namespace": "AWS/DynamoDB", "MetricName": "ProvisionedWriteCapacityUnits", "Dimensions": [ { "Name": "TableName", "Value": "<table-name>" } ] }, "Period": <period>, "Stat": "Average" }, "Label": "Provisioned", "ReturnData": false }, { "Id": "consumedWCU", "MetricStat": { "Metric": { "Namespace": "AWS/DynamoDB", "MetricName": "ConsumedWriteCapacityUnits", "Dimensions": [ { "Name": "TableName", "Value": "<table-name>"" } ] }, "Period": <period>, "Stat": "Sum" }, "Label": "", "ReturnData": false }, { "Id": "m1", "Expression": "consumedWCU/PERIOD(consumedWCU)", "Label": "Consumed WCUs", "ReturnData": false }, { "Id": "utilizationPercentage", "Expression": "100*(m1/provisionedWCU)", "Label": "Utilization Percentage", "ReturnData": true } ], "StartTime": "<start-time>", "EndTime": "<ent-time>", "ScanBy": "TimestampDescending", "MaxDatapoints": 24 }

읽기 계산 파일은 비슷한 파일을 사용합니다. 이 파일은 지정된 날짜 범위에 해당하는 기간 동안 프로비저닝되고 소비된 RCU 수를 검색합니다. read-calc.json 파일의 콘텐츠는 다음과 같아야 합니다.

{ "MetricDataQueries": [ { "Id": "provisionedRCU", "MetricStat": { "Metric": { "Namespace": "AWS/DynamoDB", "MetricName": "ProvisionedReadCapacityUnits", "Dimensions": [ { "Name": "TableName", "Value": "<table-name>" } ] }, "Period": <period>, "Stat": "Average" }, "Label": "Provisioned", "ReturnData": false }, { "Id": "consumedRCU", "MetricStat": { "Metric": { "Namespace": "AWS/DynamoDB", "MetricName": "ConsumedReadCapacityUnits", "Dimensions": [ { "Name": "TableName", "Value": "<table-name>" } ] }, "Period": <period>, "Stat": "Sum" }, "Label": "", "ReturnData": false }, { "Id": "m1", "Expression": "consumedRCU/PERIOD(consumedRCU)", "Label": "Consumed RCUs", "ReturnData": false }, { "Id": "utilizationPercentage", "Expression": "100*(m1/provisionedRCU)", "Label": "Utilization Percentage", "ReturnData": true } ], "StartTime": "<start-time>", "EndTime": "<end-time>", "ScanBy": "TimestampDescending", "MaxDatapoints": 24 }

파일을 만들었으면 사용률 데이터 검색을 시작할 수 있습니다.

  1. 쓰기 사용률 데이터를 검색하려면 다음 명령을 실행합니다.

    aws cloudwatch get-metric-data --cli-input-json file://write-calc.json
  2. 읽기 사용률 데이터를 검색하려면 다음 명령을 실행합니다.

    aws cloudwatch get-metric-data --cli-input-json file://read-calc.json

두 쿼리의 결과는 분석에 사용될 일련의 JSON 형식 데이터 포인트입니다. 결과는 지정한 데이터 포인트 수, 기간 및 고유한 워크로드 데이터에 따라 달라집니다. 결과는 다음과 같을 것입니다.

{ "MetricDataResults": [ { "Id": "utilizationPercentage", "Label": "Utilization Percentage", "Timestamps": [ "2022-02-22T05:00:00+00:00", "2022-02-22T04:00:00+00:00", "2022-02-22T03:00:00+00:00", "2022-02-22T02:00:00+00:00", "2022-02-22T01:00:00+00:00", "2022-02-22T00:00:00+00:00", "2022-02-21T23:00:00+00:00" ], "Values": [ 91.55364583333333, 55.066631944444445, 2.6114930555555556, 24.9496875, 40.94725694444445, 25.61819444444444, 0.0 ], "StatusCode": "Complete" } ], "Messages": [] }
참고

짧은 기간과 긴 시간 범위를 지정하는 경우 스크립트에서 기본값인 24로 설정되어 있는 MaxDatapoints를 수정해야 할 수 있습니다. 이는 시간당 하나의 데이터 포인트, 하루에 24개의 데이터 포인트를 나타냅니다.

AWS Management Console
  1. AWS Management Console에 로그인하고 CloudWatch 서비스 페이지로 이동합니다. 필요한 경우 적절한 AWS 리전을 선택합니다.

  2. 왼쪽 탐색 메뉴에서 지표 섹션을 찾은 다음 모든 지표를 선택합니다.

  3. 그러면 두 개의 패널이 있는 대시보드가 열립니다. 상단 패널에는 그래픽이 표시되고 하단 패널에는 그래프로 표시하려는 지표가 나타납니다. DynamoDB를 선택합니다.

  4. 테이블 지표를 선택합니다. 그러면 현재 리전에 있는 테이블이 표시됩니다.

  5. 검색 창을 사용하여 테이블 이름을 검색하고 쓰기 작업 지표(ConsumedWriteCapacityUnitsProvisionedWriteCapacityUnits)를 선택합니다.

    참고

    이 예제에서는 쓰기 작업 지표에 대해 설명하지만 다음 단계를 사용하여 읽기 작업 지표를 그래프로 표시할 수도 있습니다.

  6. 그래프로 표시된 지표(2) 탭을 선택하여 수식을 수정합니다. 기본적으로 CloudWatch는 그래프에 통계 함수 Average를 선택합니다.

    선택한 그래프로 표시된 지표와 기본 통계 함수로 사용되는 Average.
  7. 그래프로 표시된 지표 두 개를 모두 선택한 상태에서(왼쪽의 확인란) Add math(수식 추가), Common(공통) 메뉴를 차례로 선택한 다음 Percentage 함수를 선택합니다. 절차를 두 번 반복합니다.

    처음으로 Percentage 함수를 선택할 때:

    두 번째로 Percentage 함수를 선택할 때:

  8. 이제 하단 메뉴에 네 개의 지표가 있어야 합니다. ConsumedWriteCapacityUnits 계산 작업을 해봅시다. 일관성을 유지하려면 AWS CLI 섹션에서 사용한 이름과 동일한 이름을 사용해야 합니다. m1 ID를 클릭하고 이 값을 ConsumedWCU로 변경합니다.

  9. 통계를 Average에서 Sum으로 변경합니다. 이 작업을 수행하면 ANOMALY_DETECTION_BAND라는 또 다른 지표가 자동으로 생성됩니다. 이 절차의 범위에서는 새로 생성된 ad1 지표에서 확인란을 선택 취소하여 이 절차를 무시해도 됩니다.

  10. 8단계를 반복하여 m2 ID의 이름을 provisionedWCU로 변경합니다. 통계는 Average로 설정된 상태로 둡니다.

  11. Expression1 레이블을 선택하고 값을 m1로 업데이트한 다음 레이블을 Consumed WCUs로 업데이트합니다.

    참고

    데이터를 제대로 시각화하려면 m1(왼쪽의 확인란) 및 provisionedWCU만 선택했는지 확인하세요. Details(세부 정보)를 클릭하고 수식을 consumedWCU/PERIOD(consumedWCU)로 변경하여 수식을 업데이트합니다. 이 단계는 또 다른 ANOMALY_DETECTION_BAND 지표를 생성할 수도 있지만 이 절차의 범위에서는 무시해도 됩니다.

  12. 이제 두 개의 그래픽이 생겼을 것입니다. 하나는 테이블의 프로비저닝된 WCU를 나타내고 다른 하나는 소비된 WCU를 나타냅니다. 그래픽의 모양은 아래와 다를 수 있지만 참조로 사용할 수 있습니다.

  13. Expression2 그래픽(e2)을 선택하여 백분율 수식을 업데이트합니다. 레이블 및 ID의 이름을 utilizationPercentage로 변경합니다. 수식의 이름을 100*(m1/provisionedWCU)와 일치하도록 변경합니다.

  14. 사용률 패턴을 시각화하려면 utilizationPercentage를 제외한 모든 지표에서 확인란을 선택 취소하세요. 기본 간격은 1분으로 설정되어 있지만 필요에 따라 자유롭게 수정할 수 있습니다.

다음은 더 긴 시간 및 더 큰 1시간 기간의 모습입니다. 사용률이 100%보다 높은 간격이 있는 것을 볼 수 있지만, 이 특정 워크로드는 간격이 더 길고 사용률이 0입니다.

이 시점에서는 이 예제의 그림과 다른 결과를 얻을 수 있습니다. 이 모든 것은 워크로드의 데이터에 따라 달라집니다. 사용률이 100%를 초과하는 간격은 제한 이벤트가 발생하기 쉽습니다. DynamoDB는 버스트 용량을 제공하지만 버스트 용량이 완료되는 즉시 100%를 초과하는 용량은 제한됩니다.

과소 프로비저닝된 DynamoDB 테이블을 식별하는 방법

대부분의 워크로드에서 테이블은 프로비저닝된 용량의 80%를 초과하여 지속적으로 소비하는 경우 과소 프로비저닝된 것으로 간주됩니다.

버스트 용량은 고객이 원래 프로비저닝된 것보다 더 많은(테이블에 정의된 초당 프로비저닝된 처리량보다 많은) RCU/WCU를 일시적으로 소비할 수 있도록 하는 DynamoDB 기능입니다. 버스트 용량은 특수 이벤트 또는 사용량 급증으로 인한 갑작스러운 트래픽 증가를 흡수하기 위해 만들어졌습니다. 이 버스트 용량은 지속되지 않습니다. 사용되지 않은 RCU와 WCU가 소진되었을 때 프로비저닝된 용량보다 더 많은 용량을 소비하려고 하면 제한이 발생합니다. 애플리케이션 트래픽이 80% 사용률에 가까워지면 제한 위험이 훨씬 높아집니다.

80% 사용률 규칙은 데이터의 계절성 및 트래픽 증가에 따라 달라집니다. 다음 시나리오를 고려해 보세요.

  • 지난 12개월 동안 트래픽이 약 90%의 사용률로 안정적이었다면 테이블의 용량이 적절한 것입니다.

  • 애플리케이션 트래픽이 3개월 이내에 매월 8%씩 증가하면 100%에 도달하게 됩니다.

  • 애플리케이션 트래픽이 4개월이 조금 넘는 기간 이내에 5%씩 증가해도 100%에 도달하게 됩니다.

위 쿼리의 결과는 사용률을 보여줍니다. 이를 참고하여 필요에 따라 테이블 용량을 늘리도록 선택하는 데 도움이 될 수 있는 다른 지표(예: 월별 또는 주별 증가율)를 추가로 평가해 보세요. 운영 팀과 협력하여 워크로드와 테이블에 적합한 비율을 정하세요.

일별 또는 주별로 데이터를 분석할 때 데이터가 왜곡되는 특수한 시나리오가 있습니다. 예를 들어 근무 시간 동안 사용량이 급증하다가 근무 시간 외에는 거의 0으로 떨어지는 계절성 애플리케이션의 경우, 프로비저닝된 용량을 늘리거나 줄일 하루 중 시간(및 요일)을 지정하는 Auto Scaling을 예약하면 효과를 볼 수 있습니다. 바쁜 시간을 처리하기 위해 더 높은 용량을 목표로 하는 대신 계절성이 덜 두드러지는 경우 DynamoDB 테이블 Auto Scaling 구성을 활용할 수도 있습니다.

참고

기본 테이블에 대해 DynamoDB Auto Scaling 구성을 생성할 때는 테이블과 연결된 GSI에 대해 다른 구성을 포함해야 한다는 점을 기억하세요.

과다 프로비저닝된 DynamoDB 테이블을 식별하는 방법

위 스크립트에서 얻은 쿼리 결과는 일부 초기 분석을 수행하는 데 필요한 데이터 포인트를 제공합니다. 데이터 세트의 여러 간격에 사용률이 20% 미만인 값이 표시되면 테이블이 과다 프로비저닝된 것일 수 있습니다. WCU 및 RCU 수를 줄여야 하는지 여부를 더 자세히 정의하려면 해당 간격의 다른 측정값을 다시 살펴봐야 합니다.

테이블에 낮은 사용 간격이 여러 개 있는 경우 Auto Scaling을 예약하거나 사용률을 기반으로 테이블에 대한 기본 Auto Scaling 정책을 구성하여 Auto Scaling 정책을 사용하면 큰 이점을 얻을 수 있습니다.

워크로드에 사용률이 낮고 제한은 높은 비율(간격의 Max(ThrottleEvents)/Min(ThrottleEvents))이 있는 경우 며칠(또는 몇 시간) 동안 트래픽이 많이 증가하지만 일반적으로는 트래픽이 지속적으로 낮은 변동이 심한 워크로드일 때 이런 일이 발생할 수 있습니다. 이러한 시나리오에서는 예약된 Auto Scaling을 사용하는 것이 유용할 수 있습니다.