사례2건

2건 중 1~2번째

1. IL-0284 Workers KV 의 저장소 인프라가 멈춰 KV 에 기대는 Access, WARP, Gateway, 대시보드 같은 Cloudflare 서비스 여럿이 2시간 28분 동안 전 세계에서 실패했다

   Cloudflare2025

   증상

   17:52 UTC 에 WARP 팀이 새 기기 등록이 실패하는 것을 보고 장애를 선언했다. 18:05 에 Cloudflare Access 팀이 오류율 급증 알림을 받았고, 여러 서비스의 SLO 가 목표 아래로 떨어져 팀마다 알림이 울렸다.

   오류율 상승서비스 중단자격 증명 획득 실패

   촉발

   Workers KV 의 중앙 저장소 일부를 받치던 서드파티 클라우드 공급자에 장애가 났고, KV 가 원본 저장소에서 값을 읽고 쓰지 못하게 됐다.

   원인

   클라우드 제공자 장애

   구성 요소

   데이터베이스

   기여 요인

   단일 장애점과도한 영향 범위순환 의존재시도 폭주

   감지

   17:52 UTC 에 Cloudflare WARP 팀이 새 기기 등록이 실패하는 것을 보고 조사를 시작해 장애를 선언했다. 18:05 에 Access 팀이 오류율 급증 알림을 받았고, 여러 서비스의 SLO 가 목표 아래로 떨어져 팀마다 알림이 울렸다. 18:06 에 Workers KV 를 쓸 수 없게 된 것이 공통 원인임을 찾아 서비스별 장애를 하나로 합쳤다.

   조치

   • Challenges 와 Turnstile 의 siteverify 호출을 끄는 킬 스위치를 켜 방문자가 막히지 않게 했다. 킬 스위치를 켜 둔 동안에는 siteverify API 가 유효한 토큰 하나를 여러 번 받아들일 수 있었다. 봇 탐지는 영향을 받지 않았다.
   • 19:09 UTC 에 Zero Trust Gateway 가 신원이나 Device Posture 상태를 참조하는 규칙을 단계적으로 약하게 만들어 Workers KV 의존을 덜었다.
   • 19:32 UTC 에 Access 와 Device Posture 가 서드파티 서비스가 돌아올 때까지 신원과 Device Posture 요청을 강제로 버려 Workers KV 의 부하를 줄였다.
   • 저장소가 계속 멈출 때를 대비해, 다른 저장소를 쓰는 Workers KV 릴리스를 배포하고 핵심 서비스가 설정 데이터를 그 저장소에 쓰게 할 방법을 계속 준비했다.
   • 20:25 UTC 에 서드파티 서비스가 회복되자 Access 와 Device Posture 가 Workers KV 호출을 되살렸다.

   후속 조치

   • Cloudflare 가 소유하지 않은 저장소 인프라 하나에만 기대는 구조를 없앤다.
   • Access, Gateway, WARP 같은 핵심 서비스를 복구하는 능력을 높인다.
   • Workers KV 저장소 인프라의 이중화를 강화해 어느 한 공급자에도 기대지 않게 하는 작업을 앞당긴다. 장애 중에 이미 핵심 KV 네임스페이스를 자체 인프라로 옮기고 백필하는 일을 시작했다.
   • 이번 장애로 영향을 받은 제품마다 피해 범위를 줄이는 단기 조치를 적용해, 서드파티 의존을 포함한 어떤 단일 장애 지점이 멈춰도 제품이 버티게 한다.
   • 저장소 인프라 장애 때 네임스페이스를 차례로 다시 켜는 도구를 만들어, 캐시를 다시 채우는 동안 Access 와 WARP 같은 핵심 의존 서비스가 자체 인프라에 서비스 거부를 일으키지 않고 올라오게 한다.

   교훈

   서드파티 공급자의 장애가 직접 원인이었지만 Cloudflare 는 어떤 의존을 고르고 그 의존을 감안해 시스템을 어떻게 설계하는지가 자기 책임이라고 밝혔다. 많은 서비스가 각자 저장소를 만들지 않고 Workers KV 에 기대는 것은 평소에는 서비스를 튼튼하게 하지만, 이번에는 KV 의 실패가 연쇄로 번져 피해 범위를 크게 넓혔다.

   사례 보기
