Docker를 활용한 서비스 배포

스마트스터디에서의 사용사례

유은총

Software Engineer

@materialistic42

DISCLAMER

• Best practice는 아닙니다.

– 오히려 시행착오기에 더 가깝습니다.

스마트스터디

• 무엇을 하는 회사인가?

• “교육용 김성모 게임을 만듭니다.”

다양한 컨텐츠 사업을 합니다

• 유아용 교육 앱

• 애니메이션

• 만화

• 게임

• 기타 등등

• 수백여 개 이상의 모바일 앱을 배포

지금까지는

• 평범하게 IDC에 입주시킨 서버 사용

• 평범하게 Amazon CloudFront 사용

• 정적인 컨텐츠를 주로 다루는 모바일 앱들

• 대다수의 앱들이 공통으로 사용하는 기반 서비스

– 클라이언트 로깅, 애플리케이션 메타데이터 배포, 동영상 컨텐츠 배포, 이미지 파일

제공,

서비스간 접근 허가, 푸시 알림 발송, 관리 콘솔, 기타 등등……

• 규모에 비해 애플리케이션 서버의 수요가 적었음

• 기반 서비스를 서비스 지향 아키텍쳐로 개편

– 관리해야 할 서비스의 숫자가 늘어남

• 사업 분야를 넓히면서, 점차 별도의 서버 로직이 필요한 앱이 늘어나게 됨

– 특히 게임

• 글로벌 서비스를 하게 됨에 따라 한국 이외의 지역에도 서버를 둘 필요가 생김

• 많은 모바일 앱만큼이나, 많은 서버 애플리케이션을 운영하게 됨

• 이미 CloudFront를 쓰고 있었으므로, 나머지 서비스 스택도 AWS로 올리기로 함

기존의 배포

• 대부분의 서비스는 파이썬으로 작성됨

• 소스 코드를 git으로 업데이트

• Python Package Index(PyPI)로부터 필요한 라이브러리를 업데이트

• 함정: setuptools와 PyPI의 구조적 헛점

– 패키지 매니페스트가 setup.py라는 실행 가능한 파이썬 스크립트

– 의존성이나 업데이트 여부 같은 것만 확인하려 해도 패키지 전체를 다운로드받음

– 배포하는 데에 한세월

개선책 (?)

• 배포 서버에서 virtualenv 사용, 필요한 라이브러리를 업데이트

• virtualenv 폴더 째로 rsync

• 함정: virtualenv는 본디 portable하지 않음

– 본래는 여러 파이썬 버전과 라이브러리간 충돌을 피하기 위한 물건

– 배포 서버와 대상 서버의 OS 배포판 버전부터 서비스 디렉토리까지 동일하게 맞춰야

했음

– OS 업데이트를 진행하기 매우 곤란

희망사항

• 기존보다 배포가 느리지 않았으면 좋겠음

• 롤백이 용이했으면 좋겠음

• 꼭 Python으로만 서비스를 작성하라고 강제하지 않았으면 좋겠음

• IDC 쪽에도 적용할 수 있는 배포 방법이라면 좋겠음

평범하게 EC2로 서비스를 배포하는 과정

1. AMI 빌드용 EC2 인스턴스를 생성

2. 빌드용 인스턴스에 애플리케이션 코드 업로드

3. 애플리케이션에 필요한 라이브러리 패키지를 설치

4. 빌드용 인스턴스로부터 AMI 생성

5. 빌드용 인스턴스를 제거하고, 새 AMI로 서비스용 인스턴스를 다수 생성

6. 새 인스턴스로 기존 인스턴스들을 교체

대책 1:

• 라이브러리를 미리 받아서 AMI로 만들어 두기

• 서비스가 많음

• 서비스 별로 사용하는 패키지도 제각각임

대책 2:

• 인하우스 PyPI 미러 운용

– 잘 안 됨

• 희망사항: 꼭 Python으로만 서비스를 작성하라고 강제하지 않았으면 좋겠음

대책 3:

“An open platform for distributed applications

for developers and sysadmins.”

Docker

어떤 서비스든지 Docker 이미지로 만들 수 있음

