DAN25 참가 후기

DAN25란?

네이버 자사의 기술 뿐만 아니라 협업하고 있는 기업들의 기술 전시를 볼 수 있는 공간

2025년 11월 7일 DAN25 DAY2 DAN25 | TEAM NAVER CONFERENCE

기업 및 기술 탐방

• 네이버 관련 간단한 질문에 답하면 상품을 얻을 수 있었다

• 커다란 화면을 통해 영상을 띄우고 체험하는 분들의 카메라로 영상을 찍어주었다

• 최근에 나온 삼성 XR 헤드셋을 사용해서 치직직이 3D 영상을 시현하는 곳

• PRISM을 통해 바로 방송 시작할 수 있다는 것을 홍보하고 있다
• 방송을 처음 시작할 때 복잡한 과정이 많은데 PRISM 생태계 확장을 통해서 비교적 쉽게 시작할 수 있다

• AI를 활용하여 사업하는 기업 부스

  참가한 세션

  MLXP: GPU 효율화를 선도하는 대규모 MLOps 플랫폼

  

학부 GPU 서비스를 운영하고 있는 입장에서 네이버 같은 큰 기업은 어떻게 운영하고 있는지 궁금했습니다. 특히 동일하게 쿠버네티스를 사용하여 운영하고 있는데 저희가 해결하고 싶은 문제들을 해결했는지 확인하고 싶었습니다.

주요 내용:

• 크게 GPU 자원 운영 효율화, 스케줄링 전략, 그리고 장애 복구 자동화 세 가지 파트로 나눌 수 있습니다. 상세한 요약은 다음과 같습니다.

  1. 전사 GPU 효율화를 위한 MLXP 멀티테넌트 클러스터 (발표자: 장혁진)

  문제점: 기존 운영 방식의 한계

• Private Zone (팀별 독점): 각 팀이 GPU 노드를 독점하는 방식은 일부 팀의 과도한 점유와 다른 팀의 자원 부족을 초래했습니다.
• 자원 낭비: 낮은 GPU Utilization에도 불구하고 항상 자원이 부족하다고 느끼는 ‘자원 편중’과 ‘파편화’ 문제가 발생했습니다.
• 이기종 GPU: 다양한 세대(V100, A100, H100 등)와 스펙의 GPU가 혼재되어 관리가 어려웠습니다.

해결책: 공유 리소스 풀(Public Zone) 도입 및 체계화

• Public Zone 전환: GPU를 공유 자원화하여 유휴 자원을 다른 팀이 활용할 수 있게 함으로써, 기존 대비 약 4.7배의 효율 개선을 기대할 수 있게 되었습니다.
• 계층 구조 도입: Workspace(조직/비용 단위) > Project(실제 워크로드 실행 단위) 구조로 관리 체계를 확립했습니다.
• 우선순위 기반 쿼터 제어: 무분별한 사용을 막기 위해 3가지 요소로 워크로드를 정의하여 제어합니다.
  1. Provisioning Type: Reserved, On-Demand, Spot.
  2. Category: Serving, Training, Data, Interactive.
  3. Purpose: Service, QA, Produce, Test 등 목적에 따라 우선순위 차등.
• 자원 표준화 (Machine Profile): 이기종 GPU의 복잡성을 해결하기 위해 GPU/CPU/Memory 스펙을 미리 정의한 프로필과 그룹(Machine Group)을 만들어 사용자가 쉽게 선택하도록 했습니다.
• 사후 평가 및 회수: GPU 신청 후 실제 사용률을 분석하여, 저사용 자원은 회수하는 정책을 도입했습니다.

  2. GPU 활용 극대화를 위한 스케줄링 전략과 구현 (발표자: 김정명)

  문제점: Kubernetes 기본 스케줄러의 한계

• 기본 스케줄러는 Pod 단위 할당에 초점이 맞춰져 있어, 대규모 학습(LLM 등)에 필요한 배치 작업이나 갱 스케줄링(Gang Scheduling) 기능을 지원하지 못했습니다.

해결책: Volcano Scheduler 도입 및 고도화

• Distributed Bin-Packing (서빙 최적화):
  • 서빙 안정성을 위해 최소 3개 노드에 분산 할당(High Availability 확보)한 후, 나머지는 빈 패킹하여 자원 파편화를 방지했습니다.
• Gang Scheduling (학습 최적화):
  • 분산 학습 시 필요한 모든 자원(ex 4노드)이 준비될 때까지 기다렸다가 All-or-Nothing 할당을 하여 교착 상태를 방지했습니다.
• Network Topology-Aware Scheduling:
  • 노드 간 고속 통신(InfiniBand)이 필수적인 분산 학습을 위해, 네트워크 스위치 구조를 인지하는 HyperNode CRD를 개발하여 통신이 원활한 노드끼리 묶어서 할당했습니다.
