사례1건
1건 중 1~1번째
- 증상
OpenAI 의 Cluster A 에서 50K GPU 로 돌던 운영 사전 학습 작업의 처리량이 1분 동안 약 25% 떨어졌다. 같은 시각 T0 스위치 한 대의 광 트랜시버에 달린 링크 네 개가 짧은 간격으로 연달아 내려갔다 올라왔다.
- 촉발
T0 스위치의 광 트랜시버 하나가 순간적으로 오작동해 그 트랜시버의 링크 네 개가 짧은 간격으로 연달아 플래핑했다.
- 원인
- 구성 요소
- 기여 요인
- –
- 감지
NIC 와 T0 스위치가 각각 링크가 내려간 것을 기록했고, 두 기록의 시각은 정확히 같지 않았다. 작업 처리량 그래프와 노드별 패킷 손실률 그래프에 이 사건이 나타났다.
- 조치
- MRC 가 플래핑으로 잃은 패킷을 빠르게 복구해서 작업이 받은 영향은 비교적 작았다.
- 교훈
논문은 NIC 와 T0 사이의 링크를 잃으면 성능이 떨어진다고 했다. 다만 이런 사건은 대부분 잠깐이고, 작업이 노드를 빼지 않고도 금방 원래 속도로 돌아오는 경우가 많다고 했다. NIC 와 T0 사이의 링크와 T0 스위치는 눈에 띄는 영향을 주므로 T1 스위치보다 더 조심해서 다뤄야 한다고 했다. 단일 장애 지점도 남아 있다고 했다. 800 Gb/s NIC 광 모듈을 200 Gb/s 링크 네 개로 나눠 쓰므로 NIC 쪽 트랜시버 자체가 플래핑하면 그 NIC 의 포트를 모두 잃는다. 그러면 QP 가 실패하므로 작업이 이 상황을 견디지 못한다. 논문은 다른 광 설계를 쓰면 이 문제를 아예 피할 수 있을 것이라고 했다.
이 사례에서 가장 많이 나오는 구성 요소: NIC·케이블·스위치 포트 링크. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.