Azure Spring Apps を複数のリージョンにデプロイする

この参照アーキテクチャでは、複数のリージョンで複数の Azure Spring Apps インスタンスをアクティブ/アクティブの構成で実行するための方法について説明します。

この設計は Azure Spring Apps ベースライン アーキテクチャの上に構築されています。 このベースラインは、Java Spring Boot アプリケーションを 1 つのリージョン内の複数の可用性ゾーンにデプロイします。 複数のゾーンがあることで、アプリケーションのワークロードは独立した場所に分散されるため、Azure リージョン内のローカルな障害に耐えることができます。

ただし、リージョン全体で障害が発生した場合、ユーザーはベースラインを使用できなくなります。 この設計の目的は、リージョンの障害に耐えることができる高可用性を構築することです。

このアーキテクチャは、次の目標を達成するのに役立ちます。

• アプリケーションの全体的な回復力とサービス レベル目標 (SLO) を向上させる。
• アプリケーションをグローバルに利用できる。
• ワークロードをエンド ユーザーに近づけ、待機時間をできるだけ短くする。
• セカンダリ リージョンをプライマリ リージョンのフェールオーバー サイトとして使用し、アクティブ/パッシブ設計を選ぶ。

アプリケーションの回復力と信頼性を高めるために、複数のリージョンにアプリケーションをデプロイすることもできます。 この設計では、リージョン間でアプリケーションへの要求を負荷分散するためのグローバル ルーターが必要になります。 このアーキテクチャのグローバル ルーターは、他の目標にも対応します。

マルチリージョンのセットアップの最大の課題は、複数のリージョン間でアプリケーションのデータをレプリケートすることです。 この問題は、マルチゾーンのセットアップの問題ではありません。 Azure 可用性ゾーンは、ラウンドトリップ待ち時間が 2 ミリ秒未満の高パフォーマンス ネットワークによって接続されます。 この待機時間は、ほとんどのアプリケーションで十分です。

アーキテクチャ

次の図は、このアプローチのアーキテクチャを示しています。

Components

このアーキテクチャのコンポーネントは、ベースライン アーキテクチャと同じです。 次の一覧では、ベースライン アーキテクチャに対する変更のみが強調されています。 Azure サービスに関する製品ドキュメントについては、「関連リソース」セクションを参照してください。

• Azure Front Door は、グローバル ロード バランサーとして機能します。 このサービスが使用されるのは、より短い待機時間、より大きなスケール、エッジでのキャッシュ機能によって高可用性を実現する機能があるためです。

ワークフロー

この参照アーキテクチャでは次のワークフローを実装します。

1. ユーザーはアプリケーションの HTTP ホスト名 (たとえば www.contoso.com) に要求を送信します。 Azure DNS により、このホスト名に対する要求が Azure Front Door に解決されます。

2. Azure Front Door は、さまざまな負荷分散構成を使用して、受信要求を各リージョンの Azure Application Gateway のパブリック エンドポイントに転送します。 Application Gateway インスタンスは、Azure Front Door と同じカスタム ドメイン名と TLS 証明書名で構成されています。

3. Azure Web Application Firewall が統合された Application Gateway で、要求が検査されます。 Web Application Firewall では、指定された Azure Front Door プロファイルからの着信要求のみが許可されます。

4. Application Gateway では、許可されたトラフィックを、プロビジョニングされた Spring Apps インスタンス内のロード バランサーの IP アドレスに転送します。

5. 内部ロード バランサーでは、Application Gateway からのトラフィックのみをバックエンド サービスにルーティングします。 これらのサービスは、各リージョンの仮想ネットワーク内の Spring Apps インスタンスでホストされます。

6. 要求の処理の一環として、アプリケーションは仮想ネットワーク内の他の Azure サービスと通信します。 たとえば、Azure Key Vault とシークレットを通信するアプリケーションや、状態を格納するためのデータベースなどがあります。

グローバル配信

