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

[アーティクル]
10/03/2024

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

移行前

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

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

Azure Kubernetes Service のコンテナーに実行可能 JAR アプリケーションを移行する (ガイド計画済)
実行可能 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 Storage での静的 Web サイトホスティング」と「クイックスタート:Azure ストレージアカウントと Azure CDN との統合」を参照してください。

動的に公開される静的コンテンツ

アプリケーションが、アップロードされたものかアプリケーション自体によって生成されたものかを問わず、作成後に変更されない静的コンテンツをサポートしている場合は、Azure Blob Storage と Azure CDN を統合できます。また、Azure Functions を使用してアップロードを管理し、必要に応じて 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 ディストリビューションの安定した最新リリースを使用します。

Note

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

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

java -version

サポートされている Java、Spring Boot、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> 要素にあります。

    <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 バージョンは通常、org.springframework.boot プラグインのバージョンとして plugins セクションにあります。

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

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 ファイル内にあります。

Note

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 をリッスンしますが、必要に応じて server.port または環境変数 SERVER_PORT を使用して設定できます。

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

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

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

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

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

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

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

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

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

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

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

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

geo レプリケーション/分散を文書化する

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

移行

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

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

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

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

アプリケーションが Azure Container Apps にデプロイされたら、Container Apps 環境内でログ記録オプションを構成して、ログの宛先を 1 つ以上定義できます。これらの宛先には、Azure Monitor Log Analytics、Azure イベントハブ、またはその他のサードパーティ監視ソリューションを含めることができます。ログデータを無効にして、実行時にのみログを表示することもできます。詳細な構成手順については、「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 つの選択肢です。詳細については、「Azure Monitor Application Insights と Spring Boot の使用」を参照してください。

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

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

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

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

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

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

ID プロバイダーが Microsoft Entra ID である場合、変更は一切必要ありません。
ID プロバイダーがオンプレミスの 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 環境でのネットワーク」を参照してください。

移行後

これで移行が完了したので、アプリケーションが予想どおりに動作することを確認します。その後、次の推奨事項を利用することでアプリケーションをよりクラウドネイティブにすることができます。

Spring Cloud レジストリと連動するようにアプリケーションを有効にすることを検討してください。このコンポーネントにより、デプロイされた他の Spring アプリケーションやクライアントから、アプリケーションを動的に検出できます。詳細については、「Azure Container Apps の Spring 用 Eureka Server コンポーネントの設定を構成する」を参照してください。次に、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 の Spring 用 Config Server コンポーネントの設定を構成する」を参照してください。次に、以下の手順で構成を移行します。
1. アプリケーションの src/main/resources ディレクトリ内に、次の内容を含む bootstrap.yml ファイルを作成します。
```
  spring:
    application:
      name: <your-application-name>
```
2. 構成 Git リポジトリで、<your-application-name>.yml ファイルを作成します。ここで、your-application-name は、前の手順と同じです。 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 で Spring Boot Admin コンポーネントを構成する」を参照してください。
一貫性のある自動デプロイのためにデプロイパイプラインを追加することを検討します。 Azure Pipelines と GitHub Actions の手順を参照できます。
コンテナーアプリのリビジョン、リビジョンラベル、およびイングレストラフィックの重みを使用してブルーグリーンデプロイを有効にすることを検討してください。これにより、コードの変更を一部またはすべてのエンドユーザーに公開する前に、運用環境でテストできます。詳細については、「Azure Container Apps でのブルーグリーンデプロイ」を参照してください。
サポートされている Azure データベースにアプリケーションを接続するために、サービスバインドを追加することを検討します。これらのサービスバインドにより、資格情報などの接続情報を Spring Cloud アプリケーションに提供する必要がなくなります。
Java 開発スタックを有効にして、アプリケーションの JVM コアメトリックを収集することを検討してください。詳細については、「Azure Container Apps の Java アプリ用 Java メトリック」を参照してください。
異常な状態を迅速に検出して対処するために、Azure Monitor のアラートルールおよびアクショングループを追加することを検討します。詳細については、「Azure Container Apps でアラートを設定する」を参照してください。
Azure Container Apps のゾーン冗長性を有効にして、リージョン内のゾーン間でアプリをレプリケートすることを検討してください。トラフィックは負荷分散され、ゾーンの停止が発生した場合、レプリカに自動的にルーティングされます。冗長設定の詳細については、「Azure Container Apps の信頼性」を参照してください。
Application Gateway の Web Application Firewall を使用して、Azure Container Apps を一般的な悪用や脆弱性から保護することを検討してください。詳細については、「Application Gateway で Web Application Firewall を使用して Azure Container Apps を保護する」を参照してください。

次の方法で共有