🚀 Wave Autoscale 3.2.0: GPU 인지형 오토스케일링과 OpenShift 지원

Author: Hwansoo Kim (opens in a new tab)
Date: 2026년 4월 29일

TL;DR: Wave Autoscale 3.2.0은 3.x 시리즈에서 남아 있던 두 가지 비용·범위 격차를 메웁니다. GPU 워크로드는 이제 NVIDIA DCGM (opens in a new tab) 메트릭 수집, 비용 추적, 낭비 감지, Web Console의 GPU 전용 뷰까지 완전한 최적화 스택을 갖추게 됩니다. 그리고 OpenShift는 이제 풀(first-class) 배포 대상입니다. DeploymentConfig가 Kubernetes Deployment, Argo Rollouts와 함께 인식되는 워크로드 타입으로 추가되며, Helm 차트는 Red Hat 인증 파이프라인을 통해 배포됩니다.

🛤️ 워크로드와 노드를 넘어 GPU와 OpenShift로

Wave Autoscale 3.0은 워크로드 레벨 인텔리전스를 제공했습니다. ML 기반 오토스케일링을 위한 Autopilot, 자동 라이트사이징을 위한 Smart Sizing, 스토리지 최적화를 위한 PV 관리가 그 결과였습니다. Wave Autoscale 3.1은 그 인텔리전스를 노드 계층까지 확장해 Amazon EKS의 Karpenter (opens in a new tab)를 제어할 수 있게 했습니다.

저희가 가장 자주 만나는 고객들에게 두 가지 격차가 남아 있었습니다.

첫 번째는 GPU입니다. GPU 인스턴스는 일반적인 AI 중심 클러스터에서 가장 비싼 항목이자, 가장 자주 과다 할당되는 자원이기도 합니다. 표준 Kubernetes 메트릭(CPU, 메모리, pod 수)으로는 GPU 사용률에 대해 아무것도 알 수 없습니다. 학습과 추론 워크로드를 운영하는 팀들은 매월 청구서에서 가장 큰 비중을 차지하는 항목에 대해 사실상 눈을 감고 있는 상태였습니다.

두 번째는 OpenShift입니다. Wave Autoscale의 엔터프라이즈 고객 다수는 규제 환경이나 온프레미스에서 Red Hat OpenShift (opens in a new tab)를 운영합니다. OpenShift의 DeploymentConfig는 Deployment, Rollout과 함께 풀(first-class) 워크로드 객체이지만, Wave Autoscale은 후자의 두 가지만 인식하고 있었습니다. 그래서 DC 기반 서비스는 Autopilot과 Smart Sizing의 시야 밖에 있었고, 정작 그 기능이 가장 필요한 워크로드들이 사각지대에 놓여 있었습니다.

Wave Autoscale 3.2.0은 이 두 가지 격차를 모두 해소합니다.

🎯 GPU 인지형 오토스케일링: 비용 사각지대를 메우다

GPU는 비용 최적화 관점에서 CPU와 다른 특성을 갖습니다. CPU 사용률은 단일한 의미를 갖는 하나의 숫자입니다. 반면 GPU 사용률은 적어도 세 가지 숫자(SM(스트리밍 멀티프로세서) 활동률, 메모리 사용률, 메모리 대역폭)이며, 이들은 서로 함께 움직이지 않습니다. 한 pod가 80GB의 GPU 메모리를 점유한 채 거의 연산을 하지 않을 수도 있고, 메모리 일부만 쓰면서 SM 활동률 100%를 태울 수도 있습니다. 표준 클러스터 모니터링은 둘 다 보여주지 않습니다.

NVIDIA의 해법은 Data Center GPU Manager (DCGM) exporter (opens in a new tab)입니다. 드라이버에서 직접 GPU별 메트릭을 가져오는 Prometheus 스타일 수집기죠. 많은 플랫폼 팀이 이미 들어봤거나 Prometheus로 스크래핑하고 있습니다. 어려운 부분은 메트릭을 모으는 것이 아니라, 그 메트릭을 오토스케일링·사이징·FinOps 의사결정으로 바꾸는 것입니다.

