SlideShare a Scribd company logo
1 of 97
Download to read offline
본 문서는 나눔고딕으로 작성되었습니다.
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
Index
2
3
1
4
1
1. 왜 DevOps를 해야 할까요?
1. 왜 DevOps를 해야 할까요?
5
“세상이 달라졌습니다.”
1. 왜 DevOps를 해야 할까요?
6
2015년 5월말에 발표된
KPCB의 “INTERNET TRENDS 2015” 보고서에서…
출처: http://www.kpcb.com/internet-trends
1. 왜 DevOps를 해야 할까요?
7
출처: http://www.kpcb.com/internet-trend
s
지난 20년 동안 가장 큰 변화는…
People Connected 24/7 with Mobile Devices
이런 사용자의 변화는 트랙픽의 변화로 이어지고…
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.
1. 왜 DevOps를 해야 할까요?
9
또, 모바일은 비지니스 환경도 바꿨습니다.
온라인 시대 모바일 시대
시장 상황
이미 시장의 강자들이 패권 장악 아직은 춘추 전국 시대. 강자가 계속
바뀜
새로운 기회
새로운 플레이어의 진입이 쉽지
않음
벤쳐, 대기업 등 새로운 기회 찾아
Rush
경쟁 상황
기존 강자들 위주로 경쟁 상황 변
화가 많지 않음
매우 치열함. 벤쳐, 대기업 너도 나
도 모바일로…
1. 왜 DevOps를 해야 할까요?
10
결국,
모바일 시대의 사용자의 변화는
기존의 온라인에서와
다른 개발 방법, 아키텍쳐 등을
요구하게 됩니다.
1. 왜 DevOps를 해야 할까요?
11
그럼, 이런 시대에
Google, Facebook, Amazon 과 같은 회사들은
어떻게 대응하고 있을까요?
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/
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.
1. 왜 DevOps를 해야 할까요?
14
14
Amazon Leadership Principles
1. Customer Obsession
2. Ownership
3. Invent and Simplify
…
Moving Fast
2013년 한해 동안
신규 서비스 280개 출시
1. 왜 DevOps를 해야 할까요?
15
출처: http://www.slideshare.net/diannemarsh/from-code-to-the-monkeys-continuous-delivery-at-
netflix/
Dianne Marsh (Director of Engineering, Netflix) said…
1. 왜 DevOps를 해야 할까요?
16
공통점을 뽑아보면…
Moving Fast!!
Focus on Customer!!
1. 왜 DevOps를 해야 할까요?
17
공통점을 뽑아보면…
즉, 고객 중심으로
빠르게
움직이고 있다.
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
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)
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)
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)
1. 왜 DevOps를 해야 할까요?
22
왜 DevOps를 해야 할까요?
빠르게 변하는 비지니스 환경과 사용자의 필요에 기민하게 대처
하고
결국은 비지니스가 계속 살아남기 위해서…
그래서, Damon Edwards (DTO solutions inc.)가 말하길…
“ DevOps is not about a technology,
DevOps is about a business problem.”
2
2. 그럼, 도데체 DevOps는 뭘까요?
2. 그럼, 도데체 DevOps는 뭘까요?
24
이런 말은 많습니다.
DevOps is NOT …
- A Job title.
- An Organizational Unit.
- A automation.
- A tool.
- Simply combining Dev & Ops.
…..
2. 그럼, 도데체 DevOps는 뭘까요?
25
But, there is not a clear definition
yet.
WHAT???
2. 그럼, 도데체 DevOps는 뭘까요?
26
• DevOps 정의 (Wikipedia)
DevOps는 소프트웨어 개발자와 정보 기술 전문가 간의 소통, 협
업 및
통합을 강조하는 개발 방법론.
데브옵스는 소프트웨어 개발 조직과 운영 조직간의 상호 의존적
대응이며 소프트웨어 제품과 서비스를 빠른 시간에 개발 및 배포
하는 것을목적으로 한다.
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)
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)]
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]
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)]
2. 그럼, 도데체 DevOps는 뭘까요?
31
1) DevOps의 유래 (그 이름을 갖게 된 역사)
출처: IT Revolution Press (http://itrevolution.com/the-history-of-devops/)
[ http://devopsdays.org/ ]
• 2009년 10월말 벨기에를 시작으로
DevOpsDay 컨퍼런스가 전 세계적으로 점
점 확산됨.
• DevOpsDay가 확산되면서 트위터에서 관련
된 트윗들이 #DevOps로 확산되게 됨.
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의 역사가 주는 교훈
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)을 추가
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/
2. 그럼, 도데체 DevOps는 뭘까요?
35
4) DevOps의 foundations
Lean은 낭비를 제거함으로 어떻게 고객에게 가치를 빠르게 제공할
수 있을까에 대한 생각이자 사고 방식 (Lean Thinking)
Lean의 핵심은 끊임없이 문제를 해결하고 개선하는 것
•Lean
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
2. 그럼, 도데체 DevOps는 뭘까요?
37
•OODA loop (OODA 주기 – 판단 및 결심 주기)
존 보이드 대령이 한국전에서 F-86과 MiG-15간의 전투에서 어떻게
10:1의 일방적인 승리를 얻을 수 있었나 분석하고 제시했던 이론. 존 보
이드 대령은 현대 전쟁 이론의 아버지라 일컫음.
• Competed Observation: 경쟁적 관찰
• Orientation: 상황 판단
• Decision: 결심
• Action: 행동
4) DevOps의 foundations
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”의 저자
2. 그럼, 도데체 DevOps는 뭘까요?
39
http://itrevolution.com/the-three-ways-principles-underpinning-devops/
5) DevOps를 지탱하는 the Three ways principles (Gene Kim)
2. 그럼, 도데체 DevOps는 뭘까요?
40
http://itrevolution.com/the-three-ways-principles-underpinning-devops/
5) DevOps를 지탱하는 the Three ways principles (Gene Kim)
2. 그럼, 도데체 DevOps는 뭘까요?
41
http://itrevolution.com/the-three-ways-principles-underpinning-devops/
5) DevOps를 지탱하는 the Three ways principles (Gene Kim)
2. 그럼, 도데체 DevOps는 뭘까요?
42
Robert Johnson(Engineering Director at FB)의 InfoQ 영상 (2010년 5월)
“만약 어제밤에
제가 아이디어가 하나 있었다면...
그걸 오늘 아침에 코딩해서…
오후에 그걸 사이트에 올릴 수 있구요…
내일이면 데이타를 얻을 수 있습니다.
제가 일반적인 다른 시스템에서
일년동안 배울 수 있는 것보다 훨씬 더 많은 것
들을 불과 몇 주 안에 배웠습니다.”
http://www.infoq.com/presentations/Facebook-Moving-Fast-at-Scale
• DevOps의 실례
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)
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에 집중
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로 봄.
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에 추가하는 것
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
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)
3
3. FB, Flickr, Netflix, Etsy, Google의 적용 사례
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
3. FB, Flickr, Netflix, Etsy, Google의 적용 사례
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
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
9) 문화
• 문제가 생기면 빠르게 버그 수정. 롤백은 잘 안함.
• 개발자들의 카르마 관리. 즉, 배포할 때 문제를 일으킨 코드를 작성한 개발자
들을 릴리즈팀에서 평판 관리하고 있음. (좋아요/싫어요 버튼으로)
• 카르마 점수가 낮은 개발자가 코드 머지 요청을 할 경우 더 엄격히 코드 리뷰
함.
Facebook 릴리즈 엔지니어링팀에 있는 Hotfix Bar에 있는 술병 사진.
성공적으로 릴리즈한 이후에 한 잔식으로 자축. 이 중에 카르마가 낮은 개발자가 선물한 술들이 있음.
출처: http://www.looah.com/article/view/983
3. FB, Flickr, Netflix, Etsy, Google의 적용 사례
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
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
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
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
출처: http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr
3. FB, Flickr, Netflix, Etsy, Google의 적용 사례
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 등을 공
유 받음
출처: http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr
3. FB, Flickr, Netflix, Etsy, Google의 적용 사례
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
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
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
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
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
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
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
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
• 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
• 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
3. FB, Flickr, Netflix, Etsy, Google의 적용 사례
4) Canary
출처: SRE@Google: Thousands of DevOps Since 2004 (https://www.youtube.com/watch?v=iIuTnhdTzK0)
72
3. FB, Flickr, Netflix, Etsy, Google의 적용 사례
4) Canary
출처: SRE@Google: Thousands of DevOps Since 2004 (https://www.youtube.com/watch?v=iIuTnhdTzK0)
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
3. FB, Flickr, Netflix, Etsy, Google의 적용 사례
6) Joint Responsibility
출처: SRE@Google: Thousands of DevOps Since 2004 (https://www.youtube.com/watch?v=iIuTnhdTzK0)
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
[참고] DevOps Team Topologies
3. FB, Flickr, Netflix, Etsy, Google의 적용 사례
• Type 1: Dev and Ops Collaboration (Flickr, Etsy)
출처: http://web.devopstopologies.com/
77
[참고] DevOps Team Topologies
3. FB, Flickr, Netflix, Etsy, Google의 적용 사례
출처: http://web.devopstopologies.com/
• Type 2: Fully Shared Ops Responsibilities (Netflix, Amazon)
78
[참고] DevOps Team Topologies
3. FB, Flickr, Netflix, Etsy, Google의 적용 사례
출처: http://web.devopstopologies.com/
• Type 7: SRE Team (Google)
4
4. 위메프의 DevOps 적용 사례
4. 위메프의 DevOps 적용 사례
80
• 치열한 경쟁 시장에서 어떻게 살아남을 것인가?
• 우리 개발 조직의 경쟁력은 뭘까?
• 어떻게 해야 우리의 경쟁력을 더 강화시킬 수 있을까?
• 고민하던 중에… The Phoenix Project와 Lean Enterprise를 읽게 됨.
고민…
4. 위메프의 DevOps 적용 사례
81
그럼, 어떻게? (이론상)
출처: 도서 Lean Enterprise
4. 위메프의 DevOps 적용 사례
82
하지만…
• DevOps는 Branch 전략, 프로세스, 인프라, 릴리즈, 자동화, 문
화 등등 모든 면에서 개선이 이뤄져야 하기 때문에 시간도 많이
걸리고 많은 변화가 필요함
• 2014년 하반기 그 당시 회사의 개발 환경은 상당히 열악한 상황
• 하지만, Flickr의 John Allspaw도 Etsy에 SVP로 입사해서
DevOps 정착시키는 데 6년 이상 걸렸음.
• 따라서, 조급해하지 말고.. 하나씩 해나가자!!
83
1) 내 자신이 먼저 Lean하게 생각하기
• 낭비를 제거함으로 어떻게 고객에게 가치를 빠르게
제공할 수 있을까에 대해 먼저 생각하기 (Lean
Thinking)
• 나의 역할은 조직원들이 문제에 부딪혔을 때 그 문
제를 해결하도록 도와주는 역할
출처: http://zzino.co.kr/blog/?p=173
4. 위메프의 DevOps 적용 사례
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
3) 목표 정하기
• 지시나 명령보단 Best Practices 중심의 문화
4. 위메프의 DevOps 적용 사례
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 적용 사례
4. 위메프의 DevOps 적용 사례
87
첫째, DevOps/Lean/CD로 개발 조직의 방향과 목표 설정하고 공유하기
• 개발 조직의 방향과 목표 설정하고 대표님, 다른 실장들, 개발 조직원들에게 공유
• 매월 첫주 부트캠프(신입 개발자 입사 교육) 첫번째 교육 시간에 공유
• 매주 금요일 오후 6시 (참고로, 퇴근시간은 7시)에 전체 개발자가 모이는 All Hands Meeting
을 통해서 조직 내 목표를 위해서 진행 중인 개선 사항(또는 진행 상황)을 공유
• 또, All Hands Meeting 시간에 Q&A 시간을 통해서 조직원들과 소통하려고 노력
4) 실행하기
4. 위메프의 DevOps 적용 사례
88
둘째, 개발/기획/인프라 실장 Daily Stand-up Meeting
• 주요 프로젝트 진행 상황 및 주요 업무 등을 서로 공유 / 우선 순위 합의 / 이슈 공유
• 같이 목표 설정하고 협업하기 더 쉬워졌음.
• 의사 결정이 빨라짐.
• 서로 조직에 대한 이해로 불필요한 오해
셋째, 배포를 늘리기 위해 개발팀을 도메인별로 나누고 MSA 기반으로 서
비스를 점차 분리해나감
• 각 개발팀의 도메인에 맞게 Source Repository 분리하여 서로 dependency 제거
• Deploy frequency 증가
• 개발 리소스와 상황을 고려하여 분리
4) 실행하기
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) 실행하기
4. 위메프의 DevOps 적용 사례
90
다섯째, 개발팀장, SE, DBA, 보안 담당자로 구성된 아키텍트 그룹을 만들
고 프로젝트 초기에 같이 리뷰
• Patrick Debois가 말한 Area 4에 해당
• 가급적 SE, DBA, 보안 담당자들도 프로젝트 담당자를 지정해서 가능하면 같이 Sprint
에 참여토록 권고
여섯째, 서비스 모니터링 TV를 개발팀 자리에도 같이 배치
• Patrick Debois가 말한 Area 2에 해당
• 서비스 장애 발생 시 개발팀도 바로 장애 인지해서 같이 원인 파악하며 정보를 그룹
채팅을 통해 Ops와 공유
• 결과적으로, MTTR 단축됨
4) 실행하기
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) 실행하기
4. 위메프의 DevOps 적용 사례
92
• 하루 배포 수: 기존의 약 2배 증가
• 2015년 프로젝트 성공률: 99%
• 2015년 상반기 대비 동시 진행 프로젝트 수: 2배 증가
• 2015년 상반기 대비 개발자 1명당 진행 중인 프로젝트: 30% 증가
• 2015년 상반기 대비 장애 발생 수: 50% 감소
• Mean Time to Recover(MTTR)도 단축
5) 1년 간의 결과
4. 위메프의 DevOps 적용 사례
93
• DevOps의 끝은 없다. 지속적인 개선해야 한다.
• 가장 어려운 건 문화다. 그래서, 사람과 소통이 중요하다.
• 일하는 사람 입장에선 솔직히 DevOps 힘들다. 그래서, 본인들의
innovation으로 배울 수 있는 분위기와 환경을 만들어주는 것과
Automation으로 좀 더 중요한 일에 집중할 수 있게 해야 지속 가능하
다.
• 테스트 자동화가 제약도 많고 힘들고 시간도 많이 걸린다. 따라서,
많이 투자해야 하는 부분 중에 하나.
6) 그간의 여정을 통해 느낀 점
94
감사합니다
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/
Further Reading
97