高可用性を実現できるように設計する場合は、このアーキテクチャを "アクティブ/アクティブ"、"アクティブ/パッシブ (ホット スタンバイ)"、"アクティブ/パッシブ (コールド スタンバイ)" のいずれかのモードで設定できます。

ユーザーの選択は、アプリケーションの可用性要件に依存します。 このアーキテクチャでは、2 つのリージョンでアクティブ/アクティブのデプロイが使用されています。これは、サンプル組織では、高いアップタイムの SLA (サービス レベル アグリーメント) によるグローバル プレゼンスを必要としているためです。 ミッション クリティカルなアプリケーションを実行していて、可用性を高めたい場合は、2 つ以上のリージョンを使用する必要があります。

アクティブ/アクティブ

アクティブ/アクティブ モードでは、すべてのリージョンで要求が同時に処理されます。 アクティブ/アクティブ モードの最大の課題は、リージョン間のデータの同期を保つことです。 このモードは、ほぼすべてのコンポーネントに二重の支払いが発生するため、コストのかかるアプローチです。

アクティブ/パッシブ (ホット スタンバイ)

ホット スタンバイによるアクティブ/パッシブ モードでは、プライマリ リージョンがアクティブである限り、セカンダリ リージョンは Azure Front Door から要求を受け取りません。 プライマリ リージョンからセカンダリ リージョンにアプリケーション データが確実にレプリケートされるようにしてください。 プライマリ リージョンで障害が発生した場合は、バックエンド データベースのロールを変更し、Azure Front Door 経由のすべてのトラフィックをセカンダリ リージョンにフェールオーバーさせる必要があります。

アクティブ/パッシブ モードでは、フェールオーバーに時間がかかると予想されるため、すべてのデータの同期を維持しやすくなります。 ただし、ホット スタンバイによるアクティブ/パッシブ モードには、アクティブ/アクティブ モードの操作と同じくらいコストがかかります。

アクティブ/パッシブ (コールド スタンバイ)

コールド スタンバイによるアクティブ/パッシブ モードでは、プライマリ リージョンですべてのリソースを保持し、トラフィックが処理されます。 セカンダリ リージョンのコンポーネントは、数が少なかったり、コンピューティング リソースが少なかったりする場合があります。 テクノロジの選択は、ビジネス要件に従ってどの程度のダウンタイムが許容されるかによって決まります。 セカンダリ リージョンの設定の範囲も、コストに影響します。 少なくともアプリケーション データは、セカンダリ リージョンに必ず置いてください。

前述のように、アクティブ/パッシブ モードではフェールオーバーに時間がかかるため、すべてのデータの同期を維持するのが簡単です。コールド スタンバイによるアクティブ/パッシブ モードは、すべてのリソースを両方のリージョンにデプロイしないため、最もコスト効率の高い方法です。

ソリューション全体のセットアップにテンプレートを使用している場合は、必要に応じてリソースを作成することで、簡単にコールド スタンバイのセカンダリ リージョンをデプロイできます。 Terraform、Bicep、または Azure Resource Manager テンプレートを使用して、継続的インテグレーション/継続的デプロイメント (CI/CD) パイプラインでインフラストラクチャのセットアップを自動化できます。 緊急時にテンプレートがデプロイ可能であるようにするために、セカンダリ リージョンを再作成して構成を定期的にテストします。

アプリケーションまたはコンポーネントの複数の独立したコピーを 1 つのテンプレートから複数のリージョンにデプロイできるため、デプロイ スタンプ パターンをお勧めします。

モードの比較

次の表は、各モードでデータを同期するために必要な作業をまとめたもので、コストが比較されています。

リージョン間のルーティング

この参照アーキテクチャでは、任意のリージョンが任意の要求を処理できる地理的ノード (ジオード) を使用します。

2 つのデプロイ リージョン間に均等にルーティングする Azure Front Door を構成します。 Azure Front Door には、配信元への他のトラフィック ルーティング方法も用意されています。 クライアントを最も近い配信元にルーティングする場合は、待機時間に基づいたルーティングが最も適しています。 アクティブ/パッシブ ソリューション用に設計している場合は、優先順位に基づいたルーティングがより適切です。

