DynamoDB グローバルテーブルの使用 - Amazon DynamoDB
重要な事実MREC に関する重要な事実MRSC に関する重要な事実ユースケース結論とリソース

DynamoDB グローバルテーブルの使用

グローバルテーブルは、Amazon DynamoDB のグローバルフットプリントに基づいて構築され、フルマネージド、マルチリージョン、マルチアクティブのデータベースにより、大規模にスケールされたグローバルアプリケーションの高速なローカルの読み取り/書き込みパフォーマンスを実現できます。グローバルテーブルは、選択する AWS リージョン 全体で DynamoDB テーブルを自動的にレプリケートします。グローバルテーブルは既存の DynamoDB API を使用するため、アプリケーションを変更する必要はありません。グローバルテーブルの使用に伴う前払い料金やコミットメントはなく、使用したリソース分のみの支払いで済みます。

このガイドでは、DynamoDB グローバルテーブルを効果的に使用する方法について説明します。ここでは、次の項目を取り上げます。グローバルテーブルに関する重要な情報、機能の主なユースケース、2 つの整合性モード、考慮すべき 3 種類の書き込みモデルの分類基準、実装可能な 4 つの主なリクエストルーティング、稼働しているリージョンまたはオフラインのリージョンを退避させる方法、スループットキャパシティプランニングに関する考え方、グローバルテーブルをデプロイする際の考慮事項のチェックリスト。

このガイドは、「AWS マルチリージョンの基礎」のホワイトペーパーや「AWS を使用したデータ回復力の設計パターン」の動画で説明されているように、AWS マルチリージョンデプロイという、より広いコンテキストに適しています。

トピック

DynamoDB グローバルテーブル設計に関する重要な事実

  • グローバルテーブルには、現行バージョンであるグローバルテーブルバージョン 2019.11.21 (現行) (「V2」とも呼ばれます) と グローバルテーブルバージョン 2017.11.29 (レガシー) (「V1」とも呼ばれます) の 2 つのバージョンがあります。このガイドは、現行バージョンのみを対象としています。

  • DynamoDB (グローバルテーブルなし) は、リージョンサービスとして提供されるため、可用性に優れ、本質的に、インフラストラクチャの障害 (アベイラビリティーゾーン全体の障害を含む) に対するレジリエンスを備えています。単一リージョンの DynamoDB テーブルは、99.99% の可用性を実現するように設計されています。詳細については、「DynamoDB サービスレベルアグリーメント (SLA)」を参照してください。

  • DynamoDB グローバルテーブルでは、2 つ以上のリージョン間でデータがレプリケートされます。マルチリージョンの DynamoDB テーブルは、99.999% の可用性を実現するように設計されています。グローバルテーブルを適切に計画すると、リージョンでの障害に対するレジリエンスが確保されたアーキテクチャを構築しやすくなります。

  • DynamoDB にはグローバルエンドポイントはありません。どのリクエストも、リージョンエンドポイントに対し行われ、そのエンドポイントが、そのリージョンでローカルなグローバルテーブルインスタンスにアクセスします。

  • DynamoDB への呼び出しは、リージョンを越えて実行してはなりません。ベストプラクティスとしては、あるリージョンをホームとするアプリケーションが、そのリージョンのローカル DynamoDB エンドポイントにのみ直接アクセスするようにします。リージョン内 (DynamoDB レイヤー内や周辺スタック内) で問題を検出した場合は、エンドユーザーのトラフィックを別のリージョンでホストしている別のアプリケーションエンドポイントにルーティングする必要があります。グローバルテーブルを使用すると、どのリージョンをホームとするアプリケーションも同じデータにアクセスできるようになります。

整合性モード

グローバルテーブルを作成する際には、その整合性モードを設定できます。グローバルテーブルは 2 つの整合性モードに対応しています。1 つは、マルチリージョンの結果整合性 (MREC)、もう 1 つは、2025 年 6 月に導入された、マルチリージョンの強力な整合性 (MRSC) です。

