Spinnaker Architecture
Update: 2018년 11월 기준으로 할야드(Halyard)는 많이 안정화 되었다. AWS EKS 위에 스핀에커를 설치하는 동안 큰 문제는 없었다. 예전에 겪었던 인증 정보(Credential)를 날려버리는 오류도 없어졌다.
Update: 2018년 10월 Spinnaker Summit에 참석해서 넷플릭스(Netflix) 엔지니어에게 놀라운 이야기를 들었다. 자신들이 사용하는 스핀에커는 1개의 인스턴스에서 동작하고 있다고 한다. 아키텍처는 위의 그림처럼 마이크로서비스(Microservices)지만 분산된 인스턴스에 나누어져 있지는 않다고 했다. 그리고 스핀에커 자체를 배포할 때도 레드/블랙(Red/Black) 배포 방식을 사용한다고 했다. 최신 기술의 현란함을 따르기보다 투박하지만 실용적으로 접근하는 모습이 인상적이었다.
스핀에커(Spinnaker)는 여러 개의 마이크로서비스(Microservices) 조합으로 이루어져 있다. 그래서 (수평)확장에 용이하다. 아래 그림은 Netflix에서 어떻게 Spinnaker를 구성해서 사용하고 있는 지를 보여주고 있다. Netflix에서 사용 중인 Spinnaker는 크게 외부로 열린 Deck와 Gate, 그리고 내부에서 동작하는 Orca, Rosco, Front50, Igor, Clouddriver, Echo, Fiat 등으로 구성되어있다. 지금도 몇 개의 마이크로 서비스가 새로 생기고 있다. Rush는 오래 전부터 사용하지 않는다고 한다. 각 마이크로서비스들은 클러스터로 이루어져 있다. 1
최근에는 할야드(Halyard)를 이용하면 쉽고 간편하게 아래 그림과 같이 분산된 형태로 스핀에커를 구성하고 배포할 수 있다. 할야드로 분산배포하는 것은 쿠버네티스(Kubernetes) 환경 밖에는 안된다. 기존 VM 환경에 익숙한 사람들에게는 아쉽겠지만, 쿠버네티스 위에 스핀에커 분산환경을 구축하는 것은 충분히 괜찮을 것 같다.
여기서 재밌는 것은 할야드는 배의 돛을 올리는 밧줄을 뜻한다. 스핀에커가 큰 삼각형의 돛이니까 스핀에커를 띄우기 위해서라면 할야드만큼 좋은 것은 없을 것 같다. 이름만 들어서는 그렇긴 한데, 2017년 7월 기준으로는 안되는 기능도 있고 버그도 좀 있었다. 가장 치명적이었던 것은 사용자 인증을 위한 보안 키를 덮어써서 할야드에 잘 입력한 값이 실제 배포 후에는 지워지는 일이었다. 할야드는 베타기능이므로 지켜보다가 사용하는 것이 좋을 것 같다.
Spinnaker Architecture at Netflix (https://blog.spinnaker.io/scaling-spinnaker-at-netflix-part-1-8a5ae51ee6de)
스핀에커를 위와 같이 분산된 형태로 배포하는 가장 큰 이유는 유연성, 확장성을 얻기위해서다. 다시말하면, 스핀에커는 마이크로서비스의 철학을 따르고 있고 그래서 마이크로서비스의 장점을 그대로 가지고 있다. 그러나 단점도 그대로 가진다. 자잘한 서비스(Service)들이 많이 있기 때문에 관리가 어렵고, 서비스들의 네트워크 통신을 위한 보안을 신경써야한다. 네트워크 통신을 하기때문에 속도도 느리고 처리 비용도 많이 든다.
Name
|
Functionality
|
Port
|
Deck
|
User interface.
|
9000
|
Gate
|
Api gateway. All external requests to Spinnaker are directed through Gate.
|
8084
|
Orca
|
Orchestration engine of pipelines and ad hoc operations.
|
8083
|
Clouddriver
|
Interacts with and mutates infrastructure on underlying cloud providers. Encapsulates all cloud operations.
|
7002
|
Rosco
|
Machine image bakery. A machine image is a static view of the state and disk of a machine that can be 'deployed' into a running instance. Representation varies by cloud provider.
|
8087
|
Front50
|
Interface to persistent storage, such as Amazon S3 or Google Cloud Storage.
|
8080
|
Igor
|
Interface to Jenkins. Can both listen to and fire Jenkins jobs and collect contextual job and build information.
|
8088
|
Echo
|
Event bus for notifications and triggers. Triggers are things like git commits, Jenkins jobs finishing and other Spinnaker pipelines finishing. Notifications can send emails, slack notifications, SMS messages, etc.
|
8089
|
Fiat | Fiat is the authorization server for the Spinnaker system. | 7003 |
Rush | General purpose scripting engine. (Deprecated) | |
Halyard | A tool for configuring, installing, and updating Spinnaker. | 8064 |
Keyenta | Automated Canary Analysis platform | 8090 |
스핀에커는 한 개의 서버(Server)에 모든 마이크로서비스들을 설치해서 구동할 수도 있다. 모놀리틱(Monolithic)보다는 유연성과 확장성을 얻을 수 있고 여기저기 분산된 형태보다는 보안을 위한 비용을 아낄 수 있다. 이렇게 구성하면 서비스들들 사이의 통신이 localhost 호출이 되기 때문에 외부 망과의 접점을 최소화 할 수 있어서 보안을 위해서 해주어야 하는 일들이 매우 단순해지기 때문이다. 모든 서비스들이 localhost의 접속만 허용하도록하고 외부로부터는 SSH 터널링(Tunneling)만 허용한다면 외부로부터의 접속은 최소화하면서 서비스들 간의 통신에 발생하는 통신보안 비용을 줄일 수 있다. 따라서, Local 배포는 보안비용을 줄일 수 있는 장점이 있지만 가용성이 떨어지게 되는 단점이 있다.