Spring Boot 애플리케이션을 Azure Spring Cloud로 마이그레이션

이 가이드에서는 Azure Spring Cloud에서 실행할 기존 Spring Boot 애플리케이션을 마이그레이션하려는 경우에 알아야 할 사항을 설명합니다.

사전 마이그레이션

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

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

  • 실행 가능한 JAR 애플리케이션을 Azure Kubernetes Service의 컨테이너로 마이그레이션(계획된 지침)
  • 실행 가능한 JAR 애플리케이션을 Azure Virtual Machines로 마이그레이션(계획된 지침)

애플리케이션 구성 요소 검사

로컬 상태 식별

PaaS 환경에서는 어떤 애플리케이션도 지정된 시간에 정확히 한 번만 실행된다고 보장할 수 없습니다. 단일 인스턴스에서 실행되도록 애플리케이션을 구성하더라도 다음과 같은 경우에는 중복 인스턴스를 만들 수 있습니다.

  • 오류 또는 시스템 업데이트 때문에 애플리케이션을 물리적 호스트에 재배치해야 합니다.
  • 애플리케이션을 업데이트하는 중입니다.

이러한 경우에는 새 인스턴스가 완전히 시작될 때까지 원래 인스턴스가 계속 실행됩니다. 이로 인해 애플리케이션에 다음과 같은 중대한 영향을 미칠 수 있습니다.

  • 싱글톤이 진짜 단일 항목이라고 보장할 수 없습니다.
  • 외부 스토리지에 보관되지 않은 데이터는 단일 물리적 서버 또는 VM에 보관될 때보다 훨씬 빠르게 손실될 가능성이 높습니다.

Azure Spring Cloud로 마이그레이션하기 전에, 손실 또는 중복되면 안 되는 로컬 상태가 코드에 포함되지 않도록 확인해야 합니다. 로컬 상태가 있는 경우 해당 상태를 애플리케이션 외부에 저장하도록 코드를 변경하세요. 클라우드 지원 애플리케이션은 일반적으로 다음과 같은 위치에 애플리케이션 상태를 저장합니다.

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

서비스가 로컬 파일 시스템에서 쓰거나 읽는 인스턴스를 찾습니다. 단기/임시 파일을 쓰고 읽는 위치와 수명이 긴 파일을 쓰고 읽는 위치를 확인합니다.

참고

Azure Spring Cloud는 /tmp에 탑재된 Azure Spring Cloud 인스턴스당 5GB의 임시 스토리지를 제공합니다. 임시 파일이 이 제한을 초과하거나 다른 위치에 쓰이는 경우 코드를 변경해야 합니다.

읽기 전용 정적 콘텐츠

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

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

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

서비스 중에서 OS 관련 코드가 포함된 서비스가 있는지 확인

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

지원되는 플랫폼으로 전환

Azure Spring Cloud는 특정 버전의 Java 및 특정 버전의 Spring Boot 및 Spring Cloud를 제공합니다. 호환성을 보장하려면 먼저 애플리케이션을 현재 환경에서 지원되는 Java 버전 중 하나로 마이그레이션한 다음, 나머지 마이그레이션 단계를 진행합니다. 결과 구성을 완전히 테스트해야 합니다. 테스트에서 Linux 배포판의 안정적인 최신 릴리스를 사용하세요.

참고

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

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

java -version

지원되는 Java, Spring Boot 및 Spring Cloud 버전 및 업데이트 지침은 Azure Spring Cloud에서 배포용 Java Spring 애플리케이션 준비를 참조하세요.

Spring Boot 버전 확인

마이그레이션되는 각 애플리케이션의 종속성을 검사하여 해당 Spring Boot 버전을 확인합니다.

Maven

Maven 프로젝트에서 Spring Boot 버전은 일반적으로 POM 파일의 <parent> 요소에 있습니다.

    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.2.6.RELEASE</version>
        <relativePath/> <!-- lookup parent from repository -->
    </parent>
Gradle

