그래프
사례1건
1건 중 1~1번째
- 증상
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 위주 작업에서는 더 컸으며, 계산과 통신을 더 잘 겹치면 줄일 수 있다.
이 사례에서 가장 많이 나오는 구성 요소: NIC·케이블·스위치 포트 링크, TPU. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.