이전포스트

Netflix Spinnaker 를 사용한 Cloud Native Continuous Delivery

freemmer 2016. 5. 3. 13:05
출처 : https://blog.pivotal.io/kr/pivotal-cloud-foundry/features/netflix-spinnaker-를-사용한-cloud-native-continuous-delivery


Netflix Spinnaker 를 사용한 Cloud Native Continuous Delivery

Spinnaker 는 Netflix 의 클라우드-네이티브 기반의 연속 배포 플랫폼으로서, 클라우드 플랫폼에 소프트웨어를 배포하기 위해 개발된 도구입니다. Spinnaker 는 개발자들에게 애플리케이션 배포에 대한 높은 시안성을 제공하여 코드를 보다 빠르고 안전하게 배포하는 것을 지원 합니다. 이는 오픈소스 프로젝트로서 Pivotal 외에도 Google 과 Microsoft 와 같은 클라우드 서비스 공급자들이 함께 참여하고 있습니다. 이 플랫폼은 다양한 언어로 작성된 코드와 개발을 AWS, Pivotal Cloud Foundry (PCF), Google Computing Engine, 그리고 Microsoft Azure 와 같은 다양한 클라우드 기반에서 사용할 수 있는 모델을 지원합니다.

Spinnaker 는 지난 6년 동안 Netflix 가 Asgard 를 사용하면서 얻어온 개발 패턴과 경험이 담겨있는 도구이며, 이 프로젝트는 아래와 같은 목표를 가지고 있습니다.

  • 반복적으로 발생하는 배포에 대해 유연하고도 설정 가능한 파이프라인 및 단계들을 제공합니다.
  • 애플리케이션이 통과하는 배포 파이프라인의 모든 환경에 대한 글로벌 뷰를 제공합니다.
  • 신뢰성 높은 API 를 바탕으로 프로그래밍적인 설정 방법과 실행을 제공합니다.
  • 쉬운 설정과 유지, 그리고 확장이 가능합니다.
  • 운영에 대한 탄력성을 제공합니다.
  • 폭넓은 파이프라인 구성이 가능합니다.

Pivotal 과 Spinnaker

위에 나열된 목표들을 달성하기 위해 Spinnaker는 개방적이며 플러그인의 형태로 사용할 수 있는 시스템으로 계획되었으며, 오픈소스 커뮤니티를 바탕으로 다양한 클라우드 플랫폼에서 쉽게 사용할 수 있도록 지속적으로 구현되고 있습니다. 본 프로젝트의 주체인 Netflix 는 다양한 목표들을 달성하기 위해 Pivotal, Google, Microsoft 와 같은 업체들과 함께 Spinnaker 에 최신의 기술을 도입할 수 있도록 협업하고 있습니다. 이에 Pivotal 은 Cloud Foundry 의 지원을 포함하여, 엔터프라이즈의 고객들께서 Spinnaker 를 바탕으로 클라우드 네이티브 기반의 플랫폼 위에서 배포를 쉽게 처리할 수 있게끔 하는 기능을 제공합니다. Spinnaker 는 그 자체로서 PCF 기반의 다른 애플리케이션과 동일한 방법으로 배포가 가능 합니다. 또한 추가적으로 Cloud Foundry 드라이버가 함께 제공됩니다. 이는 곧 Spinnaker 의 개발 모델이 Cloud Foundry API 에 매핑 되어 있음을 의미하며, 이 드라이버를 통해 사용자의 애플리케이션에 대한 빠르고 쉬운 배포를 지원합니다.

클라우드 네이티브와 연속 개선, 연속 배포.

클라우드 환경으로의 소프트웨어 배포는 보통 연속 개선 (CI) 및 연속 배포 (CD)의 방법을 사용합니다. 연속 개선은 일반적으로 개발 환경으로 배포하는 코드의 빌드와 테스트를 의미합니다. 연속 배포(CD)는 CI 이후에 프로덕션 환경 으로의 배포를 빠르고 안전하게 수행하는 것을 의미합니다. CD 파이프라인 역시 애플리케이션이 프로덕션 환경으로의 배포에 준비가 되었는지 검증하는 단계로 사용됩니다. 이렇게 각 단계별로 구성된 배포 환경은 비지니스 개선을 위한 새로운 소프트웨어 배포를 보다 안전하고 빠르게 수행할 수 있도록 돕습니다. 

