[DC/OS 아키텍처에 관한 분석]MESOS와 MARATHON
DC/OS는 쿠버네티스와 같은 컨테이너 오케스트레이션 솔루션으로 알려져 있다. 실제로도 그렇게 많이 사용되고 있지만 DC/OS를 리셀링 하는 회사에서 엔지니어로 근무하며 많이 받았던 질문으로 “그래서 쿠버네티스와는 뭐가 다른데?” 라는 질문에 대해 장황하게 설명하게 되는 나 자신을 돌아보며, 먼저 DC/OS 라는 플랫폼에 대해서 다시 한번 간단하게 해부해 보고자 한다.
MESOS 아키텍쳐
DC/OS를 지칭할 때 종종 marathon + mesos 라는 수식어를 붙이곤 한다. 실제로 DC/OS는 Apache 재단에서 핫한 프로젝트 중 하나였던 Mesos 라는 프로젝트에 핵심 기능을 의존하여 개발된 서비스인데, mesos는 컨테이너 오케스트레이션이라는 컨셉에만 초점을 두고 탄생한 플랫폼이 아니다. Mesos는 분산형 시스템 커널이라는 아이디어를 기반으로, CPU/MEMORY/STORAGE 등과 같은 여러 머신으로부터 분산된 컴퓨팅 자원들을 marathon 뿐만 아니라 하둡, 스파크, 카프카와 같은 다양한 프레임워크들에게 추상화하여 제공하고, 각 프레임워크들이 실행을 요청한 작업이 적절한 노드에서 실행되도록 한다.
특정 프레임워크가 Mesos를 활용하여 동작하기 위해서는 scheduler 와 executor 라는 두 가지의 타입의 컴포넌트가 필요하다. 각 컴포넌트는 mesos를 통해 task를 생성하기 위해 아래와 같은 기능을 수행한다.
scheduler : scheduler는 mesos 마스터로부터 리소스풀을 제공받고 그 중에서 어떤 리소스를 사용하여 task를 배포할지 결정한다.
executor : executor는 리소스풀의 대상이 되는 서버에서 동작하며, mesos agent가 mesos master로부터 task 실행 요청을 받음에 따라 mesos agent에 의해 트리거 되어 제공받은 스펙에 따라 task를 수행한다. 이때 task는 컨테이너가 될 수도 있고 프로세스가 될 수도 있다.
이러한 두 가지 컴포넌트를 포함하여 Mesos를 활용하는 프레임워크를 개발하고자 한다면 Mesos 프로젝트에서 제공하는 가이드를 참고하여 개발하면 된다. marathon도 이러한 mesos의 가이드에 따라 만들어진 하나의 프레임워크 중 하나인 것이다.
MESOS Task 실행 과정
Mesos를 활용해서 특정 프레임워크가 task를 실행하는 과정은 아래와 같다.
mesos agent에서 여유 리소스가 생기면, mesos master에게 가용 리소스에 대한 정보를 전달한다.
여러 agent로부터 받은 여유 리소스에 관한 정보들을 집계하여, mesos master는 framework에 가용 리소스 목록을 전달한다.
framework의 scheduler는 mesos master에게 전달 받은 리소스를 기준으로 task를 실행하는데 적합한 노드와 사용할 자원의 양과 같은 정보들을 포함하여 executor가 task를 실행하는데 필요한 정보들과 함께 mesos master에 응답한다.
마지막으로, mesos master는 framework의 scheduler로부터 전달 받은 task 실행 요청을 대상 mesos agent로 전달하고, 궁극적으로 executor를 통해 task를 실행한다.
DC/OS
개인적으로 DC/OS의 공식 문서에 설명된 내용들에 불만이 많다. 실제로 내부적으로 어떤 오픈소스들을 이용해 각 기능들을 구현 했는지에 대한 명세를 생략하고, 자신들이 추상화하여 표현하는 별도의 용어를 통해 기능들을 설명하려고 한다.
DC/OS는 기본적으로 잘 만들어진 여러가지 오픈소스들에 marathon이라는 mesos와 연계되어 동작하도록 설계된 프레임워크를 함께 잘 버무려서 만든, 컨테이너 오케스트레이션에 초점이 맞춰진 솔루션이다(물론 컨테이너가 아닌 단일 프로세스를 실행하는 기능도 제공한다).
DC/OS는 실질적으로 위에서 설명한 marathon 이라는 application 상태 관리 프레임워크와, Job 실행을 위한 Metronome을 비롯해서 어플리케이션을 배포하고 스케줄링 하는데 유용한 여러 요소들을 하나로 결합하여 편리한 UI와 간편한 설치등의 기능을 제공하도록 설계된 플랫폼이다. 뿐만 아니라 별도로 제공하는 catalog(쿠버네티스의 공식 helm과 비슷함)를 통해 기존에 mesos를 활용할 수 있도록 설계된 다양한 프레임워크들을 쉽게 설치하고 이용할 수 있도록 기능들을 지원하고 있다.
Job 스케줄러로써 이전에는 Chronos라는 서드파티를 내부적으로 사용하고 있었는데, 최근에는 해당 프로젝트가 지원이 종료되면서 지금은 Metronome을 사용하고 있는 것으로 보인다.
Aurora도 마찬가지로 Apache에서 프로젝트 지원이 종료되고, Marathon과 포지션이 겹치는 부분도 많아서 지금은 사용되지 않는다.(로고가 Mesos와 매우 흡사하고 기능적인 부분으로 미루어 보아 애초에 Mesos를 활용해 서비스들을 스케줄링 하기 위한 목적으로 사용되는 프레임워크로 Apache에서 밀던 프로젝트인 것으로 보인다.)
Marathon
marathon은 D2iQ(이전 mesosphere)사에서 mesos의 자원 추상화를 활용하여 동작하도록 설계된 프레임워크이다. Apache 프로젝트에 속한 Mesos에 의존적으로 동작하지만, Apache 프로젝트와는 무관하다. Marathon 자체는 Scala로 작성된 오픈소스이며, DC/OS라는 유료 플랫폼의 주요 컴포넌트로써 동작한다.
공식 Github에 따르면 안타깝게도 2021년 10월 31일을 기점으로 공식 서비스 지원이 종료된다고 한다.
여담이지만, D2iQ 회사 홈페이지에서 미루어 볼 수 있듯이 이미 D2iQ 자체적으로 쿠버네티스를 기반으로 한 상품들을 주력으로 밀고 있고 시장에서의 점유율이 컨테이너 플랫폼에 대해서는 쿠버네티스쪽으로 압도적으로 기울고 있는 것에 따라 marathon 프로젝트와 함께 DC/OS에 대한 지원도 천천히 종료하게 되지 않을까 싶다.
