사례4건

4건 중 1~4번째

1. IL-0137 60노드 B200 학습 클러스터에서 노드들의 작은 랜덤 I/O 가 VAST 스토리지의 메타데이터 서비스를 포화시켜 학습 초기화가 8시간 넘게 걸렸다

   Lablup Inc2026

   증상

   60노드 B200 학습 구성을 운영 규모로 늘리자 VAST 스토리지에서 학습을 초기화하는 단계가 몇 분이 아니라 8시간 넘게 걸렸다. 그동안 처리량은 이론상 한계보다 훨씬 낮게 머물렀다. 2~4노드 규모로 한 초기 검증에서는 큰 문제가 없었다.

   처리량 저하

   촉발

   학습 구성을 2~4노드 시험 규모에서 60노드 운영 규모로 늘렸다.

   원인

   용량 한계

   구성 요소

   공유 네트워크 파일 시스템

   기여 요인

   스테이징 불일치모니터링 사각지대

   감지

   운영 규모로 늘린 뒤 학습 초기화가 몇 분이 아니라 8시간 넘게 걸리면서 드러났다. 애플리케이션 로그로는 초기화 지연만 보였다. 원인은 다섯 조직이 함께 쓰는 모니터링 파이프라인에서 애플리케이션, 스케줄러, 네트워크, 스토리지 지표를 같은 타임라인에 맞춰 본 뒤에야 찾았다.

   조치

   • 애플리케이션 쪽에서 Arrow 파일을 rank 별로 나누는 파일 샤딩을 적용했다.
   • 스토리지 쪽에서 동기 rm/unlink 대신 비동기 삭제를 쓰도록 바꿨다.
   • readahead 설정을 조정했다.

   교훈

   2~4노드 규모에서 본 성능 특성으로는 60노드에서 어떻게 동작할지 예측할 수 없었다. 이런 스토리지와 메타데이터 병목은 운영 규모에서만 드러나므로 작은 규모의 사전 시험으로는 찾기 어렵다. 이 규모에서는 한 팀이 따로 하는 모니터링만으로 근본 원인을 찾을 수 없었고, 조직 경계를 넘어 지표를 공유하는 파이프라인이 있어야 했다. GPU 용량을 늘리면서 그에 맞는 스토리지 처리 경로를 갖추지 않으면 운영 규모에서만 보이는 급격한 성능 저하가 생긴다.

   사례 보기
