Out of Bedlam Swiftish

Docker Swarm vs. Kubernetes

최근 설문조사에서 DevOps에 관한 질문을 하여 응답한 500명의 응답자들의 답변을 조사해 보면 마이크로서비스와 퍼블릭 클라우드 분야에서 3가지 오케스트레이션 도구가 주도권 경쟁 중인 것으로 나타났습니다. 그 세 가지 솔루션은 Docker Swarm, Google Kubernetes, Amazon EC2 Container Service (ECS) 입니다.

fig

유저의 환경에 적용할 오케스트레이션 도구를 선택할 때, 다음의 세 가지 사항이 중점적으로 고려되어야 합니다.

  • 성능(Performance): 얼마나 빨리 컨테이너를 올려서 대규모로 가동할 수 있는가? 시스템에 부하가 가해지는 상황에서 얼마나 응답성이 좋은가?
  • 단순성(Simplicity): 초기 구축시의 학습곡선과 유지보수에서 들어가는 노력의 정도는 어느 정도인가? 시스템 구성의 복잡도가 너무 높지는 않은가?
  • 유연성(Flexibility): 현재 나의 환경과 워크플로우에 적용할 수 있는가? 어플리케이션들을 개발환경에서 상용환경으로 옮기는 과정이 매끄러운가? 특정 플랫폼에 의존적이지 않은가?

Docker Swarm은 이 세가지 영역에서 두드러진 특징을 나타냅니다.

규모에 따른 성능

Docker 개발팀이 Swarm의 첫 번째 베타 버전을 릴리즈하고 1년이 지나는 동안 많은 사항들이 개선되었습니다. Swarm 1.0은 2015년 11월에 발표되었고 상용 환경에서 1,000개의 실행 노드를 지원할 수 있을 정도로 확대될 수 있다는 것이 증명되었습니다. Docker 개발팀 내부 시험에서도 동일하게 확인되었습니다.

Kubernetes의 개발자 블로그상에서 밝힌 성능 시험은 100개의 노드 클러스터에서 수행되었습니다. 사용자 입장에서는 이 두 가지 도구의 시험 방법이 근본적으로 다르므로 성능을 비교할 수가 없었습니다. 따라서 오케스트레이션 도구간의 성능을 정확히 측정하려면 통일된 프레임워크가 필요합니다.

독립 기술 컨설턴트인 Jeff Nickoloff는 직접 성능 평가를 하기위해서 대규모 컨테이너 그룹을 구성하였는데, 그 규모가 1,000개의 노드 클러스터 상에 30,000 개의 컨테이너가 동시에 실행되는 상황에서 성능 측정을 실시하였다고 합니다.

이 성능시험은 다음의 두 가지를 측정하기위해서 계획되었습니다.

  • 컨테이너 시작 시간: 컨테이너를 단순하게 시작하는 과정과 얼마나 빠르게 새로운 컨테이너를 온라인 상태로 만들 수 있는가?
  • 부하가 가해진 상황에서 시스템의 응답성: 부하가 발생하는 상태에서 오퍼레이션 명령에 대해 시스템이 얼마나 빨리 응답하는가? (이 시험에서는 동작 중인 모든 컨테이너의 리스트를 출력하도록 하는 명령)

시험은 구축된 클러스터상에서 측정되었고 전체 클러스터는 1,000개 노드에서 30,000개 컨테이너 (노드당 30 컨테이너)입니다.

노드들이 클러스터에 추가될때, 측정이 시작되고 컨테이너를 구동하는데 소요되는 시간과 시스템의 응답성을 측정하였습니다. 전체 클러스터의 10%, 50%, 90%, 99%, 100% 구동 상태마다 측정을 하였고 1,000회 반복하여 응답성 성능을 측정하였습니다.

예를 들어, 클러스터가 10% 구동이 완료된 상태에서 (100개의 노드, 3,000개의 컨테이너) 새로운 노드를 추가작업은 중단하고 새로운 컨테이너를 시작하는데 소요되는 시간을 측정합니다. (이 예에서는 3,001번째 컨테이너), 그리고 전체 동작 중인 (3,001개의) 컨테이너를 리스트하도록 명령을 내리고 응답하는 시간을 측정하고, 이 특정 컨테이너 (3,001번째 컨테이너)를 제거하는 명령을 내립니다. 이 3,001번째 컨테이너를 생성하고 리스트하고 제거하는 명령을 1,000회 반복하여 측정하고 이 전체 과정을 10%, 50%, 90%, 99%, 100% 상태에서마다 반복하였습니다.

