# DynamoDB テーブルの自動スケーリング設定を評価する
このセクションでは、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 設定について
ターゲット使用率、初期ステップ、最終値の正しい値を定義するには、運用チームの関与が必要です。これにより、AWS Auauto Scaling ポリシーのトリガーに使用されるアプリケーションの使用履歴に基づいて値を適切に定義することができます。ターゲット使用率は、Auto Scaling ルールが適用される前の期間に達成する必要がある合計キャパシティの割合です。
**高いターゲット使用率 (90% 前後)** を設定すると、Auto Scaling が起動する前に、一定期間トラフィックが 90% を超える必要があります。アプリケーションが常に一定で、トラフィックが急増しない場合を除いて、高いターゲット使用率を使用しないでください。
非常に**低い使用率 (50% 未満)** を設定する場合は、アプリケーションが Auto Scaling ポリシーをトリガーする前に、プロビジョニングされたキャパシティの 50% に達する必要があります。アプリケーショントラフィックが非常に速い速度で増加しない限り、これは通常、キャパシティの未使用およびリソースの浪費につながります。
## 目標使用率が低い (50% 未満） テーブルを特定する方法
AWS CLI または AWS マネジメントコンソール を使用して、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/”
```
1. 特定の GSI の Auto Scaling ポリシーのみを返すには、次のコマンドを実行します。
```
aws application-autoscaling describe-scaling-policies --service-namespace dynamodb --resource-id "table//index/”
```
Auto Scaling ポリシーで注目している値は以下のとおりです。オーバープロビジョニングを避けるため、ターゲット値を 50% 以上に設定したいと考えています。次のような結果を取得します。
```
{
"ScalingPolicies": [
{
"PolicyARN": "arn:aws:autoscaling:::scalingPolicy::resource/dynamodb/table//index/:policyName/$-scaling-policy",
"PolicyName": $”,
"ServiceNamespace": "dynamodb",
"ResourceId": "table//index/",
"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:::scalingPolicy::resource/dynamodb/table//index/:policyName/$-scaling-policy",
"PolicyName":$”,
"ServiceNamespace": "dynamodb",
"ResourceId": "table//index/",
"ScalableDimension": "dynamodb:index:ReadCapacityUnits",
"PolicyType": "TargetTrackingScaling",
"TargetTrackingScalingPolicyConfiguration": {
"TargetValue": 70.0,
"PredefinedMetricSpecification": {
"PredefinedMetricType": "DynamoDBReadCapacityUtilization"
}
},
"Alarms": [
...
],
"CreationTime": "2022-03-04T16:23:47.820000+10:00"
}
]
}
```
------
#### [ AWS マネジメントコンソール ]
1. AWS マネジメントコンソール にサインインして DynamoDB コンソール ([https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/)) を開きます。
必要に応じて、適切な AWS リージョン を選択します。
1. 左のナビゲーションバーで、[**Tables (テーブル)**] を選択します。[**Tables (テーブル)**] ページで、テーブルの [**Name (名)**] を選択します。
1. *[テーブルの詳細]* ページで **[追加の設定]** を選択して、テーブルの Auto Scaling 設定を確認します。
![\[Auto Scaling 設定を含む DynamoDB のテーブルの詳細ページ。プロビジョニングされたキャパシティの使用率を確認して、必要に応じて調整します。\]](http://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/images/CostOptimization/AutoScalingSettings1.png)
インデックスの場合は、**[インデックスキャパシティー]** セクションを展開して、インデックスの Auto Scaling 設定を確認します。
![\[DynamoDB コンソールの [インデックスキャパシティー] セクション。インデックスの自動スケーリング設定を確認して管理します。\]](http://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/images/CostOptimization/AutoScalingSettings2.png)
------
目標使用率が 50% 以下の場合は、テーブルの使用率メトリクスを調べて、[プロビジョニングが不十分か過剰か](CostOptimization_RightSizedProvisioning.md)を確認する必要があります。
## 季節変動のあるワークロードに対処する方法
次のシナリオを考えてみましょう。アプリケーションはほとんどの場合最小平均値で動作していますが、目標使用率は低いため、アプリケーションは 1 日の特定の時間に発生するイベントに迅速に対応でき、十分なキャパシティがあり、スロットリングを回避できます。これは、アプリケーションが通常の勤務時間 (午前 9 時～午後 5 時) には非常にビジーで、勤務時間外には基本的なレベルで動作する場合に一般的なシナリオです。一部のユーザーは午前 9 時前に接続を開始するため、アプリケーションはこの低いしきい値を使用して、ピーク時に*必要な*キャパシティに達するようにすばやく拡張します。
このシナリオは次のようなものです。
+ 午後 5 時から午前 9 時までの間、`ConsumedWriteCapacity` ユニットの単位は 90 から 100 の間にとどまる
+ ユーザーが午前 9 時前にアプリケーションに接続し始めると、キャパシティユニットが大幅に増加する (最大値は 1500 WCU)
+ 勤務時間中のアプリケーション使用量は、平均して 800～1,200 の間で推移する
前述のシナリオが当てはまる場合は、[スケジュールされた Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/examples-scheduled-actions.html) の使用を検討してください。この場合、テーブルにはアプリケーションの Auto Scaling ルールを設定できますが、ターゲット使用率はそれほど高くなく、必要な間隔で追加のキャパシティのみをプロビジョニングできます。
AWS CLI を使用して以下の手順を実行し、時間帯と曜日に基づいて実行されるスケジュールされた Auto Scaling ルールを作成することができます。
1. DynamoDB テーブルまたは GSI をスケーラブルなターゲットとして Application Auto Scaling に登録します。スケーラブルなターゲットは、Application Auto Scaling でスケールアウトまたはスケールインできるリソースです。
```
aws application-autoscaling register-scalable-target \
--service-namespace dynamodb \
--scalable-dimension dynamodb:table:WriteCapacityUnits \
--resource-id table/ \
--min-capacity 90 \
--max-capacity 1500
```
1. 要件に従ってスケジュールされたアクションをセットアップします。
このシナリオに対応するには、2 つのルールが必要です。1 つはスケールアップ用、もう 1 つはスケールダウン用です。スケジュールされたアクションをスケールアップするための最初のルール:
```
aws application-autoscaling put-scheduled-action \
--service-namespace dynamodb \
--scalable-dimension dynamodb:table:WriteCapacityUnits \
--resource-id table/ \
--scheduled-action-name my-8-5-scheduled-action \
--scalable-target-action MinCapacity=800,MaxCapacity=1500 \
--schedule "cron(45 8 ? * MON-FRI *)" \
--timezone "Australia/Brisbane"
```
スケジュールされたアクションをスケールダウンするための 2 つ目のルール:
```
aws application-autoscaling put-scheduled-action \
--service-namespace dynamodb \
--scalable-dimension dynamodb:table:WriteCapacityUnits \
--resource-id table/ \
--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:::scheduledAction::resource/dynamodb/table/:scheduledActionName/my-5-8-scheduled-down-action",
"ServiceNamespace": "dynamodb",
"Schedule": "cron(15 17 ? * MON-FRI *)",
"Timezone": "Australia/Brisbane",
"ResourceId": "table/",
"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:::scheduledAction::resource/dynamodb/table/:scheduledActionName/my-8-5-scheduled-action",
"ServiceNamespace": "dynamodb",
"Schedule": "cron(45 8 ? * MON-FRI *)",
"Timezone": "Australia/Brisbane",
"ResourceId": "table/",
"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/ja_jp/amazondynamodb/latest/developerguide/images/CostOptimization/AutoScalingSettings3.png)
拡大すると、アプリケーションにスパイクが発生して自動スケーリングのしきい値が 70% に達し、自動スケーリングが強制的に開始され、テーブルに必要な追加キャパシティが提供されたことがわかります。スケジュールされた Auto Scaling アクションは最大値と最小値に影響するので、設定するのはユーザーの責任です。
![\[必要な追加キャパシティを提供するために Auto Scaling を開始する DynamoDB テーブルスループットのスパイク。\]](http://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/images/CostOptimization/AutoScalingSettings4.png)
![\[DynamoDB テーブルの Auto Scaling 設定: ターゲット使用率とキャパシティの最小値および最大値。\]](http://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/images/CostOptimization/AutoScalingSettings5.png)
## パターンが不明な急増するワークロードに対処する方法
このシナリオでは、アプリケーションのパターンがまだわからないため、アプリケーションのターゲット使用率が非常に低く、ワークロードがスロットリングされないようにする必要があります。
代わりに[オンデマンドキャパシティモード](capacity-mode.md#capacity-mode-on-demand)を使用することを検討してください。オンデマンドテーブルは、トラフィックパターンが不明で急増するワークロードに最適です。オンデマンドキャパシティモードでは、アプリケーションがテーブルに対して実行するデータの読み取りと書き込みに対して、リクエストごとに料金を支払います。DynamoDB はワークロードの増減に即座に対応するため、アプリケーションに期待する読み取りと書き込みのスループットを指定する必要はありません。
## リンクされたアプリケーションのワークロードに対応する方法
このシナリオでは、アプリケーションは他のシステムに依存します。例えば、バッチ処理シナリオでは、アプリケーションロジックのイベントに応じてトラフィックが大幅に急増する可能性があります。
特定のニーズに応じてテーブルのキャパシティと `TargetValues` を増やすことができる、これらのイベントに反応するカスタムの Auto Scaling ロジックの開発を検討してください。Amazon EventBridge のメリットを得たり、Lambda や Step Functions のような AWS を組み合わせることで、特定のアプリケーションのニーズに対応することができます。