ランディング ゾーンと統合された Azure Spring Apps

この参照アーキテクチャでは、Azure ランディング ゾーンに Azure Spring Apps ベースライン アーキテクチャをデプロイします。

このシナリオでは、お客様の組織は中央チーム (プラットフォーム) によって管理されるフェデレーション リソースをワークロードで使用することを期待しています。一元管理の例としては、オンプレミスの接続、ID アクセス管理、ポリシーのネットワークなどがあります。 このガイダンスでは、組織が一貫性のあるガバナンスを適用し、複数のワークロードでコストを節約するために Azure ランディング ゾーンを採用していることを前提としています。

このアーキテクチャで行われた設計の選択については、このアクセラレータの主要な技術設計領域で説明します。 詳細については、「Azure Spring Apps ランディング ゾーン アクセラレータ」をご覧ください。

アーキテクチャ

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

このアーキテクチャの一般的な用途は次のとおりです。

• プライベート アプリケーション: ハイブリッド クラウド環境にデプロイされた内部アプリケーション。
• パブリック アプリケーション: 外部に接続するアプリケーション。

これらのユース ケースは、セキュリティの構成とネットワーク トラフィック規則以外は似ています。

Components

次のセクションでは、このアーキテクチャのコンポーネントについて説明します。 コンポーネントは所有権の責任に従って分割され、組織のプラットフォーム チームと共有する内容を特定するのに役立ちます。 Azure サービスに関する製品ドキュメントについては、「関連リソース」セクションを参照してください。

アプリケーション チーム所有のリソース

チームは、次のリソースの作成と保守を担当します。

• Azure Spring Apps Standard は、Azure で Java Spring Boot アプリケーションをホストします。

• Azure Application Gateway Standard_v2 は、受信 Web トラフィックを Azure Spring Apps にルーティングするリバース プロキシです。 この SKU には、Open Web Application Security Project (OWASP) の脆弱性のトラフィックを検査する Azure Web Application Firewall が統合されています。

• Azure Virtual Machine は、管理操作のジャンプ ボックスとして機能します。

• Azure Database for MySQL アプリケーション データを保存します。

• Azure Key Vault には、データベースへの接続文字列などのシークレットと構成が保存されます。

• Log Analytics は、Azure Monitor ログとも呼ばれる Azure Monitor の機能の 1 つです。 Log Analytics は、アプリケーションと Azure サービスからのログとメトリックを保存する監視シンクです。

• Azure Application Insights は、アプリケーション パフォーマンス管理 (APM) ツールとして使用され、すべてのアプリケーション監視データを収集し、Log Analytics 内に直接保存します。

プラットフォーム チーム所有のリソース

このアーキテクチャでは、次のリソースが既に存在することを前提としています。 組織の中央チームが、リソースを所有して管理します。 運用オーバーヘッドを削減し、コストを最適化するために、アプリケーションはこれらのサービスに依存しています。

• Azure Firewall は、エグレス トラフィックを検査して制限します。

• Azure Bastion は、管理ジャンプ ボックスへの安全なアクセスを提供します。

• Azure ExpressRoute は、オンプレミスから Azure インフラストラクチャへのプライベート接続を提供します。

• Azure DNS は、クロスプレミスの名前解決を提供します。

• Azure VPN Gateway は、オンプレミス ネットワーク内のリモート チームとアプリケーションを接続します。

アプリケーションに関する検討事項

参照実装には、Azure Spring Apps インスタンスでホストされる一般的なマイクロサービス アプリケーションを示すサンプル アプリケーションが含まれています。 以下のセクションでは、ホストされたアプリケーションに関する詳細を説明します。 詳細については、「PetClinic のストア サンプル」をご覧ください。

サービス検出

マイクロサービス パターンでは、ユーザー要求とサービス間通信をルーティングするために、サービス レジストリ機能をサポートする必要があります。

サービスが他のサービスと通信できる必要があります。 新しいインスタンスが生成されると、動的に検出できるようにレジストリに追加されます。 このアーキテクチャでは、Azure Spring Apps に対してマネージド Spring Cloud Service Registry (OSS) が有効になっています。 このサービスは、ライブ アプリ インスタンスのレジストリを維持し、クライアント側の負荷分散を有効にし、ドメイン ネーム サービス (DNS) に依存せずにクライアントからサービス プロバイダーを分離します。

