DevOps!! 도데체 왜, 어떻게 할까??

본 문서는 나눔고딕으로 작성되었습니다 .

GS Shop 서문래 프로젝트 4 탄2016 년 6 월 3 일 ( 금 )

김요섭 (chingu94@gmail.com)

FB, Flickr, Etsy, Netflix 등의 사례 중심으로 살펴본 DevOps!

DevOps!! 도데체 왜 , 어떻게 할까 ??

Speaker

“ 안녕하세요 . 김요섭입니다 .”

• 평범한 가장 , 두 아이의 아빠• 전 ) 위메프 플랫폼개발실 실장• 전 ) 앱디스코 CTO• 전 ) UofN, Kona Sr. Software Engineer• 전 ) Yahoo! APAC Listing/Map Eng. Leader• 전 ) Yahoo! KR Local/Map Eng. Leader• 전 ) Portaltone 개발팀장

https://www.facebook.com/kim.joseph.75https://www.linkedin.com/in/josephkim75

그럼 , 도데체 DevOps 뭘까요 ?2

FB, Flickr, Etsy, Netflix, Google 의 적용 사례3

왜 DevOps 를 해야 할까요 ?1

위메프의 적용 사례4

왜 DevOps 를 해야 할까요 ?1

1. 왜 DevOps 를 해야 할까요 ?

“ 세상이 달라졌습니다 .”

2015 년 5 월말에 발표된

KPCB 의 “ INTERNET TRENDS 2015” 보고서에서

출처 : http://www.kpcb.com/internet-trends

지난 20 년 동안 가장 큰 변화는…

People Connected 24/7 with Mobile Devices

이런 사용자의 변화는 트랙픽의 변화로 이어지고…

