英語で読む

次の方法で共有

Azure Spring Apps を Azure Kubernetes Service に移行する

  • [アーティクル]

注意

Basic、Standard、Enterprise プランは、2025 年 3 月中旬以降非推奨になり、廃止期間は 3 年間です。 Azure Container Apps に移行することをお勧めします。 詳細については、「Azure Spring Apps の廃止のお知らせ」を参照してください。

Standard 従量課金と専用プランは、2024 年 9 月 30 日以降に非推奨になり、6 か月後に完全にシャットダウンされます。 Azure Container Apps に移行することをお勧めします。 詳細については、「Azure Spring Apps の Standard 従量課金および専用プランを Azure Container Apps に移行する」を参照してください。

この記事の適用対象:✅ Basic/Standard ✅ Enterprise

この記事では、Azure Spring Apps から Azure Kubernetes Service (AKS) への移行の概要について説明します。

Azure Spring Apps は、Spring Boot アプリケーション専用に設計されたサービスとしてのプラットフォーム (PaaS) ソリューションです。 これにより、これらのアプリケーションのデプロイ、実行、管理が容易になります。 Azure Spring Apps はインフラストラクチャ、スケーリング、監視に対処するため、開発者はコードの開発に集中できます。

AKS は、フル マネージド Kubernetes 環境を提供するサービスとしてのインフラストラクチャ (IaaS) オファリングです。 AKS を使用すると、アプリケーションのデプロイと管理方法をより詳細に制御できます。 コンテナー化されたアプリケーションを幅広くサポートし、特定のニーズを満たすためにカスタマイズを可能にします。

Azure Spring Apps から AKS にアプリケーションを移行すると、マネージド環境からより柔軟性のある環境に移行することになります。 このプロセスでは、Azure Spring Apps を使用して実現していたのと同じ結果を AKS で達成するためには、新しいツールとプラクティスを採用する必要があります。

概念マッピング

Azure Spring Apps と AKS は異なる種類のクラウド サービス オファリングであるため、Azure Spring Apps の概念を AKS に直接マッピングしても完全には対応しません。 また、Azure Spring Apps は、運用環境で使用されるときに多くの内部コンポーネントに依存しますが、それらはここには記載されていません。 次の図と表は、基本を理解するのに役立つ、Azure Spring Apps から AKS への概念の単純なマッピングを示しています。 実際の運用環境では、より安全で信頼性の高いソリューションを検討する必要があります。

Azure Spring Apps と Azure Kubernetes Service の概念マッピングの図。

Azure Spring Apps サービス Azure Kubernetes Service
"サービス インスタンス" はアプリとその他のリソースの境界をホストしてセキュリティで保護し、カスタム仮想ネットワークをサポートします。 "クラスター" はデプロイの基本の単位です。 クラスター内では、"名前空間" はリソースを整理および分離するために使用される仮想サブ区分です。 クラスターの仮想ネットワークが定義する基本となる同じネットワーク インフラストラクチャを共有します。 専用クラスター、または名前空間を持つ共有クラスターのどちらを選択するかは、ビジネス ニーズによって異なります。
"アプリ" は、サービス インスタンス内の子リソースとして機能する 1 つのビジネス アプリです。 "アプリ" は Azure Spring Apps の仮想概念であり、AKS 内の複数のリソースで構成されます。 "イングレス" はサービスへの外部アクセスを制御し、トラフィックをさまざまなサービスにルーティングするための規則を設定します。 "サービス" は、ポッドのセットへのアクセスを抽象化します。 ラベルを使用して、別のバージョンのデプロイを指すようにサービスを更新することで、ブルーグリーン デプロイの切り替えを実行できます。
"デプロイ" はアプリのバージョンです。 アプリには、1 つの運用デプロイと 1 つのステージング デプロイを含めることができます。 "デプロイ" は、特定のアプリケーションまたはサービスのロールアウトとライフサイクルを管理します。 また、ローリング更新とロールバックも可能にし、これにより、ダウンタイムなしで制御されたシームレスなアプリケーション変更が可能になります。
"アプリケーション インスタンス" は、サービスによって管理される最小ランタイム単位です。 "ポッド" は、1 つ以上の密に結合されたコンテナーを表し、実行中のアプリケーションまたはワークロードの 1 つのインスタンスをホストします。

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

AKS クラスターをプロビジョニングする前に、ネットワーク設定を慎重に検討することが重要です。 これらの決定は、アプリケーションのパフォーマンス、スケーラビリティ、セキュリティに大きく影響する可能性があります。

