2017년 4월 20일 AWS Summit 2017에서 발표한 자료입니다.
AWS를 통한 신뢰성 높은 지속적 배포 및 통합(CI/CD) 사례의 2부 자료로서 AWS Lambda와 GitHub 그리고 Travis CI를 이용하여 안정적인 CI/CD를 구현한 사례를 공유합니다.
자세한 내용은 이곳을 참고하세요: https://goo.gl/wgsKKl
2. 본 강연에서 다룰 내용
• Continuous Integration & Continuous Deployment
• 기존 Unmanaged CI/CD의 문제
• 왜 GitHub와 Travis CI 인가?
• Travis CI의 한계, AWS Lambda로 뛰어넘다
• Code Build vs Travis CI
• 신뢰성 높은 Software Stack 이란?
6. Definition
Continuous Integration (지속적인 통합)
• Build & Packaging을 자주 행함
• 여러 사람이 작성한 코드가 병합되었을 때 생기는 문제를 미리 감지
• 언제든 최신 Build를 고객에게 바로 제공가능
Continuous Deployment (지속적인 배포)
• Deployment를 자주 행함
• System과 Application을 최대한 Fresh한 상태로 유지
• 장시간 운영 시 발생하는 문제를 예방
Jenkins, Bamboo, Cruise Control등을 주로 사용해 옴
7. Jenkins, Bamboo 같은 CI 의 문제
• 설치/운영비용 소요
(최소 t2.medium = Android App 필요 시)
• 여러 Job들이 같은 서버에서 실행,
Job끼리 영향을 미칠 수 있음
• 낮은 활용률: 큰 프로젝트가 아니면
서버가 24시간 내내 바쁠 일이 적음
운영(관리)에 드는 돈, 시간, 노력을
줄일 수 있는 방법은 없을까?
8. 우리는 왜 IDC에서 AWS로 이동 하는가?
1. 서버관리를 위한 잡일을 AWS에 위임
2. 시간 및 비용이 절감됨
3. 작은 개발팀으로 큰 시스템 개발/운영 가능
4. 집에 좀더 일찍 감
5. 가정이 안정되고 …
6. 나라가 좋아지고 ...
…
10. HBSmith의 개발 Stack (As of 2017.4)
• AWS
• GitHub
• Jenkins -> Bamboo -> Travis CI
• Atlassian Cloud (JIRA/Confluence)
• Slack
https://hbsmith.io/
11. GitHub + Travis CI = 최적의 조합
• GitHub 와의 Seamless한 통합
• 2016 CI Ranking Top 3
(Travis CI, CodeShip, Jenkins)
• 수많은 GitHub기반 Open Source
프로젝트들이 이용 (ex: Apache Zeppelin)
• Managed CI 중 가장 많은 Reference
• Docker 기반으로 모든 Job이
Independent한 환경에서 수행
• 정말정말 배우기 쉬움(Easy)
12.
13. 아직 아쉬운? Travis CI 기능
• Job기반이 아닌, 저장소 기반
• GUI에서 할 수 있는 게 거의 없음
(대신 REST API는 엄청나게 많음)
• 정말 중요해 보이는 기능이 Beta
• CronJob이 Beta인 상황 (as of 2017.4)
• Cron Expression을 지원 안 함
14. AWS Lambda를 이용, Travis CI를 제어
- 1 Job = 1 Lambda
- Lambda의 Cron Expression 이용
- Lambda에서 Travis CI의 Build API 호출
참고사항
- 저장소의 .travis.yml은 최소설정만 사용
- Build API는 위 설정 위에 CI/CD에 맞는 설정을
Override 하여 실행할 수 있음
- 모든 과정은 Python Script로 언제나 재현가능
(Provisioning Ready)
20. 결과: 최신 Stack + 신뢰성 높은 CI/CD 탄생
• Lambda or Travis CI가 장애가 생기지 않는 한 멈출 일이 없음
• 장애가 생겨도 그쪽에서 빨리 복구함, 우리는 기다리면 됨
• iOS도 Build 가능 (Code Build엔 미 지원)
• 문제생기면 Slack으로 바로 Notification
2016년 10월 첫 Setup이후 6개월 동안 3000 Build
이상 진행하는 동안 중단 및 장애 거의 없음
Travis CI 장애 발생시 Travis Team에서 빠르게 대응
Lambda 장애 발생시 AWS에서 빠르게 대응
21. Jenkins 대비 비용비교 (TCO)
비교기준
• Travis CI Docker Instance: 2 CPU + 4G Ram
• AWS: 위와 가장 유사한 t2.medium Instance
• 1 Job = 1 Instance로 계산 (논쟁의 여지는 있음)
결론
• t2.medium = 약 $59/월
• Travis CI = 약 $69/월
• Concurrent Instance가 늘어날수록 가격차 커짐
평가
• EC2 관리자로 1 Man-month를 고용/투입하는 것보다 월 $10을
더 내고 투입하지 않는 게 더 효율적
• 서버가 늘어날수록 Travis CI가 EC2 대비 더 저렴
• 보안, 성능 등이 맘에 안들 경우 Travis CI Enterprise도 고려가능
(Enterprise는 EC2 환경에서 동작함!)
22. Code Build & Code Deploy로 옮길 생각은?
우리 팀 기준엔 아직 미 부합
- 충분한 Reference 있음?
- 기존 것을 대체할 만큼 충분한 기능 있음?
- 확실히 옮길만한 이유가 존재?
그러나 충분히 가능성 있음
- 안정성, 가격측면서 확실한 Benefit이 존재
- GitHub 연동이 Travis 보다 좋아진다면…
- 특히 iOS Build 만 지원이 된다면…
망설임 없이 옮길 예정!
?
23. Code Build vs Travis CI
Code Build Travis CI
• 월 돌리는 Build 개수, Build 완료까지
걸리는 시간이 짧고 유동적일 경우
(시간당 과금 = Build 가 느릴수록 비용이 더 늘어남)
• AWS 인프라만 이용해야 할 경우
• GitHub 외에 다른 저장소일 경우
• Linux 또는 Windows Build 환경만 필요할 경우
• 월 돌리는 기본 Build 개수가 고정되어 있을 경우
• Build 완료까지 걸리는 시간이 꽤 걸릴 경우
(Travis CI는 시간당 과금 없음)
• 팀이 GitHub를 적극적으로 사용할 경우
(특히 PR 및 Review 기능)
• iOS App Build가 필요할 경우 (XCode Server)
24. 결론: 한가지 일을 잘하는 것들을 조합, 확실한 것을 만들다.
- Trigger = AWS Lambda
- Build = Travis CI
이 모든 게 서로 잘 조합될 수 있는 이유
- 훌륭한 표준 인터페이스 (API)
- 완전 관리 형 서비스 (Full Managed)
- 각자 1가지의 목적에 충실 (Primitive)
25. Unix 창시자 Douglas McIlroy 께서 말씀하시길…
AWS = Unix 철학에 가장 가까운 Public Cloud
26. 본 강연이 끝난 후…
여러분도 AWS Lambda로
멋진 자동화 시스템을 만들 수 있습니다!
지금 떠오르는 아이디어로 시작해보세요!
https://aws.amazon.com/lambda/getting-started/
도움이 필요하세요? 아래로 언제든 문의주세요
https://hbsmith.io/
28. https://www.awssummit.kr
AWS Summit 모바일 앱을 통해 지금 세션 평가에
참여하시면, 행사후 기념품을 드립니다.
#AWSSummitKR 해시태그로 소셜 미디어에
여러분의 행사 소감을 올려주세요.
발표 자료 및 녹화 동영상은 AWS Korea 공식 소셜
채널로 공유될 예정입니다.
여러분의 피드백을 기다립니다!