WebLogic 애플리케이션을 Azure Virtual Machines로 마이그레이션

  • 아티클
  • 읽는 데 36분 걸림

이 가이드에서는 Azure Virtual Machines에서 실행되도록 기존 WebLogic 애플리케이션을 마이그레이션하려는 경우 알아야 할 사항을 설명합니다. Azure Marketplace 사용 가능한 WebLogic Server 솔루션에 대한 개요는 Azure Virtual Machines Oracle WebLogic Server를 실행하기 위한 솔루션은 무엇인가요?를 참조하세요.

사전 마이그레이션

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

"마이그레이션 완료"의 의미를 정의

이 가이드 및 해당 Azure Marketplace 제품은 Azure로 WebLogic Server 워크로드를 신속하게 마이그레이션할 수 있는 시작점입니다. 마이그레이션 작업의 범위를 정의하는 것이 중요합니다. 예를 들어 기존 인프라에서 Azure Virtual Machines로 엄격한 "리프트 앤 시프트"를 수행하려 하시나요? 만약 그렇다면 마이그레이션할 때 "리프트 및 향상"을 수행하고 싶다는 유혹에 빠질 수도 있습니다.

하지만 이 가이드에 설명된 대로 필요한 변경 내용을 고려하여 가능하다면 순수 "리프트 앤 시프트"에 최대한 가깝게 유지하는 것이 좋습니다. 마이그레이션 완료라는 마일스톤에 도달했을 때 그 의미를 알 수 있도록 "마이그레이션 완료"의 의미를 정의합니다. "마이그레이션 완료"에 도달하면 스냅샷 만들기에 설명된 대로 Virtual Machines의 스냅샷을 만들 수 있습니다. 스냅샷에서 성공적으로 복원할 수 있는 것을 확인한 후에는 지금까지 수행한 마이그레이션 진행 상황을 잃지 않고 보다 안전하게 기능을 개선할 수 있습니다.

대상이 마이그레이션 작업에 적합한 대상인지 확인합니다.

WLS 애플리케이션을 Azure로 성공적으로 마이그레이션하는 첫 번째 단계는 가장 적절한 마이그레이션 대상을 선택하는 것입니다. WLS는 Azure VM(가상 머신) 또는 AKS(Azure Kubernetes Service)에서 잘 실행됩니다. VM 대상은 온-프레미스 배포와 가장 유사하기 때문에 가장 쉬운 선택입니다. 가상 머신에 대한 관리 및 배포 환경은 온-프레미스와 매우 유사합니다. 이러한 용이성을 위한 장단분은 경제적 비용입니다. 일반적으로 VM 기반 솔루션의 분당 비용은 AKS에 비해 높습니다. AKS 기반 솔루션은 실행 비용이 적게 들지만 AKS 요구 사항에 맞게 애플리케이션을 제한해야 합니다. 변경을 최소화하는 것이 마이그레이션 작업에 가장 중요한 요소인 경우 VM 기반 마이그레이션을 고려합니다. 이 경우 WebLogic 애플리케이션을 Azure Virtual Machines 마이그레이션을 참조하세요. 런타임 비용을 줄이기 위해 Kubernetes 내에서 실행되도록 애플리케이션을 변환하는 것을 허용할 수 있는 경우 AKS 기반 마이그레이션을 고려합니다. 이 경우 WebLogic Server 애플리케이션을 Azure Kubernetes Service 마이그레이션을 계속합니다.

미리 빌드된 Azure Marketplace 제품이 좋은 시작점인지 확인

Oracle과 Microsoft는 Azure로 마이그레이션하기 위한 견고한 시작점을 제공하기 위해 일련의 Azure 솔루션 템플릿을 Azure Marketplace 위해 파트너로 협력했습니다. Oracle 퓨전 미들웨어 설명서를 참조하여 기존 배포와 가장 일치하는 제품을 선택하세요. Azure 기반 Oracle WebLogic Server란? 개요 문서에서 솔루션 목록을 볼 수 있습니다.

기존 제품 중에 좋은 시작점이 없는 경우 Azure Virtual Machine 리소스를 사용하여 배포를 직접 재현해야 합니다. 자세한 내용은 IaaS란?을 참조하세요.

WebLogic 버전이 호환되는지 확인

