Share via

Azure Spring Apps の参照アーキテクチャ

  • [アーティクル]

注意

Azure Spring Apps は、Azure Spring Cloud サービスの新しい名前です。 サービスの名前は新しくなりましたが、スクリーンショット、ビデオ、図などの資産の更新に取り組んでいる間、場所によってはしばらく古い名前が表示されます。

この記事の適用対象: ✔️ Standard ✔️ Enterprise

この参照アーキテクチャは、Azure Spring Apps を使用するための一般的なエンタープライズ ハブとスポーク設計を使用した基盤です。 この設計では、Azure Spring Apps はハブでホストされている共有サービスに依存する単一のスポークにデプロイされます。 アーキテクチャは、「Microsoft Azure Well-Architected Framework」の原則を達成するためのコンポーネントで構築されています。

Azure Spring Apps には、Standard プランと Enterprise プランの 2 種類があります。

Azure Spring Apps Standard プランは、Spring Cloud Config Server、Spring Cloud Service Registry、kpack ビルド サービスで構成されます。

Azure Spring Apps Enterprise プランは、VMware Tanzu® Build Service、Application Configuration Service™ for VMware Tanzu®、VMware Tanzu® Service Registry、Spring Cloud Gateway for VMware Tanzu®、および VMware Tanzu® 用 API ポータルで構成されています。

このアーキテクチャの実装については、GitHub の Azure Spring Apps リファレンス アーキテクチャ に関するページを参照してください。

このアーキテクチャのデプロイ オプションには、Azure Resource Manager (ARM)、Terraform、Azure CLI、および Bicep が含まれます。 このリポジトリ内の成果物により、ご利用の環境に合わせてカスタマイズできる基礎が提供されます。 Azure Firewall や Application Gateway などのリソースを別のリソース グループまたはサブスクリプションにグループ化することができます。 このグループ化は、IT インフラストラクチャ、セキュリティ、ビジネス アプリケーション チームなどのさまざまな機能を別々に保つのに役立ちます。

アドレス空間の計画

Azure Spring Apps には、次の 2 つの専用サブネットが必要です。

  • サービス ランタイム
  • Spring Boot アプリケーション

これらのサブネットにはそれぞれ専用の Azure Spring Apps クラスターが必要です。 複数のクラスターで同じサブネットを共有することはできません。 各サブネットの最小サイズは /28 です。 Azure Spring Apps でサポートできるアプリケーション インスタンスの数は、サブネットのサイズによって異なります。 詳細な仮想ネットワークの要件については、「仮想ネットワークに Azure Spring Apps をデプロイする」の「仮想ネットワークの要件」セクションを参照してください。

警告

選択するサブネットのサイズは、既存の仮想ネットワーク アドレス空間と重複できません。また、ピアリングされた、あるいはオンプレミスのサブネット アドレス範囲と重複することもできません。

ユース ケース

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

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

これらのユース ケースは、そのセキュリティとネットワーク トラフィック規則以外は似ています。 このアーキテクチャは、それぞれの微妙な差異をサポートするように設計されています。

プライベート アプリケーション

次の一覧では、プライベート アプリケーションのインフラストラクチャ要件について説明します。 これらの要件は、厳しく規制された環境では一般的です。

  • サブネットには、Azure Spring Apps のインスタンスが 1 つだけ必要です。
  • 少なくとも 1 つのセキュリティ ベンチマークへの準拠を強制する必要があります。
  • アプリケーション ホストのドメイン ネームサービス (DNS) レコードは、Azure プライベート DNS に格納する必要があります。
  • Azure サービスの依存関係では、サービス エンドポイントまたはプライベート リンクを介して通信する必要があります。
  • 保存データは暗号化する必要があります。
  • 転送中のデータは暗号化する必要があります。
  • DevOps デプロイ パイプラインを使用することができ (Azure DevOps など)、Azure Spring Apps へのネットワーク接続が必要です。
  • エグレス トラフィックは、中央のネットワーク仮想アプライアンス (NVA) (Azure Firewall など) を経由する必要があります。
  • Azure Spring Apps Config Server を使用してリポジトリから構成プロパティを読み込む場合は、リポジトリがプライベートである必要があります。
  • Microsoft のゼロ トラスト セキュリティ手法では、シークレット、証明書、および資格情報をセキュリティで保護されたコンテナーに格納する必要があります。 推奨されるサービスは Azure Key Vault です。
  • オンプレミスおよびクラウド内のホストの名前解決は、双方向である必要があります。
  • コントロール プレーンのトラフィックを除き、パブリック インターネットへの直接のエグレスはありません。
  • Azure Spring Apps デプロイで管理されているリソース グループは変更できません。
  • Azure Spring Apps デプロイで管理されているサブネットは変更できません。

