사례3건

3건 중 1~3번째

1. IL-0477 Tencent의 1만 GPU MoE 학습에서 계산이 느려진 노드 때문에 스텝 시간이 30초에서 90초 넘게 늘었다

   Tencent2026

   증상

   GPU 약 10,000개로 돌던 MoE 학습 작업의 반복 시간이 약 30초에서 90초 넘게 늘어 ARGUS의 L1 단계가 알림을 냈다. L1은 랭크마다 반복 시간 시계열을 모아 급등과 계단식 성능 저하를 찾는 단계다.

   처리량 저하

   원인

   하드웨어 고장

   구성 요소

   –

   기여 요인

   미검증 가정

   감지

   ARGUS의 L1 단계가 반복 시간이 약 30초에서 90초 넘게 늘어난 것을 잡아 알림을 냈다. 이어서 L2 단계가 DP 그룹 안의 랭크별 mlp 단계 소요 시간을 비교해 랭크 10352~10359를 찾았다.

   조치

   • 영향받은 노드를 교체했고, 교체 직후 학습 속도가 회복되었다.

   교훈

   인프라 수준에서 보이는 통신 이상이 꼭 네트워크 하드웨어에서 생긴 것은 아니다. 계산 성능 저하가 집합 통신의 의존성을 타고 번져 통신 이상처럼 보일 수 있다. 세밀한 가시성이 없으면 운영자가 문제를 잘못 진단하고 효과 없는 조치를 할 위험이 있다. 1만 GPU 넘는 학습 클러스터에서 느려지는 고장의 형태는 매우 다양해서 진단 단계 하나로는 모든 경우를 다룰 수 없다.

   사례 보기
2. IL-0421 Alibaba 의 LLM 학습 클러스터에서 GPU 결함을 비롯한 오류로 작업이 거듭 죽어 2023년 6월 한 작업이 시간의 31.19% 를 잃었다

   Alibaba Group2025

   증상

   GPU 수천 개로 도는 LLM 학습 작업이 자주 죽었고, 사용자 눈에는 원인 대부분이 "NCCL Error" 로만 보였다. 새로 배포한 클러스터에서 GPU 4,096개를 쓰는 대표 작업은 한 달에 40번 죽었다.

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

   원인

   하드웨어 고장

   구성 요소

   GPU 하드웨어·메모리NCCLPyTorch

   기여 요인

   모니터링 사각지대미검증 가정

   감지

   사용자는 작업이 죽은 뒤 대부분 "NCCL Error" 로만 오류를 봤고, 오류가 난 뒤에도 작업이 멈춘 줄 바로 알지 못했다. PyTorch 작업은 elastic agent 가 프로세스를 죽일 때까지 최대 30분 동안 멈춰 있을 수 있었다. 원인을 찾고 결함 노드를 가려내는 일은 사람이 직접 했다. C4D 를 배포한 뒤에는 C4 에이전트가 학습 워커의 상태를 중앙 마스터로 보내고, 마스터가 워커끼리 비교해 이상을 수십 초 안에 찾았다.

   조치

   • GPU 1,024개, 곧 서버 128대마다 백업 서버 8대, 곧 백업 GPU 64개를 더 두었다. 그래서 서버 136대 풀 안의 어느 128대로도 같은 통신과 성능으로 학습을 이어 갈 수 있었다.
   • C4D 가 이상을 찾으면 작업 관리 서비스가 문제 노드를 격리하고 가장 최근의 유효한 체크포인트에서 작업을 다시 시작했다. 같은 이벤트를 백그라운드 근본 원인 분석 시스템으로 보내 오프라인으로 진단했다.
   • 고성능 인프라를 활용해 체크포인트를 더 자주 저장하게 했고, 사용자는 10분마다 체크포인트를 저장할 수 있게 되었다. 마지막 체크포인트 뒤에 잃는 시간이 33배 줄었다.
   • GPU 과열을 막으려고 팬 속도를 높이고 공조를 개선해 냉각을 강화했다.
   • 여섯 달 동안 시스템에서 가장 취약한 부품을 찾아 보강했고, 평균 오류율이 3.33배 줄었다.

   후속 조치

   • 전문가 병렬처럼 워커 사이의 부하가 고르지 않은 경우에도 느린 워커를 정확히 찾도록 C4D 에 부하 변동을 반영한다.

   교훈

   작업을 죽인 오류의 대부분은 특정 노드나 장치에 국한되어 있어서, 결함 부품만 격리하면 다수의 오류에 대처할 수 있었다. 분산 학습은 데이터 병렬 묶음 안의 계산 비용이 고르고 이터레이션마다 동기화하므로, 이 성질을 이용하면 결함 노드를 자동으로 찾을 수 있다. Alibaba 는 결함을 찾으면 곧바로 격리하고 다시 시작했으며, 깊은 원인 분석은 오프라인으로 미뤘다. 그러자 사람이 개입할 일이 없어져 수십 분 걸리던 일이 몇 초로 줄었다. 마지막 체크포인트 뒤에 잃는 시간을 줄이려면 체크포인트를 자주 저장해야 한다.

   사례 보기
