쿠버네티스 GPU 인식을 넘어 운영 신뢰성으로: 토스증권의 클러스터 고도화와 업스트림 기여

ARCH-B

ARCH-B

토스테크 기반 · 2026년 10월 9일 · 5분 분량

0

한눈에 보는 핵심요약

토스증권이 쿠버네티스 기반 GPU 클러스터 운영 문제를 해결하기 위해 하드웨어 헬스체크와 5단계 사전 검증 게이트를 구축하고, MIG 자원 파편화를 해결하는 Packed Allocation 정책을 구현해 엔비디아 공식 디바이스 플러그인에 병합시켰습니다.

  • cgroup 제어 및 정수 단위 스케줄링 제약 등 쿠버네티스 기본 GPU 연동의 한계를 운영 관점에서 분리 정의했습니다.
  • 하드웨어 결함 검출과 복귀를 자동화하는 5단계 'Preflight' 검증 체계로 노드 Ready와 GPU Ready 간 괴리를 해결했습니다.
  • 자원 파편화를 줄이는 Packed Allocation 알고리즘을 제안해 엔비디아 공식 레포지토리(PR #1621, v0.20.0)에 반영했습니다.
쿠버네티스 GPU 인식을 넘어 운영 신뢰성으로: 토스증권의 클러스터 고도화와 업스트림 기여
이미지 제공: 토스테크 · 원출처 기사

쿠버네티스 GPU 인식 단계의 구조와 운영상 한계

토스증권 Data Infra 팀과 ML Platform 팀은 대고객 AI 서비스 확장에 대응하기 위해 기존 쿠버네티스 클러스터에서 GPU 워크로드를 운영해 왔습니다. 통상 쿠버네티스에서 GPU를 컨테이너에 연결하려면 호스트 OS 드라이버, NVIDIA Container Toolkit, NVIDIA Device Plugin, 파드 스펙 요청이라는 네 단계를 거치며, 이를 통해 노드의 'nvidia.com/gpu' 확장 리소스로 GPU를 인식하게 됩니다.

그러나 토스증권 측에 따르면 단순히 자원을 인식하는 것(GPU-aware)과 실제 서비스를 안정적으로 운영하는 것 사이에는 상당한 간극이 존재했습니다. CPU나 메모리와 달리 GPU VRAM은 리눅스 커널의 cgroup 제어 경로에 포함되지 않아, VRAM 고갈 시 발생하는 CUDA OOM 같은 오류를 쿠버네티스 기본 이벤트만으로 통제하거나 격리하기 어렵기 때문입니다.

'Node Ready'와 'GPU Ready'의 괴리 극복과 사전 검증 체계

실제 운영 환경에서는 kubelet이 노드를 정상(Node Ready=True)으로 보고하고 파드가 실행(Pod Running) 중이더라도, 실제 GPU 장치에는 Xid 오류나 NVML Unknown Error 같은 하드웨어 장애가 발생해 있을 수 있습니다. 토스증권은 이에 따라 하드웨어 실행 경로, DCGM(Data Center GPU Manager) 메트릭, 커널 신호를 종합해 판정하는 'GPU Ready'라는 별도의 운영 기준을 수립했습니다.

또한 신규 장비 도입이나 정비를 마친 노드가 서비스에 복귀할 때 자동으로 실행되는 5단계 'Preflight(사전 검증)' 파이프라인을 구축했습니다. 이 절차는 표준 스펙 대조, dcgmi diag 스트레스 및 NVLink 대역폭 실측, 디바이스 플러그인 편입 검증, CUDA 런타임 연산 테스트, 실제 경량 LLM 추론 동작 검증으로 구성되며, 모든 단계를 통과해야 cordon이 해제되어 트래픽을 수신합니다.

MIG 파편화 해결과 엔비디아 업스트림 기여

쿠버네티스의 확장 리소스는 정수 단위로만 할당할 수 있어 0.5 GPU 같은 세밀한 요청이 불가능합니다. 이를 해결하기 위해 MIG(Multi-Instance GPU) 기술을 활용해 자원을 분할하지만, NVIDIA Device Plugin의 기존 기본 정책(Distributed Allocation)은 인스턴스를 여러 물리 GPU에 분산 배치해 단일 풀 GPU(Full GPU)가 조기에 고갈되는 자원 파편화를 유발했습니다.

토스증권 엔지니어들은 하나의 물리 GPU부터 순차적으로 채워 다른 GPU를 온전하게 보존하는 'Packed Allocation' 방식을 구현했습니다. 이 개선안은 공식 NVIDIA 레포지토리(NVIDIA/k8s-device-plugin)에 PR #1621로 제안되어 병합되었으며, 공식 릴리스 v0.20.0부터 '--shared-devices-allocation-policy' 플래그로 정식 반영되었습니다.

ARCH.B 분석

용어 정의와 아키텍처 도입 시 고려해야 할 제약

토스증권이 제시한 'GPU-native'라는 개념은 CNCF나 업계의 공인 표준 용어가 아니라, 하드웨어 헬스체크와 복귀 게이트, MIG 세부 배치 등을 완비한 자사 운영 체계를 설명하기 위해 부여한 명칭으로 해석해야 합니다. 기업의 프레임워크 명칭 자체보다는 하드웨어 상태와 오케스트레이션 상태의 비동기화를 해결하려 한 실무적 접근에 주목할 필요가 있습니다.

또한 이번에 업스트림에 반영된 Packed Allocation 정책이 모든 환경에 만능은 아닙니다. 단일 GPU 집중 배치는 온전한 풀 GPU 확보에는 유리하지만, 열 분산이나 물리적 결함 격리가 필요한 대규모 분산 학습 환경에서는 오히려 분산 배치(Distributed Allocation)가 더 적합할 수 있습니다. MIG 자체도 A100이나 H100 등 특정 고사양 GPU 하드웨어에서만 지원되는 기술이라는 점을 염두에 두어야 합니다.

ARCH.B 분석

인프라 실무를 위한 시사점과 DRA 기술 발전 방향

토스증권의 사례는 플랫폼 엔지니어링 팀이 상용 솔루션이나 클라우드 관리형 기능에만 의존하지 않고, 인프라 계층의 병목을 소프트웨어 패치 형태로 해결해 업스트림 생태계로 환원한 실무 모델을 보여줍니다. 노드 복구 시 실제 추론 워크로드까지 태워보는 Preflight 게이트는 배치 실패로 인한 장애 전파를 방지하는 실질적인 모범 사례입니다.

장기적으로 쿠버네티스 생태계는 디바이스 플러그인의 정수 할당 제약을 넘어서기 위해 DRA(Dynamic Resource Allocation)를 발전시키고 있습니다. 따라서 인프라 조직은 단기적으로 검증된 디바이스 플러그인 패킹 정책과 상태 검증 자동화를 적용하되, 쿠버네티스 코어 레벨의 DRA 사양 진화 추이를 검토하여 중장기적인 GPU 풀링 아키텍처를 설계해야 합니다.

출처

토스테크의 원출처와 본문에 표시한 참고자료를 바탕으로 한국어로 재구성했습니다. ‘ARCH.B 분석’은 자료를 읽고 덧붙인 편집 해석입니다.

토스증권이 GPU-aware를 넘어 GPU-native 클러스터를 구축한 방법 (새 창)

Share

Related

함께 읽기 좋은 글