레드햇에 도커 기술의 전략적 가치는?

레드햇은 지난 레드햇엔터프라이즈리눅스(RHEL)6.5 버전부터 컨테이너 배포기술인 도커(Docker)를 지원하기 시작했고, RHEL7은 아예 도커를 배포판 일부로 포함시켰다. 그리고 4월엔 도커의 주도 개발사인 前 ‘닷클라우드’, 현재의 ‘도커’와 협력방안을 발표하면서 늦었지만 발 빠른 움직임을 보였다.

그전까지 도커는 우분투만 지원했기 때문에, 리눅스컨테이너(LXC) 기반 기술임에도 그 활용에 제약사항을 갖고 있었다. 레드햇의 가세는 도커의 리눅스 생태계 확산에 기폭제 역할을 할 것으로 주목되고 있다.

개발자 사이에선 도커와 컨테이너가 가상머신(VM)을 만들어내는 서버 가상화를 대체할 수 있는가를 두고 열띤 토론이 벌어진다. 컨테이너와 VM을 경쟁구도로 본다면 커널기반가상화(KVM)와 도커 컨테이너를 RHEL 안에서 모두 제공한다는 레드햇의 행보는 흥미롭다.

박준완 한국레드햇 차장은 “도커는 리눅스에서 컨테이너를 쉽게 쓰게 하는 도구로 애플리케이션과 하드웨어 조합을 어떻게 구성할 것인가에 대한 고민에서 나왔다”며 “경량화된 가상화 기반의 운영시스템이라 정의되지만 가상화와는 다른 개념”이라고 설명했다.

그는 “크게 호스트 기반과 이미지 기반으로 컨테이너 기술이 나뉘는데, 도커는 이미지 기반이므로 각 컨테이너가 자신만의 네트워크 인터페이스와 프로세스 공간, 이닛 프로세스를 별도로 갖는다”며 “서버 가상화와 사용 형태나 구성 형태가 달라 비교 대상으로 보기 힘들다”고 덧붙였다.

박준완 차장이 밝힌 도커의 장점은 일반적으로 인식되는 것과 크게 다르지 않다. 도커가 이미 존재했으나 사용하기에 너무 어려워 널리 쓰이지 못했던 LXC를 손쉽게 쓸 수 있게 하는 패키지 기술이란 점이다.

또, 개발자가 개발 절차 속에서 자신의 구성을 그대로 유지할 수 있다는 점, 애플리케이션 업데이트 시 변경된 라이브러리만 따로 이미지로 만들어 기존 컨테이너 이미지에 붙였다 떼는 식으로 운영한다는 점 등 사용 방법이 무궁무진하다는 면을 강조했다. 성능도 도커 1.0으로 가면서 물리적 호스트 서버와 1대1에 가까운 수준을 보이고 있다. 부족했던 네트워크 손실도 많이 개선됐다는 설명이다.

레드햇 입장으로 볼 때 도커는 꽤 낯익은 기술로 이뤄져 있다. 도커에 내장된 파일시스템인 AUFS(Advanced multi layered Unification File System)이 RHEL의 라이브CD 에서 사용된다. AUFS는 여러 레이어에 걸쳐 사용하는 구조로, 하나의 파일시스템을 하나의 마운트 포인트에 붙이는 일반적 리눅스용 파일시스템과 다르다.

그는 “레드햇에서 도커를 이용한 새로운 프로젝트를 구성하고 있다”며 “아토믹(Atomic)이란 프로젝트인데, 컨테이너 기술에 오픈시프트 PaaS에서 쓰는 애플리케이션 배포 툴 ‘기어D’를 함께 활용하는 가벼운 호스트 운영체제 개발 프로젝트”라고 밝혔다. 레드햇은 또한 오픈시프트 PaaS 오리진의 기본 컨테이너 배포 기술에 도커를 채택했다.

그는 이어 “현재 레드햇의 제이보스 엔지니어들은 모두 컨테이너를 활용해 개발하고 있다”며 “제이보스 개발자들의 반응은 매우 긍정적이다”고 덧붙였다.

도커와 컨테이너의 여러 한계점도 언급됐다. 그는 우선 기존의 시스템 운영자, 즉 개발 지식을 갖지 않은 운영자에게 환영받기 어렵다는 점을 들었다.

그는 “도커를 설명할 때 데브옵스란 단어가 많이 나오는데, 이는 역으로 개발지식을 갖지 못한 순수 운영자에게 도커란 프로세스의 증가로 보일 수 있다는 의미다”며 “아직 도커를 어떻게 관리할 것인가에 대한 프로세스와 체계가 없어 혼란스러울 수 있다”고 설명했다.

개발과 운영의 프로세스를 분리해놓은 현재의 국내외 대다수 기업 및 공공 현장에서 무턱대고 도커를 도입할 수는 없다는 지적이다.

그는 “VM에 비해 도커는 이미지를 개발할 때 중간에 설정을 잘못한 걸 발견하면, 그동안 해온 구성을 다 버리고 새로 시작해야 한다”며 “프로세스를 미리 만들어 놓고 도커를 쓰는가가 정말 중요한 부분이며, 도커를 쓰기 전 계획을 철저히 하고, 미리 준비를 다 마친 상태에서 써야 한다”고 강조했다.

보안 측면의 단점도 제기됐다.

그는 “도커 커뮤니티에 각지의 개발자가 자신들의 이미지를 사이트에 올려 공유하고 있다”며 “그냥 이미지를 받아서 쓰면 되긴 하는데, 실제로 돌려보기 전까지 그 이미지에 무엇이 담겼는가를 알 수 없기 때문에 거기서 나오는 보안 문제가 있다”고 전했다.

그는 “때문에 이미지를 다운로드받기 보다 도커 이미지를 만들 때 생성하는 도커 파일이란 걸 받아 자신이 원하는 이미지를 만드는 게 유용한 접근법 같다”며 “도커 파일엔 애플리케이션과 라이브러리, 스크립트 등의 정보들이 담겨 있다”고 덧붙였다.

또한 도커 시스템에 대한 시스템관리자 권한을 어느 선까지 부여할 것인가도 이슈라고 설명했다. 개발시스템에서 모든 개발자에게 도커의 관리자권리를 줄 경우 권한 이슈가 발생할 수 있다는 것이다. 그는 “개발자의 노트북에서 이미지를 만들어 시스템에 업로드하는 형태가 일반적인 모습으로 자리잡을 것”이라고 말했다.

KVM과 도커의 관계는 어떨까. 그는 “KVM에서 할 수 있는 걸 컨테이너에서 다 쓸 수 있다고 엔지니어들은 본다”며 “그러나 각자 별개의 것으로 흘러갈 것이라 예상한다”고 말했다.