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

본 문서는 나눔고딕으로 작성되었습니다.
GS Shop 서문래 프로젝트 4탄
2016년 6월 3일(금)
김요섭 (chingu94@gmail.com)
FB, Flickr, Etsy, Netflix 등의 사례 중심으로 살펴본 DevOps!
DevOps!! 도데체 왜, 어떻게 할까??

Speaker
2
“안녕하세요. 김요섭입니다.”
• 평범한 가장, 두 아이의 아빠
• 전) 위메프 플랫폼개발실 실장
• 전) 앱디스코 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.75
https://www.linkedin.com/in/josephkim75

1
1. 왜 DevOps를 해야 할까요?

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

6
2015년 5월말에 발표된
KPCB의 “INTERNET TRENDS 2015” 보고서에서…
출처: http://www.kpcb.com/internet-trends

7
출처: http://www.kpcb.com/internet-trend
s
지난 20년 동안 가장 큰 변화는…
People Connected 24/7 with Mobile Devices
이런 사용자의 변화는 트랙픽의 변화로 이어지고…

8
(http://www.reactivemanifesto.org/)Reactive Manifesto를 보면…
These changes are happening because application requirements have changed dramatically
in 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 clusters 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 proc
essors
Seconds of response time Millisecond response time
Hours of offline maintenance 100% uptime
Gigabytes of data Petabytes of data
Today's demands are simply not met by yesterday’s software architectures.

9
또, 모바일은 비지니스 환경도 바꿨습니다.
온라인 시대 모바일 시대
시장 상황
이미 시장의 강자들이 패권 장악 아직은 춘추 전국 시대. 강자가 계속
바뀜
새로운 기회
새로운 플레이어의 진입이 쉽지
않음
벤쳐, 대기업 등 새로운 기회 찾아
Rush
경쟁 상황
기존 강자들 위주로 경쟁 상황 변
화가 많지 않음
매우 치열함. 벤쳐, 대기업 너도 나
도 모바일로…

10
결국,
모바일 시대의 사용자의 변화는
기존의 온라인에서와
다른 개발 방법, 아키텍쳐 등을
요구하게 됩니다.

11
그럼, 이런 시대에
Google, Facebook, Amazon 과 같은 회사들은
어떻게 대응하고 있을까요?

12
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/

13
출처: http://www.google.com/intl/ko_KR/about/company/philosophy/
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.

14
14
Amazon Leadership Principles
1. Customer Obsession
2. Ownership
3. Invent and Simplify
…
Moving Fast
2013년 한해 동안
신규 서비스 280개 출시

15
출처: http://www.slideshare.net/diannemarsh/from-code-to-the-monkeys-continuous-delivery-at-
netflix/
Dianne Marsh (Director of Engineering, Netflix) said…

16
공통점을 뽑아보면…
Moving Fast!!
Focus on Customer!!

17
공통점을 뽑아보면…
즉, 고객 중심으로
빠르게
움직이고 있다.

18
Company Deploy Frequency Deploy Lead Time Reliability Customer
Responsiveness
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 Performances
- Deploy frequency (Note: NOT delivery)
- Mean Time to Recover (MTTR)
- Lead Time for Changes

19
더 무서운 건
더 빨라지고 있다는 것!!!
• 하루에 한번 배포 (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)

20
• 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)

21
• 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)

22
왜 DevOps를 해야 할까요?
빠르게 변하는 비지니스 환경과 사용자의 필요에 기민하게 대처
하고
결국은 비지니스가 계속 살아남기 위해서…
그래서, Damon Edwards (DTO solutions inc.)가 말하길…
“ DevOps is not about a technology,
DevOps is about a business problem.”

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

24
이런 말은 많습니다.
DevOps is NOT …
- A Job title.
- An Organizational Unit.
- A automation.
- A tool.
- Simply combining Dev & Ops.
…..

25
But, there is not a clear definition
yet.
WHAT???

26
• DevOps 정의 (Wikipedia)
DevOps는 소프트웨어 개발자와 정보 기술 전문가 간의 소통, 협
업 및
통합을 강조하는 개발 방법론.
데브옵스는 소프트웨어 개발 조직과 운영 조직간의 상호 의존적
대응이며 소프트웨어 제품과 서비스를 빠른 시간에 개발 및 배포
하는 것을목적으로 한다.

27
DevOps 좀 더 알아가기
1) DevOps의 유래 (DevOps 이름을 갖게 된 역사)
2) CAMS or CALMS
3) Devops.com의 정의
4) DevOps의 foundations
5) The Three Ways Principles (Gene Kim)
6) DevOps Area Practices (Patrick Debois)

