Incident Library

IL-0585 Microsoft · 2019-08-08 (게시일)ai-infra

Philly GPU 클러스터의 학습 작업이 오래 실행된 뒤 모델 체크포인트를 만들지 못해 실패했다

Microsoft Research 의 연구진은 Microsoft 안에서 딥러닝 모델 학습을 맡는 서비스 Philly 의 다중 테넌트 GPU 클러스터 하나에서 2017년 10월부터 12월까지 75일 동안 작업 96,260개의 로그를 모아 분석했다. 이 클러스터는 서버 수백 대와 같은 모델의 GPU 수천 개로 이루어졌고, 분산 저장소로 HDFS 를, 리소스 관리자로 Apache YARN 을 썼다. 학습 입력 데이터는 HDFS 에 있었다. 실패한 작업은 정해진 횟수만큼 다시 실행됐고, 그래도 실패하면 unsuccessful 로 끝났다.

연구진은 실패한 작업의 stdout 과 stderr 로그를 230개가 넘는 규칙으로 분류했다. 그렇게 나눈 실패 원인 가운데 하나가 모델 체크포인트 오류였다. 이 오류는 작업이 에포크를 일정 수 마친 뒤 모델 체크포인트를 만들지 못할 때 났고, 대개 HDFS 의 일시적인 오류나 HDFS 네임노드 복구 때문이었다. 75일 동안 1,995번의 실패가 작업 948개와 사용자 85명에게서 나왔다. 실패까지의 실행 시간 중앙값이 181.67분이어서 대개 10분 안에 나는 사용자 코드 오류보다 훨씬 늦게 났다. 그래서 횟수는 많지 않았지만 실패한 작업이 쓴 실행 시간의 21.73%를, GPU 시간으로는 16.33%를 차지했다.

심각도
–
영향 범위
Deep learning training jobs on one Philly GPU cluster from October to December 2017: 1,995 failure events in 948 jobs, 16.33% of the GPU time lost to failures
영향 사용자
85 users
지역
–
감지까지
–
복구까지
–

증상

Philly 클러스터의 딥러닝 학습 작업이 에포크를 일정 수 마친 뒤 모델 체크포인트를 만들지 못하고 실패했다. 실패는 작업이 오래 돈 뒤에 났고, 실패까지 걸린 실행 시간의 중앙값이 181.67분이었다.

2017년 10월부터 12월까지 75일 동안 모은 로그에서 이 실패는 1,995번 일어났고, 작업 948개와 사용자 85명에게 걸쳐 있었다. 실패까지 걸린 실행 시간은 90번째 백분위수가 3,728.93분, 95번째 백분위수가 8,196.02분이었다.

실패한 시도를 작업이 요청한 GPU 수에 따라 나누면 GPU 1개 작업이 743번, GPU 2~4개 작업이 384번, GPU 4개를 넘는 작업이 868번이었다. 실패한 작업들이 실패하기까지 쓴 실행 시간을 모두 더하면 그중 21.73%가 이 오류였다. 실행 시간에 GPU 수를 곱한 GPU 시간으로 따지면 16.33%였다.

모델 체크포인트 오류는 인프라 쪽 실패로 분류됐다. 모델 체크포인트 오류와 MPI 런타임 실패를 합쳐도 전체 실패 시도의 6.2%에 그쳤다. 하지만 두 오류는 오래 실행된 뒤에 나타나서 실패를 알아채기까지 걸리는 시간의 큰 몫을 차지했다. 이 점에서 사용자 코드의 문법 오류나 설정 오류처럼 대개 10분 안에 드러나는 실패와 달랐다.

증상 학습 작업 실패스토리지 연결 끊김

원인

원인 의존성 장애

구성 요소 공유 네트워크 파일 시스템
기여 요인 –
촉발
체크포인트를 만들 때 HDFS 에서 일시적인 오류가 나거나 HDFS 네임노드가 복구 중이었다.

감지

실패한 작업은 스케줄러가 정해진 횟수만큼 다시 실행했고, 계속 실패하면 unsuccessful 로 표시했다. 연구진은 실패한 작업의 stdout 과 stderr 로그에서 230개가 넘는 규칙으로 실패 원인의 시그니처를 찾아 이 오류를 가려냈다.

조치

–

후속 조치

–

교훈

논문은 HDFS 같은 클러스터 구성 요소 때문에 난 실패가 학습 과정의 훨씬 뒤에서 나타난다고 정리했다. 모델 체크포인트 오류와 MPI 런타임 실패는 드물지만 오래 실행된 뒤에 나타나 실패를 알아채기까지 걸린 시간의 큰 몫을 차지했다. 논문은 학습 작업이 남기는 오류 메시지를 실시간으로 분류하고, 실패 종류에 따라 재시도 횟수 같은 스케줄링 값을 작업마다 바꾸는 시스템이 쓸모 있다고 했다. 예를 들어 잘못된 입력 같은 실패는 재시도를 멈추고, 네트워크 타임아웃은 계속 재시도한다.

출처

참고 문서

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 공유 네트워크 파일 시스템. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.