WebLogic Server 애플리케이션을 Azure 앱 Service의 JBoss EAP로 마이그레이션
이 가이드에서는 JBoss EAP를 사용하여 Azure 앱 Service에서 실행되도록 기존 WebLogic Server 애플리케이션을 마이그레이션하려는 경우 알아야 할 사항에 대해 설명합니다.
사전 마이그레이션
마이그레이션을 성공적으로 수행하려면 시작하기 전에 다음 섹션에서 설명하는 평가 및 인벤토리 단계를 완료합니다.
이러한 마이그레이션 전 요구 사항을 충족할 수 없는 경우 대신 Virtual Machines로 애플리케이션을 마이그레이션하는 도우미 마이그레이션 가이드를 참조하세요. WebLogic Server 애플리케이션을 Azure Virtual Machines로 마이그레이션
서버 용량 인벤토리화
현재 프로덕션 서버의 하드웨어(메모리, CPU, 디스크) 및 평균 및 최대 요청 수 및 리소스 사용률을 문서화합니다. 선택한 마이그레이션 경로에 관계없이 이 정보가 필요합니다. 예를 들어 App Service 계획의 선택을 안내하는 데 유용합니다.
사용 가능한 App Service 계획 계층 목록에는 메모리, CPU 코어, 스토리지 및 가격 책정 정보가 표시됩니다. App Service의 JBoss EAP는 프리미엄 V3 및 격리된 V2 App Service 계획 계층에서만 사용할 수 있습니다.
모든 비밀 인벤토리화
Azure Key Vault와 같은 "서비스로 구성" 기술이 도입되기 전에는 "비밀"이라는 개념이 잘 정의되지 않았습니다. 그 대신 우리가 현재 "비밀"이라고 부르는 기능을 효율적으로 수행하는 별도의 구성 세트가 있었습니다. WebLogic Server와 같은 앱 서버를 사용하면 이러한 비밀은 다양한 구성 파일 및 구성 저장소에 있습니다. 프로덕션 서버의 모든 속성 및 구성 파일에 비밀과 암호가 있는지 확인합니다. WAR에서 weblogic.xml 확인해야 합니다. 애플리케이션 내에서도 암호 또는 자격 증명을 포함하는 구성 파일을 찾을 수 있습니다. 자세한 내용은 Azure Key Vault 기본 개념을 참조 하세요.
모든 인증서 인벤토리화
공용 SSL 엔드포인트에 사용되는 모든 인증서를 문서화합니다. 다음 명령을 실행하여 프로덕션 서버에서 모든 인증서를 볼 수 있습니다.
keytool -list -v -keystore <path to keystore>
JNDI 리소스 인벤토리화
모든 JNDI 리소스를 인벤토리화합니다. 예를 들어 데이터베이스와 같은 데이터 원본에는 JPA가 특정 데이터베이스에 EntityManager 인스턴스를 올바르게 바인딩할 수 있도록 하는 연결된 JNDI 이름이 있을 수 있습니다. JNDI 리소스 및 데이터베이스에 대한 자세한 내용은 Oracle 설명서의 WebLogic Server 데이터 원본을 참조하세요. JMS 메시지 브로커와 같은 다른 JNDI 관련 리소스에는 마이그레이션 또는 재구성이 필요할 수 있습니다. JMS 구성 에 대한 자세한 내용은 Oracle WebLogic Server 12.2.1.4.0을 참조하세요.
도메인 구성 검사
WebLogic Server의 기본 구성 단위는 도메인입니다. 따라서 config.xml 파일에는 마이그레이션을 위해 신중하게 고려해야 하는 다양한 구성이 포함되어 있습니다. 이 파일에는 하위 디렉터리에 저장된 추가 XML 파일의 참조가 포함되어 있습니다. Oracle은 일반적으로 관리 콘솔을 사용하여 WebLogic Server의 관리 가능한 개체 및 서비스를 구성하고 WebLogic Server가 config.xml 파일을 유지 관리할 수 있도록 해야 한다고 조언합니다. 자세한 내용은 도메인 구성 파일을 참조 하세요.
애플리케이션 내부
WEB-INF/weblogic.xml 파일 및/또는 WEB-INF/web.xml 파일을 검사합니다.
세션 복제 사용 여부 확인
애플리케이션이 Oracle Coherence*Web을 사용하거나 사용하지 않고 세션 복제를 사용하는 경우 다음 두 가지 옵션이 있습니다.
- 세션 관리에 데이터베이스를 사용하도록 애플리케이션을 리팩터링합니다.
- Azure Redis Service에 세션을 외부화하도록 애플리케이션을 리팩터링합니다. 자세한 내용은 Azure Cache for Redis를 참조하세요.
이러한 모든 옵션의 경우 WebLogic이 HTTP 세션 상태 복제를 수행하는 방법을 마스터하는 것이 좋습니다. 자세한 내용은 Oracle 설명서의 HTTP 세션 상태 복제를 참조하세요.
문서 데이터 원본
애플리케이션에서 데이터베이스를 사용하는 경우 다음 정보를 캡처해야 합니다.
- 데이터 원본 이름은 무엇인가요?
- 연결 풀 구성이란?
- JDBC 드라이버 JAR 파일은 어디에서 찾을 수 있나요?
WebLogic의 JDBC 드라이버에 대한 자세한 내용은 WebLogic Server에서 JDBC 드라이버 사용을 참조 하세요.
WebLogic이 사용자 지정되었는지 확인
다음 중 어떤 사용자 지정이 수행되었는지 확인하고 수행된 작업을 캡처합니다.
- 시작 스크립트가 변경되었나요? 이러한 스크립트에는 setDomainEnv, commEnv, startWebLogic 및 stopWebLogic이 포함됩니다.
- JVM에 전달된 특정 매개 변수가 있나요?
- 서버 클래스 경로에 JAR이 추가되어 있나요?
온-프레미스 연결이 필요한지 확인
애플리케이션에서 온-프레미스 서비스에 액세스해야 하는 경우 Azure의 연결 서비스 중 하나를 프로비저닝해야 합니다. 자세한 내용은 온-프레미스 네트워크를 Azure에 연결을 참조하세요. 또는 온-프레미스 리소스에서 노출하는 공개적으로 사용 가능한 API를 사용하도록 애플리케이션을 리팩터링해야 합니다.
JMS(Java Message Service) 큐 또는 토픽을 사용하는지 확인
애플리케이션에서 JMS 큐 또는 토픽을 사용하는 경우 외부에서 호스팅되는 JMS 서버로 마이그레이션해야 합니다. Azure Service Bus 및 AMQP(고급 메시지 큐 프로토콜)는 JMS를 사용하는 애플리케이션에 매우 유용한 마이그레이션 전략이 될 수 있습니다. 자세한 내용은 Azure Service Bus 표준 및 AMQP 1.0에서 Java Message Service 1.1 사용을 참조 하세요.
JMS 영구 저장소가 구성된 경우 해당 구성을 캡처하여 마이그레이션 후에 적용해야 합니다.
사용자 지정으로 만든 공유 Java EE 라이브러리를 사용하고 있는지 확인
공유 Java EE 라이브러리 기능을 사용하는 경우 다음과 같은 두 가지 옵션이 있습니다.
- 애플리케이션 코드를 리팩터링하여 라이브러리에 대한 모든 종속성을 제거하고 대신 기능을 애플리케이션에 직접 통합합니다.
- 서버 클래스 경로에 라이브러리를 추가합니다.
OSGi 번들이 사용되는지 확인
WebLogic 서버에 추가된 OSGi 번들을 사용한 경우에는 동등한 JAR 파일을 웹 애플리케이션에 직접 추가해야 합니다.
애플리케이션에 OS 관련 코드가 포함되어 있는지 확인
애플리케이션에 호스트 OS에 대한 종속성이 있는 코드가 포함된 경우 해당 종속성을 제거하려면 리팩터링해야 합니다. 예를 들어 파일 시스템 경로 File.Separator Paths.get 의 / 사용 또는 \ 사용 또는 응용 프로그램이 Windows에서 실행 중인 경우를 바꿔야 할 수 있습니다.
Oracle Service Bus가 사용 중인지 확인
애플리케이션이 OSB(Oracle Service Bus)를 사용하는 경우 OSB가 구성된 방법을 캡처해야 합니다. 자세한 내용은 Oracle Service Bus 설치 정보를 참조하세요.
애플리케이션이 여러 WAR로 구성되었는지 확인
애플리케이션이 여러 WAR로 구성된 경우 각 WAR를 별도의 애플리케이션으로 처리하고 각각에 대해 이 가이드를 수행해야 합니다.
애플리케이션이 EAR로 패키징되는지 확인
애플리케이션이 EAR 파일로 패키지된 경우 application.xml 검사하고 파일을 weblogic-application.xml 해당 구성을 캡처해야 합니다.
프로덕션 서버에서 실행되는 모든 외부 프로세스 및 디먼 확인
디먼 모니터링과 같이 애플리케이션 서버 외부에서 실행되는 프로세스가 있는 경우 이러한 프로세스를 제거하거나 다른 곳으로 마이그레이션해야 합니다.
지원되는 Java 버전이 올바르게 작동하는지 확인
Azure 앱 Service의 JBoss EAP는 Java 8 및 11을 지원합니다. 따라서 지원되는 버전을 사용하여 애플리케이션을 올바르게 실행할 수 있는지 확인해야 합니다. 현재 서버에서 지원되는 JDK(예: Oracle JDK 또는 IBM OpenJ9)를 사용하는 경우 이 유효성 검사가 특히 중요합니다.
현재 Java 버전을 가져오려면 프로덕션 서버에 로그인하고 다음 명령을 실행합니다.
java -version
애플리케이션이 예약된 작업에 의존하는지 확인
Quartz Scheduler 작업 또는 Unix cron 작업과 같은 예약된 작업은 Azure 앱 Service에서 사용하면 안 됩니다. Azure 앱 서비스에서는 예약된 작업이 포함된 애플리케이션을 내부적으로 배포할 수 없습니다. 그러나 애플리케이션이 확장되는 경우 동일한 예약된 작업이 예약된 기간마다 두 번 이상 실행될 수 있습니다. 이 상황은 의도하지 않은 결과를 초래할 수 있습니다.
Azure에서 예약된 작업을 실행하려면 타이머 트리거와 함께 Azure Functions를 사용하는 것이 좋습니다. 자세한 내용은 Azure Functions릐 타이머 트리거를 참조하세요. 작업 코드 자체를 함수로 마이그레이션할 필요가 없습니다. 함수는 애플리케이션에서 URL을 호출하여 작업을 트리거할 수 있습니다.
참고 항목
악의적인 사용을 방지하려면 작업 호출 엔드포인트에 자격 증명이 필요한지 확인해야 할 수 있습니다. 이 경우 트리거 함수는 자격 증명을 제공해야 합니다.
WLST(WebLogic Scripting Tool)가 사용되는지 확인
현재 WLST를 사용하여 배포를 수행하는 경우 수행 중인 작업을 평가해야 합니다. WLST가 배포의 일부로 애플리케이션의 런타임 매개 변수를 변경하는 경우 해당 매개 변수가 다음 옵션 중 하나를 준수하는지 확인해야 합니다.
- 앱 설정으로 외부화됩니다.
- 애플리케이션에 포함됩니다.
- 배포하는 동안 JBoss CLI를 사용합니다.
WLST가 위에서 언급한 것보다 많은 작업을 수행하는 경우 마이그레이션 중에 수행할 몇 가지 추가 작업이 있습니다.
애플리케이션에서 WebLogic 관련 API를 사용하는지 확인
애플리케이션에서 WebLogic 관련 API를 사용하는 경우 애플리케이션을 사용하지 않도록 리팩터링해야 합니다. 예를 들어 Oracle WebLogic Server용 Java API 참조에 언급된 클래스를 사용한 경우 애플리케이션에서 WebLogic 관련 API를 사용했습니다. 앱용 Red Hat 마이그레이션 도구 키트는 이러한 종속성을 제거하고 리팩터링하는 데 도움이 될 수 있습니다.
애플리케이션에서 Entity Beans 또는 EJB 2.x 스타일 CMP Beans를 사용하는지 확인
애플리케이션에서 Entity Beans 또는 EJB 2.x 스타일 CMP 빈을 사용하는 경우 애플리케이션을 사용하지 않도록 리팩터링해야 합니다.
Java EE 애플리케이션 클라이언트 기능이 사용되는지 확인
Java EE 애플리케이션 클라이언트 기능을 사용하여 (서버) 애플리케이션에 연결하는 클라이언트 애플리케이션이 있는 경우 HTTP API를 사용하려면 클라이언트 애플리케이션과 (서버) 애플리케이션을 모두 리팩터링해야 합니다.
배포 계획이 사용되었는지 확인
배포 계획을 사용하여 배포를 수행한 경우 배포 계획이 수행하는 작업을 평가해야 합니다. 배포 계획이 직접 배포인 경우 변경하지 않고 웹 애플리케이션을 배포할 수 있습니다. 배포 계획이 더 정교한 경우 JBoss CLI를 사용하여 배포의 일부로 애플리케이션을 올바르게 구성할 수 있는지 여부를 결정해야 합니다. JBoss CLI를 사용할 수 없는 경우 배포 계획을 더 이상 요구하지 않도록 애플리케이션을 리팩터링해야 합니다.
EJB 타이머가 사용 중인지 확인
애플리케이션에서 EJB 타이머를 사용하는 경우 각 JBoss EAP 인스턴스에서 EJB 타이머 코드를 독립적으로 트리거할 수 있는지 확인해야 합니다. App Service가 수평으로 확장되면 각 EJB 타이머가 자체 JBoss EAP 인스턴스에서 트리거되기 때문에 이 유효성 검사가 필요합니다.
파일 시스템이 사용되는지 및 사용 방법의 유효성을 검사합니다.
애플리케이션 서버에서 파일 시스템을 사용하려면 재구성하거나 드물게 아키텍처 변경이 필요합니다. 파일 시스템은 WebLogic 공유 모듈 또는 애플리케이션 코드에서 사용할 수 있습니다. 다음 시나리오의 일부 또는 전부를 식별할 수 있습니다.
읽기 전용 정적 콘텐츠
애플리케이션이 현재 정적 콘텐츠를 제공하는 경우 해당 정적 콘텐츠의 대체 위치가 필요합니다. 정적 콘텐츠를 Azure Blob Storage로 이동하고 전 세계적으로 빠른 다운로드를 위해 Azure CDN을 추가하는 것이 좋습니다.
동적으로 게시된 정적 콘텐츠
애플리케이션이 애플리케이션에서 업로드/생성되었지만 생성 후 변경할 수 없는 정적 콘텐츠를 허용하는 경우, 위에서 설명한 대로 Azure Blob Storage 및 Azure CDN과 Azure Function을 사용하여 업로드 및 CDN 새로 고침을 처리할 수 있습니다. 사용 시 샘플 구현을 제공했습니다.
동적 또는 내부 콘텐츠
애플리케이션에서 자주 쓰고 읽는 파일(예: 임시 데이터 파일) 또는 애플리케이션에만 표시되는 정적 파일의 경우 Azure Storage를 App Service 파일 시스템에 탑재할 수 있습니다.
JCA 커넥터 사용 여부 확인
애플리케이션에서 JCA 커넥터를 사용하는 경우 JBoss EAP에서 JCA 커넥터를 사용할 수 있는지 확인해야 합니다. JCA 구현이 WebLogic에 연결된 경우 JCA 커넥터를 사용하지 않도록 애플리케이션을 리팩터링해야 합니다. 사용할 수 있는 경우 서버 클래스 경로에 JAR을 추가하고 JBoss EAP 서버 디렉터리의 올바른 위치에 필요한 구성 파일을 배치해야 사용할 수 있습니다.
애플리케이션에서 리소스 어댑터를 사용하는지 확인
애플리케이션에 RA(리소스 어댑터)가 필요한 경우 JBoss EAP와 호환되어야 합니다. RA가 서버에 배포하고 올바르게 구성하여 JBoss EAP의 독립 실행형 인스턴스에서 제대로 작동하는지 확인합니다. RA가 제대로 작동하는 경우 APP Service 인스턴스의 서버 클래스 경로에 JAR을 추가하고 필요한 구성 파일을 JBoss EAP 서버 디렉터리의 올바른 위치에 배치해야 사용할 수 있습니다.
JAAS 사용 여부 확인
애플리케이션이 JAAS를 사용하는 경우 JAAS가 구성된 방법을 캡처해야 합니다. 데이터베이스를 사용하는 경우 JBoss EAP의 JAAS 도메인으로 변환할 수 있습니다. 사용자 지정 구현인 경우 JBoss EAP에서 사용할 수 있는지 확인해야 합니다.
WebLogic 클러스터링이 사용되는지 확인
아마도 많은 분들이 고가용성을 얻기 위해 여러 WebLogic 서버에 애플리케이션을 배포하셨을 것입니다. Azure 앱 Service는 크기를 조정할 수 있지만 WebLogic 클러스터 API를 사용한 경우 해당 API를 사용하지 않도록 코드를 리팩터링해야 합니다.
마이그레이션
앱용 Red Hat 마이그레이션 도구 키트
Red Hat Migration Toolkit for Applications는 Visual Studio Code용 무료 확장입니다. 이 확장은 애플리케이션 코드 및 구성을 분석하여 전용 API에 대한 종속성 제거와 같은 다른 앱 서버에서 JBoss EAP로 Jakarta EE 애플리케이션을 마이그레이션하기 위한 권장 사항을 제공합니다. 또한 확장은 온-프레미스에서 클라우드로 마이그레이션하는 경우 권장 사항을 제공합니다. 자세한 내용은 애플리케이션용 마이그레이션 도구 키트 개요를 참조하세요.
이 가이드의 내용은 올바른 App Service 계획 유형 선택, 세션 상태 외부화 및 Azure를 사용하여 JBoss 관리 인터페이스 대신 EAP 인스턴스를 관리하는 등 마이그레이션 과정의 다른 구성 요소를 해결하는 데 도움이 됩니다.
App Service 계획 프로비저닝
사용 가능한 서비스 계획 목록에서 사양이 현재 프로덕션 하드웨어의 사양을 충족하거나 초과하는 계획을 선택합니다.
참고 항목
스테이징/카나리아 배포를 실행하거나 배포 슬롯을 사용하려는 경우 App Service 계획에 추가 용량이 포함되어야 합니다. Java 애플리케이션에 프리미엄 이상 플랜을 사용하는 것이 좋습니다.
App Service 계획을 만듭니다.
웹앱 만들기 및 배포
JBoss EAP 서버에 배포된 모든 WAR 파일에 대해 App Service 계획에 웹앱을 만들어야 합니다.
참고 항목
여러 WAR 파일을 단일 웹앱에 배포할 수 있지만 매우 바람직하지 않습니다. 여러 WAR 파일을 단일 웹앱에 배포하면 각 애플리케이션의 사용량 요구에 따라 크기가 조정되지 않습니다. 또한 복잡성을 후속 배포 파이프라인에 추가합니다. 단일 URL에서 여러 애플리케이션을 사용할 수 있어야 하는 경우 Azure 애플리케이션 Gateway와 같은 라우팅 솔루션을 사용하는 것이 좋습니다.
Maven 애플리케이션
애플리케이션이 Maven POM 파일에서 빌드된 경우 Maven용 Webapp 플러그 인을 사용하여 웹앱을 만들고 애플리케이션을 배포합니다. 자세한 내용은 빠른 시작의 Maven 플러그 인 구성 섹션을 참조하세요. Azure 앱 Service에서 Java 앱 만들기
Maven이 아닌 애플리케이션
Maven 플러그 인을 사용할 수 없는 경우 다음과 같은 다른 메커니즘을 통해 웹앱을 프로비전해야 합니다.
웹앱을 만든 후 사용 가능한 배포 메커니즘 중 하나를 사용하여 애플리케이션을 배포합니다. 자세한 내용은 App Service에 파일 배포를 참조하세요.
JVM 런타임 옵션 마이그레이션
애플리케이션에 특정 런타임 옵션이 필요한 경우 가장 적절한 메커니즘을 사용하여 지정합니다. 자세한 내용은 Azure 앱 Service용 Java 앱 구성의 Java 런타임 옵션 설정 섹션을 참조하세요.
외부화된 매개 변수 마이그레이션
외부 매개 변수를 사용해야 하는 경우 앱 설정으로 설정해야 합니다. 자세한 내용은 앱 설정 구성을 참조하세요.
시작 스크립트 마이그레이션
원래 애플리케이션에서 사용자 지정 시작 스크립트를 사용한 경우 Bash 스크립트로 마이그레이션해야 합니다. 자세한 내용은 애플리케이션 서버 구성 사용자 지정을 참조하세요.
비밀 채우기
[애플리케이션 설정]을 사용하여 애플리케이션과 관련된 모든 비밀을 저장합니다. 여러 애플리케이션에서 동일한 비밀 또는 비밀을 사용하거나 세분화된 액세스 정책 및 감사 기능이 필요한 경우 Azure Key Vault 참조를 대신 사용합니다. 자세한 내용은 Azure 앱 Service용 Java 앱 구성의 KeyVault 참조 사용 섹션을 참조하세요.
사용자 지정 도메인 및 SSL 구성
애플리케이션이 사용자 지정 도메인에 표시되면 웹 애플리케이션을 이 도메인에 매핑해야 합니다. 자세한 내용은 자습서: 기존 사용자 지정 DNS 이름을 Azure 앱 Service에 매핑을 참조하세요.
그런 다음, 해당 도메인에 대한 TLS/SSL 인증서를 App Service 웹앱에 바인딩해야 합니다. 자세한 내용은 Azure App Service에서 TLS/SSL 바인딩으로 사용자 지정 DNS 이름 보호를 참조하세요.
데이터 원본, 라이브러리 및 JNDI 리소스 마이그레이션
데이터 원본을 마이그레이션하려면 Azure 앱 Service용 Java 앱 구성의 데이터 원본 구성 섹션에 있는 단계를 따릅니다.
Azure 앱 Service용 Java 앱 구성의 JBoss EAP 섹션에 있는 지침에 따라 추가 서버 수준 클래스 경로 종속성을 마이그레이션합니다.
추가 공유 서버 수준 JDNI 리소스를 마이그레이션합니다. 자세한 내용은 Azure 앱 Service용 Java 앱 구성의 JBoss EAP 섹션을 참조하세요.
JCA 커넥터 및 JAAS 모듈 마이그레이션
설치 모듈 및 종속성 지침 에 따라 JCA 커넥터 및 JAAS 모듈을 마이그레이션합니다.
참고 항목
애플리케이션당 하나의 WAR의 권장 아키텍처를 따르는 경우 서버 수준 클래스 경로 라이브러리 및 JNDI 리소스를 애플리케이션으로 마이그레이션하는 것이 좋습니다. 이렇게 하면 구성 요소 거버넌스 및 변경 관리가 크게 간소화됩니다. 애플리케이션당 WAR을 두 개 이상 배포하려는 경우 이 가이드의 시작 부분에 언급된 도우미 가이드 중 하나를 검토해야 합니다.
예약된 작업 마이그레이션
최소한 예약된 작업을 Azure VM으로 이동하여 더 이상 애플리케이션에 속하지 않도록 해야 합니다. 또는 Azure Functions, SQL Database 및 Event Hubs와 같은 Azure 서비스를 사용하여 이벤트 기반 Java로 현대화하도록 선택할 수 있습니다.
다시 시작 및 스모크 테스트
마지막으로 모든 구성 변경 내용을 적용하려면 웹앱을 다시 시작해야 합니다. 다시 시작이 완료되면 애플리케이션이 올바르게 실행되고 있는지 확인합니다.
마이그레이션 후
이제 애플리케이션을 Azure 앱 Service로 마이그레이션했으므로 예상대로 작동하는지 확인해야 합니다. 이렇게 하면 애플리케이션을 클라우드 네이티브로 만들 수 있는 몇 가지 권장 사항이 있습니다.
권장 사항
파일 스토리지에 /home 디렉터리를 사용하도록 선택한 경우 Azure Storage로 바꾸는 것이 좋습니다. 자세한 내용은 App Service의 사용자 지정 컨테이너에서 로컬 공유로 Azure Storage 탑재를 참조 하세요.
/home 디렉터리에 연결 문자열, SSL 키 및 기타 비밀 정보를 포함하는 구성이 있는 경우 가능한 경우 애플리케이션 설정과 함께 Azure Key Vault 및 매개 변수 삽입의 조합을 사용하는 것이 좋습니다. 자세한 내용은 App Service 및 Azure Functions 에 대한 Key Vault 참조 사용 및 App Service 앱 구성을 참조하세요.
가동 중지 시간이 없는 안정적인 배포를 위해 배포 슬롯을 사용하는 것이 좋습니다. 자세한 내용은 Azure 앱 Service에서 스테이징 환경 설정을 참조하세요.
DevOps 전략을 설계하고 구현합니다. 개발 속도를 높이는 동시에 안정성을 유지하기 위해 Azure Pipelines를 사용하여 배포를 자동화하고 테스트하는 것이 좋습니다. 자세한 내용은 Java 웹앱에 빌드 및 배포를 참조 하세요. 배포 슬롯을 사용하는 경우 슬롯 및 후속 슬롯 교환에 대한 배포를 자동화할 수 있습니다. 자세한 내용은 예제: Azure Pipelines를 사용하여 App Service에 배포의 슬롯 섹션에 배포를 참조하세요.
비즈니스 연속성 및 재해 복구 전략을 설계하고 구현합니다. 중요 업무용 애플리케이션의 경우 다중 지역 배포 아키텍처를 고려하세요. 자세한 내용은 고가용성 다중 지역 웹 애플리케이션을 참조 하세요.