(http://www.reactivemanifesto.org/)Reactive Manifesto 를 보면

These changes are happening because application requirements have changed dramati-callyin recent years.

Only a few years ago a large application had tens of servers, seconds of response time, hours of offline maintenance and gigabytes of data.

Today applications are deployed on everything from mobile devices to cloud-based clus-ters running thousands of multi-core processors. Users expect millisecond response times and 100% uptime. Data is measured in Petabytes.

Few years ago Today

Large application?

Tens of servers Thousands of multi-core processors

Seconds of response time Millisecond response timeHours of offline maintenance 100% uptime

Gigabytes of data Petabytes of data

Today's demands are simply not met by yesterday’s software architectures.

또 , 모바일은 비지니스 환경도 바꿨습니다 .

온라인 시대 모바일 시대시장 상황 이미 시장의 강자들이 패권 장악 아직은 춘추 전국 시대 . 강자가 계속

바뀜새로운 기회 새로운 플레이어의 진입이 쉽지 않음 벤쳐 , 대기업 등 새로운 기회 찾아

경쟁 상황 기존 강자들 위주로 경쟁 상황 변화가 많지 않음

매우 치열함 . 벤쳐 , 대기업 너도 나도 모바일로…

결국 , 모바일 시대의 사용자의 변화는

기존의 온라인에서와

다른 개발 방법 , 아키텍쳐 등을

요구하게 됩니다 .

그럼 , 이런 시대에

Google, Facebook, Amazon 과 같은

회사들은

어떻게 대응하고 있을까요 ?

The Hacker Way

Facebook IPO 때에 마크 주커버그가 투자자들에게 보낸 편지

• Focus on Impact• Move Fast• Be Bold• Be Open• Build Social Value

“ 끊임없는 개선과 이터레이션 방식… 빠른 출시와 작은 이터레이션을 통해서 배움으로써 장기적으로 최고의 서비스를 만들려고 노력…” “ 완성이 완벽보다 낫다 . (Done is better than perfect.)““ 코드가 논쟁보다 낫다 . (Code wins arguments.)”“ 최고의 아이디어와 최고의 구현이 늘 이겨야 한다 .”

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

출처 : http://www.google.com/intl/ko_KR/about/company/philoso-phy/

Ten Things Google Knows To Be True

• Focus on the user and all else will follow• It’s best to do one thing really, really well.• Fast is better than slow.• Democracy on the web works.• You don’t need to be on your desk to need an answer.• You can make money without doing evil.• There is always more information out there.• The need for information crosses all border.• You can be serious without a suit.• Great just isn’t good enough.

Amazon Leadership Principles

1. Customer Obsession2. Ownership3. Invent and Simplify…

Moving Fast2013 년 한해 동안 신규 서비스 280 개 출시

출처 : http://www.slideshare.net/diannemarsh/from-code-to-the-monkeys-continuous-delivery-at-netflix/

Dianne Marsh (Director of Engineering, Netflix) said…

공통점을 뽑아보면…

Moving Fast!!Focus on Customer!!

공통점을 뽑아보면…

즉 , 고객 중심으로빠르게

움직이고 있다 .

Company Deploy Frequency Deploy Lead Time Reliability Customer Re-sponsiveness

Amazon 23,000 / day Minutes High High

Google 5,500 / day Minutes High High

Netflix 500 / day Minutes High High

Facebook 1 / day Hours High High

Twitter 3 / week Hours High High

Typical enterprise Once every 9 months

Months or quarters Low / Medium Low / Medium

출처 : 도서 The Phoenix Project (2013 년 )

그럼 , Amazon, Google, Netflix, Facebook, Twitter 는

얼마나 빨리 움직이고 있을까요 ? Measuring DevOps and IT Perfor-mances

- Deploy frequency (Note: NOT deliv-ery)

- Mean Time to Recover (MTTR)- Lead Time for Changes

더 무서운 건

더 빨라지고 있다는 것 !!!

• 하루에 한번 배포 (2013 년 ) => 하루에 두 번 배포 (2014년 )

• 하루에 30+ (2013 년 )• 하루에 50 번 배포 (2014 년 3 월 ) – Qcon London• 하루에 80 ~ 90 번 배포 (2014 년 4 월 ) – Chef Conf

출처 : Releng 2014 – Keynote (https://www.youtube.com/watch?v=Nffzkkdq7GM)

• GOTO Berlin 2015 에서 Dr. Nicole Forsgren (Chef 에서 the State of DevOps study 를 이끌고 계신 ) 의 DevOps: Next 강연에서…

출처 : GOTO Berlin 2015 에서 DevOps: Next (https://www.youtube.com/watch?v=dMwGfRINpz0)

• GOTO Berlin 2015 에서 Dr. Nicole Forsgren (Chef 에서 the State of DevOps study 를 이끌고 계신 ) 의 DevOps: Next 강연에서…

출처 : GOTO Berlin 2015 에서 DevOps: Next (https://www.youtube.com/watch?v=dMwGfRINpz0)

왜 DevOps 를 해야 할까요 ?

빠르게 변하는 비지니스 환경과 사용자의 필요에 기민하게 대처하고

결국은 비지니스가 계속 살아남기 위해서…

그래서 , Damon Edwards (DTO solutions inc.) 가 말하길…

“ DevOps is not about a technology, DevOps is about a business prob-

lem.”

그럼 , 도데체 DevOps 뭘까요 ?2

2. 그럼 , 도데체 DevOps 는 뭘까요 ?

이런 말은 많습니다 .DevOps is NOT …

- A Job title.- An Organizational Unit. - A automation.- A tool.- Simply combining Dev &

Ops.…..

But, there is not a clear definition yet.

WHAT???

• DevOps 정의 (Wikipedia)

DevOps 는 소프트웨어 개발자와 정보 기술 전문가 간의 소통 , 협업 및통합을 강조하는 개발 방법론 .

데브옵스는 소프트웨어 개발 조직과 운영 조직간의 상호 의존적 대응이며 소프트웨어 제품과 서비스를 빠른 시간에 개발 및 배포하는 것을목적으로 한다 .

DevOps 좀 더 알아가기

1) DevOps 의 유래 (DevOps 이름을 갖게 된 역사 )2) CAMS or CALMS3) Devops.com 의 정의4) DevOps 의 foundations5) The Three Ways Principles (Gene Kim)6) DevOps Area Practices (Patrick Debois)

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

