환상 금물…도커에 대해 알아야 할 것들

지난달 1일 열린 오스콘(OSCon)은 도커에 대한 관심이 얼마나 뜨거운지 보여준 현장이었다. 많은 기업들이 서버 애플리케이션을 가상머신(VM)에서 컨테이너로 이전하고 있다는 소식이 관심을 끌었다.

미국 지디넷의 최근 보도에 따르면, 도커사의 제임스 턴불 서비스&서포트 부사장은 컨퍼런스에서 초대형 은행 3곳이 도커를 프로덕션 환경에 적용하기 위해 베타테스트를 진행중이라고 전했다. 도커사가 도커1.0 버전을 내놓으며 엔터프라이즈급 니즈를 언급한 건 이 때문이었던 듯하다.

그러나 어느 기업이나 조직보다 보안을 우선시하는 금융권이 1.0 버전에 불과한 기술을 덜컥 현업 시스템에 적용하리라 확신하기 힘들다. 언제나 그렇듯 급부상하는 신기술에 대한 막연한 환상은 금물이다. 도커 역시 장단점이 명확하게 존재한다. 도커로 할 수 있는 것과 할 수 없는 것을 정리해본다. ■도커란 무엇인가

도커의 정체부터 정의해보자. 도커의 사전적 정의는 '이동 가능한 경량화된 가상화 기반의 운영체제'다. 리눅스 기반의 컨테이너를 생성하고 배포하는 작업 상당부분을 자동화하는 패키지 툴로 통한다.

도커는 리눅스 커널 즉 호스트OS를 공유하면서, 컨테이너마다 고유의 그리고 하드웨어단의 CPU, 메모리, 디스크, 네트워크 인터페이스를 할당한다. 한 컨테이너에 할당된 물리적 자원에 다른 컨테이너가 접근할 수 없는 멀티테넌트를 지원한다. 파일시스템과 라이브러리를 컨테이너 여러개가 공유하거나 별도로 보유할 수 있다. 부팅과 관련한 이닛프로세스도 컨테이너마다 다르다.

호스트OS 상단에 도커 엔진을 올리고 그를 기반으로 컨테이너들을 구성하는 형태다. 서버가상화는 호스트OS에 하이퍼바이저를 올려 VM을 만든 뒤, VM에 게스트OS를 설치해 애플리케이션을 만든다.

컨테이너를 활용하면 리눅스 OS 아랫단의 하드웨어 부분에 대한 시스템 요구사항을 개발자가 제어, 관리할 수 있다. 개발자가 도커 컨테이너 이미지로 앱을 만들면, 도커 환경에선 하드웨어가 달라져도 시스템설정을 유지할 수 있다. 앱의 이동성(portable)을 쉽게 확보할 수 있다는 의미다. '포터블(portable)'이란 공식 정의는 이 성격을 반영한다.(☞관련기사)

■묵은 기술 '컨테이너'가 재조명 받는 이유

컨테이너는 하드웨어 활용도(Utility)에서 서버 가상화보다 우위에 있다. 제임스 보톰리 패러렐즈 서버가상화 최고기술책임자(CTO)는 하나의 리눅스 인스턴스 위에 여러 컨테이너를 정렬하므로 쓸모없는 VM 정크(Junk)를 99.9%까지 없앨 수 있다고 설명했다.

그에 의하면 동일한 서버 하드웨어에서 젠(Xen)이나 KVM의 VM을 이용했을 때보다 4~6배 많은 서버 애플리케이션을 사용할 수 있게 된다.

도커는 신기술이지만 컨테이너 자체는 새로운 아이디어가 아니다. 적어도 2000년대초 프리BSD의 제일(Jail)이란 기능이 컨테이너와 같은 아이디어다. 오라클 솔라리스도 유사한 콘셉트의 '존(Zone)'이란 기능을 일찌감치 제공해왔다. 메인프레임과 유닉스 시절부터 있었던 컨테이너란 개념은 오픈VZ, 리눅스컨테이너(LXC) 같은 오픈소스 프로젝트로도 구현돼 있었다.

최근 들어 도커란 기술이 관심을 끌고 컨테이너의 유용성이 재조명 받는 이유는 무엇일까. 유닉스의 유사 컨테이너 기술에 비해 리눅스 환경에서 컨테이너를 쓰는 게 쉽지 않았던 탓에 LXC가 대중화되지 못했기 때문이다. 도커는 컨테이너란 영역으로 가는 진입장벽을 허무는 존재로 스타덤에 올랐다.

