서버리스란
코드를 업로드하면 클라우드가 자동으로 실행 환경을 제공하고, 요청이 없을 때는 비용이 0원입니다. 서버는 있지만 개발자가 관리하지 않는다는 의미입니다.
Lambda 실전 예시: 이미지 썸네일 자동 생성
import boto3
from PIL import Image
import io
def handler(event, context):
s3 = boto3.client('s3')
bucket = event['Records'][0]['s3']['bucket']['name']
key = event['Records'][0]['s3']['object']['key']
# 원본 이미지 다운로드
response = s3.get_object(Bucket=bucket, Key=key)
image = Image.open(io.BytesIO(response['Body'].read()))
# 썸네일 생성 (200x200)
image.thumbnail((200, 200), Image.LANCZOS)
buffer = io.BytesIO()
image.save(buffer, format='JPEG', quality=85)
buffer.seek(0)
s3.put_object(
Bucket=bucket,
Key=f"thumbnails/{key}",
Body=buffer.getvalue(),
ContentType='image/jpeg'
)
return {'statusCode': 200}Lambda 배포 설정
# serverless.yml
provider:
name: aws
runtime: python3.12
architecture: arm64 # Graviton: 20% 저렴
memorySize: 512
timeout: 30
functions:
thumbnail:
handler: handler.handler
events:
- s3:
bucket: my-bucket
event: s3:ObjectCreated:*
rules:
- prefix: uploads/
- suffix: .jpgCold Start 최적화
Cold Start 시간:
- Python 3.12: ~300ms
- Node.js 20: ~200ms
- Go 1.21: ~50ms# 전역 초기화 (컨테이너 재사용)
s3 = boto3.client('s3') # 1회만 초기화
def handler(event, context):
response = s3.get_object(...) # 재사용# Provisioned Concurrency로 Cold Start 제거
functions:
api:
provisionedConcurrency: 5 # 5개 인스턴스 항상 웜서버리스 적합성 판단
적합한 워크로드:
- 이벤트 기반 처리 (파일 업로드, 메시지 큐)
- 불규칙한 트래픽 (피크가 있는 API)
- 배치/스케줄 작업 (Cron)
부적합한 워크로드:
- 15분 이상 장기 실행
- 극도로 낮은 레이턴시 (<10ms)
- GPU 집약적 연산
비용 비교
| 방식 | 월 100만 요청 비용 |
|---|---|
| Lambda | ~$10 |
| ECS Fargate (상시) | ~$45 |
| EC2 t3.micro (상시) | ~$9 (고정) |
트래픽이 불규칙하면 Lambda가 압도적으로 저렴합니다. 24/7 고부하에서는 EC2/ECS가 유리합니다.
서버리스는 "인프라 관리 시간 = 0"을 목표로 합니다. 작은 것부터 시작해 점진적으로 확장하세요.
서버리스가 맞는 워크로드 vs 아닌 워크로드
| 적합 | 비적합 |
|---|---|
| 이벤트 드리븐 API, 웹훅, 배치 트리거 | 장시간 CPU(수십 분+) 상시 부하 |
| 트래픽 스파이크가 큰 엔드포인트 | 웹소켓·고정 IP 필수 레거시 |
| 팀 규모 대비 인프라 최소화 | GPU/특수 커널 모듈 필요 |
한도·콜드스타트 실전 대응
# AWS Lambda 동시성·스로틀 확인
aws cloudwatch get-metric-statistics \
--namespace AWS/Lambda --metric-name Throttles \
--dimensions Name=FunctionName,Value=my-fn \
--start-time $(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%SZ) \
--end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
--period 60 --statistics Sum- 프로비저닝된 동시성: 결제 UX·로그인처럼 콜드스타트가 치명적인 경로만.
- 패키지 크기: 의존성은 Lambda Layer/컨테이너 이미지로 분리. 배포 ZIP이 커질수록 콜드스타트↑.
- 타임아웃: API는 29초(API GW) 한계를 넘기면 SQS/Step Functions로 비동기 분리.
관측 최소 세트
- 호출수·오류율·기간·스로틀 알람
- 분산 추적(X-Ray / Cloud Trace)으로 다운스트림 DB 지연 분리
- 구조화 로그에
requestId,tenantId필수
서버리스 함수가 타임아웃·스로틀될 때 진단
운영 중 서버리스 장애의 상당수는 코드 버그가 아니라 한도와 연결 관리 문제입니다.
원인
- 함수 타임아웃이 호출하는 외부 API·DB의 응답 시간보다 짧음
- 계정 또는 함수 단위 동시 실행 한도에 도달해 스로틀(Throttles) 발생
- 호출마다 DB 연결을 새로 열어 DB의 최대 연결 수를 소진
검증 명령 (AWS Lambda 예시)
# 계정 동시성 한도와 함수 설정
aws lambda get-account-settings --query 'AccountLimit.ConcurrentExecutions'
aws lambda get-function-configuration --function-name thumb --query '{timeout:Timeout,mem:MemorySize}'
# 최근 1시간 스로틀·오류 지표
aws cloudwatch get-metric-statistics --namespace AWS/Lambda --metric-name Throttles \
--dimensions Name=FunctionName,Value=thumb --statistics Sum --period 300 \
--start-time $(date -u -d '-1 hour' +%FT%TZ) --end-time $(date -u +%FT%TZ)
# 타임아웃 로그
aws logs filter-log-events --log-group-name /aws/lambda/thumb --filter-pattern '"Task timed out"'(macOS에서는 date -u -v-1H +%FT%TZ처럼 옵션이 다릅니다.)
해결
- 타임아웃은 하위 호출의 타임아웃보다 길게, 하위 호출에는 명시적 타임아웃과 재시도 상한을 둡니다.
- 중요한 함수는 예약 동시성(reserved concurrency)으로 다른 함수와의 경쟁을 막고, 비동기 호출은 큐(SQS)를 앞에 둬 급증을 흡수합니다.
- DB 연결은 핸들러 밖에서 재사용하거나 RDS Proxy 같은 연결 풀을 사용합니다.
재발 방지
- Throttles, Errors, Duration p99에 경보를 걸고, 동시성 사용률이 한도에 가까워지면 미리 한도 상향을 요청합니다.
참고 자료
자주 묻는 질문 (FAQ)
Q. 서버리스가 항상 더 싸나요?
유휴 트래픽에선 유리하지만, 상시 고트래픽·큰 메모리 설정은 컨테이너/VM이 더 쌀 수 있습니다. 월간 GB-초를 먼저 계산하세요.
Q. VPC 안에 넣어야 하나요?
사설 DB 접근이 필요하면 예. 다만 ENI 부착으로 콜드스타트가 늘 수 있어 Hyperplane/네이티브 연동 옵션을 확인하세요.
검증 환경·편집자 주
- 검증 시점: 2026-09 (문서·CLI 플래그는 벤더 업데이트에 따라 달라질 수 있음)
- 명령어는 읽기 전용 조회 위주이며, 프로덕션 적용 전 스테이징에서 plan/dry-run을 권장합니다.
- 본문은 공식 문서 링크와 운영에서 반복되는 실패 패턴을 기준으로 편집 검토했습니다.
실무 적용 순서 (요약)
- 현재 상태 측정(메트릭·비용·오류율) 없이 도구부터 바꾸지 말 것
- 가장 작은 범위에서 변경 → 롤백 조건 명시
- 체크리스트를 런북/티켓 템플릿에 옮겨 팀 공유
- 한 달 뒤 지표로 효과 재평가 후 확대
글마다 출처와 확인 범위가 다릅니다. 아래에 확인일·확인 범위·출처가 기록된 글만 그 범위에서 확인된 것입니다. 기록이 없는 글은 적용 전 사용 중인 버전의 공식 문서로 직접 확인하고, 오류는 이메일로 알려주세요. 편집 정책 · 이메일로 제보
이 글에는 사람이 확인한 날짜·범위 기록이 아직 없습니다.
댓글
첫 번째 댓글을 남겨보세요.