地理的に分散したアプリケーション アーキテクチャを設計する
- 8 分
リージョン規模の障害の影響を緩和するため、ネットワーク コンポーネントで複数のリージョンに要求をルーティングする場合、プライマリ リージョンとスタンバイ リージョンの両方でこれらの要求に応答できるアプリケーション サービスを設計する必要があります。
前に説明したように、優先バックエンドの割り当てを使用して Azure Front Door を構成することを計画しています。 米国東部リージョンをプライマリ リージョンとして、米国西部リージョンをスタンバイ リージョンとして割り当てます。 リージョン規模の障害が発生すると、要求は障害が発生していないリージョンの App Service にルーティングされます。 ユーザー アクセス、レプリケートされたストレージ、およびアプリケーション コードに関してこれらのフェールオーバーがサポートされるように、各リージョンのリソースを構成する必要があります。
ここでは、ソリューションのアプリケーション サービスを調べ、マルチリージョン アーキテクチャで機能するように変更する必要があるかどうかを判断します。 具体的には、Active Directory、静的コンテンツ ストレージ、Web アプリ、Web API、キュー、Azure 関数、データ キャッシュについて調べます。
Microsoft Entra ID
配送追跡ポータルでは、ユーザーは追跡番号を入力して購入の配送を追跡できます。 ただし、よく利用するユーザーは、迅速な配達や他の統計情報などの高度な機能にアクセスするためのメンバーシップを登録できます。 Microsoft Entra ID にユーザー アカウントを格納するための追跡ポータルを開発しました。
Microsoft Entra ID は、既定ではグローバル システムとして設計されます。 そのため、リージョンの障害に対して脆弱ではなく、システムのこのコンポーネントを変更する必要はありません。
Azure Blob Storage
画像やビデオなどの静的コンテンツは、Azure ストレージ アカウントにバイナリ ラージ オブジェクト (BLOB) として格納され、Azure CDN を通じてユーザーに提供されます。
元の設計では、ローカル冗長ストレージ (LRS) を使用していたため、ストレージ アカウントは 1 つのリージョンに含まれています。 データは、LRS により 1 つのデータセンター内でのみレプリケートされます。 そのため、この構成では、リージョン規模の障害が発生した場合、ストレージ アカウントは使用できません。 ユーザーは、CDN によって既にキャッシュされている静的コンテンツを引き続き利用できます。
これは、ゾーン冗長ストレージ (ZRS) にも当てはまります。 この構成ではデータは異なるデータセンターにレプリケートされますが、これらのデータセンターはすべて同じリージョンに存在します。 この構成でも、リージョンが停止するとストレージ アカウントに影響します。
この設計では、静的なコンテンツをキャッシュするために CDN の構成に大きく依存しています。 停止の間に、CDN キャッシュにまだ存在しない静的ファイルをユーザーが要求する可能性があります。 このような要求では、グラフィックやビデオを表示できなくなります。
geo 冗長ストレージ オプションを選択するときに、ストレージ アカウントを複数のリージョンにレプリケートすることで、このようなことが起きる可能性をなくすことができます。 リージョンの停止中に静的コンテンツが追加されるのを防ぐために、読み取り専用レプリケーション オプションも使用できます。
geo 冗長性を有効にする必要がある場合は、次の 2 つのオプションを選択できます。 読み取りアクセス geo 冗長ストレージ (RA-GRS) と、読み取りアクセス geo ゾーン冗長ストレージ (RA-GZRS) です。 どちらを選択するかは、予算と、必要なアップタイムの割合によって決まります。
Azure App Service と Azure 関数アプリ
配送追跡ポータルでは、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 関数アプリの別のインスタンスを作成し、プライマリ リージョンで実行されるものと同じカスタム コードをデプロイします。
重要
App Service または関数アプリ サービスのカスタム コードに更新をデプロイするときは、App Service のすべてのインスタンスに配布することを忘れないでください。 このプロセスを自動化する場合、Azure DevOps には役立つツールが用意されています。
Azure Storage キュー
元の単一リージョン アーキテクチャでは、Azure ストレージ アカウントのキューを使用して、App Service と関数アプリの間の通信を管理していました。 Web アプリまたは Web API でバックグラウンド タスクを実行する必要がある場合、必要なすべての情報を含むメッセージがキューに格納されます。 関数アプリによって、キューの新しいメッセージが監視され、データ ストアに対して必要なクエリを実行することでバックグラウンド タスクが実行されます。
この方法でキューを使用すると、大量の Web 要求を整然と管理できます。 実行するバックグラウンド タスクが多数ある場合、キューは長くなることがありますが、タスクは削除されません。 処理されるまでキューに残っています。 関数アプリによってキューの処理が行われ、需要が低下するとキューのサイズは縮小されます。 需要が低下しない場合は、関数アプリのインスタンスの数を増やします。
配送追跡ポータルの複数リージョン バージョンでは、フェールオーバーが発生したときに、キューの項目が失われないようにする必要があります。 キューは Azure Storage で定義されており、geo レプリケーションの冗長オプションを使用できます。
キューでは読み取り操作と書き込み操作がサポートされているため、読み取りアクセス冗長オプションは使用できないことに注意してください。 App Service でキューに項目を追加し、関数アプリで完了した項目をキューから削除する必要があります。 代わりに、geo 冗長ストレージ (GRS) または geo ゾーン冗長ストレージ (GZRS) を使用します。
Azure Redis Cache
データ ストレージのパフォーマンスを最大にするため、Azure Redis Cache を使用しています。 Redis では、アプリによってデータベースのデータが要求されたとき、アプリから生成されたすべてのクエリ結果がキャッシュされます。 似たデータに対する以降のクエリでは、データベース クエリは必要なく、Redis キャッシュからフェッチされます。
マルチリージョン アーキテクチャでは、プライマリ リージョンとスタンバイ リージョンの両方に Redis Cache インスタンスを作成します。 フェールオーバー発生時点では、スタンバイ リージョンの Redis Cache はおそらく空であることに注意してください。 キャッシュが空でもエラーは発生しませんが、データが新しいキャッシュにたまるまで、パフォーマンスが一時的に低下する可能性があります。