[컴퓨터월드]

현재 인터넷에 존재하는 대부분의 서비스들은 서버와 네트워크, 그리고 스토리지로 이루어져있다. 그리고 그 대부분의 서비스들은 지속적으로 업데이트돼 고객이 원하는 기능이 추가되거나 제거된다. 또한 그 과정에서 새로운 제품이 출현하기도 한다.

이런 과정을 반복하면서 회사들은 시장점유율을 늘려나간다. 특히 이러한 과정을 빠르게 반복하는 회사일수록 시장에서 기업의 영향력은 확대된다. 아마존, 넷플릭스, 페이스북, 유튜브, 구글 그리고 트위터 같은 미국 회사들 뿐만 아니라 알리바바나 바이두와 같은 중국의 서비스 기업들이 빠르게 성장할 수 있었던 것도 이런 이유 때문이었다.

이런 서비스들은 ‘중지 없이’ 제공되는 것이 매우 중요하다. 중단없는 서비스는 고객이 언제나 원할 때 서비스에 접근할 수 있다는 믿음을 갖게 해준다. 그러나 이런 믿음이 깨질 때, 앞서 언급한 회사들의 주가는 요동친다.

뉴스에서 접했겠지만 삼성전자의 반도체나 메모리 공장의 가동 중지와 그 중지가 야기하는 손실액 규모는 상상을 초월한다. 손실 규모를 초단위로 계산할 수 있을 만큼 손실 규모는 천문학적이다.

대부분의 엔터프라이즈 시장에서 소프트웨어는 이런 제조업과 유사하게 취급된다. 변경보다는 변경하지 않아야 더 안전하다. 그래서 업데이트는 아주 중요한 문제가 아니면 하지 않는다. 중요한지 중요하지 않은지를 가리는 수차례 타이틀 방어전이 끝나야 비로소 업데이트를 수행한다. 잘못이 생기면 어떻게 다시 원래대로 고쳐놓을지의 계획도 수립해야 한다. 수백억을 들여서 DR(Disaster Recovery, 재해복구) 시스템을 준비했지만, 그 시스템이 제대로 동작할지는 아무도 알지 못한다.

위의 그림은 그 대단하다는 넷플릭스 역시 이런 문제에서 자유로울 수 없다는 점을 보여주고 있다. 변화의 주기가 빠르면 서비스 가용성도 그만큼 손해를 볼 수밖에 없다. 따라서 가용성을 높이기 위해서는 변화의 주기를 느리게 가져야 한다. 하지만 넷플릭스가 다른 점은 바로 이 그래프 전체를 바꾸는 것이다. 즉, 변화의 주기를 빠르게 하더라도 서비스의 가동시간에 손해를 보지 않도록 하는 것, 이런 생각을 실행으로 옮기는 것이 바로 넷플릭스의 강력한 인프라를 유지하는 핵심 사상이다.

변화의 주기와 가용성
이번 기고에서는 인프라를 구동하고 유지하기 위해 필요한 다양한 기술과 도구를 살펴보도록 하겠다. 필요하다면 제시되는 도구들 중 일부를 직접 서비스에 도입할 수 있겠지만, 이 기고의 목적은 발상과 사고의 전환을 통해 서비스의 구조를 어떻게 개편할수 있는지에 대한 아이디어를 제공하는 것이다. 실존하는 도구와 그 도구의 동작 방식을 소개하고, 그 운용의 핵심 원리에 대한 이해와 각각의 기능이 왜 필요한지에 대해서도 설명한다.

보쉬는 리눅스 파운데이션의 지원을 받는 클라우드 파운드리 프로젝트의 요소중 하나다. 보쉬의 핵심 기능은 아래와 같다.

- 원하는 클러스터 배포
- 배포된 클러스터의 확장 및 축소
- 배포된 클러스터의 무중단 업데이트
- 다양한 클라우드 서비스 지원: 아마존 웹서비스(Amazon Web Services), 마이크로소프트 애저(Microsoft Azure), 구글 클라우드 플랫폼(Google Cloud Platform), 브이엠웨어 브이스페어(VMware vSphere), 오픈스텍(OpenStack) 등
- 모니터링과 모니터링을 통해 문제 발생시 클러스터 복구(자가 치유)
- 서버에서 동작하는 데몬 역할을 하는 서비스 애플리케이션 릴리즈 관리

