그래프
사례3건
3건 중 1~3번째
- 증상
04시 34분에 모니터링 시스템이 첫 노드의 DNS 이름 해석 문제를 잡아 pager duty 알림을 울렸다. 첫 노드가 DNS 레코드를 해석하지 못하면서 인프라 전체의 가용성에 영향이 갔다.
- 촉발
Octez Connect 가 쓰는 하나뿐인 DNS 공급사 MetaNet 에서 장애가 났다. 공급사의 긴급 전화, 상태 페이지, 티켓 시스템도 함께 멈췄다.
- 원인
- 구성 요소
- 기여 요인
- 감지
04시 34분에 모니터링 시스템이 DNS 이름 해석 문제를 잡았다. 첫 노드가 DNS 를 해석하지 못해 pager duty 알림이 울렸다.
- 조치
- 04시 34분에 DNS 이름 해석 문제를 감지하고 pager duty 호출을 걸었다.
- 공급사의 긴급 전화를 계속 걸고 상태 페이지를 지켜보며 공급사에 광범위한 장애가 났음을 확인했다.
- 08시 20분에 [email protected] 에서 공급사가 문제를 살펴보고 있다는 답을 받았다.
- 08시 30분에 시험해서 DNS 가 다시 돌기 시작한 것을 확인했다.
- 08시 40분에 Slack 과 Twitter 에 복구를 알리는 공개 공지를 올렸다.
- 후속 조치
- DNS 공급사를 둘로 쓰는 구성을 만든다.
- 장애 정보를 실시간으로 알리는 공개 상태 페이지를 만든다.
- 외부 공급사 장애 때의 내부 에스컬레이션 절차를 다시 살피고 고친다.
- 교훈
DNS 공급사 하나에만 기대면 그 공급사가 단일 장애 지점이 되어 연결된 서비스가 모두 멈출 수 있다. 이번 DNS 장애는 가용성만이 아니라 공급사와의 소통도 늦춰 중단을 키웠다. 몇 시간 안에 복구됐지만, 공급사 하나가 장애를 겪어도 서비스가 계속 돌도록 DNS 공급사를 둘로 두어야 한다.
- 증상
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 로 옮기려던 장기 목표 상당수를 빨리 이뤘다.
- 증상
멜버른 시간 2016년 2월 7일 일요일 오전 4시 50분, UTC 로는 2월 6일 오후 6시 무렵 Level 3 와 NYI 사이의 GRE 터널이 끊겼다. FastMail 로 오는 트래픽이 FastMail 네트워크에 전혀 들어오지 못해 고객은 서비스를 쓸 수 없었다.
- 촉발
멜버른 시간 2016년 2월 7일 오전 4시 50분에 DDoS 방어를 맡은 Level 3 와 주 데이터센터 NYI 사이의 GRE 터널이 끊겼다.
- 원인
- 구성 요소
- 기여 요인
- 감지
데이터센터 업체 NYI 가 장애를 금방 알아챘다.
- 조치
- NYI 가 Level 3 지원 창구에 계속 상급자 대응을 요청해, FastMail 의 공인 IP 대역이 다시 NYI 를 가리키게 했다.
- 후속 조치
- DDoS 방어를 예전 방식으로 되돌려, NYI 가 직접 통제하는 가운데 Black Lotus 가 방어를 맡는다.
- Los Angeles 데이터센터에 보조 네트워크로 NYI 의 애플리케이션·메일 서버와 통신하는 nginx 프런트엔드를 새로 만든다. NYI 의 주 네트워크가 끊기면 DNS 로 www.fastmail.com, mail.messagingengine.com 같은 이름을 LA 프런트엔드로 돌린다.
- Amsterdam 에 하드웨어를 늘리고, 배달 시스템이 NYI 와 덜 통신하도록 내부를 바꾼다.
- NYI 가 네트워크 장애를 감지하고 대응하는 내부 절차를 NYI 와 함께 더 자세히 파악한다.
- 교훈
이렇게 복구가 늦어지는 것은 받아들일 수 없다. FastMail 과 NYI 가 쌓아 온 신뢰성의 큰 부분은 NYI 가 인프라를 직접 통제하는 데서 나왔다. 상시 DDoS 방어로 옮기면서 그 통제를 잃었다.
이 3건에서 가장 많이 나오는 구성 요소: BGP 라우팅, DDoS 방어 서비스. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.