# DynamoDB の未使用のリソースを特定する
このセクションでは、未使用のリソースを定期的に評価する方法の概要を説明します。アプリケーションの要件が変化するにつれて、未使用のリソースによって不要な Amazon DynamoDB のコストが生じないようにする必要があります。以下に説明する手順では、Amazon CloudWatch メトリクスを使用して未使用のリソースを特定します。さらにこの手順は、リソースを特定してコストを削減するための対策を講じるのに役立ちます。
CloudWatch を使用して DynamoDB をモニタリングすることで、DynamoDB から raw データを収集し、リアルタイムに近い読み込み可能なメトリクスに加工することができます。これらの統計は一定期間保持されるため、履歴情報にアクセスして使用率をより正確に調べることができます。デフォルトでは、DynamoDB メトリクスデータは 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)
+ [未使用の GSI リソースを特定する](#CostOptimization_UnusedResources_GSI)
+ [未使用の GSI リソースをクリーンアップする](#CostOptimization_UnusedResources_GSI_Cleanup)
+ [未使用のグローバルテーブルをクリーンアップする](#CostOptimization_UnusedResources_GlobalTables)
+ [未使用のバックアップまたはポイントインタイムリカバリ (PITR) をクリーンアップする](#CostOptimization_UnusedResources_Backups)
## 未使用のリソースを特定する方法
未使用のテーブルやインデックスを特定するには、30 日間にわたって次の CloudWatch メトリクスを調べ、テーブルに対するアクティブな読み込みまたは書き込み、あるいはグローバルセカンダリインデックス (GSI) の読み込みがあるかどうかを調べます。
**[ConsumedReadCapacityUnits](metrics-dimensions.md#ConsumedReadCapacityUnits)**
指定された期間に消費された読み込みキャパシティユニットの数。消費されたキャパシティの使用量を追跡できます。テーブルとそのすべてのグローバルセカンダリインデックス、または特定のグローバルセカンダリインデックスの消費された読み込み容量の合計を取得できます。
**[ConsumedWriteCapacityUnits](metrics-dimensions.md#ConsumedWriteCapacityUnits)**
指定された期間に消費された書き込みキャパシティユニットの数。消費されたキャパシティの使用量を追跡できます。テーブルとそのすべてのグローバルセカンダリインデックス、または特定のグローバルセカンダリインデックスの消費された書き込み容量の合計を取得できます。
## 未使用のテーブルリソースを特定する
Amazon CloudWatch は、モニタリングおよびオブザーバビリティサービスで、未使用のリソースの特定に使用する DynamoDB テーブルのメトリクスを提供します。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/DynamoDB --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/DynamoDB --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 コンソールにログインして、CloudWatch サービスページ ([https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)) を開きます。必要に応じて、コンソールの右上で適切な AWS リージョンを選択します。
1. 左のナビゲーションバーで、[Metrics] (メトリクス) セクションを探し、**[All metrics]** (すべてのメトリクス) を選択します。
1. これにより、2 つのパネルで構成されるダッシュボードが開きます。上部のパネルには、現在グラフ化されているメトリクスが表示されます。下部のパネルでは、グラフ化できるメトリクスを選択できます。下部のパネルで DynamoDB を選択します。
1. DynamoDB メトリクスの選択パネルで **[Table Metrics]** (テーブルメトリクス) カテゴリを選択し、現在のリージョンのテーブルのメトリクスを表示します。
1. メニューを下にスクロールしてテーブル名を確認し、テーブルの `ConsumedReadCapacityUnits` および `ConsumedWriteCapacityUnits` メトリクスを選択します。
1. **[Graphed metrics (2)]** (グラフ化したメトリクス (2)) タブを選択し、**[Statistic]** (統計) 列を **[Sum]** (合計) に設定します。
![\[[グラフ化されたメトリクス] タブ。[統計] を [合計] に設定し、コンソールにリソース使用状況データを表示します。\]](http://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/images/CostOptimization/GraphedMetricsTab.png)
1. テーブルが未使用と誤って識別されないようにするには、長期間にわたってメトリクスを評価する必要があります。グラフパネルの上部で、テーブルを評価するための適切な時間枠 (1 か月など) を選択します。**[Custom]** (カスタム) を選択し、ドロップダウンで **[1 Months]** (1 か月間) を選択し、**[Apply]** (適用) を選択します。
![\[CloudWatch コンソール。メトリクスを評価するには、1 か月のカスタム時間枠を選択します。\]](http://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/images/CostOptimization/OneMonthTimeFrame.png)
1. テーブルのグラフ化されたメトリクスを評価して、使用されているかどうかを判断します。**0** を超えるメトリクスは、評価期間中にテーブルが使用されたことを示します。読み込みと書き込みの両方が **0** の平らなグラフは、テーブルが未使用であることを示します。
以下の画像は、読み込みトラフィックがあるテーブルを示しています。
![\[DynamoDB テーブルの ConsumedReadCapacityUnits を示すグラフ。テーブルが使用中であることを示しています。\]](http://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/images/CostOptimization/TableWithReadTraffic.png)
以下の画像は、読み込みトラフィックがないテーブルを示しています。
![\[DynamoDB テーブルの読み取りアクティビティがないことを示すグラフ。テーブルが使用されていないことを示しています。\]](http://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/images/CostOptimization/TableWithoutReadTraffic.png)
------
## 未使用のテーブルリソースをクリーンアップする
未使用のテーブルリソースを特定したら、次の方法でその継続的なコストを削減できます。
**注記**
未使用のテーブルを特定したものの、将来アクセスする必要が生じた場合に備えて使用できるようにしておきたい場合は、オンデマンドモードに切り替えることを検討してください。それ以外の場合、テーブル全体をバックアップして削除することを検討できます。
**キャパシティモード**
DynamoDB テーブル内のデータの読み込み、書き込み、保存には料金がかかります。
DynamoDB には [2 種類のキャパシティモード](capacity-mode.md)があり、テーブルの読み書き処理について別個の請求オプション (オンデマンドとプロビジョンド) があります。読み取り/書き込みキャパシティモードは、読み取りおよび書き込みスループットの課金方法とキャパシティの管理方法を制御します。
オンデマンドモードのテーブルでは、アプリケーションで実行することが予測される読み込みおよび書き込みスループットを指定する必要はありません。DynamoDB では、読み込みリクエスト単位と書き込みリクエスト単位に関して、アプリケーションがテーブルに対して実行する読み込みと書き込みに対して料金が請求されます。テーブル/インデックスにアクティビティがない場合、スループットに対する支払いは発生しませんが、ストレージ料金は発生します。
**テーブルクラス**
DynamoDB には、コストの最適化に役立つように設計された [2 つのテーブルクラス](HowItWorks.TableClasses.md)も用意されています。デフォルトは DynamoDB Standard テーブルクラスで、大半のワークロードで推奨されています。DynamoDB Standard-Infrequent Access (DynamoDB Standard-IA) テーブルクラスは、ストレージが主要なコストとなるテーブル向けに最適化されています。
テーブルまたはインデックスにアクティビティがない場合は、ストレージがコストの大きな割合を占める可能性が高く、テーブルクラスを変更することで大幅な節約が実現します。
**テーブルの削除**
未使用のテーブルを発見し、それを削除する場合は、まずデータのバックアップまたはエクスポートを行うことをお勧めします。
AWS Backup によるバックアップでは、コールドストレージの階層化を活用できるため、コストをさらに削減できます。AWS Backup を使用してバックアップを有効にする方法については「[DynamoDB での AWS Backup の使用](backuprestore_HowItWorksAWS.md)」のドキュメントを、ライフサイクルを使用してバックアップをコールドストレージに移動する方法については、「[Managing backup plans](https://docs.aws.amazon.com/aws-backup/latest/devguide/about-backup-plans)」(バックアッププランの管理) のドキュメントを参照してください。
または、テーブルのデータを S3 にエクスポートすることもできます。その場合は、「[Export to Amazon S3](S3DataExport.HowItWorks.md)」(Amazon S3 へのエクスポート) のドキュメントを参照してください。データをエクスポートした後に、S3 Glacier Instant Retrieval、S3 Glacier Flexile Retrieval、または S3 Glacier Deep Archive を活用してさらにコストを削減する場合は、「[Managing your storage lifecycle](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt)」(ストレージのライフサイクルの管理) を参照してください。
テーブルをバックアップしたら、AWS マネジメントコンソール または 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 --end-time --period --namespace AWS/DynamoDB --statistics Sum --
dimensions Name=TableName,Value=
Name=GlobalSecondaryIndexName,Value=
```
テーブルが未使用と誤って識別されないようにするには、長期間にわたってメトリクスを評価する必要があります。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 日間までの継続的バックアップを利用できるため、意図しない書き込みや削除を防ぐことができます。一方、オンデマンドバックアップでは、長期的に保存が可能なスナップショットを作成できます。リカバリ期間は、1～35 日間の任意の値を設定できます。どちらのタイプのバックアップにも、関連するコストがあります。
「[DynamoDB のバックアップと復元](Backup-and-Restore.md)」および「[DynamoDB のポイントインタイムバックアップ](Point-in-time-recovery.md)」のマニュアルを参照して、不要になった可能性のあるバックアップがテーブルで有効になっているかどうかを確認してください。