사례8건

8건 중 3~7번째

1. IL-0586 T0 스위치 트랜시버의 링크 네 개가 연달아 플래핑해 50K GPU 사전 학습 작업의 처리량이 1분 동안 약 25% 떨어졌다

   OpenAI2026

   증상

   OpenAI 의 Cluster A 에서 50K GPU 로 돌던 운영 사전 학습 작업의 처리량이 1분 동안 약 25% 떨어졌다. 같은 시각 T0 스위치 한 대의 광 트랜시버에 달린 링크 네 개가 짧은 간격으로 연달아 내려갔다 올라왔다.

   링크 플래핑처리량 저하

   촉발

   T0 스위치의 광 트랜시버 하나가 순간적으로 오작동해 그 트랜시버의 링크 네 개가 짧은 간격으로 연달아 플래핑했다.

   원인

   하드웨어 고장

   구성 요소

   NIC·케이블·스위치 포트 링크

   기여 요인

   –

   감지

   NIC 와 T0 스위치가 각각 링크가 내려간 것을 기록했고, 두 기록의 시각은 정확히 같지 않았다. 작업 처리량 그래프와 노드별 패킷 손실률 그래프에 이 사건이 나타났다.

   조치

   • MRC 가 플래핑으로 잃은 패킷을 빠르게 복구해서 작업이 받은 영향은 비교적 작았다.

   교훈

   논문은 NIC 와 T0 사이의 링크를 잃으면 성능이 떨어진다고 했다. 다만 이런 사건은 대부분 잠깐이고, 작업이 노드를 빼지 않고도 금방 원래 속도로 돌아오는 경우가 많다고 했다. NIC 와 T0 사이의 링크와 T0 스위치는 눈에 띄는 영향을 주므로 T1 스위치보다 더 조심해서 다뤄야 한다고 했다. 단일 장애 지점도 남아 있다고 했다. 800 Gb/s NIC 광 모듈을 200 Gb/s 링크 네 개로 나눠 쓰므로 NIC 쪽 트랜시버 자체가 플래핑하면 그 NIC 의 포트를 모두 잃는다. 그러면 QP 가 실패하므로 작업이 이 상황을 견디지 못한다. 논문은 다른 광 설계를 쓰면 이 문제를 아예 피할 수 있을 것이라고 했다.

   사례 보기
2. IL-0476 ByteDance의 128대 V100 학습 작업이 머신 한 대의 PCIe 저하로 40분 동안 크게 느려졌다

   ByteDance2025

   증상

   128대 머신으로 돌던 분산 학습 작업이 멈추지는 않고 40분 동안 심하게 느려졌다. 수천 개의 V100 GPU가 그동안 계산 자원을 다 쓰지 못한 채 느리게 돌았다.

   처리량 저하

   촉발

   머신 한 대의 PCIe 링크가 6.4Gbps에서 4Gbps로 떨어졌다.

   원인

   하드웨어 고장

   구성 요소

   PCIe 링크InfiniBand 패브릭

   기여 요인

   한계 경보 부재

   감지

   작업이 멈추지 않아 알림이 오지 않았다. 여러 팀이 40분 동안 손으로 진단한 끝에 고장 난 머신을 찾았다.

   후속 조치

   • 모니터링 지표로 고장 난 머신을 자동으로 찾는 Minder를 설계하고 구현해 모든 분산 학습 작업에 배포한다.

   교훈

   작업이 완전히 멈출 때만 알리는 방식으로는 학습을 느리게만 하는 고장을 잡지 못한다. 엔지니어가 경험에 기대 볼 로그를 고르면 일부 내용을 빠뜨린다. 게다가 로그에는 GPU 전력, 온도, NVLink 대역폭, PFC 패킷 비율 같은 모니터링 지표가 없다. 여러 팀이 함께하는 수동 진단은 시간이 오래 걸린다. 분산 학습에서는 머신마다 부하가 고르게 나뉘므로 모니터링 지표도 비슷하게 움직이고, 한 머신만 다른 패턴을 몇 분 넘게 보이면 그 머신이 고장 났을 가능성이 높다.

   사례 보기
