1981년에 출간된 ‘나무에 젤리 못 박기(Nailing Jelly to a Tree)’라는 책은 소프트웨어를 “모호하고 제대로 파악하기 어려운 것”이라고 설명한다. 1981년에도 그랬고 40년이 지난 지금도 마찬가지다. 구매한 애플리케이션이든 직접 구축한 애플리케이션이든 소프트웨어는 여전히 배포하기 어렵고, 관리하기 어렵고, 실행하기 어렵다.

도커 컨테이너와 컨테이너 및 컨테이너 런타임에 대한 OCI 표준은 소프트웨어를 파악할 수 있는 방법을 제공한다. 컨테이너를 사용하면 애플리케이션을 네트워크에 노출하는 방법, 스토리지와 메모리 및 I/O 사용을 관리하는 방법, 액세스 권한을 제어하는 방법 등 애플리케이션의 배포 및 런타임 문제를 애플리케이션 외부에서 처리하고 모든 “컨테이너화된” 앱에서 일관된 방식으로 처리하는 방식으로 애플리케이션을 패키지화할 수 있다. 컨테이너 런타임이 설치된 모든 리눅스 또는 윈도우 호환 호스트에서 컨테이너를 실행할 수 있다.

컨테이너는 캡슐화, 격리, 이동성 및 제어 외에도 많은 이점을 제공한다. 우선, 크기가 가상머신은 기가바이트 단위인데 비해 컨테이너는 메가바이트 단위로 작다. 즉각 실행되며, 버전 관리 및 구성 요소 재사용을 위한 자체 메커니즘이 내장되어 있다. 도커 허브나 프라이빗 리포지토리와 같은 디렉토리를 통해 쉽게 공유할 수 있다.

또한 컨테이너는 변경할 수 없으므로 보안과 운영 측면에서 모두 이점이 있다. 컨테이너에 대한 모든 변경 사항은 완전히 새롭고 버전이 다른 컨테이너로 배포해야 한다.

여기서는 컨테이너를 통해 소프트웨어를 더 쉽게 빌드하고 배포할 수 있는 방법을 살펴본다. 컨테이너가 어떤 문제를 해결하고 어떻게 해결하는지, 컨테이너가 문제에 대한 정답인 경우와 그렇지 않은 경우에 대해서도 알아본다.

컨테이너 이전의 소프트웨어

오랫동안 엔터프라이즈 소프트웨어는 ‘베어메탈(Bare Metal) 환경(기반 하드웨어를 완전히 제어할 수 있는 운영체제에 설치) 또는 가상머신 환경(기반 하드웨어를 다른 “게스트” 운영체제와 공유하는 운영체제에 설치)에 배포하는 것이 일반적이었다. 당연히 베어메탈 환경에 설치하면 소프트웨어를 이동하고 업데이트하기가 매우 어렵기 때문에 IT 부서가 비즈니스 요구사항의 변화에 민첩하게 대응하기 어려웠다.

그러던 중 가상화가 등장했다. 가상화 플랫폼(하이퍼바이저라고도 함)을 사용하면 여러 가상머신이 하나의 물리 시스템을 공유할 수 있으며, 각 가상머신은 자체 운영체제, 스토리지, I/O를 갖춘 전체 시스템의 동작을 격리된 방식으로 에뮬레이션할 수 있다. 이제 IT 부서는 수요를 충족하거나 자원을 절약하기 위해 가상머신을 복제, 복사, 마이그레이션, 증설 또는 축소할 수 있으므로 비즈니스 요구 사항의 변화에 보다 효과적으로 대응할 수 있다.

또한 하나의 물리 시스템에 여러 대의 가상머신을 통합할 수 있기 때문에 비용 절감에도 도움이 됐다. 오래된 애플리케이션을 실행하는 레거시 시스템을 가상머신으로 전환하고 물리 시스템은 폐기해 더 많은 비용을 절감할 수 있다.

하지만 가상머신에는 여전히 많은 문제가 있다. 가상머신은 크기가 크고, 각 가상머신에 전체 운영체제가 포함되어 있다. 하나의 시스템에 통합할 수 있는 가상화된 앱의 수도 제한되어 있다. 가상머신 프로비저닝에는 여전히 상당한 시간이 소요된다. 마지막으로, VM의 이동성이 제한된다. 특정 시점이 지나면 VM은 빠르게 변화하는 비즈니스에 필요한 속도, 민첩성, 비용 절감 효과를 제공할 수 없다.

도커와 OCI 표준