기존 WebLogic 버전이 IaaS 제품의 버전과 호환되어야 합니다. 이 쿼리는 WebLogic 버전 12.2.1.3에 대한 제품을 보여줍니다. 기존 WebLogic 버전이 해당 버전과 호환되지 않는 경우 Azure IaaS 리소스를 사용하여 직접 배포를 재현해야 합니다. 자세한 내용은 Azure 설명서를 참조하세요.

서버 용량 인벤토리화

현재 프로덕션 서버의 하드웨어(메모리, CPU, 디스크)와 평균/최대 요청 수 및 리소스 사용량을 문서화합니다. 이 정보를 통해 적절한 VM 크기를 알 수 있습니다. 자세한 내용은 Cloud Services에 적합한 크기를 참조하세요.

모든 비밀 인벤토리화

Azure Key Vault 같은 "서비스로 구성" 기술이 등장하기 전에는 "비밀"에 대한 개념이 잘 정의되지 않았습니다. 그 대신 우리가 현재 "비밀"이라고 부르는 기능을 효율적으로 수행하는 별도의 구성 세트가 있었습니다. WebLogic Server 같은 앱 서버를 사용하는 경우 이러한 비밀이 다양한 구성 파일 및 구성 저장소에 있습니다. 프로덕션 서버의 모든 속성 및 구성 파일에 비밀과 암호가 있는지 확인합니다. WAR에 weblogic.xml 파일이 있는지 확인합니다. 애플리케이션 내에서도 암호 또는 자격 증명을 포함하는 구성 파일을 찾을 수 있습니다. 자세한 내용은 Azure Key Vault 기본 개념을 참조하세요.

모든 인증서 인벤토리화

공용 SSL 엔드포인트에 사용되는 모든 인증서를 문서화합니다. 다음 명령을 실행하여 프로덕션 서버에서 모든 인증서를 볼 수 있습니다.

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

지원되는 Java 버전이 제대로 작동하는지 확인

WebLogic에서 Azure로 마이그레이션하는 모든 경로에는 특정 Java 버전이 필요하며, 필요한 버전은 경로마다 다릅니다. 지원되는 버전을 사용하여 애플리케이션을 올바르게 실행할 수 있는지 확인해야 합니다.

참고

현재 서버를 지원되지 않는 JDK(예: Oracle JDK 또는 IBM OpenJ9)에서 실행하는 경우 이 유효성 검사가 특히 중요합니다.

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

java -version

참고

Azure 가상 머신에서 WLS로 마이그레이션할 때 특정 Java 버전에 대한 요구 사항은 가상 머신에 미리 설치된 Java에 의해 결정됩니다. AKS에서 WLS로 마이그레이션할 때 특정 Java 버전은 선택한 컨테이너 이미지에 의해 결정됩니다. 다양한 선택 사항이 있지만 모두 Oracle JDK를 사용합니다.

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의 유무와 관계없이 다음과 같은 세 가지 옵션이 있습니다.

  • Coherence*Web은 Azure 가상 머신에서 WebLogic Server와 함께 실행할 수 있지만, 제품을 프로비저닝한 후 이 옵션을 수동으로 구성해야 합니다. 독립 실행형 Coherence를 사용하는 경우 Azure 가상 머신에서 실행할 수도 있지만, 제품을 프로비저닝한 후 이 옵션을 수동으로 구성해야 합니다.
  • 세션 관리에 데이터베이스를 사용하도록 애플리케이션을 리팩터링합니다.
  • 세션을 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가 추가되었나요?

REST를 통한 관리를 사용 중인지 확인

애플리케이션의 수명 주기에 REST를 통한 관리 사용이 포함되는 경우 REST API 액세스에 사용되는 포트를 캡처하고 포트의 권한 부여 및 노출 방법을 결정해야 합니다. 마이그레이션 후에는 애플리케이션 수명 주기가 마이그레이션 전과 비슷한 방식으로 작동할 수 있도록 동일한 포트 및 인증 메커니즘을 노출해야 합니다. 자세한 내용은 RESTful Management Services를 사용하여 Oracle WebLogic Server 관리를 참조하세요.

온-프레미스 연결이 필요한지 확인

