編集

可用性の高い複数リージョンの Web アプリケーション

App Service
Azure Cosmos DB
Front Door
Storage
SQL Database

このアーキテクチャの例はスケーラブルな Web アプリケーションのアーキテクチャの例に基づいており、それを拡張して、Azure App Service アプリケーションを複数のリージョンで実行して高可用性を実現する方法を示します。 この記事に備えて、その設計と、そこで使用されるコンポーネントについて理解を深めておいてください。 ここには再掲しないコア コンポーネントに関する詳細情報が提供されています。

アーキテクチャ

高可用性を備えた Web アプリケーションの参照アーキテクチャを示す図。

このアーキテクチャの Visio ファイルをダウンロードします。

ワークフロー

このアーキテクチャは、「スケーラブルな Web アプリケーション」で説明されているアーキテクチャに基づいて構築されています。 主な違いは次のとおりです。

  • プライマリ リージョンとセカンダリ リージョン。 このアーキテクチャでは、2 つのリージョンを使用して、高可用性を実現します。 アプリケーションは、各リージョンにデプロイされます。 通常の運用中は、ネットワーク トラフィックはプライマリ リージョンにルーティングされます。 プライマリ リージョンが使用できなくなった場合、トラフィックはセカンダリ リージョンにルーティングされます。
  • Front Door。 Front Door は、Web アプリに推奨されるロード バランサーと Web アプリケーション ファイアウォール (WAF) ソリューションであるため、単一リージョンの設計に含まれています。 ただし、この設計での相違点は、ルーティング構成と、Azure CDN を Front Door のネイティブ コンテンツ キャッシング機能で置き換えることにあります。 この設計では、Front Door は優先順位によるルーティング用に構成され、使用できない場合を除き、すべてのトラフィックがプライマリ リージョンに送信されます。 プライマリ リージョンが使用できなくなった場合、Front Door はすべてのトラフィックをセカンダリ リージョンにルーティングします。
  • ストレージ アカウント、SQL Database、または Azure Cosmos DB の geo レプリケーション。

コンポーネント

このアーキテクチャの実装に使用される主要テクノロジ:

この設計のスコープ内のコンポーネントの詳細な説明については、この設計の基になっている記事「スケーラブルな Web アプリケーション」をご覧ください。

シナリオの詳細

リージョン間で高可用性を実現する一般的な方法はいくつかあります。

  • アクティブ/パッシブ (ホット スタンバイ): トラフィックは 1 つのリージョンに送信され、もう一方はホット スタンバイで待機します。 "ホット スタンバイ" とは、セカンダリ リージョン内の App Service が割り当て済みであり、常に実行されていることを意味します。

  • アクティブ/パッシブ (コールド スタンバイ): トラフィックは 1 つのリージョンに送信され、もう一方はコールド スタンバイで待機します。 コールド スタンバイとは、セカンダリ リージョン内の App Service がフェールオーバーで必要になるまで割り当てられないことを意味します。 この方法のほうが実行コストは低くなりますが、ほとんどの場合、障害発生時にオンラインになるまでの時間が長くなります。

  • アクティブ/アクティブ: 両方のリージョンがアクティブであり、要求はそれらの間で負荷分散されます。 片方のリージョンが使用できなくなった場合は、ローテーションから外されます。

このリファレンスでは、ホット スタンバイによるアクティブ/パッシブに焦点を当てています。 これにより、スケーラブルな Web アプリケーションの単一リージョンの設計が拡張されます。 ベース アーキテクチャについては、「スケーラブルな Web アプリケーション」を参照してください。

考えられるユース ケース

これらのユースケースでは、複数リージョンのデプロイのメリットが得られる場合があります。

  • LoB アプリケーションの事業継続とディザスター リカバリー計画を設計する。

  • Windows または Linux で実行されるミッション クリティカルなアプリケーションをデプロイする。

  • アプリケーションを利用可能な状態に保つことで、ユーザー エクスペリエンスを向上させる。

