DockerBasedOpen Platform for BigData and Mobile Cloud

Docker Based Open Platformfor Big Data and Mobile Cloud

Prof. 허의남 PhD.Director of Real-time mobile cloud research center

Kyung Hee University

배경: Computing Paradigm

2

v차별성 Mainframe vs Cloud

ü Mainframe : finite computing power§ dummy terminals as user

interface devices

ü Cloud computing: almost infinite power and capacity

üPowerful PCs with local computing power and caching

배경: 비즈니스 패러다임

차세대 빅데이터 이슈

실시간 빅데이터 이슈

• TIBCO : 실시간 빅데이터의 가치, 2초 먼저 아는 기업이 승리한다[1]

– Vivek Ranadivé (Chairman, Founder & CEO of TIBCO)

• “단 몇 시간, 몇 분 또는 몇 초라도 먼저, 올바른 정보의 일부라도 파악하는 것이 6개월이 지난 후 이미 모든 사람 들

이 알고 있는 정보를 전부 파악하는 것보다 훨씬 더 값진 결과를 얻을 수 있을 것이다. 이것이 바로 2초의 경쟁력

(Two-second advantage)이다.”

– 비즈니스 분석은 다이나믹하고 트랜드를 방영해줄 수 있는 이벤트 기반 분석이 수행 되어야 함

– 발생하는 이벤트 자체가 워낙 다양하고 종류가 많기 때문에 고속의 대용량 처리가 필요함

• 실시간 빅데이터 분석

– 실시간 Visualization / 전달– 실시간 수집 기술 (IoT) – Data in Motion 상에서 고속처리 및 분석

5

[1] TIBCO, “Real-Time Bigdata_TIBCO”, IDG Summary, March 2014.[2] Mike Gualtieri and Rowan Curran, “The Forrester Wave™: Big Data Streaming Analytics Platforms, Q3 2014”, July 17, 2014

모바일 클라우드 개요

• 모바일에서 제약 받는 서비스의 공급• 성능 및 클라우드 접근 용이성 (mDC)• 모바일 콘텐츠/서비스의 이중화

실시간 모바일 클라우드 플랫폼

8

• IoT & Wearable Devices 시대

- 유저의 행동 기반 Always Perform- 다양한 단말 센서 등과 연계된 서비스 (dynamic, adaptive techniques)- Light 한 서비스들 또는 조합의 자유로운 이동성 제공- 서비스 특성에 맞는 VM 조합 (관리) 등이 중요한 쟁점- 실시간 지원을 위한 클라우드 플랫폼의 필요성이 대두됨

Always there Always on Always perform

실시간 클라우드 플랫폼

• 서버시장

10

가상머신증가로서버관리비용증가하여컴퓨팅자원의효율적인관리가중요해짐

현재클라우드이슈

<출처: IDC 2012>

11

2014.08.20 클라우드관련오픈소스에대한인기도를조사. <출처: 리눅스재단>

클라우드 오픈소스프로젝트 동향

• 오픈소스클라우드프로젝트들중에서도오픈스택다음으로‘도커’에대한연구가 활발하게진행되고있음

• 기존 가상화 환경

– 하이퍼바이저, 가상머신을 위한

운영체제를모두 설치

– 일부어플리케이션들은 플랫폼을

거쳐야하는 처리과정으로

성능이상대적으로 저하됨

• 도커

– 도커엔진을 기반으로

실행환경이포함된 다수의

컨테이너를독립적으로 구축 및

실행가능

– 기존가상화에비해자원을덜

필요로하고, 성능도개선

12

가상환경 VS 도커 환경

App A

Bin/Lib

Guest OS

App A

Bin/Lib

13 <출처 : Docker blog>

서버관리가용이해지고 가벼운 OS 제공으로관리비용이저렴한도커에대한관심이증가하고있음. MS도다음제품에출시.

확산 전망

도커 개요

14

Python→go(구글개발언어)