Azure Spring Apps インスタンスは、外部トラフィックの単一エントリ ポイントを提供するゲートウェイ ルーティング パターンを実装します。 ゲートウェイは、レジストリ内にあるアクティブなサービス インスタンスに受信要求をルーティングします。 この設計では、このパターンは Spring Cloud Gateway のオープンソース実装で実装されます。 認証および承認、回復性機能、レート制限などを含む機能セットを提供します。

構成サーバー

マイクロサービスの場合、構成データはコードから分離する必要があります。 このアーキテクチャでは、Azure Spring Apps Config Server は、ローカル ストレージと Git リポジトリをサポートするプラグ可能なリポジトリを通してリソースの管理が可能になります。

冗長性

Azure Spring Apps インスタンスを作成するときに可用性ゾーンを使用できます。

この機能により、Azure Spring Apps で、基になる Azure インフラストラクチャの論理セクション間で基本的なリソースが自動的に分散されます。 この分散により、より高いレベルの可用性を実現し、ハードウェア障害や計画メンテナンス イベントから保護することができます。

ゾーン冗長性により、基になる VM ノードがすべての可用性ゾーンに均等に分散されます。 ただし、ゾーン冗長性では、アプリ インスタンスの均等な分散は保証されません。 配置されたゾーンがダウンしたためにアプリ インスタンスが失敗した場合、Azure Spring Apps は、他の可用性ゾーン内のノード上にこのアプリの新しいアプリ インスタンスを作成します。

Azure Spring Apps で独自のリソース (独自の永続ストレージなど) を有効にする場合は、リソースのゾーン冗長性を有効にします。 詳細については、「Azure Spring Apps で独自の永続ストレージを有効にする方法」を参照してください。

可用性ゾーンは一部のリージョンでサポートされていません。 可用性ゾーンをサポートするリージョンについては、「可用性ゾーンがサポートされている Azure リージョン」をご覧ください。

スケーラビリティ

Azure Spring Apps には、すぐに使用できる自動スケーリング機能が用意されており、アプリはメトリックのしきい値に基づいて、または特定の時間枠内にスケーリングできます。 自動スケーリングは、需要の変化に応じてアプリをスケールアップまたはスケールアウトする必要がある場合に推奨されます。

Azure Spring Apps では、CPU、インスタンスあたりのメモリ/GB、アプリ インスタンス数を調整することによるアプリケーションの手動スケーリングもサポートされています。 この種類のスケーリングは、特定のアプリに対して実行する 1 回限りのスケーリング アクティビティに適しています。 アプリケーションのスケーリングのニーズに合わせて値を調整し、設定が各属性の上限内にあることを確認します。

ネットワークに関する考慮事項

この設計では、ワークロードはオンプレミスのリソースにアクセスしたり、エグレス トラフィックを制御したりするために、プラットフォーム チームが所有するリソースに依存します。 詳細については、Azure Spring Apps ランディング ゾーン アクセラレータ: ネットワーク トポロジと接続性に関する記事を参照してください。

ネットワーク トポロジ

プラットフォーム チームがネットワーク トポロジを決定します。 このアーキテクチャでは、ハブスポーク トポロジが想定されています。

ハブ仮想ネットワーク

接続サブスクリプションには、組織全体で共有されるハブ仮想ネットワークが含まれます。 このネットワークには、プラットフォーム チームによって所有および管理されているネットワーク リソースが含まれています。 次のプラットフォーム チーム リソースは、このアーキテクチャのスコープ内にあります。

• Azure Firewall はインターネットへの送信トラフィックを制限します。
• Azure Bastion は、管理ジャンプ ボックスへのアクセスをセキュリティで保護します。

スポーク仮想ネットワーク

アプリケーション ランディング ゾーンには、ハブ ネットワークとピアリングされたプロビジョニング済み仮想ネットワークが少なくとも 1 つ存在します。 インターネットから Azure Spring Apps への受信 HTTP/s 接続をルーティングして保護するロード バランサーなど、このネットワーク内のリソースを所有しています。

事前にプロビジョニングされた仮想ネットワークとピアリングが、ワークロードの予想される増加に対応できることが必要です。 仮想ネットワークのサイズを見積もり、プラットフォーム チームと定期的に要件を評価します。 詳細については、「仮想ネットワークの要件」をご覧ください。

VNet インジェクションとサブネット化

Azure Spring Apps は、VNET インジェクション プロセスを介してネットワークにデプロイされます。 このプロセスにより、インターネット、プライベート ネットワーク内のシステム、他の Azure サービス、さらにはサービス ランタイムからアプリケーションが分離されます。 アプリケーションからの受信トラフィックと送信トラフィックは、ネットワーク規則に基づいて許可または拒否されます。

