グローバルテーブル: 仕組み - Amazon DynamoDB

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

グローバルテーブル: 仕組み

重要

このドキュメントはグローバルテーブルのバージョン 2017.11.29 (レガシー) を対象としています。新しいグローバルテーブルでは使用しないでください。可能であれば、グローバルテーブルバージョン 2019.11.21 (現行) を使用する必要があります。 2017.11.29 (レガシー) よりも柔軟性と効率が高く、消費される書き込みキャパシティーが少ないためです。

ご使用のバージョンを確認するには、「使用しているグローバルテーブルのバージョンを確認する」を参照してください。既存のグローバルテーブルを 2017.11.29 (レガシー) からバージョン 2019.11.21 (現行) に更新する方法については、「グローバルテーブルのアップグレード」を参照してください。

以下のセクションでは、Amazon DynamoDB におけるグローバルテーブルの概念および動作を理解することができます。

バージョン 2017.11.29 (レガシー) のグローバルテーブルの概念

グローバルテーブルは 1 つ以上のレプリカテーブルの集合体であり、すべて単一の AWS アカウントが所有します。

レプリカテーブル (または、略してレプリカ) は、グローバルテーブルの一環として機能する単一の DynamoDB テーブルです。各レプリカには、同じデータ項目のセットが保存されます。指定のグローバルテーブルは、AWS リージョンごとに 1 つのレプリカテーブルのみを持つことができます。

以下は、グローバルテーブルの作成方法における概念的な概要です。

  1. AWS リージョンで、DynamoDB Streams を有効にしてある通常の DynamoDB テーブルを作成します。

  2. データをレプリケートする他のすべてのリージョンに対して、ステップ 1 を繰り返します。

  3. 作成したテーブルに基づいて DynamoDB グローバルテーブルを定義します。

AWS Management Console はこれらのタスクを自動化するため、グローバルテーブルをより迅速かつ簡単に作成できます。詳細については、「」を参照してくださいグローバルテーブルの作成

結果の DynamoDB グローバルテーブルは、DynamoDB が単一の単位として扱う複数のレプリカテーブル (リージョンごとに 1 つ) で構成されます。すべてのレプリカは、同じテーブル名と同じプライマリキーのスキーマを持っています。アプリケーションが 1 つのリージョンのレプリカテーブルにデータを書き込むと、DynamoDB はその書き込みを他の AWS リージョンの他のレプリカテーブルに自動的に伝搬します。

重要

テーブルデータの同期を維持するために、グローバルテーブルでは、すべての項目に対して次の属性を自動的に作成します。

  • aws:rep:deleting

  • aws:rep:updatetime

  • aws:rep:updateregion

これらの属性を変更したり、同じ名前の属性を作成したりしないでください。

レプリカテーブルをグローバルテーブルに追加して、追加のリージョンで使用できるようにすることができます。(これを行うには、グローバルテーブルが空である必要があります。つまり、どのレプリカテーブルにもデータを含めることはできません。)

グローバルテーブルからレプリカテーブルを削除することもできます。これを行うと、テーブルはグローバルテーブルから完全に関連付けが解除されます。この新しく独立したテーブルは、グローバルテーブルと相互作用しなくなり、データはグローバルテーブルとの間で伝播されなくなります。

警告

レプリカの削除がアトミックプロセスではないことに注意してください。動作と既知の状態に確実に一貫させるために、削除されるレプリカからアプリケーションの書き込みトラフィックを事前に切り離しておくことをお勧めします。削除後、すべてのレプリカリージョンのエンドポイントでレプリカが関連付け解除されたものとして表示されるのを待ってから、レプリカへのそれ以降の書き込みを独自の分離リージョンテーブルとして実行してください。

一般的なタスク

グローバルテーブルの一般的なタスクは以下のように機能します。