この参照アーキテクチャの例では、2 つのリージョン間に同程度の重みづけをする負荷分散規則を使用しています。 Azure Front Door は、次のように構成されています。

• アプリケーションのホスト名 (www.contoso.com など) と同じ名前を持つ、カスタム ドメインとトランスポート層セキュリティ (TLS) 証明書。

• アプリケーションがデプロイされているリージョンごとに 1 つの配信元。各配信元は Azure Application Gateway インスタンスです。

リソース グループのレイアウト

Azure リソース グループを使用して、各リージョンにデプロイされたリソースを 1 つのコレクションとして管理します。 次の図に示すように、プライマリ リージョン、セカンダリ リージョン、Azure Front Door を別々のリソース グループにデプロイすることを検討します。

この図はリソース グループの次の構成を示しています。

• Azure Front Door は Application-shared リソース グループにデプロイされています。
• 西ヨーロッパ リージョン (weu) でホストされているすべてのリソースは、Application-weu リソース グループにデプロイされています。
• 米国東部リージョン (eus) でホストされているリソースは、Application-eus リソース グループでホストされています。
• 東日本リージョン (jae) でホストされているリソースは、Application-jae リソース グループでホストされています。

同じリソース グループのリソースは同じライフサイクルを共有するため、一緒に作成したり削除したりするのが簡単です。 各リージョンには、リージョン名に基づく名前付け規則に従う専用のリソース グループ内に独自の一連のリソースがあります。 Azure Front Door は、他のリージョンが追加または削除されても存在する必要があるため、独自のリソース グループ内に配置されています。

リバース プロキシの設定

Azure Front Door では、リージョン間のグローバル負荷分散が行われます。 このリバース プロキシは、ワークロードを複数のリージョンにデプロイする場合に、トラフィックを分散させるのに役立ちます。 また、代わりに Azure Traffic Manager を使用することができます。 Traffic Manager は、ドメイン レベルでのみ負荷分散を行う DNS ベースのトラフィックロードバランサーです。

Azure Front Door には、世界中にプレゼンス ポイント (PoP) が分散している、Microsoft のグローバル エッジ ネットワークからコンテンツを配信する統合コンテンツ配信ネットワーク (CDN) があります。

現在のソリューションでは、2 つのリバース プロキシを使用して、ベースライン アーキテクチャとの一貫性を維持します。 Azure Front Door はグローバル ルーターです。 Application Gateway は、リージョンごとのロード バランサーとして機能します。 ほとんどの場合、この設定は不要です。 以下の要件に対応すれば、Application Gateway をセットアップから削除することも可能です。

• Azure Web Application Firewall は Application Gateway に接続されているため、代わりに Azure Front Door サービスに Web Application Firewall を接続する必要があります。
• 着信呼び出しが Azure Front Door インスタンスからのみ発信されるようにする方法が必要です。 Spring Cloud Gateway アプリケーションで、X-Azure-FDID header のチェックと Azure Front Door IP 範囲のチェックを追加することができます。 詳細については、Spring Cloud Gateway と共に Azure Front Door をリバース プロキシとして使用する方法に関するセクションを参照してください。

さまざまなリバース プロキシのシナリオ、それらの設定方法、セキュリティに関する考慮事項については、「リバース プロキシ経由で Azure Spring Apps を公開する」を参照してください。

バックエンド データベース

マルチリージョンのデプロイの場合は、データ レプリケーション戦略が必要です。 リージョンを越えてアプリケーションを使用できる場合は、ユーザーに古いデータが表示されないようにデータを同期する必要があります。

現在のアーキテクチャでは、バックエンド データベース用に MySQL データベースが使用されていますが、この構成ではデータ同期に対応していません。 データベース テクノロジを選ぶときは、リージョン間でのデータのレプリケートと同期をどのように行うのが最適かを確認してください。 1 つの方法として Azure SQL Database があり、このアクティブ geo レプリケーション機能では、プライマリ データベースに対して、継続的に同期され、読み取り可能なセカンダリ データベースを提供できます。

