사례7건

7건 중 1~5번째

1. IL-0394 Cloudflare Miami 라우터가 내부 IPv6 경로를 BGP 피어와 트랜짓 제공자에게 유출해 25분 동안 백본이 혼잡해지고 트래픽이 드롭됐다

   Cloudflare2026

   증상

   2026년 1월 22일 20:25 UTC 부터 Cloudflare 의 Miami edge 라우터 하나가 BGP 트랜짓 제공자와 피어에게 예상하지 않은 경로를 광고했다. 20:40 UTC 에 네트워크 팀이 Miami 에서 나간 의도하지 않은 경로 광고를 조사하기 시작했다.

   패킷 손실지연 시간 증가

   촉발

   20:25 UTC 에 정책 자동화 플랫폼으로 Bogotá 데이터센터용 BGP 광고를 Miami 에서 빼는 변경을 내보냈다. 이 변경이 Miami 라우터의 여러 BGP export 정책에서 prefix-list 6-BOG04-SITE-LOCAL 줄만 지워, 남은 정책이 route-type internal 인 경로를 모두 받아들여 밖으로 광고하게 됐다.

   원인

   설정 변경

   구성 요소

   BGP 라우팅백본망

   기여 요인

   설정 테스트 부재

   감지

   20:40 UTC 에 네트워크 팀이 Miami 에서 나간 의도하지 않은 경로 광고를 조사하기 시작했고, 20:44 UTC 에 대응을 조율하려고 인시던트를 열었다.

   조치

   • 20:50 UTC 에 네트워크 운영자가 잘못된 설정 변경을 손으로 되돌렸다. 이때 영향이 끝났다.
   • 자동화가 같은 라우터에서 다시 돌지 않도록 그 라우터의 자동화를 멈췄다.
   • 21:47 UTC 에 유출을 촉발한 변경을 네트워크 자동화 코드 저장소에서 되돌렸다.
   • 22:07 UTC 에 운영자가 라우팅 정책 버그 없이 자동화가 다시 돌 수 있음을 확인했고, 22:40 UTC 에 Miami 라우터의 자동화를 다시 켰다.

   후속 조치

   • 경로 유출을 일으킨 라우팅 정책 자동화의 결함을 고치고, 이 결함과 비슷한 결함을 바로 막는다.
   • 외부 export 정책에서 제공자와 피어에게서 받은 경로를 명시적으로 거부하는 BGP community 기반 안전장치를 라우팅 정책에 더한다.
   • 비어 있거나 잘못된 정책 term 을 찾는 라우팅 정책 자동 평가를 CI/CD 파이프라인에 넣는다.
   • 네트워크 설정 문제와 자동 변경의 나쁜 영향을 더 일찍 알아채도록 개선한다.
   • RFC9234 의 BGP role 과 Only-to-Customer Attribute 를 배포하기에 앞서 라우팅 장비 공급사의 구현을 검증한다. BGP role 과 Only-to-Customer Attribute 는 라우팅 정책과 상관없이 자기 AS 에서 생기는 경로 유출을 막는 유일한 방법이다.
   • 비정상적인 AS path 를 가진 경로를 네트워크가 자동으로 거부할 수 있게 하는 RPKI Autonomous System Provider Authorization, 곧 ASPA 를 장기적으로 채택하도록 권한다.

   교훈

   Cloudflare 는 이번 사고로 경로 유출을 실수로 일으키기가 얼마나 쉬운지 직접 겪었다고 적었다. 경로 유출을 막으려면 여러 갈래의 대책이 필요하고, 라우팅 정책 설정과 자동화에서 단기와 장기로 고칠 곳을 여럿 찾았다고 했다.

   사례 보기