Gradle 프로젝트에서 Spring Boot 버전은 일반적으로 plugins 섹션에서 org.springframework.boot 플러그 인의 버전으로 찾을 수 있습니다.

plugins {
  id 'org.springframework.boot' version '2.2.6.RELEASE'
  id 'io.spring.dependency-management' version '1.0.9.RELEASE'
  id 'java'
}

Spring Boot 1.x를 사용하는 애플리케이션의 경우 Spring Boot 2.0 마이그레이션 가이드에 따라 지원되는 Spring Boot 버전으로 업데이트합니다. 지원되는 버전은 배포용 Java Spring 앱 준비를 참조하세요.

로그 집계 솔루션 확인

마이그레이션하는 애플리케이션에서 사용 중인 로그 집계 솔루션을 확인합니다.

APM(애플리케이션 성능 관리) 에이전트 확인

애플리케이션에서 사용 중인 애플리케이션 성능 모니터링 에이전트(예: Dynatrace 및 Datadog)를 확인합니다. 이러한 에이전트를 대신하여 Azure Spring Cloud는 Azure Monitor와 긴밀하게 통합하여 성능 관리와 이상 상황에 대한 실시간 응답을 제공합니다. 자세한 내용은 마이그레이션 후를 참조하세요.

인벤토리 외부 리소스

데이터 원본, JMS 메시지 브로커, 다른 서비스의 URL 등과 같은 외부 리소스를 확인합니다. Spring Boot 애플리케이션에서 이러한 리소스의 구성은 일반적으로 src/main/directory 폴더의 application.properties 또는 application.yml 이라는 파일에서 찾을 수 있습니다.

데이터베이스

SQL 데이터베이스의 연결 문자열을 확인합니다.

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 메시지 broker

관련 종속성에 대한 빌드 매니페스트(일반적으로 pom.xml 또는 build.gradle 파일)를 검토하여 사용 중인 broker를 확인합니다.

예를 들어 ActiveMQ를 사용하는 Spring Boot 애플리케이션은 일반적으로 이 종속성을 pom.xml 파일에 포함합니다.

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-activemq</artifactId>
</dependency>

독점적 브로커를 사용하는 Spring Boot 애플리케이션은 일반적으로 브로커의 JMS 드라이버 라이브러리에 직접 종속성을 포함하고 있습니다. 다음은 build.gradle 파일의 예제입니다.

    dependencies {
      ...
      compile("com.ibm.mq:com.ibm.mq.allclient:9.0.4.0")
      ...
    }

사용 중인 broker가 확인되면 해당 설정을 찾습니다. Spring Boot 애플리케이션에서 이러한 설정은 일반적으로 애플리케이션 디렉터리의 application.propertiesapplication.yml 파일에서 찾을 수 있습니다.

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=tryandguess

ActiveMQ 구성에 대한 자세한 내용은 Spring Boot 메시징 설명서를 참조하세요.

application.yaml 파일의 IBM MQ 예제는 다음과 같습니다.

ibm:
  mq:
    queueManager: qm1
    channel: dev.ORDERS
    connName: localhost(14)
    user: admin
    password: big$ecr3t

IBM MQ 구성에 대한 자세한 내용은 IBM MQ Spring 구성 요소 설명서를 참조하세요.

외부 캐시 확인

사용 중인 외부 캐시를 확인합니다. Redis는 Spring Data Redis를 통해 자주 사용됩니다. 구성 정보는 Spring Data Redis 설명서를 참조하세요.

Java 또는 XML에서 각 구성을 검색하여 Spring Session을 통해 세션 데이터가 캐시되는지 여부를 확인합니다.

ID 공급자

애플리케이션에서 사용하는 모든 ID 공급자를 식별합니다. ID 공급자를 구성하는 방법에 대한 자세한 내용은 다음을 참조하세요.

비표준 포트를 사용하는 클라이언트 식별

Azure Spring Cloud는 배포된 애플리케이션의 server.port 설정을 덮어씁니다. 클라이언트가 443이 아닌 다른 포트에 제공되는 애플리케이션을 사용하는 경우 수정이 필요합니다.

