사례2건
2건 중 1~2번째
- 증상
대규모 MoE 학습의 스텝 시간이 약 0.3초 늘어 8.4초가 아닌 8.7초가 걸렸다. 하드웨어 고장 알림은 없었고, 노드는 표준 상태 점검을 통과했다.
- 촉발
노드 안 GPU 한 개에 배정된 고대역폭 네트워크 어댑터가 고장 나 내려갔다.
- 원인
- 구성 요소
- 기여 요인
- 감지
하드웨어 고장 알림은 없었다. network packets transmitted 지표에서 남은 어댑터의 트래픽이 비정상적으로 높게 나타났고, GPU와 NIC의 배정을 보니 GPU7의 통신이 NIC 0으로 나가고 있었다.
- 조치
- 성능이 떨어진 통신 경로를 바로잡았고, 학습 스텝 시간이 8.7초에서 8.4초로 줄었다.
- 후속 조치
- 네트워크 장치의 링크 상태를 계속 모니터링해, 성능 저하가 번지기 전에 영향받은 노드를 찾아 격리한다.
- 온라인 모니터링이 표시한 노드는 정상 노드 풀에서 빼고 오프라인 검증 일정을 잡는다.
- 노드 사이 집합 통신에 부하를 거는 다중 노드 스윕을 돌려, 성능이 떨어진 링크와 통신 라이브러리의 우회를 찾는다.
- 모든 노드를 주기적으로 스윕하지 않고, 온라인 모니터링이 이상을 찾았을 때나 수리를 마친 뒤에 스윕을 실행한다.
- 교훈
NCCL의 대체 경로는 작업 실패를 막지만 하드웨어 문제를 가린다. 짧게 도는 NCCL 테스트와 GPU burn-in은 기능의 정확성만 확인하므로, 점검을 통과한 노드도 실제 학습에서는 계속 뒤처질 수 있다. 동기화가 많은 MoE 학습에서는 1초도 안 되는 차이가 층과 스텝을 지나며 큰 효율 손실로 쌓인다. 그래서 학습 중에 성능을 보는 모니터링과, 노드를 다시 서비스에 넣기 전의 독립된 오프라인 검증이 함께 필요하다.
- 증상
2023년 11월 17일 금요일 오전, 지방자치단체가 쓰는 지방행정전산서비스와 정부24가 멈췄다. 장애 당시 로그를 보면 통합인증서버의 네트워크 세션이 비정상 상태였다. 네트워크 장비인 L4 장비가 비정상 상태로 바뀌었다는 로그도 여러 번 반복해 남았다.
- 원인
- 구성 요소
- 기여 요인
- 조치
- 11월 18일 04시에 정상 작동하지 않던 L4 장비를 고성능 장비로 바꾸고, 기능 테스트와 부하 테스트로 안정성을 확인한 뒤 오전 9시에 정부24 서비스를 다시 열었다.
- 대전센터 라우터 중 광주센터와 연결된 포트의 불량을 찾아, 11월 19일 오전 7시에 다른 포트로 연결을 옮겨 지연을 없앴다.
- 정부 서비스를 다시 연 다음 날 아침에 문제가 생긴 라우터의 모듈을 바꿔 끼웠다.
- 후속 조치
- 비슷한 포트 불량이 있을 수 있는 오래된 장비를 전수 점검한다.
- 국민에게 장애 상황을 빨리 알리지 못한 문제를 풀기 위해 장애가 났을 때의 처리 매뉴얼을 보완한다.
- 여러 수단을 써서 장애로 멈춘 서비스의 복구 상황을 빠르게 알린다.
- 장애 징후를 빨리 잡도록 중요 서비스 시스템과 연관 장비를 함께 보는 통합 모니터링 체계를 만든다.
- 상설 장애대응반을 꾸려 중요 장애에 투입해 문제를 일찍 해결한다.
- 핵심 디지털정부 서비스가 멈춘 상황에서도 행정서비스를 제공할 수 있도록 행정조치 방안을 마련하고 대응 매뉴얼을 만든다.
- 국가전산망 마비를 재난과 사고의 유형으로 명시해 예방부터 복구까지 체계적으로 관리한다.
- 여러 정보시스템이 연계된 환경에 맞는 위기대응체계를 만들고, 이를 총괄하는 범정부 장애 예방·대응 컨트롤타워를 강화한다.
- 공공정보화사업의 추진 절차와 사업관리체계를 고치고, 내용연수가 지나 잠재적 위험이 높은 하드웨어와 소프트웨어를 빨리 교체하며, 기술력 높은 기업이 참여할 수 있게 사업대가를 현실화한다.
- 정보시스템 개발과 운영을 외주용역에 기대는 지금의 체계를 고치고, 디지털 분야의 우수한 인재가 정부에 들어오게 한다.
- 국가정보자원관리원에 입주한 시스템의 이중화, 재복구 시스템, 네트워크 구성 같은 기술 구조를 전면 검토하고, 조직 진단으로 조직 구성과 인사 운영의 개선 방안을 마련한다.
- 제조사와 협의해 장비 안의 부품 고장을 더 일찍 발견하고 모니터링하는 체계를 만든다.
- 교훈
라우터 장비의 기본 모니터링은 하고 있었고 전산실에서는 매일 눈으로도 점검했지만, 이번 문제는 모듈 안의 특수한 부분에서 생겨 미리 잡아내지 못했다. 이중화는 장비 하나가 완전히 작동하지 않을 때 다른 장비가 대신하는 구조여서, 모듈 일부만 고장 난 이번 경우에는 제대로 작동하지 않았다. 고장 난 포트가 전체 서비스에 영향을 주는 위치에 있어 파급이 컸다. 장애가 L4 장비의 OS 업데이트 바로 뒤에 나서 업데이트가 원인처럼 보였지만, OS 를 되돌린 뒤에도 같은 문제가 나서 원인이 아닌 것으로 드러났다.
이 2건에서 가장 많이 나오는 구성 요소: NIC·케이블·스위치 포트 링크, NCCL. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.
원인별1
하드웨어 고장2건
- 기여 요인