굿어스 블로그

[굿어스] '컨테이너화'(Containerization)는 또 뭐야? 본문

Good Tech

[굿어스] '컨테이너화'(Containerization)는 또 뭐야?

굿어스_Goodus 2020. 5. 13. 18:10

 

 

가상화사업을 처음 시작하던 9년 전만 해도 가상화의 개념과 필요성을 충분히 이해하는 사람이 많지는 않았지만, 현재는 서버 뿐만 아니라 스토리지와 네트워크까지 가상화되면서 가상화를 당연히 여기는 분위기입니다. 그리고 이제는 컨테이너화(Containerization)’라는 새로운 기술이 클라우드 환경에 도입되고 있습니다. ‘컨테이너화라는 익숙하지 않은 IT 용어는 짧은 시간에 이해하기가 쉽지는 않습니다. 그래서 에스넷 그룹의 식구라면 IT 전공자가 아니더라도 쉽게 이해할 수 있도록 설명해 드리고자 합니다.

 

▷ 변화의 시작은 애플리케이션에서부터

모든 산업분야에서의 신제품 출시는 사용자의 needs와 수요가 있기 때문에 가능하듯이, IT 산업에서도 사용자의 필요를 충족시키기 위한 변화를 수용하면서 새로운 기술과 제품이 나타나고 있으며, 뒤쳐지는 제품과 기술은 사라지고 있습니다. IT산업에서는 사용자에게 제공되는 애플리케이션에 따라 변화가 시작됩니다. 메인프레임에서만 실행되던 기업용 애플리케이션이 ISV(Independent S/W Vender)들에 의해 Unix 환경에서도 실행되고 나니, 고객들은 Unix를 선택하기 시작하였습니다. CPU 중심의 컴퓨팅 처리 영역이 GPU로도 확산되고 있는데, GPU 기술이 아무리 발전되었다고 하더라도 GPU에서 실행되는 애플리케이션이 계속해서 확산되지 않았다면 GPU 시장의 성장세는 한계가 있었을 것입니다. IT 환경의 변화는 사용자의 needs를 충족시키는 애플리케이션의 변화로 시작되며, 인프라 환경도 Client-Server 환경에서 웹 환경으로, 그리고 가상화/클라우드 환경으로 발전해 오면서 애플리케이션 변화를 거들게 됩니다.

 

 

IT 기술이 가상화/클라우드로 발전해 오면서 인프라 측면에서는 최적화효율화 되었지만 애플리케이션이 실행되는 환경은 동일하게 하나의 서버(또는 VM)와 운영체계 및 관련 도구(바이너리, 라이브러리)를 필요로 해왔습니다. 그래서 애플리케이션이 실행되는 이미지(VM, 운영체계, 관련 도구를 포함하여 애플리케이션이 실행될 수 있게 만든 환경을 이미지라고 합니다)가 달라지게 되면 동일한 애플리케이션이라도 애플리케이션이 실행되지 않을 수 있습니다. 애플리케이션의 수정에 따른 이미지도 애플리케이션마다 존재하여야 하기에 4차 산업혁명 시대에 사용자가 요구하는 애플리케이션의 민첩성(Agility)를 갖추기에는 한계점이 있습니다. 그래서 애플리케이션을 개발 환경에 구애 받지 않고 실행할 수 있는 방안이 없는지 고민하기 시작하였고, 그 필요에 의해서 컨테이너화된 애플리케이션 실행 환경이 탄생하였습니다. ‘컨테이너란 호스트 OS상에 논리적인 구획(컨테이너)을 만들고, 애플리케이션 실행에 필요한 라이브러리나 애플리케이션 등을 하나로 모아, 마치 별도의 서버인 것처럼 사용할 수 있게 만든 것입니다.

VM 환경과 Container 환경이 어떻게 다른지 비교해 보면 다음과 같습니다.

 

 

[VM 환경]

[Container 환경]

 

[성능]

VM마다 전용 OS가 있어서 VM에 구축된 애플리케이션을 실행할 때 메모리 사용량이 필요 이상으로 많아져 VM이 호스트에 필요한 리소스를 모두 사용할 수 있습니다.