Wave Autoscale 3.2.0이 제공하는 것:

• Wave Agent의 DCGM 수집. Agent는 이제 기존 CPU/메모리/네트워크 메트릭과 함께 DCGM exporter 엔드포인트를 스크래핑하고, 동일한 경로로 내부 분석 저장소에 기록합니다.
• GPU 비용 추적 태스크. 모든 GPU 연결 pod는 노드 인스턴스 타입과 온디맨드/스팟 가격에 매핑되어, 워크로드별·네임스페이스별·클러스터별 GPU 비용 뷰로 집계됩니다.
• 낭비 감지. 스케줄링된 태스크가 할당은 됐지만 유휴 상태인 GPU를 표시합니다. 즉, A100이나 H100을 통째로 점유한 채 설정된 윈도 동안 SM 활동률이 임계치를 밑도는 pod를 잡아내는 것입니다. GPU FinOps에서 가장 실행 가능한 단일 신호입니다.
• Web Console의 GPU 리소스. 콘솔의 새 뷰는 노드별 GPU 인벤토리, pod별 GPU 사용량, 낭비 감지 결과를 보여주며, 기반이 되는 DCGM 시계열까지 드릴다운할 수 있습니다.

GPU 스택은 Wave Autoscale의 다른 영역과 동일한 기본 요소 위에서 동작합니다. Agent가 수집하고, 분석 계층이 저장하며, 태스크가 원시 메트릭을 추천으로 변환합니다. DCGM exporter가 이미 동작 중이라면 업그레이드 후 자동으로 인식됩니다.

🟥 OpenShift 지원: 사용자가 실제로 운영하는 환경에 닿다

Red Hat OpenShift는 규제 산업과 온프레미스 배포에서 가장 점유율이 높은 Kubernetes 배포판입니다. OpenShift 고유의 워크로드 객체인 DeploymentConfig(DC)는 Deployment보다 먼저 등장했으며, Red Hat이 OCP 4.14에서 deprecated 처리 (opens in a new tab)하고 마이그레이션을 권고했음에도 여전히 프로덕션에서 광범위하게 사용되고 있습니다. 그 마이그레이션이 보편화되기 전까지는(현재로서는 그렇지 않습니다) DC를 지원하는 것이 OpenShift 환경의 기본 조건입니다.

DC는 단순히 "이름만 다른 Deployment"가 아닙니다. 라이프사이클 모델 자체가 다릅니다.

가장 까다로운 부분은 deployer pod입니다. 새 revision이 만들어질 때마다 <dc>-<revision>-deploy라는 이름의 일회성 pod가 생성되어 롤아웃을 조율하고, 끝나면 Completed (0/1) 상태로 종료됩니다. 단순한 워크로드 추적 관점에서는 이런 pod들이 실제 워크로드 pod인데 계속 죽는 것처럼 보입니다. 사실은 워크로드가 아니라 롤아웃 도구입니다. 이를 워크로드로 잘못 다루면 사용률 데이터가 왜곡되고 Smart Sizing이 혼란을 겪게 됩니다.

Wave Autoscale 3.2.0이 다루는 부분:

• DeploymentConfig를 풀(first-class) 워크로드 타입으로 인식. Kubernetes Deployment, Argo Rollouts와 함께 deployment 목록과 상세 뷰에 표시됩니다.
• Deployer pod 필터링. *-deploy pod는 openshift.io/deployer-pod-for.name 라벨과 이름 패턴으로 식별되어, 사용률 집계 및 Pod Placement 뷰에서 제외됩니다.
• Autopilot과 Smart Sizing 연동. DC 워크로드도 다른 워크로드 타입과 동일한 오토스케일링 및 라이트사이징 추천 흐름을 통해 처리됩니다.
• S3에 게시되는 Red Hat 인증 Helm 차트. OpenShift용 Helm 차트는 이제 GitHub Actions 파이프라인 (opens in a new tab)을 통해 Red Hat 차트 인증을 통과한 뒤 S3로 업로드되며, 빌드는 deprecated된 offline-token 방식 대신 service account를 사용해 Red Hat Hybrid Cloud Console에 인증합니다.

