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

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

3a: AWS のサービス 

マルチリージョンアーキテクチャを設計する場合、使用される特定の AWS のサービスを理解する必要があります。1 つ目の側面は、サービスがマルチリージョンを有効にするためにどのような機能を備えているか、そしてマルチリージョンの目標を達成するためにソリューションを設計する必要があるかどうかを理解することです。例えば、Amazon Aurora と Amazon DynamoDB には、スタンバイリージョンにデータを非同期でレプリケートする機能があります。AWS のサービスの依存関係はすべて、ワークロードが実行されるすべてのリージョンで利用できる必要があります。使用するサービスが該当するリージョンで利用できることを確認するには、「AWS リージョン サービスリスト」を確認してください。 

3b: 内部およびサードパーティーの依存関係

ワークロードに内部依存関係がある場合は、そのワークロードが動作するリージョンから利用できることを確認してください。例えば、ワークロードが多数のマイクロサービスで構成されている場合は、ビジネス機能を構成するすべてのマイクロサービスに精通している必要があります。そこから、ワークロードが動作する各リージョンに、それらのマイクロサービスがすべてデプロイされていることを確認します。

ワークロード内のマイクロサービス間のクロスリージョンコールは推奨されず、リージョンの分離を維持する必要があります。これは、クロスリージョンの依存関係を作成すると、相関する障害の発生リスクが高まり、ワークロードを独立したリージョンで実装することで得られるメリットが損なわれるためです。オンプレミスの依存関係もワークロードの一部になる可能性があるため、プライマリリージョンが変更された場合にこれらの統合の特性がどのように変化するかを理解することが不可欠です。例えば、スタンバイリージョンがオンプレミス環境から離れた場所にある場合、レイテンシーの増加は悪影響を及ぼします。

Software as a Service (SaaS) ソリューション、Software Development Kit (SDK)、およびその他のサードパーティー製品の依存関係を理解し、これらの依存性が低下したり利用できなくなったりするシナリオを実行できれば、さまざまな障害モードでシステムチェーンがどのように動作し、機能するかについて、より多くの洞察を得ることができます。これらの依存関係は、AWS Secrets Manager やサードパーティーのボールトソリューション (Hashicorp など) を使用してシークレットを外部で管理する方法から、フェデレーテッドログイン用の IAM Identity Center に依存関係を持つ認証システムまで、アプリケーションコード内に存在する可能性があります。

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

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

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

ドメインネームシステム (DNS) は、トラフィックをプライマリリージョンからスタンバイリージョンに移すフェイルオーバーメカニズムとして一般的に使用されています。フェイルオーバーメカニズムが取るすべての依存関係を慎重に確認し、精査してください。例えば、ワークロードが Amazon Route 53 を使用している場合、コントロールプレーンが US-East-1 でホストされているということは、その特定のリージョンのコントロールプレーンに依存することになります。プライマリリージョンが US-East-1 の場合も、これをフェイルオーバーメカニズムの一部として使用することはお勧めしません。別のフェイルオーバーメカニズムを使用している場合は、そのメカニズムが想定どおりに動作しないシナリオを十分に理解する必要があります。この理解が確立されたら、不測の事態に備えるか、必要に応じて新しいメカニズムを開発します。フェイルオーバーを成功させるために使用できるアプローチについては、「Creating Disaster Recovery Mechanisms Using Amazon Route 53」を参照してください。

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

3d: 設定の依存関係

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

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

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

主なガイダンス