地理的に分散されたアプリケーション アーキテクチャを設計する

ネットワーク コンポーネントがリージョンの停止の影響を軽減するために複数のリージョンに要求をルーティングする場合は、プライマリ リージョンとスタンバイ リージョンの両方でこれらの要求に応答できるアプリケーション サービスを設計する必要があります。

前の手順で、優先順位の高いバックエンド割り当てで Azure Front Door を構成する予定であることを思い出してください。 プライマリ リージョンとして米国東部リージョンを割り当て、スタンバイ リージョンとして米国西部リージョンを割り当てます。 リージョンの障害が発生すると、失敗していないリージョンの App Service へのルートが要求されます。 ユーザー アクセス、レプリケートされたストレージ、アプリケーション コードに対してこれらのフェールオーバーをサポートするように、各リージョンのリソースを構成する必要があります。

ここでは、ソリューション内のアプリケーション サービスを調べて、複数リージョン アーキテクチャで機能するように変更する必要があるかどうかを判断します。 具体的には、Active Directory、静的コンテンツ ストレージ、Web アプリ、Web API、キュー、Azure 関数、データ キャッシュについて説明します。

Microsoft Entra ID

出荷追跡ポータルでは、ユーザーは追跡番号を入力して購入の配送を追跡できます。 ただし、通常のユーザーはメンバーシップに登録して、配信のプロンプトやその他の統計情報などの高度な機能にアクセスできます。 Microsoft Entra ID にユーザー アカウントを格納するための追跡ポータルを開発しました。

Microsoft Entra ID は、既定でグローバル システムとして設計されています。 そのため、リージョンの障害に対して脆弱ではなく、システムのこのコンポーネントを変更する必要はありません。

Azure Blob Storage

画像やビデオなどの静的コンテンツは、Azure Storage アカウントにバイナリ ラージ オブジェクト (BLOB) として格納され、Azure CDN を介してユーザーに提供されます。

元の設計では、ローカル冗長ストレージ (LRS) を使用することを選択したため、ストレージ アカウントは 1 つのリージョンに含まれています。 データは、LRS を使用して 1 つのデータセンター内でのみレプリケートされます。 そのため、ストレージ アカウントは、この構成でリージョンが停止した場合は使用できません。 CDN によって既にキャッシュされている静的コンテンツは、ユーザーが引き続き使用できます。

ゾーン冗長ストレージ (ZRS) についても同様です。 この構成でデータが異なるデータ センターにレプリケートされる場合でも、これらのデータ センターはすべて同じリージョンに残ります。 リージョンの停止は、この構成のストレージ アカウントにも影響します。

この設計では、静的コンテンツをキャッシュするために CDN 構成に大きく依存しています。 停止中に、ユーザーがまだ CDN キャッシュにない静的ファイルを要求する可能性があります。 この要求により、グラフィックまたはビデオが表示できなくなります。

geo 冗長ストレージ オプションを選択するときに、ストレージ アカウントを複数のリージョンにレプリケートすることで、この可能性を排除できます。 読み取り専用レプリケーション オプションを使用して、リージョンの停止中に静的コンテンツを追加しないようにすることもできます。

geo 冗長性を有効にする必要がある場合から、2 つのオプションを選択できます。 これらのオプションは、Read-Access Geo-Redundant Storage (RA-GRS) と Read-Access geo-Zone-Redundant Storage (RA-GZRS) です。 選択は、予算と、必要なアップタイムの割合によって異なります。

Azure App Service と Azure Function Apps

出荷追跡ポータルには、2 つの Azure App Services が実装されています。 1 つ目の App Service は、ユーザー向けの Web インターフェイスを実装する Web アプリをホストし、2 つ目はモバイル アプリが出荷データを追跡するために使用する Web API をホストします。 すべてのバックグラウンド タスクは、Azure 関数アプリとして実行されます。

元の設計では、各 Azure App Service は 1 つの Azure リージョンにローカライズされています。 セカンダリ リージョン (米国西部) に 2 つ目の App Service を作成し、そこに Web プロジェクトをデプロイして、新しいマルチリージョン アーキテクチャをサポートします。 プライマリ リージョンが使用できないときにセカンダリ リージョンに要求を送信するように Azure Front Door の優先順位ルーティング モードを構成します。

フェールオーバーが可能な限りスムーズになるように、Web アプリケーションがセッション状態情報をメモリに格納しないようにします。 データ損失が生じないように Web サイトを変更します。 たとえば、コードでユーザーの出荷の一覧がメモリに格納されている場合、フェールオーバーが発生した場合、このリストは失われます。

セッション状態が保存されていない場合、各 Web 要求は他方に影響を与えずに処理されます。 ユーザーのセッションの途中でフェールオーバーが発生した場合、フェールオーバーはユーザーに対して透過的である必要があります。

Azure 関数アプリと同様の変更を行います。 セカンダリ リージョンに Azure 関数の別のインスタンスを作成し、プライマリ リージョンで実行するのと同じカスタム コードをデプロイします。

Azure Storage キュー

元の単一リージョン アーキテクチャでは、Azure Storage アカウントのキューを使用して、App Service と関数アプリ間の通信を管理しました。 Web アプリまたは Web API でバックグラウンド タスクを実行する必要がある場合は、必要なすべての情報を含むメッセージをキューに配置します。 関数アプリは、新しいメッセージのキューを監視し、データ ストアに対して必要なクエリを実行してバックグラウンド タスクを実行します。

この方法でキューを使用する場合、Web 要求の高い需要を順番に管理できます。 実行するバックグラウンド タスクが多数ある場合、キューが構築される可能性がありますが、タスクは削除されません。 処理されるまでキューに残っています。 関数アプリはキューを介して動作し、需要が減少したときにそのサイズを小さくします。 需要が持続する場合は、関数アプリのインスタンスの数を増やします。

複数リージョンバージョンの出荷追跡ポータルでは、フェールオーバーが発生したときにキュー項目が失われないようにする必要があります。 キューは Azure Storage で定義されており、geo レプリケーションに冗長性オプションを使用できます。

キューでは読み取りと書き込みの操作がサポートされているため、読み取りアクセス冗長オプションを使用できないことに注意してください。 App Service はキューに項目を追加する必要があり、関数アプリはキューから完了した項目を削除する必要があります。 代わりに、Geo-Redundant Storage (GRS) または geoZone-Redundant Storage (GZRS) を使用してください。

Azure Redis Cache

Azure Redis Cache を使用して、データ ストレージのパフォーマンスを最大化しています。 Redis は、データベースからデータを要求すると、アプリから生成されたすべてのクエリ結果をキャッシュします。 同様のデータに対するそれ以降のクエリでは、データベース クエリは必要なく、Redis キャッシュからフェッチされます。

マルチリージョン アーキテクチャでは、プライマリ リージョンとスタンバイ リージョンの両方に Redis Cache インスタンスを作成します。 フェールオーバーが発生すると、スタンバイ リージョンの Redis Cache が空になる可能性があることに注意してください。 その空のキャッシュではエラーは発生しませんが、データが新しいキャッシュに格納されるため、パフォーマンスが一時的に低下する可能性があります。