1.
클라우드 환경 개발 플랫폼 및 Docker의 이해
㈜오픈소스컨설팅
2014. 08. 28
최 지 웅(jchoi@osci.kr)

2.
2
- Internal Use Only -
Index
오픈소스 클라우드 개발 플랫폼 - PaaSI
Docker 소개II

3.
3
- Internal Use Only -
모바일 확산
기존의 기업 모델의 변화, 수많은 스타트업의 등장, 린스타트업

4.
4
- Internal Use Only -
트렌드 변화
Mobile
클라우드
소셜
빅데이터
모바일(스마트폰) 에 의한 데이터, 애플케이션, 엔터프라이즈 아키텍처 변화

5.
5
- Internal Use Only -
클라우드 컴퓨팅 환경으로의 변화
1990 20102000
Web ITEnterprise IT Cloud IT
 전용 Network
 Appliance HW
 License SW
 확장성
 Open API
 고집적화
 Open Source SW
 Platform화
 IOPS 예측 가능  IOPS 예측 불가
 교환망/전송망 중심
 IP망(Shared Network)
 내부전용(Silo)
 Service용(외부판매) 구축형, Manual
 Commodity HW
 종량제, 자동화
 Expert only  Everyone
사용환경HW/SWNetwork
 표준화/통합화
 CDN
 소용량 Data  대용량 Data
 System Network 중요App에서 Network 이슈 없음
Data Traffic
210X ↑
 SDN

6.
6
- Internal Use Only -
클라우드 컴퓨팅 서비스
• SaaS : 소프트웨어를 서비스로 제공하며, 사용료 지불 방식에 따라 서비스 비용을 지불, 표준화된
애플리케이션 프로세스 제공 (Salesforce.com, MS Office Live 등)
• PaaS : 애플리케이션 개발과 조합 가능한 플랫폼 제공(SW 개발환경)(Google Apps 등)
• IaaS : 서버, 스토리지, 네트워크 등 인프라 자원을 사용량 기반으로 제공,
기본 스토리지와 컴퓨팅 능력을 제공(CPU, Disk 등)(Amazon EC2, S3 등)
계산자원 가상화 스토리지 가상화 네트워크 가상화애플리케이션
IaaS SaaSPaaS
Software as-a-ServicePlatform as-a-ServiceInfrastructure as-a-Service
Salaesforce, MS Office LiveGoogle App Engine, MS Azure, AWSAmazon EC2/S3, BlueLock
프레임워크, API 제공 애플리케이션 제공

7.
7
- Internal Use Only -
가상화 전환 – 개발/테스트/운영
시스템SW
확장
OS
Multi-App 환경
App App App
OS
x86 서버
아키텍처
App 장애/간섭,
선택/Hang
사용률
Virtualization
가상화 환경
OS
App
OS
App
OS
App
고성능 H/W
단일 OS, 다중 애플리케이션
단일 H/W, OS,
애플리케이션
파티셔닝,
캡슐화, 격리
서버 사용률 개선, 서버 즉시 확장 등의 IT 자원의 효율화
서버 통합을 통한 TCO 절감, 유연성 및 확장성의 제고라는 다양한 효용성 제공
운영체제, 네트워크, 스토리지 등의 다양한 가상화 종류
즉시성 제공 – 새로운 서버 생성에 10분을 넘기지 않음

8.
8
- Internal Use Only -
클라우드 서비스 환경

9.
9
- Internal Use Only -
소프트웨어 개발환경의 변화
1세대 (Language) : OS 위에 컴파일러를 사용한 개발언어 중심으로 어플리케이션을 개발하던 세대. 이때는 개발자의
선택에 따라 모든 것을 정할 수 있었지만, 각각을 setting 해줘야 한다.
2세대(Library) : 공통 라이브러리들을 분리하면서, 라이브러리를 사용한 개발세대로 돌입했다. 개발자들은 자주
사용되는 함수(그래프, UI, 계산)등을 매번 구현할 필요없이 라이브러리를 사용하여 쉽게 개발할 수 있게 되었다. 하지만
개발환경 테스팅 환경이 필요하다.
3세대(Framework) : 공통 라이브러리와 함께 다양한 패턴 등이 발전하며, 공통 개발방식을 찾아내어, 개발을 좀 더
유연하게 효율적으로 할 수 있는 방법들을 찾기 시작했다. 이렇게 만들어진 프레임워크를 통해 DB Access 분리,
Testing, 개발환경 등을 구축할 수 있게 되었다.
4세대(Platform) : 플랫폼으로 발전하면서 개발은 더욱 쉬워졌다. 각 벤더사에서 ALM 및 라이선스까지 관리해주며, App
Store를 사용하여, 활성화 시켰다. 하지만 App은 플랫폼에 의존하게 되었다.
5세대(Cloud) : 클라우드 PaaS의 발전으로 하드웨어까지 통합하여 제공하게 되었다. 하드웨어, DB, WAS등도 선택할
필요가 없어졌다.

