翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # Amazon Keyspaces テーブルのコスト最適化 このセクションでは、既存の Amazon Keyspaces テーブルのコストを最適化する方法のベストプラクティス説明します。次の戦略を見て、どのコスト最適化戦略がニーズに最も適しているかを確認し、それらに繰り返しアプローチする必要があります。各戦略では、コストに影響する可能性のある要素、コストを最適化する機会を探す方法、節約に役立つこれらのベストプラクティスの実装方法に関する規範的なガイダンスの概要を示します。 **Topics** + [テーブルレベルでコストを評価する](CostOptimization_TableLevelCostAnalysis.md) + [テーブルのキャパシティモードの評価](CostOptimization_TableCapacityMode.md) + [テーブルの Application Auto Scaling 設定を評価する](CostOptimization_AutoScalingSettings.md) + [未使用のリソースを特定して Amazon Keyspaces のコストを最適化する](CostOptimization_UnusedResources.md) + [テーブルの使用パターンを評価してパフォーマンスとコストを最適化する](CostOptimization_TableUsagePatterns.md) + [適切なサイズのプロビジョニングを行うために、プロビジョンドキャパシティを評価する](CostOptimization_RightSizedProvisioning.md) # テーブルレベルでコストを評価する 内にある Cost Explorer ツール AWS マネジメントコンソール を使用すると、読み取り、書き込み、ストレージ、バックアップ料金など、コストをタイプ別に分類して確認できます。また、これらのコストを月や日などの期間別にまとめて表示することもできます。 Cost Explorer のよくある課題の 1 つは、特定のテーブル単体のコストを簡単には確認できないことです。Cost Explorer では、特定のテーブルのコストだけをフィルタリングまたはグループ化して表示することができません。Amazon Keyspaces コンソールでは、テーブルごとの **[請求可能なテーブルサイズ (バイト)]** メトリクスを各テーブルの **[モニタリング]** タブで確認できます。テーブルごとのコスト関連情報がさらに必要な場合は、このセクションで紹介する方法で[タグ付け](tagging-keyspaces.md)を利用し、Cost Explorer で個々のテーブルのコスト分析を実行してください。 **Topics** + [1 つの Amazon Keyspaces テーブルのコストを表示する方法](#CostOptimization_TableLevelCostAnalysis_ViewInfo) + [Cost Explorer のデフォルトビュー](#CostOptimization_TableLevelCostAnalysis_CostExplorer) + [Cost Explorer でのテーブルタグの使用方法および適用方法](#CostOptimization_TableLevelCostAnalysis_Tagging) ## 1 つの Amazon Keyspaces テーブルのコストを表示する方法 Amazon Keyspaces テーブルに関する基本情報 (プライマリキースキーマ、請求可能なテーブルサイズ、キャパシティ関連のメトリクスなど) はコンソールで確認できます。テーブルのサイズから、そのテーブルの月々のストレージコストを計算できます。たとえば、米国東部 (バージニア北部) では、GB あたり 0.25 USD AWS リージョンです。 テーブルがプロビジョンドキャパシティモードの場合、現在のリードキャパシティユニット (RCU）とライトキャパシティユニット (WCU）の設定も返ります。この情報を基に、テーブルの現在の読み取りと書き込みのコストを計算できます。これらのコストは、テーブルに Amazon Keyspaces 自動スケーリングを設定している場合は特に、変動する可能性があります。 ## Cost Explorer のデフォルトビュー Cost Explorer のデフォルトビューには、スループットやストレージなど、消費されたリソースのコストを示すグラフが表示されます。月ごとや日ごとの合計など、期間ごとにこれらのコストをグループ化することを選択できます。ストレージ、読み取り、書き込み、その他のカテゴリーのコストも分類して比較できます。 ![\[Cost Explorer のビューで消費されたリソースのコストを表示した画像。\]](http://docs.aws.amazon.com/ja_jp/keyspaces/latest/devguide/images/CostOptimization/CostExplorerView.png) ## Cost Explorer でのテーブルタグの使用方法および適用方法 デフォルトでは、Cost Explorer は複数のテーブルのコストを合計するため、特定の 1 つのテーブルのコストの概要が表示されません。ただし、[AWS リソースへのタグ付け](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html)を使用すると、メタデータタグで各テーブルを識別できます。タグとは、プロジェクトや部門に属するすべてのリソースの識別など、さまざまな目的に使用できるキーと値のペアです。詳細については、「[Amazon Keyspaces リソースのタグとラベルを操作する](tagging-keyspaces.md)」を参照してください。 この例では、**MyTable** という名前のテーブルを使用します。 1. **table\$1name** のキーと **MyTable** の値を使用してタグを設定します。 1. [Cost Explorer 内でタグをアクティブ化し](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html)、タグ値でフィルタリングすると、各テーブルのコストをより明確に把握できます。 **注記** タグが Cost Explorer に表示され始めるまでには、1～2 日かかる場合があります。 メタデータタグは、コンソールで自分で設定することも、CQL、、 AWS CLIまたは AWS SDK を使用してプログラムで設定することもできます。組織の新しいテーブル作成プロセスの一環として、**table\$1name** タグの設定を義務付けることを検討してください。詳細については、「[タグを使用して Amazon Keyspaces のコスト配分レポートを作成する](CostAllocationReports.md)」を参照してください。 # テーブルのキャパシティモードの評価 このセクションでは、Amazon Keyspaces テーブルで、適切なキャパシティモードを選択する方法の概要を説明します。各モードは、スループットの変化に対する応答性や使用に対する請求方法という点で、さまざまなワークロードのニーズを満たすように調整されています。決定を下す際には、これらの要素のバランスを取る必要があります。 **Topics** + [利用可能なテーブルキャパシティモード](#CostOptimization_TableCapacityMode_Overview) + [オンデマンドキャパシティモードを選択する場合](#CostOptimization_TableCapacityMode_OnDemand) + [プロビジョンドキャパシティモードを選択する場合](#CostOptimization_TableCapacityMode_Provisioned) + [テーブルキャパシティモードを選択する際に考慮すべきその他の要素](#CostOptimization_TableCapacityMode_AdditionalFactors) ## 利用可能なテーブルキャパシティモード Amazon Keyspaces テーブルを作成するとき合、オンデマンドキャパシティモードとプロビジョンドキャパシティモードのいずれかを選択する必要があります。詳細については、「[Amazon Keyspaces で読み取り/書き込みのキャパシティモードを設定する](ReadWriteCapacityMode.md)」を参照してください。 **オンデマンドキャパシティモード** オンデマンドキャパシティモードでは、Amazon Keyspaces テーブルのキャパシティをプランニングまたはプロビジョニングする必要がありません。このモードでは、リクエストにテーブルが即座に対応します。いかなるリソースもスケールアップやスケールダウンの必要はありません (テーブルの過去のピークスループットの最大 2 倍まで対応可能)。 オンデマンドテーブルは、テーブルに対する実際のリクエスト数をカウントして請求されるため、お支払いいただくのは、プロビジョニングされたリクエスト数ではなく、実際に使用したリクエスト分のみです。 **プロビジョンドキャパシティモード** プロビジョンドキャパシティモードは従来型のモデルで、リクエストに対して利用できるテーブルのキャパシティを、直接、または Application Auto Scaling で定義できます。特定のキャパシティが指定された時間にテーブルにプロビジョニングされるため、請求はリクエスト数ではなく、プロビジョニングされたキャパシティに基づいて行われます。割り当てられたキャパシティを超えると、テーブルはリクエストを拒否し、アプリケーションのユーザーのエクスペリエンスが低下する可能性があります。 プロビジョンドキャパシティモードでは、テーブルをオーバープロビジョニングとアンダープロビジョニングの双方の間で調整して、スループットキャパシティエラーの発生率の軽減と、コスト最適化の両方を実現する必要があります。 ## オンデマンドキャパシティモードを選択する場合 コストを最適化する際、次のグラフに示すような想定外のワークロードがある場合は、オンデマンドモードが最適です。 この種のワークロードには、次のような要素が影響します。 + リクエストのタイミングが予測できない (トラフィックの急増につながる) + リクエストの量が変動する (バッチワークロードに起因) + 一定時間、ゼロまで低下する、またはピーク時の 18% を下回る (開発環境またはテスト環境に起因) ![\[トラフィックでピークがランダムに発生する、スパイキーなワークロードを示す画像。\]](http://docs.aws.amazon.com/ja_jp/keyspaces/latest/devguide/images/CostOptimization/TableCapacityModeOnDemand.png) 上記のような特性のワークロードでは、Application Auto Scaling を使用してテーブルがトラフィックの急増に対応できる十分なキャパシティを維持すると、望ましくない結果が生じるおそれがあります。その場合、テーブルの過剰なプロビジョニングによって必要以上のコストが発生するか、テーブルのプロビジョニングが不十分でリクエストに不必要な低キャパシティスループットエラーが発生するおそれがあります。このような場合は、オンデマンドテーブルの方が適しています。 オンデマンドテーブルはリクエストに応じて請求されるため、コスト最適化のためにテーブルレベルでこれ以上の対応は不要です。オンデマンドテーブルを定期的に評価して、ワークロードに上記の現象が引き続き残っていることを確認してください。ワークロードが安定したら、コスト最適化のためにプロビジョンドモードへの変更を検討してください。 ## プロビジョンドキャパシティモードを選択する場合 プロビジョンドキャパシティモードに最適なワークロードは、以下のグラフに示すように、使用パターンを予測しやすい場合です。 予測可能なワークロードには、次のような要素があります。 + 特定の時間または 1 日のトラフィックが予測可能/周期的 + トラフィックの急増が短期間で限定的 ![\[トラフィックのピークが限られていて、極めて予測可能なワークロードを示す画像。\]](http://docs.aws.amazon.com/ja_jp/keyspaces/latest/devguide/images/CostOptimization/TableCapacityModeProvisioned.png) 一定時間内または 1 日のトラフィック量が安定しているため、プロビジョンドキャパシティは、テーブルで実際に消費されるキャパシティに比較的近い値に設定できます。プロビジョンドキャパシティテーブルのコストの最適化は、最終的には、テーブル上で `ThrottledRequests` イベントを増やさずに、プロビジョンドキャパシティ (青色の線) を消費キャパシティ (オレンジ色の線) にできるだけ近づける練習になります。2 つの線の間にある空白は、未使用のキャパシティであると同時に、スループットキャパシティ不足エラーによるユーザーエクスペリエンスの低下に備えた保険にもなります。 Amazon Keyspaces は、Application Auto Scaling を備えており、あなたに代わって自動的にプロビジョンドキャパシティテーブルのバランスを調整してくれます。1 日を通して消費されたキャパシティを追跡し、いくつかの変数に基づいてテーブルのプロビジョンドキャパシティを設定できます。 **キャパシティユニットの最小数** テーブルの最小キャパシティを設定すると、スループットキャパシティ不足のエラーの発生を抑えることはできますが、これによってテーブルのコストが削減されるわけではありません。テーブルの使用量が少ない期間が続いた後に突然使用量が急増した場合、最小値を設定しておくと、Application Auto Scalingによって低すぎるテーブルキャパシティが設定されるのを防ぐことができます。 **キャパシティユニットの最大数** テーブルの最大キャパシティを設定すると、テーブルが意図したより大きくスケールしてしまうことを制限できます。大規模な負荷テストが望ましくない開発テーブルやテストテーブルには最大値の適用を検討してください。最大数はどのテーブルにも設定できますが、本番環境で使用する場合は、不意のスループットキャパシティ不足エラーを防ぐため、この設定はテーブルのベースラインと照らし合わせて定期的に評価してください。 **目標使用率** テーブルの目標使用率を設定することは、プロビジョンドキャパシティテーブルのコストを最適化するための主な手段です。ここでパーセント値を低く設定すると、テーブルでオーバープロビジョニングされるキャパシティ増により、コストが増加しますが、スループットキャパシティ不足エラーのリスクは軽減できます。パーセント値を高く設定すると、テーブルの過剰プロビジョニングの割合を軽減できますが、スループットキャパシティ不足エラーが発生するリスクが高まります。 ## テーブルキャパシティモードを選択する際に考慮すべきその他の要素 2 つのキャパシティモードのどちらかを選択する際には、考慮すべき点が他にもいくつかあります。 2 つのテーブルモードのどちらかを選択する際は、この追加の割引でテーブルのコストに与えられる影響を考慮してください。多くの場合、比較的予測が困難なワークロードでも、リザーブドキャパシティを利用すればオーバープロビジョニングされたプロビジョンドキャパシティテーブルで実行する方がコスト効率が良くなる場合があります。 **ワークロードの予測可能性の向上** 状況によっては、ワークロードに予測可能なパターンと予測不可能なパターンの両方があるように思われる場合があります。これはオンデマンドテーブルで簡単にサポートできますが、ワークロードの予測不可能なパターンを改善できれば、コストも低くなる可能性があります。 これらのパターンの最も一般的な原因の 1 つは、バッチインポートです。このタイプのトラフィックでは、ワークロードを実行するとスループットキャパシティ不足エラーが発生してしまうほど、テーブルのベースラインキャパシティを超えることがよくあります。このようなワークロードをプロビジョンドキャパシティテーブルで実行し続ける場合は、次のオプションを検討してください。 + 予定した時間にバッチが行われる場合は、バッチの実行前にアプリケーションオートスケーリングキャパシティを増やすようにスケジュールできます。 + バッチがランダムに行われる場合は、できるだけ速く実行することよりも、実行する時間を延長することを検討してください。 + Application Auto Scaling でテーブルキャパシティの調整を開始できるまで、低インポート速度で開始し、数分かけてゆっくりと速度を上げていくランプアップ時間をインポートに追加します。 # テーブルの 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 サービスを組み合わせて使用することで、特定のアプリケーションのニーズに対応できます。 # 未使用のリソースを特定して Amazon Keyspaces のコストを最適化する このセクションでは、未使用のリソースを定期的に評価する方法の概要を説明します。アプリケーションの要件が変化に対応できるよう、未使用のリソースの使用によって不要な Amazon Amazon Keyspaces のコストが生じないようにする必要があります。以下に説明する手順では、Amazon CloudWatch メトリクスで未使用のリソースを特定し、コストを削減する措置を講じます。 Amazon CloudWatch で Amazon Keyspaces をモニタリングすると、raw データが収集され、Amazon Keyspaces からほぼリアルタイムで読み取り可能なメトリクスに加工することができます。これらの統計は一定期間保持されるため、履歴情報にアクセスして使用率をより正確に調べることができます。デフォルトでは、 Amazon Keyspaces メトリクスデータは CloudWatch に自動的に送信されます。詳細については、「*Amazon CloudWatch ユーザーガイド*」の「[Amazon CloudWatch とは](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)」および「[メトリクスの保持](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#metrics-retention)」を参照してください。 **Topics** + [未使用のリソースを特定する方法](#CostOptimization_UnusedResources_Identifying) + [未使用のテーブルリソースを特定する](#CostOptimization_UnusedResources_Tables) + [未使用のテーブルリソースをクリーンアップする](#CostOptimization_UnusedResources_Tables_Cleanup) + [未使用のポイントインタイムリカバリ (PITR) バックアップのクリーンアップ](#CostOptimization_UnusedResources_Backups) ## 未使用のリソースを特定する方法 未使用のテーブルを特定するには、現在から30 日間の CloudWatch メトリクスを調べ、特定のテーブルに対してアクティブな読み込みまたは書き込みがあるかどうかを調べます。 **`ConsumedReadCapacityUnits`** 指定された期間に消費された読み込みキャパシティユニットの数。消費されたキャパシティの使用量を追跡できます。テーブルの読み取り消費キャパシティの合計を取得できます。 **`ConsumedWriteCapacityUnits`** 指定された期間に消費された書き込みキャパシティユニットの数。消費されたキャパシティの使用量を追跡できます。テーブルの書き込み消費キャパシティの合計を取得できます。 ## 未使用のテーブルリソースを特定する Amazon CloudWatch は、モニタリングサービスとオブザーバビリティサービスです。Amazon CloudWatch では、未使用のリソースを特定できる Amazon Keyspaces テーブルのメトリクスが得られます。CloudWatch メトリクスは、 AWS マネジメントコンソール と AWS Command Line Interfaceを使って表示できます。 ------ #### [ AWS Command Line Interface ] を使用してテーブルメトリクスを表示するには AWS Command Line Interface、次のコマンドを使用できます。 1. まず、テーブルの読み込みを評価します。 **注記** そのテーブル名がアカウント内で一意でない場合は、キー空間名も指定する必要があります。 ``` aws cloudwatch get-metric-statistics --metric-name ConsumedReadCapacityUnits --start-time --end-time --period --namespace AWS/Cassandra --statistics Sum -- dimensions Name=TableName,Value= ``` テーブルが未使用と誤って識別されないようにするには、長期間にわたってメトリクスの評価を行います。たとえば、**30 日間**と、適切な開始時刻と終了時刻の範囲、および **86400** などで適切な期間を選択します。 返されるデータで、[**合計**] が **0** を超える場合は、評価対象のテーブルがその期間に受信した読み込みトラフィックを示します。 次の結果は、評価期間中に読み込みトラフィックを受信したテーブルを示しています。 ``` { "Timestamp": "2022-08-25T19:40:00Z", "Sum": 36023355.0, "Unit": "Count" }, { "Timestamp": "2022-08-12T19:40:00Z", "Sum": 38025777.5, "Unit": "Count" }, ``` 次の結果は、評価期間中に読み込みトラフィックを受信しなかったテーブルを示しています。 ``` { "Timestamp": "2022-08-01T19:50:00Z", "Sum": 0.0, "Unit": "Count" }, { "Timestamp": "2022-08-20T19:50:00Z", "Sum": 0.0, "Unit": "Count" }, ``` 1. 次に、テーブルの書き込みを評価します。 ``` aws cloudwatch get-metric-statistics --metric-name ConsumedWriteCapacityUnits --start-time --end-time --period --namespace AWS/Cassandra --statistics Sum -- dimensions Name=TableName,Value= ``` テーブルが未使用と誤って識別されないようにするには、長期間にわたってメトリクスを評価する必要があります。**30 日間**などの適切な開始時刻と終了時刻の範囲、および **86400** などの適切な期間を選択します。 返されるデータで、[**Sum (合計)**] が **0** を超える場合は、評価対象のテーブルがその期間に受信した読み込みトラフィックを示します。 次の結果は、評価期間中に書き込みトラフィックを受信したテーブルを示しています。 ``` { "Timestamp": "2022-08-19T20:15:00Z", "Sum": 41014457.0, "Unit": "Count" }, { "Timestamp": "2022-08-18T20:15:00Z", "Sum": 40048531.0, "Unit": "Count" }, ``` 次の結果は、評価期間中に書き込みトラフィックを受信しなかったテーブルを示しています。 ``` { "Timestamp": "2022-07-31T20:15:00Z", "Sum": 0.0, "Unit": "Count" }, { "Timestamp": "2022-08-19T20:15:00Z", "Sum": 0.0, "Unit": "Count" }, ``` ------ #### [ AWS マネジメントコンソール ] 次のステップでは、 AWS マネジメントコンソールでリソースの使用率を評価します。 1. にログイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) の CloudWatch サービスページに移動します。必要に応じて、コンソールの右上 AWS リージョン にある適切な を選択します。 1. 左のナビゲーションバーで、[**メトリクス**] セクションを探し、[**すべてのメトリクス**] を選択します。 1. これにより、2 つのパネルで構成されるダッシュボードが開きます。上部のパネルには、現在グラフ化されているメトリクスが表示されます。下部のパネルでは、グラフ化できるメトリクスを選択できます。下部のパネルで Amazon Keyspaces を選択します。 1. Amazon Keyspaces メトリクスの選択パネルで [**テーブルメトリクス**] カテゴリを選択し、現在のリージョンのテーブルのメトリクスを表示します。 1. メニューを下にスクロールしてテーブル名を確認し、テーブルの `ConsumedReadCapacityUnits` と `ConsumedWriteCapacityUnits` メトリクスを選択します。 1. [**グラフ化したメトリクス (2)**] タブを選択し、[**統計**] 列を [**合計**] に設定します。 1. テーブルが誤って未使用と識別されないように、長期間にわたってテーブルメトリクスの評価を行います。グラフパネルの上部で、テーブルを評価するための適切な時間枠 (1 か月など) を選択します。[**カスタム**] を選択し、ドロップダウンで [**1 か月間**] を選択し、[**適用**] を選択します。 1. テーブルのグラフ化されたメトリクスを評価して、使用されているかどうかを判断します。**0** を超えるメトリクスは、評価期間中にテーブルが使用されたことを示します。読み込みと書き込みの両方が **0** の平らなグラフは、テーブルが未使用であることを示します。 ------ ## 未使用のテーブルリソースをクリーンアップする 未使用のテーブルリソースを特定したら、次の方法でその継続的なコストを削減できます。 **注記** 未使用のテーブルを特定したものの、将来アクセスする必要が生じた場合に備えて使用できるようにしておきたい場合は、オンデマンドモードに切り替えることを検討してください。それ以外の場合、テーブルの削除を検討してください。 **キャパシティモード** Amazon Keyspaces テーブル内のデータの読み込み、書き込み、保存には料金がかかります。 Amazon Keyspaces には [2 種類のキャパシティモード](ReadWriteCapacityMode.md)があり、テーブルの読み書き処理については特定の請求オプション (オンデマンドとプロビジョンド) があります。読み取り/書き込みキャパシティモードは、読み取りおよび書き込みスループットの課金方法とキャパシティの管理方法を制御します。 オンデマンドモードのテーブルでは、アプリケーションで実行することが予測される読み込みおよび書き込みスループットを指定する必要はありません。Amazon Keyspaces では、読み込みリクエスト単位と書き込みリクエスト単位に関して、テーブルに対してアプリケーションが実行する読み込みと書き込みに料金が請求されます。テーブルにアクティビティがない場合、スループットに対する支払いは発生しませんが、ストレージ料金は発生します。 **テーブルの削除** 未使用のテーブルを発見し、それを削除する場合は、まずデータのバックアップか、エクスポートを行うことを検討してください。 を介してバックアップを実行すると、コールドストレージ階層化を活用 AWS Backup できるため、コストをさらに削減できます。ライフサイクルを使用してバックアップをコールドストレージに移動する方法については、[バックアッププランの管理](https://docs.aws.amazon.com/aws-backup/latest/devguide/about-backup-plans)ドキュメントを参照してください。 テーブルをバックアップしたら、 AWS マネジメントコンソール または AWS Command Line Interfaceを使用してテーブルを削除できます。 ## 未使用のポイントインタイムリカバリ (PITR) バックアップのクリーンアップ Amazon Keyspaces にはポイントインタイムリカバリ機能があり、35 日間の継続的バックアップを利用できるため、意図しない書き込みや削除を防ぐことができます。PITR バックアップには、関連する追加コストがあります。 不要になった可能性のあるバックアップがテーブルで有効になっているかどうかを、[Amazon Keyspaces のポイントインタイムリカバリでデータをバックアップおよび復元する](PointInTimeRecovery.md) のマニュアルを参照して確認してください。 # テーブルの使用パターンを評価してパフォーマンスとコストを最適化する このセクションでは、あなたがAmazon Keyspaces テーブルを効率的に使用しているかどうかを評価する方法の概要を説明します。Amazon Keyspaces には最適ではない特定の使用パターンがあり、これらはパフォーマンスとコストの両方の観点から最適化する余地があります。 **Topics** + [強力な整合性のある読み込みオペレーションの数を減らす](#CostOptimization_TableUsagePatterns_StronglyConsistentReads) + [有効期限 (TTL) の有効化](#CostOptimization_TableUsagePatterns_TTL) ## 強力な整合性のある読み込みオペレーションの数を減らす Amazon Keyspaces では、リクエストごとに[読み込み整合性](consistency.md#ReadConsistency)を設定できます。デフォルトでは、読み込みリクエストは結果的に整合性が保たれます。結果整合性のある読み込みは、最大 4 KB のデータに対して 0.5 RCU が課金されます。 分散型ワークロードのほとんどの部分は柔軟性があり、最終的な一貫性を許容できます。ただし、強力な整合性のある読み込みを必要とするアクセスパターンもあり得ます。強力な整合性のある読み込みには、最大 4 KB のデータに対して 1 RCU の料金が課金されるため、読み込みコストは実質的に 2 倍になります。Amazon Keyspaces では、同じテーブルで両方の整合性モデルを柔軟に使用できます。 ワークロードとアプリケーションコードを評価して、強力な整合性のある読み込みが必要な場合にのみ使用されているかどうかを確認できます。 ## 有効期限 (TTL) の有効化 [有効期限 (TTL) ](TTL.md)を使用すると、テーブルのデータが自動的に期限切れになり、アプリケーションロジックが簡素化され、ストレージの料金を最適化できます。不要になったデータは、設定した有効期限の値に基づいて、テーブルから自動的に削除されます。 # 適切なサイズのプロビジョニングを行うために、プロビジョンドキャパシティを評価する このセクションでは、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) を使用すると有益な場合があります。