Recommendations

実際の要件は、ここで説明するアーキテクチャとは異なる場合があります。 このセクションに記載されている推奨事項は原案として使用してください。

リージョンのペアリング

各 Azure リージョンは、同じ地区内の別のリージョンとペアリングされます。 通常は、同じリージョン ペアからリージョンを選択します (たとえば、米国東部 2 と米国中部)。 これには、次のような利点があります。

  • 広範囲にわたる停止が発生した場合は、すべてのペアで、少なくとも 1 つのリージョンの復旧が優先的に実行されます。
  • Azure システムの計画的更新は、起こり得るダウンタイムを最小限に抑えるために、ペアになっているリージョンに対して順にロールアウトされます。
  • ほとんどの場合、リージョン ペアは、データの所在地要件を満たすために同じ地区内に所在します。

ただし、両方のリージョンでアプリケーションに必要なすべての Azure サービスがサポートされていることを確認してください。 リージョン別サービスに関する記事を参照してください。 リージョン ペアの詳細については、「ビジネス継続性とディザスター リカバリー (BCDR):Azure のペアになっているリージョン」をご覧ください。

リソース グループ

プライマリ リージョン、セカンダリ リージョン、Front Door を別々のリソース グループにデプロイすることを検討します。 この割り当てにより、各リージョンにデプロイされているリソースを単一のコレクションとして管理できます。

Front Door の構成

ルーティング。 Front Door では、複数のルーティング メカニズムがサポートされています。 この記事で説明するシナリオでは、"優先順位" によるルーティングを使用します。 この設定では、プライマリ リージョンのエンドポイントが到達不能にならない限り、Front Door ではプライマリ リージョンにすべての要求が送信されます。 到達不能になった時点で、セカンダリ リージョンに自動的にフェールオーバーします。 配信元プールに異なる優先順位の値を設定します。アクティブなリージョンは 1、スタンバイまたはパッシブ リージョンは 2 以上にします。

正常性プローブ。 Front Door は、HTTPS プローブを使って、各バックエンドが使用可能かどうかを監視します。 プローブでは、セカンダリ リージョンにフェールオーバーするための成功/失敗テストが Front Door に提供されます。 それは、特定の URL パスに要求を送信することによって機能します。 タイムアウト期間内に 200 以外の応答を取得した場合、プローブは失敗します。 正常性プローブの頻度、評価に必要なサンプルの数、配信元を正常とマークするために必要な成功サンプルの数を構成できます。 Front Door によって機能低下としてマークされた配信元は、他の配信元にフェールオーバーします。 詳細については、「正常性プローブ」を参照してください。

ベスト プラクティスとして、アプリケーションの全体的な正常性を報告するアプリケーション配信元に正常性プローブ パスを作成します。 この正常性プローブでは、App Service アプリ、ストレージ キュー、SQL Database などの重要な依存関係をチェックする必要があります。 これを行わなかった場合、プローブは、アプリケーションの重要な部分で実際には障害が発生しているにもかかわらず、配信元が正常であると報告する可能性があります。 その一方で、優先度の低いサービスをチェックするために正常性プローブを使用しないでください。 たとえば電子メール サービスがダウンした場合、アプリケーションは、2 つ目のプロバイダーに切り替えるか、後でメールを送信できます。 この設計パターンの詳細については、「正常性エンドポイント監視パターン」を参照してください。

インターネットからの配信元のセキュリティ保護は、パブリックにアクセス可能なアプリの実装の重要な部分です。 Front Door でアプリのイングレス通信をセキュリティ保護するための Microsoft が推奨する設計と実装のパターンについては、「ネットワーク セキュア イングレスの実装」をご覧ください。

SQL Database

