클라우드플레어 대규모 글로벌 장애

클라우드플레어는 전 세계 수많은 웹사이트의 CDN(콘텐츠 전송)과 디도스 방어 등 보안 기능을 대행하는 인프라 기업으로, 이 회사 네트워크에 장애가 나면 이를 사용하는 서비스들이 동시에 마비되는 구조임. 2025년 11월 18일 발생한 대규모 장애는 X(옛 트위터)·ChatGPT·캔바·리그 오브 레전드 등 성격이 다른 글로벌 서비스들을 한꺼번에 멈춰 세우며 이 구조적 위험을 드러냄.^[2][3]

공식 보고서가 밝힌 방아쇠는 권한 변경이다 — 「it was triggered by a change to one of our database systems' permissions which caused the database to output multiple entries into a “feature file” used by our Bot Management system. That feature file, in turn, doubled in size.」 공격이 아니었다는 것도 첫머리에 못 박았다 — 「The issue was not caused, directly or indirectly, by a cyber attack or malicious activity of any kind.」^[7]

그런데 여유는 충분해 보였다. 봇 관리 시스템의 기능 수 한도에 대해 — 「Currently that limit is set to 200, well above our current use of ~60 features.」 한도를 둔 이유는 성능이다 — 「the limit exists because for performance reasons we preallocate memory for the features.」^[7]

행이 2배 넘게 늘면서 그 200을 넘겼고, 러스트 코드가 그대로 패닉했다 — 「thread fl2_worker_thread panicked: called Result::unwrap() on an Err value」 `unwrap()` 이 에러 값 위에서 호출된 것이다.^[7]

원인 쿼리의 결함은 한 줄로 설명된다 — 「Note how the query does not filter for the database name.」 권한이 명시적으로 부여되자 「the response now contained all the metadata of the r0 schema effectively more than doubling the rows in the response ultimately affecting the number of rows (i.e. features) in the final file output.」^[7]

이 장애의 가장 특이한 점은 증상이 오락가락했다는 것이다. 「the file was being generated every five minutes by a query running on a ClickHouse database cluster, which was being gradually updated to improve permissions management. Bad data was only generated if the query ran on a part of the cluster which had been updated.」 그래서 「every five minutes there was a chance of either a good or a bad set of configuration files being generated and rapidly propagated across the network.」^[7]

「This fluctuation made it unclear what was happening as the entire system would recover and then fail again as sometimes good, sometimes bad configuration files were distributed to our network. Initially, this led us to believe this might be caused by an attack.」 내부 오류가 회복과 실패를 반복하는 것은 이례적이라, 공격 쪽으로 판단이 기울었다.^[7]

그리고 우연이 하나 겹쳤다. 「Cloudflare's status page went down. The status page is hosted completely off Cloudflare's infrastructure with no dependencies on Cloudflare. While it turned out to be a coincidence, it led some of the team diagnosing the issue to believe that an attacker may be targeting both our systems as well as our status page.」 클라우드플레어 밖에 호스팅된 상태 페이지가 같은 시각에 죽은 것은 이 장애와 무관했는데, 「공격자가 양쪽을 동시에 노린다」는 그림을 만들어 오진을 굳혔다.^[7]

마침 프록시 교체가 진행 중이었고, 두 버전에서 결과가 갈렸다. 「Customers deployed on the new FL2 proxy engine, observed HTTP 5xx errors.」 반면 「Customers on our old proxy engine, known as FL, did not see errors, but bot scores were not generated correctly, resulting in all traffic receiving a bot score of zero.」^[7]

그래서 구버전 쪽에서는 「사이트가 죽는」 대신 「봇이 아닌 트래픽이 차단되는」 일이 일어났다 — 「Customers that had rules deployed to block bots would have seen large numbers of false positives. Customers who were not using our bot score in their rules did not see any impact.」 봇 점수를 룰에 쓰지 않던 고객은 아무 영향도 못 느꼈다.^[7]

응답이 느려진 것에도 별도 원인이 있었다 — 「This was due to large amounts of CPU being consumed by our debugging and observability systems, which automatically enhance uncaught errors with additional debugging information.」 오류를 자세히 남기려는 장치가 오류가 쏟아지자 자원을 먹은 것이다.^[7]

장애 시간 동안 이용자들은 '500 Internal Server Error' 등 오류 화면을 마주했고, CDN 기능 정지로 웹페이지가 열리지 않거나 급격히 느려졌음. 서비스는 다음 날인 11월 19일 정상화가 일단락됐으나, 보름 뒤인 12월 5일에도 약 24분간 장애가 재발함.^[1][2][6]

이 사건은 소수 인프라 기업에 기댄 인터넷의 '도미노 마비' 취약성을 보여준 사례로 평가되며, 단일 사업자 의존도를 낮추는 이중화 논의로 이어짐.^[4][6]

「we made a change at 11:05 to make this access explicit」 → 「On 18 November 2025 at 11:20 UTC (all times in this blog are UTC), Cloudflare's network began experiencing significant failures to deliver core network traffic.」 → 「The team was able to reduce the impact to these systems at 13:04, when a patch was made to Workers KV to bypass the core proxy.」 → 「Core traffic was largely flowing as normal by 14:30.」 → 「As of 17:06 all systems at Cloudflare were functioning as normal.」^[7]

해결 방법 자체는 단순했다 — 「We solved the problem by stopping the generation and propagation of the bad feature file and manually inserting a known good file into the feature file distribution queue. And then forcing a restart of our core proxy.」^[7]

규모에 대한 자체 평가 — 「Today was Cloudflare's worst outage since 2019.」 「in the last 6+ years we've not had another outage that has caused the majority of core traffic to stop flowing through our network.」^[7]

후속 조치 중 첫 줄이 이 사건의 교훈을 그대로 담고 있다 — 「Hardening ingestion of Cloudflare-generated configuration files in the same way we would for user-generated input」 자기가 만든 설정 파일도 남이 준 입력처럼 검사하겠다는 것이다. 이어 「Enabling more global kill switches for features」 등이 이어진다.^[7]