본문 바로가기

카테고리 없음

Set up Orca to use SQL

스핀에커(Spinnaker)의 핵심 기능은 카나리 배포(Canary Deployment), 블루/그린 배포(Blue/Green Deployment)를 쉽게 지원한다는 것이다. 스핀에커에는 오르카(Orca)라는 마이크로서비스(Microservice)가 있으며, 배포를 포함한 전체 파이프라인을 관리하는 오케스트레이션(Orchestration) 기능을 담당한다. 그래서 흔히 지속적 전달(Continuous Delivery)도구를 이야기하면서 여전히 젠킨스(Jenkins)나 GitLab CI, Circle CI를 이야기한다. 그러나 그 어느 것도 오르카만큼 최신 배포 기술을 잘 지원하지 못한다. 만약 VM(Virtual Machine)환경 기반으로 블루/그린 배포를 하고 싶은 경우, 스핀에커를 제외한 다른 도구들은 도구 자체에서 이 기능을 지원하지 못한다. 사용자가 각 클라우드 제공업체(Cloud Provider)의 기능을 활용하여 직접 스크립트를 작성해야 한다.
 
이러한 명확한 차이점이 있음에도 스핀에커와 젠킨스를 비교하는 질문들이 많았다. 이러한 질문을 하는 사람들 중에는 순수하게 궁금해서 질문을 하는 경우도 있었지만, 상당 수의 사람들은 자신들이 사용 중인 젠킨스와 비교하여 스핀에커가 뚜렷하게 장점이 없다는 것을 확인받고 싶어했다. 어떻게 의중을 알 수 있었냐면, 그 사람들은 질문을 시작할 때 이렇게 말했기 때문이었다. "젠킨스로 지속적 전달을 잘 하고 있습니다. 꼭 스핀에커를 써야 하나요?", 그러나, 안타깝게도 스핀에커와 젠킨스는 경쟁상대가 되지 않는다. 젠킨스는 오랜 시간동안 개발자와 운영자를 도와 준 매우 고마운 도구이며 거의 만능의 기능을 가지고 있다. 하지만 범용성을 지향하다보니 필요한 기능은 플러그인(Plug-in)을 개발해야 사용할 수 있다. 이미 있는 플러그인을 설치하더라도 내부에서 실행할 작업을 직접 스크립트로 만들어야 한다. 최초 한 번만 고생해서 만들기만 한다면 견딜만 하겠지만, 실무에서는 전혀 그렇지 않다. 스크립트를 디버깅하기도 어려운데다 버전 관리는 알아서 따로 해야한다. 이러한 불편함을 극복하고 젠킨스의 파이프라인 시각화와 파이프라인 코드 플러그인을 설치할 수도 있다[각주:1]. 그러나 결정적으로 젠킨스는 클라우드 환경에서 안정적인 배포를 하기위한 오케스트레이션 플러그인이나 자체 엔진을 제공하지 않는다. 다시 말하면 AWS에 블루/그린 배포를 하기위해 직접 스크립트를 작성하고 그 스크립트를 검증하고 버전 관리하는 수고를 해야 한다는 뜻이다. 다만, 이러한 단점은 콘테이너 기술[각주:2]로 넘어가면 줄어든다. 젠킨스에 오케스트레이션 엔진이 없어도 되기 때문이다.
 
