System Compleat.

Hypervisor, Container and docker.io

Techs



(younjin.jeong@gmail.com, 정윤진) 


수 년전에 일했던 회사중에서 아파치를 하나의 리눅스 머신에서 다양한 사용자 권한으로 수행하도록 모듈을 만들고 소스를 수정하여 서비스를 구현했던적이 있다. 기본적으로 단일 서비스 및 단일 기업을 위한 웹 사이트를 구성하는 경우에는 www-user 또는 httpd 와 같이 root 대신 적절한 사용자 레벨의 권한을 부여하여 서비스하는 것이 일반적이지만, 서로 관계가 없는 다양한 사용자들을 하나의 시스템에 수용하고자 하는 경우에는 이야기가 좀 다르다. 





위의 경우에서는 운영체제에서 지원하는 사용자관리 및 이에따른 보안 모델을 제공하며 이는 매우 오래된 역사를 가진 유닉스 System V 모델을 따르는 경우가 많다. 따라서 각 사용자의 프로세스는 구획되고 구분되며, Semaphore, Shared memory, Message pipeline, Named pipe 등의 IPC method 를 통해 서로 데이터를 참조하도록 구성하지 않는 경우라면 참조가 불가능하기 때문에 서로 다른 사용자의 권한으로 동일한 웹 서버 daemon 을 구동하는것은 그에 필요한 오버헤드만큼이나 하나의 시스템에서 높은 보안성을 가지도록 구성 할 수 있다.


새로운 시대는 더 빠른 프로세서에 대한 요구에 부합한 하드웨어들을 양산해 내게 되었으며 이로인해 다양한 OS 와 플랫폼, 그리고 어플리케이션들이 등장하게 되었는데, 이들 중 가장 그 영향력이 큰 부분중 하나는 바로 가상화 기술이다. 가상화라고 하면 보통 하나의 OS 위에 다른 OS 를 추가로 설치할 수 있는 환경으로 이해하는 경우가 많다. 가상화에 대해 조금 더 살펴보자면, 네트워크, 프로세서 및 메모리와 같은 리소스를 관리하여 게스트 OS 들에게 할당하고 인식하게 하는 기술이다. 이는 "하나의 시스템에서 여러개의 운영체제를 구동하고 싶다" 라는 요구에 의해 개발되고 발전해 왔다. 


최근에 거대하게 발전하고 있는 클라우드의 컴퓨팅 관련 서비스들은 가상화 기술을 기반으로 하고 있다. 하드웨어들은 넘쳐 흐르는 충분한 성능을 가지고 있고, 가상화가 가져다 주는 힘은 이제 단일 호스트에서 여러개의 OS 를 구동하는 것 이상으로 파워풀하다. 기존의 하나의 시스템 기반이었던 가상화 기술이 특정 하드웨어의 세트 단위로 클러스터링하거나, 사용자의 가상 리소스들 간의 고립된 네트워크 및 스토리지를 제공하는 별도의 기술이 투여 된 것이 대부분 클라우드 사업자의 컴퓨팅 관련 서비스들이라고 볼 수 있다. 


목적을 되새겨 보면, 결국 필요한 것은 "내가 실행한 어플리케이션이 정상적으로, 또한 높은 보안성으로 구동되면 된다" 라는 간단한 요구사항을 가진다. 이는 처음에 이야기했던 서로 다른 사용자의 아파치 프로세스가 유닉스의 서로 다른 사용자 권한으로 실행할 때의 요구사항과 유사하다. 하나의 시스템에서 동작하지만, 너와 나의 프로세스는 별개이며 관리하는 입장에서도 한명의 사용자 프로세스에 문제가 발생하더라도 전체 아파치의 문제로 전파되지 않기 때문에 운영과 관리측면에서도 매우 유용하다. 



