

# DynamoDB 테이블의 오토 스케일링 설정 평가
<a name="CostOptimization_AutoScalingSettings"></a>

이 섹션에서는 DynamoDB 테이블의 Auto Scaling 설정을 평가하는 방법을 간략히 살펴봅니다. [Amazon DynamoDB Auto Scaling은](AutoScaling.md) 애플리케이션 트래픽과 대상 사용률 지표를 기반으로 테이블 및 글로벌 보조 인덱스(GSI) 처리량을 관리하는 기능입니다. 이렇게 하면 테이블 또는 GSI가 애플리케이션 패턴에 필요한 용량을 확보할 수 있습니다.

AWS Auto Scaling 서비스는 현재 테이블 사용률을 모니터링하고 이를 목표 사용률 값(`TargetValue`)과 비교합니다. 할당된 용량을 늘리거나 줄여야 할 시기가 되면 알려 줍니다.

**Topics**
+ [Auto Scaling 설정 이해하기](#CostOptimization_AutoScalingSettings_UnderProvisionedTables)
+ [목표 사용률이 낮은(<= 50%) 테이블을 식별하는 방법](#CostOptimization_AutoScalingSettings_IdentifyLowUtilization)
+ [계절적 변동이 있는 워크로드를 해결하는 방법](#CostOptimization_AutoScalingSettings_SeasonalVariance)
+ [알 수 없는 패턴으로 급증하는 워크로드를 해결하는 방법](#CostOptimization_AutoScalingSettings_UnknownPatterns)
+ [연결된 애플리케이션으로 워크로드를 해결하는 방법](#CostOptimization_AutoScalingSettings_BetweenRanges)

## Auto Scaling 설정 이해하기
<a name="CostOptimization_AutoScalingSettings_UnderProvisionedTables"></a>

목표 사용률, 초기 단계 및 최종 값에 대한 올바른 값을 정의하려면 운영 팀의 참여가 필요합니다. 이렇게 하면 AWS Auto Scaling 정책을 트리거하는 데 사용될 값을 과거 애플리케이션 사용량을 기반으로 적절하게 정의할 수 있습니다. 사용률 목표는 Auto Scaling 규칙이 적용되기 전에 일정 기간 동안 도달해야 하는 총 용량의 백분율입니다.

**높은 사용률 목표(약 90%의 목표)**를 설정하면 Auto Scaling이 시작되기 전에 일정 기간 동안 트래픽이 90%보다 높아야 합니다. 애플리케이션이 매우 일정하고 트래픽 급증이 발생하지 않는 한 높은 사용률 목표를 사용해서는 안 됩니다.

매우 **낮은 사용률(50% 미만의 목표)**을 설정하면 애플리케이션이 Auto Scaling 정책을 실행하기 전에 프로비저닝된 용량의 50%에 도달해야 합니다. 애플리케이션 트래픽이 매우 빠른 속도로 증가하지 않는 한 이는 대개 용량 미사용 및 리소스 낭비로 이어집니다.

## 목표 사용률이 낮은(<= 50%) 테이블을 식별하는 방법
<a name="CostOptimization_AutoScalingSettings_IdentifyLowUtilization"></a>

AWS CLI 또는 AWS Management Console을 사용하여 DynamoDB 리소스의 Auto Scaling 정책에 대한 `TargetValues`를 모니터링하고 식별할 수 있습니다.

------
#### [ AWS CLI ]

1. 다음 명령을 실행하여 전체 리소스 목록을 반환합니다.

   ```
   aws application-autoscaling describe-scaling-policies --service-namespace dynamodb
   ```

   이 명령은 모든 DynamoDB 리소스에 발행된 Auto Scaling 정책의 전체 목록을 반환합니다. 특정 테이블에서만 리소스를 검색하려는 경우 `–resource-id parameter`를 추가하면 됩니다. 예제:

   ```
   aws application-autoscaling describe-scaling-policies --service-namespace dynamodb --resource-id "table/<table-name>”
   ```

1. 다음 명령을 실행하여 특정 GSI에 대한 Auto Scaling 정책만 반환하세요.

   ```
   aws application-autoscaling describe-scaling-policies --service-namespace dynamodb --resource-id "table/<table-name>/index/<gsi-name>”
   ```

   Auto Scaling 정책과 관련하여 알아야 할 값은 아래에 강조 표시되어 있습니다. 과다 프로비저닝을 방지하기 위해 목표값을 50%보다 높게 설정하고자 합니다. 다음과 유사한 결과가 출력되어야 합니다.

   ```
   {
       "ScalingPolicies": [
           {
               "PolicyARN": "arn:aws:autoscaling:<region>:<account-id>:scalingPolicy:<uuid>:resource/dynamodb/table/<table-name>/index/<index-name>:policyName/$<full-gsi-name>-scaling-policy",
               "PolicyName": $<full-gsi-name>”,
               "ServiceNamespace": "dynamodb",
               "ResourceId": "table/<table-name>/index/<index-name>",
               "ScalableDimension": "dynamodb:index:WriteCapacityUnits",
               "PolicyType": "TargetTrackingScaling",
               "TargetTrackingScalingPolicyConfiguration": {
                   "TargetValue": 70.0,
                   "PredefinedMetricSpecification": {
                       "PredefinedMetricType": "DynamoDBWriteCapacityUtilization"
                   }
               },
               "Alarms": [
                   ...
               ],
               "CreationTime": "2022-03-04T16:23:48.641000+10:00"
           },
           {
               "PolicyARN": "arn:aws:autoscaling:<region>:<account-id>:scalingPolicy:<uuid>:resource/dynamodb/table/<table-name>/index/<index-name>:policyName/$<full-gsi-name>-scaling-policy",
               "PolicyName":$<full-gsi-name>”,
               "ServiceNamespace": "dynamodb",
               "ResourceId": "table/<table-name>/index/<index-name>",
               "ScalableDimension": "dynamodb:index:ReadCapacityUnits",
               "PolicyType": "TargetTrackingScaling",
               "TargetTrackingScalingPolicyConfiguration": {
                   "TargetValue": 70.0,
                   "PredefinedMetricSpecification": {
                       "PredefinedMetricType": "DynamoDBReadCapacityUtilization"
                   }
               },
               "Alarms": [
                   ...
               ],
               "CreationTime": "2022-03-04T16:23:47.820000+10:00"
           }
       ]
   }
   ```

------
#### [ AWS Management Console ]

1. AWS Management Console에 로그인하고 DynamoDB 콘솔([https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/))을 엽니다.

   필요한 경우 적절한 AWS 리전을 선택합니다.

1. 왼쪽 탐색 메뉴에서 **Tables**(테이블)를 선택합니다. **Tables**(테이블) 페이지에서 테이블 **이름**을 선택합니다.

1. *테이블 세부 정보* 페이지에서 **추가 설정**을 선택한 다음 테이블의 Auto Scaling 설정을 검토합니다.  
![\[Auto Scaling 설정이 포함된 DynamoDB 테이블 세부 정보 페이지. 프로비저닝된 용량 사용률을 검토하고 필요에 따라 조정하세요.\]](http://docs.aws.amazon.com/ko_kr/amazondynamodb/latest/developerguide/images/CostOptimization/AutoScalingSettings1.png)

   인덱스의 경우 **인덱스 용량** 섹션을 확장하여 인덱스의 Auto Scaling 설정을 검토합니다.  
![\[DynamoDB 콘솔의 인덱스 용량 섹션. 인덱스의 Auto Scaling 설정을 검토하고 관리합니다.\]](http://docs.aws.amazon.com/ko_kr/amazondynamodb/latest/developerguide/images/CostOptimization/AutoScalingSettings2.png)

------

목표 사용률 값이 50% 이하이면 테이블 사용률 지표를 살펴보고 해당 지표가 [과소 프로비저닝되었는지 과다 프로비저닝되었는지](CostOptimization_RightSizedProvisioning.md) 확인해야 합니다.

## 계절적 변동이 있는 워크로드를 해결하는 방법
<a name="CostOptimization_AutoScalingSettings_SeasonalVariance"></a>

다음과 같은 시나리오를 생각해 보세요. 대부분의 경우 애플리케이션이 최소 평균값 미만으로 작동하지만 사용률 목표가 낮기 때문에 애플리케이션이 하루 중 특정 시간에 발생하는 이벤트에 신속하게 반응할 수 있고 충분한 용량이 확보되어 제한을 피할 수 있습니다. 이 시나리오는 일반적인 업무 시간(오전 9시\$1오후 5시)에는 사용량이 아주 많지만 업무 시간 이후에는 기본 수준에서 작동하는 애플리케이션이 있는 경우에 일반적입니다. 일부 사용자는 오전 9시 이전에 연결을 시작하므로 애플리케이션은 이 낮은 임계값을 사용하여 사용량이 많은 시간대에 *필요한* 용량에 빠르게 도달합니다.

이 시나리오는 다음과 같이 진행될 수 있습니다.
+ 오후 5시에서 오전 9시 사이에는 `ConsumedWriteCapacity` 단위가 90에서 100 사이로 유지됩니다.
+ 사용자가 오전 9시 이전에 애플리케이션에 연결하기 시작하면 용량 단위가 크게 늘어납니다(지금까지 본 최대값은 1,500WCU).
+ 평균적인 애플리케이션 사용량은 근무 시간 동안 800에서 1,200 사이로 다양합니다.

이전 시나리오에 해당하는 경우 [예약된 Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/examples-scheduled-actions.html)을 사용하는 것을 고려해 보세요. 예약된 Auto Scaling에서는 테이블에 애플리케이션 Auto Scaling 규칙을 구성하면서도 필요한 특정 간격으로만 추가 용량을 프로비저닝하는 덜 적극적인 대상 사용률을 적용할 수 있습니다.

AWS CLI를 통해 다음 단계를 실행하여 시간과 요일을 기준으로 실행되는 예약된 Auto Scaling 규칙을 생성할 수 있습니다.

1. Application Auto Scaling을 사용하여 DynamoDB 테이블 또는 GSI를 확장 가능한 목표로 등록하세요. 확장 가능한 목표란 Application Auto Scaling이 스케일 아웃 또는 스케일 인할 수 있는 리소스입니다.

   ```
   aws application-autoscaling register-scalable-target \
       --service-namespace dynamodb \
       --scalable-dimension dynamodb:table:WriteCapacityUnits \
       --resource-id table/<table-name> \
       --min-capacity 90 \
       --max-capacity 1500
   ```

1. 요구 사항에 따라 예약된 작업 설정

   시나리오를 다루려면 두 가지 규칙이 필요합니다. 하나는 스케일 업 규칙이고 다른 하나는 스케일 다운 규칙입니다. 예약된 작업을 스케일 업하기 위한 첫 번째 규칙:

   ```
   aws application-autoscaling put-scheduled-action \
       --service-namespace dynamodb \
       --scalable-dimension dynamodb:table:WriteCapacityUnits \
       --resource-id table/<table-name> \
       --scheduled-action-name my-8-5-scheduled-action \
       --scalable-target-action MinCapacity=800,MaxCapacity=1500 \
       --schedule "cron(45 8 ? * MON-FRI *)" \
       --timezone "Australia/Brisbane"
   ```

   예약된 작업을 스케일 다운하기 위한 첫 번째 규칙:

   ```
   aws application-autoscaling put-scheduled-action \
       --service-namespace dynamodb \
       --scalable-dimension dynamodb:table:WriteCapacityUnits \
       --resource-id table/<table-name> \
       --scheduled-action-name my-5-8-scheduled-down-action \
       --scalable-target-action MinCapacity=90,MaxCapacity=1500 \
       --schedule "cron(15 17 ? * MON-FRI *)" \
       --timezone "Australia/Brisbane"
   ```

1. 다음 명령을 실행하여 두 규칙이 모두 활성화되었는지 확인합니다.

   ```
   aws application-autoscaling describe-scheduled-actions --service-namespace dynamodb
   ```

   다음과 같은 결과가 나와야 합니다.

   ```
   {
       "ScheduledActions": [
           {
               "ScheduledActionName": "my-5-8-scheduled-down-action",
               "ScheduledActionARN": "arn:aws:autoscaling:<region>:<account>:scheduledAction:<uuid>:resource/dynamodb/table/<table-name>:scheduledActionName/my-5-8-scheduled-down-action",
               "ServiceNamespace": "dynamodb",
               "Schedule": "cron(15 17 ? * MON-FRI *)",
               "Timezone": "Australia/Brisbane",
               "ResourceId": "table/<table-name>",
               "ScalableDimension": "dynamodb:table:WriteCapacityUnits",
               "ScalableTargetAction": {
                   "MinCapacity": 90,
                   "MaxCapacity": 1500
               },
               "CreationTime": "2022-03-15T17:30:25.100000+10:00"
           },
           {
               "ScheduledActionName": "my-8-5-scheduled-action",
               "ScheduledActionARN": "arn:aws:autoscaling:<region>:<account>:scheduledAction:<uuid>:resource/dynamodb/table/<table-name>:scheduledActionName/my-8-5-scheduled-action",
               "ServiceNamespace": "dynamodb",
               "Schedule": "cron(45 8 ? * MON-FRI *)",
               "Timezone": "Australia/Brisbane",
               "ResourceId": "table/<table-name>",
               "ScalableDimension": "dynamodb:table:WriteCapacityUnits",
               "ScalableTargetAction": {
                   "MinCapacity": 800,
                   "MaxCapacity": 1500
               },
               "CreationTime": "2022-03-15T17:28:57.816000+10:00"
           }
       ]
   }
   ```

다음 그림은 항상 70% 목표 사용률을 유지하는 샘플 워크로드를 보여 줍니다. Auto Scaling 규칙이 여전히 적용되고 있으며 처리량은 감소하지 않는다는 점에 유의하세요.

![\[Auto Scaling 규칙이 용량을 조정하더라도 테이블의 처리량은 목표 사용률의 70%입니다.\]](http://docs.aws.amazon.com/ko_kr/amazondynamodb/latest/developerguide/images/CostOptimization/AutoScalingSettings3.png)


자세히 보면 애플리케이션에 급증이 발생하여 70% 오토 스케일링 임곗값이 트리거되고, 오토 스케일링이 강제로 시작되어 테이블에 필요한 추가 용량을 제공하는 것을 볼 수 있습니다. 예약된 Auto Scaling 작업은 최대값과 최소값에 영향을 미치며 이를 설정하는 것은 사용자의 책임입니다.

![\[필요한 추가 용량을 제공하기 위해 Auto Scaling을 시작하는 DynamoDB 테이블 처리량 급증.\]](http://docs.aws.amazon.com/ko_kr/amazondynamodb/latest/developerguide/images/CostOptimization/AutoScalingSettings4.png)


![\[DynamoDB 테이블의 Auto Scaling 구성: 목표 사용률과 최소 및 최대 용량 값.\]](http://docs.aws.amazon.com/ko_kr/amazondynamodb/latest/developerguide/images/CostOptimization/AutoScalingSettings5.png)


## 알 수 없는 패턴으로 급증하는 워크로드를 해결하는 방법
<a name="CostOptimization_AutoScalingSettings_UnknownPatterns"></a>

이 시나리오에서는 애플리케이션 패턴을 아직 모르고 워크로드에 제한이 발생하지 않도록 하기 위해 애플리케이션이 매우 낮은 사용률 목표를 사용합니다.

대신 [온디맨드 용량 모드를](capacity-mode.md#capacity-mode-on-demand) 사용하는 것을 고려해 봅니다. 온디맨드 테이블은 트래픽 패턴을 모르는 급증하는 워크로드에 적합합니다. 온디맨드 용량 모드를 사용하면 애플리케이션이 테이블에서 수행하는 데이터 읽기 및 쓰기에 대해 요청당 요금을 지불합니다. DynamoDB는 늘어나거나 줄어드는 워크로드를 즉시 수용하기 때문에 애플리케이션에서 수행할 것으로 예상되는 읽기 및 쓰기 처리량을 지정할 필요가 없습니다.

## 연결된 애플리케이션으로 워크로드를 해결하는 방법
<a name="CostOptimization_AutoScalingSettings_BetweenRanges"></a>

이 시나리오에서 애플리케이션은 다른 시스템에 의존합니다. 예를 들어 애플리케이션 로직의 이벤트에 따라 트래픽이 크게 급증할 수 있는 일괄 처리 시나리오가 이에 해당합니다.

이러한 이벤트에 대응하여 특정 요구 사항에 따라 테이블 용량 및 `TargetValues`를 늘릴 수 있는 사용자 지정 Auto Scaling 로직을 개발하는 것을 고려해 보세요. Amazon EventBridge를 활용하고 Lambda 및 Step Functions와 같은 AWS 서비스의 조합을 사용하여 특정 애플리케이션 요구 사항에 대응할 수 있습니다.