2015.07.20

도커를 사용한 컨테이너 오케스트레이션 방법

Simon Bisson | InfoWorld
차세대 애플리케이션을 구축하는 것과 그 애플리케이션을 관리하고 운영하는 것은 전혀 다른 문제다.

흔히 비유되는 사례로 애완동물과 소 이야기가 있다. 사람들은 애완동물의 건강을 유지하는 데 각별히 신경을 쓴다. 관리자가 모든 요소를 이중화해 하이엔드 서버를 관리하는 것과 비슷하다.

그러나 농장의 관점에서 보면 죽은 소 한 마리는 비즈니스 비용의 일부일 뿐이다. 마찬가지로 애플리케이션이 장애를 견디도록 설계되는 지금의 클라우드 환경에서는 서버 한 대가 고장나는 것은 대수로운 문제가 아니다.

비유하자면 요즘 사용되는 애플리케이션 오케스트레이션 툴의 역할은 가상 서버와 컨테이너라는 소를 적절한 목장 내에 방목하는 것이다. 서버 하나가 죽으면 즉시 새 VM, 또는 경우에 따라 새 컨테이너를 가동시킨다. 이 모든 과정이 자동화되므로 시스템 관리자가 개입할 일은 없다. 어느 서버 또는 컨테이너(또는 이 둘의 조합)가 애플리케이션을 실행하고 있는지 정확히 알 수도 없다.

자동화된 IT는 업계의 오랜 꿈이었는데, 최신 툴들이 마침내 자동화에 제대로 부합하는 기능을 제공하기 시작한 것이다. 클라우드급 애플리케이션을 다루는 경우, 특히 확장형 마이크로서비스에서 이런 툴은 필수적이다.

데이터센터용 운영체제
여기서 데이터센터 운영체제 개념이 사용된다. 개별 서버는 연산, 저장 또는 네트워킹의 한 요소라는 점 외에는 더 이상 중요하지 않다. 애플리케이션은 가상 머신 또는 컨테이너에 묶이며 주 관리 요소가 된다.

관리자는 개별 서버를 관리하는 대신 전체 데이터센터를 관리하고 다양한 애플리케이션의 지원 필요에 따라 데이터센터를 분할한다. 기반 하드웨어에 대해 아무것도 알 필요 없이 개발, 테스트 및 배포 환경을 구축한다. 서버와 애플리케이션을 관리하는 방식이 대대적으로 바뀐 것이다. 새로운 시대의 시작이다. 특정 워크로드를 위한 하드웨어 프로비저닝은 이제 과거 시대의 유물이다.

핵심 개념은 오케스트레이션(orchestration), 즉 애플리케이션과 서비스를 동적으로 배치해 가용한 연산 리소스를 활용하는 것이다. 오케스트레이션은 분산, 자동화된 컴퓨팅에서 중요한 툴이다. 오케스트레이션은 애플리케이션 정의(application definitions)와 매니페스트(manifests)를 사용해 호스트와 워크로드 배치를 결정하고 확장을 관리하고 장애가 발생한 서버와 서비스가 적절히 처리되도록 한다.

오케스트레이션 솔루션은 많지만 가장 유명한 것은 구글 쿠베르네테스(Kubernetes)와 아파치 메소스(Mesos) 프로젝트다. 두 가지 모두 복잡한 툴로서 기술과 리소스에 대한 상당한 투자를 요하며 대규모 설비에 가장 적합하다.

규모가 작은 기업들의 경우 마이크로소프트, 오픈스택, VM웨어 등이 제공하는, 오케스트레이션이 포함된 프라이빗 클라우드를 선택했다. 그러나 대부분의 조직은 차세대 애플리케이션을 제공하는 데 필요한 프로세스와 툴들을 여전히 실험하는 중이다.

도커를 사용한 방목
여기서 필요한 것은 서버 1~2개에서 시작해 랙 1~2개로, 그 다음 전체 데이터센터로 확장할 수 있는 툴이다. 도커의 컨테이너 자동화 툴인 머신(Machine), 스웜(Swarm), 컴포즈(Compose)가 바로 이 방식을 취하는 툴들이다.

