2015 Open Cloud Engine Handbook

1
목 차
2015 오픈클라우드엔진의 오늘과 미래.................................................................2
OMG SW 공학 표준 Essence 와 Cloud Software Lifecycle Management
.....................................................................................................................................................18
Essencia Tutorial............................................................................................................35
Mesos 와 Docker 기반 PaaS..................................................................................44
OCE Sub Project – Flamingo (Big Data Platform)......................................53

2
2015 오픈클라우드엔진의 오늘과 미래
1. 서론
안녕하십니까? 오픈클라우드엔진의 의장을 맡고 있는 장진영입니다. 지난 2012 년
부터 3 년간의 국산 오픈소스 플랫폼 제품들을 클라우드 컴퓨팅의 주제로 통합하고
있는 프로젝트입니다. 본 자료는 기업과 서비스 제공자 들의 클라우드 컴퓨팅 전환
에 있어 요구되는 사항들을 짚어보고, 2015 년 지금까지 노력해온 오픈클라우드엔진
의 제품들이 어떻게 그 요구사항들에 부합될 수 있는지에 대한 내용을 담고 있습니
다.
(그림 1) 소프트웨어 딜리버리 하기

3
전통적인 소프트웨어 서비스 제공 방식은 하드웨어를 구매하는 절차에서 소프트
웨어를 개발하고 그 개발을 위한 다양한 미들웨어를 설치하고 최적화하는 과정입니
다. 즉, 하나의 시스템이나 서비스를 운영하기 위해서는 소프트웨어의 기획, 설계, 개
발을 넘어 하드웨어, 네트워크, 미들웨어, 성능 최적화와 같은 시스템 운영과 관련한
전문성을 갖추어야 하는 부담이 존재하였습니다. 그런데 최근에 등장한 IaaS 와
PaaS는 우리로 하여금 소프트웨어 개발 아이디어에만 집중할 수 있도록 해주고 있
습니다. IaaS와 PaaS는 어떤 마법을 부린 것일까요?
(그림 2) DevOps
DevOps (데브옵스) 라는 Developer와 Operator의 합성어인 용어가 심심치 않게
최근에 들려오고 있습니다. 즉, 개발자가 운영자의 역할도 대신할 수 있는 환경이라
는 이야기인데요, 그림은 그 진화과정을 보여주고 있습니다. 상대적으로 시스템이 자
동화할 수 있는 영역인 빌드와 통합 그리고 테스트, 그리고 반영에 이르기까지의 사
람이 개입하여 작업하던 것들을 도구들이 대신 해주면서 점점 사람은 보다 창의적이
고 설계 관점의 임무만을 수행하면 되기에 이르렀습니다. 그러한 도구들에는 통합빌
드를 쉽게 해주는 maven, 테스트 자동화를 위한 junit, 자동화된 주기적인 시스템
반영과 통합을 오케스트레이션하는 jenkins 등이 있습니다.

4
(그림 3) DevOps
이러한 완전한 형태의 DevOps 환경이 암시하는 바는, 사람의 개입 없이도 우리
시스템이 언제나 가용하고, 새로운 버전을 반영하더라도 멈춤이 없으며, 이를 넘어서
똑똑하게 범람하는 요청에 대비하여 시스템을 알아서 증설하고 HA 환경을 구성하고,
반대로 요청이 줄어들면 이에 따라 시스템의 사용을 절약하도록 완전한 운영의 자동
화를 할 수 있는 단계를 암시합니다. 과연 이러한 자동화는 어떤 기술들에 의해 가능
해질 수 있을까요?
그림 4 은 클라우드 컴퓨팅 제공 방식 중 하나인 PaaS (Platform As A Service)가
제공

5
(그림 4) PaaS Functional Landscape
하는 기능의 범위를 보여줍니다. PaaS 는 운영중인 시스템을 ‘안정되게 제공하는’
OSS (Operation Support Service)와 ‘비즈니스적으로 시스템을 판매, 마케팅, 과금
할 수 있는’ 기능들을 제공하는 BSS (Business Support Service)를 포함합니다.
PaaS 는 IaaS 의 하드웨어 운영 자동화의 기반 위에서 소프트웨어 개발자가 운영에
필요한 다양한 미들웨어 운영 및 시스템 최적화에 대한 고민을 대신 알아서 해줍니
다. 이 기반에는 서버가 소프트웨어로 정의되어 컨트롤 가능해진‘Software Defined
X’ 세상에 우리가 태어난 덕분이라고 할 수 있습니다. PaaS는 DevOps 환경을 구성
하기 위한 좋은 기반이 될 수 있습니다.
앞서 언급드린 것처럼, PaaS 는 애플리케이션 운영, 최적화, 확대를 위한 운영자동
화 뿐만 아니라, 애플리케이션의 개발, 설계, 모델링에 필요한 도구들도 클라우드의
사용
(그림 5) IBM의 클라우드 도입 가이드 라인
방식대로 쉽게 접근하여 사용할 수 있도록 도와줍니다. 이러한 환경은 특히 조직내
에 적용했을때 효과가 높은데, 조직이 크고 클라우드 컴퓨팅을 단순 비용절감 수준

6
이 아닌 제공자 측면에서 전략적으로 적용할 때일 수록, 이를 조직에 적용했을 때의
효율이 높습니다. 그림은 IBM 이 제시하는 클라우드 도입 가이드라인으로서, 특히
비즈니스 모델링 기능까지 겸비한 PaaS인 BPM As A Service 를 적용하면, 조직이
보유한 애플리케이션 자원들끼리 혹은 외부에서 빌려다 쓰는 SaaS 애플리케이션까
지도 모델링 기반으로 통합하여 자동화된 운영을 할 수 있는 단계에 이르게 됩니다.
그러니까 모델링만으로 시스템을 만들기도 통합하기도 하면서 곧바로 운영할 수 있
는 진정한 SOA 수준을 경험할 수 있게 됩니다.
(그림 6) 확장된 SaaS 성숙도 모델과 BPaaS
그러한 확장된 시나리오를 많은 시장 조사 기관들에서는 수준 높은 SaaS 도입단
계로 제시하고 있죠.
2. 2015년의 오픈클라우드엔진
이제 2015 년의 오픈클라우드엔진을 소개하겠습니다. 오픈클라우드엔진에는 자체
적으로 개발된 운영지원을 위한 환경을 요즘 유행하는 도커와 아파치 메소스를 기반
하여 개발되었습니다. 도커는 기존 VM 기반 가상화보다 가볍고 민첩하며, 이식성이
좋은 실행환경 분리를 가능하게 합니다. 아파치 메소스는 매우 유연한 클라우드 시

7
나리오를 프레임워크화 해놓은 환경으로 이를 기반하면 빅데이터 클러스터, PaaS 운
영환경 등을 마음껏 만들어 쓸 수 있습니다. 특히 기반 운영 프로세스를 자바를 기반
으로
(그림 7) 2015 OCE
자체적으로 구현 가능하다는 옵션은 기존 자바 인력들을 많이 응용해온 엔터프라
이즈에서 접근하지 좋은 옵션이 됩니다. 아키텍트와 개발자들은 제공자 포탈에 접근
하여 모델링 툴과 개발환경을 통하여 애플리케이션을 빠르게 모델링하여 운영단계에
적용할 수 있도록 하고 있습니다.
모델 Github.com/TheOpenCloudEngine 에 가시면 오픈클라우드엔진 내에는 여
러 개의 서브프로젝트가 존재합니다. 오픈클라우드엔진의 어떤 서브 프로젝트들이

8
그러한 자동화된 DevOps 환경을 가능토록 하는 것일까요?
(그림 8) Github.com/TheOpenCloudEngine
가. Essencia SaaS ALM
첫번째는 Essencia SaaS ALM 입니다. 전체적인 DevOps 프로세스를 OMG
BPMN 을 준수하는 uEngine BPMS 와 OMG SW 공학 방법론 표준인 Essence 를
중심으로 확장적으로 개발 운용할 수 있도록 고안되었습니다.
(그림 9) Essencia: Model-driven SaaS ALM
필요할 때 언제든지 프로세스를 만들고 수정하여 반영할 수 있습니다. BPMS 가
내장하고 있는 시스템 통합의 기능은 내부적으로 이미 사용중인 IaaS와 CI 도구 등
도 유연하게 통합할 수 있도록 해줍니다.

