Kubernetes, Jenkins, Git-flow를 이용하여 개발 - 테스트 자동화를 어떻게 구축하는지에 대한 슬라이드입니다.

1. Kubernetes를 통한
Laravel
개발프로세스
개선하기
아이엠컴퍼니 개발자 김창엽 (changyeopkim@gmail.com)

2. Kubernetes를 통한
Laravel
개발프로세스
개선하기
아이엠컴퍼니 개발자 김창엽 (changyeopkim@gmail.com)

3. 저는
안드로이드 개발자 (카카오폴, 쿨메신저, 아이엠스쿨)
DevOps 개발자 (Kubernetes, CI 자동화)
필요한 개발들 (스크립팅, 웹어플리케이션)

4. 아이엠컴퍼니는
● AWS 사용
● 개발팀 13 ~ 15명
● 웹&시스템개발자 8명
○ 배포쪽 겸직 2명
○ 시스템 겸직 2~3명
○ 웹전담도 있음
● 일반적으로 2명 정도의 개발자가 3~4개 정도의 기능들을 묶어서 개발함
○ => 한번에 3개 정도의 기능 집합들이 동시에 개발됨
○ Ex) SMS 문자 메시지(주소록) + 추천 관리 시스템 + 커머스 리스팅 광고 기능을 동시에

5. 좋은 개발자 상시 모집 중

6. 오늘 주제
Kubernetes를 통해서 개발프로세스(워크플로우)를 개선한 이야기
● Laravel 1%
● Docker 9%
● AWS 30%
● Kubernetes 40% (세부 개념에 대한 설명은 하지 않습니다.)
● Jenkins 20%

7. 발표가 끝났을 때 기대하는 반응
● Docker나 Kubernetes 모르는데 들을 만 했다
● 아이엠컴퍼니는 저런 식으로 일하고 있구나
● 세팅하느라 고생했네
● 아이엠컴퍼니에서 일해보고 싶다

8. PHP
Hypertext Preprocessor

9. PHP
Hypertext Preprocessor
Pogi Hamyeon Pyeonhae?

10. 초기 스타트업이 간과하는 것들
● 배포
● 백업
○ Version Control System
○ Daily Database Backup
● 에러 추적
○ Email on Error
○ Slack on Error
○ Logging

11. Node.js를 배포한다면?
● Update on Restart
● 그냥 재시작하면 당연히 서비스 순단(순간 단절)이 생김

12. Node.js를 배포하려면?
현재 돌고 있는 워커들이 연결된 리퀘스트를 처리할 때 까지 대기해야함
● Blue-Green Deployment
http://martinfowler.com/bliki/BlueGreenDeployment.html
● Rolling Update
https://en.wikipedia.org/wiki/Rolling_release

13. Laravel + PHP-FPM을 배포하려면?
● Git Pull (Clone)하고
● artisan 커맨드 좀 돌리면 (optimize나 cache등)
● 재시작 없이 끝!
● 왠만해서는...

14. 개발 프로세스와 Git Flow
● 개발 브랜치
○ feature
○ develop
● 테스트 브랜치
○ release
● 프로덕션 브랜치
○ master
○ hotfix

15. 2016년 중순까지의 아이엠컴퍼니
● features
○ 작업 단위가 한달정도 되면 따로 분리
● develop
○ 작업 단위가 작으면 develop에서 바로 작업
● qa
○ 개발자들이 작업한 것을 기획자와 QA들이 체크하는 곳
● stable (git-flow의 master 대응)
○ 프로덕션

16. 환경에 따른 백엔드 분리 (비동기 Queue, DB)
production
● stable
feature
● features
develop
● develop
● qa

17. Push Based Deploy
● 아이엠컴퍼니에서는 Git
Push를 하면 모든 배포가 자동으로 일어나게 설정되어있었음
○ QA Deploy
○ Production Deploy
● 환경은 미리 구축된 것을 이용하기만 함
● Feature의 경우는 일련의 과정을 수동으로 한번 해줘야함
○ 귀찮으니까 Feature용 환경 구축을 지양하게 됨
○ 비용 발생도 원인

18. Gitlab
Production QA
Push
githook
githook

19. 테스트와 환경에 따른 문제
● 기획자나 QA가 테스트를 하려면 QA까지 밀어넣어야 외부 노출이 된다.
● feature 환경을 별도로 노출시키려면 전체 환경을 복제해야하므로 비용이
발생한다.
○ Route53
○ DB (정말 드물게)
○ EC2
○ SQS 등
○ 안쓰는 리소스가 가끔 남아있을 때가 있음

20. 1. Git-Flow대로 브랜치를 관리하고, 브랜치들은 외부 노출이 되어야함
2. ip based로 가면 ssl(https) 환경에서 테스트 불가 => 도메인이 필요
어떻게 해야할까?

21. 문제점
1. 각 브랜치들이 모두 독립적으로 인스턴스를 가동하면 인스턴스 관리가 어려워
짐
a. 사용하지 않는 인스턴스를 주기적으로 정리해줘야 함
2. 도메인을 매번 관리하는 것은 손이 많이 감
a. Route53까지 자동화시켜야함.

