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

[アーティクル]
04/10/2023

Note

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

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

移行前

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

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

Azure Kubernetes Service のコンテナーに実行可能 JAR アプリケーションを移行する (ガイド計画済)
実行可能 JAR アプリケーションを Azure Virtual Machines に移行する (ガイド計画済)

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

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

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

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

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

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

Azure Spring Apps に移行する前に、失われたり、重複したりしてはならないローカルの状態がコードに確実に含まれていないようにしてしてください。ローカルの状態が存在する場合、アプリケーションの外部にその状態を格納するようにコードを変更します。クラウド対応アプリケーションでは通常、次のような場所にアプリケーションの状態が格納されます。

Azure Cache for Redis
Azure Cosmos DB
Azure SQL、Azure Database for MySQL、Azure Database for PostgreSQL などの別の外部データベース。

ファイルシステムが使用されているかどうかとその使用方法を判断する

お使いのサービスがローカルファイルシステムに対して書き込みや読み取りを行うすべてのインスタンスを検索します。短期または一時ファイルの書き込みと読み取りが行われる場所と、存続期間が長いファイルの書き込みと読み取りが行われる場所を特定します。

Note

Azure Spring Apps では、/tmp にマウントされた Azure Spring Apps インスタンスごとに 5 GB の一時ストレージが提供されます。一時ファイルがその制限を超えて、または別の場所に書き込まれる場合は、コードの変更が必要になります。

読み取り専用の静的コンテンツ

現在、アプリケーションで静的コンテンツを提供している場合は、そのための別の場所が必要になります。静的コンテンツを Azure Blob Storage に移動し、グローバルな高速ダウンロードのために Azure CDN を追加することを検討できます。詳細については、「Azure Storage での静的 Web サイトホスティング」と「クイックスタート:Azure ストレージアカウントと Azure CDN との統合」を参照してください。

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

アプリケーションによってアップロードまたは生成されるが、作成後に変更できない静的コンテンツをアプリケーションで許可する場合は、前述のように Azure Blob Storage と Azure CDN を使用し、Azure Function でアップロードと CDN の更新を処理します。「Azure Functions を使用した静的コンテンツのアップロードと CDN の事前読み込み」で、ご利用いただけるサンプルの実装を提供しています。

いずれかのサービスに OS 固有のコードが含まれているかどうかを判断する

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

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

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

Note

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

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

java -version

サポートされている Java、Spring Boot、Spring Cloud のバージョン、および更新の手順については、「Azure Spring Apps でアプリケーションをデプロイ用に準備する」を参照してください。

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

スケジュールされたジョブ (Quartz Scheduler タスクや Unix cron ジョブなど) は、Azure Spring Apps では使用できません。 Azure Spring Apps では、スケジュールされたタスクを含むアプリケーションの内部でのデプロイが妨げられることはありません。ただし、アプリケーションをスケールアウトすると、同じスケジュールされたジョブが、スケジュールされた期間に複数回実行されることがあります。このような場合、意図しない結果になることがあります。

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

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

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

Maven

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

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

Gradle

Gradle プロジェクトでは、Spring Boot バージョンは通常、org.springframework.boot プラグインのバージョンとして plugins セクションにあります。

plugins {
  id 'org.springframework.boot' version '2.7.10'
  id 'io.spring.dependency-management' version '1.0.15.RELEASE'
  id 'java'
}

Spring Boot 1.x を使用しているアプリケーションの場合は、「Spring Boot 2.0 の移行ガイド」に従って、サポートされている Spring Boot バージョンに更新します。サポートされているバージョンについては、「Azure Spring Apps でアプリケーションをデプロイ用に準備する」の「Spring Boot と Spring Cloud のバージョン」のセクションを参照してください。

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

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

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

アプリケーションで使用されているアプリケーションパフォーマンス監視エージェントを特定します。 Azure Spring Apps では、Application インサイト、New Relic、Elastic APM、Dynatrace、AppDynamics との統合がサポートされています。アプリケーションでサポートされている APM を使用している場合は、移行で統合を構成します。サポートされている APM をアプリケーションで使用していない場合は、代わりにアプリケーションインサイトの使用を検討してください。詳細については、「移行」セクションを参照してください。

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

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

