Spring Boot アプリケーションを Azure Container Apps に移行する

このガイドでは、既存の Spring Boot アプリケーションを Azure Container Apps に移行するプロセスについて説明します。移行前の評価、移行自体、移行後の最適化について説明します。

前提条件

Azure のサブスクリプション。アカウントがない場合は、無料アカウントを作成してください。
Azure CLI がインストールされているか、 Azure portal にアクセスします。
Spring Boot アプリケーションの開発と Docker コンテナーに関する知識。
サポートされている JDK バージョン (8、11、17、または 21)。詳細については、「Azure Container Apps 上の Java の概要」を参照してください。

移行前の評価

移行を開始する前に、次のセクションで説明する評価とインベントリの手順を完了します。

ローカルの状態を特定する

サービスとしてのプラットフォーム (PaaS) 環境では、アプリケーションは、特定の時点で 1 つのインスタンスとして実行されることを保証しません。 1 つのインスタンスを構成した場合でも、次の場合に重複するインスタンスを作成できます。

障害またはシステムの更新により、システムはアプリケーションを物理ホストに再配置する必要があります。
システムによってアプリケーションが更新されます。

どちらの場合も、元のインスタンスは、新しいインスタンスの開始が完了するまで実行されたままです。この動作は、アプリケーションに次の影響を与えます。

シングルトンが本当にシングルであることを保証することはできません。
外部ストレージに保持されていないデータが失われる可能性があります。

Azure Container Appsに移行する前に、コードに、失われたり重複したりしてはならないローカル状態が含まれていないことを確認します。ローカル状態が存在する場合は、コードをリファクタリングして、その状態を外部に格納します。クラウド対応アプリケーションは、通常、次のいずれかの場所に状態を格納します。

Azure Cache for Redis
Azure Cosmos DB
Azure SQL、Azure Database for MySQL、Azure Database for PostgreSQL などの外部データベース
非構造化データまたはシリアル化されたオブジェクトの Azure Storage

ファイルシステムの使用状況を確認する

サービスがローカルファイルシステムに対して読み取りまたは書き込みを行うインスタンスを特定します。短期または一時的なファイルと、有効期間が長いファイルに注意してください。

Azure Container Appsには、いくつかの種類のストレージが用意されています。エフェメラルストレージを使用すると、実行中のコンテナーまたはレプリカ内の一時データの読み取りと書き込みを行うことができます。 Azure Files を使用すると、複数のコンテナーで共有できる永続的なストレージを提供できます。詳細については、「 Azure Container Appsを参照してください。

アプリケーションが 読み取り専用の静的コンテンツを提供する場合は、それを Azure Blob Storage に移動し、グローバル配布用に Azure CDN を追加することを検討してください。詳細については、「 Azure Storagec1>Quickstart: Azure storage アカウントを Azure CDN と統合する」を参照してください。

アプリケーションが 動的に発行された静的コンテンツ (作成後に変更されないアップロードまたは生成されたコンテンツ) を処理する場合は、Azure Blob Storage と Azure CDN を統合できます。 Azure 関数を使用してアップロードを管理し、CDN の更新をトリガーすることもできます。サンプル実装については、「 Azure Functions を使用した静的コンテンツのアップロードと CDN プリロード」を参照してください。

OS 固有のコードを確認する

アプリケーションにホスト OS に依存するコードが含まれている場合は、それらの依存関係を削除するようにリファクタリングします。たとえば、ファイルシステムパスでの / または \ の使用を、 File.Separator または Paths.getに置き換えます。

プラットフォームの互換性を確認する

Dockerfile を手動で作成し、コンテナー化されたアプリケーションを Azure Container Apps にデプロイする場合は、JRE/JDK バージョンを含むデプロイを完全に制御できます。

成果物からのデプロイのために、Azure Container Apps には、特定のバージョンの Java (8、11、17、21) と、Spring Boot および Spring Cloud コンポーネントの特定のバージョンが用意されています。互換性を確保するには、まず、現在の環境でサポートされているバージョンの Java にアプリケーションを移行してから、残りの移行手順に進みます。 Linux ディストリビューションの最新の安定したリリースで、結果の構成を完全にテストします。

注

