Naver DEVIEW 2023 : 대규모 HPC 클러스터의 효율적 활용을 위한 Schedeling, Monitoring, Diagnostics

강민우·2023년 3월 9일
1
post-thumbnail

해당 게시글은 Naver DEVIEW 2023을 기반으로 작성되었습니다.
게시된 모든 기능 설명 및 자료사진은 해당 세션의 발표자료를 참조하였습니다.

Naver DEVIEW 2023

0. Naver DEVIEW 2023 방문기

네이버에서 DEVIEW라는 개발자 컨퍼런스가 23년 2월에 한다는 소식을 듣고 친구랑 부랴부랴 티켓팅을 시도했다. 아쉽게도 DAY 1은 실패했지만, DAY 2는 성공하여 이렇게 삼성동 코엑스를 다녀오게 되었다.

여러 세션을 듣고 느낀점이 많았지만, 그중 가장 재밌고 흥미롭게 듣게 된 이 세션, 대규모 HPC 클러스터의 효율적 활용을 위한 Schedeling, Monitoring, Diagnostics 을 듣고 느낀점을 간략하게 기록하려고 한다.


1. NSML의 대규모 HPC 클러스터

1.1 NSML의 소개와 HPC 클러스터의 효율화

NSML이란 네이버의 대규모 컴퓨팅 클러스터 서버를 쉽게 사용할 수 있게 학습 모델링 관련 도구를 제공하는 플랫폼이다. 이 세션의 주요 주제는 이 NSML을 사용자로부터 어떻게 Scheduling하고 Monitoring 도구를 개발하며 쉽게 이슈를 찾을 수 있는 디버그 도구(diagnostics)를 개발하는 것에 초점이 맞추어져 있다.

이 세션에 따르면, NSML은 GPU 최대 128장 규모의 연산이 가능한 대규모 HPC 클러스터이며, 모든 GPU 서버는 고속 네트워크(InfiniBand)로 연결되어있어 서버 간 통신 병목이 최소화되어 분산 학습에 유리하다고 한다.

한편, 이러한 HPC는 고비용 인프라이기 때문에 자원 활용량이 극대화되어야 한다. 이를 위하여 세 가지 지표를 통해 NSML 클러스터를 효율화 시켰다.

Scheduling : GPU 활용률을 높이는 스케줄링
Monitoring : 대규모 HPC 클러스터 모니터링 도구 개발
Diagnostics : 정형화 어려운 분산학습 엔지니어링 이슈 진단

1.2 느낀점

사실 대규모 연산이 가능한 클라우드 서버는 amazonAWS나, microsoftAzure밖에 몰랐기에 '네이버에서도 이런 플랫폼이 존재하구나...'라고 생각했고, GPU 서버나 스케줄링 기법 모두 관심있는 주제였기 때문에 흥미롭게 들을 수 있었다.


2. NSML의 Scheduling 개선

개인 또는 조직이 GPU 서버를 할당받아 사용하게 되면 당연하게도 GPU 자원이 나누어지게 된다. 여기서, 조직 변동이나 팀 내 사용률 저하는 GPU 활용률 저하로 이어지게 되고, 이는 GPU의 유동적인 수요에 대처하기 어렵게 만든다.

따라서 파편화된 GPU 자원을 효율적으로 배분하기 위해 수요 및 정책에 따른 스케줄링을 도입하게 된다.

2.1 자원 파편화 현상 방지

자원을 배정하고 회수하는 과정에서 발생하는 리소스 조각은 사용되지 못하고 방치되는데, 이는 GPU할당률을 저해하는 가장 큰 요소이다.

리소스 유형 정의

이를 해결하기 위하여 리소스 유형을 정의하여 자원을 배정한다.
분산 학습 용도라면 GPU 사용량이 높고, 전처리 위주의 작업이라면 CPU 활용량이 높다는 특징에 기인하여, CPU, GPU, RAM 등의 호스트 자원을 배정하여 호스트 내 자원 파편화를 방지한다.

MostAllocated 정책 적용

또한 소규모 실험이 대규모 실험의 할당을 저해해서는 안되므로, 리소스를 많이 사용중인 호스트부터 우선 배치한다.

실험 규모에 따른 NSML Pod에 역할 부여

소규모, 대규모 등 규모가 유사한 실험끼리 조합하여 배치하여 다양한 실험 규모에 따른 호스트 자원 파편화를 방지한다.

