운영하는 서비스의 전체 또는 일부분을 클라우드의 이점을 100% 얻으며 옮겨가기 위해 서버리스는 가장 좋은 선택입니다. 서버리스 환경은 개발자가 애플리케이션을 개발하고 배포하는 방식을 바꾸고 있습니다. 본 세션에서는 서버리스 개발자가 애플리케이션 수명주기 관리, CI/CD, 모니터링 및 진단에 사용할 수 있는 모범 사례를 살펴 봅니다. AWS CodePipeline, AWS CodeBuild 및 AWS CloudFormation을 사용하여 서버리스 애플리케이션을 자동으로 구축, 테스트 및 배포하는 CI/CD 파이프 라인을 구축하는 방법에 대해 설명합니다. 또한 기능 및 API의 여러 버전, 단계 및 환경을 만들기 위해 Lambda 및 API Gateway의 기본 제공 기능에 대해 설명합니다. 마지막으로, Amazon CloudWatch 및 AWS X-Ray로 람다 기능의 모니터링 및 진단에 대해 소개합니다.
컨테이너와 서버리스 기반 CI/CD 파이프라인 구성하기 - 김필중 솔루션즈 아키텍트, AWS / 강승욱 솔루션즈 아키텍트, AWS :: A...Amazon Web Services Korea
컨테이너와 서버리스 기반 CI/CD 파이프라인 구성하기
김필중 솔루션즈 아키텍트, AWS
강승욱 솔루션즈 아키텍트, AWS
서버리스와 컨테이너의 민첩성을 최대한 활용하기 위해서는 CI/CD 파이프라인 구축을 통한 지속적인 배포로 반복적인 코드 업데이트 및 릴리즈가 필수입니다. 본 세션에서는 AWS에서 서버리스와 컨테이너화된 배포를 관리할 수 있는 CI/CD 릴리즈 워크플로우를 효과적으로 구축하는 방법에 대해 살펴봅니다. AWS CodePipeline, AWS CodeBuild, AWS CodeDeploy를 활용한 릴리즈 파이프라인 구축에 대해 알아보고, AWS CloudFormation과 AWS SAM을 활용한 인프라를 코드로서 다루는(IaC) 모델에 대해서도 알아봅니다. 또, 서버리스와 컨테이너를 기반으로 하는 데모 애플리케이션을 통해 실제 업무에 활용할 수 있는 방법에 대해 공유합니다.
운영하는 서비스의 전체 또는 일부분을 클라우드의 이점을 100% 얻으며 옮겨가기 위해 서버리스는 가장 좋은 선택입니다. 서버리스 환경은 개발자가 애플리케이션을 개발하고 배포하는 방식을 바꾸고 있습니다. 본 세션에서는 서버리스 개발자가 애플리케이션 수명주기 관리, CI/CD, 모니터링 및 진단에 사용할 수 있는 모범 사례를 살펴 봅니다. AWS CodePipeline, AWS CodeBuild 및 AWS CloudFormation을 사용하여 서버리스 애플리케이션을 자동으로 구축, 테스트 및 배포하는 CI/CD 파이프 라인을 구축하는 방법에 대해 설명합니다. 또한 기능 및 API의 여러 버전, 단계 및 환경을 만들기 위해 Lambda 및 API Gateway의 기본 제공 기능에 대해 설명합니다. 마지막으로, Amazon CloudWatch 및 AWS X-Ray로 람다 기능의 모니터링 및 진단에 대해 소개합니다.
컨테이너와 서버리스 기반 CI/CD 파이프라인 구성하기 - 김필중 솔루션즈 아키텍트, AWS / 강승욱 솔루션즈 아키텍트, AWS :: A...Amazon Web Services Korea
컨테이너와 서버리스 기반 CI/CD 파이프라인 구성하기
김필중 솔루션즈 아키텍트, AWS
강승욱 솔루션즈 아키텍트, AWS
서버리스와 컨테이너의 민첩성을 최대한 활용하기 위해서는 CI/CD 파이프라인 구축을 통한 지속적인 배포로 반복적인 코드 업데이트 및 릴리즈가 필수입니다. 본 세션에서는 AWS에서 서버리스와 컨테이너화된 배포를 관리할 수 있는 CI/CD 릴리즈 워크플로우를 효과적으로 구축하는 방법에 대해 살펴봅니다. AWS CodePipeline, AWS CodeBuild, AWS CodeDeploy를 활용한 릴리즈 파이프라인 구축에 대해 알아보고, AWS CloudFormation과 AWS SAM을 활용한 인프라를 코드로서 다루는(IaC) 모델에 대해서도 알아봅니다. 또, 서버리스와 컨테이너를 기반으로 하는 데모 애플리케이션을 통해 실제 업무에 활용할 수 있는 방법에 대해 공유합니다.
Cloud-Barista 제1차 오픈세미나 - CB-Spider : 멀티 클라우드 인프라 연동 프레임워크(1st Open Seminar, ...Cloud-Barista Community
멀티 클라우드 서비스 공통 프레임워크 기술(Multi-Cloud Service Common Framework)
- 커뮤니티 사이트(Community Site) : https://github.com/cloud-barista
주요 내용 : 이종 멀티 클라우드 인프라 연동 기술 소개 및 개발 현황
- CB-Spider 시스템 및 서비스 개요
- CB-Spider 기술 개발 현황
- CB-Spider 기술 개발 로드맵
데브옵스 엔지니어를 위한 신규 운영 서비스 - 김필중, AWS 개발 전문 솔루션즈 아키텍트 / 김현민, 메가존클라우드 솔루션즈 아키텍트 :...Amazon Web Services Korea
AWS re:Invent에서 소개된 개발에서 운영까지 이어지는 파이프라인 전체에 대한 최신 기술을 통해, 사일로를 분리하고 협업을 향상하는 방법을 소개합니다. 거버넌스 제어를 위한 AWS Control Tower, 코드 수준에서의 위험성 사전 탐지를 위한 Amazon CodeGuru Reviewer, 더 빠르고 풍부한 기능의 앱 제작을 위한 AWS Amplify Studio, IaC를 위한 AWS Cloud Development Kit, 그리고 운영 효율성을 향상 시키는 Amazon CloudWatch의 신규 기능을 알아봅니다.
Cloud-Barista 제1차 오픈세미나 - CB-Spider : 멀티 클라우드 인프라 연동 프레임워크(1st Open Seminar, ...Cloud-Barista Community
멀티 클라우드 서비스 공통 프레임워크 기술(Multi-Cloud Service Common Framework)
- 커뮤니티 사이트(Community Site) : https://github.com/cloud-barista
주요 내용 : 이종 멀티 클라우드 인프라 연동 기술 소개 및 개발 현황
- CB-Spider 시스템 및 서비스 개요
- CB-Spider 기술 개발 현황
- CB-Spider 기술 개발 로드맵
데브옵스 엔지니어를 위한 신규 운영 서비스 - 김필중, AWS 개발 전문 솔루션즈 아키텍트 / 김현민, 메가존클라우드 솔루션즈 아키텍트 :...Amazon Web Services Korea
AWS re:Invent에서 소개된 개발에서 운영까지 이어지는 파이프라인 전체에 대한 최신 기술을 통해, 사일로를 분리하고 협업을 향상하는 방법을 소개합니다. 거버넌스 제어를 위한 AWS Control Tower, 코드 수준에서의 위험성 사전 탐지를 위한 Amazon CodeGuru Reviewer, 더 빠르고 풍부한 기능의 앱 제작을 위한 AWS Amplify Studio, IaC를 위한 AWS Cloud Development Kit, 그리고 운영 효율성을 향상 시키는 Amazon CloudWatch의 신규 기능을 알아봅니다.
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를 사용하는 관리포인트를 줄일 수 있을 것이라 기대중