28
• 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)]

29
• 2008년 8월, 캐나다 토론토에서 Andrew Shafer
가 Agile 2008 Conference에서
Agile Infrastructure라는 주제로 발표.
• 안타깝게도 참석자는 딱 한 명. 그가 바로
Patrick Debois!!
• Andrew Shafer는 발표를 건너뛰고 Patrick
Debois와 함께 넓은 복도에서 Patrick이 고민하
고 있던 주제에 대해서 토론.
• 이를 계기로 Patrick Debois가 구글 그룹스에
“The Agile Systems Administration”라는 그룹을
만들게 됨.
[Andrew Shafer]

30
• 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)]

31
[ http://devopsdays.org/ ]
• 2009년 10월말 벨기에를 시작으로
DevOpsDay 컨퍼런스가 전 세계적으로 점
점 확산됨.
• DevOpsDay가 확산되면서 트위터에서 관련
된 트윗들이 #DevOps로 확산되게 됨.

32
By Damon Edwards (DTO Solutions inc.) - https://www.youtube.com/watch?v=o7-IuYS0iSE&feature=youtu.be
• From practitioners, by practitioners
• An experience-based movement
• Decentralized and open to all
DevOps의 역사가 주는 교훈

33
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)을 추가

34
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/

35
Lean은 낭비를 제거함으로 어떻게 고객에게 가치를 빠르게 제공할
수 있을까에 대한 생각이자 사고 방식 (Lean Thinking)
Lean의 핵심은 끊임없이 문제를 해결하고 개선하는 것
•Lean

36
•Lean Software Development Principles
1. Eliminate waste (낭비를 제거하라)
2. Amplify learning (배움을 증폭시켜라)
3. Decide as late as possible (가능한 늦게 결정하라)
4. Deliver as fast as possible (가능한 빨리 delivery 하라)
5. Empower the team (팀에 권한을 주라)
6. Build quality in (quality를 만들어 가라)
7. See the whole (전체를 보라)

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

38
http://itrevolution.com/the-three-ways-principles-underpinning-devops/
5) DevOps를 지탱하는 the Three ways principles (Gene Kim)
• Gene Kim은 DevOps의 Cookbook인 “the Phoenix Project”의 저자

39

40

41

42
Robert Johnson(Engineering Director at FB)의 InfoQ 영상 (2010년 5월)
“만약 어제밤에
제가 아이디어가 하나 있었다면...
그걸 오늘 아침에 코딩해서…
오후에 그걸 사이트에 올릴 수 있구요…
내일이면 데이타를 얻을 수 있습니다.
제가 일반적인 다른 시스템에서
일년동안 배울 수 있는 것보다 훨씬 더 많은 것
들을 불과 몇 주 안에 배웠습니다.”
http://www.infoq.com/presentations/Facebook-Moving-Fast-at-Scale
• DevOps의 실례

43
http://www.jedi.be/blog/2012/05/12/codifying-devops-area-practices/
• 넓은 의미의 DevOps는 IT를 뛰어넘어 모든 조직 (HR, Finance…)의 collaboration과
optimization을 지향.
• 최근에는 DevQAOps, DevOpsSec, DevSecOps, BizDevOps 등 기존의 DevOps에서
점점 확대되는 추세 (IT Performance => Org. Performance)

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

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

46
• Practical examples
• Practices => Patterns => Principles
Areas Practical examples
Area 1 Extend delivery to production CI/CD. chef/puppet 같은 configuration management 쓰는 것 등등
Area 2 Extend operations feedback to
project
Production(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)도 같이 참여시키고
Production(Ops) 업무를 Project(Dev) backlog에 추가하는 것

47
“You can’t directly change culture.
But you can change behavior, and behavior becomes culture”
– Lloyd Taylor VP Infrastructure, Ngmoco

48
- http://www.jedi.be/blog/2012/05/12/codifying-devops-area-practices/
• Patrick Debois의 4 Area와 CAMS를 같이 보면…

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

50
페이스북은 어떻게 개발하고 배포할까?
1) 자료들
• 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

51
2) 배포 주기
• 매일 2번 업데이트
• 메이저 업데이트 (매주 화요일 오후)
3) Deployment Pipeline
출처: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6449236

52
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]

53
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에 대한 트윗들까지 모니터링함