アクティブ geo レプリケーションと自動フェールオーバー グループを使って、データベースの回復性を高めます。 アクティブ geo レプリケーションを使うと、プライマリ リージョンから 1 つ以上の (最大 4 つ) 他のリージョンにデータベースをレプリケートできます。 自動フェールオーバー グループは、アクティブ geo レプリケーションを基に構築されていて、アプリのコードを変更せずに、セカンダリ データベースにフェールオーバーできるようになります。 フェールオーバーは、ユーザーが作成するポリシー定義に従って、手動または自動で実行できます。 自動フェールオーバー グループを使うには、個々のデータベースの接続文字列ではなく、フェールオーバー グループに対して自動的に作成されるフェールオーバー接続文字列を使って、接続文字列を構成する必要があります。

Azure Cosmos DB

Azure Cosmos DB では、複数の書き込みリージョンを持つアクティブ/アクティブ パターンのリージョン間の geo レプリケーションがサポートされています。 また、あるリージョンを書き込み可能リージョンとして指定し、別のリージョンを読み取り専用レプリカとして指定することもできます。 地域的な停止が発生した場合は、書き込みリージョンにする別のリージョンを選択することで、フェールオーバーできます。 クライアント SDK が書き込み要求を現在の書き込みリージョンに自動的に送信するため、フェールオーバー後にクライアントの構成を更新する必要はありません。 詳細については、「Azure Cosmos DB でのグローバルなデータの分散」を参照してください。

ストレージ

Azure Storage では、読み取りアクセス geo 冗長ストレージ (RA-GRS) を使用します。 データは、RA-GRS を使用して、セカンダリ リージョンにレプリケートされます。 セカンダリ リージョンのデータには、別のエンドポイントを介して読み取り専用でアクセスできます。 geo レプリケートされるストレージ アカウントでは、セカンダリ リージョンへのユーザー開始フェールオーバーがサポートされています。 ストレージ アカウントのフェールオーバーを開始すると、DNS レコードが自動的に更新されて、セカンダリ ストレージ アカウントが新しいプライマリ ストレージ アカウントになります。 フェールオーバーは、必要と思われるときにのみ実行することが必要です。 この要件は組織のディザスター リカバリー計画によって定義されていて、以下の「考慮事項」セクションで説明されているように、その影響を考慮する必要があります。

地域的な停止や災害が発生した場合、Azure Storage チームがセカンダリ リージョンに geo フェールオーバーを実行することを決定する場合があります。 これらの種類のフェールオーバーでは、顧客の操作は必要ありません。 このような場合は、プライマリ リージョンへのフェールバックも Azure ストレージ チームによって管理されます。

場合によっては、ブロック BLOB のオブジェクト レプリケーションがワークロードに対して十分なレプリケーション ソリューションになります。 このレプリケーション機能を使うと、プライマリ ストレージ アカウントからセカンダリ リージョンのストレージ アカウントに、個々のブロック BLOB をコピーできます。 この方法の利点は、レプリケートされるデータを細かく制御できることです。 レプリケーション ポリシーを定義して、レプリケートされるブロック BLOB の種類をさらに細かく制御できます。 ポリシー定義の例を次に示しますが、これらに限定されません。

  • ポリシーの作成後に追加されたブロック BLOB のみをレプリケートする
  • 特定の日時より後に追加されたブロック BLOB のみをレプリケートする
  • 特定のプレフィックスに一致するブロック BLOB のみをレプリケートする

キュー ストレージは、このシナリオで Azure Service Bus への代替メッセージング オプションとして参照されます。 ただし、メッセージング ソリューションにキュー ストレージを使用する場合、geo レプリケーションに関連する上記のガイダンスが、ここにあてはまります。キュー ストレージはストレージ アカウントに存在するためです。 ただし、メッセージはセカンダリ リージョンにレプリケートされず、その状態はリージョンから切り離せないことを理解しておくことが重要です。

Azure Service Bus

