이 가이드에서는 기존 Spring Boot 애플리케이션을 Azure App Service로 마이그레이션할 때 알아야 할 사항에 대해 설명합니다.
마이그레이션 전
마이그레이션을 성공적으로 수행하려면 시작하기 전에 다음 섹션에서 설명하는 평가 및 인벤토리 단계를 완료합니다.
지원되는 플랫폼으로 전환
App Service는 특정 버전의 Java SE를 제공합니다. 호환성을 보장하려면 나머지 단계를 계속하기 전에 애플리케이션을 현재 환경의 지원되는 버전 중 하나로 마이그레이션합니다. 결과 구성을 완전히 테스트해야 합니다. 이러한 테스트에서 Linux 배포판의 안정적인 최신 릴리스를 사용합니다.
비고
이 유효성 검사는 현재 서버가 지원되지 않는 JDK(예: Oracle JDK 또는 IBM OpenJ9)에서 실행 중인 경우에 특히 중요합니다.
현재 Java 버전을 가져오려면 프로덕션 서버에 로그인하고 다음 명령을 실행합니다.
java -version
Azure 앱 서비스에서 Java 8에 대한 이진 파일은 Eclipse Temurin에서 제공됩니다. Java 11, 17 및 Java의 모든 향후 LTS 릴리스의 경우 App Service는 Microsoft Build of OpenJDK를 제공합니다. 이러한 이진 파일은 다음 사이트에서 무료로 다운로드할 수 있습니다.
인벤토리 외부 리소스
데이터 원본, JMS 메시지 브로커 및 다른 서비스의 URL과 같은 외부 리소스를 식별합니다. Spring Boot 애플리케이션에서는 일반적으로 application.properties 또는 application.yml 파일의 src/main/directory 폴더에서 이러한 리소스에 대한 구성을 찾을 수 있습니다. 또한 프로덕션 배포의 환경 변수에서 관련 구성 설정을 확인합니다.
데이터베이스
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 파일)를 확인하여 사용 중인 broker 또는 broker를 식별합니다.
예를 들어 ActiveMQ를 사용하는 Spring Boot 애플리케이션은 일반적으로 pom.xml 파일에 이 종속성을 포함합니다.
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-activemq</artifactId>
</dependency>
상업용 브로커를 사용하는 Spring Boot 애플리케이션은 일반적으로 broker의 JMS 드라이버 라이브러리에 직접 종속성을 포함합니다. build.gradle 파일의 예제는 다음과 같습니다.
dependencies {
...
compile("com.ibm.mq:com.ibm.mq.allclient:9.4.0.5")
...
}
사용 중인 broker 또는 broker를 식별한 후 해당 설정을 찾습니다. Spring Boot 애플리케이션에서 이러한 설정은 일반적으로 애플리케이션 디렉터리의 application.properties 및 application.yml 파일에서 찾을 수 있습니다.
비고
사용 가능한 가장 안전한 인증 흐름을 사용하는 것이 권장됩니다. 데이터베이스, 캐시, 메시징 또는 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 지침을 참조 하세요.
기타 모든 외부 리소스
이 가이드에서 가능한 모든 외부 종속성을 문서화하는 것은 불가능합니다. App Service 마이그레이션 후에 애플리케이션의 모든 외부 종속성을 충족할 수 있는지 확인하는 것은 팀의 책임입니다.
인벤토리 비밀
암호 및 보안 문자열
모든 비밀 문자열 및 암호는 프로덕션 배포의 모든 속성 및 구성 파일 및 모든 환경 변수를 확인합니다. Spring Boot 애플리케이션에서 이러한 문자열은 application.properties 또는 application.yml 찾을 수 있습니다.
인증서 인벤토리화
공용 SSL 엔드포인트 또는 백 엔드 데이터베이스 및 기타 시스템과의 통신에 사용되는 모든 인증서를 문서화합니다. 다음 명령을 실행하여 프로덕션 서버에서 모든 인증서를 볼 수 있습니다.
keytool -list -v -keystore <path to keystore>
파일 시스템의 사용 여부 및 방법 확인
애플리케이션 서버에서 파일 시스템을 사용하려면 재구성하거나 드물게 아키텍처 변경이 필요합니다. 다음 시나리오의 일부 또는 전부를 식별할 수 있습니다.
읽기 전용 정적 콘텐츠
애플리케이션이 현재 정적 콘텐츠를 제공하는 경우 대체 위치가 필요합니다. 정적 콘텐츠를 Azure Blob Storage로 이동하고 전 세계적으로 빠른 다운로드를 위해 Azure Front Door를 추가하는 것이 좋습니다. 자세한 내용은 Azure Storage의 Static 웹사이트 호스팅 및 Azure Front Door와 Azure Storage 계정 통합을 참조하세요.
특수 사례
특정 프로덕션 시나리오에는 추가 변경이 필요하거나 추가 제한 사항이 있을 수 있습니다. 이러한 시나리오는 드물지만 애플리케이션에 적용할 수 없거나 올바르게 해결되었는지 확인하는 것이 중요합니다.
애플리케이션이 예약된 작업에 의존하는지 여부 확인
Quartz 스케줄러 작업 또는 cron 작업과 같은 예약된 작업은 App Service에서 사용할 수 없습니다. App Service는 예약된 작업이 포함된 애플리케이션을 내부적으로 배포하는 것을 방지하지 않습니다. 그러나 애플리케이션이 확장되는 경우 동일한 예약된 작업이 예약된 기간마다 두 번 이상 실행될 수 있습니다. 이 상황은 의도하지 않은 결과를 초래할 수 있습니다.
애플리케이션 프로세스 내부 또는 외부에서 예약된 작업을 인벤토리로 작성합니다.
애플리케이션에 OS 관련 코드가 포함되어 있는지 확인
애플리케이션에 호스트 OS에 대한 종속성이 있는 코드가 포함된 경우 해당 종속성을 제거하려면 리팩터링해야 합니다. 예를 들어 파일 시스템 경로 File.Separator
Paths.get
의 /
사용 또는 \
사용 또는 응용 프로그램이 Windows에서 실행 중인 경우를 바꿔야 할 수 있습니다.
프로덕션 서버에서 실행되는 모든 외부 프로세스/디먼 식별
애플리케이션 서버 외부에서 실행되는 프로세스(예: 디먼 모니터링)는 다른 곳으로 마이그레이션하거나 제거해야 합니다.
HTTP가 아닌 요청 또는 여러 포트의 처리 식별
App Service는 단일 포트에서 단일 HTTP 엔드포인트만 지원합니다. 애플리케이션이 여러 포트에서 수신 대기하거나 HTTP 이외의 프로토콜을 사용하여 요청을 수락하는 경우 Azure App Service를 사용하지 마세요.
마이그레이션
구성 매개 변수화
모든 외부 리소스 좌표(예: 데이터베이스 연결 문자열) 및 기타 사용자 지정 가능한 설정을 환경 변수에서 읽을 수 있는지 확인합니다. Spring Boot 애플리케이션을 마이그레이션하는 경우 모든 구성 설정을 이미 외부화할 수 있어야 합니다. 자세한 내용은 Spring Boot 설명서의 외부화된 구성 을 참조하세요.
application.properties 파일에서 환경 변수를 SERVICEBUS_CONNECTION_STRING
참조하는 예제는 다음과 같습니다.
spring.jms.servicebus.connection-string=${SERVICEBUS_CONNECTION_STRING}
spring.jms.servicebus.topic-client-id=contoso1
spring.jms.servicebus.idle-timeout=10000
App Service 계획 구성
사용 가능한 서비스 계획 목록에서 사양이 현재 프로덕션 하드웨어의 사양을 충족하거나 초과하는 계획을 선택합니다.
비고
스테이징/카나리아 배포를 실행하거나 배포 슬롯을 사용하려는 경우 App Service 계획에 추가 용량이 포함되어야 합니다. Java 애플리케이션에 프리미엄 이상 플랜을 사용하는 것이 좋습니다.
App Service 계획을 만듭니다.
웹앱 만들기 및 배포
실행하려는 모든 실행 JAR 파일에 대해 App Service 계획에서 웹앱을 만들어야 합니다(런타임 스택으로 "Java SE"를 선택).
Maven 애플리케이션
애플리케이션이 Maven POM 파일에서 빌드된 경우 Maven용 Webapp 플러그 인을 사용하여 웹앱을 만들고 애플리케이션을 배포합니다. 자세한 내용은 빠른 시작: Azure 앱 Service에서 Java 앱 만들기를 참조하세요.
Maven이 아닌 애플리케이션
Maven 플러그 인을 사용할 수 없는 경우 다음과 같은 다른 메커니즘을 통해 웹앱을 프로비전해야 합니다.
Web App이 만들어지면 사용 가능한 배포 메커니즘 중 하나를 사용하여 애플리케이션을 배포합니다. 가능하면 애플리케이션을 /home/site/wwwroot/app.jar 업로드해야 합니다. JAR 이름을 app.jar로 바꾸고 싶지 않다면 JAR을 실행하는 명령을 가진 셸 스크립트를 업로드할 수 있습니다. 그런 다음 포털의 구성 섹션에 있는 시작 파일 텍스트 상자에 이 스크립트의 전체 경로를 붙여넣습니다. 시작 스크립트는 배치된 디렉터리에서 실행되지 않습니다. 따라서 항상 절대 경로를 사용하여 시작 스크립트의 파일을 참조해야 합니다(예: java -jar /home/myapp/myapp.jar
).
JVM 런타임 옵션 마이그레이션
애플리케이션에 특정 런타임 옵션이 필요한 경우 가장 적절한 메커니즘을 사용하여 지정합니다.
사용자 지정 도메인 및 SSL 구성
애플리케이션이 사용자 지정 도메인에 표시되면 웹 애플리케이션을 이 도메인에 매핑해야 합니다. 자세한 내용은 자습서: 기존 사용자 지정 DNS 이름을 Azure 앱 Service에 매핑을 참조하세요.
그런 다음, 해당 도메인에 대한 SSL 인증서를 App Service 웹앱에 바인딩해야 합니다. 자세한 내용은 Azure 앱 Service에서 SSL 바인딩을 사용하여 사용자 지정 DNS 이름 보안을 참조하세요.
백 엔드 인증서 가져오기
데이터베이스와 같은 백 엔드 시스템과 통신하기 위한 모든 인증서를 App Service에서 사용할 수 있도록 설정해야 합니다. 자세한 내용은 App Service에서 SSL 인증서 추가를 참조 하세요.
외부 리소스 좌표 및 기타 설정 마이그레이션
다음 단계에 따라 연결 문자열 및 기타 설정을 마이그레이션합니다.
비고
구성 매개 변수화 섹션의 변수로 매개 변수가 있는 Spring Boot 애플리케이션 설정의 경우 해당 환경 변수를 애플리케이션 구성에 정의해야 합니다. 환경 변수로 명시적으로 매개 변수화되지 않은 Spring Boot 애플리케이션 설정은 애플리케이션 구성을 통해 계속 재정의할 수 있습니다. 다음은 그 예입니다.
spring.jms.servicebus.connection-string=${CUSTOMCONNSTR_SERVICE_BUS}
spring.jms.servicebus.topic-client-id=contoso1
spring.jms.servicebus.idle-timeout=1800000
예약된 작업 마이그레이션
Azure에서 예약된 작업을 실행하려면 Azure Functions에 타이머 트리거를 사용하는 것이 좋습니다. 작업 코드 자체를 함수로 마이그레이션할 필요가 없습니다. 함수는 애플리케이션에서 URL을 호출하여 작업을 트리거할 수 있습니다. 이러한 작업 실행을 동적으로 호출하고/하거나 중앙에서 추적해야 하는 경우 Spring Batch를 사용하는 방안을 고려해보세요.
또는 애플리케이션 외부에 코드를 작성하지 않고 URL을 호출하는 되풀이 트리거를 사용하여 논리 앱을 만들 수 있습니다. 자세한 내용은 개요 - Azure Logic Apps란? 및 Azure Logic Apps에서 되풀이 트리거를 사용하여 되풀이 작업 및 워크플로 만들기, 예약 및 실행을 참조하세요.
비고
악의적인 사용을 방지하려면 작업 호출 엔드포인트에 자격 증명이 필요한지 확인해야 할 수 있습니다. 이 경우 트리거 함수는 자격 증명을 제공해야 합니다.
ID 공급자 마이그레이션 및 사용
애플리케이션에 인증 또는 권한 부여가 필요한 경우 다음 지침을 사용하여 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 앱 Service로 마이그레이션했으므로 예상대로 작동하는지 확인해야 합니다. 작업이 완료되면 애플리케이션을 클라우드 네이티브로 만들 수 있는 몇 가지 권장 사항이 있습니다.
권장 사항
파일 스토리지에 /home 디렉터리를 사용하도록 선택한 경우 Azure Storage로 바꾸는 것이 좋습니다.
연결 문자열, SSL 키 및 기타 비밀 정보를 포함하는 /home 디렉터리에 구성이 있는 경우 가능한 경우 애플리케이션 설정과 함께 Azure Key Vault 및/또는 매개 변수 삽입을 사용하는 것이 좋습니다.
가동 중지 시간이 0인 안정적인 배포에 배포 슬롯을 사용하는 것이 좋습니다.
DevOps 전략을 설계하고 구현합니다. 개발 속도를 높이면서 안정성을 유지하려면 Azure Pipelines를 사용하여 배포 및 테스트를 자동화하는 것이 좋습니다. 배포 슬롯을 사용하는 경우 슬롯에 대한 배포를 자동화한 다음 슬롯 교환을 수행할 수 있습니다.
비즈니스 연속성 및 재해 복구 전략을 설계하고 구현합니다. 중요 업무용 애플리케이션의 경우 다중 지역 배포 아키텍처를 고려하세요.