DevOps) 가 벨기에 정부의 IDC 데이터 마이그레이션 큰 프로젝트에 참여하게 됨 .

• 테스팅을 담당하던 Patrick Debois 는 개발 조직과 운영 조직 사이에서 엄청 힘들어 함 .

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

1) DevOps 의 유래 ( 그 이름을 갖게 된 역사 )

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

[Patrick Debois (godfather of DevOps)]

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

Agile Infrastructure 라는 주제로 발표 . • 안타깝게도 참석자는 딱 한 명 . 그가 바로 Patrick

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

Debois 와 함께 넓은 복도에서 Patrick 이 고민하고 있던 주제에 대해서 토론 . • 이를 계기로 Patrick Debois 가 구글 그룹스에 “ The Agile Systems Administration” 라는 그룹을 만들게 됨 .

[Andrew Shafer]

• 2009 년 O’Reilly Velocity 2009 conference에서 Flickr 의 John Allspaw 와 Paul Ham-mond 가 그 유명한 “ 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 월말 벨기에를 시작으로 De-vOpsDay 컨퍼런스가 전 세계적으로 점점 확산됨 .

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

By Damon Edwards (DTO Solutions inc.) - https://www.youtube.com/watch?v=o7-IuYS0iSE&feature=youtu.be

• From practitioners, by practition-ers

• An experience-based movement• Decentralized and open to all

DevOps 의 역사가 주는 교훈

2) CAMS or CALMS

- https://www.chef.io/blog/2010/07/16/what-devops-means-to-me/- http://devops.com/2015/05/13/surprise-broad-agreement-on-the-definition-of-devops/- http://itrevolution.com/devops-culture-part-1/

Devops is about CAMS. (John Willis)

- C: Culture- A: Automation- M:Measurement- S: Sharing- L: Lean ( 나중에 추가 )

• CAMS: 2010 년 미국에서 처음 열린 Devopsdays in Mountainview 에서 Damon Adwards 와 John Willis 가 CAMS 에 대해 소개

• CALMS: 나중에 Continuous Delivery 의 저자 Jez Humble 이 L (Lean) 을 추가

3) Devops.com 의 정리

• DevOps exists to help the business win• The scope is broad, but centered on IT• The foundations are found in Agile and Lean• Culture is very important• Feedback is fuel for innovation• Automation helps

http://devops.com/2015/05/13/surprise-broad-agreement-on-the-definition-of-devops/

4) DevOps 의 foundations

Lean 은 낭비를 제거함으로 어떻게 고객에게 가치를 빠르게

제공할 수 있을까에 대한 생각이자 사고 방식 (Lean Thinking)

Lean 의 핵심은 끊임없이 문제를 해결하고 개선하는 것

•Lean

•Lean Software Development Principles1. Eliminate waste ( 낭비를 제거하라 )2. Amplify learning ( 배움을 증폭시켜라 )3. Decide as late as possible ( 가능한 늦게

결정하라 )4. Deliver as fast as possible ( 가능한 빨리 de-

livery 하라 )5. Empower the team ( 팀에 권한을 주라 )6. Build quality in (quality 를 만들어 가라 )7. See the whole ( 전체를 보라 )

•OODA loop (OODA 주기 – 판단 및 결심 주기 )존 보이드 대령이 한국전에서 F-86 과 MiG-15 간의 전투에서 어떻게 10:1 의 일방적인 승리를 얻을 수 있었나 분석하고 제시했던 이론 . 존 보이드 대령은 현대 전쟁 이론의 아버지라 일컫음 .

• Competed Observation: 경쟁적 관찰• Orientation: 상황 판단• Decision: 결심• Action: 행동

http://itrevolution.com/the-three-ways-principles-underpinning-devops/

5) DevOps 를 지탱하는 the Three ways principles (Gene Kim)

• Gene Kim 은 DevOps 의 Cookbook 인 “ the Phoenix Project” 의 저자

