AWS Lambda vs Cloud Run: 콜드 스타트보다 동시성이 비용을 바꾼다

짧고 드문 이벤트를 처리한다면 기본 AWS Lambda 함수가 간단한 출발점이다. 요청이 자주 겹치는 API라면 Cloud Run이 유리해질 수 있다. Cloud Run의 인스턴스당 동시 요청 설정은 한 인스턴스가 여러 요청을 함께 처리하게 해 필요한 인스턴스 수를 줄일 수 있지만, 실제 처리량은 코드와 CPU 사용률에 달려 있다.

따라서 두 서비스를 비교할 때는 단일 요청의 콜드 스타트 기록보다 요청이 겹치는 시간, 한 실행 단위가 감당하는 작업량, 유휴 상태로 유지할 용량을 함께 봐야 한다. 첫 응답 지연이 중요한 API는 Lambda의 프로비저닝된 동시성이나 Cloud Run의 최소 인스턴스에 드는 비용까지 포함해야 한다. 같은 월 요청 수라도 이런 조건에 따라 비용의 우위가 바뀐다.

요청별 실행 시간과 인스턴스 활성 시간

기본 Lambda 함수는 호출 수와 배정한 메모리·실행 시간의 곱인 GB-초로 과금된다. AWS의 Lambda 요금표에 나온 미국 동부 버지니아 북부 지역의 x86 예시 단가는 실행 시간 GB-초당 0.0000166667달러, 호출 100만 건당 0.20달러다. 프로비저닝된 동시성을 켜면 확보한 메모리 용량과 시간에 GB-초당 0.0000041667달러가 붙고, 해당 용량에서 처리한 호출과 실행 시간도 별도로 청구된다.

여기서 비교하는 대상은 요청별 실행 시간을 청구하는 기본 Lambda 함수다. AWS 요금표에는 한 실행 환경에서 여러 요청을 처리할 수 있는 Lambda Managed Instances도 별도 과금 모델로 올라와 있다. 이를 기본 함수의 단가에 섞으면 동시성에 따른 비용 계산이 달라지므로 아래 예시에서는 제외한다. 기본 함수에서 실행 중인 요청이 겹치면 그만큼 별도의 실행 환경이 필요하다.

Cloud Run 서비스에는 요청 기반 과금과 인스턴스 기반 과금이 있다. Google Cloud의 Cloud Run 요금표에서 미국 아이오와 지역의 요청 기반 기본 단가는 활성 vCPU-초당 0.000024달러, 활성 GiB-초당 0.0000025달러, 요청 100만 건당 0.40달러다. 요청 기반 과금은 인스턴스가 시작하거나 종료할 때와 요청을 처리하는 동안의 CPU·메모리 시간을 센다. 최소 인스턴스를 유지하면 요청이 없는 시간에도 별도의 유휴 단가가 적용되고, 인스턴스 기반 과금은 인스턴스가 살아 있는 전체 시간을 센다.

핵심은 Cloud Run에서 동시에 처리되는 요청이 같은 인스턴스 활성 시간을 나눠 쓸 수 있다는 점이다. 설정한 최대 동시성이 높아도 코드가 요청을 병렬로 처리하지 못하거나 CPU가 이미 바쁘면 그 수만큼 요청이 한 인스턴스에 모이지 않는다. 반대로 외부 API나 데이터베이스 응답을 기다리는 동안 다른 요청을 진행할 수 있는 코드라면 활성 인스턴스 시간을 줄일 여지가 생긴다. 동시성 설정값을 곧바로 비용 절감률로 읽어서는 안 되는 이유다.

월비용의 교차점은 어디에서 생기나

다음은 과금 구조만 살펴보는 조건부 계산이다. 월 1,000만 건의 요청이 각각 0.4초 걸리고 무료 사용량, 할인, 네트워크 비용, 시작·종료 시간을 제외한다고 가정하자. 기본 Lambda 함수에는 메모리 1GiB와 앞의 버지니아 북부 단가를 적용한다. Cloud Run에는 1vCPU·메모리 0.5GiB와 앞의 아이오와 요청 기반 단가를 적용한다. 두 자원 설정의 실제 처리 능력이 같다는 가정은 아니다.

