DynamoDB グローバルテーブルの仕組み
マルチアカウントグローバルテーブルは、DynamoDB グローバルテーブルのフルマネージド、サーバーレス、マルチリージョン、マルチアクティブ機能を複数の AWS アカウントに拡張します。マルチアカウントグローバルテーブルは、AWS リージョンとアカウント間でデータをレプリケートし、同一アカウントグローバルテーブルと同じアクティブ/アクティブ機能を提供します。いずれかのレプリカに書き込むと、DynamoDB は他のすべてのレプリカにデータをレプリケートします。
同一アカウントグローバルテーブルとの主な違いは次のとおりです。
-
マルチアカウントレプリケーションは、マルチリージョンの結果整合性 (MREC) グローバルテーブルでサポートされています。
-
レプリカを追加できるのは、単一リージョンテーブルから始める場合のみです。既存の同一アカウントグローバルテーブルをマルチアカウント設定に変換することはサポートされていません。移行するには、新しいマルチアカウントグローバルテーブルを作成する前に、既存のレプリカを削除して単一リージョンテーブルに戻す必要があります。
-
各レプリカは個別の AWS アカウントに存在する必要があります。N 個のレプリカを持つマルチアカウントグローバルテーブルの場合、N 個のアカウントが必要です。
-
マルチアカウントグローバルテーブルは、デフォルトですべてのレプリカにわたって統合されたテーブル設定を使用します。すべてのレプリカは自動的に同じ設定 (スループットモード、TTL など) を共有しますが、同一アカウントグローバルテーブルとは異なり、これらの設定はレプリカごとに上書きすることはできません。
-
顧客は、リソースポリシーで DynamoDB グローバルテーブルサービスプリンシパルにレプリケーション許可を提供する必要があります。
マルチアカウントグローバルテーブルは、同一アカウントグローバルテーブルと同じ基盤となるレプリケーションテクノロジーを使用します。テーブル設定はすべてのリージョンレプリカに自動的にレプリケートされ、顧客はレプリカごとに設定を上書きまたはカスタマイズすることはできません。これにより、同じグローバルテーブルに参加している複数の AWS アカウント間で一貫した設定と予測可能な動作が保証されます。
DynamoDB グローバルテーブルの設定は、テーブルの動作と、リージョン間でのデータのレプリケート方法を定義します。これらの設定は、テーブルの作成時または新しいリージョンレプリカの追加時に DynamoDB コントロールプレーン API を介して設定されます。
マルチアカウントグローバルテーブルを作成する場合、顧客はリージョンレプリカごとに GlobalTableSettingsReplicationMode = ENABLED を設定する必要があります。これにより、1 つのリージョンで行われた設定変更は、グローバルテーブルに参加する他のすべてのリージョンに自動的に伝播されます。
テーブルの作成後に設定のレプリケーションを有効にできます。これは、テーブルがもともとリージョンテーブルとして作成され、後でマルチアカウントグローバルテーブルにアップグレードされるシナリオをサポートします。
同期される設定
次のテーブル設定は、マルチアカウントグローバルテーブル内のすべてのレプリカ間で常に同期されます。
注記
同一アカウントグローバルテーブルとは異なり、マルチアカウントグローバルテーブルでは、これらの設定をリージョンごとに上書きすることはできません。唯一の例外は、読み取り自動スケーリングポリシー (テーブルと GSI) は個別の外部リソースであるため、上書きが許可されることです。
-
キャパシティモード (プロビジョンドキャパシティまたはオンデマンド)
-
テーブルのプロビジョニングされた読み込みおよび書き込みキャパシティ
-
テーブルの読み込みおよび書き込みの自動スケーリング
-
ローカルセカンダリインデックス (LSI) 定義
-
グローバルセカンダリインデックス (GSI) 定義
-
GSI プロビジョニングされた読み込みおよび書き込みキャパシティ
-
GSI の読み込みおよび書き込みの自動スケーリング
-
MREC モードでの Streams 定義
-
有効期限 (TTL)
-
ウォームスループット
-
オンデマンドの最大読み取りおよび書き込みスループット
同期されない設定
以下の設定はレプリカ間で同期されないため、リージョンごとにレプリカテーブルごとに個別に設定する必要があります。
-
テーブルクラス
-
サーバー側の暗号化 (SSE)
-
ポイントインタイムリカバリ
-
サーバー側の暗号化 (SSE) KMS キー ID
-
削除保護
-
Kinesis Data Streams (KDSD)
-
タグ
-
リソースポリシー
-
テーブル Cloudwatch-Contributor Insights (CCI)
-
GSI Cloudwatch-Contributor Insights (CCI)
モニタリング
マルチリージョンの結果整合性 (MREC) 用に設定されたグローバルテーブルは ReplicationLatency メトリクスを CloudWatch に発行します。このメトリクスは、項目がレプリカテーブルに書き込まれてから、その項目がグローバルテーブルの別のレプリカに表示されるまでの経過時間を追跡します。ReplicationLatency はミリ秒単位で表し、グローバルテーブル内のすべての送信元と送信先のリージョンペアに対して出力されます。
一般的な ReplicationLatency 値は、選択した AWS リージョン間の距離と、ワークロードタイプやスループットなどの他の変数によって異なります。例えば、米国西部 (北カリフォルニア) (us-west-1) リージョンのソースレプリカは、アフリカ (ケープタウン) (af-south-1) リージョンと比較して、米国西部 (オレゴン) (us-west-2) リージョンへの ReplicationLatency が低くなります。
ReplicationLatency の値が上昇している場合、1 つのレプリカからの更新が他のレプリカテーブルにタイムリーに伝播されていないことを示している可能性があります。この場合、アプリケーションの読み込みおよび書き込みアクティビティを別の AWS リージョンに一時的にリダイレクトすることができます。
マルチアカウントグローバルテーブルでのレプリケーションレイテンシーの問題の処理
レプリカテーブルで顧客に起因する問題が原因で ReplicationLatency が 3 時間を超える場合、DynamoDB は顧客に根本的な問題に対処するように求める通知を送信します。レプリケーションを妨げる可能性がある一般的な顧客に起因する問題には、次のようなものがあります。
-
レプリカテーブルのリソースポリシーから必要なアクセス許可を削除する
-
マルチアカウントグローバルテーブルのレプリカをホストする AWS リージョンをオプトアウトする
-
データの復号に必要なテーブルの AWS KMS キーアクセス許可を拒否する
DynamoDB は、レプリケーションレイテンシーが増加してから 3 時間以内に最初の通知を送信し、問題が解決されない場合は 20 時間後に 2 回目の通知を送信します。必要な時間枠内に問題が修正されない場合、DynamoDB はグローバルテーブルからレプリカの関連付けを自動的に解除します。その後、影響を受けるレプリカはリージョンテーブルに変換されます。