9
(그림 10) Essencia: 방법론 및 ALM 프로세스 정의
Essencia 는 또한 OMG 의 SW공학 표현 표준인 Essence 를 지원하여 현존하는
많은 종류의 방법론 프랙티스를 표현하고 관리할 수 있습니다. 산출물의 유형, 참여
역할의 정의와 수준, 활동에 대한 기준과 산출물의 수준등의 방법론에서 준수해야
하는 구체적인 체크포인트로도 관리할 수 있습니다. 자세한 사항은 OMG Essence
표준을 확인하시기 바랍니다. Essencia 는 이러한 OMG essence 표준을 기반으로
정의된 다양한 방법론들을 프로젝트 실행할 수 있는 형태로 변환하는 기능을 포함하
고 있어 스크럼, UP, UX등의 방법론을 그때 그때 조합하여 실행할 수 있습니다.
그림 11 은 OCE 의 적용사례인 KIAT 에서 적용된 클라우드 운영 프로세스를 보
여주고 있습니다. BPMN 을 기반한 DevOps 프로세스 환경은 조직의 크기, 영역에
따라 추가 수정이 용이합니다.
(그림 11) essencia: 방법론 및 ALM 프로세스 정의
에센스 OMG 표준은 프로젝트의 진척 상황을 에센스에서 정의한 3 개 대분류 –
고객관점, 솔루션관점, 노력관점, 그리고 7 개 세분류로 진척의 상태를 균형적인 잦
대로 평가할 수 있도록 해줍니다. 이는 한번 정의된 방법론의 활동과 에센스에서 표
준적으로 정의한 Kernel 이라고 하는 기준의 매핑을 한번 해놓았기 때문입니다. 다
양한 방법론을 적용하는 프로젝트를 운영할 경우 매우 유용합니다.

10
(그림 12) Essencia: 방법론 및 ALM 프로세스 정의
나. OCE Garuda PaaS
OCE garuda PaaS 에는 클라우드 접속만으로 애플리케이션 개발을 할 수 있는 프
로그래밍 환경을 제공합니다. 이를 통하여 개발자는 각자의 개발환경을 매번 잡을
필요가 없고 개발환경의 상이함에 의한 테스팅 비용 및 운영비용을 절감할 수 있습
니다. 또한 일괄적인 보안적용도 용이합니다.

11
(그림 13) Garuda-portal : Cloud IDE
개발자 포탈의 일부인 UML 모델링 환경은 2015 년 OCE 로드맵의 핵심중 하나
로, 소프트웨어 코딩을 최소화하고 가능한 비즈니스 모델링을 기반하여 애플리케이
션을 만들 수 있도록 할 예정입니다. 순수웹기반의 모델링 환경을 기반으로 클래스
를 모델을 설계하고 클라우드 IDE 에서 생성된 소스코드를 구현하여 BPMN 프로세
스에 연계할 수 있습니다.
(그림 14) uEngine-UML : UML 기반 Software Modeling
특히 POJO 기반 프레임워크에서의 애노테이션 주입을 용이하게 하여 다양한 구현
정보를 모델링 과정에서 주입가능하기 때문에, 모델링만으로 웹서비스 노출 (JAX-
RS), 데이터베이스 ORM (JPA) 개발 등을 쉽게 할 수 있습니다. 사용된 기반기술로
는 SVG, Eclipse EMF eCore framework 이 있습니다.
소프트웨어를 모델링하고 이를 웹서비스로 Expose 하는 설정을 애노테이션으로
주입하는 등의 모델링 작업이 마쳐지면, 이렇게 완성된 요소들을 기반으로 프로세스
를 편집할 수 있습니다. 또한 외부에서 연결할 수 있는 클라우드 애플리케이션들간

12
의 오케스트래이션 프로세스를 구성할 수 도 있습니다. BPM 기능은 DevOps 운영
프로세스 자체의 관리 뿐만 아니라, PaaS상에서 개발된 애플리케이션내의 프로세스
운영, 그리고 테넌트가 가입한 애플리케이션 들간의 오케스트래이션 설정을 위한 용
도로도
(그림 15) uEngine-BPM : 비즈니스 프로세스 관리
광범위하게 사용되어 전체 시스템의 유연성을 제공합니다. 여기에는 국내에서 개발
되어 안정화된 BPM엔진인 uEngine BPM 최신 버전이 적용되었습니다.
PaaS 에서 개발한 클라우드 애플리케이션을 프라이빗 환경에서만 사용하는 경우
라면 이 내용이 관심이 없을 수 있습니다만, 만약 외부에 서비스로 판매할 계획이라

13
면 과금과 빌링, 인보이스를 만드는 행위는 매우 중요합니다.
(그림 16) Garuda-portal/bss-monetization : 가격 모형 관리 / 시뮬레이션
결국 인터넷 기반 비즈니스의 핵심은 가격경쟁이기 때문입니다. 타 제공 서비스보
다 빠르게 가격산출 룰을 적용하고 안정된 쿼터제어 및 인보이스 생성 및 메일링 등
은 성공우위에 핵심적인 기능입니다.
OCE Garuda PaaS 실행환경은 앞서 언급한 아파치 메소스를 기반으로 운영됩니
다.
(그림 17) Garuda : OSS supportcore
아파치 메소스는 트위터, 구글등에서 검증된 클라우드 프레임워크입니다. 또한 여러
유형의 Infra 를 하나의 가상화된 Pool 로 인식할 수 있어 Hybrid Cloud 환경을 구축
할 수 도 있으며, 다양한 언어를 기반으로 커스터마이징을 할 수 있는 클라우드 시스
템의 ‘스프링 프레임워크’ 라 할 수 있습니다. 향후 조직내에 쉽게 커스터마이징을
할 수 있으려면 생소한 언어를 이해해야 관리 프로세스를 변경할 수 있는 다른 오픈

14
소스 기반 PaaS 에 대비하여 기업내에 적용에서는 장점이 있다 판단할 수 있습니다.
클라우드 애플리케이션들을 사용하는 조직은 하나이상의 멀티태넌시-싱글인스턴스
애플리케이션을 어떻게 내 사용자들이 쉽게 커스터마이징하고 통합하여 사용할 수
있을지를 고민해야 합니다.
(그림 18) Operation Time Support (Integration via MSA / CSB)
OCE 의 uEngine BPMS 기반의 환경은 하나이상의 RESTful 서비스를 expose 한
애플리케이션들을 통합할 수 있도록 Pool 모델링과 WebService invocation 액티비
티들을 드래그-앤-드롭으로 구현할 수 있도록 제공합니다. 모델링 만으로 시스템을

15
취득, 통합, 운영할 수 있는 환경의 핵심열쇠입니다.
(그림 19) Multi-tenancy Support
소프트웨어 개발에 있어서 싱글인스턴스-멀티테넌시를 구현하는 것은 쉽지 않습니
다. OCE 에 내장된 멀티테넌시 프레임워크는 하나이상의 노드에 분산되어 요청된 워
크로드가 어떤 테넌트에서 요청된 것인지 인지하고 요청된 테넌트의 브랜드, 워크플
로우, 데이터 구조에 맞게 소프트웨어를 폴리폴핑 시켜주어 하나의 인스턴스로 많은
테넌트를 받아들이면서도 각자의 요건에 맞춤화를 해줍니다. 이러한 기반이 없으면
Free-mium 전략 같은 핵심 SaaS 비즈니스 전략을 구사하기 어렵습니다.
(그림 20) Business Supporting Service : Metering / Billing
사용량 측정과 과금은 클라우드 전략을 내부적인 활용수준을 넘어선 전략적으로 클
라우드 비즈니스를 수행하고자 하는 기업에게는 매우 중요한 구현 고려사항입니다.
특히 언제든지 노드를 소멸가능하고 (Ephemeral) 빠르게 재생성하는 방식으로 가용
성과 확장성을 제공하고자 하는 클라우드 접근 방법에서는 로그를 파일로 남겨서 수
집할 수도 없고, 쿼터관리를 위하여 기존의 무거운 수집방법을 사용할 수 없습니다.

16
OCE Billing/Metering 프레임워크는 이러한 고려사항을 기반하여 설계되었습니다.
3. 결론
(그림 21) Supporting Full Lifecycle of Model-driven, DevOps
앞서 소개한 많은 구현요소들은 우리 조직으로 하여금 최소한의 노력으로 최대한의
성능을 발휘할 수 있는 소프트웨어 운영을 가능하게 할 것입니다. 이를 위하여 OCE
플랫폼은 설계되어 개발됩니다.

