|
가상화 기술과도 유사한 개념인 컨테이너는 애플리케이션 실행에 필요한 파일과 라이브러리(lib)를 패키지화한 후, 필요할 때마다 이를 실행시켜 동일한 환경을 이용할 수 있도록 하는 역할을 한다. 실제 제품 수출입 시에 활용하는 철제 포장 용기인 ‘컨테이너’와 역할이 유사해 애플리케이션 실행에 필요한 파일과 라이브러리 등을 간편하게 패키지화할 수 있으며, 자유롭게 이동시키고 쉽게 이식도 가능하다. 이로 인해 컨테이너 기술은 클라우드 환경에 꼭 필요한 기술로 여겨지며 그 활용도가 높아지고 있다.
‘컨테이너’가 IT업계의 핫 키워드로 떠올랐다. 클라우드 등장 이후 가장 많은 주목을 받는 기술이라 평가될 정도다. 대체 무엇 때문에 컨테이너의 주가가 치솟는 것일까? 이를 확인하기 위해서는 먼저 서비스 구동 환경인 ‘서버’와 ‘가상화’ 기술에 대해 이해하고 넘어갈 필요가 있다.
특정 서비스를 제공하기 위해서는 이를 구동시킬 인프라가 있어야 하며, 보통 서버가 그 역할을 맡는다. 그러나 레거시 환경에서 서버를 구성하고 관리하는 것은 결코 쉬운 일이 아니다. 처음 장비를 구매하고 배송이 완료되면 운영체제(OS)를 설치하고, WAS 등을 구축한 다음에야 애플리케이션을 올려 서비스를 제공할 수 있다. 이 단계가 완료되기까지 상당한 시간이 필요하며, 전문적인 서버 지식을 갖춘 엔지니어의 손길을 거쳐야만 했다.
이 같은 방식은 시간이 지나며 한계점을 노출하기 시작했다. 기술의 발전으로 서버의 성능은 나날이 좋아졌으나 정작 해당 서버에서 구동되는 애플리케이션 서비스가 소모하는 하드웨어 자원은 일부에 불과해 사실상 자원의 낭비가 심해졌기 때문이다. 같은 애플리케이션이라 하더라도 이전에는 서버 자원의 80%를 사용했다면, 이제는 20%도 채 사용하지 못하는 경우가 빈번해졌다. 유휴자원이 발생한다는 것은 그만큼 과지출이 일어났다는 것을 의미하기에, IT 담당자들로서는 고민에 빠질 수밖에 없었다.
이후 가상화 기술이 등장하면서 자원 활용률 문제 해소가 가능해졌다. 하나의 시스템을 논리적으로 여러 개의 시스템처럼 활용할 수 있게 되면서 단일 서버에 여러 개의 애플리케이션을 올려 서비스하는 것이 가능해졌고, 이를 토대로 유휴자원을 줄일 수 있었기 때문이다. 이는 가히 혁명적인 변화였다.
다시 시간이 지나 현재로 이어지면서 가상화 기술도 최근 IT 트렌드를 좇아가기에 부족하다는 평가가 나오고 있다. 가상화가 하드웨어 기반의 자원 격리를 통해 자원 활용률을 높이는데 기여한 것은 맞지만, 가상화 환경에서 애플리케이션 서비스를 제공하려면 서버에 하이퍼바이저(Hypervisor)와 게스트(Guest) OS를 설치하고, WAS를 올려 애플리케이션을 설치하는 그 과정마저 바뀐 것은 아니었기 때문이다.
또한 이기종 가상머신(VM) 간 호환성 문제도 있었으며, 애플리케이션 서비스를 자동으로 확장하는 것도 불가능해 유연한 스케일 업/다운 환경에서 활용하기에는 아쉬운 점이 많았다.
이후 등장한 것이 컨테이너 기술이다. 컨테이너는 가상화와 마찬가지로 자원 격리를 통해 효율적인 자원 활용을 가능하게 하며, 가상화 이미지 대비 한층 경량화된 용량으로 인해 빠르게 서비스를 올리고 내리는 것도 가능해졌다. 이로 인해 민첩하고 유연함이 강조되는 클라우드 환경에서 컨테이너 기술이 빠르게 성장하게 된 것이다.
소프트웨어 패키징+자원 격리로 관리 복잡성 제거
컨테이너가 현재 각광 받는 기술임에는 틀림이 없지만, 최근 등장한 개념은 아니다. 컨테이너 기술은 리눅스 컨테이너 기술인 LXC를 비롯해 chroot, namespace, SELinux 등 컨테이너 기반 기술들은 오래전부터 사용됐다. 다만 현재 우리가 알고 있고, 활용하는 컨테이너는 저들에 비하면 한층 더 편리하고 사용하기 쉬워졌다는 차이만 있을 뿐이다.
컨테이너는 ‘소프트웨어 패키징(AUFS)’과 ‘자원 격리’라는 크게 두 가지 핵심 기술 요소로 구성된다. 이 중 AUFS는 이른바 ‘레이어드 파일시스템’으로, 원하는 소프트웨어를 계층 구조로 만들어 냄으로써 디스크를 효율적으로 사용할 수 있도록 한다.
가령 WAS 위에 애플리케이션을 배포한다 했을 시 WAS와 애플리케이션을 함께 넣어 패키징한다. 다만 애플리케이션은 자주 바뀔 수 있으며, 새로 패키징을 할 때마다 버전이 늘어나게 되는 문제점이 있다. 그러나 WAS는 변하지 않기 때문에, 한 개의 WAS에 변화된 애플리케이션 버전만 추가하는 방법으로 효율적인 활용이 가능하다.
또한 자원 격리 기술은 컨테이너 호스트를 장비에 올릴 때 하드웨어 자원을 격리해줌으로써 VM을 사용할 때와 같은 효과를 제공한다.
이처럼 컨테이너를 활용할 경우 하나의 이미지로 파일 패키징을 하기에, 원하는 시점에 원하는 장비로 이미지 파일을 편리하게 옮겨 애플리케이션 서비스를 구동할 수 있다. 이는 여러 대의 장비에서 서비스를 올리고 내리는 관리가 간편해진다는 것을 의미한다. 이미지 파일에 서비스 구동에 필요한 것들을 다 넣어뒀기 때문에 호스트 OS상에서 별도의 세팅을 할 필요가 없다.
비록 컨테이너 기술이 이전과는 달리 편의성을 제공한 것은 맞지만, 플랫폼을 통해 컨테이너 이미지를 옮기는 것은 결코 쉬운 과정은 아니었다. 스테이트리스(Stateless) 애플리케이션뿐만 아니라 스테이트풀(Stateful) 애플리케이션이 컨테이너 상태로 이동되더라도 서비스가 구동될 수 있어야 했지만, 이를 지원하는 것이 미약했기 때문이다. 그러나 도커(Docker) 컨테이너 기술이 등장하면서 외부 스토리지 사용 지원 등 컨테이너 각각의 상태를 저장하기 위한 다양한 방법들이 등장했고, 초기 컨테이너 기술이 등장했을 때보다 쉽고 간편하게 컨테이너 관리가 가능해졌다.
| |
 |
