KEDA GPU Scaler — 노드 지표와 추론 엔진 지표를 KEDA에 연결하기

분석 기준: 58e20ff8f0277dc301b3bb88d93ea24de0ee2b4f. 공식 저장소의 문서·설정·소스를 대조했습니다. 이 글의 설치·실습 명령은 독자를 위한 예시이며, 분석 중 프로젝트 설치·빌드·모델 호출은 실행하지 않았습니다.

1프로젝트 한줄 요약

NVIDIA GPU 지표를 NVML에서 읽고 KEDA의 ExternalScaler gRPC 계약으로 전달하는 Go 서버입니다. GPU 노드별 DaemonSet이 하드웨어를 읽고, 중앙 KEDA가 워크로드 파드 수를 조절합니다. vLLM·Triton의 자체 지표를 읽는 별도 경로와 GPU 상태를 확인하는 gpu-metrics CLI도 있습니다.

파드를 0개로 줄이는 기능과 GPU 노드 자체의 종료·클라우드 비용 제거는 다릅니다. 장비 과금까지 자동으로 0이 된다고 해석할 수 없습니다.

2왜 주목받는가

DCGM exporter와 PromQL을 거치지 않고 NVML 값을 외부 스케일러로 연결하는 구성이 특징입니다. 반응 시간은 수집·KEDA 폴링 설정과 실제 환경에 따라 달라지므로 고정 2~4초로 보장하지 않습니다. HPA 자체는 외부 지표도 사용할 수 있지만 NVIDIA 지표를 기본으로 수집해 주지는 않습니다.

현재 README는 노드별 로컬 지표만 보고하며 클러스터 전체 집계는 미구현이라고 명시합니다. 여러 노드에서 서비스가 돌 때 ClusterIP가 서로 다른 DaemonSet 파드로 요청을 보내는 상황을 고려해야 합니다. 노드별 ScaledObject·노드 선택 전략을 검토하는 것이 먼저입니다.

3기술 스택 전체 지도

스케일링을 위해 Prometheus 서버가 필수인 구조는 아닙니다. 다만 vLLM·Triton 지표는 해당 엔진의 metrics endpoint가 별도로 필요합니다.

4아키텍처 심화 분석

GPU node: NVML → MetricsCollector → GPUExternalScaler
                                    ↑ vLLM /metrics
                                    ↑ Triton /metrics
KEDA ← gRPC: IsActive / StreamIsActive / GetMetricSpec / GetMetrics
  ↓
HPA·대상 워크로드의 replica 조절

IsActive는 지표가 activationThreshold보다 큰지 판단합니다. GetMetricSpec은 목표값을, GetMetrics는 실제 측정값을 제공합니다. StreamIsActive는 설정된 주기로 값을 읽되 수집 오류를 활성 신호로 바꾸지 않고 로그 후 다음 주기를 기다립니다.

// pkg/scaler/server.go 발췌
active := value > cfg.activationThreshold
value = s.applyCooldown(key, value, time.Duration(cfg.cooldownSeconds)*time.Second)

축소 억제 상태 키는 ScaledObject의 namespace·name뿐 아니라 지표명·종류·집계·GPU index·엔진 endpoint도 포함합니다. 한 객체의 여러 트리거가 다른 단위의 값을 같은 기준선으로 공유하지 않기 위한 설계입니다. 프로필 구조체에 있는 모든 안정화 필드가 KEDA 설정에 자동 반영된다고 가정하지 말고 실제 parseMetadata와 배포 YAML을 구분합니다.

MIG와 엔진 지표의 경계

pkg/gpu/mig.go는 MIG 인스턴스별 UUID·메모리·지원되는 사용률을 읽습니다. 온도·전력·PCIe·NVLink는 물리 GPU에서 읽어 각 인스턴스에 복사하므로 인스턴스 합계로 다시 더하면 중복될 수 있습니다. Triton의 요청률·대기시간은 누적 카운터 차분이므로 같은 endpoint를 두 번 이상 관측해야 의미 있는 값이 나옵니다.

5디렉토리 구조 해부

cmd/                 scaler·gpu-metrics 진입점
pkg/gpu/             NVML·MIG·mock collector
pkg/scaler/server.go gRPC·metadata 해석·cooldown
pkg/profiles/        지표 종류와 워크로드 프로필
pkg/vllm/            vLLM metrics client
pkg/triton/          Triton counters client
proto/               gRPC 계약
deploy/              manifests·Helm·예시
pkg/slurm/, flux/    HPC 환경 연동

읽는 순서는 proto → server → MetricsCollector 인터페이스 → NVML 구현이 좋습니다. 하드웨어 의존과 스케일 정책을 나누어 mock으로 검증하는 지점을 찾을 수 있습니다.

6학습 포인트

• 인터페이스 설계: MetricsCollector를 mock과 실제 NVML 구현으로 바꾸며 서버 로직과 장치 접근을 분리합니다.
• 단위 관리: MiB·퍼센트·초당 요청·밀리초가 섞이지 않도록 MetricType과 목표값을 함께 추적합니다.
• 상태 분리: 여러 트리거의 cooldown 키가 왜 endpoint까지 포함하는지 예제로 설명해 봅니다.
• 분산 관측: 노드 안 여러 GPU의 max/avg/min/sum 집계와 클러스터 여러 노드 집계는 다른 문제입니다.

7하드웨어·시스템 요구사항과 설치

GPU 실행에는 NVIDIA 드라이버·Device Plugin이 있는 Kubernetes 노드와 KEDA 2.10+가 필요합니다. 소스 빌드는 go.mod의 Go 1.26.0과 CGO 도구체인을 확인합니다. Helm 기본값은 NVIDIA GPU Operator가 제공하는 노드 라벨과 nvidia RuntimeClass를 전제로 합니다. Operator가 없다면 노드 라벨·runtimeClassName·NVML host mount 설정을 별도로 맞춰야 합니다.

# 독자의 시험 클러스터에서 선택할 예시
helm install keda-gpu-scaler deploy/helm/keda-gpu-scaler --namespace keda

CPU·RAM 소모와 지연 수치를 이 분석에서 측정하지 않았습니다. NVML 장치 접근 권한과 매니페스트를 검토하고, 엔진 endpoint의 네트워크 접근성과 인증 조건을 확인합니다.

8직접 해볼 수 있는 실습 과제

1. 기초: proto의 4개 메서드를 server.go와 대응시키고 활성 임계값·목표값의 차이를 표로 만듭니다.
2. 중급: mock 입력을 사용해 지표 0·임계값과 동일·초과·수집 오류가 서로 구분되는지 기존 테스트를 읽습니다.
3. 중급: 자신의 시험 클러스터에서 아래 vLLM 트리거를 검토하고 endpoint의 실제 지표 이름과 수집 주기를 확인합니다.
4. 심화: MIG 사용률과 물리 전력의 집계가 다른 이유를 검증하고, 다중 노드에서 각 요청이 어느 노드를 읽는지 추적합니다.

triggers:
  - type: external
    metadata:
      scalerAddress: "keda-gpu-scaler.keda.svc.cluster.local:6000"
      profile: "vllm-queue-depth"
      vllmEndpoint: "http://vllm-svc:8000/metrics"

코드의 프로필 기본값은 queue depth 목표 5·활성값 1입니다. 예시는 부하·복구·scale-from-zero 경로를 포함한 운영 검증을 대신하지 않습니다.

9관련 기술 심화 학습 로드맵

10핵심 키워드 사전

11참고 링크

• README.md
• go.mod
• pkg/scaler/server.go
• pkg/gpu/mig.go
• pkg/profiles/profiles.go