DevOps

2017-03-12

1

2016. 8.

수집/정리: 안종석NAIM Networks, Inc.

DevOps

2Copyright � 2015 by NAIM Networks, Inc. All rights reserved.

Contents

1. 개요

2. 아키텍처

3. 적용 사례

4. 응용 (클라우드)

2017-03-12

2


1. 개요


v 자료: Wikipedia, “DevOps.”(http://en.wikipedia.org/wiki/DevOps)v DevOps의 영역

1. 개요 1) DevOps 영역

개발

(Development)

품질 관리

(Quality

Assurance)

운영

(Technology

Operations)

2017-03-12

3


1. 개요

vDevOps는 요구분석에서 배포와 피드백에 이르는 일련의 작업들이 자동화

되고 끊임없이 반복되는 형태를 추구

2) 정의


1. 개요

§ 개발업무와 운영업무를 분리하지 않고, 하나의 업무로 다루는 개발운영(DevOps;

Development and Operations) 개념의 등장은 최근 운영 환경의 큰 변화이며, 다른

관점에서는 운영 업무가 따로 분리되어 있지 않아 무운영(NoOps)이라고도 함

§ DevOps는 SW 개발자, 운영자, SW 서비스의 품질을 관리하는 품질관리자가 SW 서비스를

개발, 빌드, 테스트, 배포, 운영에 이르는 과정을 신속하게 진행할 수 있도록 하는 방법론과

개념을 말하며 대표적인 사례로는 Netflix, Flickr, fotopedia와 같은 SW 서비스를 들 수

있고, DevOps에서는 개발 환경의 변화에서 살펴본 애자일 방법론을 사용하여 위험도를

감소시킴

§ 대규모 웹 서비스 운영은 클라우드 서비스의 운영과 개발 운영(DevOps)과 같은 개념의

발전, BaaS와 같은 개발용 클라우드 기술의 발전에 많은 영향을 주었음

2) 정의

O 데브옵스(DevOps)

- 정보시스템 개발과 운영 유지보수 관리 연계 신방법론- ICT 자동화, 융합화 추진

2017-03-12

4


v 데브옵스(DevOps)의 귀환?

v ‘개발(Development)’과 ‘운영(Operations)’의 합성어로, 애자일 개발을

실현하기 위해운영의 효율성 증진에 집중한다는 것을 의미한다. 데브옵스 트렌드는

5년 전에 등장했으며, 업체들은 애플리케이션 생명주기 관리, 자동화된 실험 도구,

데이터베이스 가상화, 배포 자동화, 구성 관리, 애플리케이션 성능 모니터링, PaaS

등 관련 기술 부문에서 데브옵스를 활성화시키고 있다.

v 현 시점에서는 데브옵스를 개발과 테스트 환경을 구축하기 위한 가장 효과적이고

현대적인 솔루션이라고 생각해도 무방하다. 데브옵스는 더 나은 애플리케이션을

필요로 하는 오늘날의 거의 보편적인 비즈니스 요구를 충족하기 위해 확장되는

양상이다.

1. 개요 2) 정의


v Wikipedia, “DevOps.”(http://en.wikipedia.org/wiki/DevOps) v 잦은 릴리스로 인한 위험의 하향 균등화

1. 개요 2) 정의

2017-03-12

5


• 2007년 벨기에 프리랜서였던 Patrick Debois

(godfather of DevOps)가 벨기에 정부의 IDC

데이터 마이그레이션 큰 프로젝트에 참여하게 됨.

• 테스팅을 담당하던 Patrick Debois는 개발

조직과 운영 조직 사이에서 엄청 힘들어 함.

• 어떻게 하면 이런 문제를 해결할까 고민.