グローバルテーブルのレプリカテーブルは、通常のテーブルと同じように削除できます。これにより、そのリージョンへのレプリケーションが停止し、そのリージョンに保存されているテーブルコピーが削除されます。レプリケーションを切断して、テーブルのコピーを独立したエンティティとすることはできません。

注記

ソーステーブルは、新しいリージョンの作成に使用されてから 24 時間以上経たないと削除できません。削除を試みるのが早すぎると、エラーが発生します。

アプリケーションが異なるリージョンにある同一項目をほぼ同時に更新すると、競合が発生する可能性があります。結果整合性を確保するために、DynamoDB グローバルテーブルでは同時更新間の調整のために、「最新書き込み優先」方法が使用されます。すべてのレプリカが最新の更新に合意し、すべてのレプリカが同一のデータを持つ状態に収束します。

注記

競合を回避する方法は、以下を含めていくつかあります。

  • IAM ポリシーを使用して、1 つのリージョンのテーブルへの書き込みのみを許可する。

  • IAM ポリシーを使用してユーザーを 1 つのリージョンのみにルーティングし、もう 1 つはアイドル状態のスタンバイのままにする。または、奇数のユーザーをあるリージョンに、偶数のユーザーを別のリージョンにルーティングする。

  • Bookmark = Bookmark + 1 のような非冪等の更新は避け、Bookmark=25 のような静的な更新を優先する。

グローバルテーブルのモニタリング

CloudWatch を使用して、 メトリクスを監視できますReplicationLatency。このメトリクスは、更新された項目が 1 つのレプリカテーブルの DynamoDB ストリームに表示されてから、その項目がグローバルテーブルの別のレプリカに表示されるまでの経過時間を追跡します。 ReplicationLatency はミリ秒単位で表され、ソースリージョンと送信先リージョンのペアごとに出力されます。これは、グローバルテーブル v2 によって提供される唯一の CloudWatch メトリクスです。

表示されるレイテンシーは、選択したリージョン間の距離やその他の変動要素によって異なります。リージョンのレイテンシーが 0.5~2.5 秒の範囲で発生するのは、同じ地域内でもよくあることです。

有効期限 (TTL)

Time To Live (TTL) を使用して、項目の有効期限を示す値を含む属性名を指定できます。この値は、Unix エポックの開始からの秒単位の数値として指定されます。

グローバルテーブルのレガシーバージョンでは、TTL 削除は他のレプリカに自動的にレプリケートされません。TTL ルールを使用して項目を削除すると、その作業は書き込みユニットを消費せずに実行されます。

ソーステーブルとターゲットテーブルのプロビジョニングされた書き込みキャパシティーが非常に少ない場合、TTL 削除には書き込みキャパシティーが必要となるため、スロットリングが発生する可能性があります。

グローバルテーブルでのストリームとトランザクション

各グローバルテーブルは、書き込みの開始点に関係なく、すべての書き込みに基づいて独立したストリームを生成します。この DynamoDB ストリームを 1 つのリージョンで使用するか、すべてのリージョンで個別に使用するかを選択できます。

レプリケートされた書き込みではなくローカル書き込みを処理する場合は、各項目に独自のリージョン属性を追加できます。次に、Lambda イベントフィルターを使用して、ローカルリージョンへの書き込みに対して Lambda のみを呼び出すことができます。

トランザクションオペレーションは、書き込みが最初に行われたリージョン内でのみ、不可分性、一貫性、分離性、耐久性 (ACID) を保証します。グローバルテーブルのリージョン間では、トランザクションはサポートされていません。

例えば、米国東部 (オハイオ) リージョンと米国西部 (オレゴン) リージョンにレプリカを含むグローバルテーブルがあり、米国東部 (オハイオ) リージョンで TransactWriteItems オペレーションを実行する場合、変更がレプリケートされると、米国西部 (オレゴン) リージョンで部分的に完了したトランザクションが観察されることがあります。変更は、ソースリージョンでコミットされると、他のリージョンにのみレプリケートされます。

