翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# テーブルの Application Auto Scaling 設定を評価する
このセクションでは、Amazon Keyspaces テーブルの Application Auto Scaling 設定を評価する方法を概説します。[Amazon Keyspaces Application Auto Scaling](autoscaling.md) は、アプリケーショントラフィックと目標使用率メトリクスに基づいてテーブルのスループットを管理する機能です。これにより、テーブルがアプリケーションパターンに必要なキャパシティを確保できます。
Application Auto Scaling サービスは現在のテーブル使用率をモニタリングし、目標使用率値である `TargetValue` と比較します。割り当てられたキャパシティを増減する時期になると、通知されます。
**Topics**
+ [Application Auto Scaling 設定の理解](#CostOptimization_AutoScalingSettings_UnderProvisionedTables)
+ [目標使用率が低い (50% 未満） テーブルを特定する方法](#CostOptimization_AutoScalingSettings_IdentifyLowUtilization)
+ [季節変動のあるワークロードに対処する方法](#CostOptimization_AutoScalingSettings_SeasonalVariance)
+ [パターンが不明な急増するワークロードに対処する方法](#CostOptimization_AutoScalingSettings_UnknownPatterns)
+ [リンクされたアプリケーションのワークロードに対応する方法](#CostOptimization_AutoScalingSettings_BetweenRanges)
## Application Auto Scaling 設定の理解
目標使用率、初期ステップ、最終値の正しい値を定義するには、運用チームの関与が必要です。これにより、Application Auto Scaling ポリシーのトリガーに使用されるアプリケーションの使用履歴に基づいて値を適切に定義することができます。目標使用率は、Application Auto Scaling ルールが適用される前の期間に達成する必要がある合計キャパシティの割合です。
**高い目標使用率 (90% 前後) **を設定するときは、Application Auto Scaling が起動する前に、一定期間、トラフィックが 90% を超える必要があります。アプリケーションが常に一定で、トラフィックが急増しない場合を除いて、高い目標使用率を使用しないでください。
非常に**低い使用率 (50% 未満) **を設定する場合は、アプリケーションが Application Auto Scaling ポリシーをトリガーする前に、プロビジョニングされたキャパシティの 50% に達する必要があります。アプリケーショントラフィックが非常に速い速度で増加しない限り、これは通常、キャパシティの未使用およびリソースの浪費につながります。
## 目標使用率が低い (50% 未満） テーブルを特定する方法
AWS CLI または のいずれかを使用して AWS マネジメントコンソール 、Amazon Keyspaces リソース内の Application Auto Scaling ポリシー`TargetValues`の をモニタリングおよび識別できます。
**注記**
プロビジョンドキャパシティモードのマルチリージョンテーブルで Amazon Keyspaces 自動スケーリングを有効にする場合は、Amazon Keyspaces の API オペレーションを使用して自動スケーリングを設定してください。Amazon Keyspaces で自動的に呼び出される基盤の Application Auto Scaling API オペレーションには、マルチリージョンの機能がありません。詳細については、「[Amazon Keyspaces でマルチリージョンテーブルのプロビジョンドキャパシティと自動スケーリングの設定を表示する](tables-mrr-view.md)」を参照してください。
------
#### [ AWS CLI ]
1. リソースのリスト全体を返すには、次のコマンドを実行します。
```
aws application-autoscaling describe-scaling-policies --service-namespace cassandra
```
このコマンドでは、すべての Amazon Keyspaces リソースに発行された Application Auto Scaling ポリシーのリスト全体が返ります。特定のテーブルからのみリソースを取得する場合は、`–resource-id parameter` を追加できます。例えば、次のようになります。
```
aws application-autoscaling describe-scaling-policies --service-namespace cassandra --resource-id "keyspace/keyspace-name/table/table-name”
```
1. 特定のテーブルの Auto Scaling ポリシーのみを返すには、次のコマンドを実行します。
```
aws application-autoscaling describe-scaling-policies --service-namespace cassandra --resource-id "keyspace/keyspace-name/table/table-name”
```
Application Auto Scaling ポリシーで求める値は以下のとおりです。たとえば、オーバープロビジョニングを避けるため、目標値を 50% 以上に設定しようと考えているとします。次のような結果を取得します。
```
{
"ScalingPolicies": [
{
"PolicyARN": "arn:aws:autoscaling:us-east-1:111122223333:scalingPolicy::resource/keyspaces/table/table-name-scaling-policy",
"PolicyName": $”,
"ServiceNamespace": "cassandra",
"ResourceId": "keyspace/keyspace-name/table/table-name",
"ScalableDimension": "cassandra:table:WriteCapacityUnits",
"PolicyType": "TargetTrackingScaling",
"TargetTrackingScalingPolicyConfiguration": {
"TargetValue": 70.0,
"PredefinedMetricSpecification": {
"PredefinedMetricType": "KeyspacesWriteCapacityUtilization"
}
},
"Alarms": [
...
],
"CreationTime": "2022-03-04T16:23:48.641000+10:00"
},
{
"PolicyARN": "arn:aws:autoscaling:us-east-1:111122223333:scalingPolicy::resource/keyspaces/table/table-name-scaling-policy",
"PolicyName":$”,
"ServiceNamespace": "cassandra",
"ResourceId": "keyspace/keyspace-name/table/table-name",
"ScalableDimension": "cassandra:table:ReadCapacityUnits",
"PolicyType": "TargetTrackingScaling",
"TargetTrackingScalingPolicyConfiguration": {
"TargetValue": 70.0,
"PredefinedMetricSpecification": {
"PredefinedMetricType": "KeyspacesReadCapacityUtilization"
}
},
"Alarms": [
...
],
"CreationTime": "2022-03-04T16:23:47.820000+10:00"
}
]
}
```
------
#### [ AWS マネジメントコンソール ]
1. にログイン AWS マネジメントコンソール し、 [の開始方法 AWS マネジメントコンソール](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/getting-started.html)の CloudWatch サービスページに移動します。 AWS リージョン 必要に応じて適切な を選択します。
1. 左のナビゲーションバーで、[**Tables (テーブル)**] を選択します。[**Tables (テーブル)**] ページで、テーブルの [**Name (名)**] を選択します。
1. [**Capacity (キャパシティ)**] タブの [**Table Details (テーブルの詳細)**] ページで、テーブルの Application Auto Scaling 設定を確認します。
------
目標使用率が 50% 以下の場合は、テーブルの使用率メトリクスを調べて、[プロビジョニングが不十分か過剰か](CostOptimization_RightSizedProvisioning.md)を確認する必要があります。
## 季節変動のあるワークロードに対処する方法
次のシナリオを考えてみましょう。アプリケーションはほとんどの場合最小平均値で動作していますが、目標使用率は低いため、アプリケーションは 1 日の特定の時間に発生するイベントに迅速に対応でき、十分なキャパシティがあり、スロットリングを回避できます。これは、アプリケーションが通常の勤務時間 (午前 9 時～午後 5 時) には非常にビジーで、勤務時間外には基本的なレベルで動作する場合に一般的なシナリオです。一部のユーザーは午前 9 時前に接続を開始するため、アプリケーションはこの低いしきい値を使用しますが、ピーク時には*必要な*キャパシティに対応して迅速に増加します。
このシナリオは次のようなものです。
+ 午後 5 時から午前 9 時までの間、`ConsumedWriteCapacityUnits` ユニットの単位は 90 から 100 の間にとどまる
+ ユーザーが午前 9 時前にアプリケーションに接続し始めると、キャパシティユニットが大幅に増加する (最大値は 1500 WCU)
+ 勤務時間中のアプリケーション使用量は、平均して 800～1,200 の間で推移する
前述のシナリオがアプリケーションに当てはまる場合は、[スケジュールした Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/examples-scheduled-actions.html) の使用を検討してください。この場合、テーブルにはアプリケーションの Application Auto Scaling ルールを設定できますが、目標使用率はそれほど高くなく、必要な間隔で追加のキャパシティのみをプロビジョニングできます。
を使用して次のステップ AWS CLI を実行し、時刻と曜日に基づいて実行されるスケジュールされた自動スケーリングルールを作成できます。
1. Application Auto Scalingで Amazon Keyspaces テーブルをスケーラブルな目標として登録します。スケーラブルな目標は、 Application Auto Scaling によるスケールアウトやスケールインが可能なリソースです。
```
aws application-autoscaling register-scalable-target \
--service-namespace cassandra \
--scalable-dimension cassandra:table:WriteCapacityUnits \
--resource-id keyspace/keyspace-name/table/table-name \
--min-capacity 90 \
--max-capacity 1500
```
1. 要件に従ってスケジュールされたアクションをセットアップします。
このシナリオに対応するには、2 つのルールが必要です。1 つはスケールアップ用、もう 1 つはスケールダウン用です。スケジュールしたアクションをスケールアップするための最初のルールを次の例で示します。
```
aws application-autoscaling put-scheduled-action \
--service-namespace cassandra \
--scalable-dimension cassandra:table:WriteCapacityUnits \
--resource-id keyspace/keyspace-name/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"
```
スケジュールされたアクションをスケールダウンするための 2 つ目のルールを次の例で示します。
```
aws application-autoscaling put-scheduled-action \
--service-namespace cassandra \
--scalable-dimension cassandra:table:WriteCapacityUnits \
--resource-id keyspace/keyspace-name/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 cassandra
```
次のような結果が表示されます。
```
{
"ScheduledActions": [
{
"ScheduledActionName": "my-5-8-scheduled-down-action",
"ScheduledActionARN": "arn:aws:autoscaling:us-east-1:111122223333:scheduledAction::resource/keyspaces/table/table-name:scheduledActionName/my-5-8-scheduled-down-action",
"ServiceNamespace": "cassandra",
"Schedule": "cron(15 17 ? * MON-FRI *)",
"Timezone": "Australia/Brisbane",
"ResourceId": "keyspace/keyspace-name/table/table-name",
"ScalableDimension": "cassandra: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:us-east-1:111122223333:scheduledAction::resource/keyspaces/table/table-name:scheduledActionName/my-8-5-scheduled-action",
"ServiceNamespace": "cassandra",
"Schedule": "cron(45 8 ? * MON-FRI *)",
"Timezone": "Australia/Brisbane",
"ResourceId": "keyspace/keyspace-name/table/table-name",
"ScalableDimension": "cassandra:table:WriteCapacityUnits",
"ScalableTargetAction": {
"MinCapacity": 800,
"MaxCapacity": 1500
},
"CreationTime": "2022-03-15T17:28:57.816000+10:00"
}
]
}
```
次の図は、常に 70% の目標使用率を維持するサンプルワークロードを示しています。オートスケーリングルールが適用され、スループットが低下していないことがわかりますか。
![\[書き込み使用量を 1 秒あたりのユニット数で示したグラフ。1 日間の期間にわたって、プロビジョニング済みのキャパシティと実際のキャパシティ消費量を比較しています。\]](http://docs.aws.amazon.com/ja_jp/keyspaces/latest/devguide/images/CostOptimization/AutoScalingSettings3.png)
拡大すると、アプリケーションにスパイクが発生して Auto Scaling のしきい値が 70% に達し、Auto Scaling が強制的に開始され、テーブルに必要な追加キャパシティが提供されたことがわかります。スケジュールされた自動スケーリングアクションは最大値と最小値に影響するため、それらの値を設定しておくのはユーザーの責任です。
![\[プロビジョニング済みキャパシティと実際のキャパシティ消費量を比較した書き込み使用量 (1 秒あたりのユニット数) のグラフをさらに詳しく表示した画面。特定の期間を拡大表示しています。\]](http://docs.aws.amazon.com/ja_jp/keyspaces/latest/devguide/images/CostOptimization/AutoScalingSettings4.png)
![\[1 日間の期間にわたってプロビジョニング済みキャパシティと実際のキャパシティ消費量を比較した書き込み使用量 (1 秒あたりのユニット数) のグラフの詳細表示画面。\]](http://docs.aws.amazon.com/ja_jp/keyspaces/latest/devguide/images/CostOptimization/AutoScalingSettings5.png)
## パターンが不明な急増するワークロードに対処する方法
このシナリオでは、アプリケーションのパターンがまだわからないため、アプリケーションの目標使用率が非常に低く、ワークロードに低いキャパシティスループットエラーが生じないようにする必要があります。
代わりに[オンデマンドキャパシティモード](ReadWriteCapacityMode.OnDemand.md)を使用することを検討してください。オンデマンドテーブルは、トラフィックパターンが不明で急増するワークロードに最適です。オンデマンドキャパシティモードでは、アプリケーションがテーブルに対して実行するデータの読み取りと書き込みに対して、リクエストごとに料金を支払います。Amazon Keyspaces はワークロードの増減に即座に対応するため、アプリケーションに期待する読み取りと書き込みのスループットを指定する必要はありません。
## リンクされたアプリケーションのワークロードに対応する方法
このシナリオでは、アプリケーションは他のシステムに依存します。例えば、バッチ処理シナリオでは、アプリケーションロジックのイベントに応じてトラフィックが大幅に急増する可能性があります。
特定のニーズに応じてテーブルのキャパシティと `TargetValues` を増やすことができる、これらのイベントに反応するカスタムの Application Auto Scaling ロジックの開発を検討してください。Λ Amazon EventBridge や Step Functions などの AWS サービスを組み合わせて使用することで、特定のアプリケーションのニーズに対応できます。