출처: IT Revolution Press (http://itrevolution.com/the-history-of-devops/)

[Patrick Debois (godfather of DevOps)]

1. 개요

[Andrew Shafer]

• 2008년 8월, 캐나다 토론토에서 Andrew Shafer가 Agile

2008 Conference에서 Agile Infrastructure라는 주제로

발표. 참석자는 한 명. Patrick Debois

• Andrew Shafer는 발표를 건너뛰고 Patrick Debois와

함께 넓은 복도에서 Patrick이 고민하고 있던 주제에

대해서 토론.

• 이를 계기로 Patrick Debois가 구글 그룹스에 “The Agile

Systems Administration”라는 그룹을 만들게 됨.

출처: IT Revolution Press (http://itrevolution.com/the-history-of-devops/)

3) DevOps의 유래


• 2009년 O’Reilly Velocity 2009 conference에서 Flickr의John Allspaw와 Paul Hammond가 “10+ Deploys a Day: Dev and Ops Cooperation at Flickr”를 발표.

• 원격에서 이 영상을 지켜보던 Patrick이 그 자리에참석할 수 없었던 것을 트위터에서 아쉬워하자, “벨기에에 너도 Velocity 같은 거 만들어봐.”라는 트윗을보고 컨퍼런스를 만들기로 함.

• 컨퍼런스 이름을 고민하던 중 3개의 단어 “Dev”, “Ops”, “Days”을 붙여 DevOpsDays 컨퍼런스를 벨기에Ghent에서 2009년 10월 처음 개최

[2009년 Velocity 2009 Conference에서 발표 중인 John Allspaw와 Paul Hammond(https://www.youtube.com/watch?v=LdOe18KhtT4)]

[ http://devopsdays.org/ ]

• 2009년 10월말 벨기에를 시작으로 DevOpsDay컨퍼런스가 전 세계적으로 점점 확산됨.

• DevOpsDay가 확산되면서 트위터에서 관련된트윗들이 #DevOps로 확산되게 됨.

1. 개요 3) DevOps의 유래

출처: IT Revolution Press (http://itrevolution.com/the-history-of-devops/) 출처: IT Revolution Press (http://itrevolution.com/the-history-of-devops/)

2017-03-12

6


2. 아키텍처


2. 아키텍처 1) 적용 영역/공통 요소

v 적용 영역별 아키텍처 필요

v Software Supply Chain의 공통 요소

http://www.drdobbs.com/cloud/cloudmunch-continuously-delivering-devop/240152371

2017-03-12

7


v CA: 지속적인 제공 파이프라인

Link to: What are the Cool Kids Doing http://bit.ly/27QQFxh

2. 아키텍처 2) CA


v 페이팔: 하이브리드 클라우드 (퍼블릭 클라우드와 프라이빗 클라우드 연동)

2. 아키텍처 3) PayPal

2017-03-12

8


v OpenShift: PaaS(Platform as a Service)

2. 아키텍처 4) Openshift


v Open Sourceser: PaaS(Platform as a Service)

2. 아키텍처 5) OpenmSourceser

2017-03-12

9


v IHTSDO DevOps 관련 요소 순서도

2. 아키텍처 6) ihtsdo


v 프라이빗 클라우드 기반 테스트와 퍼블릭 클라우드 기반 운영

2. 아키텍처 7) 공통 IBM

2017-03-12

10


v HP의 엔터프라이즈용 DevOps 아키텍처(안)

2. 아키텍처 8) IBM


3. 적용사례

2017-03-12

11


1) 배포 주기

• 매일 2번 업데이트• 메이저 업데이트 (매주 화요일오후)

2)�Deployment�Pipeline

3. 적용사례 1) 페이스북


3)�배포 시스템

• HipHop을 통해 PHP�->�C++로 변환해서바이너리 생성. 대략 사이즈가1.5�GB.

• 1.5GB�바이너리를 전세계 서버에 push하기 위해 BitTorrent로 배포• BitTorrent는 같은노드나 랙(rack)�상에 있는 서버들로부터바이너리 조각을 복사

• 배포 시간대략 30분 (바이너리생성: 15분, 배포: 15분, 2012년 기준)• 배포는 아래릴리즈 엔지니어링팀에서진행.


2017-03-12

12


4)�소스 버젼 관리• 모든 FB�개발자는 Single�stable�branch에서 작업• 따라서, long-lived�branche들을 머징하는데 시간소비 하지않도록 함

5)�Tools• 코드 리뷰:�Phabricator�(�http://phabricator.org/ )• 테스트 자동화:�Watir (�http://watir.com/ )• 테스트 자동화: Selenium�(�https://github.com/seleniumhq/selenium )• 성능 테스트: Perflab

6)�커뮤니케이션• 자체 IRC서버로배포할때 관련자들다같이 IRC로 커뮤니케이션 (평균 700명)• 개발자가 몇분 내로답변하지 않을때는 해당개발자 개발한건 빼고배포