注記
  • グローバルテーブルは DynamoDB を直接更新することで、DynamoDB Accelerator を「書き込み迂回」します。その結果、DAX は古いデータを保持していることを認識しません。DAX キャッシュは、キャッシュの TTL が期限切れになったときにのみ更新されます。

  • グローバルテーブルのタグは自動的には伝播されません。

読み取りおよび書き込みスループット

グローバルテーブルは、次の方法で読み取りと書き込みのスループットを管理します。

  • 書き込みキャパシティーは、リージョン間のすべてのテーブルインスタンスで同じでなければなりません。

  • バージョン 2019.11.21 (現行) では、テーブルが自動スケーリングをサポートするように設定されているか、オンデマンドモードの場合、書き込みキャパシティーは自動的に同期されます。各リージョンで現在プロビジョニングされている書き込みキャパシティーは、同期された自動スケーリング設定の範囲内で個別に増減します。テーブルをオンデマンドモードにすると、そのモードは他のレプリカと同期します。

  • 読み取りキャパシティーはリージョンによって異なる場合があります。これは、読み取りキャパシティーが等しくない場合があるためです。グローバルレプリカをテーブルに追加すると、ソースリージョンのキャパシティーが反映されます。作成後、1 つのレプリカの読み込みキャパシティーを調整できますが、この新しい設定はもう 1 つのレプリカには転送されません。

整合性と競合の解決

レプリカテーブル内の項目に加えられた変更は、同じグローバルテーブル内の他のすべてのレプリカにレプリケートされます。グローバルテーブルでは、新しく書き込まれた項目は通常、数秒以内にすべてのレプリカテーブルに伝播されます。

グローバルテーブルでは、各レプリカテーブルには同じデータ項目のセットが保存されます。DynamoDB では、一部の項目のみの部分的なレプリケーションはサポートされていません。

アプリケーションは、任意のレプリカテーブルとの間でデータを読み込みおよび書き込みできます。DynamoDB は、リージョン間での結果整合性にある読み込みに対応していますが、リージョン間での強力な整合性のある読み込みには対応していません。アプリケーションが結果整合性のある読み込みのみを使用し、1 つの AWS リージョンに対して読み込みのみを発行する場合、変更を加えずに動作します。ただし、アプリケーションで強力な整合性のある読み込みが必要な場合は、同じリージョンですべての強力な整合性のある読み込みと書き込みを実行する必要があります。そうではなく、あるリージョンに書き込んで別のリージョンから読み込む場合、読み込みのレスポンスには、他のリージョンで最近完了した書き込みの結果を反映していない古いデータが含まれる可能性があります。

アプリケーションが異なるリージョンにある同一項目をほぼ同時に更新すると、競合が発生する可能性があります。結果整合性を確保するために、DynamoDB グローバルテーブルでは最終書き込み者優先を使用して、同時更新間の調整を行い、DynamoDB は最終書き込み者を判断するために最善を尽くします。この競合解決メカニズムでは、すべてのレプリカが最新の更新に合意し、すべてのレプリカが同一のデータを持つ状態に収束します。

可用性と耐久性

単一の AWS リージョンが分離または低下した場合、アプリケーションは別のリージョンにリダイレクトし、別のレプリカテーブルに対して読み込みと書き込みを実行できます。カスタムビジネスロジックを適用して、リクエストを他のリージョンにリダイレクトするタイミングを決定できます。

リージョンが分離または縮退した場合、DynamoDB は、実行されたが、まだすべてのレプリカテーブルに反映されていない書き込みを追跡します。リージョンがオンラインに戻ると、DynamoDB はそのリージョンから他のリージョンのレプリカテーブルへの保留中の書き込みの伝播を再開します。また、他のレプリカテーブルから現在オンラインに戻っているリージョンへの書き込みの伝播も再開します。リージョンの分離期間がどれほど長くても、それまでに成功した書き込みはすべて最終的に反映されます。