アプリケーション移行の概要

[アーティクル]
02/06/2025

Note

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 Container Apps へのアプリ移行アプローチの概要について説明します。

前提条件

既存の Azure Spring Apps インスタンス。
既存の Azure Container Apps。詳細については、クイックスタート: Azure portal を使用して最初のコンテナーアプリをデプロイするを参照してください。

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

Azure Container Apps を使用すると、Azure Container Registry (ACR) や Docker Hub などのコンテナーレジストリからデプロイできます。デプロイには、Azure portal、Azure CLI、またはその他のツールを使用できます。次の例は、ターゲットマネージド環境 my-container-apps にアプリケーションをデプロイする方法を示しています。詳細については、「containerapp up を使用して最初のコンテナーアプリをデプロイする」または「Azure portal を使用して最初のコンテナーアプリをデプロイする」を参照してください。

az containerapp up \
    --resource-group my-container-apps \
    --name my-container-app \
    --location centralus \
    --environment 'my-container-apps' \
    --image mcr.microsoft.com/k8se/quickstart:latest \
    --target-port 80 \
    --ingress external

Azure Container Apps では、Java アプリケーションのプレビュー機能が提供されるようになりました。この機能により、ユーザーはローカルまたはコードリポジトリで JAR ファイルまたはソースコードから直接アプリケーションをデプロイできます。コンテナーイメージを使用してコンテナーアプリをデプロイすることを強くお勧めします。

環境変数

Azure Container Apps を使用すると、環境変数を構成できます。これらは、新しいアプリを作成するときに、または新しいリビジョンを作成することで後から設定できます。

Azure portal で環境変数を変更するには、新しいリビジョンを明示的に作成する必要があります。 Azure CLI を使用する場合は、コマンド az containerapp update を使用してアプリを更新できます。次の例に示すように、新しいリビジョンが自動的に作成されます。環境変数は重複しないことが重要です。複数の変数の名前が同じである場合、リスト内の最後の変数のみが有効になります。

az containerapp update \
    --resource-group <RESOURCE_GROUP_NAME> \
    --name <APP NAME> \
    --set-env-vars <VAR_NAME>=<VAR_VALUE>

Azure Container Apps には、組み込みの環境変数も用意されています。これらの変数は、実行時に便利なプラットフォームメタデータを提供します。詳細については、「Azure Container Apps で環境変数を管理する」の組み込み環境変数に関するセクションを参照してください。

シークレット

Azure Container Apps は、「シークレット」と呼ばれる機密性の高い構成値の安全な格納をサポートします。これらのシークレットは、名前と値のペアとしてアプリケーションレベルで定義され、すべてのコンテナーアプリリビジョンからアクセスできます。

シークレットは、直接入力するのではなく、Azure Key Vault に格納することをお勧めします。次のいずれかの形式を使用して、Azure Key Vault から各シークレットの値を参照できます。

https://myvault.vault.azure.net/secrets/mysecret はシークレットの最新バージョンを参照します。
https://myvault.vault.azure.net/secrets/mysecret/<version-ID> は特定バージョンのシークレットを参照します。

この方法では、コンテナーアプリのマネージド ID を有効にし、Key Vault へのアクセス権を付与する必要があります。 Key Vault のアクセスポリシーでは、アプリが GET を使用してシークレットを取得できるようにする必要があります。または、Key Vault で Azure のロールベースのアクセス制御が使用されている場合は、Key Vault Secrets User ロールを割り当てる必要があります。マネージド ID を設定したら、シークレットの URI を指定することで、Key Vault 参照をシークレットとしてアプリに追加できます。その後、アプリはマネージド ID を使用して実行時にシークレットを取得できます。

次の規則に注意してください。

シークレットを削除または変更しても、既存のリビジョンには自動的には影響しません。シークレットを更新または削除する場合は、新しいリビジョンをデプロイするか、既存のリビジョンを再起動して変更を反映する必要があります。
スケールルール内でシークレットを使用することもできます。

