확정 할당량(Committed Quota) 없이 GKE에서 AI 워크로드를 실행하는 전략

모델을 구축하고, 학습 코드를 컨테이너화했으며, Google Kubernetes Engine (GKE)에서 규모를 확장할 준비가 되었습니다. nvidia-h100-80gb 노드 풀을 프로비저닝하려고 하면... QUOTA_EXCEEDED(할당량 초과) 메시지가 뜹니다.

이는 현대 AI 개발에서 가장 흔하면서도 좌절감을 주는 장애물 중 하나입니다. H100, A100, TPU와 같은 고성능 가속기(Accelerators)에 대한 수요가 엄청나기 때문에, 이에 대한 영구적인 온디맨드(On-demand) 할당량을 확보하는 것은 어려울 수 있습니다. 하지만 온디맨드 할당량이 부족하다고 해서 선택지가 없는 것은 아닙니다.

GKE는 표준 온디맨드 인스턴스를 확보할 수 없을 때, 이러한 희소 자원을 획득할 수 있는 두 가지 강력하고 비용 효율적인 전략을 제공합니다: Spot VMs와 Dynamic Workload Scheduler (DWS)입니다.

이들이 무엇인지, 각각 언제 사용해야 하는지, 그리고 어떻게 구현하는지 자세히 살펴보겠습니다.

전략 1: Spot VMs

Spot VMs는 Google Cloud의 유휴 컴퓨팅 용량을 표준 온디맨드 VM 가격보다 최대 90% 저렴하게 판매하는 서비스입니다. 중단되어도 괜찮은 워크로드에 완벽합니다.

주의할 점은 Spot VMs에 가용성 보장이 없다는 것입니다. Google Cloud는 해당 용량이 온디맨드 고객에게 필요할 경우 언제든지 이를 "선점(Preempt)"(즉, 종료)할 수 있습니다. GKE는 노드가 종료되기 전 30초의 경고 시간을 받습니다. Kubernetes는 노드가 사라지기 전, 애플리케이션을 우아하게 종료(Graceful shutdown)하기 위해 이 시간(시스템이 아닌 포드에게는 최대 15초의 정리 시간 부여)을 사용합니다.

가속기를 위해 Spot VMs를 사용해야 하는 경우

Spot VMs는 다음과 같은 워크로드에 이상적입니다:

결함 허용 및 상태 비저장 (Fault-tolerant and stateless): 노드가 사라지고 Pod가 다른 곳으로 재스케줄링(Rescheduled)되는 상황을 애플리케이션이 처리할 수 있는 경우
배치 처리 (Batch processing): 쉽게 재시작할 수 있거나 체크포인팅 (Checkpointing) 기능이 내장된 작업
CI/CD 파이프라인 (CI/CD pipelines): 100% 가동 시간 (Uptime)이 필요하지 않은 테스트 또는 빌드 실행

GKE에서 Spot VM을 사용하는 방법

GKE Standard 클러스터에 Spot VM 노드 풀 (Node pool)을 쉽게 추가할 수 있습니다. 핵심은 중요한 시스템 Pod가 아닌 워커 (Worker) 용도로 Spot VM을 사용하는 것입니다.

전용 Spot VM 노드 풀 생성:
노드 풀을 생성할 때 --spot 플래그를 추가하고, 일반 Pod가 실수로 해당 노드에 스케줄링되지 않도록 테인트 (Taint)를 적용합니다.

gcloud container node-pools create spot-gpu-pool \
  --cluster=my-cluster \
  --region=northamerica-northeast2 \
...

워크로드의 YAML에 용인 (Toleration) 추가:

# 해당 노드에서 실행하고자 하는 특정 워크로드에 대해서만 해당 테인트를 "용인(tolerate)"하도록 설정합니다.
apiVersion: apps/v1
kind: Deployment
...

이러한 아키텍처를 통해 중요한 구성 요소는 신뢰할 수 있는 온디맨드 (On-demand) 노드에 유지하면서, 중단 가능한 학습 작업은 선점 가능한 (Preemptible) Spot 노드에서 실행할 수 있습니다. (참고: GKE Autopilot을 사용하는 경우, Pod 스펙에서 Spot 클래스를 요청하기만 하면 GKE가 테인트와 노드를 자동으로 처리합니다!)

전략 2: flex-start를 활용한 동적 워크로드 스케줄러 (DWS)

