다음을 통해 공유

Tomcat 애플리케이션을 Azure App Service의 Tomcat으로 마이그레이션

  • 아티클

이 가이드에서는 Tomcat 9.0을 사용하여 Azure 앱 서비스에서 실행되도록 기존 Tomcat 애플리케이션을 마이그레이션하려는 경우 알아야 할 사항에 대해 설명합니다.

사전 마이그레이션

마이그레이션을 성공적으로 수행하려면 시작하기 전에 다음 섹션에서 설명하는 평가 및 인벤토리 단계를 완료합니다.

이러한 마이그레이션 전 요구 사항 중에서 충족할 수 없는 요구 사항이 있는 경우 다음 마이그레이션 관련 가이드를 참조하세요.

지원되는 플랫폼으로 전환

App Service는 특정 버전의 Java에서 특정 버전의 Tomcat을 제공합니다. 호환성을 보장하려면 나머지 단계를 계속하기 전에 현재 환경에서 지원되는 Tomcat 및 Java 버전 중 하나로 애플리케이션을 마이그레이션합니다. 결과 구성을 완전히 테스트해야 합니다. 이러한 테스트에서 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를 제공합니다. 이러한 이진 파일은 다음 사이트에서 무료로 다운로드할 수 있습니다.

현재 Tomcat 버전을 가져오려면 프로덕션 서버에 로그인하고 다음 명령을 실행합니다.

${CATALINA_HOME}/bin/version.sh

Azure 앱 서비스에서 사용하는 현재 버전을 가져오려면 Azure 앱 서비스에서 사용하려는 버전에 따라 Tomcat 9를 다운로드합니다.

인벤토리 외부 리소스

데이터 원본, JMS 메시지 브로커 등과 같은 외부 리소스는 JNDI(Java 명명 및 디렉터리 인터페이스)를 통해 삽입됩니다. 이러한 리소스 중 일부는 마이그레이션 또는 재구성이 필요할 수 있습니다.

애플리케이션 내부

META-INF/context.xml 파일을 검사합니다. <Context> 요소 내에서 <Resource> 요소를 찾습니다.

애플리케이션 서버에서

$CATALINA_BASE/conf/context.xml 및 $CATALINA_BASE/conf/server.xml 파일과 $CATALINA_BASE/conf/[engine-name]/[host-name] 디렉터리에 있는 .xml 파일을 검사합니다.

context.xml 파일에서 JNDI 리소스는 최상위 <Context> 요소 내의 <Resource> 요소에 의해 설명됩니다.

server.xml 파일에서 JNDI 리소스는 <GlobalNamingResources> 요소 내의 <Resource> 요소로 설명됩니다.

Datasources

데이터 원본은 특성이 type .로 설정된 javax.sql.DataSourceJNDI 리소스입니다. 각 데이터 원본에 대해 다음 정보를 문서화합니다.

  • 데이터 원본 이름은 무엇인가요?
  • 연결 풀 구성이란?
  • JDBC 드라이버 JAR 파일은 어디에서 찾을 수 있나요?

자세한 내용은 Tomcat 설명서의 JNDI Datasource HOW-TO를 참조하세요.

기타 모든 외부 리소스

이 가이드에서 가능한 모든 외부 종속성을 문서화하는 것은 불가능합니다. 마이그레이션 후 애플리케이션의 모든 외부 종속성을 충족할 수 있는지 확인하는 것은 팀의 책임입니다.

인벤토리 비밀

암호 및 보안 문자열

프로덕션 서버의 모든 속성 및 구성 파일에서 비밀 문자열 및 암호를 확인합니다. $CATALINA_BASE/conf에서 server.xml 및 context.xml 확인해야 합니다. 애플리케이션 내에서 암호 또는 자격 증명을 포함하는 구성 파일을 찾을 수도 있습니다. 여기에는 META-INF/context.xml 및 Spring Boot 애플리케이션, application.properties 또는 application.yml 파일이 포함될 수 있습니다.