• Preemption 알고리즘 고도화:
  • 자원 부족 시 낮은 우선순위 작업을 Preemption할 때, 단순히 우선순위만 보는 것이 아니라 ‘영향도’를 점수화 했습니다.
  • 학습 중단 시 피해가 적은 작업이나, PDB(Pod Distribution Budget)를 고려하여 서빙 안정성을 해치지 않는 선에서 축출 대상을 선정합니다.
• Descheduling (조각 모음):
  • 시간이 지나며 발생하는 자원 파편화를 해결하기 위해, 사용량이 낮은 새벽 시간대에 워크로드를 재배치(Defrag)하여 큰 자원 공간을 확보하는 RepairBot을 운영합니다.

    3. GPU 클러스터 가용성: 감지·분석·복구 자동화 (발표자: 박영훈)

    문제점: 고비용 GPU 장비의 장애 관리

• A100, H100 등 고가의 장비에서 장애가 발생하거나 성능 이슈가 생길 경우 막대한 비용 손실과 학습 실패로 이어집니다.
• 사람이 직접 장애 알림을 받고 대응하는 것은 시간도 오래 걸리고, 운영자의 피로도가 매우 높았습니다.

해결책: 모니터링 및 자동 복구 시스템 (RepairBot)

• 모니터링 강화:
  • NVIDIA Error, GPU 온도, PCI 버스 에러, InfiniBand 상태 등을 실시간으로 수집합니다.
  • VictoriaMetrics와 Grafana를 활용해 대규모 클러스터의 메트릭을 통합 관리합니다.
• RepairBot (자동 복구 봇) 개발:
  • Operator 패턴: Grafana Alert가 발생하면 Webhook을 통해 RepairBot에 전달되고, 봇이 해당 노드에 ‘장애’ 태깅을 합니다.
  • 자동 조치: 컨트롤러가 태그를 감지하고, 정해진 절차(재부팅, 드라이버 리셋, 헬스 체크 등)를 자동으로 수행하여 장애를 복구합니다.
  • 결과 공유: 장애 감지부터 복구까지의 모든 과정을 Slack과 Jira 티켓으로 자동 전파합니다. 도입 효과
• MTTA (장애 인지 시간): 평균 1분 41초 → 1.22초 (약 83배 단축)
• MTTR (장애 해결 시간): 사람 개입 시 수십 분 소요 → 평균 6분 내외로 자동 복구
• 운영자의 새벽 기상 및 단순 반복 업무를 제거하여 개발에 집중할 수 있는 환경을 마련했습니다.

  QnA

  발표 이후 궁금한 점들이 생겨 질문했습니다

• Q: 사용자들의 활동 기록을 보고 평가한다고 했는데 무의미한 연산을 확인하고 있는지?
  • A: 현재로써는 사용자를 믿고있지만 나중에는 GPU 트레이스를 통해 확인할 생각을 가지고 있다고 합니다
• Q: hami 같은 GPU vram slicing은 사용하지 않는다고 하는데 자세한 이유는?
  • A: 해당 방식은 소프트웨어 레벨에서 나누는 slicing인데 완벽한 격리가 어려울 뿐만 아니라 안정성이 조금 떨어져서 하지 않고 있음
• Q: 노드끼리 떨어져있는 경우 데이터 저장 문제는 어떻게 해결했는지?
  • A: 고속 인터넷 연결을 통해 외부 스토리지 ex)S3를 사용하는 식으로 해결
• Q: 연구 분야에선 값을 조금씩 바꾸면서 실험하고 최대한 환경이 안 바뀌는 것을 선호하는데 pod의 경우 환경설정을 처음부터 해야하는데 이런 문제는 어떻게 해결하는지?
  • A: 따로 환경 유지를 시스템적으로 제공하지 않고 유저가 이미지를 만드는 식으로 해결해야함

전체 소감

• 네이버하면 가장 먼저 떠오르는 것은 우리와 밀접한 서비스(블로그, 웹툰 등등) 밖에 없었는데 요번 컨퍼런스를 통해 네이버가 하고 있는 것들 (현대 자동차 전용 앱, 로봇 기술, GPU 자원 관리 등등) + 나아가려고 하는 방향을 볼 수 있어서 좋았습니다.
  • 특히 Whale을 브라우저로만 생각하고 있었는데 하드웨어 특화 OS로 나아가고 있는 것은 신기했습니다.
• 그 외에도 AI를 활용한 다양한 기업들의 기술을 체험해보는 것이 재미있었습니다
  • LLM을 통한 신발 만들기
  • 트래킹 장비 없이 인물 추적하기