홈/인프라/서버리스 도입 가이드: 적합한 워크로드·한도·관측
인프라서버리스Lambda

서버리스 도입 가이드: 적합한 워크로드·한도·관측

Lambda/Cloud Functions/Azure Functions를 언제 쓰고 언제 피할지, 콜드스타트·동시성·관측 포인트와 실무 체크리스트.

서버리스 도입 가이드: 적합한 워크로드·한도·관측
목차
  1. 서버리스란
  2. Lambda 실전 예시: 이미지 썸네일 자동 생성
  3. Lambda 배포 설정
  4. Cold Start 최적화
  5. 서버리스 적합성 판단
  6. 비용 비교
  7. 서버리스가 맞는 워크로드 vs 아닌 워크로드
  8. 한도·콜드스타트 실전 대응
  9. 관측 최소 세트
  10. 서버리스 함수가 타임아웃·스로틀될 때 진단
  11. 참고 자료
  12. 자주 묻는 질문 (FAQ)
  13. 검증 환경·편집자 주
  14. 실무 적용 순서 (요약)

서버리스란

코드를 업로드하면 클라우드가 자동으로 실행 환경을 제공하고, 요청이 없을 때는 비용이 0원입니다. 서버는 있지만 개발자가 관리하지 않는다는 의미입니다.

Lambda 실전 예시: 이미지 썸네일 자동 생성

Python
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 배포 설정

YAML
# 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: .jpg

Cold Start 최적화

CODE
Cold Start 시간:
- Python 3.12: ~300ms
- Node.js 20: ~200ms
- Go 1.21: ~50ms
Python
# 전역 초기화 (컨테이너 재사용)
s3 = boto3.client('s3')      # 1회만 초기화

def handler(event, context):
    response = s3.get_object(...)  # 재사용
YAML
# 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/특수 커널 모듈 필요

한도·콜드스타트 실전 대응

Bash
# 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로 비동기 분리.

관측 최소 세트

  1. 호출수·오류율·기간·스로틀 알람
  2. 분산 추적(X-Ray / Cloud Trace)으로 다운스트림 DB 지연 분리
  3. 구조화 로그에 requestId, tenantId 필수

서버리스 함수가 타임아웃·스로틀될 때 진단

운영 중 서버리스 장애의 상당수는 코드 버그가 아니라 한도와 연결 관리 문제입니다.

원인

  • 함수 타임아웃이 호출하는 외부 API·DB의 응답 시간보다 짧음
  • 계정 또는 함수 단위 동시 실행 한도에 도달해 스로틀(Throttles) 발생
  • 호출마다 DB 연결을 새로 열어 DB의 최대 연결 수를 소진

검증 명령 (AWS Lambda 예시)

Bash
# 계정 동시성 한도와 함수 설정
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을 권장합니다.
  • 본문은 공식 문서 링크와 운영에서 반복되는 실패 패턴을 기준으로 편집 검토했습니다.

실무 적용 순서 (요약)

  1. 현재 상태 측정(메트릭·비용·오류율) 없이 도구부터 바꾸지 말 것
  2. 가장 작은 범위에서 변경 → 롤백 조건 명시
  3. 체크리스트를 런북/티켓 템플릿에 옮겨 팀 공유
  4. 한 달 뒤 지표로 효과 재평가 후 확대
✦ ✦ ✦
출처·검증 안내

글마다 출처와 확인 범위가 다릅니다. 아래에 확인일·확인 범위·출처가 기록된 글만 그 범위에서 확인된 것입니다. 기록이 없는 글은 적용 전 사용 중인 버전의 공식 문서로 직접 확인하고, 오류는 이메일로 알려주세요. 편집 정책 · 이메일로 제보

이 글에는 사람이 확인한 날짜·범위 기록이 아직 없습니다.

발행 ·
주제 관련 공식 문서(자동 연결 · 문장별 근거 아님)AWS 공식 문서 ↗

댓글

첫 번째 댓글을 남겨보세요.