Spinnaker Versions

스핀에커(Spinnaker)는 버전(Version)관리를 위해 BOM(Bill of Materials)을 적용하였다. BOM은 전통적인 제조사에서 주로 사용하는 말이며, 소프트웨어 쪽에서는 그렇게 친숙한 단어는 아니다. 삼성전자와 같은 제조사는 여러 협력업체에 발주한 부품을 조립하여 최종 제품을 생산한다. 예를들어, 휴대전화를 만들경우 화면은 어느 부품을 사용하고 배터리는 어느 부품을 조합에서 생산할 지 명세하는 것이다. 이럴 경우, 전체 그림을 그리는 설계도가 필요한데, 이 것을 BOM이라고 부른다. 스핀에커에 BOM을 적용한 후로는 각 마이크로서비스(Microservices) 단위의 버전을 따로 말하지 않고 큰 틀에서 지정한 단일 버전을 발표하고 있다.

그렇다고해서 기존에 지켜오던 버전이 사라진 것은 아니다. 오히려 BOM 안에서 어떤 버전의 마이크로서비스들로 구성되었는 지 명세하고 있으므로, 기존에 각 마이크로서비스가 갖고 있던 버전은 유지하고 있다. BOM을 발행한 이유는 각 마이크로서비스 버전들의 궁합을 잘 맞춰보고 어느정도 검증을 거친 것만 배포하기 위함이다. 구글(Google)의 스티븐 킴도 할야드(Halyard)를 권장했는데, 그 이유는 구글이 먼저 기능을 검증한 다음 BOM을 발행하고 할야드는 BOM을 기준으로 배포하기 때문이라고 말했다. 그래서 할야드로 갈아탈 것을 권유받았고, 지금은 할야드 기반으로 여러 개의 스핀에커를 잘 관리하고 있다. BOM은 구글(Google) 중심으로 만들고 있으며, 여전히 넷플릭스(Netflix)에서 사용하던 버전도 존재한다. 시간이 지나면 차츰 BOM으로 합쳐질 것이라고 예상한다. 그런데 현재 스핀에커는 크게 세 가지 버전을 발행하고 있다. 다음과 같이 1.11, 1.10, 1.9 를 동시에 관리하고 있다.
 

Versions (https://spinnaker.io)

 
1.4, 1.5 처럼 BOM을 적용한 후 단일 버전을 잘 발행하다가 뜻하지 않게 여러 갈래를 만난 것이다. 스핀에커를 처음 사용했을 때는 넷플릭스에서 발행하던 버전뿐이어서 그 쪽을 계속 따라왔었다. 그래서 BOM으로 관리하는 버전은 그냥 지나쳤다. 이제 할야드(Halyard)기반으로 설치하도록 준비했는데, 버전이 여러 갈래로 나눠져 있어서 혼란스러웠다.
그래서 운영을 위한 버전은 1.10을 선택했고 기능 및 안정성 점검을 위한 테스트 버전은 1.11을 선택했다. 그러나 1.10에서 꽤 버그(Bug)가 많이 발견되었다. 그래서 1.9로 갈아타려고 시도했었다. 그러나 여기서 예상하지 못한 문제를 발견했다. 1.9버전에서는 Orca-sql을 지원하지 않았다. 일단 운영 중인 상황이었고 1.9로 갈아타면서 오르카(Orca)는 예전처럼 레디스(Redis)를 사용하도록 변경하였다. 동시에 1.11 버전에서도 문제가 발생하였다. 레디스 4.0에서 제대로 동작하지 않았다. 그래서 엘라스티캐시(Elasticache)의 레디스를 5.0으로 변경하여 점검해 보았다. 그랬더니 잘 동작하는 것이었다.

결국, 세 가지 버전으로 갈래가 나누어진 이유는 인프라스트럭처(Infrastucture)의 구조가 변경되었기 때문에 쉽게 버전을 갈아타지 못하는 상황이 발생했기 때문이었다. 1.9는 기존환경을 그대로 유지하는 상황이고, 1.10은 많은 사용자를 감당하기 위해 고가용성 (HA, High Availablity) 기능을 추가한 것이고, 1.11은 추가로 레디스를 변경한 것이었다. 확인한 결과를 따라, 앞으로 생성하는 버전들은 1.11을 기준으로 삼을 것이다. 특히 1.10 버전은 오류가 너무 많다.