この検証は、Oracle JDK や IBM OpenJ9 など、サポートされていない JDK で現在のサーバーが実行されている場合に特に重要です。

現在の Java バージョンを確認するには、運用サーバーにサインインし、次のコマンドを実行します。

java -version

サポートされているバージョンの Java、Spring Boot、Spring Cloud については、 Java on Azure Container Apps の概要を参照してください。

Spring Boot のバージョンを特定する

移行する各アプリケーションの依存関係を調べて、Spring Boot のバージョンを確認します。

Maven プロジェクトで、POM ファイルの <parent> 要素で Spring Boot バージョンを見つけます。

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>3.3.3</version>
    <relativePath/> <!-- lookup parent from repository -->
</parent>

Gradle プロジェクトで、plugins セクションで Spring Boot のバージョンを見つけます。

plugins {
  id 'org.springframework.boot' version '3.3.3'
  id 'io.spring.dependency-management' version '1.1.6'
  id 'java'
}

3.x より前の Spring Boot バージョンを使用するアプリケーションの場合は、 Spring Boot 3.0 移行ガイドに従って、サポートされているバージョンに更新してください。サポートされているバージョンについては、 Spring Boot と Spring Cloud のバージョンを参照してください。

スケジュールされたジョブを識別する

Unix cron ジョブや Spring Batch フレームワークに基づく有効期間の短いアプリケーションなどのエフェメラルアプリケーションは、Azure Container Apps 上でジョブとして実行する必要があります。詳細については、Azure Container Apps におけるジョブをご参照ください。

アプリケーションが実行時間が長く、スケジュールフレームワーク (Quartz や Spring Batch など) を使用して定期的にタスクを実行する場合は、Azure Container Apps でホストできます。ただし、アプリケーションは、スケールアウトまたはローリングアップグレード中にスケジュールされた期間ごとに同じタスクが複数回実行される競合状態を回避するために、スケーリングを適切に処理する必要があります。

アプリケーションコードの内部または外部の運用サーバーで実行されているスケジュールされたタスクのインベントリを取得します。

外部リソースをインベントリする

データソース、JMS メッセージブローカー、その他のサービスの URL などの外部リソースを特定します。 Spring Boot アプリケーションでは、通常、このようなリソースの構成は、通常は application.properties または application.yml と呼ばれるファイル内の src/main/resources フォルダーにあります。

データベース

Spring Boot アプリケーションの場合、接続文字列は通常、外部データベースに依存する場合に構成ファイルに表示されます。 application.properties ファイルの例を次に示します。

spring.datasource.url=jdbc:mysql://localhost:3306/mysql_db
spring.datasource.username=dbuser
spring.datasource.driver-class-name=com.mysql.jdbc.Driver

application.yaml ファイルの例を次に示します。

spring:
  data:
    mongodb:
      uri: mongodb://mongouser:deepsecret@mongoserver.contoso.com:27017

可能な構成シナリオについては、Spring Data のドキュメントを参照してください。

JMS メッセージブローカー

関連する依存関係のビルドマニフェスト (通常は 、pom.xml または build.gradle ファイル) を調べることで、使用中のブローカーを特定します。

たとえば、ActiveMQ を使用する Spring Boot アプリケーションでは、通常、 pom.xml ファイルにこの依存関係が含まれます。

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-activemq</artifactId>
</dependency>

商用ブローカーを使用する Spring Boot アプリケーションには、通常、ブローカーの JMS ドライバーライブラリへの依存関係が直接含まれます。 build.gradle ファイルの例を次に示します。

    dependencies {
      ...
      compile("com.ibm.mq:com.ibm.mq.allclient:9.4.0.5")
      ...
    }

使用中のブローカーを特定したら、対応する設定を見つけます。通常、アプリケーションディレクトリ内の application.properties ファイルと application.yml ファイルで見つかります。

注

Microsoft では、使用可能な最も安全な認証フローを使用することをお勧めします。この手順で説明する認証フロー (データベース、キャッシュ、メッセージング、AI サービスなど) には、アプリケーションに対する高度な信頼が必要であり、他のフローには存在しないリスクが伴います。このフローは、パスワードレス接続やキーレス接続のマネージド ID など、より安全なオプションが実行できない場合にのみ使用します。ローカルコンピューターの操作では、パスワードレス接続またはキーレス接続にユーザー ID を使用します。