인증서 인벤토리화

공용 SSL 엔드포인트 또는 백 엔드 데이터베이스 및 기타 시스템과의 통신에 사용되는 모든 인증서를 문서화합니다. 다음 명령을 실행하여 프로덕션 서버에서 모든 인증서를 볼 수 있습니다.

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

파일 시스템의 사용 여부 및 방법 확인

애플리케이션 서버에서 파일 시스템을 사용하려면 재구성하거나 드물게 아키텍처 변경이 필요합니다. 다음 시나리오의 일부 또는 전부를 식별할 수 있습니다.

읽기 전용 정적 콘텐츠

애플리케이션에서 현재 정적 콘텐츠를 제공하는 경우 이를 대체할 위치가 필요합니다. 정적 콘텐츠를 Azure Blob Storage로 이동하고 전역적으로 빠른 다운로드를 위해 Azure CDN을 추가하는 것이 좋습니다. 자세한 내용은 Azure Storage에서 정적 웹 사이트 호스팅 및 빠른 시작: Azure CDN과 Azure Storage 계정 통합을 참조하세요.

동적으로 게시된 정적 콘텐츠

애플리케이션이 애플리케이션에서 업로드/생성되었지만 생성 후 변경할 수 없는 정적 콘텐츠를 허용하는 경우, 위에서 설명한 대로 Azure Blob Storage 및 Azure CDN과 Azure Function을 사용하여 업로드 및 CDN 새로 고침을 처리할 수 있습니다. Azure Functions를 사용하여 정적 콘텐츠 업로드 및 CDN 사전 로드에서 사용할 샘플 구현을 제공했습니다.

동적 또는 내부 콘텐츠

애플리케이션에서 자주 쓰고 읽는 파일(예: 임시 데이터 파일) 또는 애플리케이션에만 표시되는 정적 파일의 경우 Azure Storage를 App Service 파일 시스템에 탑재할 수 있습니다. 자세한 내용은 App Service에서 로컬 공유로 Azure Storage 탑재를 참조 하세요.

세션 지속성 메커니즘 식별

사용 중인 세션 지속성 관리자를 식별하려면 애플리케이션 및 Tomcat 구성에서 context.xml 파일을 검사합니다. <Manager> 요소를 찾은 다음, className 특성의 값을 확인합니다.

StandardManager 또는 FileStore와 같은 Tomcat의 기본 제공 PersistentManager 구현은 App Service와 같은 분산된 확장 플랫폼에서 사용하도록 설계되지 않았습니다. App Service는 여러 인스턴스 간에 부하를 분산하고 언제든지 인스턴스를 투명하게 다시 시작할 수 있으므로 변경 가능한 상태를 파일 시스템에 유지하지 않는 것이 좋습니다.

세션 지속성이 필요한 경우 외부 데이터 저장소에 쓰는 대체 PersistentManager 구현(예: Redis Cache를 사용하는 VMware Tanzu 세션 관리자)을 사용해야 합니다. 자세한 내용은 Tomcat을 사용하여 Redis를 세션 캐시로 사용을 참조하세요.

프로덕션 서버에서 실행되는 모든 외부 프로세스 및 디먼 확인

디먼 모니터링과 같이 애플리케이션 서버 외부에서 실행되는 프로세스가 있는 경우 이러한 프로세스를 제거하거나 다른 곳으로 마이그레이션해야 합니다.

특별 케이스

특정 프로덕션 시나리오에는 추가 변경이 필요하거나 추가 제한 사항이 있을 수 있습니다. 이러한 시나리오는 드물지만 애플리케이션에 적용할 수 없거나 올바르게 해결되었는지 확인하는 것이 중요합니다.

애플리케이션이 예약된 작업에 의존하는지 여부 확인

