블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

Docker란 무엇인가?

개념 잡기

Docker Linux 기반의 Container RunTime 오픈소스이다. 처음 개념을 잡기가 조금 어려운데, Virtual Machine과 상당히 유사한 기능을 가지면서, Virtual Machine보다 훨씬 가벼운 형태로 배포가 가능하다. 정확한 이해를 돕기 위해서, VM Docker Container의 차이를 살펴보자.

아래는 VM 에 대한 컨셉이다. Host OS가 깔리고, 그 위에 Hypervisor (VMWare,KVM,Xen etc)가 깔린 후에, 그위에, Virtual Machine이 만들어진다. Virtual Machine은 일종의 x86 하드웨어를 가상화 한 것이라고 보면된다. 그래서 VM위에 다양한 종류의 Linux, Windows등의 OS를 설치할 수 있다.



DockerContainer 컨셉은 비슷하지만 약간 다르다. Docker VM 처럼 Docker Engine Host위에서 수행된다. 그리고, Container Linux 기반의 OS만 수행이 가능하다.

Docker VM처럼 Hardware를 가상화 해주는 것이 아니라, Guest OS (Container) Isolation해준다.무슨 말인가 하면, Container OS는 기본적으로 Linux OS만 지원하는데, Container 자체에는 Kernel등의 OS 이미지가 들어가 있지 않다. Kernel Host OS를 그대로 사용하되, Host OS Container OS의 다른 부분만 Container 내에 같이 Packing된다. 예를 들어 Host OS Ubuntu version X이고, Container OS CentOS version Y라고 했을때, Container에는 CentOS version Y full image가 들어가 있는 것이 아니라, Ubuntu version X CentOS version Y의 차이가 되는 부분만 패키징이 된다. Container 내에서 명령어를 수행하면 실제로는 Host OS에서 그 명령어가 수행된다. Host OS Process 공간을 공유한다.



실제로 Container에서 App을 수행하고 ps –ef 를 이용하여 process를 보면, “lxc”라는 이름으로 해당 App이 수행됨을 확인할 수 있다. 아래는 docker를 이용해서 container에서 bash 를 수행했을때는 ps 정보이다. lxc 프로세스로 bash 명령어가 수행되었음을 확인할 수 있다.

root      4641   954  0 15:07 pts/1    00:00:00 lxc-start -n 161c56b9284ffbad0477bd04875c4277be976e2032f3ffa35395950ea05f9bd6 -f /var/lib/docker/containers/161c56b9284ffbad0477bd04875c4277be976e2032f3ffa35395950ea05f9bd6/config.lxc -- /.dockerinit -g 172.17.42.1 -e TERM=xterm -e HOME=/ -e PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin -e container=lxc -e HOSTNAME=161c56b9284f -- /bin/bash

LXC (LinuX Container), 자세한 정보는 http://linuxcontainers.org/ 에서 얻을 수 있다.

lxc container를 실행시켜주는 runtime으로, 앞에서 설명한것과 같이 VM과 비슷한 기능을 제공하지만, 실제 수행에 있어서, guest os (container)를 마치 VM처럼 isolate해서 수행해주는 기능을 제공한다.

이와 같이 Docker LXC라는 Linux에 특화된 feature를 사용하기 때문에, 제약 사항을 가지고 있는데, 현재까지 Docker Ubuntu 12.04 이상(Host OS)에서만 사용이 가능하다.

Performance에 대해서는 당연히 Host OS에서 직접 application 을 돌리는 것보다 performance 감소가 있는데, 아래 표와 같이 performance 감소가 매우 적은 것을 볼 수 있다.



출처: http://www.slideshare.net/modestjude/dockerat-deview-2013

Repository 연계

다음으로 Docker의 특징중의 하나는 repository 연계이다.Container Image를 중앙의 Repository에 저장했다가, 다른 환경에서 가져다가 사용할 수 있다. 마치 git와 같은 VCS (Version Control System)과 같은 개념인데, 이를 통해서 Application들을 Container로 패키징해서 다른 환경으로 쉽게 옮길 수 있다는 이야기다.