コンテナーアプリでシークレットを使用する場合は、環境変数で参照するか、ボリュームにマウントします。環境変数では、シークレットの値が自動的に設定されます。または、シークレットをボリュームにマウントすることもできます。この場合、各シークレットはファイルとして格納され、シークレット名がファイルの名前になり、シークレット値がファイルの内容になります。この柔軟性により、シークレットを安全に処理し、アプリ環境内でアクセスできるようになります。詳細については、「Azure Container Apps でシークレットを管理する」を参照してください。

ワークロードが機密性の高い構成をセキュリティで保護し、spring-cloud-azure-starter-keyvault-secrets ライブラリを使用して Key Vault からプロパティを取得する場合は、Azure Container Apps で Azure SDK または Spring KeyVault PropertySource を使用できます。移行中にコードを変更する必要はありません。

JVM オプション

Azure Container Apps で JVM オプションを出力するには、JAR または WAR からのコンテナーイメージのビルド方法に含まれるアプリケーションをコンテナー化する手順に従います。次の例に示すように、Dockerfile の ENTRYPOINT に -XX:+PrintFlagsFinal を追加できます。

# filename: JAR.dockerfile

FROM mcr.microsoft.com/openjdk/jdk:17-mariner

ARG JAR_FILENAME

COPY $JAR_FILENAME /opt/app/app.jar
ENTRYPOINT ["java", "-XX:+PrintFlagsFinal", "-jar", "/opt/app/app.jar"]

Azure Container Apps で JVM オプションのクエリを実行するには、次のクエリを使用します。

ContainerAppConsoleLogs_CL
| where ContainerAppName_s == "<APP_NAME>"
| where Log_s has_any ('{default}', '{command line}', '{ergonomic}')

次のログは、クエリを実行した後の JVM オプションを示す例です。

size_t MinHeapSize = 8388608 {product} {ergonomic}
size_t MaxHeapSize = 268435456 {product} {ergonomic}

Azure Container Apps で JVM オプションを調整するには、次の例に示すように、Dockerfile の ENTRYPOINT に JVM オプションを追加できます。

# filename: JAR.dockerfile

FROM mcr.microsoft.com/openjdk/jdk:17-mariner

ARG JAR_FILENAME

COPY $JAR_FILENAME /opt/app/app.jar
ENTRYPOINT ["java", "-XX:+PrintFlagsFinal", "-Xmx400m", "-Xss200m", "-jar", "/opt/app/app.jar"]

JVM オプションの詳細については、Java HotSpot VM オプションと JVM オプションの構成に関する説明を参照してください。

Storage

Azure Spring Apps と Azure Container Apps はどちらもコンテナースコープのストレージをサポートしています。つまり、コンテナーに格納されているデータは、コンテナーの実行中にのみ使用できます。 Azure Spring Apps の場合、アプリのストレージの合計は 5 GiB です。 Azure Container Apps は、割り当てられた vCPU の合計数に応じて 1 GiB から 8 GiB の範囲でストレージを提供します。このストレージには、各レプリカに割り当てられているすべてのエフェメラルストレージが含まれます。詳細については、「Azure Container Apps でストレージマウントを使用する」の「エフェメラルストレージ」セクションを参照してください。

Azure Spring Apps と Azure Container Apps の両方で、Azure Files を介した永続的ストレージがサポートされます。 Azure Container Apps では、SMB および NFS プロトコルを使用したファイル共有のマウントがサポートされています。マネージド環境でストレージ定義を作成し、その後、リビジョンで AzureFile (SMB) または NfsAzureFile (NFS) のボリュームを定義する必要があります。 Azure portal で AzureFile (SMB) の構成全体を完了できます。詳細については、Azure Container Apps で Azure Files ボリュームマウントを作成する方法を参照してください。 NFS 共有のマウントのサポートは現在プレビュー段階です。 Azure CLI または ARM テンプレートを使用して構成できます。詳細については、「チュートリアル: Azure portal を使用して NFS Azure ファイル共有を作成し、Linux VM にマウントする」の「NFS Azure ファイル共有」と「NFS Azure ファイル共有を作成する」セクションを参照してください。

マネージド ID

各コンテナーアプリには、保護された Azure リソースにアクセスするためのシステム割り当てマネージド ID またはユーザー割り当てマネージド ID があります。 ID を管理し、アクセス許可を付与する方法については、「Azure Container Apps のマネージド ID」を参照してください。

