[Docker] 하이퍼바이저 및 컨테이너 가상화와 도커 아키텍쳐

이 글은 인프런의 개발자를 위한 쉬운도커(데브위키) 강의를 수강하고 개인적으로 정리하는 글임을 알립니다.

---

하이퍼바이저 가상화

가상 머신(Virtual Machine)

• 두 개의 가상 머신이 물리적 서버에서 실행되고 있으며, 각각 리눅스(Linux)와 맥(MacOS) 운영체제를 사용하는 게스트 OS(Guest OS)를 가지고 있다.
• 가상 머신은 각기 독립적인 프로세스를 실행하고, 리소스(예: CPU, 메모리, 저장공간)를 할당받아 운영된다.
• 각 게스트 OS는 자체 커널(Kernel)을 가지고 있으며, 사용자 프로세스는 이 커널을 통해 시스템 자원에 접근하게 된다.

 

하이퍼바이저(Hypervisor)

• 가상 머신들을 관리하는 소프트웨어 계층이다.
• 하이퍼바이저는 물리적 서버 자원을 추상화하여 각 가상 머신에 필요한 리소스를 할당하고 관리한다.
• 게스트 OS 간에는 커널이 독립적이기 때문에, 그림에서 표시된 것처럼 서로 간의 커널 호출은 허용되지 않는다. 즉, 서로의 커널로 직접 접근할 수 없으며, 하이퍼바이저를 통해서만 자원을 요청하거나 할당받는다.
  
  

호스트 OS(Host OS)

• 하이퍼바이저는 호스트 운영체제 위에서 실행되며, 물리적 서버 자원에 접근하고 관리하는 역할을 수행한다.
• 그림에서 보여지는 호스트 OS는 윈도우(Windows) 기반이다.

 

서버(Server)

• 물리적 하드웨어 자원(CPU, RAM, 디스크 등)을 제공하는 실제 서버이다. 이 서버 위에서 하이퍼바이저와 가상 머신들이 운영된다.

 

 

전체적인 흐름

• 각 가상 머신의 프로세스는 시스템 호출(System Call)을 통해 자신의 커널을 거쳐 자원을 요청한다.
• 자원 사용 요청은 하이퍼바이저를 통해 물리적 서버의 리소스와 연결된다.
• 각 가상 머신은 독립적으로 운영되며, 하이퍼바이저는 가상 머신 간의 리소스 충돌을 방지하고, 필요한 자원을 관리한다.

 

 

컨테이너 가상화

컨테이너 가상화는 하이퍼바이저 가상화에 비해 가볍고 빠르다라는 장점을 가지고 있다.

 

컨테이너 가상화는 가상 머신(VM)과는 다른 방식으로 가상화된 환경을 제공하는 기술이다. 컨테이너는 응용 프로그램과 그 실행에 필요한 모든 라이브러리, 종속성, 설정 파일 등을 하나의 패키지로 묶어 독립적으로 실행할 수 있게 해준다.

 

호스트 OS 공유

• 컨테이너는 호스트 운영체제의 커널을 공유한다. 따라서 각 컨테이너는 별도의 커널을 사용하지 않고, 호스트 커널에서 격리된 환경에서 동작한다.
• 이는 가상 머신처럼 하이퍼바이저가 물리적 하드웨어를 추상화하고 각 VM에 커널을 할당하는 방식과는 다르다. 즉, 가상 머신에 비해 리소스 사용이 효율적이다.

 

가벼움(Lightweight)

• 컨테이너는 VM과 달리 게스트 운영체제를 포함하지 않기 때문에 더 가볍고 빠르게 시작할 수 있다. 컨테이너는 수 MB에서 수백 MB 정도의 크기지만, 가상 머신은 수 GB에 달할 수 있다.
• 컨테이너는 수 초 내에 시작하거나 중단할 수 있어 애플리케이션 배포 및 관리를 매우 빠르게 수행할 수 있다.

 

격리성(Isolation)

• 컨테이너는 각기 독립적인 프로세스와 파일 시스템을 가지고 있지만, 호스트 운영체제의 커널을 공유하는 특성 때문에 완전한 하드웨어 격리는 제공하지 않는다.
• 그러나 네임스페이스(Namespaces)와 cgroups(Control Groups) 기술을 통해 프로세스, 네트워크, 파일 시스템, 메모리, CPU 등 자원들을 서로 격리할 수 있다.

 

효율적인 자원 사용

• 하이퍼바이저 기반의 가상 머신에 비해 컨테이너는 더 적은 자원으로 더 많은 애플리케이션을 실행할 수 있다. 여러 컨테이너가 하나의 호스트 커널을 공유하기 때문에 메모리와 CPU 사용량을 줄일 수 있다.
• 리소스를 동적으로 할당할 수 있어 자원을 보다 효율적으로 사용할 수 있다.

 