10.
10
- Internal Use Only -
플랫폼 개발 환경의 변화
PaaS 환경
1.업무 개발 계획 수립
2.예산 산정
3.코드 개발
4.테스트
5.실행
6. 자동 확장
1.업무 개발 계획 수립
2.예산 산정
3.VM 생성 요청
4.대기
5.framework/appserver 설치
6.테스트 툴 설치
7.테스트 툴 시험
8.코드 개발
9.운영 VM 구성
10.코드 업로드
11.실행
12.요구에 따라 운영VM 추가요청
13.대기
14.새로운 VM에 운영환경 구성
15.기타 작업
가상화 환경
1.업무 개발 계획 수립
2.예산 산정
3.하드웨어 구매 요청
4.대기
5.하드웨어 구매
6.하드웨어 설치
7.OS 설치
8.OS 패치 적용
9.사용자 계정 생성
10.framework/appserver 설치
11.테스트 툴 설치
12.테스트 툴 시험
13.코드 개발
14.운영 서버 구성
15.코드 업로드
16.실행
17.요구에 따라 새로운 서버 구매
18.대기
19.새로운 서버 구성
20.기타 작업
물리적인 환경
기존의 개발환경 시스템 구성에 상당한 시간을 애플리케이션 개발에 집중하는 것이 가능

11.
11
- Internal Use Only -
서비스 관점에서의 클라우드 플랫폼
권한별 사용자를 위한 셀프서비스 포털 제공
출처: DataNet - http://pdf.datanet.co.kr/207/207114.PDF

12.
12
- Internal Use Only -
PaaS(Platform as as Service)
클라우드 공급자에 의해 지원되는 프로그래밍 언어, 라이브러리, 서비스, 툴들 을 이용하여 생성된 애플리케이션이나 인프
라 사용자에 의해 생성된 애플리케이션을 배포할 수 있는 능력(기술).
사용자는 네트워크, 서버, OS 같은 클라우드 인프라스트럭처를 관리하거나 컨트롤하지 않으나 배포 제어 가능.
– NIST -
자료 : NIST’s Cloud Cube Model
특징 설명
확장성
사용자가 언제나 필요한만큼의 리소스를 할당받을 수 있도록 서비
스 제공
서비스 중심
인프라스트럭처 서비스 관점으로 구성한 플랫폼 서비스 카탈로그
형태 제공
셀프
서비스
사용자가 포털을 통해 서비스 카탈로그에서 필요한 리소스를 선택
하고 라이프 사이클 서비스를 제공
자동
프로비저닝
환경
요청된 서비스에 따라 운영체제, 네트워크, 스토리지, 시스템 소프트
웨어까지 자동화된 프로비저닝 제공. 서비스 회수를 위한 디-프로비
저닝 환경
가상화 빠르고 유연한 프로비저닝과 효율성을 위한 가상화 환경 제공
과금 사용량만큼의 과금 정책을 사용

13.
13
- Internal Use Only -
PaaS 특장점
개발환경 접근용이 : 클라우드 기반 환경
개발시간 및 비용 절감 : 개발시스템,S/W 구매/도입/설치 등의 절차 불필요
개발 편이성 : 손쉬운 애플리케이션 설치 자동화
확장성 : 개발자별 사용 패키지 추가 및 배포 용이
개발 환경 및 개발 프레임워크 표준화 용이 : 표준화 버전 적용
소스 코드 관리 용이
배포 편리 : 빌드, 배포툴 기본 제공
개발자단에서의 제어와 배포를 할 수 있는 DevOps 가능
멀티테넌시, 공유, 셀프서비스, 유연성, 자동 프로비저닝, 확장성 등의 기능 제공

14.
14
- Internal Use Only -
PaaS를 통한 DevOps 환경
DevOps는 소프트웨어 개발자들과 IT 종사자들 사이의 의사소통, 협업, 융합
을 강조한 소프트웨어 개발 방법론이며, 소프트웨어 개발과 IT 운영간의
상호 의존관계에 대한 산물이다. DevOps 는 조직에서 소프트웨어 상품과 서비스
를 신속히 생산하는 것에 도움이 되는 것을 목적으로 한다.
- Wikipedia –
Best Practice
자동화된 빌드와 릴리즈
자동화된 인프라스트럭처와 시스템 프로비저닝
DevOps 팀간의 일관된 도구 사용
설정과 같은 코드는 어플리케이션 코드와 분리
공유가 가능한 버전 관리 도구 보유
감사시 릴리스 추적 가능(요구사항에서 운영까지)
모델화된 수명주기

