사례3건

3건 중 1~3번째

1. IL-0481 RoCEv2 학습 클러스터에서 RNIC 포트가 플랩한 뒤 GID 가 바뀌어 집합 통신이 깨지고 LLM 학습 작업에 크래시가 났다

   Infrawaves2026

   증상

   Infrawaves 가 운영하는 RoCEv2 GPU 학습 클러스터에서 RNIC 포트가 잠깐 내려갔다 다시 올라오는 플랩이 생긴 뒤 집합 통신이 무너지고 LLM 학습 작업에 크래시가 났다. RNIC 는 RDMA 를 지원하는 네트워크 카드다.

   링크 플래핑학습 작업 실패

   촉발

   장애는 RNIC 포트 플랩에서 시작됐다. 운영체제의 기본 네트워크 관리자인 NetworkManager 로 IP 주소를 설정한 서버에서는 포트가 내려간 동안 포트의 IP 주소가 잠깐 사라졌다. 원래 주소가 다시 돌아왔을 때 GID 는 하나 올라가 있었다.

   원인

   소프트웨어 결함

   구성 요소

   NIC·케이블·스위치 포트 링크InfiniBand 패브릭NCCL호스트 라우팅 규칙

   기여 요인

   기본 설정 방치

   조치

   • Infrawaves 는 Ubuntu 에서 RNIC 포트의 IP 주소를 NetworkManager 대신 Networking 서비스로 설정하도록 바꿨다. 그러자 포트가 내려가도 IP 주소가 그대로 남았고 GID 가 바뀌지 않았다.

   교훈

   네트워크 설정은 VCCL 의 신뢰성을 좌우한다. RoCEv2 환경에서는 포트가 내려가도 IP 주소를 유지하는 방법으로 IP 주소를 설정해야 GID 가 바뀌지 않는다. GID 가 올라가는 것을 막는 드라이버 패치는 가상화 네트워크에서 호환성 문제를 일으킬 위험이 있었다. 그래서 Infrawaves 는 가볍고 믿을 만한 대안으로 IP 설정 방법을 바꿨다.

   사례 보기
2. IL-0344 Linode US-West 의 Fremont 와 Santa Clara 데이터 센터가 인터넷 연결과 두 사이트 사이 연결을 잃었다

   Linode2023

   증상

   2023년 2월 12일 Linode US-West 리전의 고객이 자기 Linode 에 접속하지 못했다. 상태 페이지는 10:22 UTC 에 US-West 의 연결 문제 신고를 조사 중이라고 알렸고, 12:52 에 다시 연결 문제 신고가 들어왔다고 알렸다.

   네트워크 도달 불가

   촉발

   2월 11일 17:45 UTC 에 US-West 두 데이터 센터를 잇는 A 쪽 다중 광섬유 회선의 링크 하나가 끊겼고, 2월 12일 2:45 UTC 에 이중화 짝인 B 쪽 회선 전체가 끊겼다. 하드웨어 업체와 함께 원인을 조사하던 중에는 시스템에 영향을 주지 않는 명령 하나가 드문 버그를 건드려 A 쪽 링크가 모두 끊겼다.

   원인

   소프트웨어 결함

   구성 요소

   백본망NIC·케이블·스위치 포트 링크

   기여 요인

   장애 중첩수동 조치 악화

   감지

   2월 12일 10:22 UTC 상태 페이지에 US-West 리전의 연결 문제 신고를 조사 중이라는 공지가 올라왔다. 12:52 UTC 에는 연결 문제 신고가 더 들어와 다시 살펴보기 시작했다.

   조치

   • 2월 12일 10:13 UTC, Santa Clara 보더 라우터에서 인터넷 트래픽을 모두 뺀 변경을 되돌려 서비스를 살렸다.
   • 버그를 피하려고 두 회선의 코드를 긴급히 업그레이드했다. 업그레이드는 16:25 UTC 에 끝나 연결이 돌아왔고, 17:29 UTC 까지 트래픽이 A 쪽 경로로 돌아왔다.
   • 하드웨어 업체, 광섬유 제공자와 함께 B 쪽 고장 지점을 찾아, 2월 14일 18:30 UTC 에 B 쪽 경로를 살리고 US-West 두 사이트 사이 이중화를 모두 되찾았다.

   사례 보기