7)�서비스 모니터링• 배포 이후에트래픽의 변화, 자원 사용량, 프로덕션 환경의각각 세그먼트들등• 심지어 Facebook에 대한 트윗들까지모니터링함



8)�문화

• 문제가 생기면빠르게 버그수정.�롤백은잘 안함.• 개발자들의 카르마관리. 즉, 배포할 때문제를 일으킨코드를 작성한개발자들을 릴리즈팀에서평판 관리하고있음. (좋아요/싫어요버튼으로)

• 카르마 점수가낮은 개발자가코드 머지요청을 할경우 더엄격히 코드리뷰함.

Facebook 릴리즈 엔지니어링팀에 있는 Hotfix Bar에 있는 술병 사진.성공적으로 릴리즈한 이후에 한 잔식으로 자축. 이 중에 카르마가 낮은 개발자가 선물한 술들이 있음.

출처: http://www.looah.com/article/view/983


2017-03-12

13


9)�자료들

• Ars technica 기사:�http://arstechnica.com/business/2012/04/exclusive-

a-behind-the-scenes-look-at-facebook-release-engineering/

• 소프트웨어 프로세스이야기: http://swprocess.egloos.com/3009704

• The�Hacker�Way:�http://www.looah.com/article/view/738

• Robert�Johnson의 InfoQ 영상:�

http://www.infoq.com/presentations/Facebook-Moving-Fast-at-Scale

• Releng 2014� Keynote�1:�

https://www.youtube.com/watch?v=Nffzkkdq7GM#t=275

• The�Facebook�Release�Process의 InfoQ 영상:�

http://www.infoq.com/presentations/Facebook-Release-Process



1)�Deployment�Flow

• Unit�Test• Regression�Test• Canary�Analysis• Red/Black• Global�Release�(Red)

3. 적용사례 2) 넷플릭스

2017-03-12

14


2)�Branches

• 3개의 long-lived�branches�(Test/Release/Prod�branch)

• Test�branch:�test�branch는 테스트환경에 자동으로 deploy되고 개발자가해당 기능을 production에 반영하려면 release�branch로 merge

• Release�branch:�weekly�release.�Release�branch로 commit�하면 자동으로테스트 환경과 production�환경 안에 있는 staging�환경으로자동 deploy�됨.Staging�환경에서 production�환경으로 deploy는 delivery�team에 의해수행.�모두 자동화 되어있음

• Prod�branch:�Release가 끝나면 release�branch는 prod�branch로 merge.�Prod�branch는 Patch/Daily�push를 할 때기본 사용됨. 개발자가 production에 deploy할 게 있으면 weekly�release�기다리지 않고 deploy�가능한 상태로prod�branch로 직접 commit.�Prod�branch로 commit�하면 자동으로release�branch와 merge되고 실제 live�트래픽의작은 portion만 담당하는canary�cluster로 자동 deploy됨.�Canary�analysis�결과 이상없으면 “go”라고나오고 그코드는 자동으로 global하게 deploy�됨



3)�Canary를 통해서 확신 갖기

• Canary란? 실제 production�환경에서 small�subset에서 새로운 코드를돌려보고 옛날코드와 비교해서새로운 코드가어떻게 돌아가는지 보는것

• Canary�분석 작업(HTTP�status�code,�response�time,�실행수, load�avg 등이 옛날코드랑 새로운코드랑 비교해서어떻게 다른지 확인하는것)은 1000개 이상의metric을 비교해서 100점 만점에 점수를주고 일정점수일 경우만배포할 수있음.


2017-03-12

15


4)�여러 Region으로 배포 자동화하기

• Netflix는 3개의 AWS�region 사용 중 (2013년 기준)• API�deploy를 위해서는 Asgard (https://github.com/Netflix/asgard)를 이용• Red/Black�push를 사용해서 새로운코드를 production에 push

A. AWS의 Auto�Scale�Group(이하 ASG)을 이용해서 Red/Black�push 함B. 기존의 ASG 인스턴스의 10% 더한새로운 ASG�생성. 새로운코드와 기존의 코드를나란히 생성 (red/red�상태)

C. 그런 후기존의 ASG에 트래픽을막음 (red/black�상태)D. 문제없으면 기존의 ASG�삭제. 문제 생기면기존의 ASG로 롤백

5)�커뮤니케이션• 새로운 코드를 production에 push 될 때에는팀 전체에메세지 보내도록 XMPPbot을 만듬



