(독서광) 인간이 초대한 대형 참사 - 대형 참사가 일어날 때까지 사람들은 무엇을 하고 있었는가?
Feature Branch Branch Dev QA 환경 구성기
1. Copyright ⓒ AB180 All Rights Reserved
Lambda Feature Branch
Dev QA 환경 구성기
Copyright ⓒ AB180 All Rights Reserved
2022.04.28 - 임원균 (AB180) Backend Engineer
2. 2
Contents
1. Airbridge API의 운영 환경
2. Feature Branch 기반 개발 서버
3. 운영하면서 생긴 문제 - 동시 update
4. 운영하면서 생긴 문제 - lambda 정리
5. 마치며
6. 6
Airbridge API 운영 환경
- 기존에는 Production을 ECS에서 운영하고 있었음 (python, flask)
- 인프라를 Lambda로 변경해서 스케일링에 대한 관리 포인트를 덜고 Feature Branch 기반의 개발 서버를
좀 더 손쉽게 띄워보고자 함
- ECS에서는 Feature Branch 개발 서버를 만들려면 클러스터 안에 새로운 서비스를 만들고 그 안에
Task를 할당하고 로드밸런서에 연결하는 과정을 거쳐야함
-> 이렇게 뜬 서비스들도 주기적으로 삭제하고 관리해야함
- Lambda 환경에서는 새로운 코드를 Deploy만 하고 연결만 하면 구현 가능할 거라 예상
-> serverless 특성상 사용할 때만 실행해주니 비용적으로도 관리하기 쉬울거라 생각함
7. 7
Airbridge API 운영 환경
- 과거(2019)에 ECS에서 한번 Lambda로 옮기려는 시도를 해본적이 있음
- VPC 연결 구조 때문에 최초 실행하는 Cold Start시 응답시간이 너무 느려져서 트래픽이 몰릴 때
사용할 수 없었음 (함수가 호출될 때 10s가 넘었음)
- 향상된 VPC 연결 업데이트를 기다렸고 릴리즈에 맞춰서 다시 Lambda로 옮겨가며 Feature Branch
기반 개발 서버를 만들어 보고자 함
8. 8
Airbridge API 운영 환경
- 인프라를 단순하게 표현하면, Route 53 -> ALB -> Lambda
- python 3.8, flask / FastAPI, Serverless framework 사용 중
9. 9
Airbridge API 운영 환경
- API Gateway를 안쓰고 ALB를 사용하나요?
- API Gateway는 timeout이 30s이고 이는 Hard Limit
- 기존 비즈니스 로직(ex. 통계 리포트 API)에서 30초가 넘는 패턴들이 있어서 ALB를 그대로 사용
- 물론 더 빠르고 정확하게 제공하기 위해서 로직 최적화, 비동기, DB 엔진 개발 등 다방면으로 노력 중
- https://engineering.ab180.co/stories/introducing-luft
10. 10
- small tip: cold start를 줄이기 위해서 provisioned concurrency를 적극 활용 중
- lambda 특성상 runtime이 준비되는 시간이 필요
- 코드 다운로드, 실행 환경 구성, 초기화 코드 구성 등
- 요청이 왔어도 handler 코드가 실행되기 전까지 준비를 해야하는 시간이 반드시 필요함
- 한번 띄운 lambda 컨테이너는 다시 내려가기 전까지 warm 상태라 좀 더 빨리 수행됨
Airbridge API 운영 환경
11. 11
Airbridge API 운영 환경
- small tip: cold start를 줄이기 위해서 provisioned concurrency를 적극 활용 중
- provisioned concurrency를 활용하면 미리 warm상태의 컨테이너를 준비할 수 있음
- provisioned concurrency 사용량 기준으로 application autoscaling을 사용하는 것도 가능함
- 70%로 설정하면 사용량을 70%가 넘는 순간 provisioned concurrency를 더 할당함
- 응답 시간 p99가 80% 감소함
13. 13
Feature Branch 기반 개발 서버
- Feature Branch 기반 개발 서버를 만들게 된 이유
- 초기에는 개발 서버가 stage, dev 각각 하나씩 lambda가 띄워져 있었음
- 기능 개발 후에는 dev branch에 코드를 병합하면 dev lambda로 배포하고 완료되면 QA를 진행함
- 회사가 커지고 팀원이 더 많아지면서 dev branch에 conflict가 점점 발생함
-> 개발중인 기능들끼리 서로 영향을 주기 시작함
- ex. 두명의 작업자가 하나의 컴포넌트에 작업을 하기 때문에 develop branch부터 conflict를 겪었고
QA도중 다른 팀원이 반영한 변경사항이 다른 작업에 영향을 미쳤음
- 위와 같은 문제로, 서로 영향을 받지 않는 작업 브랜치가 필요했음
14. 14
Feature Branch 기반 개발 서버
- Feature Branch 기반 개발 서버 구상
- 티켓 번호(eg. jira: ABRBE-1234)로 브랜치를 생성하면 CD를 통해서 자동화 배포 실행
- CD는 codebuild를 활용하고 있고 PR이 열리면 codebuild를 trigger
- Lambda Feature Branch에 새로운 코드를 업데이트함
- 업데이트 후 새로운 버전의 alias에 티켓 번호를 부여함
- ALB에서 lambda alias로 이동할 수 있도록 target group을 생성하고 ALB에 연결
15. 15
Feature Branch 기반 개발 서버 구현
1. Github에서 Feature Branch(ABRBE-3253)로 브랜치가 생성/업데이트 되면 Lambda에 배포 수행
16. 16
Feature Branch 기반 개발 서버 구현
2. 배포된 코드가 정상적으로 수행할 수 있는 상태인지 검사
- 직접 Lambda를 invoke 하면서 수행
24. 24
운영 문제 - 동시 update
- 개발 도중 코드가 dev 혹은 stage에 합쳐질 일 없이 feature branch에만 있을 수 있게 되었음
- 코드는 개발 단계에서 잘 분리 되었음
- 팀이 작을 땐 잘 동작함. 하지만 팀원이 늘어나면서 여러 팀원이 동시에 feature lambda로 배포 시도
- 2개의 PR이 동시에 열리고 두 코드를 동시에 업데이트 하는 경우 어떤 코드가 alias를 가져야하나?
- 동시에 할 경우 대부분 한쪽이 update code 명령이 실패하는 상황 발생
- 처음에는 배포가 되지 않았을 때 재시도 하는 방향으로 안내했지만 결국 구조적인 문제를 해결해야했음
25. 25
운영 문제 - 동시 update
- 문제 해결
- Feature branch 하나당 Lambda Function 하나씩 생성하기로 결정
- ABRBE-1234면 airbridge-api-ABRBE-1234-app 이름으로 Lambda를 하나 생성함
- 다른 Feature Branch는 다른 Lambda로 만들어지므로 동시에 여러개를 배포 가능
27. 27
운영 문제 - lambda 정리
- 티켓이 생성되고 작업이 진행될 때 마다 함수가 하나씩 만들어짐
- 서비스 quota에 도달하기 시작함
- Lambda의 경우 전체 코드를 저장할 수 있는 size가 75GB (조정 가능)
- ALB의 경우 LB에 설정할 수 있는 rule은 100개 (조정 가능)
- ALB의 경우 LB당 target group은 100개까지 등록 가능 (조정 불가능)
28. 28
운영 문제 - lambda 정리
- 1. 코드 사이즈 해결
- production, stage, dev 처럼 상시 띄워두는 lambda는 이전 버전 주기적 삭제
- feature lambda는 invocation이 7일 이상 없는 lambda에 대해서 삭제
- 2. ALB target group 해결
- ALB target rule도 lambda invocation이 7일 이상 없을 때 삭제
- invocation은 lambda cloudwatch log stream을 보고 확인함
-> 주기적으로 삭제하는 lambda를 하나 만들고 하루마다 트리거 시키면서 가능
29. 29
운영 문제 - lambda 정리
- 직접 만들어서 운영하고 있지만 lambda 삭제하는 오픈소스 존재
- https://www.serverless.com/plugins/serverless-prune-plugin
- https://github.com/karl-cardenas-coding/go-lambda-cleanup
31. 31
마치며
- 현재 개발 프로세스
- 테크 스펙 작성 및 로컬에서 코딩
- Feature Branch를 통해서 개발 서버 배포 후 Front(Dashboard)에 연결
- QA 진행 및 릴리즈
- 기존 개발 경험이 많이 개선되었음
- 코드와 배포를 분리를 했고 2년간 잘 동작함
- 5~10명 정도의 API 개발팀으로 850개 정도의 Feature branch가 생성되었음
- 3k 정도의 feature branch 배포가 이뤄짐
- 자체 유지보수 할 일이 거의 없이 자동으로 수행되며, 개발 iteration을 빠르게 만들 수 있었음
32. 32
마치며
- 계속 자동화를 시도중
- 스타트업에서 신경쓰기 어려운 Ops에 대해서 최대한 자동화 하려는 시도를 계속함
- Deploy, Feature Branch Deploy, Lambda Cleaner …
- Endpoint를 생성하는 것을 넘어서서 Dashboard에서 Feature Endpoint로 연결되는 배포도 자동화
- 슬랙 command로 자동화되어있고 마찬가지로 티켓 번호 있으면 배포 가능
33. 33
마치며
- 앞으로 알아보고 싶은 것
- 새로나온 lambda endpoint를 활용하면 ALB를 거치지 않고도 endpoint를 사용할 수 있지 않을까?
- ALB를 사용하는 관리포인트를 줄일 수 있을 것이라 기대중