이식성(Portability)

• 컨테이너는 애플리케이션을 실행하는데 필요한 모든 라이브러리와 종속성을 포함하므로, 한 번 빌드된 컨테이너는 어디서든지 동일하게 실행될 수 있다.
• 예를 들어, 로컬 개발 환경에서 테스트한 컨테이너를 클라우드나 다른 서버 환경으로 옮겨도 동일한 환경에서 실행이 가능하다.

 

오케스트레이션 가능

• 여러 개의 컨테이너를 관리하고 조정할 수 있는 오케스트레이션 도구(예: Kubernetes)를 통해 대규모 애플리케이션을 유연하고 안정적으로 관리할 수 있다.
• 이를 통해 컨테이너의 배포, 확장, 모니터링 등이 자동화될 수 있다.

 

보안

• 컨테이너는 VM에 비해 커널을 공유하기 때문에 이론적으로 더 많은 보안 취약점을 가질 수 있다. 그러나 SELinux, AppArmor 등의 보안 강화 도구를 통해 보안성을 높일 수 있다.

 

빠른 배포 및 롤백

• 컨테이너는 애플리케이션 배포 속도가 매우 빠르다. 이미지를 빌드한 후 신속하게 배포할 수 있으며, 문제가 발생하면 이전 버전으로의 롤백도 간단하게 처리할 수 있다.

 

 

 

하이버바이저 가상화와 컨테이너 가상화 비교

아키텍처 구조

• 하이퍼바이저 가상화:
  -하이퍼바이저(타입 1 혹은 2)가 물리적 하드웨어를 가상화하여 여러 가상 머신(VM)을 생성하고 관리한다.
  -각 가상 머신은 자체 운영체제(게스트 OS)를 가지고 있으며, 이 운영체제는 각기 독립적인 커널을 사용한다.
  -하이퍼바이저는 물리적 서버 자원을 관리하며, 각 가상 머신이 요청하는 자원을 분배한다.
  
  
• 컨테이너 가상화:
  -컨테이너는 호스트 운영체제의 커널을 공유하며, 각 컨테이너는 애플리케이션과 필요한 라이브러리만을 포함한다.
  -컨테이너는 하드웨어 가상화가 아닌 OS 수준에서 가상화된다.
  -네임스페이스와 cgroups 같은 기술을 통해 자원과 프로세스를 격리하지만, 각 컨테이너는 동일한 커널을 사용한다.

 

운영체제(커널)

• 하이퍼바이저 가상화:
  -각 가상 머신은 자체 운영체제(리눅스, 윈도우 등)를 가질 수 있다. 따라서, 서로 다른 운영체제를 한 물리 서버에서 동시에 실행할 수 있다.
  -각 가상 머신은 독립적인 커널을 실행하므로, 운영체제 간 충돌 없이 격리된 환경을 제공한다.
  
  
• 컨테이너 가상화:
  -컨테이너는 호스트 운영체제의 커널을 공유하기 때문에, 호스트 OS와 동일한 커널을 사용해야 한다. 예를 들어, 리눅스 기반 호스트에서 윈도우 컨테이너를 실행할 수 없다.
  -게스트 OS 레벨에서의 격리가 아닌, 애플리케이션과 라이브러리 수준에서의 격리를 제공한다.

 

자원 효율성

• 하이퍼바이저 가상화:
  -각 가상 머신은 별도의 운영체제와 커널을 실행하기 때문에 더 많은 메모리와 CPU 자원을 소비한다.
  -VM을 시작하는 데 시간이 걸리고, 리소스 사용량이 상대적으로 크다.
  
  
• 컨테이너 가상화:
  -컨테이너는 호스트 커널을 공유하므로, 운영체제에 관련된 오버헤드가 적어 더 적은 자원으로 많은 애플리케이션을 실행할 수 있다.
  -매우 빠르게 시작되며(수 초 내), 리소스 사용이 매우 효율적이다.

 

격리성

• 하이퍼바이저 가상화:
  -각 가상 머신은 물리적 하드웨어 수준에서 완전히 격리된 환경을 제공한다. 각 VM은 독립적인 커널과 운영체제를 가지므로, 격리 수준이 높고 보안적 이점이 있다.
  -게스트 OS가 직접 다른 VM의 자원에 접근할 수 없다.
  
  
• 컨테이너 가상화:
  -컨테이너는 OS 수준에서 격리되지만, 커널을 공유하므로 하이퍼바이저 가상화보다 격리 수준이 낮다.
  -네임스페이스와 cgroups로 격리되지만, 보안 문제나 커널 공유로 인한 취약점이 있을 수 있다.

 