17
지금 깃허브에서 오픈클라우드엔진을 만나보실 수 있습니다. 깃허브에는 전문가
여러분의 의견을 받을 수 있는 채널이 있습니다.

18
OMG SW 공학 표준 Essence 와 Cloud Software
Lifecycle Management
1. 소개
Essencia(이하 에센시아)는 소프트웨어 공학 방법론을 정의하기 위해 SEMAT
에서 제정한 방법론 제정 표준(2014 년 상반기 OMG 의 정식 표준)인 Essence(이하
에센스)를 지원하는 방법론 재정의 및 실행지원 솔루션이다. 산업계에서 UP/RUP
등의 프로세스 모델과 마르미 등 CBD 기반 개발 방법론, DW 구축 방법론 등 많은
방법론들이 혼재하고 있으나 다양한 고객의 역량과 프로젝트 상황에 맞게 최적화된
프랙티스들을 조합하여 적용하기가 어렵다. 에센스는 기존 방법론들의 낮은 재사용
성과 유연성, 확장성 등을 극복하고, 특정한 상황에 맞춤화하기 쉽도록 다양하고 복
잡할 수 있는 방법론을 보다 쉽게 접근하기 위해 개발되었으며, 표기법 기반의 모델
을 사용하여 특정 조직에 최적화된 방법론을 제정할 수 있다는 점에서 관심을 받고
있다. 이러한 배경에서 SW공학 프랙티스 표준의 표준으로 제정되고 있는 OMG 에
센스를 통하여 최대한 쉽게 누구나 사용할 수 있는 프랙티스 재정의, 방법론 조합 및
이를 실행할 수 있도록 지원하는 도구인 에센시아를 개발하게 되었다. 에센시아를
통하여 일반 SW개발자들도 쉽게 SW 개발방법론을 정의하여 적용함으로써 SW 생
산성을 향상시킬 수 있도록 도움을 줌으로써 에센스의 보급에 및 활성화에 큰 기여
를 할 수 있을 것으로 기대한다.
2. 에센스 실행 지원 모델
가. 에센스의 특성

19
OMG 에센스는 현존하는 소프트웨어 프로세스의 다양성을 고객의 요구사항에 따
라 프랙티스를 최적화시키고, 누구나 쉽게 방법론 조합을 통하여 비용과 시간을 절
감하기 위해 개발 되었다. 에센스의 실행 지원도구로 개발된 에센시아는 웹 기반 시
스템으로 인터넷 연결만으로 실행이 가능하기 때문에 누구나 접근하기 편리할 수 있
도록 하였다. 새로운 메서드를 매핑하는데 있어서 에센스의 표준화 된 Kernel(이하
커널)과 Language(이하 언어)를 이용하여 메서드를 구성하는 프랙티스를 재구성 할
수 있으며, 에센스에 사용되는 커널은 프랙티스의 기본이 되는 요소들이다. 이해관계
자로부터 요구사항이 들어왔을 때, 프랙티스와 방법론을 요구사항에 맞게 커스터마
이징하고, 변경이나 생성해야 할 프로젝트의 조건에 적합하게 대입하여 도구를 사용
해 실행 자동화하는 것이 에센시아이다.
나. 에센스 지원 메타모델의 정의
에센시아는 에센스 specification의 Practice description conformance Level 3
을 지원하는 웹 기반의 도구로 에센스를 지원하기 위하여 그림 1 과 같은 메타모델
로 정의할 수 있다. 에센시아를 실행시키는 프랙티스는 조직적이고 분리되지 않아
재사용이 가능하다. 프랙티스는 에센스 커널과 그에 따른 언어로 표현 되고 여러 프
랙티스가 모여 메서드를 구성한다. 프랙티스들은 서로의 중복요소 파악, 프랙티스 간
의 산출물 추적성과 상호의존성 파악이 가능하고 프랙티스 통합 연계가 가능하다.
High-level의 메서드는 여러 개의 lower-level로 구성 될 수 있고, lower-level 메
서드 또한 여러 개의 high-level의 메서드로 구성 될 수 있다. 에센시아는 Practice
Author(프랙티스 저자), Method Author(메서드 저자)와 Project Stakeholders(프로
젝트 이해관계자)의 3가지 시스템 액터들이 있다.
(그림 1) 에센시아 메타모델 구성요소와 그의 관계들을 설명해주는 구성도

20
이 메타모델은 사용자가 하나 이상의 프로젝트에 참여 중이고, 다른 소속의 파트
너일지라도 여러 명이 함께 같은 프로젝트에 참여할 수 있다. 에센시아의 특성 중 하
나는 순차적으로 Alpha Mapping --> Activity Space Mapping --> Practice
Process Design을 할 수도 있으나, 언제든지 되돌아가 다시 설계할 수 있고 역순이
어도 상관이 없다. 이 프로세스는 프로젝트 참여자들의 이행을 돕는 소프트웨어 엔
지니어링 활동의 오케스트레이션이다.
다. 에센스 지원 메타모델의 구성요소
에센스를 구성하는 표준 커널은 언어를 사용하는 필수요소가 되는 모델이다. 커
널은 고객관점, 솔루션관점과 노력관점으로 분류 된다. 그리고 각 관점에 속하는 에
센스를 지원하는 메타모델의 커널 구성요소들에는 언어에는 alpha, activity space,
competency로 정의할 수 있다. 이러한 커널의 구성요소들로 에센스 언어를 구성할
수 있고 프랙티스와 메서드를 재구성하여 메타모델을 만들 수 있다.
프랙티스는 에센스 커널의 표준화된 언어(alpha, activity, activity space,
competency)들로 만들어진 work product, activity 와 role 들을 매핑하여 가장 기
본적인 프랙티스가 되며 노력관점의 소프트웨어 엔지니어링을 이행시키는 도구장치
이다. 프랙티스는 분리되지 않으며 재사용할 수 있다. 여러 프랙티스가 모여 메서드
를 구성하고 메서드는 특정한 엔지니어링의 목적을 이루기 위한 방법론으로 정의 된
다. 메서드는 재사용 율이 낮은 방법론이다.
Alpha 는 ‘Abstract–Level Progress Health Attribute’의 함축어로 프랙티스의
구성이 되는 객체요소이고 소프트웨어 엔지니어링의 진행 과정을 쉽게 파악할 수 있
게 해주며, 프로젝트의 진행 프로세스에 따라 각 alpha 들(stakeholder,
(그림 2) 커널의 세 가지 관점과 alpha 들의 관계
opportunity, requirement, software system, work, team, way of working (그
림 2.))의 상태를 나타내는 alpha state 를 거친다. 이 alpha state 들은 프로젝트의
진행 상태를 판단할 수 있는 체크리스트를 각각 가지고 있고 체크리스트를 만족시키

21
지 못할 경우에 언제든지 전 state 로 되돌아가 완성시킬 수 있다. Alpha 의 상태 변
환에 따라 프로젝트가 특정한 시점에서 건강하게 진행되고 있는지 파악할 수 있다.
Activity space 는 커널의 세 가지 관점에서 alpha 들이 임무를 완성할 수 있는
공간이며 activity 를 포함하고 있는 활동요소이다. Activity 는 커널 관점의 상태를
변경할 수 있으며, 여러 개의 작업항목(Work Product)을 포함하고 있다. 아래 보기
와 같이 activity space 들은 각 해당하는 커널의 관점에서 활동이 이루어지도록 한
다. Activity space 범위 안에서 알파의 상태변화를 식별하고 상태를 실행하기 위한
과정을 추적함으로써 프로젝트가 건강하게 진행되고 있는지를 파악할 수 있다.
‘Competency’는 소프트웨어 엔지니어링을 이행할 수 있는 주 된 역량을 뜻하며
competency 에는 stakeholder representation, analysis, development, testing,
leadership 과 management 가 있다. 각 competency 는 다섯 가지의 레벨로 나뉠
수 있는데; 레벨 1 은 개념에 대한 기본적인 이해도와 주어진 설명대로 이행 할 수
있어야 한다. 레벨 2는 경험을 통해 개념을 간단하게 적용 할 수 있는 단계이다. 레
벨 3 은 특별한 지시 없이 개념을 무리 없이 적용 할 수 있는 단계이다. 레벨 4 는
직접 판단하고 복잡한 맥락에 적용 할 수 있는 단계이고 레벨 5는 전문가로 인정받
고 기존 개념을 더 넓히며 다른 사람을 도울 수 있는 단계이다.
(그림 3) 커널의 세 가지 관점에서의 activity spaces