컨테이너는 프로세스를 독립적으로 실행하는 등과 같은 리눅스의 기반 기능들을 한데 묶어 구성하는 방법으로 고안됐다. 하지만 컨테이너들을 함께 사용하기 어려웠고, 오늘날 컨테이너가 동작하는 방식으로 구현하려면 상당한 수작업을 수행해야 했다.

2013년에 출시된 도커는 앱을 컨테이너화하는 데 필요한 모든 작업을 쉽게 자동화할 수 있게 했다. 도커는 프로젝트로 성공하고, 이후 수익을 창출하는 기업으로도 성공하면서 컨테이너에 대한 도커의 접근 방식이 사실상 표준이 됐다. 그 후 몇 년 동안 컨테이너 도입이 확산되면서 컨테이너를 가장 잘 구현하는 방법에 대한 경쟁적인 아이디어가 생겨나기 시작했다.

결국 공통의 표준이 등장했다. 2017년에 공식화된 OCI(Open Container Initiative) 사양은 도커와 그 경쟁사들의 공헌으로 탄생했다. 이제 도커라는 회사는 예전의 흔적만 남았지만, 제품인 도커와 오픈소스 프로젝트인 도커는 여전히 살아 있으므로 OCI 표준이 독자적으로 생존하고 번성하는 것은 당연한 일이다.

컨테이너와 컨테이너화의 이점

컨테이너는 가상머신과 비슷하게 작동하지만, 훨씬 더 구체적이고 세분화된 방식으로 작동한다. 컨테이너는 단일 애플리케이션과 그 종속성(앱 실행에 필요한 모든 외부 소프트웨어 라이브러리)을 기본 운영체제 및 다른 컨테이너로부터 격리한다.

컨테이너화된 모든 앱은 하나의 공통 운영체제(리눅스 또는 윈도우)를 공유하지만, 서로 간에, 그리고 시스템 전체로부터 구획화되어 있다. 운영체제는 이런 구획화를 실현하는 데 필요한 격리 메커니즘을 제공한다. 컨테이너는 이런 메커니즘을 개발자를 위한 편리한 인터페이스로 포장한다.

컨테이너의 장점은 여러 곳에서 나타난다. 다음은 VM이나 베어메탈에 비해 컨테이너를 사용할 때 얻을 수 있는 몇 가지 주요 이점이다.

시스템 자원을 더 효율적으로 사용한다.

컨테이너화된 앱의 인스턴스는 가상머신보다 훨씬 적은 메모리를 사용하며, 더 빠르게 시작 및 중지되고, 호스트 하드웨어에 훨씬 더 조밀하게 담을 수 있다. 이 모든 것이 IT 비용 절감으로 이어진다.

비용 절감 효과는 어떤 앱을 사용하고 얼마나 많은 자원을 사용하는지에 따라 다르지만, 컨테이너는 언제나 가상머신보다 더 효율적이다. 또한 동일한 워크로드를 실행하는 데 필요한 운영체제 인스턴스 수가 훨씬 적기 때문에 소프트웨어 라이선스 비용도 절감할 수 있다.

더 빠른 소프트웨어 전달 주기를 지원한다.

엔터프라이즈 소프트웨어는 변화하는 환경에 빠르게 대응해야 한다. 즉, 수요에 맞춰 쉽게 확장하고 비즈니스에 필요한 새로운 기능을 추가하기 위해 쉽게 업데이트할 수 있어야 한다. 컨테이너를 사용하면 새로운 비즈니스 기능이 포함된 새 버전의 소프트웨어를 신속하게 프로덕션에 적용하고, 필요한 경우 이전 버전으로 빠르게 롤백할 수 있다. 또한 블루/그린 배포와 같은 전략을 더 쉽게 구현할 수 있다.

애플리케이션 이동성을 지원한다.

엔터프라이즈 애플리케이션을 실행하는 위치는 중요하다. 방화벽 뒤에서 보안을 유지하려면 방화벽 뒤에서, 또는 퍼블릭 클라우드에서 손쉬운 공개 액세스와 자원의 높은 탄력성을 원한다면 퍼블릭 클라우드에서 실행하는 것이 좋다.

컨테이너는 애플리케이션을 실행하는 데 필요한 모든 것을 캡슐화하기 때문에 애플리케이션을 환경 간에 쉽게 전환할 수 있다. 컨테이너 런타임이 설치된 호스트는 개발자의 노트북이든 퍼블릭 클라우드 인스턴스이든 상관없이 컨테이너화된 특정 애플리케이션에 필요한 시스템 자원만 있다면 컨테이너를 실행할 수 있다.