データベース

SQL データベースが存在する場合は、接続文字列を特定します。

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

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

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=tryandguess

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

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

ibm:
  mq:
    queueManager: qm1
    channel: dev.ORDERS
    connName: localhost(14)
    user: admin
    password: big$ecr3t

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 Spring Apps によって、デプロイされたアプリケーションの server.port 設定が上書きされます。 443 以外のポートで利用できるアプリケーションにいずれかのクライアントが依存している場合、それらを変更する必要があります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

移行

Azure Spring Apps のインスタンスとアプリを作成する

Azure サブスクリプションに Azure Spring Apps インスタンスがまだ存在しない場合は、プロビジョニングします。その後、そこでアプリケーションを作成します。詳細については、「クイックスタート: 初めてのアプリケーションを Azure Spring Apps にデプロイする」を参照してください。

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

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

アプリケーションが Azure Spring Apps にデプロイされたら、診断設定を追加して、たとえば Azure Monitor Log Analytics を使用して、ログに記録されたイベントを使用できるようにします。

LogStash/ELK スタック

ログの集計に LogStash/ELK スタックを使用する場合は、コンソールの出力を Azure Event Hub にストリーミングするように診断設定を構成します。次に、LogStash EventHub プラグインを使用して、ログに記録されたイベントを LogStash に取り込みます。

Splunk

ログの集計に Splunk を使用する場合は、コンソールの出力を Azure Blob Storage にストリーミングするように診断設定を構成します。次に、Microsoft Cloud Services 用の Splunk アドオンを使用して、ログに記録されたイベントを Splunk に取り込みます。

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

アプリケーションのいずれかの部分でローカルファイルシステムに対する読み取りまたは書き込みが行われる場合は、永続ストレージを構成してローカルファイルシステムを置き換える必要があります。詳細については、「Azure Spring Apps で組み込みの永続ストレージを使用する」を参照してください。

一時ファイルは、/tmp ディレクトリに書き込む必要があります。 OS 非依存の場合は、System.getProperty("java.io.tmpdir") を使用してこのディレクトリを取得できます。また、java.nio.Files::createTempFile を使用して、一時ファイルを作成することもできます。

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

Azure Spring Apps は JRE キーストアへのアクセスを提供しないため、Azure KeyVault に証明書を移行し、KeyVault 内の証明書にアクセスするようにアプリケーションコードを変更する必要があります。詳細については、「Key Vault 証明書の概要」と Java 用の Azure Key Vault の証明書クライアントライブラリに関するページを参照してください。

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

Azure Spring Apps には、次の APM 統合が用意されています。リンクに従って、必要な APM を有効にします。

サポートされている APM をアプリケーションで使用していない場合は、代わりにアプリケーションインサイトの使用を検討してください。 Azure Spring Apps は、パフォーマンス管理と異常に対するリアルタイムの応答のために、Application インサイトと緊密に統合されています。

アプリケーションのメトリッククライアントおよびエンドポイントを無効にする

使用しているメトリッククライアント、またはアプリケーションで公開されているメトリックエンドポイントを削除します。

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

「クイックスタート: 初めてのアプリケーションを Azure Spring Apps にデプロイする」で説明されているように、移行した各マイクロサービス (Spring Cloud Config および Registry のサーバーは含みません) をデプロイします。

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

サービスごとの構成設定を各サービスに環境変数として挿入できます。 Azure portal で次の手順を使用します。

Azure Spring Apps インスタンスに移動し、[アプリ] を選択します。
構成するサービスを選択します。
[構成] を選択します。
構成する変数を入力します。
[保存] を選択します。

Spring Cloud App Configuration Settings

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 Spring Apps にデプロイされたアプリケーションは外部に表示されません。次のコマンドでパブリックにすることでアプリケーションを公開できます。

az spring app update --name <application name> --is-public true

Spring Cloud Gateway を使用している場合、または使用する予定の場合は、この手順をスキップします。詳しくは、次のセクションをご覧ください。

移行後

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

