2017.03.31

컨테이너 오케스트레이션 기본 가이드 "도커 스웜모드, 퀴베르네시스, 메소스피어"

BrandPost Sponsored by HPE
Steven Vaughan-Nichols | HPE


최근 가장 인기 있는 컨테이너 관리 프로그램 3가지에 대해 반드시 알아야 할 사항을 꼽았습니다.

애플리케이션을 가볍게 가상화하는 방법인 컨테이너는 어떤 데브옵스 계획에서도 가장 중요한 요소입니다. 그렇지만, 그 모든 컨테이너를 어떻게 관리할 수 있을까요? 컨테이너 오케스트레이션 프로그램인 퀴베르네시스(Kubernetes), 메소스피어(Mesosphere), 그리고 도커(Docker) 스웜 모드(Swarm Mode)의 편리한 장점을 알아보겠습니다.

무턱대고 달려들기 전에, 기초부터 재검토하는 것이 중요합니다. 451 리서치에 따르면, 컨테이너는 가장 빠르게 성장하고 있는 클라우드 활성화 기술입니다. 컨테이너가 가상 머신(Virtual Machine: VM)보다 훨씬 더 적은 자원을 사용한다는 것이 이유입니다. 가상머신은 그저 운영 체제만 구동하는 것이 아니라, OS가 구동하기 위해 필요한 모든 하드웨어에 대한 VC(Virtual Copy)도 구동합니다.

CFO가 이해할 수 있는 말로 바꿔볼까요? 동일한 컴퓨터 하드웨어 상에서 가상머신을 사용할 때보다 최대 4~10배나 더 많은 서버 인스턴스를 구동할 수 있다는 의미입니다. 그 결과 이미 데이터센터에서 가동 중인 하드웨어에서 더 많은 애플리케이션을 구동할 수 있습니다. 반기지 않을 이유가 있을까요?

또한, 컨테이너를 사용하면 애플리케이션을 쉽게 배포할 수 있습니다. 특히 시스템 관리자가 아주 기뻐할 만한 일입니다. 선두적인 리눅스 커널 개발자인 제임스 보틈리는 “컨테이너는 즉각적인 애플리케이션 이식성을 제공”한다고 말했습니다.

컨테이너는 2000년부터 그리고 FreeBSD Jail과 함께 해왔지만, 도커가 2013년에 등장할 때까지는 누구도 별다른 관심을 가지지 않았습니다. 그런데 한순간 갑자기 모든 사람들과 CTO가 컨테이너를 배포하고 싶어하게 됩니다. 451 리서치에 따르면 2016년 컨테이너 기술 시장은 7억 6,200만 달러의 매출을 일으켰다고 합니다. 2020년에는 컨테이너 연간 매출이 40%의 연평균 성장률(Compound Annual Growth Rate: CAGR)로 27억 달러에 이를 것으로 예상합니다.

단, 2가지 문제가 있습니다. 그 모든 컨테이너를 어떻게 보호할 것인가? 그리고 배포와 관리는 어떻게 할 것인가 라는 문제입니다.

컨테이너는 관리가 필요합니다
클라우드 인프라의 다른 요소와 마찬가지로, 컨테이너는 관리되고 통제되어야만 합니다. 그렇지 않으면, 그야말로 서버 상에서 무엇이 구동되고 있는지 전혀 알지 못하게 됩니다.

도커 같은 컨테이너를 퍼펫(Puppet), 셰프(Chef), 그리고 앤서블(Ansible) 같은 데브옵스 도구와 함께 사용할 수 있지만, 이런 도구는 컨테이너용으로 최적화된 것은 아닙니다. 클라우드 감시 회사인 데이터독이 실 세계 도커 도입에 대한 보고서에서 “컨테이너의 짧은 수명과 증가된 밀집도(Density)가 인프라 감시에 중요한 영향을 미치고 있습니다. 개별적으로 감시 해야 하는 항목 수를 몇 배나 늘렸습니다”라고 지적한 바 있습니다.

감시 솔루션은 역할 중심적이기 보다는 호스트 중심적인 성질이 있어 금세 사용할 수 없게 됩니다.

일반적인 감시 도구는 2가지가 있습니다. 또, 클러스터링과 스케줄링(Scheduling) 컨테이너를 가리키는 용어로는 오케스트레이션이 있습니다. 오케스트레이션에 손을 대는 개발자는 극히 적습니다. 그리고 그 다음에는 컨테이너 관리가 있는데, 컨테이너화 된 애플리케이션과 애플리케이션 구성요소들에 대한 관리 작업을 처리하는 과정입니다.

