Incident Library

IL-0263 GitHub · 2012-11-30networking

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

GitHub 의 네트워크는 각 스위치가 옆 랙의 스위치와 이어진 구조였다. 그래서 반대쪽 끝까지 가는 데이터가 가운데 스위치들을 모두 지나야 했고, 가운데 링크가 포화되곤 했다. GitHub 는 이를 풀려고 애그리게이션 스위치가 각 캐비닛의 액세스 스위치와 바로 이어지는 트리 구조의 애그리게이션 네트워크를 만들기로 했다. 서버는 저마다 A, B 두 스위치에 이어져 있었다. GitHub 는 11월 29일 목요일에 B 스위치를 먼저 옮겼고, 큰 문제는 없었다.

11월 30일 금요일 아침 A 스위치를 하나씩 옮기다가 마지막 스위치에서 설정 오류로 브리지 루프가 생겨 같은 캐비닛의 B 스위치와 연결이 끊겼다. 이를 빨리 고쳐 이전을 마쳤지만 액세스 스위치와 애그리게이션 스위치 사이 링크가 모두 포화된 상태였다. 엔지니어들은 이를 브리지 루프가 일으킨 브로드캐스트 스톰으로 보고 그날 대부분을 루프를 찾는 데 썼다. 엔지니어들은 링크를 하나씩 끊어 보다가 공급사와 함께 다른 문제를 찾았다. 두 링크 사이의 부분 링크 장애를 감지하는 설정이 이 애그리게이션 스위치와 액세스 스위치 모델 조합에서는 지원되지 않아서, 링크 하나를 끊으면 모든 링크를 꺼 버렸다. 18분 동안의 완전한 중단은 이 조사 중에 여러 스위치와 연결이 한꺼번에 끊기면서 났다. 이 설정을 지우자 페일오버는 기대대로 작동했다.

몇 시간을 더 찾아도 설정 문제가 나오지 않자 GitHub 는 네트워크 공급사에 다시 에스컬레이션했다. 공급사는 이 문제를 가장 높은 심각도 등급으로 올려 함께 조사했다. 금요일 밤 다섯 시간의 조사 끝에 애그리게이션 스위치의 버그가 원인으로 드러났다. 스위치가 MAC 주소의 상당 부분을 학습하지 못해서 그 주소로 가는 트래픽을 모든 포트로 플러딩했고, 이 트래픽이 액세스 스위치와 애그리게이션 스위치 사이 링크를 모두 채웠다. 태평양 시간 토요일 오전 6시의 점검 시간에 애그리게이션 스위치의 핵심 프로세스 일부를 재시작해 MAC 주소를 다시 학습시켰고, 트래픽과 성능이 정상으로 돌아왔다. 파일 서버 한 쌍은 이 네트워크 문제가 고가용성 클러스터링에 영향을 줘서 하루 대부분 내려가 있었다.

심각도
–
영향 범위
GitHub: 18 minutes of complete unavailability and sporadic slow responses and intermittent errors for the whole day; one fileserver pair offline for a large part of the day
영향 사용자
all GitHub users during the 18 minutes of downtime; a small percentage of repositories on the offline fileserver pair
지역
–
감지까지
–
복구까지
–

증상

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

그날 아침 GitHub 는 새 애그리게이션 스위치로 옮기는 작업의 두 번째 단계로 각 캐비닛의 A 스위치를 하나씩 옮기고 있었다. 마지막 A 스위치를 연결하자 같은 캐비닛의 B 스위치와 연결이 끊겼다. 이 스위치 한 쌍의 설정 오류가 브리지 루프를 만들었고, 스위치는 설정대로 문제를 감지한 링크를 꺼서 네트워크를 보호했다.

이 문제를 고쳐 이전을 끝낸 뒤에도 성능이 기대만큼 나오지 않았다. 들여다보니 액세스 스위치와 애그리게이션 스위치를 잇는 링크가 전부 꽉 차 있었다.

엔지니어들은 이것을 감지되지 않은 브리지 루프가 일으키는 브로드캐스트 스톰으로 판단했다. 그날 대부분을 스위치 설정을 다시 점검하고 포트를 하나하나 살피며 루프를 찾는 데 썼다. 범위를 좁히려고 액세스 스위치와 애그리게이션 스위치 사이 링크를 하나씩 끊어 봤다.

링크를 끊어 보다가 다른 문제가 드러났다. 이중으로 묶인 링크 하나를 끊는 순간 액세스 스위치가 짝이 되는 다른 링크까지 꺼 버렸다. 애그리게이션 스위치 하나가 고장 나면 버틸 수 없다는 뜻이었다. 공급사와 함께 원인을 찾아보니, 부분 링크 장애를 감지하려고 켜 둔 설정이 문제였다. 이 설정은 이 애그리게이션 스위치와 액세스 스위치 모델 조합에서는 지원되지 않아서, 링크 하나를 끊으면 모든 링크를 꺼 버렸다. 18분 동안의 완전한 중단은 이 조사 도중 여러 스위치와 연결이 한꺼번에 끊기면서 생겼다.

이 설정을 지운 뒤 링크를 계속 시험했지만 몇 시간이 지나도 설정에서 문제를 찾지 못했다. 엔지니어들은 여전히 루프가 원인인 브로드캐스트 스톰이라고 믿고 있었다. 금요일 밤 공급사와 함께 다섯 시간을 조사한 끝에 애그리게이션 스위치가 MAC 주소 테이블에서 많은 주소를 빠뜨리고 그 주소로 가는 트래픽을 모든 포트로 플러딩하는 버그를 찾았다.

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

원인

원인 소프트웨어 결함

구성 요소 네트워크 스위치NIC·케이블·스위치 포트 링크
기여 요인 장애 중첩미검증 가정수동 조치 악화
촉발
새 애그리게이션 스위치를 들이려고 액세스 스위치를 떼어 설정을 바꾸고 다시 연결하는 작업을 했다. 11월 30일 아침 A 스위치를 옮기던 중 마지막 스위치에서 브리지 루프가 생겼다.

감지

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

조치

후속 조치

교훈

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

출처

관련 사례

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

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 네트워크 스위치, NIC·케이블·스위치 포트 링크. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.