[가상머신 ( Virtual Machine , VM )]
클라우드 서비스 형태로는 기본 엔진 (AWS : EC2 , GCP : CGE 등) 으로 제공된다.
VM의 구현 방법에 따라 다르지만, 기본적으로 하이퍼바이저가 여러개의 VM을 띄우고 실행한다. 이때 중요한 것은 각 VM마다 독립된 실행 환경을 제공한다는 것이다. 즉 VM1과 VM2가 동일한 OS를 사용한다고 하더라도, 데이터는 물론이고 코드도 전혀 공유하여 사용하지 않는다.
이로 인해 각 VM마다 최소 GB 단위의 공간이 필요하며, VM 수에 비례해서 늘어나게 된다.
퍼포먼스 오버헤드도 상당하다. 하드웨어까지 가상화하는 전가상화(full-virtualization)이냐 그렇지 않은 반가상화(para-virtualization)이냐에 따라 다르지만, 보통 부팅 시에 상당한 시간이 소요된다.
전가상화의 느린 속도를 보완하기 위해 현재는 반가상화 방식으로 퍼포먼스를 제공하나 아직은 리얼 머신에 비해 느리다.
예를 들면 VMware, Virtual Box 와 같이 Host OS 위에 Guest OS를 가상화 하는 방식인데, 예전에는 Guest OS 전체를 가상화했고 이 방식은 간단하지만 무겁고 느려 운영환경에는 적용하기 어려웠다.
그래서 현재는 Xen 과 같은 반가상화 방식으로 구성된다.
[ 컨테이너 ( Container )]
무겁고 느린 가상화방식을 해결하기 위해 프로세스를 격리하는 방안이 등장했다.
컨테이너화는 커널 하나에 격리된 여러 개의 사용자 공간 인스턴스가 포함 될 수 있도록 애플리케이션 수준에서 이루어지는 가상화의 일종이다. 이런 인스턴스를 컨테이너라고 부른다.
컨테이너는 애플리케이션 코드, 런타임, 시스템 도구, 시스템 라이브러리 및 구성을 하나의 인스턴스에 패키징하는 기본적인 방법을 제공한다. 컨테이너는 하드웨어에 설치된 커널(운영 체제) 하나를 공유한다.
Docker의 컨테이너는 독립된 실행환경을 제공하지 않는다.
즉 OS의 많은 자원들을 컨테이너들끼리 공유한다( 높은 이동성 )
덕분에 부팅시간이 훨씬 짧고,
컨테이너 개수가 늘어나더라도 디스크 공간을 많이 차지하지 않는다.
또한, 컨테이너가 완전히 독립된 실행환경을 제공하지 않고 공유한다고 하더라도, 각 컨테이너 내의 프로세스들은 이를 감지하지 못하고, 자신이 OS의 모든 자원을 독점하고 있다고 생각한다.
[ 컨테이너와 가상머신]
개략적으로 컨테이너와 가상머신은 유사하다고 볼 수 있다. 이 두가지 모두 다양한 IT 요소를 결함해 시스템의 나머지 부분으로부터 분리하는 패키지 컴퓨팅 환경이기 때문이다. 차이점이라면 확장 방식과 이식성이다.
컨테이너는 일반적으로 크기가 MB 단위이다. 앱보다 크거나 실행하는데 필수적인 요소는 아니며, 특정 작업을 수행하는 단일 기능(마이크로서비스)이 컨테이너에 패키징되는 경우가 많다.
컨테이너는 경량화 속성과 공유 운영 체제로 인해 여러 환경 간에 매우 쉽게 이동한다.
가상머신은 일반적으로 크기가 GB 단위이다. 가상머신은 자체 OS를 포함하고 있어 리소스 집약적인 기능 여러 개를 동시에 수행 할 수 있다. 가상머신에서 사용할 수 있는 리소스가 늘어남에 따라 전체 서버, OS, 데스크탑, 데이터베이스, 네트워크를 추상화, 분할, 복제, 에뮬레이션 할 수 있다.
위에서 언급했듯 VM은 하이퍼바이저 위에 Guest OS 가 올라가는데 그 위에 Binary, 라이브러리 등을 모두 구성해야 하기에 무겁고 성능저하가 발생한다. ( 오버헤드 )
컨테이너 장점
1. 가벼움
서버에서 가상 머신보다 공간을 더 적게 차지하며, 시작하는데 일반적으로 몇 초 밖에 걸리지 않는다.
2. 탄력성
탄력적이여서 리소스를 별도로 할당할 필요가 없다. 따라서 컨테이너는 서버의 리소스를 더 효율적이고 동적으로 사용한다. 컨테이너 하나에 대한 수요가 감소하면 여분의 리소스를 다른 컨테이너에서 사용할 수 있다.
3. 밀도
밀도란 물리적 서버 한 대에서 동시에 실행할 수 있는 개체 수를 의미한다. 컨테이너화를 사용하면 호스트 서버의 리소스를 완전히 이용하지만 과다하게 이용하지 않는 밀집된 환경을 조성할 수 있다. 컨테이너는 전용 운영 체제를 호스트할 필요가 없으므로 가상화와 비교하여 보다 밀집한 환경이 가능하다.
4. 성능
리소스 압박이 큰 경우 애플리케이션 성능은 하이퍼바이저를 사용하는 것보다 컨테이너가 훨씬 우수하다.
가상머신에서는 게스트 OS도 자체 메모리 요구 사항을 충족해야 하기에 RAM을 호스트에서 가져와야한다.
5. 유지관리 효율
운영 체제 커널이 하나밖에 없기 때문에 운영 체제 수준에서 업데이트 또는 패치 작업을 한 번만 수행하면 변경사항이 모든 컨테이너에 적용된다. 이를 통해 서버를 더 효율적으로 운영하고 관리한다.
도커는 하이퍼바이저가 필요없고 도커엔진만 있으면 그 위에 어플리케이션, Binary, 라이브러리가 포함된 컨테이너만 올리면 되는 구성이다. OS의 자원인 커널을 공유하지만 어플리케이션 단위로 추상화하여 서로 격리하는 형태이다.
오버헤드가 없기에 시작 시간이 짧고, 자원 효율성이 높으며 메모리를 훨씬 적게 차지한다. Host OS가 어느 것이든 상관없이 도커 엔진만 있다면 배포가 가능하다. 이런 사항을 확장하면 멀티 클라우드, 하이브리드 환경 구축이 가능하다.
컨테이너 단점
보안 이슈가 있다. 컨테이너는 커널을 공유한다. 즉, 논리적으로 격리한 개념인데 당연히 물리적으로 격리한 가상머신에 비해서는 보안이 취약 할 수 밖에 없다. 그리고 컨테이너는 MSA( Microservice Architecture ) 와 최적화 되었을때 빛을 본다.
[ 컨테이너와 가상머신(VM) 의 차이 ]
| 하이퍼바이저 형 가상화 | 컨테이너 형 가상화 | |
| 시작 시간 | 길다 (분) | 짧다 (초) |
| 컨테이너 무게 |  수 GB ~ 수백 GB OS + 애플리케이션 + 런타임 소프트 웨어 |
 ~ 수백 MB 애플리케이션 + 런타임 소프트웨어 |
