구글의 클라우드 컴퓨팅 아키텍처와 오픈소스 컨테이너 프로젝트 Docker

구글의 클라우드 플랫폼 담당 시니어 소프트웨어 앤지니어인 Joe Beda씨는 Containers At Scale이라는 타이틀로 구글의 스케일링 아키텍처에 대해서 설명하는 슬라이드 자료를 발표했다.

오늘은 이 자료를 통해 세계최고의 IT서비스 기업중 하나인 구글이 채택하고 있는 클라우드 아키텍처를 살펴보고자 한다.

구글의 모든 서비스들은 컨테이서안에서 실행된다. 

(Everything이 굵은 글자로 강조되고 있음을 놓치지 말자!)

• 구글 사내의 어플리케이션을 포함한 구글의 모든 서비스들은 모두 이 컨테이너 안에서 실행되고 있다. (역자주: 현재 구글이 퍼블릭 크라우드 서비스로 제공하고 있는 App Engine또한 이 컨테이서 상에서 동작되고 있다. 자세한것은 App Engine Architecutre 문서를 살펴보자.)
• 구글은 매주 20억개 이상의 컨테이너를 기동하고 있다. (역자주 : 세계 인구는 2013년 1월 기준으로 71억명 이다!) 

컨테이너란?

컨테이너는 프로그램이 작동하기 위한 최소한의 요소들을 묶어 패키징한 것으로 OS보다 작으면서 독립적인 배포와 실행을 가능하게 하는 일종의 가상 머신이다. 대표적인 오픈소스 컨테이너 기술인 docker가 최근 급속도로 인기를 끌고 있다. 대부분의 컨테이너 스텍은 LXC(Linux Containers)를 기초로 만들어졌으며 docker또한 LXC와 호환이 된다.

컨테이너가 동작하는 아키텍쳐 레이어

파란색 부분은 시스템 전체에서 공유되는 부분이며 노랑색 부분이 개별 컨테이너에 해당되는 부분이다.

여기서 컨테이너 아키텍처를 잘 모르시는 분들을 위해 이 추가로 설명을 해 보도록 하겠다.

가상환경에 어플리케이션을 배포하고자 할때 흔히 겪는 문제들은 다음과 같다.

• 가상환경 서버라고는 해도 환경변수나 언어버전, 라이브러리 버전이 달라 어플리케이션이 동장을 하지 않는다
• 개발환경에서는 잘 움직이다가도 프로덕션 환경에서 제대로 움직이지 않는다
• 기존환경의 가동을 중단시키지 않으면서도 새로운 어플리케이션이나 기능을 추가하고자 한다

이를 해결하기 위해 등장한 것이 지금부터 소개할 차세대 가상화 오픈소스 프로젝트인  docker이다.

차세대 오픈소스 가상화 프로젝트 docker

docker는 Go언어로 작성되어 있으며 오직 리눅스 커널에만 의존 한다. 다시 말해 자바의 바이트 코드가 자바VM이 작동되는 곳 이라면 어디든지 작동 가능했던 것 처럼 docker는 리눅스 커널만 작동 가능한 환경이라면 어느곳 이든 동일한 동작을 보장한다.

이러한 컨테이너 방식의 가상화는 개발자와 운영자에게 어떠한 장점이 있을까?

개발자 입장에서 컨테이너 방식의 가상화 개발은 컨테이너 내부의 관리에만 신경을 써 주면 되고, 한번의 컴파일 만으로도 모든 환경에서동일한 동작을 보장 받게 된다. 패키지의 의존관계나 네이티브 라이브러리, 심지어 DB에 이르기 까지 말이다!
반면 DevOps엔지니어의 입장에서는 한번 설정 만으로 모든 어플리케이션의 배포를 보장 받게 되며, 여기에 운영자에게 여러모로 편리한 로그감시나 리모트억세스, 네트워크설정, 리소스 모니터링 기능이 충실히 따라온다.