도커 스웜 모드, 퀴베르네시스, 그리고 메소스피어 DC/OS에 대해 알아봅시다. 오픈 소스 도구는 교체 사용이 불가능하며, 서로 직접적으로 경쟁하지도 않습니다. 정도의 차이는 있지만, 모든 도구들이 다음과 같은 기능을 제공하고 있습니다.

- 프로비저닝 : 컨테이너 클러스터 내부에서 컨테이너를 프로비전 하고 예약하며 시작할 수 있습니다. 이상적으로는 자원과 지리적 위치 같은 사용자의 요구사항에 따라 최상의 가상머신에 컨테이너를 스핀업(Spin Up)합니다.

- 구성 스크립팅(Scripting: 스크립트 작성) : 스크립팅은 주주 참스(Juju Charms), 퍼펫 매니페스트(Puppet Manifest) 또는 셰프 레시피(Recipe)에서처럼 특정 애플리케이션 구성정보를 컨테이너에 로드할 수 있습니다. 대개 YAML이나 JSON으로 작성됩니다.

- 모니터링 : 컨테이너 관리 도구는 컨테이너의 상태와 클러스터에 있는 호스트를 추적하고 감시합니다. 감시도구가 맡은 일을 제대로 한다면, 컨테이너가 다운될 때 새로운 인스턴스를 스핀 업 합니다. 서버가 장애를 일으키면, 도구는 다른 호스트 상의 컨테이너를 재시작합니다. 도구는 시스템 상태 검사도 실행하고, 컨테이너와 도구가 들어있는 가상머신, 그리고 자신들을 구동하고 있는 서버에 대한 특이점을 보고합니다.

- 업그레이드와 롤백(Rollback: 되돌리기), 롤링(Rolling) : 새 버전의 컨테이너 또는 컨테이너 내부에서 구동하는 애플리케이션을 배포할 때, 컨테이너 관리 도구는 컨테이너 클러스터 전체를 대상으로 자동으로 업데이트 합니다. 뭔가가 잘못되면, 컨테이너 관리 도구로 사용자가 알려진 좋은 구성으로 롤백 할 수 있습니다.

- 서비스 탐색(Service Discovery) : 구식 애플리케이션에서는 소프트웨어가 구동하기 위해 필요한 각각의 서비스를 어디에서 찾을 수 있는지 사용자가 일일이 명확하게 지정해주어야 했습니다. 그러나 컨테이너는 적합한 자원을 찾기 위해 서비스 탐색을 사용합니다.

분명 어디선가 많이 들어본 용어들입니다. 그도 그럴 것이 애널리스트 댄 쿠스네츠키가 자적한 것처럼, 컨테이너는 2000년대에 아주 많은 주목을 받았던 SOA(Service-oriented Architecture)와 매우 비슷하게 동작합니다. 이 기술을 접하지 못한 사람들을 위해 설명하자면, SOA란 애플리케이션을 각기 다른 독립형 서비스로 해체합니다. 이때의 기술 장벽으로는 프로세스 간 통신보다 네트워크 통신이 몇 배나 더 늦었다는 점을 꼽습니다. 컨테이너는 동일한 서버 상의 자원을 사용하는 경향이 있기 때문에 SOA보다 훨씬 더 빨리 구동합니다. 이런 도구는 프론트엔드(Front-end) 애플리케이션, 가령 워드프레스 인스턴스가, DNS나 프록시를 통해서 해당 MySQL 인스턴스를 동적으로 탐색할 수 있도록 도와줍니다.

- 컨테이너 정책 관리 : 컨테이너가 어디에서 실행되기를 원하는가? CPU당 몇 개를 할당해야 할까요? 이런 기본적인 질문에 대한 답은 올바른 컨테이너 정책을 수립함으로써 얻을 수 있을 것입니다.

- 상호운영성 : 그리고 매우 당연하게도 컨테이너는 사용자의 기존 IT 관리 도구와도 함께 동작해야 할 것입니다.

마지막으로, 이 3가지 컨테이너 관리 도구 모두는 오픈스택 매그넘(OpenStack Magnum) 그리고 애저 컨테이너 서비스(Azure Container Services)를 포함하여 다양한 클라우드플랫폼과도 동작합니다.

사용자가 자체적인 컨테이너 관리 도구 프로그램을 개발할 수도 있지만, 과연 다시 만들 이유가 있을까요? 3가지 관리 도구 모두 오픈소스 기반으로 만들어졌습니다. 사용자가 필요한 기능을 항상 추가할 수 있으므로 굳이 처음부터 다시 시작할 필요는 없겠죠.