2. IL-0220 연휴 뒤 첫 업무일에 AWS Transit Gateway 가 패킷을 버려 Slack 웹 계층이 포화되고 Slack 을 한동안 쓸 수 없었다.

   Slack2021

   증상

   미주 지역 오전에 외부 모니터링 서비스가 오류율이 조금씩 오르고 있다며 호출했다. 조사를 막 시작했을 때 사내 대시보드와 알림 서비스까지 먹통이 됐다.

   오류율 상승모니터링 중단패킷 손실서비스 중단노드 증설 실패파일 디스크립터 고갈클라우드 API 호출 한도 소진

   촉발

   연휴 동안 트래픽이 낮다가 연휴 뒤 첫 월요일에 클라이언트 캐시가 비어 평소보다 많은 데이터를 내려받으면서 트래픽이 하룻밤 새 크게 늘었다. Slack 의 VPC 들을 잇는 AWS Transit Gateway 하나가 이 증가를 따라 충분히 빨리 늘지 못해 과부하가 걸리고 패킷을 버렸다.

   원인

   클라우드 제공자 장애

   구성 요소

   트랜짓 게이트웨이와 네트워크 연결 장비자동 용량 관리 시스템

   기여 요인

   순환 의존자동화 증폭

   감지

   미주 지역 오전에 외부 모니터링 서비스가 오류율이 오르고 있다며 호출했다. 조사 초기에 대시보드와 알림 서비스가 멈춰, 그 뒤로는 내부 콘솔, 상태 페이지, 명령줄 도구, 로그와 지표 백엔드 직접 조회로 상황을 봤다. TGW 의 패킷 드롭은 AWS 내부 모니터링이 AWS 엔지니어에게 알렸다.

   조치

   • 조사를 돕고 서빙 용량을 지키려고 웹 계층의 자동 축소를 껐다.
   • 일부 대응자가 프로비저닝을 끝내지 못한 채 오토스케일링 그룹 크기 한도를 채우던 고장 난 인스턴스를 정리했다.
   • provision-service 를 고쳐 PST 오전 8시 15분쯤 다시 돌게 했고, 그때부터 정상 인스턴스가 서비스에 들어오기 시작했다.
   • AWS 엔지니어가 내부 모니터링으로 패킷 드롭을 알아채고 Slack 의 TGW 용량을 손으로 늘렸다. PST 오전 10시 40분에 모든 가용 영역에 반영되자 네트워크가 정상으로 돌아왔다.

   후속 조치

   • AWS 가 사고 후속 절차로 초당 패킷 수가 크게 늘 때의 TGW 스케일링 알고리즘을 검토한다.
   • 다음 연휴 시즌이 끝날 무렵 TGW 를 미리 증설해 달라고 요청하도록 Slack 리마인더를 걸어 둔다.
   • 대시보드 서비스 인스턴스를 데이터베이스와 같은 VPC 에서 돌려 TGW 의존을 없앤다.
   • provision-service 를 정기적으로 부하 테스트해 남은 확장 문제가 없는지 확인한다.
   • 큰 네트워크 장애 같은 극단적인 상황에서도 provision-service 가 다시 과부하되지 않도록 헬스 체크와 오토스케일링 설정을 다시 검토한다.

   교훈

   모니터링은 사용자 서비스가 정상인지 아는 수단이자 진단의 핵심 도구다. 그래서 Slack 은 모니터링 도구를 Slack 인프라에서 최대한 떼어 두려 했다. 그런데 대시보드와 알림 서비스가 백엔드 데이터베이스와 다른 VPC 에 있어 TGW 에 의존했고, 가장 필요한 순간에 함께 멈췄다. provision-service 는 예전에 부하 테스트를 했지만 이번 증설은 그때의 규모를 넘었다.

   사례 보기

원인별1