람다 함수를 처음 띄울 때는 모든 게 마법처럼 느껴진다. 코드를 zip으로 올리거나 컨테이너 이미지를 가리키기만 하면 누군가가 알아서 띄우고 알아서 스케일링한다. 그러나 production에서 트래픽이 갑자기 10배로 뛰는 순간, "어제까지 50ms였던 응답이 왜 갑자기 5초가 되었나" 같은 질문이 떠오른다. 그 답은 거의 항상 동시성 한도, 콜드 스타트, VPC ENI 셋 중 하나에 있다.
SAP-C02 시험에서 Lambda는 서버리스 도메인의 중심축이고, 단순한 "이벤트 → 함수 실행" 수준의 문제는 거의 안 나온다. 대부분의 문제는 "트래픽 스파이크에 대응하는 가장 비용 효율적인 방법", "콜드 스타트를 비용 추가 없이 줄이는 방법", "VPC 안에서 Lambda가 RDS Proxy에 접속할 때 ENI 폭증을 피하는 방법" 같은 운영 관점이다. 오늘은 그 운영 관점을 만드는 내부 동작을 본다.
Lambda를 "컨테이너 서비스"라고 부르는 자료가 많지만, 정확히는 컨테이너가 아니다. 각 함수 인스턴스는 Firecracker라는 자체 마이크로 VMM(Virtual Machine Monitor) 위에 올라간 micro VM이다. AWS가 2018년 OSS로 공개한 Firecracker는 QEMU를 대체할 목적으로 만들어졌고, 부팅 시간을 약 125ms까지 줄였다.