aws lambda를 이용한 ci/cd 기법
TRANSCRIPT
윤제상Co-Founder & CTO of HBSmith
- 삼성전자 소프트웨어 멤버십 17 기- ( 전 ) 삼성전자 무선사업부 서비스 개발팀 선임연구원- ( 전 ) Kanizsa Lab Co-Founder & CTO- ( 현 ) KOSSLAB 오픈 프론티어 3 기- Apache Zeppelin Contributor- Linkedin & GitHub: yoonjs2- 개인 Email: [email protected]
Continuous Integration ( 지속적인 통합 )- Build & Packaging 을 자주 행함- 여러 사람이 작성한 코드가 병합되었을때 생기는 문제를 미리 감지- 언제든 최신 Build 를 고객에게 바로 제공가능
Continuous Deployment ( 지속적인 배포 )- Deployment 를 자주 행함- System 과 Application 을 최대한 Fresh 한 상태로 유지- 장시간 운영시 발생하는 문제를 예방
=> Jenkins, Bamboo, CruiseControl 등을 그동안 주로 사용
Jenkins, Bamboo 같은 솔루션의 문제- 설치 / 운영비용 소요
( 최소 t2.medium = Android App 필요시 )- 여러 Job 들이 같은 서버에서 실행 ,
Job 끼리 영향을 미칠수 있음- 낮은 활용률 : 큰 프로젝트가 아니면 서버가 24 시간 내내 바쁠일이 드뭄=> 운영 ( 관리 ) 에 드는돈 , 시간 , 노력을 줄일수 있는 방법은 없을까 ?
우리는 왜 IDC 에서 AWS 로 이동하는가 ?
1. 서버관리를 위한 잡일을 AWS 에 위임2. 시간 및 비용이 절감됨3. 작은 개발팀으로 큰 시스템 개발 / 운영 가능4. 집에 일찍 감5. 가정이 안정되고 …6. 나라가 좋아지고 ...
HBSmith 의 개발 Stack (AS of 2017.1)
- AWS- GitHub- Bamboo => Travis CI- Atlassian Cloud (JIRA/Confluence)- Slack
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 한 환경에서 수행- 정말정말 배우기 쉬움
아직 아쉬운 ? Travis CI 기능- Job 기반이 아닌 , 저장소 기반- GUI 에서 할수 있는게 거의 없음
( 대신 REST API 는 엄청나게 많음 )- 일부 중요해 보이는 기능이 Beta
- CronJob 이 Beta 인 상황 (as of 2017.1)
- Cron Expression 을 지원 안함
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)
결과 : 최신 Stack + 신뢰성 높은 CI/CD 툴 탄생- Lambda or Travis CI 가 장애가 생기지 않는 한 멈출일이 없음- 장애가 생겨도 그쪽에서 빨리 복구함 , 우리는 기다리면 됨- iOS 도 빌드 가능 (CodeBuild 엔 미지원 )- 문제생기면 Slack 으로 바로
Notification=> 2016 년 10 월 첫 Setup 이후 2 개월 동안
1700 빌드 이상 진행중단 X, 장애 X
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 도 고려가능
Code Build & Code Deploy 스택은 ?- 아직 HBSmith 의 선택기준엔 아직 미 부합
- 충분한 Reference 있음 ?- 기존것을 대체할 만큼 충분한 기능있음 ?- 확실히 옮길만한 이유가 존재 ?
- 그러나 - 안정성과 가격으로는 Benefit 은 존재- GitHub 연동이 Travis 대체재가 될 정도라면 쓸만함- 지켜보겠음 ...
?
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 및 앱 빌드가 필요할 경우
결론 : 하나씩 잘하는 것들을 조합 , 확실한것을 만들다 .
- Execution: AWS Lambda- Build: Travis CI
=> 이 모든게 서로 잘 조합될수 있는 이유 :- 훌륭한 외부 인터페이스를 가지고 있으며- Full Managed 이기 때문
Q & A제 블로그 follow 하시고 더 많은 AWS 팁 가져가세요
^^https://medium.com/@yoonjs2