컨테이너화된 애플리케이션은 VM보다 리소스를 더 적게 사용하고 호스트 메모리에 가해지는 부담을 줄일 수 있도록 운영 체제 환경(커널)을 공유합니다.

[무게]

VM은 디스크 공간을 많이 차지할 수 있습니다. VM이 호스트하는 애플리케이션과 함께 전체 운영 체제와 관련 도구도 포함하기 때문입니다.

컨테이너는 상대적으로 가볍습니다. 컨테이너화된 애플리케이션을 실행하는데 필요한 라이브러리와 도구만 포함하기 때문에 VM보다 더 작고 더 빨리 시작됩니다.

[관리]

운영 체제를 업데이트하거나 패치(Patch)할 경우 기존 컴퓨터를 하나씩 업데이트해야 하고 각 게스트 OS를 개별적으로 패치해야 합니다.

컨테이너의 경우 컨테이너 호스트(컨테이너를 호스트하는 컴퓨터)의 운영 체제만 업데이트하면 됩니다. 따라서 유지관리가 매우 간소화됩니다.

 

 

컨테이너는 서비스 기반 아키텍처(Service Oriented Architecture. SOA라 함)와 가장 잘 어울립니다.

데이터의 I/O(Input/Output)에서 처리, 렌더링에 이르기까지 애플리케이션의 모든 요소가 서로 얽혀 있는 기존의 모놀리식 아키텍처(Monolithic Architecture)와는 다르게, 서비스 기반 아키텍처는 이런 요소들을 개별 구성요소로 분리(Micro Service)합니다. 그래서, 민첩성을 가진 애플리케이션 개발 환경으로 컨테이너화를 선호하고 있으며, 컨테이너를 기본으로 한 새로운 프로젝트가 늘어날 것입니다. NetFlix, SK Planet, 배달의 민족, 삼성전자 같은 기업들이 경쟁사 대비 더 빠르게 고객 서비스 상품을 개발하기 위하여 개발 환경에 최대한 구애 받지 않으면서 각 독립된 서비스 단위로 개발, 배포할 수 있도록 컨테이너화된 환경에서 마이크로서비스 방식으로 애플리케이션 개발을 하였습니다. 사용자 needs를 충족시키기 위해 애플리케이션 개발 환경이 컨테이너화 되는 것은 이미 시작된 패러다임이라 볼 수 있습니다.

 

▷ 처음에는 오픈소스에서 시작

UnixLinux도 처음에는 open source에서 시작 되었듯이, 컨테이너의 시작도 오픈소스에서 시작되었습니다. 새로운 기술은 기존 시장을 파괴하는 경향이 있습니다. 기존 제조사들 역시 아무리 효율적인 신기술이더라도 자기 잠식’(cannibalization)할 수 있는 솔루션의 신제품을 선뜻 먼저 출시하지는 않겠죠? 컨테이너화를 본격적으로 알리기 시작한 것은 2013년에 출시된 도커(Docker)인데, 도커는 컨테이너 환경에서 애플리케이션을 관리하고 실행하기 위한 오픈소스 플랫폼으로 Linux 위에서 동작하며 Amazon EC2, Google GCP, IBM SoftLayer 같은 클라우드 환경에서도 동작합니다. 도커는 컨테이너의 새로운 국면을 열었지만, 동시에 이 모든 컨테이너는 어떻게 조정하고 예정할 것인가? 애플리케이션의 모든 컨테이너를 서로 어떻게 통신하게 할 것인가? 컨테이너 가상의 공간인 인스턴스를 어떻게 확장 할 것인가?’와 같은 문제를 해결해 주지는 못합니다. 그래서, 이러한 이슈들을 해결하기 위한 컨테이너 오케스트레이션(Orchestration) 솔루션이 등장하게 되는데, 2014년에 컨테이너화된 애플리케이션을 자동으로 배포, 스케일링 및 관리해 주는 오픈소스 시스템으로 쿠버네티스(Kubernetes. ‘K8s’로도 씀)가 바로 그것입니다. 쿠버네티스는 구글이 개발한 것을 공개하여 현재는 리눅스 재단에서 관리되고 있습니다.

