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

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

2. 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

3. Index 2 3 1 4

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

5. 1. 왜 DevOps를 해야 할까요? 5 “세상이 달라졌습니다.”

6. 1. 왜 DevOps를 해야 할까요? 6 2015년 5월말에 발표된 KPCB의 “INTERNET TRENDS 2015” 보고서에서… 출처: http://www.kpcb.com/internet-trends

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

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

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

11. 1. 왜 DevOps를 해야 할까요? 11 그럼, 이런 시대에 Google, Facebook, Amazon 과 같은 회사들은 어떻게 대응하고 있을까요?

12. 1. 왜 DevOps를 해야 할까요? 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. 1. 왜 DevOps를 해야 할까요? 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. 1. 왜 DevOps를 해야 할까요? 14 14 Amazon Leadership Principles 1. Customer Obsession 2. Ownership 3. Invent and Simplify … Moving Fast 2013년 한해 동안 신규 서비스 280개 출시

15. 1. 왜 DevOps를 해야 할까요? 15 출처: http://www.slideshare.net/diannemarsh/from-code-to-the-monkeys-continuous-delivery-at- netflix/ Dianne Marsh (Director of Engineering, Netflix) said…

16. 1. 왜 DevOps를 해야 할까요? 16 공통점을 뽑아보면… Moving Fast!! Focus on Customer!!

17. 1. 왜 DevOps를 해야 할까요? 17 공통점을 뽑아보면… 즉, 고객 중심으로 빠르게 움직이고 있다.

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

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

24. 2. 그럼, 도데체 DevOps는 뭘까요? 24 이런 말은 많습니다. DevOps is NOT … - A Job title. - An Organizational Unit. - A automation. - A tool. - Simply combining Dev & Ops. …..

25. 2. 그럼, 도데체 DevOps는 뭘까요? 25 But, there is not a clear definition yet. WHAT???

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

27. 2. 그럼, 도데체 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. 2. 그럼, 도데체 DevOps는 뭘까요? 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. 2. 그럼, 도데체 DevOps는 뭘까요? 29 • 2008년 8월, 캐나다 토론토에서 Andrew Shafer 가 Agile 2008 Conference에서 Agile Infrastructure라는 주제로 발표. • 안타깝게도 참석자는 딱 한 명. 그가 바로 Patrick Debois!! • Andrew Shafer는 발표를 건너뛰고 Patrick Debois와 함께 넓은 복도에서 Patrick이 고민하 고 있던 주제에 대해서 토론. • 이를 계기로 Patrick Debois가 구글 그룹스에 “The Agile Systems Administration”라는 그룹을 만들게 됨. 1) DevOps의 유래 (그 이름을 갖게 된 역사) 출처: IT Revolution Press (http://itrevolution.com/the-history-of-devops/) [Andrew Shafer]

30. 2. 그럼, 도데체 DevOps는 뭘까요? 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월 처음 개최하게 됨. 1) DevOps의 유래 (그 이름을 갖게 된 역사) 출처: IT Revolution Press (http://itrevolution.com/the-history-of-devops/) [2009년 Velocity 2009 Conference에서 발표 중인 John Allspaw와 Paul Hammond (https://www.youtube.com/watch?v=LdOe18KhtT4)]

31. 2. 그럼, 도데체 DevOps는 뭘까요? 31 1) DevOps의 유래 (그 이름을 갖게 된 역사) 출처: IT Revolution Press (http://itrevolution.com/the-history-of-devops/) [ http://devopsdays.org/ ] • 2009년 10월말 벨기에를 시작으로 DevOpsDay 컨퍼런스가 전 세계적으로 점 점 확산됨. • DevOpsDay가 확산되면서 트위터에서 관련 된 트윗들이 #DevOps로 확산되게 됨.

32. 2. 그럼, 도데체 DevOps는 뭘까요? 32 1) DevOps의 유래 (그 이름을 갖게 된 역사) 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. 그럼, 도데체 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. 2. 그럼, 도데체 DevOps는 뭘까요? 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. 2. 그럼, 도데체 DevOps는 뭘까요? 35 4) DevOps의 foundations Lean은 낭비를 제거함으로 어떻게 고객에게 가치를 빠르게 제공할 수 있을까에 대한 생각이자 사고 방식 (Lean Thinking) Lean의 핵심은 끊임없이 문제를 해결하고 개선하는 것 •Lean

36. 2. 그럼, 도데체 DevOps는 뭘까요? 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 (전체를 보라) 4) DevOps의 foundations

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

38. 2. 그럼, 도데체 DevOps는 뭘까요? 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. 2. 그럼, 도데체 DevOps는 뭘까요? 39 http://itrevolution.com/the-three-ways-principles-underpinning-devops/ 5) DevOps를 지탱하는 the Three ways principles (Gene Kim)

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

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

