Embedded Files
< 클라우드 스터디 잼 을 위한 정리 >
작성자 : 최형욱 (광주과학기술원)
< 참조 >
[2] http://www.mantech.co.kr/container_orchestration/
※ 클라우드를 하나도 몰라서 스터디 시작전에 공부 할 겸 정리한 문서입니다. 저 처럼 하나도 모르시는 입문자를 위한 자료.
※ 아래 첨부파일에 PDF 버전 있습니다.
*** Docker ***
도커는 2013년 3월 산타클라라에서 열린 Pycon Conference에서 dotCloud의 창업자인 Solomon Hykes가 The future of Linux Containers 라는 세션을 발표하면서 처음 세상에 알려졌습니다.
도커는 컨테이너 기반의 오픈소스 가상화 플랫폼
- real container : 배에 싣는 수송용 박스로써 옷, 전자기기, 술, 과일등의 화물을 넣고 규굑화 시켜서 다양한 운송수단으로 옮긴다.
- server container : 비슷한데 다양한 프로그램, 실행환경을 컨테이너로 추상화하여 프로그램의 배포 및 관리를 단순하게 해줌. 또한 backand program, data sever 등 어떤 프로그램도 컨테이너로 추상화 할수 있고 PC, AWS, Google cloud 등 어디서든 샐행 할 수 있게 해준다. 즉, 애플리케이션을 가볍게 가상화하는 방법이라 보면 된다.
(그래서 뭐 설치할때 docker 써서 하는 애들은 docker 통해서 내 pc에서 프로그램을 실행 가능하도록 한 개념이였구만...)
컨테이너를 가장 잘 사용하고 있는 기업은 구글인데 2014년 발표 에 따르면 구글은 모든 서비스들이 컨테이너로 동작하고 매주 20억 개의 컨테이너를 구동 한다고 합니다.
Container는 격리된 공간에서 프로세스가 동작하는 기술이다. 가상화 기술의 하나지만 기존 방식과는 차이가 있다. 우리가 아는 가상화 방식은 VMware, VirtualBox 같은 것들이 있는데 이러한 기존 방식은 OS를 가상화 하였다. (난 Window 10에서 리눅스 소스코드를 돌려야 되는 경우에 사용하였다....이유는 듀얼 부팅을 할경우 껏다켰다가 매우 번거로워서)
이러한 방식은 host OS 위에 guest OS 전체를 가상화하여 사용하는 방식이다. 사용 방법은 간단하지만 무겁고 매우 느리다.
이런 문제를 해결하기위해서 HVM을 이용한 Kernel-based Virtual Machine 과 반가상화(Paravirtualization)방식의 Xen 이 등장한다. guest OS가 필요하지만 전체 OS를 사용하는게 아니라 일부만 사용하므로 좀 더 낫다. 이 기술들은 AWS나 Racksapce 같은 클라우드 서비스에서 가상 컴퓨팅 기술의 기반이 된다.
그런데!
전가상화든 반만쓰는 반가상화든 어쨋든 추가적인 OS를 설치해서 하는 방법들은 성능에 문제가 있었다. 그래서 이를 해결하려고 프로세스를 격리하는 방식이 등장한다!
리눅스에서는 리눅스 컨테이너 라고도 불리며 단순히 프로세스를 격리 하므로 가볍고 빠르다. CPU나 메모리는 딱 필요한 만큼만 추가로 쓰고 성능 손실도 거의 없다. 즉, 컨테
이너 서버는 운영체제 레벨에서 CPU, RAM, Disk, Network 등의 자원을 격리하여 container에 할당하기 때문에 guest OS가 따로 필요없다.
하나의 server에 여러개의 container를 실행하면 서로 영향도 안주고 독립적으로 실행되서 마치 가벼운 virtual machine을 사용하는 느낌을 준다. 그리고 container에 접속해서 명령어를 입력하기도 하고 사용자도 추가하며 여러개의 프로세스를 백그라운드로 실행 할 수도 있다. CPU나 메모리 사용량을 제한 하는것도 가능하고 host를 특정 port와 연결하거나 host의 특정 디렉토리를 내부 디렉토리 처럼 사용 가능하다.
*** Container 특징 ***
1) 효율성
기업환경에서는 안정적인 운영을 위해, 1개의 가상머신(VM, Virtual Machine)에 1개의 서비스를 구동하는 것이 권장됩니다. 이의 경우 가상머신의 모든 자원을 사용하는 것이 아니기 때문에 성능적 오버헤드가 발생합니다. 반면 컨테이너의 경우, OS 커널을 공유하기 때문에 자원을 필요한 만큼 효율적으로 사용할 수 있습니다.
2) 신속성
사용자의 서비스 요청량이 증가함에 따라, 기업에서는 가상머신이나 컨테이너를 추가적으로 배포합니다. 가상머신의 크기는 최소 몇 GB이지만, 컨테이너의 경우 Guest OS가 없어 MB단위의 크기를 가집니다. 결과적으로 가상머신은 배포하는데 수 분에서 수십 분의 시간이 소요되지만, 컨테이너는 배포에 소요되는 시간이 수 초에 불과합니다.
3) 라이센스 비용 절감
가상화 서버의 경우 가상머신의 개수만큼 Guest OS의 라이센스 비용이 발생합니다. 반면에 컨테이너 서버의 경우 Host OS 1대의 라이센스 비용만 발생합니다. 만약 서버의 수가 많아진다면 비용의 차이도 기하급수적으로 증가할 것입니다.
4) 안정성
가상머신의 경우 정확히 할당된 자원 내에서 가상머신이 운영되기 때문에, 컨테이너에 비해 안정적으로 운영할 수 있습니다. 반면에 컨테이너들은 OS 커널을 공유하기 때문에, 하나의 컨테이너가 무리하게 자원을 사용하게 될 수 있습니다. 자원 할당량을 사전에 지정시켜줄 수 있지만, 만약 이런 상황이 발생하면 컨테이너에 장애가 발생합니다. 이런 컨테이너의 문제는 쿠버네티스로 해결할 수 있습니다.
**** 이미지(Image) ****
- 이미지 : '컨테이너 실행에 필요한 파일과 설정값등을 포함하고 있는 것' 으로 상태값을 가지지 않고 변하지 않습니다.(Immutable).
Container는 image를 실행한 상태라 볼 수 있고 추가되거나 변경되는 값은 container에 저장된다.
같은 image에서 여러개의 container를 만들 수 있고 container의 상태가 바뀌거나 container가 삭제되더라도 image는 변하지 않고 그대로 남아있습니다. (container가 box 개념이면 image는 무역회사라고 보면 되는듯)
예를 들면 ubuntu 이미지는 ubuntu를 실행하기 위한 모든 파일을 가지고 있고 MySQL 이미지는 debian을 기반으로 MySQL을 실행하는데 필요한 실행명령어, 포트정보 등을 가지고 있다. Gitlab 이미지의 경우에는 centos를 기반으로 ruby, go, database, redis등을 가지고 있다.
설명한거 같이 image는 container를 실행하기 위한 모~~~~~~든 정보를 다 가지고 있기 때문에 더이상 의존성 파일을 추가로 컴파일하고 이것저것 설치할 필요가 없다.
새로운 서버가 추가되면 미리 만들어 둔 image를 다운 받고 container만 생성하면 된다. 한개 sever에 여러개의 container 생성이 가능하고, server도 수백, 수천대의 server도 문제없다.
Docker image는 Docker hub에 등록하거나 Docker Registry 저장소를 직접 만들어서 관리 할 수 있다. 현재 공개된 도커 이미지는 50만개가 넘고 Docker hub의 이미지 다운로드 수는 80억회에 이릅니다. 누구나 쉽게 이미지를 만들고 배포할 수 있습니다.
*** 도커가 왜 핫하냐? ***
docker image는 container를 실행하기 위한 모든 정보를 가지고 있어서 용량이 겁나 크다. image를 처음 받을땐 부담이 안되지만 수백메가의 파일을 계속 다시 받는다면 비효율적일것이다.
Docker는 이런걸 해결하려고 Layer라는 개념을 도입했다. image는 여러개의 읽기전용(read only) 레이어로 구성되고 파일이 추가되거나 수정되면 새로운 레이어가 생성되는 개념이다.
예를 들어서, ubuntu 이미지가 A + B + C의 집합이라면, ubuntu 이미지를 베이스로 만든 nginx 이미지는 A + B + C + nginx가 됩니다. webapp 이미지를 nginx 이미지 기반으로 만들었다면 예상대로 A + B + C + nginx + source 레이어로 구성됩니다. webapp 소스를 수정하면 A, B, C, nginx 레이어를 제외한 새로운 source(v2) 레이어만 다운받으면 되기 때문에 굉장히 효율적으로 이미지를 관리할 수 있다.
Container를 생성할때도 같은 방식을 사용하는데 기존의 레이어 위에 읽기/쓰기 레이어를 추가한다. image 레이어를 그대로 사용하면서 실행하는 중에 만들어지는 파일이나 변경되는 내용은 읽기/쓰기 레이어에 저장되므로 여러개의 container를 생성해도 최소한의 용량만 사용해서 업데이트가 가능하다. (가상화 특성상 image 용량이 크고 여러대 server에서 배포하는걸 감안하면 엄청나게 효율적인 방식)
image는 URL 방식으로 관리하며 태그를 붙일 수 있다. 예를들어, ubuntu 14.04 이미지는 docker.io/library/ubuntu:14.04 또는 docker.io/library/ubuntu:trusty 이고 docker.io/library는 생략가능하여 ubuntu:14.04 로 사용할 수 있습니다.
도커 이미지의 용량은 보통 수백메가로 수기가가 넘는 경우도 흔합니다. 이렇게 큰 용량의 이미지를 서버에 저장하고 관리하는 것은 쉽지 않은데 도커는 Docker hub를 통해 공개 이미지를 무료로 관리해 줍니다.
*** Image 와 Container 로 해결 되는 것 ***
- 개발 환경 이전(옮김) 에 대한 해결
- 주로 애플리케이션을 개발할 때는 개인 환경에서 개발을 하고, 통합 환경에서 코드를 통합합니다. 그 다음 테스트 환경을 거쳐 실제 운영 환경으로 이전하게 됩니다.
- 이렇게 수차례 환경을 이전하다 보면 소프트웨어의 버전이나 서버 설정의 차이로 인해 다양한 장애가 발생하기도 합니다. 이때, 컨테이너에 애플리케이션과 애플리케이션을 구동하는 환경을 그대로 담아서 환경을 이전하면, 장애 걱정 없이 신속하고 안정적으로 환경을 이전할 수 있습니다.
- 마이크로 서비스화 (Micro Serviece)
- 기업에서는 애플리케이션을 배포할 때 오랜 시간이 소요되거나, 작은 부분을 수정했을 뿐인데 애플리케이션 전체에 문제가 발생하는 것을 경험합니다.
- 이는 애플리케이션이 거대한 덩어리처럼 구성되어있기 때문인데, 이런 애플리케이션을 기능별로 나누어 변경과 조합이 가능하게 한 것을 마이크로 서비스(Micro Service)라고 합니다. 마이크로 서비스를 컨테이너로 구성하면 애플리케이션을 기능 혹은 서비스 단위로 신속하게 배포할 수 있습니다. 또한, 컨테이너는 독립적인 구조이기 때문에, 하나의 변경 사항이 다른 기능들에 영향을 미치지 않습니다.
*** 쿠버네티스 ****
Container를 배포, 정리, 관리를 하는 것을 흔히 컨테이너 오케스트레이션(Container Orchestration) 이라고 불립니다. 컨테이너 오케스트레이션 도구 중에서 널리 사용되는 도구가 쿠버네티스이다.
원래 구글에서 개발된 오픈소스 컨테이너 관리자 이다.
발표 이후 거의 모든 클라우드 플랫폼에 이식이 되었다. 현재, 쿠버네티스 리눅스 재단의 클라우드 네이티브 컴퓨팅 재단(Cloud Native Computing Foundation: CNCF)이 주관하고 있습니다. 또한, 레드햇 오픈시프트(Red Hat OpenShift), Canonical Distribution of Kubernetes, 코어OS 테크토닉(Tectonic) 그리고 인텔과 미란티스를 포함한 수많은 기업의 쿠버네티스 배포판이 존재합니다.
쿠버네티스는 자동으로 문제를 해결하는 데 뛰어납니다. 그렇지만, 너무나 뛰어난 나머지 컨테이너가 장애를 일으켜도 너무 빨리 재가동되어 사용자가 컨테이너가 장애가 있었음을 알아차리지 못합니다. 이 문제를 해소하기 위해, 사용자는 중앙 집중형 로그기록 시스템을 추가할 필요가 있습니다.
Google Sites
Report abuse