Incident Library

IL-0267 Wikimedia Foundation · 2023-01-10networking

싱가포르 캐시 거점 eqsin 의 전송 회선 두 개가 함께 끊겨 BGP 가 내려가고 eqsin 의 호스트에 닿을 수 없게 됐다

eqsin 은 전송 회선 두 개로 코어 데이터센터에 이어져 있었다. 그중 하나는 T322529 에 기록된 광케이블 절단으로 오래 끊겨 있었다. 전송 회선 공급사 Arelion 은 2022년 12월 22일에 계획 작업 PWIC225900 을 알렸고 작업 전날 다시 알렸다. 하지만 이 공급사 계획 작업은 작업 티켓이나 알림으로 남지 않았고, SRE 들은 두 회선이 겹쳐서 끊기는 것을 미리 잡지 못했다.

2023년 1월 10일 16시 00분 UTC 에 작업 시간이 시작되며 남은 회선도 내려갔다. 16시 37분 cr3-eqsin, 16시 44분 cr2-eqsin 의 BGP 상태가 CRITICAL 로 떴고, 16시 45분부터 eqsin 의 호스트와 로드 밸런서가 잇달아 DOWN 으로 떴다. 16시 48분에 SRE 가 eqsin 을 DNS 에서 뺐다. 평소 eqsin 으로 가던 사용자, 주로 APAC 지역 사용자는 약 11분 동안 eqsin 에 캐시된 Wikipedia 페이지만 읽을 수 있었다. 사용자 DNS 리졸버가 이를 반영하는 데 걸리는 시간 때문에 영향이 길게는 30분 더 이어졌다. 사고 기록은 아시아 사용자가 약 11분에서 41분 동안 영향을 받았다고 적었다. 16시 55분부터 호스트들이 회복됐고, 이후 eqsin 을 다시 DNS 에 넣었다. 사고는 20시 57분에 끝난 것으로 기록됐다.

심각도
–
영향 범위
Users normally directed to eqsin could read only Wikipedia pages already cached in eqsin
영향 사용자
users in Asia, mostly in the APAC region, for about 11 to 41 minutes
지역
APAC (eqsin)
감지까지
–
복구까지
4h 57m

증상

16시 37분 UTC 에 Icinga 가 cr3-eqsin 의 BGP 상태가 CRITICAL 이라고 알렸고, 몇 분 뒤 eqsin 의 호스트들이 한꺼번에 DOWN 으로 떴다. 호출 알림 세 건이 동시에 울렸고 그중 두 건은 batphone 으로 올라갔다.

첫 알림은 "PROBLEM - BGP status on cr3-eqsin is CRITICAL: BGP CRITICAL - AS1299/IPv6: Active - Telia, AS1299/IPv4: Active - Telia" 였다. 16시 44분에는 "PROBLEM - BGP status on cr2-eqsin is CRITICAL: BGP CRITICAL - No response from remote host 103.102.166.130" 이 이어졌다.

16시 45분부터 16시 47분 사이에 bast5002, doh5001, prometheus5001, ncredir5001, netflow5002, cr2-eqsin, durum5002, cr3-eqsin, ncredir5002, durum5001, install5001, doh5002, upload-lb.eqsin.wikimedia.org, text-lb.eqsin.wikimedia.org 가 차례로 "is DOWN: PING CRITICAL - Packet loss = 100%" 로 떴다. 16시 49분과 16시 50분에는 cr2-eqsin, mr1-eqsin, cr3-eqsin, ripe-atlas-eqsin 의 IPv6 도 같은 알림을 냈다. 알림이 IRC 에서 감당하기 어려울 만큼 쏟아졌다. 호스트 다운 알림이 이렇게 몰리면 대개 네트워크 문제다.

평소 eqsin 으로 가던 사용자, 주로 APAC 지역 사용자는 약 11분 동안 eqsin 에 이미 캐시된 Wikipedia 페이지만 읽을 수 있었다. 사용자의 DNS 리졸버가 eqsin 이 빠진 것을 반영하기까지 시간이 더 걸려 영향은 길게는 30분 더 이어졌다. 16시 55분부터 호스트들에 "PING OK - Packet loss = 0%" 와 함께 RECOVERY 알림이 떴다.

증상 네트워크 도달 불가

원인

촉발
eqsin 을 코어 데이터센터에 잇는 전송 회선 두 개 중 하나는 오래 이어진 광케이블 절단으로 끊겨 있었다. 남은 하나가 전송 회선 공급사 Arelion 의 계획 작업 PWIC225900 으로 내려갔다.

감지

자동 모니터링이 먼저 잡았다. 16시 37분 UTC 에 Icinga 가 cr3-eqsin 의 BGP 상태 CRITICAL 을 알렸고, 이어서 cr2-eqsin 의 BGP 상태와 eqsin 호스트들의 DOWN 알림이 울렸다. 호출 알림 세 건이 동시에 울렸고 그중 두 건이 batphone 으로 올라갔다.

조치

후속 조치

교훈

eqsin 을 DNS 에서 빨리 뺀 것이 잘됐고, 먼저 빼고 나중에 조사한다는 태도가 맞았다. 잘못된 것은 세 가지였다. eqsin 이 너무 오래 전송 회선 하나로만 버텼다. 두 전송 회선이 겹쳐서 내려가는 것을 SRE 들이 잡지 못했다. 공급사의 계획 작업이 작업 티켓이나 알림으로 남지 않았다. 알림은 맞게 울렸지만 IRC 에서 감당하기 어려울 만큼 많았다.

출처

참고 문서

관련 사례

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

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 백본망, BGP 라우팅, CDN 과 엣지 네트워크. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

AI 도구와 스크립트용

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