즉 보쉬는 서비스에 배포되는 모든 도구들에 대한 라이프 사이클 관리 도구라고 할 수 있다. 따라서 구조적으로 보쉬는 배포에 사용되는 다른 도구들과는 큰 차이점이 있다. 배포에 사용하는 인기 있는 도구들, 특히 데브옵스 도구들로 불리는 것들은 거의 대부분 ‘언어’ 또는 ‘프레임워크 기반’이다. 이런 도구들은 그 기능이 조금씩 다르기는 하지만, 대부분 인프라 엔지니어가 항상 동일하게 배포해야 하는 다양한 서비스들에서 배치성으로 동작한다.

보쉬는 마이크로 서비스들로 구성된 하나의 체계이다. 이는 각각의 배포에 정의된 내용을 바탕으로 그 클러스터가 제대로 동작하는지 확인하고, 동작하지 않는다면 복구를 시도한다. 아래는 보쉬의 아키텍처를 나타낸다.

CLI
커맨드 라인 인터페이스를 말한다. 보쉬는 CLI를 통해 제어된다. 커맨드는 bosh이며, help를 치면 사용 가능한 명령어 리스트들이 등장한다. CLI가 통제하는 보쉬 디렉터와 네트워크로 통신이 가능해야 한다. 보통은 점프박스에 설치하거나, 보쉬 디렉터가 위치하는 네트워크에 함께 설치하는 것이 일반적이다.

디렉터 (Director)
보쉬 시스템 체계를 제어하는 핵심 부분이다. 용도에 맞는 버추얼 머신의 생성과 제거, 및 생성된 버추얼 머신에서 동작하는 소프트웨어 및 서비스들의 라이프 사이클을 관리한다.

실제로 보쉬를 사용하다 보면 Task # 의 구조를 볼 수 있다. 이는 사용자가 원하는 동작을 CLI를 통해 받고, 이 각각의 커맨드는 보쉬 디렉터의 큐에 저장된다. 이 각각의 명령을 보쉬 입장에서는 Task로 처리하고, 유입된 순서에 따라 고유의 일련번호를 부여한다. 이 일련번호 체계를 통해 히스토리의 확인과 해당 커맨드가 만들어낸 보쉬의 로그를 확인할 수 있다.

또 보쉬 디렉터는 빌드와 같은 태스크 처리를 위해 워커(Workers) 역할을 하는 가상머신을 만들기도 한다. 예를 들어 새로운 버전의 MySQL 릴리즈가 배포 되어야 한다면, 이 릴리즈에 필요한 코드를 다운 받아 컴파일을 진행한다. 이때 보쉬 디렉터가 직접 컴파일 하는 것이 아니라 워커가 수행하며, 따라서 컴파일에 사용되는 가상 머신은 프로세싱 파워가 더 좋은 것을 사용한다던지 하는 방식으로 컴파일 속도를 높일 수 있다.

디렉터의 중요 요소중 하나인 CPI(클라우드 프로바이더 인터페이스, Cloud Provider Interface)는 가상 머신의 생성과 삭제 등의 클라우드 서비스 별 다른 API를 보쉬를 통해 동일하게 처리할 수 있도록 돕는 역할을 한다. 즉, 보쉬가 어떤 CPI를 가지고 있는가에 따라 지원하는 클라우드 서비스 공급자가 추가된다.

이전에는 보쉬 내부적으로 다른 코드와 결합되어 있었지만, 더 다양한 클라우드 서비스 공급자의 지원을 위해 핵심 코드에서 분리해 내었다. 결과적으로 마이크로소프트나 구글의 엔지니어들이 보쉬의 CPI개발에 참여하면서 다양한 서비스를 제공하고 있다. 즉 바꾸어 말하면, 각각의 클라우드 서비스 공급자들이 보쉬의 API를 사용해 자사의 클라우드에 서비스를 배포하도록 지원하고 있다는 것이다.