Robert Johnson(Engineering Director at FB) 의 InfoQ 영상 (2010 년 5월 )

“ 만약 어제밤에

제가 아이디어가 하나 있었다면 ... 그걸 오늘 아침에 코딩해서…

오후에 그걸 사이트에 올릴 수 있구요…

내일이면 데이타를 얻을 수 있습니다 . 제가 일반적인 다른 시스템에서

일년동안 배울 수 있는 것보다 훨씬 더 많은

것들을 불과 몇 주 안에 배웠습니다 .”

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

• DevOps 의 실례

http://www.jedi.be/blog/2012/05/12/codifying-devops-area-practices/

6) DevOps Area Practices (Patrick Debois)

• 넓은 의미의 DevOps 는 IT 를 뛰어넘어 모든 조직 (HR, Finance…) 의 collabora-tion 과 optimization 을 지향 .

• 최근에는 DevQAOps, DevOpsSec, DevSecOps, BizDevOps 등 기존의 DevOps에서 점점 확대되는 추세 (IT Performance => Org. Performance)

• 좁은 의미의 DevOps (Devops lite) 는 Dev 와 Ops 에 집중

• Patrick Debois 의 4 Areas• 간단히 , Dev 는 Project, Ops 는 Product 로 봄 .

• Practical examples• Practices => Patterns => Principles

Areas Practical examplesArea 1 Extend delivery to production CI/CD. chef/puppet 같은 configuration management 쓰는 것

등등Area 2 Extend operations feedback to

projectProduction(Ops) 의 Logfiles, metrics, information 을 Project(Dev) 에 공유하는 것

Area 3 Embed Project knowledge into Operations

Project(Dev) 릴리즈 후에 Project(Dev) 도 같이 pagers 를 차고 Project(Dev) 의 knowledge 를 Production(Ops) 에 공유하고 같이 책임지는 것

Area 4 Embed Operations knowledge into Project

Project(Dev) 초창기에 Production(Ops) 도 같이 참여시키고 Pro-duction(Ops) 업무를 Project(Dev) backlog 에 추가하는 것

“You can’t directly change culture. But you can change behavior, and behavior becomes culture”

– Lloyd Taylor VP Infrastructure, Ngmoco

- http://www.jedi.be/blog/2012/05/12/codifying-devops-area-practices/

• Patrick Debois 의 4 Area 와 CAMS 를 같이 보면…6) DevOps Area Practices (Patrick Debois)

FB, Flickr, Etsy, Netflix, Google 의 적용 사례3

3. FB, Flickr, Netflix, Etsy, Google 의 적용 사례

페이스북은 어떻게 개발하고 배포할까 ?

1) 자료들

• Ars technica 기사 : http://arstechnica.com/business/2012/04/exclu-sive-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

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

3) Deployment Pipeline

출처 : http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6449236

4) 배포 시스템• HipHop 을 통해 PHP -> C++ 로 변환해서 바이너리 생성 . 대략 사이즈가

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

조각을 복사• 배포 시간 대략 30분 ( 바이너리 생성 : 15분 , 배포 : 15분 , 2012 년 기준 )

• 배포는 아래 릴리즈 엔지니어링팀에서 진행 .

[Facebook 릴리즈 엔지니어링팀 사진 . 출처 : http://www.looah.com/article/view/983]

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

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

7) 커뮤니케이션• 자체 IRC 서버로 배포할 때 관련자들 다같이 IRC 로 커뮤니케이션 ( 평균

700명 )• 개발자가 몇 분 내로 답변하지 않을 때는 해당 개발자 개발한 건 빼고 배포

8) 서비스 모니터링• 배포 이후에 트래픽의 변화 , 자원 사용량 , 프로덕션 환경의 각각

세그먼트들 등• 심지어 Facebook 에 대한 트윗들까지 모니터링함

9) 문화• 문제가 생기면 빠르게 버그 수정 . 롤백은 잘 안함 .• 개발자들의 카르마 관리 . 즉 , 배포할 때 문제를 일으킨 코드를 작성한