3. IL-0263 새 애그리게이션 스위치로 옮기는 작업 뒤 데이터센터 스위치 사이 링크가 포화되어 GitHub 가 하루 종일 느렸고 18분 동안 완전히 멈췄다

   GitHub2012

   증상

   2012년 11월 30일 금요일, GitHub 는 18분 동안 완전히 접속이 안 됐고, 하루 종일 응답이 이따금 느려지고 오류가 간헐적으로 났다. 파일 서버 한 쌍이 하루 대부분 내려가 있어 일부 저장소가 영향을 받았다.

   지연 시간 증가오류율 상승서비스 중단

   촉발

   새 애그리게이션 스위치를 들이려고 액세스 스위치를 떼어 설정을 바꾸고 다시 연결하는 작업을 했다. 11월 30일 아침 A 스위치를 옮기던 중 마지막 스위치에서 브리지 루프가 생겼다.

   원인

   소프트웨어 결함

   구성 요소

   네트워크 스위치NIC·케이블·스위치 포트 링크

   기여 요인

   장애 중첩미검증 가정수동 조치 악화

   감지

   마지막 A 스위치를 연결할 때 같은 캐비닛의 B 스위치와 연결이 끊겼다. 문제를 고친 뒤에도 성능이 기대만큼 나오지 않아 들여다보다가 액세스 스위치와 애그리게이션 스위치 사이 링크가 모두 포화된 것을 봤다.

   조치

   • 마지막 A 스위치에서 난 첫 문제를 빨리 해결하고, 영향받은 B 스위치를 다시 서비스에 넣어 이전을 마쳤다.
   • 액세스 스위치에서 잘못된 설정을 지웠다. 그 뒤로는 링크를 시험해도 페일오버가 기대대로 작동했고, 애그리게이션 계층이나 액세스 계층의 스위치 하나를 빼도 서버에 영향이 없었다.
   • 몇 시간을 더 찾아도 설정 문제가 나오지 않자 네트워크 공급사에 다시 에스컬레이션했고, 공급사는 이 문제를 가장 높은 심각도 등급으로 올려 바로 함께 조사했다.
   • 태평양 시간 토요일 오전 6시에 네트워크 점검 시간을 잡고 애그리게이션 스위치의 핵심 프로세스 일부를 재시작해 MAC 주소를 다시 학습하게 했다. 이 우회책이 통해서 트래픽과 성능이 정상으로 돌아왔다.

   후속 조치

   • 공급사가 MAC 학습 문제의 근본 원인을 찾았고, 1주일쯤 안에 최종 수정이 나오면 스위치에 소프트웨어 업데이트를 배포한다.
   • 그때까지 애그리게이션 계층과 액세스 계층 사이 용량을 면밀히 지켜보고, 문제가 다시 나면 쓸 우회 절차를 둔다.
   • 라우터부터 액세스 계층 스위치까지 네트워크 스택을 똑같이 한 벌 더 갖춰 스테이징 환경으로 쓰고, 이런 변경을 미리 더 충분히 시험한다.
   • 비슷한 문제가 생기면 더 빨리 알림을 받도록 네트워크에 자동 모니터링을 더한다.
   • 앞으로 몇 달 동안 정기적인 장애 대응 훈련을 늘리고, 한 가지 가설에 매달리지 않도록 하는 시나리오를 만든다.
   • 앞으로는 네트워크에 문제 조짐이 처음 보일 때 바로 공급사 지원팀에 연락한다.

   교훈

   GitHub 는 고객에게 영향이 없도록 설계한 점검 작업이 결국 고객에게 영향을 줬다고 인정했다. 장애 대응 중에 브리지 루프라는 생각에 오래 매달려 다른 원인을 보지 못했고, 그래서 한 가지 가설에 갇히는 것을 더 경계해야 한다고 했다. GitHub 는 공급사 지원팀과 일한 경험이 좋았다며, 앞으로는 문제 조짐이 처음 보일 때 바로 지원팀에 연락하겠다고 했다.

   사례 보기

원인별1