グローバルテーブルは、DynamoDB のグローバルフットプリントに基づいて構築され、フルマネージド、マルチリージョン、マルチアクティブのデータベースにより、大規模にスケールされたグローバルアプリケーションの高速なローカルの読み取り/書き込みパフォーマンスを実現します。グローバルテーブルでは、選択した AWS リージョン間でデータが自動的にレプリケートされます。グローバルテーブルは既存の DynamoDB API を使用するため、アプリケーションを変更する必要はありません。グローバルテーブルの使用に伴う前払い料金やコミットメントはなく、使用したリソース分のみの支払いで済みます。
トピック
DynamoDB グローバルテーブル設計の規範的ガイダンス
グローバルテーブルを効率的に使用するには、使用する書き込みモード、ルーティングモデル、退避プロセスなどの要素を慎重に検討する必要があります。すべてのリージョンにわたってアプリケーションを計測し、グローバルな健全性を維持するためのルーティングの調整や退避に備える必要があります。これにより、読み取りと書き込みが低レイテンシーで、サービスレベルアグリーメントが 99.999% のグローバルに分散されたデータセットが実現します。
DynamoDB グローバルテーブル設計に関する重要な事実
グローバルテーブルには、現行バージョンであるグローバルテーブルバージョン 2019.11.21 (現行) (「V2」とも呼ばれます) と グローバルテーブルバージョン 2017.11.29 (レガシー) (「V1」とも呼ばれます) の 2 つのバージョンがあります。このガイドは、現行バージョンの V2 のみを対象としています。
グローバルテーブルを使用しない場合、DynamoDB はリージョン別のサービスとなります。サービスは可用性が高く、リージョンでのインフラストラクチャの障害 (アベイラビリティーゾーン (AZ) 全体の障害を含む) に対する本質的な回復力を備えています。単一リージョンの DynamoDB テーブルは 99.99% の可用性 https://aws.amazon.com/dynamodb/sla/
サービスレベルアグリーメント (SLA) を提供します。 DynamoDB は、グローバルテーブルを使用することで、1 つのテーブルのデータを複数のリージョン間でレプリケートできます。マルチリージョンの DynamoDB テーブルは、99.999% の可用性 SLA を提供します。グローバルテーブルを適切に計画することは、リージョンの障害に対する回復力と耐性を備えたアーキテクチャの構築に役立ちます。
グローバルテーブルは、アクティブ-アクティブレプリケーションモデルを採用しています。DynamoDB の観点から見ると、各リージョンのテーブルは読み取りと書き込みのリクエストを同じように受け入れることができます。ローカルレプリカテーブルは、書き込みリクエストを受け取ると、バックグラウンドで他の参加リージョンに書き込みをレプリケートします。
項目は個別にレプリケートされます。1 回のトランザクションで更新した複数の項目を、まとめてレプリケートすることはできません。
ソースリージョンの各テーブルパーティションは、他のすべてのパーティションと並行して書き込みをレプリケートします。リモートリージョン内の書き込みの順序は、ソースリージョン内で発生した書き込みの順序と一致しない場合があります。テーブルパーティションの詳細については、ブログ記事「DynamoDB のスケーリング: パーティション、ホットキー、ヒートに応じた分割がパフォーマンスに与える影響
」を参照してください。 新しく書き込まれた項目は、通常、1 秒以内にすべてのレプリカテーブルに伝播されます。近くのリージョンにはより速く伝播される傾向があります。
Amazon CloudWatch は、リージョンのペアごとに
ReplicationLatencyメトリクスを提供します。到着した項目の到着時間と最初の書き込み時間を比較し、平均を算出することでメトリクスが計算されます。タイミングはソースリージョンの CloudWatch 内に保存されます。平均タイミングと最大タイミングを表示すると、平均および最悪の場合のレプリケーションラグを判断するのに役立ちます。このレイテンシーには SLA はありません。同じ項目が 2 つの異なるリージョンでほぼ同時に (この
ReplicationLatencyウィンドウ内で) 更新され、最初の書き込みがレプリケートされる前に次の書き込みが行われると、書き込みが競合する可能性があります。グローバルテーブルは、書き込みのタイムスタンプに基づく最終書き込み者優先メカニズムにより、このような競合を解決します。1 回目の書き込みよりも 2 回目の書き込みが「優先」されます。これらの競合は CloudWatch または AWS CloudTrail には記録されません。各項目には、最終書き込みタイムスタンプがプライベートシステムプロパティとして保持されます。最終書き込み者優先アプローチを実装するには、着信する項目のタイムスタンプが既存の項目のタイムスタンプよりも大きいことを要求する条件付き書き込みを使用します。
グローバルテーブルは、すべての項目をすべての参加リージョンにレプリケートします。複数の異なるレプリケーションスコープが必要な場合は、複数の異なるテーブルを作成し、テーブルごとに異なる参加リージョンを割り当てることができます。
レプリカリージョンがオフラインであったり、
ReplicationLatencyが高くなったりしても、ローカルリージョンへの書き込みは受け入れられます。ローカルテーブルは、各項目が成功するまで、リモートテーブルへの項目のレプリケーションを試行し続けます。万が一、リージョンが完全にオフラインになった場合でも、後でオンラインに戻ったときに、すべての保留中のアウトバウンドレプリケーションとインバウンドレプリケーションが再試行されます。テーブルを同期状態に戻すために特別なアクションは必要ありません。最終書き込み者優先メカニズムにより、データは結果的に整合します。
DynamoDB テーブルには、いつでも新しいリージョンを追加できます。DynamoDB は、初期同期と進行中のレプリケーションを処理します。リージョンを削除すると、それが元のリージョンであっても、そのリージョンのテーブルのみが削除されます。
DynamoDB にはグローバルエンドポイントはありません。すべてのリクエストは、リージョンのエンドポイントに対して行います。このエンドポイントからリージョンのローカルなグローバルテーブルインスタンスにアクセスします。
DynamoDB への呼び出しはリージョンを越えないようにします。ベストプラクティスとして、1 つのリージョンのコンピューティングレイヤーは、そのリージョンのローカル DynamoDB エンドポイントにのみ直接アクセスするようにします。リージョン内で問題が検出された場合は、問題が DynamoDB レイヤーにあるか周囲のスタックにあるかにかかわらず、エンドユーザーのトラフィックを別のリージョンでホストされている別のコンピューティングレイヤーにルーティングする必要があります。グローバルテーブルのレプリケーションのおかげで、別のリージョンには、ローカルで使用する同じデータのローカルコピーが既に存在します。状況によっては、あるリージョンのコンピューティングレイヤーから別のリージョンのコンピューティングレイヤーにリクエストを渡して処理することがありますが、この場合、リモート DynamoDB エンドポイントに直接アクセスすべきではありません。この特別なユースケースの詳細については、「コンピューティングレイヤーのリクエストルーティング」を参照してください。
DynamoDB グローバルテーブルのユースケース
グローバルテーブルには、以下のような一般的な利点があります。
読み取りレイテンシーの短縮。データのコピーをエンドユーザーの近くに配置して、読み取り時のネットワークレイテンシーを短縮できます。キャッシュは
ReplicationLatency値と同じ最新の状態に保たれます。書き込みレイテンシーの短縮。近くのリージョンに書き込むことで、ネットワークレイテンシーと書き込みにかかる時間を短縮できます。書き込みトラフィックは、競合が発生しないように慎重にルーティングする必要があります。ルーティングの手法の詳細については、「DynamoDB グローバルテーブルを使用したリクエストルーティング」を参照してください。
回復力とディザスタリカバリの向上。リージョンのパフォーマンス低下や完全な停止が発生した場合、リージョンから退避する (そのリージョンへのリクエストの一部またはすべてを移動する) ことができます。これに伴う目標復旧時点 (RPO) と目標復旧時間 (RTO) は秒単位で測定されます。また、グローバルテーブルを使用すると、DynamoDB の SLA
が 99.99% から 99.999% に向上します。 シームレスなリージョンの移行。新しいリージョンを追加してから古いリージョンを削除し、リージョン間でデプロイを移行できます。これに伴うデータレイヤーでのダウンタイムは発生しません。例えば、注文管理システムに DynamoDB グローバルテーブルを使用すると、AZ やリージョンの障害に対する回復力を維持しながら、低レイテンシーの処理を高い信頼性とスケールで実現できます。