3. IL-0419 Vela 에서 GPU 768개로 돌던 Granite-20B 학습 작업의 스텝 시간이 거의 3배로 늘었다

   IBM2025

   증상

   Vela 에서 GPU 768개로 Granite-20B 를 학습하던 중 스텝 시간이 갑자기 거의 3배로 늘었고, 팀이 이 성능 저하를 알아챘다.

   처리량 저하

   촉발

   작업에 속한 노드 96대 가운데 한 대의 전원 카드에 문제가 생겼다.

   원인

   하드웨어 고장

   구성 요소

   서버 전원 공급 장치와 전력 제한

   기여 요인

   –

   감지

   학습 팀은 스텝 시간이 거의 3배로 늘어난 것을 알아챘다. 이 고장은 호스트를 죽이지 않고 작업을 느리게만 만드는 종류였다. 팀은 작업이 쓰던 노드 96대를 모두 디버깅해서 원인 노드를 찾았다.

   조치

   • 작업이 쓰던 노드 96대를 모두 디버깅해 전원 카드 문제로 전력을 낮춘 노드 한 대를 찾았다.

   후속 조치

   • AI 연구자와 시스템 관리자가 문제 노드를 빨리 찾고 버퍼 노드로 작업을 빨리 다시 시작할 수 있도록 인프라 계층에 경보를 더한다. 경보는 호스트 VM 로그, 애플리케이션 로그, 호스트 BMC 로그의 메시지로 만든다.
   • nvidia-smi 의 power break slowdown 같은 GPU 카운터로 전원 문제가 있는 노드를 찾는 검사를 Autopilot 에 넣고, Grafana 대시보드에 표시한다.

   교훈

   수백, 수천 개의 GPU 를 함께 쓰는 분산 학습에서는 노드 한 대의 성능만 떨어져도 작업 전체의 성능이 떨어진다. 그 상태는 느린 노드를 찾아 빼거나 고치기 전까지 이어진다. 호스트를 죽이지 않는 미묘한 하드웨어 고장도 작업을 실패시키거나 느리게 만들 수 있어서, IBM 은 로그 기반 경보와 Autopilot 의 주기 검사로 이런 노드를 먼저 찾는다. 이런 기능 덕분에 IBM 의 SRE 는 사용자가 신고하면 디버깅하던 방식에서 사용자가 알기 전에 먼저 알리는 방식으로 바뀌었고, 근본 원인을 찾는 시간을 2배 넘게 줄였다.

   사례 보기