22
(그림 4) 커널의 세 가지 관점에서의 competencies
3. 에센시아 설계
가. 에센시아 설계기준
(1) Executable Practice(실행 가능한 프랙티스)
Business Process Orchestration Approach 를 적용한 프랙티스 / 메소드 의
실행 자동화를 통하여 SOA 를 기반한 SW 통합방식 중 하나인 Process
Orchestration Approach는 Business Process 를 중심으로 동적 통합 및 프로
세스 실행 (인스턴스) 데이터의 분석을 통한 추적성과 성능을 지속적으로 관리
할 수 있도록 한다.
(2) OMG의 BPMN 표준을 준수하는 실행가능한 BPMN출력이 가능하여
야 한다.
(3) 에센스 커널내의 Alpha, Activity Space, Competency의 요소들을 기
반하여 재정의된 프랙티스를 가능한 자동으로 BPMN으로 출력해 낼수
있으며, 이를 기반으로 Practice Author는 BPMN으로 표현된 프랙티스
의 역할, 액티비티, 트랜지션, 분기규칙, 입출력 산출물 등을 명확히 재
정의하고 향후 실행하는데 있어서 무결성을 검증할 수 있어야 한다.

23
(그림 5) SW 공학 프랙티스를 BPMN으로 정의하여 명확한 역할 정의와
실행에서의 무결성 보장
(그림 6) SW 공학 프랙티스의 자산화와 지속적 개선을 위하여 Business Process
Management 기반의 프로세스 관리 방식을 접목하면 추적성, 투명성이 개선되고
개발조직의 퍼포먼스 분석과 프랙티스 자체의 성능 분석 또한 가능해진다.
(4) BPMN은 JIRA 를 포함한 다양한 소프트웨어 개발에 관련한 도구들을 시스템

24
에 통합함에 있어 REST, Web Service 등으로 통합하는 관점에서의 인터페이
스를 제공할 수 있어야 한다.
(그림 7) 유엔진 BPM엔진의 메타모델은 BPMN의 표현과
실행을 커버하도록 고안되었음
(5) BPMN 2.0 의 모델링, 실행, 모니터링, 분석을 지원하여야 한다. 이를 통하여
Essencia 의 프랙티스의 저작에서 실행, 모니터링까지의 기반 기능을 제공할
수 있어야 한다.
(6) 소셜과 모바일 기반의 집단지성과 사용성 제공
1) 사용자는 본 서비스에 접근하여 자신의 프랙티스를 웹브라우저 접근만으
로 쉽게 저작하여 공유할 수 있고, 상호 공유하여 개선하여 완성하는 집
단지성 기능을 제공할 수 있어야 한다.
2) 사용의 용이성을 위하여 본 플랫폼의 UI/UX 설계 방식은 순수 웹 기술과
Light-wight 한 통신기술인 ajax, web socket을 적용하여 다양한 단말
– 태블릿, 스마트폰을 포함한 모든 단말에서 OSMU 되는 콘텐츠를 제공
할 수 있어야 한다.

25
(그림 8) 반응형 웹 기술과 멀티태넌시를 지원하고 클라우드 환경위에서 제공
되는 서비스의 예시나. PaaS는 어떠한 변화를 주는가?
나. 에센시아 아키텍처
에센스 기반의 프랙티스 재정의 및 메서드 조합이 가능하도록 하기 위하여 에
센시아의 역할로 다음 5가지 액터를 정의할 수 있다.
1). Practice Author: Essence 에 입각하여 기존의 혹은 새롭게 정의하고자 하
는 프랙티스를 정의하는 사람.
2) Method Author: Essence 기반으로 재정되는 프랙티스들을 조합하여 새로운
방법론을 정의하는 사람.
3) Product Owner: Essence 기반으로 프로젝트의 진행 및 건강도를 조망하고
자 하는 사람.
4) Project Manager: Essence 기반으로 프로젝트의 진행과 감독, 팀활동을 하
는 사람
5) Developer: Essence 기반으로 프로젝트 진행단계에서 체크리스트를 확인하
여 개발 및 테스트, 팀 활동 등을 수행하는 개발자.
<표 1> 액터정의
상위액터 액터명 정의 및 자격 유즈케이스

26
Author
Practice
Author
에센스 커널과 랭귀지를
사용하여 프랙티스를 정
의하는 사람. 방법론 전
문가.
프랙티스 정의 :
-Essence-Kernel-Alpha :
PracticeComponent 간의 매핑
-Essence-Kernel-
ActivitySpace : Practice Activity
간의 매핑
Method
Author
프랙티스를 전문가가 정
의한 프랙티스 들을 조합
하여 기업 내에서 혹은
프로젝트 내에서 사용할
방법론을 정의하는 사람.
메서드 정의: 프랙티스 들의 조합
& 프로세스 추가 정의
Project
Stakeholder
Product
Owner
프로젝트를 발주하여 프
랙티스와 방법론에 의한
진행상황에 관심 있게 모
니터링 하는 사람
프로젝트 모니터링 (대시보드)
Project
Manager
프로젝트 관리의 책임을
가지고 정의된 방법론을
사용하여 프로젝트에 적
용하는 사람.
메서드 / 프랙티스 실행
프로젝트 모니터링
프로젝트 워크리스트 확인, 체크포
인트 실행유무 판단, 체크
관계자 선택 및 관리
Develope
r
프로젝트 내의 요구사항
을 개발하는 개발자
프로젝트 워크리스트 확인, 체크포
인트 실행 유무 판단, 체크
에센시아를 구성하는 각 컴포넌트를 설계 기준을 준수하기 위하여 다음과 같이 크
게 3개의 컴포넌트로 설계하였다.
1) Practice Definer: Practice Author가 사용하여 Essence 표준 정의기반
으로 프랙틱스의 세부 구성요소와 프로세스를 매핑시켜 재정의 하는 컴포
넌트
2) Method Composer: Method Author 가 사용하여 Practice Author

27
Practice Definer를 통해 재정의한 Essence 화된 프랙티스들을 쉽게 재조
합 하여 새로운 방법론을 만드는 컴포넌트
3) Practice/Method Orchestrator: Product Owner, Project Manager,
Developer 들이 접속하여 정의된 프랙티스와 메서드를 실행시키고 진척도
를 확인하고, 해야 할 체크포인트를 부여 받는 컴포넌트
각 액터와 에센시아를 구성하는 컴포넌트/시스템의 유즈케이스를 정의하면 <표
2>와 같다.
<표 2> 시스템 / 유즈케이스 정의
시스템명 유즈케이스명 활동 액터
프랙티스 컴포
저
프랙티스 정의
Essence – Kernel - Alpha :
PracticeComponent 간의 매핑
Essence – Kernel - ActivitySpace :
PracticeActivity 간의 매핑
Practice
Author
메서드 정의 프랙티스들의 조합 & 프로세스 추가 정의 Author
정의 밸리데이션
/ 시뮬레이션
정의한 프랙티스와 메서드에 대한 무결성
검증 및 실행 시뮬레이션
Author
프로젝트
핼쓰 대시보드
프로젝트 모니터
링
프로젝트 모니터링 (대시보드)
Project
Stakeholder
프랙티스
오케스트레이터
메서드/프랙티스
실행
프랙티스 실행 시작 정보 입력 (프로젝트
정보 및 참여자 역할 매핑)
Project
Manager
프로젝트 워크리
스트
확인, 체크포인트 실행유무 판단, 체크
Project
Stakeholder
이를 유즈케이스 흐름에 따라 설명하면
1) Practice Author 가 정의한 Practice 들은 Practice Library (저장소)에 저
장됨.
2) Method Author는 Method Composer를 통하여 이미 정의된 Practice
Library들을 조합하여 자신의 방법론을 정의하여 자사의 공간 혹은 퍼
블릭한 (SaaS서비스에서 공유·판매 될 수 있는) 공간으로 업로드가
가능함.
3) 이렇게 정의된 Practice 와 Method 는 Essencia Practice Orchestrator에