이 측정 결과를 보면 컨테이너를 구동하는 시간에 있어서 Swarm이 평균 5배 이상 빠른 것으로 나타났으며 응답성에 있어서는 7배 빠른 것으로 나타났습니다.

컨테이너의 구동에 소요되는 시간을 자세히 살펴보면, 클러스터의 부하 상태에 관계없이 Swarm이 성능상의 우위에 있음을 명확히 알 수 있습니다.

Jeff Nickoloff는 그의 블로그에서 아래와 같이 정리하였습니다.

클러스터가 90% 이하일 때 Swarm은 컨테이너를 구동시키는데 0.5초가 걸리는데 반하여 Kubernetes는 클러스터가 50% 이상인 경우에 2초 이상이 소요되었습니다.

fig

한 가지 짚고 넘어가야할 점은 이 번 성능측정이 컨테이너 스케줄링에 관한 시험이 아니라 컨테이너를 구동하고 작업을 수행하는 관점에 대한 것이라는 것입니다.

현실적으로 컨테이너가 스케줄에의해 구동되는지에 관심이 있는 사람은 없습니다. 우리가 가장 관심을 가지는 것은 컨테이너가 실제로 동작하고 있느냐는 것이기 때문입니다. 비유를 들어 보면 - 외식을 하려고 레스토랑에 갔을 때 내가 주문한 내용이 주방에 어떻게 잘 전달되었는가는 중요하지 않습니다. 중요한 것은 내가 주문한 음식이 얼마나 빨리 나올 수 있는가 입니다.

또 다른 한 가지 컨테이너에 기대하는 것은 민첩성과 반응성입니다. 컨테이너 구동에 5배의 시간이 더 소요된다는 것은 준-실시간 응답성이 요구되는 분산 어플리케이션에게 치명적인 약점입니다. 실시간 응답성이 필요하지 않더라도 인프라스트럭쳐를 구동하는데 더 많은 시간이 걸린다는 것은 바람직하지는 않습니다. CI (continuous integration) 워크플로우의 일부로써의 오케스트레이션을 고려해 보면 컨테이너 구동에 시간이 더 걸린다는 것은 전체 테스트 사이클에 더 많은 시간이 들어 가게 만듭니다.

이런 차이점은 30,000개의 컨테이너로 구성된 클러스터 규모에서 전체 시스템 환경을 효과적으로 관리할 수 있도록 만드는 매우 중요한 요소입니다. 부하가 주어진 상황에서 시스템의 응답성을 확보하는 것은 효과적인 관리에 매우 중요합니다.

부하상태에서 시스템의 응답성을 측정하기위해서 다양한 클러스터 로드 상황에서 실행중인 모든 컨테이너들의 리스트를 출력하는데 소요되는 시간을 측정하였습니다.

결과는 Swarm에 대비하여 Kubernetes는 100% 로드에 도달하는 시점에 7배 이상 시간이 걸려서 실행중인 컨테이너를 전부 리스트하는데 2분이 걸렸습니다. 더구나 Kubernetes는 10% 로드에서 100% 로드로 진행되면서 98배 느렸습니다(98%의 오타가 아닙니다. 98배입니다).

fig

단순성

왜 Swarm이 Kubernetes보다 빠른 응답성을 나타내는 것일까요? 시스템 아키텍처를 비교해보아야합니다. Jeff의 시험환경에 대한 다이어그램을 살펴보면 Swarm이 Kubernetes보다 구성요소가 적다는 것을 알 수 있습니다.

fig

각각의 구성요소들은 초기 구성 프로세스 상에서 고도의 복잡성을 만들어 냅니다. 아래의 다이그램은 Kubernetes가 Swarm에 비교해서 더 많은 수의 컴포넌트 레벨에서 연동해야한다는 점을 표현하고 있습니다. run이나 list와 같은 명령을 수행하기 위해서 8배 더 많은 연동 절차가 필요한 점이 7배나 더 느린 이유입니다. 이런 복잡성의 추가적인 문제점은 명령을 수행하던 중에 오류가 발생하면 그 원인을 예상해 내기가 어렵다는 점입니다.

fig

