클라우드 컴퓨팅이 발전하면서 서버리스 서비스는 현대 애플리케이션의 핵심 선택지가 됨. Google Cloud Run과 AWS Lambda는 각각 Google Cloud와 AWS에서 제공하는 대표적인 서버리스 플랫폼으로, 각기 다른 장점과 사용 사례를 가집니다.
이번 글에서는 두 플랫폼의 특징과, 장단점을 함께 비교하며 상황에 따라 적합한 선택 기준을 정리해보고자 합니다.
1. Google Cloud Run 특징
컨테이너 기반
Cloud Run은 컨테이너를 기반으로 하며, 사용자가 작성한 컨테이너 이미지를 실행. 언어나 프레임워크 제한이 없음
요청 기반 실행
HTTP 요청이 있을 때만 컨테이너를 실행하며, 유휴 시간에는 비용이 발생하지 않음
자동 확장
요청 수에 따라 자동으로 컨테이너 인스턴스를 확장해 트래픽 증가를 처리함
실행 시간 제한
요청당 기본 15분, 최대 60분 실행 가능. 장기 작업에는 적합하지 않음.
VPC 연결 가능
네트워크 설정을 통해 Cloud Run을 VPC 내부에 배포할 수 있음
비용 구조
vCPU, 메모리, 네트워크 사용량에 따라 과금됨.
콜드 스타트
약 100ms ~ 1초 (컨테이너 크기 및 설정에 따라 다름)
2. AWS Lambda 특징
함수 기반
Lambda는 코드를 함수 단위로 실행하며, 사용자는 컨테이너 이미지가 아닌 코드를 업로드
이벤트 기반 실행
HTTP 요청 외에도 DynamoDB, S3 등 다양한 AWS 서비스 이벤트에 의해 실행 가능
자동 확장
초당 수천 개의 요청도 처리 가능하며, 요청 수에 따라 자동 확장
실행 시간 제한
요청당 최대 15분 실행 가능
서버 관리 필요 없음
함수 실행에 필요한 인프라는 모두 AWS에서 관리
비용 구조
실행 시간, 메모리 사용량, 요청 수를 기준으로 과금
콜드스타트
몇 백 ms ~ 수 초 (언어 및 메모리 설정에 따라 달라짐)
3. 콜드 스타트 (Cold Start)
콜드 스타트는 서버리스 환경에서 요청을 처리하기 위한 실행 환경이 준비되는 데 걸리는 시간을 의미한다. 서버리스 플랫폼에서 처음 요청이 오면, 해당 코드나 컨테이너가 실행될 준비를 해야 하기 때문에 처음 요청에 대해 일정 시간 지연이 발생할 수 있다.
Google Cloud Run의 콜드 스타트
- Google Cloud Run은 컨테이너 기반으로 동작하므로, 콜드 스타트 시에는 컨테이너가 초기화되는 시간이 필요
- 처음 요청이 들어오면 컨테이너 이미지가 다운로드되어 실행되는데, 이 과정에서 약간의 지연이 발생할 수 있음.
- 특히, 컨테이너 크기나 복잡성에 따라 초기화 시간이 달라질 수 있기 때문에, 작은 애플리케이션에서는 지연이 적고, 큰 애플리케이션에서는 더 길어질 수 있음.
- 다만, 유휴 상태에서는 비용이 발생하지 않으며, 요청이 오면 자동으로 확장되므로, 콜드 스타트가 발생한 뒤에는 빠르게 실행
AWS Lambda의 콜드 스타트
- AWS Lambda는 함수 기반으로 실행되며, 처음 실행 시에는 실행 환경을 초기화해야 하므로 콜드 스타트 지연이 발생
- Lambda는 짧은 시간 동안 실행되기 때문에 일반적으로 지연 시간이 비교적 짧지만, 대형 패키지나 특정 런타임 환경을 사용할 경우 콜드 스타트 시간이 더 길어질 수 있음
lambda의 경우 단순 함수 실행 환경이지만, cloud run의 경우 전체 컨테이너를 새로 시작해야하기 때문에 GCR 콜드 스타트가 더 길어질 확률이 높음
4. 비용
Google Cloud Run 비용
Google Cloud Run은 vCPU, 메모리, 실행 시간을 기준으로 요금이 부과
주요 비용 항목
-
요청 처리 시간 (Request Processing Time)
요금은 실행 시간(컨테이너가 요청을 처리하는 시간)과 메모리, vCPU 사용량에 따라 결정- vCPU 요금: 1분당 $0.000024 (1분 단위로 부과)
- 메모리 요금: 1GB 메모리에 대해 1분당 $0.0000025
-
요청 수
Google Cloud Run은 1백만 요청당 $0.40의 요금이 부과 -
유휴 시간
요청이 없는 경우, Google Cloud Run은 컨테이너를 자동으로 중지, 유휴 시간에 대한 요금이 발생 X. 즉, 요청이 없으면 비용이 발생하지 않음 -
기본 무료 한도
Google Cloud Run은 매월 2백만 요청, 360,000 vCPU 초, 1GB 메모리 180,000초까지 무료로 제공됩
AWS Lambda 요금
AWS Lambda는 함수 실행 시간(코드가 실행되는 시간)과 메모리 사용량을 기준으로 요금이 부과
주요 비용 항목
-
실행 시간 (Execution Time)
AWS Lambda는 밀리초 단위로 실행 시간을 계산. 메모리 사용량에 따라 실행 시간이 달라짐
요금은 메모리 용량(128MB ~ 10GB)에 따라 100ms 단위로 계산- 메모리 요금: 메모리 사용량에 따라 $0.00001667/GB-초 (100ms마다)
-
요청 수 (Request Count)
Lambda는 1백만 요청당 $0.20의 요금이 부과 -
기본 무료 한도
AWS Lambda는 매월 1백만 요청, 400,000 GB-초까지 무료로 제공 -
Provisioned Concurrency
AWS Lambda는 Provisioned Concurrency 기능을 제공하여, 지정된 수의 인스턴스를 미리 준비 가능. 이 기능을 사용하면 콜드 스타트 시간을 줄일 수 있지만, 초기화된 인스턴스에 대해 비용이 계속 부과
| Google Cloud Run | AWS Lambda | |
|---|---|---|
| 요금 기준 | 요청 처리 시간 (vCPU, 메모리 사용) | 함수 실행 시간 (메모리, 실행 시간) |
| 요금 단위 | 1분 단위 (vCPU와 메모리 사용량에 따라) | 100ms 단위 (메모리 용량에 따라) |
| 기본 무료 한도 | 매월 2백만 요청, 360,000 vCPU 초, 1GB 메모리 180,000초까지 무료 | 매월 1백만 요청, 400,000 GB-초까지 무료 |
| 요청 처리 비용 | 1백만 요청당 $0.40 | 1백만 요청당 $0.20 |
| 실행 시간 비용 | 1분당 $0.000024 (vCPU) + 1분당 $0.0000025 (1GB 메모리) | 메모리 용량에 따라 $0.00001667/GB-초 |
| 유휴 상태 요금 | 유휴 상태에서는 비용 발생 X | 유휴 상태에서는 비용 발생 X |
주요 비교 정리
| 특징 | Google Cloud Run | AWS Lambda |
|---|---|---|
| 기반 구조 | 컨테이너 기반 | 함수 기반 |
| 사용 사례 | 컨테이너 앱, REST API | 이벤트 기반 작업, 단순 함수 실행 |
| 실행 시간 제한 | 최대 60분 | 최대 15분 |
| 확장성 | 트래픽 증가에 따라 자동 확장 | 이벤트와 요청 기반으로 자동 확장 |
| 유연성 | 언어/프레임워크 제한 없음 | 특정 언어 지원(컨테이너 사용 시 확장 가능) |
| 콜드 스타트 | 약간의 지연 가능 | 더 짧은 지연 |
| 비용 | vCPU, 메모리 기준 | 실행 시간, 요청 수 기준 |
5. 적합한 사용 사례
AWS Lambda
- 짧은 실행 시간의 작업: AWS Lambda는 짧은 실행 시간의 작업을 빠르게 처리하는 데 유리. 예) 이벤트 처리, 간헐적인 API 요청, 파일 업로드 후 자동화 처리, 실시간 알림 전송
- 사용자가 S3 버킷에 이미지를 업로드할 때마다 Lambda 함수가 트리거되어 이미지를 자동으로 리사이즈하거나 파일을 다른 위치로 이동
- 비정기적인 작업 처리: Lambda는 비정기적인 작업을 처리할 때 매우 비용 효율적. 요청이 발생할 때만 실행되므로 유휴 상태에서는 요금이 발생하지 않기 때문에 간헐적인 트래픽을 처리하는 데 적합
- 사용자가 가입하거나 로그인할 때마다 Lambda 함수가 트리거되어 사용자를 인증하고 API 토큰을 발급하는 작업을 처리
- 실시간 알림 전송: 실시간 알림이나 메시징 시스템과 같은 이벤트 기반 작업에도 매우 유용. 예)SNS(Single Notification Service) 또는 이메일 알림을 실시간으로 처리
- 사용자가 서비스 내에서 특정 활동을 하면, Lambda는 SNS를 통해 실시간으로 알림을 전송하거나 이메일 전송
Google Cloud Run:
- 긴 실행 시간이 필요한 작업에 적합: Google Cloud Run은 긴 실행 시간을 요구하는 작업을 처리하는 데 유리. 최대 60분까지 실행할 수 있으므로, 머신러닝 모델 배포, 웹 애플리케이션, 대규모 데이터 처리 작업 등을 처리할 수 있습니다.
- 머신러닝 모델 학습 또는 예측 서비스를 제공하는 시스템에서, 대규모 데이터를 처리하거나 모델을 학습하는 작업 실행
- 고정적인 트래픽 처리: Google Cloud Run은 고정적인 트래픽을 처리하는 데 유리하며, 자동으로 확장. Docker 컨테이너 기반으로 서비스를 운영하기 때문에 다양한 언어와 의존성을 처리 가능
- 웹 애플리케이션이나 API 서비스를 제공하는 경우, Cloud Run을 사용하면 지속적인 트래픽을 자동으로 처리하면서 필요에 따라 서버를 확장
- 사용자 로그인 API나 상품 검색 API와 같은 서비스에서 Cloud Run을 사용
- Docker 컨테이너 환경에서 유연한 실행: Cloud Run은 Docker 컨테이너 기반으로 실행되므로, 개발자가 원하는 환경을 자유롭게 설정 가능. 애플리케이션 환경이나 의존성에 제약을 두지 않고 다양한 언어와 라이브러리를 사용 가능
- 멀티 언어 애플리케이션을 운영하는 경우, 하나의 서비스를 Docker로 컨테이너화하여 Python, Node.js, Go 등 다양한 언어로 작성된 마이크로서비스를 독립적으로 실행하고 관리
결론
-
AWS Lambda는 짧고 간헐적인 작업, 이벤트 기반 처리, 비정기적인 트래픽에 매우 적합합니다. 서버리스 아키텍처의 진정한 의미인 자동 스케일링, 비용 효율성을 제공합니다. 간헐적으로 트래픽이 발생하는 API나 이벤트 처리, 실시간 알림 전송 시스템에 이상적입니다. 다만, 긴 실행 시간을 요구하는 작업이나 복잡한 애플리케이션 환경에서는 한계가 있을 수 있습니다.
-
Google Cloud Run은 긴 실행 시간이 필요한 작업, 지속적인 트래픽을 처리하는 웹 애플리케이션, 그리고 Docker 컨테이너 기반으로 실행되어야 하는 복잡한 시스템에 적합합니다. Cloud Run은 자동 확장 기능과 함께 다양한 개발 환경을 지원하므로, 정기적인 서비스, 머신러닝 모델 배포, 대규모 데이터 처리 등과 같은 경우에 유리합니다. 긴 실행 시간이나 고정적인 트래픽을 처리하는 경우에도 효율적으로 운영될 수 있습니다.
결론적으로, 짧고 비정기적인 작업이라면 AWS Lambda, 긴 실행 시간이나 복잡한 환경 설정이 필요한 경우에는 Google Cloud Run이 더 적합합니다. 각 서비스의 특성을 잘 이해하고, 프로젝트의 요구 사항에 맞춰 선택하는 것이 중요합니다.
