Anthos를 사용한 자바 애플리케이션 현대화: 사용자 가이드

Last reviewed 2020-06-30 UTC

이 문서에서는 Anthos를 사용하여 기존 모놀리식 자바 애플리케이션을 현대화하는 프로세스, 권장사항, 도구를 간략하게 설명합니다.

이 문서는 CTO, CIO, 엔터프라이즈 아키텍트, 애플리케이션 개발자, IT 보안 관리자, 애플리케이션 개발자, DevOps팀, 사이트 안정성 엔지니어링(SRE)팀을 대상으로 합니다. 컨테이너화와 이에 대한 운영 및 개발상의 이점에 대한 기본 지식을 알고 있다고 가정합니다.

이 문서에서는 현대화에 대한 2단계 접근 방식을 제안합니다.

  1. 컨데이터화. 이 단계에서는 적절한 후보 애플리케이션을 컨테이너화하고 Anthos 플랫폼(온프레미스 또는 Google Cloud)에 배포합니다. 이 단계에서는 Migrate to Containers, 최신 지속적 통합/지속적 배포(CI/CD) 사례, 시스템 통합 도구와 같은 다양한 서비스와 기술을 사용합니다.
  2. 리팩터링 및 플랫폼 변경. 시간이 지남에 따라 기존 모놀리식 애플리케이션을 Spring Boot와 같은 최신 자바 프레임워크 및 마이크로서비스로 리팩터링하고 플랫폼을 변경합니다.

이 문서에서는 이러한 각 단계를 안내하고 리소스를 제공합니다. 또한 엔터프라이즈를 가상 머신(VM)에 보관하려는 경우를 위한 대체 경로를 제공합니다.

현대화 사례

많은 조직에서는 비즈니스 애플리케이션을 계속 실행하는 동시에 혁신을 시도하기 위해 노력하고 있습니다. 개발팀과 운영팀은 애플리케이션 서비스의 새로운 수요를 충족하는 동시에 기존 애플리케이션 포트폴리오를 유지, 운영, 개선해야 합니다.

이 새로운 수요는 디지털 비즈니스 이니셔티브와 기존 기능을 개선하기 위한 디지털 혁신의 목표에서 나옵니다. 하지만 Gartner 보고서(멀티플랫폼 애플리케이션 현대화 비즈니스 구축 사례, 2019년 11월)에 따르면 현재 애플리케이션의 90%가 2025년까지 계속 사용됩니다. 이러한 애플리케이션을 지원하고 관리하기 위한 기술적 채무는 계속 증가하여 현재 IT 예산의 40% 이상을 소비하게 될 것이라고 합니다.

기업은 새로운 애플리케이션을 개발하고 채택하지만 대부분의 애플리케이션은 여전히 기존의 모놀리식 애플리케이션입니다. 이러한 많은 기존 애플리케이션은 IBM WebSphere 또는 Oracle® WebLogic과 같은 독점적 상업용 애플리케이션 서버에서 실행됩니다. 이러한 애플리케이션은 대게 최적화, 유지, 관리가 잘 되고 있으므로 기업이 이를 혁신하는 것은 쉽지 않습니다. 또한 독점적인 애플리케이션 서버로 인해 운영 오버헤드가 늘어날 수 있으며 대부분의 경우 비경제적인 라이선스 계약이 요구될 수 있습니다.

여러 연구에 따르면 조직은 기존 애플리케이션 코드를 다시 작성하는 대신 기존 애플리케이션을 현대화하여 시간과 비용을 절약할 수 있습니다. 기존 애플리케이션을 현대화하는 모든 전략은 현대화 시간과 비용을 둘 다 줄이는 데 집중해야 합니다.

최신 애플리케이션

최신 애플리케이션을 사용하면 고객에게 더 나은 환경을 제공하여 고객 유지율과 만족도를 높여 수익성을 향상시킬 수 있습니다. 최신 애플리케이션 및 플랫폼 개발 원칙은 디지털 혁신과 함께 제공되는 이점을 강조합니다. 다음 섹션에서는 이러한 원칙을 설명합니다.

개발자 및 운영자 생산성 향상

기존 애플리케이션은 보통 모놀리식 애플리케이션입니다. 이러한 애플리케이션에는 여러 기능을 수행하는 대형 코드베이스가 있습니다. 애플리케이션, 개발팀, 관리팀이 동시에 성장하면서 새 기능을 신속하게 유지보수하고 출시하기가 어려워 집니다. 프로덕션과 고객에게 변경사항이 제공되기까지 조율되고 승인받아야 하는 팀 간 종속성이 존재합니다. 이런 환경은 개발자와 운영자의 생산성, 그리고 고객 만족도를 낮추게 됩니다.

최신 애플리케이션은 마이크로서비스를 사용하여 빌드됩니다. 모놀리식 애플리케이션의 여러 도메인이 별개의 서비스로 분할되며, 각 서비스는 특정 기능을 담당합니다(즉, 마이크로서비스). 이 아키텍처에는 다음과 같은 몇 가지 이점이 있습니다.

  • 개발자 측면: 서비스를 분리하면 개발자는 다른 서비스와 별개로 특정 기능을 작업할 수 있습니다. 이 접근 방식은 개발자가 다른 서비스 및 팀에 긴밀하게 종속되지 않고 서비스에 기능을 추가할 수 있기 때문에 개발자 생산성을 높입니다.
  • 운영자 측면: 각 마이크로서비스 출시는 소규모 변경사항을 구현하므로 운영팀이 크고 복잡한 변경사항보다 쉽게 관리할 수 있습니다. 이러한 제어 방식으로 소규모 변경사항을 배포하면 출시에 실패할 경우 위험이 줄어들어 운영 생산성이 향상됩니다.
  • 고객 측면: 최신 아키텍처의 개발 및 운영 효율성으로 팀이 모놀리식 아키텍처를 사용하는 것보다 더 빠르게 새로운 기능을 고객에게 제공할 수 있습니다.

