Container Vs. VM

이번 시간엔 컨테이너와 가상머신(VM; Virtual Machine)을 비교하는 시간을 갖고자 한다. 

 

VM - Container 비교

VM(Virtual Machine)

하나의 물리적인 컴퓨터(Baremetal) 위에 하이퍼바이저(Hypervisor)가 존재하여 H/W 자원(CPU, Memory 등)을 가상화한 레이어를 제공한다. VM은 하이퍼바이저 위에서 필요한 만큼의 자원이 할당된 가상의 컴퓨터로, 각각의 VM은 서로간의 존재를 알 수 없으며 커널을 포함한 OS는 독립적으로 실행된다. 

 

일반적으로 클라우드 환경에서 인프라(서버, 네트워크, 스토리지 등)를 프로비저닝하는데 가장 많이 사용되며, 환경을 분리하거나 전통적인 Monolithic Architecture 기반의 서비스를 운영하는데 쓰인다. 물리적인 컴퓨터와 기능면에선 차이가 없기 때문에 다양한 작업을 할 수 있는 것이 가장 큰 장점이지만, VM마다 자신의 OS를 갖고 있으므로 컨테이너와 비교하면 당연히 무거울 수 밖에 없다.

 

하이퍼바이저에 대해선 이전에 작성해 놓은 글이 있으므로 링크를 참고하기 바란다.

하이퍼바이저(Hypervisor)

 

Container

컨테이너는 별도의 격리된 환경에서 프로세스를 실행하는 개념에서 시작한다. Host 측에선 다른 프로세스와 다를 것이 없으며 투명하게 보이나, 컨테이너 내부에선 Host나 다른 컨테이너의 존재를 알 수 없으므로 나름의 격리가 이루어지는 셈이다. 보통 마이크로서비스 단위로 구성되며, 실행에 필요한 모든 것(ex: 라이브러리, 파일, 환경변수)을 담고 있는 Image로부터 생성된다. 

 

컨테이너는 Docker나 containerd와 같은 Container Runtime에 의해 Lifecycle이 관리되며, 내부적으로는 Linux Kernel 기능인 cgroup과 namespace를 통해 리소스 제한 및 환경에 대한 격리가 이루어진다. 

하나의 Host 안에 존재하는 모든 컨테이너는 동일한 커널을 공유한다는 점이 VM과 가장 큰 차이라고 할 수 있다. 컨테이너는 하이퍼바이저나 Guest OS가 존재하지 않기 때문에 서비스를 가볍고 빠르게 배포할 수 있는 장점을 갖고 있다. 또한 Kubernetes와 같은 Container Orchestration 플랫폼을 통해 수백~수천개의 컨테이너를 쉽게 관리 가능하다. 

이러한 이유로 Cloud Native Application 빌드나 마이크로서비스 패키징에 있어서 컨테이너는 불가피한 선택이라고 볼 수 있다.

 

결론

지금까지는 서비스 배포 관점에서 VM과 Container를 비교했을 뿐, 사실 Cloud Native 시대에선 둘다 잘 쓸 줄 알아야 한다. 대부분의 서버 인프라가 ec2나 gce와 같은 VM 기반으로 이루어져 있으며, 여기에 배포하는 서비스는 컨테이너로 패키징되어 있기 때문이다. DevOps 엔지니어는 여러모로 공부해야할 내용이 많다.