# DynamoDB テーブルで適切なサイズのプロビジョニングを行うために、プロビジョンドキャパシティを評価する
このセクションでは、DynamoDB テーブルのプロビジョニングが適切なサイズであるかどうかを評価する方法の概要を説明します。ワークロードの変化に応じて、運用手順を適切に変更する必要があります。特に DynamoDB テーブルがプロビジョニングモードで設定されていて、テーブルを過剰にプロビジョニングしたり、プロビジョニング不足になったりするリスクがある場合はそうです。
以下に説明する手順では、本稼働アプリケーションをサポートしている DynamoDB テーブルから取得する必要がある統計情報が必要です。アプリケーションの動作を理解するには、アプリケーションからのデータの季節性を把握するのに十分な期間を定義する必要があります。たとえば、アプリケーションに週単位のパターンが見られる場合は、3 週間の期間を使用することで、アプリケーションのスループットニーズを分析するための十分な余裕が得られます。
何から始めればよいかわからない場合は、以下の計算に少なくとも 1 か月分のデータ使用量を使用してください。
容量を評価する際、DynamoDB テーブルでは、**読み込みキャパシティユニット (RCU)** と**書き込みキャパシティユニット (WCU)** を個別に設定できます。テーブルにグローバルセカンダリインデックス (GSI) が設定されている場合は、そのテーブルが消費するスループットを指定する必要があります。これもベーステーブルの RCU や WCU から独立しています。
**注記**
ローカルセカンダリインデックス (LSI) はベーステーブルの容量を消費します。
**Topics**
+ [DynamoDB テーブルの消費メトリクスを取得する方法](#CostOptimization_RightSizedProvisioning_ConsumptionMetrics)
+ [プロビジョニング不足の DynamoDB テーブルを識別する方法](#CostOptimization_RightSizedProvisioning_UnderProvisionedTables)
+ [過剰にプロビジョニングされた DynamoDB テーブルを識別する方法](#CostOptimization_RightSizedProvisioning_OverProvisionedTables)
## DynamoDB テーブルの消費メトリクスを取得する方法
テーブルと GSI の容量を評価するには、次の CloudWatch メトリクスをモニタリングし、適切なディメンションを選択してテーブルまたは GSI 情報を取得します。
| 読み込みキャパシティユニット | 書き込みキャパシティユニット |
| --- | --- |
| `ConsumedReadCapacityUnits` | `ConsumedWriteCapacityUnits` |
| `ProvisionedReadCapacityUnits` | `ProvisionedWriteCapacityUnits` |
| `ReadThrottleEvents` | `WriteThrottleEvents` |
この操作は、AWS CLI または AWS マネジメントコンソール で実行できます。
------
#### [ AWS CLI ]
テーブル消費メトリクスを取得する前に、まず CloudWatch API を使用して履歴データポイントを取得する必要があります。
まず、`write-calc.json` と `read-calc.json` の 2 つのファイルを作成します。これらのファイルは、テーブルまたは GSI の計算を表します。下の表に示すように、一部のフィールドを環境に合わせて更新する必要があります。
| フィールド名 | 定義 | 例 |
| --- | --- | --- |
| | 分析するテーブルの名前 | サンプルテーブル |
| | ターゲット使用率の評価に使用する期間 (秒単位) | 1 時間の場合は 3600 と指定します |
| | ISO8601 形式で指定された評価間隔の開始 | 2022-02-21T23:00:00 |
| | ISO8601 形式で指定された評価間隔の終了 | 2022-02-22T06:00:00 |
書き込み計算ファイルに、指定された日付範囲の期間にプロビジョニングおよび消費された WCU の数が取得されます。また、分析に使用される使用率も生成されます。`write-calc.json` ファイルのすべての内容は以下のようになります。
```
{
"MetricDataQueries": [
{
"Id": "provisionedWCU",
"MetricStat": {
"Metric": {
"Namespace": "AWS/DynamoDB",
"MetricName": "ProvisionedWriteCapacityUnits",
"Dimensions": [
{
"Name": "TableName",
"Value": ""
}
]
},
"Period": ,
"Stat": "Average"
},
"Label": "Provisioned",
"ReturnData": false
},
{
"Id": "consumedWCU",
"MetricStat": {
"Metric": {
"Namespace": "AWS/DynamoDB",
"MetricName": "ConsumedWriteCapacityUnits",
"Dimensions": [
{
"Name": "TableName",
"Value": """
}
]
},
"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": "",
"EndTime": "",
"ScanBy": "TimestampDescending",
"MaxDatapoints": 24
}
```
読み込み計算ファイルにも同様のファイルを使用します。このファイルには、指定された日付範囲にプロビジョニングおよび消費された RCU の数が取得されます。`read-calc.json` ファイルの内容は以下のようになります。
```
{
"MetricDataQueries": [
{
"Id": "provisionedRCU",
"MetricStat": {
"Metric": {
"Namespace": "AWS/DynamoDB",
"MetricName": "ProvisionedReadCapacityUnits",
"Dimensions": [
{
"Name": "TableName",
"Value": ""
}
]
},
"Period": ,
"Stat": "Average"
},
"Label": "Provisioned",
"ReturnData": false
},
{
"Id": "consumedRCU",
"MetricStat": {
"Metric": {
"Namespace": "AWS/DynamoDB",
"MetricName": "ConsumedReadCapacityUnits",
"Dimensions": [
{
"Name": "TableName",
"Value": ""
}
]
},
"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": "",
"EndTime": "",
"ScanBy": "TimestampDescending",
"MaxDatapoints": 24
}
```
ファイルを作成したら、使用率データの取得を開始できます。
1. 書き込み使用率データを取得するには、次のコマンドを実行します。
```
aws cloudwatch get-metric-data --cli-input-json file://write-calc.json
```
1. 読み込み使用率データを取得するには、次のコマンドを実行します。
```
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` を変更する必要があるかもしれません。これは、1 時間あたり 1 データポイント、1 日あたり 24 データポイントに相当します。
------
#### [ AWS マネジメントコンソール ]
1. AWS マネジメントコンソール にログインして、CloudWatch サービスページに移動します。必要に応じて、適切な AWS リージョン を選択します。
1. 左側のナビゲーションバーの **[メトリクス]** セクションで、**[すべてのメトリクス]** を選択します。
1. これにより、2 つのパネルで構成されるダッシュボードが開きます。上のパネルにはグラフィックが表示され、下のパネルにはグラフ化するメトリクスが表示されます。**[DynamoDB]** を選択します。
1. **[テーブルメトリクス]** を選択します。これにより、現在のリージョンのテーブルが表示されます。
1. 検索ボックスを使用してテーブル名を検索し、書き込みオペレーションメトリクス (`ConsumedWriteCapacityUnits` および `ProvisionedWriteCapacityUnits`) を選択します。
**注記**
この例では書き込みオペレーションメトリクスについて説明していますが、これらの手順を使用して読み込みオペレーションメトリクスをグラフ化することもできます。
1. **[グラフ化したメトリクス (2)]** タブを選択して、式を変更します。デフォルトでは、CloudWatch はグラフの統計関数 **[平均]** を選択します。
![\[選択したグラフ化したメトリクスとデフォルトの統計関数 平均。\]](http://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/images/CostOptimization/RightSizedProvisioning1.png)
1. グラフ化された両方のメトリクスを選択した状態 (左側のチェックボックス) で、[**Add math (算術の追加)**] メニュー、[**Common (共通)**] の順に選択し、次に [**Percentage (パーセンテージ)**] 関数を選択します。この手順を 2 回繰り返します。
**[Percentage]** (パーセンテージ) 関数を初めて選択する場合:
![\[CloudWatch コンソール。グラフ化されたメトリクスに対して [パーセンテージ] 関数を選択します。\]](http://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/images/CostOptimization/RightSizedProvisioning2.png)
**[Percentage]** (パーセンテージ) 関数を 2 回目に選択する場合:
![\[CloudWatch コンソール。グラフ化されたメトリクスに対して [パーセンテージ] 関数を 2 回目に選択します。\]](http://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/images/CostOptimization/RightSizedProvisioning3.png)
1. この時点で、下部のメニューに 4 つのメトリクスが表示されているはずです。`ConsumedWriteCapacityUnits` の計算に取り掛かりましょう。一貫性を保つために、AWS CLI セクションで使用した名前と一致させる必要があります。**[m1 ID]** をクリックし、この値を **[ConsumedWCU]** に変更します。
![\[CloudWatch コンソール。m1 ID というグラフ化されたメトリクスの名前を consumedWCU に変更します。\]](http://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/images/CostOptimization/RightSizedProvisioning4.png)
**ConsumedWriteCapacityUnit** ラベルの名前を **consumedWCU** に変更します。
![\[ConsumedWriteCapacityUnit ラベルが付いたグラフ化されたメトリクスの名前を consumedWCU に変更します。\]](http://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/images/CostOptimization/RightSizedProvisioning5.png)
1. 統計を **Average** から **Sum** に変更します。このアクションにより、**ANOMALY\$1DETECTION\$1BAND** という名前の別のメトリクスが自動的に作成されます。この手順の対象範囲では、新しく生成された **[ad1 metric]** のチェックボックスをオフにして、これを無視します。
![\[CloudWatch コンソール。グラフ化されたメトリクスのドロップダウンリストで統計として [合計] を選択します。\]](http://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/images/CostOptimization/RightSizedProvisioning6.png)
![\[CloudWatch コンソール。ANOMALY_DETECTION_BAND メトリクスは、グラフ化されたメトリクスのリストから削除されます。\]](http://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/images/CostOptimization/RightSizedProvisioning7.png)
1. 手順 8 を繰り返して **m2 ID** の名前を **ProvisionedWCU** に変更します。統計は [**Average (平均)**] に設定したままにします。
![\[CloudWatch コンソール。m2 ID のグラフ化されたメトリクスの名前を provisionedWCU に変更します。\]](http://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/images/CostOptimization/RightSizedProvisioning8.png)
1. **[Expression1]** ラベルを選択し、値を **[m1]** に更新し、ラベルを **[Consumed WCUs]** に更新します。
**注記**
データを正しく視覚化するには、必ず **[m1]** (左側のチェックボックス) と **[ProvisionedWCU]** のみを選択してください。**[Details]** (詳細) をクリックし、数式を **[consumedWCU/PERIOD(consumedWCU)]**」に変更して、数式を更新します。このステップで別の **[ANOMALY\$1DETECTION\$1BAND]** メトリクスを生成することもありますが、この手順の範囲では無視できます。
![\[m1 と provisionedWCU を選択します。m1 の詳細が consumedWCU/PERIOD(consumedWCU) に更新されます。\]](http://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/images/CostOptimization/RightSizedProvisioning10.png)
1. これで 2 つのグラフィックができたはずです。1 つはテーブル上にプロビジョニングされた WCU を示し、もう 1 つは消費された WCU を示しています。グラフィックの形状は下の図と異なる場合がありますが、参考にしてください。
![\[プロットされたテーブルのプロビジョニングされた WCU と消費された WCU を示すグラフ。\]](http://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/images/CostOptimization/RightSizedProvisioning11.png)
1. Expression2 グラフィック (**e2**) を選択して、パーセンテージ数式を更新します。ラベルと ID の名前を **utilizationPercentage** に変更します。**100\$1(m1/provisionedWCU) **と一致するように数式の名前を変更します。
![\[CloudWatch コンソール。Expression2 のラベルと ID の名前を utilizationPercentage に変更します。\]](http://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/images/CostOptimization/RightSizedProvisioning12.png)
![\[CloudWatch コンソール。Expression2 のパーセント式を 100*(m1/provisionedWCU) に更新します。\]](http://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/images/CostOptimization/RightSizedProvisioning13.png)
1. 使用率パターンを視覚化するには、**utilizationPercentage** 以外のすべてのメトリクスのチェックボックスをオフにします。デフォルトの間隔は 1 分に設定されていますが、必要に応じて自由に変更できます。
![\[選択した時間間隔の utilizationPercentage メトリクスのグラフ。\]](http://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/images/CostOptimization/RightSizedProvisioning14.png)
こちらは、1 時間の拡大表示と長時間の表示です。使用率が 100% を超える間隔がいくつかあることがわかりますが、この特定のワークロードでは、使用率がゼロの間隔が長くなっています。
![\[長期間の使用パターン。使用率が 100% を超える期間とゼロの期間を示します。\]](http://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/images/CostOptimization/RightSizedProvisioning15.png)
この時点では、この例の写真とは異なる結果が得られるかもしれません。すべてはワークロードのデータ次第です。使用率が 100% を超える間隔では、スロットリングイベントが発生しやすくなります。DynamoDB には[バーストキャパシティ](burst-adaptive-capacity.md#burst-capacity)がありますが、バーストキャパシティが完了すると、100% を超えるものはすべてスロットリングされます。
------
## プロビジョニング不足の DynamoDB テーブルを識別する方法
ほとんどのワークロードでは、テーブルがプロビジョンドキャパシティの 80% 以上を絶えず消費している場合、そのテーブルはプロビジョニング不足と見なされます。
[バーストキャパシティ](burst-adaptive-capacity.md#burst-capacity)は DynamoDB の機能の 1 つで、お客様が当初のプロビジョニング量よりも多くの (表で定義されている 1 秒あたりのプロビジョニングスループットを超える) RCU/WCU を一時的に消費できるようにするものです。バーストキャパシティは、特別なイベントや使用量の急増によるトラフィックの急激な増加を吸収するために作成されました。このバーストキャパシティはいつまでも続くわけではありません。未使用の RCU と WCU がなくなると同時に、プロビジョニングされた容量よりも多くの容量を消費しようとすると、スロットリング状態になります。アプリケーショントラフィックの使用率が 80% に近づくと、スロットリングのリスクが大幅に高まります。
80% 使用率ルールは、データの季節性やトラフィックの増加によって異なります。次のシナリオを考えてみます。
+ 過去 12 か月間、トラフィックの使用率が約 90% で**安定**していれば、テーブルのキャパシティは適切であると言えます
+ アプリケーショントラフィックが 3 か月以内に毎月 8% の割合で**増加**した場合、100% に到達します
+ アプリケーショントラフィックが 4 か月余りで 5% の割合で**増加**している場合でも、100% に到達します
上記のクエリの結果から、使用率の全体像がわかります。これらを参考にして、必要に応じてテーブルのキャパシティを増やす方法を選択するのに役立つ他のメトリクス (月間または毎週の増加率など) をさらに評価してください。運用チームと協力して、ワークロードとテーブルに適したパーセンテージを定義してください。
データを毎日または毎週分析すると、データが歪んでしまう特別なシナリオがあります。例えば、季節性のアプリケーションで、勤務時間中に使用量が急増する (ただし、勤務時間外はほぼゼロになる) 場合は、[自動スケーリングをスケジュールして](https://docs.aws.amazon.com/autoscaling/application/userguide/examples-scheduled-actions.html)時間帯 (および曜日) を指定してプロビジョンドキャパシティを増やすと効果的です。繁忙期に対応できるように容量を増やすかわりに、季節性がそれほどない場合には、[DynamoDB テーブルの自動スケーリング](AutoScaling.md)設定を利用することもできます。
**注記**
ベーステーブルに DynamoDB Auto Scaling 設定を作成するときは、そのテーブルに関連付けられている GSI にも別の設定を含めることを忘れないでください。
## 過剰にプロビジョニングされた DynamoDB テーブルを識別する方法
上記のスクリプトから取得したクエリ結果から、初期分析を実行するために必要なデータポイントが得られます。データセットの使用率が複数の間隔で 20% 未満の値を示す場合は、テーブルが過剰にプロビジョニングされている可能性があります。WCU と RCU の数を減らす必要があるかどうかをさらに明確にするには、その間隔で他の測定値を見直す必要があります。
テーブルに使用頻度の低い間隔が複数ある場合は、自動スケーリングをスケジュールするか、使用率に基づくテーブルのデフォルトの自動スケーリングポリシーを設定することで、自動スケーリングポリシーの使用から大きなメリットが得られます。
使用率が低いのにスロットリング率 (間隔内の **Max(ThrottleEvents)/Min(ThrottleEvents)**) が高いワークロードがある場合、この現象は、ある日 (または時間) にトラフィックが大幅に増加するが一般的にトラフィックは常に少ない、非常にスパイクの多いワークロードがある場合に発生する可能性があります。このようなシナリオでは、[スケジュールされた自動スケーリング](https://docs.aws.amazon.com/autoscaling/application/userguide/examples-scheduled-actions.html)を使用すると有益な場合があります。