기타 모든 외부 리소스

이 가이드에서 가능한 모든 외부 종속성을 문서화할 수는 없습니다. 마이그레이션 후에 사용자가 애플리케이션의 모든 외부 종속성이 충족될 수 있는지 확인해야 합니다.

인벤토리 구성 원본 및 비밀

인벤토리 암호 및 보안 문자열

프로덕션 배포의 모든 속성 및 구성 파일과 모든 환경 변수에 비밀 문자열과 암호가 있는지 확인합니다. Spring Boot 애플리케이션에서 이러한 문자열은 일반적으로 application.properties 또는 application.yml 파일에서 찾을 수 있습니다.

인증서 인벤토리화

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

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

배포 아키텍처 검사

각 서비스에 대한 하드웨어 요구 사항 문서화

Spring Boot 애플리케이션에 대한 다음 정보를 문서화합니다.

  • 실행되는 인스턴스 수
  • 각 인스턴스에 할당되는 CPU 수
  • 각 인스턴스에 할당되는 RAM 양

지역 복제/배포 문서화

Spring Boot 애플리케이션 인스턴스가 현재 여러 지역 또는 데이터 센터 간에 분산되어 있는지 확인합니다. 마이그레이션하는 애플리케이션의 가동 시간 요구 사항/SLA를 문서화합니다.

마이그레이션

Azure Spring Cloud 인스턴스 및 앱 만들기

Azure 구독에 아직 Azure Spring Cloud 인스턴스가 없다면 지금 프로비저닝합니다. 그런 다음, 애플리케이션 템플릿을 만듭니다. 자세한 내용은 빠른 시작: Azure Portal을 사용하여 기존 Azure Spring Cloud 애플리케이션 시작의 지침을 따릅니다.

콘솔 로깅 확인 및 진단 설정 구성

모든 출력이 파일이 아닌 콘솔로 라우팅되도록 로깅을 구성합니다.

애플리케이션이 Azure Spring Cloud에 배포되면 진단 설정을 추가하여 기록된(예: Azure Monitor Log Analytics를 통해) 이벤트를 사용할 수 있도록 합니다.

LogStash/ELK Stack

LogStash/ELK Stack을 로그 집계에 사용하는 경우 콘솔 출력을 Azure Event Hub로 스트림하도록 진단 설정을 구성합니다. 그런 다음, LogStash EventHub 플러그 인을 사용하여 기록된 이벤트를 LogStash에 수집합니다.

Splunk

Splunk를 로그 집계에 사용하는 경우 콘솔 출력을 Azure Blob Storage로 스트림하도록 진단 설정을 구성합니다. 그런 다음, Microsoft Cloud Services용 Splunk 추가 기능을 사용하여 기록된 이벤트를 Splunk에 수집합니다.

영구 스토리지 구성

애플리케이션의 일부에서 로컬 파일 시스템을 읽거나 쓰는 경우 로컬 파일 시스템을 바꾸도록 영구 스토리지를 구성해야 합니다. 자세한 내용은 Azure Spring Cloud에서 영구 스토리지 사용을 참조하세요.

임시 파일은 /tmp 디렉터리에 써야 합니다. OS 독립성을 위해 System.getProperty("java.io.tmpdir")를 사용하여 이 디렉터리를 가져올 수 있습니다. 또한 java.nio.Files::createTempFile을 사용하여 임시 파일을 만들 수도 있습니다.

모든 인증서를 KeyVault로 마이그레이션

Azure Spring Cloud는 JRE 키 저장소에 대한 액세스를 제공하지 않으므로 인증서를 Azure KeyVault로 마이그레이션하고 KeyVault의 인증서에 액세스하도록 애플리케이션 코드를 변경해야 합니다. 자세한 내용은 Key Vault 인증서 시작Java용 Azure Key Vault 인증서 클라이언트 라이브러리를 참조하세요.

APM(애플리케이션 성능 관리) 통합 제거

APM 도구/에이전트와의 통합을 제거합니다. Azure Monitor를 사용하여 성능 관리를 구성하는 방법에 대한 자세한 내용은 마이그레이션 후 섹션을 참조하세요.

