[잡담] 25.12.05 Cloudflare 서비스 중단 원인 알아보기

1. 개요

2025.12.05 17시 40분쯤 갑자기 노션이 안됐다.
또한 몇몇 사이트들이 HTTP 500에러를 내며 접속이 되지 않았다.
원인은 Cloudflare가 뻗으며 해당 도메인에 접근이 불가능한 것이었다.

간략히 표현하면 이런 상황

Cloudflare측에서 왜 이런 문제가 발생했는지 원인을 블로그에 작성해두었고, 이 글을 읽어보며 Cloudflare내에서 어떤 일이 있었던건지 간단하게 살펴보았다.
Cloudflare에서 작성한 전체 내용은 아래 링크에서 확인할 수 있다.
https://blog.cloudflare.com/5-december-2025-outage/

Cloudflare outage on December 5, 2025

 

2. 사건의 진행 과정

시작은 12월 초에 발견된 RSC(React Server Components)취약점이었다.
이번에 발견된 취약점은 CVSS 10.0을 받을정도로 매우 치명적인 취약점이기에 Cloudflare에서도 이와 관련한 취약점 공격을 감지하고 보완하기 위한 작업을 진행했다.
이를 위한 작업중 한 가지는 Next.js의 허용 버퍼 크기를 1MB로 늘리는것이었다. 기존 Cloudflare의 WAF는 HTTP요청을 메모리에 버퍼링한다. 이 버퍼의 크기는 128KB였다. 버퍼 크기를 늘리는 작업 후 단계적 배포 시스템을 통해 롤아웃이 되고있었는데 이중 내부 WAF테스트 도구가 이 버퍼 크기를 지원하지 않는것이 발견되었다. 하지만 이 WAF테스트 도구는 필요하지 않고, 고객 트래픽에 영향을 주는것도 아니었다. 그렇기에 이 도구를 비활성화했고, 이는 단계적 배포가 아닌 글로벌 시스템을 통해 한번에 배포되었다. 그리고...

HTTP 500오류가 발생한 트래픽(빨간선), 영향을 받지 않은 트래픽(녹색선)

이렇게 되고 만 것이다.
해당 변경이 Cloudflare 네트워크에 전파되자마자 FL1프록시에서 실행된 코드가 버그를 일으키며 아래의 Lua오류로 이어졌다.

[lua] Failed to run module rulesets callback late_routing: /usr/local/nginx-fl/lua/modules/init.lua:314: attempt to index field 'execute' (a nil value)

HTTP 500오류가 발생되었고, 이는 약 30~40분 정도 후 변경 사항을 롤백하며 모든 트래픽이 정상적으로 처리되었다.
 

3. 왜 HTTP 500오류가 발생했을까?

Cloudflare의 규칙 집합 시스템(rulesets system - 보통 "규칙 세트"라고 한다.)은 시스템으로 들어오는 요청을 평가한다. 그리고 최상위 규칙 집합은 테스트 규칙 집합을 포함하는 다른 규칙 집합을 실행한다. 이번에 시도한것은 이런 테스트 규칙을 비활성화 하는것이었다. 그리고 오동작하는 규칙을 빠르게 비활성화하기 위해 킬 스위치 시스템을 도입했고, 이는 잘 동작하고 있지만 "execute"동작을 가진 규칙에 킬 스위치를 적용하지는 않았다. 킬 스위치가 적용되었을 때 실행동작 평가를 건너뛰게 로직이 구성되어있었다. 하지만 규칙 집합을 평가한 전체 결과를 처리하던 중 아래의 오류가 발생했다.

if rule_result.action == "execute" then
  rule_result.execute.results = ruleset_results[tonumber(rule_result.execute.results_index)]
end

규칙 집합에 action="execute"가 있는 경우 "rule_result.execute"가 존재할 것으로 가정하고 코드가 실행되었으나 규칙이 건너뛰어졌지 때문에 "rule_result.execute"가 존재하지 않았고, Lua에서 nil값(null 값이다.)을 찾으려고 시도하여 오류가 발생되었던 것이다.
 