대략적인 사항은 충분히 알아보았습니다. 이제 더 깊게 파고들어봅시다.

도커 스웜 모드
컨테이너를 처음 접한다면, 아마도 도커로 시작했을 것이며, 도커는 대규모 사용자 기반을 확보한 최초의 컨테이너 프로그램이었습니다. 컨테이너 인프라를 개발한 사람들이 만든 컨테이너 관리자(Container Manager)에 의지하는 것은 자연스러운 본능이며, 이는 도커 스웜을 의미합니다.

도커 1.12 당시, 도커의 진행 모델은 오케스트레이션을 내장하는 것으로, 도커는 스웜 모드라고 부릅니다. 도커의 독립형 오케스트레이터(Orchestrator)인 도커 스웜은 이 내장 기능보다 눈에 띄지 않게 되었습니다. 스웜 모드는 사용자에게 컨테이너 클러스터링이나 스케줄링뿐 아니라, 애플리케이션 생명주기 전체에 대한 통제력을 제공합니다.

도커 스웜과 스웜 모드의 차이점? 도커 1.12에서, 스웜 모드는 도커 엔진(Docker Engine)의 일부분입니다. 확장, 컨테이너 탐색, 그리고 보안이 최소한의 설정으로 모두 포함됩니다. 도커 스웜은 더 오래된 독립형 제품으로, 여러 대의 도커 호스트를 클러스터링 하는데 사용되곤 했습니다. 스웜 모드는 도커의 내장 클러스터 관리기입니다.

스웜 모드는 단일 노드 도커 개념을 사용하고 있으며 이런 개념들을 스웜으로 확장하고 있습니다. 예를 들어, 도커 클러스터를 구동하기 위해, 사용자는 스웜 모드로 전환하기 위해 run docker swarm init 명령어를 사용합니다. 더 많은 노드를 추가하기 위해서는 docker swarm join을 실행합니다.

또한, 도커 1,12 이상의 버전과 스웜 모드에는 롤링 업데이트, 노드들 간의 TLS(Transport Layer Security) 암호화, 부하 분산(Load Balancing: 로드 밸런싱), 그리고 쉬운 서비스 추상화(Service Abstraction)에 대한 지원이 포함되어 있습니다.

요약하면, 도커 스웜 모드는 컨테이너의 로드(부하)를 여러 대의 호스트로 분산하고, 사용자가 여러 대의 호스트 플랫폼 상에서, 스웜 (즉, 클러스터)를 설정할 수 있게 합니다. 통합 (그렇게 해서, 서로 다른 노드 상에서 구동하고 있는 컨테이너들이 서로 통신할 수 있도록)과 분리(서로 다른 컨테이너 워크로드를 격리하고 보호하기 위해)를 포함해서 호스트 플랫폼 상에 몇 가지 사항을 설정할 것을 요구하기도 합니다. 이런 필요사항을 충족하기 위해서는 가상 네트워크를 사용해야 합니다.

퀴베르네시스
퀴베르네시스는 원래 구글에서 개발된 오픈 소스 컨테이너 관리자입니다. 퀴베르네시스는 발표된 이후, 애저, DC/OS, 그리고 널리 알려진 거의 모든 클라우드 플랫폼에 이식되었습니다. 코어OS(CoreOS)로 AWS 상에 퀴베르네시스 클러스터를 배포하는 방법도 있지만, 한 가지 예외는 AWS(Amazon Web Service)입니다.

현재, 퀴베르네시스는 리눅스 재단의 클라우드 네이티브 컴퓨팅 재단(Cloud Native Computing Foundation: CNCF)이 주관하고 있습니다. 또한, 레드햇 오픈시프트(Red Hat OpenShift), Canonical Distribution of Kubernetes, 코어OS 테크토닉(Tectonic) 그리고 인텔과 미란티스를 포함한 수많은 기업의 퀴베르네시스 배포판이 존재합니다.

퀴베르네시스는 자가 수정(Self-healing), 자동 롤아웃과 롤백, 그리고 스토리지 오케스트레이션뿐 아니라 높은 수준의 상호운영성도 제공합니다. 그렇지만, 퀴베르네시스를 이용한 부하 분산은 어렵습니다. 결국, 퀴베르네시스 수신 트래픽은 퀴베르네시스 내부에서 외부 로드 밸런서를 구동하는 것을 쉽게 해주겠지만, 아직은 진행중인 작업입니다.

퀴베르네시스는 자동으로 문제를 해결하는 데 뛰어납니다. 그렇지만, 너무나 뛰어난 나머지 컨테이너가 장애를 일으켜도 너무 빨리 재가동되어 사용자가 컨테이너가 장애가 있었음을 알아차리지 못합니다. 이 문제를 해소하기 위해, 사용자는 중앙 집중형 로그기록 시스템을 추가할 필요가 있습니다.

