KEDA GPU Scaler 딥다이브
— GPU '하드웨어 계기판'을 직접 읽어 쿠버네티스가 vLLM·추론 파드를 0개까지 자동 증감하게 만드는 오토스케일러

pmady/keda-gpu-scaler. 쿠버네티스 기본 오토스케일러(HPA)는 CPU·메모리만 볼 수 있어 GPU가 100%로 불타는데도 "CPU 8%니 한가하네"라고 착각합니다. 이 프로젝트는 GPU 노드마다 DaemonSet을 띄워 NVIDIA의 NVML 라이브러리에서 GPU 사용률·VRAM 같은 진짜 하드웨어 지표를 직접 읽고, 그것을 KEDA 외부 스케일러(gRPC) 규격으로 KEDA에 넘겨 vLLM·Triton·학습 잡을 0개까지(scale-to-zero) 자동 증감하게 합니다. 기존 정석인 dcgm-exporter → Prometheus → PromQL → KEDA(컴포넌트 5개·지연 15~30초)를 컴포넌트 2개·지연 2~4초로 줄이는 게 핵심. (저장소: pmady/keda-gpu-scaler · 언어 Go 1.25 · go-nvml(CGO) + gRPC + Prometheus · Helm 차트·CI 포함 · Apache-2.0 · TrendShift 라이브 멘션 #62133)

1프로젝트 한줄 요약

"방 온도계(CPU)만 보던 보일러 자동조절기에, 오븐(GPU)에 직접 꽂은 온도계를 달아 준다."

좀 더 구체적으로, keda-gpu-scaler는 Go로 만든 두 개의 작은 실행파일입니다. ① keda-gpu-scaler는 GPU 노드에서 도는 gRPC 서버(KEDA가 여기에 "지금 GPU 얼마나 써?"라고 물음), ② gpu-metrics는 쿠버네티스 없이도 터미널에서 GPU 지표를 보는 CLI(SLURM·Flux·맨몸 서버까지 같은 형식으로 출력). 핵심 자랑은 "dcgm-exporter + Prometheus 파이프라인(5개 컴포넌트, 15~30초 지연)을 컴포넌트 2개·2~4초 지연으로 압축"한다는 것 — 즉 이 프로젝트의 진짜 상품은 '단순함과 짧은 지연'입니다.

이 문서가 파고드는 건 사용법만이 아니라 그 안의 설계입니다 — "왜 GPU 지원을 KEDA 본체에 못 넣고 별도 컴포넌트로 뺐나(CGO·하드웨어 접근)", "왜 Deployment가 아니라 DaemonSet인가", "KEDA 외부 스케일러 gRPC 규격(4개 함수)은 정확히 무엇을 약속하나", "scale-to-zero는 코드로 어떻게 구현되나". 쿠버네티스 오토스케일링·gRPC·GPU 시스템 프로그래밍을 처음 공부하는 사람에게 아담하지만 알찬 실전 교본입니다.

2왜 주목받는가

"GPU는 시간당 수천 원짜리 자원이다. '안 쓸 때 0개로 끄기'를 빠르고 단순하게 해 주는 게 곧 돈이다."

먼저, GPU 오토스케일링이 왜 그렇게 어려운가

vLLM·Triton 같은 GPU 추론 서버를 쿠버네티스에 올리면, 부하가 몰릴 때 파드를 늘리고 한가하면 줄이고 싶습니다. 그런데 HPA는 GPU 사용률을 볼 줄 모릅니다. 요청 200개를 처리하느라 GPU가 포화 상태여도 CPU는 8%라, HPA는 "널널하네"라며 파드를 안 늘립니다. 반대로 요청이 끊겨도 GPU 파드는 계속 켜져 있어 시간당 수천 원짜리 GPU가 놀면서 돈만 태웁니다.

"왜 KEDA 본체에 GPU 지원을 안 넣었나" — 이게 설계의 핵심

이 질문이 프로젝트 전체를 이해하는 열쇠입니다. 개발자는 세 가지 '구조적 제약' 때문에 GPU 지원을 KEDA 코어에 넣는 게 불가능하다고 설명합니다(KEDA 이슈 #7538에서 논의됨).

셀링 포인트 요약

정리하면 이 프로젝트가 주목받는 이유는 네 가지입니다. ① 단순함(Prometheus 파이프라인 제거, 3줄 ScaledObject), ② 짧은 지연(직접 NVML로 2~4초), ③ scale-to-zero(요청 없으면 GPU 파드 0개 → 비용 0), ④ 워크로드별 프로필(vllm-inference·triton-inference·training 등 검증된 기본값 5종 + 멀티 GPU 집계 max/avg/min/sum). 거기에 HPC 보너스로, 같은 코드의 gpu-metrics CLI가 쿠버네티스·SLURM·Flux·맨몸 서버에서 동일한 JSON 형식으로 GPU 지표를 뽑아 온프렘과 클라우드를 같은 도구로 비교하게 해 줍니다.

3기술 스택 전체 지도

"전부 Go 한 덩어리지만, 진짜 재미는 'Go가 C(NVML)와 손잡는 지점'과 'gRPC로 KEDA와 약속을 맺는 지점'에 있다."

keda-gpu-scaler는 화면(UI)이 없는 순수 백엔드/인프라 도구입니다. 무게중심은 "GPU에서 숫자를 읽어(NVML) → 약속된 규격으로 내보낸다(gRPC)"의 두 다리에 쏠려 있고, 나머지는 관측성·배포·테스트를 위한 견고한 살입니다.

① 코어 (GPU 읽기 + 스케일러 두뇌)

② 관측성 · 헬스 (스케일링과 '분리된' 모니터링 경로)

③ 인프라 · 빌드 · 배포

④ 보너스 — 크로스 환경 CLI (gpu-metrics)

같은 코드베이스에 gpu-metrics라는 독립 CLI가 들어 있습니다. 쿠버네티스가 전혀 없어도 베어메탈·SLURM·Flux·싱귤래리티 컨테이너에서 GPU 지표를 table/json/csv로 뽑습니다. 환경을 자동 감지(--env auto)하고, 어디서 돌든 동일한 JSON 스키마(environment 블록 포함)로 출력해 온프렘과 클라우드 GPU 성능을 jq·pandas로 손쉽게 비교하게 합니다.

4아키텍처 심화 분석 (GPU 온도가 파드 개수가 되기까지)

"GPU 하드웨어 → NVML → DaemonSet(2초 폴링) → gRPC → KEDA → HPA → 파드 개수. 한 줄로 흐른다."

전체 데이터 흐름 한 장

흐름은 일곱 단계입니다. ① DaemonSet이 NVML 폴링 루프를 시작(기본 2초) → ② 매 주기 SM 사용률·메모리·VRAM·온도·전력을 읽어 ③ 메모리에 캐시(디스크·외부 저장소 없음) → ④ KEDA가 gRPC로 GetMetrics() 호출 → ⑤ 스케일러가 ScaledObject에 적힌 집계 방식대로 값을 계산해 응답 → ⑥ KEDA가 그 값을 HPA에 먹임 → ⑦ HPA가 파드를 늘리거나 줄이거나(0개 포함) 결정. 선택적으로 :9090/metrics가 Prometheus용 게이지를 노출하지만 이건 스케일링 경로와 완전히 분리돼 있어 꺼도 무방합니다.

설계 패턴 ① — KEDA 외부 스케일러 gRPC 규격(4개 함수)

이 프로젝트의 심장은 proto/externalscaler.proto에 정의된 KEDA와의 약속입니다. KEDA가 부를 수 있는 함수는 정확히 네 개입니다.

service ExternalScaler {
    rpc IsActive(ScaledObjectRef) returns (IsActiveResponse) {}
    rpc StreamIsActive(ScaledObjectRef) returns (stream IsActiveResponse) {}
    rpc GetMetricSpec(ScaledObjectRef) returns (GetMetricSpecResponse) {}
    rpc GetMetrics(GetMetricsRequest) returns (GetMetricsResponse) {}
}
// 메타데이터는 map<string, string> 으로 전달 (ScaledObject에 쓴 설정 그대로)

설계 패턴 ② — Deployment가 아니라 DaemonSet인 이유

NVML은 /dev/nvidiactl 등 물리 노드의 장치 파일을 통해서만 GPU를 읽습니다. 중앙에 1개 뜨는 Deployment로는 다른 노드의 GPU를 볼 수 없죠. 그래서 모든 GPU 노드에 1개씩 떠야 하는 DaemonSet이 유일한 정답입니다. 매니페스트의 핵심 설정을 보면 의도가 또렷합니다.

# GPU 있는 노드에만 스케줄
nodeSelector:
  nvidia.com/gpu.present: "true"
# GPU 노드의 taint를 견뎌 쫓겨나지 않게
tolerations:
  - key: "nvidia.com/gpu"
    operator: "Exists"
    effect: "NoSchedule"
# NVML이 장치 파일에 접근하려면 권한 + hostPath 마운트 필요
securityContext:
  privileged: true
volumeMounts:
  - { name: dev-nvidiactl,  mountPath: /dev/nvidiactl }
  - { name: nvidia-driver,  mountPath: /usr/lib/x86_64-linux-gnu/libnvidia-ml.so.1 }

설계 패턴 ③ — CGO 다리와 '인터페이스로 GPU 갈아끼우기'

GPU 읽기는 C(NVML)에 의존하지만, 코드 대부분은 인터페이스 뒤에 숨겨져 있습니다. 핵심은 이 작은 약속입니다.

type MetricsCollector interface {
    CollectAll() ([]Metrics, error)        // 모든 GPU
    CollectDevice(index int) (Metrics, error) // 특정 GPU
    DeviceCount() (int, error)
    Close() error
}

실제 구현(nvml.go)은 NVML을 호출하지만, 테스트용 mock 구현(mock.go)도 같은 인터페이스를 만족합니다. 덕분에 GPU가 없는 노트북·CI에서도 단위/E2E 테스트가 전부 돌아갑니다 — 스케일러 두뇌(gRPC·집계·프로필)는 GPU 없이 검증하고, 진짜 하드웨어는 클러스터에서만 확인. 이것이 의존성 주입(DI)과 인터페이스 설계의 교과서적 활용입니다.

설계 패턴 ④ — 프로필 + 메타데이터로 설정 해석

사용자가 "raw 지표 임계값"을 직접 정하는 건 실수하기 쉽습니다("vLLM에 GPU 80%가 맞나?"). 그래서 워크로드별 프로필을 미리 만들어 뒀습니다. 스케일러는 ScaledObject의 메타데이터를 parseMetadata()로 읽어 기본값 → 프로필 → 개별 override 순서로 설정을 겹쳐 해석합니다.

멀티 GPU 노드(4~8장)에선 GPU별 값을 하나로 합쳐야 하는데, aggregation으로 max(아무 GPU나 뜨거우면 증설 — 추론 기본값)·avg(평균 — 학습)·min(보수적)·sum(총량 기반)을 고릅니다.

설계 패턴 ⑤ — 크로스 환경 통합(pkg/env): 어디서든 같은 JSON

gpu-metrics CLI는 HPC와 클라우드를 동등하게 노립니다. env.Detect()가 환경변수를 SLURM → Flux → 쿠버네티스 → 맨몸 우선순위로 검사해 자동 판별하고(예: SLURM_JOB_ID 있으면 SLURM), 스케줄러가 배정한 GPU만 골라 수집합니다. 출력은 어디서 돌든 항상 같은 스키마라 파서가 환경별로 분기할 필요가 없습니다.

{ "environment": { "orchestrator": "slurm", "node": "compute-01",
                    "job_id": "123", "task_rank": 0 },
  "collected_at": "2026-06-17T10:00:00Z",
  "devices": [ ... ] }

이 "통일된 어휘" 설계 덕에 온프렘 SLURM 클러스터와 클라우드 쿠버네티스의 GPU 성능을 동일한 도구·동일한 JSON으로 비교할 수 있습니다.

5디렉토리 구조 해부

"표준 Go 레이아웃(cmd · pkg). 작지만 '실행파일 2개 · 패키지마다 _test.go' 로 군더더기 없이 짜여 있다."

최상위 한눈에

기능별로 묶어 보기

6학습 포인트 (기술별 — 배울 것 + 실습 아이디어)

"이 한 레포 안에 쿠버네티스 오토스케일링 · gRPC · GPU 시스템 프로그래밍 · 인터페이스 설계가 다 들어 있다."

① KEDA 외부 스케일러 & gRPC 계약

배울 것: KEDA가 "아무 지표로든" 스케일링하게 해 주는 외부 스케일러의 gRPC 4함수 계약(IsActive·StreamIsActive·GetMetricSpec·GetMetrics). 특히 scale-to-zero가 IsActive라는 별도 게이트로 구현된다는 점.

실습: externalscaler.proto를 그대로 가져와, GPU 대신 "랜덤 숫자"나 "현재 분(minute)"을 지표로 돌려주는 미니 외부 스케일러를 Go로 구현하고, ScaledObject로 KEDA에 물려 파드가 늘었다 줄었다 하는지 본다.

② 쿠버네티스 HPA / 오토스케일링 내부

배울 것: HPA가 "목표값 대비 현재값"으로 파드 수를 계산하는 원리, KEDA가 그 위에서 어떻게 동작하고 scale-to-zero·cooldown·플래핑 방지(stabilization)를 어떻게 다루는지.

실습: 로컬 kind/minikube에 KEDA를 깔고, CPU 기반 ScaledObject로 부하를 줘서 파드가 0→N→0으로 변하는 과정을 kubectl get hpa,scaledobject -w로 관찰.

③ NVML · GPU 지표 · CGO

배울 것: nvidia-smi 뒤에 있는 NVML로 GPU 사용률·VRAM·온도·전력·NVLink를 읽는 법, 그리고 Go에서 C 라이브러리를 부르는 CGO의 빌드 제약(C 컴파일러·동적 링크).

실습: GPU 머신에서 go-nvml로 디바이스 개수와 각 GPU의 사용률·메모리를 출력하는 30줄짜리 프로그램 작성. nvidia-smi 값과 비교해 단위(MiB·milliwatt) 변환을 확인.

④ DaemonSet · 노드 하드웨어 접근

배울 것: 노드 단위 하드웨어를 다루는 쿠버네티스 패턴 — DaemonSet + nodeSelector + toleration + privileged + hostPath, 그리고 파드가 자기 노드/네임스페이스를 아는 Downward API(NODE_NAME·POD_NAME 주입).

실습: 모든 노드에서 호스트의 /proc/loadavg를 읽어 로그로 찍는 간단한 DaemonSet을 작성하고, hostPath 마운트와 nodeSelector를 직접 붙여 본다.

⑤ Go에서 gRPC + protobuf 실전

배울 것: .proto → 코드 생성(protoc) → 서버 구현 → 헬스체크·reflection 등록까지의 전체 흐름. grpcurl로 살아있는 gRPC 서버를 직접 찔러 보는 디버깅법.

실습: 이 레포의 서버를 mock으로 띄우고(make test-e2e 경로 참고), grpcurl -plaintext localhost:6000 externalscaler.ExternalScaler/GetMetrics로 응답을 받아 본다.

⑥ 인터페이스 기반 설계 = 테스트 가능성

배울 것: MetricsCollector 인터페이스 하나로 실물(NVML)과 모형(mock)을 갈아끼우는 의존성 주입 패턴. "GPU 없는 CI에서도 핵심 로직을 100% 테스트"하는 비결이자, 좋은 Go 설계의 정석.

실습: 내 프로젝트의 외부 의존(파일·HTTP·DB) 한 곳을 인터페이스로 추출하고, 진짜 구현과 fake 구현을 만들어 단위 테스트를 fake로 돌려 본다.

⑦ 관측성: Prometheus 계측 래퍼 · 헬스 프로브

배울 것: 컬렉터를 감싸서(decorator) 호출 수·에러·지연을 자동 기록하는 Prometheus 계측 패턴, 그리고 /healthz(liveness)·/readyz(readiness)의 의미 차이(살아있음 vs 트래픽 받을 준비됨).

실습: 임의의 함수를 감싸 "호출 횟수 카운터 + 실행시간 히스토그램"을 기록하는 래퍼를 만들고 /metrics로 노출해 본다.

7하드웨어 / 시스템 요구사항

"NVIDIA GPU + 드라이버는 필수. 대신 스케일러 자체는 노드당 ~20Mi RAM의 깃털 같은 무게다."

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

"GPU 없이 코드부터 → 클러스터에 KEDA 깔기 → ScaledObject 붙이기 → 직접 스케일러 만들기, 단계별로."

9관련 기술 심화 학습 로드맵 (6주 플랜)

"쿠버네티스 오토스케일링에서 출발해 gRPC·GPU 시스템·관측성까지, 이 레포를 길잡이 삼아."

10핵심 키워드 사전

"이 문서와 저장소에서 반복되는 용어를 한곳에 모았다."

11참고 링크

• GitHub 저장소 — github.com/pmady/keda-gpu-scaler
• README · DESIGN · BENCHMARKS — 아키텍처·gRPC 계약·프로필·벤치마크 (docs/DESIGN.md)
• TrendShift 페이지 — trendshift.io/repositories/62133
• KEDA — 외부 스케일러 개념 keda.sh/docs (external-scalers)
• KEDA 이슈 #7538 — GPU 스케일링을 외부 컴포넌트로 분리한 배경 (kedacore/keda#7538)
• NVIDIA/go-nvml — NVML Go 바인딩 github.com/NVIDIA/go-nvml
• CNCF 블로그 — "GPU Autoscaling on Kubernetes with KEDA" (cncf.io blog)
• vLLM — 대표 LLM 추론 서버 github.com/vllm-project/vllm