6)�자료들

• Netflix�API�배포하기 (Tech�Blog):http://techblog.netflix.com/2013/08/deploying-netflix-api.html

• Self�service�build�and�deployment�at�Netflix:�http://www.slideshare.net/garethbowles/self-servicebuilddeploymentagile2013?related=2

• Dianne�Marsh�(Director�of�Engineering�for�Cloud�Tools):�http://www.slideshare.net/diannemarsh/from-code-to-the-monkeys-continuous-delivery-at-netflix?related=2

• Continuous�Delivery�at�Netflix:�http://www.slideshare.net/robspieldenner/continuous-delivery-at-netflix?related=1


2017-03-12

16


1)�SRE�(Site�Reliability�Engineering)

• Google의 DevOps?�SRE�(Site�Reliability�Engineering)• SRE의 업무 자체는전통적인 operation�조직이 하는업무를 담당하지만그 구성원을소프트웨어 백그라운드가진 사람과시스템 백그라운드를가진 사람 50:50�비율로 구성함.�

• SRE를 hire�할 때도 ops�skill을 가진 개발자를구함.• 그리고,�SRE의 업무도운영 업무반,�자동화를위해 개발업무가 반이라고함.

3. 적용사례 3) 구글


• Developers�run�their�own�service.�(self-support)- SRE�creates�tools�and�services�to�make�this�possible.

• Some�services�get�allocated�an�SRE-team:�(high�priority�services�only)- Developers�have�run�it�for�6+�months.- Must�pass�a�“Hand-off�Readiness�Review”�

before�Hand-off.�- In�the�future�goes�back�to�self-support�if�

“things�go�wrong�a�lot”.

2)�SRE�Methodology�


2017-03-12

17


• Type�and�frequency�of�pages�/�alerts

• Maturity�of�the�monitoring�infrastructure:�pages,�dashboard,�etc

• System�architecture�review

• Release�process

• Bug�counts�/�severities

• Production�hygiene

3)�Hand-off�Readiness�Review



4)�Canary


2017-03-12

18


4)�Canary



5)�The�“Reliability�Budget”


2017-03-12

19


6)�Joint�Responsibility



1) “10+�deploys�per�day”�동영상

• Flickr의 John�Allspaw(Ops�head)와 Paul�Hammond(Dev head)가Velocity�2009년에서 발표한 영상

3. 적용사례 4) 플리커

2017-03-12

20


2)�고정 관념 탈피

• [기존의 고정관념]�Dev의 업무는 새로운기능을 추가하는것,�Ops의 업무는 사이트를 안전하고빠르게 만드는것

• John�Allspaw와 Paul�Hammond가 말하길…�No!!�둘 다 아니다!!

• Ops와 Dev의 업무는 비즈니스가 가능하게 하는 것이다.�비즈니스는변화를 요구한다.�그럼,�어떻게 해야지?

• 사이트의안정성을 위해서 변화를 줄어던가? 필요할 때마다 변할 수 있게하던가?둘 중에 하나를 선택해야한다.�선택은?



2)�고정 관념 탈피

• 선택은 Tools과 Culture로 변화의 Risk를 낮추는 것


2017-03-12

21


3)�Tools

• Automated�infrastructureA. Flickr에서 사용하고있는 Tools:�Chef,�Cfengine,�Puppet,�FAI,�Cobbler�등

• Shared�version�controlA. Dev/Ops�모든 소스코드나 환경설정 등이다 볼수 있게 version�control�공유

• One�step�build�and�deployA. 모든 빌드작업을 자동화하고한번에 할수 있는툴 제공B. 누가, 언제, 무엇을 배포했는지 한눈에확인 가능



3)�Tools


2017-03-12

22


3)�Tools

• Feature�flags: 새로 개발한 기능을설정으로 언제든 on/off�할 수 있음• Trunk�기반의 개발:�Paul�Hammond의 Always�ship�trunk�참고.�http://www.paulhammond.org/2010/06/trunk/alwaysshiptrunk.pdf

