안녕하세요, 여러분. 15년 차 백엔드 개발자이자, 서버리스 아키텍처의 최전선에서 여러분과 같은 고민으로 수많은 밤을 지새운 동료로서 이 글을 씁니다. 혹시 서버리스(Serverless) 아키텍처를 야심 차게 도입하고 나서 "다 좋은데, 왜 가끔 첫 요청이 이렇게 느리죠?"라는 클라이언트의 불만을 들어보신 적 있으신가요? 고객은 로딩 스피너가 3초 이상 돌면 가차 없이 앱을 종료해버리는데, 우리 Lambda 함수는 이제 막 잠에서 깨어나 기지개를 켜고 있는 상황, 정말 등 뒤로 식은땀이 흐르는 순간입니다.
사실 저도 처음 AWS Lambda를 대규모 커머스 서비스에 도입했을 때, 이 악명 높은 '콜드 스타트(Cold Start)' 문제 때문에 꽤나 고생했습니다. 트래픽이 없을 때 비용이 '0원'이라는 엄청난 장점에 매료되었지만, 정작 중요한 블랙 프라이데이 이벤트 때 2~3초씩 지연되는 API를 보며 "이게 과연 프로덕션 레벨에서 쓸 수 있는 기술인가?" 하는 회의감까지 들었죠. 특히 무거운 라이브러리를 많이 사용하는 자바(Java)나 스프링 부트(Spring Boot) 기반의 런타임에서는 JVM 웜업 시간까지 더해져 체감상 5초 이상 걸리기도 했습니다. 클라이언트는 타임아웃 오류를 뱉어내고, 저는 CloudWatch 로그만 하염없이 바라보던 뼈아픈 기억이 납니다.
오늘은 이 골치 아픈 문제를 해결해 줄 가장 확실한 구원투수, 바로 '프로비저닝된 동시성(Provisioned Concurrency)'에 대해 아주 깊이 있게 파헤쳐 보려 합니다. 단순히 "옵션을 켜면 빨라진다" 수준이 아닙니다. 내부적으로 어떤 마법이 일어나는지, 자칫하면 발생할 수 있는 '비용 폭탄'을 피하려면 어떻게 설정해야 하는지, 그리고 제가 현업에서 수천만 원의 비용을 아끼며 배운 최적화 팁까지 몽땅 털어놓겠습니다. 커피 한 잔 진하게 타 오세요. 이제부터 진짜 서버리스 최적화의 세계로 들어갑니다. ☕
1. 콜드 스타트(Cold Start), 도대체 왜 생기는 걸까요?
적을 알고 나를 알면 백전백승이라고 했습니다. 해결책을 논하기 전에, 왜 AWS Lambda가 느려지는지 그 메커니즘을 정확히 이해해야 합니다. 많은 분들이 단순히 "서버가 꺼져 있어서"라고 생각하지만, 실제로는 훨씬 복잡한 4단계의 과정이 숨어 있습니다. 이 과정을 이해해야 어디서 병목이 발생하는지 알 수 있습니다.
AWS Lambda의 생명주기와 초기화 4단계
AWS Lambda가 요청을 받으면, AWS의 내부 시스템은 해당 요청을 처리할 수 있는 '준비된 실행 환경(Execution Environment)'이 있는지 확인합니다. 만약 유휴 상태의 컨테이너가 없다면, AWS는 새로운 컨테이너를 생성해야 합니다. 이 과정이 바로 콜드 스타트입니다. 구체적으로는 다음과 같은 단계가 순식간에 일어납니다.
- 1단계: 코드 다운로드 (Code Download)
S3 버킷이나 ECR(컨테이너 이미지의 경우)에서 여러분이 작성한 함수 코드를 실행 환경으로 가져옵니다. 코드가 50MB라면 빠르겠지만, 200MB가 넘는 무거운 패키지라면 여기서부터 수백 밀리초(ms)가 소요됩니다.
- 2단계: 실행 환경 구성 (MicroVM Start)
AWS는 보안을 위해 Firecracker라는 경량화된 가상 머신(MicroVM)을 띄웁니다. 아무리 경량화되었다고 해도 물리적인 컴퓨팅 자원을 할당하는 시간이 필요합니다.
- 3단계: 런타임 초기화 (Runtime Init)
Node.js, Python, Java 등의 언어 런타임을 구동합니다. Java의 경우 JVM을 띄우고 클래스를 로딩하는 무거운 작업이 여기서 발생하며, 여기서만 2~3초가 걸릴 수도 있습니다.
- 4단계: 함수 초기화 코드 실행 (Init Code)
핸들러(Handler) 함수 밖(Global Scope)에 작성된 코드들을 실행합니다. 데이터베이스 커넥션 풀을 생성하거나, 비밀 키를 로드하거나, 설정 파일을 읽어오는 작업들이죠.
이 모든 과정이 끝나야 비로소 여러분의 비즈니스 로직(Handler)이 실행됩니다. 반면, '웜 스타트(Warm Start)'는 이미 떠 있는 컨테이너를 재사용하기 때문에 위의 1~4번 과정을 모두 건너뛰고 바로 로직을 수행합니다. 성능 차이가 10배에서 100배(예: 50ms vs 5000ms)까지 나는 이유가 바로 여기에 있습니다.
현장에서 겪은 콜드 스타트의 악몽
제 경험을 하나 더 구체적으로 말씀드리죠. 3년 전, 라이브 커머스 프로젝트의 결제 모듈을 Lambda로 구축했습니다. 평소에는 문제가 없었지만, 특정 인플루언서가 방송을 시작하자마자 트래픽이 0에서 10,000 RPM으로 폭주했습니다. 이론상 Lambda는 무한히 확장되어야 하지만, 순간적으로 수백 개의 새로운 컨테이너가 동시에 뜨면서(Scaling out) 거의 모든 사용자가 콜드 스타트를 경험하게 되었습니다.
결과는 처참했습니다. 평균 응답 시간이 80ms였던 API가 순간적으로 P99 기준 4.5초까지 치솟았습니다. 결제 PG사와의 타임아웃 설정(3초) 때문에 결제 실패가 속출했고, 고객센터 전화기에는 불이 났죠. "서버리스는 확장성이 좋다며?"라는 경영진의 질문에 진땀을 흘렸습니다. 이때 깨달았습니다. "아무런 준비 없는 오토스케일링은 재앙이 될 수도 있다"는 것을요.
2. 프로비저닝된 동시성(Provisioned Concurrency)의 원리
2019년, AWS는 이 문제를 해결
댓글
댓글 쓰기