서비스 및 API에 중점

인프라 측면에서 기존 애플리케이션을 고려하는 경우가 많습니다. 서버, 가상 머신(VM), 네트워킹, 스토리지는 모놀리식 애플리케이션의 핵심 설계 요소입니다. 최신 애플리케이션은 서비스 및 API 측면에서 고려됩니다. 서비스 및 API에 중점을 두면 다음과 같은 이점이 있습니다.

  • 서비스 중복화 및 복원력. VM, 컨테이너, 클러스터 등 여러 곳 어디서나 서비스를 실행할 수 있습니다.
  • 서비스 가용성. 서비스에 중점을 두고 작업하면 애플리케이션의 전체 가용성이 향상될 수 있습니다. 서비스를 사용할 수만 있다면 인프라 오류는 문제가 되지 않으며 관련이 없습니다. 인프라가 아닌 서비스와 API 측면에서 설계하고 고려하는 방식은 업타임을 강조합니다. 업타임은 서비스 수준 목표(SLO)를 충족하는 데 도움이 됩니다.

컨테이너에서 마이크로서비스로 실행

기존 애플리케이션은 일반적으로 VM으로 또는 드물게 베어메탈에서 실행됩니다. 이러한 플랫폼은 비용이 많이 들고 비효율적으로 사용(CPU 및 RAM이 낮게 사용됨)되며 최신 클라우드 기반 플랫폼보다 관리하기가 어렵습니다(특히 베어메탈 서버의 경우). 최신 애플리케이션은 컨테이너의 마이크로서비스로 실행되므로 다음을 비롯한 여러 이점이 있습니다.

  • 더 작고 효율적인 애플리케이션. 컨테이너는 모놀리식 애플리케이션보다 2~3배 정도 작은 사용 공간으로 마이크로서비스를 패키징할 수 있습니다.
  • Linux 사용자 공간 격리. 호스트를 효율적으로 사용하여 단일 호스트에서 여러 컨테이너를 실행할 수 있습니다.
  • 다양한 환경과 인프라 간의 이동성. 컨테이너는 모든 종속 항목 및 필수 라이브러리로 애플리케이션을 캡슐화하므로 온프레미스 데이터 센터에서나 퍼블릭 클라우드 환경의 모든 환경에서 컨테이너를 실행할 수 있습니다.

개방형 표준을 기반으로 빌드

기존 애플리케이션은 기능 구현을 위해 상업용 또는 라이선스 제품을 사용하는 경우가 많습니다. 이러한 방식을 사용하면 라이선스 비용으로 비용이 많이 들어갈 뿐만 아니라 애플리케이션이 상용 플랫폼에 크게 의존하게 됩니다.

경우에 따라서 상용 소프트웨어는 실행할 수 있는 인프라 또는 하드웨어가 제한됩니다. 예를 들어 소프트웨어를 온프레미스에서만 실행할 수 있는 경우 기업은 많은 비용이 드는 데이터 센터와 인프라(예: 네트워킹, 스토리지, 서버, 전원, HVAC)를 관리해야 합니다.

최신 애플리케이션과 서비스는 대게 오픈소스 소프트웨어를 사용하여 빌드되며 다음과 같은 여러 이점이 있습니다.

  • 확장성 및 이동성. 어디서나 서비스를 실행할 수 있습니다.
  • 지원. Kubernetes 및 Docker와 같이 잘 채택된 오픈소스 기술은 단일 기업이나 단일 기업의 이익을 위해 제약을 받지 않는 여러 회사로 구성된 강력한 커뮤니티 구성 기능이 있는 경우가 많습니다. 이러한 오픈소스 접근 방식을 통해 제품의 특성 세트가 전반적으로 개선됩니다. Kubernetes와 같은 오픈소스 기술을 더 많이 채택하면 특성 세트가 상응하는 거의 모든 상용 특성 세트에 비해 더 강력해집니다.
  • 유연성. 이 모델에서는 기업이 더 이상 애플리케이션 플랫폼 또는 인프라의 단일 공급업체에 종속되지 않습니다. 개방형 표준을 채택하면 고객 및 비즈니스 요구사항을 기반으로 애플리케이션 및 인프라 관련 결정을 내릴 수 있습니다.

최신 플랫폼

최신 애플리케이션에는 최신 플랫폼이 필요합니다. 최신 플랫폼은 여러 요구사항을 충족해야 합니다.

빠르고 안정적이며 안전한 기능 출시

최신 플랫폼은 새 기능을 빠르고 안정적이며 안전하게 출시할 수 있도록 지원해야 합니다.

  • 신속성. 이 요구사항은 서비스 및 새 기능을 배포하기에 충분한 자동화에 따라 달라집니다. 자동화를 통해 인적 작업과 오류를 없애고 전송 속도를 높일 수 있습니다.
  • 안정성. 이 플랫폼을 사용하면 팀이 기능을 점진적으로 출시할 수 있거나 작동하지 않을 때 원래 상태로 되돌릴 수 있어야 합니다.
  • 보안. 플랫폼은 세부적인 액세스 제어를 지원해야 합니다. 승인된 운영자만 서비스에 액세스하거나 플랫폼에 기능 및 서비스를 배포할 수 있어야 합니다.

서비스 우선순위

최신 애플리케이션은 인프라가 아닌 서비스 측면에서 설계, 개발, 실행됩니다. 이러한 서비스 우선순위는 인프라 장애에 탄력적인 플랫폼에 따라 다릅니다. 최신 플랫폼에는 하드웨어 및 소프트웨어 장애로부터 서비스 및 플랫폼 자체를 복구하는 기능이 내장되어 있습니다.

