1.
AWS Lambda를 이용한
Continuous Integration & Deployment
2017.1.11
Jesang Yoon (yoonjs2@hbsmith.io)

2.
윤제상
Co-Founder & CTO of HBSmith
- 삼성전자 소프트웨어 멤버십 17기
- (전) 삼성전자 무선사업부 서비스 개발팀 선임연구원
- (전) Kanizsa Lab Co-Founder & CTO
- (현) KOSSLAB 오픈 프론티어 3기
- Apache Zeppelin Contributor
- Linkedin & GitHub: yoonjs2
- 개인 Email: yoonjs2@gmail.com

3.
Continuous Integration (지속적인 통합)
- Build & Packaging을 자주 행함
- 여러 사람이 작성한 코드가 병합되었을때 생기는 문제를 미리 감지
- 언제든 최신 Build를 고객에게 바로 제공가능
Continuous Deployment (지속적인 배포)
- Deployment를 자주 행함
- System과 Application을 최대한 Fresh한 상태로 유지
- 장시간 운영시 발생하는 문제를 예방
=> Jenkins, Bamboo, CruiseControl 등을 그동안 주로 사용

4.
Jenkins, Bamboo 같은 솔루션의 문제
- 설치/운영비용 소요
(최소 t2.medium = Android App 필요시)
- 여러 Job들이 같은 서버에서 실행,
Job끼리 영향을 미칠수 있음
- 낮은 활용률: 큰 프로젝트가 아니면
서버가 24시간 내내 바쁠일이 드뭄
=> 운영(관리)에 드는
돈, 시간, 노력을 줄일수 있는 방법은 없을까?

5.
우리는 왜 IDC에서 AWS로 이동하는가?
1. 서버관리를 위한 잡일을 AWS에 위임
2. 시간 및 비용이 절감됨
3. 작은 개발팀으로 큰 시스템 개발/운영 가능
4. 집에 일찍 감
5. 가정이 안정되고 …
6. 나라가 좋아지고 ...

6.
HBSmith의 개발 Stack (AS of 2017.1)
- AWS
- GitHub
- Bamboo => Travis CI
- Atlassian Cloud (JIRA/Confluence)
- Slack

7.
GitHub + Travis CI = 최적의 조합
- GitHub 와의 Seamless한 통합
- 2016 CI Ranking Top 3
(Travis CI, CodeShip, Jenkins)
- 수많은 GitHub기반 OpenSource
프로젝트들이 이용 (ex: Apache
Zeppelin)
- Managed CI 중 가장 많은 Reference
- Docker 기반으로 모든 Job이
Independent한 환경에서 수행
- 정말정말 배우기 쉬움

8.
아직 아쉬운? Travis CI 기능
- Job기반이 아닌, 저장소 기반
- GUI에서 할수 있는게 거의 없음
(대신 REST API는 엄청나게 많음)
- 일부 중요해 보이는 기능이 Beta
- CronJob이 Beta인 상황 (as of 2017.1)
- Cron Expression을 지원 안함

9.
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)

10.
결과: 최신 Stack + 신뢰성 높은 CI/CD 툴 탄생
- Lambda or Travis CI가 장애가 생기지 않
는 한 멈출일이 없음
- 장애가 생겨도 그쪽에서 빨리 복구함, 우리는
기다리면 됨
- iOS도 빌드 가능 (CodeBuild엔 미지원)
- 문제생기면 Slack으로 바로 Notification
=> 2016년 10월 첫 Setup이후 2개월 동안
1700 빌드 이상 진행
중단X, 장애X

11.
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도 고려가능

12.
Code Build & Code Deploy 스택은?
- 아직 HBSmith의 선택기준엔 아직 미 부합
- 충분한 Reference 있음?
- 기존것을 대체할 만큼 충분한 기능있음?
- 확실히 옮길만한 이유가 존재?
- 그러나
- 안정성과 가격으로는 Benefit은 존재
- GitHub 연동이 Travis 대체재가
될 정도라면 쓸만함
- 지켜보겠음 ...?

13.
Code Build vs Travis CI
Code Build Travis CI
아래 요건이 만족되면 Travis CI 보다 훨씬 나음
● 월 돌리는 Build 개수, Build 완료까지 걸리는 시
간이 짧고 유동적일 경우
(시간당 과금이어서 느릴수록 비용이 더 늘어남)
● AWS 인프라만 이용해야 할 경우
● GitHub 외에 다른 저장소일 경우
아래 상황일 경우 Code Build보다 더 나음
● 월 돌리는 기본 Build 개수가 고정되어 있을 경우
● Build 완료까지 걸리는 시간이 꽤 걸릴 경우
(Travis CI는 시간당 과금 없음)
● 팀이 GitHub를 적극적으로 사용할 경우
(특히 PR 및 Review 기능)
● iOS 및 앱 빌드가 필요할 경우

14.
결론: 하나씩 잘하는 것들을 조합, 확실한것을 만들다.
- Execution: AWS Lambda
- Build: Travis CI
=> 이 모든게 서로 잘 조합될수 있는 이유:
- 훌륭한 외부 인터페이스를 가지고 있으며
- Full Managed 이기 때문

15.
Q & A
제 블로그 follow 하시고 더 많은 AWS 팁 가져가세요 ^^
https://medium.com/@yoonjs2
yoonjs2@hbsmith.io