메소스피어 마라톤
마라톤(Marathon)은 메소스피어의 DC/OS와 아파치 메소스(Mesos)를 위한 컨테이너 오케스트레이션 플랫폼입니다. DC/OS는 메소스 분산 시스템 커널을 기반으로 하는 분산 운영 체제입니다. 메소스는 오픈소스 클러스터 관리 시스템입니다. 마라톤은 (협력 프로그램인 고장 방지 작업 스케줄러 크로노스(Chronos)를 통해서) 사용자의 기존 스테이트풀(Stateful: 동작 상태 정보를 저장함) 애플리케이션과 컨테이너 기반의 스테이트리스(Stateless: 동작 상태 정보를 저장하지 않음) 애플리케이션 간의 관리 통합 기능을 제공합니다.

마라톤은 애플리케이션으로 생각할 수 있는 사용자 인터페이스를 가지고 있지만, 컨테이너 관리를 위한 프레임워크로 보는 것이 더 쉽습니다. 컨테이너가 REST API를 통해서 마라톤과 동작하기 때문에, 데브옵스의 개발자 측면을 간단히 언급하고 있습니다.

마라톤은 고 가용성, 서비스 탐색, 부하 분산을 포함하여 여러 가지 특성을 자랑합니다. DC/OS 상에서 구동한다면, 애플리케이션은 가상 IP 라우팅까지도 얻을 수 있습니다.

그렇지만, 마라톤은 메소스를 탑재한 소프트웨어 스택(Stack) 상에서만 구동할 수 있습니다. 또한, (인증 같은) 특정 기능은 DC/OS 상의 마라톤에서만 사용할 수 있습니다. 이는 사용자의 스택에 추상화 계층을 하나 더 추가합니다.

어떤 것이 알맞을까?
결국에는 사용자의 필요사항에 의해 좌우됩니다. 메소스와 퀴베르네시스는 대체로 클러스터링 된 애플리케이션을 구동하는 데 사용됩니다. 메소스는 포괄적인 스케줄링 그리고 여러 가지 상이한 스케줄러에 플러그 인(Plug in)하는데 초점을 맞추고 있습니다. 구글은 원래 컨테이너로부터 분산 애플리케이션을 구축하기 위한 환경으로서 퀴베르네시스를 설계했습니다.

도커 스웜 모드는 머신 클러스터를 단일 도커 API로 사용하기 더 쉽게 만들기 위해 기존 도커 API를 확장합니다. 회사 직원 중에 도커 전문가가 있다면, 어쩌면 이미 스웜 모드를 구동하고 있을 것입니다. 잘 작동하고 있다면, 귀찮게 다른 시스템으로 전환할 이유가 없습니다. 마라톤은 컨테이너와 구형 애플리케이션 두 가지 모두를 (비록 다단계이기는 하지만) 처리하기 위한 한 가지 방안을 제공한다는 고유의 이점이 있습니다.

다행스럽게도, 회사가 필요로 하는 독특한 혼합을 만들기 위해 이런 프로그램들을 짜 맞출 수 있습니다. 세 가지 모두 서로 잘 동작합니다. 쉽지는 않지만, 가능한 일이며, 아마도 옵션을 탐색하기 위한 좋은 방법일 것입니다.

컨테이너 관리 : 리더를 위한 교훈
- 컨테이너를 최대한 활용하기 위해, 훌륭한 컨테이너 관리 프로그램이 필요합니다. 3가지 주요한 애플리케이션은 퀴베르네시스, 메소스피어, 그리고 도커 스웜입니다. 각각의 특성은 다양하지만, 모두 컨테이너 프로비저닝, 감시, 그리고 관리를 지원합니다.

- 컨테이너 관리 외에, 메소스피어는 데이터 센터를 관리하는데 도움이 되는 특성을 가지고 있습니다.

- 도커 스웜 모드는 컨테이너 스케줄링에 대한 통제력을 제공함으로써 도커 클러스터링을 간소화하는 것을 목표로 합니다. 예를 들면, 컨테이너가 시작할 수 있는 노드를 제한하고, 도커 Remote API와 함께 동작하며, 클러스터의 어떤 노드에 새로운 컨테이너를 예약해야 할지를 사용자가 결정할 수 있게 합니다.

- 퀴베르네시스는 인텔, 마이크로소프트, 레드햇, 그리고 미란티스를 포함해서 폭넓은 업계 협력업체를 가지고 있습니다.