만약 작업이 중단될 수 없다면 어떻게 해야 할까요? 많은 대규모 학습 작업은 며칠씩 걸릴 수 있습니다. 체크포인팅 기능이 있더라도, Spot 선점 (Preemption)으로 인해 몇 시간마다 처음부터 다시 시작하는 것은 비효율적이고 비용이 많이 듭니다.

이때 동적 워크로드 스케줄러 (Dynamic Workload Scheduler, DWS)가 필요합니다.

DWS는 배치 워크로드(batch workloads)를 위해 희소한 대량의 리소스(GPU 및 TPU와 같은)를 확보하기 위해 특별히 설계된 기능입니다. 이는 요청 방식을 "지금 당장 이 GPU를 주세요"에서 "이 GPU가 사용 가능해지면 주세요"로 변경합니다.

여기서 주의할 점은 작업이 즉시 시작되지 않는다는 것입니다. 작업은 대기열(queue)에 진입하며, 리소스가 프로비저닝(provisioned)될 때까지 몇 분, 몇 시간, 또는 심지어 며칠 동안 기다려야 할 수도 있습니다.

몇 가지 엄청난 장점이 있습니다:

"줄 서기" 시스템입니다: 5분마다 gcloud 명령어를 재시도하는 스크립트를 직접 작성하는 대신, DWS는 요청을 대기열에 넣고 용량(capacity)이 확보되면 자동으로 노드를 프로비저닝합니다.
선점(preemptions)이 없습니다: DWS 노드가 프로비저닝되면, 작업이 지속되는 전체 기간(최대 7일) 동안 해당 노드는 사용자의 것이 됩니다. 이는 스팟 VM(Spot VMs)이 아니며 선점되지 않습니다.
비용 절감: DWS 워크로드는 온디맨드 인스턴스(on-demand instances)와 비교하여 상당한 할인 혜택(L4 GPU의 경우 최대 53%)이 제공됩니다.

DWS를 사용해야 하는 경우

DWS는 다음과 같은 경우에 완벽합니다:

모델 학습 또는 강화학습 (RL): 수 시간 또는 수일 동안 중단 없이 실행되어야 하는 작업.
배치 추론 (Batch inference): 대규모 데이터셋에 대해 대량의 추론 작업을 실행하는 경우.
"시작" 시점에는 시간에 민감하지 않지만, "중단"에는 민감한 모든 워크로드.

flex-start와 함께 DWS를 사용하는 방법

DWS의 flex-start 모드는 이러한 "대기열 대기" 동작을 가능하게 하는 핵심입니다. GKE Autopilot 클러스터(또는 노드 자동 프로비저닝(Node Auto-provisioning)이 활성화된 Standard 클러스터)를 사용하는 경우, 이를 구현하는 방법은 매우 간단합니다.

복잡한 커스텀 리소스(custom resources)를 생성할 필요가 없습니다. 표준 Kubernetes Job 객체의 nodeSelector를 통해 의도(intent)를 전달하기만 하면 됩니다.

Job에서 flex-start 요청:
Job.yaml 파일의 가속기(accelerator) 요청과 함께 cloud.google.com/gke-flex-start: "true" 노드 선택기(node selector)를 추가합니다.

apiVersion: batch/v1
kind: Job
metadata:
...

이 Job을 적용하면, GKE는 flex-start 선택기(selector)를 인식합니다. DWS 대기열 시스템(queueing system)이 요청된 A100 노드를 프로비저닝(provision)할 수 있을 때까지 Job의 Pod들은 대기(Pending) 상태로 유지됩니다. 노드가 준비되면 Pod가 스케줄링(scheduled)되고, 작업은 중단 없이 완료되며, 노드는 자동으로 프로비저닝 해제(deprovisioned)됩니다.

어떤 전략을 선택해야 할까요?

다음은 간단한 요약표(cheat sheet)입니다:

기능	Spot VMs	flex-start를 사용하는 DWS
최적의 용도	결함 허용(Fault-tolerant)이 가능하고 중단 가능한 워크로드	장시간 실행되며 중단되지 않아야 하는 배치 작업 (batch jobs)
...

Spot VM과 Dynamic Workload Scheduler(DWS)를 모두 숙달하면, 온디맨드(on-demand) 가속기 할당량을 찾기 어려운 상황에서도 GKE 상에서 탄력적이고 비용 효율적인 AI 플랫폼을 구축할 수 있습니다.