일관된 제어 영역이 있는 하이브리드 및 멀티 클라우드 방식

디지털 혁신의 일환으로 많은 기업이 서비스 포트폴리오에 대한 멀티 클라우드 또는 하이브리드 클라우드 전략으로 전환하고 있습니다. 규제, 규정 준수 또는 보안상의 이유로 특정 애플리케이션을 온프레미스 데이터 센터에서 퍼블릭 클라우드로 이동할 수는 없지만 클라우드를 다른 서비스에 사용하려고 할 수 있습니다. 최신 플랫폼은 온프레미스 데이터 센터, 프라이빗 클라우드 또는 하나 이상의 퍼블릭 클라우드와 같은 여러 환경에서 실행될 수 있습니다. 다양한 인프라에서 실행되는 동안 최신 플랫폼은 개발자와 운영자에게 일관된 제어 영역 환경을 제공해야 하므로 운영 효율성이 향상됩니다.

모두 선언 코드로 표시

VM과 같은 기존 플랫폼은 기본적으로 명령형입니다. 운영자는 종종 리소스를 만들고 애플리케이션 런타임에서 실행되는 스크립트와 구성을 제공합니다. 운영자가 애플리케이션을 변경하는 경우 애플리케이션이 실행되는 VM에서 직접 변경을 수행해야 합니다. 이 프로세스로 인해 구성 드리프트가 발생할 수 있습니다. 즉, 애플리케이션과 플랫폼이 언제든지 의도한 상태에 있다고 보장할 수 없습니다. 이러한 환경에서는 장애 발생 시 문제 해결과 복구가 어려울 수 있습니다.

최신 플랫폼은 모든 리소스가 코드로 정의되는 선언적 시스템이며 코드형 인프라(IAC)라고도 합니다. 인프라, 서비스, 배포, 보안, 정책은 플랫폼의 의도된 상태를 정의하는 리소스 문서로 코드화됩니다. 이러한 선언적 접근 방식을 통해 운영자는 통합 언어를 통해 서비스, 보안, 정책을 정의할 수 있습니다. 이러한 리소스는 코드이므로 코드 저장소에 저장될 수 있으며 애플리케이션과 동일하게 정밀한 코드 검사가 수행됩니다. 플랫폼의 상태가 모든 상태 변경 커밋 기록과 함께 Git 저장소에 있으면 시스템 장애 또는 재해가 발생할 경우 이전 상태로 더 쉽게 복구할 수 있습니다.

Anthos 플랫폼

Anthos는 Google Cloud의 최신 애플리케이션 플랫폼입니다. 개방형 하이브리드 멀티 클라우드 Anthos 플랫폼을 사용하면 기존 애플리케이션을 현대화하고, 새 애플리케이션을 빌드하고, 어디서나 더 안전한 방식으로 애플리케이션을 실행할 수 있습니다. Kubernetes, Istio, Knative 등 Google에서 개척한 오픈소스 기술 기반의 Anthos를 사용하면 온프레미스와 클라우드 환경 간의 일관성을 확보하고 애플리케이션 개발을 가속화할 수 있습니다.

다음 다이어그램은 일반적인 엔터프라이즈 환경에서 Anthos 구성요소와 각 구성요소의 상호작용을 나타낸 것입니다.

Anthos 플랫폼이 지원하는 핵심 현대화 기능입니다.

다음 섹션에서는 Anthos의 핵심 구성요소를 간략하게 설명합니다.

Anthos 클러스터: 컨테이너 조정

기본적인 Anthos 컴퓨팅 환경에서는 Anthos 클러스터를 사용하여 애플리케이션을 배포할 환경에서 Kubernetes 설치를 관리합니다. 이러한 서비스는 업스트림 Kubernetes 출시 버전을 번들로 제공하고 요구사항을 준수하는 Kubernetes 클러스터를 만들고, 확장하고, 업그레이드할 수 있습니다.

Kubernetes는 제어 영역노드 구성요소라는 두 가지 부분으로 이루어집니다. GKE를 사용할 때 Google Cloud는 제어 영역을 호스팅하며 Kubernetes API 서버는 고객이 액세스할 수 있는 유일한 제어 영역 구성요소입니다. GKE는 Compute Engine의 인스턴스를 사용하여 고객 프로젝트의 노드 구성요소를 관리합니다. Anthos 클러스터를 사용하면 모든 구성요소가 고객의 온프레미스 가상화 환경에서 호스팅됩니다.

Kubernetes를 설치하여 실행하면 애플리케이션 배포, 구성, 업그레이드, 확장을 관리하는 일반적인 조정 레이어에 액세스할 수 있습니다.

Anthos Config Management: 정책 관리

Anthos Config Management를 사용하면 구성(config)이라는 파일을 사용하여 단일 클러스터, 멀티 테넌트 클러스터, 멀티 클러스터 Kubernetes 배포를 관리할 수 있습니다. 구성은 Git 저장소에 저장됩니다.

일부 구성은 Kubernetes 객체 매니페스트이지만 다른 구성은 객체 매니페스트가 아니며 Anthos Config Management에 필요한 정보를 제공합니다. YAML 또는 JSON으로 구성을 작성할 수 있습니다. Anthos Config Management는 이러한 파일의 업데이트를 감시하고 변경사항을 모든 관련 클러스터에 자동으로 적용합니다.

코드로 구성(Configuration-as-code) 접근 방식을 사용하면 Kubernetes에 배포된 애플리케이션을 관리하는 데 사용하는 것과 동일한 원칙을 사용하여 Anthos 클러스터의 구성을 관리할 수 있습니다.

Anthos Service Mesh: 서비스 관리

