기준: SAP-C02 시험 가이드오류 제보
Lambda 함수를 처음 띄울 때는 모든 게 마법처럼 느껴진다. 코드를 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까지 줄였다.
왜 컨테이너(cgroups + namespaces)가 아니라 micro VM인가. 핵심은 멀티테넌트 환경에서의 격리 강도 때문이다. 한 베어메탈 서버에 수백 명의 고객 함수가 옆에 떠 있을 수 있는데, 컨테이너 격리만으로는 커널 공유로 인한 side-channel 공격(예: Spectre, Meltdown)을 막을 수 없다. Firecracker는 KVM 위에 동작하면서도 device model을 minimal하게 잘라내어, VM 부팅 오버헤드를 컨테이너 수준으로 줄였다.
Firecracker는 NSDI 2020에 발표된 "Firecracker: Lightweight Virtualization for Serverless Applications" 논문에 자세히 설명되어 있다. 특징은 minimal VMM(2만 줄 미만의 Rust 코드)으로 attack surface를 최소화했다는 점. 같은 기술이 Fargate에도 쓰여서 "Lambda와 Fargate는 본질적으로 같은 격리 기술 위에 다른 추상화를 얹은 것"이라고 보면 된다. CS적으로 보면 Lambda는 stateless function 추상화, Fargate는 stateful container 추상화로 사용 사례가 갈린다.
Firecracker가 매번 새 micro VM을 만드는 건 아니다. AWS는 Worker(베어메탈 EC2) 위에 Slot이라는 단위로 사전 워밍업된 micro VM 풀을 유지한다. 새 콜드 스타트 요청이 오면 Slot에서 가져와 함수 코드를 주입하고 init을 실행하는 식이다. 즉 콜드 스타트의 시간 분해는 (1) Slot 할당 — 거의 0 (2) 코드 다운로드·압축 해제 — zip/이미지 크기에 비례 (3) 런타임 부팅 — Java JVM이 가장 무거움 (4) Init 코드 실행 — 사용자 책임. 시험 문제에서 "콜드 스타트를 줄이려면" 보기 중 (2)(3)(4)를 공격하는 것이 정답 후보다.
동시성은 Lambda에서 가장 헷갈리는 개념 중 하나다. 같은 단어가 세 가지 다른 의미로 쓰인다.
| 종류 | 의미 | 영향 |
|---|---|---|
| 계정 동시성 한도(Unreserved) | 리전당 모든 함수가 공유하는 풀. 기본 1,000(소프트). | 한 함수가 폭주하면 다른 함수가 throttle |
| Reserved Concurrency | 특정 함수에 풀의 일부를 예약. 동시에 상한 역할도 함. | 격리 + 상한 |
| Provisioned Concurrency (PC) | 미리 따뜻한(initialized) 인스턴스를 N개 유지. | 콜드 스타트 0, 비용 발생 |
Reserved와 PC는 동시에 쓸 수 있다. 예를 들어 "이 함수는 Reserved=200, PC=50"이라고 설정하면, 평상시 50개는 항상 따뜻하게 유지되고 그 위 트래픽은 150까지 cold scale-out된다. 트래픽이 더 몰리면 그 함수는 200에서 throttle되고, 그 throttle이 다른 함수를 보호한다.
⚠️ 함정: "Reserved Concurrency를 설정하면 그 함수에 N개만 띄울 수 있다"는 표현이 보기에 나온다. 정확히는 N개의 동시 실행을 보장하면서 동시에 상한으로 작동한다. Reserved=10이라면 평상시 10개까지만 동시 실행되고, 나머지는 throttle된다. 이걸 격리 목적으로만 보고 "상한"이라는 의미를 빼먹으면 시나리오를 잘못 푼다.
2019년 한 핀테크가 결제 처리용 Lambda 함수가 새벽 배치 작업 함수의 트래픽 스파이크에 휘말려 throttle된 사건이 있다. 두 함수가 같은 계정 동시성 풀(1,000)을 공유했고, 배치 함수가 1시간 동안 950개를 점유하면서 결제 함수가 50개만 받게 되어 결제 거부율이 30% 가까이 치솟았다. 사후 대응은 결제 함수에 Reserved=500을 부여해 격리. SAP 시험의 "한 함수가 다른 함수에 영향을 준다" 시나리오는 정확히 이 패턴이다.
콜드 스타트의 시간은 단일 숫자가 아니라 누적이다. AWS 공식 데이터 기준 Java 11 Lambda의 콜드 스타트는 다음과 같이 분해된다:
여기서 가장 큰 비중은 Init 코드다. Java Spring Boot 함수는 클래스 수천 개를 로드하면서 평균 2~3초가 사라진다. 이를 줄이는 도구가 SnapStart다.
SnapStart의 동작 원리:
CRaC는 OpenJDK의 공식 프로젝트로, Java JVM 프로세스의 상태를 체크포인트로 저장·복원하는 표준이다. CRIU(Checkpoint/Restore In Userspace)라는 Linux 커널 기능을 기반으로 한다. SnapStart는 CRaC를 채택해 Java에 먼저 적용했고, 2024년 Python·.NET로 확장됐다. 이 모델은 "초기화는 한 번, 실행은 무한"이라는 분산 시스템의 일반적 최적화 패턴을 따른다.
SnapStart가 무료인 이유는 AWS 입장에서도 컴퓨팅 효율이 더 좋기 때문이다. 매 콜드 스타트마다 init을 실행하는 것보다, 한 번 만든 스냅샷을 page cache에서 복원하는 게 CPU·메모리·네트워크 모두 저렴하다. 다만 함정이 있다. 스냅샷은 메모리·디스크 상태를 그대로 복사하므로 init 단계에서 생성한 난수 시드, 고유 ID, DB connection의 TCP 상태가 모든 복원본에 동일하게 들어간다. 그래서 SnapStart 가이드는 "init에서 uniqueness state를 만들지 말 것"을 강조하고, Crac.Resource 인터페이스로 beforeCheckpoint/afterRestore 훅을 제공한다.
⚠️ 함정: SnapStart로 활성화하면 함수 환경이 stateless라는 가정이 깨진다. 예를 들어 init에서
UUID.randomUUID()로 인스턴스 ID를 만들고 캐시 key로 쓰는 코드가 있다면, 모든 SnapStart 복원본이 같은 ID를 갖게 되어 캐시 충돌이 생긴다. 시험에서는 직접 묻지 않지만 실무에서 흔한 함정이라 알아두면 좋다.
VPC 안의 RDS·ElastiCache에 접속하는 Lambda는 VPC 통합이 필수다. 그런데 2019년 이전의 Lambda VPC 통합은 악명 높은 함정이었다. 함수가 새 동시 실행을 만들 때마다 ENI(Elastic Network Interface)를 새로 attach했고, ENI 생성에 10~15초가 걸렸다. 함수가 100개 동시 실행되면 ENI 100개가 만들어졌고, VPC ENI 한도(서브넷당 보통 ~5,000)에 부딪혀 함수가 timeout나는 사고가 빈번했다.
AWS는 2019년 9월 Hyperplane ENI 아키텍처로 이를 완전히 재설계했다. Hyperplane은 AWS 내부 네트워크 가상화 레이어(VPC, NAT GW, NLB도 같은 기반)이고, 다음과 같이 동작한다:
이 변화 덕분에 VPC Lambda 콜드 스타트는 비-VPC와 거의 동일한 수준으로 떨어졌다. 시험에서 "Lambda VPC 통합 시 ENI 폭증을 어떻게 피하나" 같은 질문은 이제 거의 안 나오지만, 운영 관점에서 "한 함수당 ENI 개수는 동시성에 비례하지 않는다"는 사실은 알아두어야 한다.
Hyperplane은 AWS 내부에서 분산 NAT/LB 역할을 하는 Andromeda 같은 SDN 시스템이다. NLB와 PrivateLink, Lambda VPC ENI, NAT Gateway, S3 Gateway Endpoint 모두 Hyperplane 위에서 동작한다. 그래서 Lambda VPC 통합이 "서브넷 내 IP를 쓰지만 실제 트래픽 경로는 Hyperplane을 거친다"는 점이 동작 원리의 핵심이다. AWS re:Invent 2019 "A Serverless Journey: AWS Lambda Under the Hood" 세션이 가장 좋은 1차 자료.
🎯 시나리오: "한 회사가 Lambda 함수에서 VPC 내부 RDS PostgreSQL에 초당 500건 쿼리를 보낸다. 동시 실행이 1,000개로 늘면 RDS의 max_connections=200 한도를 초과해 'too many connections' 오류가 발생한다. 가장 적합한 해결책은?" — 답은 RDS Proxy. Lambda → RDS Proxy → RDS 패턴으로 connection multiplexing(pooling)을 적용하면, Lambda 1,000개가 RDS 50개 연결로 묶인다. 추가로 RDS Proxy는 IAM 인증과 페일오버 시 connection holding도 제공한다. 시험에서 "Lambda + RDS + 동시성 + connection 오류" 키워드 조합은 거의 RDS Proxy가 답이다.
Lambda 호출은 동기/비동기/스트림 3가지가 있고, 각각 재시도 모델이 다르다.
| 호출 모델 | 호출자 | 재시도 |
|---|---|---|
| 동기(Sync) | API GW, ALB, Function URL, 직접 invoke | 호출자 책임 (Lambda는 재시도 안 함) |
| 비동기(Async) | S3 Event, SNS, EventBridge | Lambda가 자동 2회 재시도 (총 3회) |
| 스트림 폴(Poll) | SQS/Kinesis/DDB Streams | ESM이 재시도 + DLQ/PartialBatch |
비동기 호출의 실패 처리는 두 가지가 있다. DLQ(legacy, 함수 실행 자체가 실패한 케이스만)와 Destinations(2019, 성공/실패 모두 라우팅). Destinations가 권장 방식이고 4가지 타겟(Lambda, SNS, SQS, EventBridge)을 지원한다.
2020년 한 e-commerce가 S3 → Lambda(이미지 리사이즈) 파이프라인을 DLQ로 운영하다가, 실패한 이미지에 대해 "어떤 단계에서 어떤 입력으로 실패했는지"를 추적하기 어려워 Destinations로 전환했다. OnFailure → EventBridge로 보내면 실패 이벤트에 원본 입력 + 응답 페이로드 + 실행 컨텍스트가 모두 포함되어 분석이 쉬워졌다. DLQ는 페이로드만 남고 컨텍스트가 없다.
2022년 출시된 Function URL은 Lambda 함수에 직접 HTTPS endpoint를 부여한다. API Gateway 없이도 https://<id>.lambda-url.<region>.on.aws로 접근 가능. 인증은 NONE 또는 IAM(AWS_IAM). CORS·CloudFront 앞단 가능.
언제 쓰나:
언제 쓰면 안 되나:
Function URL은 IAM 인증만 지원하고 Cognito User Pool 통합이 없다. JWT 기반 사용자 인증이 필요하면 API GW + Cognito Authorizer를 써야 한다. 시험에서 "Cognito 사용자 인증 + Lambda" 시나리오는 거의 API GW가 답이다.
함수 패키징은 두 가지 방식이 있다.
| 방식 | 크기 한도 | 사용 사례 |
|---|---|---|
| zip + Layer | zip 50MB(직접 업로드) / 250MB unzipped(S3 경유), Layer 5개 | 일반 함수 + 공통 라이브러리 |
| Container Image (OCI) | 10GB | ML 모델, 큰 바이너리(ffmpeg, headless Chrome), 기존 컨테이너 워크플로 |
Container Image는 ECR Push 후 Lambda가 이미지를 unpack해 micro VM에 주입한다. 10GB 한도는 매우 크지만, 콜드 스타트가 더 길 수 있다(이미지 pull 시간 때문). 대신 Lambda는 이미지를 레이어 단위 lazy loading으로 가져와서 첫 실행 시간을 줄인다. 이는 SOSP 2023 "Faster Cold Starts for Lambda with On-Demand Code Loading" 논문에 자세히 설명되어 있다.
Lambda는 컨테이너 이미지를 받으면 ECR 원본을 그대로 쓰지 않고, AWS 내부 분산 캐시에 block-level deduplication을 적용해 저장한다. 같은 base image(예: public.ecr.aws/lambda/python:3.11)를 쓰는 함수가 1만 개 있어도 storage는 한 번만 쓰인다. 콜드 스타트 시에도 이미지 전체를 다운로드하지 않고, 함수 실행에 필요한 블록만 lazy fetch한다. 이 덕분에 10GB 이미지도 200~500ms 안에 첫 호출이 시작된다.
Lambda는 x86_64와 arm64 두 아키텍처를 지원한다. arm64(Graviton2)는 약 20% 저렴하고 19% 빠르다. 호환성 문제만 없으면 거의 무조건 ARM이 답이다.
언제 ARM을 못 쓰나:
대부분의 Node.js/Python/Go/Java 함수는 그대로 ARM으로 옮길 수 있다. SAP 시험에서 "비용 최적화" + "Lambda" 키워드면 ARM 전환이 첫 번째 후보다.
Lambda는 동시성 한도(예: 1000)까지 무한정 즉시 스케일링되지 않는다. Burst Concurrency라는 초기 폭증 한도가 있고, 리전에 따라 다르다:
이를 초과하면 분당 +500씩 gradual scale-up된다. 즉 0에서 갑자기 5,000 동시 실행이 필요한 워크로드는 처음 몇 분간 throttle된다(HTTP 429). 이를 피하려면 Provisioned Concurrency를 사전에 워밍업해야 한다.
🎯 시나리오: "월 1회 발생하는 블랙프라이데이 세일 시작 시 평소의 50배 트래픽이 5분 안에 몰린다. Lambda 함수가 throttle 없이 처리하게 하려면?" — 답은 Application Auto Scaling으로 Provisioned Concurrency를 스케줄 기반으로 미리 증가시키는 것. 세일 시작 30분 전부터 PC=2000으로 올려두고, 끝나면 PC=10으로 내린다. 비용은 PC 시간당이지만 throttle 회피와 일관된 latency가 더 가치 있다.
Lambda는 표면적으로는 "코드만 쓰면 알아서 돈다"는 약속이지만, production 운영에서는 micro VM 격리·Hyperplane ENI·CRaC 스냅샷·동시성 풀 같은 내부 모델이 비용과 latency를 결정한다. 시험에 나오는 시나리오는 "콜드 스타트(SnapStart vs PC vs init 최적화)", "동시성 격리(Reserved)", "VPC + DB 연결(RDS Proxy)", "ARM 전환" 네 가지 카테고리에 거의 다 매핑된다.
다음 day에서는 Step Functions로 Lambda를 여러 개 묶어 워크플로우를 만드는 방법을 본다. 비동기 호출의 한계(15분 timeout, 재시도 모델의 단순함)를 Step Functions가 어떻게 보완하는지가 다음 글의 핵심이다.
선택지를 클릭하면 정답·해설이 펼쳐집니다.
문제 1
Java 17 Spring Boot 기반 Lambda 함수의 콜드 스타트가 평균 4초다. 운영팀은 추가 비용 없이 이를 1초 이하로 줄이려 한다. 가장 적합한 방법은?
문제 2
한 결제 처리 Lambda 함수가 다른 분석 배치 Lambda의 트래픽 스파이크 때문에 throttle된다. 두 함수는 같은 AWS 계정에서 동작한다. 결제 함수의 최소 500 동시 실행을 보장하고 격리하려면?
문제 3
Lambda 함수가 VPC 안의 RDS PostgreSQL에 접속한다. 동시 실행이 1,500개로 증가하면서 "FATAL: too many connections" 오류가 발생한다. RDS max_connections는 200이다. 가장 적합한 해결책은?
문제 4
S3 → Lambda 비동기 호출 파이프라인에서 실패한 이벤트의 원본 페이로드 + 응답 + 실행 컨텍스트를 모두 분석하고 싶다. 가장 적합한 구성은?
문제 5
한 ML 추론 함수가 1.8GB의 PyTorch 모델 가중치를 포함한다. zip 기반 Lambda의 250MB unzipped 한도를 초과한다. 동시 실행 100개에서도 적절히 동작해야 한다. 가장 적합한 패키징은?
문제 6
블랙프라이데이 세일 시작 시 0에서 5,000 Lambda 동시 실행으로 5분 안에 폭증한다. us-east-1 burst 한도는 3,000이고 그 이후 분당 +500 gradual. throttle 없이 트래픽을 받으려면?
문제 7
Lambda 함수가 Python 3.11이고 NumPy/Pandas만 사용한다. 운영팀이 비용 20% 절감을 원한다. 가장 단순한 변경은?