헬스 모니터(Health monitor)
이름이 의미하듯 생성된 가상 머신들의 상태를 모니터링 한다. 보쉬를 통해 생성되는 가상 머신에 동작하는 에이전트가 가상 머신이 처음 시작되면 정상적으로 시작 되었는지 등에 대한 정보를 헬스 모니터에 보내도록 한다. 이 헬스 모니터는 보쉬 디렉터의 통제를 받고, 만약 특정 수량으로 동작해야하는 가상 머신에 문제가 발생하면 그 사실이 있는지의 여부를 디렉터에 보고한다.

리저렉터 (Resurrector)
리저렉터는 헬스 모니터를 통해 동작을 원하는 가상 머신 숫자보다 실제 동작하고 있는 가상 머신의 숫자가 다른 경우에 관여한다. 예를 들어 카프카(Kafka) 클러스터를 배포했는데 이들 중 하나에 문제가 발생했다면 그 한 개를 즉시 신규로 생성한다. 옵션을 통해 켜거나 끌 수 있다.

DNS 서버
보쉬는 내부적으로 파워DNS(PowerDNS)를 사용해 네임서비스를 사용할 수 있다.

데이터 저장소
보쉬가 사용하는 데이터 저장소는 크게 두가지이다. 하나는 업로드된 소프트웨어 패키지를 저장하는 용도인 Blob저장소이며, 다른 하나는 스템셀의 버전, 각각 소프트웨어 릴리즈 및 배포에 대한 데이터를 보관하는 포스트그레스-큐엘(PostgreSQL)이다. 블럽 스토어는 아마존의 경우엔 보통 S3를 사용한다.

보통 디렉터를 처음 배포할 때 이런 저장소를 어떻게 사용할지를 정할수 있다. 디렉터 로컬에 같이 설치해서 사용하거나, 외부 데이터베이스를 사용하거나 S3와 같은 스토리지 옵션을 선택할 수 있다.

에이전트(Agent)
보쉬로 배포된 모든 가상머신에는 에이전트가 존재한다. 이 에이전트는 보쉬를 통해 배포되는 스템셀에 존재하므로, 가상머신을 켜자마자 즉시 함께 동작한다고 보면 된다. 에이전트는 디렉터로 부터 할당된 태스크를 처리한다.

예를 들어 MySQL 클러스터를 HAProxy와 함께 설치한다고 하면, 디렉터는 이 클러스터 구성에 필요한 소프트웨어 패키지와 설정을 에이전트에 전달하고 에이전트는 이렇게 받은 정보를 바탕으로 가상 머신을 구성한다. 이런 동작에 따라 어떤 가상 머신은 프락시로, 어떤 가상 머신은 마스터 데이터베이스로, 또 다른 가상 머신은 슬레이브로 구성한다. 경우에 따라서는 갈레라 클러스터를 만들기도 한다.

메시지 버스(NATS)
보쉬 시스템 체계는 아주 가벼운 메시지 도구인 NATS를 사용한다. 이 메시지 버스는 기본적으로 서로 다른 보쉬의 도구들에 정보를 제공하는 중요한 역할을 한다. 이전에 설명한 헬스모니터 부분에서, 헬스 모니터 서비스는 직접 각각의 가성 머신에 접속해서 상태를 파악하기 보다는, 각각의 에이전트가 메시지 버스에 자신의 가상 머신 상태를 퍼블리싱 하면 그 데이터를 헬스 모니터 도구가 살피는 방식이다.

이 메시지 버스에 흐르는 정보는 각각 배포에 대한 실시간 스트림 정보들이며, 이는 서비스들이 공통적으로 참조할 수 있는 구조로 만들어져 있다.

레지스트리(Registry)
가상 머신의 에이전트와 디렉터가 처음 통신에 성공하고 나면, 디렉터는 각각의 가상머신을 레지스트리에 보관한다. 하쉬 코프의 Consul이 사용된다. 이 정보는 가상 머신이 한대로 동작하지 않고 클러스터로 동작해야 하는 경우, 이 클러스터 설정에 필요한 참조 정보에 사용할 수 있다.

예를 들어 갈레라 클러스터를 보쉬로 배포한다면, 지정된 수량으로 가상 머신을 먼저 만들고, 만들어진 머신에 ‘업데이트’를 수행한다. 이 업데이트가 바로 보쉬 디렉터와 에이전트간 주고 받는 설정, 패키지, 상태 정보이며, 이때 디렉터는 각각의 가상 머신의 아이피 주소와 클러스터의 이름을 레지스트리에 보관한다. 이 정보를 통해 각각의 클러스터 멤버는 다른 클러스터 멤버가 누가 있는지를 참조할 수 있다.