이 조건에서 Lambda 실행 시간은 모두 합해 400만 초다. 실행료 약 66.67달러에 호출료 2달러를 더하면 월 약 68.67달러가 된다. Cloud Run에서 한 인스턴스가 한 번에 한 요청만 처리하고 인스턴스 활성 시간이 요청 시간과 같다면 CPU·메모리 약 101달러에 요청료 4달러를 더해 약 105달러다. 어느 쪽이 저렴한지는 월 호출량만으로 결정되지 않는다.

Cloud Run 인스턴스가 활성 상태에서 평균 두 요청을 실제로 겹쳐 처리한다면, 같은 가정 아래 인스턴스 활성 시간은 절반인 200만 초로 줄어든다. 계산액은 CPU·메모리 약 50.50달러에 요청료 4달러를 더한 약 54.50달러다. 이 식에서 양쪽 금액이 같아지는 유효 동시성은 인스턴스당 약 1.56건이다. 여기서 유효 동시성은 설정 상한이 아니라 개별 요청 처리 시간의 합을 청구되는 인스턴스 활성 시간의 합으로 나눈 값이다.

실제 청구액은 요청의 도착 간격과 인스턴스 시작·종료, 청구 시간의 반올림에 영향을 받는다. 요청이 잠깐씩 겹쳤다가 끊기면 계산상의 두 배 공유가 실현되지 않는다. CPU를 오래 점유하는 작업은 동시 요청을 늘렸을 때 각 요청이 더 느려질 수도 있다. 한국 서비스를 서울 리전에 배치한다면 이 미국 지역 단가로 나온 교차점을 그대로 적용하지 말고 해당 리전의 단가와 실제 자원 구성을 넣어야 한다.

드문 이벤트 함수에는 무엇이 중요한가

파일 업로드 뒤 메타데이터를 정리하거나 간헐적인 이벤트 한 건을 처리하는 작업은 기본 Lambda 함수의 요청별 모델과 잘 맞는다. 유휴 용량을 따로 확보하지 않고 호출과 실행 시간부터 계산할 수 있기 때문이다. 기존 AWS 이벤트 흐름에 이미 연결된 함수라면 실행 코드와 주변 서비스의 구성도 선택에 영향을 준다. 다만 이것이 드문 작업에서 Lambda가 언제나 더 싸다는 뜻은 아니다. 같은 일을 처리하는 데 필요한 메모리, CPU, 실행 시간이 달라지면 단가만으로는 결론을 낼 수 없다.

이미 컨테이너로 운영하는 HTTP 작업이라면 Cloud Run에 가져갈 수 있는 배포 형태 자체가 이점일 수 있다. 그러나 요청이 드물고 서로 겹치지 않으면 높은 인스턴스당 동시성은 거의 쓰이지 않는다. 백그라운드 작업도 요청을 받아 그 안에서 끝나는지, 요청이 끝난 뒤에도 계속 실행돼야 하는지 구분해야 한다. 후자라면 요청 처리 중의 활성 시간만을 전제로 한 앞의 예시가 작업 전체 비용을 설명하지 못한다.

동시 요청이 많은 API는 왜 달라지나

외부 서비스의 응답을 기다리는 시간이 긴 컨테이너 API에서는 한 요청이 대기하는 동안 다른 요청을 처리할 수 있다. 이런 작업은 Cloud Run의 인스턴스당 동시성이 활성 인스턴스 시간을 줄이는 경로를 갖는다. 요청이 충분히 자주 겹치고 애플리케이션이 병렬 처리를 감당해야 앞의 교차점이 의미를 가진다. 트래픽이 몰리는 순간의 최대 동시 요청 수만 보고 한 달 내내 같은 효율이 나온다고 가정하면 비용을 낮게 잡게 된다.

한 인스턴스 안에서 요청들이 연결 풀, 메모리 또는 공유 상태를 두고 경쟁한다면 처리 시간이 늘어날 수 있다. CPU를 많이 쓰는 요청도 같은 자원을 나눠 쓰므로 설정 상한을 높였다는 이유만으로 인스턴스 수가 줄지는 않는다. 이런 경우 동시성을 낮추면 필요한 인스턴스가 늘고, 높이면 응답 시간이 길어지는 선택이 생긴다. 비교해야 할 값은 설정 화면의 숫자가 아니라 목표 지연을 지키면서 실제로 달성하는 유효 동시성이다.