4. IL-0418 TPU v4 슈퍼컴퓨터에서 장비, ICI 링크, 광 회로 스위치가 고장 나 학습 작업 약 1% 가 멈추거나 느려졌다

   Google2024

   증상

   TPU v4 슈퍼컴퓨터에서 TPU 장비, 칩 사이를 잇는 ICI 링크, 광 회로 스위치 OCS 가 고장 나면 그 하드웨어를 쓰던 학습 작업이 중단되었다. 장비나 ICI 링크가 고장 난 작업은 남는 정상 큐브로 다시 스케줄되었다. 전체 학습 작업의 약 1% 가 이런 하드웨어 장애를 겪었다.

   학습 작업 실패처리량 저하

   원인

   하드웨어 고장

   구성 요소

   TPUNIC·케이블·스위치 포트 링크

   기여 요인

   –

   감지

   각 TPU 장비의 healthd 데몬이 ICI 링크, PCIe 채널, TPU ASIC 을 실시간으로 감시했다. healthd 는 심각한 증상이 보이면 Borg 에 영향받은 작업을 내보내고 다시 스케줄하라고 알렸다. Pod Manager 는 RPC 로 모든 OCS 의 하드웨어 상태를 주기적으로 조회했다. libtpunet 은 작업 동안 ICI 세션을 지켜보다가 오류, 링크 다운, 드라이버 패닉이 나면 Borg 에 알렸다. 작업마다 시작 전에 작은 표본 워크로드를 돌리는 검사와 물리 계층 지표를 기준값과 비교하는 검사로 이루어진 프리플라이트 검사도 돌렸다.

   조치

   • Borg 는 문제가 생긴 TPU 장비를 쓸 수 없다고 표시하고, 돌던 작업에 알린 뒤 내보냈으며, 문제가 풀릴 때까지 대기 작업이 그 장비에 배치되지 않게 했다.
   • 작업은 알림을 받으면 가능할 때 최신 모델 체크포인트를 썼고, 다시 스케줄된 뒤 최신 체크포인트에서 이어 갔다.
   • 장비와 ICI 장애는 작업이 남는 정상 큐브를 쓰도록 다시 구성해 자동으로 견뎠다.
   • 고장 난 OCS 때문에 차원 순서 라우팅 경로가 끊긴 링크를 지나게 되면, 패킷이 각 차원에서 최대 한 번의 wild hop 을 먼저 한 뒤 차원 순서 라우팅으로 돌아가는 wild-first routing 으로 대체 경로를 만들었다. 경로는 정수 선형 계획법으로 오프라인에서 미리 계산해 두었다.
   • 끊긴 ICI 링크는 드레인해 사용자 애플리케이션이 쓰지 않도록 자동으로 빼고 온라인으로 수리했다. TPU 계산 자원은 그대로 두어, 고장 난 ICI 를 쓰지 않는 작업은 그 장비에 계속 배치되었다.
   • 고장 난 하드웨어는 자동 진단과 필요할 때 기술자의 손을 거쳐 복구했고, 자동 QA 과정을 통과한 뒤에 자원 풀로 돌려보냈다.
   • OCS 장애의 성능 영향을 줄이려고 OCS 부품을 다른 부품보다 먼저 복구했다.
   • 신뢰성을 높이려고 OCS 부품을 전체 플릿에서 계획적으로 업그레이드했다.

   후속 조치

   • 고장이 있을 때 일반 토러스와 트위스티드 토러스 모두에서 부하가 더 고르게 나뉘도록 ICI 스위치에 무작위 라우팅 기능을 넣는다. 특히 가장 가까운 이웃과 통신하는 패턴이 대상이다.
   • 장애가 나면 핫 스탠바이 큐브를 마련하고, 영구 체크포인트를 거치지 않고 가속기 상태를 새 TPU 로 바로 옮긴다. 그러면 작업이 장애에 거의 영향받지 않고 이어진다. 이를 위해 Borg 스케줄러, libtpunet, Pathways ML 런타임을 고친다.

   교훈

   정적으로 연결된 TPU v3 같은 포드에서는 작업에 필요한 연속된 노드가 모두 동시에 정상이어야 해서, 필요한 칩이 1,024개로 늘면 작업 가용성이 급격히 떨어졌다. 큐브 단위로 다시 구성할 수 있게 하자 약 50개 큐브, TPU 3,200개까지 가용성이 약 94% 로 유지되었다. OCS 장애를 견디는 장애 허용 라우팅을 더하자 가용성이 99.98% 가 되었다. 재구성이 없을 때 호스트 1,024대가 필요한 작업이 쓸 만한 가용성을 얻으려면 호스트마다 99.9% 가용성이 필요했지만, OCS 로 재구성하면 99% 로 충분했다. 장애 허용 라우팅의 성능 영향은 all-to-all 위주 작업에서는 작고 all-reduce 위주 작업에서는 더 컸으며, 계산과 통신을 더 잘 겹치면 줄일 수 있다.

   사례 보기
5. IL-0381 Newark 의 Linode Object Storage 가 두 번 느려지고 일부 요청이 504 gateway timeout 으로 실패했다

   Linode2022

   증상

   10월 10일부터 16일까지 한 주 동안 Newark 의 Linode Object Storage 에서 성능과 가용성이 떨어지는 장애가 두 번 났다. 일부 경우에는 프런트엔드 게이트웨이가 고객에게 504 gateway timeout 으로 응답했다.

   간헐적 타임아웃처리량 저하

   촉발

   백엔드 Object Storage 노드 하나에 하드웨어 문제가 생겼다. 완전한 고장이 아니어서 그 백엔드 인프라가 올라왔다 내려가기를 반복했다.

   원인

   하드웨어 고장

   구성 요소

   오브젝트 스토리지

   기여 요인

   모니터링 사각지대자동화 증폭

   조치

   • 10월 16일 10:31 UTC 에 완전히 고장 난 백엔드 Object Storage 인프라를 클러스터에서 뺐다. 그 뒤 클러스터가 회복하고 프런트엔드 게이트웨이가 정상으로 요청을 처리했다.

   후속 조치

   • 고장 나고 있거나 이상하게 동작하는 하드웨어의 미묘한 문제를 클러스터 전체에 번지기 전에 빨리 찾아 분류하도록 탐지 방법을 개선한다.
   • Ceph 관련 이벤트를 당직 관리자에게 더 정확히 설명하도록 모니터링을 바꿨다. 관리자가 문제를 더 빨리 좁힐 수 있게 알림도 더 분명히 정의했다.

   교훈

   Linode 는 이 장애로 내부 모니터링 시스템의 빈틈이 드러났다고 적었다. 완전히 고장 나지 않고 이상하게 동작하는 하드웨어의 미묘한 문제는 클러스터 전체에 번지기 전에 찾아내야 한다고 봤다.

   사례 보기

원인별1