애플리케이션 마이그레이션 개요

아티클
02/04/2025

참고 항목

기본, 표준 및 엔터프라이즈 계획은 2025년 3월 중순부터 사용되지 않으며 3년의 은퇴 기간이 있습니다. Azure Container Apps로 전환하는 것이 좋습니다. 자세한 내용은 Azure Spring Apps 사용 중지 공지 사항을 참조하세요.

표준 소비 및 전용 계획은 2024년 9월 30일부터 사용되지 않으며 6개월 후에 완전히 종료됩니다. Azure Container Apps로 전환하는 것이 좋습니다. 자세한 내용은 Azure Spring Apps 표준 사용량 및 전용 계획을 Azure Container Apps로 마이그레이션을 참조 하세요.

이 문서는 기본/표준 ✅ 엔터프라이즈에✅ 적용됩니다.

이 문서에서는 Azure Spring Apps에서 Azure Container Apps로의 앱 마이그레이션 접근 방식에 대한 개요를 제공합니다.

필수 조건

기존 Azure Spring Apps 인스턴스입니다.
기존 Azure 컨테이너 앱입니다. 자세한 내용은 빠른 시작: Azure Portal을 사용하여 첫 번째 컨테이너 앱 배포를 참조하세요.

애플리케이션 배포

Azure Container Apps를 사용하면 ACR(Azure Container Registry) 또는 Docker Hub와 같은 컨테이너 레지스트리에서 배포할 수 있습니다. Azure Portal, Azure CLI 또는 다른 도구와 같은 도구를 배포에 사용할 수 있습니다. 다음 예제에서는 대상 관리 환경에 my-container-apps애플리케이션을 배포하는 방법을 보여 줍니다. 자세한 내용은 Containerapp을 사용하여 첫 번째 컨테이너 앱 배포 또는 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에서 컨테이너 이미지 빌드의 단계에 따라 애플리케이션을 컨테이너화합니다. 다음 예제와 ENTRYPOINT 같이 Dockerfile에 추가할 -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 옵션 구성을 참조하세요.

스토리지

Azure Spring Apps와 Azure Container Apps는 모두 컨테이너 범위 스토리지를 지원합니다. 즉, 컨테이너가 실행되는 동안에만 컨테이너에 저장된 데이터를 사용할 수 있습니다. Azure Spring Apps의 경우 앱의 총 스토리지는 5GiB입니다. Azure Container Apps는 할당된 총 vCPU 수에 따라 1GiB에서 8GiB까지의 스토리지를 제공합니다. 이 스토리지에는 각 복제본에 할당된 모든 임시 스토리지가 포함됩니다. 자세한 내용은 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 템플릿을 사용하여 구성할 수 있습니다. 자세한 내용은 NFS Azure 파일 공유 및 자습서의 NFS Azure 파일 공유 만들기 섹션을 참조하세요. Azure Portal을 사용하여 NFS Azure 파일 공유를 만들고 Linux VM에 탑재합니다.

관리 ID

각 컨테이너 앱에는 보호된 Azure 리소스에 액세스하기 위해 시스템 할당 관리 ID 또는 사용자 할당 관리 ID가 있습니다. ID를 관리하고 권한을 부여하는 방법을 알아보려면 Azure Container Apps의 관리 ID를 참조 하세요.

각 컨테이너 앱에는 Azure Spring Apps에서 사용되는 엔드포인트와 다른 환경 변수를 통해 IDENTITY_ENDPOINT 액세스할 수 있는 내부 REST 엔드포인트가 있습니다. 앱에서 직접 HTTP GET 요청을 사용하는 경우 코드를 조정하여 올바른 엔드포인트를 가져와야 합니다. 앱이 Azure ID 클라이언트 라이브러리를 통해 관리 ID를 사용하는 경우 Azure Identity가 이 세부 정보를 자동으로 관리하기 때문에 코드 변경이 필요하지 않습니다.

