쿠버네티스는 컨테이너 오케스트레이션 분야의 절대 강자다.
전 세계에서 가장 큰 규모의 배포들을 뒷받침하지만, 그에 따른 대가가 따른다.

특히 소규모 팀에게는 유지 관리에 많은 시간이 들고 학습 곡선도 가파르다. trivago에서 4명으로 구성된 우리 팀이 이루고자 했던 목표에는 너무 많은 오버헤드가 됐다. 그래서 대안을 찾아봤고 — Nomad와 사랑에 빠졌다.

위시리스트

우리 팀은 모니터링과 성능 분석을 위한 여러 일반적인 서비스를 운영한다. Go로 작성된 메트릭용 API 엔드포인트, Prometheus exporter, Logstash나 Gollum 같은 로그 파서, InfluxDB나 Elasticsearch 같은 데이터베이스가 그 예다. 각 서비스는 독립된 컨테이너에서 실행된다. 우리는 이런 작업들을 안정적으로 유지해 줄 단순한 시스템이 필요했다.

컨테이너 오케스트레이션에 필요한 요구사항을 정리하는 것부터 시작했다:

• 다수의 머신에 걸쳐 서비스 플릿을 실행할 것.
• 실행 중인 서비스 현황을 한눈에 파악할 수 있을 것.
• 서비스 간 통신을 지원할 것.
• 서비스가 죽으면 자동으로 재시작할 것.
• 소규모 팀이 관리할 수 있을 것.

여기에 더해 있으면 좋지만 필수는 아닌 요구사항은 다음과 같았다:

• 머신의 역량에 따라 태그를 지정할 수 있을 것 (예: I/O가 많은 서비스를 위해 빠른 디스크를 갖춘 머신에 라벨 부여).
• 오케스트레이터 없이도 서비스를 독립적으로 실행할 수 있을 것 (예: 개발 환경에서).
• 설정과 시크릿을 공유할 수 있는 공통 공간이 있을 것.
• 메트릭과 로깅을 위한 엔드포인트를 제공할 것.

쿠버네티스가 우리에게 맞지 않았던 이유

쿠버네티스로 프로토타입을 만들면서, 서비스를 운영하기 위해 점점 더 복잡한 로직 계층을 쌓게 된다는 걸 알게 됐다. 그리고 우리는 그 로직에 암묵적으로 의존하게 됐다.

예를 들어 쿠버네티스에서는 ConfigMaps를 이용해 서비스 설정을 임베드할 수 있다. 특히 여러 설정 파일을 병합하거나 파드에 서비스를 추가할 때 금방 혼란스러워질 수 있다. 쿠버네티스 — 혹은 helm도 마찬가지지만 — 관심사 분리를 위해 외부 설정을 동적으로 주입할 수 있게 해준다. 하지만 이는 프로젝트와 쿠버네티스 사이에 단단하고 암묵적인 결합을 만들 수 있다. Helm과 ConfigMaps는 선택 기능이라 꼭 사용할 필요는 없다. 설정을 Docker 이미지에 그대로 복사해 넣을 수도 있다. 다만 그 길을 따라가다 보면 불필요한 추상화를 만들게 되고, 나중에 발목을 잡힐 수 있다는 유혹에 빠지기 쉽다.

게다가 쿠버네티스 생태계는 여전히 빠르게 진화하고 있다. 모범 사례와 최신 툴을 따라잡으려면 상당한 시간과 에너지가 든다. kubectl, minikube, kubeadm, helm, tiller, kops, oc — 목록은 끝없이 이어진다. 쿠버네티스를 시작하는 데 모든 툴이 필요한 건 아니지만, 어떤 것이 필요한지 알기 어렵기 때문에 최소한 그 존재는 알고 있어야 한다. 그래서 학습 곡선이 상당히 가파르다.

언제 쿠버네티스를 사용해야 할까

trivago만 해도 많은 팀이 쿠버네티스를 사용하고 있으며 꽤 만족하고 있다. 다만 이들 인스턴스는 이를 감당할 역량을 갖춘 Google이나 Amazon에서 관리한다.

쿠버네티스에는 대규모 컨테이너 오케스트레이션을 더 관리하기 쉽게 만드는 놀라운 기능들이 있다:

• 세분화된 권한 관리
• 커스텀 컨트롤러를 통해 클러스터에 로직을 넣을 수 있다. 이는 그저 쿠버네티스 API와 통신하는 프로그램일 뿐이다.
• 오토스케일링! 쿠버네티스는 필요에 따라 서비스를 자동으로 확장하고 축소할 수 있다. 수동 개입 없이 서비스 메트릭을 이용해 이를 수행한다.

문제는 이런 기능들이 정말 필요한가 하는 점이다. 이런 추상화가 그저 알아서 동작하리라 믿고 쓸 수는 없다. 내부에서 무슨 일이 일어나는지 배워야 한다.

특히 trivago 핵심 인프라와 밀접하게 연결되어 있어 대부분의 서비스를 온프레미스에서 운영하는 우리 팀은 자체 쿠버네티스 클러스터를 운영하는 데 비용을 들이고 싶지 않았다. 대신 서비스를 출시하고 싶었다.

배터리 미포함