구글의 Borg 프로젝트에서 Kubernetes가 시작되었기 때문에 많은 사람들이 Kubernetes가 클라우드 규모의 성능을 고려하여 설계되었을 것이라고 예상합니다. 위의 결과는 Kubernetes가 Borg로 부터 갈라져 나왔을 뿐만아니라 Borg이 전반적인 복잡성과 클라우드 엔지니어들이 매일같이 유지보수를 위해 노력해야만 한다는 점 까지도 그대로 이어 받았다는 점을 보여줍니다.

반면에 Swarm은 Docker에서 쌓아온 복합적인 클라우드 기술들을 평준화하였습니다. Swarm은 처음부터 대규모의 엔지니어의 도움이 없이도 다양한 형태의 기업/조직에서 컨테이너를 오케스트레이션할 수 있도록 하는 최선의 도구로 설계되었습니다. 랩탑으로 작은 클러스터를 시험하든 데이터센터의 시험환경을 설정하든 상용 클라우드 인프라스트럭쳐를 설정하든 편리한 사용성을 동일하게 보장합니다.

Jeff는 “Kubernetes보다 Docker Swarm이 도입해서 사용하기에 더 쉽다”라고 하였습니다.

Kubernetes가 더 많은 기능을 지원하기 때문에 더 복잡하다록 주장할 수 있습니다. 하지만 “더 많은 기능” 혹은 “더 많은 일”을 한다는 것이 나에게 가치를 만들어내지 못한다면 아무 소용이 없는 것입니다. 사실, 더 “많은” 것들을 가져오기 위한 것들이 장애 포인트가 될 수 있으며 운영에 비용이 더 들어 가고 불필요한 인프라스트럭쳐에 투자되어야할 수도 있습니다.

Jeff가 설명하였듯이

Kubernetes는 더 많은 요소들로 이우러져있고, 더 많은 배워야할 면들이 있고, 더 많은 장애 가능성을 가진 대규모 프로젝트입니다. Kubernetes 아키텍처를 통해서 Swarm 아키텍처에서 알려진 몇 가지 약점을 해결할 수도 있지만 난해한 문제들을 더 많이 발생시킵니다. 

유연성

서두에서 밝혔듯이 오케스트레이션 도구를 고려할 때 성능과 단순성이 중요 요소입니다. 세번째 중요한 요소는 유연성(flexibility)이며 유연성 자체로도 많은 것들을 의미합니다.

앞에서 언급한 설문 조사의 결과에서 보였듯이 여러 회사들이 사용하거나 도입을 고려 중인 세 가지 주요 오케스트레이션 도구는 Docker Swarm, 구글 Kubernetes, 아마존 EC2 Container Service(ECS)입니다.

이 중에서 Docker만이 전체 인프라스트럭처 전반에 걸쳐서 그 인프라스트럭처가 개발자의 시험환경이거나 상용 배포 환경이든 상관없이 어플리케이션이 실행될 수 있도록 지원합니다. 개인용 랩탑이든, 클라우드이든 Docker Swarm은 어디서든 호스트 클러스터를 구성하고 컨테이너를 오케스트레이션 할 수 있도록 지원합니다.

어떤 인프라스트럭처라도 지원가능한 이동성(portability)뿐만 아니라 Docker는 플러그인 기반의 아키텍트를 지원합니다. 플러그인을 통해서 도커화(Dockerized)된 어플리케이션의 코드 수정없이 상이한 네트워크나 스토리지로 이동할 수 있도록 만들 수 있습니다.

마지막으로 오케스트레이션 도구는 모든 CaaS (Container as a Service)의 필수 요소입니다. 현실적으로 오케스트레이션은 플랫폼 자체뿐만 아니라 훨씬 커다란 기술 스택의 일부분일 뿐입니다.

이 사실은 앞서 언급한 것과 동일한 설문에서 유저들이 원하는 것은 전체 어플리케이션 라이프 사이클을 맡길 수 있고, 개발자와 운영 엔지니어들이 공통으로 사용할 수 있으며, 개발자 도구에 대한 폭넓은 지원을 갖춘 도구라는 결론을 냈습니다.

fig

Docker Swarm은 여러 조직들이 네이티브 Docker CLI와 API의 전체 능력을 활용할 수 있도록 합니다. 개발자가 어플리케이션의 개발 진행 정도에 상관없이 일관된 방법으로 작업을 수행할 수 있도록 합니다. 지금 당장 가지고 있는 인프라 스트럭처에서 동작하며 다른 인프라스트럭처 프로바이더로 매끄럽게 이관할 수 있게 합니다.