15.
15
- Internal Use Only -
클라우드 환경의 소프트웨어 개발
소프트웨어 라이프사이클 영역의 클라우드 사용률 조사
소프트웨어 운영 환경의 as-a-Service 영역
When asked which cloud-based services they use in software production, the top two
answers were PaaS and IaaS. This is not a surprise based on market perceptions, but it is
surprising that PaaS is being used by 58% of respondents while slightly fewer are using
IaaS (52%).
This shows just how far PaaS has come in the last few years, offering
more choices and flexibility than ever before. Based on these results,
organizations seem to be very interested in the fast development speeds that PaaS can
enable.
출처: Dzone 2014 Cloud Platform Report, 2014.03

16.
16
- Internal Use Only -
PaaS 제공자

17.
17
- Internal Use Only -
PaaS 솔루션 제공자
DotCloud
Java, Ruby, Perl, Python, PHP 등 다양한 언
어, 프레임 워크, DB를 지원하는 PaaS
Heroku
Salesforce.com에서 제공하는 서비스로 Ruby
와 Node.js에 대응한 PaaS. Git 등과 연계하여
자체 애플 리케이션을 배포
Cloud Foundry
vm ware 제공하는 PaaS. Spring (Java),
Rails와 Sinatra (Ruby), Node.js와 Grails와
같은 프레임 워크와 MySQL, Redis,
MongoDB 등의 DB를 지원
Google App Engine
Google의 PaaS. Python과 Java를
지원
Windows Azure
마이크로소프트 PaaS. Windows 환경,
SQL Server와 각종 언어에 대응.
OpenShift
Red Hat에서 제공하는 PaaS. Java,
Python, PHP, Ruby 및 Spring,
Seam, Weld, CDI, Rails, Rack,
Symfony, Zend Framework,
Twisted, Django, Java EE와 같은
프레임워크를 지원

18.
18
- Internal Use Only -
CloudBees
항 목 내 용
특징
운영 환경에서의 애플리케이션 라이프사이클과 구동을 위한 개발, 디플로이 프로세스를 자동화. Jenkins를 사
용하여 개발팀과 DevOps 팀이 지속적 통합을 수행할 수 있는 기반 환경을 제공
장점
• PaaS 전체 라이프사이클 제공
• 지속적 통합을 위한 Jenkins 서비스 제공
• 고사양의 JVM 기반 런타임 운영 환경 제공
• 모바일 및 백엔드 서비스 통합 기능 지원
• APM, DBaaS, SaaS 개발툴과 네트워크를 통한 확장 가능
지원언어 Java, PHP, JavaScript, Groovy, Clojure, Scala
무료영역 5개의 애플리케이션, 월당 300분의 빌드시간
서비스 영역
Application Containers
App Server-as-a-Service
Integration PaaS(ESB-as-a-Service)
Database-as-a-Service
고객사 Netflix, ChooseDigital, Groupe Adeo, Bullhorn Inc., Viridity Energy, Lose It

19.
19
- Internal Use Only -
Stackato
항 목 내 용
특징
Cloud Foundry와 Docker를 지원하는 상용 PaaS 서비스 제공하며, 애플리케이션 미들웨어로써 클라우드 인프
라스트럭처 상에서 수행. 런타임, 웹 프레임워크, 데이터 및 메시징 서비스에 필요한 설정을 자동화 해줌.
관리자는 사용자 권한, 애플리케이션 컴포넌트, 스케일링과 메모리를 웹 인터페이스와 CLI를 통해 제공
장점
• Cloud Foundry, Docker를 포함하는 오픈 소스 기술 구현
• 프라이빗, 퍼블릭, 하이브리드 클라우드 IaaS 환경 지원
• 서비스, 클러스터 노드, 사용자, 모니터링을 제공하는 콘솔 제공
• 무중단 서비스 기능 제공
• 기존의 애플리케이션을 쉽게 마이그레이션 가능
지원언어 Java, Ruby, Python, Perl, PHP, JavaScript, Go, Groovy, Clojure, Scala, HTML/XML, Erlang, Haskell
무료영역 애플리케이션 4GB 메모리 제한
서비스 영역
Routing, Queuing, & Scheduling System
Application Containers
App Server-as-a-Service
Database-as-a-Service
고객사 HP, Mozilla, MTN Communications, ExactTarget, Cisco, Nelnet