| Guest OS | Windows/Linux 등 다양한 선택 가능 | 호스트 OS와 동일한 OS |
| 이식성 | 대부분 가상 이미지에 대한 변환이 필요 | 컨테이너 이미지 그대로 사용 가능 |
| 데이터 관리 | VM 내부 또는 연결된 스토리지에 저장 | 컨테이너 내부에 있는 데이터는 종료시 소멸되며, 필요에 따라 스토리지를 이용하여 저장 |
| Guest OS 와 관계 | Guest OS는 하드웨어(가상)로 인식 | Host OS를 커널 수준으로 분리하여 OS를 가상화 형태로 사용, 필요에 따라 호스트와 리소스 공유 가능 |
| 시스템 성능 | 각 가상 머신마다 전용 운영 체제가 있기 때문에 가상 머신에 구축된 애플리케이션을 실행할 때 메모리 사용량이 필요 이상으로 많아져 가상 머신이 호스트에 필요한 리소스를 모두 사용할 수 있다. | 컨테이너화된 애플리케이션은 완전한 가상 머신보다 리소스를 더 적게 사용하고 호스트 메모리에 가해지는 부담을 줄일 수 있도록 운영 체제 환경(커널)을 공유한다. |
| 유지관리와 업데이트 |  운영 체제를 업데이트하거나 패치할 경우 기존 컴퓨터를 하나씩 업데이트해야 하고 각 게스트 OS를 개별적으로 패치해야 한다. |
 컨테이너 호스트(컨테이너를 호스트하는 컴퓨터)의 운영 체제만 업데이트하면 됩니다. 따라서 유지관리가 매우 간소화된다. |
