Azure Spring Apps の信頼性
このアーティクルには、可用性ゾーン を持つリージョンの回復性と、リージョン間のディザスター リカバリーおよび事業継続 という Azure Spring Apps 向けのサポートに関する詳細情報が含まれています。
可用性ゾーンのサポート
Azure 可用性ゾーンとは、各 Azure リージョン内にある、3 つ以上に物理的に分離されたデータセンターのグループです。 各ゾーン内のデータセンターには、独立した電源、冷却手段、ネットワーク インフラストラクチャが備わっています。 ローカル ゾーンの障害が発生した場合、可用性ゾーンは、1 つのゾーンが影響を受けたときに、リージョンのサービス、容量、高可用性が残りの 2 つのゾーンによってサポートされるように設計されています。
障害の範囲は、ソフトウェアやハードウェアの障害から、地震、水害、火災などの事象に至る可能性があります。 Azure サービスの冗長と論理的な分離により、障害に対するトレランスが実現されます。 Azure の可用性ゾーンの詳細については、リージョンと可用性ゾーンに関する記事を参照してください。
Azure の可用性ゾーン対応サービスは、適切なレベルの信頼性と柔軟性を提供するように設計されています。 それらは 2 つの方法で構成できます。 それらは、ゾーン間の自動レプリケーションによるゾーン冗長、またはインスタンスを特定のゾーンにピン留めするゾーンベースのいずれかになります。 これらのアプローチを組み合わせることもできます。 ゾーン ベースとゾーン冗長のアーキテクチャを比較した詳細については、「可用性ゾーンとリージョンの使用に関する推奨事項」を参照してください。
Azure Spring Apps は、ゾーン冗長をサポートしています。 ゾーン冗長性が有効になった Azure Spring Apps のサービス インスタンスを作成すると、Azure Spring Apps は、基になる Azure インフラストラクチャの論理セクション全体に基本的なリソースを自動的に分散します。 基になるコンピューティング リソースは、コンピューティング能力を確保するために、すべての可用性ゾーンに VM を分散します。 基になるストレージ リソースは、可用性ゾーン間でデータをレプリケートして、データセンターで障害が発生した場合でもデータを使用できるようにします。 この分散により、より高いレベルの可用性を実現し、ハードウェア障害や計画メンテナンス イベントから保護することができます。
前提条件
ゾーン冗長性は Basic プランでは使用できません。
Azure Spring Apps は次のリージョンで可用性ゾーンをサポートしています:
- オーストラリア東部
- ブラジル南部
- カナダ中部
- 米国中部
- 東アジア
- 米国東部
- 米国東部 2
- フランス中部
- ドイツ中西部
- 北ヨーロッパ
- 東日本
- 韓国中部
- 南アフリカ北部
- 米国中南部
- 東南アジア
- 英国南部
- 西ヨーロッパ
- 米国西部 2
- 米国西部 3
可用性ゾーンが有効になった Azure Spring Apps インスタンスを作成する
Note
ゾーン冗長性は、Azure Spring Apps のサービス インスタンスを作成する時にのみ有効にすることができます。 作成後はゾーン冗長性プロパティの変更はできません。
Azure CLI または Azure portal を使って、Azure Spring Apps におけるゾーン冗長性を有効にすることができます。
ゾーン冗長性が有効になった Azure Spring Apps において Azure CLI を使ってサービスを作成するには、次の例に示すように、サービス作成時に --zone-redundant パラメーターを含めます:
az spring create \
--resource-group <your-resource-group-name> \
--name <your-Azure-Spring-Apps-instance-name> \
--location <location> \
--zone-redundant true
可用性ゾーンを有効にして独自のリソースを有効にする
Azure Spring Apps で、永続ストレージなどの独自のリソースを有効にすることができます。 ただし、リソースのゾーン冗長を必ず有効にしなければなりません。 詳細については、「Azure Spring Apps で独自の永続ストレージを有効にする方法」を参照してください。
ゾーン ダウン エクスペリエンス
障害が発生したゾーン内の VM ノードに配置されていることが原因でアプリ インスタンスが失敗する場合、Azure Spring Apps は、別の可用性ゾーンの別の VM ノード上に、障害が発生したアプリのための新しいアプリ インスタンスを作成します。 作成中の時間は、短い中断が発生する可能性があります。 ユーザーは何もする必要はなく、影響を受けた Azure Spring Apps インスタンスはサービスによって復元されます。
価格
ゾーン冗長性の有効に伴う追加のコストは発生しません。 ゾーン冗長性を有効にするための Standard プランまたは Enterprise プランの料金のみ支払う必要があります。
リージョン間のディザスター リカバリーおよび事業継続
ディザスター リカバリー (DR) とは、ダウンタイムやデータ損失につながるような、影響の大きいイベント (自然災害やデプロイの失敗など) から復旧することです。 原因に関係なく、災害に対する最善の解決策は、明確に定義されテストされた DR プランと、DR を積極的にサポートするアプリケーション設計です。 ディザスター リカバリー計画の作成を検討する前に、「ディザスター リカバリー戦略の設計に関する推奨事項」を参照してください。
DR に関しては、Microsoft は共有責任モデルを使用します。 共有責任モデルでは、ベースライン インフラストラクチャとプラットフォーム サービスの可用性が Microsoft によって保証されます。 同時に、多くの Azure サービスでは、データのレプリケート、または障害が発生したリージョンから別の有効なリージョンにクロスレプリケートするフォールバックは、自動的には行われません。 それらのサービスについては、お客様がワークロードに適したディザスター リカバリー計画を設定する必要があります。 Azure PaaS (サービスとしてのプラットフォーム) オファリング上で実行されるほとんどのサービスには、DR をサポートするための機能とガイダンスが用意されており、お客様はサービス固有の機能を使って迅速な復旧をサポートでき、DR 計画の開発に役立ちます。
Azure Spring Apps サービスでは geo ディザスター リカバリーは提供されませんが、慎重に計画することで、ダウンタイムが発生しないように保護できます。
高可用性と災害からの保護を確保するには、Azure Spring Apps でホストされているアプリケーションを複数のリージョンにデプロイします。 Azure には ペアになっているリージョン の一覧が用意されているため、それに従ってアプリケーションのデプロイの計画を立てられます。
アーキテクチャを設計するときには、次の重要な要因を考慮してください。
- 利用可能なリージョン。 ネットワーク ラグと送信時間を最小限に抑えるには、Azure Spring Apps のゾーン冗長性をサポートするリージョン、またはユーザーに近い地域を選択します。
- Azure ペア リージョン。 プラットフォームの調整された更新を確保し、必要に応じて、優先順位の高い復旧作業を行うには、選択した地域内でペアになっているリージョンを選択します。
- サービスの可用性。 ペアになっているリージョンの動作を、ホット/ホット、ホット/ウォーム、またはホット/コールドのいずれにするかを決定します。
Azure Traffic Manager を使用してトラフィックをルーティングする
Azure Traffic Manager には、DNS ベースのトラフィックの負荷分散機能があるため、複数のリージョンにわたってネットワーク トラフィックを分散させることができます。 Azure Traffic Manager を使用して、顧客を最も近い Azure Spring Apps サービス インスタンスに転送します。 最適なパフォーマンスと冗長性を実現するには、Azure Spring Apps サービス インスタンスに送信する前に、すべてのアプリケーション トラフィックを Azure Traffic Manager 経由で転送します。 詳細については、「Traffic Manager について」を参照してください。
複数のリージョンで実行される Azure Spring Apps アプリケーションがある場合は、Azure Traffic Manager で、各リージョン内のアプリケーションへのトラフィック フローを制御できます。 インスタンス IP を使用して、サービス インスタンスごとに Azure Traffic Manager エンドポイントを定義します。 Azure Spring Apps サービス インスタンスを指す Azure Traffic Manager の DNS 名に接続する必要があります。 Azure Traffic Manager では、定義されたエンドポイント間でトラフィックの負荷が分散されます。 データ センターが災害に遭った場合、Azure Traffic Manager により、そのリージョンからそのペアにトラフィックが転送され、サービスの継続性が確保されます。
次の手順を使用して、Azure Spring Apps インスタンス用の Azure Traffic Manager インスタンスを作成します。
2 つの異なるリージョンで Azure Spring Apps インスタンスを作成します。 たとえば、次の表に示すように、米国東部と西ヨーロッパでサービス インスタンスを作成します。 各インスタンスがトラフィックのプライマリとフェールオーバーのエンドポイントとして機能します。
[サービス名] 場所 アプリケーション service-sample-a 米国東部 gateway / auth-service / account-service service-sample-b 西ヨーロッパ gateway / auth-service / account-service サービス インスタンスのカスタム ドメインを設定します。 詳細については、チュートリアル: Azure Spring Apps への既存のカスタム ドメインのマップに関するページを参照してください。 設定が正常に完了すると、両方のサービス インスタンスが
bcdr-test.contoso.comなどの同じカスタム ドメインにバインドされます。Traffic Manager と 2 つのエンドポイントを作成します。 手順については、「 クイックスタート: Azure portal を使用した Traffic Manager プロファイルの作成」をご覧ください。これにより、次の Traffic Manager プロファイルが生成されます。
- Traffic Manager の DNS 名:
http://asa-bcdr.trafficmanager.net - エンドポイント プロファイル:
プロファイル Type 移行先 優先順位 カスタム ヘッダーの設定 エンドポイント A のプロファイル 外部エンドポイント service-sample-a.azuremicroservices.io1 host: bcdr-test.contoso.comエンドポイント B のプロファイル 外部エンドポイント service-sample-b.azuremicroservices.io2 host: bcdr-test.contoso.com- Traffic Manager の DNS 名:
bcdr-test.contoso.com CNAME asa-bcdr.trafficmanager.netの例のように、DNS ゾーンに CNAME レコードを作成します。
これで、環境が設定されました。 リンクされた記事にあるサンプル値を使用した場合は、https://bcdr-test.contoso.com を使用してアプリにアクセスできます。
Azure Front Door と Azure Application Gateway を使用してトラフィックをルーティングする
Azure Front Door は、Microsoft グローバル エッジ ネットワークを使用してセキュリティで保護された高速でスケーラビリティの高い Web アプリを作成するための、スケーラブルなグローバル エントリ ポイントです。 Azure Front Door では、Azure Traffic Manager と同じ複数地域の冗長性と、最も近いリージョンへのルーティングが提供されます。 Azure Front Door には、TLS プロトコルの終了、アプリケーション層の処理、Web Application Firewall (WAF) などの高度な機能も用意されています。 詳細については、「 Azure Front Door とは」をご覧ください。
次の図は、複数リージョンの冗長性、仮想ネットワークに統合された Azure Spring Apps サービス インスタンスのアーキテクチャを示しています。 この図は、カスタム ドメインを使用した Application Gateway と Front Door の正しいリバース プロキシ構成を示しています。 このアーキテクチャは、「 仮想ネットワークでエンドツーエンド TLS を使用してアプリケーションを公開する」で説明されているシナリオに基づいています。 このアプローチでは、2 つの Application-Gateway 統合 Azure Spring Apps 仮想ネットワーク インジェクション インスタンスが geo 冗長インスタンスに結合されます。