Quartz 스케줄러 작업 또는 cron 작업과 같은 예약된 작업은 App Service에서 사용할 수 없습니다. App Service는 예약된 작업이 포함된 애플리케이션을 내부적으로 배포하는 것을 방지하지 않습니다. 그러나 애플리케이션이 확장되는 경우 동일한 예약된 작업이 예약된 기간마다 두 번 이상 실행될 수 있습니다. 이 상황은 의도하지 않은 결과를 초래할 수 있습니다.

애플리케이션 서버 내부 또는 외부에서 예약된 작업을 인벤토리로 작성합니다.

애플리케이션에 OS 관련 코드가 포함되어 있는지 확인

애플리케이션에 호스트 OS에 대한 종속성이 있는 코드가 포함된 경우 해당 종속성을 제거하려면 리팩터링해야 합니다. 예를 들어 파일 시스템 경로 File.Separator Paths.get 의 / 사용 또는 \ 사용 또는 응용 프로그램이 Windows에서 실행 중인 경우를 바꿔야 할 수 있습니다.

Tomcat 클러스터링이 사용되는지 확인

Tomcat 클러스터링이 Azure 앱 서비스에서 지원되지 않습니다. 대신 Tomcat 특정 기능 없이 Azure App Service를 통해 크기 조정 및 부하 분산을 구성하고 관리할 수 있습니다. 복제본에서 사용할 수 있도록 세션 상태를 대체 위치로 유지할 수 있습니다. 자세한 내용은 세션 지속성 메커니즘 식별을 참조 하세요.

애플리케이션에서 클러스터링을 사용하는지 여부를 확인하려면 server.xml 파일의 요소 또는 <Engine> 내부 <Host> 요소를 찾 <Cluster> 습니다.

비 HTTP 커넥터 사용 여부 확인

App Service는 단일 HTTP 커넥터만 지원합니다. 애플리케이션에 AJP 커넥터와 같은 추가 커넥터가 필요한 경우 App Service를 사용하지 마세요.

애플리케이션에서 사용하는 HTTP 커넥터를 식별하려면 Tomcat 구성에서 server.xml 파일 내의 요소를 찾 <Connector> 습니다.

MemoryRealm 사용 여부 확인

MemoryRealm 에는 지속형 XML 파일이 필요합니다. Azure 앱Service에서 이 파일을 /home 디렉터리 또는 해당 하위 디렉터리 중 하나에 업로드하거나 탑재된 스토리지에 업로드해야 합니다. 그런 다음 그에 따라 매개 변수를 pathName 수정해야 합니다.

현재 사용되는지 여부를 MemoryRealm 확인하려면 server.xml 검사하고 파일을 context.xml 특성이 className 설정된 요소를 검색 <Realm> 합니다org.apache.catalina.realm.MemoryRealm.

SSL 세션 추적 사용 여부 확인

App Service는 Tomcat 런타임 외부에서 세션 오프로드를 수행하므로 SSL 세션 추적을 사용할 수 없습니다. 대신 다른 세션 추적 모드(COOKIE 또는 URL)를 사용합니다. SSL 세션 추적이 필요한 경우 App Service를 사용하지 마세요.

AccessLogValve 사용 여부 확인

AccessLogValve를 사용하는 경우 directory 매개 변수를 /home/LogFiles 또는 해당 하위 디렉터리 중 하나로 설정해야 합니다.

마이그레이션

구성 매개 변수화

마이그레이션 전 단계에서는 server.xml 및 context.xml 파일에서 데이터 원본과 같은 일부 비밀 및 외부 종속성을 식별했을 수 있습니다. 식별한 각 항목에 대해 사용자 이름, 암호, 연결 문자열 또는 URL을 환경 변수로 대체합니다.

참고 항목