워크로드가 보호된 Azure 리소스에 액세스하는 경우 관리 ID의 애플리케이션 ID 또는 클라이언트 ID를 사용하여 액세스 토큰을 가져와야 합니다. Azure Spring Apps 환경에서 시스템 할당 또는 사용자 할당 관리 ID의 클라이언트 ID를 설정할 수 있습니다. 또는 비워 두고 서비스에서 관리 ID 중 하나에서 애플리케이션 ID를 선택하도록 할 수 있습니다. Azure Container Apps에서는 시스템 할당 관리 ID를 사용할 때 애플리케이션 ID를 명시적으로 지정할 수 없습니다. 그러나 사용자가 할당한 관리 ID를 사용하는 경우 애플리케이션 ID가 필요합니다.

상태 프로브

Azure Container Apps 및 Azure Spring Apps는 모두 시작 프로브, 활동성 프로브 및 준비 상태 프로브를 포함한 세 가지 유형의 상태 프로브를 모두 지원합니다. Azure Container Apps의 경우 프로브는 HTTP 또는 TCP 프로토콜을 사용할 수 있습니다. exec은 아직 지원되지 않습니다.

Azure Spring Apps에서 프로브 설정은 배포 리소스에 구성됩니다. 반면, Azure Container Apps의 경우 프로브 설정은 컨테이너 앱 리소스에 정의됩니다. 다음과 같은 설정을 사용할 수 있습니다.

속성	설명	Azure Spring Apps	Azure Container Apps
`probeAction`	프로브의 동작입니다.	지원 , `TCPSocketAction`및 `ExecAction`.`HTTPGetAction`	작업 유형에 대한 속성이 없습니다. 사용자가 직접 `httpGet` 사용해야 `tcpSocket` 합니다.
`disableProbe`	프로브를 사용할 수 없는지 여부를 나타냅니다.	Boolean	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`	선택적 기간(초)은 프로브 실패 시 Pod가 정상적으로 종료되어야 합니다.	기본값은 90초입니다.	최대값은 3600초입니다.

현재 Azure Portal에서 직접 Azure Container Apps에 대한 프로브를 구성할 수 없습니다. 대신 Azure CLI를 통해 ARM 템플릿 또는 컨테이너 앱 YAML 파일을 사용하여 설정해야 합니다. 자세한 내용은 Azure Container Apps의 상태 프로브를 참조 하세요.

Scale

Azure Container Apps는 크기 조정 규칙 집합을 통한 수평 크기 조정을 지원합니다. 규칙을 추가하거나 변경하면 컨테이너 앱의 새 수정 버전이 만들어집니다.

크기 조정에는 HTTP, TCP 및 사용자 지정의 세 가지 범주가 있습니다. HTTP 및 TCP는 요청 또는 네트워크 연결 수를 기반으로 합니다. 자세한 내용은 Azure Container Apps에서 크기 조정 규칙 설정을 참조하세요.

CPU 또는 메모리에 따라 크기 조정 트리거

사용자 지정 컨테이너 앱 크기 조정 규칙은 ScaledObject 기반 KEDA 스케일러를 기반으로 합니다. KEDA CPU 스케일러 및 메모리 스케일러 를 통해 CPU 또는 메모리 사용량에 따라 컨테이너 앱으로 크기를 조정할 수 있습니다.

다음 예제에서는 평균 메모리 사용량이 25%를 초과할 때 스케일 아웃이 발생하는 구성을 보여 줍니다. 메모리 사용량에는 현재 컨테이너 앱에서 사용하는 메모리와 내부 사이드카 컨테이너와 같은 관련 Pod도 포함됩니다. 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 대한 역할을 할당합니다.

단계

비밀을 추가합니다. 다음 명령을 사용하여 Azure Container Apps에 Microsoft Entra 애플리케이션의 클라이언트 ID 및 비밀을 비밀로 저장합니다.

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 메트릭(예: JvmThreadCountJava 메트릭)에 따라 크기 조정 작업을 트리거합니다.

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 옵션

스토리지

관리 ID

상태 프로브

Scale

CPU 또는 메모리에 따라 크기 조정 트리거

Java 메트릭을 기반으로 크기 조정 트리거

필수 조건

단계

키 세부 정보

피드백

추가 리소스