マルチリージョンの基本 2: データについて

マルチリージョンアーキテクチャを採用する場合、データの管理は簡単な問題ではありません。リージョン間の地理的距離は、リージョン間でデータをレプリケートするのにかかる時間として現れる不可避のレイテンシーを課します。可用性、データ整合性、およびマルチリージョンアーキテクチャを使用するワークロードへのレイテンシーの増加のトレードオフが必要になります。非同期レプリケーションと同期レプリケーションのどちらを使用するかにかかわらず、レプリケーションテクノロジーが課す動作の変更を処理するようにアプリケーションを変更する必要があります。データ整合性とレイテンシーに関する課題により、単一のリージョン用に設計された既存のアプリケーションを取得し、マルチリージョンにすることは非常に困難です。特定のワークロードのデータ整合性要件とデータアクセスパターンを理解することは、トレードオフを比較検討するのに重要です。

2.a: データ整合性要件を理解する

CAP 定理は、データ整合性、可用性、ネットワークパーティション間のトレードオフについて推論するためのリファレンスを提供します。これらの要件のうち、ワークロードで同時に満たすことができるのは 2 つだけです。定義上、マルチリージョンアーキテクチャにはリージョン間のネットワークパーティションが含まれているため、可用性と整合性を選択する必要があります。

リージョン間でデータの可用性を選択した場合、トランザクション書き込みオペレーション中に大きなレイテンシーが発生することはありません。リージョン間でコミットされたデータの非同期レプリケーションに依存すると、レプリケーションが完了するまでリージョン間の一貫性が低下するためです。非同期レプリケーションでは、プライマリリージョンで障害が発生した場合、書き込みオペレーションがプライマリリージョンからのレプリケーションを保留中になる可能性が高くなります。これにより、レプリケーションが再開されるまで最新のデータが使用できなくなり、中断が発生したリージョンからレプリケートされなかった処理中のトランザクションを処理するための調整プロセスが必要になるシナリオが発生します。このシナリオでは、ビジネスロジックを理解し、トランザクションを再生したり、リージョン間でデータストアを比較したりする特定のプロセスを作成する必要があります。

非同期レプリケーションが優先されるワークロードでは、Amazon Aurora や Amazon DynamoDB などのサービスを非同期クロスリージョンレプリケーションに使用できます。Amazon Aurora グローバルデータベースと Amazon DynamoDB グローバルテーブルには、レプリケーションラグのモニタリングに役立つデフォルトの Amazon CloudWatchmetrics があります。Aurora グローバルデータベースは、データが書き込まれる 1 つのプライマリリージョンと、最大 5 つの読み取り専用セカンダリリージョンで構成されます。DynamoDB グローバルテーブルは、データの書き込みと読み取りを行う任意の数のリージョンにわたるマルチアクティブレプリカテーブルで構成されます。

イベント駆動型アーキテクチャを活用するようにワークロードをエンジニアリングすることは、マルチリージョン戦略の利点です。これは、ワークロードがデータの非同期レプリケーションを受け入れ、イベントを再生することで状態を再構築できることを意味します。ストリーミングおよびメッセージングサービスはメッセージペイロードデータを 1 つのリージョンでバッファするため、リージョンフェイルオーバーまたはフェイルバックプロセスには、クライアント入力データフローをリダイレクトするメカニズムを含める必要があります。このプロセスでは、中断が発生したリージョンに保存されている処理中または未配信のペイロードも調整する必要があります。

CAP 整合性要件を選択し、リージョン間で同期的にレプリケートされたデータベースを使用して、複数のリージョンから同時に実行されるアプリケーションをサポートする場合は、データ損失のリスクを排除し、リージョン間でデータを同期させます。ただし、書き込みは複数のリージョンにコミットする必要があり、リージョンは互いに数百マイルまたは数千マイルになる可能性があるため、レイテンシー特性は高くなります。アプリケーション設計では、このレイテンシー特性を考慮する必要があります。さらに、同期レプリケーションは、書き込みを成功させるために複数のリージョンにコミットする必要があるため、相関障害が発生する可能性があります。1 つのリージョン内に障害がある場合は、書き込みを成功させるためのクォーラムを作成する必要があります。これには通常、3 つのリージョンにデータベースを設定し、3 つのリージョンのうち 2 つのリージョンのクォーラムを確立する必要があります。Paxos などのテクノロジーは、データを同期的にレプリケートしてコミットするのに役立ちますが、開発者の多大な投資が必要です。

強固な整合性要件を満たすため、書き込みに複数のリージョン間での同期レプリケーションが含まれる場合、書き込みレイテンシーは桁違いに大きくなります。書き込みレイテンシーを長くすることは、アプリケーションのタイムアウトや再試行戦略を再検討するなど、大きな変更を加えることなく、通常アプリケーションに改良できるものではありません。理想的には、アプリケーションを最初に設計するときに考慮する必要があります。同期レプリケーションが優先されるマルチリージョンワークロードでは、 AWS Partner ソリューションが役立ちます。

2.b: データアクセスパターンを理解する

ワークロードデータアクセスパターンは、読み込み多用または書き込み多用です。特定のワークロードのこの特性を理解することは、適切なマルチリージョンアーキテクチャを選択するのに役立ちます。

