컨테이너 vs. 가상 머신 : 기업에 맞는 것 선택하는 방법

모든 IT 업체가 컨테이너에 투자하고 있다. 구글, IBM, 마이크로소프트 모두 마찬가지다. 그러나 컨테이너가 폭발적인 인기를 끈다고 해서 가상 머신의 시대가 끝난 것은 결코 아니다.

물론 컨테이너를 사용하면 가상 머신보다 훨씬 더 많은 애플리케이션을 한 대의 물리 서버에 집어넣을 수 있다. 클라우드 또는 데이터센터의 집적도 측면에서 도커와 같은 컨테이너 기술은 가상 머신을 앞선다.

VM은 훨씬 더 많은 시스템 리소스를 사용한다. 각 VM은 단순히 운영체제의 복사본만 실행하는 것이 아니라 그 운영체제의 실행을 위해 필요한 모든 하드웨어의 복사본도 실행한다. 따라서 많은 RAM과 CPU 사이클이 빠른 속도로 소비된다. 반면 컨테이너에는 운영체제와 보조 프로그램, 라이브러리, 그리고 특정 프로그램을 실행하기 위한 시스템 리소스만 있으면 된다.

즉, 컨테이너를 사용하면 VM에 비해 2~3배 더 많은 애플리케이션을 하나의 서버에 집어넣을 수 있다. 컨테이너를 사용하면 개발, 테스트, 배포를 위한 이식 가능하고 일관서 있는 운영체제를 만들 수 있다는 것도 큰 장점이다.

컨테이너와 가상 머신의 대결에서 이것이 전부라면 지금쯤 필자는 VM 사망 선고 기사를 쓰고 있을 것이다. 그러나 물리 서버에 몇 개의 애플리케이션을 넣을 수 있느냐는 전체 그림의 한 부분일 뿐이다. 그보다 훨씬 더 많은 내용이 있다.

컨테이너 문제 #1: 보안
뜨거운 인기 탓에 간과되는 경우가 많은 컨테이너의 가장 큰 문제는 보안이다. 레드햇의 보안 엔지니어인 다니엘 월시는 도커와 컨테이너에 대해 "컨테이너는 통제하지 않는다"고 말했다. 예를 들어 도커는 libcontainers를 컨테이너 기술로 사용한다. libcontainers는 리눅스에서 작동하기 위해 프로세스, 네트워크, 마운트, 호스트 이름, 공유 메모리의 5가지 네임스페이스에 접근한다. 어느 정도까지는 괜찮지만 컨테이너 외부에는 중요한 리눅스 커널 서브시스템이 많다.

여기에는 모든 디바이스, SELinux, Cgroups와 /sys 아래의 모든 파일 시스템이 포함된다. 즉, 사용자나 애플리케이션이 컨테이너 내에서 superuser 권한을 갖는 경우 이론적으로 기본 운영체제가 크랙될 수 있다. 이건 좋지 않다.

현재 도커와 기타 컨테이너 기술을 보호할 수 있는 방법은 많다. 예를 들어 /sys 파일 시스템을 읽기 전용으로 마운트하고, 컨테이너 프로세스가 컨테이너별 파일 시스템에만 쓸 수 있도록 강제하고, 지정된 사설 인트라넷에만 연결되도록 네트워크 네임스페이스를 설정하는 등의 방법이 있다. 그러나 어떤 방법도 기본적으로 내장된 것은 아니다. 컨테이너를 보호하기 위해서는 많은 노력이 필요하다.

기본적인 규칙은 서버 애플리케이션을 다룰 때와 똑 같은 방법으로 컨테이너를 다뤄야 한다는 것이다. 월시는 이를 다음과 같이 설명했다.

• 최대한 신속하게 권한을 낮출 것
• 가능한 경우 항상 루트가 아닌 권한으로 서비스를 실행할 것
• 컨테이너 내의 루트를 컨테이너 외부의 루트처럼 다룰 것

또 다른 보안 문제는 많은 사람들이 컨테이너화된 애플리케이션을 배포한다는 것이다. 이러한 애플리케이션 중에는 상태가 좋지 않은 것이 있다. 예를 들어 담당자가 조금 게을러서 눈에 띄는 아무 컨테이너나 설치한다면 서버에 트로이 목마가 유입될 수도 있다. 스마트폰에서 게임을 다운로드하듯 인터넷에서 앱을 다운로드하면 안 된다는 것을 담당자들에게 주지시켜야 한다.

물론 게임도 아무거나 마구 다운로드하면 안 되지만 그건 여기서 다루는 내용과는 관계없는 또 다른 보안 문제다.