22. Kubernetes (쿠베르네테스, k8s)
이상한 모임이니까 이상한 모임 링크
https://blog.weirdx.io/post/30460
● Kubernetes: Intro by 1ambda님

23. Kubernetes
● By Google
● Docker Container Management
○ vs Docker Swarm?
● Docker Container Deploy
● Internal IP, DNS, Proxy 등등의 Network Management Layer
● AWS, Google Cloud등과 연동
● Pod: 컨테이너 그룹
● Service: Pod 접근 제어

24. Kubernetes Service
● ClusterIP
○ Internal 접근만 가능
● NodePort
○ 포트 개방
○ 노출되는 형태가 안 이쁨
● LoadBalancer
○ 서비스 하나당 하나의 로드밸런서
○ 포트포워딩 없이 SSL 사용하려면 사실상 유일한 방법

25. Service with LoadBalancer
● 1달에 18불
● 로드밸런서 한대로 모든 트래픽을 분산시킬 수 없을까?

26. Kubernetes DNS
● 자체 DNS를 가지고 있어서 노출된 서비스를 규칙에 따라 접근할 수 있다.
● [svc].[namespace].svc.cluster.local
● svc와 namespace를 호스트로 받으면?
● DNS Server: 10.0.0.1

27. Kubernetes Navigator
● 요청된 호스트에 따라 내부 DNS를 이용하여 Proxy Pass하는 Nginx Service

28. Navigator nginx

29. Service with Git Branch
● 네임스페이스는 그렇다치고…
● 어떤 브랜치가 어떤 서비스로 만들어지는지 어떻게 결정하지?
● 브랜치를 가지고 서비스를 만들면 되지!

30. Jenkins를 통한 Git과 k8s 연결

31. Jenkins를 통한 Git과 k8s 연결
mgr-ft는 서비스 구분자입니다.
(같은 namespace에 다른 서비스들이 돌아가고 있음. namespace는 환경별로만
구분)

32. Jenkins를 통한 Git과 k8s 연결

33. Jenkins를 통한 Git과 k8s 연결

34. 3줄 요약
1. Jenkins에서 푸시가 일어나면
2. 브랜치 이름에서 서비스 이름을 따다가 (feature/sms면 sms)
3. 해당 브랜치 이름으로 k8s deployment와 service를 생성 혹은 갱신한다.

35. Git-flow + Kubernetes = PROFIT!
● 언제든지 독립된 환경에서 개발자가 git만으로 테스트를 위한 배포를 수행할
수 있다.

36. Pros
● 여러명의 개발자가 동시에 같은 제품을 작업해도 문제가 없다.
● QA는 코드 머지로 인한 사이드이펙트 같은 문제에 신경쓰지 않고, 기능
테스트때 기능 테스트에만 집중할 수 있다.
○ 통합테스트는 릴리즈 전에 최종 진행
● 로컬 환경보다 훨씬 빠르다. (AWS내에서의 리소스 접근)
● 프로덕션 환경과 동일한 환경에서 테스트가 가능하다.

37. Cons
● Docker image build를 포함한 Rolling update 반영이 생각보다 좀 걸린다.
○ 현재 Laravel + Angular.js 어플리케이션 빌드하는데 평균 3분 ~ 길면 5분
● 1.3 기준 Kubernetes Service name 길이 제한이 있다 (24자)
○ 이 제한이 브랜치 이름 길이 제한을 줘버린다.
○ mgr-ft-(feature)이름이므로 실제 사용할 수 있는 브랜치 이름은 17자
○ 1.4 에서 63자까지로 완화됨
(https://github.com/deis/workflow/issues/212)
● k8s 환경에 문제가 있다면 원인을 찾기가 어렵다.
○ Laravel https 필터 관련 Navigator에 X-Forwarded-Proto 관련 문제를 경험
● 클라이언트는 호스트를 동적 변경 할 수 있어야 편해진다.

38. 고민 사항
● DB, Redis, SQS(MessageQueue)등도 환경에 따라 분리하는 게 좋지만…
● 결국 Kubernetes 안에 서비스를 많이 밀어넣으면 클러스터 개수가 굉장히
빠르게 늘어남.
● DB같은경우는 기존에 누적된 데이터가 없으면 테스트가 너무 어려운 부분이
있음.
○ 데이터가 많아서 덤프 넣는데도 시간이 오래 걸릴거라...

39. 배포 요약
Gitlab Jenkins Kubernetes

40. Kubernetes 서비스 접근 요약
Navigator
Loadbalencer
Kubernetes
Navigator Pods
namespace
App Pods
namespace
App Pods

41. 부록) 그래서 얼마나 아꼈을까? (30개의 서비스를
가정)

42. Plain AWS (1 mon)
● EC2 (t2.nano): $0.01 * 24(시간) * 30(일) * 30(대) = $216
● ELB: $0.025 * 24 * 30 * 30 = $540
● $756

43. Kubernetes (1 mon)
● EC2(m3.large): $0.193 * 24 * 30 * 2(대, master & slave) = $277.92
● ELB: $0.025 * 24 * 30 * 1: $18
● $295.92
● Plain AWS 대비 60% 절감

44. Q&A
감사합니다