이 글은 IDG의 아티클을 전재하여 제공합니다.
[원문보기] : https://www.itworld.co.kr/t/62076/
1981년에 출간된 '나무에 젤리못 박기(Nailing Jelly to a Tree)'라는 책은 소프트웨어를 “모호해서 확실히 통제하기 어려운 것”이라고 묘사했다. 1981년 당시에는 맞는 말이었고 40년이 지난 지금도 제법 유효한 말이다. 예나 지금이나 소프트웨어는 사용자가 구매한 것이든 직접 개발한 것이든 배포와 관리, 실행이 다 어렵다.
도커(Docker) 컨테이너는 소프트웨어를 통제할 수단을 제공한다. 도커를 활용하면 애플리케이션의 배포 및 런타임 문제(네트워크상에 노출하는 방법, 저장용량, 메모리, I/O를 관리하는 방법, 접근 권한을 통제하는 방법 등)가 애플리케이션 외부에서 처리되고 “컨테이너화”된 모든 앱에 걸쳐 일관된 방식으로 애플리케이션을 포장할 수 있다. 도커 컨테이너는 도커 런타임이 설치된 모든 OS 호환 호스트(리눅스 또는 윈도우)에서 실행할 수 있다.
도커는 이런 편리한 캡슐화, 격리, 이동성, 통제 이외에 다른 장점도 많다. 도커 컨테이너는 크기가 작고(수 MB) 즉각적으로 실행된다. 버전 작성 및 구성요소 재사용을 위한 자체 메커니즘도 내장되어 있으며, 공용 도커 허브나 사설 저장소를 통해 쉽게 공유할 수 있다. 도커 컨테이너는 또한 불변성이 있다. 이는 보안은 물론 운영 면에서도 장점이 있다. 특정 컨테이너에 대한 변경사항은 버전이 다르게 작성된 완전히 새로운 컨테이너로 배포해야 한다.
여기서는 도커 컨테이너가 어떻게 소프트웨어의 개발과 배포 모두를 수월하게 만드는지, 도커 컨테이너가 해결하는 문제는 무엇이며 어떻게 해결하는지, 도커 컨테이너가 문제의 정답일 때와 그렇지 않을 때는 언제인지 등을 알아본다.
도커 컨테이너가 없던 시절
오랜 세월 기업 소프트웨어는 보통 “베어메탈(bare metal)”이나 가상머신(VM)에 배포되었다. 베어메탈은 소프트웨어가 설치되는 운영체제가 기반 하드웨어를 전적으로 통제하는 반면, 후자는 기저 하드웨어를 다른 “게스트” 운영체제와 공유한다. 당연히 베어메탈에 설치하면 소프트웨어를 여기저기 옮기는 것이 큰 골칫거리였고 소프트웨어를 업데이트하기도 어려웠다. 이런 두 가지 제약 때문에 IT 부서가 비즈니스 수요의 변화에 민첩하게 대응하기 힘들었다.
그러던 중 가상화 기술이 등장했다. 가상화 플랫폼(일명 “하이퍼바이저(hypervisor)”) 덕분에 여러 대의 가상머신이 하나의 물리 시스템을 공유할 수 있게 됐다. 가상머신 한 대마다 자체적인 운영체제, 저장장치, I/O를 완비하고 격리된 방식으로 전체 시스템의 행동을 모방했다. 따라서 IT 부서는 비즈니스 요구의 변화에 보다 효과적으로 대응할 수 있게 됐다. VM은 수요 충족이나 리소스 절약을 목적으로 한 복제, 복사, 이전, 스핀 업/다운 등이 가능했기 때문이다.
VM은 비용 절감에도 도움이 됐다. 최대한 많은 VM을 최대한 적은 물리 시스템에 통합할 수 있기 때문이다. 구형 애플리케이션을 실행하는 레거시 시스템을 VM으로 바꾼 후 물리 시스템을 해체해 버리면 비용을 더욱 절감할 수 있다.
그러나 VM은 여전히 나름의 문제가 있다. VM 한 대마다 운영체제 하나가 온전히 들어 있어 크기가 크다(수 GB). 또한, 단일 시스템에 통합할 수 있는 가상화된 앱의 개수에 한계가 있다. VM 프로비저닝에는 꽤 많은 시간이 걸린다. 마지막으로, VM은 이동성에 제한이 있다. 특정 시점이 지나면 VM은 빠르게 움직이는 기업이 요구하는 수준의 속도, 민첩성, 비용 절감 효과를 제공할 수 없다.
도커 컨테이너의 장점
컨테이너는 작동 방식이 VM과 약간 비슷하지만 훨씬 더 구체적이고 세밀하다. 하나의 애플리케이션과 애플리케이션이 의존하는 요소(애플리케이션의 실행에 필요한 외부 소프트웨어 일체)를 기반 운영체제는 물론 다른 컨테이너로부터 격리한다. 컨테이너화된 앱은 모두 단일 공통 운영체제(리눅스 또는 윈도우)를 공유하지만 상호 간은 물론 전체적인 시스템과도 구분되어 있다. 이런 구분에 필요한 격리 메커니즘을 운영체제가 제공한다. 도커는 개발자를 위해 그런 메커니즘을 편리한 인터페이스와 추상화로 포장한다.
도커 컨테이너의 장점은 여러 곳에서 나타난다. 도커와 컨테이너의 주요 장점은 다음과 같다.
시스템 자원을 더 효율적으로 활용할 수 있다
컨테이너화된 앱의 인스턴스는 가상머신에 비해 사용하는 메모리가 훨씬 적고, 가동과 중단이 더 빠르며, 호스트 하드웨어 상의 밀집도가 훨씬 더 높다. 이는 모두 IT 지출 감소로 이어진다. 비용 절감 수준은 어떤 앱을 실행하고, 해당 앱이 얼마나 리소스 집약적인지에 따라 달라지지만, 컨테이너의 효율성은 예외 없이 VM보다 높다. 소프트웨어 라이선스 비용을 절약하는 것도 가능하다. 동일한 워크로드를 실행하기 위해 필요한 운영체제 인스턴스가 대폭 줄어들기 때문이다.
소프트웨어 제공 주기가 빨라진다
기업 소프트웨어는 변화하는 상황에 빠르게 대응해야 한다. 이는 수요에 맞추기 위한 확장 작업은 물론 비즈니스가 요구하는 새로운 기능을 추가하기 위한 업데이트 작업도 수월해야 한다는 의미다. 도커 컨테이너를 활용하면 새로운 비즈니스 기능이 들어간 새로운 버전의 소프트웨어를 프로덕션 단계로 빠르게 배치하고 필요 시 이전 버전으로 빠르게 복구하는 작업이 수월해진다. 블루/그린 배포와 같은 전략의 실행도 마찬가지다.
애플리케이션의 이동이 가능해진다
기업 애플리케이션을 실행하는 장소는 중요하다. 가까이에 안전하게 두고 싶다면 방화벽 뒤에서 실행하고, 수월한 일반인 접근과 리소스의 높은 탄력성을 위해서라면 외부의 퍼블릭 클라우드에서 실행한다. 도커 컨테이너는 애플리케이션의 실행에 필요한 모든 것(그 외의 것은 일체 배제)을 캡슐화하므로 애플리케이션이 여러 환경 사이를 쉽게 오갈 수 있다. 도커 런타임이 설치된 호스트라면 개발자의 노트북 컴퓨터든 퍼블릭 클라우드 인스턴스든 어디에서나 실행할 수 있다.
마이크로서비스 아키텍처에서 진가를 발휘한다
경량성, 이동성, 독립성을 갖춘 도커 컨테이너는 미래를 염두에 둔 방식으로 소프트웨어를 개발하기 쉽게 만들어 준다. 따라서, 내일의 문제를 어제의 개발 방법으로 해결하려고 애쓸 필요가 없다. 컨테이너를 통해 보다 수월해지는 소프트웨어 패턴 중에 마이크로서비스가 있다. 느슨하게 연결된 다수의 구성요소로 애플리케이션을 구성하는 방식이다. 마이크로서비스는 전통적인 “모놀리식” 애플리케이션을 별도의 서비스로 분해한다. 따라서, 업무별 앱의 다양한 부분을 개별적으로 확장, 수정, 서비스할 수 있게 된다. 기업의 요구에 맞는다면, 이를 별도의 팀이 별도의 일정으로 수행할 수도 있다. 마이크로서비스 구현에 꼭 필요한 것은 아니지만, 컨테이너는 마이크로서비스 접근방식과 일반적인 애자일 개발 프로세스에 안성맞춤이다.
도커 컨테이너로 해결되지 않는 문제
모든 소프트웨어 기술이 마찬가지지만, 컨테이너가 만병통치약은 아니다. 도커 컨테이너 그 자체로는 모든 문제를 해결할 수 없다. 특히 다음과 같은 문제가 있다.
도커로는 보안 문제가 해결되지 않는다
컨테이너 안의 소프트웨어는 베어메탈상의 소프트웨어보다 기본적으로 더 안전할 수 있지만, 이는 문이 잠겨 있지 않은 집보다 문이 잠겨 있는 집이 더 안전하다는 말과 다를 것이 없다. 동네의 상태, 절도범을 유혹하는 귀중품이 눈에 보이게 있는지 여부, 거주자의 일상 등은 전혀 언급하지 않는다. 컨테이너는 앱에 보안 계층을 추가할 수는 있지만, 앱의 안전을 보호하는 일반 프로그램의 일환일 뿐이다.
도커는 애플리케이션을 마이크로서비스로 바꾸는 마법을 부리지 않는다
기존 앱을 컨테이너화하면 앱의 리소스 소비가 줄고 앱의 배포가 수월해지지만, 해당 앱의 ‘설계’나 다른 앱과의 상호작용 방식이 자동으로 변하는 것은 아니다. 그런 장점은 단순히 모든 것을 컨테이너로 이전한다고 얻어지는 것이 아니라 개발자의 시간과 노력을 통해서만 얻어진다. 구식 모놀리식 또는 SOA 방식 앱을 컨테이너에 넣어봤자 컨테이너 안의 구식 앱일 뿐이다. 유용성을 높이기는커녕 오히려 저하시킬 우려가 있다. 컨테이너 자체에는 마이크로서비스 방식 앱을 작성할 메커니즘이 없다. 이를 위해서는 더 높은 수준의 오케스트레이션이 필요하다. 쿠버네티스가 그런 오케스트레이션 시스템의 대표적인 예이며, 도커 스웜 모드(swarm mode)도 여러 도커 호스트에 걸친 다수의 도커 컨테이너 관리에 활용할 수 있다.
도커는 가상머신의 대체제가 아니다
컨테이너와 관련해 좀처럼 사라지지 않는 한 가지 오해는 컨테이너만 있으면 이제 VM는 쓸모없다는 것이다. VM에서 실행하던 많은 앱은 컨테이너로의 이전이 ‘가능’하지만 그렇다고 앱을 ‘모두’를 이전할 수 있거나 이전해야 한다는 뜻은 아니다. 예를 들어 규제 요건이 엄격한 산업군이라면, VM을 컨테이너로 대체할 수 없다. VM이 컨테이너보다 더 많은 격리를 제공하기 때문이다.
그래도 도커 컨테이너를 사용해야 하는 이유
기업 개발 업무는 편협하고 변화에 대한 반응이 느리기로 악명 높다. 기업 개발자는 IT 부서에서 강요한 제약, 회사 전반적으로 내리는 요구사항 등 여러 압박에 항상 시달린다. 도커와 컨테이너는 개발자가 갈망하는 자유를 더 많이 부여하는 동시에, 변화하는 비즈니스 상황에 빠르게 대응하는 비즈니스 앱을 개발할 수단을 제공한다.
▶ 해당 콘텐츠는 저작권법에 의하여 보호받는 저작물로 기고자에게 저작권이 있습니다.
▶ 해당 콘텐츠는 사전 동의 없이 2차 가공 및 영리적인 이용을 금하고 있습니다.
InfoWorld