Azure Service Bus に提供される最高の回復性を利用するには、名前空間に Premium レベルを使います。 Premium レベルで使用される可用性ゾーンにより、名前空間はデータ センターの停止に対して回復性を持つようになります。 複数のデータ センターに影響を与える広範な障害が発生した場合、Premium レベルに含まれる geo ディザスター リカバリー機能が、復旧に役立つ可能性があります。 geo ディザスター リカバリー機能を使用すると、名前空間 (キュー、トピック、サブスクリプション、フィルター) の構成全体が、確実に、ペアリングされたプライマリ名前空間からセカンダリ名前空間に継続的にレプリケートされるようになります。 これにより、プライマリからセカンダリへの 1 回限りのフェールオーバー移動をいつでも開始できます。 フェールオーバー移動を行うと、名前空間の選択したエイリアス名がセカンダリ名前空間に再指定され、その後にペアリングが解除されます。 フェールオーバーは、開始されるとほぼ瞬時に完了します。

Cognitive Search の可用性は、複数のレプリカによって実現されます。一方、事業継続とディザスター リカバリー (BCDR) は、複数の検索サービスによって実現されます。

Cognitive Search では、レプリカとはインデックスのコピーです。 Azure Cognitive Search で複数のレプリカを用意すれば、あるレプリカでコンピューターの再起動やメンテナンスを行い、同時に他のレプリカでクエリの実行を続けることが可能になります。 レプリカの追加については、「レプリカとパーティションの追加または削減」を参照してください。

検索サービスに 2 つ以上のレプリカを追加することで、Availability Zones を Azure Cognitive Search で利用できます。 各レプリカは、リージョン内の異なる可用性ゾーンに配置されます。

BCDR に関する考慮事項については、「個別の地理的リージョン内の複数のサービス」をご覧ください。

Azure Cache for Redis

Azure Cache for Redis のすべてのレベルでは高可用性のために Standard レプリケーションが提供されますが、さらに高いレベルの回復性と復旧可能性を実現するには Premium または Enterprise レベルをお勧めします。 これらのレベルでの回復性と復旧可能性のすべての機能とオプションの一覧については、「高可用性とディザスター リカバリー」をご覧ください。 どのレベルが実際のインフラストラクチャに最適かは、ビジネス要件によって決まります。

考慮事項

これらの考慮事項は、ワークロードの品質向上に使用できる一連の基本原則である Azure Well-Architected Framework の要素を組み込んでいます。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。

[信頼性]

信頼性により、顧客に確約したことをアプリケーションで確実に満たせるようにします。 詳細については、「信頼性の重要な要素の概要」を参照してください。 リージョン間で高可用性を実現するための設計時には、次の点を考慮してください。

Azure Front Door

Azure Front Door は、プライマリ リージョンが使用できなくなると自動的にフェールオーバーします。 Front Door によってフェールオーバーが実行されると、クライアントがアプリケーションに到達できない時間が発生します (通常は約 20 から 60 秒)。 この持続時間は、次の要因に影響されます。

  • 正常性プローブの頻度。 正常性プローブの送信頻度が高いほど、Front Door によってダウンタイムを検出されたり、配信元が正常な状態に復元されるまでの時間が短縮されたりする可能性があります。
  • サンプル サイズの構成。 この構成によって、プライマリ配信元が到達不能になったことを正常性プローブで検出するために必要なサンプル数を制御します。 この値が低すぎると、間欠的な問題から誤検知を受け取る可能性があります。

Front Door は、システムの障害ポイントになる可能性があります。 このサービスに障害が発生すると、クライアントは、ダウンタイム中はアプリケーションにアクセスできなくなります。 Front Door のサービス レベル アグリーメント (SLA) に関するページを確認し、Front Door の使用だけで高可用性のビジネス要件が満たされるかどうかを判断してください。 満たされない場合は、フォールバックとして別のトラフィック管理ソリューションを追加することを検討してください。 Front Door サービスで障害が発生した場合は、他のトラフィック管理サービスを参照するように、DNS の正規名 (CNAME) レコードを変更します。 この手順は手動で実行する必要があり、DNS の変更が反映されるまでアプリケーションを使用することはできません。

