도커와 컨테이너를 꼭 사용해야 하는 이유

2018년 10월 13일      

ⓒ CIO Korea, Serdar Yegulalp | InfoWorld

1981년 출판된 <Nailing Jelly to a Tree>라는 책에서는 소프트웨어를 “흐릿하고 붙잡기 어렵다”고 묘사한다. 1981년에 이는 사실이었고, 40년 가까이가 흐른 지금도 별로 달라지지 않았다. 소프트웨어는, 구매한 애플리케이션이든, 직접 제작한 것이든, 여전히 전개하기 어렵고, 관리하기 까다롭고, 실행하기 힘들다.

도커 컨테이너(Docker container)는 소프트웨어를 제어할 한 수단을 제공한다. 도커를 이용해 애플리케이션을 패키징하면, 이의 전개와 런타임 문제를 애플리케이션 외부에서 제어할 수 있다. 예컨대 애플리케이션을 네트워크에 노출하는 방식, 애플리케이션의 스토리지, 메모리, I/O 이용을 관리하는 방식, 접근 권한을 통제하는 방식 등이다. 그리고 이는 ‘컨테이너화된(containerized)’ 앱들 전체에 일괄적으로 적용된다. 도커 컨테이너는 도커 런타임이 설치된 OS-호환 호스트라면 어디서든 (리눅스 또는 윈도우) 실행될 수 있다.

도커는 이러한 간편한 캡슐화, 격리, 이동성, 제어 외에도 많은 혜택을 제공한다. 도커 컨테이너는 소형이다(메가바이트). 이들은 즉시 시작한다. 버저닝과 컴포넌트 재사용에 관한 자체적인 빌트-인 메커니즘이 있다. 퍼블릭 도커 허브(Docker Hub)나 프라이빗 리포지터리를 통해 간단히 공유될 수 있다.

이 글에서는 도커 컨테이너가 어떻게 소프트웨어의 구축과 전개를 더 쉽게 만드는지를 설명할 것이다. 다시 말해 컨테이너가 대처하는 문제들, 이들 문제를 어떻게 처리하는지, 이들이 문제의 해법이 되는 경우는 어떤 경우이고, 또 문제의 해법이 되지 않는 경우는 어떤 경우인지를 설명할 것이다.

도커 컨테이너 이전
여러 해 동안, 엔터프라이즈 소프트웨어는 일반적으로 ‘베어메탈’ 상에서나 (하부 하드웨어를 전적으로 통제하는 운영체계상에 설치), 또는 가상 머신 내에서 (하부 하드웨어를 ‘게스트’ 운영 체계와 공유하는 운영체계상에 설치) 전개되는 것이 보통이었다. 당연한 말이지만, 베어메탈 상의 설치는 소프트웨어를 이동하거나 업데이트하기가 지극히 어렵게 만들었다. 따라서 IT는 비즈니스 요구의 변화에 민첩하게 대응하기 힘들었다.

그 후 가상화가 등장한다. 가상화 플랫폼은 (‘하이퍼바이저(hypervisors)’라고도 알려짐) 다수의 가상 머신이 하나의 물리 시스템을 공유할 수 있도록 허용했고, 각 가상 머신은 격리된 형식으로 자체 운영 체계, 스토리지 및 I/O를 완비한 전체 시스템의 가동을 에뮬레이션한다. IT는 이제 비즈니스 요건의 변화에 좀더 효과적으로 반응할 수 있었다. VM은 수요에 따라서나 자원 절감을 위해 복제, 복사, 이동 및 가속 또는 감속될 수 있었기 때문이다.

가상 머신은 더 많은 VM이 더 적은 물리 머신상에서 통합될 수 있으므로 비용 절감에도 도움이 되었다. 구식 애플리케이션을 실행하는 구형 시스템은 VM으로 변환되고 물리적으로 해체되어 또다시 비용을 절감할 수 있었다.

