The future of Linux Containers

리눅스 컨테이너의 미래

‘The future of Linux Containers(리눅스 컨테이너의 미래)’는 솔로몬 하익스(Solomon Hykes)가 Pycon2013에서 진행했던 발표 제목이다. 당시 닷클라우드(dotCloud) 직원이던 그는 5분 남짓 짧은 발표를 통해 그동안 개발해온 도커(Docker)를 처음 세상에 공개했다. 발표내용은 정말 간단했다. 프로그래밍 언어를 처음 배울 때 누구나 작성하는 ‘헬로우 월드(Hello World)’를 도커로 찍는 것을 보여줬다. 이 발표는 지금도 유튜브에서 볼 수 있다(맘이 급했는지 ‘Hello Wowlrd’라고 오타를 냈다). blog.docker.com/2013/03/the-future-of-linux-containers/

도커로 ‘Hello World’를 찍는 명령어는 간단하다.

<리스트 1> 도커로 ‘Hello World’ 찍기$docker run busybox echo ‘Hello World’

하지만 다른 ‘Hello World’ 프로그램처럼 이 데모도 도커의 많은것을 보여준다.

- if(busybox 도커 이미지가 없으면) 서버로부터 busybox 이미지를 다운로드
- busybox 컨테이너를 만들고
- 컨테이너에서 stdout으로 ‘Hello World’가 출력되면
- 출력결과가 (컨테이너에서 호스트로 전송되어) 사용자 터미널에 보인다.

언뜻보기에는 화면에 ’Hello World’를 출력하는것처럼 보이지만 실은 가상서버와 유사한 컨테이너를 만들고 그 안에서 echo 명령을 실행하고 컨테이너가 결과를 서버로 전송한다. 도커를 하는 엔지니어로 이 발표를 볼때마다 짜릿함을 느낀다. 지난 2015년 6월23일 도커콘(DockerCon)2015가 샌프란시스코에서 열렸다. 도커 최고경영자(CEO) 벤갈럽(Ben Golub)과 최고기술책임자(CTO) 솔로몬 하익스가 키노트를 했다. 키노트를 통해서 지난 한해동안 도커가 얼마나 성장했는지 숫자로 보여줬다. 2014년과 비교했을때 깃허브(github) 프로젝트 갯수는 515%, 도커 관련 구인은 1,720%, 컨테이너 다운로드수는 18,082% 성장했다. 현재 직업을 찾고 있다면 도커를 배워야 하지 않을.까^^;도커가 빠르게 성장하고 있는 기술이라는 사실은 더이상 설명할 필요가 없다.

리눅스 컨테이너(Linux Container)와 하이퍼바이저(Hypervisor)

이렇게 많은 사람들이 도커에 관심을 보이는 이유는 뭘까. 그 이유를 정확히 이해하기 위해서는 리눅스 컨테이너를 설명하지 않을수 없다.

리눅스컨테이너(LXC)는 단일 리눅스 호스트에 격리된(isolated) 리눅스 시스템을 여러개 실행하는 운영체제(OS) 수준의 가상화 기술이다.리눅스 커널은 가상머신 없이 CPU, 메모리, 블록I/O, 네트워크 같은 리소스를 제한하고 우선순위를 정하기 위해 cgroups기능을 제공하고 애플리케이션 관점에서 운영환경을 완전히 제약하기 위해 namespace 기능을 제공한다. - 위키피디아

리눅스 컨테이너는 최신 기술이 아니다. 이미 나온지 10년이 넘은 구식() 기술이다. 도커가 등장하기 전부터 LXC, OpenVZ, Imctfy, Warden 같은 오픈소스가 이미 존재했다. 그럼 왜 지금까지 널리 쓰이지 못한걸까. 그 이유는 사용성에서 찾을수 있다. LXC는 사용하기 복잡하고 어려워서 일반 사용자가 쉽게 접근할수 없었다. 이런 리눅스 컨테이너의 벽을 도커가 깨뜨린 것이다.

시기도 적절했다고 본다. Xen, KVM, vSphere, Hyper-V 등 많은 하이퍼바이저(Hypervisor) 기술이 경쟁하면서 가상서버의 안정성이 높아졌다. 가상화 기술이 널리 보급되면서 사람들은 가상서버를 사용하는 것에 익숙해졌다. 과거 베어메탈을 쓰던것에 비해 가상서버는 다양한 편의성을 제공했고 서버 효율도 높여주었지만 서면 앉고 싶고, 앉으면 눕고 싶은게 사람 마음다. 하이퍼바이저보다 더 가볍고 빠른 기술을 찾기 시작하면서 리눅스 컨테이너 기술인 도커로 눈을 돌리게 된 것이다. <그림 3>은 도커 컨테이너가 왜 가상머신(VM)에 비해 가벼운지를 나타내는 대표적인 그림이다. 게스트 OS가 필요없는 도커는 더 적은 디스크, 더 적은 메모리에서도 마치 VM처럼 동작한다.