마이크로서비스를 단순화한다.

컨테이너를 사용하면 미래 지향적인 방식으로 소프트웨어를 더 쉽게 구축할 수 있으므로 어제의 개발 방법으로 내일의 문제를 해결하려고 하지 않아도 된다. 컨테이너가 간소화하는 소프트웨어 패턴 중 하나는 느슨하게 결합된 여러 구성 요소로 애플리케이션을 구성하는 마이크로서비스이다.

마이크로서비스는 기존의 ‘모놀리식’ 애플리케이션을 별도의 서비스로 분해함으로써 비즈니스 요구사항에 맞는 경우 별도의 팀과 별도의 일정에 따라 비즈니스 앱의 여러 부분을 별도로 확장, 수정 및 서비스할 수 있게 해준다. 컨테이너는 마이크로서비스를 구현하기 위해 반드시 필요한 것은 아니지만, 마이크로서비스 접근 방식과 애자일 개발 프로세스에 너무나도 안성맞춤이다.

컨테이너가 해결하지 못하는 문제

컨테이너를 구현할 때 가장 먼저 생각해야 할 것은 모든 소프트웨어 기술에 적용되는 것과 동일한 조언이다: 컨테이너는 만병통치약이 아니다. 컨테이너 자체만으로는 모든 문제를 해결할 수 없다. 컨테이너가 해결하지 못하는 몇 가지 특정 문제를 살펴보자.

보안 문제가 해결되지 않는다.

컨테이너에 있는 소프트웨어가 베어메탈에서 실행되는 소프트웨어보다 기본적으로 더 안전할 수 있지만, 이는 문이 잠긴 집이 문이 열려 있는 집보다 더 안전하다고 말하는 것과 같다. 주변 환경, 도둑을 유혹하는 귀중품의 가시적 존재, 그곳에 사는 사람들의 일상 등에 대해서는 아무것도 말해주지 않다. 컨테이너는 보안 계층을 추가할 수 있지만, 상황에 따라 애플리케이션을 보호하는 일반적인 프로그램의 일환일 뿐이다.

애플리케이션을 마이크로서비스로 자동 전환하지 않는다.

기존 앱을 컨테이너화하면 자원 리소스 소비가 줄어들고 배포가 쉬워질 수 있다. 하지만 애플리케이션의 디자인이나 다른 애플리케이션과 상호 작용하는 방식이 자동으로 변경되지는 않는다. 이런 이점은 개발자의 시간과 노력을 통해서만 얻을 수 있다.

구식 모놀리식 또는 SOA 스타일의 애플리케이션을 컨테이너에 넣으면 결국 구식 애플리케이션을 컨테이너에 넣는 것과 마찬가지다. 그렇다고 해서 업무에 더 유용해지는 것은 아니며, 오히려 유용성이 떨어질 수도 있다.

컨테이너 자체에는 마이크로서비스 스타일의 앱을 구성할 수 있는 메커니즘이 없다. 이를 위해서는 더 높은 수준의 오케스트레이션이 필요한다. 쿠버네티스는 이런 오케스트레이션 시스템의 가장 일반적인 예다. 좀 더 가벼운 솔루션인 도커 스웜 모드를 사용하면 여러 도커 호스트에서 많은 도커 컨테이너를 관리할 수 있다.

가상머신을 대체하지 않는다

컨테이너에 대한 오래된 오해 중 하나는 컨테이너가 가상머신을 쓸모없게 만든다는 것이다. 가상머신에서 실행되던 많은 앱을 컨테이너로 옮길 수 있지만, 그렇다고 해서 모든 앱을 컨테이너로 옮길 수 있거나 옮겨야 한다는 의미는 아니다. 예를 들어, 규제 요건이 엄격한 산업에 종사하는 경우, 가상머신이 컨테이너보다 더 많은 격리 기능을 제공하기 때문에 컨테이너를 VM으로 교체할 수 없는 애플리케이션도 있다.

컨테이너를 위한 변론

엔터프라이즈 개발 분야는 폐쇄적이고 변화에 느리게 대응하는 것으로 악명이 높다. 엔터프라이즈 개발자는 IT가 부과하는 제한이나 비즈니스 전반의 요구 등 많은 제약에 부딪히게 된다. 컨테이너는 개발자가 갈망하는 더 많은 자유를 제공하는 동시에 변화하는 비즈니스 환경에 빠르게 대응하는 비즈니스 앱을 구축할 수 있는 방법을 제공한다.
dl-itworldkorea@foundryco.com