次の一覧には、設計を構成するコンポーネントが示されています。

  • オンプレミス ネットワーク
    • ドメイン ネーム サービス (DNS)
    • Gateway
  • ハブ サブスクリプション
    • Application Gateway サブネット
    • Azure Firewall サブネット
    • 共有サービス サブネット
  • 接続されているサブスクリプション
    • Azure Bastion サブネット
    • 仮想ネットワーク ピア

次の一覧では、この参照アーキテクチャでの Azure サービスについて説明します。

  • Azure Key Vault: Microsoft の ID サービスとコンピューティング リソースに緊密に統合されている、ハードウェアを基盤にした資格情報管理サービス。

  • Azure Monitor: Azure とオンプレミスの両方にデプロイするアプリケーション向けの包括的な監視サービス スイート。

  • Azure Pipelines: 更新された Spring Boot アプリを Azure Spring Apps に自動的にデプロイできる、完全な機能を備えた継続的インテグレーションまたは継続的開発 (CI/CD) サービス。

  • Microsoft Defender for Cloud: オンプレミス、複数のクラウド、および Azure にわたるワークロードのために統合されたセキュリティ管理および脅威防止システム。

  • Azure Spring Apps: Java ベースの Spring Boot アプリケーションと .NET ベースの Steeltoe アプリケーションに特化して設計および最適化された管理サービス。

次の図には、上記の要件に対応する、適切に設計されたハブとスポークの設計が示されています。

パブリック アプリケーション

次の一覧では、パブリック アプリケーションのインフラストラクチャ要件について説明します。 これらの要件は、厳しく規制された環境では一般的です。

  • サブネットには、Azure Spring Apps のインスタンスが 1 つだけ必要です。
  • 少なくとも 1 つのセキュリティ ベンチマークへの準拠を強制する必要があります。
  • アプリケーション ホストのドメイン ネームサービス (DNS) レコードは、Azure プライベート DNS に格納する必要があります。
  • Azure DDoS Protection を有効にする必要があります。
  • Azure サービスの依存関係では、サービス エンドポイントまたはプライベート リンクを介して通信する必要があります。
  • 保存データは暗号化する必要があります。
  • 転送中のデータは暗号化する必要があります。
  • DevOps デプロイ パイプラインを使用することができ (Azure DevOps など)、Azure Spring Apps へのネットワーク接続が必要です。
  • エグレス トラフィックは、中央のネットワーク仮想アプライアンス (NVA) (Azure Firewall など) を経由する必要があります。
  • イングレス トラフィックは、少なくとも Application Gateway または Azure Front Door で管理する必要があります。
  • インターネット ルーティング可能なアドレスは、Azure パブリック DNS に格納する必要があります。
  • Microsoft のゼロ トラスト セキュリティ手法では、シークレット、証明書、および資格情報をセキュリティで保護されたコンテナーに格納する必要があります。 推奨されるサービスは Azure Key Vault です。
  • オンプレミスおよびクラウド内のホストの名前解決は、双方向である必要があります。
  • コントロール プレーンのトラフィックを除き、パブリック インターネットへの直接のエグレスはありません。
  • Azure Spring Apps デプロイで管理されているリソース グループは変更できません。
  • Azure Spring Apps デプロイで管理されているサブネットは変更できません。

次の一覧には、設計を構成するコンポーネントが示されています。

  • オンプレミス ネットワーク
    • ドメイン ネーム サービス (DNS)
    • Gateway
  • ハブ サブスクリプション
    • Application Gateway サブネット
    • Azure Firewall サブネット
    • 共有サービス サブネット
  • 接続されているサブスクリプション
    • Azure Bastion サブネット
    • 仮想ネットワーク ピア

次の一覧では、この参照アーキテクチャでの Azure サービスについて説明します。

  • Azure アプリケーション ファイアウォール: 一般的な脆弱性やその悪用からアプリケーションを一元的に保護する Azure Application Gateway の機能。

  • Azure Application Gateway: レイヤー 7 でトランスポート層セキュリティ (TLS) のオフロード操作を行うアプリケーション トラフィックを担当するロード バランサー。

  • Azure Key Vault: Microsoft の ID サービスとコンピューティング リソースに緊密に統合されている、ハードウェアを基盤にした資格情報管理サービス。

  • Azure Monitor: Azure とオンプレミスの両方にデプロイするアプリケーション向けの包括的な監視サービス スイート。

  • Azure Pipelines: 更新された Spring Boot アプリを Azure Spring Apps に自動的にデプロイできる、完全な機能を備えた継続的インテグレーションまたは継続的開発 (CI/CD) サービス。

  • Microsoft Defender for Cloud: オンプレミス、複数のクラウド、および Azure にわたるワークロードのために統合されたセキュリティ管理および脅威防止システム。

  • Azure Spring Apps: Java ベースの Spring Boot アプリケーションと .NET ベースの Steeltoe アプリケーションに特化して設計および最適化された管理サービス。