サブネットによって分離を実現します。 スポーク仮想ネットワークへのサブネットの割り当ては、お客様が行う必要があります。 Azure Spring Apps には、サービス ランタイム用と、Java Spring Boot アプリケーション用の 2 つの専用サブネットが必要です。

このサブネットは、1 つの Azure Spring Apps インスタンス専用である必要があります。 複数のサブネットで同じサブネットを共有することはできません。

各サブネットの最小サイズは /28 です。 実際のサイズは、Azure Spring Apps でサポートできるアプリケーション インスタンスの数によって異なります。 詳細については、「使用するサブネット範囲を小さくする」を参照してください。

ネットワーク制御

インターネットからスポーク仮想ネットワークへの受信トラフィックは、Web Application Firewall を使用して Azure Application Gateway によって制限されます。 Web Application Firewall 規則では、HTTP/s 接続を許可または拒否します。

ネットワーク内のトラフィックは、サブネット上のネットワーク セキュリティ グループ (NSG) を使用して制御されます。 NSG は、構成された IP アドレスとポートに従ってトラフィックをフィルター処理します。 この設計では、NSG はすべてのサブネットに配置されます。 Azure Bastion サブネットでは、インターネット、ゲートウェイ サービス、ロード バランサー、仮想ネットワークからの HTTPS トラフィックが許可されます。 サブネットから許可されるのは、仮想ネットワークへの RDP および SSH 通信のみです。

プライベート リンクは、Azure Spring Apps と他の Azure サービス間の接続 (キー コンテナーとデータベースへのアクセスなど) を制御するために使用されます。 プライベート エンドポイントは、別のサブネットに配置されます。

地理的障害発生時に引き続き可用性を確保するために、アプリケーション ホスト DNS レコードを Azure プライベート DNSに保存する必要があります。

接続サブスクリプションにはプライベート DNS ゾーンがありますが、プライベート エンドポイントからアクセスするサービスをサポートするためには、独自の Azure プライベート DNS ゾーンを作成します。

データ流出攻撃を防ぐために、仮想ネットワークからの送信トラフィックを制限する必要があります。 このトラフィックは、完全修飾ドメイン名 (FQDN) を使用してフローを許可または拒否する一元化された Azure Firewall (ネクスト ホップ) を介してルーティングされます。

ID 管理とアクセス管理

ワークロードの ID 実装は、アプリケーションが組織のセキュリティやガバナンスの境界に違反しないように、組織のベスト プラクティスに準拠している必要があります。 詳細については、Azure Spring Apps ランディング ゾーン アクセラレータ: ID およびアクセス管理に関する記事を参照してください。

Microsoft Entra ID は、Azure Spring Apps インスタンスと連携するユーザーとサービスを認証するために推奨されます。

推奨される方法は、アプリケーションの Azure リソースの Microsoft Entra マネージド ID を有効にして、アプリが他のサービスに対して自己認証できるようにすることです。 このアーキテクチャでは、管理を容易にするために、システム割り当てのマネージド ID が使用されます。

承認には、アクセス許可を付与するときに最小特権の原則を適用して、Azure ロール ベースのアクセス制御 (RBAC) を使用します。

監視に関する考慮事項

Azure ランディング ゾーン プラットフォームは、管理サブスクリプションの一部として共有監視リソースを提供します。 ただし、ワークロードの全体的な管理を簡略化するために、独自の監視リソースをプロビジョニングすることをお勧めします。 詳細については、Azure Spring Apps ランディング ゾーン アクセラレータ: モニター操作に関する記事を参照してください。

このアーキテクチャでは、次のリソースが作成されます。

• Azure Application Insights はアプリケーション パフォーマンス監視 (APM) ソリューションであり、Java エージェントを使用してサービスに完全に統合されます。 このエージェントで、追加のコードを必要とせずに、デプロイされたすべてのアプリケーションと依存関係を可視化できます。
• Azure Log Analytics ワークスペースは、Azure サービスとアプリケーションから収集されたすべてのログとメトリックの統合シンクです。

Azure Spring Apps インスタンスを構成して、診断ログをアプリケーションからプロビジョニングされた Log Analytics ワークスペースに送信します。 詳細については、「アプリケーションをエンド ツー エンドで監視する」をご覧ください。

他の Azure サービスのログとメトリックを収集します。 ブート診断はジャンプ ボックスに対して有効になっているため、仮想マシンの起動時にイベントをキャプチャできます。

診断設定を構成して、その他全ての Azure リソースのリソース ログを Log Analytics ワークスペースに送信します。 リソース ログは、宛先にルーティングされるまで収集されません。 各 Azure リソースには、独自の診断設定が必要です。

