[위클리 페이퍼] 컨테이너와 Docker, 컨테이너 오케스트레이션

이번주 위클리 페이퍼의 주제는

컨테이너 기술과 Docker를 명확히 구분하여 설명해보자. 컨테이너 기술이 Docker 이전에도 존재했던 개념임을 언급하고, Docker가 컨테이너 기술을 구현한 하나의 도구라는 관점에서 설명하기. 또한, Docker 외에 컨테이너 기술을 구현한 다른 도구의 예시를 들어보자.

컨테이너 오케스트레이션의 개념과 필요성을 설명하고, Docker 단독 사용 환경과 비교하여 컨테이너 오케스트레이션이 해결하는 주요 문제점 3가지(자동 확장, 자가 복구, 선언적 인프라)를 설명해보자.

 

컨테이너란?

Docker는 개발자가 컨테이너를 빌드, 배포, 실행, 업데이트 및 관리할 수 있는 오픈 소스 플랫폼입니다.
컨테이너는 애플리케이션 소스 코드와 모든 환경에서 해당 코드를 실행하는 데 필요한 운영 체제(OS) 라이브러리 및 종속성을 결합하는 표준화된 실행 가능한 구성 요소입니다.
출처: IBM

이미지 출처: https://www.atlassian.com/microservices/cloud-computing/containers-vs-vms

 

기존 가상머신은 각 VM이 별도의 OS를 가지는 형태이다. 이로 인해 리소스 오버헤드가 크고 부팅 속도도 느리다.

하지만 컨테이너는 공통 Host OS 위에서 애플리케이션을 격리하여 실행할 수 있다. 가상 머신보다 격리 수준은 약하지만 리소스 오버헤드나 부팅속도, 이식성 등의 부분에서 기존 가상머신보다 효율적이다. 

이런 컨테이너 기술은 1979년 파일 시스템 수준에서 프로세스의 루트 디렉터리를 변경해 격리하는 리눅스의 chroot를 발표한 것부터 시작된다. 이를 통해 프로세스가 접근할 수 있는 디렉터리를 제한하는 등의 격리조치를 할 수 있다. 

2000년대 초 chroot보다 더 고도화된 격리 기능을 제공하는 FreeBSD Jail, Solaris Zone 같은 기술이 등장했고

2008년 리눅스의 namespace와 cgroups를 조합한 리눅스 수준의 컨테이너 기능인 LXC가 리눅스 커널에 구현됐다.

 

도커와 컨테이너

docker는 2013년 Pycon에서 Solomon Hykes가 발표한 세션에서 알려졌다. docker는 Paas 기업인 dotCloud의 내부 프로젝트로 진행되고 있었다.

도커는 이런 컨테이너 기술을 구현한 대표적인 도구이다.

컨테이너의 핵심은 호스트 OS 위에서 별도의 OS를 가진 것 처럼 동작하는 독립적인 환경을 만드는 것이다.

도커는 컨테이너 기술을 개발자와 운영자가 쉽고 안전하게 사용할 수 있도록 구현한 플랫폼이다.

도커는 복잡한 리눅스 명령어와 설정 없이 docker build, docker run 와 같은 CLI 명령어로 컨테이너를 쉽게 만들고 관리할 수 있다.

도커는 현재 LXC 기반 컨테이너가 아니라 자체 라이브러리를 사용하고 있다고 한다.

 

도커 외의 컨테이너 구현 도구로는

• RKT (보안 중점 컨테이너 시스템, 현재는 프로젝트가 종료됨)
• CRI-O (쿠버네티스용 컨테이너 런타임)
• Podman (도커의 보안 취약점 발생 가능성이나 데몬 문제 개선을 위해 선택하는 새로운 툴)

이 있다.

 

 

컨테이너 오케스트레이션이란?

컨테이너 오케스트레이션은 컨테이너화된 애플리케이션의 프로비저닝, 배포, 확장 및 수명 주기를 자동으로 프로비저닝, 배포, 확장 및 관리합니다. 개발자는 컨테이너 오케스트레이션을 사용하여 민첩한 또는 DevOps 워크플로를 간소화하여 최신 하이브리드 멀티클라우드 인프라를 지원하는 데 필요한 유연성과 속도를 제공합니다.
출처: IBM

대표적인 오케스트레이션 도구로는 쿠버네티스가 있다.

Docker만으로도 컨테이너 실행은 가능하지만 컨테이너가 많아지면 수동 관리가 어려워지고, 장애 복구가 불가하다.

또한 트래픽이 갑자기 폭증하게 되면 컨테이너의 수 조절이 필요한데 이를 수동으로 조절하면 로드 증가 대응이 어려워진다.

 

컨테이너 오케스트레이션이 필요한 이유

AWS는 컨테이너 오케스트레이션이 필요한 이유를 다음과 같이 설명한다.

Docker 는 소프트웨어 및 관련 라이브러리, 시스템 도구, 코드 및 런타임을 컨테이너에 패키징하기 위한 오픈 소스 도구입니다. 단일 서버 인스턴스에서 몇 개의 컨테이너를 실행 및 관리하기 위한 간단한 솔루션이지만 확장이 어렵습니다.

관리형 컨테이너 오케스트레이션 플랫폼이 존재하기 전에는 조직에서 복잡한 스크립팅을 사용하여 여러 시스템에서 컨테이너 배포, 스케줄링 및 삭제를 관리했습니다. 이러한 스크립트를 유지 관리하려면 버전 제어와 같은 문제가 발생했고 설정을 확장하기도 어려웠습니다. 컨테이너 오케스트레이션은 이러한 복잡성을 자동화하고 해결하여 수동 관리와 관련된 문제를 제거합니다.
 
컨테이너 오케스트레이션 사용 사례 (컨테이너 오케스트레이션 도구는 다음과 같은 경우에 필요합니다.)
- 여러 인스턴스에서 컨테이너를 관리하고 확장합니다.
- 다양한 컨테이너식 애플리케이션을 실행합니다.
- 여러 버전의 애플리케이션(예: CI/CD 전반의 테스트 및 프로덕션)을 한 번에 실행합니다.
- 컨테이너의 여러 복제 인스턴스(복제본)를 실행하여 서버 장애 시 앱 서비스 연속성을 보장합니다.
- 여러 지리적 지역에서 앱의 여러 인스턴스를 실행합니다.예산 편성을 위해 여러 서버 인스턴스의 사용을 극대화합니다.
- 수천 개의 다양한 마이크로서비스로 구성된 대규모 컨테이너식 애플리케이션을 실행합니다.

 

자동 확장, 자가 복구, 선언적 인프라?

도커를 단독으로 사용할 때는 자동 확장 기능이 없다. 사용자가 직접 docker run을 반복해야한다.

컨테이너 오케스트레이션은 요청량이 증가하면 자동으로 컨테이너 수를 증가시켜준다.

 

도커 단독 사용시 컨테이너가 죽으면 그대로 종료되며 자가복구가 불가능하다. 하지만 컨테이너 오케스트레이션은 컨테이너의 상태를 지속적으로 모니터링 하다가 컨테이너가 죽으면 복제된 컨테이너를 실행하는 등 중단없는 서비스를 보장해준다.

 

도커를 단독 사용하면 nginx 컨테이너를 3개 실행하려면 docker run nginx 같은 명령어를 반복적으로 입력해야 하지만 대부분의 컨테이너 오케스트레이션 툴은 선언적 인프라를 지원한다. 개발자가 원하는 상태를 yaml이나 json 형식으로 작성하면 이를 실행하여 해당 상태를 유지한다.