사례10건

10건 중 1~5번째

1. IL-0160 고쳐서 다시 돌린 레거시 GPU 모니터링 스크립트의 펌웨어 조회가 GSP 레이스 컨디션을 일으켜 Linode 의 RTX 4000 Ada GPU 가 잠기고 LKE 워커 노드의 GPU 작업이 멈췄다

   Linode2026

   증상

   2026년 3월 4일 21:00 UTC 무렵부터 NVIDIA RTX 4000 Ada GPU 를 쓰는 Linode 인스턴스가 잠기기 시작했다. 처음에는 Linode Kubernetes Engine 의 워커 노드만 겪는 문제로 보였지만, 나중에 이 하드웨어를 쓰는 모든 Linode 가 영향을 받은 것으로 확인됐다. 일반 컴퓨트 인스턴스와 RTX 4000 이 아닌 GPU 인스턴스는 영향이 없었다.

   GPU 인식 불가컨트롤 플레인 무응답

   촉발

   내부 관측 대시보드에서 빠진 지표를 되살리려고 고장 난 레거시 GPU 모니터링 스크립트를 고쳐 배포했다.

   원인

   배포 결함

   구성 요소

   텔레메트리 에이전트GPU 드라이버

   기여 요인

   리뷰 누락미검증 가정

   감지

   고객은 21:00 UTC 무렵부터 잠김을 겪었고, 상태 페이지 첫 공지는 약 5시간 뒤인 3월 5일 02:07 UTC 에 올라왔다. 처음에는 LKE 워커 노드에서만 생기는 문제로 보였다.

   조치

   • 모든 GPU 에서 문제의 모니터링 스크립트를 껐다.
   • 영향을 받은 노드를 재부팅했다.

   후속 조치

   • 재발을 막을 개선 조치와 예방 조치를 마련한다.

   교훈

   모니터링 스크립트가 자기가 지켜보는 하드웨어를 멈출 수 있다. 빠진 지표 하나를 되살리려던 수정이 이전 세대 GPU 용으로 쓴 펌웨어 조회까지 되살렸다. RTX 4000 Ada 아키텍처에서는 동작 중인 GPU 에 이 조회를 보내면 GPU 가 잠긴다. 스크립트가 모든 GPU 에서 돌았기 때문에 여러 리전에서 이 GPU 를 쓰는 모든 Linode 가 영향을 받았다. 엔지니어들은 처음에 호스트 하이퍼바이저나 GPU 펌웨어의 회귀를 의심했다.

   사례 보기
2. IL-0134 AUS01 데이터센터에 전력 문제가 생겨 GPU 노드 246대와 스파인 스위치, VAST 스토리지가 한꺼번에 재부팅됐고, 워크로드가 실패하고 NFS 마운트가 끊겼다.

   Lambda2026sev1

   증상

   2026년 2월 14일 21:06 UTC 에 AUS01 데이터센터의 GPU 노드가 모두 동시에 재부팅됐다. 노드는 곧 다시 올라왔지만, 계획에 없던 재부팅이었고 여러 고객이 영향을 받았다.

   GPU 인식 불가스토리지 연결 끊김

   촉발

   AUS01 데이터센터에 전력 문제가 생겨 전원이 끊겼다.

   원인

   의존성 장애

   구성 요소

   데이터센터 전력·냉각InfiniBand 패브릭공유 네트워크 파일 시스템

   기여 요인

   –

   조치

   • 컴퓨트 패브릭과 InfiniBand 연결을 복구해 스파인 스위치 4대 전부와 대부분의 리프 스위치를 다시 온라인으로 올렸다.
   • UPS 이중화를 일부 복구하고, 스토리지와 보호 전원을 완전히 되살리는 작업을 이어 갔다.
   • AUS01 의 모든 노드 전원을 올리고 물리 점검을 마친 뒤 스토리지를 다시 올렸다.
   • us-west-3 의 Starbase 와 스토리지에 의존하는 다른 서비스를 복구했다.
   • NFS 마운트가 stale 상태이거나 비어 있는 고객에게 VM 을 재부팅하라고 안내했고, VM 재부팅으로 풀리지 않으면 하이퍼바이저 재부팅이 필요하다고 알렸다.

   교훈

   전원이 끊겨 GPU 노드와 함께 네트워크 스파인과 공유 스토리지까지 재부팅되면, 노드 자체가 다시 뜨는 것보다 전체 복구가 훨씬 오래 걸린다. GPU 노드는 곧 다시 올라왔지만, 팀은 패브릭을 먼저 되살렸고 스토리지는 물리 점검을 마친 뒤에야 다시 올렸다. 일부 VM 에는 stale 상태의 NFS 마운트가 남아, Lambda 는 고객에게 VM 을 재부팅하고 그래도 안 되면 하이퍼바이저를 재부팅하라고 안내했다.

   사례 보기
