토스증권이 GPU-aware를 넘어 GPU-native 클러스터를 구축한 방법
Summary
노드만 Ready면 끝? 토스증권이 밝히는 진정한 'GPU-native' 클러스터 구축기
쿠버네티스 환경에서 간헐적인 GPU 오류를 잡아내고 안정적으로 AI 서비스를 운영하기 위한 인프라 생존법
토스증권 데이터 인프라 팀이 GPU를 단순히 쿠버네티스 자원으로 할당하는 것을 넘어, 하드웨어 결함 검증 및 효율적 분배가 가능한 'GPU-native' 인프라를 구축한 과정을 소개합니다. 시스템 메모리와 달리 cgroup 제어를 벗어나는 GPU VRAM 관리의 근본적인 문제점과 이를 보완하기 위해 노출시킨 검증 메커니즘을 상세히 다룹니다.
- 01NVIDIA 커널 드라이버부터 Container Toolkit, Device Plugin으로 이어지는 GPU-aware 구성 4단계 정립
- 02쿠버네티스 cgroup 한계로 인한 GPU VRAM 직접 제어의 한계 및 CUDA OOM 진단 난이도 지적
- 03노드 정상(Node Ready) 상태가 실제 개별 GPU의 완벽한 동작(GPU Ready)을 보장하지 못하는 모순 해결
- 04nvidia-validator를 통한 드라이버, 툴킷, 디바이스 플러그인의 결함 및 연산 상태 조기 사전 검증
- 05동작 중인 H100 GPU에서 유발될 수 있는 nvml unknown error 검출 사례 제시
RECOMMENDATION
쿠버네티스 환경에서 대규모 AI 모델 서빙을 안정적으로 격리 운영해야 하거나, 인프라 상의 원인 모를 GPU 에러로 시스템 가동률이 저하되는 인프라 및 DevOps 엔지니어에게 적극 추천합니다.
The Problem
토스증권은 AI 서비스를 위해 기존 쿠버네티스 클러스터에 GPU 워크로드를 실행하고자 했으나, 단순히 GPU를 인식시키는 단계(GPU-aware)만으로는 개별 GPU 오류 대응이나 물리 GPU 단위 할당의 비효율성 등 실무적인 운영 한계를 극복하기 어려웠습니다.
The Solution
GPU의 세부 작동 상태를 독립적으로 검증하고 서비스 크기에 따라 세밀하게 자원을 나누는 'GPU-native' 상태로 진화하기 위해, 별도의 GPU Ready 검증 절차를 수립하고 nvidia-validator 및 dcgm-exporter 기반의 사전 검증 스택을 도입했습니다.
The Result
노드 활성화 상태와 무관하게 개별 GPU 스택의 실제 정상 작동 상태를 가려낼 수 있게 되었으며, 멀티테넌트 환경에서 AI 워크로드를 안정적이고 정밀하게 스케줄링할 수 있는 운영 기반을 다졌습니다.
Trade-off
별도의 검증 도구 및 정밀 상태 수집 시스템을 관리해야 하므로 플랫폼 관리 포인트가 늘어났으며, 하드웨어 제조사 스택의 신규 버전 및 쿠버네티스 최신 명세(DRA 등) 변화에 맞춰 시스템을 지속적으로 보완해야 하는 오버헤드가 수반됩니다.
Key Concepts
More from 토스
View all posts from 토스
사용자를 위해 일부러 어렵게 만드는 경험, 어디까지 괜찮을까?
UX DesignFriction UXBehavioral Design2일 전
리더보드 1등 LLM, 토스에서도 1등일까? - Toss Benchmark 구축기
LLM BenchmarkModel EvaluationNLP3일 전
App Router의 장점은 우리에게도 장점일까요?
Next.jsApp RouterReact Server Components1주 전
AI가 팀 규칙을 지키도록 하는 방법
LLMCoding AgentContext Window1주 전
2. Beyond Our Expertise
Technical WritingSingle Source of TruthGenerative AI1주 전
Related reads#Kubernetes
Explore #Kubernetes
장애 Alert의 원인을 스스로 찾다: SRE Observer 개발기
AI에게 만드는 법 대신 실패하는 법을 묻다: 포토그래퍼의 수천 명 동시 접속 게임 만들기
EKS 컨테이너 메모리 스파이크 추적기
SRE 업무에 AI 녹여내기 — 1편: Smart RI Calc로 인프라 비용 산정 자동화
