DynamoDB の未使用のリソースを特定する
このセクションでは、未使用のリソースを定期的に評価する方法の概要を説明します。アプリケーションの要件が変化するにつれて、未使用のリソースによって不要な Amazon DynamoDB のコストが生じないようにする必要があります。以下に説明する手順では、Amazon CloudWatch メトリクスを使用して未使用のリソースを特定します。さらにこの手順は、リソースを特定してコストを削減するための対策を講じるのに役立ちます。
CloudWatch を使用して DynamoDB をモニタリングすることで、DynamoDB から raw データを収集し、リアルタイムに近い読み込み可能なメトリクスに加工することができます。これらの統計は一定期間保持されるため、履歴情報にアクセスして使用率をより正確に調べることができます。デフォルトでは、DynamoDB メトリクスデータは CloudWatch に自動的に送信されます。詳細については、「Amazon CloudWatch ユーザーガイド」の「Amazon CloudWatch とは」および「メトリクスの保持」を参照してください。
トピック
未使用のリソースを特定する方法
未使用のテーブルやインデックスを特定するには、30 日間にわたって次の CloudWatch メトリクスを調べ、テーブルに対するアクティブな読み込みまたは書き込み、あるいはグローバルセカンダリインデックス (GSI) の読み込みがあるかどうかを調べます。
ConsumedReadCapacityUnits
指定された期間に消費された読み込みキャパシティユニットの数。消費されたキャパシティの使用量を追跡できます。テーブルとそのすべてのグローバルセカンダリインデックス、または特定のグローバルセカンダリインデックスの消費された読み込み容量の合計を取得できます。
ConsumedWriteCapacityUnits
指定された期間に消費された書き込みキャパシティユニットの数。消費されたキャパシティの使用量を追跡できます。テーブルとそのすべてのグローバルセカンダリインデックス、または特定のグローバルセカンダリインデックスの消費された書き込み容量の合計を取得できます。
未使用のテーブルリソースを特定する
Amazon CloudWatch は、モニタリングおよびオブザーバビリティサービスで、未使用のリソースの特定に使用する DynamoDB テーブルのメトリクスを提供します。CloudWatch メトリクスは、AWS Management Console と AWS Command Line Interface を使って表示できます。
未使用のテーブルリソースをクリーンアップする
未使用のテーブルリソースを特定したら、次の方法でその継続的なコストを削減できます。
注記
未使用のテーブルを特定したものの、将来アクセスする必要が生じた場合に備えて使用できるようにしておきたい場合は、オンデマンドモードに切り替えることを検討してください。それ以外の場合、テーブル全体をバックアップして削除することを検討できます。
キャパシティモード
DynamoDB テーブル内のデータの読み込み、書き込み、保存には料金がかかります。
DynamoDB には 2 種類のキャパシティモードがあり、テーブルの読み書き処理について別個の請求オプション (オンデマンドとプロビジョンド) があります。読み取り/書き込みキャパシティモードは、読み取りおよび書き込みスループットの課金方法とキャパシティの管理方法を制御します。
オンデマンドモードのテーブルでは、アプリケーションで実行することが予測される読み込みおよび書き込みスループットを指定する必要はありません。DynamoDB では、読み込みリクエスト単位と書き込みリクエスト単位に関して、アプリケーションがテーブルに対して実行する読み込みと書き込みに対して料金が請求されます。テーブル/インデックスにアクティビティがない場合、スループットに対する支払いは発生しませんが、ストレージ料金は発生します。
テーブルクラス
DynamoDB には、コストの最適化に役立つように設計された 2 つのテーブルクラスも用意されています。デフォルトは DynamoDB Standard テーブルクラスで、大半のワークロードで推奨されています。DynamoDB Standard-Infrequent Access (DynamoDB Standard-IA) テーブルクラスは、ストレージが主要なコストとなるテーブル向けに最適化されています。
テーブルまたはインデックスにアクティビティがない場合は、ストレージがコストの大きな割合を占める可能性が高く、テーブルクラスを変更することで大幅な節約が実現します。
テーブルの削除
未使用のテーブルを発見し、それを削除する場合は、まずデータのバックアップまたはエクスポートを行うことをお勧めします。
AWS Backup によるバックアップでは、コールドストレージの階層化を活用できるため、コストをさらに削減できます。AWS Backup を使用してバックアップを有効にする方法については「DynamoDB での AWS Backup の使用」のドキュメントを、ライフサイクルを使用してバックアップをコールドストレージに移動する方法については、「Managing backup plans」(バックアッププランの管理) のドキュメントを参照してください。
または、テーブルのデータを S3 にエクスポートすることもできます。その場合は、「Export to Amazon S3」(Amazon S3 へのエクスポート) のドキュメントを参照してください。データをエクスポートした後に、S3 Glacier Instant Retrieval、S3 Glacier Flexile Retrieval、または S3 Glacier Deep Archive を活用してさらにコストを削減する場合は、「Managing your storage lifecycle」(ストレージのライフサイクルの管理) を参照してください。
テーブルをバックアップしたら、AWS Management Console または AWS Command Line Interface を使用してテーブルを削除できます。
未使用の GSI リソースを特定する
未使用のグローバルセカンダリを特定するステップは、未使用のテーブルを特定するステップと似ています。ベーステーブルに書き込まれた項目に GSI のパーティションキーとして使用される属性が含まれている場合、DynamoDB は項目を GSI にレプリケートするため、ベーステーブルが使用中であれば、未使用の GSI でも ConsumedWriteCapacityUnits
が 0 を超える可能性があります。その結果、ConsumedReadCapacityUnits
メトリクスのみを評価して、GSI が未使用かどうかを判断することになります。
AWS AWS CLI を使って GSI メトリクスを表示する場合は、次のコマンドを使用してテーブルの読み込みを評価できます。
aws cloudwatch get-metric-statistics --metric-name ConsumedReadCapacityUnits --start-time <start-time> --end-time <end- time> --period <period> --namespace AWS/DynamoDB --statistics Sum -- dimensions Name=TableName,Value=<table-name> Name=GlobalSecondaryIndexName,Value=<index-name>
テーブルが未使用と誤って識別されないようにするには、長期間にわたってメトリクスを評価する必要があります。30 日間などの適切な開始時刻と終了時刻の範囲、および 86400 などの適切な期間を選択します。
返されるデータで、[Sum] (合計) が 0 を超える場合は、評価対象のテーブルがその期間に受信した読み込みトラフィックを示します。
次の結果は、評価期間中に読み込みトラフィックを受信した GSI を示しています。
{ "Timestamp": "2022-08-17T21:20:00Z", "Sum": 36319167.0, "Unit": "Count" }, { "Timestamp": "2022-08-11T21:20:00Z", "Sum": 1869136.0, "Unit": "Count" },
次の結果は、評価期間中に最小限の読み込みトラフィックを受信した GSI を示しています。
{ "Timestamp": "2022-08-28T21:20:00Z", "Sum": 0.0, "Unit": "Count" }, { "Timestamp": "2022-08-15T21:20:00Z", "Sum": 2.0, "Unit": "Count" },
次の結果は、評価期間中に読み込みトラフィックを受信しなかった GSI を示しています。
{ "Timestamp": "2022-08-17T21:20:00Z", "Sum": 0.0, "Unit": "Count" }, { "Timestamp": "2022-08-11T21:20:00Z", "Sum": 0.0, "Unit": "Count" },
未使用の GSI リソースをクリーンアップする
未使用の GSI が見つかった場合は、それを削除することができます。GSI に存在するすべてのデータはベーステーブルにも存在するため、GSI を削除する前に追加のバックアップを行う必要はありません。今後、GSI が再び必要になった場合は、テーブルに追加し直すことができます。
使用頻度の低い GSI が見つかった場合は、それを削除したりコストを削減したりできるように、アプリケーションの設計変更を検討する必要があります。例えば、DynamoDB のスキャンは大量のシステムリソースを消費するため、控え目に使用する必要がありますが、サポートするアクセスパターンが極めて低頻度であれば、GSI よりもコスト効率が高くなる可能性があります。
さらに、低頻度のアクセスパターンを GSI でサポートする必要がある場合は、より限定された属性セットを射影することを検討してください。この場合、低頻度のアクセスパターンをサポートするために、ベーステーブルに対して後続のクエリが必要になる場合がありますが、ストレージと書き込みのコストを大幅に削減できる可能性があります。
未使用のグローバルテーブルをクリーンアップする
Amazon DynamoDB グローバルテーブルは、マルチリージョンにマルチアクティブデータベースをデプロイするための完全マネージド型のソリューションです。独自のレプリケーションソリューションを構築および管理する必要はありません。
グローバルテーブルは、ユーザーに近いデータに低レイテンシーでアクセスしたり、ディザスタリカバリのためのセカンダリリージョンにしたりするのに最適です。
データへの低レイテンシーアクセスを提供するためにリソースに対してグローバルテーブルオプションが有効になっていても、ディザスタリカバリ戦略の一部でない場合は、CloudWatch メトリクスを評価して、両方のレプリカが読み込みトラフィックをアクティブに処理していることを確認します。1 つのレプリカが読み込みトラフィックを処理しない場合、そのレプリカは未使用のリソースである可能性があります。
グローバルテーブルがディザスタリカバリ戦略の一部である場合、アクティブ/スタンバイパターンでは、1 つのレプリカが読み込みトラフィックを受信しないことが予想されます。
未使用のバックアップまたはポイントインタイムリカバリ (PITR) をクリーンアップする
DynamoDB には 2 種類のバックアップスタイルがあります。ポイントインタイムリカバリでは 35 日間の継続的バックアップを利用できるため、意図しない書き込みや削除を防ぐことができます。また、オンデマンドバックアップでは、長期的に保存できるスナップショットを作成できます。どちらのタイプのバックアップにも、関連するコストがあります。
「DynamoDB のバックアップと復元」および「DynamoDB のポイントインタイムバックアップ」のマニュアルを参照して、不要になった可能性のあるバックアップがテーブルで有効になっているかどうかを確認してください。