개발자들을 릴리즈팀에서 평판 관리하고 있음 . (좋아요 /싫어요 버튼으로 )• 카르마 점수가 낮은 개발자가 코드 머지 요청을 할 경우 더 엄격히 코드

리뷰함 .

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

1) 그 유명한 “ 10+ deploys per day” 동영상• Flickr 의 John Allspaw(Ops head) 와 Paul Hammond(Dev head) 가 Velocity 2009 년에서 발표한 영상

출처 : 유투브 동영상 : https://www.youtube.com/watch?v=LdOe18KhtT4

2) 고정 관념 탈피

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

• John Allspaw 와 Paul Hammond 가 말하길… No!! 둘 다 아니다 !! • Ops 와 Dev 의 업무는 비즈니스가 가능하게 하는 것이다 . 비즈니스는

변화를 요구한다 . 그럼 , 어떻게 해야지 ?

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

출처 : http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr

2) 고정 관념 탈피

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

3) Tools

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

bler 등

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

trol 공유

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

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 moni-tors 등을 공유 받음

4) Culture

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

결국 , 문제가 났을 때 서로 손가락질 하거나 잘잘못 따지지 말고 우선 해결하는 데 집중하고 서로의 전문성을 존중하고 신뢰하자 !!

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

(http://www.slideshare.net/beamrider9/continuous-deployment-at-etsy-a-tale-of-two-approaches)

1) 자료들

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

• Self service build and deployment at Netflix: http://www.s-lideshare.net/garethbowles/self-servicebuilddeploymentag-ile2013?related=2

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

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

출처 : http://techblog.netflix.com/2013/08/deploying-netflix-api.html

2) Deployment Flow

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

3) 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 됨

4) Canary 를 통해서 확신 갖기

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

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

5) 여러 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 로 롤백

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

XMPP bot 을 만듬

1) Google 의 DevOps? SRE (Site Reliability Engineering)

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

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

출처 : https://landing.google.com/sre/interview/ben-treynor.html

• 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 Re-view” before Hand-off.

- In the future goes back to self-sup-port if “things go wrong a lot”.

출처 : SRE@Google: Thousands of DevOps Since 2004 (https://www.youtube.com/watch?v=iIuTnhdTzK0)

2) SRE Methodology

• Type and frequency of pages / alerts• Maturity of the monitoring infrastruc-

ture: pages, dashboard, etc• System architecture review• Release process• Bug counts / severities• Production hygiene

3) Hand-off Readiness Review

4) Canary

5) The “Reliability Budget”

6) Joint Responsibility

[참고 ] DevOps Team Topologies

출처 : http://blog.matthewskelton.net/2013/10/22/what-team-structure-is-right-for-devops-to-flourish/

• 2013 년 10 월 Matthew Skelton 이 자신의 블로그에 “ What Team Structure Is Right for DevOps to Flourish?” 라는 포스팅

• 이 내용을 바탕으로 http://web.devopstopologies.com/• 7 개의 Anti-Types 과 9 개의 DevOps Team Topologies 소개 • 현 조직에서 DevOps 를 적용할 때 참고하면 도움

• Type 1: Dev and Ops Collaboration (Flickr, Etsy)

출처 : http://web.devopstopologies.com/

• Type 2: Fully Shared Ops Responsibilities (Netflix, Amazon)

• Type 7: SRE Team (Google)

위메프의 적용 사례4

4. 위메프의 DevOps 적용 사례

• 치열한 경쟁 시장에서 어떻게 살아남을 것인가 ?• 우리 개발 조직의 경쟁력은 뭘까 ?• 어떻게 해야 우리의 경쟁력을 더 강화시킬 수 있을까 ?

• 고민하던 중에… The Phoenix Project 와 Lean Enterprise 를 읽게 됨 .

고민…

그럼 , 어떻게 ? ( 이론상 )

출처 : 도서 Lean Enterprise

하지만…

• DevOps 는 Branch 전략 , 프로세스 , 인프라 , 릴리즈 , 자동화 , 문화 등등 모든 면에서 개선이 이뤄져야 하기 때문에

