그래프
사례3건
3건 중 1~3번째
- 증상
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 쪽 링크가 모두 끊겼다.
- 원인
- 구성 요소
- 기여 요인
- 감지
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 두 사이트 사이 이중화를 모두 되찾았다.
- 증상
14:43 UTC 에 네트워크 스위치 하나가 ping 에 응답하지 않는다는 알림이 울리기 시작했다. 장애 동안 API 쿼리 성공률이 한때 75%까지 떨어졌고, 대시보드는 평소보다 최대 80배 느려졌다.
- 촉발
14:43 UTC 에 제어 플레인 데이터 센터의 네트워크 스위치 하나가 일부만 동작하는 상태에 빠졌다. LACP 와 BGP 는 계속 돌았지만 받은 패킷 일부를 전달하지 못했고, 스위치는 6분 뒤 스스로 회복했다.
- 원인
- 구성 요소
- 기여 요인
- 감지
14:43 UTC 에 스위치가 ping 에 응답하지 않는다는 알림이 울리기 시작했다. 그 뒤 엔지니어들이 주 인증 데이터베이스가 과부하에 걸린 것을 확인했다.
- 조치
- SSL 인증서를 엣지로 보내는 속도와 메일 발송 같은 기능을 줄여 주 인증 데이터베이스가 늘어난 부하를 감당할 여유를 만들었다.
- 읽기 복제본으로 처리할 수 있는 API 트래픽을 손으로 보조 데이터 센터로 돌렸다. API 가용성이 크게 나아졌다.
- 대시보드 사용자의 불편이 커지자 인증 호출을 모두 주 데이터 센터로 되돌렸고, 성능이 떨어진 상태에서도 최대한 버티도록 주 데이터베이스를 계속 손봤다.
- 21:20 UTC 에 첫 데이터베이스 복제본이 다시 만들어지자마자 자동으로 서비스에 투입됐고, 성능이 정상으로 돌아왔다.
- 줄였던 서비스를 모두 다시 올려 밀린 비동기 처리가 따라잡게 했고, 한동안 지켜본 뒤 장애 종료를 선언했다.
- 후속 조치
- 새 primary 를 승격하면 데이터베이스 복제본을 모두 다시 만들어야 하는 클러스터 관리 시스템의 제약을 고친다. Cloudflare 는 글을 쓸 무렵 이 결함을 이미 고쳤다고 밝혔다.
- 트래픽을 다른 데이터 센터로 돌려야 할 때 유연하게 대응하지 못하는 사용자 세션 시스템을 다시 설계한다.
- 자동 복구 조치의 설정 값을 다시 검토한다. 적어도 데이터베이스 하나에서는 복제본을 primary 로 승격하는 절차를 그렇게 빨리 시작하지 않도록 장애 직후 설정을 바꿨다.
- 이 장애에 얽힌 시스템마다 자기가 의존하는 시스템의 고장을 더 잘 견디도록 계속 조정한다.
- 교훈
모든 시스템에 이중화가 있었지만, 고장 난 시스템들은 완전히 멈추지 않고 성능이 떨어진 채로 동작했다. 그래서 뒤이어 일어난 일들을 미리 모델링하고 예상하기가 훨씬 어려웠다. 1분 만에 복제본을 승격하는 자동 조치는 Cloudflare 가 자랑하던 기능이었지만, 적어도 데이터베이스 하나에서는 그 조치가 원래 문제보다 더 큰 피해를 낼 수 있었다. 대부분의 범용 클러스터 관리 시스템은 비잔틴 장애를 견디는 프로토콜을 쓰지 않고 RAFT 처럼 단순한 프로토콜을 쓴다. 드문 장애 유형에 약하다고 알려진 단순한 프로토콜이 구현과 디버깅이 어려운 복잡한 프로토콜보다 안전한 경우가 많다고 Cloudflare 는 보았다.
- 증상
2012년 11월 30일 금요일, GitHub 는 18분 동안 완전히 접속이 안 됐고, 하루 종일 응답이 이따금 느려지고 오류가 간헐적으로 났다. 파일 서버 한 쌍이 하루 대부분 내려가 있어 일부 저장소가 영향을 받았다.
- 촉발
새 애그리게이션 스위치를 들이려고 액세스 스위치를 떼어 설정을 바꾸고 다시 연결하는 작업을 했다. 11월 30일 아침 A 스위치를 옮기던 중 마지막 스위치에서 브리지 루프가 생겼다.
- 원인
- 구성 요소
- 기여 요인
- 감지
마지막 A 스위치를 연결할 때 같은 캐비닛의 B 스위치와 연결이 끊겼다. 문제를 고친 뒤에도 성능이 기대만큼 나오지 않아 들여다보다가 액세스 스위치와 애그리게이션 스위치 사이 링크가 모두 포화된 것을 봤다.
- 조치
- 마지막 A 스위치에서 난 첫 문제를 빨리 해결하고, 영향받은 B 스위치를 다시 서비스에 넣어 이전을 마쳤다.
- 액세스 스위치에서 잘못된 설정을 지웠다. 그 뒤로는 링크를 시험해도 페일오버가 기대대로 작동했고, 애그리게이션 계층이나 액세스 계층의 스위치 하나를 빼도 서버에 영향이 없었다.
- 몇 시간을 더 찾아도 설정 문제가 나오지 않자 네트워크 공급사에 다시 에스컬레이션했고, 공급사는 이 문제를 가장 높은 심각도 등급으로 올려 바로 함께 조사했다.
- 태평양 시간 토요일 오전 6시에 네트워크 점검 시간을 잡고 애그리게이션 스위치의 핵심 프로세스 일부를 재시작해 MAC 주소를 다시 학습하게 했다. 이 우회책이 통해서 트래픽과 성능이 정상으로 돌아왔다.
- 후속 조치
- 공급사가 MAC 학습 문제의 근본 원인을 찾았고, 1주일쯤 안에 최종 수정이 나오면 스위치에 소프트웨어 업데이트를 배포한다.
- 그때까지 애그리게이션 계층과 액세스 계층 사이 용량을 면밀히 지켜보고, 문제가 다시 나면 쓸 우회 절차를 둔다.
- 라우터부터 액세스 계층 스위치까지 네트워크 스택을 똑같이 한 벌 더 갖춰 스테이징 환경으로 쓰고, 이런 변경을 미리 더 충분히 시험한다.
- 비슷한 문제가 생기면 더 빨리 알림을 받도록 네트워크에 자동 모니터링을 더한다.
- 앞으로 몇 달 동안 정기적인 장애 대응 훈련을 늘리고, 한 가지 가설에 매달리지 않도록 하는 시나리오를 만든다.
- 앞으로는 네트워크에 문제 조짐이 처음 보일 때 바로 공급사 지원팀에 연락한다.
- 교훈
GitHub 는 고객에게 영향이 없도록 설계한 점검 작업이 결국 고객에게 영향을 줬다고 인정했다. 장애 대응 중에 브리지 루프라는 생각에 오래 매달려 다른 원인을 보지 못했고, 그래서 한 가지 가설에 갇히는 것을 더 경계해야 한다고 했다. GitHub 는 공급사 지원팀과 일한 경험이 좋았다며, 앞으로는 문제 조짐이 처음 보일 때 바로 지원팀에 연락하겠다고 했다.
이 3건에서 가장 많이 나오는 구성 요소: NIC·케이블·스위치 포트 링크, 백본망. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.