• Bucket�testing• Dark�launches• Shared�metrics• IRC�and�IM�robots

• Dev,�Ops�모두 IRC와 IM�robots으로 build,�deploy,�alerts�monitors�등을공유 받음



4)�Culture

• Respect: 개발, 운영 서로전문성을 인정하고존중• Trust: 서로 신뢰하는문화• Healthy�attitude�about�failure• Avoiding�Blame

문제가 발생시서로 잘못을따지지 말고우선 해결하는데 집중하고서로의 전문성을존중하고 신뢰하는문화


2017-03-12

23


v Etsy:

수제품, 사진, 그림, 빈티지 물건을 판매할 수 있는 마켓플레이스

• 2008 (40+ engineers)ü Painful mergeü Hand off to deployersü Deploy, site downü Roll back deployü Fix bugs, go to step 2

• 6년후엔? 하루에 배포만 매일 50회 이상. 매일 매일• 2014 (400+ engineers)

ü Small changesets, deployed frequentlyü Engineers deploy (not just engineers, but also Designers, Dogs)ü Deploys are fastü Changes behind flagsü Copious graphs/metricsü Fix fast & roll forward

3. 적용사례 5) Etsy


4. 응용

2017-03-12

24


v (예) 매니지드 서비스 플랫폼

SOFTWARE DEVELOPMENT LIFECYCLE

DEV QA/UA PROD

SCM

CI/CD

AUTOMATION

PLATFORM

Source ControlContinuous Build

Release/Change Management

SOFTWARE DEVELOPMENT LIFECYCLE

4. 응용 1) 클라우드


• 개발하고자는 웹 사이트 혹은 서비스를 구축할 때 필요한 개발환경을

package화 하여 제공되는 서비스

• 개발 환경과 운영 환경을 동시에 제공할 수 있으며 개발 환경은 형상관리 Tool인

SVN 또는 git으로 구성이 되며 배포환경과 같이 제공

• 운영 환경은 웹 서비스를 제공하기 위한 대표적인 오픈소스들로 구성이 되며

Apache, ngnix, Tomcat, MySQL, Maria DB 등으로 구성 (Web, WAS 환경은

End-User가 직접 선택할 수 있도록 다양한 옵션을 제공)

v DevOps PaaS 서비스란?


2017-03-12

25


v 엔터프라이즈 환경: 애플리케이션 요구에 적합한 클라우드 자원

v 텔코 (Telco) 환경: 오피스의 네트워크 기능 가상화 기반 데이터센터화

요구 조건

성능

비용

보안

준수

위치

벤더

기존 DC

애플리케이션

App 1

App 2

App 3

App 4

App 5

App 6

App 7

자원 풀

퍼블릭 클라우드 1

퍼블릭 클라우드 2

프라이빗 클라우드

가상화

베어메탈

App 1

App 2

App 3

App 4 App 5

App 6 App 7

비디오헤드엔드

모바일게이트웨이

PE / 서비스에지

모바일 / 태블릿

셋탑박스 / TV

CE Router / 브로드밴드

모바일 / 태블릿

셋탑박스 / TV

CE Router / 브로드밴드

서비스 1

서비스 2

컨텐츠 2

컨텐츠 1

SP’sCloud

네트워크기능 가상화

(NFV)


50Copyright � 2016 by NAIM Networks, Inc. All rights reserved.IMS (IP Multimedia Subsystem)

Cloud

요청요청

응답응답

• 웹 요청

– 초 단위 지연 허용– 서버가 접속 유지를 위한 전송 가능– 응답의 유실 발생

v 엔터프라이즈 (Enterprise) : 요청/응답 기반 클라우드 서비스v 텔코 (Telco): 실시간 멀티미디어 서비스

Telco Cloud

시그널링시그널링

미디어미디어

시그널링시그널링

미디어미디어

• 실시간 멀티미디어 애플리케이션

– 지연과 유실에 민감– 음성의 경우 LTE는 200 ms를 넘지 않아야– 초단위 지연 발생시 음성 품질 저하를 감지

Cloud Telco Cloud

웹 기반 IMS

Stateless Stateful

낮은 업링크 사용 / 높은 다운링크 사용

높은 업링크 / 다운링크 사용