More Related Content

What's hot

(발표자료) CentOS EOL에 따른 대응 OS 검토 및 적용 방안.pdf
(발표자료) CentOS EOL에 따른 대응 OS 검토 및 적용 방안.pdf(발표자료) CentOS EOL에 따른 대응 OS 검토 및 적용 방안.pdf
(발표자료) CentOS EOL에 따른 대응 OS 검토 및 적용 방안.pdfssuserf8b8bd1
 
91APP: 從 "零" 開始的 DevOps
91APP: 從 "零" 開始的 DevOps91APP: 從 "零" 開始的 DevOps
91APP: 從 "零" 開始的 DevOpsAndrew Wu
 
데브옵스(DevOps)의 현재와 미래 - ChatOps & VoiceOps (윤석찬)
데브옵스(DevOps)의 현재와 미래 - ChatOps & VoiceOps (윤석찬)데브옵스(DevOps)의 현재와 미래 - ChatOps & VoiceOps (윤석찬)
데브옵스(DevOps)의 현재와 미래 - ChatOps & VoiceOps (윤석찬)Amazon Web Services Korea
 
Docker Introduction
Docker IntroductionDocker Introduction
Docker IntroductionSparkbit
 
[2022 DevOpsDays Taipei] 走過 DevOps 風雨的下一步
[2022 DevOpsDays Taipei] 走過 DevOps 風雨的下一步[2022 DevOpsDays Taipei] 走過 DevOps 風雨的下一步
[2022 DevOpsDays Taipei] 走過 DevOps 風雨的下一步Edward Kuo
 
