참고 : https://www.oreilly.com/ideas/swarm-v-fleet-v-kubernetes-v-mesos?cmp=tw-webops-free-lp-promo_swarm_v_fleet_v_kubernetes_v_mesos_article , http://stackoverflow.com/questions/27640633/docker-swarm-kubernetes-mesos-core-os-fleet
DevOps라는 단어의 대두와 함께 소프트웨어의 개발 뿐만 아니라 서비스의 운영이 개발 프로세스에서 중요한 비중을 차지하게 됨에 따라 다양한 클라우드 인프라 오케스트레이션 툴들이 나오게 됐는데 크게 Docker 이전의 경우 상용툴로 Chef와 Puppet 이후는 Swarm, Fleet, Kubernetes 그리고 Mesos를 들 수 있을것이다.
사실 이런 툴들이 없는 전통적인 방식의 개발, 운영 시스템에 DevOps를 해야 한다면 가혹한 환경에 놓이게 될 가능성이 매우 높겠지만 이런 툴들은 언제든지 새로운 소프트웨어를 제공 할 수 있는(Continuous Delivery)환경을 만드는데 도움을 주고 있는 것 처럼 보인다.
기존의 인프라는 머신 각각에 대해 신경을 썼다면 새로운 툴들은 시스템은 언제든 문제를 일으킬 수 있다고 보고 문제가 발생한 요소를 제거하고 새로운 백업 시스템으로 교체하는 형태로 발상의 전환이 이루어진 점이 특징이라고 볼 수 있다. 물론 오케스트레이션 툴을 이용하기 위해선 기존의 어플리케이션의 설계도 맞춰서 바뀌어야 하겠지만…
오케스트레이션 툴을 통한 제로 다운 타임, 자동 장애 복구, 서비스 확장을 위한 사전 프로비저닝 된 지원 시스템 그리고 보편화 된 서로 다른 데이터센터와 지역에서의 서비스 운영이 가능해진 시스템은 전통적인 시스템과는 달리 매우 매력적으로 보이지만 각 툴에 대한 충분한 이해가 필요하다는 것을 간과해서는 안된다.
다음은 각 툴을 선택할 때 고려할만한 특징에 대해서 간략히 정리해 보았으며 컨테이너(Docker와 같은..)를 스캐줄링 할 것인지 머신(EC2 인스턴스와 같은..)을 스케줄링 할 것인지와 같은 차이가 있으며 내용은 다음과 같다.
Docker의 표준 API를 사용하는 툴로 기존에 Docker Compose와 같은 스크립트를 이용하는 환경이라면 상대적으로 적은 리소스를 투입하여 통합할 수 있지만 복잡한 스케줄링을 위한 커스텀 인터페이스 정의가 어려워 질 수 있다. 주요 구성요소로 머신에 설치되어 컨테이너를 스케줄링 하기 위한 매니저와 에이전트가 있다.
CoreOS의 클러스터 관리 툴로 Kubernetes와 같이 추상화 단계가 높은 툴과 비교해 로우레벨 클러스터 엔진으로 분류되며 리눅스의 init을 대체하기 위해 나온 systemd위에서 동작하는 툴이다. Fleet은 단순한 레이어를 갖으며 Kubernetes와 같은 상위 레이어의 툴의 베이스가 될 수 있다. 머신간의 통신은 Etcd를 통해 이루어지며 장애에 유연하게 대처할 수 있도록 디자인 되었다. 만약 머신중 하나가 죽는다면 해당 머신에서 스케줄링 되던 유닛(컨테이너와 같은..)은 새 머신에서 재시작 할 수 있다. 네트워크 소켓을 통해 즉각적인 컨테이너 구동이 가능하다는 장점을 가지고 있다.
구글의 서비스는 모두 컨테이너 기반으로 제공되고 있으며 이것을 가능하게 하는 것이 Borg인데 Kubernetes는 구글에서 Borg를 오픈소스로 공개한 대규모 컨테이너 시스템을 스케줄링 하기 위한 툴이다. Kubernetes는 몇가지 추상화된 개념들을 제공하며 서비스 추가나 복제와 같은 확장성을 제공하고 장애에 유연한 대처가 가능한 강력한 툴이지만 어플리케이션이 이를 충족시키기 위해 재 디자인 되어야 한다. Kubernetes가 제공하는 강력한 기능이 궁금하다면 링크의 영상을 보길 추천한다.
아파치의 Mesos는 수백에서 수천개의 머신으로 구성된 대규모 클러스터 관리를 위해 개발 되었으며 Twitter, eBay 그리고 Airbnb와 같은 회사들이 사용하고 있다. 대규모 클러스터 구성을 기본으로 하다보니 다수의 사용자에 대한 워크로드를 지원하는 것이 특징이며 Fleet과 같이 로우 레벨 클러스터 엔진으로 분류되며 스케줄러로 Marathon, Kubernetes 그리고 Swarm과 같은 툴을 이용할 수 있다. 12개 이하의 머신 노드를 이용하는 경우라면 필요 이상으로 복잡한 솔루션이 될 수 있다.