TCP UDP

TLS IPsec

프로세싱 집중 고려 지속적인 프로세싱

큐 처리 즉각 처리

컨텐츠의 캐시화 실시간 스트리밍

5-7 계층 4-7 계층


2017-03-12

26


v 클라우드 사업자 솔루션: 자사를 위한 하이브리드 클라우드 솔루션v 공개 기반 기술: 오픈스택을 기반으로 확장하는 것이 추세v DevOps 기반 멀티 클라우드 통합 관리 자동화 필요



v 포털 서비스 제공v 멀티 퍼블릭 클라우드 연계 서비스v 부가 서비스 생태계v 매니지드 클라우드 기반 DevOps

퍼블릭클라우드

멀티 사이트 적용

백업 / 복제

SSD 스토리지

오브젝트스토리지

10G / 40G 이더넷백본

클라우드 컴퓨팅

Security as a Service (SaaS)

네트워크 서비스

가상 데이터센터L2/L3

클라이언트데이터센터


2017-03-12

27


v SLA 유지v 온프레미스(On-premise)와 클라우드 간의 통합관리v 상호 운영 가능한 클라우드간 경유 적용v 비용 절감v 실시간 프로비젼(Provision)과 스케일(Scale)

프라이빗 클라우드 (Private Cloud)퍼블릭 클라우드 (Public Cloud)

멀티 클라우드 기술 적용 기반

하드웨어 인프라

Dev

Ops

온프레미스(On-premise)

레가시(Legacy)

베어메탈(Bare Metal)

멀티 클라우드 통합 관리

멀티 클라우드 통합 서비스 관리자

SLA인벤토리

관리 적용/배포 프로비저닝서비스탬플릿

거버넌스정책 인증

기타


54Copyright � 2016 by NAIM Networks, Inc. All rights reserved.Google 2015

에지클라우드

적용

코어클라우드

적용

v 클라우드 서비스 환경 고려

• 데이터 플레인 분리/테이블의 캐시 사용/마이크로 세그먼트 구조 바람직

• 텔코는 데이터센터 내에서 처리 가능한 서비스 제공 구조(에지 클라우드)


2017-03-12

28


CORD

Leaf-Spine패브릭

BBUs(Multi-RATs)

Front- Haul To RRUs Back Haul RRU

ResidentialResidential Software

Stack vOLT, vSG, vRouter,

vCDN

5GMobility

Stack over Multiple

RATs

4GMobility Software

Stack : vBBU, VOD, vCDN,

vDNS

Host 1Host 1

Host 2Host 2

Host 3Host 3

가상 계층가상 계층

VNF-2C

VNF-2C

VNF-2C

VNF-2C

VNF-2C

VNF-2C

VNF-1VNF-1 VNF-3VNF-3

라우터1

라우터2

OperatorMobile Core

vSG (Virtual Subscriber Gateway)BBU (Baseband Unit) RRU (Remote Radio Unit)

v CORD 구성: ONOS(SDN 컨트롤러), OpenStack, XOS and more

RESTful API / TOSCARESTful API / TOSCA TOSCA, Yang

RAT (Radio Access Technology)

TOSCA (Topology and Orchestration Specification for

Cloud Applications)

4. 응용 2) Telco 클라우드


v 소프트웨어 스택 (Software Stack)

일반 서버에서구동하는 컨테이너

가상 네트워크와 필요한 플로우

제어애플리케이션

VNFaaS

일반 서버에서구동하는 가상머신

가상 네트워크와 필요한 플로우

제어애플리케이션

VNFaaS


2017-03-12

29


v 표준 TOSCA 기반 오케스트레이션

RESTful API / TOSCA

표준 TOSCA 기반오케스트레이션OSS 시연 동영상



TOSCA YANG

기관 OASIS IETF

적용 기반 IT, 애플리케이션 네트워킹

목적

애플리케이션 중심, 애플리케이션과 관련 가공 기능 적용, 확장성(Scale), 복구(Healing), 업그레이드, 설계 싯점 초점, 이행을 위한 기술(Description)

운영중인 네트워크 기기와 애플리케이션 컨피규레이션, 운영중을 초점, 블랙박스

슬로건 Bring them up and running Configure them