2017.03.31

컨테이너 오케스트레이션 기본 가이드 "도커 스웜모드, 퀴베르네시스, 메소스피어"

BrandPost Sponsored by HPE
Steven Vaughan-Nichols | HPE


최근 가장 인기 있는 컨테이너 관리 프로그램 3가지에 대해 반드시 알아야 할 사항을 꼽았습니다.

애플리케이션을 가볍게 가상화하는 방법인 컨테이너는 어떤 데브옵스 계획에서도 가장 중요한 요소입니다. 그렇지만, 그 모든 컨테이너를 어떻게 관리할 수 있을까요? 컨테이너 오케스트레이션 프로그램인 퀴베르네시스(Kubernetes), 메소스피어(Mesosphere), 그리고 도커(Docker) 스웜 모드(Swarm Mode)의 편리한 장점을 알아보겠습니다.

무턱대고 달려들기 전에, 기초부터 재검토하는 것이 중요합니다. 451 리서치에 따르면, 컨테이너는 가장 빠르게 성장하고 있는 클라우드 활성화 기술입니다. 컨테이너가 가상 머신(Virtual Machine: VM)보다 훨씬 더 적은 자원을 사용한다는 것이 이유입니다. 가상머신은 그저 운영 체제만 구동하는 것이 아니라, OS가 구동하기 위해 필요한 모든 하드웨어에 대한 VC(Virtual Copy)도 구동합니다.

CFO가 이해할 수 있는 말로 바꿔볼까요? 동일한 컴퓨터 하드웨어 상에서 가상머신을 사용할 때보다 최대 4~10배나 더 많은 서버 인스턴스를 구동할 수 있다는 의미입니다. 그 결과 이미 데이터센터에서 가동 중인 하드웨어에서 더 많은 애플리케이션을 구동할 수 있습니다. 반기지 않을 이유가 있을까요?

또한, 컨테이너를 사용하면 애플리케이션을 쉽게 배포할 수 있습니다. 특히 시스템 관리자가 아주 기뻐할 만한 일입니다. 선두적인 리눅스 커널 개발자인 제임스 보틈리는 “컨테이너는 즉각적인 애플리케이션 이식성을 제공”한다고 말했습니다.

컨테이너는 2000년부터 그리고 FreeBSD Jail과 함께 해왔지만, 도커가 2013년에 등장할 때까지는 누구도 별다른 관심을 가지지 않았습니다. 그런데 한순간 갑자기 모든 사람들과 CTO가 컨테이너를 배포하고 싶어하게 됩니다. 451 리서치에 따르면 2016년 컨테이너 기술 시장은 7억 6,200만 달러의 매출을 일으켰다고 합니다. 2020년에는 컨테이너 연간 매출이 40%의 연평균 성장률(Compound Annual Growth Rate: CAGR)로 27억 달러에 이를 것으로 예상합니다.

단, 2가지 문제가 있습니다. 그 모든 컨테이너를 어떻게 보호할 것인가? 그리고 배포와 관리는 어떻게 할 것인가 라는 문제입니다.

컨테이너는 관리가 필요합니다
클라우드 인프라의 다른 요소와 마찬가지로, 컨테이너는 관리되고 통제되어야만 합니다. 그렇지 않으면, 그야말로 서버 상에서 무엇이 구동되고 있는지 전혀 알지 못하게 됩니다.

도커 같은 컨테이너를 퍼펫(Puppet), 셰프(Chef), 그리고 앤서블(Ansible) 같은 데브옵스 도구와 함께 사용할 수 있지만, 이런 도구는 컨테이너용으로 최적화된 것은 아닙니다. 클라우드 감시 회사인 데이터독이 실 세계 도커 도입에 대한 보고서에서 “컨테이너의 짧은 수명과 증가된 밀집도(Density)가 인프라 감시에 중요한 영향을 미치고 있습니다. 개별적으로 감시 해야 하는 항목 수를 몇 배나 늘렸습니다”라고 지적한 바 있습니다.

감시 솔루션은 역할 중심적이기 보다는 호스트 중심적인 성질이 있어 금세 사용할 수 없게 됩니다.

일반적인 감시 도구는 2가지가 있습니다. 또, 클러스터링과 스케줄링(Scheduling) 컨테이너를 가리키는 용어로는 오케스트레이션이 있습니다. 오케스트레이션에 손을 대는 개발자는 극히 적습니다. 그리고 그 다음에는 컨테이너 관리가 있는데, 컨테이너화 된 애플리케이션과 애플리케이션 구성요소들에 대한 관리 작업을 처리하는 과정입니다.