Anthos Service Mesh는 Anthos 클러스터에서 실행되는 서비스에 대한 연결, 모니터링, 지원하는 Istio 호환 프레임워크입니다. Anthos Service Mesh를 사용하면 서비스 코드를 변경하지 않아도 부하 분산, 서비스 간 인증, 모니터링과 같은 배포된 서비스 네트워크를 만들 수 있습니다.

Anthos Service Mesh는 애플리케이션의 각 pod에 사이드카 프록시를 자동으로 삽입합니다. pod는 Kubernetes 애플리케이션의 기본적인 실행 단위입니다. pod는 애플리케이션의 컨테이너(경우에 따라 여러 컨테이너)를 캡슐화합니다. Anthos Service Mesh에서 모든 pod에는 애플리케이션 컨테이너와 Envoy 프록시 컨테이너(사이드카 프록시라고도 함)라는 2개의 컨테이너가 포함됩니다. 사이드카 프록시는 pod에서 주고 받는 모든 네트워크 트래픽을 가로챕니다. 또한 Anthos Service Mesh는 인그레스 게이트웨이를 구성하여 메시에 대한 인바운드 트래픽을 관리합니다. 오픈소스 Istio API를 사용하여 사이드카 및 게이트웨이에 적용되는 정책을 구성할 수 있습니다.

현대화 과정

Google Cloud는 자바 애플리케이션을 모놀리식 상태에서 마이크로서비스로 이동하는 권장 프로세스를 제공합니다. 다음 단계를 채택하고 비즈니스 요구사항과 니즈에 가장 적합한 속도로 이동할 수 있습니다.

  1. 코드를 다시 작성하지 않고 적합한 애플리케이션을 VM에서 실행에서 컨테이너에서 실행으로 리프트 및 현대화
  2. 최신 CI/CD 방식을 사용하여 컨테이너식 애플리케이션을 Anthos 플랫폼에 배포합니다. 일부 애플리케이션은 컨테이너화에 적합하지 않을 수 있으며 VM으로 있는 것이 나을 수 있습니다.
  3. 시간이 지남에 따라 애플리케이션을 OSS 애플리케이션 스택, 최신 프레임워크, 마이크로서비스로 리팩터링합니다.

다음 플로차트는 이 과정을 보여줍니다.

현대화 프로세스의 단계 흐름

이러한 각 중요한 단계는 다음 섹션에서 설명합니다.

현대화 단계

다음 섹션에서는 현대화 프로세스의 각 단계와 Anthos 및 Migrate to Containers가 각 단계에서 어떻게 도움이 되는지 설명합니다.

1단계: 자바 애플리케이션 컨테이너화

이 현대화 단계에서는 VM으로 실행되는 적절한 자바 애플리케이션을 컨테이너화합니다.

최신 프레임워크 및 패키지 애플리케이션을 위한 컨테이너화

컨테이너화는 운영 환경의 모든 종속 항목 및 라이브러리와 함께 애플리케이션 코드를 패키징하는 프로세스입니다. 격리된 독립형 애플리케이션 환경을 각각 사용하여 단일 호스트에서 여러 컨테이너를 실행할 수 있습니다. 컨테이너는 간단하고 이동하기 쉬우며 효율적인 VM 대안입니다.

일반적으로 maven 또는 gradle과 같은 도구를 사용하여 자바 애플리케이션을 JAR 파일로 빌드하고 패키징합니다. 그런 다음 VM 또는 베어메탈 서버에서 바이너리를 실행합니다.

다음 두 가지 방법 중 하나로 자바 애플리케이션을 컨테이너화할 수 있습니다.

  1. Migrate to Containers를 사용하여 애플리케이션을 리프트하고 현대화합니다.
  2. 시스템 통합 도구를 사용하여 컨테이너 빌드

Migrate to Containers를 사용하여 리프트 및 현대화

Migrate to Containers를 사용하여 애플리케이션을 VM에서 Dockerfile 또는 Kubernetes 리소스 매니페스트와 같은 컨테이너화된 아티팩트로 직접 마이그레이션할 수 있습니다. 그런 다음 컨테이너를 Anthos(GKE 및 VMware용 Anthos 클러스터)에 배포합니다.

Migrate to Containers로 마이그레이션

Migrate to Containers를 사용하여 애플리케이션을 마이그레이션하는 프로세스는 다음과 같습니다.

  1. 마이그레이션 후보 식별. 이 단계에서는 마이그레이션에 적합한 애플리케이션을 평가합니다. 두 가지 애플리케이션 유형이 마이그레이션에 적합합니다.
    • 소스 코드에 액세스할 수 없는 애플리케이션. 개발자가 더 이상 회사에 있지 않으며 코드베이스가 더 이상 지원되지 않을 수도 있습니다. 이러한 애플리케이션을 VM으로 관리하는 대신 Migrate to Containers에서 간소화된 컨테이너화 프로세스를 사용하면 이러한 애플리케이션을 Anthos로 이동할 수 있습니다.
    • 유지보수되지만 개발되지 않는 애플리케이션. 일부 애플리케이션은 활발하게 개발되지 않지만 다른 서비스의 종속 항목 때문에 여전히 필요합니다. Migrate to Containers는 이러한 애플리케이션을 지원하는 플랫폼을 현대화하는 프로세스를 간소화합니다.
  2. Anthos로 마이그레이션. 마이그레이션에 적합한 후보를 식별한 후 Migrate to Containers를 사용하여 최신 CI/CD 사례를 사용하여 VM을 Anthos에 배포할 수 있는 컨테이너화된 아티팩트로 변환합니다(다음 섹션 참조). Migrate to Containers는 애플리케이션의 데이터와 상태를 이동하는 데도 도움이 됩니다.
Migrate to Containers 및 어려운 마이그레이션

