VM(가상머신)

VM 은 클라우드 서비스 형태로는 기본 엔진 (AWS 에서 EC2 하나가 VM) 으로 제공이 된다.
VM의 구현 방법에 따라 다르지만, 기본적으로 하이퍼바이저가 여러개의 VM을 띄우고 실행한다. 이때 중요한 것은 각 VM마다 독립된 실행 환경을 제공한다는 것이다. 즉 VM1과 VM2가 동일한 OS를 사용한다고 하더라도, 데이터는 물론이고 코드도 전혀 공유하여 사용하지 않는다.

이로 인해 각 VM마다 최소 GB 단위의 공간이 필요하며, VM 수에 비례해서 늘어나게 된다.
퍼포먼스 오버헤드도 상당하다. 하드웨어까지 가상화하는 전가상화(full-virtualization)이냐 그렇지 않은 반가상화(para-virtualization)이냐에 따라 다르지만, 보통 부팅 시에 상당한 시간이 소요된다.

아래는 하이퍼바이저의 설명과 가상화 종류에 대한 간단한 설명이며, 링크를 통해 더 자세한 설명을 확인할 수 있다.

Hypervisor (하이퍼바이저)

가상화의 종류 3가지

전가상화

하드웨어를 완전히 가상화하는 것이다. 시스템 바이오스, CPU, 메모리 등 시스템의 모든 하드웨어를 가상화 한다.
Guest OS 들과 네이티브 하드웨어 사이를 중재하는 가상머신(하이퍼바이저)을 사용하며, Guest OS 에서 발생한 하드웨어 접근하기 위해 기존의 OS 를 통해서 접근한다.
Guest OS 와 하드웨어 사이에 VM 을 거쳐 전달하므로 성능은 떨어지자만, Guest OS 수정없이 바로 사용가능하다.

반가상화

모든 하드웨어의 반 정도만 가상화하고 나머지 반은 실제 하드웨어의 기능을 그대로 이용한다.
전가상화보다 속도가 빠르지만 Guest OS 수정이 필요하다.
특권모드 명령어를 HyperCall 로 변환하여 실행한다. (Hypercall: H/W에 접근할 때 사용하는 명령)
Guest OS 의 명령을 중간 단계 없이 바로 하드웨어에 전달하므로 성능은 향샹되지만 Guest OS 의 커널 수정이 필요하다.

Container(컨테이너)

무겁고 느린 가상화방식을 해결하기 위해 프로세스를 격리하는 방안이 등장한다.
컨테이너화는 커널 하나에 격리된 여러 개의 사용자 공간 인스턴스가 포함 될 수 있도록 애플리케이션 수준에서 이루어지는 가상화의 일종이다. 이런 인스턴스를 컨테이너라고 부른다. 
컨테이너는 애플리케이션 코드, 런타임, 시스템 도구, 시스템 라이브러리 및 구성을 하나의 인스턴스에 패키징하는 기본적인 방법을 제공한다. 컨테이너는 하드웨어에 설치된 커널(운영 체제) 하나를 공유한다.

컨테이너와 가상머신

컨테이너는 일반적으로 크기가 MB 단위이다. 앱보다 크거나 실행하는데 필수적인 요소는 아니며, 특정 작업을 수행하는 단일 기능(마이크로서비스)이 컨테이너에 패키징되는 경우가 많다.

컨테이너는 경량화 속성과 공유 운영 체제로 인해 여러 환경 간에 매우 쉽게 이동한다.

가상머신은 일반적으로 크기가 GB 단위이다. 가상머신은 자체 OS를 포함하고 있어 리소스 집약적인 기능 여러 개를 동시에 수행 할 수 있다. 가상머신에서 사용할 수 있는 리소스가 늘어남에 따라 전체 서버, OS, 데스크탑, 데이터베이스, 네트워크를 추상화, 분할, 복제, 에뮬레이션(하드웨어적으로 수행되는 작업을 소프트웨어로 흉내) 할 수 있다.

위에서 언급했듯 VM은 하이퍼바이저 위에 Guest OS 가 올라가는데 그 위에 Binary, 라이브러리 등을 모두 구성해야 하기에 무겁고 성능저하가 발생한다. ( 오버헤드 )

컨테이너 장점

• 가벼움 : 서버에서 가상 머신보다 공간을 더 적게 차지하며, 시작하는데 일반적으로 몇 초 밖에 걸리지 않는다.
• 탄력성 : 탄력적이여서 리소스를 별도로 할당할 필요가 없다. 따라서 컨테이너는 서버의 리소스를 더 효율적이고 동적으로 사용한다. 컨테이너 하나에 대한 수요가 감소하면 여분의 리소스를 다른 컨테이너에서 사용할 수 있다.
• 성능 향상 : 리소스 압박이 큰 경우 애플리케이션 성능은 하이퍼바이저를 사용하는 것보다 컨테이너가 훨씬 우수하다. 가상머신에서는 Guest OS도 자체 메모리 요구 사항을 충족해야 하기에 RAM을 호스트에서 가져와야한다.
• 유지관리 효율: 운영 체제 커널이 하나밖에 없기 때문에 운영 체제 수준에서 업데이트 또는 패치 작업을 한 번만 수행하면 변경사항이 모든 컨테이너에 적용된다. 이를 통해 서버를 더 효율적으로 운영하고 관리가 가능하다. 도커는 하이퍼바이저가 필요없고 도커엔진만 있으면 그 위에 어플리케이션, Binary, 라이브러리가 포함된 컨테이너만 올리면 되는 구성이다. OS의 자원인 커널을 공유하지만 어플리케이션 단위로 추상화하여 서로 격리하는 형태이다. 

컨테이너 단점

• 보안 이슈 : 컨테이너는 커널을 공유한다. 즉, 논리적으로 격리한 개념인데 당연히 물리적으로 격리한 가상머신에 비해서는 보안이 취약 할 수 밖에 없다. 그리고 컨테이너는 MSA(Microservice Architecture) 와 최적화 되었을때 빛을 본다.

컨테이너와 가상머신 선택 기준

컨테이너 선택할 때

빠르게 자주 변경하고 다시 배포해야 하는 거의 모든 애플리케이션이 컨테이너화에 적합하다.주로 마이크로서비스 아키텍처를 사용하는 애플리케이션의 경우에도 사용을 한다.

다음과 같은 용도에 적합

• 클라우드 네이티브 애플리케이션 빌드
• 마이크로서비스 패키징
• DevOps 또는 CI/CD 구성 가속화

가상 머신을 선택할때

가상머신(VM)은 모놀리식 워크로드 패키징에 사용되는 기존 방식인 단일 컨테이너보다 훨씬 더 많은 작업을 실행한다. 하지만 확장된 기능으로 인해 OS, 애플리케이션, 라이브러리에 의존하며 VM 의 이식성이 크게 저하된다.

다음과 같은 용도에 적합

• 기존, 레거시 및 모놀리식 워크로드
• 위험한 개발 사이클 분리

간단 정리

가상 머신(VM)과 컨테이너(Container)는 현대 소프트웨어 개발 및 배포에서 핵심적으로 사용하고 있다.정리를 하면서 두 기술은 각각의 장점과 한계를 갖고 있으며, 상황에 따라 VM을 사용하는 것이 더 적합할 수도 있으며, 컨테이너만이 해결책이 될 수 있는 것은 아니라는 점을 글을 정리하면서 생각이 되었다.