Static website Web application

Background worker

Database Message Queue

어떤 머신이든지 Docker 이미지를 받아서 띄우면 똑같이 돌아감

Developer’s PC

Test server EC2 instances

Production cluster

Contributor’s PC

Developer’s PC

Test server EC2 instances

Production cluster

Contributor’s PC

Static website

Web application

Background worker

Database

Message Queue

가상 머신하고 다른 게 뭐죠…?

• 가상 머신

– 몇십 MiB 남짓한 애플리케이션에

십여 GiB 남짓한 게스트 OS가

딸려옴

– 가상화 오버헤드 → 성능 저하

• Docker 컨테이너

– 호스트 OS의 커널을 공유

– 몇백 MiB 수준의 기반 환경

오버헤드

– 네이티브에 근접한 수준의 성능

App A App B

Bins/Libs Bins/Libs

Docker Engine

Host OS

Server

App A App B

Bins/Libs Bins/Libs

Guest OS Guest OS

Hypervisor

Host OS

Server

가상 머신 Docker

유용한 특징

• 레이어링되는 파일시스템

– 기반 OS가 담긴 레이어부터 시작해서 한층 한층 파일시스템의 diff가 쌓이는 구조

– 한번 이미지로 만들어진 레이어는 읽기 전용이 됨

– 공통되는 레이어는 여러 이미지가 공유할 수 있음

– 배포 이미지 크기를 줄이는 데에 유용

그래서 이걸 왜 굳이 EC2에서 쓰죠?

• 로컬에서 Docker 이미지 빌드 가능

• 로컬에서 Docker 이미지 실행 가능

– 테스트에 이득이 되길 기대

• EC2 이외의 환경에서도 Docker 이미지 빌드/실행 가능

– IDC 재활용?

– CI 서버와 연동?

희망사항

• 기존보다 배포가 느리지 않았으면 좋겠음

• 롤백이 용이했으면 좋겠음

• 꼭 Python으로만 서비스를 작성하라고 강제하지 않았으면 좋겠음

• IDC 쪽에도 적용할 수 있는 배포 방법이라면 좋겠음

좋아 보임

• 이때는 아직 Docker 0.6이었지만

• LXC의 성숙도를 믿고 모험을 걸어 보기로 함

※ http://www.lgtm.in/i/i9qq7djRp

Docker를 사용한 배포 전략

1. 로컬에서 Docker 이미지를 빌드

2. Docker 이미지를 레지스트리에 밀어올림(push)

3. 서비스용 인스턴스에서 새 이미지를 당겨옴(pull)

4. 기존 서비스 컨테이너를 종료하고 새 이미지로 새 서비스 컨테이너를 실행

배포

developer

docker image

Docker Registry

EC2 instance contents

Docker engine

함정

• Docker 이미지는 파일이 아님

– 이미지 배포는 Docker Hub나 Docker 레지스트리에 의존함

– 다행히 docker-registry 소스코드를 받아 사내 레지스트리를 운용할 수 있었음

• Docker 이미지 push/pull이 생각처럼 빠르지 않음

• 초기에는 레지스트리가 불안정하여 push/pull 도중 실패하는 경우가 잦았음

함정 (2)

• Docker 컨테이너는 가상 머신이 아님

– 완전한 OS 환경이 아닌, 하나의 프로세스를 위한 격리 구역

– 컨테이너의 실행 주기 ≈ 프로세스의 실행 주기

• 디버깅하기 난해

docker build -t image . → docker run -i -t --name app image → FAIL

→ docker build …… → docker kill app → docker rm app → docker run …… → FAIL

→ docker build …… → docker rm –f app → docker run …… → FAIL

→ docker build …… → docker rm –f app → docker run …… → FAIL

→ docker build …… → docker rm –f app → docker (이하 생략)

가장 큰 함정

• Docker는 리눅스 커널의 control group 기능에 의존함

• 즉, 리눅스 전용.

• Mac OS X이나 윈도에서는 boot2docker 등으로 리눅스 가상 머신을 띄워서

사용해야 함

• 스마트스터디 프로그래머의 대부분은 맥 사용자, 혹은 아주 드물게 윈도 사용자.

