IL-0475 Microsoft Azure · 2024-06-08 (게시일)ai-infraazurenetworking
Azure A100 InfiniBand 클러스터에서 ToR 스위치의 이중화 업링크가 절반 넘게 끊겨 2노드 all-reduce 대역폭이 크게 떨어졌다
Azure A100 클러스터는 ToR 스위치와 집선 스위치 사이에 이중화 링크를 여러 개 둔 여유 있는 InfiniBand 네트워크를 쓴다. Microsoft 저자들은 혼잡으로 인한 성능 저하를 피하려면 이중화 링크의 절반보다 많이 살아 있어야 한다는 것을 확인했다. 즉 끊겨도 되는 이중화 링크는 많아야 절반이다. InfiniBand NIC 192개를 쓰는 24노드 fat-tree 테스트베드에서는 ToR 스위치마다 업링크의 25%가 여유분이었다. 일부 엣지 스위치에서 이중화 링크가 절반 넘게 끊기자, 동시에 트래픽을 보내는 여러 2노드 쌍의 all-reduce 버스 대역폭이 크게 떨어졌다. 운영자가 관련된 모든 ToR 스위치의 이중화 링크를 50% 이상으로 고친 뒤에야 모든 2노드 쌍의 대역폭이 정상으로 돌아왔다.
논문은 이것을 하드웨어 이중화가 만드는 회색 장애의 예로 든다. 회색 장애는 부품이 완전히 고장 나지 않은 채 겉으로 드러나지 않게 성능만 떨어지는 상태다. 이중화 링크가 일부 끊기면 상태가 좋고 나쁨 둘로 갈리지 않고 서서히 나빠지며, 일부 워크로드에는 초기에 영향이 없다. 장애 대응에서는 멈춘 워크로드를 빨리 다시 돌리려고 끊긴 링크 중 하나만 바꾸는 경우가 많다. 이렇게 하면 당장의 장애는 끝나지만, 다음 링크 하나만 나빠져도 다시 장애가 난다. Azure A100 클러스터의 장애 간 평균 시간은 17.5시간이었고 장애의 38.1%는 복구에 하루 넘게 걸렸다.
- 심각도
- –
- 영향 범위
- 24-node A100 testbed with 192 InfiniBand NICs: all-reduce bus bandwidth of multiple 2-node pairs dropped significantly
- 영향 사용자
- –
- 지역
- –
- 감지까지
- –
- 복구까지
- –
증상
Azure A100 클러스터의 24노드 테스트베드에서 여러 2노드 쌍이 동시에 트래픽을 보낼 때 all-reduce 버스 대역폭이 크게 떨어졌다. 이 성능 저하는 좋고 나쁨 둘로 갈리지 않고 서서히 나빠지는 형태였다.
테스트베드는 InfiniBand NIC 192개를 쓰는 fat-tree 구성이었고, ToR 스위치마다 업링크의 25%가 이중화용 여유분이었다. 일부 엣지 스위치에서 이중화 링크가 절반 넘게 끊기자 2노드 all-reduce 대역폭 분포가 정상에서 벗어났다.
이중화 링크가 일부만 끊긴 동안에는 ResNet 학습처럼 GPU와 네트워크를 다 쓰지 않는 워크로드에는 문제가 드러나지 않았다. all-to-all 같은 집합 통신에서는 혼잡 때문에 처리량이 떨어졌다. 기존 워크로드를 모니터링하는 것만으로는 이런 부분적인 이중화 손실을 제때 찾기 어려웠다.
증상 처리량 저하
원인
원인 의존성 장애
- 촉발
- InfiniBand ToR 스위치와 집선 스위치 사이의 이중화 업링크가 일부 엣지 스위치에서 절반 넘게 끊겼다.
감지
24노드 테스트베드에서 여러 2노드 쌍에 동시에 트래픽을 보내며 all-reduce 버스 대역폭의 누적 분포를 재 보았고, 이중화 비율에 따라 분포가 크게 달라지는 것을 확인했다.
조치
- 운영자가 관련된 모든 ToR 스위치의 이중화 링크를 최소 50%까지 고쳤고, 그 뒤 모든 2노드 쌍의 all-reduce 대역폭이 정상으로 돌아왔다.
후속 조치
- 장애가 난 뒤에 고치는 대신, 장애가 나기 전에 클라우드 AI 인프라의 구성 요소를 미리 검증하는 SuperBench를 쓴다.
교훈
부품 단위의 이중화는 성능 저하를 숨기고, 시간이 지나면 장애를 더 잦게 만든다. 이중화가 일부 끊겨 생기는 점진적인 성능 저하는 기존 워크로드를 모니터링해서는 제때 찾기 어려우므로, 하드웨어에 부하를 거는 별도 테스트로 찾아야 한다. 장애 대응에서 이중화를 일부만 고치면 당장의 워크로드는 살아나지만 신뢰성은 떨어진다. 그래서 장애가 나기 전에 구성 요소를 미리 검증해 이중화를 모두 되살려야 한다.
출처
- https://arxiv.org/abs/2402.06194 · paper · 보관본
참고 문서
관련 사례
IL-0133폭풍으로 데이터센터 냉각이 멈춰 us-central1 리전 전체가 내려갔고, 디스크 핫플러그 버그로 Managed Kubernetes 컨트롤 플레인 약 140개의 복구가 길어졌다.Nebius · 2026같은 원인 · 공통 InfiniBand 패브릭
같은 원인 · 공통 InfiniBand 패브릭
IL-0134AUS01 데이터센터에 전력 문제가 생겨 GPU 노드 246대와 스파인 스위치, VAST 스토리지가 한꺼번에 재부팅됐고, 워크로드가 실패하고 NFS 마운트가 끊겼다.Lambda · 2026 · sev1같은 원인 · 공통 InfiniBand 패브릭
IL-0412InfiniBand 링크 오류와 링크 flapping 으로 Meta RSC-1 의 bring-up 단계에서 백엔드 패브릭 대역폭이 최대 50~75% 줄었다Meta · 2024같은 원인 · 공통 InfiniBand 패브릭
IL-0025H100 4,088개 클러스터를 구축하는 동안 InfiniBand 배선 오류, 링크 플래핑, GPU 와 PCIe 하드웨어 결함이 학습을 멈추거나 늦췄다Imbue · 2024같은 원인 · 공통 InfiniBand 패브릭
IL-0126OPT-175B 학습이 클라우드 노드의 ECC 메모리 오류, 같은 결함을 안고 돌아온 교체 노드, 멈추는 체크포인트 다운로드 때문에 2주 동안 40번 넘게 재시작했다.Meta AI · 2021같은 원인 · 공통 InfiniBand 패브릭
내 클러스터에도 있는지 확인하기
AI 도구와 스크립트용
- 이 사례의 JSON: https://incidentlib-api.benchlet.com/cases/IL-0475
- 가장 비슷한 사례들: https://incidentlib-api.benchlet.com/cases/IL-0475/similar
- MCP 서버(Streamable HTTP, 키 없음):
https://incidentlib-mcp.benchlet.com/mcp
API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.