DotCloud내부프로젝트로시작(2013.01)

Docker주요기술1. 리눅스 컨테이너2. Control Groups & Namespace3. AUFS (Another Union File System

Docker는거의어디에서나실행되는경량, 이식가능하고, 컨테이너

응용프로그램의배포를자동화하는오픈소스엔진

Docker는거의어디에서나실행되는경량, 이식가능하고, 컨테이너

응용프로그램의배포를자동화하는오픈소스엔진

15

LXC

프로세스격리

AUFS

계층화된저장장치

Docker Index

이미지공유

• Docker v0.1

도커 개요

16

AUFS

Libcontainer

DockerHub

프로세스격리 계층화된저장장치 이미지공유

LXC

Device Mapper

PrivateRegistry

Third Party Repository

BTRFS(B-tree file

system)

Boot2Docker

• Docker v1.1.2

도커 개요

다양한환경

17

도커 개요

• 가상머신 vs 컨테이너특징및성능

가상머신

도커

18

도커 개요

Docker

LXC

AUFScgroup namespace

chroot ….

• 도커 = LXC + AUFS

• 도커 = 리눅스컨테이터기능 + 배포및쉬운확장

• 도커는리눅스 컨테이너가 개선된 환경

LXC• Cgroup

- 워크로드가 필요로 하는 컴퓨팅과 메모리, 디스크 I/O를 정의

• Namespace- 각각의 워크로드를 구분하고 격리

AUFS– 컨테이너 배포를 위한 읽기전용 기능– 컨테이너 공유를 위한 쓰기전용 기능

à격리된공간을제공하고자원을관리할수있게함.

도커 개요

19<출처 : Docker blog>

• 도커 작동 구조

• 이미지

– 필요한 프로그램과 라이브러리, 소스를 포함한 이미지 파일 생성

– 이미지를 저장소에 Up/Download 가능

• 컨테이너

– 해당이미지를실행할수있는공간

– 한 이미지로 동일한 복수의 컨테이너 생성 가능

– 이미지 = 실행파일, 컨테이너 = 프로세스

20

도커 개요

Docker 이미지와 컨테이너

Ship Manual deployment

Automated deployment

Boot

Bare Metal Days Hours Minutes Minutes

Virtualization Minutes Minutes Seconds Less thanminutes

LightweightVirtualization

seconds Minutes Seconds Seconds

21

도커 개요

• 왜도커인가?• 가벼운가상화솔루션을제시

– 호스트의 운영체제는 공유해 필요한 최소한의 리소스만 할당 받아 동작

– 가상머신에 대비 도커는 짧은 시간에 어플리케이션 실행

– 물리적 서버의 자원 할당(10배 차이)

• 10-100 virtual machines

• 100-1000 containers

à 가상화기능은물론가상화대비높은성능

à더가볍고, 더빠른가상화환경을제공

22

도커 개요

• 해외동향

<출처: Goolecloudplatfrom.blogspot.kr>

항목 구글과도커

특징 • 컨테이너 동작에 필요한자원 할당과 데이터 소스에대한 공유를 수행

장점 • Docker구동에 최적화된아키텍처

항목 MS azure과도커

특징 • 윈도우 서버 컨테이너 기술을 제공

장점 • 소프트웨어 애플리케이션을 더 쉽게생성

23

도커 개요

<출처: 레드햇>

항목 레드햇과도커

특징 • Openshift 에 서 쓰 는애플리케이션 배포 툴 ‘기어D’를함께 활용

장점 • Red Hat Enterprise Linux에 컨테이너 형 가상화로 가벼운 호스트OS를 개발

• 해외동향

항목 오픈스택과도커

특징 • Havana 버전에 도입

장점 • 오픈스택 내에서 기존 VM대비 구동시간감소

<출처: 오픈스택>

VM vs Docker 성능평가 보고(IBM Data)

• IBM 실험 내용– OpenStack Controller(Libvirt 기반)에 의한 가상머신 환경

(KVM)과 컨테이너 환경(Docker) 성능 비교 평가

Retrieved from ‘Passive Benchmarking with docker LXC, KVM & OpenStack’, IBM

KVM with OpenStack Docker with OpenStack

24


• 실험환경

25Retrieved from ‘Passive Benchmarking with docker LXC, KVM & OpenStack’, IBM


실험 1 : Boot VM

•이미지를 통한

가상 머신 부팅

•ACTIVE state에

도달까지 대기

•15회 반복

•가상 머신 삭제

실험 2 : Reboot VM



•ACTIVE state에

도달까지 대기

•Soft reboot 5회

반복


•전체 과정 5회

반복

실험 3 : Snapshot



•ACTIVE state에

도달까지 대기

•glance로 스냅샷

생성




• Reboot Test(1차)

– Reboot 과정 처리는

마이그레이션시 발생

하는 다운타임과 비슷

함

– 재부팅에 docker는 6

초, VM 은 2분이 소요

(18.9배 향상)

– 가상 머신(컨테이너)을

Reboot 하는 행위가

서비스 제공에 끼치는

영향이 적음



• Delete Test(1차)

– 삭제 시, KVM 보다 오

히려 속도가 저하하는

문제점 발생

– 기존 코드에, 이미지

종료 시 일정시간 대

기하는 부분이 있었음

– 따라서, 항상 Stop시

일정 시간 아무 동작

도 일어나지 않는 경

우 발생

– 소스 수정 실험 결과…



• Reboot Test(2차)

– 재부팅에 2.5초가

소요 됨으로써 이

전 실험 결과의

1/3로 줄어 듦

– 가상 머신(컨테이

너)을 Reboot 하는

행위가 서비스 제

공에 끼치는 영향

이 적음 → 매우

적음



• CPU 사용률

– Docker: 1~2%

사용률 변화 폭

유지

– KVM: 1~7%

사용률 변화 폭

유지

• Docker는 MDC(Micro

Data Center)환경에

더욱적합할것이라

예상0123456789

10

110

420

731

041

351

661

972

282

592

810

3111

3412

3713

4014

4315

4616

4917

5218

5519

5820

6121

6422

6723

7024

7325

7626

7927

8228

8529

8830

91

CPU

Usa

ge In

Per

cent

Time(s)

KVM: Compute Node CPU

usr

sys

0123456789

10

1 9 17 25 33 41 49 57 65 73 81 89 97 105

113

121

129

137

145

153

161

169

177

185

193

201

209

217

225

233

241

CPU

Usa

ge In

Per

cent

Time(s)

Docker: Compute Node CPU

usr

sys



• 재부팅시메모리

변화량(Δm)

– Docker: 평균

57MB

– KVM: 평균

467MB

• 재부팅시많은자원

예약을요구하지않음

0.00E+00

5.00E+08

1.00E+09

1.50E+09

2.00E+09

2.50E+091 10 19 28 37 46 55 64 73 82 91 100

109

118

127

136

145

154

163

172

181

190

199

208

217

226

235

Mem

ory

Use

d

Time

Docker: Compute Node Used Memory

Memory

0.00E+00

5.00E+08

1.00E+09

1.50E+09

2.00E+09

2.50E+09

111

923

735

547

359

170

982

794

510

6311

8112

9914

1715

3516

5317

7118

8920

0721

2522

4323

6124

7925

9727

1528

3329

5130

69

Mem

ory

Use

d

Time

KVM: Compute Node Used Memory

Memory



0

1

2

3

4

5

6

7

1 5 9 13 17 21 25 29 33 37 41 45 49 53 57 61 65 69 73 77 81 85 89 93 97 101

105

109

113

CPU

Usa

ge In

Per

cent

Time

KVM: Compute Node CPU

usr

sys

0

0.5

1

1.5

2

2.5

3

3.5

1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51 53 55 57 59 61 63 65 67

CPU

Usa

ge In

Per

cent

Time

Docker: Compute Node CPU

usr

sys

• CPU 사용률

• Docker: 최대 3%,

특정 지점에서만

연산 수행

• KVM: 최대 6%

다발적인 연산

수행 발생

• 마이그레이션 과정에

포함 되는 스냅 샷

연산 처리에 강함



1.64E+091.66E+091.68E+09

1.7E+091.72E+091.74E+091.76E+091.78E+09

1.8E+091.82E+091.84E+091.86E+09

1 6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 91 96 101

106

111

Mem

ory

Use

d

Time

KVM: Compute Node Used Memory

Memory

1.83E+091.84E+091.85E+091.86E+091.87E+091.88E+091.89E+09

1.9E+091.91E+091.92E+091.93E+09

1 4 7 10 13 16 19 22 25 28 31 34 37 40 43 46 49 52 55 58 61 64 67

Mem

ory

Use

d

Time

Docker: Compute Node Used Memory

Memory

• 스냅샷 생성 중

메모리

변화량(Δm)

– Docker: 평균

48MB

– KVM: 평균

114MB

• 스냅 샷 생성시 많은

메모리 공간 할당을

필요로 하지 않음


• 실험환경(자체 Test)

– Ubuntuü12.04 64bit

üKernel Linux 3.8.0.42-generic

– Hardwareü메모리 : 2.0GB

üProcessor : Intel Xeon CPU 3.10GHZ*2

34

Physical machine

Linux(Ubuntu)

Qemu-kvm

가상머신

Physical machine

Linux(Ubuntu)

docker

컨테이너

VM환경

Container환경

VM vs Docker 성능평가 보고(자체)

• 응답시간

– CPUü 소수(prime number)를이용한연산으로 CPU 성능측정

ü --cpu-max-prime=20000

– File I/Oü 디스크에 대한 sequential, random I/O 성능 측정

ü --file-total-size=1G

• CPU 사용량

• 메모리 사용량

35

VM및 Container에 대한 자원 및 성능 비교를 위한 실험


성능측정 방법 VM 컨테이너

CPU sysbench 1(32.3270s) 0.965(31.196s)

File I/O sysbench 1(40.09s) 0.989(39.649s)

CPU 사용률 top 7.5% 0.5%

메모리 사용률 top 32% 0.1%

Swap 사용률 top 0% 0%

36

VM/Container 성능 측정


37

단위:ms

0

1000000

2000000

3000000

4000000

5000000

6000000

7000000

8000000

CPU(VM) CPU(도커)

user

0

1000

2000

3000

4000

5000

6000

7000

8000

CPU(VM) CPU(도커)

nice

0

5000000

10000000

15000000

20000000

25000000

30000000

CPU(VM) CPU(도커)

iowait

0

1000

2000

3000

4000

5000

6000

7000

8000

CPU(VM) CPU(도커)

nice


평가지표

• 시간 측정– Reboot– Snapshot– Delete– Execution time

• User• Nice

– iowait

• 자원 측정– CPU 사용률– Memory 변화량

38

preparation downtime resume

Pre-copy Dirty memory 전송 CPU, dirty memory reschedule

Post-copy - CPU, 가상device state paging

마이그레이션 성능

39

Pre-copy

Post-copy

Live Migration 과정 비교

40

0

5

10

15

20

페이지 전송량 다운타임 전체 마이그레이션

시간

오버헤드

참

조

횟수

Metrics

* 실시간마이그레이션관련논문 16개의 Metrics 별통계[1~16]

• Downtime(마이그레이션 동안 VM이 정지해 있는 시간)

= Stop and Copy + Commitment + Activation

• Total migration time

= Initialization + Reservation + Iterative pre-copy + Stop and Copy +

Commitment + Activation

• Amount of migrated data

• Migration overhead

VM 마이그레이션 성능(자체)

Docker 마이그레이션 성능 평가

• 현재 Docker는 Live migration 기능을 제공하지 않음• 기존 Docker 기술과 추가 연구를 통해 성능 평가 수

행 예정

41

preparation Suspend and copy Image transfer resume

downtimeresume

도커에서 VM과 동일한 독립적 자원 할당

• Docker: Underlying Technology– ‘Docker’는 기존 LXC의 기능을 강화시킨

Wrapper

– LXC• Kernel namespace: ‘컨테이너’라고

부르는 독립된 워크스페이스를 제공해주는 기술

• Cgroups: 운용중인 어플리케이션에 대해독립된 자원 환경을 할당

• Chroots: 리눅스 다중 사용자 환경• 기존의 커널기능과 보안 환경 포함

– UnionFS• 기존에 비해 경량화 되고 빠른 통합 파일

시스템 환경 제공

– 향후 BSD Jails, Solaris Zones등 타플랫폼에 대한 컨테이너 환경도 지원예정

DockerDocker

LXC: Linux ContainerLXC: Linux Container

Kernel namespacesKernel namespaces

Apparmor and SELinux profilesApparmor and SELinux profiles

Seccomp policesSeccomp policesChrootsChroots

Kernel capabilitiesKernel capabilities

CGroupsCGroups

UnionFS: Union File SystemUnionFS: Union File System

AUFSAUFS vfsvfs btrfsbtrfs Device MapperDevice Mapper

42

• Cgroups를 통한 독립된 자원 할당 기법 소개

• cgroups의 역할

• LXC의 구성 요소이며, 자원의 할당/관리/모니터링을 담당 함

• 계층적 구조, 할당된 그룹 별로 우선순위가존재

• 타 작업과의 자원 분할/공유를 가능토록 하는 프로세스들의 집합체

43


• cgroup 개념도

44


• cgroups의 역할(cont)

• CPU, memory, I/O bandwidth의 사용량 제어 (허용/금지/대역폭 설

정)

• 그룹간의 상대적 우선순위를 부여 가능

• 그룹 별 자원 사용량 측정 가능

• 그룹의 파일, 프로세스, 네트워크를 다른 그룹으로부터 독립 가능

• 체크포인트를 만들어 그룹을 동결(freeze)시킬 수 있음

– 기존 VM 제공 기능인 일시정지-복귀와 같은 과정

• RedHat 계열 Linux는 ‘systemctl’ 명령어를 통해 cgroups 제어

45


• cgroups 하위 요소

• blkio : I/O operation 제어 및 보고

• cpu : CPU 자원 접근 제어

• cpuacct : CPU 자원 사용량 보고

• cpuset : CPU core와 memory node 접근 제어

• devices : 시스템 장치 접근 제어

• freezer : cgroups 작업의 suspend / resume 제어

• memory : memory 자원 접근 제어와 사용량 보고

• net_cls : 네트워크 트래픽 제어

46


• cgroups 요소: devices

– allow : 디바이스 접근 허가– deny : 디바이스 접근 거부– list : 접근이 허용된 디바이스 목록– device 장치 표현 법

• [Type] [major_num]:[minor_num] [Mode]• Type : a for any, b for block, c for character)

– Mode : read/write

예) b 8:1 rw → user can read and write to block device8:1

47


결론

• Big Data & Mobile Cloud 서비스의 실시간 지원 기본요구 사항

• 이동성 및 경량 단말(IoT) 과의 실시간 연결• 기존의 VM 또는 Openstack 의 Heavy 의 문제점 분명

히 존재• Docker (Container) 기반의 Cloud 환경 제공이 추세• 국외 기업의 빠른 움직임 현실화• 국내 기술 격차 최소화 및 기여 부분 많음• 도커 기반의 Cloud 시스템 빠른 도입 및 테스트 환경

구축 시급

DockerBasedOpen Platform for BigData and Mobile Cloud

Documents

Transcript of DockerBasedOpen Platform for BigData and Mobile Cloud