44. 2. 그럼, 도데체 DevOps는 뭘까요? 44 http://www.jedi.be/blog/2012/05/12/codifying-devops-area-practices/ 6) DevOps Area Practices (Patrick Debois) • 좁은 의미의 DevOps (Devops lite)는 Dev와 Ops에 집중

45. 2. 그럼, 도데체 DevOps는 뭘까요? 45 http://www.jedi.be/blog/2012/05/12/codifying-devops-area-practices/ 6) DevOps Area Practices (Patrick Debois) • Patrick Debois의 4 Areas • 간단히, Dev는 Project, Ops는 Product로 봄.

46. 2. 그럼, 도데체 DevOps는 뭘까요? 46 http://www.jedi.be/blog/2012/05/12/codifying-devops-area-practices/ 6) DevOps Area Practices (Patrick Debois) • 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. 2. 그럼, 도데체 DevOps는 뭘까요? 47 http://www.jedi.be/blog/2012/05/12/codifying-devops-area-practices/ 6) DevOps Area Practices (Patrick Debois) “You can’t directly change culture. But you can change behavior, and behavior becomes culture” – Lloyd Taylor VP Infrastructure, Ngmoco

48. 2. 그럼, 도데체 DevOps는 뭘까요? 48 - http://www.jedi.be/blog/2012/05/12/codifying-devops-area-practices/ • Patrick Debois의 4 Area와 CAMS를 같이 보면… 6) DevOps Area Practices (Patrick Debois)

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

50. 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. 51 2) 배포 주기 • 매일 2번 업데이트 • 메이저 업데이트 (매주 화요일 오후) 3) Deployment Pipeline 출처: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6449236 3. FB, Flickr, Netflix, Etsy, Google의 적용 사례

52. 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] 3. FB, Flickr, Netflix, Etsy, Google의 적용 사례

53. 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에 대한 트윗들까지 모니터링함 3. FB, Flickr, Netflix, Etsy, Google의 적용 사례

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

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

56. 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 3. FB, Flickr, Netflix, Etsy, Google의 적용 사례

57. 57 2) 고정 관념 탈피 • 선택은 Tools과 Culture로 변화의 Risk를 낮추는 것 출처: http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr 3. FB, Flickr, Netflix, Etsy, Google의 적용 사례

58. 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. 누가, 언제, 무엇을 배포했는 지 한눈에 확인 가능 출처: http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr 3. FB, Flickr, Netflix, Etsy, Google의 적용 사례

59. 59 출처: http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr 3. FB, Flickr, Netflix, Etsy, Google의 적용 사례 3) Tools

60. 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 등을 공 유 받음 출처: http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr 3. FB, Flickr, Netflix, Etsy, Google의 적용 사례

61. 61 4) Culture • Respect: 개발, 운영 서로 전문성을 인정하고 존중하라. • Trust: 서로 신뢰하는 문화 • Healthy attitude about failure • Avoiding Blame 결국, 문제가 났을 때 서로 손가락질 하거나 잘잘못 따지지 말고 우 선 해결하는 데 집중하고 서로의 전문성을 존중하고 신뢰하자!! 출처: http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr 3. FB, Flickr, Netflix, Etsy, Google의 적용 사례

62. 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) 3. FB, Flickr, Netflix, Etsy, Google의 적용 사례

63. 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 3. FB, Flickr, Netflix, Etsy, Google의 적용 사례

64. 64 2) Deployment Flow • Unit Test • Regression Test • Canary Analysis • Red/Black • Global Release (Red) 출처: http://techblog.netflix.com/2013/08/deploying-netflix-api.html 3. FB, Flickr, Netflix, Etsy, Google의 적용 사례

65. 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 됨 출처: http://techblog.netflix.com/2013/08/deploying-netflix-api.html 3. FB, Flickr, Netflix, Etsy, Google의 적용 사례

66. 66 4) Canary를 통해서 확신 갖기 • Canary란? 실제 production 환경에서 small subset에서 새로운 코드를 돌려 보고 옛날 코드와 비교해서 새로운 코드가 어떻게 돌아가는 지 보는 것 • Canary 분석 작업(HTTP status code, response time, 실행수, load avg 등이 옛날 코드랑 새로운 코드랑 비교해서 어떻게 다른 지 확인하는 것)은 1000개 이상의 metric을 비교해서 100점 만점에 점수를 주고 일정 점수일 경우만 배 포할 수 있음. 출처: http://techblog.netflix.com/2013/08/deploying-netflix-api.html 3. FB, Flickr, Netflix, Etsy, Google의 적용 사례

67. 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을 만듬 출처: http://techblog.netflix.com/2013/08/deploying-netflix-api.html 3. FB, Flickr, Netflix, Etsy, Google의 적용 사례

