사례2건

2건 중 1~2번째

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

   사례 보기
2. IL-0555 한 수집 리전에 밀린 트래픽이 다른 엣지 리전으로 번져 Sentry US 의 이벤트 수집이 트래픽을 거부했다

   Sentry2024

   증상

   2024년 10월 4일, 16일, 21일에 Sentry 의 이벤트 수집에서 오류가 늘었다. 수집 리전 하나에 밀린 트래픽이 쌓였고, 그 리전에서 빠져나간 트래픽을 받은 다른 리전에도 트래픽이 밀려 쌓이면서 트래픽이 거부됐다.

   오류율 상승서비스 중단오토스케일러 오동작

   촉발

   세 사고는 계기가 각각 달랐지만, 세 번 모두 수집 리전 하나에서 밀린 트래픽이 늘어나면서 시작했다.

   원인

   용량 한계

   구성 요소

   CDN 과 엣지 네트워크자동 용량 관리 시스템

   기여 요인

   자동화 증폭과도한 영향 범위

   후속 조치

   • 연쇄 장애의 가능성을 줄이려고 엣지 리전을 더 작게 더 많이 만들었다. 남아메리카에 첫 리전을 열고, 북아메리카와 유럽에는 하나씩이던 리전을 둘로 늘려 모두 세 리전을 더했다.
   • 오토스케일링 규칙이 원래의 CPU 부하 지표보다 더 강한 신호를 잡도록 바꿨다.
   • iowait 때문에 요청이 밀릴 때 축소가 일어나지 않도록 축소 속도를 낮췄다.
   • 오토스케일링 규칙과 민감도를 더 다듬을 수 있도록 엣지가 내는 지표를 개선한다.

   사례 보기

원인별1