도커 스웜 모드, 퀴베르네시스, 그리고 메소스피어 DC/OS에 대해 알아봅시다. 오픈 소스 도구는 교체 사용이 불가능하며, 서로 직접적으로 경쟁하지도 않습니다. 정도의 차이는 있지만, 모든 도구들이 다음과 같은 기능을 제공하고 있습니다.

- 프로비저닝 : 컨테이너 클러스터 내부에서 컨테이너를 프로비전 하고 예약하며 시작할 수 있습니다. 이상적으로는 자원과 지리적 위치 같은 사용자의 요구사항에 따라 최상의 가상머신에 컨테이너를 스핀업(Spin Up)합니다.

- 구성 스크립팅(Scripting: 스크립트 작성) : 스크립팅은 주주 참스(Juju Charms), 퍼펫 매니페스트(Puppet Manifest) 또는 셰프 레시피(Recipe)에서처럼 특정 애플리케이션 구성정보를 컨테이너에 로드할 수 있습니다. 대개 YAML이나 JSON으로 작성됩니다.

- 모니터링 : 컨테이너 관리 도구는 컨테이너의 상태와 클러스터에 있는 호스트를 추적하고 감시합니다. 감시도구가 맡은 일을 제대로 한다면, 컨테이너가 다운될 때 새로운 인스턴스를 스핀 업 합니다. 서버가 장애를 일으키면, 도구는 다른 호스트 상의 컨테이너를 재시작합니다. 도구는 시스템 상태 검사도 실행하고, 컨테이너와 도구가 들어있는 가상머신, 그리고 자신들을 구동하고 있는 서버에 대한 특이점을 보고합니다.

- 업그레이드와 롤백(Rollback: 되돌리기), 롤링(Rolling) : 새 버전의 컨테이너 또는 컨테이너 내부에서 구동하는 애플리케이션을 배포할 때, 컨테이너 관리 도구는 컨테이너 클러스터 전체를 대상으로 자동으로 업데이트 합니다. 뭔가가 잘못되면, 컨테이너 관리 도구로 사용자가 알려진 좋은 구성으로 롤백 할 수 있습니다.

- 서비스 탐색(Service Discovery) : 구식 애플리케이션에서는 소프트웨어가 구동하기 위해 필요한 각각의 서비스를 어디에서 찾을 수 있는지 사용자가 일일이 명확하게 지정해주어야 했습니다. 그러나 컨테이너는 적합한 자원을 찾기 위해 서비스 탐색을 사용합니다.

분명 어디선가 많이 들어본 용어들입니다. 그도 그럴 것이 애널리스트 댄 쿠스네츠키가 자적한 것처럼, 컨테이너는 2000년대에 아주 많은 주목을 받았던 SOA(Service-oriented Architecture)와 매우 비슷하게 동작합니다. 이 기술을 접하지 못한 사람들을 위해 설명하자면, SOA란 애플리케이션을 각기 다른 독립형 서비스로 해체합니다. 이때의 기술 장벽으로는 프로세스 간 통신보다 네트워크 통신이 몇 배나 더 늦었다는 점을 꼽습니다. 컨테이너는 동일한 서버 상의 자원을 사용하는 경향이 있기 때문에 SOA보다 훨씬 더 빨리 구동합니다. 이런 도구는 프론트엔드(Front-end) 애플리케이션, 가령 워드프레스 인스턴스가, DNS나 프록시를 통해서 해당 MySQL 인스턴스를 동적으로 탐색할 수 있도록 도와줍니다.

- 컨테이너 정책 관리 : 컨테이너가 어디에서 실행되기를 원하는가? CPU당 몇 개를 할당해야 할까요? 이런 기본적인 질문에 대한 답은 올바른 컨테이너 정책을 수립함으로써 얻을 수 있을 것입니다.

- 상호운영성 : 그리고 매우 당연하게도 컨테이너는 사용자의 기존 IT 관리 도구와도 함께 동작해야 할 것입니다.

마지막으로, 이 3가지 컨테이너 관리 도구 모두는 오픈스택 매그넘(OpenStack Magnum) 그리고 애저 컨테이너 서비스(Azure Container Services)를 포함하여 다양한 클라우드플랫폼과도 동작합니다.

사용자가 자체적인 컨테이너 관리 도구 프로그램을 개발할 수도 있지만, 과연 다시 만들 이유가 있을까요? 3가지 관리 도구 모두 오픈소스 기반으로 만들어졌습니다. 사용자가 필요한 기능을 항상 추가할 수 있으므로 굳이 처음부터 다시 시작할 필요는 없겠죠.