첫 응답 지연을 줄이는 비용

지연에 민감한 API에서는 준비된 실행 용량을 유지하는 비용이 별도 항목이 된다. AWS의 Lambda 실행 환경 설명에 따르면 콜드 스타트 초기화 시간은 100밀리초 미만부터 1초 이상까지 달라질 수 있다. 프로비저닝된 동시성은 실행 환경을 미리 초기화해 시작 지연을 줄인다. Cloud Run의 최소 인스턴스도 준비된 인스턴스를 유지하지만, 유지한 수를 넘어 요청이 몰리면 새 인스턴스의 시작 시간이 다시 중요해진다.

앞의 미국 지역 예시 단가로 메모리 1GiB인 Lambda 실행 환경 한 개를 30일 내내 프로비저닝하면, 실제 호출과 실행료를 제외한 용량 비용만 약 10.80달러다. Cloud Run에서 1vCPU·0.5GiB 최소 인스턴스 한 개가 같은 기간 내내 유휴 상태라면 요청 기반 과금의 유휴 단가로 약 9.72달러가 나온다. 두 값은 서로 다른 지역과 자원 구성을 사용한 예시이므로 어느 서비스의 확정적인 가격 우위를 나타내지 않는다. 활성 요청이 들어온 시간의 비용과 필요한 대기 용량의 크기는 따로 더해야 한다.

대기 용량을 한 단위만 확보해도 피크의 모든 요청이 따뜻하게 시작하는 것은 아니다. Lambda에서는 준비된 동시성을 넘어선 호출에 추가 실행 환경이 필요하고, Cloud Run에서도 준비된 인스턴스가 감당하지 못하면 확장이 일어난다. 첫 요청 지연의 허용 범위와 동시에 몰리는 요청량이 함께 있어야 상시 유지 비용을 산정할 수 있다. 평균 응답 시간 하나로 준비할 용량을 정하면 지연 목표와 월비용을 모두 잘못 읽을 수 있다.

2020년 지연 측정에서 읽을 수 있는 것

IOD의 2020년 5월 28일 Go 실험은 각 서비스에 200회 호출을 10개씩 병렬로 보내고, 환경 변수를 바꿔 콜드 시작을 유도했다. 코드는 5초 동안 대기하도록 했고 측정용 가상머신은 각 서비스와 같은 클라우드·리전에 뒀다. 그 조건에서 콜드 시작이 응답에 더한 시간은 Lambda 약 210밀리초, Cloud Run 약 1,090밀리초였다. 따뜻한 요청의 추가 지연 중앙값은 반대로 Cloud Run 32밀리초, Lambda 51밀리초였다.

이 수치는 당시의 코드, 구성, 지역에서 얻은 결과이며 현재 서울 리전의 성능 수치가 아니다. 또한 콜드 시작의 추가 시간과 따뜻한 요청의 추가 지연은 서로 다른 상황을 측정한다. 하나의 순위로 합치면 지연에 민감한 API가 마주하는 두 문제가 가려진다. 드문 첫 호출이 중요한 서비스와 지속적으로 요청을 받는 서비스는 같은 실험 결과에서도 주목할 값이 다르다.

플랫폼 선택에서 남는 판단 기준은 작업별로 분명하다. 드문 단발 작업은 호출당 필요한 자원과 실행 시간이 중심이고, 대기 시간이 많은 API는 실제로 겹쳐 처리한 요청 수가 중심이다. 첫 응답 지연을 엄격하게 관리해야 한다면 여기에 유휴 용량을 유지하는 시간을 더해야 한다. 같은 트래픽이라도 이 세 값의 조합이 달라지면 비용의 교차점도 달라진다.

함께 읽기:

• AI 시대 인사평가, 산출물 개수보다 재작업률을 봐야 한다
• Stripe냐 Paddle이냐…수수료보다 ‘판매자 책임’이 비용을 가른다
• AI 추론비를 낮추려면 GPU보다 작업을 먼저 나눠야 한다