3. IL-0171 Bottlerocket AMI 에 libdcgm.so 가 없어 GPU 노드의 AcceleratedHardwareReady 가 False 가 됐고, Karpenter 노드 자동 복구가 Ready 뒤 10~11분마다 GPU 노드를 교체하는 일을 끝없이 되풀이했다.

   Inflab2025

   증상

   강의 영상 업스케일링용 GPU 파드를 띄우자 GPU 노드가 정상적으로 만들어져 Ready 가 됐다가, 약 10~11분 뒤 갑자기 비정상으로 판정되어 Karpenter 가 노드를 교체했다. 새로 만든 노드에서도 같은 일이 되풀이됐고, GPU 파드가 계속 재시작되어 작업이 진행되지 않았다.

   노드 재생성 반복GPU 인식 불가

   촉발

   kubelet OOM 으로 생기던 좀비 노드를 정리하려고 Karpenter 설정에서 nodeRepair 기능 게이트를 켰다.

   원인

   소프트웨어 결함

   구성 요소

   Karpenter노드 운영체제 이미지GPU 드라이버

   기여 요인

   자동화 증폭미검증 가정

   감지

   GPU 노드가 Ready 뒤 10~11분 만에 계속 교체되는 것을 보고 노드 이벤트를 분석해 DCGMError 메시지를 찾았다.

   조치

   • Karpenter 설정에서 nodeRepair 기능 게이트를 false 로 바꿔 Node Auto-Repair 를 껐다.

   교훈

   Karpenter Node Auto-Repair 는 AcceleratedHardwareReady=False 도 노드를 교체할 사유로 본다. 그래서 GPU 연산에는 문제가 없어도 GPU 모니터링 라이브러리 하나가 빠지면 노드가 끝없이 교체될 수 있다. Node Auto-Repair 를 켠 뒤 GPU 노드가 자주 교체되면 이 기능을 꺼 볼 만하다. 좀비 노드 문제는 이제 메모리가 4GB 이상인 인스턴스 타입을 써서 완화했다.

   사례 보기
4. IL-0120 클라우드 GPU 서버의 정기 OS 업데이트가 systemd-networkd 를 재시작해 자체 네트워크 에이전트와 충돌했고, 많은 GPU 노드의 라우트가 모두 지워져 ChatGPT 와 API 의 오류율이 크게 올랐다.

   OpenAI2025

   증상

   6월 9일 오후 11시 36분 PDT 에 여러 서비스에서 동시에 알림이 울렸다. 인프라가 네트워크 연결을 잃기 시작했고, 상황은 바로 엔지니어링 팀에 에스컬레이션됐다.

   오류율 상승GPU 인식 불가

   촉발

   매일 예약된 호스트 OS 업데이트가 영향받은 노드에서 네트워크 관리 서비스인 systemd-networkd 를 의도치 않게 재시작했다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   systemd-networkd노드 운영체제 이미지

   기여 요인

   단계적 배포 부재디버그 접근 제한

   감지

   장애가 시작된 6월 9일 오후 11시 36분 PDT 에 인프라가 네트워크를 잃기 시작하면서 여러 서비스의 알림이 바로 울렸고, 상황은 즉시 엔지니어링 팀에 에스컬레이션됐다.

   조치

   • 6월 10일 오전 2시부터 영향받은 GPU VM 을 대규모로 다시 이미징했다.
   • 6월 10일 오전 6시 49분에 복구 자동화를 배포해 아직 영향받은 상태인 나머지 노드를 재시작했다.
   • 백그라운드에서 도는 업데이트를 멈췄다.

   후속 조치

   • GPU VM 의 매일 자동 업데이트를 끄고, 업데이트는 직접 정한 일정에 맞춰서만 하도록 바꿨다.
   • systemd-networkd 와 자체 네트워크 서비스가 충돌하지 않도록 시스템 설정을 고쳤다.
   • 전체 VM 설정을 감사해 비슷한 위험을 찾아 줄인다.
   • GPU VM 과 클러스터 같은 핵심 인프라의 복구 속도를 높이는 작업에 우선순위를 둔다.
   • 대응 능력을 높이려고 재해 복구 훈련을 정기적으로 계획한다.

   교훈

   호스트 OS 의 자동 업데이트가 네트워크 관리 서비스를 재시작하면, 같은 노드에서 라우트를 관리하는 다른 에이전트와 충돌해 노드 전체가 네트워크를 잃을 수 있다. 매일 도는 업데이트는 모든 노드에 거의 같은 시각에 적용된다. 네트워크가 끊긴 노드를 빠르게 되살릴 비상 도구가 없으면 노드를 다시 이미징할 수밖에 없고 복구가 길어진다.

   사례 보기
