Lambda를 쓰면서 불편했던 점과 단점을 위해 글을 작성하게 됨!
lambda의 최대 실행시간이 15분밖에 안되기때문에 제목 어그로를참을 수 없었음..
내부 서비스 아키텍처
- 실행 환경: Firecracker Micro VM
- Invoke Data Plane: 호출 시 샌드박스를 선택(또는 생성)하고 요청을 해당 샌드박스로 라우팅하는 내부 웹 서비스
- 이 서비스는 스로틀 제한을 적용하는 역할
즉, Lambda는 멀티 테넌트 기반의 베어메탈 인스턴스 플릿을 운영하며,
이 인스턴스에서 Firecracker microVM을 분할하여
함수의 실행 환경으로 사용해.
자 그러면, 람다 함수가 invoke되면 어떤 일이 일어나는지 보자구 Let's Go
사용자가 Invoke API 호출을 하면,
해당 호출은 실행 환경에 도달하기 전에
일부 또는 모든 Invoke 데이터 플레인 서비스를 거쳐 함수 코드가 다운로드 및 실행돼!
이 과정에는 서로 관련된 세 가지 고유한 스로틀 제한이 있고,
이 제한들이 함께 동작하여 사용자의 호출 요청이 데이터 플레인에 의해
수락될지 또는 스로틀이 적용될지를 결정하지.
동시성
동시성(concurrent)이란
“동시에 존재하거나, 발생하거나, 수행되는 것”을 의미한다는 건 다 알 거야.
따라서 Lambda 동시성 제한은 주어진 시간에 허용되는
동시 진행 중인 호출의 수에 대한 제한이야.
초당 거래 수(TPS) 또는 속도 제한 자체가 아니라,
동시에 진행 중일 수 있는 호출 수에 대한 제한인 거지.
내부적으로, 동시성 제한은 사용자가 특정 시점에 점유할 수 있는
최대 실행 환경(따라서 Firecracker microVM)의 수에 대한 제한으로 해석될 수 있어.
AWS는 들어오는 수요에 맞춰 이 플릿을 지속적으로 모니터링하고 확장하며,
고객 간에 사용 가능한 용량을 공정하게 분배한다고 하네.
결론적으로, 동시성 제한은
한 명의 고객이 모든 가용 용량을 소진하여
다른 고객에게 서비스 거부 상태를 유발하는 것을 방지하기 위해 Lambda를 보호하는 목적으로 존재하는 거야.
아니 그래서 뭐?
잘 들어봐. 고객들의 가용 용량을 적절하게 분배하고 리소스를 최적화해서 비용을 절감하는 것을 목표로 람다에게 함수 실행 시간부터 동시성에 제한이 생겼다는 건,
람다로는 어느정도 규모있는 서비스를 하기 어렵다는 뜻이야.
그러니까!!
사람들이 서버리스를 하려고 Lambda를 쓰다가
ECS Fargate으로 넘어가는 거라규~