68. 68 1) Google의 DevOps? SRE (Site Reliability Engineering) • SRE의 업무 자체는 전통적인 operation 조직이 하는 업무를 담당하지만 그 구 성원을 소프트웨어 백그라운드 가진 사람과 시스템 백그라운드를 가진 사람 50:50 비율로 구성함. • SRE를 hire 할 때도 ops skill을 가진 개발자를 구함. • 그리고, SRE의 업무도 운영 업무 반, 자동화를 위해 개발 업무가 반이라고 함. 3. FB, Flickr, Netflix, Etsy, Google의 적용 사례 출처: https://landing.google.com/sre/interview/ben-treynor.html

69. 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”. 3. FB, Flickr, Netflix, Etsy, Google의 적용 사례 출처: SRE@Google: Thousands of DevOps Since 2004 (https://www.youtube.com/watch?v=iIuTnhdTzK0) 2) SRE Methodology

70. 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. FB, Flickr, Netflix, Etsy, Google의 적용 사례 3) Hand-off Readiness Review 출처: SRE@Google: Thousands of DevOps Since 2004 (https://www.youtube.com/watch?v=iIuTnhdTzK0)

71. 71 3. FB, Flickr, Netflix, Etsy, Google의 적용 사례 4) Canary 출처: SRE@Google: Thousands of DevOps Since 2004 (https://www.youtube.com/watch?v=iIuTnhdTzK0)

72. 72 3. FB, Flickr, Netflix, Etsy, Google의 적용 사례 4) Canary 출처: SRE@Google: Thousands of DevOps Since 2004 (https://www.youtube.com/watch?v=iIuTnhdTzK0)

73. 73 3. FB, Flickr, Netflix, Etsy, Google의 적용 사례 5) The “Reliability Budget” 출처: SRE@Google: Thousands of DevOps Since 2004 (https://www.youtube.com/watch?v=iIuTnhdTzK0)

74. 74 3. FB, Flickr, Netflix, Etsy, Google의 적용 사례 6) Joint Responsibility 출처: SRE@Google: Thousands of DevOps Since 2004 (https://www.youtube.com/watch?v=iIuTnhdTzK0)

75. 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를 적용할 때 참고하면 도움 3. FB, Flickr, Netflix, Etsy, Google의 적용 사례

76. 76 [참고] DevOps Team Topologies 3. FB, Flickr, Netflix, Etsy, Google의 적용 사례 • Type 1: Dev and Ops Collaboration (Flickr, Etsy) 출처: http://web.devopstopologies.com/

77. 77 [참고] DevOps Team Topologies 3. FB, Flickr, Netflix, Etsy, Google의 적용 사례 출처: http://web.devopstopologies.com/ • Type 2: Fully Shared Ops Responsibilities (Netflix, Amazon)

78. 78 [참고] DevOps Team Topologies 3. FB, Flickr, Netflix, Etsy, Google의 적용 사례 출처: http://web.devopstopologies.com/ • Type 7: SRE Team (Google)

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

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

81. 4. 위메프의 DevOps 적용 사례 81 그럼, 어떻게? (이론상) 출처: 도서 Lean Enterprise

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

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

84. 84 2) DevOps의 Practice들로 조직 내 변화를 위한 framework 만들기 출처: http://zzino.co.kr/blog/?p=173 4. 위메프의 DevOps 적용 사례 첫째, 조직원들과의 신뢰와 빠른 실행을 위해 빠른 Feedback loop 만 들기 (개발/기획/인프라실장 Daily Stand-up Meeting, 매주 All Hands Meeting) 둘째, Small changesets와 frequently deploy. 즉, 개선 사항을 잘게 쪼개고 지속적으로 배포(개선)하기 셋째, 큰 변화는 일부 팀에 적용해보고 전체로 확대하기 (Dark launches) 이렇게 하는 이유는 조직 내 변화를 Risk는 줄이면서 변화를 가속화하고 지속 시킬 수 있기 때문…

85. 85 3) 목표 정하기 • 지시나 명령보단 Best Practices 중심의 문화 4. 위메프의 DevOps 적용 사례

86. 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) 목표 정하기 4. 위메프의 DevOps 적용 사례

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

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

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

91. 4. 위메프의 DevOps 적용 사례 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. 4. 위메프의 DevOps 적용 사례 92 • 하루 배포 수: 기존의 약 2배 증가 • 2015년 프로젝트 성공률: 99% • 2015년 상반기 대비 동시 진행 프로젝트 수: 2배 증가 • 2015년 상반기 대비 개발자 1명당 진행 중인 프로젝트: 30% 증가 • 2015년 상반기 대비 장애 발생 수: 50% 감소 • Mean Time to Recover(MTTR)도 단축 5) 1년 간의 결과

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

94. 94 감사합니다

95. 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

96. 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/

97. Further Reading 97