54
9) 문화
• 문제가 생기면 빠르게 버그 수정. 롤백은 잘 안함.
• 개발자들의 카르마 관리. 즉, 배포할 때 문제를 일으킨 코드를 작성한 개발자
들을 릴리즈팀에서 평판 관리하고 있음. (좋아요/싫어요 버튼으로)
• 카르마 점수가 낮은 개발자가 코드 머지 요청을 할 경우 더 엄격히 코드 리뷰
함.
Facebook 릴리즈 엔지니어링팀에 있는 Hotfix Bar에 있는 술병 사진.
성공적으로 릴리즈한 이후에 한 잔식으로 자축. 이 중에 카르마가 낮은 개발자가 선물한 술들이 있음.
출처: http://www.looah.com/article/view/983

55
1) 그 유명한 “10+ deploys per day” 동영상
• Flickr의 John Allspaw(Ops head)와 Paul Hammond(Dev head)가
Velocity 2009년에서 발표한 영상
출처: 유투브 동영상: https://www.youtube.com/watch?v=LdOe18KhtT4

56
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

57
2) 고정 관념 탈피
• 선택은 Tools과 Culture로 변화의 Risk를 낮추는 것

58
3) Tools
• Automated infrastructure
A. Flickr에서 사용하고 있는 Tools: Chef, Cfengine, Puppet, FAI, Cobbler 등
• Shared version control
A. Dev/Ops 모든 소스 코드나 환경 설정 등이 다 볼 수 있게 version control 공
유
• One step build and deploy
A. 모든 빌드 작업을 자동화하고 한번에 할 수 있는 툴 제공
B. 누가, 언제, 무엇을 배포했는 지 한눈에 확인 가능

59
3) Tools

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

61
4) Culture
• Respect: 개발, 운영 서로 전문성을 인정하고 존중하라.
• Trust: 서로 신뢰하는 문화
• Healthy attitude about failure
• Avoiding Blame
결국, 문제가 났을 때 서로 손가락질 하거나 잘잘못 따지지 말고 우
선 해결하는 데 집중하고 서로의 전문성을 존중하고 신뢰하자!!

62
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)

63
1) 자료들
• 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
출처: http://techblog.netflix.com/2013/08/deploying-netflix-api.html

64
2) Deployment Flow
• Unit Test
• Regression Test
• Canary Analysis
• Red/Black
• Global Release (Red)

65
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 됨

66
4) Canary를 통해서 확신 갖기
• Canary란? 실제 production 환경에서 small subset에서 새로운 코드를 돌려
보고 옛날 코드와 비교해서 새로운 코드가 어떻게 돌아가는 지 보는 것
• Canary 분석 작업(HTTP status code, response time, 실행수, load avg 등이
옛날 코드랑 새로운 코드랑 비교해서 어떻게 다른 지 확인하는 것)은 1000개
이상의 metric을 비교해서 100점 만점에 점수를 주고 일정 점수일 경우만 배
포할 수 있음.

67
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을 만듬

68
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

69
• 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”.
출처: SRE@Google: Thousands of DevOps Since 2004 (https://www.youtube.com/watch?v=iIuTnhdTzK0)
2) SRE Methodology

70
• 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

71
4) Canary

72
4) Canary

73
5) The “Reliability Budget”

74
6) Joint Responsibility

75
[참고] 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를 적용할 때 참고하면 도움

76
• Type 1: Dev and Ops Collaboration (Flickr, Etsy)
출처: http://web.devopstopologies.com/

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

78
• Type 7: SRE Team (Google)

4
4. 위메프의 DevOps 적용 사례

80
• 치열한 경쟁 시장에서 어떻게 살아남을 것인가?
• 우리 개발 조직의 경쟁력은 뭘까?
• 어떻게 해야 우리의 경쟁력을 더 강화시킬 수 있을까?
• 고민하던 중에… The Phoenix Project와 Lean Enterprise를 읽게 됨.
고민…

81
그럼, 어떻게? (이론상)
출처: 도서 Lean Enterprise

82
하지만…
• DevOps는 Branch 전략, 프로세스, 인프라, 릴리즈, 자동화, 문
화 등등 모든 면에서 개선이 이뤄져야 하기 때문에 시간도 많이
걸리고 많은 변화가 필요함
• 2014년 하반기 그 당시 회사의 개발 환경은 상당히 열악한 상황
• 하지만, Flickr의 John Allspaw도 Etsy에 SVP로 입사해서
DevOps 정착시키는 데 6년 이상 걸렸음.
• 따라서, 조급해하지 말고.. 하나씩 해나가자!!

83
1) 내 자신이 먼저 Lean하게 생각하기
• 낭비를 제거함으로 어떻게 고객에게 가치를 빠르게
제공할 수 있을까에 대해 먼저 생각하기 (Lean
Thinking)
• 나의 역할은 조직원들이 문제에 부딪혔을 때 그 문
제를 해결하도록 도와주는 역할
출처: http://zzino.co.kr/blog/?p=173