머신은 호스트 서버를 설정하고 프로비저닝하는 프로세스를 자동화하므로 도커 자동화 툴의 심장이라 할 수 있다. 머신은 도커 API를 사용해 호스트 서버를 설정하고 도커 엔진을 프로비저닝하고 클라이언트 툴을 준비하는 하나의 명령을 제공한다.

또한 기존 스웜(Swarm) 클러스터에 호스트를 붙이거나 새 클러스터를 만들 수 있다. 컨테이너는 다양한 클라우드 제공업체에서 작동하므로 명령행(command line)을 사용해 원하는 클라우드 환경에서 호스트를 설정하면 된다.

컨테이너 호스트 생성을 자동화하고 도커 엔진을 실행했다면 이제 도커의 클러스터링 툴인 스웜을 사용해 연산 패브릭으로 이러한 호스트를 가져올 수 있다. 스웜은 표준 도커 엔진 인스턴스와 동일한 API를 사용해 컨테이너를 위한 확장 가능한 환경을 제공한다.

이미 데브옵스 환경에서 도커를 실행 중이라면 스웜을 설치하고 기존 데브옵스 툴과 프로세스를 가져오는 방법으로 신속하게 확장할 수 있다. 내장된 스케줄러가 개별 도커 엔진 노드로 컨테이너를 할당하는 작업을 처리하며, 최적화를 위한 여러 가지 전략을 지원한다.

스웜을 만들기도, 기존 클러스터에 새 엔진을 추가하기도 쉽다. 머신을 사용해서 자동으로 새 엔진을 만들거나 도커 API를 사용해 가용 노드 인덱스를 제공할 수 있다. 도커 허브 레지스트리를 사용해서 검색(discovery)을 간소화하고 스웜이 등록된 호스트를 식별하고 관리하도록 하는 것도 한 가지 방법이다.

컴포즈(Compose)는 조금 더 복잡한 툴이다. YAML과 작동해 애플리케이션 설명을 작성하고 애플리케이션에 사용되는 다양한 컨테이너가 어떻게 서로 연결되는지를 보여준다. YAML은 API의 스웨거(Swagger)와 같이 애플리케이션을 설명하기 위한 툴에 접근할 수 있게 해준다. 애플리케이션과 애플리케이션 구축에 대한 설명을 작성하고 나면 스크립트 한 줄만으로 애플리케이션을 실행할 수 있다.

단순하게 유지하기
도커 오케스트레이션 툴에서 가장 흥미로운 부분은 단순함이다. 세 가지 툴 모두 단순한 명령을 사용하므로 젠킨스(Jenkins)와 같은 도구에서 스크립트를 작성하거나 퍼펫(Puppet) 또는 셰프(Chef)와 같은 환경에서 관리하는 일도 그다지 어렵지 않다.

기존 도커 API를 기반으로 구축되므로 개발용 PC에서 사용하는 것과 동일한 툴을 사용해 손쉽게 분산 환경을 관리하고 제어할 수 있으며 개발에서 프로덕션으로의 이동도 간소화할 수 있다.

도커의 툴은 쿠베르네테스와 같은 데이터센터 관리 툴과 잘 맞고 퍼블릭 클라우드가 제공하는 도구와도 함께 사용이 가능하다. 머신, 스웜, 컴포즈 조합을 사용하면 개발 단계부터 단일 서버에서의 테스트, 그리고 애저 또는 AWS에서 실행되는 전체 규모의 클라우드 서비스에 이르기까지 애플리케이션을 다룰 수 있다.

개발자는 자신이 컨테이너를 어디로 보내는지 알 필요가 없다. 클라우드 규모의 메소스 구현에서 실행되는 경우라도 겉으로는 하나의 스웜으로 보일 뿐이다. 결국 이런 수준의 추상화가 바로 클라우드의 핵심이다. editor@itworld.co.kr


