Incident Library

IL-0418 Google · 2024-04-16 (게시일)ai-infranetworking

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

Google 의 TPU v4 슈퍼컴퓨터 한 대는 TPU 4,096개로 이루어진다. 큐브는 TPU 칩 64개를 4x4x4 로 배치한 하드웨어 단위이고, TPU 장비 16대로 이루어진다. 슈퍼컴퓨터 한 대에는 큐브가 64개 있다. 칩 사이를 잇는 고속 인터커넥트 ICI 는 TPU 끼리 CPU 를 거치지 않고 직접 통신하게 한다. 광 회로 스위치 OCS 48대는 서로 다른 큐브의 ICI 를 교차 연결해 사용자가 요청한 토러스 모양을 만든다. 클러스터 관리 서비스 Borg 가 작업을 받아 스케줄하고, Pod Manager 가 Borg 의 결정에 맞춰 OCS 연결을 설정하며 OCS 상태를 감시한다. ML 학습 작업은 모든 계산 자원이 동시에 정상이어야 돌아가므로 프로세스 하나가 실패하거나 중단되어도 학습 전체가 멈춘다.

논문은 Google 이 지난 2년 동안 TPU v4 를 운영한 경험을 담았다. 평균적인 슈퍼컴퓨터에서 하루에 장비의 0.08%, ICI 케이블의 0.005%, OCS 의 0.04% 가 고장 났고, 학습 작업의 약 1% 가 하드웨어 장애를 겪었다. healthd, libtpunet, Pod Manager, 수리 자동화 시스템이 이상을 알리면 Borg 는 해당 장비를 쓸 수 없다고 표시하고 돌던 작업에 알린 뒤 내보냈다. 작업은 가능하면 최신 체크포인트를 쓰고, 다시 스케줄된 뒤 최신 체크포인트에서 이어 갔다. 장비와 ICI 장애는 작업을 남는 정상 큐브로 옮겨 자동으로 견뎠다. OCS 장애는 영향 범위가 컸다. Google 은 끊긴 링크를 피해 가는 장애 허용 ICI 라우팅으로 약간의 성능 손실을 안고 OCS 장애를 견뎠고, OCS 를 다른 부품보다 먼저 복구했다. 학습 작업의 95% 가 장애 허용 라우팅을 켰고, 실제로 장애 허용 라우팅으로 도는 작업은 어느 때든 2% 미만이었다. 8개월 동안의 기록에서 60일째 무렵에 이 비율이 치솟은 것은 신뢰성을 높이려고 OCS 부품을 전체적으로 업그레이드한 계획 작업 때문이었다. 이런 재구성으로 TPU v4 슈퍼컴퓨터는 시스템 가용성 99.98% 를 유지했다.

심각도
–
영향 범위
About 1% of TPU v4 training jobs experienced hardware outages; jobs on a failed machine or ICI link were evicted, rescheduled onto healthy cubes and resumed from checkpoints, and jobs routed around an unavailable OCS ran 0.5% to 8.6% slower per step
영향 사용자
Google Cloud customers and internal Google users of TPU v4 supercomputers
지역
–
감지까지
–
복구까지
–

증상

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

평균적인 슈퍼컴퓨터 한 대에서 하루에 TPU 장비의 0.08%, ICI 케이블의 0.005%, OCS 의 0.04% 가 고장 났다. 비율은 작지만 슈퍼컴퓨터마다 장비, ICI, OCS 가 매우 많아 영향받는 작업 수는 적지 않았다.

각 장비의 healthd 데몬은 ICI 링크 24개, TPU 와 CPU 사이의 PCIe 채널, TPU ASIC 4개를 실시간으로 감시하며 링크의 케이블 연결과 링크 품질을 모델 값, 임계값과 비교했다. 작업 중에 TPU 가 오류를 보거나 링크 계층이 내려가거나 드라이버가 패닉하면 PCIe MSI-X 인터럽트가 libtpunet 에 전달되었다. libtpunet 은 Borg 에 재스케줄을 요청했다. 작업 시작 전 프리플라이트 검사에서 걸린 작업은 다른 큐브로 다시 스케줄되었다.

OCS 하나를 쓸 수 없게 되면 모든 큐브에서 같은 {dim, index} 를 가진 ICI 링크가 하나씩 끊겼다. 4x4x8 토러스라면 X 차원의 한 XZ 평면에서 링크 두 개가 끊기고, 끊긴 링크가 Z 를 따라 4홉마다 되풀이되었다. OCS 장애는 슈퍼컴퓨터의 모든 큐브에 영향을 줄 수 있어 장비나 ICI 장애보다 영향 범위가 컸다.

고장 난 OCS 를 우회하는 장애 허용 라우팅으로 실행된 작업은 고장 링크 주변에 트래픽이 몰려 스텝 시간이 0.5% 에서 8.6% 늘었다. all-reduce 위주 작업은 가장 가까운 이웃과의 통신 처리량이 50% 떨어져 영향이 더 컸다. 일반 토러스에서 OCS 하나가 빠지면 이상적인 all-to-all 성능이 15/16, 약 93.4% 로 줄었다. 4x4x4 에서 잰 all-to-all 처리량은 75.9 GB/s 에서 70.0 GB/s 로 줄어 원래의 92.2% 였다.

증상 학습 작업 실패처리량 저하

원인

원인 하드웨어 고장

구성 요소 TPUNIC·케이블·스위치 포트 링크
기여 요인 –
촉발
–

감지

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

조치

후속 조치

교훈

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

출처

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: TPU, NIC·케이블·스위치 포트 링크. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.