사례3건
3건 중 1~3번째
- 증상
Infrawaves 가 운영하는 RoCEv2 GPU 학습 클러스터에서 RNIC 포트가 잠깐 내려갔다 다시 올라오는 플랩이 생긴 뒤 집합 통신이 무너지고 LLM 학습 작업에 크래시가 났다. RNIC 는 RDMA 를 지원하는 네트워크 카드다.
- 촉발
장애는 RNIC 포트 플랩에서 시작됐다. 운영체제의 기본 네트워크 관리자인 NetworkManager 로 IP 주소를 설정한 서버에서는 포트가 내려간 동안 포트의 IP 주소가 잠깐 사라졌다. 원래 주소가 다시 돌아왔을 때 GID 는 하나 올라가 있었다.
- 원인
- 구성 요소
- 기여 요인
- 조치
- Infrawaves 는 Ubuntu 에서 RNIC 포트의 IP 주소를 NetworkManager 대신 Networking 서비스로 설정하도록 바꿨다. 그러자 포트가 내려가도 IP 주소가 그대로 남았고 GID 가 바뀌지 않았다.
- 교훈
네트워크 설정은 VCCL 의 신뢰성을 좌우한다. RoCEv2 환경에서는 포트가 내려가도 IP 주소를 유지하는 방법으로 IP 주소를 설정해야 GID 가 바뀌지 않는다. GID 가 올라가는 것을 막는 드라이버 패치는 가상화 네트워크에서 호환성 문제를 일으킬 위험이 있었다. 그래서 Infrawaves 는 가볍고 믿을 만한 대안으로 IP 설정 방법을 바꿨다.
IL-0412InfiniBand 링크 오류와 링크 flapping 으로 Meta RSC-1 의 bring-up 단계에서 백엔드 패브릭 대역폭이 최대 50~75% 줄었다Meta2024- 증상
RSC-1 의 bring-up 단계에서 InfiniBand 백엔드 패브릭의 대역폭이 최대 50~75% 줄었다. InfiniBand 링크 오류, 줄여서 IB 링크 오류는 RSC-1 과 RSC-2 에서 학습 작업 실패의 큰 원인이기도 했다.
- 원인
- 구성 요소
- 기여 요인
- –
- 감지
5분마다 도는 노드 헬스 체크가 IB 링크 오류를 잡았다. IB 링크 오류는 높은 심각도 점검이라 걸리면 스케줄러가 바로 노드를 뺐고, 논문은 작업 실패 전후에 감지된 점검 결과로 실패 원인을 정했다.
- 조치
- 클러스터에 Adaptive Routing 을 켜서, 패킷이 혼잡한 곳과 상태가 나쁜 링크를 피하도록 해 성능을 예측할 수 있게 했다.
- IB 링크 오류를 높은 심각도 헬스 체크에 넣어, 오류가 나면 스케줄러가 노드를 바로 빼고 그 노드에서 돌던 작업을 모두 다시 스케줄하게 했다.
- 교훈
논문은 네트워크가 고장 난 링크를 빼고 그 주변으로 경로를 돌려야 한다고 밝혔다. 이런 복원 장치가 없으면 50% 넘는 대역폭을 잃을 수 있다. 앞으로는 패브릭이 고장을 피해 토폴로지를 다시 구성하는 식으로, 불안정을 없애기보다 덜 드러나게 하는 인프라가 필요하다고 봤다. NCCL timeout 처럼 원인이 여럿일 수 있는 오류는 네트워크 문제로 성급히 판단하기 쉬우니 조심해야 한다.
- 증상
TPU v4 슈퍼컴퓨터에서 TPU 장비, 칩 사이를 잇는 ICI 링크, 광 회로 스위치 OCS 가 고장 나면 그 하드웨어를 쓰던 학습 작업이 중단되었다. 장비나 ICI 링크가 고장 난 작업은 남는 정상 큐브로 다시 스케줄되었다. 전체 학습 작업의 약 1% 가 이런 하드웨어 장애를 겪었다.
- 원인
- 구성 요소
- 기여 요인
- –
- 감지
각 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 위주 작업에서는 더 컸으며, 계산과 통신을 더 잘 겹치면 줄일 수 있다.
이 3건에서 가장 많이 나오는 구성 요소: NIC·케이블·스위치 포트 링크, InfiniBand 패브릭. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.