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