•
Airbridge 서비스와 Workload 소개
◦
Daily 1B 이벤트 수집, 처리한 것을 Dashboared에 제공
◦
Dashboard에서는 고객의 다양한 Needs를 빠르게 구현하고 안정적으로 제공해야하는 미션을 가짐
•
Airbridge API 운영 환경
◦
Python, Flask 환경
◦
Production을 ECS에서 Lambda로 옮겼음
◦
Route 53 → ALB → Lambda 인프라 사용중
◦
Tip: Code Start를 줄이기 위해서 Provisioned Concurrency를 활용 중
▪
Lambda 특성상 cold start가 잦고
•
Feature Branch 기반 개발 서버
◦
개발 서버 분리 이유
▪
초기에는 stage, dev 개발 서버만 존재했고 기능개발 후 dev 서버에 띄워서 QA했음
▪
회사가 성장하고 팀원이 많아지면서 dev branch에 conflict를 해결해야하는 일이 잦아짐
▪
QA를 위한 개발 서버를 작업별로 분리해야할 필요가 생김
◦
Feature Branch 기반 개발 서버 구상
▪
티켓 번호(eg. jira: ABRBE-1234)로 브랜치를 생성하면 CD 실행
▪
Lambda Feature Branch에 새로운 Feature Lambda에 업데이트 수행
▪
업데이트 후 새로운 버전에 alias에 티켓 명을 부여함
▪
ALB에서 lambda alias로 이동할 수 있도록 target 생성
◦
실제 구현
▪
Feature Lambda 배포 진행
▪
Health Check 수행: Lambda에 직접 invoke를 날려봄
▪
가장 최신의 Lambda Version을 가져오도록 수행
▪
정해진 Alias를 찾거나 없다면 별칭을 하나 만듦
▪
Alias의 Lambda Version을 최신 버전으로 이동
▪
ALB에 target group을 가져오거나 생성
▪
ALB Rule에 추가하고 Route53에 연결
◦
개발자는 배포를 위해서 PR만 열면 됨
•
동시 업데이트 문제
◦
Feature Lambda를 하나로 운영하다보니 동시에 코드를 업데이트하는 경우 문제가 생김
▪
항상 최신 Lambda에 alias를 부여하다보니 동시에 배포되면 한 버전에 2개의 alias가 부여됨
◦
Feature Lambda를 하나로 하는 것이 아닌 여러개로 띄우고자 함
▪
다른 Feature Branch는 다른 Lambda로 띄움으로서 동시에 여러개를 배포해도 문제 없게 되었음
•
Lambda Quota 문제
◦
Service Quota
▪
Lambda 코드 저장 75G까지 가능 (조정 가능)
▪
ALB의 경우는 target group을 100개까지 등록 가능 (조정 불가능)
◦
해결
▪
7일 이전의 Lambda Version은 삭제하도록 변경
▪
Feature Branch도 주기적으로 검사해서 invocation이 없으면 삭제
•
ALB 및 Target group도 같이 삭제함
•
마치며
◦
현재 개발 프로세스
▪
Tech Spec 작성 후 로컬에서 개발 진행
▪
Feature Branch를 통해서 개발 서버 배포 후 Front 연결
▪
QA 진행 및 릴리즈
◦
기존 개발 경험 개선
▪
코드와 배포를 분리했고 2년간 문제 없이 잘 동작함
▪
5~10명의 개발팀으로 850개의 Feature branch 개발 서버 생성
▪
3k 넘는 개발 서버 배포가 이뤄짐
▪
자체 유지 보수를 할 일이 거의 없이 수행되며 개발 Iteration을 빠르게 수행 가능
ᴡʀɪᴛᴇʀ
Wonkyun Lim @Corikachu
Backend Software Engineer @AB180