3. IL-0219 Postgres 프라이머리의 디스크 어레이가 망가진 뒤 Pacemaker 가 새 프라이머리를 승격하지 못해 GoCardless API 와 대시보드가 1시간 50분 멈췄다

   GoCardless2017

   증상

   2017년 10월 10일 15:09 BST 에 모니터링이 API 와 대시보드가 완전히 멈춘 것을 찾았다. 그동안 들어온 요청은 모두 실패하고 오류를 받았다.

   서비스 중단장애 조치 실패

   촉발

   10월 10일 오후 Postgres 프라이머리 노드의 RAID 컨트롤러가 디스크 3개를 동시에 잃어 디스크 어레이가 망가졌다. 거의 같은 때 동기 복제본에서 Postgres 하위 프로세스 하나가 죽었다.

   원인

   하드웨어 고장

   구성 요소

   데이터베이스데이터베이스 장애 조치 관리자

   기여 요인

   장애 중첩미검증 가정

   감지

   15:09 BST 에 모니터링이 API 와 대시보드의 완전한 중단을 찾았고 엔지니어들이 조사를 시작했다.

   조치

   • 15:17 BST 에 디스크 어레이가 망가진 채 켜져 있는 노드를 클러스터에 두지 않으려고 망가진 Postgres 프라이머리 노드의 전원을 껐다. 클러스터는 여전히 새 프라이머리를 승격하지 않았다.
   • 15:18 BST 에 Pacemaker 가 Postgres 인스턴스 상태를 다시 파악하게 하려고 crm resource cleanup 으로 오류 횟수를 지웠지만 효과가 없었다.
   • Pacemaker 클러스터를 유지보수 모드로 두고 동기 복제본의 recovery.conf 에서 복제본 설정을 지운 뒤 유지보수 모드를 풀어 직접 승격하려 했지만, 매번 원래 recovery.conf 로 돌아갔다.
   • 16:18 BST 에 클러스터를 마지막으로 유지보수 모드로 두고 동기 복제본을 프라이머리로 설정해 Postgres 를 직접 띄웠다.
   • 클러스터가 유지보수 모드라 가상 IP 를 옮길 수 없었으므로 백엔드 애플리케이션이 새 프라이머리의 실제 IP 주소로 접속하게 다시 설정했다.
   • 평소 수준의 이중화를 되찾으려고 세 번째 노드를 비동기 복제본으로 띄웠다.
   • Pacemaker 가 유지보수 모드라 자동 페일오버가 없었으므로 인프라 팀이 손으로 관리할 가상 IP 를 하나 더 두어, 프라이머리가 망가지면 동기 복제본을 승격하고 가상 IP 를 직접 옮길 수 있게 했다.
   • 디스크 어레이 장애였으므로 생각할 수 있는 모든 시험으로 데이터 무결성을 확인했고 데이터 손상의 증거는 없었다.
   • Pacemaker 가 다시 관리하는 새 데이터베이스 클러스터를 만들고, 유지보수 시간을 공지한 뒤 문제없이 옮겼다. 옛 클러스터는 내렸다.

   후속 조치

   • Backup VIP 의 colocation 규칙을 Postgres 프라이머리와의 -INF 선호 대신 복제본과의 INF 선호로 바꿔, 같은 장애 조건에서도 동기 복제본이 승격되게 했다.
   • 특정 Postgres 인스턴스로 트래픽을 보내는 가상 IP 를 없애고, 애플리케이션 서버에서 클러스터 상태에 따라 알맞은 노드로 트래픽을 보내는 프록시를 돌려 Pacemaker 가 관리하는 자원 수를 줄인다.
   • Postgres 클러스터를 더 거칠게 시험하고, Chaos Monkey 처럼 계속 장애를 주입하는 자동화를 검토한다.
   • 장애 대응 훈련인 게임 데이에 임의의 제약을 넣는 방안을 검토한다. 예를 들어 자동화가 실패하고 원인도 찾을 수 없는 상황에서 다른 방법으로 서비스를 되살리게 한다.

   교훈

   GoCardless 는 단순해 보이는 Pacemaker 설정이 매우 이상한 동작을 부를 수 있다는 것을 배웠다. 두 자원이 함께 돌면 안 된다는 규칙과 함께 돌아야 한다는 규칙은 반대말처럼 보이지만, 특정 장애 조건에서는 시스템이 완전히 다르게 움직였다. 프로세스 두 개가 거의 동시에 죽을 때만 드러나는 설정 오류는 기본 시험이나 평소 운영으로는 찾을 수 없고, 장애 주입으로만 드러나는 버그가 있다. 자동화가 2년 동안 장애를 잘 처리하자 그 아래 인프라를 손으로 다루는 기술이 녹슬었다. 런북을 써 두어도 몇 년 뒤에 꺼내 보면 거의 확실히 낡아 있다.

   사례 보기

원인별1