28
의하여 실행되어 Alpha State 에 따라 해야 할 일 (워크아이템) 이 제
시됨. 이때 Essencia 이외에 JIRA 와 같은 도입 고객이 기존에 사용 하
던 도구가 있는 경우, 해당 도구가 Orchestrator 역할을 수행하도록
P r ac t ic e · M e t ho d 의 모 델 은 해 당 도 구 로 E x p o r t 됨 .
4) 해야할 일을 처리하는 과정에서 다양한 소셜 커뮤니케이션이 웹 2.0
포탈을 통하여 벌어질 수 있음.
5) 해야 할 일을 처리하기 위하여 사용할만한 도구들이 추천됨
6) 실행의 결과들이 집계되면 Alpha State 통합 대시보드를 통하여 진척
을 프로젝트 전체 이행관계자들이 확인할 수 있으며 계획 변경 등을
실시할 수 있음.
(그림 9) Essencia의 시스템 구성요소와 액터
에센시아의 전체 아키텍처는 SOA아키텍처로 SaaS 서비스 시에 동적 확장
과 외부 서비스들과의 매시업 서비스 등이 용이하게 구성될 수 있는 구조를
보여줄 수 있도록 그림 9와 같이 설계되었다.
서비스 레이어는 RESTful 서비스로 바인딩하여 다종 단말 및 외부 서비스
에서의 Open API접근을 가능하게 하며 Stateless 하게 설계하는 것을 도와,
이후 언급된 아마존 웹 서비스 클라우드를 기반한 서비스 노드 확장과 제거
를 용이하게 하는 가장 중심적인 설계 영역이며, 프랙티스 오케스트레이션
서비스는 프랙티스와 메서드를 오케스트레이션 해주는 서비스가 프로젝트
진척에 따른 알파의 전이, 체크포인트 등을 집계하여 워크리스트 UI가 체크포
인트 카드를 생성할 수 있도록 RESTful 서비스이다.

29
(그림 10) Essencia 의 서비스 중심 아키텍처 설계
대시보드 서비스
프로젝트 진척에 따라 전이된 Alpha State 들의 상태, 계획대비 실정 정보 등을
조회하는 서비스, 계획의 변경이 필요하면 계획 변경을 요청하는 RESTful 서비
스.
프랙티스·메서드 저장소 서비스
프랙티스·메서드 컴포저에 의하여 재정의된 프랙티스와 제정된 방법론을 저장
하고, 조회하고, 취득할 수 있는 저장소 서비스.
외부 서비스들
아마존 웹 서비스를 SaaS서비스 플랫폼으로 활요할 예정이므로, 과금시 아마
존의 Payment Gateway 서비스를 호출할 수 있음. JIRA 와 같은 외부 PMS
도
구를 통하여 제정된 방법론을 오케스트레이션 하도록 지원하기 위하여 JIRA
의 RESTful 서비스를 사용함. 온라인 공학 도구들과 연계하여 워크아이템 발
행시 추천해줄 때 외부 공학도구들의 서비스가 존재함.
다. 에센시아 주요 기능
에센시아의 처음 단계인 프랙티스 definer 는 웹 기반으로써 별도의 설치 없이
자동 구동되는 drag & drop 방식으로 설계를 할 수 있다. 프랙티스의 생성, 수정,

30
삭제 등 전반적인 기능 및 관리가 가능하고 정의 변경과 이력관리 또한 가능하다.
프랙티스 라이브러리 트리를 오른쪽 클릭하여 커널 요소들로(alpha, activities,
activity spaces, competencies) 새로운 프랙티스 definition 을 생성할 수 있다.
커널요소들과 산출물을 composition link 로 서로 연동시킴으로써 함께 설계할 수
있고 요소들에 대한 세부사항이 설정 되고 미리보기가 가능하다.
그림 11. 사용자가 웹 기반의 GUI 프랙티스 설계를 정의할 수 있다.
에센스 specification 정의 의해, drag & drop 방식으로 다른 프랙티스와 같은
카테고리의 요소들이 새로운 메서드를 구성할 수 있다. 레이아웃은 자동으로 완료
되지만, 사용자가 링크를 수동으로 요소들을 나란히 정렬해야 한다. 메서드 구성
이 완료되면 캔버스 아래에 있는 process modeler 탭을 클릭하여 BPMN
process modeler 로 전환이 되어 프로세스 모델을 파생할 수 있고 competency
가 하나의 Role 로 그려질 수 있다. 메서드 author 는 BPMN 표기법을 따라
activities 를 서로 연결할 수있다.

31
그림 12. 프랙티스들의병합 및 자동으로 통합과 BPMN Model로의 전환
소셜 네크워크 포탈을 기반으로 workspace 가 구현되어 프로젝트에 관련 된 모
든 이해관계자들이 참여할 수 있으며 더 쉽고 활발하게 서로 소통할 수 있다. 오
른쪽 클릭을 하여 이용 가능한 메서드를 시작한다. 각각의 competency 를 실제
사용자에 지정해야 하여 메서드를 시작한다. Work item 보기는 completion
criteria 의 체크포인트를 포함하고 있고 프로세스 기반의 모니터링을 할 수 있다.
다른 사용자로 전환하여 같은 방식으로 work item 을 구현할 수 있다.
그림 13. 메서드의 실행을 위한 BPMN의 자동 변환
배포 된 메서드 프로세스의 실행 환경이 설정되고 프로세스를 시작 할 때,
Role

32
설정 및 activity 별 에센스 specification 의 체크리스트가 제공되며 이해관계자
들
간의 의사소통이 가능하다. 또한, 커널의 각 관점 별로, 또는 activity별로
프로젝트의 상태를 모니터링 할 수 있다.
그림 14. 에센스 specification에 정의 된 관점 별 모니터링
3. 용어집
• Ajax(Asynchronous Javascript and XML): 대화식 웹 어플리케이션의 제작을
위해 자바스크립트와 XML등의 조합을 이용하는 웹 개발 기법이다.

33
• BPEL (Business Process Execution Language): BPEL 은 웹 서비스로 구성
된 비즈니스 프로세스 워크플로우를 명세 하는데 사용되는 XML 기반의 언
어로서, 여러 서비스를 조합하여 복합 서비스를 만들 때 사용된다. 즉, 복합
서비스는 일반적으로 BPEL 을 이용하여 구현될 수 있다. 현재 발표된
BPEL의 공식 버전은 2.0이다.
• BPMN (Business Process Modeling Notation): BPMN 은 비즈니스 프로세스
의 워크플로우를 표현할 수 있는 표준화된 그래픽 기반 표기법으로 OMG 에
서 발표되었다. BPMN 에는 비즈니스 프로세스의 액티비티(태스크 또는 하
위 프로세스), 흐름, 이벤트, 게이트웨이 등에 관련된 표기법을 포함하고 있
다. 현재 발표된 BPMN 공식 버전은 1.0이다.
• Business Process Orchestration Approach: 비즈니스의 목적을 달성하기 위
해 기술적인 측면에서의 프로세스 엑티비티와 이벤트를 결성하고 관리한다.
• Business Process: 비즈니스 프로세스는 서비스 소비자 관점에서 정의한 일
련의 작업 순서를 나타낸 것으로, 사용자가 비즈니스 조직에서 수행하는 비
즈니스 활동 또는 실제 업무를 실체화하기 위해 정의된다. 비즈니스 프로세
스는 비즈니스의 주요한 기능을 처리한다.
• Capability(기능): 기능은 서비스에 의해 수행되며, 서비스 소비자의 요구사항
을 만족시키기 위해 서비스를 통해 제공되는 것이다. 서비스 소비자는 필요
한 요구사항을 기술하고, 단일 서비스는 더 이상 분해되지 않는 기능 단위로,
일반적으로 하나의 스텝에 의해 수행되는 단순한 기능을 가진 태스크를 포
함한다.
• Completion criteria: 프로젝트 진행이 완료되었는지 파악하기 위한 표준으로
네 가지 criteria 가 있다.
• Essence Kernel(에센스 커널): 에센스의 표준화된 도형의 요소들로써 커널의
콘텐츠를 표현하고 소프트웨어 엔지니어링을 위한 최적화된 에센스를 제공
한다. 커널은 고객관점, 솔루션관점과 노력관점으로 분류된다.
• GUI(Graphic User Interface): 그림으로 된 화면 위의 물체, 틀, 색상과 같은
그래픽 요소들을 기능과 용도를 나타내기 위해 설계된 사용자를 위한 인터
페이스이다.
• Mapping(매핑): 소프트웨어 엔지니어링의 프로세스에서 어떠한 요소들끼리의
가상으로 관계를 찾아내거나 연결시키는 것을 말한다.
• OSMU(One Source, Multi-Use): 하나의 미디어 소스를 여러 미디어 형태로
확장하여 납품하는 것을 말한다.
• Practice Author(프랙티스 저자): 에센스 커널의 요소들을 매핑을 하여 프랙티