그러나 이들은 모두 할당량을 향상시키는 방법이며, 수요에 비해 공급량이 상대적으로 부족하므로 다른 스케줄링 방식을 개발하게 된다.

2.2 커스텀 스케줄링

경제학 전문가와 협업하여 자원 활용에 대하여 분석을 진행한다고 한다. 주요 지표는 아래와 같다.

  • GPU 활용률
  • 리소스 유형별 대기 시간
  • 팀별 리소스 사용 현황
  • 규모에 따른 구역 활용률
  • 전체 사용자별 GPU 점유 시간
  • 우선순위 낮은 소규모 실험 활용률

이러한 지표 분석을 기반으로 Kubernetes Scheduler Framework를 활용하여 커스텀 스케줄링을 도입했다고 한다.

정책 우선순위 기반 스코어링

기존의 랜덤 대기풀의 한계를 극복하기 위해 실험 규모 맟 대기시간에 따른 스케줄링 우선순위를 조정하는 정책을 시행하며, 이는 동적으로 우선순위를 조정할 수 있으며, 긴급 수요 배치 또한 가능하다는 효과가 있다.

중•대규모 학습 예약

전체 리소스에 큰 영향을 주는 학습을 관리하기 위하여, 규모가 큰 실험에 대하여 예약 시스템을 도입하였다. 이는 스케줄의 가시성이 향상되며 학습시간을 예측하기가 용이하고, 분산학습 사용성이 증가한다는 효과이 있다.

분산학습 지원

앞서 GPU 서버끼리는 고속 네트워크인 InfiniBand로 연결되어 있다고 서술했는데, 이는 노드 간 통신 병목을 최소화하게 구성할 수 있게 한다. 여기서 분산 학습 시 반드시 같은 NSML Pod 내에 배치하고, 동시 실행(Coscheduling)을 보장하도록 스케줄링하였다. 이는 GPU 노드 간 통신 병목을 해소하며, 스케줄링 데드락 현상 또한 방지할 수 있게 하였다.

2.3 느낀점

지금까지 교내 수업을 들으면서 시스템 프로그래밍, 오퍼레이팅 시스템에 관심이 많던 나에게 이러한 GPU 클러스터 내에서의 스케줄링 기법은 특히나 흥미롭게 다가왔다. 현재 지능형 임베디드 소프트웨어 연구실 소속이기 때문에 OS 레벨에서의 스케줄링 기법은 어느정도 알고 있었지만, HPC에서 스케줄링 정책의 효율화는 생각하지 못했던 분야였기 때문에 지식의 폭을 확장하며 흥미롭게 들을 수 있었다.


3. Monitoring

3.1 모니터링 도구의 필요성

대규모 HPC 자원의 효율화를 위해서는 운영자와 사용자 모두의 노력이 필요하다고 한다. 저사용 자원 및 가용 자원을 파악하고 조치하여야 하며, 학습의 자원 사용량을 모니터링하다가 엔지니어링 이슈가 탐지되면 이 또한 신속하게 처리하여야 한다.

기존의 MLOps 플랫폼 또는 Cloud 모니터링 플랫폼이 존재하지만, 클러스터 자원 현황과 학습 상태를 한눈에 파악하기는 어려웠고, 이를 알기 위해 사내에 배포할 수 있는 Monitoring 도구를 개발하였다고 한다.

사내에서 요구한 구체적인 조건은 아래와 같다고 한다.

  • 전체 클러스터 자원 상태 및 할당된 실험 상태 동시 표현
  • 운영자, 사용자의 서로 다른 모니터링 니즈 만족
  • 자원이나 실험의 이상 현상의 신속한 탐지
  • 문제를 디버깅할 수 있는 상세한 시스템 지표 데이터 제공

3.2 모니터링 도구 개발

전체 클러스터 자원 상태와 할당된 실험 상태를 동시에 표현하는 방법으로 Unit Visualization을 적용하였다고 한다. GPU 자원 하나를 정사각형 유닛으로, 색상 및 패턴을 매핑하여 Outlier(이상치)를 빠르게 드러낼 수 있다.

구체적으로 클러스터 노드 및 GPU 지표, 스케줄링 지표, 애플리케이션 지표를 수집하여 NSML Insight API로 묶어 시각화하였다. 웹 어플리케이션으로 구현하였으며, 운영자나 사용자의 니즈에 맞게 다양한 형태의 정보를 제공하도록 시각화할 수 있다.

