Update: 스핀에커(Spinnaker)를 생성하고 관리할 수 있는 테라폼 모듈 프로젝트 저장소(https://github.com/Young-ook/terraform-aws-spinnaker) 에서 구체적인 내용을 확인할 수 있다. 스핀에커 테라폼 모듈 외에도 AWS 계정을 스핀에커에서 관리할 수 있도록 등록하는 방법, Amazon EKS 클러스터를 생성하고 스핀에커에서 관리할 수 있도록 등록하는 방법, 카오스 엔지니어링1을 위한 카오스 몽키(Chaos Monkey) 연동방법 등 스핀에커 모범 사례 예제가 제공된다.
|
|||
넷플릭스(Netflix)에서 2016년에 꽤 발칙한 소프트웨어(Software)를 공개했다. 스핀에커(Spinnaker, https://www.spinnaker.io) 라는 도구인데, 공개되자마자 많은 사람들의 관심을 받았다. 스핀에커가 관심을 받은 이유는 편리함과 세련됨을 동시에 가졌기 때문이다. 어플리케이션 서버(Application Server)의 개발부터 운영까지 일관되게 관리할 수 있도록 파이프라인(Pipeline)을 지원하는 것은 기본이고, 모든 진행환경을 직관적이고 투명하게 볼 수 있도록 해준다. 게다가, 화면구성은 효과적이고 세련되서 전 세계에 걸쳐있는 매우 많은 양의 서비스 서버들을 한 눈에 확인할 수 있다. 필요한 경우 개별 서버를 지정해서 바로 새 인스턴스(Instance)로 교체하는 것도 가능하다. 인스턴스 각각을 눌러서 로그(System Log)를 파악하는 것도 쉽다. 그리고 AWS는 물론, GCP(Google Cloud Platform), Kubernetes와 같은 컨테이너(Container) 환경도 지원한다. 이러한 특장점 때문에 마이크로서비스(Microservices) 와 같이 매우 많은 수의 서버가 전 세계에 걸쳐서 쉴새없이 만들어지고 사라지는 운영환경을 매우 효과적으로 지원할 수 있다.
Spinnaker Pipline (https://medium.com/netflix-techblog)
스핀에커는 위 그림에서 볼 수 있는 전체 파이프라인 중 지속적 통합(Continuous Integration, CI)2이후를 담당한다. 원칙적으로 지속적 전달(Continuous Delivery, CD) 3은 지속적 통합을 품고있는데, 지속적 전달은 지속적 통합이 잘 되어 있다는 가정아래 운영환경까지 자동화를 확장하는 개념이기 때문이다. 그러나 스핀에커는 약간 힘을 뺐다. 기존에 잘 하고있던 지속적 통합은 그대로 유지하고 스핀에커와 잘 연동하도록 설계 하였다.
다음으로 스핀에커를 이해하기 위한 주요 구성요소를 살펴본다. 스핀에커는 크게 두 가지 구성요소로 나누어져 있는데, 클러스터(Cluster)와 배포(Deployment, Delivery)다.
Deployment/Delivery Management (Pipeline)
배포관리는 어플리케이션을 어떤 절차에 맞추어 운영할 것인지 결정하는 부분이다. 가장 핵심적인 것은 파이프라인인데, 어플리케이션의 배포, 검증, 상태점검, 복구 등의 개별 작업들을 순차적 또는 동시다발적으로 수행하도록 잘 엮어주는 기능을 한다. 파이프라인은 지속적 전달에서 제일 중요한 개념인데, 지속적 전달의 목표를 달성하기 위해서는 반드시 자동화된 파이프라인이 반드시 필요하기 때문이다. 그 이유는 사소하고 조그만 변경이 발생하더라도 운영에 내놓을 수준까지 빠르게 포장하고 검증하여 운영환경까지 자동으로 내보내겠다는 것이 지속적 전달/배포의 목표이기 때문이며, 동시에 어플리케이션의 변경과 복구에 대하여 사용자가 불편을 느끼지 않도록 하는 것이 목표이기 때문이다.
스핀에커에서 배포관리는 파이프라인을 통해 이루어 진다. 파이프라인은 여러 종류의 스테이지(Stage)를 연결하여 구성한다. 스테이지는 일종의 작업(Task)을 의미한다. 스핀에커에는 미리 만들어진 스테이지 들이 있으며, 대부분 미리 제공받은 스테이지만으로도 충분하다. 만약 사용자가 따로 구현하고 싶은 기능이 있다면, Shell script, 젠킨스(Jenkins) 스테이지를 이용할 수 있다.
Pipeline (https://spinnaker.io)
스핀에커에서는 여러가지 배포방식을 선택할 수 있고, 필요에 따라 직접 만들어서 사용할 수도 있다. 일반적으로 Red/Black을 사용해서 배포하면 큰 문제는 없다. 새로운 이미지(Machine Image)를 이용해서 새로운 서버그룹(Server Group)을 만든 다음 상태확인(Health check)를 통과하면 예전 서버그룹을 삭제한다. 빠른 복구(Rollback)을 위해 이전 버전 서버그룹에 대한 정보는 남겨둔다. 따라서 클라이언트(Client) 입장에서는 무중단으로 서비스를 이용할 수 있다. 다음은 스핀에커에서 지원하는 다양한 배포방식에 대한 설명이다.
Deployment Strategy (https://spinnaker.io)
Cluster Management
- 클러스터(Cluster)는 높은 가용성 (HA, High Availability)를 지원하기 위하여 서버그룹들을 묶은 논리적인 집합니다.
- 서버 그룹(Server Group): 스핀에커에서 관리할 어플리케이션 서버들의 집합을 말한다. 서버 그룹에서는 어떤 이미지를 이용하여 몇 개의 인스턴스를 어떤 종류로 만들 것인지에 대한 정보를 담고 있다. 서버 그룹을 AWS 에서 실제 구현하면 론치 콘피그(Launch Configuration)과 오토스케일링 그룹(Auto-Scaling Group)의 묶음이 된다.
- 시큐리티 그룹(Security Group, Firewall): 네트워크의 흐름을 제어하도록 정의하는 것을 말한다. IP 주소범위표현식(CIDR)과 통신규약(Protocol), 포트 (Port)번호를 이용하여 규칙을 생성한다. AWS에서 구현한 실체는 시큐리티 그룹이며 쿠버네티스에서 구현한 실체는 방화벽(Firewall)이 된다.
- 로드 발란서(Load Balancer): 입력으로 들어오는 요청을 서버 그룹으로 잘 분배하는 기능을 한다. 기본적으로 스핀에커에서 다루는 서버 그룹은 기본적으로 로드 발란서와 함께 동작한다. 클러스터(Cluster): 스핀에서에서 정의한 서버 그룹의 집합이다.
Cluster (https://spinnaker.io)
스핀에커는 많은 면에서 개발 및 운영업무의 생산성을 높여주었다. 직관적이고 효율적이면서 담백하다. 그러나 한가지 주의해야할 점이 있다. 스핀에커는 지속적 전달이라는 데브옵스 또는 애자일 방법을 잘 구현한 도구이다. 따라서 지속적 전달에의 개념과 이론에 대하여 충분한 공감이 있어야 가장 효율적으로 사용할 수 있다. 지속적 전달(Continuous Delivery)에 대한 자세한 내용는 긴 이야기가 될 수 있기 때문에 따로 다루려고 한다.
스핀에커는 넷플릭스(Netflix)에서 AWS환경을 중심으로 개발하여 운영하다가 2016년 깃허브(GitHub)에 공개하였다. 이후 구글(Google)에서 매우 큰 관심을 보였고, 자신들의 필요에 따라 권한관리 기능 등 매우 굵직한 기능들을 추가하였다. 마이크로소프느(Microsoft)에서도 관심을 가지고 있으며, 애저(Azure)와 연동하도록 개발하였고 자신들의 적용사례를 공유하였다. 이렇게 뜨거운 관심을 받고 있는 스핀에커는 2017년 6월 버전 1.0을 발표하고 대규모 기업(Enterprise)의 요구수준까지 맞출 수 있을만큼 발전하였다.