사례5건

5건 중 1~5번째

1. IL-0509 DDoS 뒤 상위 망의 null route 로 SourceHut 의 PHL 데이터센터 망이 끊겨 170시간 동안 장애가 이어졌다

   SourceHut2024

   증상

   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 를 걸었다.

   원인

   의존성 장애

   구성 요소

   ISP·트랜짓 망BGP 라우팅

   기여 요인

   단일 장애점디버그 접근 제한미검증 백업

   감지

   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 로 옮기려던 장기 목표 상당수를 빨리 이뤘다.

   사례 보기
2. IL-0267 싱가포르 캐시 거점 eqsin 의 전송 회선 두 개가 함께 끊겨 BGP 가 내려가고 eqsin 의 호스트에 닿을 수 없게 됐다

   Wikimedia Foundation2023

   증상

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

   네트워크 도달 불가

   촉발

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

   원인

   의존성 장애

   구성 요소

   백본망BGP 라우팅CDN 과 엣지 네트워크

   기여 요인

   단일 장애점초기 신호 무시

   감지

   자동 모니터링이 먼저 잡았다. 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 에서 감당하기 어려울 만큼 많았다.

   사례 보기
3. IL-0255 데이터센터 사이 메트로 회선이 잠깐 끊긴 뒤 Redis 레플리카가 재동기화 루프에 빠져 BC3 가 느려지고 채팅이 멈췄다

   37signals2020

   증상

   2020년 8월 28일 금요일 11:59AM CDT 에 PagerDuty, Nagios, Prometheus 에서 알림이 쏟아졌다. 모니터링에는 새 메트로 회선이 20~30초쯤 끊긴 것이 보였고, 네트워크가 돌아온 뒤에도 BC3 응답이 계속 느렸다.

   링크 플래핑지연 시간 증가복제 지연

   촉발

   2020년 8월 28일 11:59AM CDT 에 Ashburn 의 주 데이터센터와 Chicago 데이터센터를 잇는 이중 메트로 회선이 짧게 끊겼다. 모니터링에는 새 회선이 20~30초 끊긴 것만 보였지만, 로그에서는 두 회선이 모두 잠깐씩 끊긴 것이 드러났다.

   원인

   의존성 장애

   구성 요소

   백본망BGP 라우팅인메모리 캐시데이터베이스 복제

   기여 요인

   단일 장애점재시도 폭주잡음에 묻힌 신호

   감지

   PagerDuty, Nagios, Prometheus 에서 알림이 쏟아졌다. Redis 문제는 상황이 진정된 뒤 Redis DB 인스턴스 하나에 계속 떠 있던 알림을 보고 찾았다.

   조치

   • 로드 밸런서 계층에서 채팅을 꺼 나머지 BC3 를 안정시켰다.
   • 레플리카의 Redis 를 재시작했다.

   후속 조치

   • 알려진 Redis 문제의 문서화된 우회 방법대로 Redis 서버의 설정을 바꾼다.
   • 두 메트로 회선이 펜실베이니아에서 같은 물리 경로를 지나는 문제를 없앨 구체적인 계획을 세운다.
   • 장애 조치 시스템을 최대 부하 때 운영 환경에서 직접 검증한다.
   • 사고 후속 조치를 할 시간을 명시적으로 비우고, 우선순위를 밝혀 다른 일을 뒤로 미룬다.

   교훈

   이중화를 계획하고 실제 시험을 늘려 왔지만 충분하지 않았고, 특히 최대 부하에서는 안전하다는 착각을 하고 있었다. 데이터센터 사이로 부하를 옮기거나 이중 회선 사이를 오가는 일은 문제없이 돼야 한다. 그렇지 않다면 팀 전체가 준비된 통제된 상황에서 그 사실을 알아야 한다. 장애에서 나온 후속 조치는 목록에 더하는 데서 그치지 말고 더 급하게 처리해야 한다.

   사례 보기
4. IL-0358 Packet 공용 클라우드의 여러 리전에서 라우팅 루프와 블랙홀로 연결이 간헐적으로 끊겼다

   Packet2019

   증상

   2019-06-02 08:49 UTC 에 Packet 의 내부 네트워크 모니터링이 여러 글로벌 데이터센터에서 목적지에 닿지 못하는 문제와 성능 문제를 알렸다. 엔지니어들은 08:52 에 이 연결 문제를 확인했다.

   네트워크 도달 불가패킷 손실지연 시간 증가

   촉발

   Packet 의 상위 네트워크 사업자 Zayo 의 미국 대륙 횡단 백본 링크에 하드웨어 고장이 나서, 그 링크로 라우팅된 IP 트래픽이 블랙홀로 사라졌다.

   원인

   의존성 장애

   구성 요소

   백본망BGP 라우팅네트워크 컨트롤 플레인

   기여 요인

   –

   감지

   08:49 UTC 에 모니터링 도구가 Packet 의 여러 글로벌 데이터센터에서 목적지에 닿지 못하는 문제를 알렸다. 08:52 에 엔지니어링 팀이 문제를 확인하고 내부 사고를 만들어 운영 인력과 플랫폼 엔지니어링, 네트워크 엔지니어링의 에스컬레이션 담당자를 불렀다.

   조치

   • 트래픽을 다른 네트워크로 옮겨 Zayo 를 상위 사업자 구성에서 뺐다.
   • 알맞은 경로 필터를 적용해 서비스를 정상으로 되돌렸다.
   • 바뀐 트래픽 구성에 맞춰 특정 라우팅 정책을 다듬어 백본 전반의 지연을 줄였다.

   후속 조치

   • 내부 연결 모니터링을 넓히고, 당직 운영팀에게 가는 알림을 늘린다.
   • 네트워크 자동화와 라우팅 프로토콜 구현을 넓혀 쓸 수 있는 모든 백본 경로로 더 잘 라우팅하고 부하를 나눈다. 큰 사업자 사고가 나면 운영자가 Packet 의 모든 데이터센터에 걸쳐 자동 트래픽 우회를 실행할 수 있게 한다.
   • Packet 의 프로비저닝 시스템과 서비스가 외부 네트워크 사업자와 데이터센터 사이 연결에 덜 의존하게 해서 복원력을 높인다.

   사례 보기
5. IL-0258 DDoS 방어 업체에서 데이터센터로 가는 GRE 터널이 끊겨 FastMail 이 두 시간 가까이 접속되지 않았다

   Fastmail2016

   증상

   멜버른 시간 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 터널이 끊겼다.

   원인

   의존성 장애

   구성 요소

   DDoS 방어 서비스BGP 라우팅

   기여 요인

   디버그 접근 제한

   감지

   데이터센터 업체 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 방어로 옮기면서 그 통제를 잃었다.

   사례 보기

원인별1