Incident Library

IL-0412 Meta · 2024-10-29 (게시일)ai-infranetworking

InfiniBand 링크 오류와 링크 flapping 으로 Meta RSC-1 의 bring-up 단계에서 백엔드 패브릭 대역폭이 최대 50~75% 줄었다

Meta FAIR 의 엔지니어들이 자사 연구 클러스터 RSC-1 과 RSC-2 의 11개월치 데이터를 분석한 논문이다. 두 클러스터는 서버당 NVIDIA A100 80GB 8장을 단 DGX 기반 bare-metal 클러스터이고, RSC-1 은 GPU 16k, RSC-2 는 GPU 8k 규모다. 서버는 Ethernet 프런트엔드 네트워크와, 학습 중 모델 gradient 를 낮은 지연으로 주고받는 rail-optimized InfiniBand 백엔드 네트워크로 연결된다. 랙마다 서버 두 대가 있고, 랙 열 개가 rail-optimized 네트워크로 이어져 pod 를 이루며, pod 사이 통신은 spine 스위치를 거친다. 노드는 작업 전후와 5분마다 도는 헬스 체크로 점검하고, InfiniBand 링크 오류, 곧 IB 링크 오류는 노드를 바로 빼는 높은 심각도 점검에 들어간다. 논문은 실패 원인이 작업 수명의 마지막 10분 안이나 끝난 뒤 5분 안에 감지되면 그 원인을 작업 실패의 원인으로 보았다.

실패 분석에서 원인이 밝혀진 하드웨어 실패는 백엔드 네트워크, 파일 시스템, GPU 가 가장 많았고, IB 링크는 실패율에 크게 기여했다. 다만 IB 링크 쪽 수치는 2024년 여름에 소수의 노드에서 IB 링크 관련 작업 실패가 짧게 몰린 영향이 컸다. 서버처럼 네트워크 링크도 물리적이거나 전기적인 성질이 바뀌어 일시적으로 또는 영구적으로 나빠질 수 있다. 오류율이 높은 링크, up 과 down 을 오가는 링크, 영구히 내려간 링크, 혼잡이 모두 패브릭 통신 성능을 떨어뜨린다.

링크를 대규모로 물리 교체하기는 번거로워서 InfiniBand 패브릭은 스위치 수준에서 링크 문제를 견디는 기능을 갖춘다. 그중 SHIELD 는 스위치끼리 고장 난 링크를 피하도록 맞추는 self-healing 기능이지만, 켜 둔 상태에서도 링크를 down 으로 판정하는 기준이 너무 보수적일 수 있어서 프로토콜 수준의 재전송과 네트워크 성능 저하가 생길 수 있다. RSC-1 의 bring-up 단계에서는 대역폭이 최대 50~75% 줄었다. Meta 는 실시간 네트워크 상태에 따라 경로를 바꾸는 Adaptive Routing, 줄여서 AR 을 클러스터에 켰고, 두 가지 실험으로 그 효과를 확인했다. 첫째 실험에서는 mlxreg 도구로 패브릭의 포트 레지스터를 바꿔 Bit Error 를 넣고, 512 GPU 에서 NCCL-Tests 의 All-Reduce 벤치마크를 AR 을 켠 채와 끈 채로 돌렸다. AR 을 켰을 때 링크 오류 속에서도 훨씬 높은 대역폭을 유지했다. 둘째 실험에서는 64개 노드에서 두 노드씩, 16 GPU 묶음으로 All-Reduce NCCL-Tests 를 동시에 여러 번 돌렸다. AR 을 켰을 때 성능 편차가 작고 성능이 높았다.

심각도
–
영향 범위
RSC-1's InfiniBand back-end fabric during bring-up, with as much as 50-75% bandwidth loss; IB link errors also caused job failures on RSC-1 and RSC-2
영향 사용자
Researchers running ML jobs on RSC-1 and RSC-2
지역
–
감지까지
–
복구까지
–

증상

RSC-1 의 bring-up 단계에서 InfiniBand 백엔드 패브릭의 대역폭이 최대 50~75% 줄었다. InfiniBand 링크 오류, 줄여서 IB 링크 오류는 RSC-1 과 RSC-2 에서 학습 작업 실패의 큰 원인이기도 했다.

논문은 패브릭 전체의 통신 성능을 떨어뜨리는 링크 문제로 오류율이 높은 링크, up 과 down 상태를 오가는 flapping 링크, 아예 내려간 링크, 여러 사용자가 함께 쓰는 환경의 심한 혼잡을 꼽았다.

스위치에는 self-healing 기능인 SHIELD 가 있다. SHIELD 는 스위치끼리 고장 난 링크를 피하도록 맞추는 기능이지만, 켜 둔 상태에서도 링크를 down 으로 판정하는 기준이 너무 보수적일 수 있다. 그러면 프로토콜 수준에서 재전송이 일어나고 네트워크 성능이 떨어질 수 있다.

IB 링크 실패는 시간에 따라 몰려 나타났다. 2024년 초여름에 소수의 노드에서 IB 링크 실패가 치솟아 두 클러스터의 실패율을 한동안 끌어올렸고, IB 링크가 실패율에서 큰 비중을 차지한 것은 대부분 이 짧은 기간 때문이었다. RSC-1 에서는 IB 링크 실패의 2%, RSC-2 에서는 6% 가 GPU 가 버스에서 떨어지는 것 같은 GPU 실패와 함께 났다.

이런 링크 문제는 작업에서 NCCL timeout 으로 나타날 수 있었다. 논문은 NCCL timeout 의 실제 원인이 교착 상태여도 네트워크 문제로 성급히 판단하기 쉽고, 네트워크 문제는 피해 범위가 넓어 스택 전체에 오류를 낸다고 적었다.

증상 처리량 저하링크 플래핑학습 작업 실패

원인

원인 의존성 장애

구성 요소 InfiniBand 패브릭NIC·케이블·스위치 포트 링크
기여 요인 –
촉발
–

감지

5분마다 도는 노드 헬스 체크가 IB 링크 오류를 잡았다. IB 링크 오류는 높은 심각도 점검이라 걸리면 스케줄러가 바로 노드를 뺐고, 논문은 작업 실패 전후에 감지된 점검 결과로 실패 원인을 정했다.

조치

후속 조치

–

교훈

논문은 네트워크가 고장 난 링크를 빼고 그 주변으로 경로를 돌려야 한다고 밝혔다. 이런 복원 장치가 없으면 50% 넘는 대역폭을 잃을 수 있다. 앞으로는 패브릭이 고장을 피해 토폴로지를 다시 구성하는 식으로, 불안정을 없애기보다 덜 드러나게 하는 인프라가 필요하다고 봤다. NCCL timeout 처럼 원인이 여럿일 수 있는 오류는 네트워크 문제로 성급히 판단하기 쉬우니 조심해야 한다.

출처

참고 문서

관련 사례

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

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

kubegap 열기

AI 도구와 스크립트용

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