この参照アーキテクチャでは、Azure Spring Apps で Java Spring Boot ワークロードを実行する方法について説明します。 この設計では、ゾーン冗長を使って高可用性を実現します。 ゾーン内のすべてのデータセンターで障害が発生した場合にアプリケーションが失敗するのを防ぐには、この設計を実装します。
このアーキテクチャは、次の場合に役立ちます。
- 単一ゾーンのデプロイに対するアプリケーションの可用性を向上させる。
- アプリケーションの全体的な回復力とサービス レベル目標 (SLO) を向上させる。
このソリューションでは、Azure Spring Apps のデプロイのベースライン戦略を示します。 このアーキテクチャに基づく他のソリューションについては、「Azure Spring Apps を複数のリージョンにデプロイする」と「ランディング ゾーンと統合された Azure Spring Apps」をご覧ください。
ヒント
このアーキテクチャの設計に関するいくつかの選択を示す実装例を参照してください。 この実装を、運用に向けた最初のステップとして検討してください。
Architecture
次の図は、このアプローチのアーキテクチャを示したものです。
このアーキテクチャの Visio ファイルをダウンロードします。
ワークフロー
このワークフローは、上で示した図に対応しています。
ユーザーが、アプリケーションの HTTP ホスト名 (
www.contoso.comなど) を使ってアプリケーションにアクセスします。 Azure DNS は、このホスト名に対する要求を Azure Application Gateway のパブリック エンドポイントに解決するために使われます。Application Gateway は、要求を検査するために使われます。 また、許可されたトラフィックを、プロビジョニングされた Azure Spring Apps インスタンス内のロード バランサーの IP アドレスに転送するためにも使われます。 Application Gateway は、Azure Web Application Firewall と統合されています。
内部ロード バランサーは、トラフィックをバックエンド サービスにルーティングするために使われます。
要求が処理されている間に、アプリケーションは仮想ネットワーク内の他の Azure サービスと通信します。 たとえば、アプリケーションは Azure Key Vault からシークレットを、またはデータベースから格納状態を、受け取ることがあります。
コンポーネント
次の Azure サービスはこのアーキテクチャのコンポーネントです。
Azure Spring Apps の Standard バージョンは、マイクロサービスとして実装されているサンプルの Java Spring Boot アプリケーションをホストするために使われます。
Application Gateway の Standard v2 バージョンは、アプリケーションへのトラフィックを管理するために使われます。 これは、アプリケーションが実行するリージョンでのローカル リバース プロキシとして機能します。
この SKU には Web Application Firewall が統合されており、Web アプリケーションを悪用や脆弱性から保護するのに役立ちます。 Application Gateway 上の Web Application Firewall により、Open Web Application Security Project (OWASP) の悪用が追跡されます。
Azure DNS は、アプリケーションのホスト名に送信された要求を解決するために使われます。 それらの要求は、Application Gateway のパブリック エンドポイントに解決されます。 Azure DNS のプライベート ゾーンは、指定された Azure Private Link リソースにアクセスするプライベート エンドポイントへの要求を解決するために使われます。
Azure Database for MySQL は、バックエンド リレーショナル データベースに状態を格納するために使われます。
Key Vault は、アプリケーションのシークレットと証明書を格納するために使われます。 Azure Spring Apps で実行されるマイクロサービスでは、アプリケーション シークレットが使用されます。 Azure Spring Apps と Application Gateway では、ホスト名の保存に証明書が使用されます。
代替
データベースとして使用できるのは Azure Database for MySQL だけではありません。 以下を使用することもできます。
冗長性
単一障害点を最小限に抑えるには、ワークロードに冗長性を構築します。 このアーキテクチャでは、リージョン内のゾーン間でコンポーネントをレプリケートします。 アーキテクチャで、セットアップ内のすべてのコンポーネントに可用性ゾーンを使用していることを確認します。
Azure サービスはすべてのリージョンでサポートされているわけではなく、すべてのリージョンがゾーンをサポートしているわけではありません。 リージョンを選ぶ前に、リージョンとゾーンのサポートを確認してください。
ゾーン冗長サービスによって、リソースがゾーン間で自動的にレプリケートまたは分散されます。 常時利用可能型サービスは、Azure のすべての地域で常に利用でき、ゾーン全体とリージョン全体の停止に対して回復性があります。
次の表では、このアーキテクチャのサービスの回復性の種類を示します。
| サービス | 回復性 |
|---|---|
| Azure DNS | 常に使用可能かどうか |
| Application Gateway | ゾーン冗長 |
| Azure Spring Apps | ゾーン冗長 |
| Azure Database for MySQL | ゾーン冗長 |
| Key Vault | ゾーン冗長 |
| Azure Virtual Network | ゾーン冗長 |
| Azure プライベート エンドポイント | ゾーン冗長 |
Azure Spring Apps では、ゾーン冗長がサポートされています。 ゾーン冗長では、サービスの基になるすべてのインフラストラクチャが複数の可用性ゾーンに分散され、アプリケーションの可用性が向上します。 コードを変更しなくても、アプリケーションは水平方向にスケーリングします。 Azure の可用性ゾーンは、ハイ パフォーマンスのネットワークによって接続されます。 接続のラウンドトリップ待機時間は 2 ミリ秒 (ms) 未満です。 設計上の課題となることが多いデータ ワークロードの非同期レプリケーションに依存する必要はありません。
Application Gateway が使うパブリック IP アドレスなど、複数の可用性ゾーンが Application Gateway に対して設定されます。 Standard SKU を使うパブリック IP アドレスは、可用性ゾーンをサポートします。
このアーキテクチャでは、Azure Database for MySQL とフレキシブル サーバーのデプロイ オプションを使って、自動フェールオーバーを備えた高可用性がサポートされます。 待ち時間の要件に応じて、ゾーン冗長高可用性または同一ゾーン高可用性を選びます。 高可用性構成では、フレキシブル サーバー オプションによってスタンバイ レプリカが自動的にプロビジョニングおよび管理されます。 停止が発生した場合、コミットされたデータは失われません。
可用性ゾーンを利用できるすべてのリージョンで、Key Vault は自動的にゾーン冗長になります。 このアーキテクチャで使われる Key Vault のインスタンスは、バックエンド サービス用のシークレットを格納するためにデプロイされます。
スケーラビリティ
スケーラビリティは、ユーザーによる要求を効率的に満たすワークロードの能力を示します。 マルチゾーンの手法は、負荷が複数の可用性ゾーン間で分散されるため、単一ゾーンのデプロイよりスケーラビリティに適しています。
このアーキテクチャには、メトリックに基づいて自動スケーリングできるいくつかのコンポーネントがあります。
Application Gateway では自動スケーリングがサポートされています。 詳細については、Application Gateway v2 と Web アプリケーション ファイアウォール v2のスケーリングに関する記事を参照してください。
Azure Spring Apps では、自動スケーリングがサポートされています。 詳細については、アプリケーションの自動スケーリングを設定する方法に関するページを参照してください。
データベースのセットアップによっては、ゾーン間でデータを同期する必要がある場合に、余分な待機時間が発生する可能性があります。
ネットワークのセキュリティ
インターネット、プライベート ネットワーク内のシステム、他の Azure サービス、緊密に結合された依存関係からの不正アクセスから、アプリケーションを保護します。
Virtual Network は、Azure でのプライベート ネットワークの基本的な構成要素です。 このアーキテクチャでは、デプロイのリージョンに仮想ネットワークが使われます。 さらに分離するには、コンポーネントをサブネットに配置します。 Azure Spring Apps には、サービス ランタイム用の専用サブネットと、Java Spring Boot アプリケーション用の別のサブネットが必要です。
Azure DDoS Protection を使って、仮想ネットワークを保護します。 軽減策を強化して DDoS 攻撃から防御するには、分散型サービス拒否 (DDoS) 保護と、アプリケーションの設計に関するベスト プラクティスを組み合わせます。
アーキテクチャの設計には、ユーザー要求の処理に役立つ複数のサービスとしてのプラットフォーム (PaaS) ソリューションが組み込まれています。 アプリケーションが影響を受けないように、それらのサービスに厳密なネットワーク制御を適用します。
プライベート接続
Azure Spring Apps から Key Vault や Azure Database for MySQL などのサポート サービスへの通信を提供するには、プライベート エンドポイントまたはネットワーク統合を使います。
アクセスを制御するにはプライベート エンドポイントを使います。 ネットワーク インターフェイスは、プライベート IP アドレスを使って、仮想ネットワークにサービスを転送します。 このアーキテクチャでは、プライベート エンドポイントを自動的に設定する Azure サービスが使われます。
仮想ネットワーク インジェクション プロセスを使って、Azure Spring Apps をネットワークにデプロイします。 アプリケーションは、プライベート IP アドレスに到達することによってアクセスされます。
データベースは同様のモデルに従います。 Azure Database for MySQL のフレキシブル サーバー デプロイ モードでは、専用サブネットを介した仮想ネットワーク統合がサポートされます。
Key Vault などの他のサービスは、Private Link 経由で仮想ネットワークに接続されます。 Private Link では、プライベート エンドポイントを有効にして、パブリック ネットワーク アクセスを無効にする必要があります。 詳しくは、「Key Vault を Azure Private Link と統合する」をご覧ください。
プライベート エンドポイントに専用サブネットは必要ありませんが、別のサブネットにそれらを配置することをお勧めします。 プライベート エンドポイントへのプライベート IP アドレスは、そのサブネットから割り当てます。
プライベート エンドポイントとネットワーク統合接続では、Azure DNS プライベート ゾーンが使われます。
トラフィック フローの制御
このアーキテクチャでは、Application Gateway によって公開されるパブリック エンドポイント経由でのみ着信要求が許可されます。 それでも、悪用と脆弱性をブロックするために、トラフィックの検査は必要です。 Application Gateway 上の Web Application Firewall では、OWASP の脆弱性が追跡されます。 受信トラフィックは、従うアクションを使用して構成されたルールに基づいて検査されます。
Azure Spring Apps インスタンスには、バックエンド サービスにトラフィックをルーティングして分散する内部ロード バランサーがあります。 このロード バランサーは、Application Gateway からのみトラフィックを受け入れるように構成されています。
アプリケーションは、パブリック インターネット経由で他のエンドポイントと接続する必要がある場合があります。 そのフローを制限するには、エグレス パスに Azure Firewall を配置することを検討してください。
リバース プロキシの設定
このソリューションでは、リバース プロキシとして Application Gateway を使います。 ただし、Azure Spring Apps の前面で異なるリバース プロキシを使用できます。 Application Gateway と Azure Front Door を組み合わせることも、Application Gateway の代わりに Azure Front Door を使うこともできます。
リバース プロキシのシナリオ、それらの設定方法、セキュリティに関する考慮事項については、「リバース プロキシ経由で Azure Spring Apps を公開する」をご覧ください。
ID 管理とアクセス管理
ネットワーク制御の使用に加えて、境界として ID を使うことによりセキュリティ態勢を強化します。
アプリケーションでは、Key Vault からシークレットを取得する場合など、バックエンド サービスに接続するときに自身の認証を行う必要があります。 アプリケーションでは、Microsoft Entra の Azure リソース用マネージド ID を有効にすることをお勧めします。 この構成方法では、Microsoft Entra ID トークンを取得できるようにアプリケーションに ID を割り当てることで、資格情報を管理するオーバーヘッドが軽減されます。
このアーキテクチャでは、いくつかの操作のためにシステム割り当てマネージド ID が使用されます。
バックエンド サービスでは、マネージド ID に割り当てられたサービス プリンシパルへのアクセスを許可する必要があります。 サービスでは、特定のアクションに対して最小限のアクセス ポリシーを定義する必要があります。 このアーキテクチャでは、アプリケーションがシークレット、証明書、キーにアクセスできるようにするため、Key Vault が使われます。
シークレットの管理
このアーキテクチャでは、アプリケーション シークレットと証明書を 1 つのキー コンテナーに格納します。 アプリケーションのシークレットと、ホスト名を保持するための証明書は、異なる検討事項であるため、これらの項目は別々のキー コンテナーに格納した方がよい場合があります。 この代替方法では、アーキテクチャに別のキー コンテナーが追加されます。
監視
Azure Monitor は、クラウド環境とオンプレミス環境からの監視データを収集し、分析して、対応するための監視ソリューションです。
コード レベルでログとメトリックを出力するには、インストルメンテーションをアプリケーションに追加します。 Azure Spring Apps インスタンス内のサービス間で監視できるようにするには、分散トレースを有効にすることを検討します。 ログとメトリックのデータを収集するには、アプリケーション パフォーマンス管理 (APM) ツールを使います。 APM ツールとしては、Azure Monitor 用の Application Insights Java エージェントがよい選択肢です。
Azure Database for MySQL などのすべての Azure サービスからログとメトリックを取得するには、プラットフォーム診断を使います。 すべてのデータを Azure Monitor ログと統合して、アプリケーションとプラットフォーム サービスに対するエンド ツー エンドの分析情報を提供します。
Azure Log Analytics ワークスペースは、Azure リソースと Application Insights からログとメトリックを収集する監視データ シンクです。 このログ ソリューションによって提供される可視性は、コンポーネントをリアルタイムでスケーリングするための自動化プロセスに役立ちます。 ログ データを分析することで、アプリケーション コードの非効率性を見つけ出し、コストとパフォーマンスを改善するために対策を講じることができます。
Spring App 固有の監視のガイダンスについては、「アプリケーションをエンド ツー エンドで監視する」および Dynatrace Java OneAgent を使用した監視に関する記事をご覧ください。
自動化されたデプロイ
インフラストラクチャのデプロイとアプリケーション コードのデプロイを可能な限り自動化してください。
インフラストラクチャのデプロイを自動化すると、インフラストラクチャの構成が同一であることが保証され、環境間で発生する可能性がある構成の相違を回避するのに役立ちます。 インフラストラクチャの自動化を使って、フェールオーバー操作をテストすることもできます。
アプリケーションにはブルーグリーンまたはカナリア デプロイ戦略を使用できます。
考慮事項
以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。
次の考慮事項では、このアーキテクチャのコンテキストで Azure Well-Architected フレームワークの柱を実装するためのガイダンスを提供します。
信頼性
信頼性により、顧客に確約したことをアプリケーションで確実に満たせるようにします。 詳細については、「信頼性の重要な要素の概要」を参照してください。
より信頼性の高いアプリケーションを作成するには、以下で推奨する機能を実装します。
ブルーグリーン デプロイを使って、重大な問題が発生した場合に以前の正常な状態に簡単にロールバックできるようにします。
アプリケーションに自動スケーリングを設定して、需要が変化したときにアプリケーションがより適切に実行できるようにします。
Spring Boot の Web の正常なシャットダウンを有効にし、Azure Spring Apps の正常な終了を構成して、アプリ インスタンスで実行しているプロセスを強制的に停止します。
セキュリティ
セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの重要な要素の概要」を参照してください。
より安全なアプリケーションを作成するには、以下で推奨する機能を実装します。
Microsoft Entra ID などの成熟した ID およびアクセス管理 (IAM) ソリューションを使います。 多要素認証を有効にします。 詳細については、以下を参照してください:
可能な限りパスワードを使わないようにします。 詳細については、以下を参照してください:
Azure Spring アプリのセキュリティ保護方法に関する推奨事項については、「Azure Spring Apps の Azure セキュリティ ベースライン」をご覧ください。
コストの最適化
コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。
このアーキテクチャでは、コンポーネントを複数のゾーンにデプロイするため、コストが高くなることが予想されます。 Azure Spring Apps の 1 つのインスタンスではなく、2 つまたは 3 つのインスタンスを実行します。 ただし、サービスでゾーン冗長を有効にしても追加コストは発生しません。 詳しくは、Azure Spring Apps の価格に関する記事をご覧ください。
コストに対処するには、次の実装の選択肢を検討してください。
Azure Spring Apps の単一のインスタンスに、さまざまなアプリケーションとアプリケーションの種類をデプロイできます。 複数のアプリケーションをデプロイすると、基になるインフラストラクチャのコストがアプリケーション間で共有されます。
Azure Spring Apps では、メトリックまたはスケジュールによってトリガーされるアプリケーションの自動スケーリングがサポートされており、これによって使用率とコスト効率を向上できます。
Azure Monitor の Application Insights を使用して、運用コストを削減することができます。 継続的な監視は、問題に迅速に対処し、コストとパフォーマンスを向上させるのに役立ちます。
要件に基づいて最適な価格レベルを選びます。
需要に基づいてスケールアップおよびスケールダウンするには、アプリケーションの自動スケーリングを使います。
このアーキテクチャのサービスの推定コストについては、Azure 料金計算ツールをご覧ください。 この見積もりでは、小規模なアプリケーションの妥当な既定値が使われます。 見積もりは、アプリケーションに対して予想されるスループットの値に基づいて更新できます。
オペレーショナル エクセレンス
オペレーショナル エクセレンスは、アプリケーションをデプロイし、それを運用環境で実行し続ける運用プロセスをカバーします。 詳細については、「オペレーショナル エクセレンスの重要な要素の概要」を参照してください。
前に説明した監視ガイダンスに加えて、以下で推奨するアプリケーションのデプロイと監視に役立つ機能を実装します。
Azure DevOps または GitHub Actions を使って、アプリケーションのデプロイを自動化します。
Azure Managed Grafana を使って、アプリケーションとインフラストラクチャのテレメトリ データをリアルタイムで表示および分析します。
パフォーマンス効率
パフォーマンス効率とは、ユーザーによって行われた要求に合わせて効率的な方法でワークロードをスケーリングできることです。 詳細については、「パフォーマンス効率の柱の概要」を参照してください。
より効率的なアプリケーションを作成するには、以下で推奨する機能を実装します。
このシナリオのデプロイ
このアーキテクチャをデプロイするには、Azure Spring Apps のマルチゾーン参照アーキテクチャに関するページの手順のようにしてください。 このデプロイには、Terraform テンプレートが使用されています。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパル作成者:
- Gitte Vermeiren | FastTrack for Azure エンジニア
パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。