|
| ▲ 베어메탈, 가상화, 컨테이너 기술 비교 |
자원 효율성·OS 호환성 등 다양한 이점 보유
클라우드 환경이 확산되면서 컨테이너 기술에 대한 인기가 상승한 요인은 애플리케이션 이동과 배포가 수월해졌다는 점도 있지만, 이 외에도 자원 효율성, 자원 격리, 호환성, 오토스케일링(Auto-Scaling), 마이크로서비스, 관리 편의성 등이 뒷받침됐기 때문인 것으로 평가된다.
최근 베어메탈 환경은 컴퓨팅 기술의 발전으로 인해 많은 수의 CPU 코어가 제공된다. 단일 애플리케이션의 성능을 온전히 내려면 베어메탈 환경을 이용하면서 최대의 자원을 활용할 수 있도록 구성하겠지만, 실제로 이렇게 이용하는 경우는 극히 일부를 제외하면 드문 편이다. 이에 단일 장비에서 가상화 기술과 같은 자원 격리를 통해 여러 개의 WAS와 애플리케이션을 구동하는 방식이 활용된다.
그러나 그 중 하나의 애플리케이션이 잘못 구성돼 무한루프 현상을 보이며 인프라 자원을 모두 소진할 경우 다른 WAS와 애플리케이션은 제대로 동작을 하지 못하는 불상사가 일어날 수 있다. 말 그대로 장애 아닌 장애 상태를 맞이하게 되는 셈인데, 컨테이너 기술은 할당된 자원을 완벽하게 격리하기 때문에 특정 WAS와 애플리케이션에서 시스템 전체의 자원을 소비하는 문제를 막는다. 이를 통해 보다 효율적으로 인프라 자원을 활용할 수 있다.
컨테이너 기술의 또 다른 장점은 OS간 호환성이 높다는 점이다. 베어메탈을 비롯해 장비에 설치된 OS 버전이 다를 경우, 같은 벤더의 WAS를 사용한다 해도 쓸 수 있는 버전이 달라진다. 이에 필요할 때마다 WAS 구성을 해야 하는 불편함이 생긴다.
그렇다고 WAS를 사전에 설치해놓는 것은 어떨까? 확실한 사용 계획이 있는 것도 아닌데 미리 시스템을 구성한다면 효율적이지 못하며, 이로 인해 시스템 증설이 필요한 경우도 생기는 만큼 좋은 방안이라 할 수 없다.
이후 자원을 효율적으로 사용하자는 목표 하에 VM 기술들이 등장했다. 그러나 가장 큰 문제점은 각 VM 간 호환성이 떨어진다는 점이었다. 실제로 가상화 환경을 구현하기 위한 하이퍼바이저 기술은 ESXi, KVM, Xen 등 다양하게 존재하지만, 각 하이퍼바이저 간 호환성은 높지 않은 편이다.
가령 특정 벤더의 VM을 만들어 이용하다가 벤더와의 갈등이나 비싼 유지보수 비용, 기술지원 불만 등으로 인해 이탈하려 해도, 막상 시스템 자원을 옮길 비용이 새로 시스템을 구축하는 비용과 큰 차이가 없을 정도로 비싸기에 어쩔 수 없이 벤더에 종속(Lock-in)되는 경우도 많다.
이에 반해 컨테이너는 오픈 컨테이너 이니셔티브(OCI)라 하는 프로젝트가 지난 2015년부터 추진되면서 기술 표준화를 위해 움직이고 있다. 벤더마다 독점적으로 보유하고 있는 기술이 아니라 공개 산업 표준의 파일 포맷과 이를 구동시키는 런타임 표준에 대한 작업이 이뤄지고 있는 것이다. 이로 인해 cri-o로 불리는 경량의 OCI 호환 컨테이너 런타임이 개발되기도 했다.
| |
 |