애플리케이션에서 온-프레미스 서비스에 액세스해야 하는 경우 Azure의 연결 서비스 중 하나를 프로비저닝해야 합니다. 자세한 내용은 온-프레미스 네트워크를 Azure에 연결하기 위한 솔루션 선택을 참조하세요. 또는 온-프레미스 리소스에서 노출하는 공개적으로 사용 가능한 API를 사용하도록 애플리케이션을 리팩터링해야 합니다.

JMS(Java Message Service) 큐 또는 토픽을 사용하는지 확인

애플리케이션에서 JMS 큐 또는 토픽을 사용하는 경우 외부에 호스트되는 JMS 서버로 마이그레이션해야 합니다. Azure Service Bus 및 고급 메시지 큐 프로토콜은 JMS를 사용하는 애플리케이션을 위한 훌륭한 마이그레이션 전략이 될 수 있습니다. 자세한 내용은 Azure Service Bus 및 AMQP 1.0에서 JMS 사용을 참조하세요.

JMS 영구 저장소가 구성된 경우 해당 구성을 캡처하여 마이그레이션 후에 적용해야 합니다.

Oracle Message Broker를 사용하는 경우 이 소프트웨어를 Azure 가상 머신으로 마이그레이션하여 그대로 사용할 수 있습니다.

본인이 직접 만든 사용자 지정 공유 Java EE 라이브러리를 사용하고 있는지 확인

공유 Java EE 라이브러리 기능을 사용하는 경우 다음과 같은 두 가지 옵션이 있습니다.

  • 애플리케이션 코드를 리팩터링하여 라이브러리의 모든 종속성을 제거하고, 그 대신 기능을 애플리케이션에 직접 통합합니다.
  • 서버 클래스 경로에 라이브러리를 추가합니다.

OSGi 번들이 사용되는지 확인

WebLogic 서버에 추가된 OSGi 번들을 사용한 경우에는 동등한 JAR 파일을 웹 애플리케이션에 직접 추가해야 합니다.

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

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

Oracle Service Bus를 사용 중인지 확인

애플리케이션에서 OSB(Oracle Service Bus)를 사용 중인 경우 OSB 구성 방법을 캡처해야 합니다. 자세한 내용은 Oracle Service Bus 설치 정보를 참조하세요.

애플리케이션이 여러 WAR로 구성되었는지 확인

애플리케이션이 여러 WAR로 구성된 경우 각 WAR를 별도의 애플리케이션으로 처리하고 각각에 대해 이 가이드를 수행해야 합니다.

애플리케이션이 EAR로 패키징되는지 확인

애플리케이션이 EAR 파일로 패키징되는 경우 application.xml 및 weblogic-application.xml 파일을 검사하고 해당 구성을 캡처해야 합니다.

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

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

WLST(WebLogic Scripting Tool)가 사용되는지 확인

현재 WLST를 사용하여 배포를 수행하는 경우 WLST가 하는 작업을 평가해야 합니다. WLST가 배포 과정에서 애플리케이션의 (런타임) 매개 변수를 변경하는 경우 마이그레이션 후 애플리케이션을 테스트하는 동안 이 동작이 계속 작동하는지 확인해야 합니다.

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

VM 파일 시스템은 지속성, 시작 및 종료의 측면에서 온-프레미스 파일 시스템과 동일한 방식으로 작동합니다. 그렇다 하더라도, 파일 시스템 요구 사항을 파악하고 VM의 스토리지 크기와 성능이 적절한지 확인해야 합니다.

읽기 전용 정적 콘텐츠

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

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

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

네트워크 토폴로지 결정

현재 Azure Marketplace 제안 집합은 마이그레이션의 시작점입니다. 마이그레이션해야 하는 아키텍처의 특징을 제품에서 지원하지 않는 경우 솔루션 템플릿 중 하나를 사용하여 기본 제품을 설치한 후에라도 기존 배포의 네트워크 토폴로지를 캡처하여 Azure에서 재현해야 합니다.

이 토픽은 매우 광범위한 주제이지만, 다음 참고 자료에서 마이그레이션 작업에 대한 약간의 지침을 얻을 수 있습니다.

  • 이 참조 자료에서는 Azure: 빠른 추적 배포 가이드로 네트워크 토폴로지를 마이그레이션하는 것과 관련된 개략적인 토픽을 열거합니다.
  • 이 참조 자료에서는 네트워크 토폴로지: WebLogic Server 클러스터링에 영향을 미치는 클러스터링과 관련된 중요한 사안을 설명합니다.
  • 데이터 원본은 WebLogic 시스템에 있는 별도의 서버이므로 네트워크 토폴로지 분석의 일부라고 생각해야 합니다. WebLogic Server 데이터 원본
  • 메시징 원본도 별도의 서버입니다. WebLogic Server 메시징
  • 부하 분산은 기본 요구 사항입니다. 이 참고 자료에서는 WebLogic Server 쪽의 부하 분산: 클러스터의 부하 분산에 대해 설명합니다.

