사례8건

8건 중 6~8번째

1. 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 위주 작업에서는 더 컸으며, 계산과 통신을 더 잘 겹치면 줄일 수 있다.

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

   사례 보기
3. IL-0429 GLM-130B 사전 학습이 노드 고장으로 거듭 중단됐고 Lustre 오류로 2.3T 말뭉치를 읽지 못했다

   Tsinghua University2022

   증상

   96개 노드에서 돌던 GLM-130B 사전 학습이 2022년 5월과 6월 내내 노드 고장, GPU 누락, 연결 끊김으로 여러 번 멈췄다. 2022-05-30 에는 재시작이 데이터 로딩에서 멈춰 더 나아가지 않았다.

   학습 작업 실패노드 NotReadyGPU 인식 불가스토리지 연결 끊김처리량 저하

   촉발

   학습 중에 계산 노드가 고장 나거나 연결이 끊기거나 GPU 를 잃었고, 2022-05-30 재시작 때는 Lustre 파일 시스템 오류가 났다.

   원인

   하드웨어 고장

   구성 요소

   GPU 하드웨어·메모리공유 네트워크 파일 시스템

   기여 요인

   –

   감지

   처리량 저하는 학습 flops 가 127T 로 전보다 낮은 것을 보고 알아챘다. Lustre 파일 시스템 오류는 재시작이 데이터 로딩에서 멈춘 것을 보고 찾아냈다. n30039 는 GPU 가 없다고 스스로 보고했다.

   조치

   • 노드가 고장 날 때마다 마지막으로 저장한 step 에서 학습을 다시 시작했다.
   • 체크포인트 저장 간격을 500 step 에서 100 step 으로 줄였다. 500 step 은 너무 길었다.
   • 다른 노드 풀로 옮겨 15600 step 에서 다시 시작했다.
   • 교체해 넣은 n30076 에 알 수 없는 오류가 있다고 보고 16600 step 부터 이 노드를 뺐지만, 처리량은 달라지지 않았다.
   • 2.3T 텍스트 말뭉치를 백업 디스크에서 파일 시스템으로 다시 복사했고, 며칠이 걸렸다.

   사례 보기

원인별1