사용 가능한 가장 안전한 인증 흐름을 사용하는 것이 권장됩니다. 데이터베이스, 캐시, 메시징 또는 AI 서비스와 같이 이 절차에서 설명하는 인증 흐름은 애플리케이션에 대한 신뢰 수준이 매우 높고 다른 흐름에 존재하지 않는 위험을 수반합니다. 암호 없는 연결 또는 키 없는 연결에 대한 관리 ID와 같은 더 안전한 옵션이 실행 가능하지 않은 경우에만 이 흐름을 사용합니다. 로컬 컴퓨터 작업의 경우 암호 없는 연결이나 키 없는 연결에 사용자 ID를 사용하는 것이 좋습니다.

예를 들어 context.xml 파일에 다음 요소가 포함되어 있다고 가정합니다.

<Resource
    name="jdbc/dbconnection"
    type="javax.sql.DataSource"
    url="jdbc:postgresql://postgresdb.contoso.com/wickedsecret?ssl=true"
    driverClassName="org.postgresql.Driver"
    username="postgres"
    password="{password}"
/>

이 경우 다음 예제와 같이 변경할 수 있습니다.

<Resource
    name="jdbc/dbconnection"
    type="javax.sql.DataSource"
    url="${postgresdb.connectionString}"
    driverClassName="org.postgresql.Driver"
    username="${postgresdb.username}"
    password="${postgresdb.password}"
/>

배포된 .war 파일 내의 META-INF 폴더 내의 모든 context.xml 파일에 대해 매개 변수 대체가 발생하도록 하려면 다음 예제와 같이 환경 변수를 설정 CATALINA_OPTS 해야 합니다.

export CATALINA_OPTS="-Dorg.apache.tomcat.util.digester.PROPERTY_SOURCE=org.apache.tomcat.util.digester.EnvironmentPropertySource"

App Service 계획 프로비저닝

App Service 가격 책정의 사용 가능한 서비스 계획 목록에서 사양이 현재 프로덕션 하드웨어의 사양을 충족하거나 초과하는 계획을 선택합니다.

참고 항목

스테이징/카나리아 배포를 실행하거나 배포 슬롯을 사용하려는 경우 App Service 계획에 추가 용량이 포함되어야 합니다. Java 애플리케이션에 프리미엄 이상 플랜을 사용하는 것이 좋습니다. 자세한 내용은 Azure 앱 Service에서 스테이징 환경 설정을 참조하세요.

그런 다음 App Service 계획을 만듭니다. 자세한 내용은 Azure에서 App Service 계획 관리를 참조하세요.

웹앱 만들기 및 배포

Tomcat 서버에 배포된 모든 WAR 파일에 대해 App Service 계획에서 웹앱을 만들어야 합니다(Tomcat 버전을 런타임 스택으로 선택).

참고 항목

여러 WAR 파일을 단일 웹앱에 배포할 수 있지만 매우 바람직하지 않습니다. 여러 WAR 파일을 단일 웹앱에 배포하면 각 애플리케이션의 사용량 요구에 따라 크기가 조정되지 않습니다. 또한 복잡성을 후속 배포 파이프라인에 추가합니다. 단일 URL에서 여러 애플리케이션을 사용할 수 있어야 하는 경우 Azure 애플리케이션 Gateway와 같은 라우팅 솔루션을 사용하는 것이 좋습니다.

Maven 애플리케이션

애플리케이션이 Maven POM 파일 에서 빌드된 경우 Maven 용 Webapp 플러그 인을 사용하여 웹앱을 만들고 애플리케이션을 배포합니다.

Maven이 아닌 애플리케이션

Maven 플러그 인을 사용할 수 없는 경우 다음과 같은 다른 메커니즘을 통해 웹앱을 프로비전해야 합니다.

Web App이 만들어지면 사용 가능한 배포 메커니즘 중 하나를 사용하여 애플리케이션을 배포합니다.

JVM 런타임 옵션 마이그레이션

애플리케이션에 특정 런타임 옵션이 필요한 경우 가장 적절한 메커니즘을 사용하여 지정합니다.

비밀 채우기

[애플리케이션 설정]을 사용하여 애플리케이션과 관련된 모든 비밀을 저장합니다. 여러 애플리케이션에서 동일한 비밀을 사용하거나 세분화된 액세스 정책 및 감사 기능이 필요한 경우 Azure Key Vault를 대신 사용합니다.