複数のワークスペースからのデータの関連付け

ワークロードとそのインフラストラクチャ コンポーネントによって生成されたログとメトリックは、ワークロードの Log Analytics ワークスペースに保存されます。 ただし、Active Directory や Azure Firewall などの一元化されたサービスによって生成されたログとメトリックは、プラットフォーム チームによって管理される中央の Log Analytics ワークスペースに保存されます。 さまざまなシンクからデータを関連付けると、複雑さが発生する可能性があります。

ワークロードが一元化されたサービスに依存するユーザー フローのシナリオを考えてみましょう。 データの一部はワークロード レベルで収集され、中央の Log Analytics ワークスペースにエクスポートされる場合があります (ここで、プラットフォーム ログと関連付けられます)。

ただし、他のエントリは、データ ボリューム、形式の相互運用性、セキュリティの制約などの問題のために、ワークロードのワークスペースにのみ存在する可能性があります。 相関のないログ エントリが 1 つのユーザー フローに対して 2 つ以上のワークスペースに存在する場合、特定の問題のトラブルシューティングがより難しくなる可能性があります。 このように複雑さが増すと、チームは連携してアプリケーション インシデントのトラブルシューティングを行う必要があります。

このようなコラボレーションに役立てるために、組織によって設定された手順をよく理解しておいてください。 セキュリティ インシデントが発生した場合、ワークロード レベルの管理者は、システムのログで悪意のあるアクティビティの兆候を確認するか、さらに分析するためにログのコピーをインシデント ハンドラーに提供するように求められる場合があります。 ワークロード管理者がアプリケーションの問題のトラブルシューティングを行っている場合、エンタープライズ ネットワーク、セキュリティ、またはその他のプラットフォーム サービスからのログ エントリを関連付けるために、プラットフォーム管理者の支援が必要になる場合があります。

正常性プローブ

Azure Application Gateway では、正常性プローブを使用して、受信トラフィックが応答性の高いバックエンド インスタンスにルーティングされるようにします。 Azure Spring Apps Readiness、Liveness、Startup プローブをお勧めします。 障害が発生した場合、これらのプローブは正常に終了するのに役立ちます。 詳細については、正常性プローブを構成する方法についてご覧ください。

セキュリティに関する考慮事項

一元化されたチームは、プラットフォームの一部としてネットワークと ID のコントロールを提供します。 ただし、ワークロードには、攻撃対象領域を減らすためにセキュリティ アフォーダンスが必要です。 詳細については、Azure Spring Apps ランディング ゾーン アクセラレータ: セキュリティを参照してください。

保存データ

保存データは暗号化する必要があります。 アプリケーション自体はステートレスです。 データは外部データベースに保持されます (この場合、このアーキテクチャは Azure Database for MySQL を退けさせます。)。 このサービスでは、バックアップやクエリの実行中に作成される一時ファイルを含むデータが暗号化されます。

転送中のデータ

転送中のデータは暗号化する必要があります。 ユーザーのブラウザーと Azure Application Gateway 間のトラフィックは、転送中にデータが変更されないように暗号化する必要があります。 このアーキテクチャでは、Azure Application Gateway は HTTPS トラフィックのみを受け入れ、TLS ハンドシェイクをネゴシエートします。 このチェックは、Application Gateway サブネットの NSG 規則によって適用されます。 TLS 証明書はデプロイ中に直接読み込まれます。

Application Gateway から Azure Spring Apps インスタンスへのトラフィックは、セキュリティで保護されたトラフィックのみがアプリケーションに到達するように再暗号化されます。 Azure Spring Apps サービス ランタイムはそのトラフィックを受信し、TLS 終端点として機能します。 この点からは、アプリケーション内のサービス間通信は暗号化されません。 ただし、他の Azure PaaS サービスとの通信とサービス ランタイムは TLS 経由で発生します。

Azure Spring Apps を介してエンド ツー エンドの TLS 通信を実装することを選択できます。 トレードオフについて考慮してください。 待機時間と操作に悪影響を及ぼす可能性があります。

転送中のデータに脆弱性がないか検査する必要があります。 Web Application Firewall は Application Gateway と統合され、OWASP の脆弱性をブロックするトラフィックをさらに検査します。 脅威アラートを検出、監視、ログするように Web Application Firewall を構成できます。 または、ルールによって検出された侵入と攻撃をブロックするようにこのサービスを設定することもできます。

DDoS 保護

