사례6건

6건 중 1~5번째

1. IL-0526 HE.net 암스테르담 라우팅 장비 고장으로 OpenStreetMap.org 의 이중 광 회선이 모두 끊김

   OpenStreetMap Foundation2024

   증상

   2024년 12월 15일 03:53 UTC 에 OpenStreetMap.org 에 접속할 수 없게 됐고, 04:01 UTC 에 StatusCake 모니터링이 장애를 잡아 SMS 알림을 보냈다. 웹사이트와 지도 API 가 완전히 내려갔다.

   네트워크 도달 불가서비스 중단

   촉발

   2024년 12월 15일 03:53 UTC 에 HE.net 의 암스테르담 라우팅 장비가 예기치 않게 고장 났다.

   원인

   의존성 장애

   구성 요소

   ISP·트랜짓 망데이터베이스 복제

   기여 요인

   단일 장애점런북 부재

   감지

   04:01 UTC 에 StatusCake 모니터링이 장애를 잡아 SMS 알림을 보냈고, 곧바로 운영 팀에 알려졌다.

   조치

   • 11:31 UTC 에 더블린에 있는 OpenStreetMap.org 의 읽기 전용 백업 인스턴스를 켜 일부 기능을 되살렸다. 사이트에는 편집 내용을 저장할 수 없다는 점검 안내를 띄웠다.
   • 12월 17일 12:21 UTC 에 HE.net 을 거치지 않는 새 Equinix Internet 회선을 암스테르담에서 개통해 OpenStreetMap.org 와 API 의 모든 기능을 되살렸다.
   • 12월 18일 00:29 UTC 에 HE.net 이 암스테르담 서비스가 복구됐다고 확인했고, HE.net 경로가 정상으로 돌아와 OpenStreetMap.org 의 모든 네트워크 경로를 다시 쓸 수 있게 됐다.

   후속 조치

   • 한 사업자가 고장 나도 다른 사업자로 거의 끊김 없이 넘어가도록 여러 ISP 를 쓰는 구성으로 옮긴다.
   • 암스테르담 서버의 예비 ISP 후보를 대역폭, 신뢰성, 비용으로 비교한다. 2025년 2월 Karlsruhe Hack Weekend 에서 BGP 를 쓰는 방안과 HE.net 을 예비 ISP 로 남기는 방안을 포함해 실제 선택지를 논의한다.
   • 경로와 지연 시간을 더 깊이 모니터링해 ISP 문제를 빨리 잡고, 자동 에스컬레이션 절차를 만든다.
   • ISP 사이 트래픽 전환을 시험하는 페일오버 훈련 일정을 정하고, 복제 과정이 최신이며 믿을 만한지 확인해 사이트 페일오버를 부담 없이 쓸 수 있는 선택지로 만든다.
   • HE.net, Equinix Internet 과 계약상 SLA 를 협의하고, 정해진 에스컬레이션 절차와 응답 시간을 계약에 넣는다.
   • 대역 외 접속에 쓰는 Raspberry Pi 4 와 4G 모뎀을 ISP 장애 때 수동 예비 업링크로 쓸 수 있게 미리 설정한다. 이 회선으로 서버에 접속하고 Postgres 복제 데이터를 보조 사이트로 동기화한다. 대역 외 장비는 견고하고 이중화되도록 업그레이드한다.
   • 장애 소식을 알리는 일을 맡을 이해관계자와 각자의 책임, 권장 소통 채널을 정리한 문서를 만든다. 운영 팀은 소통을 다른 사람에게 맡기고 복구에 집중한다.
   • OpenStreetMap.org 의 "rails-port" 유지 관리자가 OAuth 서비스를 분리해, 사이트가 흔들릴 때도 제3자 서비스의 인증이 계속 동작하게 할 수 있는지, 그 방법이 현실적인지 조사한다.

   교훈

   암스테르담 서버가 HE.net 하나에만 기대고 있어 단일 장애 지점이 생겼고, 앞으로는 상위 사업자를 여럿 둔다. 4G 예비 회선을 쓴 대역 외 접속이 아주 쓸모 있었으므로, 데이터 동기화까지 할 수 있게 신뢰성과 기능을 넓힌다. 읽기 전용 백업으로 일부 서비스는 됐지만, 복제가 이어지고 있었다면 편집 기능을 더 빨리 되살렸을 것이다. ISP 와 자주 연락해도 쓸 만한 복구 예상 시각을 받지 못했으므로, SLA 를 더 잘 이해하고 ISP 에 더 투명하게 알려 달라고 요구해야 한다. 상위 연결의 알림을 다듬고 여러 모니터링 출처의 데이터를 한데 모아야 문제를 더 빨리 짚을 수 있다. OpenStreetMap.org 가 읽기 전용이 되면 새 토큰을 저장하지 못해, 장애와 무관한 community.openstreetmap.org 같은 서비스에도 로그인할 수 없게 된다.

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

   사례 보기
3. IL-0259 Fastmail 에서 나가는 패킷이 인터넷 일부에 닿지 않아 고객 3~5% 가 약 19시간 동안 Fastmail 을 쓰지 못했다

   Fastmail2023

   증상

   2023년 6월 30일 03:00 UTC 무렵부터 Fastmail 과 인터넷 일부가 서로 통신하지 못했다. 문제는 약 19시간 이어졌고, 고객의 3~5% 로 추정되는 사용자와 일부 메일 서버가 영향을 받았다.

   네트워크 도달 불가

   원인

   의존성 장애

   구성 요소

   ISP·트랜짓 망

   기여 요인

   단일 장애점모니터링 사각지대

   감지

   고객들이 지원 티켓과 소셜 미디어로 알려 와서 처음 알았다. 세계 여러 곳에 둔 모니터링 장비도, 직원들도 문제가 있는 네트워크에 있지 않아 장애를 보지 못했다.

   후속 조치

   • 서버에 직접 들어오는 두 번째 트랜짓 회선을 둘 공급사를 고른다. Megaport 를 거치거나 365 의 New Jersey 데이터센터에 직접 들어와 있는 업체를 쓰고, 나가는 트래픽 경로를 직접 골라 문제 있는 네트워크를 피해 간다.

   교훈

   나가는 트래픽의 경로가 하나뿐이어서 Fastmail 은 공급사 네트워크의 문제를 피해 갈 수 없었고 스스로 고칠 수도 없었다. 나가는 경로를 여러 개 중에서 고를 수 있으면 모든 사용자를 더 빨리 다시 접속하게 할 수 있다.

   사례 보기
4. 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 에서 감당하기 어려울 만큼 많았다.

   사례 보기
5. 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 의 프로비저닝 시스템과 서비스가 외부 네트워크 사업자와 데이터센터 사이 연결에 덜 의존하게 해서 복원력을 높인다.

   사례 보기

원인별1