[Container] 컨테이너란?

Contents

1. VM vs. Container

2. VM Image vs. Container Layered Image

3. Container 장점

---

 

 

Container 기술이 무엇인지, VM과  비교를 통해 알아보고 Container가 갖는 장점에 대해 이야기 합니다.

---

1. VM vs. Container

많은 글들에서 VM과 Container의 차이를 다루고 있습니다.

이 글 또한 그 많은 글들 중 하나이며, 최대한 쉽게 VM과 Container의 차이를 설명하고자 합니다.

 

VM과 Container의 근본적인 차이점은 가상화를 수행하는 수준 입니다.

이 근본적인 차이에서부터 VM과 Container의 종속적(?)인 차이점들이 생겨 납니다.

 

먼저 VM은 하드웨어(또는 인프라) 수준에서 가상화가 이루어집니다.

한개의 하드웨어(CPU, RAM) 자체를 복수개의 자원인양 격리하는 것이 가상화입니다.

이러한 VM을 위한 하드웨어 가상화는 Hypervisor라는 녀석이 수행합니다.

 

 

 

Hypervisor가 제공하는 하드웨어 가상화를 통해 복수의 사용자가 하드웨어 자원을 할당 받았다고 합시다.

그렇다면, 각각의 사용자는 이 하드웨어를 구동할 OS가 필요하게 됩니다.

따라서 VM의 경우는 각 사용자마다 할당 받은 하드웨어 자원 위에 서로 다른 Guest OS를 실행 합니다.

 

따라서 VM은 Guest OS와 Host OS가 분리 되며,

Guest VM에 Guest OS가 올라가게 됩니다.

 

Guest OS와 Host OS가 서로 다르기 때문에,

I/O device에 접근하는 경우 Guest OS kernel 시스템콜 -> Host OS kernel 시스템콜 로 변환이 필요합니다.

여러 VM이 동일 I/O device에 접근하는 경우에는 이러한 kernel 변환 작업에 병목이 생긴다는 문제가 있습니다.

 

 

 

반면 Container는 Host OS 수준에서 가상화가 이루어집니다.

OS가 제공하는 사용자 격리 도구들 (namespace, cgroup 등)을 활용하여 각 Container들을 격리 합니다.

 

 

 

쉽게 말하면 Container는 결국 프로세스 입니다.

 

따라서 각 Container들은 Host OS를 공유하며,

Host OS의 중개를 통해 하드웨어 자원에 접근합니다.

Host OS라는 하드웨어를 구동시킬 OS가 이미 존재하므로,

Container 자체에는 guest OS가 필요 없습니다.

 

Guest OS가 없으니, kernel 변환 작업도 필요 없습니다.

따라서 I/O device 접근이 VM에 비해 빠릅니다.

 

 

2. VM Image vs. Container Image

Image는 어떤 시스템의 상태를 사진으로 찍듯이 저장해둔 파일을 의미합니다.

VM Image는 이러한 '사진찍기' 의미에 그대로 대응합니다.

 

VM은 Guest OS 부터 그 위에 올라간 파일들을 그대로 찍어내어 Image로 생성합니다.

따라서 동일한 파일들을 일부 포함하고 있는 VM들 간에도 완전히 새로운 Image를 새로 생성 합니다.

 

더 나은 이해를 위해 Container Image와 비교해봅시다.

Container Image는 Layer를 이루고 있습니다.

(Union File System이라는 것을 기반으로 Layered 구조를 취합니다.)

'Layer', 즉, Image를 통째로 관리 하는 것이 아니라, 계층을 나누어 관리 합니다.

아래와 같은 예시 그림을 봅시다.

 

 

Image#1은 bootfs와 그 위에 ubuntu, centOS와 같은 OS를 포함한 base image 계층으로 구성된 이미지 입니다.

이 Image#1 위에 어떤 사용자가 App1, App2를 설치했다고 합시다.

그러면 Image#2는 Image#1을 바탕으로, 새로 추가된 App1, App2 계층만을 본래 Image#1 파일에 merge 합니다.

 

다음으로 동일한 사용자가 Imgae#2를 사용하다가, App1을 업데이트 하여 App1' 이라는 녀석으로 교체한 상황을 가정합시다.

그러면 수정된 App1' 부분만을 Image#2에 merge하여 Image#3를 생성할 수 있습니다.

이와 같이 Container가 제공하는 Layered Image는

변경된 계층만을 업로드/다운로드 하여, 이미지 배포/통합 시간을 단축시킵니다.
 

 

 

3. Container 장점

위 내용들을 바탕으로 Container의 장점을 정리해 봅시다.

 

 

첫 번째, 빠르고 쉬운 배포가 가능합니다.

Layered 구조를 갖는 Container 이미지의 구조 덕분에,

새로 업데이트 된 이미지를 빠르게 다운 받을 수 있습니다.

(앞서 말했듯, 변경된 layer 부분만 다운로드 하기 때문입니다.)

 

이와 더불어 guest OS를 포함하지 않아 Container의 up-time은 굉장히 빠릅니다.

VM이 수 분에 걸쳐 up이 되는데 반해 Container는 수 초 만에 up 됩니다.

따라서 업데이트된 버전의 이미지를 빠르게 받아오고, 빠르게 실행할 수 있습니다.

 

뿐만 아니라 Kubernetes나 OpenShift와 같은 Container Orchestration 도구들과 함께 사용한다면, 이러한 배포과정을 자동화할 수 있습니다.

 

두 번째, 훌륭한 이식성을 제공합니다.

Container는 OS 수준에서의 가상화 이기 때문에,

OS 수준을 가상화하는 Container 런타임만 있으면 Container 사용이 가능합니다.

따라서 host 환경이 VM이던, baremetal이던, 또는 Window던 Linux던, Container 런타임만 설치된 환경이라면 어디에나 Container를 구동할 수 있습니다.

 

마지막 세 번째, 운영 비용을 절감할 수 있습니다.

VM에 비하여 Container는 하나의 host에 더 많은 격리 환경을 제공할 수 있습니다.

따라서 하나의 host를 더 많은 사용자들에게 제공할 수 있으므로,

운영자의 관점에서 인프라 비용을 절약 할 수 있습니다.

 

또한, Container의 경우는 guest OS가 올라가지 않기 때문에

보통 OS 라이센스 구입 비용 또한 절약 할 수 있습니다.

 

위에서 Orchestrator를 사용하면 배포 자동화를 구성할 수 있다고 말씀드렸습니다.

Orchestrator는 배포 자동화 뿐만 아니라 관리 자동화까지도 지원합니다.

Orchestrator의 관리 자동화 기능을 사용하면 운영에 드는 시간적 비용을 절감할 수 있습니다.