Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

멸종하는 공룡이 되지 않으려면

4,234 views

Published on

코딩 소림사 정기 세미나

Published in: Software
  • Be the first to comment

멸종하는 공룡이 되지 않으려면

  1. 1. 멸종하는 공룡이 되지 않으려면 DevOps / CaaS / MSA / Reactive System 코딩소림사 정기 세미나
  2. 2. 바쁘신 청중들을 위해 결론부터… • 개발자는 개발만, • 테스터는 테스트만, • 운영자는 운영만 하던 시대는 안타깝게도 끝났습니다. 공격수는 공격만 미드필더는 패스만 수비수는 수비만
  3. 3. 바쁘신 청중들을 위해 결론부터… 개발 – 테스트 – 운영 Software life cycle 전체에 걸쳐 요람에서 무덤까지 모두가 관여하여야 합니다. 토탈사커처럼!!
  4. 4. 결론 • 모든 개발 공정(개발 / QA / 운영)에 대한 극단적 자동화 • 자동화 구성에 걸맞는 S/W architecture • S/W architecture 의 복잡도를 제어할 수 있는 programming paradigm 이 3가지는 매우 유기적이어야 하며 모든 주체가 적극적으로 참여하여야 합니다.
  5. 5. 감사합니다.
  6. 6. 공룡이 멸종한 이유는? 변화된 환경에 적응하지 못했기 때문에
  7. 7. 공룡이 멸종한 이유는? 외부 환경의 변화에 적응하지 못하면 어떻게 되는지 우리는 누구보다 잘 알고 있습니다.
  8. 8. 글로벌 IT 환경은 어떻게 변하고 있나 Software 가 모든 것을 먹어 치우고 있다.
  9. 9. 글로벌 IT 환경은 어떻게 변하고 있나 Software 가 모든 것을 먹어 치우고 있다. S/W 기술을 이용한 모든 산업의 극단적 자동화 그러면 S/W 개발공정은 얼마나 자동화되어 있나?
  10. 10. 글로벌 IT 환경은 어떻게 변하고 있나 우리가 가내 수공업식 개발을 하고 있을 때 글로벌 S/W 기업은 우주정복을 하고 있더라
  11. 11. 우리는 어떻게 하고 있나 •요구사항(기능추가, 버그픽스) 이슈 트래킹 하고 있나? •이슈 – 소스코드 연결되어 추적 가능한가? •Production / Development 라인이 분리되어 형상관리 되고 있나. •pull-request / code review 는 진행하고 있나. •Build server 에서 daily build 진행하고 있나. •unit test 및 regression test 를 진행하고 있나. •QA 테스트를 자동화 하고 있나. •개발 / 상용 환경에 자동 deployment / roll back 을 진행하고 있나. •container / cloud 기반 auto scale / fault tolerant 를 보장하고 있나. •서비스 상태에 대한 모니터링 및 통지가 자동화 되어 있나. •로그 및 사용자 리뷰가 feedback 되어 서비스가 개선되고 있나. 결론 가내 수공업이다
  12. 12. 어디서부터 손을 대야 할지 • 문제인식도 공감되고 • 변화의 의지도 있는데 • 무엇을 어떻게 바꿔야 하나 • 일단 뭐부터 시작해야 할지 • 도대체 모르겠다면
  13. 13. 점진적 개선 • 당장 변할 수 있는 것 부터 부분적으로 바꿔봅시다. • 우선 마음가짐부터
  14. 14. 원숭이 – 바나나 법칙
  15. 15. 개선을 위한 두 가지 원칙 • 태도 • 모두가 개발자 & 테스터 & 운영자다. • 내가 느끼는 불편함을 해결해 줄 사람은 나밖에 없다. • Eat your own dog food!! • 자동화 • 모든 개발 공정을 극한까지 자동화한다. • 모든 개발 공정(개발/테스트/빌드/배포/운영/피드백)의 주체는 개발자다. • 개발자는 자신이 개발한 s/w 를 직접 테스트 & 운영한다. • 테스터는 개발자가 테스트하기 위한 제반 환경을 개발 & 자동화한다. • 운영자는 개발자가 운영/모니터링하기 위한 제반 환경을 개발 & 자동화한다.
  16. 16. 태도 - All you need is love before agile • 요구사항이 바뀌기 때문에 개발자는 야근하고 • 개발자가 일정을 미루기 때문에 출시일 연기하고 • QA 커버리지가 낮기 때문에 버그 투성이 s/w를 출시하고 • 장애 때문에 운영자는 밤새고 after agile • 원래 요구사항은 바뀌는 거라구! • 릴리즈 하루에 15번씩 해드리겠습니다! • 테스트는 보통 10만번 씩 하는데요? • 장애요? 내십쇼! 0.1초 만에 해드리겠습니다! 기획자 vs 개발자 vs QA vs 운영자 대결과 책임전가 대신 화해와 협력 Agile 은 사랑입니다.
  17. 17. 태도 - All you need is love • 말은 쉬운데… • 어떻게 수시로 바뀌는 요구사항을 들어주고 • 테스트를 10만번씩 하고 • 하루에 15번씩 배포를 합니까 1000원 줄테니 초코파이 2박스랑 콜라 1.5L 3병이랑 군만두 1봉지 사고 잔돈 남겨와라
  18. 18. 개발공정의 자동화(=DevOps)
  19. 19. 자동화 – 왜 자동화가 필요한가요 PEBKAC • Problem Exist Between Keyboard And Chair • 모든 문제는 의자와 키보드 사이에 존재하는 것 때문 의자 키보드 키보드랑 의자 사이 Human Error • 죄송해요 실수로… • 아차 깜박해서… • 문제가 될 줄 몰랐는데요…
  20. 20. 자동화 - 무엇을 자동화 해야 하나요 • 이슈 관리 • 빌드 – 유닛테스트 • UI 테스트 • 배포 • 운영 – 모니터링 - 스케일링
  21. 21. 이슈관리 자동화 - 반드시 src code 바인딩이 되어야 합니다. 좋은 예 나쁜 예
  22. 22. 이슈관리 자동화 • 1기능 – 1이슈 – 1브랜치 • git 브랜치 / 머지 전략 • git flow (=nvie 전략) • https://wiki.kthcorp.com/x/vgAx 참조 • pull request / 온라인 코드 리뷰 • 코드리뷰는 온라인으로 진행하여야 시간을 절약할 수 있습니다. • 교육 목적으로 가끔 오프라인 코드리뷰를 진행하는 것도 바람직합니다.
  23. 23. 빌드/테스트 자동화 • 반드시 build time 에 unit test 결과가 저장되어야 합니다. 좋은 예 나쁜 예
  24. 24. UI 테스트 자동화 • UI Test Framework 을 사용하면 테스트를 자동화할 수 있습니다. • 허나 모든 테스트를 제대로 자동화하려면 반드시 개발을 해야 합니다. • Mock Object • Fake Server
  25. 25. 배포 자동화 • 빌드 자동화와 한 몸 • develop/master 브랜치에 merge 이벤트 발생하면 배포 • develop 브랜치 – 개발 서버 • master 브랜치 – 상용 서버 좋은 예 : 브랜치로 구분하여 개발 / 상용 배포 자동화
  26. 26. DevOps=마음가짐 의 문제 • 지금까지 소개한 개발공정 자동화 방법 중 • kth 에 도입되지 않은 건 UI 테스트 자동화 뿐 • 나머지는 모두 이미 갖춰져 있습니다. 개발 구성원이 참여하지 않으면 공허한 울림에 지나지 않습니다.
  27. 27. 지금부터 할 얘기는… • DevOps 와 함께하면 엄청난 폭발력 / 시너지 • S/W 분야 cutting edge 기업 99.9% 의 선택 • 다음 단계로 도약을 위해 반드시 기본적으로 갖추어야 할 역량 CaaS(Container as a Service) MSA(Microservice Architecture) Reactive System
  28. 28. 문제제기 • 사례 1 • 1억 개의 상품 / 1천만 명의 고객에 대한 추천 시스템 • Collaborative filtering 을 가정하면 • 1억 x 1천만 x 8 = 8 x 10^15 • 8000TB = 8Petabytes 의 리소스 소요 • 8PB 리소스를 보유한 H/W 를 구하는 것도 어렵겠지만 • 4GHz CPU 1개가 위 연산을 처리하려면 • 1PB / 4G = 2.5 x 10^5 초 • 대략 3 일 소요 • 상품 추천이라도 할라 치면 • 1억^2 x 1천만 = 10^25 • 10^25 / 4G = 79274479년 • 상품 추천은 다음 생에 해드릴게요
  29. 29. 문제제기 • 사례 2 • 평시에는 조용하다가 특정 시간대에만 트래픽이 몰리는 시스템 • 평시 : 10TPS • 하루에 딱 한 번, 30분 동안 : 1000TPS • 1대의 서버가 100TPS 처리 가능 • 1대의 DB가 200TPS 처리 가능하다고 가정할 때 • 하루의 대부분은 서버 1대 / DB 1대 로 서비스 가능하나 • 30분의 요청 쏠림을 처리하기 위해 서버 10대 / DB 5대 를 구비하여야 한다.
  30. 30. 문제제기 • 사례 3 • 왠만하면 도찐개찐, 대동소이하나 비즈니스 로직 일부만 다른 시스템 • 웹서버 : httpd 또는 nginx • Servlet : tomcat • 개발언어 / 프레임워크 : java / spring • DB : mysql / oracle / postgresql / mssql • 시스템 구성 / 환경 설정 / 운영 방식 대부분이 거기서 거기 • 하지만 이 비슷비슷한 시스템 환경 구성을 매 프로젝트 마다 반복 • 경력 있는 운영자는 ctrl-C / ctrl-V 패턴을 사용 • 하지만 서버 100대를 환경 설정해야 한다면? 환경 설정 / 운영 관리의 물리적 한계 = 감당 가능한 서비스 규모의 한계
  31. 31. 마법같은 해결책이 있습니다.
  32. 32. 컨테이너 가상화 (라고 쓰고 Docker라고 읽는다)
  33. 33. 모든 인프라는 클라우드로 수렴할 것 Whatever as a Service 의 가파른 성장 클라우드는 기본, 아무 수고로움 없이 당장 S/W or 결과물 사용가능한 서비스가 대세 public cloud(e.g. AWS, Azure)를 쓰느냐 private cloud 를 구축하느냐 의 차이만 있을 뿐 우리가 원하든 원치 않든 결국 모든 인프라는 클라우드로 수렴할 것입니다.
  34. 34. Coming Soon • docker 가 production 환경을 대체하 기까지는 갈 길이 멉니다. • DevOps 팀에서 열심히 만들어 볼 테니 애정과 인내심을 갖고 기다려 주세요.
  35. 35. 클라우드 인프라와 깔맞춤 컨테이너 / 클라우드 기반 인프라 환경에 어울리는 • Software architecture • programming paradigm 이 있습니다. 치킨에는 맥주가 어울리고 삼겹살엔 소주가 어울리듯 ?
  36. 36. Microservice Architecture • loose coupled • only one cross -function • doesn‘t share any persistence • event driven
  37. 37. MSA 의 장/단점 • 장점 • CaaS 와 잘 어울림 • 단일 서비스 개발/유지보수 쉬움 • Multi-target 서비스 재사용도 높음 • 서비스 장애 영향 적음 • 다양한 기술 스택 독립적으로 적용 가능 • 단점 • End-user(단말, web페이지 등) 복잡도 높아짐 • 여러 서비스를 거치는 transaction 처리 어려움 • 여러 서비스를 거치는 테스트 어려움 • 해결 • API gateway • Message broker • Intermediate Cache 여전히 복잡한 microservice 를 chaining 하는 어려움은 남아 있다.
  38. 38. Reactive Manifesto • 한국어 선언문 : http://www.reactivemanifesto.org/ko • 다음 4가지 특성을 가져야 reactive system 이다. • 응답성(responsive) • 탄력성(resilient) • 유연성(elastic) • 메세지 구동(message driven)
  39. 39. Reactive System will save MSA • Netflix : MSA 의 대표적 성공 사례 • Netflix에서 MSA 의 복잡도를 관리하기 위해 만든 library • reactive-streams • rxJava • 소림사로 오시면 함께 공부할 수 있습니다.
  40. 40. MSA를 위한 점진적 준비 • java – spring 스택에서 벗어나보자 • spring을 써야 한다면 spring-boot 를 써보자 • mybatis 대신 hibernate 를 써보자 • rdbms 대신 no-sql을 써보자 • join query 없이 문제를 해결해 보자
  41. 41. 감사합니다.

×