Continuous Integration With Jenkins
Continuous Integration With JenkinsContinuous Integration With Jenkins
Continuous Integration With JenkinsEdureka!
 
DevOps:建造開發維運的跨界之橋 (@ C.C. Agile #37)
DevOps:建造開發維運的跨界之橋 (@ C.C. Agile #37)DevOps:建造開發維運的跨界之橋 (@ C.C. Agile #37)
DevOps:建造開發維運的跨界之橋 (@ C.C. Agile #37)Chen Cheng-Wei
 
DevOps Tutorial For Beginners | DevOps Tutorial | DevOps Tools | DevOps Train...
DevOps Tutorial For Beginners | DevOps Tutorial | DevOps Tools | DevOps Train...DevOps Tutorial For Beginners | DevOps Tutorial | DevOps Tools | DevOps Train...
DevOps Tutorial For Beginners | DevOps Tutorial | DevOps Tools | DevOps Train...Simplilearn
 
DevOps with GitHub Actions
DevOps with GitHub ActionsDevOps with GitHub Actions
DevOps with GitHub ActionsNilesh Gule
 
『コンテナ疲れ』と戦う、k8s・PaaS・Serverlessの活用法
『コンテナ疲れ』と戦う、k8s・PaaS・Serverlessの活用法『コンテナ疲れ』と戦う、k8s・PaaS・Serverlessの活用法
『コンテナ疲れ』と戦う、k8s・PaaS・Serverlessの活用法Kazuto Kusama
 
Cloud foundry: The Platform for Forging Cloud Native Applications
Cloud foundry: The Platform for Forging Cloud Native ApplicationsCloud foundry: The Platform for Forging Cloud Native Applications
Cloud foundry: The Platform for Forging Cloud Native ApplicationsChip Childers
 
AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안 :: 김필중 :: AWS Summit Seoul 20
AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안 :: 김필중 :: AWS Summit Seoul 20AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안 :: 김필중 :: AWS Summit Seoul 20
AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안 :: 김필중 :: AWS Summit Seoul 20Amazon Web Services Korea
 
Terraform을 이용한 Infrastructure as Code 실전 구성하기 :: 변정훈::AWS Summit Seoul 2018
 Terraform을 이용한 Infrastructure as Code 실전 구성하기 :: 변정훈::AWS Summit Seoul 2018 Terraform을 이용한 Infrastructure as Code 실전 구성하기 :: 변정훈::AWS Summit Seoul 2018
Terraform을 이용한 Infrastructure as Code 실전 구성하기 :: 변정훈::AWS Summit Seoul 2018Amazon Web Services Korea
 

What's hot (20)

DevOps 101
DevOps 101DevOps 101
DevOps 101
 
(발표자료) CentOS EOL에 따른 대응 OS 검토 및 적용 방안.pdf
(발표자료) CentOS EOL에 따른 대응 OS 검토 및 적용 방안.pdf(발표자료) CentOS EOL에 따른 대응 OS 검토 및 적용 방안.pdf
(발표자료) CentOS EOL에 따른 대응 OS 검토 및 적용 방안.pdf
 
Introduction to DevOps
Introduction to DevOpsIntroduction to DevOps
Introduction to DevOps
 
91APP: 從 "零" 開始的 DevOps
91APP: 從 "零" 開始的 DevOps91APP: 從 "零" 開始的 DevOps
91APP: 從 "零" 開始的 DevOps
 
데브옵스(DevOps)의 현재와 미래 - ChatOps & VoiceOps (윤석찬)
데브옵스(DevOps)의 현재와 미래 - ChatOps & VoiceOps (윤석찬)데브옵스(DevOps)의 현재와 미래 - ChatOps & VoiceOps (윤석찬)
데브옵스(DevOps)의 현재와 미래 - ChatOps & VoiceOps (윤석찬)
 
Docker Introduction
Docker IntroductionDocker Introduction
Docker Introduction
 
[2022 DevOpsDays Taipei] 走過 DevOps 風雨的下一步
[2022 DevOpsDays Taipei] 走過 DevOps 風雨的下一步[2022 DevOpsDays Taipei] 走過 DevOps 風雨的下一步
[2022 DevOpsDays Taipei] 走過 DevOps 風雨的下一步
 
DevOps introduction
DevOps introductionDevOps introduction
DevOps introduction
 
Continuous Integration With Jenkins
Continuous Integration With JenkinsContinuous Integration With Jenkins
Continuous Integration With Jenkins
 
DevOps:建造開發維運的跨界之橋 (@ C.C. Agile #37)
DevOps:建造開發維運的跨界之橋 (@ C.C. Agile #37)DevOps:建造開發維運的跨界之橋 (@ C.C. Agile #37)
DevOps:建造開發維運的跨界之橋 (@ C.C. Agile #37)
 
Multi Stage Docker Build
Multi Stage Docker Build Multi Stage Docker Build
Multi Stage Docker Build
 
SAFe and DevOps - better together
SAFe and DevOps - better togetherSAFe and DevOps - better together
SAFe and DevOps - better together
 
DevOps Tutorial For Beginners | DevOps Tutorial | DevOps Tools | DevOps Train...
DevOps Tutorial For Beginners | DevOps Tutorial | DevOps Tools | DevOps Train...DevOps Tutorial For Beginners | DevOps Tutorial | DevOps Tools | DevOps Train...
DevOps Tutorial For Beginners | DevOps Tutorial | DevOps Tools | DevOps Train...
 
DevOps - A Gentle Introduction
DevOps - A Gentle IntroductionDevOps - A Gentle Introduction
DevOps - A Gentle Introduction
 
Docker
DockerDocker
Docker
 
DevOps with GitHub Actions
DevOps with GitHub ActionsDevOps with GitHub Actions
DevOps with GitHub Actions
 
『コンテナ疲れ』と戦う、k8s・PaaS・Serverlessの活用法
『コンテナ疲れ』と戦う、k8s・PaaS・Serverlessの活用法『コンテナ疲れ』と戦う、k8s・PaaS・Serverlessの活用法
『コンテナ疲れ』と戦う、k8s・PaaS・Serverlessの活用法
 
Cloud foundry: The Platform for Forging Cloud Native Applications
Cloud foundry: The Platform for Forging Cloud Native ApplicationsCloud foundry: The Platform for Forging Cloud Native Applications
Cloud foundry: The Platform for Forging Cloud Native Applications
 
AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안 :: 김필중 :: AWS Summit Seoul 20
AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안 :: 김필중 :: AWS Summit Seoul 20AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안 :: 김필중 :: AWS Summit Seoul 20
AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안 :: 김필중 :: AWS Summit Seoul 20
 
Terraform을 이용한 Infrastructure as Code 실전 구성하기 :: 변정훈::AWS Summit Seoul 2018
 Terraform을 이용한 Infrastructure as Code 실전 구성하기 :: 변정훈::AWS Summit Seoul 2018 Terraform을 이용한 Infrastructure as Code 실전 구성하기 :: 변정훈::AWS Summit Seoul 2018
Terraform을 이용한 Infrastructure as Code 실전 구성하기 :: 변정훈::AWS Summit Seoul 2018
 

Viewers also liked

170718_테헤란로 런치클럽_스타트업 성공을 위한 AWS 첫걸음 _HB Smith
170718_테헤란로 런치클럽_스타트업 성공을 위한 AWS 첫걸음 _HB Smith170718_테헤란로 런치클럽_스타트업 성공을 위한 AWS 첫걸음 _HB Smith
170718_테헤란로 런치클럽_스타트업 성공을 위한 AWS 첫걸음 _HB SmithStartupAlliance
 
Android 5.0 & Material Design
Android 5.0 & Material DesignAndroid 5.0 & Material Design
Android 5.0 & Material DesignManjong Han
 
그런데 스타트업이 뭐더라
그런데 스타트업이 뭐더라그런데 스타트업이 뭐더라
그런데 스타트업이 뭐더라Hyun-woo Park
 
[1A7]Ansible의이해와활용
[1A7]Ansible의이해와활용[1A7]Ansible의이해와활용
[1A7]Ansible의이해와활용NAVER D2
 
Ksug2015 jpa5 스프링과jpa
Ksug2015 jpa5 스프링과jpaKsug2015 jpa5 스프링과jpa
Ksug2015 jpa5 스프링과jpaYounghan Kim
 
Ksug2015 - JPA2, JPA 기초와매핑
Ksug2015 - JPA2, JPA 기초와매핑Ksug2015 - JPA2, JPA 기초와매핑
Ksug2015 - JPA2, JPA 기초와매핑Younghan Kim
 
코드로 인프라 관리하기 - 자동화 툴 소개
코드로 인프라 관리하기 - 자동화 툴 소개코드로 인프라 관리하기 - 자동화 툴 소개
코드로 인프라 관리하기 - 자동화 툴 소개태준 문
 
Angularjs 도입 선택 가이드
Angularjs 도입 선택 가이드Angularjs 도입 선택 가이드
Angularjs 도입 선택 가이드NAVER D2
 
Project TIMAT - infrastructure as code
Project TIMAT - infrastructure as codeProject TIMAT - infrastructure as code
Project TIMAT - infrastructure as codeJesang Yoon
 
서버 개발자가 바라 본 Functional Reactive Programming with RxJava - SpringCamp2015
서버 개발자가 바라 본 Functional Reactive Programming with RxJava - SpringCamp2015서버 개발자가 바라 본 Functional Reactive Programming with RxJava - SpringCamp2015
서버 개발자가 바라 본 Functional Reactive Programming with RxJava - SpringCamp2015NAVER / MusicPlatform
 
Kernel Recipes 2017: Using Linux perf at Netflix
Kernel Recipes 2017: Using Linux perf at NetflixKernel Recipes 2017: Using Linux perf at Netflix
Kernel Recipes 2017: Using Linux perf at NetflixBrendan Gregg
 
Container Performance Analysis
Container Performance AnalysisContainer Performance Analysis
Container Performance AnalysisBrendan Gregg
 
유연하고 확장성 있는 빅데이터 처리
유연하고 확장성 있는 빅데이터 처리유연하고 확장성 있는 빅데이터 처리
유연하고 확장성 있는 빅데이터 처리NAVER D2
 
[244]네트워크 모니터링 시스템(nms)을 지탱하는 기술
[244]네트워크 모니터링 시스템(nms)을 지탱하는 기술[244]네트워크 모니터링 시스템(nms)을 지탱하는 기술
[244]네트워크 모니터링 시스템(nms)을 지탱하는 기술NAVER D2
 
[216]네이버 검색 사용자를 만족시켜라! 의도파악과 의미검색
[216]네이버 검색 사용자를 만족시켜라!   의도파악과 의미검색[216]네이버 검색 사용자를 만족시켜라!   의도파악과 의미검색
[216]네이버 검색 사용자를 만족시켜라! 의도파악과 의미검색NAVER D2
 
[212]big models without big data using domain specific deep networks in data-...
[212]big models without big data using domain specific deep networks in data-...[212]big models without big data using domain specific deep networks in data-...
[212]big models without big data using domain specific deep networks in data-...NAVER D2
 
[213]building ai to recreate our visual world
[213]building ai to recreate our visual world[213]building ai to recreate our visual world
[213]building ai to recreate our visual worldNAVER D2
 
[234]멀티테넌트 하둡 클러스터 운영 경험기
[234]멀티테넌트 하둡 클러스터 운영 경험기[234]멀티테넌트 하둡 클러스터 운영 경험기
[234]멀티테넌트 하둡 클러스터 운영 경험기NAVER D2
 
[242]open stack neutron dataplane 구현
[242]open stack neutron   dataplane 구현[242]open stack neutron   dataplane 구현
[242]open stack neutron dataplane 구현NAVER D2
 

Viewers also liked (20)

170718_테헤란로 런치클럽_스타트업 성공을 위한 AWS 첫걸음 _HB Smith
170718_테헤란로 런치클럽_스타트업 성공을 위한 AWS 첫걸음 _HB Smith170718_테헤란로 런치클럽_스타트업 성공을 위한 AWS 첫걸음 _HB Smith
170718_테헤란로 런치클럽_스타트업 성공을 위한 AWS 첫걸음 _HB Smith
 
Android 5.0 & Material Design
Android 5.0 & Material DesignAndroid 5.0 & Material Design
Android 5.0 & Material Design
 
그런데 스타트업이 뭐더라
그런데 스타트업이 뭐더라그런데 스타트업이 뭐더라
그런데 스타트업이 뭐더라
 
[1A7]Ansible의이해와활용
[1A7]Ansible의이해와활용[1A7]Ansible의이해와활용
[1A7]Ansible의이해와활용
 
Ksug2015 jpa5 스프링과jpa
Ksug2015 jpa5 스프링과jpaKsug2015 jpa5 스프링과jpa
Ksug2015 jpa5 스프링과jpa
 
DevOps with Docker
DevOps with DockerDevOps with Docker
DevOps with Docker
 
Ksug2015 - JPA2, JPA 기초와매핑
Ksug2015 - JPA2, JPA 기초와매핑Ksug2015 - JPA2, JPA 기초와매핑
Ksug2015 - JPA2, JPA 기초와매핑
 
코드로 인프라 관리하기 - 자동화 툴 소개
코드로 인프라 관리하기 - 자동화 툴 소개코드로 인프라 관리하기 - 자동화 툴 소개
코드로 인프라 관리하기 - 자동화 툴 소개
 
Angularjs 도입 선택 가이드
Angularjs 도입 선택 가이드Angularjs 도입 선택 가이드
Angularjs 도입 선택 가이드
 
Project TIMAT - infrastructure as code
Project TIMAT - infrastructure as codeProject TIMAT - infrastructure as code
Project TIMAT - infrastructure as code
 
서버 개발자가 바라 본 Functional Reactive Programming with RxJava - SpringCamp2015
서버 개발자가 바라 본 Functional Reactive Programming with RxJava - SpringCamp2015서버 개발자가 바라 본 Functional Reactive Programming with RxJava - SpringCamp2015
서버 개발자가 바라 본 Functional Reactive Programming with RxJava - SpringCamp2015
 
Kernel Recipes 2017: Using Linux perf at Netflix
Kernel Recipes 2017: Using Linux perf at NetflixKernel Recipes 2017: Using Linux perf at Netflix
Kernel Recipes 2017: Using Linux perf at Netflix
 
Container Performance Analysis
Container Performance AnalysisContainer Performance Analysis
Container Performance Analysis
 
유연하고 확장성 있는 빅데이터 처리
유연하고 확장성 있는 빅데이터 처리유연하고 확장성 있는 빅데이터 처리
유연하고 확장성 있는 빅데이터 처리
 
[244]네트워크 모니터링 시스템(nms)을 지탱하는 기술
[244]네트워크 모니터링 시스템(nms)을 지탱하는 기술[244]네트워크 모니터링 시스템(nms)을 지탱하는 기술
[244]네트워크 모니터링 시스템(nms)을 지탱하는 기술
 
[216]네이버 검색 사용자를 만족시켜라! 의도파악과 의미검색
[216]네이버 검색 사용자를 만족시켜라!   의도파악과 의미검색[216]네이버 검색 사용자를 만족시켜라!   의도파악과 의미검색
[216]네이버 검색 사용자를 만족시켜라! 의도파악과 의미검색
 
[212]big models without big data using domain specific deep networks in data-...
[212]big models without big data using domain specific deep networks in data-...[212]big models without big data using domain specific deep networks in data-...
[212]big models without big data using domain specific deep networks in data-...
 
[213]building ai to recreate our visual world
[213]building ai to recreate our visual world[213]building ai to recreate our visual world
[213]building ai to recreate our visual world
 
[234]멀티테넌트 하둡 클러스터 운영 경험기
[234]멀티테넌트 하둡 클러스터 운영 경험기[234]멀티테넌트 하둡 클러스터 운영 경험기
[234]멀티테넌트 하둡 클러스터 운영 경험기
 
[242]open stack neutron dataplane 구현
[242]open stack neutron   dataplane 구현[242]open stack neutron   dataplane 구현
[242]open stack neutron dataplane 구현
 

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

2014 공개소프트웨어 대회 소프트웨어 개발 트렌드의 변화
2014 공개소프트웨어 대회 소프트웨어 개발 트렌드의 변화2014 공개소프트웨어 대회 소프트웨어 개발 트렌드의 변화
2014 공개소프트웨어 대회 소프트웨어 개발 트렌드의 변화Terry Cho
 
[111]open, share, enjoy 네이버의 오픈소스 활동
[111]open, share, enjoy 네이버의 오픈소스 활동[111]open, share, enjoy 네이버의 오픈소스 활동
[111]open, share, enjoy 네이버의 오픈소스 활동NAVER D2
 
클라우드 네이티브로의 전환을 위한 여정
클라우드 네이티브로의 전환을 위한 여정클라우드 네이티브로의 전환을 위한 여정
클라우드 네이티브로의 전환을 위한 여정VMware Tanzu Korea
 
[H3 2012] 앱(APP) 중심으로 생각하기 - DevOps와 자동화
[H3 2012] 앱(APP) 중심으로 생각하기 - DevOps와 자동화[H3 2012] 앱(APP) 중심으로 생각하기 - DevOps와 자동화
[H3 2012] 앱(APP) 중심으로 생각하기 - DevOps와 자동화KTH, 케이티하이텔
 
꿀밋업시리즈3탄_Spring Boot를 활용한 마이크로서비스 개발과 페어프로그래밍(TDD)
꿀밋업시리즈3탄_Spring Boot를 활용한 마이크로서비스 개발과 페어프로그래밍(TDD)꿀밋업시리즈3탄_Spring Boot를 활용한 마이크로서비스 개발과 페어프로그래밍(TDD)
꿀밋업시리즈3탄_Spring Boot를 활용한 마이크로서비스 개발과 페어프로그래밍(TDD)VMware Tanzu Korea
 
Dev ops Introduction
Dev ops IntroductionDev ops Introduction
Dev ops Introduction영기 김
 
DevOps 발표 자료 다운로드
DevOps 발표 자료 다운로드DevOps 발표 자료 다운로드
DevOps 발표 자료 다운로드Opennaru, inc.
 
Understanding of Open Source
Understanding of Open SourceUnderstanding of Open Source
Understanding of Open SourceKevin Kim
 
오픈소스 생태계 일원으로서의 개발자(자막 버전)
오픈소스 생태계 일원으로서의 개발자(자막 버전)오픈소스 생태계 일원으로서의 개발자(자막 버전)
오픈소스 생태계 일원으로서의 개발자(자막 버전)JeongHun Byeon
 
131 deview 2013 yobi-채수원
131 deview 2013 yobi-채수원131 deview 2013 yobi-채수원
131 deview 2013 yobi-채수원NAVER D2
 
Mastering devops with oracle 강인호
Mastering devops with oracle 강인호Mastering devops with oracle 강인호
Mastering devops with oracle 강인호Inho Kang
 
개발자의 첫단계
개발자의 첫단계개발자의 첫단계
개발자의 첫단계yejiHong7
 
[오픈소스컨설팅]Session 6. scrum과 jira 기반의 소프트웨어 개발 프로세스
[오픈소스컨설팅]Session 6. scrum과 jira 기반의 소프트웨어 개발 프로세스[오픈소스컨설팅]Session 6. scrum과 jira 기반의 소프트웨어 개발 프로세스
[오픈소스컨설팅]Session 6. scrum과 jira 기반의 소프트웨어 개발 프로세스Hee Jae Lee
 
SRE/DevOps 신입으로 1년간 근무하며 겪은 경험담
SRE/DevOps 신입으로 1년간 근무하며 겪은 경험담SRE/DevOps 신입으로 1년간 근무하며 겪은 경험담
SRE/DevOps 신입으로 1년간 근무하며 겪은 경험담Juhyun Kim
 
Github 으로 학교 팀 프로젝트 하기
Github 으로 학교 팀 프로젝트 하기Github 으로 학교 팀 프로젝트 하기
Github 으로 학교 팀 프로젝트 하기nexusz99
 
경희대 해커 기술 세미나 - Git hub으로 학교 팀프로젝트 하기(조성수)
경희대 해커 기술 세미나 - Git hub으로 학교 팀프로젝트 하기(조성수)경희대 해커 기술 세미나 - Git hub으로 학교 팀프로젝트 하기(조성수)
경희대 해커 기술 세미나 - Git hub으로 학교 팀프로젝트 하기(조성수)NAVER D2
 
커뮤니티와 함께한 예비개발자 성장기- 조성수님
커뮤니티와 함께한 예비개발자 성장기- 조성수님커뮤니티와 함께한 예비개발자 성장기- 조성수님
커뮤니티와 함께한 예비개발자 성장기- 조성수님NAVER D2
 
ALM과 DevOps 그리고 Azure DevOps
ALM과 DevOps 그리고 Azure DevOpsALM과 DevOps 그리고 Azure DevOps
ALM과 DevOps 그리고 Azure DevOpsTaeyoung Kim
 
Ndc17 DevOps? DevOps개발자? 북미에서의 6년
Ndc17 DevOps? DevOps개발자? 북미에서의 6년Ndc17 DevOps? DevOps개발자? 북미에서의 6년
Ndc17 DevOps? DevOps개발자? 북미에서의 6년Taehyun Kim
 

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

2014 공개소프트웨어 대회 소프트웨어 개발 트렌드의 변화
2014 공개소프트웨어 대회 소프트웨어 개발 트렌드의 변화2014 공개소프트웨어 대회 소프트웨어 개발 트렌드의 변화
2014 공개소프트웨어 대회 소프트웨어 개발 트렌드의 변화
 
[111]open, share, enjoy 네이버의 오픈소스 활동
[111]open, share, enjoy 네이버의 오픈소스 활동[111]open, share, enjoy 네이버의 오픈소스 활동
[111]open, share, enjoy 네이버의 오픈소스 활동
 
클라우드 네이티브로의 전환을 위한 여정
클라우드 네이티브로의 전환을 위한 여정클라우드 네이티브로의 전환을 위한 여정
클라우드 네이티브로의 전환을 위한 여정
 
[H3 2012] 앱(APP) 중심으로 생각하기 - DevOps와 자동화
[H3 2012] 앱(APP) 중심으로 생각하기 - DevOps와 자동화[H3 2012] 앱(APP) 중심으로 생각하기 - DevOps와 자동화
[H3 2012] 앱(APP) 중심으로 생각하기 - DevOps와 자동화
 
꿀밋업시리즈3탄_Spring Boot를 활용한 마이크로서비스 개발과 페어프로그래밍(TDD)
꿀밋업시리즈3탄_Spring Boot를 활용한 마이크로서비스 개발과 페어프로그래밍(TDD)꿀밋업시리즈3탄_Spring Boot를 활용한 마이크로서비스 개발과 페어프로그래밍(TDD)
꿀밋업시리즈3탄_Spring Boot를 활용한 마이크로서비스 개발과 페어프로그래밍(TDD)
 
Dev ops Introduction
Dev ops IntroductionDev ops Introduction
Dev ops Introduction
 
DevOps 발표 자료 다운로드
DevOps 발표 자료 다운로드DevOps 발표 자료 다운로드
DevOps 발표 자료 다운로드
 
Understanding of Open Source
Understanding of Open SourceUnderstanding of Open Source
Understanding of Open Source
 
오픈소스 생태계 일원으로서의 개발자(자막 버전)
오픈소스 생태계 일원으로서의 개발자(자막 버전)오픈소스 생태계 일원으로서의 개발자(자막 버전)
오픈소스 생태계 일원으로서의 개발자(자막 버전)
 
131 deview 2013 yobi-채수원
131 deview 2013 yobi-채수원131 deview 2013 yobi-채수원
131 deview 2013 yobi-채수원
 
Mastering devops with oracle 강인호
Mastering devops with oracle 강인호Mastering devops with oracle 강인호
Mastering devops with oracle 강인호
 
개발자의 첫단계
개발자의 첫단계개발자의 첫단계
개발자의 첫단계
 
[오픈소스컨설팅]Session 6. scrum과 jira 기반의 소프트웨어 개발 프로세스
[오픈소스컨설팅]Session 6. scrum과 jira 기반의 소프트웨어 개발 프로세스[오픈소스컨설팅]Session 6. scrum과 jira 기반의 소프트웨어 개발 프로세스
[오픈소스컨설팅]Session 6. scrum과 jira 기반의 소프트웨어 개발 프로세스
 
SRE/DevOps 신입으로 1년간 근무하며 겪은 경험담
SRE/DevOps 신입으로 1년간 근무하며 겪은 경험담SRE/DevOps 신입으로 1년간 근무하며 겪은 경험담
SRE/DevOps 신입으로 1년간 근무하며 겪은 경험담
 
Github 으로 학교 팀 프로젝트 하기
Github 으로 학교 팀 프로젝트 하기Github 으로 학교 팀 프로젝트 하기
Github 으로 학교 팀 프로젝트 하기
 
경희대 해커 기술 세미나 - Git hub으로 학교 팀프로젝트 하기(조성수)
경희대 해커 기술 세미나 - Git hub으로 학교 팀프로젝트 하기(조성수)경희대 해커 기술 세미나 - Git hub으로 학교 팀프로젝트 하기(조성수)
경희대 해커 기술 세미나 - Git hub으로 학교 팀프로젝트 하기(조성수)
 
커뮤니티와 함께한 예비개발자 성장기- 조성수님
커뮤니티와 함께한 예비개발자 성장기- 조성수님커뮤니티와 함께한 예비개발자 성장기- 조성수님
커뮤니티와 함께한 예비개발자 성장기- 조성수님
 
ALM과 DevOps 그리고 Azure DevOps
ALM과 DevOps 그리고 Azure DevOpsALM과 DevOps 그리고 Azure DevOps
ALM과 DevOps 그리고 Azure DevOps
 
Ndc17 DevOps? DevOps개발자? 북미에서의 6년
Ndc17 DevOps? DevOps개발자? 북미에서의 6년Ndc17 DevOps? DevOps개발자? 북미에서의 6년
Ndc17 DevOps? DevOps개발자? 북미에서의 6년
 
DevOps
DevOpsDevOps
DevOps
 

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
  • 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)
  • 40. 2. 그럼, 도데체 DevOps는 뭘까요? 40 http://itrevolution.com/the-three-ways-principles-underpinning-devops/ 5) DevOps를 지탱하는 the Three ways principles (Gene Kim)
  • 41. 2. 그럼, 도데체 DevOps는 뭘까요? 41 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의 적용 사례
  • 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) 그간의 여정을 통해 느낀 점
  • 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/