84
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는 줄이면서 변화를 가속화하고
지속 시킬 수 있기 때문…

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

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

87
첫째, DevOps/Lean/CD로 개발 조직의 방향과 목표 설정하고 공유하기
• 개발 조직의 방향과 목표 설정하고 대표님, 다른 실장들, 개발 조직원들에게 공유
• 매월 첫주 부트캠프(신입 개발자 입사 교육) 첫번째 교육 시간에 공유
• 매주 금요일 오후 6시 (참고로, 퇴근시간은 7시)에 전체 개발자가 모이는 All Hands Meeting
을 통해서 조직 내 목표를 위해서 진행 중인 개선 사항(또는 진행 상황)을 공유
• 또, All Hands Meeting 시간에 Q&A 시간을 통해서 조직원들과 소통하려고 노력
4) 실행하기

88
둘째, 개발/기획/인프라 실장 Daily Stand-up Meeting
• 주요 프로젝트 진행 상황 및 주요 업무 등을 서로 공유 / 우선 순위 합의 / 이슈 공유
• 같이 목표 설정하고 협업하기 더 쉬워졌음.
• 의사 결정이 빨라짐.
• 서로 조직에 대한 이해로 불필요한 오해
셋째, 배포를 늘리기 위해 개발팀을 도메인별로 나누고 MSA 기반으로 서
비스를 점차 분리해나감
• 각 개발팀의 도메인에 맞게 Source Repository 분리하여 서로 dependency 제거
• Deploy frequency 증가
• 개발 리소스와 상황을 고려하여 분리
4) 실행하기

89
넷째, 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) 실행하기

90
다섯째, 개발팀장, SE, DBA, 보안 담당자로 구성된 아키텍트 그룹을 만들
고 프로젝트 초기에 같이 리뷰
• Patrick Debois가 말한 Area 4에 해당
• 가급적 SE, DBA, 보안 담당자들도 프로젝트 담당자를 지정해서 가능하면 같이 Sprint
에 참여토록 권고
여섯째, 서비스 모니터링 TV를 개발팀 자리에도 같이 배치
• Patrick Debois가 말한 Area 2에 해당
• 서비스 장애 발생 시 개발팀도 바로 장애 인지해서 같이 원인 파악하며 정보를 그룹
채팅을 통해 Ops와 공유
• 결과적으로, MTTR 단축됨
4) 실행하기

91
일곱째, 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) 실행하기

92
• 하루 배포 수: 기존의 약 2배 증가
• 2015년 프로젝트 성공률: 99%
• 2015년 상반기 대비 동시 진행 프로젝트 수: 2배 증가
• 2015년 상반기 대비 개발자 1명당 진행 중인 프로젝트: 30% 증가
• 2015년 상반기 대비 장애 발생 수: 50% 감소
• Mean Time to Recover(MTTR)도 단축
5) 1년 간의 결과

93
• DevOps의 끝은 없다. 지속적인 개선해야 한다.
• 가장 어려운 건 문화다. 그래서, 사람과 소통이 중요하다.
• 일하는 사람 입장에선 솔직히 DevOps 힘들다. 그래서, 본인들의
innovation으로 배울 수 있는 분위기와 환경을 만들어주는 것과
Automation으로 좀 더 중요한 일에 집중할 수 있게 해야 지속 가능하
다.
• 테스트 자동화가 제약도 많고 힘들고 시간도 많이 걸린다. 따라서,
많이 투자해야 하는 부분 중에 하나.
6) 그간의 여정을 통해 느낀 점

References
95
• 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/articleDetails.jsp?reload=true&arnumber=6449236
• [소프트웨어 프로세스 이야기] 페이스북은 어떻게 개발하고 배포할까?:
http://swprocess.egloos.com/3009704/
• InfoQ의 Facebook Moving Fast at Scale 발표: http://www.infoq.com/presentations/Facebook-Movin
g-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/continuous-
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
96
• 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/continuous-
delivery-at-netflix?related=1
• Principles and Practices in Continuous Deployment at Etsy: http://www.slideshare.net/mikebrittain/p
rinciples-and-practices-in-continuous-deployment-at-etsy?related=3
• Continuously Deploying Culture (Scaling Culture at Etsy) :
http://www.slideshare.net/mcdonnps/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!! 도데체 왜, 어떻게 할까??

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

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

Similar to DevOps!! 도데체 왜, 어떻게 할까?? (20)

Recently uploaded

Recently uploaded (8)

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