翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
グローバルテーブルのルーティング戦略
グローバルテーブルのデプロイで最も複雑な部分は、おそらくリクエストルーティングの管理です。リクエストは、まずエンドユーザーから、何らかの方法で経路が選定されたリージョンに送る必要があります。リクエストは、 AWS Lambda 関数、コンテナ、または Amazon Elastic Compute Cloud (Amazon EC2) ノードによってバックアップされたロードバランサーで構成されるコンピューティングレイヤーなど、そのリージョンの一部のサービスのスタックを検出します。また、別のデータベースを含む他のサービスも検出されます。このコンピューティングレイヤーは DynamoDB と通信します。そのためには、そのリージョンのローカルエンドポイントを使用する必要があります。グローバルテーブルのデータは、参加している他のすべてのリージョンにレプリケートされ、各リージョンには DynamoDB テーブルを中心に同様のサービスのスタックがあります。
グローバルテーブルは、さまざまなリージョンの各スタックに同じデータのローカルコピーを提供します。1 つのリージョンの 1 つのスタックを対象とした設計を行い、ローカルの DynamoDB テーブルに問題が発生した場合は、セカンダリリージョンの DynamoDB エンドポイントにリモート呼び出しを行うということも考えられます。これはベストプラクティスではありません。リージョンをまたいだ場合のレイテンシーは、ローカルアクセスの場合より 100 倍も高くなる可能性があります。 back-and-forth 一連の 5 つのリクエストは、ローカルで実行する場合はミリ秒、地球を横断する場合は秒かかる場合があります。エンドユーザーを別のリージョンにルーティングして処理することをお勧めします。回復性を確保するには、複数のリージョンにまたがるレプリケーションが必要です。コンピューティングレイヤーとデータレイヤーのレプリケーションです。
エンドユーザーリクエストをリージョンにルーティングして処理するには、さまざまな手法があります。適切な選択は、書き込みモードとフェイルオーバーに関する考慮事項によって異なります。このセクションでは、クライアント駆動型、コンピューティングレイヤー、Amazon Route 53、 の 4 つのオプションについて説明します AWS Global Accelerator。
トピック