이식성

• 하이퍼바이저 가상화:
  -가상 머신은 호스트 운영체제에 관계없이 이식성이 크다. 예를 들어, VM 이미지를 다른 서버로 옮길 수 있고, 다른 하이퍼바이저에서도 실행할 수 있다.
  
  
• 컨테이너 가상화:
  -컨테이너는 OS와 독립적인 애플리케이션 패키지이므로, 어디서든 동일한 환경에서 실행 가능하다. 컨테이너 이미지를 클라우드, 온프레미스, 로컬 서버 등 다양한 환경에서 동일하게 사용할 수 있다.

 

운영 및 관리

• 하이퍼바이저 가상화:
  -운영체제 자체를 설치하고 관리해야 하므로 복잡하고 관리가 다소 번거롭다. 운영체제 업데이트나 유지보수가 필요하다.
  -VM은 일반적으로 시스템 리소스를 많이 사용하기 때문에, 가상 머신의 수를 늘리면 자원 관리가 어려워질 수 있다.
  
  
• 컨테이너 가상화:
  -컨테이너는 더 간단하게 운영되고 관리할 수 있다. 컨테이너 이미지와 오케스트레이션 도구(Kubernetes 등)를 사용하여 자동으로 배포, 확장 및 관리를 할 수 있다.
  -애플리케이션 수준에서만 관리하면 되므로, 운영체제와 관련된 유지보수 부담이 적다.

 

보안

• 하이퍼바이저 가상화:
  -물리적 하드웨어 수준에서의 격리로 인해 보안 수준이 상대적으로 높다. VM 간 간섭이 없고, VM 자체가 다른 VM의 운영체제나 데이터를 침범할 가능성이 낮다.
  
  
• 컨테이너 가상화:
  -컨테이너는 호스트 커널을 공유하므로, 이 커널의 취약점이 있으면 모든 컨테이너에 영향을 미칠 수 있다. 네임스페이스와 cgroups를 사용한 격리가 있으나, 완벽한 보안을 제공하지는 않는다.

 

 

도커 아키텍쳐

클라이언트(Client)

• 사용자는 도커 클라이언트를 통해 명령어를 실행한다. 예를 들어, docker run 명령어를 사용하여 컨테이너를 실행할 수 있다.
• 클라이언트는 도커 서버와 상호작용하여 사용자의 요청을 처리한다. 이 과정에서 명령어를 도커 서버로 전달하는 역할을 한다.

 

도커 데몬(Docker Daemon)

• 도커 데몬은 도커 서버의 핵심 역할을 하며, 사용자로부터 받은 명령을 실제로 처리한다.
• 도커 데몬은 API를 통해 클라이언트와 통신하며, 컨테이너의 생성, 시작, 중단, 삭제 등의 작업을 수행한다.
• 도커 데몬은 호스트 운영체제에서 실행되며, 호스트의 자원을 이용하여 컨테이너를 관리한다.

 

API

• 도커 데몬과 클라이언트 간의 통신을 가능하게 하는 인터페이스이다.
  
• 사용자가 클라이언트에서 입력한 명령어는 API를 통해 도커 데몬으로 전달되며, 그 결과도 다시 API를 통해 클라이언트로 전달된다.

 

컨테이너 관리

• 도커 데몬은 실제로 호스트 운영체제의 자원을 이용하여 컨테이너를 관리한다.
• 각 컨테이너는 도커 데몬에 의해 생성되며, 해당 컨테이너는 애플리케이션과 그 애플리케이션을 실행하는데 필요한 모든 파일을 포함한다.
• 여러 개의 컨테이너가 호스트 OS 위에서 동시에 실행되며, 도커 데몬은 이 컨테이너들의 실행 상태를 관리한다. 

 

호스트 OS (Host OS)

• 도커는 호스트 운영체제 위에서 실행되며, 컨테이너는 이 호스트 운영체제의 자원을 사용하여 동작한다.
  
• 리눅스 기반 운영체제에서 도커는 호스트 커널을 공유하면서도 격리된 환경을 제공한다.

 

서버 (Server)

• 실제 물리적 하드웨어 자원을 제공하는 서버이다.
• 이 서버에서 도커 데몬이 실행되며, 도커 데몬은 서버의 CPU, 메모리, 스토리지 등의 자원을 사용하여 컨테이너를 관리하고 실행한다.
  
  

 

전체적인 흐름

• 사용자는 클라이언트에서 명령어를 실행하면, 해당 명령은 API를 통해 도커 데몬으로 전달된다.
  
• 도커 데몬은 호스트 운영체제에서 컨테이너를 생성하고 관리한다.
  
• 컨테이너가 실행되면 그 결과가 다시 API를 통해 클라이언트에 전달된다.