2. IL-0341 Cloudflare 와 AWS us-east-1 사이 링크가 혼잡해져 그 리전에 오리진을 둔 고객이 높은 지연과 패킷 손실을 겪었다

   Cloudflare2025

   증상

   2025년 8월 21일 16:27 UTC 부터 AWS us-east-1 에 오리진을 둔 고객과, us-east-1 의 서버를 거쳐 Cloudflare 와 트래픽을 주고받는 사용자에게 높은 지연, 패킷 손실, 오리진 연결 실패가 났다. 16:44 에 Cloudflare 네트워크 팀이 애시번 IAD 의 내부 혼잡 알림을 받았다.

   패킷 손실지연 시간 증가간헐적 타임아웃

   촉발

   16:27 UTC 쯤 한 고객이 AWS us-east-1 에서 Cloudflare 캐시에 있는 객체를 대량으로 요청하기 시작했다. 그 응답 트래픽이 Cloudflare 에서 AWS 로 가는 전체 트래픽을 두 배로 늘렸다.

   원인

   용량 한계

   구성 요소

   트랜짓 게이트웨이와 네트워크 연결 장비BGP 라우팅CDN 과 엣지 네트워크

   기여 요인

   여유 용량 부재수동 조치 악화과도한 영향 범위

   감지

   장애가 시작되고 17분 뒤인 16:44 UTC 에 Cloudflare 네트워크 팀이 애시번 IAD 의 내부 혼잡 알림을 받았다. 17:45 에는 애시번 IAD 의 고객 영향을 이유로 장애가 선언됐다.

   조치

   • 19:05 UTC 에 트래픽 급증을 일으킨 고객 하나에 속도 제한을 걸어 혼잡을 줄였다.
   • 네트워크 팀이 트래픽 엔지니어링 조치를 더 해 19:27 에 혼잡을 완전히 풀었다.
   • 19:45 부터 Cloudflare 의 요청에 따라 AWS 가 BGP 광고 철회를 되돌렸고, 20:07 에 IAD PNI 로 Cloudflare 에 보내는 BGP 프리픽스 광고를 정상으로 돌려놓았다.

   후속 조치

   • 한 고객의 트래픽이 다른 고객에게 영향을 줄 만큼 네트워크를 혼잡하게 만들기 시작하면 그 트래픽의 우선순위를 골라서 낮추는 장치를 만든다.
   • Data Center Interconnect 증설을 앞당겨 네트워크 용량을 지금보다 크게 늘린다.
   • AWS 와 함께 양쪽의 BGP 트래픽 엔지니어링 조치가 앞으로 서로 부딪치지 않게 한다.
   • 고객마다 네트워크 자원을 나눠 예산을 정하고, 예산을 넘긴 고객의 트래픽이 다른 고객의 서비스를 떨어뜨리지 못하게 하는 새 트래픽 관리 시스템을 만든다. 이 시스템은 이번에 손으로 한 혼잡 대응 조치 상당수도 자동화한다.

   교훈

   Cloudflare 는 이 사고로 한 고객의 사용 방식이 나머지 생태계를 해치지 못하게 막는 안전장치가 더 필요하다는 것이 드러났다고 했다. 어느 한 고객이 공유 자원을 독차지해 다른 고객의 안정성을 해치지 못하도록 고객 격리를 더 잘 설계해야 하고, 수요를 감당할 만큼 네트워크 인프라 용량을 늘려야 한다는 것을 핵심 교훈으로 꼽았다. 결론에서는 드물게 트래픽이 몰린 상황에서 네트워크 혼잡 관리가 모자라 장애가 났다고 했다.

   사례 보기
3. IL-0342 DigitalOcean 의 AMS3, LON1, SFO2 데이터 센터가 에지 라우터 고장으로 인터넷 연결을 되풀이해 잃었다

   DigitalOcean2023

   증상

   2023년 8월 9일 09:55 UTC 부터 DigitalOcean 의 AMS3, LON1, SFO2 데이터 센터가 인터넷 연결을 잃었다. 끊김은 세 차례 일어났다. 한 번에 10~15분씩 이어졌고, 끊김 사이의 간격은 한 시간쯤이었다.

   네트워크 도달 불가간헐적 타임아웃지연 시간 증가

   촉발

   에지 라우터가 RPKI 관련 라우팅 갱신을 받으면서, 일부 에지 라우터에서 돌던 운영체제 소프트웨어 버전의 버그가 라우팅 프로세스를 죽였다.

   원인

   소프트웨어 결함

   구성 요소

   BGP 라우팅

   기여 요인

   과도한 영향 범위수동 조치 악화

   조치

   • 장비 업체의 조사 뒤 문제의 운영체제 버전을 쓰는 에지 라우터에 소프트웨어 업데이트를 긴급히 내보냈다. 회선에서 트래픽을 빼고 라우터가 인터넷에 다시 붙는 동안 연결 문제가 더 났다.
   • AMS3 와 FRA1 사이 경로의 혼잡을 줄이려고 트래픽을 다시 나눴다.
   • 장애 전환이 일어나도 같은 문제를 겪지 않도록 이중화된 네트워크 장비에도 수정을 내보냈다. 14:58 UTC 공지에서 AMS3, LON1, SFO2 의 모든 네트워크 장비를 패치했다고 알렸다.

   후속 조치

   • 전 세계 모든 에지 라우터를 버그를 피하는 버전으로 업그레이드했다.
   • 네트워크의 안정성과 보안을 높이는 네트워크 업그레이드를 진행한다. 아시아는 이미 업그레이드를 마쳤고, 유럽과 북미는 올해 말과 2024년 초에 업그레이드한다.

   사례 보기
