VM과 Container 기술의 배경과 개념 (+ Docker, Kubernetes)

Kubernetes 발전 배경

물리 서버에 애플리케이션을 직접 배치

 

과거의 애플리케이션은 위와 같이 단순한 물리 서버에 배치하는 것에서 시작했습니다.

물리 서버가 준비 있다면 간단한 애플리케이션은 별도의 구성 없이 실행하고 서버를 구축할 수 있기 때문에 크게 문제가 되진 않습니다.

 

하지만 현대의 애플리케이션이 점점 복잡해지고 많은 요구사항이 생겨나면서 다음과 같은 제약을 겪게 되었습니다.

• 물리 자원을 효율적으로 사용하지 못함
• 애플리케이션이 특정 OS에 의존적이라면 새로운 물리 서버를 하나 더 배치하는 등의 제약
• 개발 환경, 배포 환경 등 애플리케이션 실행 환경 차이로 인한 예상치 못한 문제 발생

 

가상 머신 (Virtual Machine)

가상 머신은 가상화 기술을 사용해 물리 서버의 비효율성을 해결하고 효율적으로 애플리케이션 실행 환경을 구성할 수 있도록 합니다.

가상화라는 개념은 굉장히 오래 전부터 있었지만 애플리케이션이 복잡해짐에 따라서 가상화 기술이 주목받았고, 2000년 전후로 가상화 관련된 상용화되어 널리 사용되었습니다.

 

Type-1 Hypervisor

가상 머신을 설치할 때에는 물리 자원에 바로 OS를 설치하는 대신 Hypervisor 계층을 추가하여 물리 자원을 추상화합니다.

가상 머신은 Hypervisor가 제공하는 추상화된 물리 자원에 OS를 설치하고 그 위에 애플리케이션을 설치합니다.

 

이를 통해 다음과 같은 장점을 얻을 수 있습니다.

• 하나의 물리 자원에 여러개의 OS 설치가 가능
• 애플리케이션의 요구사항에 맞는 OS를 설치하고 하나의 물리 자원 위에서 다양한 요구사항을 가지는 애플리케이션 실행
• 가상 머신 간의 물리 자원을 완전히 격리하여 효율적인 리소스 사용 (보안 측면에서도 강점)
• 애플리케이션 실행을 위한 종속성 설치 및 환경 구성이 완료된 머신을 이미지로 만들어 손쉽게 Scale out, 개발 환경 구성하는 데 활용 

 

Type2 Hypervisor

Type1 이후에 Type2 Hypervisor가 등장하여 OS가 이미 설치된 개인 PC에도 가상머신을 실행하고 개발 환경을 구축할 수 있게 되었습니다.
하지만 Type2 Hypervisor는 추상화 계층을 여러번 거치게 되어 Type1 보다 성능이 좋지 않습니다.

 

 

하지만 가상머신은 Hypervisor 계층의 추가와 각각 별도의 OS를 가지기 때문에 다음에 설명할 컨테이너 기술보다 성능 측면에서는 상대적으로 낮은 퍼포먼스를 가집니다.

컨테이너 기술

컨테이너 기술 또한 애플리케이션을 실행하기 위한 환경을 효율적으로 구성하고 실행할 수 있도록 합니다.

 

하지만 컨테이너는 가상머신과 다르게 애플리케이션이 컨테이너라는 단위로 실행되고, 애플리케이션을 실행하기 위한 모든 구성요소를 이미지로 만들어 실행할 수 있습니다.

또한, 가상머신은 하나의 물리자원에 별도의 OS를 설치해 환경을 격리하지만 컨테이너는 호스트 머신의 OS를 공유하며 컨테이너 엔진을 통해 보다 가볍게 여러개의 애플리케이션을 실행할 수 있습니다.

 

따라서 위에 언급한 가상머신의 장점은 컨테이너도 가지며 애플리케이션이 가상화 계층 없이 호스트 OS를 사용할 수 있도록 하기 때문에 성능도 상대적으로 더 뛰어납니다.

 

하지만 단점으로 호스트 머신의 OS 커널에 의존성이 있어 일부 제약이 있을 수 있고, OS 수준에서 완전히 분리된 가상 머신과 다르게 하나의 커널을 공유하기 때문에 보안에 상대적으로 취약할 수 있습니다.

 

대표적인 컨테이너 기술로 Docker가 있습니다. Docker는 Linux 커널의 cgroup, chroot, namespace등을 통해 위와 같은 컨테이너간 격리 기술을 구현하였고, Linux 서버에서 호환성이 좋습니다.

 

 

 

Container Orchestration 

이처럼 컨테이너를 사용하면 높은 성능, 이식성 및 빠른 실행 가능성 등의 장점을 활용할 수 있습니다.

하지만 기본적으로 컨테이너는 하나의 머신에서의 동작을 지원하기 때문에, 자원을 나눠서 사용한다고 하더라도 물리적으로 한정된 자원에서 실행되기 때문에 애플리케이션 자체가 리소스를 많이 사용한다면 성능에 제약이 생깁니다.

 

이를 해결하기 위해서는 Scale up 혹은 Scale out을 해주어야 합니다. Scalue up에는 일정 수준이상에서 한계가 있기 때문에 적당한 물리 자원 수준을 넘어가면 일반적으로 Scale out을 선택합니다. 하지만 Scale Out을 위해서 컨테이너가 배치된 서버의 상태를 관리해야 하고, 컨테이너간 통신을 위한 네트워크 구성과 다른 서버에 배치된 컨테이너의 상태를 관리해주는 등 복잡도가 늘어납니다.

 

이를 해결하기 위해 컨테이너 실행 서버간의 클러스터를 맺고 관리할 수 있도록 도와주는 것이 Container Orchestration 도구 입니다.

 

대표적으로 많이 사용되는 도구로는 Kubernetes, Docker Swarm 등이 있습니다.

 

Docker Swarm vs Kubernetes

Docker Swarm과 Kubernetes는 모두 위에 언급한 것 처럼 다중 서버 환경에서의 컨테이너 실행, 관리, 통신 등을 쉽게 수행할 수 있도록 합니다.

 

Docker Swarm은 Docker 생태계와 완전히 통합되어 제공되며, 비교적 단순하고 쉽게 클러스터를 구성할 수 있다는 장점이 있습니다.

 

Kuberenetes는 보다 세밀하게 클러스터와 컨테이너를 관리할 수 있으며 시스템을 구성하거나 관리하기 위해 필요한 기술을 추상화된 형태로 제공합니다. 따라서 Docker Swarm보다 더욱 많은 기능을 제공하고 확장성이 높으며 그만큼 구조가 복잡하고 학습 곡선이 높습니다.

 

실제로 두 기술 모두 Container Ochestration 분야에서 높은 점유율을 가지고 있지만 Kubernetes가 압도적으로 높은 점유율을 가지고 있습니다.

 

이러한 이유로는 위에도 설명했듯 Docker Swarm은 Swarm 자체적으로 제공하는 기능으로 구성이 편한대신 확장성이 낮아 서로 다른 인프라 환경에서 구축하기에 제약이 있을 것이라고 생각됩니다. 반면에 Kubernetes는 대부분의 기술이 추상되어 제공되고 특히 Cloud 환경과의 통합이 굉장히 잘 되어있기 때문에 클라우드 환경에서도 이에 대한 관리형 서비스(EKS, NKS 등)를 제공하고 클라우드 기술의 발전과 함께 시너지를 내며 성장할 수 있었을 것 입니다.

 

다음 글에서는 Kubernetes의 핵심 개념과 동작 원리에 대해서 알아보도록 하겠습니다.