클라우드플레어가 멈추자 인터넷도 멈췄다, 장애 원인과 배울 점

💡

이 게시글은 개인적인 궁금증에서 출발해 정리한 글입니다

내용에 오류가 있을 수 있으며, 틀린 부분이 있다면 댓글로 알려주시면 감사하겠습니다 🙏

 

 

📰 클라우드플레어 장애 개요

📌 언제, 얼마나 장애가 났는가

• 발생 일시 (UTC 기준)
  • 시작 : 2025년 11월 18일 11:20 UTC
  • 핵심 트래픽 정상화 : 14:30 UTC
  • 모든 서비스 완전 복구 : 17:06 UTC
• 한국 시간(KST, UTC+9)으로 보면
  • 장애 시작 : 11월 18일 밤 8시 20분
  • 대부분 복구 : 11월 19일 새벽 0시 30분경
  • 완전 복구 : 11월 19일 새벽 2시 6분경

 

📌 어떤 웹사이트들이 영향을 받았는가

Cloudflare를 사용하는 수많은 서비스가 동시다발적으로 문제를 겪었다.

• 접속 문제·오류가 보고된 주요 서비스들
  • X(옛 트위터), ChatGPT, Canva, Grindr
  • Shopify, Dropbox, Coinbase, League of Legends
  • Uber, Facebook, 기타 수많은 대형 서비스들

 

❓ 클라우드플레어는 뭐하는 곳인가?

📌 Cloudflare가 하는 일

Cloudflare는 “웹사이트 앞단에 서서 속도도 올려주고, 공격도 막아주는 거대한 ‘인터넷 관문’ 역할을 하는 회사”이다.

• CDN(콘텐츠 전송 네트워크)
  • 전 세계에 깔린 서버(엣지)에 웹 콘텐츠를 캐시해 두었다가
  • 사용자가 가까운 서버에서 받아가도록 해서 속도를 빠르게 만들어 준다.
• 역프록시(Reverse Proxy)·로드 밸런싱
  • 사용자의 요청을 먼저 Cloudflare가 받고
  • 뒤에 있는 실제 서버(origin)로 라우팅해 주면서 트래픽을 분산시킨다.
• 보안(웹 방화벽·DDoS 방어·Bot Management)
  • 웹 공격, 크롤러, 봇 트래픽을 분석해서
  • 악성 요청은 차단하고 정상 유저만 통과시키는 보안 게이트 역할을 한다.
• Zero Trust·Access·VPN 같은 추가 기능
  • 내부 서비스에 대한 인증/인가(SSO, MFA 등)
  • 원격 접속 보안, 이메일 보안 등 기업용 보안 플랫폼 기능도 함께 제공한다.

요약하면, 많은 회사들이 “DNS + CDN + WAF + 봇 방어 + 인증”을 한 번에 맡기려고 쓰는 종합 인터넷 인프라

 

📌 Cloudflare의 시장 점유율

• 웹 기술 통계 서비스 W3Techs에 따르면
  • 역프록시를 쓰는 사이트 중 80% 이상이 Cloudflare를 사용한다.
  • 전체 웹사이트 기준으로 보면 약 20% 안팎의 사이트가 Cloudflare를 사용한다.
• Cloudflare 자체 발표 기준
  • 전 세계 2,500만 개 이상의 인터넷 프로퍼티가 Cloudflare 위에서 동작
  • “20% 넘는 웹사이트 앞에 앉아 있다”고 표현할 정도로 거대한 규모라고 밝히고 있다.

 

❓ 이번 장애 원인 설명

📌 전문적인 용어로 정리

• Cloudflare Bot Management는 각 요청에 대한 bot score를 계산하기 위해, ClickHouse 메타데이터를 기반으로 한 feature configuration file(특징 설정 파일)을 주기적으로 생성·배포하는 구조이다.

🌱 ClickHous : 대용량 데이터 분석용 컬럼 지향 데이터베이스 (OLAP DBMS)

 

• 11:05 UTC에 ClickHouse 권한(permissions) 변경을 적용하는 과정에서, system.columns 조회 결과에 원래 의도하지 않았던 다른 스키마(r0 등)의 컬럼 메타데이터까지 포함되었고, DB 이름 필터링이 없었던 쿼리 때문에 feature 정의가 중복·증폭되었다.

 

• 이로 인해 feature 파일이 설계보다 훨씬 커지면서, Bot Management 모듈에 설정된 **feature 개수 하드 리밋(약 200개)**을 초과하는 oversized configuration이 생성·배포되었다.

🌱 oversized configuration : 시스템이 감당할 수 있는 크기를 넘어설 정도로 설정이 과도하게 커진 상태

 