경우에 따라 기업이 관리하는 애플리케이션 수는 수천 개에 달할 수 있습니다. 이전할 애플리케이션 수 또는 컨테이너화의 복잡성으로 인해 기업에서 중요한 클라우드 이니셔티브를 진행하는 데 방해가 될 수 있습니다. 이에 따라 기업에서는 비즈니스 기회 및 동급 최고의 퍼블릭 클라우드 서비스의 이점을 간과할 수 있습니다. 이러한 서비스에는 BigQuery와 같은 데이터 및 분석 서비스, AutoML과 같은 인공지능 애플리케이션 또는 Google Cloud의 사전 학습된 API와 같은 머신러닝(ML) 애플리케이션이 있을 수 있습니다.

Migrate to Containers를 사용하면 다음과 같은 방식으로 애플리케이션 포트폴리오의 문제와 복잡성을 해결할 수 있습니다.

  • 대규모 애플리케이션 마이그레이션 처리. Migrate to Containers를 사용하면 개발자와 운영자에게 기술적 채무를 발생시키지 않으면서 여러 애플리케이션을 Anthos로 현대화하고 동시에 이동할 수 있습니다.
  • 컨테이너화 간소화. 다수의 애플리케이션과 결합되는 컨테이너화는 복잡할 수 있으며 기업에 급격한 대규모 현대화를 지원하는 기술 역량 또는 리소스가 없을 수도 있습니다. 이러한 경우 Migrate for Containers를 사용하면 Anthos로의 이동과 현대화를 간단하고 효율적으로 진행할 수 있습니다.

자세한 내용은 Migrate to Containers 문서를 참조하세요.

컨테이너화를 위한 기타 도구

Docker는 컨테이너 이미지 빌드에 널리 사용되는 플랫폼입니다. Dockerfile은 이미지를 조립하기 위해 명령줄에서 호출할 수 있는 모든 명령어가 포함된 텍스트 문서입니다. Docker 컨테이너를 만들려면 바이너리(JAR 파일)를 빌드한 후 Dockerfile에 패키징합니다. Dockerfile을 만든 후에는 이를 CI/CD 파이프라인에서 사용할 수 있습니다. 다음 다이어그램은 Dockerfile을 사용하는 워크플로를 보여줍니다.

컨테이너화에 사용할 수 있는 도구

2단계: 최신 CI/CD를 사용하여 Anthos에 애플리케이션 배포

이 현대화 단계에서는 현대식 소프트웨어 제공 방식을 사용하여 컨테이너화된 자바 애플리케이션을 Anthos에 배포합니다.

CI/CD를 사용한 컨테이너화 프로세스 흐름

애플리케이션은 잘 조정되고 자동화되고 반복 가능하며 안정적인 방법으로 빌드, 테스트되고 고객에게 제공되어야 합니다. 여러 개발팀이 지속적으로 기능을 추가하므로 CI/CD를 사용하여 컨테이너화된 애플리케이션을 빌드, 테스트, 배포하는 경우가 많습니다.

현대식 소프트웨어 제공 방식의 이점

Anthos의 최신 CI/CD 또는 소프트웨어 제공 플랫폼을 사용하면 다음을 수행할 수 있습니다.

  • 애플리케이션 프로비저닝을 위한 권장사항을 만들고 업데이트합니다.
  • 시작 또는 상용구 프로젝트를 통해 새 애플리케이션을 온보딩합니다.
  • 다른 애플리케이션 개발에 대한 방해 없이 애플리케이션을 개발하고 반복합니다.
  • 플랫폼 전체에 정책을 원활하게 구현하고 전파합니다.
  • 배포 및 개선된 출시 관리 및 변경 추적에 GitOps를 사용합니다.

Anthos를 사용한 소프트웨어 제공 플랫폼

다음 다이어그램의 구성요소는 Anthos 플랫폼에서 사용할 수 있는 완전한 소프트웨어 제공 플랫폼을 형성합니다.

Anthos 플랫폼에서 발견된 핵심 소프트웨어 제공 구성요소입니다.

각 구성요소는 플랫폼에서 실행되는 시스템 및 애플리케이션에 기능을 제공합니다. 일반적으로 개발, 운영, 보안 등 여러 팀이 플랫폼의 업타임, 구성, 안정성, 규모를 유지관리해야 합니다.

소프트웨어 제공 플랫폼의 핵심 구성요소는 CI/CD 시스템입니다. CI/CD 프로세스를 정의할 때는 각 구성요소가 표준화된 인터페이스를 준수하는 아티팩트를 생성하거나 사용하는지 확인해야 합니다. 표준화된 인터페이스를 사용하면 더 나은 구현을 출시할 때 각 구성요소를 더욱 쉽게 바꿀 수 있습니다. 컨테이너식 애플리케이션을 위한 플랫폼을 만들 때 다음 3가지 표준화된 인터페이스 중에서 선택할 수 있습니다.

  • Git 저장소
  • Docker 이미지
  • kubernetes manifests

이러한 인터페이스를 사용하면 다음 다이어그램에 표시된 흐름을 사용하여 재사용 가능하고 유연한 CI/CD 파이프라인을 만들 수 있습니다.

재사용 가능한 지속적 배포 및 배포 파이프라인의 구성요소 매핑

