2016.05.13

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

Steven J. Vaughan-Nichols | Network World

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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




2016.05.13

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

Steven J. Vaughan-Nichols | Network World

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


X