현재 컨테이너를 사용하는 기업들

이쯤되면 슬슬 궁금해져야 한다. 도커와 같은 컨테이너 기술을 사용해서 서비스를 제공하는 회사는 어떤 곳이 있을까 첫번째는 당연히 구글이다. 구글은 이미 10여 년 전부터 컨테이너 기술을 사용해왔다고 발표했다. 앞에서 리눅스 컨테이너 기술을 소개하면서 언급했던 콘트롤그룹(cgroups)도 구글 엔지니어가 2006년부터 시작한 기술이다.

구글이 발표한 논문 ‘Large-scale cluster management at Google with Borg’에 따르면 구글은 보그(Borg)라는 클러스터 매니저를 개발했다. C++로 개발된 보그는 수만대 서버로 구성된 클러스터에 수십만개의 잡(Job)을 실행한다. 보그를 개발하던 엔지니어들은 현재는 쿠버네티스(kubernetes)를 개발한다고 들었다. 쿠버네티스는 고(Go)로 개발됐으며 현재 기준으로 가장 완성도 높은 컨테이너 오케스트레이션 시스템으로 볼 수 있다. 구글 클라우드 플랫폼에서도 사용하고 있다. 지난 5월 ‘오스콘(OSCON)2015’에서 v1을 정식발표했다. 구글은 지메일(gmail)같은 자사 대표 서비스를 모두 컨테이너 기반으로 제공한다.

중국의 구글이라고 부르는 바이두(Baidu) 역시 2013년 말부터 도커를 이용한 플랫폼으로써의 서비스(PasS) ‘바이두 앱 엔진(Baidu App Engine)’을 제공한다. 바이두의 BAE 기술리더 Yifel Chen은 이렇게 발표했다.

우리는 도커에 빠졌다. 컨테이너기술은 앞으로 샌드박스를 대체하게 될 것이다.도커는 우리 개발자들이 필요로 하는 많은 프레임워크와 애플리케이션을 사용할수 있도록 다양한 언어,애자일, 비용효율적인 대안을 제공한다. 도커가 제공하는 위협적인 에코 시스템에 참여하게 되어 기쁘게 생각한다. - 출처 blog.docker.com/2013/12/baidu-using-docker-for-its-paas/

페이스북은 ‘도커콘(DockerCon)2014’에서 ‘Tupperware: Containerized Deployment at FB’ 발표를 통해 LXC기반 컨테이너 관리 시스템 타파웨어(Tupperware)를 소개했다. 15,000개 이상의 서비스를 30만개 이상의 프로세스로 운영하고 있으며 이를 위해 개발한 것이 타파웨어다. 페이스북은 도커가 나오기 전부터 리눅스 컨테이너를 사용했기 때문에 LXC를 사용한다. 바이너리 패키지 저장소를 비트토렌토(BitTorrent) 기반으로 구축한 것도 흥미롭다. 도커 이미지 저장소 성능이슈를 생각한다면 이런 접근이 나온 이유가 성능 때문이라는 걸 짐작할 수 있다. VM 대신 컨테이너를 선택한 이유는 성능상의 불이익을 피하고 하이퍼바이저가 디버깅을 더 어렵게 하기 때문이라고 말한다.

여기서 소개한 구글,바이두,페이스북 사례 외에도 컨테이너 기반으로 서비스를 운영하는 회사는 많다. 대규모 서비스를 제공하면서 VM의 한계를 느끼게 되었고, 이를 넘어 인프라를 효율적으로 운영하기 위해서 컨테이너를 선택한다. 그렇다면 컨테이너가 VM과 비교했을때 좋은점만 있는걸까.

컨테이너 관련 이슈

리눅스 컨테이너 기술에 대한 이슈는 계속 제기되어 왔다. 첫번째 화살은 컨테이너가 IP를 갖지 못한다는 점이었다. 도커고 도커 컨테이너를 실행하면 컨테이너는 ‘docker0’ 네트워크 드라이버를 기준으로 사설 IP를 할당받는다. 이 IP는 해당 서버내에서만 고유하다.

이 말은 서버 외부에서 IP를 통해 컨테이너에 직접 접근할수 없다는 뜻이다. 외부에서 컨테이너에 접근할수 있게 하려면 호스트에 컨테이너를 바인딩 시켜야한다. 이 때문에 포트(Port) 부족현상이 나타난다. 내가 실행한 엔진엑스(nginx) 서버에서 80포트를 쓰고 싶은데 이미 누가 80포트를 사용중이라면 사용할 수 없는 거다. 멀티 호스트간에 컨테이너 네트워킹 이슈에 대한 첫번째 해결책은 앰버서더 패턴이었다.

