DynamoDB テーブルの使用パターンを評価する

このセクションでは、DynamoDB テーブルを効率的に使用しているかどうかを評価する方法の概要を説明します。DynamoDB には最適ではない特定の使用パターンがあり、パフォーマンスとコストの両方の観点から最適化の余地があります。

強力な整合性のある読み込みオペレーションの数を減らす

DynamoDB では、リクエストごとに読み込み整合性を設定できます。デフォルトでは、読み込みリクエストは結果的に整合性が保たれます。結果整合性のある読み込みは、最大 4 KB のデータに対して 0.5 RCU で課金されます。

分散型ワークロードのほとんどの部分は柔軟性があり、最終的な一貫性を許容できます。ただし、強力な整合性のある読み込みを必要とするアクセスパターンもあり得ます。強力な整合性のある読み込みには、最大 4 KB のデータに対して 1 RCU の料金が課金されるため、読み込みコストは実質的に 2 倍になります。DynamoDB では、同じテーブルで両方の整合性モデルを柔軟に使用できます。

ワークロードとアプリケーションコードを評価して、強力な整合性のある読み込みが必要な場合にのみ使用されているかどうかを確認できます。

読み込み操作のトランザクション数を減らす

DynamoDB では、特定のアクションを「すべて」か「なし」でグループ化できます。つまり、DynamoDB で ACID トランザクションを実行することが可能です。ただし、リレーショナルデータベースの場合と同様に、すべてのアクションでこのアプローチに従う必要はありません。

最終的に一貫した方法で同じ量のデータを読み取るためにデフォルトでは 0.5 RCU が使用される一方、最大 4 KB のトランザクション読み込みオペレーションでは 2 RCU が使用されます。書き込み操作のコストは 2 倍になります。つまり、1 KB までのトランザクション書き込みは、2 WCU に相当します。

テーブルのすべてのオペレーションがトランザクションかどうかを判断するには、テーブルの CloudWatch メトリクスをトランザクション API に絞り込むことができます。テーブルの SuccessfulRequestLatency メトリクスで使用できるグラフがトランザクション API だけであれば、すべてのオペレーションがこのテーブルのトランザクションであることを確認できます。あるいは、全体的なキャパシティ使用率の傾向がトランザクション API の傾向と一致する場合は、トランザクション API が大部分を占めていると考えられるため、アプリケーション設計を見直すことを検討してください。

スキャンの回数を減らす

Scan オペレーションを多用するのは、一般的に DynamoDB データに対して分析クエリを実行する必要があるためです。大きなテーブルで頻繁に Scan オペレーションを実行するのは、非効率的でコストが高額になる可能性があります。

また、Export to S3 機能を使用し、特定の時点を選択してテーブルの状態を S3 にエクスポートする方法もあります。AWS には、テーブルの容量を消費することなく、データに対して分析クエリを実行できる Athena のようなサービスがあります。

Scan オペレーションの頻度は、Scan の SuccessfulRequestLatency メトリクスの SampleCount 統計を使用して決定できます。Scan オペレーションが非常に頻繁に行われる場合は、アクセスパターンとデータモデルの再評価が推奨されます。

属性名を短くする

DynamoDB の項目の合計サイズは、属性名と属性値の長さの合計です。属性名が長いと、ストレージコストだけでなく、RCU/WCU の消費量も増える可能性があります。属性名は長いものよりも短いものにすることをお勧めします。属性名を短くすると、項目サイズを次の 4KB/1KB の境界内に制限でき、それを超えるとデータにアクセスするために追加の RCU/WCU を消費することになります。

有効期限 (TTL) の有効化

有効期限 (TTL) では、項目に設定した有効期限を過ぎた項目を特定してテーブルから削除できます。データが時間の経過とともに増加し、古いデータが重要でなくなった場合は、テーブルで TTL を有効にすると、データを削減してストレージコストを節約できます。

TTL のもう 1 つの便利な点は、期限切れの項目が DynamoDB ストリームで発生することです。そのため、データからデータを削除するだけでなく、ストリームからそれらの項目を消費して低コストのストレージ階層にアーカイブすることができます。さらに、TTL による項目の削除に追加コストはかかりません。容量を消費せず、クリーンアップアプリケーションを設計するオーバーヘッドもありません。

グローバルテーブルをクロスリージョンバックアップに置き換える

グローバルテーブルを使用すると、異なるリージョンに複数のアクティブなレプリカテーブルを管理できます。これらのテーブルはすべて書き込み操作を受け付け、相互にデータをレプリケートできます。レプリカの設定は簡単で、同期は自動的に管理されます。レプリカは、最新書き込み優先ストラテジーを使用して一貫した状態に収束します。

グローバルテーブルをフェイルオーバーまたはディザスタリカバリ (DR) 戦略の一環としてのみ使用している場合は、比較的緩やかな復旧ポイント目標と復旧時間目標の要件を満たすために、グローバルテーブルをクロスリージョンバックアップコピーに置き換えることができます。高速なローカルアクセスと 99.999% の高可用性が必要ない場合は、グローバルテーブルレプリカを維持することはフェイルオーバーに最適な方法ではないかもしれません。

別の方法として、AWS Backup を使用して DynamoDB バックアップを管理することを検討してください。定期的なバックアップをスケジュールしてリージョン間でコピーすることで、グローバルテーブルを使用するよりも費用対効果の高い方法で、DR 要件を満たすことができます。