各コンテナーアプリには内部 REST エンドポイントがあり、IDENTITY_ENDPOINT 環境変数を介してアクセスできます。これは、Azure Spring Apps で使用されるエンドポイントとは異なります。アプリで直接 HTTP GET 要求を使用する場合は、正しいエンドポイントを取得するようにコードを調整する必要があります。アプリで Azure ID クライアントライブラリを介してマネージド ID を使用する場合、Azure ID によってこの詳細が自動的に管理されるため、コードの変更は必要ありません。

保護された Azure リソースにアクセスするとき、ワークロードでは、マネージド ID のアプリケーション ID またはクライアント ID を使用してアクセストークンをフェッチする必要があります。 Azure Spring Apps 環境では、システム割り当てマネージド ID またはユーザー割り当てマネージド ID のクライアント ID を設定できます。または、空のままにして、サービスがマネージド ID の 1 つからアプリケーション ID を選択できるようにすることもできます。 Azure Container Apps では、システム割り当てマネージド ID を使用する場合、アプリケーション ID を明示的に指定することはできません。ただし、ユーザー割り当てマネージド ID を使用する場合は、アプリケーション ID が必要です。

正常性プローブ

Azure Container Apps と Azure Spring Apps の両方で、startup probe、liveness probe、readiness probe の 3 種類の正常性プローブがすべてサポートされます。 Azure Container Apps の場合、プローブは HTTP または TCP プロトコルを使用できます。 exec はまだサポートされていません。

Azure Spring Apps では、プローブ設定はデプロイリソースに構成されます。これに対し、Azure Container Apps の場合、プローブ設定はコンテナーアプリリソースに定義されます。次の設定を実行できます。

プロパティ	説明	Azure Spring Apps	Azure Container Apps
`probeAction`	プローブのアクション。	`HTTPGetAction`、`TCPSocketAction`、`ExecAction` をサポートします。	アクションの種類のプロパティはありません。ユーザーは、`httpGet` または `tcpSocket` を直接使用する必要があります。
`disableProbe`	プローブが無効かどうかを示します。	Boolean	ブール値
`initialDelaySeconds`	アプリインスタンスの起動後、プローブが開始されるまでの秒数。		値の範囲は 1 から 60 です。
`periodSeconds`	プローブを実行する頻度 (秒単位)。	最大値は 1 です。	値の範囲は 1 から 240 で、既定値は 10 です。
`timeoutSeconds`	プローブがタイムアウトするまでの秒数。	最大値は 1 です。	値の範囲は 1 から 240 で、既定値は 1 です。
`failureThreshold`	成功した後にプローブが失敗したと見なされる、連続する失敗の最小数。	最大値は 1 です。	値の範囲は 1 から 10 で、既定値は 3 です。
`successThreshold`	失敗した後、プローブが成功と見なされるために必要な最小連続成功数。	最大値は 1 です。	値の範囲は 1 から 10 で、既定値は 1 です。
`terminationGracePeriodSeconds`	プローブ障害時にポッドが正常に終了する必要があるオプションの期間 (秒単位)。	既定値は 90 秒です。	最大値は 3,600 秒です。

現時点では、Azure portal で Azure Container Apps のプローブを直接構成することはできません。代わりに、Azure CLI から、ARM テンプレートまたはコンテナーアプリ YAML ファイルを使用して設定する必要があります。詳細については、「Azure Container Apps の正常性プローブ」を参照してください。

スケール

Azure Container Apps では、一連のスケーリングルールによる水平スケーリングがサポートされています。ルールが追加または変更されると、コンテナーアプリの新しいリビジョンが作成されます。

スケーリングには、HTTP、TCP、カスタムの 3 つのトリガーカテゴリがあります。 HTTP と TCP は、要求またはネットワーク接続の数に基づいています。詳細については、「Azure Container Apps でスケーリングルールを設定する」を参照してください。

CPU またはメモリに基づいてスケーリングをトリガーする

カスタムコンテナーアプリのスケーリング規則は、ScaledObject ベースの KEDA スケーラーに基づいています。 KEDA の CPU スケーラーとメモリスケーラーを使用して、CPU またはメモリ使用量に基づくコンテナーアプリでのスケーリングを実現できます。