스핀에커의 오케이스트레이션을 담당하는 오르카는 스핀에커 버전 1.11 이상에서 큰 변화가 있었다. 기존에는 오르카의 실행 정보와 실행 결과를 레디스(Redis)에 저장해왔다. 그래서 빠른 응답속도를 얻을 수 있었지만, 스핀에커의 파이프라인 실행이력(Pipeline History)과 작업이력(Task History)은 최대 2주 밖에 저장할 수 없었다. 스핀에커를 처음 만든 넷플릭스(Netflix)에서는 배포를 자주 했고, 각 마이크로서비스 개발자가 직접 배포를 수행했기 떄문에 실행이력이 오래 남지않더라도 크게 문제가 되지 않았던 것으로 보인다. 그러나 내가 사용했던 대기업환경에서는 달랐다. 일단 개발 조직과 운영조직이 달랐다. 게다가 일부 서비스는 운영조직이 해외에 있었다. 그리고 여전히 배포를 위해서는 결재가 필요했다. 그리고 누가 언제 무슨 작업을 했는 지 기록을 남겨서 책임자를 찾아야 했다. 하지만 레디스는 캐시(Cache)였으므로 저장된 정보의 안정성보다는 속도가 중요했다. 그래서 가끔 파이프라인 실행이력이 사라지기도 했다. 파이프라인 설정에 대한 정보는 프론트50(Front50)에 안전하게 보관하므로 실행이력이 사라진다고 해서 큰 문제가 있는 것은 아니다. 그러나 2주 전에 누가 어떠한 작업을 했는 지, 그리고 그 작업한 내용으로 복구하고 싶을 때, 방법이 없었다. 차선책으로 배포할 때마다 배포내역을 위키(Wiki)에 따로 작성해 두는 방법을 활용했다. 물론 스핀에커의 단점을 보완하기 위해서 그렇게 한 것은 아니고, 전통적으로 배포내역을 보고서로 작성하는 대기업의 운영문화에 따라 그렇게 한 것이다. 목적은 달랐지만, 어쩄든 스핀에커의 단점을 보완해 주었다.
그러다가 2018년 10월 스핀에커 회담(Summit)에 참가했을 때, SQL DBMS을 활용하도록 개선하고 있다는 이야기를 들었다. 여러 사람들이 의견을 주고 받았다. 모두 이해하지는 못했지만, 레디스와 비교해서 좋은 점과 나쁜 점을 토론했었던 것 같다.


오르카를 위한 데이터베이스를 생성했다면 초기화 하는 AWS를 사용하는 경우라면 임시로 작은 EC2 인스턴스를 생성한 뒤 여기에 접속해서 작업을 해도 되지만, 생성한 인스턴스에 접근하기 위해서는 퍼블릭 서브넷(Public Subnet)에 생성하거나 문지기 서버(Bastion host)를 통과해서 접속해야 한다. 임시 용도라고 하지만 퍼블릭 서브넷에 인스턴스를 올려서 데이터베이스(DBMS)에 접근하는 것은 보안을 약화시키므로 좋다고 생각하지 않는다. 문지기 서버를 통과하는 것은 보안을 강화하는 측면은 있으나 작업에 번거로움이 있다. 
쿠버네티스(Kubernetes) 환경에 스핀에커를 설치했다면, Mysql에 접근하기 위해서 도커 이미지를 활용할 수 있다. 다음과 같이 Mysql 이미지를 쿠버네티스에 올리고 바로 접속하면 된다. 여기서 가정하는 것은 쿠버네티스는 스핀에커를 설치하기 위해 만든 것이고 이미 데이터베이스에 접근할 수 있는 설정이 마무리 된 상태라는 것이다.


$ kubectl run mysql-client --image mysql:5.7 --env MYSQL_ROOT_PASSWORD=supersecret
$ kubectl exec -it mysql-client-7478c5b966-fv5kw bash
mysql-client-7478c5b966-fv5kw :/$ mysql -h mysql.internal.domain -P 3306 -u mysqluser -p

데이터베이스 접근에 성공했다면, 다음의 명령을 실행해서 오르카가 데이터베이스를 사용할 수 있도록 초기화 한다.


CREATE SCHEMA `orca` DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

GRANT
  SELECT, INSERT, UPDATE, DELETE, EXECUTE, SHOW VIEW
ON `orca`.*
TO 'orca_service'@'%';

GRANT
  SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, REFERENCES, INDEX, ALTER, LOCK TABLES, EXECUTE, SHOW VIEW
ON `orca`.*
TO 'orca_migrate'@'%';

SET PASSWORD FOR 'orca_service'@'%' = PASSWORD('changeme');
SET PASSWORD FOR 'orca_migrate'@'%' = PASSWORD('changeme');

flush privileges;

작업을 다했다면, 꼭 삭제를 해야 한다.


$ kubectl delete deployment mysql-client

 

  1. 빌드 파이프라인 플러그인을 설치하거나 젠킨스 블루오션을 설치하면 된다 [본문으로]
  2. 도커 콤포즈(Docker Compose), 쿠버네티스( Kubernetes) 등 콘테이터 클러스터 기술은 오케스트레이션 엔진을 직접 포함하고 있다 [본문으로]