この機能は、次のシナリオで使用できます。

• セカンダリ リージョンが、アクティブな要求を受信しないコールド スタンバイの場合
• プライマリ リージョンで障害が発生した場合にフェールオーバーするため
• 2 つのリージョン間の仮想ネットワーク ピアリング経由で、プライマリ データベースとセカンダリ データベースに、それぞれのリージョンへのプライベート リンク接続を設定するため。

もう 1 つの方法は、Azure Cosmos DB を使用することです。 このサービスでは、Azure Cosmos DB アカウント内のすべてのリージョンにデータを透過的にレプリケートすることで、データをグローバルに分散することができます。 また、複数の書き込みリージョンを持つ Azure Cosmos DB を構成することもできます。 詳細については、「ジオード パターン」を参照してください。

自動化されたデプロイ

インフラストラクチャのデプロイとアプリケーション コードのデプロイを可能な限り自動化してください。

インフラストラクチャのデプロイを自動化すると、インフラストラクチャが同一に構成されることが保証され、リージョン間などでの構成のずれが回避されます。 インフラストラクチャの自動化によって、フェールオーバー操作をテストすることもできます。

アプリケーションのデプロイの場合は、デプロイ システムのターゲットが、デプロイする必要がある複数のリージョンになっていることを確認します。 また、ブルーグリーンまたはカナリア デプロイ戦略でも、複数のリージョンを使用することができます。 これらのデプロイ戦略では、アプリケーションの新しいバージョンをテスト用に 1 つのリージョンにデプロイし、テストが成功した後に他のリージョンにデプロイします。

パフォーマンスと拡張性

このアーキテクチャでは、複数のリージョン間で負荷が分散されるため、ベースライン アーキテクチャと比べて、アプリケーションの要求を満たすのに適しています。 待機時間に基づいて要求をルーティングするように Azure Front Door を構成すると、要求は最も近いリージョンにルーティングされるため、ユーザーの応答時間が改善されます。

データベースのセットアップによっては、リージョン間でデータを同期する必要がある場合に、余分な待機時間が発生する可能性があります。 この待機時間は、整合性レベルがより緩やかな Azure Cosmos DB を使用することで克服できます。

この参照アーキテクチャには、メトリックに基づいて自動スケーリングできるいくつかのコンポーネントがあります。

• Azure Front Door は、需要に基づいて自動スケーリングを行うことができます。 トラフィック アクセラレーションやキャッシュ機能など、他の Azure Front Door 機能を使用することで、アセットをエンド ユーザーに近づけることができます。
• Application Gateway では自動スケーリングがサポートされています。 詳細については、Application Gateway v2 と Web アプリケーション ファイアウォール v2のスケーリングに関する記事を参照してください。
• Azure Spring Apps でも、自動スケーリングがサポートされています。 詳細については、アプリケーションの自動スケーリングを設定する方法に関するページを参照してください。

コストに関する考慮事項

このソリューションは結果的に、コスト見積もりがベースライン アーキテクチャの倍になります。

マルチリージョン ソリューションに関連するコストの主な要因は次のとおりです。

• プライマリ データベースとセカンダリ データベースで同じサービス レベルを使用する必要があります。そうでない場合、セカンダリ データベースがレプリケーションの変更に追いつけない可能性があります。
• リージョンをまたがる大規模なトラフィックが発生すると、コストが増加します。 Azure リージョン間のネットワーク トラフィックによって料金が発生する。

これらのコストを管理するには、実装に関する次の推奨事項を検討してください。

