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

このガイドでは、Azure Container Appsで実行する既存の Spring Boot アプリケーションを移行する場合に注意する必要がある事項について説明します。

移行前

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

以下の移行前の要件のいずれかを満たすことができない場合は、次の関連する移行ガイドを参照してください。

実行可能な JAR アプリケーションを Azure Kubernetes Service 上のコンテナーに移行する (ガイダンスが計画されています)
実行可能な JAR アプリケーションをAzure Virtual Machinesに移行する (ガイダンスが計画されています)

アプリケーションコンポーネントを検査する

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

PaaS 環境では、任意のタイミングでアプリケーションが厳密に 1 回実行されるという保証はありません。 1 つのインスタンスで実行するようにアプリケーションを構成するときでも、次のようなケースでは、重複するインスタンスが作成されることがあります。

故障またはシステム更新に起因して、物理ホストにアプリケーションを再配置する必要がある。
アプリケーションが更新中である。

いずれの場合も、新しいインスタンスの起動が完了するまで、元のインスタンスは実行されたままになります。このパターンは、アプリケーションに次のような大きな影響を及ぼす可能性があります。

シングルトンが実際に 1 つであるとは保証されない。
外部ストレージに永続化されていないデータは、単一の物理サーバー上または VM 上よりも早く失われる可能性がある。

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 File は永続的なストレージを提供し、複数のコンテナー間で共有できます。詳細については、「 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 に依存するコードが含まれている場合は、それをリファクタリングしてそれらの依存関係を削除する必要があります。たとえば、アプリケーションがWindowsで実行されている場合は、ファイルシステムパスで / または \ の使用を File.Separator または Paths.get に置き換える必要がある場合があります。

サポートされているプラットフォームに切り替える

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

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

注

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

現在のJava バージョンを取得するには、実稼働サーバーにサインインし、次のコマンドを実行します。

java -version

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

スケジュールされたジョブにアプリケーションが依存しているかどうかを判断する

Unix cron ジョブや Spring Batch フレームワークに基づく短いライブアプリケーションなどのエフェメラルアプリケーションは、Azure Container Appsでジョブとして実行する必要があります。詳細については、Azure Container Apps におけるジョブをご参照ください。アプリケーションが実行時間の長いアプリケーションであり、Quartz や Spring Batch などのスケジュールフレームワークを使用して定期的にタスクを実行する場合、Azure Container Appsはそのアプリケーションをホストできます。ただし、スケールアウトまたはローリングアップグレード中に、スケジュールされた期間ごとに同じアプリケーションインスタンスが複数回実行される競合状態を回避するために、アプリケーションはスケーリングを適切に処理する必要があります。

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

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

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

Maven

Maven プロジェクトでは、Spring Boot バージョンは通常、POM ファイルの要素にあります。

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

Gradle

Gradle プロジェクトでは、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 2.0 移行ガイドまたは Spring Boot 3.0 移行ガイドに従って、サポートされている Spring Boot バージョンに更新してください。サポートされているバージョンについては、Spring Boot と Spring Cloud のバージョンを参照してください。

ログ集計ソリューションを特定する

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

アプリケーションパフォーマンス管理 (APM) エージェントを特定する

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

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

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

データベース

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 のドキュメントを参照してください。

JPA リポジトリ
JDBC リポジトリ
Cassandra リポジトリ
MongoDB リポジトリ

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")
      ...
    }

使用中のブローカーを特定したら、対応する設定を見つけます。 Spring Boot アプリケーションでは、これらは通常、アプリケーションディレクトリの 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 コンポーネントのドキュメントを参照してください。

外部キャッシュを特定する

使用中の外部キャッシュを特定します。一般的に、Redis が Spring Data 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を使用すると、Azure Container Apps リソースの構成に従ってポートを公開できます。たとえば、Spring Boot アプリケーションは既定でポート 8080 をリッスンしますが、必要に応じてまたは環境変数を使用して設定できます。

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

このガイドに、考えられるすべての外部依存関係を記載することはできません。移行後に、アプリケーションの外部依存関係がすべて満たされることを確認するのは、お客様の責任です。

構成のソースとシークレットをインベントリする

パスワードとセキュリティで保護された文字列をインベントリする

すべてのシークレット文字列とパスワードについて、実稼働デプロイ上のすべてのプロパティおよび構成ファイルとすべての環境変数を確認します。 Spring Boot アプリケーションでは、多くの場合、このような文字列は application.properties または application.yml ファイルで見つかります。

証明書をインベントリする

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

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

デプロイアーキテクチャを検査する

各サービスのハードウェア要件を文書化する

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

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

地理的レプリケーション・配信の文書化

Spring Boot アプリケーションインスタンスが現在複数のリージョンまたはデータセンターに分散しているかどうかを判断します。移行するアプリケーションの稼働時間要件/SLA を文書化します。

移行

Azure Container Apps環境を作成してアプリをデプロイする

Azure サブスクリプションでAzure Container Apps インスタンスをプロビジョニングします。これに伴い、安全なホスティング環境も作成されます。詳細については、「Quickstart: Azure ポータルを使用して最初のコンテナーアプリをデプロイするを参照してください。