2. IL-0025 H100 4,088개 클러스터를 구축하는 동안 InfiniBand 배선 오류, 링크 플래핑, GPU 와 PCIe 하드웨어 결함이 학습을 멈추거나 늦췄다

   Imbue2024

   증상

   Imbue 는 H100 GPU 4,088개를 서버 511대에 나눠 담은 클러스터를 베어 메탈부터 구축하고 그 위에서 70B 모델을 학습했다. 처음 마주친 것은 장비 자체였다. 서버의 약 10% 가 주로 물리적 문제로 부팅되지 않았고, InfiniBand 네트워크를 관리하는 Unified Fabric Manager, 줄여서 UFM 은 처음에 스위치 320대를 하나도 찾지 못했다.

   링크 플래핑NCCL 타임아웃처리량 저하GPU 인식 불가학습 작업 실패

   촉발

   새로 들인 H100 4,088개 클러스터를 베어 메탈 상태에서 처음 구축하면서, 잘못 설계된 InfiniBand 배선과 불량 하드웨어, 펌웨어, 드라이버 문제가 차례로 드러났다.

   원인

   의존성 장애

   구성 요소

   InfiniBand 패브릭NCCLGPU 드라이버PyTorch

   기여 요인

   미검증 가정모니터링 사각지대부분 배포

   감지

   UFM 경고, 호스트 헬스 체크, DCGM 과 Prometheus 지표, 학습 중 MFU 와 NCCL 워치독 오류로 문제를 알아챘다. InfiniBand 포트 문제는 포트를 실제로 쓸 때만 드러나서, 모든 포트에 부하를 거는 번인 작업을 만들어 더 효율적으로 찾았다. 멈춤을 일으킨 호스트는 특정 로그를 남기지 않은 호스트를 찾는 방식으로 가려냈다. 팀은 배치마다 순간 MFU 를 살펴보고, MFU 가 떨어지는 곡선 모양으로 문제 종류를 구분했다.

   조치

   • 고장 난 기계를 찾는 점검을 자동화하고, 일부 기계는 Dell 에 돌려보내 다시 시험받게 했으며 데이터센터 직원에게 티켓을 올렸다.
   • GPU 와 내부 PCIe 케이블을 다시 장착했고 펌웨어 업그레이드를 적용했다.
   • 온도 값을 틀리게 만든 NVIDIA 드라이버를 이전 버전으로 내렸다.
   • InfiniBand 패브릭의 최상위 계층을 하나의 네트워크로 다시 배선하고, 배선이 설계와 맞는지 확인하는 점검을 추가했다.
   • 경고를 내는 포트를 청소하고 다시 꽂았고, 그래도 경고가 남은 트랜시버는 껐다.
   • 모든 InfiniBand 포트에 번인 작업을 돌려, 버티지 못한 포트를 껐다.
   • 커널 모듈을 추가하고 PCIe ACS 를 꺼서 GPUDirect RDMA 를 켰다.
   • 자동 가비지 컬렉션을 끄고 모든 호스트에서 정해진 간격으로 가비지 컬렉션을 돌렸다.

   후속 조치

   • 호스트가 학습에 쓸 만한지 예 또는 아니오로 답하는 헬스 체크를 만들었다. GPU, 디스크 공간, Docker, dmesg, iDRAC, 디스크, InfiniBand, NVLink, GDR, VBIOS, Flint, PSB 점검이 들어 있고, iDRAC 과 PSB 점검을 뺀 나머지를 공개했다.
   • 오류와 멈춤 주변의 로깅을 늘린 NCCL 패치를 공개했다.
   • GPU 스트레스 테스트와 NVLink, InfiniBand 네트워크 테스트를 공개했다.
   • UFM 이벤트 로그를 파싱해 어떤 네트워크 포트를 꺼야 할지 정하는 스크립트를 공개했다.
   • 모든 InfiniBand 링크를 쓰게 하는 번인 작업을 만드는 스크립트를 공개했다.
   • 학습이 죽으면 헬스 체크를 통과한 기계로 마지막 체크포인트부터 자동으로 다시 시작하게 했다.
   • 경고가 나서 꺼 둔 트랜시버를 교체품이 오면 바꾼다.

   교훈

   대형 GPU 클러스터에서는 연결 하나만 조금 불안해도 전체 학습이 느려질 수 있다. Imbue 는 학습에 필요한 것보다 10-20% 많은 기계를 두면 고장 난 기계를 쉽게 바꿔 다시 시작할 수 있다고 정리했다. 학습 중 겪는 문제는 모두 다시 일어나므로, 겪은 하드웨어와 소프트웨어 장애마다 테스트와 자동 처리를 만들 가치가 있다. 알아보기 어려운 오류 메시지마다 그 오류를 읽기 쉽게 만드는 도구를 만드는 것도 마찬가지다. Imbue 는 재현성을 지키려고 아주 단순한 일도 한 번에 하나씩만 바꿨다. 외부 도구를 들이거나 새 사람이 합류하면 그쪽이 내놓은 주장을 다시 확인했고, 다음 단계가 그 결과에 기댈 때는 특히 그렇게 했다. 고장은 고르게 나지 않고 소수의 문제 기계에 몰리므로, 그때그때 고장 나는 기계를 하나씩 고치기보다 믿을 수 있는 기계 묶음을 키우는 편이 낫다.

   사례 보기