예제CRM 시스템, SQL DB, IPTV 서버, 가상 네트워크 템플릿 적용

새로운 IPTV 서비스 프로비져닝

운영설치, 시작, 컨피규레이션, 확장성, 복구, 업그레이드, 중지, 삭제

시작한 후 / 정지 전에 운영과 컨피규레이션,

작업 방법기업은 템플릿을 작성하고, 사용자는 템플릿린스턴스를 작성함

표준 기구와 기업은 모델을 작성하고, 사영자는 인스턴스를 작성 한다.

v TOSCA와 YANG

• CORD와 운영의 인터페이스 표준 TOSCA와 YANG

YANG (Yet Another Next Generation)TOSCA (Topology and Orchestration Specification for Cloud Applications)


2017-03-12

30


v SDN 컨트롤러 : CORD는 클라우드 네트워킹을 위한 SDN 컨트롤러 사용(ONOS)



멀티벤더프라이빗클라우드

해외 퍼블릭클라우드

국내 퍼블릭클라우드

인프라기능

자동화 / 최적화 기능

멀티 벤더멀티 클라우드Orchestration

Platform

애플리케이션 요구 사항

표준 기반 클라우드애플리케이션 요구 기능

App / DB / 컴퓨팅 / 네트워크/ 스토리지 / 정책

v 요구 기능 : App, DB, 컴퓨팅, 네트워크, 스토리지, 정책, 기타v 인프라: 오픈스택, AWS, Azure, IBM, VMware, 기타


2017-03-12

31


프로비젼

(Provision)

설치

(Install)

구성

(Configure)

적용

(Deploy)

모니터

(Monitor)

성능 제어

(Scale)

v DEVOPS 기반 관리의 자동화v 자동화를 위한 플러그인 허용



호스트

미들웨어

앱 모듈

연결

v 멀티 클라우드 오케스트레이션 : 표준 기반 GUI 서비스

생성 소스(TOSCA)

적용 후 맵(오픈스택)


2017-03-12

32


TOSCA Template

or CSAR

• TOSCA-Parser

Heat Orchestration Template

(HOT) Deploy

TOSCA Types

Validation

TOSCA Nodes

Tests

• Heat-Translator

Map

Validation

Generate

Tests

https://github.com/openstack/heat-translatorhttps://pypi.python.org/pypi/heat-translator

https://github.com/openstack/tosca-parserhttps://pypi.python.org/pypi/tosca-parser

Heat

v TOSCA (OASIS open standards consortium)• TOSCA Simple Profile for Network Functions Virtualization (NFV) Version 1.0

Committee Specification Draft 03 (17 March 2016)

• 토스카 파서(TOSCA-Parser): Parser for TOSCA Simple Profile in YAML

• 히트번역기(Heat-Translator): An OpenStack project to map and translate non-

Heat (e.g. TOSCA) templates to Heat Orchestration Template (HOT)

CSAR (Cloud Service Archive)

TOSCA YAML HOT YAML

TOSCA (Topology and Orchestration Specification for Cloud Applications)

• Tacker is an OpenStack project forN FV O rchestration and VN F M anagem ent using ETSI MANO Architecture

• M itaka w /TO SCA -Parser



v Tacker: 멀티 사이트를 위한 오픈 NFV 오케스트레이터 (OpenStack)

• VNF 라이프 사이클 관리

ü 프레임워크 모니터

ü 프레임워크 컨피규레이션

• VNF 카탈로그 관리

ü TOSCA 탬플릿 지원

• EPA 지원

ü CPU-Pinning, Huge Page, NUMA awareness, SR-IOV

• 자원 생성 자동화

ü Flavor, Network and Image creation

v Kingbird: 멀티 리전을 관리하며 자원을 동기화v Tricircle: OpenStack L2/L3 네트워크를 연결하여 volume/VM 이동, 이미지

배포, 글로벌 자원 가시화 분산 쿼타 관리

EPA (Enhanced Platform Awareness) NUMA (Non-uniform memory access)


2017-03-12

33


v VMware의 오버레이 SDN ‘vCloud’ NFV Platform (예)

§ 가상 환경의 SFC 지원: 물리적 경로는 언더레이 SDN 장비에서 구현

5. 테스트베드 모니터링


DevOps

Software

Transcript of DevOps