次の図には、上記の要件に対応する、適切に設計されたハブとスポークの設計が示されています。 インターネットと通信するのはハブ仮想ネットワークだけです。

Azure Spring Apps のオンプレミス接続

Azure Spring Apps 内のアプリケーションは、さまざまな Azure リソース、オンプレミスのリソース、および外部リソースと通信できます。 ハブとスポークの設計を使用することにより、アプリケーションでは、Express Route またはサイト間仮想プライベート ネットワーク (VPN) を使用して外部またはオンプレミスのネットワークにトラフィックをルーティングできます。

Azure Well-Architected Framework に関する考慮事項

Azure Well-Architected Framework は、強力なインフラストラクチャ基盤を確立する際に従う一連の基本原則です。 このフレームワークには、コストの最適化、オペレーショナル エクセレンス、パフォーマンス効率、信頼性、およびセキュリティというカテゴリが含まれています。

コストの最適化

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

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

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

オペレーショナル エクセレンス

Azure Spring Apps は、オペレーショナル エクセレンスの複数の側面に対応しています。 次の一覧に示すように、これらの側面を組み合わせ、確実に運用環境でサービスが効率的に実行されるようにすることができます。

  • Azure Pipelines を使用すると、人為的なエラーを回避するのに役立つと同時に、デプロイの信頼性と整合性を確保することができます。
  • Azure Monitor と Application Insights を使用して、ログと利用統計情報を格納できます。 収集されたログとメトリック データを評価して、ご利用のアプリケーションの正常性とパフォーマンスを確かめることができます。 アプリケーション パフォーマンス監視 (APM) は、Java エージェントを使用してサービスに完全に統合されます。 このエージェントで、追加のコードを必要とせずに、デプロイされたすべてのアプリケーションと依存関係を可視化できます。 詳細については、ブログ記事の「Azure Spring Apps でアプリケーションと依存関係を簡単に監視する」を参照してください。
  • Microsoft Defender for Cloud を使用すると、指定されたデータを分析および評価するためのプラットフォームを提供することによって、アプリケーションで確実にセキュリティを維持することができます。
  • サービスでさまざまなデプロイ パターンがサポートされます。 詳細については、「Azure Spring Apps でステージング環境を設定する」を参照してください。

[信頼性]

Azure Spring Apps は AKS に基づいて構築されています。 AKS ではクラスタリングによって高いレベルの回復性が提供されますが、この参照アーキテクチャには、さらに、コンポーネントで障害が発生した場合にアプリケーションの可用性を向上させるためのサービスとアーキテクチャの考慮事項が組み込まれています。

適切に定義されたハブとスポークの設計の上に構築することで、このアーキテクチャの基盤により、確実に複数のリージョンにデプロイできるようになります。 プライベート アプリケーションのユース ケースでは、このアーキテクチャで Azure プライベート DNS を使用して、地理的な障害時に継続的に可用性を確保します。 パブリック アプリケーションのユース ケースでは、Azure Front Door と Azure Application Gateway によって可用性が確保されます。

セキュリティ

このアーキテクチャのセキュリティは、業界定義のコントロールとベンチマークに準拠することによって対処されます。 このコンテキストでの "コントロール" とは、"情報システムへのアクセスを実装する際に最小限の特権の原則を採用する (IAM-05)" など、簡潔で明確に定義されたベスト プラクティスを意味します。 このアーキテクチャのコントロールは、クラウド セキュリティ アライアンス (CSA) による Cloud Control Matrix (CCM) と、Center for Internet Security (CIS) による Microsoft Azure Foundations Benchmark (MAFB) からのものです。 適用されたコントロールでは、ガバナンス、ネットワーク、およびアプリケーション セキュリティの主要なセキュリティ設計原則に焦点を当てています。 ターゲット インフラストラクチャに関連する ID、アクセス管理、およびストレージの設計原則を扱うことはお客様の責任となります。

ガバナンス

このアーキテクチャで対処するガバナンスの主な側面は、ネットワーク リソースの分離による隔離です。 CCM の DCS-08 では、データセンターのイングレスおよびエグレス コントロールが推奨されます。 このコントロールを満たすために、アーキテクチャでは、ネットワーク セキュリティ グループ (NSG) を使用したハブとスポークの設計を使って、リソース間の east-west トラフィックをフィルター処理します。 また、このアーキテクチャでは、ハブの中央サービスとスポークのリソースとの間のトラフィックもフィルター処理します。 このアーキテクチャでは、Azure Firewall のインスタンスを使用して、インターネットと、アーキテクチャ内のリソースとの間のトラフィックを管理します。