현재 Kubernetes는 컨테이너 오케스트레이션 솔루션 시장의 선두 주자이며 컨테이너를 조정하고 분산 애플리케이션을 배포하기 위한 표준화된 수단이 되고 있습니다. VMware를 포함한 주요 제조사들은 Kubernetes를 지원하는 솔루션을 출시하고 있으며, 많은 클라우드 제공 업체(CSP) Kubernetes를 서비스로 제공하고 있습니다.

 

[ 그림 1] VMware VIO 환경에서 지원되는 Kubernetes

 

 

▷ VM vs. Container. 어느 기술이 살아남을 것인가?

전반적인 특징으로 볼 때 VM환경보다는 컨테이너화된 환경이 개발자와 애플리케이션 입장에서 더 유리합니다. 하지만, 컨테이너화된 환경을 구축하려면 몇 가지 고려사항이 있습니다. 먼저 보안적인 이슈입니다. 컨테이너의 커널 공유에 따른 기술적인 취약점 외에도, DevOps 프로세스상에 컨테이너 이미지가 보안 적용 되기도 전에 이미 공유되고 재사용되어서 보안 적용을 할 수 없는 경우도 종종 발생할 수 있습니다. 그리고 컨테이너는 MSA(Micro Service Architecture)와 최적화 되었을 때에만 구축 효과를 볼 수 있습니다. MSA는 애플리케이션을 상호 독립적인 최소 규모 구성요소로 분할하는 것입니다. 그런데, 컨테이너에 전통적인 모놀리식 방식처럼 기존에 있던 스타일의 애플리케이션을 담게 되면 여러 조건들에 의해서 더 비효율적으로 동작하게 됩니다. 엔터프라이즈에서 사용되는 많은 워크로드는 풀 스택 OS에서 돌아가는 것을 가정하고 만들어졌기 때문에, 이것은 하나의 VM을 할당해 주는 것이 더 효율적입니다. 데이터베이스(DB)와 같은 워크로드가 대표적인 케이스입니다. , 개발자들이 노력과 시간을 들여서 컨테이너화된 환경에서 애플리케이션을 새롭게 구축해야만 효과를 본다는 것입니다.

VM 상에서 컨테이너를 구동하는 것은 성능 측면에서 일부 손해를 볼 수 있지만 확장성이나 관리 용이성 측면에선 유리하기에, 관리나 운영 면에서의 편의성을 고려하여 컨테이너 서비스를 가상화된 HW 레이어에서 제공하는 것도 좋은 방법입니다. 따라서, 컨테이너가 VM을 대체하는 것이 아니라, 애플리케이션은 그 특성에 따라서 VM 환경에서 실행되거나 컨테이너화 하여 실행될 것입니다.

[그림 2] Kubernetes / VIO / VMware 솔루션 구성(예)

 

 

맺으면서

컨테이너화된 아키텍쳐와 Kubernetes는 캐즘(Chasm)을 이미 뛰어 넘었습니다. 앞으로 더 많은 시스템이 Kubernetes를 기반으로 구축되거나 활용될 것입니다. Kubernetes 생태계가 빠르게 확장되어 가고 있고, 다양한 새로운 기능을 가능하게 하고 있습니다. Kubernetes를 포함한 클라우드 네이티브로의 전환 기술은 계속해서 그 영역이 넓어질 것입니다. VMware 파트너로써, 너무 빠르지도 너무 늦지도 않은 적당한 시기에 선택과 집중을 해야 할 솔루션인 VIO Kubernetes를 구축지원 할 수 있는 역량을 갖춘다면, 고객으로 하여금 최신의 애플리케이션으로 디지털 혁신을 이룰 수 있게 큰 도움을 주는 신뢰받을 파트너로 한 단계 더 성장할 수 있습니다.

 

 

이 글은 굿어스 김세환, 가상화 솔루션 스페셜리스트가 작성한 칼럼입니다.

* 가상화 및 컨테이너화에 대한 문의가 필요하신 분은 sehwan.kim@goodus.com 으로 문의주세요.