Azure Front Door Standard および Premium レベルは、Azure Front Door (クラシック)、Microsoft の Azure CDN Standard (クラシック)、Azure WAF の機能を 1 つのプラットフォームに統合したものです。 Azure Front Door Standard または Premium を使用すると、障害点が減り、制御、監視、セキュリティが強化されます。 詳細については、「Azure Front Door のレベルの概要」を参照してください。

SQL Database

「Azure SQL Database によるビジネス継続性の概要」に、SQL Database の目標復旧時点 (RPO) と推定目標復旧時間 (RTO) の説明があります。

アクティブ geo レプリケーションでは、レプリケートされる各データベースのコストが実質的に 2 倍になることに注意してください。 サンドボックス、テスト、開発の各データベースは、通常、レプリケーションには推奨されません。

Azure Cosmos DB

Azure Cosmos DB の RPO と目標復旧時間 (RTO) は、使用されている整合性レベルを通じて構成できます。これにより、可用性、データの持続性、スループットのトレードオフが発生します。 Azure Cosmos DB は、マルチマスターを使用した緩やかな整合性レベルの場合は最小 RTO 0 を、シングルマスターを使用した厳密な整合性の場合は RPO 0 を提供します。 Azure Cosmos DB の整合性レベルの詳細については、Azure Cosmos DB での整合性レベルとデータの持続性に関するページを参照してください。

ストレージ

RA-GRS ストレージは持続的なストレージを提供しますが、フェールオーバーの実行を検討するときは、次の要素を考慮することが重要です。

  • データ損失の可能性: セカンダリ リージョンへのデータのレプリケーションは非同期で実行されます。 そのため、geo フェールオーバーが実行された場合、プライマリ アカウントへの変更がセカンダリ アカウントに完全に同期されないと、データ損失が予想されます。 セカンダリ ストレージ アカウントの最終同期時刻プロパティを調べて、プライマリ リージョンのデータがセカンダリ リージョンに正常に書き込まれた最終時刻を確認できます。

  • 目標復旧時間 (RTO) を適切に計画する: 通常、セカンダリ リージョンへのフェールオーバーには約 1 時間かかるため、DR 計画で RTO パラメーターを計算するときにこの情報を考慮する必要があります。

  • フェールバックを慎重に計画する: ストレージ アカウントがフェールオーバーするときに、元のプライマリ アカウントのデータが失われることを理解しておくことが重要です。 慎重な計画を行わずにプライマリ リージョンにフェールバックしようとすると、危険です。 フェールオーバーが完了すると、フェールオーバー リージョン内の新しいプライマリが、ローカル冗長ストレージ (LRS) 用に構成されます。 それをプライマリ リージョンへのレプリケーションを開始するための geo レプリケートされるストレージとして手動で再構成した後、アカウントが同期されるのに十分な時間を設ける必要があります。

  • ネットワークの停止などの一時的なエラーでは、ストレージのフェールオーバーはトリガーされません。 一時的な障害に対する回復力を持つようにアプリケーションを設計してください。 対応策のオプションには次のものがあります。

    • セカンダリ リージョンから読み取ります。
    • 新しい書き込み操作のために別のストレージ アカウントに (たとえばキュー メッセージに) 一時的に切り替えます。
    • データをセカンダリ リージョンから別のストレージ アカウントにコピーします。
    • システムが元の状態に戻るまで、機能を制限します。

詳細については、「Azure Storage の停止が発生した場合の対処方法」をご覧ください。

ブロック BLOB にオブジェクト レプリケーションを使用するときの考慮事項については、「オブジェクト レプリケーションの前提条件と注意事項」をご覧ください。

Azure Service Bus