4. IL-0225 라우터 명령 하나가 Microsoft WAN 의 모든 라우터에 토폴로지를 다시 계산하게 해 전 세계 Azure 네트워크 연결이 불안정해졌다.

   Microsoft Azure2023

   증상

   2023-01-25 07:08 UTC 부터 Azure 리전의 리소스와 Microsoft 365, Power Platform 같은 Microsoft 서비스에 연결할 때 네트워크 지연이 길어지거나 타임아웃이 났다. 모니터링은 07:11 UTC 부터 DNS 와 WAN 문제를 잡았고, 명령을 실행하고 5분 안에 당직 엔지니어에게 알림이 갔다.

   지연 시간 증가간헐적 타임아웃간헐적 연결 실패패킷 손실네트워크 도달 불가

   촉발

   07:08 UTC 에 마드리드에서 전 세계 WAN 에 용량을 더하던 엔지니어가, 다시 검증하지 않은 표준 운영 절차대로 IGP 데이터베이스를 비우는 명령을 실행했다. 이 명령은 한 제조사의 라우터에서는 로컬 라우터에 그치지 않고 IGP 로 이어진 모든 라우터에 IGP 토폴로지 데이터베이스를 다시 계산하라고 지시했다.

   원인

   설정 변경

   구성 요소

   백본망내부 라우팅BGP 라우팅

   기여 요인

   설정 테스트 부재미검증 가정과도한 영향 범위수동 조치 악화

   감지

   모니터링이 07:11 UTC 부터 DNS 와 WAN 문제를 잡았고, 명령을 실행하고 5분 안에 당직 엔지니어에게 알림이 갔다. 변경하던 엔지니어는 바뀐 절차 때문에 이 알림을 전달받지 못했다. 팀은 최근 변경을 모두 살펴 08:20 UTC 에 문제의 명령을 찾았다.

   조치

   • WAN 라우팅이 수렴한 뒤에도 남은 패킷 손실을 없애려고, 사고 중 멈춰 있던 비정상 장비 제거 시스템과 트래픽 엔지니어링 시스템을 손으로 다시 시작했다. 12:43 UTC 에 복구를 마쳤다.

   후속 조치

   • 세 제조사 전부와 모든 WAN 라우터 역할을 대상으로, 넓은 영향을 줄 수 있는 비슷한 명령을 감사하고 막는다. 2023년 2월에 끝낼 예정이다.
   • 승인된 자동화와 승인된 비상 접근인 break glass 작업, 승인되지 않은 장비 작업을 실시간으로 보여 줘, 당직 엔지니어가 누가 네트워크 장비에서 무엇을 바꾸는지 볼 수 있게 한다. 2023년 2월에 끝낼 예정이다.
   • 정기적인 필수 운영 교육과 모든 표준 운영 절차를 지키겠다는 확인 절차를 도입해 절차를 계속 개선한다. 2023년 2월에 끝낼 예정이다.
   • 아직 검증을 기다리는 표준 운영 절차를 모두 감사하고, 엔지니어 의견을 받아 30일 안에 Change Advisory Board 검토를 우선 받게 한다. 2023년 4월에 끝낼 예정이다.

   사례 보기
5. 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