사례3건
3건 중 1~3번째
- 증상
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 로 가는 전체 트래픽을 두 배로 늘렸다.
- 원인
- 구성 요소
- 기여 요인
- 감지
장애가 시작되고 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 는 이 사고로 한 고객의 사용 방식이 나머지 생태계를 해치지 못하게 막는 안전장치가 더 필요하다는 것이 드러났다고 했다. 어느 한 고객이 공유 자원을 독차지해 다른 고객의 안정성을 해치지 못하도록 고객 격리를 더 잘 설계해야 하고, 수요를 감당할 만큼 네트워크 인프라 용량을 늘려야 한다는 것을 핵심 교훈으로 꼽았다. 결론에서는 드물게 트래픽이 몰린 상황에서 네트워크 혼잡 관리가 모자라 장애가 났다고 했다.
- 증상
2021-12-07 PST 오전 7시 33분부터 us-east-1 에서 새 인스턴스를 띄우거나 기존 인스턴스를 조회하는 EC2 API 의 오류율과 지연이 늘었다. AWS 운영팀은 혼잡이 시작되자 곧바로 실시간 모니터링 데이터를 볼 수 없었다.
- 촉발
PST 오전 7시 30분에 주 AWS 네트워크에서 도는 한 AWS 서비스의 용량을 늘리는 자동 작업이, 내부 네트워크 안의 많은 클라이언트에서 예상하지 못한 동작을 일으켰다. 연결 시도가 한꺼번에 몰려 내부 네트워크와 주 네트워크 사이의 네트워크 장비가 감당하지 못했다.
- 원인
- 구성 요소
- 기여 요인
- 감지
혼잡이 시작되자 운영팀의 실시간 모니터링 데이터가 곧바로 끊겼다. 운영자는 로그를 보고 상황을 파악했고, 처음에는 내부 DNS 오류가 늘어난 것을 찾았다.
- 조치
- 내부 DNS 트래픽을 혼잡한 네트워크 경로에서 옮겼다. PST 오전 9시 28분에 이 작업을 마치자 DNS 해석 오류가 완전히 회복됐지만 혼잡은 남았다.
- 내부 네트워크의 트래픽을 가장 많이 내는 출처를 찾아 전용 네트워크 장비로 분리했다.
- 네트워크 트래픽이 많은 서비스 일부를 껐다. PST 오후 12시 35분에는 EventBridge 이벤트 전달도 껐다.
- 네트워크 용량을 늘렸다. 혼잡은 오후 1시 34분에 크게 나아졌고 오후 2시 22분에 모든 네트워크 장비가 회복됐다.
- 이번 일을 촉발한 확장 작업을 즉시 껐다.
- 후속 조치
- 모든 개선 조치를 배포할 때까지 이번 일을 촉발한 확장 작업을 다시 켜지 않는다.
- 네트워크 클라이언트가 혼잡에서 제대로 back-off 하지 못하게 한 잠재 문제를 고치는 수정을 만들어 2주 안에 배포한다.
- 비슷한 혼잡이 다시 생겨도 영향받을 수 있는 네트워크 장비를 보호하도록 네트워크 설정을 추가한다. 이 설정은 이미 배포했다.
- 내부 네트워크를 쓸 수 없을 때도 API Gateway 서버가 정상으로 남게 하는 완화책을 만들고, 비슷한 일이 생겼을 때 더 빨리 복구하도록 서버 교체 과정을 개선한다.
- 서비스 영향을 더 쉽게 알아볼 수 있는 새 Service Health Dashboard 를 내년 초에 내놓는다.
- 고객과의 소통이 늦어지지 않도록 여러 AWS 리전에서 동시에 도는 새 구조의 지원 시스템을 내놓는다.
- 증상
2013-04-13 태평양 시간 8:11 에 PagerDuty 당직 엔지니어가 알림 발송 시스템의 노드 하나에 문제가 있다는 호출을 받았다. 8:13 에 그 노드를 되살리려 했지만 실패했다.
- 촉발
PagerDuty 가 쓰는 AWS 리전 두 곳이 함께 쓰던 북부 캘리포니아의 피어링 지점이 나빠졌다. AWS 에 따르면 연결 문제는 태평양 시간 7:57 에 시작됐다.
- 원인
- 구성 요소
- 기여 요인
- 감지
8:11 에 당직 엔지니어가 알림 발송 시스템 노드 하나의 문제로 호출을 받았다. 8:18 에 모니터링 시스템이 연결 문제 때문에 알림 제공자 여러 곳에서 실패가 나는 것을 감지했다.
- 조치
- 장애 동안 실패한 coordinator 프로세스 대부분을 손으로 재시작했다.
- 8:53 에 알림 발송 시스템이 쿼럼을 이뤄 쌓여 있던 알림을 모두 처리하기 시작했다.
- 후속 조치
- 일부 시스템의 문제를 디버깅할 로그가 부족했으므로, 로그를 더 남기고 검색하기 쉽게 한곳으로 모으기 시작했다.
- 실패한 coordinator 같은 프로세스를 자동으로 재시작하는 프로세스 감시자를 둔다.
- 호스트 사이 연결 상태를 보여 주는 대시보드를 만든다.
- 모든 엔지니어가 Cassandra 와 ZooKeeper 를 잘 알지는 못하므로, 두 기술을 교육하는 데 시간을 들인다.
- AWS 리전 하나에서 옮겨 가는 방안을 조사한다. 새 호스팅 사업자와 데이터센터를 고를 때 단일 장애 지점이 생기지 않도록 미리 따져 본다.
- 교훈
서로 의존하지 않고 물리적으로 떨어지게 고른 데이터센터 셋 가운데 둘이 같은 피어링 지점을 쓰고 있었고, 그 지점 하나가 나빠지자 두 데이터센터가 함께 오프라인이 됐다. 데이터센터 하나를 잃는 것은 견디게 설계했지만 둘을 함께 잃는 경우는 설계에 없었다. 일부 시스템에는 디버깅할 로그가 부족했고, 호스트 사이 연결을 볼 수단도 부족했다. 모든 엔지니어가 Cassandra 와 ZooKeeper 에 밝지도 않았다.
이 3건에서 가장 많이 나오는 구성 요소: 트랜짓 게이트웨이와 네트워크 연결 장비, BGP 라우팅. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.