2015.07.20

도커를 사용한 컨테이너 오케스트레이션 방법

Simon Bisson | InfoWorld
차세대 애플리케이션을 구축하는 것과 그 애플리케이션을 관리하고 운영하는 것은 전혀 다른 문제다.

흔히 비유되는 사례로 애완동물과 소 이야기가 있다. 사람들은 애완동물의 건강을 유지하는 데 각별히 신경을 쓴다. 관리자가 모든 요소를 이중화해 하이엔드 서버를 관리하는 것과 비슷하다.

그러나 농장의 관점에서 보면 죽은 소 한 마리는 비즈니스 비용의 일부일 뿐이다. 마찬가지로 애플리케이션이 장애를 견디도록 설계되는 지금의 클라우드 환경에서는 서버 한 대가 고장나는 것은 대수로운 문제가 아니다.

비유하자면 요즘 사용되는 애플리케이션 오케스트레이션 툴의 역할은 가상 서버와 컨테이너라는 소를 적절한 목장 내에 방목하는 것이다. 서버 하나가 죽으면 즉시 새 VM, 또는 경우에 따라 새 컨테이너를 가동시킨다. 이 모든 과정이 자동화되므로 시스템 관리자가 개입할 일은 없다. 어느 서버 또는 컨테이너(또는 이 둘의 조합)가 애플리케이션을 실행하고 있는지 정확히 알 수도 없다.

자동화된 IT는 업계의 오랜 꿈이었는데, 최신 툴들이 마침내 자동화에 제대로 부합하는 기능을 제공하기 시작한 것이다. 클라우드급 애플리케이션을 다루는 경우, 특히 확장형 마이크로서비스에서 이런 툴은 필수적이다.

데이터센터용 운영체제
여기서 데이터센터 운영체제 개념이 사용된다. 개별 서버는 연산, 저장 또는 네트워킹의 한 요소라는 점 외에는 더 이상 중요하지 않다. 애플리케이션은 가상 머신 또는 컨테이너에 묶이며 주 관리 요소가 된다.

관리자는 개별 서버를 관리하는 대신 전체 데이터센터를 관리하고 다양한 애플리케이션의 지원 필요에 따라 데이터센터를 분할한다. 기반 하드웨어에 대해 아무것도 알 필요 없이 개발, 테스트 및 배포 환경을 구축한다. 서버와 애플리케이션을 관리하는 방식이 대대적으로 바뀐 것이다. 새로운 시대의 시작이다. 특정 워크로드를 위한 하드웨어 프로비저닝은 이제 과거 시대의 유물이다.

핵심 개념은 오케스트레이션(orchestration), 즉 애플리케이션과 서비스를 동적으로 배치해 가용한 연산 리소스를 활용하는 것이다. 오케스트레이션은 분산, 자동화된 컴퓨팅에서 중요한 툴이다. 오케스트레이션은 애플리케이션 정의(application definitions)와 매니페스트(manifests)를 사용해 호스트와 워크로드 배치를 결정하고 확장을 관리하고 장애가 발생한 서버와 서비스가 적절히 처리되도록 한다.

오케스트레이션 솔루션은 많지만 가장 유명한 것은 구글 쿠베르네테스(Kubernetes)와 아파치 메소스(Mesos) 프로젝트다. 두 가지 모두 복잡한 툴로서 기술과 리소스에 대한 상당한 투자를 요하며 대규모 설비에 가장 적합하다.

규모가 작은 기업들의 경우 마이크로소프트, 오픈스택, VM웨어 등이 제공하는, 오케스트레이션이 포함된 프라이빗 클라우드를 선택했다. 그러나 대부분의 조직은 차세대 애플리케이션을 제공하는 데 필요한 프로세스와 툴들을 여전히 실험하는 중이다.

도커를 사용한 방목
여기서 필요한 것은 서버 1~2개에서 시작해 랙 1~2개로, 그 다음 전체 데이터센터로 확장할 수 있는 툴이다. 도커의 컨테이너 자동화 툴인 머신(Machine), 스웜(Swarm), 컴포즈(Compose)가 바로 이 방식을 취하는 툴들이다.

