地理的に分散されたアーキテクチャを設計する

Azure はグローバル システムです。 複数の Azure リージョンに存在するアーキテクチャを設計することで、リージョン全体の災害にも耐えるアプリケーションを構築できます。

出荷追跡ポータルは、スケーリングできるさまざまな Azure リソースを使用して構築されているため、スケーラブルです。 また、コンポーネントに複数のインスタンスが含まれる可能性があるため、多くの障害に対しても回復性があります。 ただし、ポータルが米国東部 Azure リージョンに完全に含まれているため、大規模な災害によって中断が発生する可能性があることを取締役会が懸念しています。 米国東部で障害が発生した場合に 2 番目のリージョンにフェールオーバーできる変更されたアーキテクチャを提案する必要があります。

ここでは、地理的に分散されたアプリケーションをサポートするようにアプリケーションのアーキテクチャを調整する方法について説明します。 また、このようなアーキテクチャがビジネス クリティカルなアプリケーションに有利である理由も確認します。

元の Web アプリのアーキテクチャ

追跡ポータルのアーキテクチャ設計と、ソリューションで使用されるコンポーネントについて見てみましょう。 すべての部分の使用方法を理解したら、geo 冗長シナリオでこれらの各コンポーネントをサポートする方法を調査できます。

追跡ポータルの設計は、次の図に示す参照アーキテクチャに基づいています。

アプリケーションで 1 つの Azure リソース グループを使用する方法に注目してください。 このリソース グループを使用すると、すべてのリソースを論理的にグループ化して管理でき、管理が簡素化されます。 このリソース グループを米国東部リージョンにデプロイすることを選択しました。 リソース グループでは、含まれているリソースに同じ Azure リージョンを使用する制限はありませんが、アプリケーションにデプロイされているすべてのリソースに対して米国東部リージョンを使用することにしました。

アプリケーションでは、Azure リソースの 3 つのカテゴリを使用します。 各カテゴリを見て、使用中のリソースを確認しましょう。

ネットワーク コンポーネント

追跡ポータルでは、次のネットワーク サービスが使用されます。

アプリケーション コンポーネント

追跡ポータルでは、次のサービスを使用して、コード、キャッシュ、および中間ストレージの要件をサポートします。

データ ストレージ コンポーネント

追跡ポータルでは、次の永続化されたストレージ サービスが使用されます。

元のアーキテクチャに関する問題

追跡ポータルの既存のアーキテクチャは、スケーラビリティと可用性を実現するように設計されています。

たとえば、需要が高く、ユーザー Web 要求への応答が遅い場合は、App Service でフロントエンド Web アプリのインスタンスを追加することを検討できます。 ここでは、Application Gateway は、これらの新しく作成されたインスタンスに要求をルーティングできます。

ただし、アーキテクチャ設計に克服する課題がある、または失敗するシナリオもあります。 追跡ポータルへの影響について理解を深めるために、各シナリオを見てみましょう。

リージョンの障害

重要なイベントの中には、Azure リージョン全体を中断する可能性があります。 Azure データセンターは回復性が高いように設計されていますが、ハリケーンや洪水などの大規模な気象イベントによって、リージョンからのサービスが中断される可能性があります。

これらのイベントは異常な出来事であり、多くの企業はそのリスクを維持できると感じています。 ただし、地域の障害で追跡ポータルが無効になるという高リスクの結果があり、会社の重役チームはそのリスクを排除することを決定しました。

サービス レベル アグリーメント

ほとんどの Azure サービスでは、サービス レベル アグリーメント (SLA) またはアップタイムの保証が提供されています。 複数の Azure サービスで構成されるアプリケーション アーキテクチャを設計する場合、アプリの全体的な SLA は、他のすべてのサービス SLA の複合として計算されます。

この SLA は、コンポーネント サービスの SLA を掛け合わせて計算します。 たとえば、アプリが Azure App Service (99.95% SLA) と Microsoft Entra ID (99.9% SLA) で構成されているとします。 最終的に計算される SLA は 99.85%です。

この割合のアップタイムがアプリケーションに十分でない場合は、アプリケーションを別のリージョンにフェールオーバーするように調整できます。

グローバル、リージョン、および構成可能なコンポーネント

この設計では、一部のコンポーネントは既定でグローバルであり、リージョンの障害に対して脆弱ではありません。

一部のコンポーネントは、Application Gateway など、1 つのリージョンに限定されます。 これらの種類のコンポーネントの代替サービスを選択する必要があります。

一部のコンポーネントは、複数のリージョンをサポートするように構成できます。 たとえば、静的コンテンツを格納する Azure Storage アカウントで Geo-Redundant Storage (GRS) オプションを使用できます。 GRS は BLOB を別のリージョンにレプリケートします。

次の表に、グローバル、リージョン、および構成可能なコンポーネントを示します。

提案された分散アーキテクチャ

いくつかの調査の後、次の図に示すようにアーキテクチャを提案します。

この設計では、アクティブなリージョン (米国東部) とスタンバイ リージョン (米国西部) があります。 米国東部リージョンは、通常の状況でコンポーネントによるすべての要求を処理します。 障害が原因でリージョン障害が発生した場合、アプリケーションは米国西部リージョンにフェールオーバーします。

元のアーキテクチャを変更した方法を大まかに見てみましょう。 これらの変更については、後のユニットで詳しく説明します。

ネットワーク

Azure DNS と Azure CDN は既定でグローバル システムであり、リージョンの障害に対して既に回復性があります。 私たちはそれらを所定の位置に残します。

Azure Application Gateway を作成するときに、サービスを 1 つのリージョンに割り当てます。 このサービスを Azure Front Door に置き換えることで、この脆弱性を削除します。 Front Door では、複数の App Services をポーリングし、米国東部リージョンから米国西部リージョンへの App Service フェールオーバーを処理できます。

アプリケーション サービス

Microsoft Entra ID はグローバル システムであり、変更する必要はありません。

Azure Storage アカウントは、コンテンツを複数のリージョンにレプリケートするように構成できます。 構成を変更するには、geo 冗長ストレージ オプションの 1 つを使用します。

App Service、Function Apps、Redis Cache、Azure Search など、その他のコンポーネントはリージョンです。 新しいアーキテクチャ設計では、これらのコンポーネントの複製インスタンスを米国西部リージョンに作成します。 この設計では、フェールオーバーが発生したときに新しいリージョンが引き継ぐことができます。

データ ストレージ

Azure SQL Database と Azure Cosmos DB の両方で、他のリージョンへのデータの geo レプリケーションがサポートされています。 これらのサービスは、米国東部データを米国西部の同等のサービスにレプリケートするように構成します。

リージョンのペア

Azure リージョンは、1 つ以上の Azure データセンターを含む 1 つの地域を持つ領域です。 すべてのリージョンは、同じ地域内の他のリージョンとペアになっています。 これらのペア内では、更新と計画メンテナンスは一度に 1 つのリージョンでのみ行われます。 複数のリージョンに影響する障害が発生した場合、迅速な復旧のために、各ペアの少なくとも 1 つのリージョンが優先されます。

ベスト プラクティスは、アプリの 2 リージョン アーキテクチャをリージョン ペアの 2 つのリージョンに配置することです。 たとえば、米国東部と米国西部がペアを組んでいます。 提案された設計では、アクティブなリージョンに米国東部を使用し、スタンバイ リージョンに米国西部を使用します。