대략적인 사항은 충분히 알아보았습니다. 이제 더 깊게 파고들어봅시다.

도커 스웜 모드
컨테이너를 처음 접한다면, 아마도 도커로 시작했을 것이며, 도커는 대규모 사용자 기반을 확보한 최초의 컨테이너 프로그램이었습니다. 컨테이너 인프라를 개발한 사람들이 만든 컨테이너 관리자(Container Manager)에 의지하는 것은 자연스러운 본능이며, 이는 도커 스웜을 의미합니다.

도커 1.12 당시, 도커의 진행 모델은 오케스트레이션을 내장하는 것으로, 도커는 스웜 모드라고 부릅니다. 도커의 독립형 오케스트레이터(Orchestrator)인 도커 스웜은 이 내장 기능보다 눈에 띄지 않게 되었습니다. 스웜 모드는 사용자에게 컨테이너 클러스터링이나 스케줄링뿐 아니라, 애플리케이션 생명주기 전체에 대한 통제력을 제공합니다.

도커 스웜과 스웜 모드의 차이점? 도커 1.12에서, 스웜 모드는 도커 엔진(Docker Engine)의 일부분입니다. 확장, 컨테이너 탐색, 그리고 보안이 최소한의 설정으로 모두 포함됩니다. 도커 스웜은 더 오래된 독립형 제품으로, 여러 대의 도커 호스트를 클러스터링 하는데 사용되곤 했습니다. 스웜 모드는 도커의 내장 클러스터 관리기입니다.

스웜 모드는 단일 노드 도커 개념을 사용하고 있으며 이런 개념들을 스웜으로 확장하고 있습니다. 예를 들어, 도커 클러스터를 구동하기 위해, 사용자는 스웜 모드로 전환하기 위해 run docker swarm init 명령어를 사용합니다. 더 많은 노드를 추가하기 위해서는 docker swarm join을 실행합니다.

또한, 도커 1,12 이상의 버전과 스웜 모드에는 롤링 업데이트, 노드들 간의 TLS(Transport Layer Security) 암호화, 부하 분산(Load Balancing: 로드 밸런싱), 그리고 쉬운 서비스 추상화(Service Abstraction)에 대한 지원이 포함되어 있습니다.

요약하면, 도커 스웜 모드는 컨테이너의 로드(부하)를 여러 대의 호스트로 분산하고, 사용자가 여러 대의 호스트 플랫폼 상에서, 스웜 (즉, 클러스터)를 설정할 수 있게 합니다. 통합 (그렇게 해서, 서로 다른 노드 상에서 구동하고 있는 컨테이너들이 서로 통신할 수 있도록)과 분리(서로 다른 컨테이너 워크로드를 격리하고 보호하기 위해)를 포함해서 호스트 플랫폼 상에 몇 가지 사항을 설정할 것을 요구하기도 합니다. 이런 필요사항을 충족하기 위해서는 가상 네트워크를 사용해야 합니다.

퀴베르네시스
퀴베르네시스는 원래 구글에서 개발된 오픈 소스 컨테이너 관리자입니다. 퀴베르네시스는 발표된 이후, 애저, DC/OS, 그리고 널리 알려진 거의 모든 클라우드 플랫폼에 이식되었습니다. 코어OS(CoreOS)로 AWS 상에 퀴베르네시스 클러스터를 배포하는 방법도 있지만, 한 가지 예외는 AWS(Amazon Web Service)입니다.

현재, 퀴베르네시스는 리눅스 재단의 클라우드 네이티브 컴퓨팅 재단(Cloud Native Computing Foundation: CNCF)이 주관하고 있습니다. 또한, 레드햇 오픈시프트(Red Hat OpenShift), Canonical Distribution of Kubernetes, 코어OS 테크토닉(Tectonic) 그리고 인텔과 미란티스를 포함한 수많은 기업의 퀴베르네시스 배포판이 존재합니다.

퀴베르네시스는 자가 수정(Self-healing), 자동 롤아웃과 롤백, 그리고 스토리지 오케스트레이션뿐 아니라 높은 수준의 상호운영성도 제공합니다. 그렇지만, 퀴베르네시스를 이용한 부하 분산은 어렵습니다. 결국, 퀴베르네시스 수신 트래픽은 퀴베르네시스 내부에서 외부 로드 밸런서를 구동하는 것을 쉽게 해주겠지만, 아직은 진행중인 작업입니다.

퀴베르네시스는 자동으로 문제를 해결하는 데 뛰어납니다. 그렇지만, 너무나 뛰어난 나머지 컨테이너가 장애를 일으켜도 너무 빨리 재가동되어 사용자가 컨테이너가 장애가 있었음을 알아차리지 못합니다. 이 문제를 해소하기 위해, 사용자는 중앙 집중형 로그기록 시스템을 추가할 필요가 있습니다.

