翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# マルチリージョンの基本 2: データについて
マルチリージョンアーキテクチャを採用する場合、データの管理は簡単な問題ではありません。リージョン間の地理的距離により、リージョン間でデータをレプリケートするのにかかる時間として明らかになる不可避のレイテンシーが課されます。可用性、データ整合性、およびマルチリージョンアーキテクチャを使用するワークロードへのレイテンシーの増加のトレードオフが必要になります。非同期レプリケーションと同期レプリケーションのどちらを使用するかにかかわらず、レプリケーションテクノロジーが課す動作の変更を処理するようにアプリケーションを変更する必要があります。データ整合性とレイテンシーに関する課題により、単一のリージョン用に設計された既存のアプリケーションを取得し、マルチリージョンにすることは非常に困難です。特定のワークロードのデータ整合性要件とデータアクセスパターンを理解することは、トレードオフを比較検討するのに重要です。
## 2.a: データ整合性要件を理解する
[CAP 定理](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/cap-theorem.html)は、データ整合性、可用性、ネットワークパーティション間のトレードオフについて推論するためのリファレンスを提供します。これらの要件のうち、ワークロードで同時に満たすことができるのは 2 つだけです。定義上、マルチリージョンアーキテクチャにはリージョン間のネットワークパーティションが含まれているため、可用性と整合性を選択する必要があります。
リージョン間でデータの可用性を選択した場合、トランザクション書き込みオペレーション中に大きなレイテンシーが発生することはありません。リージョン間でコミットされたデータの非同期レプリケーションに依存すると、レプリケーションが完了するまでリージョン間の整合性が低下するためです。非同期レプリケーションでは、プライマリリージョンで障害が発生した場合、書き込みオペレーションがプライマリリージョンからのレプリケーションを保留中になる可能性が高くなります。これにより、レプリケーションが再開されるまで最新のデータが使用できず、中断が発生したリージョンからレプリケートされなかった処理中のトランザクションを処理するための調整プロセスが必要になるシナリオが発生します。このシナリオでは、ビジネスロジックを理解し、トランザクションを再生したり、リージョン間でデータストアを比較したりするための特定のプロセスを作成する必要があります。
非同期レプリケーションが優先されるワークロードでは、 [Amazon Aurora](https://aws.amazon.com/rds/aurora/) や [Amazon DynamoDB ](https://aws.amazon.com/dynamodb/)などのサービスを非同期クロスリージョンレプリケーションに使用できます。 [Amazon Aurora グローバルデータベース](https://aws.amazon.com/rds/aurora/global-database/) と [Amazon DynamoDB グローバルテーブル](https://aws.amazon.com/dynamodb/global-tables/) の両方に、レプリケーションラグのモニタリングに役立つデフォルトの [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) メトリクスがあります。Aurora グローバルデータベースは、データが書き込まれる 1 つの プライマリリージョンと、最大 5 つの読み取り専用 セカンダリ リージョンで構成されます。DynamoDB グローバルテーブルは、データの書き込みと読み取りを行う任意の数のリージョンにわたるマルチアクティブレプリカテーブルで構成されます。
イベント駆動型アーキテクチャを活用するようにワークロードをエンジニアリングすることは、マルチリージョン戦略の利点です。これは、ワークロードがデータの非同期レプリケーションを受け入れ、イベントを再生することで状態を再構築できることを意味します。ストリーミングおよびメッセージングサービスはメッセージペイロードデータを 1 つのリージョンでバッファするため、リージョンフェイルオーバーまたはフェイルバックプロセスには、クライアント入力データフローをリダイレクトするメカニズムを含める必要があります。このプロセスでは、中断が発生したリージョンに保存されている処理中または未配信のペイロードも調整する必要があります。
CAP 整合性要件を選択し、リージョン間で同期的にレプリケートされたデータベースを使用して、複数のリージョンから同時に実行されるアプリケーションをサポートする場合は、データ損失のリスクを排除し、リージョン間でデータを同期させます。ただし、書き込みは複数のリージョンにコミットする必要があり、リージョンは互いに数百または数千マイルになる可能性があるため、レイテンシー特性は高くなります。アプリケーション設計では、このレイテンシー特性を考慮する必要があります。さらに、同期レプリケーションでは、書き込みを成功させるために複数のリージョンにコミットする必要があるため、相関する障害が発生する可能性があります。1 つのリージョン内に障害がある場合は、書き込みを成功させるためのクォーラムを作成する必要があります。これには、通常、3 つのリージョンにデータベースを設定し、3 つのリージョンのうち 2 つのクォーラムを確立する必要があります。[Paxos](https://www.cs.yale.edu/homes/aspnes/pinewiki/Paxos.html) などの テクノロジーは、データを同期的にレプリケートしてコミットするのに役立ちますが、開発者の多大な投資が必要です。
強固な整合性要件を満たすため、書き込みに複数のリージョン間での同期レプリケーションが含まれる場合、書き込みレイテンシーは桁違いに大きくなります。書き込みレイテンシーを長くすることは、通常、アプリケーションのタイムアウトや再試行戦略を再検討するなど、大きな変更を加えることなくアプリケーションに改良できるものではありません。理想的には、アプリケーションを最初に設計するときに考慮する必要があります。同期レプリケーションが優先されるマルチリージョンワークロードでは、 [AWS Partner ソリューション](https://partners.amazonaws.com/)が役立ちます。
## 2.b: データアクセスパターンを理解する
ワークロードデータアクセスパターンは、*読み込み多用*または*書き込み多用*です。特定のワークロードのこの特性を理解することは、適切なマルチリージョンアーキテクチャを選択するのに役立ちます。
完全に読み取り専用の静的コンテンツなどの読み取り負荷の高いワークロードでは、書き込み負荷の高いワークロードと比較して、エンジニアリングの複雑さが少ない[アクティブ/アクティブ](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/)マルチリージョンアーキテクチャを実現できます。コンテンツ配信ネットワーク (CDN) を使用してエッジで静的コンテンツを提供すると、エンドユーザーに最も近いコンテンツをキャッシュすることで可用性を確保できます。[Amazon CloudFront 内でオリジンフェイルオーバー](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/high_availability_origin_failover.html)などの機能セットを使用すると、これを実現できます。もう 1 つのオプションは、ステートレスコンピューティングを複数のリージョンにデプロイし、DNS を使用してユーザーを最も近いリージョンにルーティングしてコンテンツを読み込ませることです。これを実現するには[、位置情報ルーティングポリシーで Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html) を使用できます。
読み込みトラフィックの割合が書き込みトラフィックよりも大きい読み込み負荷の高いワークロードでは、 [読み込みローカル書き込みグローバル 戦略](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/)を使用できます。つまり、すべての書き込みリクエストは特定のリージョンのデータベースに送信され、データは他のすべてのリージョンに非同期的にレプリケートされ、読み取りは任意のリージョンで実行できます。このアプローチでは、書き込みのクロスリージョンレプリケーションのレイテンシーが増加するとローカル読み取りが古くなる可能性があるため、ワークロードは結果整合性を受け入れる必要があります。
[Aurora グローバルデータベース](https://aws.amazon.com/blogs/database/improving-business-continuity-with-amazon-aurora-global-database/) は、すべての [読み取りトラフィックをローカルでのみ処理できるスタンバイリージョンでリードレプリカ](https://aws.amazon.com/rds/features/read-replicas/) をプロビジョニングし、書き込みトラフィックを処理するために特定のリージョンに単一のプライマリデータストアをプロビジョニングするのに役立ちます。データはプライマリデータベースからスタンバイデータベース (リードレプリカ) に非同期的にレプリケートされ、オペレーションをスタンバイリージョンにフェイルオーバーする必要がある場合、スタンバイデータベースをプライマリに昇格させることができます。このアプローチでは DynamoDB を使用することもできます。[DynamoDB グローバルテーブル ](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html)は、リージョン間で [レプリカテーブル](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/V2globaltables_HowItWorks.html)をプロビジョニングできます。リージョンごとにスケーリングして、任意のボリュームのローカル読み取りまたは書き込みトラフィックをサポートできます。アプリケーションが 1 つのリージョンのレプリカテーブルにデータを書き込むと、DynamoDB はその書き込みを他の リージョンの他のレプリカテーブルに自動的に伝搬します。この設定では、データは定義されたプライマリリージョンからスタンバイリージョンのレプリカテーブルに非同期的にレプリケートされます。どのリージョンのレプリカテーブルでも書き込みを受け付けることができるため、スタンバイリージョンのプライマリへの昇格はアプリケーションレベルで管理されます。ここでも、ワークロードは結果整合性を受け入れる必要があります。そのため、最初から設計されていない場合は書き直す必要がある場合があります。
書き込み負荷の高いワークロードの場合、プライマリリージョンを選択し、スタンバイリージョンにフェイルオーバーする機能をワークロードに組み込む必要があります。アクティブ/アクティブアプローチと比較して、[プライマリスタンバイ](https://aws.amazon.com/rds/features/multi-az/)アプローチには追加のトレードオフがあります。これは、アクティブ/アクティブアーキテクチャの場合、リージョンへのインテリジェントなルーティングを処理し、セッションアフィニティを確立し、べき等なトランザクションを確保し、潜在的な競合を処理するためにワークロードを書き直す必要があるためです。
回復力のためにマルチリージョンアプローチを使用するほとんどのワークロードは、アクティブ/アクティブアプローチを必要としません。[シャーディング](https://aws.amazon.com/what-is/database-sharding/)戦略を使用すると、クライアントベース全体で障害の影響範囲を制限することで、耐障害性を高めることができます。クライアントベースを効果的にシャードできる場合は、シャードごとに異なるプライマリリージョンを選択できます。例えば、クライアントの半分がリージョン 1 に、半分がリージョン 2 に整列するように、クライアントをシャードできます。リージョンをセルとして扱うことで、マルチリージョンセルアプローチを作成できます。これにより、ワークロードへの影響の範囲が縮小されます。詳細については、このアプローチに関する [AWS re:Invent プレゼンテーション](https://d1.awsstatic.com/events/reinvent/2019/REPEAT_1_Reducing_blast_radius_with_cell-based_architectures_ARC411-R1.pdf)を参照してください。
シャーディングアプローチとプライマリスタンバイアプローチを組み合わせて、シャードのフェイルオーバー機能を提供できます。フェイルオーバー後のデータストアのトランザクション整合性を確保するために、テスト済みのフェイルオーバープロセスをワークロードに設計し、データ調整のプロセスも設計する必要があります。これらについては、このガイドの後半で詳しく説明します。
## 主なガイダンス
+ 障害が発生すると、レプリケーション待ちの書き込みがスタンバイリージョンにコミットされない可能性が高くなります。レプリケーションが再開されるまで、データは使用できません (非同期レプリケーションの場合)。
+ フェイルオーバーの一環として、非同期レプリケーションを使用するデータストアでトランザクション整合性のある状態を維持するために、データ調整プロセスが必要になります。これには特定のビジネスロジックが必要であり、データストア自体によって処理されるものではありません。
+ 強力な整合性が必要な場合は、同期的にレプリケートするデータストアの必要なレイテンシーを許容するようにワークロードを変更する必要があります。