프로세스는 다음과 같습니다.

  1. 개발자는 애플리케이션 Git 저장소에 애플리케이션 코드를 커밋합니다.
  2. CI 시스템은 코드를 테스트하고 Docker 이미지 아티팩트를 만들며 레지스트리에 이미지를 저장합니다.
  3. 아티팩트를 배포할 준비가 되면 아티팩트에 대한 참조가 애플리케이션 구성 파일에 추가됩니다.
  4. 이 애플리케이션 구성은 Kubernetes가 읽을 수 있는 형식으로 렌더링되고 코드 저장소에 저장되어 사전 프로덕션 환경에 배포됩니다.
  5. 변경 사항이 코드 저장소에 커밋되면 운영자는 변경 사항을 검토한 후 마스터 분기에 병합합니다.
  6. 애플리케이션이 프로덕션에 배포됩니다.
  7. 운영자는 조직 전체에서 변경을 수행하려는 경우 저장소에 변경 사항을 커밋하여 애플리케이션 구성을 트리거합니다. 개발자가 다음 변경 사항을 배포하면 개발자가 운영자의 업데이트를 선택합니다.
  8. 동시에 보안 엔지니어는 자체 정책 저장소에 커밋하는 것으로 배포할 수 있는 항목을 정의하는 정책을 구현하고 조정할 수 있습니다.

3단계: 기존 자바 애플리케이션에 대한 온프레미스 VM 최적화

이 현대화 단계에서 자바 애플리케이션은 다음 다이어그램과 같이 온프레미스 데이터 센터 또는 Google Cloud에서 VM으로 실행됩니다.

애플리케이션을 마이그레이션할지 온프레미스로 최적화할지 결정합니다.

다음과 같은 이유로 일부 자바 애플리케이션은 컨테이너화에 적합하지 않을 수 있습니다.

  • 일부 애플리케이션은 업무상 매우 중요합니다. 업무상 중요한 애플리케이션을 컨테이너로 마이그레이션하는 것이 너무 위험하더라도 VM을 Google Cloud로 이동하면 인프라 탄력적인 비용 이점을 얻을 수 있습니다. Google Cloud에서는 VM의 크기를 맞춤설정하여 사용 비용을 극대화할 수 있습니다.
  • 운영팀이 최신 플랫폼을 관리하는 데 익숙하지 않습니다. 일부 운영팀은 VM 환경을 관리하는 데 익숙하지 않거나 최신 컨테이너화된 플랫폼에서 작업할 수 있는 기술이 없습니다. 예를 들어 팀이 기존 애플리케이션 간의 연결 및 종속 항목 관리를 위한 현재 도구 모음에 이미 익숙하지만 프로덕션에서 컨테이너화된 플랫폼을 운영하는 데 시간이 필요합니다.
  • 클라우드를 단계적으로 도입해야 합니다. 예를 들어 클라우드를 사용하기 시작하면서 동시에 너무 많은 변경을 수행하면 안 됩니다. 또한 환경(데이터 센터에서 클라우드로)과 플랫폼(VM에서 컨테이너로)을 동시에 변경하는 일은 위험할 수 있습니다.
  • 예산 및 운영 제약조건이 있습니다. 여기에는 하드웨어/인프라, 라이선스, 애플리케이션 아키텍처 요구사항이 포함될 수 있습니다.

VM 워크로드 실행 옵션

다음 옵션 중 하나 이상을 선택하여 VM 워크로드를 더 효율적으로 실행할 수 있습니다.

  • Google Cloud와 함께. Google Cloud에서 VM을 다음 두 가지 방법으로 실행할 수 있습니다.
    • Compute Engine 인스턴스로. Compute Engine은 고성능 네트워킹 인프라 및 블록 스토리지에 액세스할 수 있는 Google 데이터 센터에서 실행되는 구성 가능한 VM을 제공합니다. 이 옵션을 사용하면 기업에서 온프레미스 데이터 센터 및 서버를 관리하지 않아도 되고 가상화 상용 라이선스 비용을 지불하지 않아도 됩니다 (해당하는 경우).
    • VMware 서비스로. VMware와 Google Cloud 간의 파트너십을 통해 멀티 클라우드 및 하이브리드 클라우드 환경에서 클라우드 애플리케이션의 지속적 배포, 운영, 보안을 보장하는 개방형 플랫폼을 제공합니다. 이 옵션은 현재 VMware 관련 기능에 의존하는 VMware를 실행 중인 기업에 적용 가능합니다. 기업은 여러 환경 간에 VM을 관리하기 위해 일관적인 제어 영역을 원하거나 자체 데이터 센터와 서버 인프라를 더 이상 관리하기를 원하지 않는다는 점에서 하이브리드 클라우드 환경에 있습니다.
  • 온프레미스 데이터 센터. 특정 애플리케이션을 온프레미스에서 VM으로 실행하는 이유는 다음과 같습니다.
    • 규제 또는 규정 준수 고려사항
    • 사용자 또는 다른 애플리케이션과 더 가까워야 하는 성능 요구 사항
    • 온프레미스 하드웨어에 대한 현재 투자

VM 마이그레이션을 위한 도구 및 솔루션

Google Cloud는 VM을 Google Cloud로 마이그레이션할 때 사용할 수 있는 다양한 도구와 솔루션을 제공합니다. Migrate for Virtual Machines를 사용하면 백그라운드에서 데이터를 투명하게 마이그레이션하는 동안 몇 분 내로 애플리케이션을 유효성 검사, 실행, Google Cloud로 마이그레이션할 수 있습니다. Compute Engine으로 마이그레이션하는 방법에 대한 리소스는 Google Cloud로 마이그레이션: 시작하기를 참조하세요.

Google은 VMware 서비스로 마이그레이션할 때 신뢰할 수 있는 파트너와 협력하여 Google Cloud로의 VMWare 마이그레이션을 지원할 수 있는 전문 서비스를 제공합니다.

4단계: 애플리케이션을 마이크로서비스로 리팩터링

플랫폼을 현대화한 후에는 플랫폼에서 실행되는 애플리케이션을 현대화하는 데 집중할 수 있습니다. 이 단계에서는 Anthos 플랫폼에서 실행 중인 애플리케이션을 마이크로서비스로 리팩터링합니다.

리팩터링 애플리케이션이 현대화 과정에 적합한 경우입니다.

