Azure Spring Apps の信頼性

この記事には、可用性ゾーンを使用したリージョンの回復性と、リージョン間のディザスターリカバリーおよび事業継続という Azure Spring Apps 向けのサポートに関する詳細情報が含まれています。

可用性ゾーンのサポート

可用性ゾーンは、Azure リージョン内のデータセンターの物理的に分離されたグループです。 1 つのゾーンで障害が発生した際には、サービスを残りのゾーンのいずれかにフェールオーバーできます。

Azure Spring Apps ではゾーン冗長がサポートされています。ゾーン冗長性が有効になった Azure Spring Apps のサービスインスタンスを作成すると、Azure Spring Apps によって、基になる Azure インフラストラクチャの論理セクション全体に基本的なリソースが自動的に分散されます。基になるコンピューティングリソースは、コンピューティング能力を確保するために、すべての可用性ゾーンに VM を分散します。基になるストレージリソースは、可用性ゾーン間でデータをレプリケートして、データセンターで障害が発生した場合でもデータを使用できるようにします。この分散により、より高いレベルの可用性を実現し、ハードウェア障害や計画メンテナンスイベントから保護することができます。

[前提条件]

ゾーン冗長性は Basic プランでは使用できません。
Azure Spring Apps では、次のリージョンで可用性ゾーンがサポートされています。
- オーストラリア東部
- ブラジル南部
- カナダ中部
- 米国中部
- 東アジア
- 米国東部
- 米国東部 2
- フランス中部
- ドイツ中西部
- 北ヨーロッパ
- 東日本
- 韓国中部
- 南アフリカ北部
- 米国中南部
- 東南アジア
- 英国南部
- 西ヨーロッパ
- 米国西部 2
- 米国西部 3

可用性ゾーンが有効になった Azure Spring Apps インスタンスを作成する

注

ゾーン冗長性は、Azure Spring Apps のサービスインスタンスを作成する時にのみ有効にすることができます。作成後はゾーン冗長性プロパティの変更はできません。

Azure CLI または Azure portal を使って、Azure Spring Apps におけるゾーン冗長性を有効にすることができます。

Azure CLI
Azure Portal

ゾーン冗長性が有効になった 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 インスタンスはサービスによって復元されます。

Pricing

ゾーン冗長性の有効に伴う追加のコストは発生しません。ゾーン冗長性を有効にするための 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	米国東部	ゲートウェイ / 認証サービス / アカウントサービス
service-sample-b	西ヨーロッパ	ゲートウェイ / 認証サービス / アカウントサービス

サービスインスタンスのカスタムドメインを設定します。詳細については、チュートリアル: Azure Spring Apps への既存のカスタムドメインのマップに関するページを参照してください。設定が正常に完了すると、両方のサービスインスタンスが bcdr-test.contoso.com などの同じカスタムドメインにバインドされます。

Traffic Manager と 2 つのエンドポイントを作成します。手順については、「クイックスタート: Azure portal を使用した Traffic Manager プロファイルの作成」をご覧ください。これにより、次の Traffic Manager プロファイルが生成されます。

Traffic Manager の DNS 名: http://asa-bcdr.trafficmanager.net
エンドポイントプロファイル:

Profile	タイプ	目標	Priority	カスタムヘッダーの設定
エンドポイント A のプロファイル	外部エンドポイント	`service-sample-a.azuremicroservices.io`	1	`host: bcdr-test.contoso.com`
エンドポイント B のプロファイル	外部エンドポイント	`service-sample-b.azuremicroservices.io`	2	`host: bcdr-test.contoso.com`

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 冗長インスタンスに結合されます。

次のステップ

フィードバック

このページはお役に立ちましたか?

Last updated on 2025-11-19