application.properties ファイルの ActiveMQ の例を次に示します。

spring.activemq.brokerurl=broker:(tcp://localhost:61616,network:static:tcp://remotehost:61616)?persistent=false&useJmx=true
spring.activemq.user=admin
spring.activemq.password=<password>

ActiveMQ 構成の詳細については、 Spring Boot メッセージングのドキュメントを参照してください。

application.yaml ファイルの IBM MQ の例を次に示します。

ibm:
  mq:
    queueManager: qm1
    channel: dev.ORDERS
    connName: localhost(14)
    user: admin
    password: <password>

IBM MQ 構成の詳細については、 IBM MQ Spring コンポーネントのドキュメントを参照してください。

外部キャッシュ

使用中の外部キャッシュを特定します。多くの場合、Spring Data Redis 経由で Redis を使用します。構成情報については、 Spring Data Redis のドキュメントを参照してください。

(Java または XML で) それぞれの構成を検索して、Spring Session 経由でセッションデータをキャッシュするかどうかを決定します。

ID プロバイダー

アプリケーションが使用する ID プロバイダーを特定します。 ID プロバイダーを構成する方法については、次のリソースを参照してください。

OAuth2 の構成については、 Spring Security リファレンスを参照してください。
Auth0 Spring Security の構成については、 Auth0 Spring Security のドキュメントを参照してください。
PingFederate Spring Security の構成については、 Auth0 PingFederate の手順を参照してください。

非標準ポート

Azure Container Apps を使用すると、コンテナーアプリのリソース構成に基づいてポートを公開できます。 Spring Boot アプリケーションは既定でポート 8080 でリッスンしますが、 server.port または SERVER_PORT 環境変数を使用してこのポートを変更できます。

その他のすべての外部リソース

このガイドでは、可能なすべての外部依存関係を文書化することはできません。移行後、アプリケーションのすべての外部依存関係を満たすことができることを確認します。

インベントリの構成、シークレット、証明書

パスワードとセキュリティで保護された文字列

運用環境のデプロイ内のすべてのプロパティ、構成ファイル、環境変数で、シークレット文字列とパスワードを確認します。 Spring Boot アプリケーションでは、通常、 application.properties または application.yml ファイルにこれらの文字列があります。

証明書

パブリック SSL エンドポイント、またはバックエンドデータベースやその他のシステムとの通信に使用されるすべての証明書を文書化します。次のコマンドを実行すると、運用サーバー上のすべての証明書を表示できます。

keytool -list -v -keystore <path to keystore>

ログ記録と APM の評価

移行するアプリケーションで使用するログ集計ソリューションを特定します。ログに記録されたイベントを使用できるようにするには、移行中に診断設定を構成する必要があります。詳細については、「ログ記録と診断の構成」セクションを参照してください。

アプリケーションで使用するアプリケーションパフォーマンス管理 (APM) エージェントを特定します。 Azure Container Apps では、組み込みの APM サポートは提供されていません。コンテナーイメージを準備するか、APM ツールをコードに直接統合する必要があります。アプリケーションのパフォーマンスを測定したいが、まだ APM を統合していない場合は、Azure Application Insights の使用を検討してください。詳細については、「アプリケーションパフォーマンス監視の統合」セクションを参照してください。

ドキュメント展開アーキテクチャ

Spring Boot アプリケーションの次の情報を文書化します。

実行中のインスタンスの数。
各インスタンスに割り当てられた CPU の数。
各インスタンスに割り当てられた RAM の量。

また、複数のリージョンまたはデータセンター間でアプリケーションインスタンスを現在配布しているかどうかを判断します。移行するアプリケーションのアップタイム要件と SLA を文書化します。

移行

Container Apps 環境を作成する

Azure サブスクリプションに Container Apps 環境を作成します。詳細については、「Quickstart: Azure ポータルを使用して最初のコンテナーアプリをデプロイするを参照してください。

ログ記録と診断を構成する

ログ記録を構成して、すべての出力をファイルではなくコンソールにルーティングします。

アプリケーションを Azure Container Apps にデプロイした後、Container Apps 環境内でログオプションを構成して、1 つ以上のログ宛先を定義できます。これらの宛先には、Azure Monitor Log Analytics、Azure Event Hubs、または Microsoft 以外の監視ソリューションを含めることができます。また、ログデータストレージを無効にして、実行時にのみログを表示することもできます。構成手順については、 Azure Container Apps のログストレージと監視オプションに関するページを参照してください。

永続ストレージを構成する

アプリケーションの一部がローカルファイルシステムに対して読み取りまたは書き込みを行う場合は、永続的ストレージを構成して置き換えます。アプリ設定を使用してコンテナーにマウントするパスを指定し、アプリケーションが使用するパスに合わせます。詳細については、「 Azure Container Appsを参照してください。

証明書を Azure Key Vault に移行する

Azure Container Apps では、アプリ間のセキュリティで保護された通信がサポートされています。安全な通信を確立するプロセスをアプリケーションで管理する必要はありません。プライベート証明書を Azure Container Apps にアップロードすることも、無料のマネージド証明書を使用することもできます。 Azure Key Vault を使用して証明書を管理することをお勧めします。詳細については、Azure Container Apps の証明書を参照してください。

アプリケーションパフォーマンスの監視を統合する

コンテナーイメージまたはコードからアプリをデプロイする場合でも、Azure Container Apps はイメージやコードに干渉しません。アプリケーションと APM ツールの統合は、設定と実装によって異なります。

アプリケーションでサポートされている APM を使用していない場合は、Azure Application Insights を検討してください。詳細については、「 Spring Boot での Azure Monitor Application Insights の使用」を参照してください。

アプリケーションをデプロイする

「az containerapp up コマンドを使用して Azure Container Apps をデプロイする」の説明に従って、移行された各マイクロサービス (Spring Cloud Config Server と Spring Cloud Service Registry を含まない) をデプロイします。

シークレットと環境変数を構成する

各アプリケーションに、環境変数として構成設定を挿入できます。これらの変数を手動エントリまたはシークレットへの参照として設定します。詳細については、「 Azure Container Apps での環境変数の管理」を参照してください。

ID と認証を設定する

Spring Boot アプリケーションのいずれかが認証または承認を必要とする場合は、ID プロバイダーにアクセスするように構成されていることを確認します。

ID プロバイダーが Microsoft Entra ID の場合は、変更を加えないでください。
ID プロバイダーがon-premises Active Directory フォレストである場合は、Microsoft Entra IDを使用してハイブリッド ID ソリューションを実装することを検討してください。詳細については、ハイブリッド ID のドキュメントを参照してください。
ID プロバイダーが PingFederate などの別のオンプレミスソリューションである場合は、「 Microsoft Entra Connect のカスタムインストール」を参照して、Microsoft Entra ID とのフェデレーションを構成します。

または、Spring Security を使用して、OAuth2/OpenID Connect または SAML 経由で ID プロバイダーを使用することを検討してください。

アプリケーションを公開する

既定では、Azure Container Apps にデプロイされたアプリケーションには、アプリケーション URL を介してアクセスできます。独自の仮想ネットワークを使用してマネージド環境にアプリをデプロイする場合は、アプリのアクセシビリティレベルを決定して、仮想ネットワークからのパブリックイングレスまたはイングレスのみを許可します。詳細については、「Azure Container Apps 環境でのNetworkingを参照してください。

移行後

移行が完了したら、アプリケーションが期待どおりに動作することを確認します。次のセクションでは、アプリケーションをよりクラウドネイティブで運用上の堅牢なものにするための推奨事項について説明します。

クラウドネイティブパターンに合わせて最適化する

次の推奨事項は、Spring Cloud コンポーネントと Azure Container Apps マネージド Java コンポーネントを採用して、アプリケーションをよりクラウドネイティブにするのに役立ちます。

サービスの検出と負荷分散

アプリケーションが Spring Cloud Registry コンポーネントを操作できるようにして、デプロイされた他の Spring アプリケーションとクライアントが動的に検出できるようにします。詳細については、「Azure Container Apps の Eureka Server for Spring コンポーネントの Configure 設定」を参照してください。

次に、Spring Client Load Balancerを使用するようにアプリケーションクライアントを変更します。 Spring Client Load Balancer を使用すると、クライアントはアプリケーションの実行中のすべてのインスタンスのアドレスを取得し、別のインスタンスが破損または応答しなくなった場合に動作するインスタンスを見つけます。詳細については、Spring ブログの「Spring Tips: Spring Cloud Load Balancer」を参照してください。

API ゲートウェイ

Spring Cloud Gateway インスタンスを追加することを検討してください。 Spring Cloud Gateway は、Azure Container Apps環境にデプロイされているすべてのアプリケーションに対して単一のエンドポイントを提供します。 Spring Cloud Gateway を既にデプロイしている場合は、新しくデプロイされたアプリケーションにトラフィックをルーティングするようにルーティング規則を構成していることを確認します。

一元化された構成

Spring Cloud Config Server を追加し、すべての Spring Cloud アプリケーションの構成を、バージョン管理も含め、一元的に管理することを検討してください。まず、構成を格納する Git リポジトリを作成し、それを使用するようにアプリインスタンスを構成します。詳細については、Azure Container Apps の Config Server を利用した Spring コンポーネントの構成設定を参照してください。

次の手順を使用して、構成を移行します。

アプリケーションの src/main/resources ディレクトリ内に、次の内容 のbootstrap.yml ファイルを作成します。
```
spring:
  application:
    name: <your-application-name>
```
構成 Git リポジトリで、 <アプリケーション名>.yml ファイルを作成します。 your-application-name は前の手順と同じです。 設定を src/main/resources のapplication.yml ファイルから、作成した新しいファイルに移動します。設定が以前 に .properties ファイルに含まれている場合は、最初に YAML に変換します。この変換を実現するためのオンラインツールまたは IntelliJ プラグインを見つけることができます。
作成したディレクトリに application.yml ファイルを作成します。このファイルを使用して、データソース、ログ設定、Spring Boot Actuator の構成など、Azure Container Apps 環境内のすべてのアプリケーション間で共有される設定とリソースを定義します。
これらの変更を Git リポジトリにコミットし、プッシュします。
application.properties または application.yml ファイルをアプリケーションから削除します。

行政

アクチュエータエンドポイントを公開する Spring Boot Web アプリケーションの管理インターフェイスを有効にするには、Admin for Spring マネージドコンポーネントの追加を検討してください。詳細については、「Azure Container Appsを参照してください。

運用の準備を改善する

次の推奨事項は、移行されたアプリケーションの信頼性、可観測性、デプロイプラクティスを強化するのに役立ちます。

CI/CD パイプライン: 自動で一貫性のあるデプロイ用のデプロイパイプラインを追加します。手順は、 Azure Pipelines と GitHub Actions で使用できます。
青緑色のデプロイ: コンテナーアプリのリビジョン、リビジョンラベル、イングレストラフィックの重みを使用して、運用環境でコードの変更をテストしてから、エンドユーザーが使用できるようにします。詳細については、「Blue-Green Deployment in Azure Container Apps」を参照してください。
サービスバインド: サポートされている Azure データベースにアプリケーションを接続するためのサービスバインドを追加します。サービスバインドにより、Spring Boot アプリケーションに接続情報 (資格情報を含む) を提供する必要がなくなります。
JVM メトリック: Java 開発スタックで JVM コアメトリックを収集できるようにします。詳細については、Azure Container Apps 内の Java アプリ用 Java メトリックを参照してください。
アラート: Azure Monitor アラートルールとアクショングループを追加して、異常な状態をすばやく検出して対処します。詳細については、「 Azure Container Appsを参照してください。
ゾーンの冗長性: ゾーンの冗長性を有効にして、可用性ゾーン間でアプリをレプリケートします。トラフィックは負荷分散され、ゾーンの停止が発生した場合、レプリカに自動的にルーティングされます。詳細については、「 Azure Container Apps の信頼性」を参照してください。
Web アプリケーションファイアウォール: Application Gateway 上の Web アプリケーションファイアウォールを使用して、コンテナーアプリを一般的な悪用や脆弱性から保護します。詳細については、Application Gateway 上の Web Application Firewall で Azure Container Apps を保護する方法を参照してください。

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-03-27