Lambda Feature Branch Dev 환경 구성기

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
유니콘부터 대기업까지 쓰는 제품. 같이 만들어볼래요? 에이비일팔공에서 함께 성장할 다양한 직군의 동료들을 찾고 있어요! → 더 알아보기