Spinnaker 는 Jenkins 와 독립적으로 연동할 수 있도록 구성된 플러그형 CI 서버 입니다. Jenkins 뿐만 아니라 Concourse, Baboo, TeamCity 및 그 외의 다양한 도구들과 함께 확장 역시 가능 합니다. 대부분의 CI 서버들이 CD 솔루션의 일부로 기능하면서 대부분의 대상 플랫폼에 대한 배포를 지원하는데 반하여, Spinnaker 는 클라우드 서비스 공급자가 제공하는 메타데이터와 높은 수준의 연동을 지원하는 동시에 배포에 필요한 풍부한 설정을 지원 합니다. 이 클라우드 메타데이터는 종전보다 높은 사용성을 제공하는데, 예를 들면 time-of-day 배포, 수동 검사 단계, 문맥 기반 알림 (email, SMS, etc), 그리고 애플리케이션 지원과 배포 프로세스의 일부로서 플랫폼 메트릭의 제공 등 다양한 기능을 이용할 수 있습니다. 이는 Spinnaker 가 기존의 전통적인 CI 도구를 복잡한, rule-driven, 다양한 클라우드 서비스 공급자와의 연동, high-volume 배포등을 지원함으로서 보완합니다. 이 뿐만 아니라 Spinnaker 는 병렬 배포, 배포 시간 제한, Canary 배포 등등의 기능을 CD 파이프라인 워크 플로우에 추가할 수 있도록 제공 합니다. 아래의 스크린샷 이미지는 PCF 에 성공적으로 배포된 파이프라인의 상태를 보여 줍니다.

Spinnaker 의 클라우드 배포 모델과 Cloud Foundry 매핑 

Cloud Foundry 의 Spinnaker 모듈은 Spinnaker 의 기능을 가능한 쉽게 사용할 수 있도록 하기 위해 제공 됩니다. 아래의 예들을 통해 Spinnaker 의 컨셉과 Cloud Foundry 의 컨셉이 어떻게 매핑 될 수 있는지를 알아 볼 수 있습니다.

  • 애플리케이션 (Application) : 하나의 완전한, 모든 파트가 포함되어 캡슐화 된 애플리케이션 전체를 의미합니다. Spring.io 를 호스트 하는 Sagan 애플리케이션의 경우, GitHub 의 단일 저장소에서 수많은 커밋의 리스트를 가집니다. 
  • 클러스터 (Cluster) : 어딘가에 위치한 하나의 앱, 그리고 이 ‘어딘가’ 는 Cloud Foundry 에서 ‘스페이스’와 매핑될 수 있습니다. Sagan 애플리케이션의 경우 프로덕션, 스테이징, 그리고 개발 스페이스에 각각 배포될 수 있으며 각각 하나 이상의 복제본을 가집니다. 이렇게 배포된 각각의 Sagan 애플리케이션을 바로 클러스터라 합니다. 
  • 서버 그룹 (Server Group): 물리적으로 동작하고 있는 애플리케이션을 의미합니다. 서버 그룹은 Cloud Foundry 애플리케이션과 1 대 1로 대응됩니다. 서버 그룹은 변경 불가능한 배포 컨셉과 그들만의 이름으로 확정된 버전 넘버를 가집니다. 예를 들어 만약 sagan-prod-v001 을 배포했는데 버그가 있다면, 이 앱의 패치를 Cloud Foundry app 에 푸시하지 않습니다. 대신 여기에서는 새로운 sagan-prod-v002 애플리케이션을 패치와 함께 배포하고, 기존의 v001 를 없애는 방식으로 처리합니다. 
  • 인스턴스 (Instance) : 앱이 실제로 동작중인 인스턴스의 숫자를 의미합니다. 
  • 로드 밸런서 (Load Balancer) : Spinnaker 로드 밸런서들은 애플리케이션의 트래픽이 처리되는 장소 입니다. Cloud Foundry 에서는 인터넷 공간에 노출되어 애플리케이션들 즉 서버 그룹으로의 경로를 관장 합니다. 서버 그룹에 대한 활성 또는 비활성은 Cloud Foundry 경로를 매핑 하거나 매핑을 해제 합니다.

