マルチリージョンの基本 3: ワークロードの依存関係を理解する

特定のワークロードには、使用されるリージョン、内部依存関係、サードパーティーの依存関係、ネットワーク依存関係、証明書、キー、シークレット、パラメータなど AWS のサービス 、複数の依存関係がある場合があります。障害シナリオ中にワークロードを確実に運用するには、プライマリリージョンとスタンバイリージョンの間に依存関係がない必要があります。それぞれが他のリージョンとは独立して運用できる必要があります。これを実現するには、ワークロード内のすべての依存関係を精査して、各リージョン内で利用可能であることを確認します。これは、プライマリリージョンの障害がスタンバイリージョンに影響を与えないために必要です。さらに、依存関係が低下した状態または完全に利用できない場合のワークロードの動作を理解し、これを適切に処理するソリューションを設計できるようにする必要があります。

3.a: AWS のサービス

マルチリージョンアーキテクチャを設計するときは、 AWS のサービス 使用する 、それらのサービスのマルチリージョン機能、およびマルチリージョンの目標を達成するために設計する必要があるソリューションを理解することが重要です。例えば、Amazon Aurora と Amazon DynamoDB は、スタンバイリージョンにデータを非同期的にレプリケートできます。すべての AWS のサービス 依存関係は、ワークロードを実行するすべてのリージョンで利用できる必要があります。使用するサービスが目的のリージョンで利用できることを確認するには、AWS のサービス リージョン別の リストを確認します。

3.b: 内部依存関係とサードパーティー依存関係

すべてのワークロードの内部依存関係が、運用元のリージョンで使用可能であることを確認します。たとえば、ワークロードが多数のマイクロサービスで構成されている場合は、ビジネス機能を構成するすべてのマイクロサービスを特定し、それらのすべてのマイクロサービスがワークロードが動作する各リージョンにデプロイされていることを確認します。または、使用できなくなったマイクロサービスを正常に処理するための戦略を定義します。

ワークロード内のマイクロサービス間のクロスリージョン呼び出しは推奨されず、リージョン分離を維持する必要があります。これは、クロスリージョン依存関係を作成すると、相関障害のリスクが高まり、ワークロードの分離されたリージョン実装の利点が相殺されるためです。オンプレミスの依存関係もワークロードの一部である可能性があるため、プライマリリージョンが変更された場合、これらの統合の特性がどのように変化する可能性があるかを理解することが重要です。たとえば、スタンバイリージョンがオンプレミス環境から遠くにある場合、レイテンシーの増加は悪影響をもたらす可能性があります。

Software as a Service (SaaS) ソリューション、Software Development Kit (SDKs)、その他のサードパーティー製品の依存関係を理解し、これらの依存関係が低下したり利用できなくなったりするシナリオを実行できると、さまざまな障害モードでのシステムチェーンの動作や動作をより深く把握できます。これらの依存関係は、 を使用して外部でシークレットを管理するなど、アプリケーションコード内にある場合やAWS Secrets Manager、サードパーティーのボールトソリューション (HashiCorp など）、またはフェデレーティッドログインAWS IAM Identity Centerの に依存する認証システムが含まれる場合があります。

依存関係に関して冗長性があると、耐障害性を高めることができます。SaaS ソリューションまたはサードパーティーの依存関係が AWS リージョン ワークロードと同じプライマリを使用している場合は、ベンダーと協力して、その耐障害性体制がワークロードの要件と一致するかどうかを判断します。

さらに、サードパーティー製アプリケーションなど、ワークロードとその依存関係との間で共有される運命にも注意してください。フェイルオーバー後にセカンダリリージョンで (またはセカンダリリージョンから) 依存関係が利用できない場合、ワークロードは完全には回復しない可能性があります。

3.c: フェイルオーバーメカニズム

DNS は、トラフィックをプライマリリージョンからスタンバイリージョンにシフトするためのフェイルオーバーメカニズムとして一般的に使用されます。フェイルオーバーメカニズムが取るすべての依存関係を慎重に確認し、精査してください。例えば、ワークロードが Amazon Route 53 を使用している場合、コントロールプレーンが でホストされていることを理解することは、その特定のリージョンのコントロールプレーンに依存しているus-east-1ことを意味します。これは、プライマリリージョンが単一障害点を作成するus-east-1ため、フェイルオーバーメカニズムの一部としても推奨されません。別のフェイルオーバーメカニズムを使用する場合は、フェイルオーバーが期待どおりに機能しないシナリオを深く理解し、必要に応じて緊急時に備えるか、新しいメカニズムを開発する必要があります。ブログ記事「Amazon Route 53 を使用したディザスタリカバリメカニズムの作成」を参照して、正常にフェイルオーバーするために使用できるアプローチを確認してください。

前のセクションで説明したように、ビジネス機能の一部であるすべてのマイクロサービスは、ワークロードがデプロイされる各リージョンで利用できる必要があります。フェイルオーバー戦略の一環として、ビジネス機能の一部であるすべてのマイクロサービスがフェイルオーバーして、クロスリージョン呼び出しの可能性を排除する必要があります。または、マイクロサービスが個別にフェイルオーバーした場合、マイクロサービスがクロスリージョン呼び出しを行うなど、望ましくない動作が発生する可能性があります。これによりレイテンシーが発生し、クライアントのタイムアウト中にワークロードが使用できなくなる可能性があります。

3.d: 設定の依存関係

証明書、キー、シークレット、Amazon マシンイメージ (AMIs)、コンテナイメージ、パラメータは、マルチリージョンアーキテクチャの設計に必要な依存関係分析の一部です。可能な限り、各リージョン内でこれらのコンポーネントをローカライズして、これらの依存関係のリージョン間で運命を共有しないようにすることをお勧めします。たとえば、証明書の有効期限を変更して、期限切れの証明書 (アラームを「事前に通知」に設定) が複数のリージョンに影響を与えるシナリオを防ぐ必要があります。

暗号化キーとシークレットもリージョン固有のものでなければなりません。これにより、キーまたはシークレットのローテーションにエラーが発生した場合、影響は特定のリージョンに限定されます。

最後に、ワークロードが特定のリージョンで取得できるように、すべてのワークロードパラメータをローカルに保存する必要があります。

主なガイダンス

• マルチリージョンアーキテクチャは、リージョン間の物理的および論理的な分離からメリットを得られます。アプリケーションレイヤーでクロスリージョンの依存関係を導入すると、このメリットは損なわれます。このような依存関係は避けてください。

• フェイルオーバー制御は、プライマリリージョンに依存することなく機能する必要があります。

• フェイルオーバーは、クロスリージョン呼び出しのレイテンシーと依存関係が増加する可能性を排除するために、ユーザージャーニー全体で調整する必要があります。