mesos와 docker 기반 엘라스틱파티셔닝 paas · mesos와 docker 기반...

Mesos와 Docker 기반 엘라스틱파티셔닝 PaaS 구현

OpenCloudEngine

패스트캣 CTO 송상욱

[email protected]

Agenda

• Docker

• Mesos

• Garuda

• Billing

• Metering

• Billing/metering구현

• 패턴분석

Docker

• 오픈소스 컨테이너 – 여러개의 App을 단일 호스트에서 구동하기 위한 개념

– chroot와 가상화의 중간정도의 개념

– 가상화와 비슷하지만, Guest 운영체제가 필요없는 가벼운 대안제시.

– 이식성 - 가상머신, 클라우드, PC 어디서든 실행가능.

• Immutable Infrastructure 구현 – 한 번 설정한 운영 환경은 변경하지 않는다

– 호스트 OS와 운영환경 분리

– 운영환경만 이미지화하여 재사용

가상화

Docker

https://www.docker.com/whatisdocker/

도커의 성능

Docker hub

• 수많은 개발자들이 다양한 도커 이미지를

올리고/받고/검색할 수 있는 공식 도커 이

미지 저장소

• https://registry.hub.docker.com/

Mesos 소개

• 분산 시스템 커널

– 리눅스 커널과 동일하며, 단지 추상화 레벨만 다르다.

• 모든 머신에서 동작하며, 실행 어플리케이션에 대해 리소스관리와 스케쥴링 API를 제공.

• Mesosphere = Mesos + Marathon + Chronos

• Marathon은 작업(컨테이너)관리담당이며, Chronos는 작업스케쥴러이다.

Mesos 소개

• 아파치 Top Level 프로젝트

• 트위터, 에어비앤비, 미소스피어가 사용