JCA 어댑터 및 리소스 어댑터 사용 고려

기존 애플리케이션에서 JCA 어댑터 및/또는 리소스 어댑터를 사용하여 다른 엔터프라이즈 시스템에 연결하는 경우 이러한 아티팩트의 구성이 Azure Virtual Machines에서 실행되는 WebLogic Server에 적용되는지 확인해야 합니다. 자세한 내용은 리소스 어댑터 만들기 및 구성을 참조하세요.

사용자 지정 보안 공급자 및 JAAS 사용 계정

애플리케이션에서 JAAS를 사용하는 경우 보안 공급자의 구성이 올바르게 마이그레이션되었는지 확인해야 합니다. 자세한 내용은 Oracle 설명서의 WebLogic 보안 공급자 구성 정보를 참조하세요.

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

아마도 많은 분들이 고가용성을 얻기 위해 여러 WebLogic 서버에 애플리케이션을 배포하셨을 것입니다. 이러한 클러스터를 온-프레미스 설치에서, Azure Virtual Machines에서 실행되는 WebLogic으로 직접 마이그레이션할 수 있습니다. 자세한 내용은 Oracle 설명서의 도메인 구성 파일을 참조하세요.

부하 분산 요구 사항 고려

부하 분산은 Oracle WebLogic Server 클러스터를 Azure로 마이그레이션할 때 필수적인 과정입니다. 가장 쉬운 방법은 Oracle WebLogic Server 클러스터용 Azure Marketplace 솔루션에 제공되는 Azure Application Gateway에 대한 기본 제공 지원을 사용하는 것입니다. 이 항목에 대한 자습서는 자습서: Azure Application Gateway를 부하 분산 장치로 사용하여 WebLogic Server 클러스터를 Azure로 마이그레이션을 참조하세요.

Azure Application Gateway의 기능을 다른 Azure 부하 분산 솔루션과 비교한 요약 정보는 Azure의 부하 분산 옵션 개요를 참조하세요.

Java EE 애플리케이션 클라이언트 기능이 사용되는지 확인

애플리케이션에서 Java EE 애플리케이션 클라이언트 기능을 사용하는 경우 Azure Virtual Machines로 마이그레이션한 후에도 변경되지 않은 상태로 계속 작동합니다. 자세한 내용은 Java EE 클라이언트 애플리케이션 모듈 사용을 참조하세요.

마이그레이션

Azure Virtual Machines 제품에서 WebLogic 선택

다음은 Azure Virtual Machines에서 WebLogic에 사용할 수 있는 제품입니다.

제품을 배포하는 동안 WebLogic Server 노드에 사용할 Virtual Machine 크기를 선택하라는 메시지가 표시됩니다. VM 크기를 선택할 때 모든 관점(메모리, 프로세서, 디스크)을 고려해야 합니다. 자세한 내용은 가상 머신 규모 조정에 대한 Azure 설명서를 참조하세요.

관리 서버가 없는 WebLogic Server 단일 노드

이 제품은 단일 VM을 만들고 그 VM에 WebLogic을 설치하지만, 도메인을 구성하지는 않습니다. 따라서 고도로 사용자 지정된 도메인 구성이 있는 시나리오에 유용합니다.

관리 서버가 있는 WebLogic Server 단일 노드

이 솔루션은 단일 VM을 프로비저닝하고 거기에 WebLogic Server를 설치합니다. 도메인을 만들고 관리 서버를 시작합니다.

WebLogic Server N-노드 클러스터

이 제품은 고가용성 WebLogic Server VM 클러스터를 만듭니다.

WebLogic Server N-노드 동적 클러스터

이 제품은 확장 가능한 고가용성 WebLogic Server VM 동적 클러스터를 만듭니다.

제품 프로비저닝