AKS は、コンテナー ネットワーク インターフェイス (CNI) プラグインを使用して、クラスター内のネットワークを管理します。 これらのプラグインは、ポッドへの IP アドレスの割り当て、それらの間のトラフィックのルーティング、Kubernetes サービスを介した通信の有効化などの重要なタスクを処理します。 AKS では、さまざまなネットワーク ニーズに合わせて調整された複数の CNI プラグインがサポートされており、クラスター設計に柔軟性が提供されます。

AKS では、オーバーレイ ネットワークとフラット ネットワークという 2 つの主要なネットワーク モデルが提供されます。 オーバーレイ ネットワークは、AKS ノードの Azure Virtual Network サブネットとは別に、ポッドにプライベート IP アドレスを割り当てます。 このモデルはスケーラブルであり、仮想ネットワーク IP アドレスが節約されますが、クラスターから発信されるトラフィックにはネットワーク アドレス変換 (NAT) を使用します。 これに対し、フラット ネットワークでは、ノードと同じ Azure Virtual Network サブネットからポッド IP アドレスが直接割り当てられるため、外部サービスは NAT なしでポッドにアクセスできます。 フラット ネットワークではポッドとの直接通信が可能ですが、より広範な仮想ネットワーク IP アドレス空間が必要です。

AKS の円滑な運用には、適切な IP 計画が不可欠です。 サブネットがすべてのリソースに十分な IP アドレスを持つ状態を保ち、範囲の重複を回避し、接続の問題や中断を防ぐために将来の拡大に備えた余裕を残すことが重要です。 詳細については、Azure Kubernetes Service CNI ネットワークの概要に関する記事を参照してください。

AKS で受信トラフィックを処理するには、ロード バランサーまたはイングレス コントローラーを使用できます。 ロード バランサーはレイヤー 4 で動作し、プロトコルとポートに基づいてトラフィックを分散します。これに対し、イングレス コントローラーはレイヤー 7 で動作し、URL ベースのルーティングや TLS/SSL 終端などの高度な機能を提供します。 イングレス コントローラーは、1 つの IP を介して複数のアプリケーションへのトラフィックを管理することで、複数のパブリック IP の必要性を減らします。 Web アプリケーションの場合、イングレス コントローラーは、より優れたトラフィック管理と Kubernetes リソースとの統合を提供するため、優先的に選ばれます。 詳細については、「アプリケーション ルーティング アドオンでのマネージド NGINX イングレス」をご覧ください。

AKS でネットワーク トラフィックをセキュリティで保護するには、Azure Application Gateway などの Web アプリケーション ファイアウォール (WAF) を使用して、トラフィック ルーティングと TLS/SSL 終端を管理しながら、クロスサイト スクリプティングや Cookie ポイズニングなどの攻撃から保護します。 さらに、ラベル、名前空間、またはポートに基づいて YAML マニフェストでルールを定義することで、ポッド間通信を制御するネットワーク ポリシーを実装します。 これらのポリシーは Linux ベースのノードでのみ使用でき、クラスター内のトラフィック制御とセキュリティが向上します。 詳細については、AKS のネットワーク ポリシーを使用したポッド間のトラフィックの保護に関する記事を参照してください。

プロビジョニング

AKS クラスターをプロビジョニングするには、Azure portal、Azure CLI、または ARM テンプレートを使用できます。 通常、このプロセスには、目的のリージョンの選択、ノード プールのサイズと種類の定義、ネットワーク モデル (Azure CNI または Kubenet) の選択が含まれます。 また、ユーザー アクセス制御用の Microsoft Entra ID 統合などの認証オプションも構成する必要があります。 監視とスケーリングのために、Azure Monitor を有効にでき、リソースの使用状況に基づいて自動スケールを構成できます。 プロビジョニング後、kubectl または Azure CLI を使用してクラスターを管理できます。 AKS のプロビジョニングの詳細な手順については、「AKS クラスターを作成する」を参照してください。

アクセスと ID

AKS には、Kubernetes クラスターの認証、承認、アクセス制御を管理するいくつかの方法が用意されています。 Kubernetes のロールベースのアクセス制御 (RBAC) を使用して、ユーザー、グループ、サービス アカウントに対し、必要とするリソースへのアクセス権のみを付与できます。 詳細については、RBAC 承認の使用に関するページを参照してください。 AKS では、セキュリティと制御を強化するために Microsoft Entra ID と Azure RBAC もサポートされており、より合理化された方法でアクセス許可を割り当てて管理できます。

セキュリティを最大限に確保するために、AKS と Microsoft Entra ID を統合することをお勧めします。 この統合では、認証に OpenID Connect プロトコルと OAuth 2.0 プロトコルが使用されます。 ユーザーは、Microsoft Entra 資格情報を使用して AKS クラスターと対話するときに、クラスター管理者が管理する自分のアクセス許可によって自身を認証のために証明します。 詳細については、「kubelogin を使用して Kubernetes クラスターに対する Azure マネージド ID の認証を有効にする」を参照してください。