사용자 지정 도메인 및 SSL 구성

애플리케이션이 사용자 지정 도메인에 표시되면 웹 애플리케이션을 이 도메인에 매핑해야 합니다. 자세한 내용은 자습서: 기존 사용자 지정 DNS 이름을 Azure 앱 Service에 매핑을 참조하세요.

그런 다음, 해당 도메인에 대한 SSL 인증서를 App Service 웹앱에 바인딩해야 합니다. 자세한 내용은 Azure 앱 Service에서 SSL 바인딩을 사용하여 사용자 지정 DNS 이름 보안을 참조하세요.

백 엔드 인증서 가져오기

데이터베이스와 같은 백 엔드 시스템과 통신하기 위한 모든 인증서를 App Service에서 사용할 수 있도록 설정해야 합니다. 자세한 내용은 App Service에서 SSL 인증서 추가를 참조 하세요.

데이터 원본, 라이브러리 및 JNDI 리소스 마이그레이션

데이터 원본 구성 단계는 Azure 앱 Service용 Linux Java 앱 구성의 데이터 원본 섹션을 참조하세요.

추가 데이터 원본 지침은 Tomcat 설명서의 JNDI Datasource 방법 의 다음 섹션을 참조하세요.

데이터 원본 JAR 파일과 동일한 단계를 수행하여 추가 서버 수준 클래스 경로 종속성을 마이그레이션합니다.

추가 공유 서버 수준 JDNI 리소스를 마이그레이션합니다.

참고 항목

웹앱당 하나의 WAR의 권장 아키텍처를 따르는 경우 서버 수준 클래스 경로 라이브러리 및 JNDI 리소스를 애플리케이션으로 마이그레이션하는 것이 좋습니다. 이렇게 하면 구성 요소 거버넌스 및 변경 관리가 크게 간소화됩니다.

나머지 구성 마이그레이션

이전 섹션을 완료하면 /home/tomcat/conf에 사용자 지정 가능한 서버 구성이 있어야 합니다.

추가 구성(예: 영역 및 JASPIC)을 복사하여 마이그레이션 완료

예약된 작업 마이그레이션

Azure에서 예약된 작업을 실행하려면 Azure Functions에 타이머 트리거를 사용하는 것이 좋습니다. 작업 코드 자체를 함수로 마이그레이션할 필요가 없습니다. 함수는 애플리케이션에서 URL을 호출하여 작업을 트리거할 수 있습니다. 이러한 작업 실행을 동적으로 호출하고/하거나 중앙에서 추적해야 하는 경우 Spring Batch를 사용하는 방안을 고려해보세요.

또는 애플리케이션 외부에 코드를 작성하지 않고 URL을 호출하는 되풀이 트리거를 사용하여 논리 앱을 만들 수 있습니다. 자세한 내용은 개요 - Azure Logic Apps란? 및 Azure Logic Apps에서 되풀이 트리거를 사용하여 되풀이 작업 및 워크플로 만들기, 예약 및 실행을 참조하세요.

참고 항목

악의적인 사용을 방지하려면 작업 호출 엔드포인트에 자격 증명이 필요한지 확인해야 할 수 있습니다. 이 경우 트리거 함수는 자격 증명을 제공해야 합니다.

다시 시작 및 스모크 테스트

마지막으로 모든 구성 변경 내용을 적용하려면 웹앱을 다시 시작해야 합니다. 다시 시작이 완료되면 애플리케이션이 올바르게 실행되고 있는지 확인합니다.

마이그레이션 후

이제 애플리케이션을 Azure 앱 Service로 마이그레이션했으므로 예상대로 작동하는지 확인해야 합니다. 이 작업이 완료되면 애플리케이션을 클라우드 네이티브로 만들 수 있는 몇 가지 추천 사항이 있습니다.

권장 사항