서버리스 컨테이너 (Serverless Container)
개요
서버리스 컨테이너는 컨테이너 기반 애플리케이션을 서버 인프라 관리 없이 실행할 수 있는 클라우드 컴퓨팅 모델입니다. 기존 FaaS(Function as a Service)가 함수 단위 실행에 머무르는 반면, 서버리스 컨테이너는 전체 컨테이너 이미지를 단위로 배포하므로 레거시 애플리케이션 마이그레이션과 복잡한 마이크로서비스 구현에 더 유연합니다.
AWS Fargate, Google Cloud Run, Azure Container Apps 같은 관리형 서비스는 컨테이너 오케스트레이션의 복잡성(노드 관리, 스케줄링, 자동 스케일링)을 클라우드 제공자에게 이관합니다. 개발자는 컨테이너 이미지와 리소스 사양만 지정하면 됩니다. 이 모델은 Kubernetes 기반 Knative, OpenFaaS 같은 온프레미스 솔루션으로도 확장 가능합니다.
핵심 개념
서버리스 컨테이너 vs FaaS
서버리스 컨테이너와 FaaS는 모두 서버리스 컴퓨팅이지만, 실행 단위와 제약 조건에서 차이가 있습니다.
| 특성 | FaaS (Lambda 등) | 서버리스 컨테이너 (Fargate 등) |
|---|---|---|
| 실행 단위 | 함수 (Function) | 컨테이너 (Docker 이미지) |
| 런타임 지원 | 제한된 런타임만 지원 | 모든 언어/프레임워크 가능 |
| 패키징 | 코드 + 의존성 | 완전한 컨테이너 이미지 |
| 실행 시간 제한 | 보통 5-15분 | 제한 없음 (장시간 실행 가능) |
| 콜드 스타트 | 수백 ms~수 초 | 수 초~수십 초 |
| 상태 유지 | 무상태 (외부 저장 필수) | 로컬 디스크 임시 사용 가능 |
| 비용 모델 | 요청 + 실행 시간 | 초 단위 과금 + vCPU/메모리 |
| 네트워크 | VPC 연결 제한 | 완전한 VPC 접근 |
관리형 서버리스 컨테이너 서비스
AWS Fargate
Fargate는 AWS ECS와 EKS에서 컨테이너를 서버리스로 실행하는 엔진입니다. EC2 인스턴스를 관리할 필요 없이 컨테이너의 CPU/메모리 리소스를 지정하면 자동으로 프로비저닝됩니다.
Fargate의 주요 특징:
- microVM 격리: Firecracker 기반 마이크로VM으로 각 컨테이너를 격리하여 보안성 확보
- ECS/EKS 통합: 기존 ECS 태스크 정의나 EKS 파드 사양에 requiresCompatabilities: FARGATE 추가로 전환
- ENI 할당: 각 태스크에 고유한 Elastic Network Interface를 할당하여 VPC 네티브 보안 그룹 적용
- 스토리지: EFS 마운트 지원, 로컬 Ephemeral Storage 최대 200GB
Fargate 리소스 사양:
| 리소스 | 최소 | 최대 | 비고 |
|---|---|---|---|
| vCPU | 0.25 | 16 | 0.25 단위 증가 |
| 메모리 | 0.5GB | 120GB | vCPU당 0.5-8GB 비율 |
| 스토리지 | 20GB | 200GB | 로컬 ephemeral |
| Linux | x86_64, ARM64 | - | Graviton 지원 |
Google Cloud Run
Cloud Run은 컨테이너를 HTTP 서비스로 배포하는 완전 관리형 플랫폼입니다. 컨테이너 이미지를 업로드하면 자동으로 스케일링됩니다.
Cloud Run의 주요 특징:
- HTTP 트리거 중심: 웹 요청에 최적화, 비HTTP 작업은 Cloud Tasks 연동
- 스케일 to zero: 트래픽이 없으면 완전히 종료되어 비용 0원
- 최소 인스턴스: 콜드 스타트 방지를 위해 미리 워밍된 인스턴스 유지 가능
- 이미지 크기 제한: 최대 32GB (라이트 빌드 권장)
- 컨테이너 요청: 1 요청 = 1 컨테이너 인스턴스 (동시 요청 제한 설정 가능)
Azure Container Apps
Azure Container Apps는 Kubernetes 기반이지만 관리형으로 제공되는 서버리스 컨테이너 서비스입니다.
Container Apps의 주요 특징:
- KEDA 기반 스케일링: 이벤트 소스 큐 길이, CPU 사용량 등 기반 자동 스케일링
- Dapr 통합: 마이크로서비스 간 통신, 상태 관리, 서비스 디스커버리
- revision 기반 배포: 트래픽 분산, A/B 테스트, 카나리 배포 지원
- Job 지원: 스케줄 및 이벤트 기반 비동기 작업 실행
Knative — 온프레미스 서버리스 컨테이너
Knative는 Kubernetes 위에서 서버리스 컨테이너 실행 환경을 제공하는 오픈소스 프레임워크입니다. Cloud Run의 상위 호환으로, 온프레미스나 하이브리드 클라우드 환경에서 사용할 수 있습니다.
Knative 구성 요소:
- Knative Serving: HTTP 트리거 기반 컨테이너 배포, 자동 스케일링 (스케일 to zero 포함), 트래픽 라우팅
- Knative Eventing: 이벤트 소스-싱크 연결, 이벤트 브로커, 채널/구독 패턴
- Knative Functions: kn func CLI로 함수 단위 개발 → 컨테이너 이미지 자동 빌드
Knative Serving vs Cloud Run 비교:
| 특성 | Knative Serving | Google Cloud Run |
|---|---|---|
| 실행 환경 | 온프레미스 / Any Cloud | Google Cloud 전용 |
| 컨테이너 격리 | gVisor, Kata Containers | Firecracker microVM |
| 커스터마이징 | 높음 (Kubernetes 네이티브) | 낮음 (관리형) |
| 운영 부담 | 높음 (K8s 관리 필요) | 매우 낮음 |
비교/분석
주요 서버리스 컨테이너 서비스 비교표
| 기능 | AWS Fargate | Google Cloud Run | Azure Container Apps | Knative |
|---|---|---|---|---|
| 배포 단위 | ECS 태스크 / EKS 파드 | 컨테이너 | Container App | K8s Service |
| 최소 vCPU | 0.25 | 0.08 (125m) | 0.25 | Kubernetes 의존 |
| 최대 vCPU | 16 | 8 | 4 | Kubernetes 의존 |
| 최대 메모리 | 120GB | 32GB | 32Gi | Kubernetes 의존 |
| 스케일 to zero | 아니오 (최소 1) | 예 | 예 | 예 (K8s 0→N) |
| 장시간 실행 | 예 (최대 14일) | 예 (60분, 무한 연장 가능) | 예 (Job) | 예 |
| VPC 접근 | 완전 | 완전 | 완전 | 완전 |
| GPU 지원 | 아니오 | 아니오 | 아니오 | 아니오 |
| HTTPS 엔드포인트 | ALB/NLB 연결 | 자동 생성 | 자동 생성 | Gateway API |
| 비용 과금 | vCPU시간 + 메모리시간 | vCPU시간 + 메모리시간 + 요청 수 | vCPU시간 + 메모리시간 | 인프라 비용 |
| 최대 컨테이너 크기 | 10GB 이미지 | 32GB | 50GB | Kubernetes 의존 |
동작 원리 — 요청 흐름
서버리스 컨테이너의 일반적인 요청 흐름은 다음과 같습니다:
- 요청 수신: API Gateway/Load Balancer가 사용자 요청을 수신합니다.
- 라우팅 결정: 서비스 URL/경로에 따라 대상 서버리스 컨테이너를 결정합니다.
- 인스턴스 확인: 기존 웜 인스턴스가 있는지 확인합니다.
- 콜드 스타트 (선택): 웜 인스턴스가 없으면 새 컨테이너를 시작합니다.
- 요청 전달: 컨테이너가 요청을 처리하고 응답을 반환합니다.
- 스케일링: 동시 요청 수, 큐 길이, CPU 사용량 등에 따라 인스턴스 수를 조정합니다.
컨테이너 이미지 최적화
서버리스 컨테이너에서 콜드 슀트 시간과 비용은 컨테이너 이미지 크기에 직접적으로 영향을 받습니다.
이미지 최적화 기법:
| 기법 | 설명 | 절감 효과 |
|---|---|---|
| 멀티스테이지 빌드 | 빌드와 런타임 이미지 분리 | 60-80% 크기 감소 |
| 베이스 이미지 경량화 | Alpine, distroless, scratch 사용 | 50-90% 크기 감소 |
| 의존성 정리 | 불필요한 패키지 제거 | 10-30% 크기 감소 |
| 이미지 레이어 캐싱 | 변경 빈도 낮은 레이어 상단 배치 | 빌드 시간 단축 |
| 멀티 플랫폼 빌드 | ARM64/x86_64 각각 빌드 | 이중 아키텍처 호환 |
런타임별 권장 이미지:
| 런타임 | 기존 이미지 | 경량 이미지 | 크기 비교 |
|---|---|---|---|
| Python | python:3.12 | python:3.12-slim | 900MB → 150MB |
| Node.js | node:20 | node:20-alpine | 1GB → 180MB |
| Java | eclipse-temurin:21 | eclipse-temurin:21-jre-alpine | 400MB → 200MB |
| Go | golang:1.22 (빌드 only) | scratch (최종) | 800MB → 10MB |
| .NET | mcr.microsoft.com/dotnet/runtime:8.0 | mcr.microsoft.com/dotnet/runtime-deps:8.0-alpine | 200MB → 80MB |
스케일링 동작 비교
서버리스 컨테이너의 스케일링은 서비스마다 다른 메커니즘을 사용합니다.
| 서비스 | 스케일링 기준 | 콜드 스타트 | 동시성 모델 |
|---|---|---|---|
| Fargate | ECS Service 스케일링 정책 (CPU/메모리/커스텀) | 수 초~수십 초 | 1 컨테이너 = 1 태스크 |
| Cloud Run | 동시 요청 수, CPU 사용량 | ~50ms (최소 인스턴스) | 1 컨테이너 = N 동시 요청 |
| Container Apps | KEDA 스케일러 (큐, CPU, 커스텀) | 수 초 | 1 컨테이너 = N 동시 요청 |
| Knative | 동시 요청 수, RPS, 스케일 to zero 대기 시간 | Kubernetes 의존 | 1 컨테이너 = N 동시 요청 |
동작 원리
Firecracker MicroVM (Fargate)
AWS Fargate는 Firecracker 오픈소스를 기반으로 한 마이크로VM을 사용합니다. 각 컨테이너는 격리된 VM 안에서 실행되며, 기존 EC2 인스턴스보다 가볍고 빠르게 시작됩니다.
Firecracker 아키텍처:
- KVM 기반 가상화: Linux 커널의 KVM을 사용하여 하드웨어 수준 격리
- 최소화된 게스트: 불필요한 디바이스 드라이버 없이 필수 구성 요소만 포함
- 제한된 리소스: 각 microVM에 할당된 vCPU, 메모리, 네트워크 대역폭
- 빠른 스냅샷: 마이크로VM 상태를 스냅샷으로 저장하여 재시작 시간 단축
Cloud Run의 컨테이너 라이프사이클
Cloud Run은 컨테이너의 생명주기를 다음과 같이 관리합니다:
- 이미지 풀: Google Container Registry 또는 Artifact Registry에서 이미지 다운로드
- 시작 (Start): 컨테이너를 시작하고 애플리케이션을 초기화합니다
- 수신 대기 (Ready):
/healthz또는 지정된 헬스 체크 경로로 응답 대기 - 요청 처리: 수신된 HTTP 요청을 처리합니다
- ** 유휴 (Idle):** 요청이 없으면 유휴 상태가 되고, 설정된 시간 후 종료됩니다
- 종료 (Stop): SIGTERM 시그널을 보내고, grace period 후 강제 종료
이벤트 기반 서버리스 컨테이너 패턴
서버리스 컨테이너는 HTTP 이벤트 외에도 다양한 이벤트 소스와 통합됩니다:
- 메시지 큐 기반: SQS, Pub/Sub, Service Bus에서 메시지를 수신하여 처리
- 스토리지 이벤트: S3/GCS 버킷 업로드 시 자동 트리거
- 스케줄 기반: Cron 표현식으로 정기 실행 (Fargate Scheduled Tasks, Cloud Run Jobs)
- GitHub Actions: CI/CD 파이프라인에서 빌드/테스트/배포 자동화
장단점
장점
- 인프라 관리 제거: 서버, 클러스터, 스케줄링 인프라를 관리할 필요 없음
- 유연한 패키징: 모든 언어, 프레임워크, 레거시 애플리케이션을 컨테이너로 배포 가능
- 자동 스케일링: 트래픽에 따라 인스턴스를 자동으로 추가/제거
- 비용 최적화: 사용한 리소스만큼만 과금, 유휴 시 비용 최소화
- 보안 격리: 컨테이너별 격리된 실행 환경으로 보안성 확보
- 이식성: 컨테이너 이미지는 로컬/클라우드/온프레미스 어디서든 동일하게 실행
단점
- 콜드 스타트: 첫 요청 시 컨테이너 시작에 수 초~수십 초 소요
- 실행 시간 제한: 장시간 실행 작업에는 적합하지 않음 (Fargate 최대 14일, Cloud Run 60분)
- 네트워크 복잡성: VPC, 보안 그룹, 로드 밸런서 설정이 필요할 수 있음
- 디버깅 어려움: 서버리스 환경에서 로깅, 모니터링, 디버깅이 복잡할 수 있음
- vendor lock-in: 각 서비스별 고유 기능에 종속될 수 있음
- 상태 관리 제한: 무상태 설계가 권장되며, 상태가 필요한 애플리케이션은 추가 구성 필요
관련 기술
- 서버리스 시스템 — FaaS, BaaS, 서버리스 아키텍처 기초
- 서버리스 메모리 — 서버리스 환경의 메모리 관리
- 콜드 스타트 최적화 — 콜드 슀트 원인과 최적화 기법
- Docker — 컨테이너 표준 플랫폼
- Kubernetes — 컨테이너 오케스트레이션
- Knative — Kubernetes 기반 서버리스 프레임워크
- Firecracker — AWS 오픈소스 마이크로VM
핵심 정리
- 서버리스 컨테이너는 컨테이너 이미지를 단위로 배포하여 서버 인프라 관리 없이 실행하는 모델로, FaaS보다 유연한 패키징과 장시간 실행을 지원합니다.
- AWS Fargate는 Firecracker microVM 기반 격리와 ECS/EKS 통합을, Google Cloud Run은 HTTP 중심의 간단한 배포와 스케일 to zero를, Azure Container Apps는 KEDA/Dapr 기반 이벤트 스케일링을 제공합니다.
- Knative는 Kubernetes 위에서 온프레미스/하이브리드 환경에서 서버리스 컨테이너를 구현하는 오픈소스 대안입니다.
- 콜드 스타트를 줄이려면 컨테이너 이미지를 경량화하고, 최소 인스턴스를 설정하며, 웜 인스턴스를 유지하는 전략이 필요합니다.
- 서버리스 컨테이너는 마이크로서비스, CI/CD, 이벤트 처리, REST API 등 다양한 워크로드에 활용되지만, 장시간 실행 작업이나 상태 유지가 필요한 경우 제약을 고려해야 합니다.