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