|
| ▲ VM웨어 클라우드 PKS 아키텍처 |
오토스케일링으로 확장도 간편하게
컨테이너가 VM과 가장 차별되는 것으로 자동 자원 확장 기능이 있다. 현재 인터넷을 넘어서 모바일 시대로 접어들었으며, 모바일 시장에 앱을 출시하면 이슈에 따라 폭발적인 수요가 발생하기도 한다. 이는 예측이 전혀 불가능하다.
가령 설이나 추석 등 명절 기차표 예매 시에는 평소 대비 어느 정도 트래픽이 몰리는지 예상이 가능해 미리 자원을 증설해서 대비할 수 있지만, 태풍이나 홍수 등 자연재해가 갑작스럽게 발생했을 때 특정 정부·공공기관 사이트에 관련 정보를 조회하고자 대량의 트래픽이 몰리는 것을 예측하기는 어렵다.
예측 가능한 상황에 미리 대비해서 준비하는 것과 예기치 못한 상황에도 유연하게 대처가 가능하도록 하는 것은 전혀 다른 이야기다. 컨테이너는 컴퓨터 자원이 갑작스럽게 늘어나더라도 자동적으로 확장될 수 있는 오토스케일링 옵션 설정이 가능해 갑작스러운 환경 변화에도 효율적으로 대응이 가능하다.
컨테이너를 근간으로 하는 플랫폼 혹은 PaaS 솔루션 등은 대부분 오토스케일링 기능을 제공한다. 자동 자원 확장을 위해 개발자나 운영자가 별도로 개발하고 추가할 필요가 없다. 단지 원하는 값만 세팅해주면 되며, 임계치를 늘리거나 줄이는 것으로써 간단히 설정 가능하다.
또한 컨테이너는 VM처럼 자원 관리가 가능하다. 각 자원이 격리돼 있어 컨테이너 간 영향을 주지 않기 때문에 베어메탈 환경에서 발생할 수 있는 비효율적인 자원 활용이나 특정 WAS 및 애플리케이션 오류로 인해 장애 아닌 장애가 발생하는 문제도 일어나지 않는다. |
y1333@datanet.co.kr
KT, ‘28GHz 기업전용 5G 네트워크’ 개발 성공
