Java 애플리케이션을 Azure로 마이그레이션
이 문서에서는 Java 애플리케이션을 Azure로 마이그레이션하기 위한 권장 전략의 개요를 제공합니다.
이 마이그레이션 지침은 Azure 시나리오에서 일반적인 Java를 다루고 높은 수준의 계획 제안 및 고려 사항을 제공하도록 설계되었습니다. Azure 팀의 Microsoft Java와 특정 Java 앱 마이그레이션 시나리오에 대해 논의하려면 다음 설문지를 작성하면 담당자가 문의합니다.
애플리케이션 유형 식별
Java 애플리케이션의 클라우드 대상을 선택하려면 먼저 해당 애플리케이션 유형을 식별해야 합니다. 대부분의 Java 애플리케이션은 다음 유형 중 하나입니다.
- Spring 애플리케이션:
- Java EE 애플리케이션
- 웹 애플리케이션
- 일괄 처리/예약된 작업
이러한 유형에 대해서는 다음 섹션에서 설명합니다.
Spring Boot/JAR 애플리케이션
많은 최신 애플리케이션은 명령줄에서 직접 호출됩니다. 이러한 애플리케이션은 여전히 웹 요청을 처리하지만, HTTP 요청 처리를 제공하기 위해 애플리케이션 서버에 의존하는 대신 HTTP 통신 및 기타 모든 종속성을 애플리케이션 패키지에 직접 통합합니다. 이러한 애플리케이션은 Spring Boot, Dropwizard, Microaut, MicroProfile, Vert.x 등과 같은 프레임워크를 사용하여 빌드되는 경우가 많습니다.
이러한 애플리케이션은 .jar 확장명(JAR 파일)의 보관 파일로 패키지됩니다.
Spring Cloud 미들웨어 모듈을 사용하는 Spring 애플리케이션
마이크로 서비스 아키텍처 스타일은 단일 애플리케이션을 소규모 서비스 제품군으로 개발하는 접근 방식입니다. 각 서비스는 자체 프로세스에서 실행되며 종종 HTTP 리소스 API와 같은 간단한 메커니즘을 사용하여 통신합니다. 이러한 서비스는 비즈니스 기능을 중심으로 구축되며 완전히 자동화된 배포 기계로 독립적으로 배포할 수 있습니다. 이러한 서비스의 최소 중앙 집중식 관리는 다양한 프로그래밍 언어로 작성되고 다른 데이터 스토리지 기술을 사용할 수 있습니다. 이러한 서비스는 Spring Cloud와 같은 프레임워크를 사용하여 자주 빌드됩니다.
이러한 서비스는 .jar 확장명(JAR 파일)의 여러 애플리케이션으로 패키지됩니다.
Java EE 애플리케이션
Java EE 애플리케이션(J2EE 애플리케이션 또는 더 최근에는 Jakarta EE 애플리케이션이라고도 함)에는 웹 애플리케이션의 일부, 전체 또는 전혀 요소가 포함될 수 있습니다. 이러한 애플리케이션은 Jakarta EE 사양에 정의된 대로 더 많은 구성 요소를 포함하고 사용할 수도 있습니다.
Java EE 애플리케이션은 .ear 확장명(EAR 파일)을 사용하여 보관 파일로 패키지하거나 WAR 파일(.war 확장명)을 사용하여 보관 파일로 패키지할 수 있습니다.
Java EE 애플리케이션은 Java EE 규격 애플리케이션 서버(예: Oracle WebLogic Server, IBM WebSphere, JBoss EAP, GlassFish, Payara 등)에 배포해야 합니다.
Java EE 사양에서 제공하는 기능만 사용하는 애플리케이션(즉, 앱 서버 독립 애플리케이션)은 호환되는 애플리케이션 서버에서 다른 애플리케이션 서버로 마이그레이션할 수 있습니다. 애플리케이션이 특정 애플리케이션 서버(앱 서버 종속)에 종속된 경우 해당 애플리케이션 서버를 호스트할 수 있도록 허용하는 Azure 서비스 대상을 선택해야 할 수 있습니다.
웹 애플리케이션
웹 애플리케이션은 Servlet 컨테이너 내에서 실행됩니다. 이러한 애플리케이션 중 일부는 서블릿 API를 직접 사용하는 반면, 많은 애플리케이션은 Apache Struts, Spring MVC, JSF(JavaServer Faces) 등과 같은 서블릿 API를 캡슐화하는 다른 프레임워크를 사용합니다.
웹 애플리케이션은 .war 확장명(WAR 파일)의 보관 파일로 패키지됩니다.
Batch/예약된 작업
일부 애플리케이션은 요청 또는 사용자 입력을 기다리지 않고 잠시 실행하고 특정 워크로드를 실행한 다음 종료하기 위한 것입니다. 경우에 따라 이러한 작업은 예약된 일정 간격으로 한 번 또는 정기적으로 실행되어야 합니다. 온-프레미스에서 이러한 작업은 종종 서버의 crontab에서 호출됩니다.
이러한 애플리케이션은 .jar 확장명(JAR 파일)의 보관 파일로 패키지됩니다.
참고 항목
애플리케이션에서 스케줄러(예: Spring Batch 또는 Quartz)를 사용하여 예약된 작업을 실행하는 경우 이러한 작업을 애플리케이션 외부에서 실행하는 것이 좋습니다. 애플리케이션이 클라우드의 여러 인스턴스로 확장되면 동일한 작업이 두 번 이상 실행됩니다. 또한 예약 메커니즘이 호스트의 로컬 표준 시간대를 사용하는 경우 지역 간에 애플리케이션을 확장할 때 바람직하지 않은 동작이 발생할 수 있습니다.
대상 Azure 서비스 대상 선택
다음 섹션에서는 애플리케이션 요구 사항을 충족하는 서비스 대상과 관련 책임을 보여 줍니다.
호스팅 옵션 그리드
다음 표를 사용하여 애플리케이션 유형에 대한 잠재적인 대상을 식별합니다. 볼 수 있듯이 AKS(Azure Kubernetes Service) 및 Azure Virtual Machines는 모든 애플리케이션 유형을 지원하지만 다음 섹션에 표시된 것처럼 팀이 더 많은 책임을 맡도록 요구합니다.
| 대상 → 응용 프로그램 유형 - |
App 서비스 Java SE |
App 서비스 Tomcat |
App 서비스 JBoss EAP |
Azure Container Apps | AKS | 가상 머신 |
|---|---|---|---|---|---|---|
| Spring Boot/JAR 애플리케이션 | ✔ | ✔ | ✔ | ✔ | ||
| Spring Cloud 애플리케이션 | ✔ | ✔ | ✔ | ✔ | ✔ | |
| 웹 애플리케이션(WAR) | ✔ | ✔ | ✔ | ✔ | ✔ | |
| Java EE 애플리케이션(WAR | EAR) | ✔ | ✔ | ✔ | ✔ | ||
| 상용 애플리케이션 서버 (예: Oracle WebLogic Server 또는 IBM WebSphere) |
✔ | ✔ | ✔ | |||
| 애플리케이션 서버 수준 클러스터링 | ✔ | ✔ | ✔ | |||
| Batch/예약된 작업 | ✔ | ✔ | ✔ | |||
| VNet 통합/하이브리드 연결 | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| Azure 지역 가용성 | 세부 정보 | 세부 정보 | 세부 정보 | 세부 정보 | 세부 정보 | 세부 정보 |
지속적인 책임 표
다음 표를 사용하여 마이그레이션 후 각 대상이 팀에 배치하는 책임을 이해합니다.
표시된 
작업은 전적으로 또는 대부분 Azure에서 관리됩니다. 팀은 다음으로 표시된 👉작업에 대해 지속적으로 책임을 집니다. 이러한 모든 책임을 수행하기 위해 강력하고 고도로 자동화된 프로세스를 구현하는 것이 좋습니다.
참고 항목
이는 완전한 책임 목록이 아닙니다.
| 대상 → 작업 ( ) |
App 서비스 |
Azure 컨테이너 앱 |
AKS | 가상 머신 |
|---|---|---|---|---|
| 라이브러리 업데이트 (취약성 수정 포함) |
👉 | 👉 | 👉 | 👉 |
| 애플리케이션 서버 업데이트 (취약성 수정 포함) |
|
👉 | 👉 | 👉 |
| Java 런타임 업데이트 (취약성 수정 포함) |
|
👉 | 👉 | 👉 |
| Kubernetes 업데이트 트리거 (수동 트리거를 사용하여 Azure에서 수행) |
해당 없음 | |
👉 | 해당 없음 |
| 재해 복구 | |
👉 | 👉 | |
| 이전 버전과 호환되지 않는 Kubernetes API 변경 내용 조정 | 해당 없음 | 👉 | 👉 | 해당 없음 |
| 컨테이너 기본 이미지 업데이트 (취약성 수정 포함) |
해당 없음 | 👉 | 👉 | 해당 없음 |
| 운영 체제 업데이트 (취약성 수정 포함) |
|
|
1 |
👉 |
| 실패한 인스턴스 검색 및 다시 시작 | |
|
|
👉 |
| 업데이트에 대한 드레이닝 및 롤링 다시 시작 구현 | |
|
|
👉 |
| 인프라 관리 | |
👉 | 👉 | 👉 |
| 모니터링 및 경고 관리 | 👉 | 👉 | 👉 | 👉 |
1 일부 보안 업데이트에는 자동으로 수행되지 않는 노드 재부팅이 필요할 수 있습니다. 자세한 내용은 AKS(Azure Kubernetes Service)의 Linux 노드에 보안 및 커널 업데이트 적용을 참조하세요.
애플리케이션의 일부로 서블릿 컨테이너(예: Spring Boot)를 배포하는 경우 라이브러리로 간주해야 하며, 따라서 항상 사용자의 책임입니다.
온-프레미스 연결 보장
애플리케이션에서 온-프레미스 서비스에 액세스해야 하는 경우 Azure의 연결 서비스 중 하나를 프로비저닝해야 합니다. 자세한 내용은 온-프레미스 네트워크를 Azure에 연결을 참조하세요. 또는 온-프레미스 리소스에서 노출하는 공개적으로 사용 가능한 API를 사용하도록 애플리케이션을 리팩터링해야 합니다.
마이그레이션을 시작하기 전에 이 작업을 완료해야 합니다.
현재 용량 및 리소스 사용량 인벤토리
현재 프로덕션 서버의 하드웨어와 평균 및 최대 요청 수 및 리소스 사용량을 문서화합니다. 서비스 대상에서 리소스를 프로비전하려면 이 정보가 필요합니다.
마이그레이션 지침
다음 표를 사용하여 애플리케이션 유형 및 대상 Azure 서비스 대상별 마이그레이션 지침을 찾습니다.
Java 애플리케이션
아래 행을 사용하여 Java 애플리케이션 유형을 찾고, 열을 사용하여 애플리케이션을 호스팅할 Azure 서비스 대상을 찾습니다.
JBoss EAP 앱을 App Service의 Tomcat으로 마이그레이션하려면 먼저 Java EE 앱을 Tomcat에서 실행되는 Java Web Apps(서블릿)로 변환한 다음 아래에 표시된 지침을 따릅니다.
| 대상 → 응용 프로그램 유형 - |
App 서비스 Java SE |
App 서비스 Tomcat |
App 서비스 JBoss EAP |
Azure 컨테이너 앱 |
AKS | 가상 머신 |
|---|---|---|---|---|---|---|
| Spring Boot / JAR 애플리케이션 |
해당 없음 | 해당 없음 | 해당 없음 | 해당 없음 | 해당 없음 | 해당 없음 |
| Spring Cloud / 애플리케이션 |
해당 없음 | 해당 없음 | 해당 없음 | 해당 없음 | 지침 예정 |
지침 예정 |
| 웹 애플리케이션 On Tomcat |
해당 없음 | 지침 | 해당 없음 | 지침 | 지침 | 지침 예정 |
Java EE 애플리케이션
아래 행을 사용하여 특정 앱 서버에서 실행되는 Java EE 애플리케이션 유형을 찾습니다. 열을 사용하여 애플리케이션을 호스트할 Azure 서비스 대상을 찾습니다.
| 대상 → 앱 서버 - |
App 서비스 Java SE |
App 서비스 Tomcat |
App 서비스 JBoss EAP |
Azure 컨테이너 앱 |
AKS | 가상 머신 |
|---|---|---|---|---|---|---|
| WildFly / JBoss AS |
해당 없음 | 해당 없음 | 지침 | 해당 없음 | 지침 | 지침 예정 |
| Oracle WebLogic Server | 해당 없음 | 해당 없음 | 지침 | 해당 없음 | 지침 | 지침 |
| IBM WebSphere | 해당 없음 | 해당 없음 | 지침 | 해당 없음 | 지침 | 지침 예정 |
| Red Hat JBoss EAP | 해당 없음 | 해당 없음 | 지침 | 해당 없음 | 지침 | 지침 |