Serverless (lambda 등) 에 대해 이해하기, 장/단점과 경험한 이슈 정리

개요

• 서버리스 서비스를 많이 사용하면서 느꼈던 장/단점이나, 경험했던 이슈를 정리해 보고자 한다.
• 관련된 서비스로는 AWS lambda, Azure functions 등이 있다.

서버리스의 아키텍처 (lambda)

서버리스 실행 과정

1. 이벤트 발생: 트리거 (S3, dynamodb 등)에서 이벤트 발생 -> lambda 의 event queue 로 전달
2. 컨테이너 준비: 예를 들어, 런타임을 python 으로 설정한 경우, python 런타임을 초기화 (cold-start) 하거나 재사용한다.
3. 함수 실행: 이벤트 데이터가 함수 핸들러로 전달되어, 사용자 코드가 실행되고 결과가 반환된다.
4. 이후 로그 기록 (cloudwatch 등), 컨테이너 유지/또는 환경 종료 등의 작업이 실행된다.

병렬 처리와 스케일 아웃

• 서버리스의 내부 작동을 들여다 보면, 런타임 컨테이너가 뜨고 scale-out 함으로써 기능의 스케일을 조정해준다.
• 병렬 처리는 사용하는 트리거의 종류에 따라 다르게 작동한다.
  • HTTP 트리거는 자동으로 확장된다. (처리율 제한은 api gateway 를 쓰거나 (아니면 코드로, ..).
  • 메시지 큐 등의 트리거는 옵션에 따라 병렬 처리를 제한할 수 있다. (batch size, concurrency limit)
• 이 때, 함수 scale 이 증가하면서 (threshold 를 넘으면..) 런타임 컨테이너 또한 scale-out 되며, cold-start 가 발생할 수 있다.
• 이를 방지하려면 AWS - provisioned concurrency, Azure - dedicated function 과 같은 기능을 사용하면 된다. (런타임을 미리 띄워놓는 기능이다.) (하지만 그럴 바에는 container 기반으로...?)

서버리스의 장/단점

장점

• 오토스케일링: 사용량이 많아지면 자동으로 리소스를 확장한다.
• 페치 관리: 인스턴스의 OS, 데이터베이스의 버전 등 업데이트 관리를 자동화한다.
• 빠른 배포: 인프라에 대한 고민 없이, 코드만 관리하면 되므로 배포를 빠르게 할 수 있다.
• 비용 절감: 서버리스는 이벤트 기반으로 실행되므로 비용을 절감할 수 있다.

단점

• 콜드 스타트: 실행 환경 초기화에 시간이 걸린다.
• 비용 예측 어려움, 디버깅 및 모니터링 어려움, 테스트 환경 구축 어려움
• 플랫폼 종속성

느낀 점

• 서버리스를 개발에 활용하면서, 많은 것들이 장점으로 다가왔다.
• 특히 요청 처리의 latency 가 크게 중요하지 않은 워크로드에서 유용했다. (콜드 스타트가 문제가 되지 않는 경우)
• managed queue 서비스와 연동이 매우 간편하고, 병렬 처리가 옵션 설정하는 것만으로 쉽게 해결되었다.
• 리소스를 고민하지 않고 사용량 기반으로 과금만 고민하면 되서 편했다.
• 그렇지만 단점도 많이 느꼈는데, cicd, 모니터링, 로깅, 테스트 구축 등 관리를 꼼꼼하게 하지 않으면 기술 부채로 될 가능성이 높다는 생각이 들었다.
  • 이런 것들이 대부분 플랫폼 종속적인 형태로 제공되어 자동화가 쉽지 않다는 점이 단점으로 느껴졌다.

경험한 이슈

• managed kafka 와 FaaS 를 연동해서 사용하니까, at least once 로 작동하여 함수가 여러 번 구동된다.
  • at least once 보장이라고 명시되어 있어 버그는 아니지만, 애플리케이션에 따라 중복 처리를 핸들링해야 할 수 있다.