예를 들어 local pc에서 mysql, apache, tomcat등을 각 컨테이너에 넣어서 개발을 한 후에, 테스트 환경등으로 옮길때, Container repository에 저장했다가 테스트환경에서 pulling(당겨서) 똑같은 테스트환경을 꾸밀 수 있다는 것이다. Container에는 모든 application과 설치 파일, 환경 설정 정보 등이 들어 있기 때문에, 손쉽게 패키징 및 설치가 가능하다는 장점을 가지고 있다.

여기서 고려해야할점은 Docker는 아쉽게도 아직까지 개발중이고, 정식 릴리즈 버전이 아니다. 그래서, 아직까지는 production(운영환경)에 배포를 권장하고 있지 않다. 단 개발환경에서는 모든 개발자가 동일한 개발환경을 사용할 수 있게 할 수 있고, 또한 VM 보다 가볍기 때문에, 개발환경을 세팅하는데 적절하다고 볼 수 있다.

Base Image vs Dockerfile

Docker Container Image packing하기 위해서, Docker Base Image Docker file이라는 두가지 컨셉을 이용한다. 쉽게 설명하면, Base Image는 기본적인 인스톨 이미지, Docker file은 기본적인 인스톨 이미지와 그 위에 추가로 설치되는 스크립트를 정의한다.

예를 들어 Base Image Ubuntu OS 이미지라면, Docker FileUbuntu OS + Apache, MySQL을 인스톨하는 스크립트라고 보면 된다. 일반적으로 Docker Base Image는 기본 OS 인스톨 이미지라고 보면 된다. 만약에 직접 Base Image를 만들고 싶으면  http://docs.docker.io/en/latest/use/baseimages/ 를 참고하면 된다. docker에서는 미리 prebuilt in image들을 제공하는데, https://index.docker.io/ 를 보면 public repository를 통해서 제공되는 이미지들을 확인할 수 있다. 아직까지는 Ubuntu 많이 공식적으로 제공되고, 일반 contributor들이 배포한 centos 등의 이미지들을 검색할 수 있다. (2013.10.22 현재 redhat 등의 이미지는 없다.)