次の例は、平均メモリ使用量が 25% を超えたときにスケールアウトが発生する構成を示しています。メモリ使用量には、現在のコンテナーアプリによって使用されるメモリと、内部サイドカーコンテナーなどの関連するポッドによって使用されるメモリも含まれます。 KEDA には、コンテナーアプリのフラッピングを防ぐための組み込みの構成が含まれています。内部設定の詳細については、「Azure Container Apps でスケーリングルールを設定する」を参照してください。実行時の動作を確認して、ニーズを満たしていることを確認する必要があります。

az containerapp create \
    --resource-group MyResourceGroup \
    --name my-containerapp \
    --image my-queue-processor --environment MyContainerappEnv \
    --min-replicas 1 --max-replicas 10 \
    --scale-rule-name memory-scaler \
    --scale-rule-type memory \
    --scale-rule-metadata "type=Utilization" \
                          "value=25"

Java メトリックに基づいてスケーリングをトリガーする

KEDA には Azure Monitor スケーラーが用意されています。これにより、Azure Monitor で使用可能なメトリックに基づくスケーリングが可能になります。この機能を使用すると、Azure Monitor にパブリッシュされた Java 固有のメトリックに基づいてアプリケーションを動的にスケーリングできます。

前提条件

アプリケーションを Microsoft Entra ID に登録します。詳細については、クイックスタート : Microsoft ID プラットフォームにアプリケーションを登録するを参照してください。
アクセス許可を付与する。登録済みのアプリケーションに、Azure Container Apps リソースに対する Monitoring Reader ロールを割り当てます。

手順

シークレットを追加します。次のコマンドを使用して、Microsoft Entra アプリケーションのクライアント ID とシークレットを Azure Container Apps にシークレットとして格納します。

az containerapp secret set \
    --resource-group MyResourceGroup \
    --name my-containerapp \
    --secrets activeDirectoryClientId=<Microsoft-Entra-Application-Client-ID> \
              activeDirectoryClientPassword=<Microsoft-Entra-Application-Client-Password>

スケーリングルールを定義します。次のコマンドで、Azure Monitor スケーラーを使用するカスタムスケーリングルールを作成します。このルールは、Azure Monitor で監視される特定の Java メトリック (JvmThreadCount など) に基づいてスケーリングアクションをトリガーします。

az containerapp create \
    --resource-group MyResourceGroup \
    --name my-containerapp \
    --image my-queue-processor --environment MyContainerappEnv \
    --min-replicas 1 --max-replicas 10 \
    --scale-rule-name thread-count \
    --scale-rule-type azure-monitor \
    --scale-rule-auth "activeDirectoryClientId=activeDirectoryClientId" \
                      "activeDirectoryClientPassword=activeDirectoryClientPassword" \
    --scale-rule-metadata "activationTargetValue=1" \
                          "metricAggregationInterval=0:1:0" \
                          "metricAggregationType=Maximum" \
                          "metricName=JvmThreadCount" \
                          "resourceGroupName=MyResourceGroup" \
                          "resourceURI=MyContainerAppShortURI" \
                          "subscriptionId=MyResourceID" \
                          "targetValue=30" \
                          "tenantId=MyTenantID"

キーの詳細

シークレット管理: アプリケーションの資格情報 (クライアント ID とパスワード) は、シークレットとして安全に格納されます。
スケーリング条件: metricName パラメーターは、スケーリングがいつ行われるべきかの評価に使用される Java メトリック (この場合は JvmThreadCount) を識別します。
ターゲット値: targetValue パラメーターは、スケーリングのしきい値 (たとえば、スレッド数が 30 を超えたときにスケーリングを実行する) を設定します。

このルールを設定することで、コンテナーアプリは Java 固有のパフォーマンスメトリックに基づいてインスタンスの数を動的に調整し、応答性とリソース使用率を向上させることができます。

次の方法で共有

アプリケーション移行の概要

前提条件

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

環境変数

シークレット

JVM オプション

Storage

マネージド ID

正常性プローブ

スケール

CPU またはメモリに基づいてスケーリングをトリガーする

Java メトリックに基づいてスケーリングをトリガーする

前提条件

手順

キーの詳細

フィードバック

その他のリソース