• 구글은 Kubernetes용 Mesos 서비스중(https://google.mesosphere.com/)

• 운영시 10000대 노드까지 확장가능

• 패키지와 서포트는 미소스피어 담당

• 기본적으로 Docker지원

• 튜토리얼 코스

http://docs.mesosphere.com/intro-course/

클라우드시대의 Apps

Mesos 노드추상화

• Static Partitioning은 스케일과 장애대응이 어렵다.

• Mesos의 노드들은 모든 Task에 대해 공유된다.

Mesos 동작구성도

• Mesos에서 Docker는 작업의 Type중 하나이다.

• Zookeeper를 통해 HA를 구성한다.

• Scheduler는 Marathon을 사용하거나, 직접 개발이 가능하다.

Mesos 구성도1

• Marathon은 PaaS플랫폼

• 향후 Kubernates 지원계획

Mesos 구성도2

• 하이브리드 Cloud 구성가능

• Batch 작업은 Chronos로 지원

Mesos 프레임워크

• Meta-Frameworks / HA Services: Aurora, Marathon

• Distributed Cron: Chronos

• Containers: Docker

• Continuous Integration: Jenkins, GitLab

• Big Data: Hadoop, Spark, Storm, Kafka, Cassandra, Hypertable, MPI

• Python workloads: DPark, Exelixi

Mesos 프레임워크

마라톤은 Rails, Django등을 실행할 수 있으며, 어플리케이션을 시작,정지, 스케일링 할수 있는 REST API를 제공한다.

Mesos 동작원리

1. 슬레이브에 여유 리소스가 생기면, 마스터에게 여유정보를 통

보한다.

2. 할당정책에 따라서, 마스터는 얼마나 많은 리소스가 각 프레

임워크에 할당되었는지 결정한다.

3. 그다음, 마스터가 제안를 보내고, 스케줄러는 어는 제안 리소

스가 받아들여졌는지 선택한다.

4. 프레임워크가 제안 리소스를 받아들이면, 실행할 작업내용을

Mesos에게 보낸다.

5. 적합한 리소스를 실행기에 할당한 슬레이브에게 마스터는 차

례대로 작업들을 보낸다.

6. 최종적으로, 프레임워크는 작업을 실행하게 된다.

Scheduler 개발 import org.apache.mesos.MesosSchedulerDriver;

import org.apache.mesos.Protos;

import org.apache.mesos.Protos.*;

import org.apache.mesos.Protos.TaskID;

import org.apache.mesos.Scheduler;

import org.apache.mesos.SchedulerDriver;

public class MyScheduler implements Scheduler {

// Override Scheduler Functions like resourceOffers, etc.

}

* 리소스 할당등의 스케쥴러를 개발할수 있다.

Executor개발 import org.apache.mesos.Executor;

import org.apache.mesos.ExecutorDriver;

import org.apache.mesos.MesosExecutorDriver;

import org.apache.mesos.Protos.Environment.Variable;

import org.apache.mesos.Protos.*;

import org.apache.mesos.Protos.TaskID;

import org.apache.mesos.Protos.TaskStatus;

public class MyExecutor implements Executor {

// Override Executor Functions such as launchTask, etc.

}

* 작성실행기등의 Executor를 개발할수 있다.

참고자료

• https://docs.mesosphere.com/

• http://abhishek-tiwari.com/post/building-distributed-systems-with-mesos

• http://www.slideshare.net/Docker/building-web-scale-apps-with-docker-and-mesos

Garuda

시스템 구성도

Garuda master

Master Node

Docker Registry

DB

Garuda console

Load balancer

Proxy DMZ

REST API

Web UI

Firewall

Internet

Master

Slave

Master Master

Slave Slave ...

Cluster

ZK

Internal Firewall

Admin

http://<appId>.mydomain.com

* 색이 칠해진 박스는 하나의 VM Instance를 나타낸다.

Master Node

Garuda master

Garuda console

• 웹 어드민을 제공하는 데몬

• Listening on 80 port

• 웹 UI 제공

• Running on Tomcat, Jetty or JBoss

• 실제 모든 작업은 Manager 데몬으로 REST API

를 호출함으로서 수행된다.

• 시스템관리와 클러스터 컨트롤을 제공하는 데몬

• REST API listening on 8080 port

• 내부컴포넌트는 API Listener와 Console, Cloud

Controller, Cloud Watch등이 있다.

• REST API listening on 8080 port (Embedded)

Management

Cloud Controller

REST API

Jetty *:8080

Garuda master

• 전체시스템관리

• APP 메타데이터 관리

• 사용자 관리

• 클러스터 관리 / 컨트롤

• Mesos 통신

• Scale-in/out 담당

Master Node

Cloud Watch

• App 사용량을 감지하여 Scale-in/out 결정

Cluster • Marathon Slave의 역할로 실제 사용자 어플리

케이션이 실행되는 서버

• 최소 1개이상으로 계속 추가가능

• Marathon Master의 역할로 작업분배를 담당

• HA를 위해 3개로 구성하여 Zookeeper와 통신

• Leader로 선정된 Master 하나만 Active이며 나머지 2

개서버는 Standby.

Master

Slave

Master Master

Slave Slave ...

Mesos-slave

HAProxy

Mesos-master

Marathon

zookeeper

• Marathon framework 기반의 작업을 실행

• Master, Slave, Garuda master와 통신한다.

Docker Daemon • Docker 작업이 실행가능하도록 daemon 설치

Slave

Cluster

Master

• Marathon에서 자동설정해주는 프록시

HAProxy

• Marathon에서 자동설정해주는 프록시

• 로드밸런서가 직접 Slave를 바라보므로, 사용할일은 없음.

• Master에 설치되는 Daemon들은 모두 HA가 가능하므로,

같은 인스턴스에 함께 설치하여 노드를 절약하도록 한다.

Load Balancer

• 서브도메인에 App ID가 입력되므로, App별로 분기해준다. Load balancer

HAProxy

mesos-marathon-bridge

Cron

• 로드밸러서는 Public IP를 부여받으며 외부에서 인터넷에서

접속이 가능하며 DMZ 영역에 위치한다.

• 로드밸런싱과 프록시 기능을 동시에 수행한다.

• 주기적으로 Marathon의 작업정보를 확인하여 변경사항이

있다면 HAProxy 설정파일을 업데이트하고 리로드한다.

• mesos-marathon-bridge스크립트를 주기적으로 실행한다.

frontend http-in *:80 acl hello8 hdr_end(host) -i hello8.fastcatsearch.com use_backend hello8_server if hello8 acl tomcat4 hdr_end(host) -i tomcat4.fastcatsearch.com use_backend tomcat4_server if tomcat4 #default_backend tomcat4_server backend hello8_server balance leastconn server hello8_1 104.236.89.167:31009 check maxconn 1000 backend tomcat4_server balance leastconn server tomcat4_1 104.236.89.167:31324 check maxconn 1000

haproxy.cfg 예시

관리콘솔

사용자 APP 배포흐름도

사용자 가입

작업서버 갯수결정

클러스터생성

플랫폼 선택

App 업로드

App 갯수설정

App 디플로이

App 서비스

사용자 로그인

클러스터 추가

레이아웃

클러스터 APP

내용

로고 로그인

1. 클러스터

클러스터 메인

클러스터 추가

아직 생성된 클러스터가 없습니다.

추가버튼을 눌러 새로운 클러스터를 생성해주세요.

클러스터 추가

클러스터명

dev

작업 인스턴스 유형

IaaS 타입

OpenStack

1GB/1CPU 30G SSD

지역

Local

작업 인스턴스 갯수

6

개발환경

SSH 키

swsong macbook + SSH 키 추가

이미지

Ubuntu 14.04 x64

클러스터 생성

http://mydomin.com/clusters/5600

클러스터 “개발환경” 이 생성중입니다.

✔ 생성요청

✔ 프로비저닝

✔ 인스턴스 시작

✔ 설정

검증

실행

4 / 6

클러스터 “개발환경”

프록시

개요

IaaS 타입 지역 Image 인스턴스갯수 생성일자

OpenStack Local Ubuntu 14.04 x64 12 2015-5-10 15:29:45

Host Name IP

dev-proxy-1 10.0.1.50

DB

Host Name IP

dev-db-1 10.0.1.52

Registry

Host Name IP

dev-registry-1 10.0.1.51

클러스터 “개발환경”

Host Name IP

dev-work-1 10.0.1.56

dev-work-2 10.0.1.57

dev-work-3 10.0.1.58

작업자

클러스터 삭제

Host Name IP

dev-master-1 10.0.1.53



마스터

클러스터 메인

클러스터

클러스터명 상태 인스턴스수 생성일자

개발환경 실행중 12 2015-5-10 15:29:45 수정

추가

2. APP

APP 메인

APP 추가

아직 생성된 APP이 없습니다.

추가버튼을 눌러 새로운 APP을 생성해주세요.

APP 추가

플랫폼 PHP

guestbookapp-php.zip App 찾아보기...

갯수 2

완료 취소

book App ID

ID 메모리(MB)

CPUS Task/ Instances

Health 상태 End Point

/book 32 0.5 2/2 OK 실행중 104.131.109.14:80

/game 16 0.1 0/1 PENDING 디플로이중 -

APP 추가

APP 메인

데모시연

구성

Controllers

• 클러스터를 제어하고 WAS와 통신한다.

• 구성

– Garuda Master(이하 GM)

– Zookeeper

– HAProxy

• ZK Quorum 구성을 위해서 3대의 인스턴스 필요

• 모든 인스턴스에 3개 SW 동일하게 설치

• GM은 리더로 선출된 서버가 마스터역할을 하며, 나머지 두대는 대기상태이다.

• GM은 WAS와의 통신을 위해 REST API를 제공한다.

Controllers 구성도

Garuda Master

Zookeeper

HAProxy

Controller #1

Garuda Master

Zookeeper

HAProxy

Controller #2

Garuda Master

Zookeeper

HAProxy

Controller #3

Clusters

• 클러스터는 App을 실행하는 환경을 제공하며, App을 제어한다.

• Mesos + Marathon을 사용한다.

• Master 구성 – Mesos-master – Marathon – Zookeeper – HAProxy

• Slave 구성 – Mesos-slave

• Mesos는 ZK Quorum을 위해 3대가 소요되며, Active-Standby 로 사용된다.

• Controller와의 통신은 Mesos와 Marathon의 고유 REST API를 사용한다.

Clusters 구성도

Mesos-master

Zookeeper

HAProxy

Master #1

Mesos-master

Zookeeper

HAProxy

Master #2

Mesos-master

Zookeeper

HAProxy

Master #3

Marathon Marathon Marathon

Mesos-slave

Slave #1

Mesos-slave

Slave #2

Mesos-slave

Slave #3

각 Mesos-slave는 리더로 선출된 Mesos-master 와 통신한다.

Mesos Master

Mesos Master

Active(리더선출)

Standby

Marathon

Marathon

범례

그밖에

1. 리눅스 배포본은 Ubunto14.04로 고정

2. 심플함을 위해 VM Instance의 사양을 고정.

– 2G Memory, 2 CPU, 30GB Disk

3. 환경구성을 위해서는 Chef를 사용한다.

인스턴스 프로비저닝

초기 Chef 서버 준비

• 최소 한대의 Chef서버가 존재해야 클러스터 구성이 가능하다.

• Chef서버는 아래 방법으로 준비가능(택1)

1. Chef서버 이미지를 만들어놓는다.

2. Shell 스크립트를 통해 동적으로 구성한다. 1. 서버에 ChefDK설치

2. git clone을 통해 github.com/uengine(또는 supermarket)에 만들어놓은 chef server cookbook 다운로드

3. chef-client --local-mode를 통해 chef server 로컬에 설치

• 구성이 끝났다면 chef supermarket에 공개해둔 proxy, controller, master, slave용 cookbook들을 받아서 chef server에 유지한다.

프로비저닝

• 구성된 chef server기반으로 각 인스턴스의 환경을 구성한다.

• 구성전 먼저 어느 서버를 어떤 용도로 사용할지 정해놓아야한다. (순차적할당가능)

• 프로비저닝 수행 1. 컨트롤러그룹에게 controller cookbook을 적용

2. 마스터 그룹에게 master cookbook을 적용

3. 작업자 그룹에게 worker cookbook을 적용

4. 프록시 그룹에게 proxy cookbook을 적용

• cookbook적용시 zk, mesos 등은 동일 그룹내 타 인스턴스들의 IP, Port정보를 알고 있어야 하므로, knife 파라미터로 해당 정보를 전달해준다.

Cookbook 1. shared (참조용도)

– haproxy

– zookeeper

2. docker-registry

– docker-registry

3. controller

– haproxy (shared :: haproxy 참조)

– zookeeper (shared :: zookeeper 참조)

– gruda-master(나중에 추가)

4. master

– haproxy (shared :: haproxy 참조)

– zookeeper (shared :: zookeeper 참조)

– mesos-master

– marathon

5. slave

– mesos-slave

6. proxy

– mesos-marathon-bridge (스크립트)

7. Mysql 서비스 브로커리지

– mysql

8. Chef server

– chef-server

플랫폼제공

지원플랫폼

• 사용자들의 프로세스가 올바로 동작하기 위해서는 먼저 환경이 구성되어 있어야 한다.

• Garuda는 아래 플랫폼을 지원하며, Docker 이미지로 Registry에 등록되어 있어야 한다.

– Apache + PHP (https://registry.hub.docker.com/_/php/)

– Tomcat + JAVA (https://registry.hub.docker.com/_/tomcat/)

– Node.js (https://registry.hub.docker.com/_/node/)

– Python + Django + mod_wsgi (https://registry.hub.docker.com/_/dj

ango/)

– Ruby + Rails + Passenger (https://registry.hub.docker.com/_/rails/)

• 1차 Milestone에서는 PHP와 Tomcat만 지원

사용자 App이미지

• 사용자가 업로드한 App을 Docker Registry에 저장된 기본이미지와 합쳐서 새로운 App별 이미지를 만들어서 등록한다. 1. App을 특정디렉토리에 위치. 예) build/<사용자ID>/<AppID>

2. Dockerfile을 플랫폼별 템플릿으로 자동 생성(App COPY 포함)

3. docker build로 이미지 생성.

4. docker registry에 push

• App별 이미지는 scale-out시 재사용된다.

• 사용자가 app을 재업로드할때마다 이미지는 갱신된다. 버전자동증가. (이미지는 기본 이미지에 대하여 diff 파일만 포함하므로 크기가 작음)

• 플랫폼의 특성을 파악하여 도커이미지내부에 app의 복사대상 위치를 알고 있어야한다.

• 테스트시에는 실행된 Docker에 서비스접근되는지 확인.

서비스제공

• Docker 타입의 Marathon의 Task를 만들어서 필요한 갯수만큼 App을 실행한다.

• Task가 올바로 실행되면, 내부 네트워크에서 서비스사용이 가능하다.

• 외부 네트워크에서의 접근은 “서비스 디스커버리” 장에서 다루게 되며, 여기서 해줄 작업은 더 이상없다.

그외

Controller

• 관리콘솔UI의 실제기능을 수행

• 기능목록

– UI로 업로드된 app 수신

– app + platform 을 docker image로 생성

– app 메타데이터 관리

서비스 디스커버리

Cluster #1

Proxy Proxy

Slave #1

App A App B

Slave #2

App A App C

Slave #3

App B App C

DMZ zone

Internet

서비스 브로커리지

• 사용자 App에서 필요한 데이터베이스등의 리소스를 제공한다.

• 제공리소스

– Database(MySQL, PostgreSQL)

– NoSQL (MongoDB, Redis)

– Search engine (Elasticsearch, Fastcatsearch)

• 리소스 사용을 위해서는 먼저 콘솔을 통해 App하위에 리소스를 생성하고 Binding해야한다.

서비스 생성 및 사용

• 서비스 생성

1. 앱하위에 추가가능한 리소스내역을 확인(GET

service/catalog). 프로바이더 별로 내부에 내역관리.

2. 리소스를 선택하여 생성(POST service/create/:id)

3. 앱과 리소스 바인딩(POST service/binding/:id)

• 서비스 사용

1. 바인딩된 리소스를 클릭하여 접속정보 및 계정확인

2. Task생성시 service항목에 정보입력하면 Injection

을 통해 Datasource가 자동으로 맵핑됨.

개발사항(Spring + mysql)

• 서비스 Binding 정의

– Json형태로 접속정보입력

• Datasource 사용

– JPA등을 통해 리소스 사용시 자동으로 Injection

– 어노데이터션 제공 및 개발시 사용법 숙지.

• 주의사항

– 테이블 생성등의 SQL등은 리소스 사용시 검증하여, 없으면 자동 실행되도록 해야함.

Billing

SaaS Subscription-Billing Services

Zuora Aria

Hiveage Chargify

And more..

• Plan

– 하나의 과금정책

• Service

– Plan을 구성하는 하나의 제공 Feature

• Service and Rate

– 각 Feature들의 가격정책

• Recurring Billing

– 반복적인 과금. 매월, 매분기 또는 매년

SaaS Subscription Words

SaaS Subscription Words

Aria Systems

Zuora

• Sells a billing platform

• Founded 2007 by Tzuo

• Z-Billing, Z-Commerse, Z-Finance, Z-Pay

ment, Z-Tax

• Zendesk, Box, Dell, HP Cloud, SugarSync,

etc..

Zuora

1. One-time Pricing Model

1. 가입시 한번

2. 기본료

3. 상품에 따라 무상 혹은 할인가능

2. Recurring Pricing Model

1. 주기적으로 반복되어 과금

2. 한도를 넘어서면 제한 또는 추가과금

3. Usage-based Pricing Model

1. 사용량에 비례하여 과금

2. 사용량이 늘어나면 할인가능

• Aria + IBM Cloud + Zuora 의 과금모델을 분석하여 만든 과금 라이브러리

• Java 1.6+ • 소스 - http://www.opencloudengine.org/svn/

garuda/trunk/bss-monetization/

List<Plan> planList = app.getPlanList();

Plan plan = planList.get(0);

BillingContext context = new BillingContext();

ServiceUsages serviceUsages = plan.calculate(context);

// serviceUsages가 Billing 과금결과.

OCE 오픈소스 과금라이브러리

OCE 오픈소스 과금라이브러리

More

• 첫 과금모델은 불완전할 수 밖에 없다.

• Listen to customers voice.

• Trial, Freemium 기간에 검증하라.

• 패턴분석 – 시간, 사용량, 사용자 분류

• Plan 향상 – Win-win

Metering

• Measures how much resource used

• Billing source data

• Data loss -> Money trouble

• Logging

• Centralization

• Aggregate

Metering

Metering System Arch.

Metering 사용방식

미터링 방식

사용 시스템

장점 단점 적합성

API Call Aria Zuora

로그가 로컬에 남지 않음

• 원본로그를 직접관리

• 10분에 8000건호출등의 제약

• Https필수.

외부시스템에서 Billing Service연동시 적합

Log Agent OCE 파일로그를 이용하므로 로그의 손실우려 없음

웹어플리케이션과 빌링서비스가 다른 네트워크에 있을 경우 로그가 보안노출위협. TCP on SSL 필수.

내부 PaaS 시스템에서 적합. 하지만 SSL사용시 외부시스템도 가능.

Billing / Metering 구현

Final Billing System Arch.

Billing API

HTTP Method

URI Description

GET /app/{appId}/plan 플랜정보취득

POST /app/{appId}/tenant param1 : tenantId={tenantId} param2 : planId={planId}

사용자 가입

GET /app/{appId}/tenant/{tenantId} 사용자 가입정보 취득

Billing 프레임워크 개발 고려사항

A. 사용자의 Subscription 변경시

B. 사용자의 Subscription 해지시

C. Subscription이 Expired 되었을때

D. PLAN내용 변경시

1. 정책변경


A. 서비스호출전 항상 확인

B. 서비스호출후 Update

C. 분산캐시솔루션

D.초과상태 Update 주기

E. 초과제한시 Flag On

2. 허용량 초과 대응


A. 프로세스(JVM)당 하나의 로그파일

B. 로그기록 라이브러리

3. 로그기록

Logger Throughput / Thread

Log4j 2 All Async 288,997

Log4j 2 Async Appender 23,980

Log4j 1 Async Appender 14,072

Log4j 2 Synchronous 4,253

Log4j 1 Synchronous 3,509

http://logging.apache.org/log4j/2.x/


4. 로그백업

# 해당날짜의 로그파일을 하나의 파일로 압축한다.

$ tar cf metering.log.<DATE>.tar.gz metering.*.log.<DATE>

# 압축파일을 백업서버로 복사한다.

$ scp metering.log.<DATE>.tar.gz

<backup_server_ip>:/< backup_path>


5. 과금계산단위

A. 사용자의 Subscription 해지 / 변경시

B. Provider의 Plan 변경시

C. 잔여비용 반환 / 비용 적용 구간

D.아마존 1시간 단위

E. Google Cloud 기본 10분, 이후 1분 단위

https://cloud.google.com/compute/


6. 사용량 / 비용 계산 주기

A. Recurring pricing : 허용량 초과시

B. Usage-base pricing

C. 1분주기 계산후 1시간, 1일, 1달 단위로 합

산


7. Raw 로그데이터저장소

A. 비정형 데이터 - NoSQL

B. 로그검색

C. 통계분석


8. 로그수집기 SOF 문제

A. 중앙의 로그수집기 FAIL시 Money trouble

B. 이중화

C. Fluentd <match metering.log>

type forward

flush_interval 1s

<server>

name log-collector1

host 172.17.0.179

port 24224

</server>

<server>

name log-collector2

host 172.17.0.180

port 24224

</server>

</match>

패턴분석

사용자 패턴분석

• Subscriber에게 더 나은 Plan 제공

• Provider는 최대 수익지점 예측

• 조용한 사용자

서비스 사용률, 서비스별 사용비율, 조직별 사용비율, 사용위치정보, 그

리고 상세 데이터 테이블까지 대시보드에서 한눈에 확인할 수 있다.

Kibana를 통한 서비스사용 패턴분석

http://www.elasticsearch.org/overview/kibana

Claim 대응

http://www.elasticsearch.org/overview/kibana

(”basic service" OR ”advance service") AND uengine

Fastcat분석기를 통한 검색패턴분석

http://fastcatsearch.org/viewInOnePage/24

http://fastcatsearch.org/viewInOnePage/24

Fastcat분석기를 통한 검색패턴분석

Billing/Metering 요약

Provider는 Plan의 적극적인 설계가 중요

• 고객의 피드백을 적극 수용하라

• 조용한 고객을 대비하여 패턴분석을 하라

• 패턴분석결과로 고객그룹을 나누어 Plan을 재정비하

라

• 수요를 예측하고 적합한 가격결정을 하라

• 고객이 기능별로 선택하여 구성할 수 있도록 하라

• 플랜별 기능구분을 명확히 느끼도록 하라

• Up-selling과 Cross-selling을 유도하라

• Trial에서 Paid로 전환이 용이하도록 하라

• Discount 정책을 적절히 활용하라

mesos와 docker 기반 엘라스틱파티셔닝 paas · mesos와 docker 기반...

Documents