34
스의 세부적인 실행을 돕고 BPMN 모델러를 이용하여 프로세스를 정의한다.
• Practice description conformance Level: 에센스 언어를 사용하여 프랙티스
가 실행되기 위한 적합성을 판단하는 표준으로써 세 가지 레벨로 나뉜다;
Narrative(1), Practice Description Interchange(2), Practice Actionable
and Trackable(3).
• REST(Representational State Transfer): World-wide web 과 같은 분산 하
이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 하나의 형식이자 원리의
모음이다. REST 아키텍처의 형식을 따르면, HTTP 나 www 이 아닌 큰 소
프트웨어 시스템이 가능하며 또한 간단한 XML 과 HTTP 인터페이스를 사
용한 설계도 가능하다.
• SOA(Service Orchestrated Architecture): 컴퓨터 시스템을 구축할 때의 개
념으로 업무 처리에 해당하는 소프트웨어 기능을 서비스로 판단하여 네트워
크상에 연동하여 시스템 전체를 구축하는 방법론
• Stakeholders(이해관계자): 소프트웨어 시스템을 이용하여 영향을 주고 받는
모든 조직이나 사람을 뜻한다. Product owner, 프로젝트 매니저, 사용자, 개
발자 등이 여기에 해당한다.

35
Essencia Tutorial
1. How to define Practices
A) Create New Practice
Log in to Essencia. Find the menu on the top left side. Right-click ‘Practice’
and click ‘New Practice’ to open ‘Practice Definer’ canvas tab. Drag
Practice form Essence Language on the left menu and double-click to
rename and add description below if necessary. All actions are done by a
way of drag-and-drop.
B) Compose Practice with Essence Kernel Elements
Select desire Alphas from Kernel Palette and link to Practice by dragging a
line from center of Practice symbol to Alphas. You can adjust the position
and the size of symbols as you wish to design by dragging. The general
sequence of kernel element mapping is Alpha à Activity Space à Practice
process design. Reverse order does not matter. Link relative elements
each other. A screen example of Essence Kernel Alpha mapping, Activity
and Competency UI of Scrum Practice is shown below (Figure.10, 11, 12).
Drag Competency, Activity and Work Product from Kernel Palette and
rename them and link to each other accordingly.

36
Figure.15 Practice Product Mapping with Essence Kernel
Figure.16 Activity Mapping UI

37
Figure.17 Competency Mapping UI of Practice Role
C) Viewing Card Preview
You can see Card Preview to check each Alpha State by double-click
Alpha symbol and click ‘State’, then click ‘Card Preview’ at the bottom as
you composing the Practice. This is just to see Alpha State in progress
between each step.
D) Define State of each Kernel Language
Since Activity Space connected with Activity, has some default information
on Competency, Entry Criterion and Completion criteria. When double-
click Activity, you will find ‘Entry Criterion’, ‘Competency’ and ‘Work
Product’ options and define each state by select appropriate options. Entry
Criterion has options to choose and it express which alpha or product
should be selected to execute Activity. You define state of Competency,
Completion criteria and Work Product and click ‘Apply’. You do the same
procedure for all relevant Activities and link to Activity Spaces accordingly.
Completion criteria express each Alpha states and show which Alpha has
to be complete.

38
E) Viewing Coverage
Click ‘Save’ after Practice has been defined to store in Practice library and
click ‘Coverage’. The Alpha States covered by corresponding Method is
appears as pink area in the Coverage table. Practice is systematic and
repeatable so that user can go back remap to satisfy requirement and
reverse order is acceptable. This Coverage table can be viewed anytime
between composing a Practice and Method. If you combine two or more
Practices, the pink area (covered by Method) is then changed.
Figure.18 Coverage Table shows areaof Alpha State covered
by corresponding Practice
F) Check In & CheckOut
Log in as a different user and press ‘Check in” to assign different roles.
Previous user log in again and press ‘Check out’ A Practice can be
compiled and enhanced by many users therefore, “Check in & Check out”
functions are provided.

39
2. How to compose a Methods
A) Create New Method
Method Composer basically inheritances previous Practice in editor to able
the customizing in previous Practice. Right-click Method presented on the
left menu then click ‘New Method’. Drag relevant defined Practice from
Practice Library on the left menu and rename. - For example, name it as
“ScrumandBPR” which means it is composed of ‘Scrum’ and ‘BPR’
Practices.
Figure.19 Method Composer with BPMN base
B) Ordering Sequence
Click ‘Process Modeler’ tab seen on the top to convert into BPMN Process
Modeler. You can see the BPMN Process which can implement defined
Methods, role of Competency and Activity here. Define the sequence of
Method by drag a sequence flow line between centers of each task.

40
C) Get Ready to Use
Save the Method you created just now and the Method appears on the
Method Library on the left. Right-click the Method and press ‘Deploy’, then
the Method is deployed and ready to use.
3. How to run Essencia with Method
A) Run Application
Log in to Essencia and click ‘App’ on top right and add file. Click ‘App’
again and double click to open ‘Role Specification’ tab. Specify each role for
an App to run with appropriate person by dragging user’s icon on the left
and press ‘run’.
B) View Process Monitoring
Click ‘Process Monitoring’ above the title of page to see which tasks are
complete. You will see green mark, means completed and the blue mark
means the task is still need to be completed. For the uncompleted task, you
go back to previous step and complete the task of Alpha State. The
Practice materialized by BPM-based and checklist is managed
automatically.
The task has roles with its own user thus; different users should complete
their own task with same procedure. Users repeat this until all the tasks of
Alpha States are completed. After then, click ‘Process Monitoring’ again to
confirm all the tasks are completed and marked in green ticks. Different
user can see ‘completed’ notice as well.

41
Figure.20 Process Monitoring
4. How to import and Export Essencia Work Product
A) Export Practice
Log in to Essencia and compose a Practice as mentioned previously. Save
defined Practice and click ‘Export’ on the top.
B) Import Practice
Double-click ‘Test’ in the Practice Library and click ‘delete’, then right-
click Practice and click ‘import’ option. Attach file you just have made or
other files and press ‘import’. The imported file can be opened via Notepad
program. Practice and Methods are stored and loaded with Essence XMI.
5. DashBoard

42
The other word for dashboard is health analysis and monitoring project
progress and technological development.
- Product Owner in several different projects in progress are optimized
and tailored methodology into practice, even if the recipient provides
the most balanced monitoring into a single standardized terms is that
there is a significant.
- Standardized by Essence "Practice" to be managed through the
"Projects" that it can be aggregated in accordance with the progress of
mapping the Alpha State in activities once with Essence stages of
practice, a term even if the project is managed by a number of practices
available and provided.
- Customers point of view of the essence (The Customer), the solution
point of view (The Solution), efforts in terms of software management
perspective (The Endeavor) which allows a balanced administrationof
the project associated such as BSC (Balanced Score Card; BSC in
financial terms as sound management indicators, customer perspective,
process perspective, divided into internal capacity standpoint to collect
key performance indicators KPI management proportioned balance
was verified by monitoring indicators).
- It provides a view of the switch to be seen by the respective practices
with the activity monitoring perspective as occasion demands.
- When you drill down into detailed progress Alpha, it shows the steps
associated with the execution Stakeholder involvement and practices.

43
- The results show a plan prepared in accordance with the milestones.
Figure.21 DashBoard