그러나 가상 머신이 문제가 없는 것은 아니다. 가상 머신은 거대하고(기가바이트), 각 머신은 전체 운영 체계를 포함한다. 오직 가상 앱들만 한 시스템상에 통합될 수 있었다. VM의 구축은 상당한 시간이 소요된다. 마지막으로, VM의 이동성은 제한적이다. 일정 시점이 되면 VM은 바삐 움직이는 회사가 요구하는 속도, 민첩성, 경제성을 상실한다.

도커 컨테이너의 장점
컨테이너는 VM과 어느 정도 비슷하게 작용한다. 그러나 훨씬 더 특정적이고 미세하다. 컨테이너는 기저의 운영 체계로부터, 그리고 다른 컨테이너로부터, 단일 애플리케이션과 이의 의존성, 다시 말해 앱 실행에 필수적인 외부 소프트웨어 라이브러리 전체를 격리한다. 컨테이너화된 앱은 하나의 공통 운영 체계를 공유한다(리눅스 또는 윈도우). 그러나 이들은 상호 간에, 그리고 시스템으로부터 대체로 분획화되어 있다.

도커 컨테이너의 장점은 여러 환경에서 드러난다. 도커와 컨테이너의 주요한 장점은 아래와 같다.

도커는 시스템 자원을 좀더 효율적으로 이용할 수 있다
컨테이너에 담긴 앱은 가상 머신보다 훨씬 더 적은 메모리를 사용하며, 더 신속하게 시작하고 중지하며, 호스트 하드웨어에서 훨씬 더 밀도 있게 배치될 수 있다. 따라서 그만큼 IT비용이 줄어든다.

비용 절감은 어떤 앱을 이용하고 그 앱이 자원을 얼마나 집약적으로 사용하는가에 따라 달라진다. 그러나 컨테이너는 VM보다 언제나 더 효율적으로 작용한다. 아울러 소프트웨어 라이선스 비용도 절감할 수 있다. 동일한 워크로드를 실행하는데 훨씬 더 적은 수의 운영 체계가 필요하기 때문이다.

도커는 소프트웨어 전달 주기를 가속한다
기업용 소프트웨어는 변화하는 환경에 신속히 대응해야 한다. 수요에 맞춰 스케일링(scaling)을 간단히 할 수 있고, 비즈니스가 요구하는 신기능을 추가하는 업데이트를 간단히 할 수 있어야 한다는 의미다.
도커 컨테이너는 새 업무 기능을 가진 소프트웨어의 신 버전을 신속히 실무에 투입할 수 있고, 필요 시 이전 버전으로 신속히 롤백할 수 있다. 블루/그린 배포 등의 전략을 이행하기도 더 쉽다.

도커는 애플리케이션 이동을 가능하게 한다
엔터프라이즈 애플리케이션을 어디서 실행하는가는 중요하다. 가까이에 안전한 상태로 두기 위해서는 방화벽 뒤에서 이를 실행해야 할 것이고, 간편한 퍼블릭 접근과 자원의 높은 탄력성을 원한다면 퍼블릭 클라우드에서 이를 실행해야 할 것이다. 도커 컨테이너는 애플리케이션이 실행해야 하는 모든 것을 (그리고 오로지 그러한 것들만을) 캡슐화하기 때문에 애플리케이션이 환경들 사이에서 손쉽게 이동할 수 있다. 도커 런타임이 설치된 호스트라면, 그것이 개발자의 노트북이든, 개별 퍼블릭 클라우드든, 도커 컨테이너를 실행할 수 있다.

도커는 마이크로서비스 아키텍처에서 빛을 발한다
경량이고, 이동성 있고, 자족형인 도커 컨테이너는 미래 지향적 사고 경로를 따라 소프트웨어를 구축하는 것을 더 쉽게 해준다. 따라서 내일의 문제를 어제의 개발 방식으로 해결하려고 시도할 필요가 없다.