4. 이후

2025년 11월 18일에 발생했던 Cloudflare 중단 사고도 이처럼 관련 없는 변경을 수행하다가 전체 네트워크에 문제가 발생한 사건이었다. 이런 문제를 해결하기 위한 변경 내용이 공유되었으나 아직 이 항목은 배포하지 못한 상태이다.
아래와 같은 방법으로 이런 문제를 보완하겠다 한다.

 

5. 내 생각

• 항상 드는 생각이지만 코드간의 의존성의 범위를 컨트롤하는것은 정말 쉬운 일이 아닌것 같다. 이번 사건에서도 WAF관련 로직을 수정하다 FL1프록시에서 오류가 발생되었다.
• 전역 배포를 했다는것은 왜 그런건지 잘 이해되지 않는다. Cloudflare같은 규모면 내부 시스템 규모도 상당히 클텐데 왜 전역 배포를 결정한 것일까? RSC취약점으로 인해 급한 상황이어서 이번만 그런것이라면 이해할 수 있겠지만 사내 문화 때문이라면 향후 더 큰 문제로 이어질 수 있지 않을까?
• 본문에 나온 로그들은 배포 단계에서 즉시 찍힌 것으로 추정된다. 그런데 왜 롤백에 30~40분이 소요된 것일까? 배포팀은 로그를 계속 확인하며 이슈가 발견되었다면 즉시 롤백을 눌렀어야 했을 텐데 왜 이렇게 시간이 소요된건지 잘 모르겠다.
• Cloudflare에서 제공하는 서비스를 사용해야 하는 이유는 여전히 납득된다. 하지만 이런 중앙집중형인 시스템은 한번의 실수로 수많은 전세계의 서비스가 멈출 수 있다. 특히 현대는 수많은 서비스가 Cloudflare, AWS와 같은 대기업 서비스에 의존하고 있다. 그리고 이곳에서 장애가 발생한다면 서비스가 멈춘다. 그렇다면 현대의 서비스는 과거에 비해 안정성이 떨어진다고 할 수 있지 않을까?
• Cloudflare같은 대형 기업은 서비스에 장애가 발생하면 엔지니어가 즉시 대응을 한다. 하지만 내 서버, 내 서비스가 멈추면 어떻게 해야할까?
• 프론트엔드 개발을 할 땐 서버를 포함해 각종 시스템에서 오류는 언제든 발생할 수 있다고 가정해야 한다 생각한다. 그렇기에 커스텀 에러 페이지나, 간단한 alert메세지라도 보여주는 예외처리는 필수이다. 하지만 이날 500에러가 나타난 페이지 어디서도 예외처리는 볼 수 없었다. 물론 규칙세트 자체에서 오류가 발생한거라 처리는 어렵겠지만 최소한 에러를 보여주기 위한 별도의 정적 도메인 페이지를 만들어두는 방식으론 처리가 어려웠던걸까?
• FL2 프록시는 Rust로 작성되었고, 이번에 오류가 발생하지 않았다고 한다. Rust의 강력한 타입 시스템 덕분인것 같다. 개인적으로도 과거에는 Python, Javascript같은 동적 타입 언어를 선호하다가 현재는 타입 시스템을 강하게 갖고 있는 언어를 선호한다. 시스템이 운영되는 과정에서 타입 안정성이라는것이 얼마나 중요한지 체감을 많이했기 때문인것 같다.
• 큰 기업들에서 발생하는 장애, 보안 이슈 등은 빠른 성장만을 강요받는 환경에서 쌓여온 기술 부채가 터지는것이 아닐까 하는 생각이 들었다. 잦은 장애는 이런 기술부채가 서서히 수면으로 보이기 시작하는것 같다. 단순히 짧은 장애로 끝나면 그나마 괜찮을 수 있지만 금융 관련 문제나 정보 유출같은 문제가 터지면 해프닝으로 끝나기는 어렵지 않을까?