次の一覧には、この参照でのデータセンターのセキュリティに対処するコントロールが示されています。

CSA CCM コントロール ID CSA CCM コントロール ドメイン
DCS-08 データセンター セキュリティの承認されていない人物エントリ

ネットワーク

このアーキテクチャをサポートするネットワーク設計は、従来のハブ アンド スポーク モデルから派生したものです。 この決定により、ネットワーク分離が基本コンストラクトになります。 CCM コントロール IVS-06 では、信頼されている環境と信頼されていない環境の間で、ネットワークと仮想マシン間のトラフィックを制限し、監視することが推奨されます。 このアーキテクチャには、("データ センター" 内の) east-west トラフィック用の NSG と、("データ センター" 外の) north-south トラフィック用の Azure Firewall の実装によるコントロールが採用されます。 CCM コントロール IPY-04 では、インフラストラクチャでサービス間のデータ交換にセキュリティで保護されたネットワーク プロトコルを使用する必要があることが推奨されます。 このアーキテクチャをサポートするすべての Azure サービスでは、HTTP や SQL の TLS など、標準的なセキュリティで保護されたプロトコルが使用されます。

次の一覧には、この参照でのネットワーク セキュリティに対処する CCM コントロールが示されています。

CSA CCM コントロール ID CSA CCM コントロール ドメイン
IPY-04 ネットワーク プロトコル
IVS-06 ネットワークのセキュリティ

ネットワークの実装は、MAFB からコントロールを定義することでさらにセキュリティで保護されます。 このコントロールにより、パブリック インターネットから環境へのトラフィックが制限されるようになります。

次の一覧には、この参照でのネットワーク セキュリティに対処する CIS コントロールが示されています。

CIS コントロール ID CIS コントロールの説明
6.2 インターネットからの SSH アクセスが制限されるようにします。
6.3 SQL データベースでイングレス 0.0.0.0/0 (任意の IP) が許可されないようにします。
6.5 Network Watcher が [有効] になっていることを保証します。
6.6 インターネットからの UDP を使用したイングレスが制限されるようにします。

Azure Spring Apps では、セキュリティで保護された環境にデプロイされている場合、Azure から送信される管理トラフィックが必要です。 「VNET での Azure Spring Apps の実行に関するお客様の責任」に一覧表示されているネットワークとアプリケーションの規則を許可する必要があります。

アプリケーションのセキュリティ

この設計原則では、ID、データ保護、キー管理、アプリケーション構成の基本的なコンポーネントについて説明します。 設計上、Azure Spring Apps にデプロイされたアプリケーションは、機能するのに必要な最小限の特権で実行されます。 サービスを使用すると、データ保護に承認コントロールのセットが直接関連付けられます。 キー管理によって、このレイヤード アプリケーションのセキュリティ アプローチが強化されます。

次の一覧には、この参照でのキー管理に対処する CCM コントロールが示されています。

CSA CCM コントロール ID CSA CCM コントロール ドメイン
EKM-01 暗号化とキー管理のエンタイトルメント
EKM-02 暗号化とキー管理のキー生成
EKM-03 暗号化とキー管理の機密データ保護
EKM-04 暗号化とキー管理のストレージとアクセス

CCM の EKM-02 および EKM-03 では、キーを管理し、暗号化プロトコルを使用して機密データを保護するためのポリシーと手順が推奨されています。 EKM-01 では、すべての暗号化キーに識別可能な所有者が存在し、管理できるようにすることが推奨されています。 EKM-04 では、標準アルゴリズムを使用することが推奨されています。

次の一覧には、この参照でのキー管理に対処する CIS コントロールが示されています。

CIS コントロール ID CIS コントロールの説明
8.1 すべてのキーに有効期限が設定されていることを保証します。
8.2 すべてのシークレットに有効期限が設定されていることを確認します。
8.4 キー コンテナーが回復可能であることを確認します。

CIS コントロール 8.1 および 8.2 では、ローテーションが確実に適用されるように、資格情報に有効期限を設定することが推奨されていいます。 CIS コントロール 8.4 により、ビジネス継続性を維持するためにキー コンテナーの内容を復元できることが保証されます。

アプリケーション セキュリティの側面により、この参照アーキテクチャを使用して Azure の Spring ワークロードをサポートするための基盤が設定されます。

次のステップ

Azure Spring Apps の参照アーキテクチャ リポジトリで提供されている ARM、Terraform、Azure CLI のデプロイを通じて、この参照アーキテクチャについて確認します。