20.
20
- Internal Use Only -
Pivotal CF
항 목 내 용
특징
Pivotal CF라는 이름의 Cloud Foundry 기반의 엔터프라이즈 PaaS. 다운타임없이 확장하고 디플로이 가능하도
록 서비스를 제공하며, 빅데이터 프레임워크를 통합한 첫번째 PaaS 서비스
장점
• 프로비저닝과 바인딩된 아파치 하둡 상에 애플리케이션을 구동하는 통합 플랫폼 제공
• 리눅스 상의 모든 프레임워크와 언어를 확장할 수 있는 유연한 런타임 서비스 제공
• Pivotal One 서비스로의 자동화된 프로비저닝과 바인딩 - Pivotal HD, Pivotal RabbitMQ and Pivotal
MySQL
• IaaS와 통합된 PaaS를 제공하고, vSphere 프라이빗 클라우드에 디플로이 가능
지원언어 Java, Ruby, JavaScript, Groovy
무료영역
Pivotal CF: Trial 90일 사용 가능
Pivotal Web Services (run.pivotal.io): Trial 60일 사용 가능
서비스 영역
Routing, Queuing & Scheduling System, Application Containers, App Server-as-a-Service, Database-as-a-
Service
고객사 Warner Music, GE, Verizon

21.
21
- Internal Use Only -
Apache Stratos
항 목 내 용
특징
대표적인 오픈소스 PaaS 솔루션으로 Tomcat 서버, MySQL, PHP 컨테이너 자원을 공유하고 확장하는 서비스
제공. 사용량, 자동화된 리소스 관리, 모니터링, 빌링을 포함하는 컴포넌트 제공하며, IaaS 서비스와 통합 가능
장점
• Cloud-native architecture
• 확장형 카트리지 모델
• Amazon EC2, OpenStack 또는 vCloud에 디플로이 가능
지원언어 Java, PHP
무료영역 오픈 소스
서비스 영역 Routing, Queuing & Scheduling System, Application Containers
고객사 Cisco, Boeing

22.
22
- Internal Use Only -
Google App Engine
항 목 내 용
특징
구글 인프라스트럭처상에 애플리케이션을 디플로이하기 위한 PaaS 솔루션. 자동 스케일링, 로드밸런싱, 스토
리지와 구글 클라우드 서비스와 통합 가능. 개발을 위한 무료 SDK를 제공하며 다양한 언어를 제공
장점
• 스토리지 저장 데이터에 대한 쿼리, 소팅, 트랜잭션 제공
• 자동 스케일링 및 로드 밸런싱 기능 지원
• 요청 범위를 벗어나는 작업을 수행하기 위한 비동기 태스크 큐 서비스 제공
• 특정 시간에 이벤트를 처리하는 스케줄 태스크
• 구글 클라우드 서비스 및 API와 통합 가능
지원언어 Java, Python, PHP, Go
무료영역 무료 애플리케이션의 경우 무료 서비스
서비스 영역 Application Containers, App Server-as-a-Service
고객사 Rovio, Khan Academy, blossom.io, Snapchat

23.
23
- Internal Use Only -
Heroku
항 목 내 용
특징
사용자의 프로젝트에 적합한 기술을 신속하게 반복하고 채택하는 데 필요한 도구를 제공. 개발, 운영 영역에서
인프라스트럭처에 대한 고민없이 클라우드 서비스 제공자에서 제공하는 기능을 그대로 사용할 수 있음
장점
• 100 개 이상의 애드온 서비스를 제공하는 광범위한 라이브러리 제공
• 애플리케이션을 컴파일하기 위한 빌드 팩 모음 제공
• 소스로부터 특정 설정을 분리하고 관리 가능
• 임시 명령을 수행하기 위한 임시 인스턴스 환경 제공
지원언어 Java, Ruby, Python, JavaScript, Clojure, Scala
무료영역 각 애플리케이션당 512M 메모리, 1개의 Postgres DB
서비스 영역
Object Stroage, Routing, Queuing & Scheduling System, Application Containers, App Server-as-a-Service,
Database-as-a-Service, Mobile Backend-as-a-Service (MBaaS)
고객사 Facebook, ASICS, MailChimp, GitHub

24.
24
- Internal Use Only -
오픈소스 클라우드 개발 플랫폼 조사
대부분의 클라우드 사용자들이 IaaS, PaaS 영역의
클라우드 서비스를 활용하여 개발, 테스팅, 디플로이를
수행
CloudFoundary, OpenShift 양대산맥
클라우드를 통한 생산성, 품질 향상이 이루어짐
자체 환경 구축과 클라우드의 차이점은 극명하게 나타남