Premium レベルの Azure Service Bus に含まれる geo ディザスター リカバリー機能を使うと、同じ構成で操作をすぐに継続できることを理解しておくことが重要です。 ただし、キューやトピック サブスクリプションまたは配信不能キューに保持されているメッセージはレプリケートされません。 そのため、セカンダリ リージョンへのスムーズなフェールオーバーのためには軽減戦略が必要です。 その他の考慮事項と軽減策について詳しくは、「考慮すべき重要な点」とディザスター リカバリーでの考慮事項に関する記事をご覧ください。

セキュリティ

セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの重要な要素の概要」を参照してください。

このアーキテクチャは、「スケーラブルな Web アプリケーション」で説明されているアーキテクチャに基づいて構築されています。セキュリティの考慮事項に関するセクションを参照してください。

このアーキテクチャでコンポーネントの ID を定義するときは、可能な限りシステム マネージド ID を使用して、資格情報を管理する必要性と資格情報の管理に伴うリスクを軽減します。 システム マネージド ID を使用できない場合は、すべてのユーザー マネージド ID が 1 つのリージョン内にのみ存在し、リージョンの境界をまたいで共有されることがないようにします。

コンポーネントのサービス ファイアウォールを構成するときは、リージョンにローカルのサービスのみがサービスにアクセスできることと、レプリケーションとアプリケーション機能に明示的に必要な送信接続のみがサービスによって許可されることの両方を確認します。 制御とセグメント化をさらに強化するために、Azure Private Link の使用を検討してください。 Web アプリケーションのセキュリティ保護の詳細については、「PaaS データストアへのプライベート接続を使用したネットワーク強化 Web アプリケーション」を参照してください。

コストの最適化

コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。

コストを見積もるには、料金計算ツールを使用します。 このセクションの次の推奨事項がコストの削減に役立つことがあります。

Azure Front Door

Azure Front Door の課金には、送信データ転送、受信データ転送、ルーティング規則の 3 つの価格レベルがあります。 詳細については、Azure Front Door の価格に関するページを参照してください。 この価格のグラフには、配信元サービスからのデータへのアクセスや Front Door への転送のコストは含まれません。 これらのコストは、「帯域幅の料金詳細」で説明されているデータ転送の料金に基づいて課金されます。

Azure Cosmos DB

Azure Cosmos DB の価格を決定する要因として、次の 2 つがあります。

  • プロビジョニングされているスループットまたは要求ユニット/秒 (RU/秒)。

    Azure Cosmos DB でプロビジョニングできるスループットは、標準と自動スケーリングの 2 種類があります。 標準スループットを使用すると、指定された RU/秒を保証するために必要なリソースが割り当てられます。 自動スケーリングの場合、最大スループットをプロビジョニングすると、Azure Cosmos DB は、最大自動スケーリング スループットの最小値 10% で、負荷に応じてすぐにスケール アップまたはスケール ダウンします。 標準スループットは、プロビジョニングされたスループットに対して 1 時間ごとに課金されます。 自動スケーリング スループットは、消費された最大スループットに対して 1 時間ごとに課金されます。

  • 消費されたストレージ。 特定の 1 時間にデータおよびインデックスで消費されたストレージの合計量 (GB) に対して固定料金が請求されます。

詳細については、「Microsoft Azure Well-Architected Framework」のコストのセクションを参照してください。

オペレーショナル エクセレンス

オペレーショナル エクセレンスとは、アプリケーションをデプロイし、運用環境でそれを動かし続ける運用プロセスのことであり、Well-Architected フレームワークの信頼性ガイダンスを拡張したものです。 このガイダンスでは、確実にワークロードを使用でき、あらゆる規模の障害から復旧できるようにするために、アプリケーション フレームワークに回復性を組み込む方法の詳細な概要を示します。 このアプローチの中心となる考え方は、アプリケーションのインフラストラクチャを高可用性になるように (最適なのは、この設計で示すように複数の地理的リージョンで) 設計することです。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパル作成者:

  • Arvind Boggaram Pandurangaiah Setty |シニア コンサルタント

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