グローバルテーブルの作成時に整合性モードを指定しない場合、デフォルトでは MREC が設定されます。グローバルテーブルには、異なる整合性モードを設定したレプリカを含めることはできません。グローバルテーブルの作成後に整合性モードを変更することもできません。

MREC に関する重要な事実

  • MRSC を使用するグローバルテーブルでも、アクティブ-アクティブレプリケーションモデルを使用します。DynamoDB の観点から見ると、各リージョンのテーブルは読み取りと書き込みのリクエストを同じように受け入れることができます。書き込みリクエストを受信したローカルレプリカテーブルでは、バックグラウンドで、書き込みオペレーションが他の参加リモートリージョンにレプリケートされます。

  • 項目は個別にレプリケートされます。1 回のトランザクションで更新した複数の項目を、まとめてレプリケートすることはできません。

  • ソースリージョンの各テーブルパーティションでは、他のすべてのパーティションと並行して書き込みオペレーションがレプリケートされます。リモートリージョン内の書き込みオペレーションの順序は、ソースリージョン内で発生した書き込みオペレーションの順序と一致しない場合があります。テーブルパーティションの詳細については、ブログ記事「DynamoDB のスケーリング: パーティション、ホットキー、ヒートに応じた分割がパフォーマンスに与える影響」を参照してください。

  • 新しく書き込まれた項目は、通常、1 秒以内にすべてのレプリカテーブルに伝播されます。近くのリージョンにはより速く伝播される傾向があります。

  • Amazon CloudWatch は、リージョンのペアごとに ReplicationLatency メトリクスを提供します。到着した項目を確認し、到着時間と最初の書き込み時間を比較し、平均を算出することでメトリクスが計算されます。タイミングはソースリージョンの CloudWatch 内に保存されます。平均タイミングと最大タイミングを表示すると、平均および最悪の場合のレプリケーションラグを判断するのに役立ちます。このレイテンシーには SLA はありません。

  • 個々の項目が 2 つの異なるリージョンでほぼ同時に (この ReplicationLatency ウィンドウ内で) 更新され、最初の書き込みオペレーションがレプリケートされる前に次の書き込みオペレーションが行われると、書き込みが競合する可能性があります。MREC を使用するグローバルテーブルでは、こうした競合を解決できます。これには、書き込みオペレーションのタイムスタンプを基に、最終書き込み者優先の仕組みを使用します。つまり、最初のオペレーションよりも、2 番目のオペレーションが優先されることになります。こうした競合は CloudWatch や AWS CloudTrail には記録されません。

  • 各項目には、最終書き込みタイムスタンプがプライベートシステムプロパティとして保持されます。最終書き込み者優先のアプローチを実装するには、受け取る項目のタイムスタンプが既存の項目のタイムスタンプよりも後であることを要求する条件付き書き込みオペレーションを使用します。

  • グローバルテーブルでは、すべての項目がすべての参加リージョンにレプリケートされます。異なるレプリケーションスコープが必要な場合は、複数のグローバルテーブルを作成し、各テーブルに異なる参加リージョンを割り当てることができます。

  • レプリカリージョンがオフラインの場合や、ReplicationLatency が増加した場合でも、ローカルリージョンでは書き込みオペレーションを受け付けます。ローカルテーブルは、各項目が成功するまで、リモートテーブルへの項目のレプリケーションを試行し続けます。

  • 万が一、リージョンが完全にオフラインになっても、その後オンラインに戻った際に、すべての保留中のアウトバウンドレプリケーションとインバウンドレプリケーションが再試行されます。テーブルを同期状態に戻すために特別なアクションは必要ありません。最終書き込み者優先という仕組みにより、最終的にはデータの整合性が確保されます。

  • DynamoDB MREC テーブルには、いつでも新しいリージョンを追加できます。DynamoDB では、初期同期と継続的レプリケーションが処理されます。元のリージョンも含め、リージョンの削除も可能で、これによって、そのリージョンのローカルテーブルも削除されます。