docker는 가상 os환경과도 다른데, docker만의 특징을 잘 설명해주는 그림이 여기 있다.

효율성과 편의성. 두마리 토끼를 잡아라!

일반적인 가상OS환경(IaaS)에서는 호스트OS위에 게스트OS가 어플리케이션 수 만큼 올라가야 하므로 게스트OS에 소모되는 리소스 낭비가 많다는 단점을 지닌다. 이에비해 docker engine은 OS자체를 가상화 하는것이 아닌 어플리케이션 작동에 필요한 최소한의 바이너리와 라이브러리만을 가상화 함으로서 이러한 오버헤드를 줄일 수 있게된다. 간단히 말해 docker는 PaaS 클라우드를 구현하기 위한 아키텍처라고 할 수 있으며, 플렛폼 자체의 확장이나 변경이 보다 수월하다는 점에서 기존의 PaaS에서 좀 더 발전된 형태라고 할 수 있다.

docker는 장해 발생시에 그 진가를 발휘하는데, 모든 컨테이너는 고유의 ID를 지니는 동시에 업데이트시에 변경 차분을 보관하기 때문에 장해가 발생되었을 경우 롤 백이 손쉽게 가능하며, 이는 어플리케이션 뿐만이 아니라 DB에도 적용이 된다.

이번에  Joe Beda가 발표한 자료를 통해 구글은 Container Manifest라고 하는 yaml로 작성된 일종의 배포 디스크립터를 독자적으로 개발하여 이용하고 있음을 알 수 있는데, 이를 통해 컨테이너 동작에 필요한 자원 할당과 데이터 소스에 대한 공유를 수행한다. 참고로, 오리지널 사양의 docker는 리눅스의 리소스 제어툴인 cgroups를 이용하여 리소스를 제어한다.
Container Manifest의 상세에 대해서는 구글에서 제공하는 문서를 참고하길 바란다.

아마존의 EC2를 사용해 본 사람이라면 어느정도 수긍하겠지만, OS의 가상화는 관리라는 측면에서 보면 물리서버를 운영하는것과 비교해 더 낫다고 말하기 힘들다. 고작해야 하드웨어 관리에 대한 수고를 덜 수 있을 뿐이고, OS를 비롯해 환경변수나 라이브러리를 구축해야 하는 과정은 사실상 동일하다고 볼 수 있다.

또한 오버헤드의 측면에서도 512MB의 메모리를 지닌 가상머신 인스턴스가 어플리케이션에서 사용 가능한 메모리가 절반에도 미치지 못한다는 점을 감안해 본다면 docker 아키텍처의 유용함을 잘 알 수 있을것이다.

  docker아키텍처를 이용한 가상화는 어플리케이션 배포에 소요되는 노력과 오버헤드를 줄여주며, 프로덕션 환경과 개발환경의 차이를 없애주어 요휼적인 리소스 사용과 다양한 장해에 대한 대응을 가능케 해 준다.

구글이 현재 IT계에서 차지하고 있는 위치와 영향력을 감안해 볼 때에, 구글이 채택하고 있는 컨테이너 아키텍쳐는 어떠한 형태로든지 아마존이나 마이크로소프트와 같은 업체들에 영향을 끼칠것이며(이미 아마존은 대응을 시작했다. AWS Adopts Docker Containers For Elastic Beanstalk ) 조만간 클라우드 컴퓨팅의 중요한 흐름으로 우리 앞에 나타나게 될 것으로 예측해 본다.

관련링크

스케일링과 관련하여 프로덕션 환경에서의 Docker적용에 대해서 좀 더 알아보고 싶다면 다음의 링크들이 도움이 될 것이다.

• About Docker
• How to scale Docker containers in production - SteakOverflow
• AUTO-LOADBALANCING DOCKER WITH FIG, HAPROXY AND SERF
• AppScale on Docker

최종 수정일 : 2014년 12월18일