Incident Library
적용된 필터 구성 요소Slurm 작업 스케줄러증상학습 작업 실패기여 요인모니터링 사각지대모두 풀기검색어 없이 필터만 적용한 목록입니다. 최근 사례부터입니다.
추천 필터 검색하면 검색어에서 찾은 분류 값이 여기에 나옵니다.

그래프

  • 원인
  • 구성 요소
  • 증상
  • 기여 요인
  • 사례

사례2건

2건 중 1~2번째

  1. 증상

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

    원인
    구성 요소
    기여 요인
    감지

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

    조치
    • 레몬 노드를 미리 찾아 Slurm 에서 격리하고 교체하는 레몬 노드 탐지를 설계해 넣었다.
    • 레몬 노드 탐지로 RSC-1 의 24대와 RSC-2 의 16대, 모두 40대의 결함 노드를 찾아냈다.
    교훈

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

  2. 증상

    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 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.

원인별1