머신은 호스트 서버를 설정하고 프로비저닝하는 프로세스를 자동화하므로 도커 자동화 툴의 심장이라 할 수 있다. 머신은 도커 API를 사용해 호스트 서버를 설정하고 도커 엔진을 프로비저닝하고 클라이언트 툴을 준비하는 하나의 명령을 제공한다.

또한 기존 스웜(Swarm) 클러스터에 호스트를 붙이거나 새 클러스터를 만들 수 있다. 컨테이너는 다양한 클라우드 제공업체에서 작동하므로 명령행(command line)을 사용해 원하는 클라우드 환경에서 호스트를 설정하면 된다.

컨테이너 호스트 생성을 자동화하고 도커 엔진을 실행했다면 이제 도커의 클러스터링 툴인 스웜을 사용해 연산 패브릭으로 이러한 호스트를 가져올 수 있다. 스웜은 표준 도커 엔진 인스턴스와 동일한 API를 사용해 컨테이너를 위한 확장 가능한 환경을 제공한다.

이미 데브옵스 환경에서 도커를 실행 중이라면 스웜을 설치하고 기존 데브옵스 툴과 프로세스를 가져오는 방법으로 신속하게 확장할 수 있다. 내장된 스케줄러가 개별 도커 엔진 노드로 컨테이너를 할당하는 작업을 처리하며, 최적화를 위한 여러 가지 전략을 지원한다.

스웜을 만들기도, 기존 클러스터에 새 엔진을 추가하기도 쉽다. 머신을 사용해서 자동으로 새 엔진을 만들거나 도커 API를 사용해 가용 노드 인덱스를 제공할 수 있다. 도커 허브 레지스트리를 사용해서 검색(discovery)을 간소화하고 스웜이 등록된 호스트를 식별하고 관리하도록 하는 것도 한 가지 방법이다.

컴포즈(Compose)는 조금 더 복잡한 툴이다. YAML과 작동해 애플리케이션 설명을 작성하고 애플리케이션에 사용되는 다양한 컨테이너가 어떻게 서로 연결되는지를 보여준다. YAML은 API의 스웨거(Swagger)와 같이 애플리케이션을 설명하기 위한 툴에 접근할 수 있게 해준다. 애플리케이션과 애플리케이션 구축에 대한 설명을 작성하고 나면 스크립트 한 줄만으로 애플리케이션을 실행할 수 있다.

단순하게 유지하기
도커 오케스트레이션 툴에서 가장 흥미로운 부분은 단순함이다. 세 가지 툴 모두 단순한 명령을 사용하므로 젠킨스(Jenkins)와 같은 도구에서 스크립트를 작성하거나 퍼펫(Puppet) 또는 셰프(Chef)와 같은 환경에서 관리하는 일도 그다지 어렵지 않다.

기존 도커 API를 기반으로 구축되므로 개발용 PC에서 사용하는 것과 동일한 툴을 사용해 손쉽게 분산 환경을 관리하고 제어할 수 있으며 개발에서 프로덕션으로의 이동도 간소화할 수 있다.

도커의 툴은 쿠베르네테스와 같은 데이터센터 관리 툴과 잘 맞고 퍼블릭 클라우드가 제공하는 도구와도 함께 사용이 가능하다. 머신, 스웜, 컴포즈 조합을 사용하면 개발 단계부터 단일 서버에서의 테스트, 그리고 애저 또는 AWS에서 실행되는 전체 규모의 클라우드 서비스에 이르기까지 애플리케이션을 다룰 수 있다.

개발자는 자신이 컨테이너를 어디로 보내는지 알 필요가 없다. 클라우드 규모의 메소스 구현에서 실행되는 경우라도 겉으로는 하나의 스웜으로 보일 뿐이다. 결국 이런 수준의 추상화가 바로 클라우드의 핵심이다. editor@itworld.co.kr


X