시간도 많이 걸리고 많은 변화가 필요함

• 2014 년 하반기 그 당시 회사의 개발 환경은 상당히 열악한 상황

• 하지만 , Flickr 의 John Allspaw 도 Etsy 에 SVP 로 입사해서

DevOps 정착시키는 데 6 년 이상 걸렸음 . • 따라서 , 조급해하지 말고 .. 하나씩 해나가자 !!

1) 내 자신이 먼저 Lean 하게 생각하기

• 낭비를 제거함으로 어떻게 고객에게 가치를 빠르게

제공할 수 있을까에 대해 먼저 생각하기 (Lean Thinking)

• 나의 역할은 조직원들이 문제에 부딪혔을 때 그

문제를 해결하도록 도와주는 역할

출처 : http://zzino.co.kr/blog/?p=173

2) DevOps 의 Practice 들로 조직 내 변화를

위한 framework 만들기

출처 : http://zzino.co.kr/blog/?p=173

첫째 , 조직원들과의 신뢰와 빠른 실행을 위해 빠른 Feedback loop 만들기( 개발 / 기획 / 인프라실장 Daily Stand-up Meeting, 매주 All Hands Meeting)

둘째 , Small changesets 와 frequently deploy. 즉 , 개선 사항을

잘게 쪼개고 지속적으로 배포 ( 개선 ) 하기

셋째 , 큰 변화는 일부 팀에 적용해보고 전체로 확대하기 (Dark launches)

이렇게 하는 이유는 조직 내 변화를 Risk 는 줄이면서 변화를

가속화하고 지속 시킬 수 있기 때문…

3) 목표 정하기• 지시나 명령보단 Best Practices 중심의 문화

Best PracticesBranch Model Git flow 에서 Github flow (pull requests) 로…Release Dark launching, Feature toggle, 배포 담당자 배포 개발자가 배포 버튼 클릭으로 직접 배포Infrastructure 수동 Configuration management Chef, Docker, Moses 등으로 개발 및 테스트 환경 자동화Organization Functional 팀 구조에서 Cross-functional, 팀 쪼개기

3) 목표 정하기

첫째 , DevOps/Lean/CD 로 개발 조직의 방향과 목표 설정하고 공유하기

• 개발 조직의 방향과 목표 설정하고 대표님 , 다른 실장들 , 개발 조직원들에게 공유

• 매월 첫주 부트캠프 ( 신입 개발자 입사 교육 ) 첫번째 교육 시간에 공유

• 매주 금요일 오후 6 시 (참고로 , 퇴근시간은 7 시 ) 에 전체 개발자가 모이는 All Hands Meeting 을 통해서 조직 내 목표를 위해서 진행 중인 개선 사항 ( 또는 진행 상황 ) 을 공유

• 또 , All Hands Meeting 시간에 Q&A 시간을 통해서 조직원들과 소통하려고 노력

4) 실행하기

둘째 , 개발 / 기획 / 인프라 실장 Daily Stand-up Meeting

• 주요 프로젝트 진행 상황 및 주요 업무 등을 서로 공유 / 우선 순위 합의 / 이슈 공유

• 같이 목표 설정하고 협업하기 더 쉬워졌음 .• 의사 결정이 빨라짐 . • 서로 조직에 대한 이해로 불필요한 오해

셋째 , 배포를 늘리기 위해 개발팀을 도메인별로 나누고 MSA 기반으로 서비스를 점차 분리해나감

• 각 개발팀의 도메인에 맞게 Source Repository 분리하여 서로 dependency 제거

• Deploy frequency 증가

• 개발 리소스와 상황을 고려하여 분리

4) 실행하기

넷째 , Feature Flags, Dark Launch, Canary Analysis

• 배포를 위한 안전 장치들

• 배포 후 이슈 발생 시 롤백 보단 해당 Feature off• 또 , Feature Flags 는 Trunk 기반 개발이나 한 프로젝트에 여러 개발팀이 개발할