5. IL-0127 Llama 3 405B 사전 학습 54일 동안 학습 작업이 예기치 않게 419번 중단되었고, 주된 원인은 GPU 와 HBM3 메모리 고장이었다

   Meta2024

   증상

   Meta 는 최대 16K 개의 H100 GPU 로 Llama 3 405B 를 사전 학습했다. 54일 동안의 기록에서 학습 작업은 모두 466번 중단되었고, 그중 419번이 예기치 않은 중단이었다. 나머지 47번은 펌웨어 업그레이드 같은 자동 유지보수나, 설정과 데이터셋 갱신 같은 운영자 작업에 따른 계획된 중단이었다.

   학습 작업 실패GPU 인식 불가NCCL 타임아웃

   원인

   하드웨어 고장

   구성 요소

   GPU 하드웨어·메모리NCCLPyTorch

   기여 요인

   단일 장애점

   감지

   PyTorch 의 NCCL flight recorder 가 모든 통신 이벤트와 집합 연산마다 걸린 시간을 링 버퍼에 기록했고, NCCLX 워치독이나 하트비트 타임아웃이 나면 추적 데이터를 자동으로 덤프했다. NCCLX 는 통신 라이브러리 상태를 감시하다가 멈춤을 감지하면 자동으로 타임아웃시켰고, 실패한 집합 연산의 내부 상태 스냅샷을 남겼다. 느린 GPU 는 의심스러운 통신에 우선순위를 매겨 보여 주는 도구로 찾았다. 대개 상위 몇 개만 조사해도 찾아낼 수 있었다.

   조치

   • 대부분의 중단은 자동화가 처리했고, 사람이 크게 손을 대야 했던 것은 54일 동안 세 번뿐이었다.

   후속 조치

   • 작업 시작 시간과 체크포인트 시간을 줄였다.
   • PyTorch 의 NCCL flight recorder 로 모든 통신 이벤트와 집합 연산 시간을 기록하고, NCCLX 워치독이나 하트비트 타임아웃이 나면 추적 데이터를 자동으로 덤프하게 했다.
   • 계산이 많이 드는 추적과 메타데이터 수집은 운영 중에 필요할 때만 켜게 했다. 켜고 끄는 일은 코드를 배포하거나 작업을 재시작하지 않고 온라인 설정 변경으로 하게 했다.
   • PyTorch 가 NCCLX 의 내부 상태에 접근하게 해 멈춤을 더 빨리 감지하고 멈춘 위치를 찾게 했다. 실패한 집합 연산의 끝난 전송과 남은 전송은 스냅샷으로 남기게 했다.

   교훈

   동기식 학습은 GPU 하나의 고장에도 작업 전체가 멈출 수 있어 고장에 약하다. 하드웨어 고장은 멈춤으로만 나타나지 않고 느린 straggler 로도 나타나며, straggler 하나가 GPU 수천 개를 느리게 만들 수 있다. 이 규모에서는 기온과 전력망 같은 환경 요인도 학습 성능과 운영에 영향을 준다.

   사례 보기

원인별5