기타 컨테이너 관련 우려
그렇다면 보안 문제만 해결할 수 있다면 컨테이너가 무조건 최고일까? 그렇지 않다. 보안 외에도 고려할 부분이 있다.

랙앤(RackN)의 CEO이자 오픈스택 재단 이사인 롭 허치펠드는 "패키징이 여전히 까다롭다. 잠긴 박스를 만들면 다운스트림 문제를 일부 해결할 수 있지만(무엇을 갖고 있는지 알 수 있음) 업스트림 문제는 해결되지 않는다(무엇에 의존하는지 알 수 없음)"고 말했다.

이것은 보안 문제지만 품질 보증의 문제이기도 하다. 물론 X 컨테이너는 NGINX 웹 서버를 실행할 수 있지만 이것이 원하는 버전인가? TCP 로드밸런싱 업데이트를 포함하는가? 컨테이너에 앱을 배포하기는 쉽지만 잘못된 것을 설치하는 경우 그 결과는 시간 낭비일 뿐이다.

허치펠드는 컨테이너의 난립이 심각한 문제가 될 수 있다는 점도 지적했다. 즉 "배포를 여러 개의 개별적인 기능적 파트로 분할하는 것은 현명한 방법이지만 이 말은 관리해야 할 파트가 더 많아짐을 의미하기도 한다. 관심사의 분리(separation of concerns)와 무질서한 난립 사이에는 변곡점이 있다"는 점을 의식해야 한다는 것을 의미한다.

컨테이너의 핵심은 하나의 애플리케이션을 실행하는 것임을 명심하라. 컨테이너에 더 많은 기능을 넣을수록 애초에 가상 머신을 사용했어야 한다는 것을 의미한다.

물론 리눅스 컨테이너(LXC)와 같은 일부 컨테이너 기술은 VM 대신 사용할 수도 있다. 예를 들어 LXC를 사용해서 레드햇 엔터프라이즈 리눅스(RHEL) 6 전용 애플리케이션을 RHEL 7 인스턴스에서 실행할 수 있다. 그러나 일반적인 관점에서는 단일 애플리케이션을 실행하는 데는 컨테이너를 사용하고, 여러 애플리케이션을 실행하는 데는 VM을 사용하는 것이 좋다.

컨테이너와 VM 사이에서 결정하기
그래서 VM과 컨테이너 중에서 무엇을 사용할지 어떻게 결정하란 말인가? VM웨어 엔지니어링 설계자인 스콧 로우는 작업의 "범위"를 고려하라고 조언했다. 달리 말하자면 단일 애플리케이션, 예를 들어 MySQL의 여러 복사본을 실행하려면 컨테이너를 사용한다. 여러 애플리케이션을 실행할 수 있는 유연성을 원한다면 가상 머신을 사용한다.

또한 컨테이너는 특정 운영체제 버전에 얽매이는 경향이 있다. 이 부분은 장점이 될 수도 있다. 일단 컨테이너에서 애플리케이션이 제대로 실행된다면 종속성에 대해 걱정할 필요가 없기 때문이다. 그러나 제약이 되기도 한다. VM에서는 어떤 하이퍼바이저에서든(KVM, 하이퍼-V, v스피어, 젠 등) 모든 운영체제를 실행할 수 있다. QNX에서만 실행되는 희귀한 앱을 실행해야 하는가? VM을 사용하면 쉽지만 현재 세대의 컨테이너에서는 간단치 않다.

그럼 명확히 결론을 내보도록 하자.

최소한의 서버에서 최대한 많은 수의 특정 애플리케이션을 실행해야 하는가? 그렇다면 컨테이너를 사용해야 한다. 컨테이너 보안을 확보할 때까지 컨테이너를 실행하는 시스템을 면밀하게 관찰해야 한다는 점을 명심하라.

서버에서 여러 애플리케이션을 실행하거나 다양한 운영체제가 있다면 VM을 사용해야 한다. 또한 보안을 가장 중요시한다면 현재로서는 VM을 계속 사용하는 것이 좋다.

현실에서 대부분은 클라우드와 데이터센터에서 컨테이너와 VM을 모두 사용하게 될 것이다. 컨테이너의 규모의 경제는 무시하기에는 비용 측면의 이점이 너무 크다. 그러나 VM도 나름의 장점이 있다.

엔터프라이즈 클라우드 관리 기업 라이트스케일(RightScale)의 CTO인 토스텐 본 아이켄은 컨테이너 기술이 성숙해질수록 VM과 컨테이너가 함께 극한의 클라우드 이식성을 구현하게 될 것이라고 말했다. 아직 그 단계에 이르지는 못했지만 앞으로 도달하게 될 것이다.