Spring Cloud レジストリと連動するようにアプリケーションを有効にすることを検討してください。これにより、デプロイされた他の Spring アプリケーションやクライアントでアプリケーションを動的に検出できます。詳しくは、「Azure Spring Apps にデプロイするアプリケーションを準備する方法」を参照してください。次に、Spring Client ロードバランサーを使用するようにアプリケーションクライアントを変更します。これにより、クライアントでは実行中のすべてのアプリケーションインスタンスのアドレスを取得し、別のインスタンスが壊れたか、応答しなくなった場合に動作するインスタンスを見つけることができます。詳細については、Spring ブログの「Spring ヒント: Spring Cloud Load Balancer」を参照してください。
アプリケーションをパブリックにする代わりに、Spring Cloud Gateway インスタンスの追加を検討してください。 Spring Cloud Gateway は、Azure Spring Apps インスタンスにデプロイされたすべてのアプリケーションの単一エンドポイントとなります。 Spring Cloud Gateway が既にデプロイされている場合は、確実に新しくデプロイされたアプリケーションにトラフィックを送信するように構成します。
Spring Cloud Config サーバーを追加し、すべての Spring Cloud アプリケーションの構成を、バージョン管理も含め、一元的に管理することを検討してください。まず、構成を格納するための Git リポジトリを作成し、それを使用するように Azure Spring Apps インスタンスを構成します。詳しくは、「自分のサービス向けに Spring Cloud 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 Spring Apps インスタンス上のすべてのアプリケーション間で共有される設定とリソースを定義できます。通常、このような設定には、データソース、ログ設定、Spring Boot アクチュエータの構成などが含まれます。
4. これらの変更を Git リポジトリにコミットし、プッシュします。
5. application.properties または application.yml ファイルをアプリケーションから削除します。
一貫性のある自動デプロイのためにデプロイパイプラインを追加することを検討します。 Azure Pipelines、GitHub Actions、 Jenkins についての手順が用意されています。
ステージング環境のデプロイを使用してコードの変更を運用環境でテストした後に、一部またはすべてのエンドユーザーがそれらを使用できるようにすることを検討します。詳細については、「Azure Spring Apps でステージング環境を設定する」を参照してください。
サポートされている Azure データベースにアプリケーションを接続するために、サービスバインドを追加することを検討します。これらのサービスバインドにより、資格情報などの接続情報を Spring Cloud アプリケーションに提供する必要がなくなります。
アプリケーションのパフォーマンスおよび相互作用を監視するために、Azure Application Insights の使用を検討してください。詳細については、Azure Spring Apps での Application Insights Java インプロセスエージェントに関する記事をご覧ください。
異常な状態を迅速に検出して対処するために、Azure Monitor のアラートルールおよびアクショングループを追加することを検討します。詳細については、「チュートリアル: アラートとアクショングループを使用して Spring Cloud リソースを監視する」を参照してください。
待機時間を短くし、信頼性とフォールトトレランスを高めるために、別のリージョンに Azure Spring Apps デプロイをレプリケートすることを検討します。 Azure Traffic Manager を使用してデプロイ間で負荷を分散するか、Azure Front Door を使用して SSL オフロードと DDoS 保護付きの Web アプリケーションファイアウォールを追加します。
geo レプリケーションが不要な場合は、Azure Application Gateway を追加して、SSL オフロードと DDoS 保護付きの Web アプリケーションファイアウォールを追加することを検討します。

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

移行前

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

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

ファイル システムが使用されているかどうかとその使用方法を判断する

読み取り専用の静的コンテンツ

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

いずれかのサービスに OS 固有のコードが含まれているかどうかを判断する

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

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

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

Maven

Gradle

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

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

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

データベース

JMS メッセージ ブローカー

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

ID プロバイダー

非標準ポートに依存しているすべてのクライアントを特定する

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

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

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

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

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

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

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

移行

Azure Spring Apps のインスタンスとアプリを作成する

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

LogStash/ELK スタック

Splunk

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

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

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

アプリケーションのメトリック クライアントおよびエンドポイントを無効にする

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

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

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

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

移行後

フィードバック

フィードバック

その他のリソース

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

ファイルシステムが使用されているかどうかとその使用方法を判断する

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

JMS メッセージブローカー

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

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

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

アプリケーションのメトリッククライアントおよびエンドポイントを無効にする