일부 애플리케이션은 컨테이너에서 모놀리식으로 실행될 수 있지만 문제가 되지 않습니다. 애플리케이션을 현대화하기 위한 기본 요건으로 애플리케이션을 최신 플랫폼(예: Anthos)으로 마이그레이션해야 합니다. 마이그레이션 후 애플리케이션을 마이크로서비스로 현대화하는 프로세스는 시간을 두고 진행할 수 있습니다.

Anthos로 이동하면 개발자와 운영자 모두 새로운 애플리케이션 및 플랫폼 관리 방법을 익힐 수 있습니다. 개발자는 코드를 더 빠르게 병합하고 종종 테스트하는 데 익숙해지는 반면, 운영자는 소프트웨어를 빌드, 테스트하고 고객에게 제공하는 최신 방법에 익숙해집니다.

Anthos 플랫폼에서 실행되는 애플리케이션의 경우 비즈니스 계열이 마이크로서비스로 현대화할 항목에 우선순위를 지정할 수 있습니다. Google과 SI 파트너는 이 현대화 단계에서 엔터프라이즈를 운영하는 데 유용한 여러 개발자 및 운영자 도구를 제공합니다. 다음 섹션에서는 이러한 리소스를 설명합니다.

Spring Google Cloud

리팩터링의 일부로 자바 애플리케이션을 Spring Boot와 같은 최신 자바 프레임워크로 포팅할 수 있습니다. Spring Boot 및 Spring Framework는 최신 자바 기반 기업 애플리케이션을 위한 포괄적인 프로그래밍 및 구성 모델을 제공합니다. Spring Cloud는 개발자가 구성 관리, 서비스 검색, 회로 차단기, 지능형 라우팅, 마이크로 프록시, 제어 버스, 일회성 토큰, 전역 잠금, 경영진 선거, 분산 세션, 클러스터 상태 등 분산 시스템에서 몇 가지 일반적인 패턴을 빠르게 빌드할 수 있는 도구를 제공합니다.

Spring Google Cloud 프로젝트는 Spring Boot 애플리케이션에서 Google Cloud를 간편하게 사용할 수 있도록 다음과 같은 Google Cloud 제품을 지원하는 여러 라이브러리와 기능을 제공합니다.

  • Pub/Sub: Spring Integration 및 Spring Stream
  • Cloud Spanner, Datastore, Cloud SQL: Spring Data
  • Cloud Logging 및 Cloud Trace
  • Firestore: Spring Data Reactive Repositories
  • Cloud Storage: Spring Resource 및 Spring Integration
  • Cloud Vision API: CloudVisionTemplate 템플릿
  • IAP(Identity-Aware Proxy): IAP 헤더에서 Spring Security ID 추출
  • BigQuery: Spring 통합

개발자 도구

Google Cloud는 컨테이너화된 최신 자바 애플리케이션을 만드는 데 도움이 되는 도구를 제공합니다. 이러한 도구 중 일부는 다음과 같습니다.

  • Cloud Code. Cloud Code는 개발 및 테스트용 클러스터 생성부터 프로덕션에서 완성된 애플리케이션 실행에 이르기까지 Kubernetes 애플리케이션의 전체 개발 주기에 대한 IDE를 지원합니다. Cloud Code는 실행 준비가 완료된 샘플, 즉시 사용 가능한 구성 스니펫, 맞춤형 디버깅 환경을 제공하므로 Kubernetes를 사용한 개발이 훨씬 쉬워집니다. Cloud Code는 Google Cloud에서 호스팅되는 클러스터 생성을 간소화하고 Cloud Source Repositories, Cloud Storage, 다양한 Cloud 라이브러리 등의 Google Cloud 도구와 더 잘 통합되는 간소화된 Google Kubernetes Engine(GKE) 환경을 제공합니다. VS Code 또는 IntelliJ와 함께 Cloud Code를 사용할 수 있습니다.
  • Artifact Registry. Artifact Registry는 통합된 Google Cloud 환경의 일부로 아티팩트를 저장하고 종속 항목을 빌드할 수 있는 중앙 위치를 제공합니다. Artifact Registry는 패키지, 라이브러리, Docker 컨테이너 이미지를 관리하기 위한 단일 위치를 제공합니다. 이러한 아티팩트(패키지 및 컨테이너 이미지)는 최신 CI/CD 파이프라인에서 사용할 수 있습니다. 이 파이프라인은 이 문서의 앞부분에 설명되어 있습니다.
  • Jib, Buildpacks빌드 도구. Jib 및 Buildpack을 사용하면 이미 알고 있는 자바 도구(예: maven 또는 gradle)를 사용하여 컨테이너를 빌드할 수 있습니다. 이러한 빌드 도구가 없으면 Dockerfile을 수동으로 만들고 테스트해야 합니다. 이 수동 방식을 사용하려면 컨테이너를 만들고 실행하기 위해 Docker 데몬이 있는 호스트가 필요합니다. 이 프로세스에는 몇 가지 단계가 더 있으며 코드를 가능한 빠르고 원활하게 프로덕션에 푸시하려는 개발자는 단계를 반복할 수 있습니다. Jib는 단일 빌드 단계에서 바이너리 빌드를 조정하고, 컨테이너 이미지를 만들고, 이미지를 Container Registry로 푸시합니다. Jib는 개발자에게 익숙한 빌드 도구를 사용하여 개발자의 생산성을 향상시킵니다. 레지스트리에 자바 컨테이너를 푸시한 후에는 CI/CD 파이프라인을 통해 배포할 수 있습니다. 다음 다이어그램은 Buildpack 또는 Jib의 전체적인 흐름을 보여줍니다.

    다른 개발자 도구가 마이크로서비스를 만드는 과정에 적합한 위치.