Kubernetes のネイティブ機能は、Microsoft Entra ワークロード ID によって OpenID Connect (OIDC) フェデレーションを介して外部 ID プロバイダーと統合されます。 サービス アカウント トークンのボリューム予測を使用して、注釈付きサービス アカウントを介して Kubernetes ID をポッドに割り当てます。 これらのトークンを使用すると、Kubernetes アプリケーションは、Microsoft Entra ID を使用して Azure リソースを安全に認証し、これらにアクセスできます。 このセットアップは、Azure Identity クライアント ライブラリ (Azure.Identity) や Microsoft Authentication Library (MSAL) などのライブラリとシームレスに連携して、ワークロードの認証を効率化します。 クラスターを設定し、ワークロードを識別してアプリケーション ポッドを構成する方法については、ワークロード ID のデプロイと構成に関する記事を参照してください。

アプリケーションをコンテナー化する

アプリケーションをコンテナー イメージにコンテナー化することは、AKS へのデプロイに不可欠です。 これにより、デプロイの一貫性、移植性、拡張性が確保されます。 コンテナー イメージを使用すると、さまざまなバージョンのアプリケーションを柔軟に管理できます。 1 つのホストで複数のコンテナーを実行できるようにすることで、更新とロールバックが容易になり、リソースの効率が向上します。

Azure Spring Apps は、ユーザーがコンテナー イメージを作成し、さまざまな方法でアプリケーションをデプロイするのに役立ちます。 デプロイは、ソース コードから、JAR ファイルまたは WAR ファイルなどのビルドされた成果物から、またはコンテナー イメージから直接実行できます。 JAR ファイルまたは WAR ファイルからデプロイする方法については、「JAR または WAR からコンテナー イメージをビルドする」を参照してください。 ソース コードからデプロイする方法については、Paketo Buildpacks を使用したアプリケーションのコンテナー化に関する記事を参照してください。

AKS にデプロイされたアプリケーションのパフォーマンスを監視するには、コンテナー化プロセス中に、アプリケーション パフォーマンス監視 (APM) エージェントを統合できます。 詳細については、「アプリケーション パフォーマンス監視をコンテナー イメージに統合する」を参照してください。

アプリケーションと Spring Cloud コンポーネントをデプロイする

AKS にアプリケーションをデプロイするには、アプリケーションのニーズに応じて、Azure Spring Apps で使用される Deployment または StatefulSets を使用できます。 マイクロサービスなどのステートレス アプリケーションの場合は、通常 Deployment を使用します。これにより、アプリケーションのレプリカが管理され、それらが確実にスムーズに実行されるようになります。 この種類は、Azure Spring Apps によって使用されます。 一方、StatefulSets は、永続的なストレージまたは安定した ID を必要とするアプリケーション (データベースやステートフルなニーズを持つサービスなど) に最適です。

アプリケーションのデプロイと共に、バックエンド ポッドを公開するため、Service を定義する必要もあります。 Service は、ポッドの論理セットを定義し、それらに対するネットワーク アクセスを可能にする抽象化です。 この機能は、ポッド間の負荷分散と通信に不可欠です。

Spring Cloud Config や Spring Cloud Gateway などの Spring Cloud コンポーネントをデプロイするときは、通常、ステートレス サービスに Deployment を使用します。 安定したストレージまたは状態を必要とするバックエンド サービスの場合は、StatefulSets を選択できます。

次のリンクは、Spring Cloud コンポーネントのコンテナー イメージとマニフェスト ファイルの参照例を示しています。

モニター

監視は、AKS にデプロイされたアプリケーションを管理する上で重要な部分です。 AKS には、Azure Monitor、Azure Log Analytics、Prometheus などの統合ソリューションなど、クラスターとワークロードの状態を追跡および分析するためのさまざまなツールが用意されています。 詳細については、次の記事をご覧ください。

Azure Monitor と Prometheus に加えて、Datadog、New Relic、Elastic Stack (ELK) などの他の監視ソリューションを使用することもできます。 これらのツールを AKS に統合してログ、メトリック、トレースを収集し、クラスターのパフォーマンスに関するさまざまな分析情報を提供できます。

チュートリアル

AKS のチュートリアルとして、AKS で ACME Fitness ストア アプリケーションを実行するエンド ツー エンドのエクスペリエンスのデモを提供しています。 詳細については、「acme-fitness-store/azure-kubernetes-service」を参照してください。 このチュートリアルは、実用的なガイダンスを提供するもので、参考用に作成されています。 AKS は柔軟性が高いため、構成とカスタマイズの選択は、ユーザー独自の要件に基づいて行う必要があります。