• 거대해진 feature 파일이 전 세계 FL/FL2 엣지 프록시에 배포되자, Bot 모듈이 리밋 초과로 panic 상태에 빠졌고, FL2(Rust 기반)에서 Result::unwrap() 호출이 에러 값에 대해 실행되면서 스레드 크래시 → 대량의 HTTP 5xx 응답이 발생하였다.

🌱 스레드 크래시 : 실행 중인 스레드가 예상치 못한 오류 때문에 정상적으로 종료되지 못하고 강제로 죽어버리는 상황

 

• feature 파일은 5분 주기 재생성, DB 권한 변경은 노드별 점진 롤아웃 방식이라, 정상/비정상 파일이 번갈아 배포되는 flap 패턴이 나타났고, 최종적으로 모든 노드가 잘못된 권한 상태가 되면서 지속적인 글로벌 장애로 이어졌다는 것이 Cloudflare 포스트모템의 골자이다.

🌱 flap 패턴 : 상태가 '정상 - 비정상' 사이를 짧은 주기로 계속 왔다 갔다 하는 것

 

📌 쉬운 이해를 위해 ‘경비’에 비유

기술 용어를 다 걷어내고, “건물 경비/출입 시스템” 비유로 보면 이렇게 볼 수 있다.

• Cloudflare = 건물 입구 공동 경비 시스템
  • 수많은 웹사이트(건물)들이 입구 경비 역할을 Cloudflare에 맡겨 둔 상태에서, 사용자는 일단 Cloudflare를 거쳐야만 서버(건물 안)로 들어갈 수 있다.
• Bot Management = 출입 검문 규칙/명단 파일
  • 누가 정상 손님이고, 누가 수상한 봇인지 구분하기 위해 출입 규칙이 적힌 명단 파일을 들고 있고, 이 파일은 새로운 패턴을 반영하기 위해 몇 분마다 자동으로 갱신·배포된다.
• 규칙 파일 생성 프로그램 버그 → ‘전화번호부급’ 규칙 파일 생성
  • 원래는 A4 몇 장짜리 규칙만 있으면 되는데, DB 권한 변경 과정의 버그로 같은 정보가 중복되면서, 규칙 파일이 전화번호부 여러 권 수준으로 비정상적으로 비대해졌다.
• 비대한 규칙 파일을 전 세계 입구에 동시에 배포
  • 이 너무 큰 규칙 파일이 전 세계 Cloudflare 경비 데스크(엣지 서버)로 한꺼번에 퍼졌고, 각 서버가 이 파일을 읽다가 과부하로 스레드/프로세스가 다운되기 시작했다.
• 입구 경비가 줄줄이 다운 → 건물(웹사이트) 진입 불가
  • 실제 웹 서버(건물 안)는 멀쩡했지만, 입구인 Cloudflare가 죽어버려 사용자는 건물 안으로 못 들어가고, 대신 5xx 에러 페이지만 보게 된 것이 이번 장애의 본질이다.

 

🔍 이번 장애에서 얻을 수 있는 교훈

📌 한 곳에 올인하면, 그곳이 곧 “인터넷 목줄”이 된다

• DNS, CDN, WAF, 인증, 봇 관리 등을 모두 Cloudflare 같은 한 사업자에 의존하면, 그 한 곳이 문제가 생겼을 때 서비스 전체가 같이 멈추는 구조가 된다.
• 가능하다면 멀티-CDN, 멀티-DNS, 멀티 리전/클라우드 등을 통해 “한 군데가 죽어도 서비스 전체는 버티는 구조”를 고민해야 한다.

 

📌 설정(config)도 코드처럼 관리해야 한다

• 이번 장애는 애플리케이션 로직 버그라기보다, DB 권한·메타데이터 쿼리·설정 파일 생성 로직이 꼬인 ‘구성 문제’였다.
• 그래서 내부에서 자동 생성되는 설정도
  • 사이즈·형식 검증
  • 항목 수/리밋 체크
  • 롤백 가능한 배포 파이프라인으로 코드와 같은 레벨로 관리해야 한다.
• “내부에서 나온 값이니까 당연히 안전하겠지”라는 가정을 버리는 게 핵심이다.

 

📌 보안 레이어 장애가 서비스 전체를 끌어내리지 않게

• Bot Management 같은 보안 레이어가 장애를 내면서, 정상 사용자까지 전부 막아버린 것이 이번 사건의 핵심이다.
• 설계 단계에서 미리 정해야 할 것
  • Fail-open : 장애 시 보안은 일부 포기하더라도 서비스는 살릴 것인가
  • Fail-closed : 서비스가 멈추더라도 보안을 최우선으로 지킬 것인가
• 최소한 어떤 기능(로그인, 결제, 단순 조회 등)은 어떻게 동작해야 하는지 기준을 미리 세워두는 것이 중요하다.