https://youtu.be/POkc2PR9TCU?si=N5XgAA18RFl_GFWR
네이버의 고성능 하드웨어, 스토리지를 AI/ML 학습에 사용할 수 있도록 학습 모델링 관련 도구를 제공하는 플랫폼.
- 최대 GPU 128장 규모 모델까지 학습 가능한 대규모 HPC 클러스터
- 모든 GPU는 고속 네트워크인 infiniBand(IB)로 연결
- 서버 간 높은 트래픽을 감당해내고, GPU에 직접 데이터를 송수신하며, 고속 스토리지 DDN도 GPU / IB와 연결되어 있어 multi read 병목현상 해소
고비용 인프라이므로, 최대한 효율적으로 써야 함. How?
- 할당량: 사용자에게 할당되는 GPU. 스케줄링에 문제가 있다면, 할당량이 떨어지게 된다.
- 활용량: 배정된 GPU를 사용자가 잘 활용하는가.
- GPU utilization / Power와 같은 지표
- 자원 배분 / 스케줄링 예측가능성 등 고전적인 스케줄링 관련 정보도 활용량의 변인이다
따라서, GPU가 공급되었을 때 할당 -> 활용을 거치는 과정에서 효율성을 최대한 유지하는 것이 과제.
- Scheduling: GPU 활용률을 높이는 스케줄링
- Monitoring: HPC 클러스터 모니터링 도구
- Diagnostics: 분산학습 엔지니어링 이슈 파악
Scheduling
각 팀에서 자체적으로 GPU 수급해서 활용하던 구조: 관리 어렵고, 스케줄링도 주먹구구식, 대규모 분산학습이 불가능.
- GPU 자원 모아서, 수요 / 정책에 따른 스케줄링 도입.
- 자원 파편화 방지 + 커스텀 스케줄링
자원 파편화: GPU 할당률을 저해하는 가장 큰 요소
- 사용자마다 요구하는 GPU 스펙 수준이 다름
- GPU 호스트에 종속된 자원 형태. 한 host의 GPU는 최대 8장
호스트 내 자원 파편화 문제 해결법
- 사용자들의 실험패턴 파악 (소규모 - 대규모) -> 하드웨어 사양 정리.
- GPU 개수와 비례하는 CPU / Memory 자원 배정.
호스트 간 자원 파편화 문제 해결법
- MostAllocated: 리소스 많이 사용중인 호스트부터 우선 배치. 소규모 실험이 대규모 실험의 리소스 할당을 방해해선 안됨.
- 규모가 유사한 실험끼리 조합해서 배치. 소규모, 중규모, 대규모 Pod 역할 부여.
그럼에도 GPU 할당의 최적화에는 한계가 있다. '잘' 하려면?
- 자원 사용의 균형 유지
- 적절한 리소스 반환시간 보장
- 스케줄링의 예측 가능성 제시
최적의 GPU 자원배분을 위한 경제학 전문가와의 협업. 파라미터들은
- GPU 활용률
- 리소스 유형별 대기시간
- 팀별 리소스 사용현황
- 규모에 따른 구역 활용률
- 사용자별 GPU 점유시간
- 우선순위가 낮은, 소규모 실험 활용률
- ...
커스텀 스케줄러의 도입
- k8s Scheduler Framework 활용해서 커스터마이징
- GPU 활용률을 높이는 방향으로 리소스 할당 제어
- 누구에게, 언제, 어떻게 할당할지를 결정함.
정책 우선순위 기반 스코어링
- 원래 k8s에서도 queueSort라는 단계를 거쳐 대기중인 pod를 정렬하지만, 스케줄 / 자원 현황에 따라 랜덤하게 배치될 수 있음.
- 많은 자원이 활용될 수 있도록 정책 우선순위 도입.
- 규모가 큰 / 대기시간이 길었던 리소스에 자원을 우선 배분
- 긴급수요가 있으면 먼저 배치
- 대기열 내 실험 할당순위를 시각화하는 것도 가능
중 / 대규모 예약 시스템
- 규모가 큰 실험은 언제 시작되고, 언제 끝나는지가 중요함. -> 예약 시스템 도입.
- 원하는 시간에 실험 준비, 실행 가능하도록
- 정해져 있는 예약시간으로 가시성 보장, 전체 학습시간의 예측에도 용이함
- 분산학습을 필요로 하는 연구자들의 사용성 증가
분산학습 지원
- 노드 간 통신에 병목이 생기면 분산학습이 어려워지고, 학습효율이 떨어진다.
- 각 GPU 노드를 infiniBand로 연결 -> 노드 간 통신병목 최소화.
- 분산학습 노드는 같은 Pod에 배치되도록 제어.
- 학습을 위한 동시실행 보장 - 일부 노드 자원만 점유한 채 무한대기에 빠지는 현상 개선
Monitoring
효율적으로 쓰려면 운영자, 사용자 둘다 신경써야 함.
- 운영자: 안쓰는 리소스 모니터링 + 가용자원 파악하기
- 사용자: 학습에 쓰이는 자원 사용량 모니터링 + 엔지니어링 이슈로 의심되면 조치
즉 "클러스터 관측" / "분산학습에 관련된 인사이트" 필요
- 인사이트? - 대규모 분산학습은 하드웨어 이슈 등으로 자원낭비가 쉽게 이뤄질 수 있기에, 과거 있었던 이슈의 트러블슈팅 같은 기록이 중요하다
적절한 도구가 없다
- MLOps 플랫폼: 개별 모델 학습 관련된 가시성에 치중해 있다. 시스템 지표와 같은 클러스터 통합지표를 제공하지 못함
- Cloud 모니터링: 서비스 인프라 모니터링에 집중할 뿐, 학습 워크로드의 상태 이상을 탐지하기는 어려운 구조
따라서 '클러스터 자원 현황' / '학습 상태'를 한번에 볼 수 있는 '통합된 가시성'이 필요함.
요구사항
- 전체 클러스터 리소스 상태, 할당된 task 상태를 동시에 표현해야 함.
- 운영자 / 사용자의 서로 다른 모니터링 요구사항을 만족해야 함
- 리소스 / task에 문제가 생겼을 경우 빠르게 탐지할 수 있어야 함
- 디버깅할 수 있는 시스템 지표 데이터를 제공해야 함.
노드 상태 + task 상태 동시에 표현
- GPU를 하나의 unit으로 시각화
- 클러스터 자원 상태, 할당된 실험 상태를 동시에 표현하기 위한 API 개발
- 클러스터 노드 / GPU 지표, 스케줄링 지표, 애플리케이션 지표를 GPU 단위로 Aggregate
- deck.gl (WebGL 프레임워크) 활용해서 구현. 실시간 상태변화를 직관적으로 파악할 수 있게 했다
운영자 / 사용자의 모니터링 요구사항 충족
운영자, 사용자의 서로 다른 모니터링 요구사항을 어떻게 충족할 것인가: 2018년 ATOM 논문의 방법론 채택
- 제한된 스크린에서 유닛 / 유닛 그룹을 다양한 형태로 배치하는 레이아웃 연산
- Fill: 유닛을 x, y축에 맞춰 채워넣기
- List: x, y축 따라서 나열
- Pack: bin-packing 알고리즘으로 공간낭비 최소화
- 위와 같은 방식으로 유닛을 bar chart, grid, treemap 등의 방식으로 시각화할 수 있다
레이아웃 단위로 그룹화하면, gpu 유닛을 다양한 조건으로 묶어서 표현하는 것이 가능함.
- gpu unit을 x축으로, project / task 단위로 다시 묶음.
- 만들어진 커스텀 대시보드는 json으로 저장해서 재사용 가능하도록 했다.
이상 현상 체크하기: violation rule 활용한 힌트 제공
- 학습 시작 시점부터 GPU 활용률 등 시스템 지표의 95%, 25% 분위값 추적
- 사용자가 정의한 임계치 이하의 실험들은 강조 표시
- 강조된 task들은 빠르게 진단 도구로 분석하도록 유도한다.
효과
- 자원 사용량을 체크하고, 저사용 자원을 조치할 수 있게 됨. 운영자뿐만 아니라 사용자들도 제보할 수 있다
- 사용자가 가용자원을 파악할 수 있게 됨. 리소스 타입별 Available / Occupied / pending 자원 현황을 알 수 있다
- pending일 경우 대기열의 우선순위를 정렬해서 가시화.
- 문제가 있는 노드의 경우, 진단할 수 있는 UX flow 제공 - 디버깅 쉬운 환경 제공
Diagnostics
분산학습의 경우 대규모 학습 과정에서 여러 문제가 발생하므로, 문제 있는 실험은 빠르게 탐지하고 조치할 수 있도록 한다.
일반적으로 분산학습은 두 가지.
- Data Parallelism: 데이터를 머신별로 나누어 학습
- Model Parallelism: 모델을 머신별로 나누어 학습
동기화에서의 병목
- 일부 Worker의 작업에 문제가 생기면, 나머지 작업도 해당 worker가 해결될 때까지 대기함.
- 대기중 = 자원 점유는 하되 사용하지 않고 있음.
생기는 이유
- 코드 레벨에서 특정 workload에 더 많은 작업을 할당하는 Workload imbalance
- 장비의 장애 / 데이터 통신 지연...
결과적으로 학습이 오히려 느려지거나, 멈출 수 있다
엔지니어링 관점에서의 기존 접근법
- 지표 수집
- GPU: 주요 활용 지표 (활용률, 전력 사용량, 메모리 사용량), Node / GPU 간 통신 지표 (PCIe, NVLink bandwidth)
- Node: CPU / Mem 사용량, network I/O, disk I/O
- Grafana Dashboard
학습 / 실험에서 발생하는 여러 지표를 확인하고, GPU 활용률의 이상치 탐지 정도는 쉬움.
대규모 실험의 경우 문제 발생. 위 대시보드의 경우 128장의 GPU로 학습중인 작업
- 문제를 감지하기도 어려워지고, 분석할 지점을 탐색하기도 힘듦. (어떤 GPU가 어느 시점에 문제인지)
- 분산학습 전략에 따라 지표 패턴이 다양하기에, 문제를 정형화하기도 힘들다. (규칙 기반 접근의 한계)
사용자에게 High-Level의 분석 방향을 제시해주자. 그러려면 어떤 지표를 어떻게 봐야 하는지 안내해줘야 함.
각 GPU로부터 수집된 지표의 분포 / 패턴이 드러나도록 Preview 시각화
- 예시의 경우 단순 지표는 Histogram, 시간에 따른 패턴 변화는 Line Graph
- 시스템이 정한 Violation Rule (GPU의 낮은 활용률 or idle 상태)에 해당할 경우 강조표시
대규모 GPU라면, violation rule 표시하면 오히려 난잡해보일 수 있다.
- HCA 클러스터링 기법 적용.
- 정해진 유사도에 따라, 측정된 클러스터를 GPU 사각형에 색상 표시. 패턴이나 분포가 상이한 경우 두드러지게 보일 수 있도록
어떤 구간을 분석해야 하는가?
- 사전에 시스템 지표 간 상관관계 분석.
- 일반적인 상관관계 분포에서 멀리 떨어진 이상치 데이터를 강조한다.
- 이상치 데이터 timestamp를 지표 타임라인 분석기에 드러낸다. -> 분석해야 하는 구간 제시
목표: 이상치를 직관적으로 드러내고, 효율적인 분석 방향을 제시한다.
- 분석 대상: GPU별 지표 Preview / 클러스터링
- 분석 구간: 상관관계가 일반적이지 않은 데이터 포인트
적용 사례
Wrap Up