애플리케이션에서 메트릭 클라이언트 및 엔드포인트 사용 안 함

사용된 메트릭 클라이언트 또는 애플리케이션에 공개된 메트릭 엔드포인트를 모두 제거합니다.

애플리케이션 배포

마이그레이션된 각 마이크로서비스(Spring Cloud Config 및 Registry 서버는 제외)를 배포합니다. 자세한 지침은 빠른 시작: Azure Portal을 사용하여 기존 Azure Spring Cloud 애플리케이션 시작을 참조하세요.

서비스별 비밀 및 외부화된 설정 구성

서비스별 구성 설정을 환경 변수로 각 서비스에 주입할 수 있습니다. Azure Portal에서 다음 단계를 사용합니다.

  1. Azure Spring Cloud 인스턴스로 이동하여 Apps(앱) 를 선택합니다.
  2. 구성할 서비스를 선택합니다.
  3. Configuration(구성) 을 선택합니다.
  4. 구성할 변수를 입력합니다.
  5. 저장 을 선택합니다.

Spring Cloud 앱 구성 설정

ID 공급자 마이그레이션 및 사용

Spring Cloud 애플리케이션 중에서 인증 또는 권한 부여가 필요한 애플리케이션이 있는 경우 ID 공급자에 액세스하도록 구성되어 있는지 확인합니다.

  • ID 공급자가 Azure Active Directory인 경우 변경할 필요가 없습니다.
  • ID 공급자가 온-프레미스 Active Directory 포리스트인 경우 Azure Active Directory를 사용하여 하이브리드 ID 솔루션을 구현하는 것이 좋습니다. 자세한 내용은 하이브리드 ID 설명서를 참조하세요.
  • ID 공급자가 다른 온-프레미스 솔루션(예: PingFederate)인 경우 Azure AD Connect 설치 사용자 지정 항목을 참조하여 Azure Active Directory와 페더레이션하도록 구성합니다. 또는 Spring Security를 사용하여 OAuth2/OpenID Connect 또는 SAML을 통해 ID 공급자를 사용하는 것이 좋습니다.

애플리케이션 공개

기본적으로 Azure Spring Cloud에 배포된 애플리케이션은 외부에서 볼 수 없습니다. 다음 명령을 사용하여 애플리케이션을 공개로 설정하면 애플리케이션을 공개할 수 있습니다.

az spring-cloud app update -n <application name> --is-public true

Spring Cloud 게이트웨이를 사용 중이거나 사용할 생각이라면 이 단계를 건너뜁니다(자세한 내용은 다음 섹션에서 설명).

마이그레이션 후 작업

