Incident Library

IL-0411 Meta · 2024-10-29 (게시일)ai-infra

헬스 체크를 통과하는 레몬 노드가 Meta 연구 클러스터의 학습 작업을 거듭 실패시켰다

Meta FAIR 의 엔지니어들이 자사 연구 클러스터 RSC-1 과 RSC-2 의 11개월치 데이터를 분석한 논문이다. RSC-1 은 범용 ML 클러스터로 GPU 16k 규모이고, RSC-2 는 비전 작업 위주로 GPU 8k 규모이며, 데이터는 작업 400만 개와 A100 GPU 시간 1억 5천만 시간이 넘는다. 두 클러스터는 Slurm 으로 작업을 스케줄하고, 작업 전후와 5분마다 도는 헬스 체크로 고장 난 노드를 찾아 뺀다. 노드가 노드 안에서 도는 다른 헬스 체크에 응답하지 않으면 마지막 장치인 Slurm heartbeat 가 이를 NODE_FAIL 로 잡는다. 논문은 실패 원인이 작업 수명의 마지막 10분 안이나 끝난 뒤 5분 안에 감지되면 그 원인을 작업 실패의 원인으로 보았다.

헬스 체크는 무작위로 나는 노드 고장을 잘 찾았지만, 잘못된 설정이나 노화나 하드웨어 결함 때문에 실패가 특정 노드에 몰리는 경우가 있었다. 논문은 이런 노드를 레몬 노드라고 부르고, 작업을 거듭 실패시키지만 헬스 체크나 수리 절차 같은 기존 장치로는 찾지 못하는 서버라고 정의했다. 이런 노드는 실패한 작업이 다시 스케줄될 때마다 새 작업을 받아 다시 실패시켜 ETTR 을 떨어뜨렸다. ETTR 은 Effective Training Time Ratio 로, 쓸 수 있었던 실제 시간 가운데 작업이 의미 있게 진행된 시간의 비율이다. 연구자들이 경험으로 노드를 손으로 빼는 방식은 규모가 커지면 버티지 못했다. 논문은 학습 작업 실패의 가장 중요한 요인 가운데 하나가 NODE_FAIL 이므로 레몬 노드를 미리 다루는 일이 중요하다고 밝혔다.

팀은 노드마다 있는 수십 가지 신호 가운데 레몬 노드와 상관관계가 가장 큰 일곱 가지를 골랐고, RSC-1 의 28일치 데이터로 기준값을 정했다. 기준값은 예측한 레몬 노드의 정확도와 오탐률을 보며 손으로 조정했다. 이 탐지로 RSC-1 에서 24대, RSC-2 에서 16대, 모두 40대의 결함 노드를 85% 넘는 정확도로 찾았다. 찾은 레몬 노드는 RSC-1 전체 규모의 1.2%, 일일 작업의 13%, RSC-2 전체 규모의 1.7% 였다. 찾은 레몬 노드 가운데 85% 넘는 노드가 테스트 하나에서 실패했고, 원인은 GPU 28.2%, DIMM 20.5%, PCIE 15.4%, EUD 10.3%, NIC 7.7%, BIOS 7.7%, PSU 5.1%, CPU 2.6%, Optics 2.6% 였다. 레몬 노드 탐지로 512개 이상의 GPU 를 쓰는 대형 작업의 실패가 14% 에서 4% 로 10%포인트 줄었다.

심각도
–
영향 범위
Jobs placed on lemon nodes in RSC-1 and RSC-2; before lemon detection 14% of jobs on 512+ GPUs failed
영향 사용자
Researchers running ML jobs on RSC-1 and RSC-2
지역
–
감지까지
–
복구까지
–

증상

헬스 체크에 걸리지 않는 특정 노드들에서 학습 작업이 평균보다 자주 실패했다. 작업이 실패해 다시 스케줄되면 이 노드들이 새 작업을 또 받았고, 그 작업도 결국 실패했다. 논문은 이런 노드를 레몬 노드라고 불렀다.

레몬 노드와 상관관계가 가장 큰 노드 신호는 excl_jobid_count, xid_cnt, tickets, out_count, multi_node_node_fails, single_node_node_fails, single_node_node_failure_rate 였다. 각각 그 노드를 제외하도록 지정한 서로 다른 작업의 수, 노드가 겪은 서로 다른 XID 오류 수, 노드에 열린 수리 티켓 수, 스케줄러가 노드를 가용 상태에서 뺀 횟수, 노드 때문에 실패한 다중 노드 작업 수, 노드 때문에 실패한 단일 노드 작업 수, 노드의 단일 노드 작업 실패율이다.

피해는 큰 작업에서 컸다. 레몬 노드 탐지를 넣기 전에는 512개 이상의 GPU 를 쓰는 대형 작업의 14% 가 실패했다.

이런 노드는 빨리 찾기 어려웠다. 통계적으로 의미 있는 판단을 하려면 오랜 기간의 실패 기록을 봐야 했다. 실패율이 특정 노드에 몰려 있었기 때문에 팀은 하드웨어가 낡아 가거나 노드에 잘못 설정된 소프트웨어가 돌고 있다고 의심했다.

처음에는 연구자들이 경험에 기대 작업을 실패시키는 노드를 손으로 제외했다. 이 방식은 규모가 커지면 버티지 못했고, 노드를 너무 많이 빼면 용량이 모자랄 수 있었다. RSC-1 의 28일치 데이터를 보니 적지 않은 노드가 적어도 한 작업에서 제외됐지만, 사용자가 남긴 excl_jobid_count 신호는 노드 실패와 상관관계가 강하지 않았다.

증상 학습 작업 실패

원인

원인 하드웨어 고장

구성 요소 GPU 하드웨어·메모리Slurm 작업 스케줄러
기여 요인 모니터링 사각지대
촉발
–

감지

팀은 일부 노드의 작업 실패율이 평균보다 높다는 것을 보고 문제를 알았다. 실패율이 특정 노드에 몰려 있었지만, 통계적으로 의미 있게 판단하려면 오랜 기간의 실패 기록을 봐야 해서 빨리 찾기는 어려웠다.

조치

후속 조치

–

교훈

논문은 결함 있는 노드를 찾으려면 과거 기록이 꼭 필요하다고 밝혔다. 레몬 노드 탐지를 넣으면 대형 작업의 완료율을 30% 넘게 높일 수 있다. 결함 있는 노드에 작업이 거듭 스케줄되면 실패가 잇따르므로, 그런 노드를 확실히 빼낼 수 있어야 무작위 고장에서 회복하는 장치도 제대로 효과를 낸다. 노드를 빼는 부담을 ML 개발자에게 맡기지 않고 레몬 노드를 미리 찾아야 한다.

출처

관련 사례

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

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: GPU 하드웨어·메모리, Slurm 작업 스케줄러. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

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