Azure アプリ サービス Web アプリを 1 つのリージョンにデプロイすると、障害や停止が原因で使用できなくなると、アプリケーションが使用できなくなるリスクが発生します。 リージョンが使用できないときにアプリケーションを引き続き使用できるようにするには、マルチリージョン アーキテクチャを実装できます。 マルチリージョン アーキテクチャでは、セカンダリ Azure リージョンに同じデプロイを作成します。 セカンダリ リージョンのデプロイでは、データをレプリケートして最後のアプリケーションの状態を回復できます。また、他のソリューション コンポーネントもレプリケートできます。
この記事では、App Service 環境と App Service 環境の両方で一般的に使用される 3 つのマルチリージョン アーキテクチャ アプローチについて説明します。
考慮すべきアプローチ
ビジネス継続性計画は、次の 2 つの主要なメトリックの影響を受けられます。
- 目標復旧時間 (RTO)。 これは、障害発生時に許容できる最大ダウンタイムです。
- 目標復旧ポイント (RPO)。 これは、障害発生時に許容される最大データ損失です。
RTO や RPO などの回復目標の詳細については、「 回復目標 信頼性目標の定義に関する Recommendationsを参照してください。
Azure プラットフォームを使用すると、さまざまな方法で複数リージョンのアプリケーション ソリューションを設計できます。 この記事では、さまざまな RTO と RPO の要件をサポートし、コストと複雑さの他のトレードオフがあるアーキテクチャについて説明します。
| メトリック | アクティブ/アクティブ | アクティブ/パッシブ | パッシブ/コールド |
|---|---|---|---|
| RTO | リアルタイムまたは数秒 | 分 | 時間 |
| RPO | リアルタイムまたは数秒 | 分 | 時間 |
| コスト | $$$ | $$ | $ |
| シナリオ | ミッション クリティカルなアプリ | 優先順位の高いアプリ | 優先順位の低いアプリ |
| 複数リージョンのユーザー トラフィックを処理する機能 | はい | いいえ | いいえ |
| コードのデプロイ | CI/CD パイプライン推奨 | CI/CD パイプライン推奨 | バックアップと復元 |
| ダウンタイム中の新しい App Service リソースの作成 | 必要なし | 必要なし | 必須 |
ここで説明する 3 つのアプローチは一般的ですが、Azure でマルチリージョン ソリューションを実現する唯一の方法ではありません。 独自の要件を満たすようにソリューションを調整します。
Note
アプリケーションは、Azure SQL Database、Azure Storage アカウント、メッセージ キューなど、Azure 内の他のサービスに依存している可能性が最も高いです。 ディザスター リカバリー戦略を設計するときは、これらの依存する各 Azure サービスも考慮する必要があります。
Azure サービスのマルチリージョン ソリューションの詳細については、 Azure サービスの信頼性ガイドを参照してください。
監視
リージョンの障害発生時にチームがタイムリーな通知を受け取るように、Web アプリの監視とアラートを構成することが重要です。 Azure アプリlication Insights 可用性テストは、アプリケーションの可用性を監視する方法を提供します。 詳細については、「Application Insights 可用性テスト」を参照してください。
展開
複数リージョンのソリューションは、デプロイと構成が複雑になる場合があります。 各リージョンのインスタンスは同期状態に保たれることが重要です。
App Service などの Azure リソースのデプロイと構成を管理するには、コードとしてのインフラストラクチャ (IaC) メカニズムを使用します。 複数のリージョンにまたがる複雑なデプロイで、リージョンを別個に管理し、信頼性の高い方法でリージョン間の構成の同期を維持するには、予測可能でテスト可能で反復可能なプロセスが必要です。 Bicep、Azure Resource Manager テンプレート、 Teraform などの IaC ツールについて考。
また、複数のリージョンを使用する場合を含め、コードをデプロイするように CI/CD パイプラインを構成する必要があります。 Azure Pipelines または GitHub Actions の使用を検討してください。 詳しくは、「Azure App Service への継続的デプロイ」をご覧ください。
アクティブ/アクティブ アーキテクチャ
アクティブ/アクティブ アーキテクチャでは、同じ Web アプリが 2 つの異なるリージョンにデプロイされます。 Azure Front Door は、両方のアクティブなリージョンにトラフィックをルーティングするために使用されます。
各リージョンの App Service アプリケーションでは、価格レベルやインスタンス数など、同じ構成が使用されます。
通常の操作中 App Service アプリに直接送信されるパブリック トラフィックはブロックされます。 トラフィックは、Azure Front Door を使用して両方のアクティブなリージョンにルーティングされます。 この方法は、要求が Azure Front Door Web アプリケーション ファイアウォール (WAF) によって検査されることを確認したり、それ以外の場合は一元的にセキュリティで保護または管理したりするのに役立ちます。
リージョンの障害時にいずれかのリージョンがオフラインになった場合、Azure Front Door 正常性プローブは、障害の発生元を検出し、トラフィックがオンラインのままのリージョンにのみ送信されるようにルートを再構成します。
障害のあるリージョンの復旧 (フェールバック) 中に、Azure Front Door 正常性プローブは正常な配信元を検出し、通常のトラフィック ルーティングを復元します。
推奨事項
アプリケーション コンテンツの RPO を 0 に満たすには、CI/CD ソリューションを使用して両方の Web アプリにアプリケーション ファイルをデプロイします。
可能であれば、App Service ファイル システムの外部 (データベースや Azure Storage など) にアプリケーションの状態を格納します。 geo 冗長性の要件を満たすようにこれらのコンポーネントを構成します。
ヒント
アプリケーションがファイル システムをアクティブに変更し、App Service アプリ リージョンペアリージョンがある場合、Web アプリの/ホームコンテンツ共有に直接書き込む代わりにマウントされた Azure Storage 共有に書き込むことで、ファイル システムの RPO を削減できます。 次に、マウントされた共有に対して Azure Storage 冗長機能 (GZRS または GRS) を使用します。この RPO は約 15 分です。
考慮事項
低 RTO: このような geo フェールオーバー中の RTO は、正常性プローブが障害のあるリージョンを検出する時間によって異なります。 既定では、プローブは 30 秒ごとにチェックされますが、 異なるプローブ頻度を構成できます。
負荷分散とフェールオーバー: この方法では、グローバル負荷分散、トラフィック分散、フェールオーバーに Azure Front Door を使用します。 Azure には、Azure Traffic Manager などの他の負荷分散オプションが用意されています。 さまざまなオプションの比較については、「負荷分散オプション - Azure アーキテクチャ センター」を参照してください。
アクティブ/アクティブな App Service Web アプリをデプロイする
App Service を使用して Web アプリのアクティブ/アクティブアプローチを作成するには、次の手順に従います。
2 つの異なる Azure リージョンに 2 つの App Service プランを作成します。 2 つの App Service プランを同じように構成します。
Web アプリの 2 つのインスタンスを、各 App Serviceプランに 1 つ作成します。
次を持つ Azure Front Door プロファイルを作成します。
- エンドポイント。
- 2 つのオリジンを持つオリジン グループ。それぞれ優先度が 1 です。 優先度が等しい値は、両方のリージョンのアプリケーションにトラフィックを均等に (アクティブ/アクティブ) ルーティングするように Azure Front Door に指示します。
- 1 つのルート。
データベース、ストレージ アカウント、認証プロバイダーなど、他のすべてのバックエンド Azure サービスをセットアップして構成します。
継続的デプロイを使用して、両方の Web アプリにコードをデプロイします。
Azure アプリ Service で高可用性マルチリージョン アプリを作成するチュートリアルでは、アクティブ/パッシブ アーキテクチャを設定する方法について説明します。 アクティブ/アクティブアプローチをデプロイするには、同じ手順に従いますが、1 つの例外を除きます。Azure Front Door では、配信元グループの両方の配信元を 1 の優先度に構成します。
アクティブ/パッシブ アーキテクチャ
アクティブ/パッシブ アーキテクチャでは、同じ Web アプリが 2 つの異なるリージョンにデプロイされます。 Azure Front Door は、トラフィックを 1 つのリージョン ( アクティブ リージョン) にのみルーティングするために使用されます。
通常の操作中、Azure Front Door はプライマリ リージョンにのみトラフィックをルーティングします。 App Service アプリに直接の送られるパブリック トラフィックはブロックされます。
リージョンの障害時プライマリ リージョンが非アクティブになった場合、Azure Front Door 正常性プローブは障害のある配信元を検出し、セカンダリ リージョンの配信元へのトラフィック ルーティングを開始します。 その後、セカンダリ リージョンがアクティブ リージョンになります。 セカンダリ リージョンがアクティブになると、ネットワーク負荷が事前構成済みの自動スケーリング ルールをトリガーして、セカンダリ Web アプリをスケールアウトします。
障害が発生したリージョンの復旧 (フェールバック) 中、Azure Front Door はトラフィックをプライマリ リージョンに自動的に戻し、アーキテクチャは以前と同様にアクティブ/パッシブに戻ります。
Note
アクティブなリージョンとして実行するために必要な機能がまだない場合は、セカンダリ リージョンの価格レベルを手動でスケールアップすることが必要な場合があります。 たとえば、自動スケーリングには Standard レベル以上が必要です。
推奨事項
アプリケーション コンテンツの RPO を 0 に満たすには、CI/CD ソリューションを使用して両方の Web アプリにアプリケーション ファイルをデプロイします。
可能であれば、App Service ファイル システムの外部 (データベースや Azure Storage など) にアプリケーションの状態を格納します。 geo 冗長性の要件を満たすようにこれらのコンポーネントを構成します。
ヒント
アプリケーションがファイル システムをアクティブに変更し、App Service アプリ リージョンペアリージョンがある場合、Web アプリの/ホームコンテンツ共有に直接書き込む代わりにマウントされた Azure Storage 共有に書き込むことで、ファイル システムの RPO を削減できます。 次に、マウントされた共有に対して Azure Storage 冗長機能 (GZRS または GRS) を使用します。この RPO は約 15 分です。
考慮事項
コストコントロール: 同一の App Service アプリは、2 つの異なるリージョンにデプロイされます。 コストを節約するために、セカンダリ App Service プランは、少ないインスタンス数や、低い価格レベルで構成されています。 考えられる方法は 3 とおりあります。
Preferred: セカンダリ App Service プランの価格レベルはプライマリと同じで、インスタンス数は同じか少なくなります。 この方法では、2 つの App Service プランの機能と VM のサイズの両方でパリティが確保されます。 geo フェールオーバー中の RTO は、インスタンスのスケールアウト時間にのみ依存します。
低優先: セカンダリ App Service プランの価格レベルの種類は同じですが (PremiumV3 など)、VM のサイズは小さく、インスタンス数は少なくなります。 たとえば、プライマリ リージョンを P3V3 レベル、セカンダリ リージョンを P1V3 レベルにすることが考えられます。 この方法では、2 つのApp Service プランの機能パリティは引き続き確保されますが、セカンダリ リージョンがアクティブなリージョンになったときにサイズ パリティが不足して、手動によるスケールアップが必要になる場合があります。 geo フェールオーバー中の RTO は、インスタンスのスケールアップとスケールアウトの両方の時間に依存します。
最小優先: セカンダリ App Service プランの価格レベルは、プライマリ インスタンスと小さいインスタンスとは異なります。 たとえば、プライマリ リージョンを P3V3 レベル、セカンダリ リージョンを S1 レベルにすることが考えられます。 セカンダリ App Service プランに、アプリケーションを実行するために必要なすべての機能があることを確認してください。 2 つの機能の可用性が異なると、Web アプリの回復が遅れる可能性があります。 geo フェールオーバー中の RTO は、インスタンスのスケールアップとスケールアウトの両方の時間に依存します。
トラフィックがリダイレクトされ、要求が急増した場合に備えて 自動スケールをセカンダリ リージョンで構成する必要があります。 アクティブ リージョンとパッシブ リージョンの両方に、同じ自動スケーリング ルールを設定することをお勧めします。
負荷分散とフェールオーバー: この方法では、グローバル負荷分散、トラフィック分散、フェールオーバーに Azure Front Door を使用します。 Azure には、Azure Traffic Manager などの他の負荷分散オプションが用意されています。 さまざまなオプションの比較については、「負荷分散オプション - Azure アーキテクチャ センター」を参照してください。
アクティブ/パッシブ App Service Web アプリをデプロイする
App Service を使用して Web アプリのアクティブ/パッシブ アプローチを作成するには、次の手順に従います。
2 つの異なる Azure リージョンに 2 つの App Service プランを作成します。 セカンダリ App Service プランは、前述のいずれかの方法を使用してプロビジョニングできます。
プライマリ リージョンが非アクティブになったときにプライマリと同じインスタンス数にスケーリングされるように、セカンダリ App Service プランの自動スケーリング ルールを構成します。
Web アプリの 2 つのインスタンスを、各 App Serviceプランに 1 つ作成します。
次を持つ Azure Front Door プロファイルを作成します。
エンドポイント。
2 つのオリジンを持つオリジン グループ:
- プライマリ リージョン内のアプリケーションの優先度が 1 のオリジン。
- セカンダリ リージョン内のアプリケーションの優先順位が 2 の 2 番目の配信元。
優先順位が異なると、オンラインのときはプライマリ リージョンを優先する (したがってアクティブ/パッシブ) ように Azure Front Door に通知されます。
1 つのルート。
データベース、ストレージ アカウント、認証プロバイダーなど、他のすべてのバックエンド Azure サービスをセットアップして構成します。
継続的デプロイを使用して、両方の Web アプリにコードをデプロイします。
"アクティブ/パッシブ" アーキテクチャを設定する方法については、「チュートリアル: Azure App Service で高可用性のマルチリージョン アプリを作成する」を参照してください。
パッシブ/コールド アーキテクチャ
パッシブ/コールド アーキテクチャでは、Web アプリは 1 つのプライマリ リージョンにデプロイされます。 アプリケーション ファイルと一部のデータベースは、Azure Storage アカウントにバックアップされます。 バックアップは別のリージョンにレプリケートされます。 プライマリ リージョンが使用できない場合は、別のアプリを 2 つ目のリージョンに手動でデプロイし、バックアップから復元します。
Note
パッシブコールドアプローチは、リージョンの改ざん中に手動による介入に依存し、多くの場合、大幅なダウンタイムとデータ損失が発生します。 ほとんどの運用グレードのソリューションでは、アクティブ/アクティブまたはアクティブ/パッシブ ソリューションを検討する必要があります。
リージョン間レプリケーション
この方法では、 App Service バックアップ を使用して、Web アプリを同じリージョン内の Azure Storage アカウントに定期的にバックアップします。 ストレージ アカウントを構成して、バックアップのリージョン間レプリケーションを構成します。
リージョン間レプリケーションの構成に使用する方法は、リージョンにペアがあるかどうかによって異なります。 詳細については、「 Azure のペアになっているリージョン および 可用性ゾーンとリージョン ペアのないリージョンを参照してください。
RA-GZRS レプリケーションが使用可能な場合は、それを使用します。 RA-GZRS は、リージョン内の同期ゾーン冗長性とセカンダリ リージョンでの非同期の両方を提供します。 また、セカンダリ リージョン内で読み取り専用アクセスを しますこれは、ストレージ アカウントのプライマリ リージョンが使用できなくなったときにバックアップを取得できるようにするために不可欠です。
RA-GZRS を使用できない場合は、アカウントを RA-GRS として構成します。
RA-GZRS と RA-GRS の両方に、約 15 分の RPO があります。
geo 冗長ストレージを利用するようにアプリケーションを設計する方法の詳細については、「 geo 冗長を使用して高可用性アプリケーションを設計するを参照してください。
リージョンダウン エクスペリエンス
プライマリ リージョンが使用できない場合は、リージョンの損失を検出する必要があります。 詳細については、「監視」を参照してください。
トラフィックを受信するようにセカンダリ リージョンを準備するには、セカンダリ リージョンの Azure Storage アカウントからのバックアップを使用して、必要なすべての App Service リソースと依存リソースをデプロイします。
考慮事項
高 RTO: このプロセスには手動による検出と応答が必要であるため、このシナリオの RTO は数時間または数日になる可能性があります。 RTO を最小限に抑えるには、Web アプリのバックアップを別の Azure リージョンに復元するために必要なすべての手順を概説する包括的なプレイブックを構築してテストします。
セカンダリ リージョンにアプリケーションを作成した後でも、DNS レコードや TLS 証明書などの複雑な処理が必要になる場合があります。 セカンダリ リージョンにトラフィックを送信するために必要な各手順を計画していることを確認し、計画を定期的にテストします。
高 RPO: バックアップは、1 時間に 1 回まで実行するようにスケジュールできます。 プライマリ アプリケーションがオフラインになった場合、セカンダリ リージョンに復元するバックアップが古くなっている可能性があります。 RPO は、バックアップの頻度と、それらのバックアップがリージョン間でレプリケートされる速度によって異なります。
使い方の手順
パッシブコールド デプロイの構成に使用する手順は、リージョンにペアがあるかどうかによって異なります。 詳細については、「 Azure のペアになっているリージョン および 可用性ゾーンとリージョン ペアのないリージョンを参照してください。
App Service で Web アプリのパッシブコールド リージョンを作成する手順は次のとおりです。
Web アプリと同じリージョンに Azure Storage アカウントを作成します。 Standard パフォーマンス レベルを選択し、geo 冗長ストレージ (GRS) または geo ゾーン冗長ストレージ (GZRS) として冗長性を選択します。
RA-GRS または RA-GZRS (セカンダリ リージョンの読み取りアクセス権) を有効にします。
Web アプリのカスタム バックアップを構成します。 Web アプリのバックアップのスケジュール (時間単位など) を設定することもできます。
ストレージ アカウントのセカンダリ リージョンで Web アプリのバックアップ ファイルを取得できることを確認します。
次のステップ
サービス参照アーキテクチャAzure アプリ確認します。
- 単一リージョンのゾーン冗長アプリケーションについては、「 Baseline の高可用性ゾーン冗長 Web アプリケーションを参照してください。
- アクティブ/パッシブ マルチリージョン アプリケーションについては、「 高可用性マルチリージョン Web アプリケーションを参照してください。