메소스피어 마라톤
마라톤(Marathon)은 메소스피어의 DC/OS와 아파치 메소스(Mesos)를 위한 컨테이너 오케스트레이션 플랫폼입니다. DC/OS는 메소스 분산 시스템 커널을 기반으로 하는 분산 운영 체제입니다. 메소스는 오픈소스 클러스터 관리 시스템입니다. 마라톤은 (협력 프로그램인 고장 방지 작업 스케줄러 크로노스(Chronos)를 통해서) 사용자의 기존 스테이트풀(Stateful: 동작 상태 정보를 저장함) 애플리케이션과 컨테이너 기반의 스테이트리스(Stateless: 동작 상태 정보를 저장하지 않음) 애플리케이션 간의 관리 통합 기능을 제공합니다.

마라톤은 애플리케이션으로 생각할 수 있는 사용자 인터페이스를 가지고 있지만, 컨테이너 관리를 위한 프레임워크로 보는 것이 더 쉽습니다. 컨테이너가 REST API를 통해서 마라톤과 동작하기 때문에, 데브옵스의 개발자 측면을 간단히 언급하고 있습니다.

마라톤은 고 가용성, 서비스 탐색, 부하 분산을 포함하여 여러 가지 특성을 자랑합니다. DC/OS 상에서 구동한다면, 애플리케이션은 가상 IP 라우팅까지도 얻을 수 있습니다.

그렇지만, 마라톤은 메소스를 탑재한 소프트웨어 스택(Stack) 상에서만 구동할 수 있습니다. 또한, (인증 같은) 특정 기능은 DC/OS 상의 마라톤에서만 사용할 수 있습니다. 이는 사용자의 스택에 추상화 계층을 하나 더 추가합니다.

어떤 것이 알맞을까?
결국에는 사용자의 필요사항에 의해 좌우됩니다. 메소스와 퀴베르네시스는 대체로 클러스터링 된 애플리케이션을 구동하는 데 사용됩니다. 메소스는 포괄적인 스케줄링 그리고 여러 가지 상이한 스케줄러에 플러그 인(Plug in)하는데 초점을 맞추고 있습니다. 구글은 원래 컨테이너로부터 분산 애플리케이션을 구축하기 위한 환경으로서 퀴베르네시스를 설계했습니다.

도커 스웜 모드는 머신 클러스터를 단일 도커 API로 사용하기 더 쉽게 만들기 위해 기존 도커 API를 확장합니다. 회사 직원 중에 도커 전문가가 있다면, 어쩌면 이미 스웜 모드를 구동하고 있을 것입니다. 잘 작동하고 있다면, 귀찮게 다른 시스템으로 전환할 이유가 없습니다. 마라톤은 컨테이너와 구형 애플리케이션 두 가지 모두를 (비록 다단계이기는 하지만) 처리하기 위한 한 가지 방안을 제공한다는 고유의 이점이 있습니다.

다행스럽게도, 회사가 필요로 하는 독특한 혼합을 만들기 위해 이런 프로그램들을 짜 맞출 수 있습니다. 세 가지 모두 서로 잘 동작합니다. 쉽지는 않지만, 가능한 일이며, 아마도 옵션을 탐색하기 위한 좋은 방법일 것입니다.

컨테이너 관리 : 리더를 위한 교훈
- 컨테이너를 최대한 활용하기 위해, 훌륭한 컨테이너 관리 프로그램이 필요합니다. 3가지 주요한 애플리케이션은 퀴베르네시스, 메소스피어, 그리고 도커 스웜입니다. 각각의 특성은 다양하지만, 모두 컨테이너 프로비저닝, 감시, 그리고 관리를 지원합니다.

- 컨테이너 관리 외에, 메소스피어는 데이터 센터를 관리하는데 도움이 되는 특성을 가지고 있습니다.

- 도커 스웜 모드는 컨테이너 스케줄링에 대한 통제력을 제공함으로써 도커 클러스터링을 간소화하는 것을 목표로 합니다. 예를 들면, 컨테이너가 시작할 수 있는 노드를 제한하고, 도커 Remote API와 함께 동작하며, 클러스터의 어떤 노드에 새로운 컨테이너를 예약해야 할지를 사용자가 결정할 수 있게 합니다.

- 퀴베르네시스는 인텔, 마이크로소프트, 레드햇, 그리고 미란티스를 포함해서 폭넓은 업계 협력업체를 가지고 있습니다.


X