Embed Size (px)
Citation preview
목 차
2015 오픈클라우드엔진의 오늘과 미래.........................................2
OMG SW 공학 표준 Essence 와 Cloud Software Lifecycle Management..........................................................................17
Essencia Tutorial................................................................34
Mesos 와 Docker 기반 PaaS.................................................43
OCE Sub Project – Flamingo (Big Data Platform)............52
1
2015 오픈클라우드엔진의 오늘과 미래
1. 서론
안녕하십니까? 오픈클라우드엔진의 의장을 맡고 있는 장진영입니다. 지난 2012
년 부터 3 년간의 국산 오픈소스 플랫폼 제품들을 클라우드 컴퓨팅의 주제로
통합하고 있는 프로젝트입니다. 본 자료는 기업과 서비스 제공자 들의 클라우드
컴퓨팅 전환에 있어 요구되는 사항들을 짚어보고, 2015 년 지금까지 노력해온
오픈클라우드엔진의 제품들이 어떻게 그 요구사항들에 부합될 수 있는지에 대한
내용을 담고 있습니다.
(그림 1) 소프트웨어 딜리버리 하기
2
전통적인 소프트웨어 서비스 제공 방식은 하드웨어를 구매하는 절차에서
소프트웨어를 개발하고 그 개발을 위한 다양한 미들웨어를 설치하고 최적화하는
과정입니다. 즉, 하나의 시스템이나 서비스를 운영하기 위해서는 소프트웨어의
기획, 설계, 개발을 넘어 하드웨어, 네트워크, 미들웨어, 성능 최적화와 같은
시스템 운영과 관련한 전문성을 갖추어야 하는 부담이 존재하였습니다. 그런데
최근에 등장한 IaaS 와 PaaS 는 우리로 하여금 소프트웨어 개발 아이디어에만
집중할 수 있도록 해주고 있습니다. IaaS 와 PaaS 는 어떤 마법을 부린 것일까요?
(그림 2) DevOps
DevOps (데브옵스) 라는 Developer 와 Operator 의 합성어인 용어가 심심치
않게 최근에 들려오고 있습니다. 즉, 개발자가 운영자의 역할도 대신할 수 있는
환경이라는 이야기인데요, 그림은 그 진화과정을 보여주고 있습니다. 상대적으로
시스템이 자동화할 수 있는 영역인 빌드와 통합 그리고 테스트, 그리고 반영에
이르기까지의 사람이 개입하여 작업하던 것들을 도구들이 대신 해주면서 점점
사람은 보다 창의적이고 설계 관점의 임무만을 수행하면 되기에 이르렀습니다.
그러한 도구들에는 통합빌드를 쉽게 해주는 maven, 테스트 자동화를 위한 junit,
자동화된 주기적인 시스템 반영과 통합을 오케스트레이션하는 jenkins 등이
있습니다.
3
(그림 3) DevOps
이러한 완전한 형태의 DevOps 환경이 암시하는 바는, 사람의 개입 없이도 우리
시스템이 언제나 가용하고, 새로운 버전을 반영하더라도 멈춤이 없으며, 이를
넘어서 똑똑하게 범람하는 요청에 대비하여 시스템을 알아서 증설하고 HA 환경을
구성하고, 반대로 요청이 줄어들면 이에 따라 시스템의 사용을 절약하도록 완전한
운영의 자동화를 할 수 있는 단계를 암시합니다. 과연 이러한 자동화는 어떤
기술들에 의해 가능해질 수 있을까요?
그림 4 은 클라우드 컴퓨팅 제공 방식 중 하나인 PaaS (Platform As A Service)가
제공
4
(그림 4) PaaS Functional Landscape
하는 기능의 범위를 보여줍니다. PaaS 는 운영중인 시스템을 ‘안정되게 제공하는’
OSS (Operation Support Service)와 ‘비즈니스적으로 시스템을 판매, 마케팅,
과금 할 수 있는’ 기능들을 제공하는 BSS (Business Support Service)를
포함합니다. PaaS 는 IaaS 의 하드웨어 운영 자동화의 기반 위에서 소프트웨어
개발자가 운영에 필요한 다양한 미들웨어 운영 및 시스템 최적화에 대한 고민을
대신 알아서 해줍니다. 이 기반에는 서버가 소프트웨어로 정의되어 컨트롤
가능해진‘Software Defined X’ 세상에 우리가 태어난 덕분이라고 할 수 있습니다.
PaaS 는 DevOps 환경을 구성하기 위한 좋은 기반이 될 수 있습니다.
앞서 언급드린 것처럼, PaaS 는 애플리케이션 운영, 최적화, 확대를 위한
운영자동화 뿐만 아니라, 애플리케이션의 개발, 설계, 모델링에 필요한 도구들도
클라우드의 사용
(그림 5) IBM 의 클라우드 도입 가이드 라인
방식대로 쉽게 접근하여 사용할 수 있도록 도와줍니다. 이러한 환경은 특히
조직내에 적용했을때 효과가 높은데, 조직이 크고 클라우드 컴퓨팅을 단순
5
비용절감 수준이 아닌 제공자 측면에서 전략적으로 적용할 때일 수록, 이를 조직에
적용했을 때의 효율이 높습니다. 그림은 IBM 이 제시하는 클라우드 도입
가이드라인으로서, 특히 비즈니스 모델링 기능까지 겸비한 PaaS 인 BPM As A
Service 를 적용하면, 조직이 보유한 애플리케이션 자원들끼리 혹은 외부에서
빌려다 쓰는 SaaS 애플리케이션까지도 모델링 기반으로 통합하여 자동화된
운영을 할 수 있는 단계에 이르게 됩니다. 그러니까 모델링만으로 시스템을
만들기도 통합하기도 하면서 곧바로 운영할 수 있는 진정한 SOA 수준을 경험할 수
있게 됩니다.
(그림 6) 확장된 SaaS 성숙도 모델과 BPaaS
그러한 확장된 시나리오를 많은 시장 조사 기관들에서는 수준 높은 SaaS
도입단계로 제시하고 있죠.
2. 2015 년의 오픈클라우드엔진
이제 2015 년의 오픈클라우드엔진을 소개하겠습니다. 오픈클라우드엔진에는
자체적으로 개발된 운영지원을 위한 환경을 요즘 유행하는 도커와 아파치 메소스를
기반하여 개발되었습니다. 도커는 기존 VM 기반 가상화보다 가볍고 민첩하며,
6
이식성이 좋은 실행환경 분리를 가능하게 합니다. 아파치 메소스는 매우 유연한
클라우드 시나리오를 프레임워크화 해놓은 환경으로 이를 기반하면 빅데이터
클러스터, PaaS 운영환경 등을 마음껏 만들어 쓸 수 있습니다. 특히 기반 운영
프로세스를 자바를 기반으로
(그림 7) 2015 OCE
자체적으로 구현 가능하다는 옵션은 기존 자바 인력들을 많이 응용해온
엔터프라이즈에서 접근하지 좋은 옵션이 됩니다. 아키텍트와 개발자들은 제공자
포탈에 접근하여 모델링 툴과 개발환경을 통하여 애플리케이션을 빠르게
모델링하여 운영단계에 적용할 수 있도록 하고 있습니다.
모델 Github.com/TheOpenCloudEngine 에 가시면 오픈클라우드엔진 내에는
7
여러 개의 서브프로젝트가 존재합니다. 오픈클라우드엔진의 어떤 서브
프로젝트들이 그러한 자동화된 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 도구
8
등도 유연하게 통합할 수 있도록 해줍니다.
(그림 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 개 세분류로 진척의 상태를 균형적인
잦대로 평가할 수 있도록 해줍니다. 이는 한번 정의된 방법론의 활동과 에센스에서
9
표준적으로 정의한 Kernel 이라고 하는 기준의 매핑을 한번 해놓았기 때문입니다.
다양한 방법론을 적용하는 프로젝트를 운영할 경우 매우 유용합니다.
(그림 12) Essencia : 방법론 및 ALM 프로세스 정의
나. OCE Garuda PaaS
OCE garuda PaaS 에는 클라우드 접속만으로 애플리케이션 개발을 할 수 있는
프로그래밍 환경을 제공합니다. 이를 통하여 개발자는 각자의 개발환경을 매번
잡을 필요가 없고 개발환경의 상이함에 의한 테스팅 비용 및 운영비용을 절감할 수
있습니다. 또한 일괄적인 보안적용도 용이합니다.
10
(그림 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 하는 설정을 애노테이션으로
주입하는 등의 모델링 작업이 마쳐지면, 이렇게 완성된 요소들을 기반으로
프로세스를 편집할 수 있습니다. 또한 외부에서 연결할 수 있는 클라우드
11
애플리케이션들간의 오케스트래이션 프로세스를 구성할 수 도 있습니다. BPM
기능은 DevOps 운영 프로세스 자체의 관리 뿐만 아니라, PaaS 상에서 개발된
애플리케이션내의 프로세스 운영, 그리고 테넌트가 가입한 애플리케이션 들간의
오케스트래이션 설정을 위한 용도로도
(그림 15) uEngine-BPM : 비즈니스 프로세스 관리
광범위하게 사용되어 전체 시스템의 유연성을 제공합니다. 여기에는 국내에서
개발되어 안정화된 BPM 엔진인 uEngine BPM 최신 버전이 적용되었습니다.
PaaS 에서 개발한 클라우드 애플리케이션을 프라이빗 환경에서만 사용하는
경우라면 이 내용이 관심이 없을 수 있습니다만, 만약 외부에 서비스로 판매할
12
계획이라면 과금과 빌링, 인보이스를 만드는 행위는 매우 중요합니다.
(그림 16) Garuda-portal/bss-monetization : 가격 모형 관리 / 시뮬레이션
결국 인터넷 기반 비즈니스의 핵심은 가격경쟁이기 때문입니다. 타 제공
서비스보다 빠르게 가격산출 룰을 적용하고 안정된 쿼터제어 및 인보이스 생성 및
메일링 등은 성공우위에 핵심적인 기능입니다.
OCE Garuda PaaS 실행환경은 앞서 언급한 아파치 메소스를 기반으로
운영됩니다.
(그림 17) Garuda : OSS support core
아파치 메소스는 트위터, 구글등에서 검증된 클라우드 프레임워크입니다. 또한
여러유형의 Infra 를 하나의 가상화된 Pool 로 인식할 수 있어 Hybrid Cloud 환경을
구축할 수 도 있으며, 다양한 언어를 기반으로 커스터마이징을 할 수 있는 클라우드
시스템의 ‘스프링 프레임워크’ 라 할 수 있습니다. 향후 조직내에 쉽게
커스터마이징을 할 수 있으려면 생소한 언어를 이해해야 관리 프로세스를 변경할
13
수 있는 다른 오픈소스 기반 PaaS 에 대비하여 기업내에 적용에서는 장점이 있다
판단할 수 있습니다.
클라우드 애플리케이션들을 사용하는 조직은 하나이상의 멀티태넌시-
싱글인스턴스 애플리케이션을 어떻게 내 사용자들이 쉽게 커스터마이징하고
통합하여 사용할 수 있을지를 고민해야 합니다.
(그림 18) Operation Time Support (Integration via MSA / CSB)
OCE 의 uEngine BPMS 기반의 환경은 하나이상의 RESTful 서비스를 expose 한
애플리케이션들을 통합할 수 있도록 Pool 모델링과 WebService invocation
14
액티비티들을 드래그-앤-드롭으로 구현할 수 있도록 제공합니다. 모델링 만으로
시스템을 취득, 통합, 운영할 수 있는 환경의 핵심열쇠입니다.
(그림 19) Multi-tenancy Support
소프트웨어 개발에 있어서 싱글인스턴스-멀티테넌시를 구현하는 것은 쉽지
않습니다. OCE 에 내장된 멀티테넌시 프레임워크는 하나이상의 노드에 분산되어
요청된 워크로드가 어떤 테넌트에서 요청된 것인지 인지하고 요청된 테넌트의
브랜드, 워크플로우, 데이터 구조에 맞게 소프트웨어를 폴리폴핑 시켜주어 하나의
인스턴스로 많은 테넌트를 받아들이면서도 각자의 요건에 맞춤화를 해줍니다.
이러한 기반이 없으면 Free-mium 전략 같은 핵심 SaaS 비즈니스 전략을
구사하기 어렵습니다.
(그림 20) Business Supporting Service : Metering / Billing
사용량 측정과 과금은 클라우드 전략을 내부적인 활용수준을 넘어선 전략적으로
클라우드 비즈니스를 수행하고자 하는 기업에게는 매우 중요한 구현
고려사항입니다. 특히 언제든지 노드를 소멸가능하고 (Ephemeral) 빠르게
재생성하는 방식으로 가용성과 확장성을 제공하고자 하는 클라우드 접근
15
방법에서는 로그를 파일로 남겨서 수집할 수도 없고, 쿼터관리를 위하여 기존의
무거운 수집방법을 사용할 수 없습니다. OCE Billing/Metering 프레임워크는
이러한 고려사항을 기반하여 설계되었습니다.
3. 결론
(그림 21) Supporting Full Lifecycle of Model-driven, DevOps
앞서 소개한 많은 구현요소들은 우리 조직으로 하여금 최소한의 노력으로
최대한의 성능을 발휘할 수 있는 소프트웨어 운영을 가능하게 할 것입니다. 이를
위하여 OCE 플랫폼은 설계되어 개발됩니다.
16
지금 깃허브에서 오픈클라우드엔진을 만나보실 수 있습니다. 깃허브에는 전문가
여러분의 의견을 받을 수 있는 채널이 있습니다.
17
OMG SW 공학 표준 Essence 와 Cloud Software Lifecycle Management
1. 소개
Essencia(이하 에센시아)는 소프트웨어 공학 방법론을 정의하기 위해 SEMAT에서 제정한 방법론 제정 표준(2014 년 상반기 OMG 의 정식 표준)인 Essence(이하 에센스)를 지원하는 방법론 재정의 및 실행지원 솔루션이다. 산업계에서 UP/RUP 등의 프로세스 모델과 마르미 등 CBD 기반 개발 방법론, DW 구축 방법론 등 많은 방법론들이 혼재하고 있으나 다양한 고객의 역량과 프로젝트 상황에 맞게 최적화된 프랙티스들을 조합하여 적용하기가 어렵다. 에센스는 기존 방법론들의 낮은 재사용성과 유연성, 확장성 등을 극복하고, 특정한 상황에 맞춤화하기 쉽도록 다양하고 복잡할 수 있는 방법론을 보다 쉽게 접근하기 위해 개발되었으며, 표기법 기반의 모델을 사용하여 특정 조직에 최적화된 방법론을 제정할 수 있다는 점에서 관심을 받고 있다. 이러한 배경에서 SW 공학 프랙티스 표준의 표준으로 제정되고 있는 OMG 에센스를 통하여 최대한 쉽게 누구나 사용할 수 있는 프랙티스 재정의, 방법론 조합 및 이를 실행할 수 있도록 지원하는 도구인 에센시아를 개발하게 되었다. 에센시아를 통하여 일반 SW 개발자들도 쉽게 SW 개발방법론을 정의하여 적용함으로써 SW 생산성을 향상시킬 수 있도록 도움을 줌으로써 에센스의 보급에 및 활성화에 큰 기여를 할 수 있을 것으로 기대한다.
18
2. 에센스 실행 지원 모델
가. 에센스의 특성
OMG 에센스는 현존하는 소프트웨어 프로세스의 다양성을 고객의 요구사항에 따라 프랙티스를 최적화시키고, 누구나 쉽게 방법론 조합을 통하여 비용과 시간을 절감하기 위해 개발 되었다. 에센스의 실행 지원도구로 개발된 에센시아는 웹 기반 시스템으로 인터넷 연결만으로 실행이 가능하기 때문에 누구나 접근하기 편리할 수 있도록 하였다. 새로운 메서드를 매핑하는데 있어서 에센스의 표준화 된 Kernel(이하 커널)과 Language(이하 언어)를 이용하여 메서드를 구성하는 프랙티스를 재구성 할 수 있으며, 에센스에 사용되는 커널은 프랙티스의 기본이 되는 요소들이다. 이해관계자로부터 요구사항이 들어왔을 때, 프랙티스와 방법론을 요구사항에 맞게 커스터마이징하고, 변경이나 생성해야 할 프로젝트의 조건에 적합하게 대입하여 도구를 사용해 실행 자동화하는 것이 에센시아이다.
나. 에센스 지원 메타모델의 정의
19
에센시아는 에센스 specification 의 Practice description conformance Level 3 을 지원하는 웹 기반의 도구로 에센스를 지원하기 위하여 그림 1 과 같은 메타모델로 정의할 수 있다. 에센시아를 실행시키는 프랙티스는 조직적이고 분리되지 않아 재사용이 가능하다. 프랙티스는 에센스 커널과 그에 따른 언어로 표현 되고 여러 프랙티스가 모여 메서드를 구성한다. 프랙티스들은 서로의 중복요소 파악, 프랙티스 간의 산출물 추적성과 상호의존성 파악이 가능하고 프랙티스 통합 연계가 가능하다. High-level 의 메서드는 여러 개의 lower-level 로
구성 될 수 있고, lower-level 메서드 또한 여러 개의 high-level 의 메서드로 구성 될 수 있다. 에센시아는 Practice Author(프랙티스 저자), Method Author(메서드 저자)와 Project Stakeholders(프로젝트 이해관계자)의 3 가지 시스템 액터들이 있다.
(그림 1) 에센시아 메타모델 구성요소와 그의 관계들을 설명해주는 구성도이 메타모델은 사용자가 하나 이상의 프로젝트에 참여 중이고, 다른 소속의
파트너일지라도 여러 명이 함께 같은 프로젝트에 참여할 수 있다. 에센시아의 특성 중 하나는 순차적으로 Alpha Mapping --> Activity Space Mapping --> Practice Process Design 을 할 수도 있으나, 언제든지 되돌아가 다시 설계할 수 있고 역순이어도 상관이 없다. 이 프로세스는 프로젝트 참여자들의 이행을 돕는 소프트웨어 엔지니어링 활동의 오케스트레이션이다.
다. 에센스 지원 메타모델의 구성요소
에센스를 구성하는 표준 커널은 언어를 사용하는 필수요소가 되는 모델이다. 커널은 고객관점, 솔루션관점과 노력관점으로 분류 된다. 그리고 각 관점에 속하는
20
에센스를 지원하는 메타모델의 커널 구성요소들에는 언어에는 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 들은 프로젝트의 진행 상태를 판단할 수 있는 체크리스트를 각각 가지고 있고 체크리스트를 만족시키지 못할 경우에 언제든지 전 state 로 되돌아가 완성시킬 수 있다. Alpha 의 상태 변환에 따라 프로젝트가 특정한 시점에서 건강하게 진행되고 있는지 파악할 수 있다.
Activity space 는 커널의 세 가지 관점에서 alpha 들이 임무를 완성할 수 있는 공간이며 activity 를 포함하고 있는 활동요소이다. Activity 는 커널 관점의 상태를 변경할 수 있으며, 여러 개의 작업항목(Work Product)을 포함하고 있다. 아래 보기와 같이 activity space 들은 각 해당하는 커널의 관점에서 활동이 이루어지도록 한다. Activity space 범위 안에서 알파의 상태변화를 식별하고 상태를 실행하기 위한 과정을 추적함으로써 프로젝트가 건강하게 진행되고
21
있는지를 파악할 수 있다.‘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 : Practice Component 간의 매핑-Essence-Kernel-ActivitySpace : Practice Activity 간의 매핑
Method Author
프랙티스를 전문가가 정의한 프랙티스 들을 조합하여 기업 내에서 혹은 프로젝트 내에서 사용할 방법론을 정의하는 사람.
메서드 정의: 프랙티스 들의 조합 & 프로세스 추가 정의
ProjectStakeholder
Product Owner
프로젝트를 발주하여 프랙티스와 방법론에 의한 진행상황에 관심 있게 모니터링 하는 사람
프로젝트 모니터링 (대시보드)
Project Manager
프로젝트 관리의 책임을 가지고 정의된 방법론을 사용하여 프로젝트에 적용하는 사람.
메서드 / 프랙티스 실행프로젝트 모니터링프로젝트 워크리스트 확인, 체크포인트 실행유무 판단, 체크관계자 선택 및 관리
Developer
프로젝트 내의 요구사항을 개발하는 개발자
프로젝트 워크리스트 확인, 체크포인트 실행 유무 판단, 체크
에센시아를 구성하는 각 컴포넌트를 설계 기준을 준수하기 위하여 다음과 같이 크게 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 :
Practice Component 간의 매핑Essence – Kernel - ActivitySpace :
Practice Activity 간의 매핑
Practice
Author
메서드 정의프랙티스들의 조합 & 프로세스 추가 정의
Author
정의 밸리데이션 / 시뮬레이션
정의한 프랙티스와 메서드에 대한 무결성 검증 및 실행 시뮬레이션
Author
프로젝트
핼쓰 대시보드
프로젝트 모니터링
프로젝트 모니터링 (대시보드)Project
Stakeholder
프랙티스
오케스트레이터
메서드/프랙티스 실행
프랙티스 실행 시작 정보 입력 (프로젝트 정보 및 참여자 역할 매핑)
Project
Manager
프로젝트 워크리스트
확인, 체크포인트 실행유무 판단, 체크Project
Stakeholder
이를 유즈케이스 흐름에 따라 설명하면
1) Practice Author 가 정의한 Practice 들은 Practice Library (저장소)에 저
장됨.
2) Method Author 는 Method Composer 를 통하여 이미 정의된 Practice
Library 들을 조합하여 자신의 방법론을 정의하여 자사의 공간 혹은 퍼
블릭한 (SaaS 서비스에서 공유·판매 될 수 있는) 공간으로 업로드가
28
가능함. 3) 이렇게 정의된 Practice 와 Method 는 Essencia Practice Orchestrator
에 의하여 실행되어 Alpha State 에 따라 해야 할 일 (워크아이템) 이 제 시됨. 이때 Essencia 이외에 JIRA 와 같은 도입 고객이 기존에 사용 하 던 도구가 있는 경우, 해당 도구가 Orchestrator 역할을 수행하도록 Practice·Method 의 모델은 해당 도구로 Export 됨.
4) 해야할 일을 처리하는 과정에서 다양한 소셜 커뮤니케이션이 웹 2.0
포탈을 통하여 벌어질 수 있음.
5) 해야 할 일을 처리하기 위하여 사용할만한 도구들이 추천됨
6) 실행의 결과들이 집계되면 Alpha State 통합 대시보드를 통하여 진척
을 프로젝트 전체 이행관계자들이 확인할 수 있으며 계획 변경 등을
실시할 수 있음.
(그림 9) Essencia 의 시스템 구성요소와 액터
에센시아의 전체 아키텍처는 SOA 아키텍처로 SaaS 서비스 시에 동적 확장
과 외부 서비스들과의 매시업 서비스 등이 용이하게 구성될 수 있는 구조를
보여줄 수 있도록 그림 9 와 같이 설계되었다.
서비스 레이어는 RESTful 서비스로 바인딩하여 다종 단말 및 외부 서비스
에서의 Open API 접근을 가능하게 하며 Stateless 하게 설계하는 것을 도와,
이후 언급된 아마존 웹 서비스 클라우드를 기반한 서비스 노드 확장과 제거
를 용이하게 하는 가장 중심적인 설계 영역이며, 프랙티스 오케스트레이션
29
서비스는 프랙티스와 메서드를 오케스트레이션 해주는 서비스가 프로젝트
진척에 따른 알파의 전이, 체크포인트 등을 집계하여 워크리스트 UI 가 체크포
인트 카드를 생성할 수 있도록 RESTful 서비스이다.
(그림 10) Essencia 의 서비스 중심 아키텍처 설계대시보드 서비스
프로젝트 진척에 따라 전이된 Alpha State 들의 상태, 계획대비 실정 정보 등을 조회하는 서비스, 계획의 변경이 필요하면 계획 변경을 요청하는 RESTful 서비스.프랙티스·메서드 저장소 서비스프랙티스·메서드 컴포저에 의하여 재정의된 프랙티스와 제정된 방법론을 저장하고, 조회하고, 취득할 수 있는 저장소 서비스.외부 서비스들아마존 웹 서비스를 SaaS 서비스 플랫폼으로 활요할 예정이므로, 과금시
아마존의 Payment Gateway 서비스를 호출할 수 있음. JIRA 와 같은 외부 PMS
도구를 통하여 제정된 방법론을 오케스트레이션 하도록 지원하기 위하여 JIRA
30
의 RESTful 서비스를 사용함. 온라인 공학 도구들과 연계하여 워크아이템 발행시 추천해줄 때 외부 공학도구들의 서비스가 존재함.
다. 에센시아 주요 기능
에센시아의 처음 단계인 프랙티스 definer 는 웹 기반으로써 별도의 설치 없이 자동 구동되는 drag & drop 방식으로 설계를 할 수 있다. 프랙티스의 생성, 수정, 삭제 등 전반적인 기능 및 관리가 가능하고 정의 변경과 이력관리 또한 가능하다. 프랙티스 라이브러리 트리를 오른쪽 클릭하여 커널 요소들로(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 등의 조합을 이용하는 웹 개발 기법이다.
• BPEL (Business Process Execution Language): BPEL 은 웹 서비스로
33
구성된 비즈니스 프로세스 워크플로우를 명세 하는데 사용되는 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): 하나의 미디어 소스를 여러 미디어 형태로 확장하여 납품하는 것을 말한다.
34
• Practice Author(프랙티스 저자): 에센스 커널의 요소들을 매핑을 하여 프랙티스의 세부적인 실행을 돕고 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
Figure.17 Competency Mapping UI of Practice Role
37
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.
E) Viewing Coverage
38
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 area of Alpha State covered by corresponding Practice
F) Check In & Check Out
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 administration of 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.
- The results show a plan prepared in accordance with the milestones.
43
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 를 기본 컨테이너 라이브러리로 대체하여 제공하고 있다. 도커는 가상머신과도 차별이 되는데, 가상머신은 필요한
45
바이너리와 라이브러리 및 전체 게스트 운영체제를 모두 포함하고 있으며, 최소 수십 GB 의 메모리를 필요로 한다. 하지만 도커 컨테이너는 어플리케이션과 그 디펜던시 라이브러리만을 포함하며, 커널을 다른 컨테이너와 공유한다. 그 결과 프로세스는 호스트 운영체제의 각 사용자 공간에서 독립적으로 실행이 되며, 어느 특정 인프라에 종속되지도 않는다. 도커는 어느 컴퓨터, 어느 인프라 위에서도 동작 가능하다.
Virtual Machine Docker
(그림 1) VM 와 Docker 컨테이너의 차이
아래는 도커의 성능을 측정한 자료이다. CPU, 메모리부분에서 성능감소가 최소 0.55 % 에서 최대 0.189 %이며, 네트워크에서는 성능감소가 조금더 유발되어, 0.374 %이다. 모두 1%에 훨씬 못 미치는 성능감소량이며, 운영환경에 도입되어도 좋을 만한 수치로 보여주고 있다. 특히 메모리 읽기 쪽에서는 도커의 성능이 호스트의 성능을 능가하는 결과가 나왔는데, 이는 테스트의 오차범위내로, 실제 호스트의 보다 좋은 수치가 나올 수는 없다.
<표 1> Ubuntu 14.04 에서 Docker 1.1.2 의 성능측정
성능측정도구 호스트 Docker
46
CPU sysbench 1 0.9945
메모리 쓰기 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 레벨에서 도커타입의
47
Task 를 지원하고 있다. 메소스는 무엇보다도 클라우드에 걸맞는 Elastic Sharing 을 강점으로 내세우고 있는데, 기존의 Static Partitioning 의 경우 컴퓨팅자원을 정해진 대로만 사용하게 되어, 리소스 낭비가 존재한다는 단점이 있었다. 하지만, 메소스는 어떠한 작업이라도 모든 노드에서 실행할 수 있으며, 리소스를 앞에서부터 채워 사용하기 때문에, 리소스를 훨씬 효율적으로 사용할 수 있다는 장점이 있다. 물론 설정에 따라 동일한 노드에 실행되지 않도록 하는 옵션도 있어, 웹 어플리케이션의 로드를 여러 서버로 분산하고자 할 때도 문제없이 사용할 수 있다.
(그림 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 과 통신하여 작업을 할당해주는
50
Mesos Client 의 역할을 담당하여 명령은 모두 Master 로 부터 할당 받는다.
Cloud Watcher 는 Auto 스케일 인/아웃을 가능하게 해주는 모듈이며, 각 앱 (도커인스턴스)들의 리소스 사용상태를 모니터링하여, 설정해둔 부하보다 크거나, 작을때 자동으로 scale갯수를 유지해준다. 도커에서는 cgroups 을 이용하여 리소스의 사용량을 제공하는 REST API 가 있으며, Watcher 는 이 수치를 받아서 히스토리상의 사용량을 합산해 나간다.
나. 서비스 디스커버리
Load Balancer 부분이 서비스 디스커버리 부분이 된다. 실행된 웹 어플리케이션은 개별적인 테넌트로 인식되어, 서브 도메인을 할당받게 된다. 외부에서 웹 어플리케이션에 접근 시 서비스 디스커버리는 해당 작업을 요청과 연결시켜준다. 이 부분을 담당하는 소프트웨어는 HAProxy 이며, 앱이 추가되어나 삭제 될 때마다 설정이 갱신된다. HAProxy 는 초당 8 만건 정도의 외부요청을 처리할 수 있는 고성능 소프트웨어 프록시이다. 로드밸런서는 Public IP 를 부여 받으며 외부 도메인과 연동되어, 로드밸런싱과 프록시 기능을 동시에 수행한다.
다. HA 구성
51
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_serverbackend hello8_server balance leastconn server hello8_1 104.236.89.167:31009 check maxconn 1000backend tomcat4_server balance leastconn server tomcat4_1 104.236.89.167:31324 check maxconn 1000
(그림 6) Haproxy.cfg 의 예시
클러스터를 구성하는 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 를 사용할 수 있도록 지원한다.
59