경우 개발팀끼리 dependency 없이 배포할 수 있게 도와주는 유용한 테크닉

• 또 , A/B Testing 에도 유용하게 사용됨

• 마틴 파울러의 feature toggles 참고 (http://martinfowler.com/articles/feature-toggles.html)

• Dark Launch 와 Canary Analysis 를 위해서 APM(New Relic) 이용

• 배포 시 이슈를 줄일 수 있었음 .

4) 실행하기

다섯째 , 개발팀장 , SE, DBA, 보안 담당자로 구성된 아키텍트 그룹을

만들고 프로젝트 초기에 같이 리뷰• Patrick Debois 가 말한 Area 4 에 해당

• 가급적 SE, DBA, 보안 담당자들도 프로젝트 담당자를 지정해서 가능하면 같이

Sprint 에 참여토록 권고

여섯째 , 서비스 모니터링 TV 를 개발팀 자리에도 같이 배치• Patrick Debois 가 말한 Area 2 에 해당

• 서비스 장애 발생 시 개발팀도 바로 장애 인지해서 같이 원인 파악하며 정보를 그룹

채팅을 통해 Ops 와 공유

• 결과적으로 , MTTR 단축됨

4) 실행하기

일곱째 , Cross-functional Team 전환 테스트• 한번에 다 바꾸지 않고 기존 Functional 6 개의 개발팀 중에서 하나의 개발팀에 기

획 , 개발 , QA 로 cross-functional team 으로 구성하고 테스트

• 각 팀의 구성원과 리소스를 고려해서 점진적으로 시도

그 외에도…• 장애 발생 시 개발 / 기획 /QA/ 인프라 담당자 모두 그룹 채팅에서 원인 파악에서 조치 ,

QA, 유관부서 커뮤니케이션까지 빠르게 협업 (담당자는 모두 다 on-call)• 개발 /테스트 환경을 Docker + Apache Mesos 기반으로 구성

• 모바일앱 , API 테스트 자동화 진행

• SCM 도 기존의 SVN 에서 Git 으로 이전하면서 Git flow 도입 . 현재는 Git flow에서 Github flow 로 전환 중

• 프로세스도 프로젝트는 Water-Scrum-fall, 운영 업무는 Kanban 기반으로 전환 중

4) 실행하기

• 하루 배포 수 : 기존의 약 2 배 증가

• 2015 년 프로젝트 성공률 : 99%• 2015 년 상반기 대비 동시 진행 프로젝트 수 : 2 배 증가

• 2015 년 상반기 대비 개발자 1명당 진행 중인 프로젝트 : 30% 증가

• 2015 년 상반기 대비 장애 발생 수 : 50% 감소

• Mean Time to Recover(MTTR) 도 단축

5) 1 년 간의 결과

• DevOps 의 끝은 없다 . 지속적인 개선해야 한다 .• 가장 어려운 건 문화다 . 그래서 , 사람과 소통이 중요하다 . • 일하는 사람 입장에선 솔직히 DevOps 힘들다 . 그래서 , 본인들의

innovation 으로 배울 수 있는 분위기와 환경을 만들어주는 것과

Automation 으로 좀 더 중요한 일에 집중할 수 있게 해야 지속

가능하다 .• 테스트 자동화가 제약도 많고 힘들고 시간도 많이 걸린다 . 따라서 ,

많이 투자해야 하는 부분 중에 하나 .

6) 그간의 여정을 통해 느낀 점

감사합니다

References

• KPCB 의 인터넷 트렌즈 리포트 : http://www.kpcb.com/internet-trends• Reactive Manifesto: http://www.reactivemanifesto.org/• Facebook 릴리즈 엔지니어 은밀히 들여다 보기 ( 한글 번역본 ): http://www.looah.com/article/

view/983/• Development and Deployment at Facebook: http://ieeexplore.ieee.org/xpl/articleDetail-

s.jsp?reload=true&arnumber=6449236• [ 소프트웨어 프로세스 이야기 ] 페이스북은 어떻게 개발하고 배포할까 ?: http://

