地理的に分散したアーキテクチャを設計する
Azure はグローバルなシステムです。 複数の Azure リージョンに存在するアーキテクチャを設計すると、リージョン全体の災害に対してさえ回復性があるアプリケーションを構築できます。
あなたの配送追跡ポータルは、スケーリング可能なさまざまな Azure リソースを使用して構築されているため、スケーラブルです。 また、そのコンポーネントは複数のインスタンスを持つことができるため、多くの障害に対する回復性もあります。 しかし、ポータルが米国東部の Azure リージョンに完全に含まれているため、取締役会は大規模な災害によってポータルが停止する可能性があることを心配するようになりました。 あなたは、米国東部で障害が発生した場合に、第 2 のリージョンにフェールオーバーできるように変更されたアーキテクチャを、提案しようと考えています。
ここでは、地理的に分散したアプリケーションをサポートするようにアプリケーションのアーキテクチャを調整する方法について学習します。 また、ビジネスに不可欠なアプリケーションに対してそのようなアーキテクチャが有利である理由についても説明します。
元の Web アプリのアーキテクチャ
ここでは、追跡ポータルのアーキテクチャ設計と、ソリューションで使用されているコンポーネントについて見ていきましょう。 すべての部分の使用方法を理解したら、geo 冗長なシナリオでこれらの各コンポーネントをサポートする方法を調べることができます。
追跡ポータルの設計は、次の図で示す参照アーキテクチャが基になっています。
アプリケーションで 1 つの Azure リソース グループがどのように使用されているかに注目してください。 このリソース グループを使用することで、すべてのリソースを論理的にグループ化して管理し、管理を簡素化することができます。 このリソース グループを米国東部リージョンにデプロイすることを選択しました。 リソース グループに、含まれるリソースに対して同じ Azure リージョンを使用しなければならないという制限はありませんが、アプリケーションでデプロイされるすべてのリソースについて米国東部リージョンを使用することにしました。
このアプリケーションで使用されている Azure リソースには、3 つのカテゴリがあります。 各カテゴリを調べて、どのリソースが使用されているかを見てみましょう。
ネットワーク コンポーネント
追跡ポータルでは、次のネットワーク サービスが使われています。
サービス | 説明 |
---|---|
Azure DNS | Azure DNS は、Azure 内の DNS レコードをホストするように構成されています。 Azure DNS を使うと、Azure portal で Azure の資格情報を使って DNS レコードを管理できます。 |
Application Gateway | Application Gateway のロード バランサーは、Web フロントエンドの複数のインスタンス間にトラフィックを分散するように構成されています。 このサービスは、1 つの Azure リージョンに限定されています。 |
Azure CDN | Azure CDN は、Web サイトのコンテンツのグラフィックスなど、セキュリティで保護されていない静的コンテンツの配信を最大化するように構成されています。 このグローバル サービスにより、世界中の場所で静的コンテンツがキャッシュされます。 |
アプリケーション コンポーネント
追跡ポータルでは、次のサービスを使用して、コード、キャッシュ、中間ストレージの要件がサポートされています。
サービス | 説明 |
---|---|
Microsoft Entra ID | ユーザーは、Microsoft Entra アカウントを使って追跡ポータルにアクセスします。 ディレクトリとアカウントは、グローバルに自動的にレプリケートされます。 |
Azure App Service | 追跡ポータルでは、2 つの Azure App Services が使われています。 1 つ目では一連の動的 Web ページが実行され、2 つ目では Web API が実行されています。 |
Azure 関数アプリ | 追跡ポータルでは、Azure 関数アプリを使用してすべてのバックグラウンド タスクが実行されています。 これらのタスクの一部は定期的なスケジュールで実行され、他のタスクはキュー内のメッセージに対して動作します。 |
Azure Storage キュー | 追跡ポータルでは、Azure Storage キューと Azure 関数アプリを使います。 追跡ポータルでは、生成されたメッセージはキューに置かれた後、そこから関数アプリによって処理されます。 |
Redis Cache | 追跡ポータルでは、クエリのパフォーマンスを最大にするため、フロントエンドのアプリ サービスとデータ ストレージ システムの間で、Redis Cache が使われています。 |
Azure Blob Storage | グラフィックス ファイルやビデオ ファイルなどの静的コンテンツは、Azure ストレージ アカウントにバイナリ ラージ オブジェクト (BLOB) として保持され、Azure CDN を通じて配信されます。 |
Azure Search | 追跡ポータルでは Azure Search が有効にされています。 Azure Search を使うと、すべてのコンテンツを検索可能にして、検索候補やあいまい検索結果をユーザーに提供できます。 |
データ ストレージ コンポーネント
追跡ポータルでは、次の永続ストレージ サービスが使われています。
サービス | 説明 |
---|---|
Azure SQL Database | 注文や顧客の詳細などのリレーショナル データは、Azure SQL Database に格納されています。 |
Cosmos DB | 製品カタログなどの半構造化データは、Cosmos DB に格納されています。 |
元のアーキテクチャに関する問題
追跡ポータルの既存のアーキテクチャは、スケーラビリティと可用性に対応するように設計されています。
たとえば、需要が多く、ユーザーの 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 ストレージ アカウントの geo 冗長ストレージ (GRS) オプションを使って、静的コンテンツを格納できます。 GRS では、BLOB が別のリージョンにレプリケートされます。
次の表は、コンポーネントがグローバルか、リージョン固有か、構成可能かを示しています。
コンポーネント | 複数リージョンのサポート | コメント |
---|---|---|
Azure DNS | グローバル | 変更する必要はありません。 |
Application Gateway | リージョン | Application Gateway の各インスタンスは、1 つのリージョンにあります。 |
Azure CDN | グローバル | 変更は必要なく、コンテンツは既定でグローバルにキャッシュされます。 |
Microsoft Entra ID | グローバル | 変更する必要はありません。 |
Azure App Service | リージョン | アプリの各インスタンスは、1 つのリージョンにあります。 |
Azure 関数アプリ | リージョン | 関数アプリの各インスタンスは、1 つのリージョンにあります。 |
Azure Storage キュー | 構成可能 | Azure ストレージ アカウントを複数のリージョンにレプリケートすることを選択できます。 |
Azure Redis Cache | リージョン | キャッシュの各インスタンスは、1 つのリージョンにあります。 |
Azure Blob Storage | 構成可能 | Azure ストレージ アカウントを複数のリージョンにレプリケートすることを選択できます。 |
Azure Search | リージョン | 検索サービスの各インスタンスは、1 つのリージョンにあります。 |
Azure SQL Database | 構成可能 | geo レプリケーションを使って、複数のリージョンにデータを同期できます。 |
Azure Cosmos DB | 構成可能 | geo レプリケーションを使って、複数のリージョンにデータを同期できます。 |
提示された分散アーキテクチャ
調査の後、あなたは次の図に示すようなアーキテクチャを提案します。
この設計では、アクティブなリージョン (米国東部) とスタンバイ リージョン (米国西部) があります。 通常の状況下では、米国東部リージョンのコンポーネントによって、すべての要求が処理されます。 災害によるリージョン規模の障害が発生した場合、アプリケーションは米国西部リージョンにフェールオーバーされます。
元のアーキテクチャをどのように変更したかを大まかに確認しましょう。 これらの変更の詳細については、後のユニットで説明します。
ネットワーク
Azure DNS と Azure CDN は、既定でグローバル システムであり、リージョン規模の障害に対する回復性が既にあります。 これらはそのままにしておきます。
Azure アプリケーション ゲートウェイを作成するときは、サービスを 1 つのリージョンに割り当てます。 このサービスを Azure Front Door に置き換えることで、この脆弱性を排除します。 Front Door では、複数の App Services をポーリングすることができ、米国東部リージョンから米国西部リージョンへの App Service のフェールオーバーが処理されます。
アプリケーション サービス
Microsoft Entra ID はグローバルなシステムであり、変更は必要ありません。
Azure ストレージ アカウントは、コンテンツを複数のリージョンにレプリケートするように構成できます。 geo 冗長ストレージ オプションのいずれかを使用して、構成を変更します。
App Service、関数アプリ、Redis cache、Azure Search などの他のコンポーネントは、リージョンごとです。 新しいアーキテクチャの設計では、これらのコンポーネントについては、米国西部リージョンに重複するインスタンスが作成されます。 この設計では、フェールオーバーが発生したら新しいリージョンが引き継ぐことができます。
データ ストレージ
Azure SQL Database と Azure Cosmos DB はどちらも、他のリージョンへのデータの geo レプリケーションをサポートしています。 これらのサービスは、米国西部の同等のサービスに米国東部のデータをレプリケートするように構成します。
リージョン ペア
Azure のリージョンとは、1 つまたは複数の Azure データセンターが含まれる 1 つの地理的な領域です。 すべてのリージョンは、同じ地理範囲内にある他のリージョンとペアになっています。 これらのペア内では、更新と計画メンテナンスは一度に 1 つのリージョンに対してのみ行われます。 複数のリージョンに影響を与える障害が発生した場合は、各ペアの少なくとも 1 つのリージョンが迅速に回復されるように優先度付けされます。
ベスト プラクティスは、アプリの 2 リージョン アーキテクチャを、リージョン ペアになっている 2 つのリージョンに配置することです。 たとえば、米国東部と米国西部がペアになっています。 設計案では、アクティブなリージョンとして米国東部を使用し、スタンバイ リージョンとして米国西部を使用します。