完全に読み取り専用の静的コンテンツなどの読み取り負荷の高いワークロードでは、書き込み負荷の高いワークロードと比較して、エンジニアリングの複雑さが少ないアクティブ/アクティブマルチリージョンアーキテクチャを実現できます。コンテンツ配信ネットワーク (CDN) を使用してエッジで静的コンテンツを提供すると、エンドユーザーに最も近いコンテンツをキャッシュすることで可用性が確保されます。Amazon CloudFront 内でオリジンフェイルオーバーなどの機能セットを使用すると、これを実現できます。もう 1 つのオプションは、ステートレスコンピューティングを複数のリージョンにデプロイし、DNS を使用してユーザーを最も近いリージョンにルーティングしてコンテンツを読み込ませることです。これを実現するには、位置情報ルーティングポリシーで Amazon Route 53 を使用できます。

読み込みトラフィックの割合が書き込みトラフィックよりも多い読み込み負荷の高いワークロードでは、読み取りローカルの書き込みグローバル戦略を使用できます。つまり、すべての書き込みリクエストは特定のリージョンのデータベースに送信され、データは他のすべてのリージョンに非同期的にレプリケートされ、読み取りは任意のリージョンで実行できます。このアプローチでは、書き込みのクロスリージョンレプリケーションのレイテンシーが増加するとローカル読み取りが古くなる可能性があるため、結果整合性を受け入れるワークロードが必要です。

Aurora グローバルデータベースは、すべての読み取りトラフィックをローカルでのみ処理できるスタンバイリージョンでリードレプリカをプロビジョニングし、書き込みトラフィックを処理するために特定のリージョンに単一のプライマリデータストアをプロビジョニングするのに役立ちます。データはプライマリデータベースからスタンバイデータベース (リードレプリカ) に非同期的にレプリケートされ、オペレーションをスタンバイリージョンにフェイルオーバーする必要がある場合は、スタンバイデータベースをプライマリに昇格させることができます。このアプローチでは DynamoDB を使用することもできます。DynamoDB グローバルテーブルは、リージョン間でレプリカテーブルをプロビジョニングできます。リージョンごとにスケーリングして、任意のボリュームのローカル読み取りまたは書き込みトラフィックをサポートできます。アプリケーションが 1 つのリージョンのレプリカテーブルにデータを書き込むと、DynamoDB はその書き込みを他の リージョンの他のレプリカテーブルに自動的に伝搬します。この設定では、データは定義されたプライマリリージョンからスタンバイリージョンのレプリカテーブルに非同期的にレプリケートされます。任意のリージョンのレプリカテーブルは常に書き込みを受け入れることができるため、スタンバイリージョンをプライマリに昇格させることはアプリケーションレベルで管理されます。ここでも、ワークロードは結果整合性を受け入れる必要があります。そのため、最初からこのために設計されていない場合は書き直す必要がある場合があります。

書き込み負荷の高いワークロードでは、プライマリリージョンを選択し、スタンバイリージョンにフェイルオーバーする機能をワークロードに組み込む必要があります。アクティブ/アクティブアプローチと比較して、プライマリスタンバイアプローチには追加のトレードオフがあります。これは、アクティブ/アクティブアーキテクチャの場合、リージョンへのインテリジェントなルーティングを処理し、セッションアフィニティを確立し、べき等なトランザクションを確保し、潜在的な競合を処理するためにワークロードを書き直す必要があるためです。

回復力のためにマルチリージョンアプローチを使用するほとんどのワークロードでは、アクティブ/アクティブアプローチは必要ありません。シャーディング戦略を使用すると、クライアントベース全体で障害の影響範囲を制限することで、回復力を高めることができます。クライアントベースを効果的にシャードできる場合は、シャードごとに異なるプライマリリージョンを選択できます。たとえば、クライアントの半分がリージョン 1 に、半分がリージョン 2 に整列するように、クライアントをシャードできます。リージョンをセルとして扱うことで、マルチリージョンセルアプローチを作成できるため、ワークロードへの影響の範囲が縮小されます。詳細については、このアプローチに関する AWS re:Invent プレゼンテーションを参照してください。

シャーディングアプローチとプライマリスタンバイアプローチを組み合わせて、シャードのフェイルオーバー機能を提供できます。フェイルオーバー後のデータストアのトランザクション整合性を確保するために、テスト済みのフェイルオーバープロセスをワークロードに設計し、データ調整のプロセスも設計する必要があります。これらについては、このガイドの後半で詳しく説明します。

主なガイダンス

• 障害が発生すると、レプリケーション待ちの書き込みがスタンバイリージョンにコミットされない可能性が高くなります。レプリケーションが再開されるまで、データは使用できません (非同期レプリケーションの場合)。

• フェイルオーバーの一環として、非同期レプリケーションを使用するデータストアに対してトランザクション整合性のある状態を維持するために、データ調整プロセスが必要になります。これには特定のビジネスロジックが必要であり、データストア自体によって処理されるものではありません。

• 強力な整合性が必要な場合は、同期的にレプリケートするデータストアの必要なレイテンシーを許容するようにワークロードを変更する必要があります。