25.
25
- Internal Use Only -
CLOUD FOUNDRY vs OPENSHIFT
구분 Cloud Foundary OpenShift
아키텍처 작은 단위의 여러 개의 컴포넌트로 구성 2 개의 주요 컴포넌트로 구성
소스 저장구조 하나의 소스 저장 구조로 구성 다수의 소스 저장 구조로 구성
PaaS 설치
• BOSH 툴를 통한 설치
• IaaS 환경 필수적임
• 리눅스/가상머신을 통한 설치
• IaaS 환경이 선택적임
App 설치 컴파일 형태의(WAR) 저장 및 배포 소스코드 형태의 저장 및 배포
로드밸런싱 로드밸런싱 기능(Router) 내장 서비스(HA Proxy)를 통한 로드밸런싱
멀티테넌시 DEA 및 데이터 단위 멀티테넌시 Node 단위 멀티테넌시
확장성 Buildpack을 통한 서비스 확장 Cartridge를 통한 서비스 확장
출처: 오픈소스 PaaS 분석 종합 - 서보국, 2014.07
각 기능 단위의 주요 차이점 요약

26.
26
- Internal Use Only -
CLOUD FOUNDRY vs OPENSHIFT
Health Manager
Messaging(NATS)
Service Broker
DEA(Application Execution)
여러 컴포넌트의 조합
브로커(Broker)
노드(Node)
2개의 큰 단위 컴포넌트로 구성
기능항목으로 비슷하나 내부적인 아키텍처 구현 방법은 상이함

27.
27
- Internal Use Only -
CLOUD FOUNDRY vs OPENSHIFT
출처: 오픈소스 PaaS 분석 종합 - 서보국, 2014.07
구성 컴포넌트의 비교 맵핑

28.
28
- Internal Use Only -
CLOUD FOUNDRY vs OPENSHIFT
웹 애플리케이션 배포 방식의 차이
출처: 오픈소스 PaaS 분석 종합 - 서보국, 2014.07

29.
29
- Internal Use Only -
멀티테넌시 아키텍처
출처: 오픈소스 PaaS 분석 종합 - 서보국, 2014.07
공유 데이터 vs 자체 보유 데이터베이스

30.
30
- Internal Use Only -
PaaS 개발 환경에 대한 선택 조건
기업의 개발 문화, 라이프 사이클
사용의 편의성, 디버깅, 테스트, 확장성, 품질 관리
IaaS-like? SaaS-like?
서비스 vs 소프트웨어
운영환경 vs 개발환경 – 대용량 처리 트랜잭션
보안, 장애에 대한 대응

31.
31
- Internal Use Only -
Index
오픈소스 클라우드 개발 플랫폼 - PaaSI
Docker 소개II

32.
32
- Internal Use Only -
컨테이너 기반 플랫폼
Docker, Containers, and the Future of Application
Delivery

33.
33
- Internal Use Only -
Docker에 대하여
>50,000 pulls
>4,000 github stars
>100 컨트리뷰터
>150 개의 관련 프로젝트
• UIs, mini-PaaS, 원격 데스크탑
1000 개 이상의 docker 적용 애플리케이션
• Memcached, Redis, Node.js…
Jenkins, Travis, Chef, Puppet, Vagrant and
OpenStack과 통합
고객: Ebay, Uber, Mozilla, Cloudflare, and Rackspace,
Google

34.
34
- Internal Use Only -
Docker에 대하여
dotCloud 내부 프로젝트로 시작 (2013.01)
python -> go
docker는 현재 다음 기술들로 구현됨
• LinuX Containers
• Control Groups & Namespaces
• AUFS(ver1. Another Union FS, ver 2. Advanced Multi Layered Unification File System)
docker는 어디서나 실행되는 경량화되고, 이식 가능한 컨테이너로
응용프로그램의 배포를 자동화하는 오픈소스 엔진
docker is an open-source engine that automates the deployment
of any application as a lightweight, portable, self sufficient
container that will run virtually anywhere.

