Virtual Machine vs Container (가상화 기술에 대해)

 

국민대학교에서 "클라우드 컴퓨팅" 교과목을 진행하시는
이경용 교수님의 강의 교안을 이용하여 수업 내용을 정리하였습니다

 

 

시스템 가상화 기술

 

Virtual Machine

 

 

• Hypervisor (Virtual Machine Monitor)를 통한 여러 운영체제간 독립적 환경 제공
  
  
• 각 VM은 독립적인 별도의 커널(운영체제), 시스템 프로세스 등을 관리하게됨
  
  => 추가 오버헤드가 클 수 있음
  
  
• 각각의 VM은 별도의 커널을 가질 수 있기에, 서로 다른 운영체제의 동시 동작 가능
  
  
• VMM을 통한 자원 공유로 인해 VM 간 간섭은 덜하지만 오버헤드가 있어 monolithic 구조에 적합
  
  

Container Technologies

 

Container

 

 

• 호스트 운영체제내에서 동작하며 커널 및 많은 시스템 자원을 호스트 기기와 공유
  
  
• 극단적으로 볼 때 호스트 운영체제에서 동작하는 하나의 프로세스로 간주할 수 있음
  
  
• chroot를 통한 독립된 파일 서비스 제공, cgroup을 통한 자원 간섭, namespace 기능을 활용한 독립된 프로세스 공간 제공
  
  => namespace 기능으로 다른 컨테이너는 안보이게 함
  (host os에서는 kernel 공유하므로 다 보이긴함)
  
  
• 별도 VMM없이 호스트의 커널을 공유하기에 컨테이너간 간섭이 클 수 있으나, 시스템 오버헤드가 작기에 microservice 구조에 적합
  
  

chroot는 Change Root 즉, 프로세스의 루트 디렉토리를 변경하는 리눅스 기능으로

특정 프로세스가 파일 시스템을 참조할 때, 지정된 새로운 디렉토리를 최상위 루트(/)로 인식하도록 만듬

=> Root 권한이 있는 경우 chroot를 탈출할 가능성이 있음

cgroup은 리눅스에서 프로세스가 사용하는 시스템 리소스를 제한하고 관리하기 위한 메커니즘으로

프로세스를 그룹으로 묶어 CPU, 메모리, 디스크 I/O, 네트워크 대역폭 같은 자원을 제어할 수 있음

=> 컨테이너 환경에서 리소스 제어
(/sys/fs/cgroup 디렉토리에 마운트되며 CPU, 메모리 등 각각의 컨트롤러를 설정)

namespace는 리눅스에서 프로세스 간 리소스를 격리하는 기술로 

프로세스가 서로 다른 네임스페이스 안에 있으면 마치 독립된 시스템처럼 동작하며, 다른 네임스페이스의 리소스는 접근할 수 없음

=> 컨테이너 환경에서 각 컨테이너를 독립된 시스템처럼 보이게 만들어줌

 

컨테이너 기술의 대중화 - Docker

 

컨테이너 기술

 

• 기술의 세부 구성 요소들은 과거에 이미 개발되어 있었음
  
  
• 일반 사용자가 손쉽게 사용하기에는 어려움이 있었음
  (LXC = Linux Container)
  
  

Docker

• 리눅스 컨테이너 기술을 일반 사용자가 쓰기 쉽도록 이미지 생성, 배포, 응용 프로그램 실행이 가능한 서비스 개발
  
  

Docker 구조

• Image : 실행에 필요한 파일 시스템, 데이터, 프로그램등을 포함
  
  
• Registry : 여러 컨테이너 이미지를 공유하는 공간으로, 사용자는 필요에 따라 공개 여부 결정 가능
  
  
• Container : 이미지로부터 생성된 별도의 실행 공간
  
  

추가 학습 내용

 

namespace의 사용 사례에 컨테이너 환경말고도 멀티테넌시라는게 있던데?

 

=> 멀티 테넌시란 하나의 소프트웨어 인프라나 플랫폼을 여러 사용자(테넌트)가 공유하는 환경임

특징으로는

 

• 공유된 리소스 : 하나의 물리적/가상 환경 (서버, 어플리케이션, DB) 등을 여러 테넌트가 공유
  
  
• 데이터 격리 : 각 테넌트의 데이터와 설정은 서로 격리되어 독립적으로 관리됨
  
  
• 효율성 : 리소스를 최대한 활용하여 비용 절감
  
  
• 사용자 경험 : 각  테넌트는 자신만의 어플리케이션처럼 느끼지만, 실제로는 동일한 인프라를 공유함
  
  

예를 들면 AWS, Azure, GCP의 클라우드 인스턴스에서 여러 고객이 같은 물리적 서버를 공유하되 데이터와 환경은 완전히 격리되는 것과
Slack등의 SaaS 어플리케이션처럼 동일한 어플리케이션 코드를 사용하지만 사용자별 계정 데이터는 분리되는 것을 생각하면됨

 

namespace를 사용하지 않고도 chroot와 cgroup으로 격리가 제공되는거 아닌가?

 

=> chroot는 파일 시스템만 격리함

즉, 한 프로세스가 chroot 환경에 있다 하더라도 네트워크 자원(IP 주소, 포트 등)은 다른 프로세스와 공유되고 동일한 PID 네임스페이스를 사용, IPC(프로세스 간 통신) 같은 다른 리소스는 격리되지 않음

또, Root 권한을 가진 경우 chroot를 탈출할 수 있어 chroot를 변경하는 새로운 시스템 콜을 호출할 수 있음

 

=> namespace는 프로세스가 사용하는 모든 시스템 리소스를 격리함

 

즉, 네트워크, PID, IPC, 파일 시스템, 사용자 ID 등 각각을 독립적으로 분리 가능하고 한 네임스페이스의 프로세스는 다른 네임스페이스를 볼 수 없음
(컨테이너 기술에서는 namespace를 사용해 격리된 환경을 구현함)

 

chroot만으로는 격리가 부족한 이유를 살펴보면

 

두 개의 chroot 환경을 설정했다고 했을 때, 두 환경이 동일한 네트워크 인터페이스를 사용하면, 포트 충돌이 발생하거나 네트워크 트래픽이 공유됨

 

또, 서로 다른 chroot 환경에서도, ps 명령어를 통해 서로의 프로세스를 확인할 수 있고 한쪽에서 Root 권한을 얻으면 격리된 환경을 뚫고 나갈 가능성이 있음

 

반대로 namespace 만으로는 격리가 부족한가에 대해 생각해보면

 

Namespace 자체는 파일 시스템 루트를 제한하지 않기에 특정 네임스페이스 안에서도 전체 파일 시스템에 접근할 수 있음

=> chroot 활용

 

Namespace는 격리만 제공할 뿐, 리소스 사용량을 제어하지 않음
=> CPU, 메모리, 디스크 사용량 등을 제한하려면 cgroup 활용

 

그래서 namespace와 chroot, cgroup을 모두 조합하여 컨테이너 기술을 구현함