멸종하는 공룡이 되지 않으려면DevOps / CaaS / MSA / Reactive System

코딩소림사 정기 세미나

바쁘신 청중들을 위해 결론부터…• 개발자는 개발만 , • 테스터는 테스트만 , • 운영자는 운영만 하던 시대는 안타깝게도끝났습니다 .

공격수는공격만

미드필더는패스만

수비수는수비만

바쁘신 청중들을 위해 결론부터…개발 – 테스트 – 운영Software life cycle 전체에 걸쳐요람에서 무덤까지 모두가관여하여야 합니다 .

토탈사커처럼 !!

결론• 모든 개발 공정 (개발 / QA / 운영 )에 대한 극단적 자동화• 자동화 구성에 걸맞는 S/W architecture• S/W architecture 의 복잡도를

제어할 수 있는 programming paradigm

이 3가지는 매우 유기적이어야 하며 모든 주체가 적극적으로 참여하여야 합니다 .

감사합니다 .

공룡이 멸종한 이유는 ?변화된 환경에 적응하지 못했기 때문에

공룡이 멸종한 이유는 ?외부 환경의 변화에 적응하지 못하면 어떻게 되는지 우리는 누구보다 잘 알고 있습니다 .

글로벌 IT 환경은 어떻게 변하고 있나Software 가 모든 것을 먹어 치우고 있다 .

글로벌 IT 환경은 어떻게 변하고 있나Software 가 모든 것을 먹어 치우고 있다 .

S/W 기술을 이용한 모든 산업의 극단적 자동화

그러면 S/W 개발공정은 얼마나 자동화되어 있나 ?

글로벌 IT 환경은 어떻게 변하고 있나

우리가 가내 수공업식 개발을 하고 있을 때 글로벌 S/W 기업은 우주정복을 하고 있더라

우리는 어떻게 하고 있나• 요구사항 ( 기능추가 , 버그픽스 ) 이슈 트래킹 하고 있나 ?• 이슈 – 소스코드 연결되어 추적 가능한가 ?•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 되어 서비스가 개선되고 있나 .

결론가내 수공업이다

어디서부터 손을 대야 할지• 문제인식도 공감되고• 변화의 의지도 있는데• 무엇을 어떻게 바꿔야 하나• 일단 뭐부터 시작해야 할지• 도대체 모르겠다면

점진적 개선• 당장 변할 수 있는 것 부터 부분적으로 바꿔봅시다 .• 우선 마음가짐부터

원숭이 – 바나나 법칙

개선을 위한 두 가지 원칙• 태도

• 모두가 개발자 & 테스터 & 운영자다 .• 내가 느끼는 불편함을 해결해 줄 사람은 나밖에 없다 .• Eat your own dog food!!

• 자동화• 모든 개발 공정을 극한까지 자동화한다 .• 모든 개발 공정 ( 개발 / 테스트 / 빌드 / 배포 / 운영 / 피드백 ) 의 주체는 개발자다 .• 개발자는 자신이 개발한 s/w 를 직접 테스트 & 운영한다 .• 테스터는 개발자가 테스트하기 위한 제반 환경을 개발 & 자동화한다 .• 운영자는 개발자가 운영 / 모니터링하기 위한 제반 환경을 개발 & 자동화한다 .

태도 - All you need is lovebefore agile• 요구사항이 바뀌기 때문에 개발자는 야근하고• 개발자가 일정을 미루기 때문에 출시일 연기하고• QA 커버리지가 낮기 때문에 버그 투성이 s/w 를 출시하고• 장애 때문에 운영자는 밤새고

after agile• 원래 요구사항은 바뀌는 거라구 !• 릴리즈 하루에 15 번씩 해드리겠습니다 !• 테스트는 보통 10 만번 씩 하는데요 ?• 장애요 ? 내십쇼 ! 0.1 초 만에 해드리겠습니다 !

기획자 vs 개발자 vs QA vs 운영자대결과 책임전가 대신 화해와 협력

Agile 은 사랑입니다 .

태도 - All you need is love

• 말은 쉬운데…• 어떻게 수시로 바뀌는 요구사항을 들어주고• 테스트를 10 만번씩 하고• 하루에 15 번씩 배포를 합니까

1000 원 줄테니초코파이 2 박스랑콜라 1.5L 3 병이랑군만두 1 봉지 사고잔돈 남겨와라

개발공정의 자동화 (=DevOps)

자동화 – 왜 자동화가 필요한가요PEBKAC• Problem Exist Between Keyboard And Chair• 모든 문제는 의자와 키보드 사이에 존재하는 것 때문

의자

키보드

키보드랑 의자 사이

Human Error • 죄송해요 실수로…• 아차 깜박해서…• 문제가 될 줄 몰랐는데요…

자동화 - 무엇을 자동화 해야 하나요• 이슈 관리• 빌드 – 유닛테스트• UI 테스트• 배포• 운영 – 모니터링 - 스케일링

이슈관리 자동화 - 반드시 src code 바인딩이 되어야 합니다 .

좋은 예 나쁜 예

이슈관리 자동화• 1 기능 – 1 이슈 – 1브랜치• git 브랜치 / 머지 전략

• git flow (=nvie 전략 )• https://wiki.kthcorp.com/x/vgAx 참조

• pull request / 온라인 코드 리뷰• 코드리뷰는 온라인으로 진행하여야시간을 절약할 수 있습니다 .• 교육 목적으로 가끔 오프라인 코드리뷰를진행하는 것도 바람직합니다 .