分散型サービス拒否 (DDoS) は、要求に過剰な負荷をかけることでシステムを停止できます。 このような攻撃から防御するために、基本的な DDoS 保護がすべての Azure サービスに対してインフラストラクチャ レベルで有効になっています。 アプリケーションの監視、アラート、しきい値設定機能などの機能を利用するために、Azure DDoS Protection サービスへのアップグレードを検討してください。 詳細については、「Azure DDoS Protection のよくあるご質問」をご覧ください。

シークレットの管理

Microsoft のゼロ トラスト セキュリティ手法では、シークレット、証明書、および資格情報をセキュリティで保護されたコンテナーに格納する必要があります。 推奨されるサービスは Azure Key Vault です。

Azure サービスと意図に応じて、シークレットを保存する方法は他にもあります。 このアーキテクチャでは、次のアプローチを実装します。

• 証明書はデプロイ中に読み込まれます。
• MySQL への接続は、サービス コネクタを使用して実装されます。

コスト最適化の戦略

分散システムの設計の性質上、インフラストラクチャが増加するのが現実です。 この現実により、コストが予想外で制御できないものになります。 Azure Spring Apps は、需要を満たし、コストを最適化するためにスケーリングするコンポーネントを使用して構築されています。 このアーキテクチャの基盤となるのが、Azure Kubernetes Service (AKS) です。 このサービスは、Kubernetes の管理に伴う複雑さと運用上のオーバーヘッドを軽減するように設計され、クラスターの運用コストの効率化も含まれています。

Azure Spring Apps の単一のインスタンスに、さまざまなアプリケーションとアプリケーションの種類をデプロイできます。 サービスでは、メトリックまたはスケジュールによってトリガーされるアプリケーションの自動スケールがサポートされており、使用率とコスト効率を向上させることができます。

Application Insights と Azure Monitor を使用して、運用コストを削減することもできます。 包括的なログ ソリューションによって提供される可視性により、システムのコンポーネントをリアルタイムにスケーリングするための自動化を実装できます。 また、ログ データを分析し、システムの全体的なコストとパフォーマンスを向上させるために対処できるアプリケーション コードの非効率性を明らかにすることもできます。

シナリオのデプロイ

この参照アーキテクチャのデプロイは、GitHub の「Azure Spring Apps ランディング ゾーン アクセラレータ」で入手できます。 このデプロイには、Terraform テンプレートが使用されています。

このリポジトリ内の成果物により、ご利用の環境に合わせてカスタマイズできる基礎が提供されます。 この実装では、わかりやすくするために、Azure Firewall などの共有リソースを使用してハブ ネットワークを作成します。 このグループ化は、ワークロードとプラットフォームの機能を分離するために、個別のランディング ゾーン サブスクリプションにマップできます。

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

Enterprise レベルでの VMware のサポート

ライブ デプロイに対してマネージド VMware Tanzu® のサポートを利用する場合は、Azure Spring Apps Enterprise レベルを検討できます。 VMware Tanzu® Service Registry は Azure Spring Apps 用に統合されており、これによりサービスの検出と登録が可能になります。

ゲートウェイ ルーティングの場合、VMware Spring Cloud Gateway に切り替えることができます。 認証および承認、回復性機能、レート制限などを含む機能セットを提供します。

Enterprise レベルの場合、Application Configuration Service for Tanzu® を使用すると、1 つまたは複数の Git リポジトリに定義されたプロパティから設定された Kubernetes ネイティブの ConfigMap リソースを管理できます。

このレベルでサポートされている VMware サービスは、他にもあります。 詳細については、Azure Marketplace の Enterprise レベルに関するページを参照してください。

リファレンス実装では、デプロイ オプションとして Azure Spring Apps Enterprise SKU がサポートされています。 このオプションでは、いくつかのアーキテクチャの変更があります。 Azure Virtual Network 統合とプライベート エンドポイント Azure Database for PostgreSQL Azure Cache for Redis でデプロイされたフレキシブル サーバーのインスタンスを使用します。 サンプル アプリケーションは フィットネス ストア アプリです。

次のステップ

• Azure Spring Apps ランディング ゾーン アクセラレータの設計領域を確認します。

関連リソース

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

• Azure Spring Apps Enterprise
• Azure Application Gateway v2
• Azure Database for MySQL
• Azure Key Vault
• Azure Virtual Network
• ルート テーブル

その他の実装シナリオについては、次の記事を参照してください。

• Azure Spring Apps を複数のリージョンにデプロイする
• リバース プロキシ経由で Azure Spring Apps を公開する