Cloud Foundry 에서의 Spinnaker 프로세싱 흐름 

Spinnaker 는 여러개의 마이크로 서비스로 이루어져 있으며 프로덕션 수준에서 독립적으로 관리되고 확장될 수 있습니다. Spinnaker 시스템의 주요 부분들은 아래와 같습니다.

  • Igor : Jenkins 빌드 잡들과의 연동과 Echo 서비스로 알림을 보내는 역할을 맡고 있는 서비스 
  • Echo : 이벤트를 딜리버리 파이프라인을 런칭하는 Orca 로 라우팅하는 서비스
  • Orca : 딜리버리 파이프라인을 실행하며 사전에 설정된 Cloud Foundry 의 Cloud Driver 에 요청을 보내는 서비스 
  • Cloud Driver : Jenkins 로 부터 애플리케이션 배포를 꺼내와 PCF 에 배포하는 서비스 
  • Deck : 실행 이력과 딜리버리 파이프라인의 상태를 보여주는 사용자 인터페이스 

이 서비스들이 서로 어떻게 동작할까요? 이 서비스들은 서로 단순화된 구조를 바탕으로 동작하며, 각 서비스의 연결과 처리 단계는 아래와 같습니다.

Step 1: 개발자는 코드를 커밋하고 이는 Jenkins 의 빌드의 시작과 연결됩니다. 
Step 2: Jenkins 는 빌드를 완료하고 애플리케이션 배포 아티팩트를 만들어 냅니다. 
Step 3: Igor 는 빌드의 완료를 확인하고 해당 빌드 이벤트를 Echo 에 보냅니다. 
Step 4: Echo 는 이벤트를 Orca 로 전달하고 이는 딜리버리 파이프라인 인스턴스를 시작하며 Cloud Driver 로 배포 요청을 보냅니다. 
Step 5: Cloud Driver 는 아티팩트를 Jenkins 로 부터 가져와서 PCF 에 배포를 수행합니다. 
Step 6: Cloud Driver 가 서버 그룹이 PCF 에서 활성화 되어 동작하는 상태를 검출하면 Orca 파이프라인이 완료 됩니다. 

오픈소스 협업과 혁신 

Pivotal 과 Netflix 는 오픈소스에 대한 열정과 헌신을 공유하며, 혁신을 위해 함께 협업 합니다. Spinnaker 는 Pivotal 의 Spring IO 포트폴리오 (Spring Boot, Spring MVC, Spring Batch, etc) 에 기반해 작성 되었으며, Spinnaker 자체가 Spring 기반으로 만들수 있는 애플리케이션의 대표적인 사례입니다. 또한 Netflix 는 그 스스로 Spring 커뮤니티의 활동적인 구성원으로서 다양한 Spring 프로젝트에 공헌 하였으며 이에 대한 경험을 SpringOne2GX 와 같은 Spring 커뮤니티 행사에서 발표하기도 했습니다. 
Pivotal 역시 매우 많은 Netflix OSS 프로젝트에 기여하고 있으며 이를 Netflix OSS 와 Spring Cloud 의 결합을 바탕으로 Spring Cloud Services for Pivotal Cloud Foundry 라 불리는 서비스를 발표하기도 했습니다. 이는 엔터프라이즈 개발과 운영팀에가 새로운, 프로덕션 레벨의 Cloud Native 애플리케이션 아키텍처를 구성하는 기반이 될 것입니다. 

Spinnaker 는 Netflix 의 수년간의 클라우드 경험과 노력의 상징이 패키지화 된 것인 동시에 오픈소스에 대한 기업의 기여를 대표하는 프로젝트 입니다. 기존의 CI 플랫폼 기반의 커스텀 배포 워크플로우를 클라우드에 사용하고자 했던 개발자들에게 Spinnaker 는 더 많은 가치를 전해 줄 것입니다. 또한 Spinnaker 프로젝트는 오픈소스 월드에서 커뮤니티를 통해 서로 다른 기업들이 협업하는 모델의 입지전적인 사례가 될 것입니다. 

 

더 알아보기: 




반응형