사례2건
2건 중 1~2번째
- 증상
헬스 체크에 걸리지 않는 특정 노드들에서 학습 작업이 평균보다 자주 실패했다. 작업이 실패해 다시 스케줄되면 이 노드들이 새 작업을 또 받았고, 그 작업도 결국 실패했다. 논문은 이런 노드를 레몬 노드라고 불렀다.
- 원인
- 구성 요소
- 기여 요인
- 감지
팀은 일부 노드의 작업 실패율이 평균보다 높다는 것을 보고 문제를 알았다. 실패율이 특정 노드에 몰려 있었지만, 통계적으로 의미 있게 판단하려면 오랜 기간의 실패 기록을 봐야 해서 빨리 찾기는 어려웠다.
- 조치
- 레몬 노드를 미리 찾아 Slurm 에서 격리하고 교체하는 레몬 노드 탐지를 설계해 넣었다.
- 레몬 노드 탐지로 RSC-1 의 24대와 RSC-2 의 16대, 모두 40대의 결함 노드를 찾아냈다.
- 교훈
논문은 결함 있는 노드를 찾으려면 과거 기록이 꼭 필요하다고 밝혔다. 레몬 노드 탐지를 넣으면 대형 작업의 완료율을 30% 넘게 높일 수 있다. 결함 있는 노드에 작업이 거듭 스케줄되면 실패가 잇따르므로, 그런 노드를 확실히 빼낼 수 있어야 무작위 고장에서 회복하는 장치도 제대로 효과를 낸다. 노드를 빼는 부담을 ML 개발자에게 맡기지 않고 레몬 노드를 미리 찾아야 한다.
- 증상
tr1-13B 학습이 여러 시간 돌다가 iteration 43680 에서 죽었고, Slurm 이 이어서 띄운 다음 작업도 시작하자마자 죽었다.
- 촉발
학습에 배정된 노드 하나의 GPU 에 하드웨어 문제가 생겨 정정할 수 없는 ECC 오류가 났다.
- 원인
- 구성 요소
- 기여 요인
- 감지
첫 충돌 때는 아무도 지켜보지 않았고, 스케줄러가 띄운 다음 작업도 죽은 뒤에야 문제를 알았다. 팀은 두 번의 실패를 보고 GPU 하드웨어 문제를 의심했고, JZ 관리자에게 물어 노드 하나가 고장 난 것을 확인했다.
- 조치
- JZ 관리자에게 연락해 노드 하나가 고장 난 것을 확인했다.
- 다음 학습 작업이 고장 난 노드에 배정되지 않아 학습이 이어졌다.
- 후속 조치
- `#SBATCH --output=%x-%j-%N.out` 처럼 출력 파일 이름에 `%N` 을 넣어 노드마다 로그 파일을 따로 남기고, 그 로그로 어느 노드의 GPU 가 고장인지 가린다.
- 고장 난 노드의 호스트 이름을 알아내면 `sbatch --exclude=node1,node2,... ` 로 다음 작업에서 그 노드를 뺀다.
- 교훈
예외가 난 노드의 호스트 이름을 알 수 없으면, 다음 작업이 고장 난 노드에 다시 배정돼 학습이 거듭 죽는다. 호스트 이름을 알면 `sbatch --exclude` 로 그 노드를 뺄 수 있으므로, 예외와 노드를 이어 주는 수단이 꼭 있어야 한다.
이 2건에서 가장 많이 나오는 구성 요소: GPU 하드웨어·메모리, Slurm 작업 스케줄러. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.