마이그레이션을 완료했으므로, 애플리케이션이 예상대로 작동하는지 확인합니다. 그 후에는 다음 권장 사항에 따라 애플리케이션을 클라우드 네이티브로 만들 수 있습니다.

  • 애플리케이션이 Spring Cloud Registry에서 작동하도록 설정하는 방안을 고려해 보세요. 이렇게 하면 배포된 다른 마이크로서비스 및 클라이언트에서 애플리케이션을 동적으로 검색할 수 있습니다. 자세한 내용은 자습서: 배포할 Java Spring 앱 준비 그런 다음, Spring 클라이언트 부하 분산 장치를 사용하도록 애플리케이션 클라이언트를 수정합니다. 이렇게 하면 클라이언트는 실행 중인 모든 애플리케이션 인스턴스의 주소를 가져오고, 다른 인스턴스가 손상되거나 응답하지 않을 때 작동하는 인스턴스를 찾을 수 있습니다. 자세한 내용은 Spring 블로그의 Spring 팁: Spring Cloud Load Balancer를 참조하세요.

  • 애플리케이션을 공개로 설정하는 대신 Spring Cloud Gateway 인스턴스를 추가하는 것이 좋습니다. Spring Cloud Gateway는 Azure Spring Cloud 인스턴스에 배포된 모든 애플리케이션/마이크로서비스에 대한 단일 엔드포인트를 제공합니다. Spring Cloud Gateway가 이미 배포된 경우에는 새로 배포된 애플리케이션으로 트래픽을 라우팅하도록 구성해야 합니다.

  • Spring Cloud Config 서버를 추가하여 모든 Spring Cloud 마이크로서비스의 구성을 중앙에서 관리하고 버전을 제어하는 것이 좋습니다. 먼저 구성을 저장할 Git 리포지토리를 만들고 이 구성을 사용하도록 Azure Spring Cloud 인스턴스를 구성합니다. 자세한 내용은 자습서: 서비스용 Spring Cloud Config 서버 인스턴스 설정을 참조하세요. 그 후에는 다음 단계에 따라 구성을 마이그레이션합니다.

    1. 애플리케이션의 src/main/resources 디렉터리 내에 다음 콘텐츠가 포함된 bootstrap.yml 파일을 만듭니다.

        spring:
          application:
            name: <your-application-name>
      
    2. 구성 Git 리포지토리에서 <your-application-name>.yml 파일을 만듭니다. 여기서 your-application-name은 이전 단계와 동일합니다. src/main/resources 에서 application.yml 파일의 설정을 방금 만든 새 파일로 이동합니다. 설정이 이전에 .properties 파일에 있었으면 먼저 YAML로 변환합니다. 온라인 도구 또는 IntelliJ 플러그인을 찾아서 이 변환을 수행할 수 있습니다.

    3. 위의 디렉터리에 application.yml 파일을 만듭니다. 이 파일을 사용하여 Azure Spring Cloud 인스턴스의 모든 애플리케이션 간에 공유되는 설정과 리소스를 정의할 수 있습니다. 이러한 항목에는 일반적으로 데이터 원본, 로깅 설정, Spring Boot Actuator 구성 등이 포함됩니다.

    4. 변경 내용을 Git 리포지토리에 커밋하고 푸시합니다.

    5. 애플리케이션에서 application.properties 또는 application.yml 파일을 제거합니다.

  • 일관된 자동 배포를 위해 배포 파이프라인을 추가하는 것이 좋습니다. Azure Pipelines, GitHub ActionsJenkins에 대한 지침을 사용할 수 있습니다.

  • 일부 또는 모든 최종 사용자가 사용할 수 있기 전에 스테이징 배포를 사용하여 프로덕션 환경에서 코드 변경을 테스트하는 것이 좋습니다. 자세한 내용은 Azure Spring Cloud에서 스테이징 환경 설정을 참조하세요.

  • 서비스 바인딩을 추가하여 애플리케이션을 지원되는 Azure 데이터베이스에 연결하는 것이 좋습니다. 이러한 서비스 바인딩을 사용하면 자격 증명을 포함한 연결 정보를 Spring Cloud 애플리케이션에 제공할 필요가 없습니다.

  • 분산 추적 및 Azure App Insights를 사용하여 애플리케이션의 성능과 상호 작용을 모니터링하는 것이 좋습니다. 자세한 내용은 Azure Spring Cloud에서 분산 추적 사용을 참조하세요.

  • Azure Monitor 경고 규칙 및 작업 그룹을 추가하여 이상 상태를 빠르게 검색하여 처리하는 것이 좋습니다. 자세한 내용은 자습서: 경고 및 작업 그룹을 사용하여 Spring Cloud 리소스 모니터링을 참조하세요.

  • Azure Spring Cloud 배포를 다른 지역에 복제하여 대기 시간을 줄이고 안정성과 내결함성을 높이는 것이 좋습니다. Azure Traffic Manager를 사용하여 배포 간의 부하를 분산하거나 Azure Front Door를 사용하여 DDoS 보호가 있는 SSL 오프로딩 및 웹 애플리케이션 방화벽을 추가합니다.

  • 지역 복제가 필요하지 않은 경우 Azure Application Gateway를 추가하여 DDoS 보호가 있는 SSL 오프로딩 및 웹 애플리케이션 방화벽을 추가합니다.