MRSC に関する重要な事実

  • MRSC を使用するグローバルテーブルでも、アクティブ-アクティブレプリケーションモデルを使用します。DynamoDB の観点から見ると、各リージョンのテーブルは読み取りと書き込みのリクエストを同じように受け入れることができます。MRSC グローバルテーブルレプリカの項目の変更は、書き込み操作が正常なレスポンスを返す前に、少なくとも 1 つの他のリージョンに同期的にレプリケートされます。

  • MRSC レプリカに対する強力な整合性のある読み込み操作は、常に項目の最新バージョンを返します。条件付き書き込みオペレーションでは、常に項目の最新バージョンが条件式を基に評価されます。更新は、常に、項目の最新バージョンに実行されます。

  • MRSC レプリカへの、結果整合性のある読み込みオペレーションには、別のリージョンで最近発生した変更が含まれていない、あるいは、同じリージョンでごく最近発生した変更さえ含まれていない可能性があります。

  • 別のリージョンで既に変更済みの項目を変更しようとすると、書き込みオペレーションは ReplicatedWriteConflictException の例外が発生し失敗します。ReplicatedWriteConflictException の例外によって失敗した書き込みオペレーションは、再試行が可能で、別のリージョンでアイテムが変更済みでなければ成功します。

  • MRSC では、書き込みオペレーションと、強力な整合性のある読み込みオペレーションのレイテンシーが大きくなります。これらのオペレーションには、クロスリージョンの通信が必要です。この通信は、アクセスされるリージョンとグローバルテーブルに参加している最も近いリージョンとの間のラウンドトリップレイテンシーに基づいて増加するレイテンシーを追加できます。詳細については、「AWS re:Invent 2024 のプレゼンテーション」、「DynamoDB グローバルテーブルを使用したマルチリージョンの強力な整合性」を参照してください。結果整合性のある読み込みオペレーションでは、レイテンシーが増大することはありません。オープンソースのテスターツールを使用すると、自身のリージョンでこうしたレイテンシーを実験的に計算できます。

  • 項目は個別にレプリケートされます。MRSC を使用しているグローバルテーブルでは、トランザクション API はサポートされていません。

  • MRSC グローバルテーブルは、厳密に 3 つのリージョンにデプロイする必要があります。MRSC グローバルテーブルは、3 つのレプリカ、または 2 つのレプリカと 1 つの監視で設定できます。監視とは、MRSC グローバルテーブルのコンポーネントであり、これには、グローバルテーブルレプリカに書き込まれた最近のデータが含まれます。監視により、フルレプリカに代わるオプションを得られる同時に、MRSC の可用性アーキテクチャに対応できます。監視に対して読み取りまたは書き込み操作を実行することはできません。監視にストレージや書き込みのコストは発生しません。監視は、2 つのレプリカとは異なるリージョン内に存在します。

  • MRSC グローバルテーブルを作成するには、データが含まれていない既存の DynamoDB テーブルに、1 つのレプリカと 1 つの監視を追加するか、2 つのレプリカを追加します。既存の MRSC グローバルテーブルに追加のレプリカを追加することはできません。MRSC グローバルテーブルから単一のレプリカまたは監視を削除することはできません。MRSC グローバルテーブルからは、2 つのレプリカを削除するか、1 つのレプリカと 1 つの監視を削除できます。2 番目のシナリオでは、残りのレプリカを単一リージョンの DynamoDB テーブルに変換しています。

  • MRSC グローバルテーブルに監視が設定されているかどうか、またどのリージョンに設定されているかは、DescribeTable API の出力から判断できます。監視は、DynamoDB によって所有および管理されており、監視を設定したリージョンの AWS アカウントには表示されません。

  • MRSC グローバルテーブルは、次のリージョンセットで使用できます。

    • US リージョンセット: 米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)

    • EU リージョンセット: 欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (フランクフルト)

    • AP リージョンセット: アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)

  • MRSC グローバルテーブルには、リージョンセットをまたいだ設定は行えません。例えば、MRSC グローバルテーブルに、米国と欧州のリージョンセットの両方を含めることはできません。

  • MRSC グローバルテーブルでは、有効期限 (TTL) はサポートされていません。

  • ローカルセカンダリインデックス (LSI) は、MRSC グローバルテーブルではサポートされていません。

  • CloudWatch Contributor Insights の情報は、オペレーションが発生したリージョンについてのみ報告されます。

  • ローカルリージョンでは、レプリカまたは監視をホストする 2 番目のリージョンでクォーラムが確立できる限り、すべての読み取りおよび書き込みオペレーションを受け付けます。2 番目のリージョンが利用できない場合、ローカルリージョンでは、結果整合性のある読み込みのみを処理できます。

  • 万が一、リージョンが完全にオフラインになっても、その後オンラインに戻った際に、自動的にキャッチアップが開始されます。キャッチアップされるまで、キャッチアップリージョンのみへの書き込みオペレーションと強力な整合性のある読み込みオペレーションはエラーを返しますが、他のリージョンへのリクエストは通常どおり実行が続行されます。キャッチアップリージョンへの結果整合性のある読み込みオペレーションにより、これまでリージョンに伝搬されたデータが、リーダーノードとローカルレプリカ間で通常生じるローカル整合性動作に従って返ります。テーブルを同期状態に戻すために特別なアクションは必要ありません。

