사례3건
3건 중 1~3번째
- 증상
2024년 1월 10일 06:00 UTC 무렵 모니터링 시스템이 SourceHut 의 PHL 인프라에 이상이 있다고 경보를 울렸다. 09:00 UTC 무렵에는 PHL 망에 아예 닿을 수 없게 됐다.
- 촉발
2024년 1월 10일 06:00 UTC 무렵 SourceHut 의 PHL 인프라를 노린 layer 3 DDoS 가 시작됐다. 상위 망인 Cogent 가 이에 대응해 SourceHut 의 하위 AS 에 null route 를 걸었다.
- 원인
- 구성 요소
- 기여 요인
- 감지
06:00 UTC 무렵 모니터링 시스템이 이상을 알아채 경보를 울렸고, 운영팀은 곧 조사를 시작했다.
- 조치
- 코로케이션 사업자가 Cogent 를 설득해 null route 를 /24 전체에서 DDoS 가 노리던 IP 주소 하나인 /32 로 좁혔다.
- 외부 DNS 로 옮겼다.
- 새 주 데이터베이스를 띄웠다.
- FRE 의 백업을 AMS 로 복원했다.
- 운영 데이터와 마지막 백업 사이의 차이를 손으로 반영했다.
- 새 메일 시스템을 갖추고 메일 서비스를 그 시스템에 맞게 설정했다.
- OVH 서버를 두고 트래픽을 OVH 의 DDoS 방어 망을 거쳐 AMS 의 비공개 운영 서브넷으로 NAT 했다. 이 방식으로 종단 간 암호화를 지키면서 임의의 TCP 프로토콜도 서비스했다.
- 1월 12일 PHL 망 사업자가 임시 서브넷을 내줘 PHL 서버에 대역 외로 접근했고, 이것으로 대체 인프라를 더 빨리 갖췄다.
- PHL 에서 AMS 로 객체 저장소를 옮기는 동안 pages.sr.ht 를 PHL 로 가는 대역 외 링크로 서비스했다. 성능에는 제약이 있었다.
- pages.sr.ht 가 새 서브넷과 IP 주소로 옮겨 가면서, apex 레코드가 PHL 서브넷을 직접 가리키던 사용자에게 손으로 고치는 방법을 메일로 보냈다.
- AMS 의 연산 용량이 모자라 builds.sr.ht 의 빌드 워커를 OVH 의 전용 베어메탈 서버에서 돌렸다.
- 후속 조치
- 새 대기 데이터베이스를 갖춘다. 사고 뒤 작업 가운데 이미 끝난 일이다.
- AMS 에서 FRE 로 백업을 받도록 설정한다. 이미 끝난 일이다.
- 새 모니터링 시스템을 설치한다. 진행 중인 일이다.
- PHL 데이터센터의 설비를 완전히 정리하고, PHL 의 서버를 포장해 AMS 로 보내 용량을 보탠다.
- 몇 주 안에 빌드용 연산 서버를 PHL 에서 AMS 로 옮긴 뒤 빌드 서비스를 SourceHut 이 운영하는 인프라로 되돌린다.
- SourceHut 을 온프레미스 쿠버네티스 클러스터에서 돌리는 방법을 연구해 구현한다. 내부 유지 보수 때 사용자가 겪는 중단을 줄이고 이런 사고에 더 잘 견디려는 것이다.
- 그 작업이 끝나면 두 번째 운영 데이터센터를 계획한다. 두 데이터센터가 함께 부하를 나누고, 한 데이터센터에 장애가 나면 다른 쪽이 전체 서비스를 넘겨받게 한다.
- 교훈
SourceHut 은 데이터센터 전체 장애까지 대비해 둔 운영 계획이 이번 대응에 중요했다고 적었다. 이번 사고는 SourceHut 이 이중화와 복원력 목표를 다 이루기 전에, 알고 고치던 약점을 드러냈다. pages.sr.ht 의 S3 호환 객체 저장소가 오프사이트 백업에 들어 있지 않다는 것도 이번에 알았다. SourceHut 은 이번 일로 비상 절차를 실제로 시험해 볼 수 있었고, 안정성을 더 높일 방법을 많이 배웠다고 적었다. 긴급 이전으로 EU 로 옮기려던 장기 목표 상당수를 빨리 이뤘다.
- 증상
16시 37분 UTC 에 Icinga 가 cr3-eqsin 의 BGP 상태가 CRITICAL 이라고 알렸고, 몇 분 뒤 eqsin 의 호스트들이 한꺼번에 DOWN 으로 떴다. 호출 알림 세 건이 동시에 울렸고 그중 두 건은 batphone 으로 올라갔다.
- 촉발
eqsin 을 코어 데이터센터에 잇는 전송 회선 두 개 중 하나는 오래 이어진 광케이블 절단으로 끊겨 있었다. 남은 하나가 전송 회선 공급사 Arelion 의 계획 작업 PWIC225900 으로 내려갔다.
- 원인
- 구성 요소
- 기여 요인
- 감지
자동 모니터링이 먼저 잡았다. 16시 37분 UTC 에 Icinga 가 cr3-eqsin 의 BGP 상태 CRITICAL 을 알렸고, 이어서 cr2-eqsin 의 BGP 상태와 eqsin 호스트들의 DOWN 알림이 울렸다. 호출 알림 세 건이 동시에 울렸고 그중 두 건이 batphone 으로 올라갔다.
- 조치
- 16시 48분 UTC 에 eqsin 을 DNS 에서 뺐다.
- 나중에 eqsin 을 다시 DNS 에 넣었다.
- 후속 조치
- 백업 GRE 터널을 만든다. 작업은 T327265 이다.
- 오래 끊겨 있던 전송 회선이 수리된 뒤 제대로 다시 올라오는지 확인한다. 작업은 T322529 이다.
- 공급사의 점검 알림을 자동으로 읽어 들여 점검 일정이 서로 겹치면 알린다. 작업은 T230835 이다.
- 교훈
eqsin 을 DNS 에서 빨리 뺀 것이 잘됐고, 먼저 빼고 나중에 조사한다는 태도가 맞았다. 잘못된 것은 세 가지였다. eqsin 이 너무 오래 전송 회선 하나로만 버텼다. 두 전송 회선이 겹쳐서 내려가는 것을 SRE 들이 잡지 못했다. 공급사의 계획 작업이 작업 티켓이나 알림으로 남지 않았다. 알림은 맞게 울렸지만 IRC 에서 감당하기 어려울 만큼 많았다.
- 증상
2020년 8월 28일 금요일 11:59AM CDT 에 PagerDuty, Nagios, Prometheus 에서 알림이 쏟아졌다. 모니터링에는 새 메트로 회선이 20~30초쯤 끊긴 것이 보였고, 네트워크가 돌아온 뒤에도 BC3 응답이 계속 느렸다.
- 촉발
2020년 8월 28일 11:59AM CDT 에 Ashburn 의 주 데이터센터와 Chicago 데이터센터를 잇는 이중 메트로 회선이 짧게 끊겼다. 모니터링에는 새 회선이 20~30초 끊긴 것만 보였지만, 로그에서는 두 회선이 모두 잠깐씩 끊긴 것이 드러났다.
- 원인
- 구성 요소
- 기여 요인
- 감지
PagerDuty, Nagios, Prometheus 에서 알림이 쏟아졌다. Redis 문제는 상황이 진정된 뒤 Redis DB 인스턴스 하나에 계속 떠 있던 알림을 보고 찾았다.
- 조치
- 로드 밸런서 계층에서 채팅을 꺼 나머지 BC3 를 안정시켰다.
- 레플리카의 Redis 를 재시작했다.
- 후속 조치
- 알려진 Redis 문제의 문서화된 우회 방법대로 Redis 서버의 설정을 바꾼다.
- 두 메트로 회선이 펜실베이니아에서 같은 물리 경로를 지나는 문제를 없앨 구체적인 계획을 세운다.
- 장애 조치 시스템을 최대 부하 때 운영 환경에서 직접 검증한다.
- 사고 후속 조치를 할 시간을 명시적으로 비우고, 우선순위를 밝혀 다른 일을 뒤로 미룬다.
- 교훈
이중화를 계획하고 실제 시험을 늘려 왔지만 충분하지 않았고, 특히 최대 부하에서는 안전하다는 착각을 하고 있었다. 데이터센터 사이로 부하를 옮기거나 이중 회선 사이를 오가는 일은 문제없이 돼야 한다. 그렇지 않다면 팀 전체가 준비된 통제된 상황에서 그 사실을 알아야 한다. 장애에서 나온 후속 조치는 목록에 더하는 데서 그치지 말고 더 급하게 처리해야 한다.
이 3건에서 가장 많이 나오는 구성 요소: BGP 라우팅, 백본망. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.