빌드 / 테스트 자동화• 반드시 build time 에 unit test 결과가 저장되어야 합니다 .좋은 예 나쁜 예

UI 테스트 자동화• UI Test Framework 을 사용하면 테스트를 자동화할 수 있습니다 .• 허나 모든 테스트를 제대로 자동화하려면 반드시 개발을 해야 합니다 .

• Mock Object• Fake Server

배포 자동화• 빌드 자동화와 한 몸• develop/master 브랜치에 merge 이벤트 발생하면 배포

• develop 브랜치 – 개발 서버• master 브랜치 – 상용 서버

좋은 예 : 브랜치로 구분하여 개발 / 상용 배포 자동화

DevOps= 마음가짐 의 문제• 지금까지 소개한 개발공정 자동화 방법 중• kth 에 도입되지 않은 건 UI 테스트 자동화 뿐• 나머지는 모두 이미 갖춰져 있습니다 .

개발 구성원이 참여하지 않으면 공허한 울림에 지나지 않습니다 .

지금부터 할 얘기는…• DevOps 와 함께하면 엄청난 폭발력 / 시너지• S/W 분야 cutting edge 기업 99.9% 의 선택• 다음 단계로 도약을 위해 반드시 기본적으로 갖추어야 할 역량

CaaS(Container as a Service)MSA(Microservice Architecture)Reactive System

문제제기• 사례 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년• 상품 추천은 다음 생에 해드릴게요

문제제기• 사례 2• 평시에는 조용하다가 특정 시간대에만 트래픽이 몰리는 시스템

• 평시 : 10TPS• 하루에 딱 한 번 , 30 분 동안 : 1000TPS

• 1 대의 서버가 100TPS 처리 가능• 1 대의 DB 가 200TPS 처리 가능하다고 가정할 때

• 하루의 대부분은 서버 1 대 / DB 1 대 로 서비스 가능하나• 30 분의 요청 쏠림을 처리하기 위해 서버 10 대 / DB 5 대 를 구비하여야 한다 .

문제제기• 사례 3• 왠만하면 도찐개찐 , 대동소이하나 비즈니스 로직 일부만 다른 시스템

• 웹서버 : httpd 또는 nginx• Servlet : tomcat• 개발언어 / 프레임워크 : java / spring• DB : mysql / oracle / postgresql / mssql

• 시스템 구성 / 환경 설정 / 운영 방식 대부분이 거기서 거기• 하지만 이 비슷비슷한 시스템 환경 구성을 매 프로젝트 마다 반복

• 경력 있는 운영자는 ctrl-C / ctrl-V 패턴을 사용• 하지만 서버 100 대를 환경 설정해야 한다면 ?

환경 설정 / 운영 관리의 물리적 한계 = 감당 가능한 서비스 규모의 한계

마법같은 해결책이 있습니다 .

컨테이너 가상화( 라고 쓰고 Docker 라고 읽는다 )

모든 인프라는 클라우드로 수렴할 것Whatever as a Service 의 가파른 성장클라우드는 기본 , 아무 수고로움 없이 당장 S/W or 결과물 사용가능한 서비스가 대세public cloud(e.g. AWS, Azure) 를 쓰느냐 private cloud 를 구축하느냐 의 차이만 있을 뿐우리가 원하든 원치 않든 결국 모든 인프라는 클라우드로 수렴할 것입니다 .

Coming Soon• docker 가 production 환경을 대체하기까지는 갈 길이 멉니다 .

• DevOps 팀에서 열심히 만들어 볼 테니 애정과 인내심을 갖고 기다려 주세요 .

클라우드 인프라와 깔맞춤컨테이너 / 클라우드 기반 인프라 환경에 어울리는 • Software architecture• programming paradigm 이 있습니다 .

치킨에는 맥주가 어울리고 삼겹살엔 소주가 어울리듯

?

Microservice Architecture• loose coupled• only one cross -function• doesn‘t share any per-

sistence• event driven

MSA 의 장 / 단점• 장점

• CaaS 와 잘 어울림• 단일 서비스 개발 / 유지보수 쉬움• Multi-target 서비스 재사용도 높음• 서비스 장애 영향 적음• 다양한 기술 스택 독립적으로 적용 가능

• 단점• End-user( 단말 , web페이지 등 ) 복잡도 높아짐• 여러 서비스를 거치는 transaction 처리 어려움• 여러 서비스를 거치는 테스트 어려움

• 해결• API gateway• Message broker• Intermediate Cache

여전히 복잡한 microservice 를 chaining 하는 어려움은 남아 있다 .

Reactive Manifesto• 한국어 선언문 :

http://www.reactivemanifesto.org/ko• 다음 4 가지 특성을 가져야 reactive system 이다 .• 응답성 (responsive)• 탄력성 (resilient)• 유연성 (elastic)• 메세지 구동 (message driven)

Reactive System will save MSA• Netflix : MSA 의 대표적 성공 사례• Netflix 에서 MSA 의 복잡도를 관리하기 위해 만든 library• reactive-streams• rxJava

• 소림사로 오시면 함께 공부할 수 있습니다 .

MSA 를 위한 점진적 준비• java – spring 스택에서 벗어나보자• spring 을 써야 한다면 spring-boot 를 써보자• mybatis 대신 hibernate 를 써보자• rdbms 대신 no-sql 을 써보자• join query 없이 문제를 해결해 보자

감사합니다 .