EKS, ROSA, 온프레미스 OpenShift가 혼재된 플랫폼이라면, 이제 하나의 Wave Autoscale 컨트롤 플레인에서 모두 관리할 수 있습니다.

📐 Smart Sizing: 두 가지 모드를 명확하게

Smart Sizing은 Wave Autoscale 3.0부터 제품에 포함된 기능이지만, 동작 방식이 콘솔에서 항상 명확하게 드러나지는 않았습니다. 처음에는 보통 scale out 하지 않는 워크로드인 StatefulSet과 DaemonSet을 대상으로 했고, 이후 HPA나 Wave Autopilot이 없는 Deployment까지 확장됐습니다. Autopilot이 동작하는 Deployment에는 가로 스케일링이 함께 작동하기 때문에 사이징 계산식이 달라지는 두 번째 경로도 추가했습니다.

3.2.0의 Web Console은 이 두 가지 운영 모드를 명시적으로 보여줍니다.

• Static Smart Sizing: scale 하지 않거나 Autopilot을 쓰지 않는 워크로드용. 관측된 과거 사용량(P99 부근)과 안전 마진을 기반으로 추천을 계산합니다.
• Autopilot Smart Sizing: Autopilot이 가로 스케일링을 담당하는 워크로드용. 원시 수요가 아니라 replica당 정상 상태(steady-state)를 기준으로 추천을 계산해, 두 시스템이 올바르게 결합되도록 합니다.

두 모드 모두 동일한 recommendations 표면에 결과를 기록하지만, 콘솔에서는 어느 경로가 어떤 추천을 만들어냈는지 라벨로 표시됩니다. 디버깅과 신뢰성 측면에서 유용합니다.

📈 예측(Forecast)과 Wave Agent 업데이트

작지만 운영적으로 의미 있는 두 가지 변경입니다.

• Forecast 호라이즌 기본값을 30일에서 7일로 단축. 30일 호라이즌은 예측 모델이 새로 도입됐을 때 보수적으로 설정한 값이었습니다. 실무에서는 팀이 실제로 행동에 옮기는 것은 7일 예측이며, 더 긴 호라이즌은 무시되는 노이즈를 만들어내고 있었습니다. WA_CLUSTER_STATUS_FORECAST_HORIZON_DAYS 환경 변수로 여전히 재정의할 수 있습니다.
• Wave Agent 텔레메트리 개선. 3.1.0의 gRPC 파이프라인 작업에 이어, 3.2.0은 Agent 내부 태스크 스케줄러의 안정성과 관측성을 점진적으로 개선합니다.

🔭 다음에 다룰 것

3.2.0은 3.x 시리즈에서 진행해 온 플랫폼 범위 확장 작업의 마무리 지점입니다. GPU와 OpenShift가 풀(first-class)로 들어온 만큼, 초점은 다시 깊이로 옮겨갑니다. 이제 더 넓어진 워크로드 영역에 대해 Autopilot과 Smart Sizing의 추천 품질을 끌어올리고, GPU와 스토리지 낭비 감지를 더 날카롭게 다듬으며, 관측된 결과와 추천 사이의 피드백 루프를 더 촘촘히 연결할 계획입니다.

GPU를 프로덕션에서 운영하면서 워크로드별 사용률과 비용 가시성이 부족한 상황이거나, OpenShift 워크로드를 기존 오토스케일링 스택 밖에 두고 있다면, 3.2.0 업그레이드가 적기입니다. 환경에 어떤 변화가 있을지 함께 살펴보고 싶다면 문의 (opens in a new tab)해 주세요.