스템셀 (Stemcell)
스템셀은 가상머신 템플릿으로 이해해도 좋다. 스템셀의 버전명은 보통 메이저는 앞의 네자리, 마이너는 점(.) 이하 두자리로 표현한다. 이 가상머신 템플릿은 운영체제의 코어와 에이전트를 포함하고 있으며, CPI를 통해 사용할 수 있는 클라우드 서비스 공급자에 배포할 수 있도록 각각의 환경용 스템셀을 함께 제공하고 있다.

이 스템셀은 운영체제 업데이트 부분에 있어 매우 중요한데, 바로 클러스터가 동작하는 중에도 적용해야 할 CVE 업데이트가 있다면 즉시 적용할 수 있는 체계를 지원하는 근간이기 때문이다. 보통 우분투로 제공된다.

릴리즈(Release)
보쉬에서의 릴리즈는 각각의 가상 머신에서 동작해야 하는 소프트웨어의 소스코드, 설정 파라메터, 설정 템플릿, 시작 스크립트, 필요한 바이너리 등의 집합을 말한다. 예를 들어 특정 버전의 MySQL의 경우, 소스 코드와 데이터베이스 설정을 위한 값들, 그리고 my.cnf와 같은 설정 파일의 템플릿, 일부 SQL이 담겨있는 초기화 스크립트 등이 보쉬의 릴리즈가 된다. 이 릴리즈의 개념 역시 매우 중요한데, 스템셀과 더불어 가상 머신에서 동작하는 소프트웨어 패키지의 업데이트에 관여하기 때문이다.

즉, 보쉬가 하는 일은 설정에 따라 클러스터를 만들 때, 스템셀로 가상 머신을 깡통 운영체제로 시작한 후 릴리즈를 전달해서 배포를 수행하고, 이 배포가 정상적으로 수행되었는지를 모니터링하며 문제가 있을 경우 알람을 만들거나 또는 직접 복구를 수행하는 것이다. 더 중요한 점은 이런 배포가 자주, 그리고 언제나 수행할 수 있는 ‘재사용성’을 기반으로 설계 되었다는 점이다.

흐름도에 나오는 것 이전에 필요한 작업이 있지만, 이는 뒷부분의 연속 개선(Continuous Integration)부분에서 설명하도록 하겠다.

먼저 오퍼레이터는 보쉬 CLI를 사용해 ‘bosh deploy’라는 명령을 내린다. CLI는 디렉터에 배포를 명령하고, 디렉터는 이 배포 작업에 태스크 넘버링을 할당한다. 이후 지정된 수량의 가상 머신을 생성한다.

이 가상 머신은 사용을 원하는 클라우드 서비스 공급자의 API, 쉽게 말하면 아마존 EC2 서비스 API에 가상 머신 생성을 명령하고, 이 응답으로 가상 머신에 대한 네트워크 정보등을 받는다. 그러면 디렉터는 이 네트워크 정보를 레지스트리에 추가하고, 이 정보는 생성된 가상 머신의 에이전트에 전달된다. 에이전트는 이후 자신에게 할당된 설정 정보를 바탕으로 가상 머신을 준비한다.

이런 배포의 방법은 사람을 통해 발생할 수 있는 실수를 줄인다. 뿐만 아니라 같은 버전의 클러스터는 언재든 재사용해서 배포할 수 있다. 개발팀이 테스트 또는 개발용으로 사용해야 하는 다양한 서비스들을 이 방식으로 언제든 준비할 수 있다. 오퍼레이션 팀은 이 보쉬를 사용해 배포할 수 있는 다양한 패키지를 준비하면 된다.

더 중요한 것은 업데이트다. 대부분의 데브옵스 도구들은 업데이트에 상당히 취약하다. 예를 들어 현재 MySQL 클러스터를 운용중이고, 마이너 또는 메이저 버전을 업데이트 해야 한다고 가정하자.