MREC DynamoDB グローバルテーブルのユースケース

MREC グローバルテーブルにより、以下の利点を得られます。

  • 低レイテンシーの読み取りオペレーション。データのコピーをエンドユーザーの近くに配置して、読み込みオペレーション中のネットワークレイテンシーを削減できます。キャッシュは ReplicationLatency 値と同じ最新の状態に保たれます。

  • 低レイテンシーの書き込みオペレーション。近くのリージョンに書き込むことで、ネットワークレイテンシーと書き込みにかかる時間を短縮できます。書き込みトラフィックは、競合が発生しないように慎重にルーティングする必要があります。ルーティングの手法の詳細については、「DynamoDB のルーティング戦略」を参照してください。

  • シームレスなリージョンの移行。新しいリージョンを追加してから古いリージョンを削除し、リージョン間でデプロイを移行できます。これに伴うデータレイヤーでのダウンタイムは発生しません。

MREC と MRSC のグローバルテーブルの両方で、以下の利点を得られます。

  • 回復力とディザスタリカバリの向上。リージョンのパフォーマンスが低下したり、完全に停止した場合は、そのリージョンから退避できます。退避とは、そのリージョンに送信されるリクエストの一部またはすべてを遠ざけることを意味します。また、グローバルテーブルを使用すると、月間稼働率の DynamoDB SLA が 99.99% から 99.999% に向上します。MREC を使用すると、目標復旧時点 (RPO) と目標復旧時間 (RTO) を秒単位で測定可能になります。MRSC を使用すると、RPO をゼロにすることができます。

    例えば、Fidelity Investments 社は、re:Invent 2022 で、注文管理システムでの DynamoDB グローバルテーブルの活用についてプレゼンテーションを行いました。同社の目標は、オンプレミス処理では到達できなかった規模で信頼性に優れた低レイテンシーの処理を実現すると同時に、アベイラビリティーゾーンやリージョンでの障害に対するレジリエンスを確保することでした。

レジリエンス確保とディザスタリカバリを目標とする場合に、MRSC テーブルを使用すると、テーブルへの書き込み時と、強力な整合性のある読み込み時のレイテンシーは増大しますが、RPO ゼロのサポートが可能です。MREC グローバルテーブルの場合は、レプリカ間で生じるレプリケーション遅延と同じ長さの RPO (レプリカリージョンにもよるが、通常は数秒) に対応できます。

結論とリソース

DynamoDB グローバルテーブルには、制御上の項目はほとんどありませんが、慎重な検討は必要です。書き込みモード、ルーティングモデル、および退避プロセスを決定する必要があります。すべてのリージョンにわたってアプリケーションをインストルメントし、グローバルヘルスを維持するためのルーティングの調整や退避に備える必要があります。その見返りとして、グローバルに分散させたデータセットで低レイテンシーの読み取りおよび書き込みオペレーションを行える上、99.999% の可用性も確保できるのです。

DynamoDB グローバルテーブルの詳細については、次のリソースを参照してください。