길리랩blog

클라우드 ML 워크로드 자동 확장과 비용 최적화

클라우드 ML의 온라인·배치 추론과 분산 학습에 맞춘 자동 확장 정책, 비용 제어 레버, 운영 설계 원칙을 정리한다.

2026-08-14 · 최초 발행 2024-04-29

수요 변화가 큰 ML 워크로드를 다루는 방식

클라우드 ML 워크로드는 지연과 처리량 같은 SLO를 지켜야 하는 동시에, 가속기와 인프라 비용을 통제해야 한다. 자동 확장은 수요와 SLO에 맞춰 리소스를 늘리거나 줄이는 메커니즘이며, 수평 확장(Replica), 수직 확장(리소스 증감), 큐 길이·동시성에 반응하는 이벤트 기반 확장, Scale-to-Zero를 포함한다.

비용 최적화는 성능과 가용성을 유지한 상태에서 총소유비용(TCO)을 낮추는 접근이다. 인스턴스와 가속기 선택, 예약·스팟 조합, 스토리지와 네트워크 비용 통제, 관측·예산·태그 기반 거버넌스가 여기에 속한다.

워크로드는 보통 다음 성격으로 나뉜다.

  • 온라인 추론: 실시간 SLO를 가진다.
  • 배치 추론: 예약 실행 또는 이벤트에 따라 동작한다.
  • 분산 학습: 실행 시간이 길고 고가속기를 사용한다.
  • 데이터 전처리·특징 생성: burst성 I/O가 발생한다.

워크로드마다 다른 확장 신호와 정책

온라인 추론은 RPS, p95 지연, 동시성을 기준으로 HPA 또는 KEDA를 적용할 수 있다. 동적 배칭, 모델 캐시, 멀티모델 서빙도 함께 활용한다.

배치 추론에는 큐 길이와 크론 스케줄을 확장 신호로 쓰기 적합하다. 유휴 상태에서는 Scale-to-Zero로 비용을 제거할 수 있다.

분산 학습은 스팟·프리엠티블 기반의 탄력 확장과 체크포인팅, Elastic Training을 조합해 중단 내성을 확보한다.

정책의 입력에는 애플리케이션 레이턴시, GPU·CPU·메모리·NIC 사용률, 큐 길이, 오류율, 동시 세션 수가 들어간다. 정책 엔진은 히스테리시스, 쿨다운, 최대·최소 레플리카, 승수형 또는 점증형 증설 방식을 다뤄야 한다. SLO 위반 시 우선순위를 높이고, 비용 초과 시 축소나 오프로딩을 트리거하는 식으로 출력 정책을 구성한다.

Kubernetes HPA/VPA/Cluster Autoscaler, KEDA, SageMaker·Vertex 등의 서버리스 엔드포인트가 이 제어 루프를 구성한다. GPU 스케줄러, MIG, 멀티-GPU, 파드 안티어피니티는 자원 파편화를 줄이는 데 쓰인다. Canary와 AB 트래픽 가중치에 오토스케일링을 연동하면 증설과 축소의 배포 위험도 낮출 수 있다.

자동 확장 제어 루프

⤢✕확장 필요수평수직노드정상SLO 위반오류/비용 초과입력 메트릭RPS, p95 Latency, GPU Util,Queue Length, Error Rate정책 엔진SLO/비용 한도, 히스테리시스,쿨다운확장 유형 결정HPA/KEDAReplica 조정VPA리소스 증감Cluster Autoscaler노드 증감스케줄러GPU/MIG 배치실행 파드/엔드포인트서빙/학습관측/피드백SLO 충족 여부완화 조치Rate-limit, 동적 배칭↑,Scale-to-Zero, 롤백

확장 메커니즘별 운영 특성

메커니즘 성능 확장성 일관성 안정성 운영 편의
HPA(메트릭 기반 수평) 지연·RPS 대응 우수 매우 높음 트래픽 변동에 일관 응답 쿨다운 필요 구성 간단
VPA(수직) 싱글 파드 성능 향상 제한적 워밍 필요 재시작 리스크 튜닝 난도 중간
KEDA(이벤트 기반) 큐 기반 처리량 최적 매우 높음 백프레셔와 궁합 좋음 소스 의존성 다소 복잡
서버리스 엔드포인트 콜드스타트 영향 탄력 매우 높음 무상태 설계 필요 관리형 안정성 운영 편의 매우 높음

실시간·학습·배치 환경의 정책 적용

실시간 추론 API의 SLO 관리

p95 100ms SLO를 지키려면 레이턴시와 동시성 지표를 노출하고, HPA 목표를 p95=100ms와 동시성=50으로 설정할 수 있다. KEDA에는 큐 길이를 연동하고, 동적 배칭과 모델 캐시를 적용한다.

p95가 초과되면 Replica를 2배 증설하고, 2분 쿨다운 뒤 점증적으로 축소한다. 야간에는 Scale-to-One으로 운영하며, 한계 비용을 넘으면 동적 배칭을 강제 적용한다. 오류율이 5%를 초과하면 새 빌드를 롤백하고 Rate-limit로 스파이크를 평탄화한다.

체크포인팅을 전제로 한 분산 학습

대규모 학습에서는 5분 간격 체크포인트, 데이터셋 캐시, Elastic Distributed Data Parallel 구성을 사용한다. 노드가 선점되면 작업을 재개하고, 스팟 가용성이 낮아지면 예약 인스턴스로 자동 폴백한다.