swprocess.egloos.com/3009704/• InfoQ 의 Facebook Moving Fast at Scale 발표 : http://www.infoq.com/presentations/Face-

book-Moving-Fast-at-Scale• 10+ Deploys Per Day at Flickr 유튜브 영상 : https://www.youtube.com/watch?

v=LdOe18KhtT4• 10+ Deploys Per Day at Flickr 슬라이드 : http://www.slideshare.net/jallspaw/10-deploys-

per-day-dev-and-ops-cooperation-at-flickr/• Continuous Deployment at Etsy 슬라이드 : http://www.slideshare.net/beamrider9/continu-

ous-deployment-at-etsy-a-tale-of-two-approaches• Cooperation Collaboration Awareness at Etsy & Flickr: http://www.slideshare.net/

jallspaw/dev-and-ops-collaboration-and-awareness-at-etsy-and-flickr• Netflix Culture: Freedom & Responsibility 슬라이드 : http://www.slideshare.net/reed2001/

culture-1798664?related=1

References

• Netflix 에서 API deploy 하기 ( 한글 번역본 ): https://josephkim75.wordpress.com/2013/10/23/netflix%EC%97%90%EC%84%9C-api-deploy%ED%95%98%EA%B8%B0/

• Continuous Delivery at Netflix 슬라이드 : http://www.slideshare.net/robspieldenner/contin-uous-delivery-at-netflix?related=1

• Principles and Practices in Continuous Deployment at Etsy: http://www.slideshare.net/mikebrittain/principles-and-practices-in-continuous-deployment-at-etsy?related=3

• Continuously Deploying Culture (Scaling Culture at Etsy) : http://www.slideshare.net/mc-donnps/continuously-deploying-culture-scaling-culture-at-etsy-14588485?related=4

• DevOps Patterns: http://blog.matthewskelton.net/2013/10/22/what-team-structure-is-right-for-devops-to-flourish/

DevOps!! 도데체 왜, 어떻게 할까??

Engineering

Transcript of DevOps!! 도데체 왜, 어떻게 할까??

인문학 평가, 어떻게 할 것인가¸문학평가, 어떻게 할...인문학 평가, 어떻게 할 것인가 85 경쟁체제를 추동하는 것은 갈수록 견고해지는

Perguntas em coreano · Perguntas em coreano Quem 누구 (nugu) Onde 어디 (eodi) O quê 무엇 (mueos) Porquê 왜 (wae) Como 어떻게 (eotteohge) Qual 어느 (eoneu) Quando 언제

웹 개발, 왜 어려운가?

AH M J - · PDF file왜 지금 가야 할까? 반짝이며 ... AMA zi N g MAASA iultr A.org 왜 지금 가야

무엇을 어떻게 할까 ?

프로그램은 왜 실패 하는가

유류세 인하, 왜 문제인가?

프로그램은 왜 실패하는가

DevOps!! 도데체 왜, 어떻게 할까??

시맨틱한 HTML5 마크업 구조 설계, 어떻게 할까?

〈김비서가 왜 그럴까〉의 장르 나들이 · 이 어떻게 캐릭터에 생동감을 더하는지 보여주는 대표 적인 사례다. 웹툰을 그린 김명미 작가는

"왜 고전을 읽는가?"

식물도 호흡을 할까 ?

혁신은 왜 실패하는가

왜 협동조합인가 ?

대한민국 의사들 왜 투쟁하는가

구글, 모바일2.0에서도통(通)할까?구글이준비하고있는전략은모바일라이프패러 다임의혁신이다. 유비쿼터스네트워크환경과디 지털컨버전스현상으로경영환경이지금과는다른

엔콘텐츠 14호 내지(표지포함) - KOCCA · 콘텐츠산업 3대 혁신 전략 발표에 콘텐츠 기업들은 어떻게 대응해야 할까. 콘텐츠 기업들의 성장과

[2014널리세미나] 시맨틱한 HTML5 마크업 구조 설계, 어떻게 할까?

스타트업은 데이터를 어떻게 바라봐야 할까? (개정판)