• スタンバイ リージョンでスケールダウン バージョンの Azure Spring Apps や Application Gateway などのリソースを使用し、スタンバイがアクティブになったときにのみリソースをスケールアップします。
• ビジネス シナリオで許可されている場合は、アクティブ/パッシブ セットアップを作成してコストを節約します。
• 可用性と回復性のビジネス ニーズを満たすために、1 つのリージョンにマルチゾーンのセットアップを実装します。 このオプションでは、ほとんどのリソースに対する支払いが 1 回だけであるため、コスト効率が高くなります。
• コスト削減に役立つようにリバース プロキシを 1 つだけ使用する代替セットアップを選択します。 この代替案では、セキュリティを維持するために追加の構成を適用する必要があることに留意します。

このアーキテクチャのサービスのコストは、小規模なアプリケーション向けの妥当な既定値を使用して、Azure 料金計算ツールで見積もられています。 この見積もりは、アプリケーションに対して期待されるスループット値に基づいて更新できます。

その他の考慮事項

マルチゾーン ベースライン アーキテクチャの設計上の考慮事項は、この記事で説明するマルチリージョン ソリューションにも適用されます。 マルチリージョン アーキテクチャのコンテキストで、次の点を確認します。

• ネットワークのセキュリティ。 ネットワーク経由の通信を制御することが重要です。 このソリューションでは Azure Front Door からの着信呼び出しのみが許可され、この呼び出しは、各リージョンの Application Gateway にルーティングされます。 呼び出しは、Application Gateway からバックエンドの Azure Spring Apps サービスにルーティングされます。 Azure Spring Apps から Key Vault などのサポート サービスへの通信も、プライベート エンドポイントを使用して制御されます。 詳細については、ベースライン アーキテクチャ: ネットワーク セキュリティに関する記事を参照してください。

• ID とアクセスの管理。 マネージド ID を使用してさまざまなコンポーネント間を接続することで、より安全なアクセスを実装します。 1 つの例として、Azure Spring Apps でマネージド ID を使用して Key Vault に接続する方法があります。 詳細については、ベースライン アーキテクチャ: ID およびアクセス管理に関するページを参照してください。

• 監視。 インストルメンテーションを追加し、分散トレースを有効にして、アプリケーションからデータを収集できます。 そのデータ ソースとプラットフォーム診断を組み合わせて、アプリケーションに関する全体的な分析情報を取得します。 詳細については、ベースライン アーキテクチャ: 監視に関する記事を参照してください。

• シークレットの管理 マルチリージョン ソリューションでは、アプリケーション シークレットと証明書を 1 つのキー コンテナーに格納します。 詳細については、ベースライン アーキテクチャ: シークレットの管理に関する記事を参照してください。

シナリオのデプロイ

この参照アーキテクチャのデプロイは、GitHub の Azure Spring Apps マルチリージョン参照アーキテクチャで入手できます。 このデプロイには、Terraform テンプレートが使用されています。

このアーキテクチャをデプロイするには、ステップバイステップの手順に従ってください。

共同作成者

Microsoft では、このコンテンツを保持しています。 元のコンテンツは次の共同作成者によって開発されました。

プリンシパル作成者:

• Gitte Vermeiren | FastTrack for Azure エンジニア

公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。

次の手順

このワークロードを、組織の中央のチームによって管理される共有サービスと統合するには、Azure アプリケーション ランディング ゾーンにデプロイします。

関連リソース

このアーキテクチャで使用される Azure サービスのドキュメントについては、次の記事を参照してください。

• Azure Spring Apps
• Azure Front Door
• Azure Application Gateway v2
• Azure Database for MySQL
• Azure Key Vault
• Azure DNS
• Azure Web アプリケーション ファイアウォール
• Azure Private Link
• Azure リソース用の Microsoft Entra マネージド ID

このアーキテクチャに関連する構成の選択について理解を深めるには、次のガイドをお勧めします。

• リバース プロキシ経由で Azure Spring Apps を公開する
• アプリケーション向けの高可用性ブルー/グリーン デプロイ
• リバース プロキシとそのバックエンド Web アプリケーションの間で、元の HTTP ホスト名を維持する

このアーキテクチャは、Microsoft Azure Well-Architected Framework の重要要素と整合するように設計されています。 各重要要素の設計原則を確認することをお勧めします。