3. IL-0116 CNI 설정 변경이 스테이징에 없던 하드웨어 종류와 호환되지 않아 GPU 클러스터 하나의 워크로드가 네트워크 연결을 잃었고, text-davinci-003 모델이 완전히 멈췄다.

   OpenAI2023

   증상

   2023년 1월 25일 태평양 시각 오후 4시 53분, GPU 클러스터 하나에 큰 장애가 나서 text-davinci-003 모델이 완전히 멈췄다.

   서비스 중단처리량 저하

   촉발

   컨테이너에 네트워크 연결을 제공하는 CNI 플러그인의 설정을 바꿨고, 이 변경이 운영에만 있는 하드웨어 종류를 쓰는 클러스터에 배포됐다.

   원인

   설정 변경

   구성 요소

   CNI 플러그인

   기여 요인

   스테이징 불일치모니터링 사각지대

   감지

   엔지니어들은 네트워크 연결 문제임을 곧바로 알아봤지만, CNI 가 원인임을 밝히는 데 거의 한 시간이 걸렸다.

   조치

   • CNI 를 원인으로 찾은 뒤 수정을 적용해 트래픽의 80% 를 바로 되살렸다.
   • 이후 약 3시간에 걸쳐 모델을 GPU 에 다시 올려 용량을 완전히 안정시켰다.

   후속 조치

   • 스테이징 환경에 가능한 모든 하드웨어 구성을 갖춰 운영 환경과 더 가깝게 만든다.
   • CNI 시스템 자체의 상태를 직접 모니터링하고 알림을 걸어 장애가 더 잘 보이게 한다.
   • 모델 복제본을 빠르게 대량으로 배포하지 못하게 막는 네트워크와 스토리지 인프라의 병목을 고친다.

   교훈

   변경을 스테이징에서 충분히 시험해도, 운영에만 있는 하드웨어 종류가 스테이징에 없으면 문제를 잡지 못한다. 다른 클러스터에 24시간 동안 배포돼 안전하다고 본 변경도, 하드웨어가 다른 클러스터에서는 깨졌다.

   사례 보기
4. IL-0032 mutating admission controller 의 JSON 패치 버그로 일주일 동안 새 코드가 배포되지 않았고, 운영 서비스 하나는 파드가 두 개만 남아 오류율이 치솟았다

   Airbnb2020

   증상

   운영 서비스 하나에서 오류율이 높아졌고 그 서비스는 배포도 되지 않았다. 배포할 때 인덱스 5에 접근할 수 없다는 뜻의 unable to access invalid index 오류가 났는데, 처음에는 무슨 뜻인지 알기 어려웠다.

   오류율 상승처리량 저하배포 실패

   촉발

   지난 한 달 사이에 도입한 mutating admission controller 에 변경이 들어갔고, 그 뒤로 컨트롤러가 배열에서 항목 두 개를 지우는 JSON 패치를 잘못된 순서로 만들었다. 이 변경은 장애가 드러나기 7일 전에 적용되어 있었다.

   원인

   소프트웨어 결함

   구성 요소

   어드미션 웹훅수평 파드 오토스케일러

   기여 요인

   늦게 드러난 변경모니터링 사각지대초기 신호 무시

   감지

   운영 서비스의 오류율이 높아지고 배포가 실패하면서 드러났다. 지표는 이미 있었지만 그 지표에 걸린 알림이 없어, 7일 동안 배포가 실패하는 것을 아무도 알아채지 못했다.

   조치

   • 해당 클러스터에서 mutating admission controller 를 지워 파드가 다시 정상적으로 뜨게 했다.

   후속 조치

   • 이 문제를 더 일찍 잡을 수 있었던 기존 지표에 알림을 건다.

   교훈

   클러스터에 mutating admission controller 가 있다는 사실을 늘 염두에 둔다. 최근에 도입한 것이라 장애가 났을 때 팀원 대부분이 이를 먼저 떠올리지 못했다. 막히면 도움을 청한다. 동료를 호출한 뒤에야 조사가 진척됐다. 오류 문구를 검색한다. 처음 보고된 오류 문구를 바로 검색했다면 이미 알려진 문제라는 것을 훨씬 일찍 알았을 것이다. 알림을 만든다. 문제를 일찍 잡을 수 있는 지표가 있었지만 알림이 없었다.

   사례 보기

원인별4