• 결국 그냥 빌드 서버 하나 마련해서 거기서 배포하게 됨

유용한 특징 (2)

• 컨테이너 연결

– 컨테이너끼리 파일시스템이나 네트워크 포트를 서로 연결할 수 있음

– 작은 서비스 컨테이너들을 연결하여 복잡한 서비스를 만드는 것이 가능함

$ docker run [……] \

--link=app:upstream \

--volumes-from=app \

smartstudy/nginx

nginx

# Dockerfile

EXPOSE 80

VOLUME ["/conf/nginx”]

app

아키텍쳐

virtual private cloud

ELB Internet gateway

developer

web instances RDS standby (Multi-AZ)

users

bastion

Elastic IP

Amazon Route 53

Availability Zone

Availability Zone

web instances RDS

아키텍쳐

ELB RDS

EC2 instance contents

Docker engine

EC2 instance contents

Docker engine

Nginx container Application container

Nginx container Application container

안티패턴

• 한 Docker 컨테이너 안에서 여러 프로세스를 띄우지 않는 것이 좋음

– 특히 sshd

• Docker에서 애플리케이션의 최소 단위: 컨테이너

• 컨테이너는 가상 머신이 아님 (2)

– 영속적이 아닌 일시적인 것

– 손으로 관리할 대상이 아닌 일괄적으로 배포하는 단위

하지만 디버깅할 때는?

• docker logs

– 컨테이너의 표준 출력을 열람

• docker cp

– 컨테이너 안의 파일을 호스트로 복사

• docker exec

– Deus ex machina

– 컨테이너 안에서 임의의 프로세스를 실행 (ex: /bin/bash)

– Docker 1.3 이후부터 지원

안티패턴 (2)

• 한 EC2 인스턴스에 여러 Docker 컨테이너를 올리는 일은 하지 않는 편이 좋음

• 고정 비용이 들어가는 전통적 서버나 호스팅이라면 일리가 있음

• 하지만 EC2는 서버 자원 사용량에 상관 없이 무조건 인스턴스당 사용 시간으로

과금

• 일부러 여러 서비스를 올리려고 비싼 인스턴스를 할당받아 요금을 낭비할 이유가

없음

– 각 서비스별로 오토 스케일링 구성을 맞추고,

Docker는 building block으로만 활용하는 편이 나음

• 단, reserved instance를 쓰고 있다면 한번 생각해 볼 문제

CoreOS

• Docker 기반으로 서비스를 운영한다면, 호스트 OS는 거의 Docker만 돌리는 셔틀이

됨

• 그렇다면 아예 Docker만 돌리는 데에 최적화된 OS는 없을까?

• https://coreos.com/

• 타 리눅스 배포판 대비 40% 적은 OS 메모리 점유율

• 원자적 시스템 업데이트

• etcd, fleet 기본 포함

CoreOS + etcd + fleet

• etcd

– “A highly-available key value store for shared configuration and service discovery.”

• fleet

– “Distributed init system”

– etcd, systemd 기반

• CoreOS만으로 손쉬운 클러스터 구성이 가능

• AWS 위에서도 유효할지는 조금 의문

대안

• Amazon Beanstalk + Docker

– 웹 서비스라면 최적

• Docker를 사용한 PaaS/IaaS 솔루션들

– Deis, Stampede, Kubernetes, Flynn, ……

– 범용 솔루션

– AWS의 장점을 살리지 못할 수도

Reference

• What is Docker? — Docker official website

– https://docker.com/whatisdocker/

• Docker introduction

– http://www.slideshare.net/dotCloud/docker-intro-november

• 아키텍처 다이어그램에 사용하는 AWS 심플 아이콘 — AWS 아키텍처 센터

– http://aws.amazon.com/ko/architecture/icons/

• Performance Characteristics of Traditional VMs vs Docker Containers

• http://www.slideshare.net/dotCloud/performance-characteristics-of-traditional-v-ms-vs-docker-containers

• Using CoreOS • https://coreos.com/using-coreos/

함께 해요!

www.smartstudy.co.kr/withyou/