아래는 docker file 샘플이다. (출처 : http://docs.docker.io/en/latest/use/builder/)

# Nginx

#

# VERSION               0.0.1

 

FROM      ubuntu

MAINTAINER Guillaume J. Charmes <guillaume@dotcloud.com>

 

# make sure the package repository is up to date

RUN echo "deb http://archive.ubuntu.com/ubuntu precise main universe" > /etc/apt/sources.list

RUN apt-get update

 

RUN apt-get install -y inotify-tools nginx apache2 openssh-server

위의 이미지는 Ubuntu OS 베이스 이미지에 apt-get을 이용해서, inotify-tools nginx apache2 openssh-serverf 를 인스톨하는 스크립트이다.

Docker 실행해보기

그럼 간단하게 docker를 테스트해보자, 윈도우즈 환경을 가정한다. 앞서 말한바와 같이 Docker Unbuntu 위에서만 작동한다. (참고 : http://docs.docker.io/en/latest/installation/windows/)

그래서, 윈도우즈 위에서 Ubuntu VM을 설치한후, Ubuntu VM에서 Docker를 실행할 것이다. 이를 위해서 VM을 수행하기 위한 환경을 설치한다.

l  Hypervisor Virtual Box를 설치한다. https://www.virtualbox.org 

l  VM을 실행하기 위한 vagrant를 설치한다. http://www.vagrantup.com 

l  Docker 코드를 다운받기 위해서 git 클라이언트를 설치한다. http://git-scm.com/downloads 

여기까지 설치했으면, docker를 실행하기 위한 준비가 되었다.

다음 명령어를 수행해서, docker 코드를 git hub에서 다운로드 받은 후에, vagrant를 이용해서 Ubuntu host os를 구동한다.

git clone https://github.com/dotcloud/docker.git

cd docker

vagrant up

Virtual Box를 확인해보면, Docker Host OS가 될 Ubuntu OS가 기동되었음을 확인할 수 있다.



그러면, 기동된 Ubuntu OS SSH를 이용해서 log in을 해보자. Putty를 이용해서 127.0.0.1:2222 포트로, SSH를 통해서 로그인한다. (기본 id,passwd vagrant/vagrant 이다.)

이제 Docker를 이용해서, public repository에서 “busybox”라는 Ubuntu OS Container로 설치하고, Container에서 “echo hello world” 명령어를 수행해보자

sudo su

docker run busybox echo hello world

Docker public repository에서 busybox image를 다운로드 받아서 설치하고, 아래와 같이 명령어를 수행했음을 확인할 수 있다.



※ 참고 : 현재 docker에 설치된 이미지 리스트 docker images, 설치된 이미지를 삭제할려면 docker rmi {image id}. {image id} docker images에서 hexa로 나온 id를 사용하면 된다.


Remote Fx 드디어 WAN 지원

드디어 Remote Fx가 WAN환경을 지원합니다.
강력한 기능에도 불구하고, 네트워크 사용량이 문제였는데 Windows 8에서 지원하네요.

주요 기능을 발췌합니다.


http://uksbsguy.com/blogs/doverton/archive/2012/03/01/windows-server-8-remote-desktop-and-vdi-enhancements.aspx

The goal of the RemoteFX for WAN feature of Windows Server "8" Beta is to deliver a great user experience beyond the corporate network, whether the user is in a branch office, on a wireless device, or working from home over a WAN connection.

RemoteFX for WAN combines the RemoteFX Adaptive Graphics feature with new intelligent WAN aware transports. Both TCP and UDP protocols can now be used and will be chosen automatically, as well as automatic detection of network conditions to tune the encoding of content to the network.

RemoteFX Adaptive Graphics

RemoteFX in Windows Server "8" Beta dynamically adapts to changing network conditions and optimizes encoding based on the content being delivered. Windows Server "8" Beta RemoteFX adaptive graphics now uses multiple codecs that are optimized for the type of content being delivered. Using a typical web page as an example, the text, images, and video content are all encoded using codecs that are optimized for each type of content.

RemoteFX Media Remoting

Media consumption is becoming an integral part of the end user experience. Ranging from consuming Corporate training media content, lightweight content creation and authoring, to creating demos, and marketing materials. Media is also a part of online collaboration (Live meeting, conference calls etc) and recreational media consumption.

In Windows 7, efficient redirection of multimedia content was introduced. When a user attempts to play multimedia content through Windows Media Player in a remote session the content to be played back is intercepted. The intercepted content is then redirected to the client. The RDP client receives the compressed content, decodes the content and plays them back locally. This gives a very near to local experience to the end-user as the content is rendered on the client using client resources.

At the core of the RemoteFX Media Remoting feature is the integration of network detect, graphics profiles, and RemoteFX scenarios to enable a great media consumption experience over RDP. From an end user perspective there is no difference in experience between local playback and media playback over a remote session.

===========

요약해보자면


TCP/UDP를 사용하여 네트워크 상황에 맞는 Codec으로 인코딩하여 화면을 전송합니다. 화면내에 이미지,텍스트등에 대해서 각각의 특성에 맞게 인코딩해서 보낸다는 이야기 입니다.


Media Remoting도 추가 되었는데, 예를 들어 가상 데스크탑에서 동영상을 play 했을때, 기존에는 가상 데스크탑 화면에서 동영상을 decoding해서 play한 후, 그 화면을 Remote Fx에 캡취해서 네트워크로 전송하는 방식이었는데, 이번 버전에서는 가상 데스크탑에서는 play하지 않고 동영상을 클라이언트로 보내서 클라이언트 CPU를 이용하여 decoding 및 play를 하기 때문에 서버 자원을 줄일 수 있습니다.

 

GPU 가상화가 제대로 되는 VDI 솔루션은 현재 Remote Fx가 유일한데, 한번 테스트 해보고 싶네요.

 

 


Remote Fx는 Windows Server 2008 R2 SP1부터 포함되는 VDI 기술중 하나로 RDP 7.1에 포함되어서, Remote Desktop Session에 대해서 3D GPU 가상화, 고속 화면 전송을 지원한다.

쉽게 설명하면 RDP 클라이언트에서 스타크래프트2나 동영상을 끊김없이 볼 수 있다는 이야기

그런데 문제점이 아직 Release 는 되지 않았지만 현재 베타 버전에서는 Remote Fx를 사용하기 위해서는 GPU 카드가 필수적으로 필요하며 한 사용자당 약 256MB의 비디오 메모리를 필요로 한다.
PCIe 슬롯이 서버에 있다하더라도, 사용자수에 비해서 비디오 카드를 꼽을 수 있는 수량이 얼마 없기 때문에 구성이 어려운데, 이를 극복하려면, PCI 확장이 필요하다 DELL에서 나오는 장비중 하나가 Cx410 장비로 16개의 비디오 카드를 꼽을 수 있다.

하드웨어 구성을 구상해보면 다음과 같다.

PCIe Expansion 서버에는 총 16개의 비디오 카드를 꼽을 수 있고, 비디오 카드는 최상의 경우 M2070Q의 경우 카드당 6GB의 메모리를 가지고 있다. 즉 총 96GB의 비디오 메모리를 가질 수 있고 한 사용자당 256MB를 할당하면 약 370명의 사용자를 박스당 커버할 수 있다.

서버의 경우 RP810 서버는 AMD 12 코어 CPU 4개를 꼽을 수 있고 메모리는 최대 512GB를 꼽을 수 있기 때문에 사용자당 2GB 메모리를 할당하고, 사용자당 0.5 core를 할당한다고 가정하면
48 코어 * 2 = 96 명으로 박스당 96명을 커버할 수 있다.

즉 약 3대의 RP810서버와 C410x 서버 1대면 약 300명 이상의 동시 사용자에게 Remote Fx 기반의 서비스를 제공할 수 있다.

테스트해본 결과, Remote Fx의 3D 게임등의 고화질 화면을 전송할때는 20 Mbps 의 대역폭, 일반 워드나 인터넷의 경우 1Mbps의 대역폭이 필요한데, 서버당 96명의 대역폭을 동시 제공하려면 96명 * 20Mbps = 2000 Mbps = 2Gbps가 필요하기 때문에 1Gbps NIC 두장씩만 꼽히면 가능하다는 계산이 나온다.

현재 나온 기술로는 위와 같은 구성으로 가능한데... 결국은 가격이 문제... 아마도 PC 300대를 사는 것(300대 * 80만원 = 2억4천만원) 보다 비싸지 않을까?

DB VM에 올릴 때 첫번째로 고려할 사항은 수직적 확장성이다. 수평적인 확장성은 DBMS 자체가 제공하는 클러스터 기능을 이용해야 한다. (MS SQL의 경우 수평 확장 불가, ORACLE의 경우 RAC를 이용하여 수평확장 가능). 만약에 DBMS 자체 클러스터링에 대한 확장이 불가능하다면 애플리케이션 단에서 Database Sharding등을 이용하여 확장을 하는 안을 고려할 수 있다.

수직적 확장의 경우 현재까지 Hyper-V가 최대 CPU 4 코어까지만 지원하기 때문에, 더 이상의 용량이 필요한 경우 분리된 Physical Machine을 사용하는 방법을 사용해야 한다.

 

DBMS VM에 올릴 경우 가상화에 대한 Cost로 인하여 성능이 떨어지는데, 그 중에서 성능에 가장 큰 영향을 미치는 것이 Disk에 대한 부분이다. DB VM에 배포할 때 Disk에 대해서 아래와 같이 3가지 옵션을 선택할 수 있다.

       Dynamic Size VHD : 가상 디스크의 사이즈를 동적으로 지정하여 Runtime에서 변경되도록 하는 옵션

       Fixed Size VHD : 가상 디스크의 사이즈를 정해놓고, 공유하는 방안

       Pass-through Disk : 물리적인 디스크를 직접 VM에 마운트 하는 방안

 

먼저 Fixed Size VHD Pass-through Disk (이하 PTD)의 성능 차이를 보면

 

Random IO의 경우 Read/Write 모두 큰 차이는 없고 Sequential Write 부분에서 Fixed Size Disk 가 성능이 떨어지는 것을 볼 수 있다.

일반적인 OLTP성의 트렌젝션 처리 성능을 비교해보면


 1.       Baseline: a native Windows Server 2008 environment with Hyper-V role disabled. The virtual network switch is not turned off.

2.       Root partition: a root partition in Windows Server 2008 with Hyper-V enabled.

3.       VM_PT: a guest virtual machine configured with pass-through disks, four logical processors, and 14 GB RAM.

4.       VM_VHD: guest virtual machine configured with fixed-VHD disks, four logical processors, and 14 GB RAM.

5.       Overhead is calculated by comparing with Baseline ((Baseline Batches/CPU – VM Batches/CPU)/ Baseline Batches/CPU)

위의 테스트 결과와 같이 전혀 가상화를 하지 않은 상태 (Baseline) 대비 PTD를 사용했을 때와 Fixed Size VHD의 성능을 비교하면 10~20% 정도의 차이가 나는 것을 볼 수 있고, Fixed Size VHD PTD사이의 차이는 소량의 트렌젝션에서는 PHD가 약간 우세를 나타내며, 대량의 트렌젝션에서는 큰 차이가 없는 것으로 나타난다.


다음 자료는 하나의 MS SQL 인스턴스가 독립된 PTD를 사용하고, 다른 하나는 Fixed Size VHD를 사용하는데, 해당 디스크 볼륨이 다른 VM과 공유되는 상황에 대한 비교이다.

위의 표에서와 같이 Dramatic한 성능 차이는 나지 않는다.

 

결론적으로 PTD Fixed Size VHD 사이의 성능 차이는 미미하기 때문에 성능 최적화 측면에서는 PTD를 공간 활용면에서는 Fixed Size VHD를 사용한다.

 가상화에 올린 DB Physical 서버에 직접 올린 DBMS강의 성능 차이는 약 10~20% (가상화로 인한 오버헤드)정도로 판단하고 디자인에 참고해야 하며, 가상화에 올릴 시에는 최대 4개의 코어 까지만 지원하기 때문에 4 코어 이상의 성능이 필요한 경우 가상화 환경이 아닌 분리된 DBMS 하드웨어를 사용해야 한다.

(분석 리포트 출처: http://www.microsoft.com/hosting/dynamicdatacenter/Resources.html#SQLServer_)


Windows Server에서 가상화를 이용해서 Windows 7을 Hosted OS로 구동 시키고 거기서 스타크래프2를 테스트한 화면입니다.

서버는 Windows Server 2008 R2 SP1 베타 빌드를 사용했으며, AMD 쿼드코어 CPU * 4, ATI FirePro 880 그래픽 카드를 이용했습니다.

아래는 구형 HP 노트북에서 윈도우즈 서버의 윈도우7 VM에 접속해서 스타2를 테스트한 시연 화면입니다.


아래는 ThinLinx사의 Remote Fx를 지원하는 Thin Client 시제품으로 테스트한 결과입니다.



PC에서 했을때는 그럭저럭 만족할만한 성능을 보여줬습니다만, 고사용 데스크탑에서 직접 게임을 하는 것보다는 다소 프레임등이 넘어가는 것이 부드럽지 않습니다. Thin Client는 아직 시제품 단계라서 화면 해상도도 깨지고 성능도 PC보다 다소 떨어지더군요.

이번 테스트 버전이 6월 베타 빌드인데, Remote Fx 부분이 최적화가 더 된다고 하니, 그때 되면 조금 더 높은 성능을 기대해봅니다.


사실 가상화 자체는 나온지 오래된 기술이다. 세삼스럽게 이런 구닥다리 기술이 작년에 이어 올해에도 계속 주목 받는 이유는 무엇일까?

몇가지 원인을 꼽을 수 있는데,

    그린 IT의 필요성

    클라우드의 발전

    기술의 현실성

그린 IT는 이산화탄소 배출양을 줄이기 위해서 전기 사용량을 줄인다는 개념을 포함하는데 더욱 쉽게 말하면 서버 운영에 들어가는 비용을 줄이겠다는 것이다. 보통 데이타 센터의 서버는 평상시 CPU 사용률이 30~40%정도 밖에 안된다. 나머지는 잘못된 용량 산정이나 Peak Time에 대한 대비이다. 가상화를 사용하면 하드웨어 자원을 유동적으로 배정해서 이 자원의 사용률을 80~90%까지 극대화 할 수 있어서 하드웨어 자원에 대한 비용을 절약할 수 있고, 전기료와 하드웨어를 설치할 공간에 대한 비용을 절약할 수 있다. 또한 가상화 서버에 가상 시스템들이 이미지 형태로 배포되기 때문에, 애플리케이션의 배포와 백업등에 상당한 융통성을 발휘할 수 있다

아울러 구글과 아마존 그리고 막차를 타고 있는 MS가 주도하고 있는 클라우드 환경은, 이런 가상화 환경과 밀접한 관계를 가지면서, (클라우드는 가상화 솔루션을 이용해서 구축하기가 매우 용이하다. 실제로 아마존과 MS는 이러한 가상화 기술 기반으로 E2C, Azure 서비스를 제공하고 있다. ) 작년부터 서비스를 오픈하고 있다. 이로 인해서 자주 가상화 기술이 언급되고 운영에 대한 신뢰성을 간접적으로 경험할 수 있으며, 이것이 트렌드를 주도하고 있다

예전의 경우 가상화는 VOOware들이 하드웨어를 에뮬레이션해서 PC나 서버에서 새로운 서버를 띄울 수 있게 해줬지만 성능이 거의 최악 수준이었다. 그러나 요즘은 Paravirtualization같이 하나의 하드웨어 리소스를 가상 서버들이 중간 Layer에서 거의 Burden없이 나눠서 사용하는 방식으로 (Multiplexing하는 방식)으로 사용하기 때문에, 가상화 Layer로 인한 Burden이 거의 없고 성능 감소가 적기 때문에, (Paravirtualization 방식의 오픈소스 가상화 솔루션인 Xen의 경우 10%내의 성능 감소만 있다고 합니다. 실제 해보지는 못했지만..) 운영 환경에서도 사용하는 것이 상당히 현실성이 있어졌다. 실제로 호주의 경우 가상화 플랫폼을 많이 사용하고 있다. 국내의 경우 Citrix,Vmware등의 벤더가 주도하고 있지만, 개인적으로는 Xen기반의 오픈소스나, Redhat의 가상화 솔루션들이 좀더 선방을 해줬으면 하는데.. 사실 이런 기술들을 의사 결정을 할 수 있는 실무진들이 얼마나 따라와 줄 수 있을지 (벤더에 기대서 먹구사는 정치세력들..)가 걱정이다. 그 만한 Risk를 지고 도전을 하면 비용을 줄이고 혁신을 할 수 있는데.. 어짜피 자기회사 아니니까는 안전빵으로 벤더에게 맏길 가능성이 더 높지 않을까

다행이도 근래에는 SXX 통신사등 큰 기업들이 오픈소스 도입을 적극적으로 추친하고 있으며 일부에서는 가상화 솔루션을 도입하고 있어서 좋은 사례가 되지 않을까 싶다. (그런데 이런거 하시는 분들은 블로그나 인터넷에 자료좀 공개해주셨으면 좋겠습니다.) 

안타깝게도 해외에는 Xen이나 기타 가상화 기술에 대한 서적이 많이 출판되어 있는데, 국내에는 번역서 조차 희귀한 상황이 가상화에 대한 국내 관심도를 보여주고 있는것 같아서 씁쓸한 마음이 있다. 실무진분들 가상화에 관심좀 기울여 주세요. (제가 가상화 제품 파는것 아니니까는 영업활동으로 생각하지 마시고..)