오픈소스 애플리케이션 서버로 플랫폼 변경

일부 애플리케이션의 경우 자바 애플리케이션을 리팩터링하려면 자바 애플리케이션 서버도 플랫폼을 변경해야 합니다. 라이선스 비용을 줄이기 위해 상용 애플리케이션 서버 플랫폼(예: WebSphere 또는 WebLogic)에서 실행되는 자바 애플리케이션은 오픈소스 구성요소(예: JBoss 또는 Tomcat)로 플랫폼을 변경합니다.

기존 자바 애플리케이션 아키텍처

기존 자바 애플리케이션은 일반적으로 3계층 또는 4계층 JEE 아키텍처를 사용합니다. JEE 아키텍처는 다중 계층 엔터프라이즈 애플리케이션의 구성요소 기반 개발을 지원합니다. 다음 다이어그램은 일반적으로 JEE 애플리케이션 시스템에 있는 계층을 보여줍니다.

표시 계층, 애플리케이션 계층, 기업 데이터 계층으로 구성된 다중 계층 플랫폼 아키텍처입니다.

다음과 같은 계층이 있습니다.

  • 표시 계층. 표시 계층에서 서블릿 및 JavaServer 페이지(JSP 또는 JSF) 또는 독립형 자바 애플리케이션과 같은 웹 구성요소는 중간 계층에 동적 인터페이스를 제공합니다.
  • 애플리케이션 또는 중간 계층. 애플리케이션 계층 또는 중간 계층에서 Enterprise Java Beans 및 웹 서비스는 애플리케이션에 대한 재사용 가능한 배포 가능 비즈니스 로직을 캡슐화합니다. 이러한 서버 계층 구성요소는 이러한 구성요소가 작업을 수행하고 데이터를 저장할 수 있는 플랫폼을 제공하는 JEE 애플리케이션 서버에 포함되어 있습니다.
  • 기업 데이터 계층. 데이터 계층에서 기업 데이터는 일반적으로 관계형 데이터베이스에 저장되고 유지됩니다.

이러한 여러 계층은 일반적으로 가상화된 환경에 배포되고 애플리케이션 서버에 의존하므로, 라이선스 비용이 많이 발생할 수 있습니다.

개방형 표준으로 전환할 경우의 이점

개방형 표준으로 전환하면 라이선스 비용이 줄어들고 클라우드 기반 배포 방법 및 클라우드 기반 플랫폼의 이점이 제공됩니다.

도구 및 솔루션

Google Cloud는 JEE 애플리케이션의 플랫폼을 변경하고 OSS 기술을 채택하는 검증된 접근법과 도구를 갖춘 다양한 시스템 통합업체(SI)와 제휴합니다.

플랫폼 변경 프로세스는 기존 자바 애플리케이션을 평가하는 것으로 시작됩니다. 평가는 애플리케이션의 복잡성, 기능, 사용량 측정항목, 업무 중요도를 비롯한 다양한 요소를 고려합니다. 이 평가 후 플랫폼을 변경할 우선순위가 지정된 애플리케이션 후보 목록을 반환합니다. SI는 소스 코드에서 상용 애플리케이션 서버 종속 항목을 모두 삭제하도록 지원하는 개발자 및 DevOps 도구를 제공합니다. 다음 단계(배포)로 진행하기 전에 각 애플리케이션에 대한 테스트 및 종료 기준을 고려합니다. 이 단계는 소스 코드에 액세스할 수 있고 플랫폼의 오픈소스 변형이 있는 애플리케이션에 적용됩니다.

리팩터링 권장사항

다음 두 가지 Google Cloud 문서에서는 모놀리식 애플리케이션에서 마이크로서비스로 전환하는 방법과 이점을 설명합니다.

Anthos Service Mesh를 사용하여 마이크로서비스를 VM에 연결

기업에는 다양한 애플리케이션이 있습니다. 거의 모든 기업의 애플리케이션은 다음 플랫폼 중 하나에서 실행됩니다.

  • 컨테이너에서 마이크로서비스를 실행하기 위한 Anthos 플랫폼
  • VM 실행을 위한 가상화 플랫폼

이러한 두 플랫폼에서 실행되는 서비스는 서로 종속되어 있으며 서로 안전하게 통신할 수 있어야 합니다. Anthos 플랫폼에서 실행되는 마이크로서비스의 경우 Anthos Service Mesh는 가상화된 환경의 Anthos 외부에서 실행되는 VM에 대한 보안이 강화된 연결을 제공합니다.

VM이 있는 Anthos Service Mesh의 이점

  • VM은 Anthos에서 실행되는 컨테이너 및 마이크로서비스와 동일한 Kubernetes 스타일 선언적 정책 및 보안 관리 프레임워크를 활용할 수 있습니다. 이 접근 방식을 사용하면 운영자는 Anthos에서 실행되는 컨테이너와 다른 환경에서 실행 중인 VM 간에 보안이 강화된(mTLS) 인증 연결을 유지할 수 있습니다.
  • 기존 VM에서 Anthos 플랫폼에 대한 서비스로 표시하기 위해 다시 코딩할 필요가 없습니다. VM이 서비스로 표시되면 Anthos는 VM을 GKE에서 실행되는 서비스처럼 취급합니다.
  • 운영자는 계측 없이 VM의 향상된 관측 가능성(측정항목)을 얻습니다. 측정항목은 Anthos에서 실행 중인 서비스인 것처럼 표시됩니다.

VM 컨테이너화

시간이 지남에 따라 기존 리팩터링 VM을 컨테이너로 이동할 수 있습니다. 이 접근 방식을 사용하면 원하는 속도에 맞춰 현대화를 진행하여 현대화할 애플리케이션의 우선순위를 정할 수 있습니다.

다음 단계