대부분의 경우 새로운 MySQL 바이너리 또는 소스코드를 받아서 컴파일하고, 설정한 후에 해당 서버에 신규 버전의 MySQL을 전송하고, 설정 파일 수정이 필요하다면 수정해서 새로운 데이터베이스 버전을 구동한다. 모든 부분에서 사고가 발생할 수 있는 매우 취약한 체계다.

더 흥미로운 점은, 만약 서비스에 사용하고 있는 데이터베이스 클러스터가 이거 하나가 아니라 수십, 수백개인 경우에는 어떻게 처리할 것인가 하는 점이다. 마이크로 서비스에서처럼 말이다.

보쉬는 이런 문제에 대응한다. 오퍼레이터는 먼저 배포 클러스터의 설정 데이터를 만든다. 보쉬에서는 이 설정 데이터를 deploy-manifest.yml과 같은 YAML 파일로 만든다. 이 파일은 각각의 클러스터 배포에 필요한 설정 정보를 담고 있다. 처음에 신규로 생성하는데 몇가지 도구가 제공되지만, 몇번의 테스트를 통해 수정해야 한다. 그렇게 첫번째 버전이 만들어지면, 이후 소프트웨어 패키지나 스템셀의 업데이트에 따라 조금씩 수정해서 배포에 사용한다.

예를 들어 데이터베이스의 신규 릴리즈가 존재한다면, 이때 보쉬에 이 새로운 릴리즈를 업로드 한다. 경우에 따라서 새로운 릴리즈는 새로운 운영 환경을 요구할 수 있다. 더 많은 클러스터 멤버가 필요하거나, 가상 머신의 스펙이 변경되어야 하는 변경사항이 있다면, 이 manifest 파일을 수정해서 업데이트 한다. 테스트 환경에 이 새로운 릴리즈가 잘 배포되어 동작하는지 확인했다면, 보쉬를 통해 bosh deploy 커맨드를 수행한다.

이때 보쉬 디렉터는 그냥 새로운 버전을 배포하지 않는다. 보통 카나리(Canary) 배포의 방법을 사용한다. 카나리 배포란, 프로덕션에 업데이트를 반영할 때 지정된 수의 가상 머신에 먼저 배포를 해 보고, 이 방법이 지정된 횟수로 성공하면 나머지 클러스터 전체를 업그레이드 하는 방법이다. 만약 문제가 발생한다면, 문제 발생 시점에 즉시 중단한다.

오퍼레이터의 주요 역할은 다음과 같다.

- 배포 manifest 의 관리
- 서비스 요구에 따른 릴리즈 준비, 디렉터에 업로드
- 운영체제 업데이트 요구에 따른 스템셀 준비, 디렉터에 업로드
- 서비스에 필요한 다양한 소프트웨어를 보쉬를 통해 사용 가능하도록 준비

