왜 Datadog이 필요했나
KT는 1700대 이상의 대규모 GPU 인프라를 운영하며 60개 이상의 AI 프로젝트를 지원하고 있다. 마이크로소프트 Azure와 온프레미스 등으로 혼재된 하이브리드 환경에서 고성능컴퓨팅(HPC)부터 GPU 슬라이싱에 이르기까지 다양한 요구를 충족시켜야 한다. GPU 팜(Farm) 규모가 커지고 복잡해지는 가운데 ‘누가, 어디서, 얼마나 GPU를 사용하고 있는가’란 질문에 부딪쳤다.
AI 프로젝트에서 GPU는 연구 일정과 결과의 품질을 좌우하는 핵심 자원이다. 연구자는 적기에 GPU를 할당받아야 하고, 운영자는 한정된 GPU 자원을 적기적소에 효율적으로 할당하고 회수해야 한다.
기존 환경에서 GPU 할당은 수동으로 이뤄졌고, 관리도 제대로 되지못했다. GPU 회수와 절감에 대한 객관적 기준이 없다보니 사용자 불만도 쌓였다. 클라우드와 온프레미스 환경별로 각기 다른 대시보드를 이용해야 해 사용자의 편의성도 떨어졌다. 운영자 입장에서 한정된 자원을 효율적으로 분배해야 했지만, GPU를 우선 확보하려는 사용자의 경향으로 정책과 다른 할당이 잦았다. 프로젝트별 GPU 사용량, 할당량 등에 대한 정보 파악도 힘들었다. 다양한 환경의 전체 현황을 한눈에 보기 어려웠고, GPU 수량, 상태, 할당 등의 내역을 수동으로 관리하는 부담이 커졌다.
문제 상황
KT가 마주한 문제는 3가지였다. 프로젝트별 사용 현황, 환경별 통합 모니터링, 대규모 GPU 관리 등이다. 운영자는 실제 할당량과 사용량을 한눈에 확인할 수 없었다. 인프라 환경마다 규칙이나 태그 등의 메타 정보가 달라 여러 화면을 번갈아 보면서 수동으로 엑셀에 데이터를 입력했다. GPU 배분의 우선순위가 섞이면서 필요한 팀에 제때 자원을 할당하지 못하는 일도 벌어졌다. 운영자는 여러 환경에서 GPU 사용량을 각기 확인할 수밖에 없었고, 체계적이고 자동화된 운영 시스템의 부재 속에 사람이 전체 운영 프로세스에서 병목으로 작용하는 구조가 만들어졌다.
대규모 GPU 운영을 위한 Datadog 도입
KT는 Datadog을 기반으로 표준화된 운영 기준에 따라 GPU를 관리하는 프로세스를 도입하고자 했다.
전체적인 GPU 수명주기를 신청, 할당, 그룹화, 모니터링, 회수 등 5단계로 정의했다. 그중 신청과 할당은 Slack과 Datadog을 연동해 수행하고, 그룹화는 Datadog Incident와 태그를 활용해 수행하게 했다. 모니터링과 회수는 Datadog 모니터링 기반으로 하도록 했다.
KT의 독특한 점은 Datadog Incident를 GPU 운영 프로세스의 기본 단위로 활용했다는 점이다. 모든 GPU 관련 이벤트의 시작을 Incident 생성으로 정의하고, Slack에서 GPU 할당을 신청하면 Datadog의 incident가 생성되도록 했다. 사용자가 과제명, 조직명, 필요 수량 등을 입력해 신청하면, Datadog Incident에 팀명, 프로젝트명, GPU 디바이스 정보 등의 메타데이터를 저장했다. Incident는 그 자체로 하나의 할당된 GPU가 되고, Incident 상태가 운영 단계를 그대로 표현한다. Incident로 발행되는 IR 번호를 GPU 노드의 태그로 할당해 프로젝트별 추적을 가능하게 하고, 노드를 프로젝트로 묶어 관리할 수 있게 됐다.
아키텍처와 워크플로우
전체적인 GPU 운영 플랫폼의 아키텍처는 Slack, Datadog, GPU, 코드 네개의 영역으로 구성된다. 연구자가 Slack으로 GPU를 신청하면, Datadog Incident가 생성된다. 생성된 IR 번호는 Slack 알림으로 연구자에게 전달되고, 연구자는 할당받은 IR 번호를 코드 레벨이나 추론에서 태그 API를 통해 실제 태그로 삽입한다. 클라우드와 온프레미스의 GPU 노드는 태그 API를 통해 실제 사용중인 GPU 노드에 태그된 IR 번호로 모두 추적되고 탐지된다.
Incident는 액티브(Active), 스테이블(Stable), 리저브드(Reserved) 등 세가지 상태로 정의된다. 각각 신청, 할당 및 사용, 과제 종료 등의 상태를 나타낸다. 운영자는 Incident 상태 리스트만으로 신청, 할당, 회수 등의 단계를 명확히 파악할 수 있다.
GPU 할당량 관리는 Datadog Integration과 Agent로 구현했다. 클라우드와 온프레미스에 존재하는 GPU 쿼터 정보는 Datadog Integration과 Incident를 통해 자동으로 동기화되고 관리된다. 실제 GPU가 클라우드나 온프레미스에 새로 생성되면, Agent가 해당 노드를 자동으로 인식해 Datadog에 등록한다. GPU 노드 이름, GPU 모델, 할당 태그 등이 Datadog 내부에 실시간으로 동기화되므로, 운영자는 수기 입력없이 바로 GPU 현황을 확인할 수 있다. Datadog은 이러한 설정을 통해 구현된 각 인프라 환경의 GPU 현황을 그대로 반영하는 단일 플랫폼으로 기능하며, GPU 할당량 관리와 자원 추적의 완전 자동화를 지원한다.
Datadog 기반 GPU 모니터링 활용
KT는 Datadog으로 GPU 매니지먼트, GPU 거버넌스, 환경별 사용량 가시화, 연구과제별 사용량 가시화, GPU 노드 내 디바이스 및 프로세스 레벨 가시화 등을 구현해 이용하고 있다.
KT의 GPU Farm 관련 Datadog Dashboard는 여러 환경별 GPU 사용량을 직관적으로 보여준다. GPU 사용률 메트릭을 활용해 사용량을 모니터링한다. 노드는 태그를 통해 프로젝트별로 1차적으로 그룹화되고, 환경별로 그룹화된다. 태그를 활용해 모니터링에 필요한 그림으로 그룹화할 수 있게 했다.
세부적인 환경별 모니터링으로 HPC, GPU 슬라이싱 등의 클러스터 환경에서 GPU 상태를 모니터링할 수 있다. 가령 HPC 환경의 경우 각 노드의 GPU 개수, 사용률, 실행 중인 Job 상태 등을 Datadog Agent가 주기적으로 수집하고 Dashboard에서 시각화한다.
운영자는 현재 사용중인 노드, GPU 리소스의 분배 현황 등을 파악할 수 있다. GPU 슬라이싱의 경우 여러 연구 과제가 하나의 노드를 공동 사용하므로, Datadog Agent가 컨테이너 단위로 GPU 점유율과 프로세스를 수집하고 자원 공유 현황을 시각화해 보여준다. 사용자는 Datadog을 통해 GPU 노드 내 세세한 사용정보를 확인할 수 있다. Datadog Dashboard에서 GPU 노드에 어떤 프로세스와 Job이 떠있는지, 실제 연결된 GPU 디바이스별로 메트릭이 잘 수집되는지 등을 확인하거나, GPU 디바이스 문제를 점검하는 것도 확인하고 있다.
Incident 구조를 기반으로 프로젝트 모니터링도 가능하다. IR 번호가 코드 레벨에서 태깅되므로, Datadog은 태그를 기준으로 GPU 노드를 프로젝트 단위로 그룹화한다. 특정 프로젝트별 GPU 사용 규모, GPU 평균 사용률, 사용기간 등을 한눈에 확인할 수 있다. 운영자는 프로젝트별 사용량을 기준으로 GPU 효율성을 분석하고, 유휴 상태나 회수 대상 GPU를 빠르게 식별할 수 있다.
“KT에게 Datadog은 단순한 모니터링 툴이 아니라 GPU 라이프사이클 전체를 관리하는 운영 플랫폼입니다. 인력 중심 운영에서 시스템 중심 운영으로 완전히 전환함으로써, 운영 효율과 일관성을 한단계 업그레이드할 수 있었습니다.”
향후 계획: GPU 운영 완전 자동화를 향해
KT는 Datadog의 활용 범위를 운영 차원에서 모델 개발 차원으로 확장할 예정이다.
우선 GPU 프로파일링 기능을 검토 중이다. 추론 지연이나 메모리 피크, 처리량 등의 실제 GPU 사용 정보를 Datadog Dashboard로 시각화하고, 개발자와 운영자가 동일한 데이터를 공유하게 한다는 계획이다. 가령, Pytorch Profiler 같은 부속 자료가 웹페이지에 업로드되면, Datadog Dashboard에 iframe 형태로 임베디드돼 GPU 리소스와 모델 성능을 함께 추적하게 하는 식이다.
또 Datadog Workflow를 기반으로 GPU 프로세스를 완전 자동화하는 것도 검토중이다. 현재 수동으로 진행되는 구축 및 설계 작업 이력 관리를 Workflow와 Datadog Integration으로 자동화하고, Datadog Agent 설치 자동화를 구현한다. 현재 GPU에 할당했던 태그를 제거하는 작업의 자동화를 달성했고, Datadog Workflow를 통해 Incident와 태그 기반 수명주기에 맞춰 GPU 회수에 해당하는 작업을 설계하고 GPU 전체 운영을 코드로 제어하는 체계로 전환했다.