이를 통하여 자원이나 실험의 이상 현상을 가시화할 수 있다고 한다. 학습 시작 시점부터 GPU 활용률 등 시스템 지표의 95%, 25% 분위값을 추적하며, 사용자가 정의한 임계치 이하의 실험들은 하이라이팅하여 빠르게 진단 도구로 분석할 수 있다.

3.3 느낀점

대규모 컴퓨팅 서버의 스케줄링 기법도 흥미로웠지만, 각각의 GPU 서버 상태를 가시화하여 방법 또한 매우 흥미로웠다. 저사용 자원을 조치하거나 엔지니어링 이슈가 발생하였을 때 이러한 시각화를 통하여 빠르게 조치를 취할 수 있다는 점이 신기하였고, 컴퓨팅 자원의 활용성과 효율성에 대해 다시 한번 고민하면서 세션을 들을 수 있었다.


4. Diagnostics

4.1 대규모 분산학습 실험 진단 도구

사내에서 NSML의 엔지니어링 이슈를 분석하고 조치하기 위하여 진단 도구 또한 개발되었다.
분산 학습(Data Parallelism, Model Parallelism)시 학습 중 여러 이유로 인하여 동기화 병목이 발생하여 일부 작업들이 지연될 수 있는데, 이 때문에 학습이 오히려 느려지거나 멈출 수 있는 문제가 발생한다.

구체적인 이유는 아래와 같다.

  • Workload imbalance로 인한 작업 지연
  • 일부 노드 / GPU 장애로 인한 연산 지연
  • 노드 간 / GPU 간 데이터 통신 지연

기존에는 GPU, 노드 관련 시스템 지표를 수집하여 대시보드 형태로 시각화하였는데, 이런 형태는 대규모 실험의 엔지니어링 이슈를 효과적으로 드러내지 못한다.

실험 규모와 데이터 복잡도가 올라갈수록 어떤 GPU가 문제인지, 어느 구간에서 잘못된 건지 문제 감지와 분석 지점 탐색이 어려우며, 문제 정형화 또한 어렵기 때문에 실험을 종료하고 다시 실행하는 등 시행착오를 반복하게 된다.

따라서 엔지니어링 이슈 진단에 대한 고수준의 분석 방향을 제공하는 진단 도구를 만들게 된다.

지표 패턴에 사진과 같이 GPU에 빨간색으로 강조된 부분으로, 어느 GPU가 장애가 있는지를 파악할 수 있는 지표 패턴과 잠재된 imbalance, outlier을 시각화하였다.

또한 시스템 지표 간 상관관계를 분석하면서 상세적인 타임라인 또한 분석할 수 있다.

이러한 진단 도구를 활용하여, 대규모 실험에서의 workload imbalance 사례와 동기화 병목을 탐지하는 등 실제 적용 사례를 통하여 효과가 있음을 입증하였다고 한다.

4.2 느낀점

대규모 서버의 상태 가시화도 중요하지만, 엔지니어링 이슈가 생겼을 때 진단 기법 또한 중요하다고 느낄 수 있는 세션이었다. 지표 간 상관관계를 분석하여 타임라인을 확인하고, 상황에 맞는 적절한 대응 조치를 통해 분산 학습시의 이슈를 해결하는 문제 해결 방법이 흥미로웠다.


5. 마치며.

지금까지 공부하던 주제에서 벗어나 다양한 세션을 들으며 다양한 주제를 얕게나마 알 수 있는 좋은 개발자 컨퍼런스였다고 생각한다. 나 자신의 Insight가 정말 넓어진 것을 스스로도 확인할 수 있을 정도로 좋은 경험이었으며, 때문에 DAY 1 신청을 하지 못한 것이 정말 아쉬웠다.

또한 다양한 분야 간의 융합이 중요하다고 생각하는 컨퍼런스였다. 지금까지 하던 분야와는 다른 주제가 정말 많았기 때문에 지금의 분야와 접목할 수 있는 아이디어들이 많이 생각났던 하루였다.

profile
어제보다 성장한 오늘

2개의 댓글

comment-user-thumbnail
2023년 3월 9일

저도 2일차 때 갔었는데, 다음에 같이 가요~!!😀

1개의 답글