컨테이너에 의해 좀더 용이해지는 소프트웨어 패턴의 하나는 마이크로서비스다. 여기서 애플리케이션은 다수의 느슨히 결합된 컴포넌트로부터 구성된다. 전통적인 ‘모놀리틱’ 애플리케이션을 부분적 서비스들로 해체함으로써 마이크로서비스는, 비즈니스 요구에 따라 별개의 팀에 의해 별개의 스케줄 상에서, LOB 앱(a Line-Of-Business App)의 부분들이 개별적으로 확장되고, 수정되고, 서비스되도록 할 수 있다.

컨테이너는 마이크로서비스를 이행하는 데 필수적이지 않지만, 이는 마이크로서비스 접근법, 그리고 애자일 개발 프로세스에 완벽히 부합한다.
 

도커 컨테이너가 해결하지 못하는 문제들
어느 소프트웨어 기술에든 통용되는 충고가 컨테이너에 대해서도 마찬가지로 적용된다. 즉, 도커 컨테이너는 만능이 아니라는 것이다. 도커 컨테이너는 자체적으로 모든 문제를 해결할 수 없다. 예를 들면 아래와 같다.

도커는 보안 문제를 해소하지 않는다
컨테이너 안의 소프트웨어는 베어메탈상에서 실행되는 소프트웨어보다 기본적으로 더 안전하다. 그러나 이는 문이 잠긴 집이 문이 잠기지 않은 집보다 더 안전하다는 말과 비슷하다. 동네의 환경, 도둑이 탐낼만한 귀중품의 가시성, 그곳에 사는 사람들의 일과 등의 문제는 전혀 별개이다. 컨테이너는 앱에 보안 계층을 하나 추가한 것일 수 있지만, 단지 앱을 보호하는 일반적 프로그램의 일부로서일 뿐이다.

도커는 애플리케이션을 마법처럼 마이크로서비스로 변환시키지 않는다
앱을 컨테이너에 담으면 이는 자원 소비를 줄이고 전개를 쉽게 한다. 그러나 앱의 설계가 자동으로 변한다거나, 다른 앱과 상호작용하는 방법이 변하지는 않는다. 이 혜택을 누리려면, 모든 것을 컨테이너로 옮기는 명령에 의해서가 아니라, 개발자의 노력과 시간을 거쳐야 한다.
구식의 모놀리틱 또는 SOA 스타일 앱을 컨테이너에 담으면, 이는 그냥 컨테이너에 담긴 구식 앱일 뿐이다. 작업에 더 유용하지도 않고, 어쩌면 덜 유용할 수도 있다.

도커는 가상 머신의 대체물이 아니다
컨테이너에 관해 꾸준히 등장하는 한가지 속설이 있는데 그것은 컨테이너가 VM을 무용지물로 만든다는 이야기다. VM에서 실행되었던 많은 앱이 컨테이너로 이동할 수 있지만, 모든 앱을 그렇게 할 수는 없고 그렇게 되어서도 안 된다. 규제 요건이 까다로운 업종이라면, 예컨대, VM을 컨테이너로 대체할 수 없을 수 있다. 이는 VM이 컨테이너보다 더 많은 격리를 제공하기 때문이다.

도커 컨테이너의 용례
엔터프라이즈 개발 작업은 편협하고 변화에 반응하는데 느린 것으로 악명 높다. 엔터프라이즈 개발자들은 제약에 대해 언제나 불평한다. IT와 비즈니스가 나름대로 제약을 걸고 요구를 하기 때문이다. 도커와 컨테이너는 개발자들에게 이들이 갈망하는 자유를 더 많이 부여하고, 나아가 변화하는 비즈니스 환경에 신속히 대응하는 비즈니스 앱을 여러 방법으로 구축할 수 있게 해준다. ciokr@idg.co.kr
 

※ 본 내용은 한국IDG(주)(http://www.itworld.co.kr)의 저작권 동의에 의해 공유되고 있습니다.
Copyright ⓒITWORLD. 무단전재 및 재배포 금지

[원문출처 : http://www.ciokorea.com/news/39829]