컨테이너화란 무엇인가?
컨테이너화는 커널 하나에 격리된 여러 개의 사용자 공간 인스턴스가 포함될 수 있도록 애플리케이션 수준에서 이루어지는 가상화의 일종입니다. 이런 인스턴스를 컨테이너라고 합니다. 사실 컨테이너 기술은 새로운 개념이 아닌, 약 10여 년 전에 리눅스에 내장된 기술로 소개되었습니다. 현재 컨테이너는 차세대 트렌드 기술로 주목받으며 다양한 클라우드 서비스 환경에서 연구되고 있습니다.
그럼 왜 컨테이너를 써야 하는가?
지금도 대부분의 서버 장비들은 컴퓨팅 환경을 소프트웨어로 구현한 가상머신(VM : Virtual Machine)을 사용하고 있습니다. 이 서버들은 다수의 운영 체제를 동시에 실행하기 위해 하이퍼바이저가 필요하고, 그 상위계층에 Guest OS가 각각 설치된 가상머신들을 구동시킵니다. 반면에 컨테이너로 구성된 서버는 아래의 그림과 같이, 하이퍼바이저를 사용하지 않고 CPU, RAM, Disk, Network 과 같은 운영체제의 자원을 필요한 만큼 격리하여 컨테이너에 할당합니다.
컨테이너는 어떤 장점이 있는가?
첫째, 컨테이너는 효율성이 높다.
실제 기업들은 애플리케이션 서비스를 안정적으로 운영하기 위해, 1개의 가상머신에 1개의 서비스를 구동하는 것이 권장됩니다. 하지만, 해당 애플리케이션이 가상머신의 모든 자원을 사용하는 것이 아니기 때문에 유휴 자원이 생겨서 성능적 오버헤드가 발생할 수 있습니다. 반면 컨테이너의 경우, 운영체제의 자원을 공유하기 때문에 애플리케이션을 실행하는데 필요한 만큼의 자원만 할당받을 수 있습니다. 즉, 서버 전체 자원을 효율적으로 사용할 수 있다는 장점이 있습니다.
둘째, 컨테이너는 신속성이 높다.
기업들은 서비스 추가 및 확장을 위해 가상머신을 추가로 배포해야 하는 상황이 생깁니다. 가상머신의 용량은 최소 몇 GB 이기 때문에 추가 배포하는데 수 분에서 수십 분의 시간이 소요됩니다. 하지만, 컨테이너의 경우 구조적으로 Guest OS가 없기 때문에 용량이 MB 단위로 작습니다. 놀랍게도 컨테이너는 배포에 드는 시간이 수 초에 불과하다는 장점이있습니다.
셋째, 라이센스 비용이 절감된다.
가상화 서버의 경우 가상머신의 개수만큼 Guest OS의 Enterprise용 라이센스 비용이 발생합니다. 반면에 컨테이너 서버의 경우 Host OS 1대의 라이센스 비용만 발생합니다. 만약 추가로 많은 서버를 증설해야 한다면, 가상화 서버와 컨테이너 서버 사이의 라이센스로 인해 발생하는 비용의 차이는 기하급수적으로 증가할 것입니다.
장점만 있는것은 아닙니다.
가상머신의 경우 정확히 할당된 자원 내에서 가상머신이 운영되기 때문에, 컨테이너에 비해 안정적으로 운영할 수 있습니다. 반면에 컨테이너들은 OS 커널을 공유하기 때문에, 하나의 컨테이너가 무리하게 자원을 사용하게 될 수 있습니다. 자원 할당량을 사전에 지정시켜줄 수 있지만, 만약 이런 상황이 발생하면 컨테이너에 장애가 발생합니다. 이런 컨테이너의 문제는 컨테이너 오케스트레이션으로 해결할 수 있습니다.
컨테이너 오케스트레이션
도커 컨테이너의 갯수가 꾸준히 늘어나면 필요한 자원도 지속적으로 늘어나기 마련이다 때문에 서버 또한 여러대로 늘어날 수 있는데 한대 두대의 수준이 아니라 몇 십 몇 백대의 서버로 늘어났다고 가정 해보자 이 많은 서버들을 일일이 접근하여 명령어 날려주고 컨테이너 올리고 “어? 이건 또 왜 내려갔어?” 하다가 시간은 시간대로 흘러버리고 정신을 차려보면 라꾸라꾸 침대가 본인 의자옆에 있는것을 발견 할 수 있을것이다. 결론적으로 이 많은 서버들과 컨테이너를 소수의 인원으로 관리하기에는 상당히 어렵고 이 문제를 효율적으로 관리하기 위해 컨테이너 오케스트레이션 툴들이 나오게 되었다.
컨테이너 오케스트레이션 툴 소개
컨테이너 오케스트레이션 툴의 기능에는 단순 컨테이너의 배포 뿐만이 아닌 하나의 서비스를 관리하고 유지보수 하기 위한 많은 기능들을 포함하고 있고 툴마다 기능에 대한 편차는 있으나 주요 기능은 아래와 같다.
오케스트레이션 툴의 기능
- 노드 클러스터링
- 컨테이너 로드 밸런싱
- 컨테이너의 배포와 복제 자동화
- 컨테이너 장애 복구기능
- 컨테이너 자동 확장 및 축소
- 컨테이너 스케쥴링
- 로깅 및 모니터링
Docker Swarm
도커 스웜은 도커 컨테이너 플랫폼에 통합 된 컨테이너 오케스트레이션 툴이다. 최초에 도커 스웜은 도커와 별개로 개발 되었으나 도커 1.12 버전부터 도커 스웜 모드라는 이름으로 합쳐졌다.
장점
- 도커 명령어와 도커 컴포즈를 포함한 도커의 모든 기능이 내장되어 있다.
- 도커 이외의 별도의 툴 설치가 필요하지 않다.
- 타 오케스트레이션 툴에 비해 복잡하지 않고 다루기 쉽다.
단점
- 타 오케스트레이션 툴에 비해 기능이 단순하여 세부적인 설정이 어려움
- 초대형 노드 클러스터링에는 무리가 있다.
Kubernetes
쿠버네티스는 구글에서 개발한 2014년 오픈소스화 된 프로젝트이다. 무려 15년에 걸친 구글의 대규모 운영 워크로드 운영 경험과 노하우가 축적된 프로젝트로 컨테이너 중심의 관리환경을 제공한다.
장점
- 현재 가장 인지도가 높고 기능이 많은 오케스트레이션 툴
- 내장된 기능이 많아 타사 애드온이 불필요함
단점
- 쿠버네티스의 구성과 개념에 대한 이해가 필요하다.
- 학습해야할 부분이 많고 소규모 프로젝트에서 구축하기 쉽지 않다.
Apache Mesos
아파치 메소스는 Twitter, Apple, Uber, Netflix 등 대형 서비스를 운영하고 있는 기업에서 다수 채택 되었으며 마이크로서비스와 빅데이터, 실시간 분석, 엘라스틱 스케일링 기능 등을 제공하고 있다.
장점
- 대형 서비스를 운영중인 회사에서 많이 채택 되었고 안정성이 검증되었다.
- 수만대의 물리적 시스템으로 확장 가능하게 설계 되어있다.
- Zookeeper, Hadoop, Spark와 같은 응용프로그램을 연동하여 노드 클러스터링과 자원 최적화 가능
단점
- 너무 다양한 응용프로그램의 연동으로 인하여 복잡해질 수 있다.
- 설치 및 관리가 어렵고 컨테이너를 활용하기 위해 Marathon 프레임워크를 추가로 설치해야 한다.
컨테이너의 활용
1. 개발 환경 이전 솔루션
주로 개발자들이 애플리케이션을 개발할 때는 개인 환경에서 개발한 뒤에 통합 환경에서 여러 개발자의 코드를 통합합니다. 그다음 테스트 환경에서 애플리케이션을 테스트 한 뒤에, 실제 운영 환경으로 애플리케이션을 이전하게 됩니다. 이렇게 수차례 환경을 이전하다 보면 소프트웨어의 버전이나 서버 설정의 차이로 인해 다양한 장애가 매우 빈번하게 발생하고 이를 해결하기 위해 많은 시간이 소요됩니다. 그러나, 컨테이너를 사용하면 환경 이전이 쉽기 때문에 드는 시간을 대폭 줄일 수 있습니다. 컨테이너에 애플리케이션과 애플리케이션을 구동하는 환경을 그대로 담고 그 환경 자체를 다른 서버로 이전하면, 장애 걱정 없이 신속하고 안정적으로 환경을 이전할 수 있습니다. 컨테이너는 이미지 파일로 배포 및 형상관리가 가능합니다.
2. 마이크로 서비스 솔루션
기업에서 운영하는 애플리케이션은 하나의 큰 덩어리처럼 구성되어 있기 때문에 용량이 매우 큽니다. 이런 애플리케이션은 배포할 때 오랜 시간이 소요되고, 때로는 작은 부분의 수정사항이 애플리케이션 전체에 장애를 유발할 수 있습니다. 이런 거대한 애플리케이션을 기능별로 나누어 변경과 조합이 가능하게 한 것을 마이크로 서비스(Micro Service)라고 합니다. 마이크로 서비스를 구성할 때 컨테이너를 사용하면 하나의 애플리케이션을 기능 혹은 서비스 단위로 신속하게 배포할 수 있습니다. 또한, 컨테이너는 기본적으로 독립적인 구조이기 때문에 하나의 변경 사항이 분리된 다른 기능들에게 영향을 미치지 않습니다.
참고 :
https://team-platform.tistory.com/48
https://developer.ibm.com/kr/cloud/2017/07/29/kubernetes-cloud-private/