스팟 할인은 50~80%를 기대할 수 있지만, 중단에 따른 재시작 오버헤드가 따른다.

이벤트에 반응하는 배치 추론

메시지 큐에 작업을 적재한 뒤, KEDA가 큐 길이>100일 때 0→20으로 확장하도록 구성할 수 있다. 처리가 끝나면 다시 0으로 축소한다.

단가($/1k 요청)를 기준으로 비용 한도를 적용하고 워밍 풀을 최소화하면 유휴 비용을 줄일 수 있다. 실패한 작업은 D/L 큐로 옮기고 재처리 스케줄을 통해 일관성을 확보한다.

KEDA로 Kafka 소비량에 맞춰 배치 추론 확장하기

전제: Kubernetes 1.26+, KEDA v2.11+, Metrics Server 설치, Kafka 접근 가능.

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: batch-infer-scaledobject
spec:
  scaleTargetRef:
    name: batch-infer-deploy
  minReplicaCount: 0
  maxReplicaCount: 50
  cooldownPeriod: 120
  triggers:
    - type: kafka
      metadata:
        bootstrapServers: kafka:9092
        topic: infer-jobs
        consumerGroup: infer-group
        lagThreshold: "1000"

SageMaker 엔드포인트 동시성 기반 정책

전제: AWS CLI v2, IAM 권한, 엔드포인트명 존재.

aws application-autoscaling register-scalable-target \
  --service-namespace sagemaker \
  --resource-id endpoint/my-endpoint/variant/AllTraffic \
  --scalable-dimension sagemaker:variant:DesiredInstanceCount \
  --min-capacity 1 --max-capacity 20

aws application-autoscaling put-scaling-policy \
  --service-namespace sagemaker \
  --resource-id endpoint/my-endpoint/variant/AllTraffic \
  --scalable-dimension sagemaker:variant:DesiredInstanceCount \
  --policy-name target-concurrency \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration '{
    "TargetValue": 60.0,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "SageMakerVariantInvocationsPerInstance"
    },
    "ScaleInCooldown": 120,
    "ScaleOutCooldown": 60
  }'

가정한 구성에서의 비용 변화

기준 구성은 가속기 1개를 탑재한 g5.xlarge 10대를 상시 가동하고, 온디맨드 $0.9/h와 월 720h를 적용한 경우다. 월 비용은 10 × 0.9 × 720 = $6,480이다. 트래픽은 피크 30%, 오프피크 70%이며 유휴율이 높다고 가정한다.

개선안은 피크 시간대 평균 6대를 사용하고, 오프피크에는 Scale-to-Zero를 적용한다. 스팟 60% 할인과 체크포인팅을 통한 중단 허용도 전제한다.

  1. 피크 시간은 30% × 720h = 216h이며, 6대 × $0.36/h(스팟 단가 가정) = $466.56이다.
  2. 오프피크는 504h이고 Scale-to-Zero로 0대를 가정하므로 $0이다.
  3. 월 총액은 ≈ $466.56이며, 기준 대비 절감율 = (6480 - 466.56) / 6480 ≈ 92.8%이다.

스팟 가용성, 워밍·재시작 오버헤드, 데이터 이그레스·스토리지 비용을 포함하면 실제 절감율은 하락할 수 있다(최신 정보 확인 필요).

비용과 성능 사이에서 확인할 조건

동적 배칭은 비용과 효율을 개선할 수 있지만 p95 지연을 악화시킬 수 있다. 지연 상한과 모범 배치 크기를 탐색해야 한다.

Scale-to-Zero는 유휴 비용을 제거하는 대신 콜드스타트와 모델 로드 지연을 만든다. 워밍 풀과 모델 캐싱 설계가 필요하다.

스팟·프리엠티블은 큰 할인을 제공하지만 중단 리스크가 있다. 체크포인팅 주기, Idempotent 파이프라인, 폴백 정책을 함께 마련해야 한다.

수직 확장은 간편하지만 상한과 재시작 비용이 있고, 수평 확장은 탄력성이 높지만 상태 관리와 세션 스티키가 필요하다. 데이터 비용에서는 크로스 리전 이그레스와 스토리지 등급 전환 지연 비용을 고려하고, 로컬 캐시와 동일 리전 배치를 검토한다.

운영 전 확인할 항목

  • RPS·p95·동시성·오류율·GPU Util을 메트릭과 SLO로 명문화한다.
  • 목표치, 쿨다운, 히스테리시스, min/max 레플리카를 정책 파라미터로 정한다.
  • 태그·라벨, 예산 알림, 단위 비용 KPI, RI·스팟 조합 계획을 비용 거버넌스에 포함한다.
  • 체크포인팅, 재시도·D/L 큐, 폴백 인스턴스, 멀티AZ로 복원력을 마련한다.
  • 카나리 롤아웃, 부하 테스트, 비용·SLO 시뮬레이션으로 정책을 검증한다.

클라우드 ML은 수요 변동성과 높은 비용을 동시에 관리해야 한다. SLO·메트릭 기반 자동 확장에 스팟, Right-sizing, Scale-to-Zero를 결합하면 성능과 비용을 함께 조정할 수 있다. 작은 단위의 정책 실험과 FinOps 루프를 통해 개선을 반복하는 운영 체계가 필요하다.

클라우드 ML자동 확장비용 최적화KEDAMLOps