사례5건
5건 중 1~5번째
IL-0283Cloudflare 네트워크 전체에서 코어 프록시가 Bot Management 피처 파일을 읽다 실패해 사이트 방문자들이 HTTP 5xx 오류 페이지를 받았다Cloudflare2025- 증상
11:20 UTC 부터 Cloudflare 네트워크가 내보내는 HTTP 5xx 오류가 치솟았다. 고객 사이트를 찾은 인터넷 사용자들은 Cloudflare 네트워크 안에서 실패했다는 오류 페이지를 봤다.
- 촉발
11:05 UTC 에 Cloudflare 는 ClickHouse 사용자들이 암묵적으로 갖고 있던 r0 데이터베이스 하위 테이블 접근 권한을 명시적으로 주는 변경을 배포했다. Bot Management 피처 파일을 만드는 쿼리는 데이터베이스 이름으로 거르지 않았고, 이 변경 뒤 쿼리 결과에 중복 행이 섞이기 시작했다.
- 원인
- 구성 요소
- 기여 요인
- 감지
11:31 UTC 에 첫 자동 테스트가 문제를 감지했고, 11:32 에 수동 조사가 시작됐으며, 11:35 에 장애 대응 통화가 열렸다.
- 조치
- 13:05 UTC 에 Workers KV 와 Cloudflare Access 를 내부 우회 경로로 돌려 이전 버전의 코어 프록시를 쓰게 했다. 이전 버전에도 같은 문제가 있었지만 영향이 작았다.
- 14:24 UTC 에 새 Bot Management 설정 파일의 자동 배포를 멈췄다.
- 알려진 정상 피처 파일을 피처 파일 배포 큐에 손으로 넣었다.
- 코어 프록시를 강제로 재시작했다. 14:30 UTC 에 주된 영향이 풀렸다.
- 쌓인 로그인 시도와 재시도로 느려진 대시보드를 컨트롤 플레인 동시성을 늘려 15:30 UTC 무렵 되살렸다.
- 나쁜 상태에 빠진 나머지 서비스들을 재시작했고, 17:06 UTC 에 5xx 오류량이 평소로 돌아왔다.
- 후속 조치
- Cloudflare 가 직접 만든 설정 파일도 사용자 입력처럼 엄격하게 검증한 뒤 받아들인다.
- 기능을 네트워크 전체에서 끌 수 있는 킬 스위치를 더 늘린다.
- 코어 덤프나 다른 오류 보고가 시스템 자원을 다 써 버리지 못하게 한다.
- 모든 코어 프록시 모듈이 오류가 났을 때 어떻게 실패하는지 검토한다.
IL-0284Workers 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 의 실패가 연쇄로 번져 피해 범위를 크게 넓혔다.
- 증상
21:45 UTC 에 R2 전역 가용성 알림이 울렸다. 알림은 오류 예산 소진율 2% 를 가리켰고, R2 의 읽기와 쓰기 가용성 지표가 조금씩 계속 내려가고 있었다.
- 촉발
R2 엔지니어링 팀이 R2 Gateway 서비스의 스토리지 인프라 자격 증명을 교체하면서 wrangler secret put 과 wrangler deploy 에 --env 인자를 빠뜨렸다. 새 자격 증명은 운영 Worker 가 아니라 기본 환경 Worker 에 들어갔고, 그 뒤 스토리지 인프라에서 옛 자격 증명을 지웠다.
- 원인
- 구성 요소
- 기여 요인
- 감지
21:45 UTC 에 R2 전역 가용성 알림이 울렸다. 알림은 오류 예산 소진율 2% 를 가리켰고, R2 엔지니어링 팀은 운영 대시보드와 로그를 보기 시작했다.
- 조치
- 22:45 UTC 에 올바른 운영 R2 Gateway Worker 에 자격 증명을 배포했고, R2 가용성이 돌아왔다.
- 후속 조치
- R2 Gateway Worker 가 스토리지 인프라 인증에 쓰는 자격 증명 ID 의 끝자리를 로그 태그에 넣어, 어떤 자격 증명을 쓰는지 바로 확인할 수 있게 했다.
- 옛 토큰을 지우기 전에 새 토큰 ID 의 끝자리가 스토리지 인프라 로그와 맞는지 반드시 확인하도록 내부 절차를 바꿨다.
- 키 교체를 wrangler 명령을 손으로 치는 대신 핫픽스 배포 도구로만 하도록 했다. 이 도구는 환경 설정을 강제하고 다른 안전 검사도 한다.
- 변경을 적어도 두 사람이 확인한다는 관행을 관련 표준 운영 절차에 명시했다.
- 엔드포인트를 감시하는 기존 폐루프 상태 검사 시스템을 넓힌다. 이 시스템이 새 키를 시험하고, 그 상태를 알림 플랫폼으로 자동 보고하고, 게이트웨이 Worker 를 배포하기 전에 새 키가 전역으로 퍼졌는지 확인하게 한다.
- 분산 스토리지 엔드포인트의 문제를 빨리 가려내도록, 관측 플랫폼에 캐시를 거치지 않은 업스트림 성공률 화면을 더한다.
- 교훈
이번 장애는 사람의 실수로 일어났고, R2 Gateway Worker 가 어떤 자격 증명으로 스토리지 인프라에 인증하는지 볼 수 없어서 더 길어졌다. Cloudflare 는 옛 자격 증명을 지운 뒤 가용성 지표에 기대지 말고, R2 Gateway 서비스가 실제로 어떤 토큰을 쓰는지 직접 확인했어야 했다고 적었다.
- 증상
2023년 10월 4일 07:00 UTC 부터 1.1.1.1 을 직접 쓰거나 WARP, Zero Trust, 또는 1.1.1.1 을 쓰는 다른 회사의 DNS 리졸버를 거치는 일부 사용자가 유효한 질의에 SERVFAIL DNS 응답을 받았다. 07:57 에 예상하지 못한 SERVFAIL 을 알리는 외부 신고가 처음 들어왔다.
- 촉발
9월 21일 루트 존에 ZONEMD 라는 새 리소스 레코드 형식이 처음 들어왔고, 1.1.1.1 리졸버가 이 레코드를 파싱하지 못해 새 루트 존을 쓰지 못했다. 10월 4일 07:00 UTC 에 계속 쓰던 9월 21일 판 루트 존의 DNSSEC 서명이 만료됐다.
- 원인
- 구성 요소
- 기여 요인
- 감지
07:57 UTC 에 예상하지 못한 SERVFAIL 을 알리는 외부 신고가 처음 들어왔고, 08:03 에 Cloudflare 내부 장애가 선언됐다. static_zone 이 오래된 루트 존을 내주는 상황을 알리는 알림은 없었다.
- 조치
- 08:50 UTC 에 override 규칙으로 1.1.1.1 이 오래된 루트 존 파일로 응답하지 않게 하려 했다. 다른 노드로 넘긴 질의에는 rec_disable_static 태그가 실리지 않아 static_zone 앱이 계속 오래된 정보로 답했다.
- 10:30 UTC 에 1.1.1.1 이 루트 존 파일을 아예 미리 읽지 않게 했다. 10:32 에 응답이 정상으로 돌아왔다.
- 후속 조치
- static_zone 이 오래된 루트 존 파일을 내줄 때 알리는 알림을 더한다.
- 루트 존을 받아 와 내부에 배포하는 방식을 다시 검토해, 새 RRTYPE 을 문제없이 다루고 파이프라인이 잠깐 끊겨도 최종 사용자에게 보이지 않게 한다.
- 루트 존 파싱이 실패할 때 어떻게 되는지 충분히 테스트하지 않았으므로 테스트 범위와 관련 절차를 개선한다.
- RFC 8806 이 설명하는 대로 캐시한 루트 존 데이터의 수명을 관리해, 일정 시점이 지난 오래된 루트 존 사본을 쓰지 않게 한다.
- 교훈
Cloudflare 는 무엇이든 바뀌지 않으리라고 가정하지 말라는 것을 이 사고의 분명한 교훈으로 꼽았다. 최종 실행 파일에 들어가는 긴 라이브러리 사슬 어디에든 버그가 있거나, 입력이 바뀔 때 제대로 동작할 만큼 일찍 갱신되지 않은 것이 있을 수 있다고 했다. 회귀를 잡아내는 테스트와 입력이 바뀌어도 부드럽게 실패하는 시스템이 중요하다고 했다. DNS 와 BGP 처럼 인터넷에서 가장 중요한 시스템의 형식 변경은 영향을 줄 것이라고 늘 가정해야 한다고 했다. 오래된 루트 존을 내주는 것을 더 잘 감시했다면, 이미 있는 캐시 덕분에 영향이 없었을 것이라고 했다.
- 증상
14:43 UTC 에 네트워크 스위치 하나가 ping 에 응답하지 않는다는 알림이 울리기 시작했다. 장애 동안 API 쿼리 성공률이 한때 75%까지 떨어졌고, 대시보드는 평소보다 최대 80배 느려졌다.
- 촉발
14:43 UTC 에 제어 플레인 데이터 센터의 네트워크 스위치 하나가 일부만 동작하는 상태에 빠졌다. LACP 와 BGP 는 계속 돌았지만 받은 패킷 일부를 전달하지 못했고, 스위치는 6분 뒤 스스로 회복했다.
- 원인
- 구성 요소
- 기여 요인
- 감지
14:43 UTC 에 스위치가 ping 에 응답하지 않는다는 알림이 울리기 시작했다. 그 뒤 엔지니어들이 주 인증 데이터베이스가 과부하에 걸린 것을 확인했다.
- 조치
- SSL 인증서를 엣지로 보내는 속도와 메일 발송 같은 기능을 줄여 주 인증 데이터베이스가 늘어난 부하를 감당할 여유를 만들었다.
- 읽기 복제본으로 처리할 수 있는 API 트래픽을 손으로 보조 데이터 센터로 돌렸다. API 가용성이 크게 나아졌다.
- 대시보드 사용자의 불편이 커지자 인증 호출을 모두 주 데이터 센터로 되돌렸고, 성능이 떨어진 상태에서도 최대한 버티도록 주 데이터베이스를 계속 손봤다.
- 21:20 UTC 에 첫 데이터베이스 복제본이 다시 만들어지자마자 자동으로 서비스에 투입됐고, 성능이 정상으로 돌아왔다.
- 줄였던 서비스를 모두 다시 올려 밀린 비동기 처리가 따라잡게 했고, 한동안 지켜본 뒤 장애 종료를 선언했다.
- 후속 조치
- 새 primary 를 승격하면 데이터베이스 복제본을 모두 다시 만들어야 하는 클러스터 관리 시스템의 제약을 고친다. Cloudflare 는 글을 쓸 무렵 이 결함을 이미 고쳤다고 밝혔다.
- 트래픽을 다른 데이터 센터로 돌려야 할 때 유연하게 대응하지 못하는 사용자 세션 시스템을 다시 설계한다.
- 자동 복구 조치의 설정 값을 다시 검토한다. 적어도 데이터베이스 하나에서는 복제본을 primary 로 승격하는 절차를 그렇게 빨리 시작하지 않도록 장애 직후 설정을 바꿨다.
- 이 장애에 얽힌 시스템마다 자기가 의존하는 시스템의 고장을 더 잘 견디도록 계속 조정한다.
- 교훈
모든 시스템에 이중화가 있었지만, 고장 난 시스템들은 완전히 멈추지 않고 성능이 떨어진 채로 동작했다. 그래서 뒤이어 일어난 일들을 미리 모델링하고 예상하기가 훨씬 어려웠다. 1분 만에 복제본을 승격하는 자동 조치는 Cloudflare 가 자랑하던 기능이었지만, 적어도 데이터베이스 하나에서는 그 조치가 원래 문제보다 더 큰 피해를 낼 수 있었다. 대부분의 범용 클러스터 관리 시스템은 비잔틴 장애를 견디는 프로토콜을 쓰지 않고 RAFT 처럼 단순한 프로토콜을 쓴다. 드문 장애 유형에 약하다고 알려진 단순한 프로토콜이 구현과 디버깅이 어려운 복잡한 프로토콜보다 안전한 경우가 많다고 Cloudflare 는 보았다.
이 5건에서 가장 많이 나오는 구성 요소: 데이터베이스, CDN 과 엣지 네트워크. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.