가상화 또는 가상화 된 플랫폼을 기반으로 클라우드 공급자 및 3rd party 사업자들은 컨테이너 서비스를 만들어내기 시작했다. 대표적인 예가 AWS의 Elastic Beanstalk, 또는 Heroku 와 같은 서비스로 볼 수있는데, 바로 개발자들은 소스코드만 가지고 있다면 원하는 환경을 그대로 배포하여 서비스 할 수 있도록 지원하고 있는데, 이러한 서비스를 보통 컨테이너라고 부르는 경우가 많다. 컨테이너가 연상하는 기능이 바로 그렇듯이, 프레임웍이 같다면 규모는 다를지언정 그 구조가 다르지는 않기 때문에 마치 내용물은 다르지만 운반이 간편한 컨테이너와 같은 장점을 서비스에 부여하는 것이 가능하다. 


만약 이를 아파치 뿐만 아니라 다른 모든 다양한 어플리케이션에도 적용하고자 한다면 어떨까.




올 초에 이 오픈소스 프로젝트에 대해 접할 기회가 있어서 몇번 블로그에 소개하고자 했지만 여건이 나지 않았는데, 조금 살펴보니 이미 국내의 일부 블로그 포스팅에서 이를 언급하고 있고 홈페이지도 처음에 비하면 어마무지하게 좋아졌기 때문에 별도로 설치 가이드와 같은 내용을 옮길 필요는 없어 보인다. 

언제나 무언가를 사용하고 테스트 해 보고자 할때 목적이 있어야 하는데, docker.io 가 제공하는 컨테이너에 대해 개인적으로 pros 와 cons 를 나눠보면 아래와 같지 않을까. 

Pros 
- 현재까지 사용되고 있는 Hypervisor 기반의 가상화는 게스트 OS에 물리적 자원을 논리적으로 분할하여 할당하고 OS 위에 OS 를 구동하는 형태로 구성되는것과 달리 docker 는 별도의 구획된 OS가 없기 때문에 훨씬 가볍게 동작한다. 
- 이는 대단위의 클라우드와 유사한 인프라를 구성하는 경우에도 SDN 이나 별도의 네트워크 및 스토리지에 대한 전통적인 OS기반의 무언가가 필요 없기 때문에 목적에만 맞다면 기존 가상화 클러스터대비 높은 비용 효율성을 이룩할 수 있다. 
- 어플리케이션의 개발과 배포를 편리하고도 빠르게 처리 할 수 있다. 

Cons 
- 아직 빡시게 개발중이다. 
- Hypervisor 기반의 클라우드가 그래왔듯 docker 역시 사용자에 대한 구획을 대규모로 분산된 인프라에서 관리 및 구현 할 필요가 있어보인다. 
- 서비스 및 목적에 따라서는 OS 레벨의 Hypervisor 가 필요한 경우가 아직까지는 더 많이 있다. 
- 누군가 이를 PaaS 와 같은 형태의 서비스로 제작하려 한다면, Context switching 및 기타 공유 자원에 대한 부하를 급증시키는 어플리케이션에 대해 서로 다른 성능의 플랫폼으로 이전해 주거나 분산 및 확장해 주는 별도의 구조에 대해 생각 할 필요가 있다.


docker.io 는 AWS의 EC2 환경에서 손쉽게 돌려볼 수도 있다. 
http://docs.docker.io/en/latest/installation/amazon/ 


아래는 docker.io 에서 배포하고있는 슬라이드. 




새로운 무언가를 대할때는 언제나 즐거운 느낌이다. 
이를 배우고 학습하며 테스트하는데 아직 즐거워 할 수 있는 스스로에게 안도감을 느끼게 되는것은 이전보다 젊지 않아서일까. 

무언가를 직접 해 보기 전에 필요한 정보는 언제나 구글에 있다. 다만, 시도 후에 발생하는 문제와 그 해결은 있을수도, 없을수도 있으므로 검색을 먼저 먼저. 


http://docker.io


(younjin.jeong@gmail.com, 정윤진)