コンソールログを確認して診断設定を構成する

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

アプリケーションを Azure Container Apps にデプロイした後、Container Apps 環境内でログオプションを構成して、ログの 1 つ以上の宛先を定義できます。これらの宛先には、Azure Monitor Log Analytics、Azure イベントハブ、その他のサードパーティの監視ソリューションを含めることができます。ログデータを無効にして、実行時にのみログを表示することもできます。詳細な構成手順については、「log storage and monitoring options in Azure Container Apps」を参照してください。

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

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

すべての証明書を KeyVault に移行する

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

アプリケーションパフォーマンス管理 (APM) 統合を構成する

アプリがコンテナーイメージまたはコードからデプロイされているかどうかにかかわらず、Azure Container Appsはイメージやコードに干渉しません。したがって、アプリケーションを APM ツールと統合するかどうかは、個々の意向と実装に左右されます。

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

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

deploy Azure Container Appsで説明されているように、移行された各マイクロサービス (Spring Cloud Config Server と Spring Cloud Service Registry を含まない) をデプロイします。

サービスごとのシークレットと外部化された設定を構成する

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

ID プロバイダーを移行して有効にする

Spring Cloud アプリケーションのいずれかで認証または認可が必要な場合は、それらが 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 レジストリと連動するようにアプリケーションを有効にすることを検討してください。このコンポーネントにより、デプロイされた他の Spring アプリケーションやクライアントから、アプリケーションを動的に検出できます。詳細については、「Azure Container Apps の Eureka Server for Spring コンポーネントの Configure 設定」を参照してください。次に、Spring Client Load Balancerを使用するようにアプリケーションクライアントを変更します。 Spring Client Load Balancerを使用すると、クライアントはアプリケーションのすべての実行中のインスタンスのアドレスを取得し、別のインスタンスが破損または応答しなくなった場合に動作するインスタンスを見つけることができます。詳細については、Spring ブログの「Spring Tips: Spring Cloud Load Balancer」を参照してください。
アプリケーションをパブリックにする代わりに、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 コンポーネントの構成設定を参照してください。次に、以下の手順で構成を移行します。
1. アプリケーションの src/main/resources ディレクトリ内に、次の内容を含む bootstrap.yml ファイルを作成します。
```
  spring:
    application:
      name: <your-application-name>
```
2. 構成 Git リポジトリで、your-application-name.yml ファイルを作成します。ここで、は、前の手順と同じです。 src/main/resources 内の application.yml ファイルから、作成した新しいファイルに、設定を移動します。設定が以前に .properties ファイルに含まれていた場合は、まず YAML に変換します。この変換を実行するには、オンラインツールまたは IntelliJ プラグインを検索します。
3. 上記のディレクトリに application.yml ファイルを作成します。このファイルを使用して、Azure Container Apps環境内のすべてのアプリケーション間で共有される設定とリソースを定義できます。通常、このような設定には、データソース、ログ設定、Spring Boot アクチュエータの構成などが含まれます。
4. これらの変更を Git リポジトリにコミットし、プッシュします。
5. application.properties または application.yml ファイルをアプリケーションから削除します。
アクチュエータエンドポイントを公開する Spring Boot Web アプリケーションの管理インターフェイスを有効にするには、Admin for Spring マネージドコンポーネントの追加を検討してください。詳細については、「Azure Container Appsを参照してください。
一貫性のある自動デプロイのためにデプロイパイプラインを追加することを検討します。手順は、Azure Pipelines および GitHub Actions で使用できます。
コンテナーアプリのリビジョン、リビジョンラベル、およびイングレストラフィックの重みを使用してブルーグリーンデプロイを有効にすることを検討してください。これにより、コードの変更を一部またはすべてのエンドユーザーに公開する前に、運用環境でテストできます。詳細については、「Blue-Green Deployment in Azure Container Apps」を参照してください。
サポートされているAzure データベースにアプリケーションを接続するためのサービスバインドを追加することを検討してください。これらのサービスバインドにより、資格情報などの接続情報を Spring Cloud アプリケーションに提供する必要がなくなります。
Java開発スタックを有効にして、アプリケーションの JVM コアメトリックを収集することを検討してください。詳細については、Azure Container Apps 内の Java アプリの Java メトリックを参照してください。
アラートルールとアクショングループAzure Monitor追加して、異常な条件をすばやく検出して対処することを検討してください。詳細については、「 Azure Container Appsを参照してください。
リージョン内のゾーン間でアプリをレプリケートするために、Azure Container Apps のゾーン冗長性を有効にすることを検討してください。トラフィックは負荷分散され、ゾーンの停止が発生した場合、レプリカに自動的にルーティングされます。冗長な設定の詳細については、「reliability in Azure Container Apps」を参照してください。
Application Gateway でWeb Application Firewallを使用して、一般的な悪用や脆弱性からAzure Container Appsを保護することを検討してください。詳細については、Application Gateway 上の Web Application Firewall で Azure Container Apps を保護する方法を参照してください。

フィードバック

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

Last updated on 2026-03-05