컨테이너는 하이퍼바이저 위에 가상머신(VM)을 올리는 개념과 유사하다. VM에서는 하이퍼바이저가 자원을 격리시킨 후 그 위에 운영체제(OS)를 설치하고 운영하는 방식이지만, 컨테이너는 OS 자원을 가상화시키고 격리시킨다는 점에서 차이가 있다.

OS 상에서 프로그램을 실행시키면 프로세스 단위로 올라가 메모리에서 CPU를 사용하며 운영된다. 컨테이너는 그 프로세서에 CPU, 네트워크, 메모리를 할당해주고, 다른 컨테이너들이 접근하지 못하도록 격리한다. 즉 하나의 OS에서 격리된 환경으로 독립된 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 호환 컨테이너 런타임이 개발되기도 했다.

[컨테이너 기술 활용 시 장점 - 개발자 측면]