구글은 일찌감치 컨테이너 기술을 위한 자체적인 오픈소스SW를 개발해 사용했다. 'lmcfty(Let Me Contain That For You)'란 기술이다. 최근 구글이 G메일, 검색, 구글독스 등 자신들의 모든 서비스에 컨테이너를 사용하고 있다고 밝힌 건 이 기술을 활용한다.

이에 대해 도커 전문가들은 구글 정도 되니까 컨테이너를 주무를 수 있었던 것이라고 표현한다. 그만큼 컨테이너가 쓰기 어렵다는 것이다. 도커가 구글처럼 컨테이너를 주무를 수 있게 해주니 개발자들이 환호할 수밖에 없다.

■도커로 할수 있는 것과 없는 것은

LXC 위에 만들어졌던 도커는 다른 컨테이너 기술처럼 고유의 파일시스템과 스토리지, CPU, 메모리를 갖는다. VM과 컨테이너의 극명한 차이점은 여기다. 하이퍼바이저가 전체 하드웨어 기기를 추상화한다면, 컨테이너는 OS 커널을 추상화한다.

컨테이너를 쓰려면 하나의 OS만 써야 한다는 의미다.

하이퍼바이저를 사용하면 여러 OS를 한 하드웨어에서 쓸 수 있다. 하이퍼바이저를 사용하면 x86서버를 사서, 리눅스 앱이나 윈도 기반 앱을 섞어서 쓴다. 단일한 하드웨어에서 리눅스도 여러 배포판을 쓸 수 있고, 윈도도 여러 버전을 쓸 수 있다. 도커는 이게 불가능하다.

다양한 OS 환경을 운영해야 한다면 하이퍼바이저를 쓰는 게 더 유용할 수 있다. 반면, 동일한 애플리케이션을 여러 에디션이나 버전으로 관리해야 한다면 컨테이너가 유용할 것이다. 도커의 경우 SW 업데이트와 버전관리가 용이하기 때문이다.

도커는 대규모의 프라이빗 클라우드나 퍼블릭 클라우드에 쓸모가 있다. 또, 앱을 클라우드 기반 서비스 형태로 판다고 할 때 개발, 테스트, 운영에 이르는 프로세스가 대폭 단축된다.

수많은 고객에게 별도의 애플리케이션 이용환경을 할당하고 업데이트를 지속해야 하는 SaaS와 PaaS 같은 클라우드 서비스 진영에서 많이 활용하려는 이유다. 하드웨어와 운영비용을 연간 수십만에서 수백만 달러까지 절감하게 해주기 때문이다.

하이브리드 클라우드 환경을 쓴다면 도커 컨테이너는 조금 고민해봐야 할 문제다. 도커 컨테이너 이미지를 언제고 재활용할 수 있지만, 도커의 플랫폼 호환성이 아직 부족하다.

이미지를 다른 도커 환경으로 옮겨 재활용할 수는 있어도, VM웨어의 V모션 같은 라이브 마이그레이션은 안 된다. 고가용성이란 운영 측면으로 보면 도커의 이동성은 별로 필요없는 장점이다.

만약, 개발자나 운영자가 현재 퍼펫, 셰프, 베이그런트 같은 데브옵스(DevOps) 툴을 쓰지 않거나 모른다면 도커에도 별로 관심을 두지 않을 것이다.

개발과 운영 모두에게 혜택을 줄 잠재력을 가졌지만, 여전히 개발을 할 줄 아는 운영자여야 도커에 관심을 갖는다. 데브옵스를 할 수 없는 운영자에게 현업시스템에서 도커를 쓰게 한다면, 그 회사의 IT환경은 도커의 장점을 전혀 누릴 수 없다.

도커는 아직 1.0 버전에 불과하다. 충분한 검토와 실험이 필요한 시점이다. 도커가 LXC를 벗어나 여러 플랫폼과 섞이기 시작한 것도 얼마되지 않았다.(☞관련기사)

때문에 여러 전문가들은 도커를 당장 현업에 적용하려 하기보다, IT개발과 운영 프로세스를 잘 다듬을 필요가 있다며 일단 개발환경에 적용해 테스트한 뒤 유효성을 검증해볼 것을 추천한다고 밝히고 있다.