시작할 제품을 선택한 후에는 제품 설명서의 지침에 따라 해당 제품을 프로비저닝합니다. 기존 도메인 이름과 일치하는 도메인 이름을 선택해야 합니다. 도메인 암호를 기존 도메인 암호와 매칭할 수도 있습니다.

도메인 마이그레이션

제품을 프로비저닝한 후에는 도메인 구성을 검사하고, 도메인 마이그레이션 방법에 대해 자세히 설명하는 이 지침을 따릅니다.

데이터베이스 연결

도메인을 마이그레이션한 후에는 제품 설명서의 지침에 따라 데이터베이스를 연결할 수 있습니다. 이러한 지침은 관련된 데이터베이스 비밀과 액세스 문자열을 고려하는 데 도움이 됩니다.

KeyStores 계정

애플리케이션에서 사용하는 SSL KeyStores의 마이그레이션을 고려해야 합니다. 자세한 내용은 Keystores 구성을 참조하세요.

JMS 원본 연결

데이터베이스를 연결한 후에는 WebLogic 설명서의 Oracle WebLogic Server용 JMS 리소스를 관리하는 퓨전 미들웨어에 설명된 지침에 따라 JMS를 구성할 수 있습니다.

인증 및 권한 부여 고려

대부분의 애플리케이션에는 일종의 인증 및 권한 부여가 있습니다. 인증에 LDAP를 사용하는 경우 보안 LDAP를 사용하여 Azure Active Directory Domain Services(Azure AD DS)을 설정하고 WebLogic Server에서 LDAP 연결을 구성할 수 있습니다. 자세한 내용은 Azure Active Directory Domain Services 관리되는 도메인 만들기 및 구성 및 Azure Active Directory Domain Services 관리되는 도메인에 대한 보안 LDAP 구성을 참조하세요.

로깅 계정

Oracle WebLogic Server 마켓플레이스 솔루션 템플릿에서 제공하는 Elastic on Azure와의 통합을 사용합니다. 로깅을 처리하는 가장 쉬운 방법입니다. Azure Virtual Machines Oracle WebLogic Server를 실행하기 위한 솔루션은 무엇인가요? 개요 문서에서 제안 목록을 볼 수 있습니다. Elastic을 구성하는 전체 자습서는 다음에서 제공됩니다.

Elastic 통합이 적절하지 않은 경우 도메인을 마이그레이션할 때 기존 로깅 구성을 수행해야 합니다. 자세한 내용은 Oracle 설명서의 java.util.logging 로거 수준 구성 및 Oracle WebLogic Server의 로그 파일 구성 및 로그 메시지 필터링을 참조하세요.

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

개발 팀에서 테스트, 준비 및 프로덕션 서버에 애플리케이션을 배포하는 데 사용되는 기술은 상황에 따라 크게 다릅니다. 애플리케이션이 WebLogic Server에 배포되는 매우 발전된 CI/CD 플랫폼이 사용되는 경우가 있습니다. 그 외의 경우에는 프로세스를 보다 수동적으로 수행할 수 있습니다. Azure Virtual Machines를 사용하여 WebLogic 애플리케이션을 클라우드로 마이그레이션할 때 얻을 수 있는 이점 중 하나는 기존 프로세스가 계속 작동한다는 것입니다.

CI/CD 파이프라인 또는 수동 배포 시스템에서 액세스할 수 있도록 제품에서 프로비저닝되는 네트워크 보안 그룹을 구성해야 합니다. 자세한 내용은 Azure 설명서의 보안 그룹을 참조하세요.

테스트

애플리케이션에 대한 모든 컨테이너 내 테스트는 Azure 내에서 실행되는 새 서버에 액세스하도록 구성해야 합니다. CI/CD와 마찬가지로, 테스트 시 Azure에 배포된 애플리케이션에 액세스할 수 있도록 필요한 네트워크 보안 규칙을 구성해야 합니다. 자세한 내용은 Azure 설명서의 보안 그룹을 참조하세요.

마이그레이션 후 작업

사전 마이그레이션 단계에서 정의한 마이그레이션 목표에 도달한 후에는 엔드투엔드 수용 테스트를 수행하여 모든 것이 예상대로 작동하는지 확인해야 합니다. 다음은 마이그레이션 후 기능 향상에 대한 토픽 중 일부이며, 이 외에도 다른 토픽이 더 있습니다.