Incident Library
  • 원인
  • 구성 요소
  • 증상
  • 기여 요인
  • 사례

사례2건

2건 중 1~2번째

  1. 증상

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

    촉발

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

    원인
    구성 요소
    기여 요인
    조치
    • Infrawaves 는 Ubuntu 에서 RNIC 포트의 IP 주소를 NetworkManager 대신 Networking 서비스로 설정하도록 바꿨다. 그러자 포트가 내려가도 IP 주소가 그대로 남았고 GID 가 바뀌지 않았다.
    교훈

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

  2. 증상

    2020년 9월 1일 화요일 Central Time 9:51am 부터 10:08am 까지, UTC 로는 14:51–15:08 의 17분 동안 Basecamp 가 아예 열리지 않았다. 아무것도 동작하지 않는 것처럼 보였고, 다시 열린 뒤에는 모든 것이 정상으로 보였다.

    촉발

    2020년 9월 1일 데이터센터 사이 네트워크 회선이 끊긴 것을 복구하는 도중 하드웨어 로드 밸런서 하나가 죽었다. 9월 2일에는 Virginia 데이터센터의 주 로드 밸런서와 보조 로드 밸런서가 차례로 죽었다.

    원인
    구성 요소
    기여 요인
    조치
    • 9월 1일 라우터가 새 로드 밸런서와 자동으로 동기화하지 못하자 손으로 개입해 바로잡았다.
    • 9월 2일 라우터가 동기화하지 못하는 같은 문제가 다시 나자 이번에도 손으로 개입해 고쳤다.
    후속 조치
    • 로드 밸런서 공급사와 함께 장애 원인을 끝까지 밝히고, 1차 평가에서 나온 버그 수정을 적용한다.
    • 하드웨어 로드 밸런서를 교체한다.
    • 데이터센터 사이 이중 네트워크 경로를 다시 깔아 회선이 실제로 다른 경로를 지나게 하고, 네트워크 공급사 사이의 숨은 의존을 없앤다.
    • 비상 대책으로 하드웨어 로드 밸런서에서 소프트웨어 로드 밸런서로 옮기는 것을 검토한다. 하드웨어는 교체에 며칠이 걸리지만 소프트웨어는 몇 분이면 배포할 수 있다.
    • 비상 대책으로 로드 밸런서 구성을 분산해 장애 하나의 영향을 줄이는 것을 검토한다.
    • 시스템의 복원력, 취약함, 위험을 평가하고 평가 과정 자체도 검토한다.
    교훈

    Basecamp 는 여러 겹의 이중화와 복원력을 갖추고 운영 시스템에서 큰 장애 대응을 연습해 왔지만 이번 사고들은 잡지 못했다. 모든 사고를 잡을 수는 없지만, 연쇄 장애가 예상하지 못한 취약함과 어려운 복구 경로를 드러내는 일에는 대비할 수 있다.

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

이 2건에서 가장 많이 나오는 구성 요소: 백본망, 호스트 라우팅 규칙. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.

원인별1