44
Mesos 와 Docker 기반 PaaS
1. 서론
PaaS는 개발을 위한 플랫폼을 구축할 필요없이, 개발과 실행 및 어플리
케이션 관리를 제공하는 클라우드 컴퓨팅 서비스이다. 오픈소스 영역에서
는 RedHat의 OpenShift, Pivotal의 CloudFoundry 가 강세를 보이고 있으
며, 아마존 웹서비스의 ElasticBeanstalk와 Google App Engine, 그리고
Heroku도 널리 사용되고 있다. 그외에도 다양한 PaaS가 존재하며 메이저
제공자들은 실행환경에 도커를 도입하고 있는 추세이다. 우리는 Garuda프
로젝트를 통하여 웹어플리케이션을 빠르고, 안정적으로 서비스로 배포할
수 있는 PaaS시스템을 개발하고 있으며, 작업관리모듈에 유수의 기업에서
검증된 Mesos와 도커를 사용하였다. 여기서는 도커와 Mesos에 대해서 알
아보고, 그 후에 Garuda에 적용한 방법에 대해 논의할 것이다.
2. Docker
도커는 어플리케이션을 빌드하고 배포하고 실행해주는 오픈소스 컨테이
너 플랫폼이다. 리눅스 컨테이너란, 단일 호스트 상에서 여러개의 고립된
리눅스 시스템 (컨테이너) 들을 실행하기 위한 운영 시스템 레벨 가상화 방
법이다. 컨테이너는 chroot와 가상화의 중간정도 개념으로, 가상화와 비슷
하지만, Guest 운영체제가 필요없는 가벼운 대안을 제시한다. 가상머신, 클
라우드, PC 어디서든 실행가능하기 때문에, 이식성이 좋다. 리눅스 커널은
cgroups를 절충하여 가상화 머신을 시작할 필요 없이 자원 할당 (CPU, 메
모리, 블록 I/O, 네트워크 등)을 한다. Cgroups는 또한 애플리케이션 입장
에서 프로세스 트리, 네트워크, 사용자 ID, 마운트된 파일 시스템 등의 운
영 환경을 완전히 고립시키기 위해 namespace isolation을 제공한다. 도커
는 이러한 리눅스 컨테이너를 한층 더 발전시킨 플랫폼이며, 0.9버전부터는
LXC가 아닌 Go언어로 자체 개발한 libcontainer를 기본 컨테이너 라이브
러리로 대체하여 제공하고 있다. 도커는 가상머신과도 차별이 되는데, 가상
머신은 필요한 바이너리와 라이브러리 및 전체 게스트 운영체제를 모두 포
함하고 있으며, 최소 수십GB의 메모리를 필요로 한다. 하지만 도커 컨테이

45
너는 어플리케이션과 그 디펜던시 라이브러리만을 포함하며, 커널을 다른
컨테이너와 공유한다. 그 결과 프로세스는 호스트 운영체제의 각 사용자
공간에서 독립적으로 실행이 되며, 어느 특정 인프라에 종속되지도 않는다.
도커는 어느 컴퓨터, 어느 인프라 위에서도 동작 가능하다.
Virtual Machine Docker
(그림 1) VM와 Docker 컨테이너의 차이
아래는 도커의 성능을 측정한 자료이다. CPU, 메모리부분에서 성능감소
가 최소 0.55 % 에서 최대 0.189 %이며, 네트워크에서는 성능감소가 조금
더 유발되어, 0.374 %이다. 모두 1%에 훨씬 못 미치는 성능감소량이며, 운
영환경에 도입되어도 좋을 만한 수치로 보여주고 있다. 특히 메모리 읽기
쪽에서는 도커의 성능이 호스트의 성능을 능가하는 결과가 나왔는데, 이는
테스트의 오차범위내로, 실제 호스트의 보다 좋은 수치가 나올 수는 없다.
<표 1> Ubuntu 14.04에서 Docker 1.1.2의 성능측정
성능측정도구 호스트 Docker
CPU sysbench 1 0.9945

46
메모리 쓰기 sysbench 1 0.9826
메모리 읽기 sysbench 1 1.0025
디스크 I/O dd 1 0.9811
네트워크 iperf 1 0.9626
3. Mesos
메소스는 아파치 재단의 Top 프로젝트로 분산 시스템 커널이라 할 수
있다. 즉, 시스템커널은 각 단일 머신의 운영 체제안 에 속해있지만, 분산
시스템 커널은 동일한 추상화를 통해 분산 머신들 상에 커널을 구현하는
것이다. 메소스가 출현하게 된 배경은 어플리케이션들의 변화 때문이다. 레
거시 어플리케이션들은 대부분 단일 머신에서 실행하기에 충분했지만, 최
근에는 Hadoop, Spark등을 대다수 애플리케이션이 단일 머신의 크기를 뛰
어넘고 있다. 더 이상 한대의 머신으로 처리할 수 없는 대형 어플리케이션
의 라이프사이클과 리소스를 관리하기 위해 분산 커널 시스템이 필요한 시
기가 온 것이다.
(그림 2) 이전과 현재 클라우드 시대의 변화
메소스는 Twitter에서 필요에 의해 시작된 프로젝트이나, 에어비앤비를
포함한 여러 유수의 기업에서 도입하고 있으며, 운영시 수만대 노드까지
확장이 가능하다. 도커와의 연계성도 뛰어나서, Native레벨에서 도커타입의
Task를 지원하고 있다. 메소스는 무엇보다도 클라우드에 걸맞는 Elastic
Sharing을 강점으로 내세우고 있는데, 기존의 Static Partitioning의 경우
컴퓨팅자원을 정해진 대로만 사용하게 되어, 리소스 낭비가 존재한다는 단

47
점이 있었다. 하지만, 메소스는 어떠한 작업이라도 모든 노드에서 실행할
수 있으며, 리소스를 앞에서부터 채워 사용하기 때문에, 리소스를 훨씬 효
율적으로 사용할 수 있다는 장점이 있다. 물론 설정에 따라 동일한 노드에
실행되지 않도록 하는 옵션도 있어, 웹 어플리케이션의 로드를 여러 서버
로 분산하고자 할 때도 문제없이 사용할 수 있다.
(그림 3) 메소스의 Elastic Sharing
메소스는 하이브리드 클라우드를 구축할 수 있는 플랫폼이며, 사내에
Openstack으로 운영하고 있다고 하더라도, 퍼블릭 클라우드 자원과 연계
하여 그대로 확장할 수 있다. 메소스가 제공한는 추상화 레벨은 상위 App
이 하위의 IaaS가 어떤 것인지 알 필요없이 리소스가 제공하는 한 무한정
확장할 수 있다. 실행 작업(Task)는 Native또는 Docker 타입이 될 수 있
으며, 실행작업의 성격상 배치작업인지 Long-running 작업인지로 분류될
수 있다.

48
(그림 4) 메소스 작업의 종류
실행하는 App에 따라 사용하는 스케줄러가 달라지게 되는데, Long-
running 작업에는 Marathon이, 단발적인 작업에는 Chronos가 사용된다.
아래는 각 스케줄러로 실행할 수 있는 실행App의 예시이며, 겹치는 부분은
어떠한 스케줄러를 사용해도 무방하다.
(그림 5) 메소스 스케줄러의 실행작업 예시

49
4. PaaS 의 구현
위에서 알아본 도커와 메소스는 PaaS개발시, 작업관리자 모듈에 적용할
수 있다. 실행하려는 작업을 메소스의 Marathon 프레임워크에 전달해주기
만 하면, 가장 적합한 노드를 찾아서 실행이 되며, scale 갯수를 늘리거나
줄이면 알아서 실행 앱을 추가 및 제거하여 실행갯수를 유지해준다.
PaaS에는 작업관리자 이외에도 전체시스템관리자, 도커이미지 관리, 테넌
드 정보관리, 로드밸런싱, 서비스 디스커버리, 데이터 브로커리지 등이 추
가로 필요하다. 우리는 Garuda라는 프로젝트를 아래와 같은 전체적인 시스
템 구성도로 구현을 하였다.
가. 전체시스템관리
Master Node는 전체시스템 관리자의 역할을 수행한다. Garuda master
데몬은 시스템관리와 작업 클러스터를 제공하며, 내부적으로 모두 REST
API를 통해 통신을 한다. 내부 컴포넌트는 API Listener와 관리Console,
Cloud Controller, Cloud Watcher등이 있다. Master 데몬은 외부로도
REST API를 제공하여 어떠한 Client라도 HTTP 통신만 가능하면, 명령을
호출할 수 있다. 시스템관리는 App 메타데이터관리와 사용자(테넌트)관리
가 포함된다. App은 개발 및 수정이 됨에 따라 도커이미지가 계속 만들어
지게 되며, 이러한 이미지들을 도커 레지스트리에 등록이 된다. 이러한 도
커이미지를 관리하는 것도 Master의 역할에 속한다.
Cloud Controller는 메소스 및 Marathon과 통신하여 작업을 할당해주
는 Mesos Client의 역할을 담당하여 명령은 모두 Master로 부터 할당 받

