토스증권, 쿠버네티스 GPU 클러스터를 GPU-native로 고도화

ai.euno.news 자동 뉴스 요약

토스증권이 지난 상반기 동안 Data Infra 팀과 ML Platform 팀을 중심으로 쿠버네티스 기반 GPU 클러스터를 구축한 과정을 자사 기술 블로그를 통해 공개했다. 이 회사는 대고객 서비스를 운영하는 것과 같은 쿠버네티스 환경에서 AI 워크로드를 함께 실행하는 것을 목표로 삼았고, 그 과정에서 GPU를 단순히 인식하는 단계를 넘어 여러 팀이 안정적으로 나눠 쓸 수 있는 단계까지 나아갔다고 설명했다.¹

토스증권은 이 글에서 GPU 운영 성숙도를 두 단계로 구분한다. 쿠버네티스가 GPU를 자원으로 인식하고 파드에 할당할 수 있는 상태를 ‘GPU-aware’라 부르고, 여기서 더 나아가 개별 GPU의 정상 여부를 판단하고 검증된 노드만 워크로드를 받게 하며 서비스별로 필요한 단위만큼 자원을 나눠 배치할 수 있는 상태를 ‘GPU-native’라 정의했다. 토스증권이 실제로 갖추려 한 것은 후자였다.

GPU-aware한 클러스터를 만들기까지는 네 단계를 거쳐야 한다. 먼저 서버에 GPU가 탑재되고 운영체제가 이를 인식하도록 NVIDIA 커널 드라이버가 설치돼야 하고, 그 위에 NVIDIA Container Toolkit이 컨테이너 런타임과 드라이버를 연결해야 한다. 이어 NVIDIA Device Plugin이 노드의 GPU를 kubelet에 등록하면 kubelet은 이를 nvidia.com/gpu라는 자원으로 노드의 Capacity와 Allocatable에 반영하고, 스케줄러는 이 값을 기준으로 파드를 배치한다. 마지막으로 파드 스펙에서 nvidia.com/gpu를 요청하면 앞선 경로를 통해 컨테이너에 GPU가 연결된다. 이 네 스텝 중 어느 하나라도 어긋나면 노드에 GPU가 있어도 쿠버네티스 자원으로 나타나지 않거나, 파드는 배치됐는데 컨테이너는 GPU를 쓰지 못하는 식으로 결과가 비슷하게 나타난다고 토스증권은 설명한다.

문제는 GPU-aware한 상태만으로는 운영이 끝나지 않는다는 점이다. 토스증권은 CPU와 시스템 메모리가 리눅스 커널의 cgroup을 통해 컨테이너 단위로 제어되는 반면, GPU 메모리(VRAM)는 이 경로에 포함되지 않는다는 점을 핵심 한계로 짚었다. nvidia.com/gpu: 1은 GPU 장치 하나를 할당한다는 뜻일 뿐, 그 안의 VRAM 크기나 연산 비율까지 지정하지는 않는다. 쿠버네티스에는 memory: 4Gi처럼 시스템 메모리를 요청·제한하는 방법은 있어도 vram: 40Gi처럼 GPU 메모리를 다루는 표준 자원은 없다는 것이다. 그 결과 VRAM이 부족해지면 애플리케이션이 CUDA OOM 오류를 만나는데도, 쿠버네티스 이벤트만으로는 원인을 진단하기 어렵고 파드 종료 후 GPU가 정상으로 돌아왔는지도 기본 자원 상태만으로는 확인되지 않는다.

토스증권은 이런 한계 속에서 실제 서비스 운영을 위해 노드가 Ready 상태여도 개별 GPU가 정상인지는 별개 문제라는 점, 점검이나 설정 변경 후 노드를 언제 다시 투입해도 되는지 판단하는 기준이 필요하다는 점, 서비스마다 필요한 자원 크기가 달라 GPU를 한 장 단위로만 제공하는 방식이 비효율적이라는 점 등을 실제로 마주한 질문으로 꼽았다. 이 문제들을 풀기 위해 별도의 구성 요소와 운영 로직을 만들고, 필요한 경우 업스트림 프로젝트에도 기여했다고 밝혔다.

토스증권은 이런 보완 작업 중 일부가 쿠버네티스 자체의 최근 변화와 방향을 같이한다는 점도 언급했다. 쿠버네티스의 DRA(Dynamic Resource Allocation)는 ‘장치 한 개’ 단위의 단순한 요청에서 벗어나 필요한 조건을 가진 장치를 요청하고 할당받을 수 있게 하는 기능으로, 토스증권이 지난 2년간 자체적으로 메워 온 공백 일부를 표준 스펙 차원에서 다루기 시작한 사례로 소개됐다.

읽기 목록은 이 브라우저에 저장됩니다.