각 도커 호스트에 컨테이너를 연결하는 앰버서더 컨테이너를 두고 이를 이용해 통신하는 형태였다. 이 형태는 너무 많은 컨테이너를 만들어야 하는 불편이 있었다. 최근에는 오버레이 네트워크 기술을 이용해 이 이슈를 해결하고 있다. 오버레이 네트워크는 네트워크를 가상화하는 기술로서 멀티 호스트들을 연결하는 네트워크 레이어를 가상으로 만들어준다. 이를 위한 오픈소스로는 flannel, Open vSWitch, Weave가 대표적이다. 최근 도커도 이를 위한 기능을 추가하겠다고 발표했다(원래는 1.7에 들어간다고 했으나 1.9에 들어갈것으로 예상된다). 두번째 이슈는 보안이다. 컨테이너는 사실 호스트 서버에서 실행되는 프로세스다. 그렇다보니 VM에 비해 격리수준이 떨어진다. 자신만의 게스트 OS를 가진 가상머신은 해당 서버가 악의적인 사용자의 공격에 의해 위험에 노출된다 해도 그 서버 내로 위험범위를 제한할 수 있다. 그렇지만 격리수준이 떨어지는 컨테이너는 호스트 전체에 영향을 미칠 수 있다.

예를 한 번 들어보겠다. 물리서버에 도커를 설치하고 엔진엑스 컨테이너를 1개 만든다. 도커는 컨테이너를 만들때 CPU 사용률을 지정할수 있다. 예를 들어 사용률을 1로 준 후 이 컨테이너에 부하를 주면 이 컨테이너는 물리서버의 CPU를 거의 사용한다. 다른 프로세스들도 CPU를 쓰기 때문에 100%를 사용하지는 않는다. 이번에는 CPU 사용률을 1로 준 엔진엑스 컨테이너를 2개 만들어 보겠다다. 부하를 주게되면 이번에는 두 개 컨테이너 각각이 대략 50%를 사용한다. 사용률은 고정값이 아니라 비율이다. VM은 이렇게 동작하지 않는다. 처음에 10%를 사용하도록 지정하면 서버에 여유가 있어도 10%만 사용한다. 이 부분은 컨테이너의 장점이기도 하지만 단점으로 보는 사람도 있다.

이런 특징이 위험하다고 생각되면 컨테이너에 CPU 코어를 지정하면 된다. 예를 들어 CPU가 32개 있는 서버에서 6번째 CPU를 지정하겠다면 아래와 같이 컨테이너를 실행한다.

<리스트 2> 컨테이너에 CPU 코어 지정하기$ docker run -d -cpuset=6 nginx

물리머신에 VM을 설치하고 VM내에서 컨테이너를 실행할 수도 있다. 요즘 유행하는 오픈스택 KVM을 만들고 그 안에서 컨테이너를 실행하는 형태다. 이 경우 격리수준은 좋아지지만 VM이 차지하는 만큼의 성능 페널티가 발생한다. VM을 사용하기 싫다면 메소스(Mesos)를 사용할 수도 있다. 메소스 슬레이브(Mesos Slave)에 도커 컨테이너를 실행하게 되면 슬레이브에 의해 제한된 리소스 범위내에서만 컨테이너가 자원을 사용하게 된다(이 경우도 CPU는 완전히 격리되지 않는다). 이 두가지 외에도 다양한 이슈가 있지만 컨테이너를 사용하려는 사람들이 늘면서 다양한 오픈소스가 이를 해결하고 있다.

그래서 미래는

결론이다. 리눅스 컨테이너가 VM에 비해 가볍고 빠르지만 다양한 이슈를 아직 가지고 있다. 그럼에도 많은 기업들은 앞다투어 도커를 도입하고 있다. 구글, 페이스북 같은 글로벌 기업은 물론이고 국내에서도 도커를 이용한 사례가 하나씩 등장하고 있다. 지난 9월 14~15일에 열린 ‘데뷰(DEVIEW)2015’에서 네이버는 도커 기반 빌드배포시스템 십독(ShipDock)을 개발 중이라고 소개했다. 쿠버네티스 기반 빌드서버 풀로 사내에 지속적인 통합(Continuous Delivery) 플랫폼을 구축하기 위한 시도로 보인다. SK플래닛에서도 2014년말부터 도커 기반 클라우드 플랫폼 구축을 위해 프로젝트를 진행하고 있다. 이 프로젝트에 대한 내용은 10월 7일 열리는 ‘테크플래닛(TechPlanet)2015’에서 자세히 소개할 예정이다.

출처 : 마이크로소프트웨어 10월호

제공 : 데이터 전문가 지식포털 DBguide.net