[ 컨테이너 vs 가상머신 선택 기준 ]
쉽게 이동하는 작은 인스턴스(컨테이너)가 필요한지, 사용자 정의 IT 리소의 반영구적 할당이 필요한지에 따라 달라진다.
- 컨테이너 선택할 때
빠르게 자주 변경하고 다시 배포해야 하는 거의 모든 애플리케이션이 컨테이너화에 적합합니다. 마이크로서비스 아키텍처를 사용하는 애플리케이션의 경우에도 좋습니다.
이식성 :
컨테이너는 특성상 작고 가벼워 퍼블릭, 프라이빗, 하이브리드 및 멀티클라우드 환경뿐 아니라 베어메탈 시스템 간에도 쉽게 이동
자동 관리 환경 :
퍼블릭, 프라이빗, 하이브리드 및 멀티클라우드 환경 전반에 걸쳐 일관된 개발 및 자동 관리 환경을 제공하기 위해 설계된 마이크로서비스 컬렉션(클라우드 네이티브 애플리케이션)을 배포하기에 이상적이다.
빌드,최적화 가속화 :
클라우드 네이티브 애플리케이션을 사용하여 새 애플리케이션이 빌드 방법, 기존 애플리케이션이 최적화 방법, 이 모든 애플리케이션 연결 방법을 가속화한다. 주의할 점은 컨테이너가 기본 OS와 호환되어야 한다.
VM과 비교하여 다음 용도에 적합하다.
1. 클라우드 네이티브 애플리케이션 빌드
2. 마이크로서비스 패키징
3. DevOps 또는 CI/CD 프랙티스 촉진
4. 동일한 OS를 공유하는 다양한 IT 설치 공간에서 확장 가능한 IT프로젝트 전환
- 가상 머신을 선택할때
많은 작업 실행 :
가상머신(VM)은 모놀리식 워크로드 패키징에 사용되는 기존 방식인 단일 컨테이너보다 훨씬 더 많은 작업을 실행한다.
하지만 확장된 기능으로 인해 OS, 애플리케이션, 라이브러리에 의존하며 VM의 이식성이 크게 저하된다.
컨테이너와 비교해 다음 용도에 적합하다.
1. 기존, 레거시 및 모놀리식 워크로드 수용
2. 위험한 개발 사이클 분리
3. 인프라 리소스(ex: 네트워크, 서버, 데이터) 프로비저닝
4. 다른 OS에서 또 다른 OS 실행 (ex : 리눅스에서 유닉스 실행)
[ 작동 방법 ]
| 가상화 | 컨테이너 |
 |
 |
| 1. 하이퍼바이저라는 소프트웨어는 리소스가 파티셔닝되어 가상머신(VM)전용으로 할당될 수 있도록 리소스를 물리 머신에서 분리한다. 2. 사용자가 물리 환경의 추가 리소스를 요구하는 VM 명령을 발행하면 하이퍼바이저는 이 요청을 물리 시스템으로 전달하고 변경 사항을 캐싱한다. 3. VM은 물리 서버처럼 작동하므로 애플리케이션 종속성 및 대규모 OS 설치 공간의 단점을 증대한다. |
1. 컨테이너는 마이크로서비스 또는 애플리케이션과 이를 실행하는데 필요한 모든 것(이미지)이 포함되어있다. 2. 이미지라고 하는 모든 라이브러리와 종속성을 포함하는 코드 기반 파일에 저장된다. 3. 이 이미지는 RPM 패키지 및 구성 파일과 함께 제공되므로 이 파일은 Linux 배포 설치로 간주될 수 있다. 4. 컨테이너는 너무 작기 때문에 일반적으로 수백 개가 서로 느슨하게 결합되어 있으므로 컨테이너 오케스트레이션 플랫폼(ex: 쿠버네티드 , Red Hat OpenShift)을 사용하여 컨테이너를 프로비저닝하고 관리한다. |
* 컨테이너 오케스트레이션이란?
애플리케이션을 지원하기 위해 컨테이너를 배포하고 구성하는 것을 컨테이너 오케스트레이션이라고 하며, 컨테이너 오케스트레이션 도구를 통해 수행된다. (ex : Kubernetes, Docker Swarm, LXC)
참고 :
https://showx123.tistory.com/54
https://www.redhat.com/ko/topics/containers/containers-vs-vms