다음 링크에서는 보쉬와 컨커스(Concourse)라는 오픈소스 도구를 사용해 인프라에 CI를 적용한 내용을 설명하고 있다. (http://www.engineerbetter.com/blog/bosh-concourse/)

인프라에 있어 지속적인 업데이트는 매우 중요하다. 성능과 보안에 직결된 문제이며, 서비스 보안의 실패는 사업에 치명적인 영향을 미친다. 따라서 이미 알려진 보안 취약점에 대비하는 가장 좋고 기본적인 방법은 시대에 뒤쳐지지 않는 시스템 업데이트다. 규모와 관계없이 안전한 업데이트를 언제든 수행할 수 있는 능력은 서비스에 굉장한 장점을 가져다 준다.

컨커스 자체는 다음 기회에 설명하기로 하고 혹시 관심 있는 독자는 http://concourse.ci 및 http://ci.concourse.ci를 방문하기를 권한다.

넷플릭스는 월요일 아침 9시에 서비스 업데이트를 진행한다고 한다. 모든 사람이 사건 현장에 있을 때 가장 빠른 대응이 가능하기 때문이다.

하지만 대부분의 회사들은 명절 연휴에 서비스 업데이트를 진행한다. 아니면 사용하는 사람이 가장 적을 것 같은 시간에 수행한다. 그러나 매주 다가오는 게임 서비스의 새벽 2시 정기점검을 좋아하는 고객은 아무도 없을 것이다. 또 배포나 업데이트가 잘못 수행되어 원복을 한다거나, 다시 신규 배포를 처리해야 하는 경우 점검 지연 역시 아무도 좋아하지 않는다. 누구나 문제라고 생각하는데 개선되지 않는 특이한 부분이라고 생각한다.

한가지 더 중요한 점은, 동작하는 서비스를 망가트려봐야 한다는 점이다. 서비스 데몬을 죽이고, 특정 역할의 서버 전원 케이블을 뽑는다거나 하는 것이 이 범주에 속한다. 정말 수많은 엔터프라이즈 회사들이 재해/장애 복구 솔루션을 구입하고 준비하지만, 오늘 그 시스템이 동작할 수 있다고 자신있게 말하려면 실제 그 상황을 경험해봐야 하는 이치다.

서버 전원을 뽑으면 무슨 일이 발생하는지 확인할 수 있다. 그것이 프로덕션 서비스용 서버라면 그 자체가 재앙이겠지만, 테스트나 스테이징 서버의 전원을 뽑는건 아마 다른 이야기가 될 것이다. 이때 얻는 ‘무슨 일이 생긴다’ 의 정보는 실제 동일한 장애가 발생했을 때 빠른 복구를 돕는다. 최근에 자주 언급되는 ‘카오스 엔지니어링’의 핵심이 여기에 있다. 먼저 문제를 일으켜 보고, 어떤 문제가 발생하는지 학습해서, 내성이 더 강한 서비스를 만드는 것이다.

전통적 서버의 운영과 관리는 ‘네버 다이’ 였다. 사업에서 지원 가능한 최대한의 자원을 투입해 ‘서버가 꺼지는’ 사태를 막는다. 하지만 모두 알듯, 그렇게 동작하는 서버도 언젠가는 꺼질 수 있고, 꺼지지 않는 불멸의 클러스터링 솔루션을 도입한다고 해도 내부 데이터 구조의 복잡성 등으로 인해 동작상태 확인이 거의 불가능하다.

물론, 이런 서비스가 필요한 구간이 존재한다. 아직 메인프레임이나 유닉스의 워크로드가 필요한 곳도 있다. 하지만 대부분의 엔터프라이즈 서비스에서는 이런 전통적 방법 대신, 변화를 자주 반영할 수 있는 안정적인 시스템이 필요하다.

인프라 업데이트, 숨쉬듯 진행돼야
그 안정적인 시스템을 구현 하는 방법의 시작은 상상해 보는 것이다. 지금 우리 서비스를 구성하고 있는 서버 중 한대의 전원 케이블을 뽑는다면, 어디가 괜찮고 어디가 괜찮지 않을까. 만약 현재 데이터베이스 서버의 전원을 뽑는다면 무슨 일이 벌어질 것인가. 그것이 전체 서비스의 다운으로 이어진다면, 아마도 여러분의 서비스는 개선이 필요할지도 모르겠다. 그리고 그 지점이 정확히 넷플릭스가 마이크로 서비스 전환을 시도한 계기이기도 하다.

보쉬와 같은 배포 도구의 동작과 구조를 보고 있으면 필요한 것은 운영에 있어 얼마나 많은 부분이 자동화 될 수 있는지를 알 수 있다. 사람은 의식적으로 숨을 쉬지 않는다. 호흡은 인간 생명 유지에 있어 아주 핵심적 활동이기 때문에, 인지 상태로 제어할 수 있는 기능에 속하지 않는다. 마찬가지로 서비스의 기능 업데이트와 그 근간이 되는 인프라 업데이트는 이런 호흡처럼 처리되어야 한다. 누가 인지하지 않더라도, 그냥 숨쉬듯 진행되어야 하는 것이다.

서비스 인프라를 다루는 방법이 크게 바뀌는 중이다. 이런 방법의 소개를 통해 더 안정적인, 강력한 서비스 인프라를 만들어 가는 계기가 되기를 바란다.

보쉬의 사용을 원하는 경우에는 bosh.io 의 가이드를 볼 수도 있으나 가급적이면 피보탈에서 제공하는 도구를 살펴보는 것을 권고한다. https://network.pivotal.io 에서 Operation Manager를 찾아 다운로드 받으면 되겠다.