50
는다.
Cloud Watcher는 Auto 스케일 인/아웃을 가능하게 해주는 모듈이며,
각 앱 (도커인스턴스)들의 리소스 사용상태를 모니터링하여, 설정해둔 부하
보다 크거나, 작을때 자동으로 scale갯수를 유지해준다. 도커에서는
cgroups을 이용하여 리소스의 사용량을 제공하는 REST API가 있으며,
Watcher는 이 수치를 받아서 히스토리상의 사용량을 합산해 나간다.
나. 서비스 디스커버리
Load Balancer 부분이 서비스 디스커버리 부분이 된다. 실행된 웹 어플
리케이션은 개별적인 테넌트로 인식되어, 서브 도메인을 할당받게 된다. 외
부에서 웹 어플리케이션에 접근 시 서비스 디스커버리는 해당 작업을 요청
과 연결시켜준다. 이 부분을 담당하는 소프트웨어는 HAProxy이며, 앱이
추가되어나 삭제 될 때마다 설정이 갱신된다. HAProxy는 초당 8만건 정도
의 외부요청을 처리할 수 있는 고성능 소프트웨어 프록시이다. 로드밸런서
는 Public IP를 부여 받으며 외부 도메인과 연동되어, 로드밸런싱과 프록시
기능을 동시에 수행한다.
다. HA구성
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
(그림 6) Haproxy.cfg의 예시

51
클러스터를 구성하는 Master가 Fail시 모든 시스템이 정지하게 되는 문
제가 발생한다. 그렇기 때문에, Master노드의 활성화 상태는 매우 중요하며,
HA구성을 위해 Zookeeper를 사용한다. Zookeeper는 여러 노드중에 리더
를 선출 할 수 있는데, Quorum을 기반으로 한 과반수 찬성논리에 근거한
다. 그러므로, 최소인원은 3명이 되어야 하며, 리더가 필요한 Mesos-
master, Marathon, Zookeeper는 모두 3대 이상이 설치되어야 한다. 만일
이 패키지를 각각의 서버인스턴스에 설치시 관리노드가 매우 많아지는 현
상이 발생하므로, 이들 패키지는 모두 하나의 인스턴스에 설치하여 HA구
성을 하도록 한다.
(그림 7) Master 노드들의 HA구성

52
5 결론
Garuda 프로젝트는 Apache 의 검증된 Top 프로젝트인 Mesos 를 기반으로 작업
관리를 구현하였다. 가상머신의 무거움을 대체할 수 있는 도커기술이 클라우드 영역
에서 새롭게 부각되고 있으며, Mesos 는 도커를 Native 레벨에서 지원하므로,
Mesos 를 통한 작업관리는 분산 커널시스템과 도커 기반의 Immutable
Infrastructure 의 장점을 모두 만족시킬 수 있다. PaaS 는 작업관리뿐 아니라, 어플
리케이션관리와 서비스 디스커버리 또한 필수적으로 제공해야 하는 요소이며,
Garuda 는 오픈소스 기반의 검증된 패키지를 사용하여 구현된 견고한 PaaS라고 할
수 있다. Garuda 에 대한 더 자세한 정보는 OCE 커뮤니티 사이트에서 제공된다.
http://www.opence.org.
<참 고 문 헌>
[1] https://www.docker.com/
[2] https://ko.wikipedia.org/wiki/LXC
[3] http://mesos.apache.org/
[4] http://www.slideshare.net/Docker/building-web-scale-apps-with-docker-and-mesos
[5] http://www.opence.org

53
OCE Sub Project– Flamingo (Big Data Platform)
1. 공통 기반으로써 Hadoop 기반 빅데이터 플랫폼
빅데이터 저장, 처리, 분석을 위해서 Apache Hadoop 은 이제 표준 빅데이터 도
구가 되었습니다. 수없이 많은 Hadoop EcoSystem 을 유기적으로 잘 결합하여 활용
하기 위해서 대부분의 조직이 유상이든 무상이든 Cloudera, Pivotal, Hortonworks
등의 배포판을 사용하고 있다. 하지만 이러한 배포판을 사용하더라도 Hadoop 을 기
반으로 분석하고 이를 활용하기 위해서는 하둡 배포판 위에서 동작하는 플랫폼은 필
수적이다. 빅데이터 플랫폼은 분석, 저장, 처리 등의 다양한 작업을 손쉽게 해주고
확장 가능한 형태로 구축이 되어야만 다양한 요구사항을 수용할 수 있게 된다.

54
2. Flamingo Big Data Platform
Flamingo 는 Hadoop 을 기반으로 데이터를 분석하고 처리하고 모니터링 하기
위한 환경을 구성하여 빠르게 빅데이터 분석으로 이끄는 역할을 한다. Flamingo 는
다양한 사용자들이 Hadoop EcoSystem 을 기반으로 협업하여 분석하고 이를 모니
터링 할 수 있는 다양한 체계를 제공하는 오픈소스 라이센스를 가진 빅데이터 플랫
폼 소프트웨어이다.
가. Hadoop Cluster 모니터링
빅데이터 분석을 하는 많은 개발자들이 불만인 것은 Hadoop 의 각 구성요소를
모니터링 하기 위해서 Hadoop Cluster를 구성하는 노드의 동일 네트워크에 접속을
하거나 별도의 소프트웨어를 통해서 IP 주소를 라우팅해야만 각종 관리 화면에 접속
할 수 있다는 것이다. Flamingo 의 플랫폼 개발자들은 이러한 운영경험을 토대로 제
한된 네트워크가 아니라 단일 화면에서 모니터링을 가능하도록 에이전트를 개발하여
모니터링하는 기능을 Flamingo 에서 제공하도록 개발하였다. 리소스 관리자, YARN
애플리케이션 MapReduce Job, 노드, 데이터 노드, 네임노드 등 개발 및 운영에 필
요한 핵심 자원을 모니터링 할 수 있도록 도와준다.

55
나. 워크플로우 관리
데이터 처리 및 분석은 일련의 흐름이고 이러한 흐름을 설계 단계에서 도출하게
된다. 설계 단계에서 도출한 분석 플로우를 실제 수행단계에서 스크립트 개발 없이
활용하려면 워크플로우 관리가 필수적이다. Flamingo 에서는 워크플로우 관리를 위
해서 워크플로우 디자이너를 제공한다. 워크플로우 디자이너를 통해서 우리는 다양
한 처리 및 분석 모듈을 연계하여 하나의 플로우를 생성하고 이를 자동화할 수 있도
록 도와준다.

56
다. 분산 파일 시스템 관리
하둡을 이용하는 개발자 및 운영자의 가장 대표적인 업무는 파일을 관리하는 것
이다. 파일 및 디렉토리를 이동하거나 복사하거나 등등의 작업을 원활하게 하게 할
수 있도록 Flamingo 에서는 분산 파일 시스템 브라우저를 제공한다.

57
라. 분산 파일 시스템 감시
많은 사용자들이 분산 파일 시스템을 사용할 때 누가 얼마나 사용하는지, 또 어
떤 일을 하는지 파악하는 것은 관리자로써 중요한 업무이다. 파일을 분실했을 때 추
적을 할 수 있어야 하기 때문이다. Flamingo 에서는 이를 위해서 HDFS Audit 기능
을 제공하여 사용자가 어떤 작업을 했는지를 상세하게 모니터링하고 이를 통계로 제
공한다. 관리자 입장에서는 사용자들의 파일을 다루는 작업이 매우 상세하게 모니터
링이 되기 때문에 비상시 원인을 추적할 수 있게 된다.

58
마. RStudio
R은 여전이 많은 사용자들 사용하는 데이터 분석 도구이다. Flamingo 에서는 R
과 Hadoop 을 긴밀하게 연동하여 RStudio 를 사용할 수 있도록 지원한다.

2015 Open Cloud Engine Handbook

Recommended

Recommended

More Related Content

Similar to 2015 Open Cloud Engine Handbook

Similar to 2015 Open Cloud Engine Handbook (20)

More from uEngine Solutions

More from uEngine Solutions (20)

2015 Open Cloud Engine Handbook