35.
35
- Internal Use Only -
개발, 테스트, QA, 배포
Static website
Web frontend
User DB
Queue Analytics DB
Background workers
API endpoint
nginx 1.5 + modsecurity + openssl + bootstrap 2
postgresql + pgv8 + v8
hadoop + hive + thrift + OpenJDK
Ruby + Rails + sass + Unicorn
Redis + redis-sentinel
Python 3.0 + celery + pyredis + libcurl + ffmpeg +
libopencv + nodejs + phantomjs
Python 2.7 + Flask + pyredis + celery +
psycopg + postgresql-client
Development VM
QA server
Public Cloud
Disaster recovery
Contributor`s laptop
Production Servers
MultiplicityofStacks
Multiplicityofhardw
areenvironments
Production Cluster
Customer Data Center
Doservicesandappsint
eractappropriately?
CanImigratesmooth
lyandquickly?

36.
36
- Internal Use Only -
시스템 개발 구성의 악몽 – N x N Matrix
Static website
Web frontend
Background
workers
User DB
Analytics DB
Queue
Developme
nt VM
QA Server
Single Prod
Server
Onsite
Cluster
Public
Cloud
Contributor’
s laptop
Customer
Servers
? ? ? ? ? ? ?
? ? ? ? ? ? ?
? ? ? ? ? ? ?
? ? ? ? ? ? ?
? ? ? ? ? ? ?
? ? ? ? ? ? ?

37.
37
- Internal Use Only -
1960년대 화물 운송
MultiplicityofGoods
Multipilicityofmethods
fortransporting/storing
DoIworryabout
howgoodsinteract
(e.g.coffeebeans
nexttospices)
CanItransportquickly
andsmoothly
(e.g.fromboattotrain
totruck)

38.
38
- Internal Use Only -
운송 또한 N x N Matrix
? ? ? ? ? ? ?
? ? ? ? ? ? ?
? ? ? ? ? ? ?
? ? ? ? ? ? ?
? ? ? ? ? ? ?
? ? ? ? ? ? ?

39.
39
- Internal Use Only -
화물 운송 해결책MultiplicityofGoods
Multiplicityof
methodsfor
transporting/storing
DoIworryabout
howgoodsinteract
(e.g.coffeebeans
nexttospices)
CanItransport
quicklyandsmoothly
(e.g.fromboatto
traintotruck)
적재, 하적, 운반을 먼 거리까지 효율적
으로 수행하고 여러 곳으로 이동 될 수
있음(배->기차->컨테이너 트럭->목적지)
모든 상품이 적재될 수 있는 표준
컨테이너이며, 최종 목적지까지 봉
인 유지

40.
40
- Internal Use Only -
N x N의 문제 해결

41.
41
- Internal Use Only -
복합 운송 컨테이션 생태계 활성화
90%의 모든 화물에 표준 컨테이너 안에 실려 운송
배에 선적, 하적시 시간과 비용, 도난 및 파손을 크게 줄임
최종 제품의 화물 운송 비용을 감소시킴 (from >25% to <3%) – 글로벌화 가능
5000대의 화물 운송성이 연간 2억개의 컨테이너를 수송 중

42.
42
- Internal Use Only -
코드를 위한 컨테이너 운송 시스템
Static website Web frontendUser DB Queue Analytics DB
Development
VM
QA server Public Cloud Contributor’s
laptop
MultiplicityofStacksMultiplicityofhardw
areenvironments
Production
Cluster
Customer
Data Center
Doservicesandappsi
nteractappropriately?
CanImigratesmooth
lyandquickly
가상화된 모든 하드웨어 플랫폼에서 표
준 기법을 사용하여 운영
모든 애플리케이션을 가볍고 이식
가능한 형태로 캡슐화하여 컨테이
너에 탑재

43.
43
- Internal Use Only -
보다 단순한 개발 운영을 가능케 함
Static website Web frontendUser DB Queue Analytics DB
Development
VM
QA server Public Cloud Contributor’s
laptop
MultiplicityofStacksMultiplicityofhardw
areenvironments
Production
Cluster
Customer
Data Center
Doservicesandappsi
nteractappropriately?
CanImigratesmooth
lyandquickly
운영자: 한 번 설정으로 모든 플랫폼에
적용 가능
개발자: 한 번의 빌드로 다양한 환
경에서 실행

44.
44
- Internal Use Only -
시스템 소프트웨어가 설치된 Live CD?
Live CD, USB를 통한 운영체제 부팅
하지만 운영체제 자체가 RO(Read Only)
메모리에 하나의 운영체제만 로딩, 복수 개의 서버 불가
32 core, 128G 메모리 시스템을 하나의 OS로 처리?

45.
45
- Internal Use Only -
개발 vs 운영 관점
App
A
Bins/
Libs
App
A’
Bins/
Libs
App
B
Bins/
Libs
서버
운영체제
DEVELOPMENT FOCUS
-------------------------------------
APPS, CODE, DEPENDENCIES
(LIBRARIES), DATA, AND
PACKAGING
OPERATIONS FOCUS
---------------------------------
MONITORING, NETWORK
CONFIGURATION, REMOTE
ACCESS, AND LOGGING
Code
Test
Deploy
Monitor

46.
46
- Internal Use Only -
방법1 – 일반적인 개발환경 구성
정의:
• 전통적으로 개발해온 환경
• 필요한 리소스를 계정을 통해 정의하고
시스템을 관리
단점:
• 20년 이상 사용해온 시스템 관리 기법
• 서로 다른 사용자, 관리 부분에 대한
부담감 증가
Reduce#rowsviapolicy

47.
47
- Internal Use Only -
방법2 – 런타임 프로비저닝 환경 구성
Reduce # Columns via Chef/Puppet/etc.
정의:
• Chef/Puppet과 같은 개발/운영환경
구성에 필요한 머신을 런타임시에
프로비저닝
단점:
• Chef/Puppet은 시스템 프로비저닝의
강력한 도구
• 애플리케이션 혹은 소프트웨어 버전
업그레이드시 지속적인 버전 변경작업
필요
• 기업 외부에서 사용하기 어려움(보안)

48.
48
- Internal Use Only -
방법3 – 하드웨어 가상화
정의:
• 각 애플리케이션을 위한 가상 머신을
생성하는 방법
단점:
• 현재 가장 많이 사용하는 방법(서버
통합, 가상화)
• 비용 및 시간이 많이 필요
• 하이퍼바이저 환경에 따른 상이한 가상
머신
• 소프트웨어 버전 변경시 새로 템플릿
구성해야 하는 번거로움(Chef 혼용
가능)

49.
49
- Internal Use Only -
Foreman, PXEBoot, DNS 등
현재 - 가상화 기반 운영 관리 프로세스(1/2)
1
서버 입고 부팅과 함께
OS 설치 및 구성
2
Hypervisor
3 하이퍼바이저 등록
VM Pool
VM Pool
4
VM 기본 템플릿
OS 컨트롤러 리포지토리
패치 관리 컨트롤러
VM
5 가상머신 생성
6 소프트웨어 설치/패치 관리
7 VM 할당 및 사용
복잡한 입고, 시스템 관리, 처리 프로세스를 사용

50.
50
- Internal Use Only -
현재 - 가상화 기반 운영 관리 프로세스(2/2)
Middleware
③ 소프트웨어 분배
⑤ OS deployment
② Compliance 위반 검사
배포서버
Control Server
배포 서버
⑥ Report
스위치
스토리지
조작 지시
상황 표시
① Inventory 수집
④ 패치 분배
⑦ Provisioning
소프트웨어 설치／제거
공개 및 상용 소프트웨어 제어
여러 서버로 에이전트/HTTP 동시 다운
로드
설치 대상 서버 제어
OS이미지를 네트워크 경유로 배포 설
치
에이전트 설치 및 구성정보 수집
OS 설정의 규정 위반 여부 검출
네트워크나 스토리지 장비 등에 대한
다양한 프로비저닝 기능
모든 변경이력・구성정보 등의 표준
report와 custom report
프로비저닝에 대한 자동화 프로세스를 중앙 관리 서버를 기준으로 진행

51.
51
- Internal Use Only -
Like git, github
vagrant@ienvyou:~$
Pulling repository centos
539c0211cd76: Downloading 61.8 MB/98.56 MB (63%)
~/workspace/usergrid-stack-origin:~$ git pull origin master
remote: Counting objects: 291, done.
remote: Compressing objects: 100% (121/121), done.
remote: Total 210 (delta 79), reused 170 (delta 42)
Receiving objects: 100% (210/210), 48.34 KiB, done.
Resolving deltas: 100% (79/79), completed with 38 local
objects.
From github.com:apigee/usergrid-stack
Git처럼 내가 필요한 그리고 업데이트된 항목만 받아볼 수 없을까?

52.
52
- Internal Use Only -
Containers vs VMs
App
A
Hypervisor (Type 2)
Host OS
Server
Guest
OS
Bins/
Libs
App
A’
Guest
OS
Bins/
Libs
App
B
Guest
OS
Bins/
Libs
AppA’
Docker
Host OS
Server
Bins/Libs
AppA
Bins/Libs
AppB
AppB’
AppB’
AppB’
VM
Container
컨테이너가 분리되었지만,
OS를 공유하고 바이너리/
라이브러리를 사용
Guest
OS
Guest
OS

53.
53
- Internal Use Only -
경량화 모델
Bins/
Libs
App
A
Original App
(No OS to take
up space, resources,
or require restart)
AppΔ
Bins/
App
A
Bins/
Libs
App
A’
Guest
OS
Bins/
Libs
Modified App
Union file system allows
us to only save the diffs
Between container A and
container A’VMs
애플리케이션, 소프트웨어 변경시 새로
운 복제 서버(템플릿)를 생성하여 구동/배
포시켜야 함.
App
A
Guest
OS
Bins/
Libs
Copy of
App
No OS. Can
Share bins/libs
App
A
Guest
OS
Guest
OS
VMs Containers

54.
54
- Internal Use Only -
Docker 기본 처리 로직
Source Cod
e Repositor
y
Dockerfile
For
A
Docker Engine
Docker
Container
Image
Registry
Build
Docker
Host 2 OS 2 (Linux)
ContainerA
ContainerB
ContainerC
ContainerA
Push
Search
Pull
Run
Host 1 OS (Linux)

55.
55
- Internal Use Only -
단순한 업데이트
Docker Engine
Docker
Container
Image
Registry
Docker Engine
Push
Update
Bins/
Libs
App
A
AppΔ
Bins/
Base
Container
Image
Host is now running A’’
Container
Mod A’’
AppΔ
Bins/
Bins/
Libs
App
A
Bins/
Bins/
Libs
App
A’’
Host running A wants to upgrade to A’’.
Requests update. Gets only diffs
Container
Mod A’

56.
56
- Internal Use Only -
컨테이너 프로세스에 의한 성능
가상 머신이 아닌 Native를 직접 활용하므로 실제 베어메탈에 가까운 성능을 보임
프로세스들은 고립되어 있지만, host위에서 직접 실행
CPU performance
• native performance ( 거의 차이 없음 )
Memory performance
• a few % shaved off for (optional) accounting
Network performance
• 작은(small)의 오버헤드 발생
항목 방법 호스트 Docker
CPU sysbench 1 0.9931
Memory sysbench
seq
1(r) 0.9999
1(w) 0.9759
sysbench
rnd
1(r) 1.0056
1(w) 0.9807
Disk dd 1 0.9716
Network iperf 1 0.7889
출처: Docker, lightweight linux container, Deview 2013 김영찬

57.
57
- Internal Use Only -
일반적인 빌드/배포
개발 테스트
git
repository
CI
Jenkins
Development
Server
Staging
Server
Production
Server
개발, 스테이징, 운영에 대한 CI를 활용하여 라이프라이클 적용

58.
58
- Internal Use Only -
다양한 빌드/배포 방식
JENKINS
CI
RPM
Repo
DEV Hosts
STG Hosts
PRD Hosts
Version Management Build and Reporting Automated Installation
SVN
(SRC)
Develpoer
PC
SVN
JENKINS
CI
Developer Admin
Verification
SVN
Deploy Request RPM Build
Proceed RPM
REPO
SERVICE
HOSTInstall
Update
Manager
애플리케이션 코드와 운영 환경 소프트웨어에 대한 별도 패키징 및 디플로이

59.
59
- Internal Use Only -
Docker를 활용한 통합 배포
개발 테스트
git
repository
git clone
and
docker build
Development
Server
Staging
Server
Production
Server
Test
Container
Docker
Container
Image
Registry
환경설정을 docker container에 포함하기 때문에 어디서나 동일하게 동작
애플리케이션 코드와 구동 환경을 항상 일치시킴

60.
60
- Internal Use Only -
요약
기존의 개발 방식에서 벗어난 새로운 형태의 개발, 운영 방식 등장함
가상화를 통한 서버 운용성 증대를 위한 노력이 진행됨 - IaaS
개발에 집중할 수 있는 기반 환경을 마련 – PaaS(Platform as a Service)
필요한 요소 기능만을 조립하여 하나의 컨테이너를 생성하고 서비스를 제공 – Docker
VM vs Container
• 별도의 분리된 영역이 아닌 상호 의존 관계
• VM: 하드웨어 리소스의 구성 단위를 할당하는데 가장 유용
• Container: 소프트웨어 전달 단위로서 프로세스로 작동되므로, 매우 가볍고 빠름

61.
61
- Internal Use Only -
참고자료
Introducing DZone's 2014 Cloud Platform Research Report : http://java.dzone.com/articles/introducing-dzones-2014-cloud
Docker , lightweight linux container – Deview 2013, 김영찬
Portable, lightweight, & interoperable Docker containers across Red Hat solutions - Jérôme Petazzoni, Docker, Inc
Docker, Containers, and the Future of Application Delivery – Docker, Inc

62.
62
- Internal Use Only -
OPEN
SHARE
CONTRIBUTE
ADOPT
REUSE