Nomad는 서비스 오케스트레이션의 20%로 80%를 해내는 도구다. 하는 일이라고는 배포를 관리하는 것뿐이다. 롤아웃을 처리하고 오류가 발생하면 컨테이너를 재시작한다. 그게 전부다.

Nomad의 핵심은 더 적게 한다는 데 있다. 세분화된 권한 관리나 고급 네트워크 정책을 포함하지 않으며, 이는 의도된 설계다. 그런 구성 요소는 엔터프라이즈 서비스로 제공되거나, 서드파티를 통해 제공되거나, 아예 제공되지 않는다.

Nomad는 사용 편의성과 표현력 사이에서 적절한 균형점을 찾았다고 생각한다. 작고 대체로 독립적인 서비스에 적합하다. 더 많은 제어가 필요하다면 직접 만들거나 다른 방식을 사용해야 한다. Nomad는 그저 오케스트레이터일 뿐이다.

Nomad의 가장 큰 장점은 교체가 쉽다는 점이다. 제공하는 기능이 서비스를 관리하는 다른 어떤 시스템에도 쉽게 통합될 수 있기 때문에 벤더 종속성이 거의 없다. 클러스터의 모든 머신에서 평범한 단일 바이너리로 실행될 뿐이다. 그게 전부다!

느슨하게 결합된 컴포넌트들의 Nomad 생태계

Nomad의 진정한 힘은 생태계에 있다. Consul(키-값 저장소)이나 Vault(시크릿 관리) 같은 완전히 선택적인 다른 제품들과 매우 잘 통합된다. Nomad 파일 안에서는 이런 서비스들에서 데이터를 가져오는 섹션을 넣을 수 있다:

template {
  data = <<EOH
LOG_LEVEL="{{key \"service/geo-api/log-verbosity\"}}"
API_KEY="{{with secret \"secret/geo-api-key\"}}{{.Data.value}}{{end}}"
EOH

  destination = "secrets/file.env"
  env         = true
}

이 설정은 Consul에서 service/geo-api/log-verbosity 키를 읽어 job 내부에서 LOG_LEVEL 환경 변수로 노출한다. 또한 Vault의 secret/geo-api-key를 API_KEY로 노출한다. 단순하지만 강력하다!

이렇게 단순하기 때문에 Nomad는 API를 통해 다른 서비스로도 쉽게 확장할 수 있다. 예를 들어 서비스 디스커버리를 위해 job에 태그를 달 수 있다. trivago에서는 메트릭을 노출하는 모든 서비스에 trv-metrics 태그를 단다. 이렇게 하면 Prometheus가 Consul을 통해 서비스를 찾고 /metrics 엔드포인트를 주기적으로 스크랩해 새로운 데이터를 수집한다. 로그의 경우에도 예를 들어 Loki를 연동하면 동일하게 할 수 있다.

확장성의 다른 예는 다음과 같다:

• 웹훅과 Consul watches를 이용해 Jenkins job을 트리거하고 서비스 설정이 변경되면 Nomad job을 재배포하기.
• Ceph를 이용해 Nomad에 분산 파일 시스템 추가하기.
• fabio를 이용해 로드 밸런싱하기.

이 모든 덕분에 우리는 큰 초기 투자 없이 인프라를 유기적으로 확장할 수 있었다.

미리 밝혀둘 점

완벽한 시스템은 없다. 당장 프로덕션에서 화려한 신기능을 사용하지 말라고 조언하고 싶다. 물론 버그와 빠진 기능이 있다 — 하지만 쿠버네티스도 마찬가지다.

쿠버네티스에 비해 Nomad 뒤에 있는 추진력은 훨씬 약하다. 쿠버네티스는 지금까지 약 75,000개의 커밋과 2,000명의 컨트리뷰터를 기록했지만, Nomad는 약 14,000개의 커밋과 300명의 컨트리뷰터를 보유하고 있다. Nomad가 쿠버네티스의 속도를 따라잡기는 어렵겠지만, 어쩌면 그럴 필요가 없을지도 모른다! 범위가 훨씬 좁고 커뮤니티가 작다는 것은 쿠버네티스에 비해 pull request가 더 쉽게 받아들여질 수 있다는 의미이기도 하다.

요약

핵심은 이렇다. 모두가 사용한다는 이유만으로 쿠버네티스를 사용하지 마라. 요구사항을 신중하게 평가하고 어떤 도구가 적합한지 확인하라.

대규모 인프라에 동종 서비스 플릿을 배포할 계획이라면 쿠버네티스가 좋은 선택일 수 있다. 다만 추가적인 복잡성과 운영 비용을 염두에 둬야 한다. 이러한 비용 중 일부는 Google Kubernetes Engine이나 Amazon EKS 같은 관리형 쿠버네티스 환경을 사용하면 피할 수 있다.

유지 관리가 쉽고 확장 가능한 안정적인 오케스트레이터를 찾고 있다면 Nomad를 한번 써보는 건 어떨까? 기대 이상으로 멀리 갈 수 있다는 사실에 놀랄지도 모른다.

쿠버네티스가 자동차라면 Nomad는 스쿠터다. 때로는 하나가, 때로는 다른 하나가 더 끌린다. 둘 다 존재할 이유가 있다.