![ Image 기반의 배포 페러다임
Infra에 문제가 발생시, 수정
하지 않고, Re-Deploy
CM(Configuration
Management) Tool을 이용하
여, 쉽고 빠르게 신규 환경 구
성
클라우드 기반 PaaS/IaaS에서
쉽게 구현
In each cluster’s [of 10,000 servers] first year, it’s typical
that 1,000 individual machine failures will occur;
thousands of hard drive failures will occur; one power
distribution unit will fail, bringing down 500 to 1,000
machines for about 6 hours; 20 racks will fail, each time
causing 40 to 80 machines to vanish from the network; 5
racks will “go wonky,” with half their network packets
missing in action; and the cluster will have to be rewired
once, affecting 5 percent of the machines at any given
moment over a 2-day span, Dean said. And there’s about
a 50 percent chance that the cluster will overheat, taking
down most of the servers in less than 5 minutes and
taking 1 to 2 days to recover.
Jeff Dean, Fellow, Google
Immutable Infrastructure](https://image.slidesharecdn.com/devopsv1-170511012740/85/DevOps-and-Microservice-26-320.jpg)
DevOps and Microservice
- 1. DevOps in Practices CloudBread, [email protected] Inho Kang Cloud Native Application 개발의 필수 요소
- 2. 01. What is DevOps? 03. Micro Service Architecture 04. MSA Based On DevOps 02. Features of DevOps
- 3. 01.
- 4. 심봉사 문고리 잡기? 신생기업 (Cloud Native, Unicorn) 조직 이름, 직무 이름? Build/Deploy 자동화
- 5. Definition DevOps 는 높은 품질을 유지하면서 시스템에 대한 변경 사항의 적용과 그 변경사항을 일 반적인 생산 환경에 적용되는 동안의 필요한 시간을 줄이기 위한 일련의 실천 방법 (practices)이다. - from SEI Series “DevOps: A Software Architect’s Perspective” DevOps라는 합성어는 소프트웨어 개발자들과 IT 종사자들 사이의 의사소통, 협업, 융합 을 강조한 소프트웨어 개발 방법론이며, 소프트웨어 개발과 IT 운영간의 상호 의존관계에 대한 산물이다. DevOps 는 조직에서 소프트웨어 상품과 서비스를 신속히 생산하는 것에 도움이 되는 것을 목적으로 한다. - from Wikipedia
- 6. Code Build Test ReleasePlan Deploy Operate Agile Development Continuous Integration Continuous Delivery Continuous Deployment DevOps
- 7. 10+ Deploys per Day: Dev and Ops Cooperation at Flickr (2009) : • 51 total employees • 10 deploys per day https://www.youtube.com/watch?v=LdOe18KhtT4 Patrick Debois decided to organize an event in Ghent, Belgium, called DevOpsDays. The name "DevOpsDays" struck a chord, and the conference has become a recurring event. DevOpsDays was abbreviated to "DevOps" in conversations on Twitter and various Internet forums.
- 10. From : 2016 State of DevOps, Puppet Labs
- 11. Hey Ops - Here’s our code...good luck! • “Code is written...it’s your problem now”
- 12. 갑자기 알 수 없는 장애가 일어나기 때문에 어느 누구도 어떤 얘기도 해준게 없기 때문에 그들은 언제나 어떤 변화 에 대해서도 “No” Ops Stereotype • “They say no all the time”
- 13. Developer : I want change! Operations: I want stability! 내 시스템이 아니라 당신 코드가 문제라고! 내 코드가 아니라 당신 시스템이 문제라고! Dev and Ops
- 14. 새로운 기능을 추가하기 위한 목표 Dev (개발) Ops (운영) DevOps 빠르고 안정된 시스템을 유지 하기 위한 목표 새로운 목표: 새로운 기능 추가 뿐만 안정적이면서 빠르고 가용성 있는 시스템 운영
- 15. Increased Agility • Increase frequency of releases Increased Quality • To Increase end- user satisfaction Improved Innovation • To Increase Innovati on cycles Reduced Outage • Upto 80% outages are change-related Focused on Speed, Agility and Time to Market
- 16. Network Storage Compute Hypervisor Operating System JVM App Server Application PaaSIaaS 과거: 운영자(Ops)가 수동으로 각 계층 프로비저닝 현재: 개발자(Dev)가 간편한 툴들을 통해 하드웨어와 소프트웨어 전체 스택을 프로비저닝 할 수 있음 Infrastructure as Code Cloud Tool REST API PaaS를 통해 리소스 프로비저닝이 간편해 짐 Provisioning
- 17. 2005년 Puppet을 시작으로 다양한 자동화 툴 개발 Capital + mechanical automation always win over labor
- 18. 02.
- 19. Culture Technology • Culture is what’s behind DevOps; technology is the enabler
- 20. 논의존중 남탓 안하기 “완료” = 서비스 릴리즈 • Dev respect for ops • Ops respect for dev • Don’t stereotype • Don’t just say “no” • Don’t hide things • Ops should be in dev discussions • Dev should be in ops discussions • Shared runbooks/escalation plans • Ops should give devs access to systems • No fingerpointing! • Dev’s responsibility does not end when it’s in production • “Throwing it over the wall” is dead
- 22. Shared Version Control Infra as Code One Step Build /Deploy Don’t Fix Anything
- 23. Base Image Install Binaries Configure Software Make Software Work Together Patch/Push Config Changes Step 1 Pick a Tool Step 2 Script your environment Step 3 Run your scripts against all hosts 서버 구성환경을 코드로 저장 관리
- 24. 단일 서버를 이용한 코드 및 빌드 산출물 관리 (Single Source of Truth) 소스코드가 Commit될 때마다, 또는 적어도 일단위 빌드 + 자 동화된 테스트 수행 트렁크를 이용한 개별 소스코 드저장 Flags을 이용하여 기능 활성화
- 25. 매뉴얼 build/deploy 스케줄 기발 빌드 - 일/주/ 월 단위 빌드 코드 체크인시 자동 빌드 테스트 자동화 및 오류 리포팅
- 26. Image 기반의 배포 페러다임 Infra에 문제가 발생시, 수정 하지 않고, Re-Deploy CM(Configuration Management) Tool을 이용하 여, 쉽고 빠르게 신규 환경 구 성 클라우드 기반 PaaS/IaaS에서 쉽게 구현 In each cluster’s [of 10,000 servers] first year, it’s typical that 1,000 individual machine failures will occur; thousands of hard drive failures will occur; one power distribution unit will fail, bringing down 500 to 1,000 machines for about 6 hours; 20 racks will fail, each time causing 40 to 80 machines to vanish from the network; 5 racks will “go wonky,” with half their network packets missing in action; and the cluster will have to be rewired once, affecting 5 percent of the machines at any given moment over a 2-day span, Dean said. And there’s about a 50 percent chance that the cluster will overheat, taking down most of the servers in less than 5 minutes and taking 1 to 2 days to recover. Jeff Dean, Fellow, Google Immutable Infrastructure
- 27. 03.
- 28. Middleware/App Server Transactions/Synchronous API Calls/Asynchronous Monolith Problem : 1. Scaling 2. Performance 3. Deploy 4. Down
- 29. Micro Services A collection of smaller applications all working together to deliver a t otal experience to the end user. Increased efficiency • Splitting your services gives you the ability to scale o nly the parts of the site that is slow • Less wastage of service resource • More cost efficient • An individual slow performing service doesn’t slow all services • Less user frustration
- 30. Micro Services A collection of smaller applications all working together to deliver a t otal experience to the end user. Easier Updates • Updating a smaller code base is easier • Less likely to have a regression issue • Less likely to push a feature that isn’t ready from another team • Disable or slowly fail users over to the new version • You don’t put any other part of the service at risk • Easier roll back if the update fails
- 31. Micro Services A collection of smaller applications all working together to deliver a t otal experience to the end user. Increased stability • Gracefully fail parts of the site • If one service fails the rest of the site still operates • Clever use of JS calls to services can detect failures and mask it from the end user • Much better end user experience
- 32. User Interface Application Datastore Infrastructure Resulting SoftwareTypical Enterprise Organization Structure Head of IT Head of Operation Head of DBAs Head of Infrastructure Head of App Dev Head of UI Head of Development An Enormous Monolith Conway’s Law: Software reflects the structure of the organization that produced it
- 33. Build small product-focused teams – strict one team to one microservice mapping Many Small Microservices Resulting SoftwareMicroservices Organization Structure API Application Datastore Infrastructure API Application Datastore Infrastructure API Application Datastore Infrastructure API Application Datastore Infrastructure Product Lead Project Manager Sys Admin DBA JavaScript Devel oper Developer Developer Sys Admin Storage Admin Graphic ArtistNoSQL Admin Product Lead Project Manager Sys Admin DBA JavaScript Devel oper Developer Developer Sys Admin Storage Admin Graphic ArtistNoSQL Admin Product Lead Project Manager Sys Admin DBA JavaScript Devel oper Developer Developer Sys Admin Storage Admin Graphic ArtistNoSQL Admin Product Lead Project Manager Sys Admin DBA JavaScript Devel oper Developer Developer Sys Admin Storage Admin Graphic ArtistNoSQL Admin
- 34. Requirements for Microservices Implementation Microservices Security ScalingMonitoring Eventing LoggingMessaging Service Discovery ConfigurationSecurity Service Registry API GatewayAPI Load Balancer Generally Recommended for Microservices
- 36. 04.
- 37. Leader in subscription internet tv service Hollywood, indy, local Growing slate of original content 86 million members ~190 countries, 10s of languages 1000s of device types Microservices on AWS
- 38. Netflix DVD Data Center - 2000 Linux Host What microservices are not Apache Tomcat Javaweb STORE LoadBalancer BILLING HTTP JDBC DB Link HTTP/S Monolithic code base Monolithic database Tightly coupled architecture
- 40. • Buy vs. Build – Use or contribute to OSS technologies first – Only build what you have to • Services should be stateless* – Must not rely on sticky sessions – Prove by Chaos testing First Principles
- 41. • Scale out vs. scale up – If you keep scaling up, you’ll hit a limit – Horizontal scaling gives you a longer runway • Redundancy and Isolation for Resiliency – Make more than one of anything – Isolate the blast radius for any given failure • Automate destructive testing – Simian Army – Started with Chaos Monkey First Principles
- 42. First Principles in Practices
- 43. Edge ELB Zuul (Proxy Svc) Playback (Legacy Dev.) API (g/w) Middle Tier & Platform Product • Bucket testing • Subscriber • Recommendations Platform • Routing • Configuration • Crypto Persistence • Cache • Database EVCache Cassandra
- 46. Device Service B Service C Internet EdgeZuul Service A ELB FIT Fault Injection Testing (FIT) Enforced throughout the call path
- 48. Wrap up DevOps & Microservices bring great value to development velocity, availability and other dimensions DevOps & Microservices at scale require organizational change and centralized infrastructure investment Be aware of your situation and what works for you
- 49. THANK YOU
- 50. • 2012년에 비슷한 시기에 서로 다른 사람이 용어를 사용하기 시작했다. • ThoughtWorks의 Jame Lewis가 Micro Service : Java, the Unix way : goo.gl/PS7BYK • Fred George “Micro Service Architecture – A Personl Journey to Discovery : goo.gl/dgd8Ya • 2013년 1월 : Adrian Cockcroft at Netflix, describing this approach as ＂fine grained SOA＂ • 2014년 3월 James Lewis와 Martin Fowler가 Microservices라는 타이틀로 패러다임을 정립한 기사를 발표 • 독립적이고 단순한 서비스로 전체 서비스를 구성 • 데이터, 거버넌스, 아키텍처등에 있어서 완전한 독립 • 독립적인 팀이 각 서비스의 개발과 운영을 담당 • 책임과 권한에 있어서 완전한 독립을 추구 Adrian Cockcroft at Netflix, describing this approach as "fine grained SOA", pioneered the style at web scale, as did many of the others mentioned in this article - Joe Walnes, Dan North, Evan Bottcher and Graham Tackley From wikipedia
Editor's Notes
- #5: Chef helps you describe your infrastructure with code. Because your infrastructure is managed with code, it can be automated, tested and reproduced with ease.
- #6: Chef helps you describe your infrastructure with code. Because your infrastructure is managed with code, it can be automated, tested and reproduced with ease.
- #8: Chef helps you describe your infrastructure with code. Because your infrastructure is managed with code, it can be automated, tested and reproduced with ease.
- #9: Dallas Fort Worth
- #10: Chef helps you describe your infrastructure with code. Because your infrastructure is managed with code, it can be automated, tested and reproduced with ease.
- #11: Chef helps you describe your infrastructure with code. Because your infrastructure is managed with code, it can be automated, tested and reproduced with ease.
- #12: Chef helps you describe your infrastructure with code. Because your infrastructure is managed with code, it can be automated, tested and reproduced with ease.
- #13: Chef helps you describe your infrastructure with code. Because your infrastructure is managed with code, it can be automated, tested and reproduced with ease.
- #14: Chef helps you describe your infrastructure with code. Because your infrastructure is managed with code, it can be automated, tested and reproduced with ease.
- #15: Chef helps you describe your infrastructure with code. Because your infrastructure is managed with code, it can be automated, tested and reproduced with ease.
- #16: Agility and outage-reduction are the two main drivers that clients target when implementing DevOps capabilities. However, increased quality and innovation cycles are another set of key benefits clients might want to consider when applying DevOps. To a large extent, most of these drivers can directly be related and translated into cost savings. Reducing outages will have an impact on cost avoidance; increased quality will have an impact on end-user satisfaction and therefore, clients may be able to increase their profits. 4.1 Increased Agility Speed to market or better-maximized agility through a constant and fully integrated deployment capability is one key aspect here. Moving from a release cycle from every quarter to deploying changes on a minute-by-minute basis is a real aspiration. For many clients this is a massive leap, for some this is a reality. 4.2 Increased Quality Puppet Labs’ survey13 suggests that high-performing organizations are deploying code 30 times more frequently, with 50% fewer failures than their lower-performing counterparts. Increased quality is one of the key benefits of DevOps. It will, however, increase quality only when the organization reaches a certain level of maturity. As outlined in the Capgemini Maturity Model (detailed below) we differentiate 5 levels of maturity: Basic, Emerging, Co-ordinated, Enhanced, and Top Level. 4.3 Improve Innovation Experiencing fewer outages and deploying code with increased quality will lead to more time spent thinking about further improvements or new ways of working. It will enable the organization to drive more value, rather than having to dedicate time fixing issues caused by changes deployed. 4.4 Reduced Outages As outlined before, outage-reduction is a big area of value. By applying a DevOps approach, companies will be able to avoid loss of sales and other outage related implications by improving ways of working, automation, and continuous deployment.
- #17: Agility and outage-reduction are the two main drivers that clients target when implementing DevOps capabilities. However, increased quality and innovation cycles are another set of key benefits clients might want to consider when applying DevOps. To a large extent, most of these drivers can directly be related and translated into cost savings. Reducing outages will have an impact on cost avoidance; increased quality will have an impact on end-user satisfaction and therefore, clients may be able to increase their profits. 4.1 Increased Agility Speed to market or better-maximized agility through a constant and fully integrated deployment capability is one key aspect here. Moving from a release cycle from every quarter to deploying changes on a minute-by-minute basis is a real aspiration. For many clients this is a massive leap, for some this is a reality. 4.2 Increased Quality Puppet Labs’ survey13 suggests that high-performing organizations are deploying code 30 times more frequently, with 50% fewer failures than their lower-performing counterparts. Increased quality is one of the key benefits of DevOps. It will, however, increase quality only when the organization reaches a certain level of maturity. As outlined in the Capgemini Maturity Model (detailed below) we differentiate 5 levels of maturity: Basic, Emerging, Co-ordinated, Enhanced, and Top Level. 4.3 Improve Innovation Experiencing fewer outages and deploying code with increased quality will lead to more time spent thinking about further improvements or new ways of working. It will enable the organization to drive more value, rather than having to dedicate time fixing issues caused by changes deployed. 4.4 Reduced Outages As outlined before, outage-reduction is a big area of value. By applying a DevOps approach, companies will be able to avoid loss of sales and other outage related implications by improving ways of working, automation, and continuous deployment.
- #18: Agility and outage-reduction are the two main drivers that clients target when implementing DevOps capabilities. However, increased quality and innovation cycles are another set of key benefits clients might want to consider when applying DevOps. To a large extent, most of these drivers can directly be related and translated into cost savings. Reducing outages will have an impact on cost avoidance; increased quality will have an impact on end-user satisfaction and therefore, clients may be able to increase their profits. 4.1 Increased Agility Speed to market or better-maximized agility through a constant and fully integrated deployment capability is one key aspect here. Moving from a release cycle from every quarter to deploying changes on a minute-by-minute basis is a real aspiration. For many clients this is a massive leap, for some this is a reality. 4.2 Increased Quality Puppet Labs’ survey13 suggests that high-performing organizations are deploying code 30 times more frequently, with 50% fewer failures than their lower-performing counterparts. Increased quality is one of the key benefits of DevOps. It will, however, increase quality only when the organization reaches a certain level of maturity. As outlined in the Capgemini Maturity Model (detailed below) we differentiate 5 levels of maturity: Basic, Emerging, Co-ordinated, Enhanced, and Top Level. 4.3 Improve Innovation Experiencing fewer outages and deploying code with increased quality will lead to more time spent thinking about further improvements or new ways of working. It will enable the organization to drive more value, rather than having to dedicate time fixing issues caused by changes deployed. 4.4 Reduced Outages As outlined before, outage-reduction is a big area of value. By applying a DevOps approach, companies will be able to avoid loss of sales and other outage related implications by improving ways of working, automation, and continuous deployment.
- #19: Agility and outage-reduction are the two main drivers that clients target when implementing DevOps capabilities. However, increased quality and innovation cycles are another set of key benefits clients might want to consider when applying DevOps. To a large extent, most of these drivers can directly be related and translated into cost savings. Reducing outages will have an impact on cost avoidance; increased quality will have an impact on end-user satisfaction and therefore, clients may be able to increase their profits. 4.1 Increased Agility Speed to market or better-maximized agility through a constant and fully integrated deployment capability is one key aspect here. Moving from a release cycle from every quarter to deploying changes on a minute-by-minute basis is a real aspiration. For many clients this is a massive leap, for some this is a reality. 4.2 Increased Quality Puppet Labs’ survey13 suggests that high-performing organizations are deploying code 30 times more frequently, with 50% fewer failures than their lower-performing counterparts. Increased quality is one of the key benefits of DevOps. It will, however, increase quality only when the organization reaches a certain level of maturity. As outlined in the Capgemini Maturity Model (detailed below) we differentiate 5 levels of maturity: Basic, Emerging, Co-ordinated, Enhanced, and Top Level. 4.3 Improve Innovation Experiencing fewer outages and deploying code with increased quality will lead to more time spent thinking about further improvements or new ways of working. It will enable the organization to drive more value, rather than having to dedicate time fixing issues caused by changes deployed. 4.4 Reduced Outages As outlined before, outage-reduction is a big area of value. By applying a DevOps approach, companies will be able to avoid loss of sales and other outage related implications by improving ways of working, automation, and continuous deployment.
- #25: Chef helps you describe your infrastructure with code. Because your infrastructure is managed with code, it can be automated, tested and reproduced with ease.
- #26: Chef helps you describe your infrastructure with code. Because your infrastructure is managed with code, it can be automated, tested and reproduced with ease.
- #27: Chef helps you describe your infrastructure with code. Because your infrastructure is managed with code, it can be automated, tested and reproduced with ease.
- #28: Immutable : 불변의
- #46: * If you do not defend against failure at each level then you have what is essentially a distributed monolith – if any microservice fails then they all fail * Calls start failing, retries make it worse, thread pools become saturated, lack of isolation leads to full cascading failure