▲

Cloudflare 2025년 12월 5일 장애

 (blog.cloudflare.com)
1P by GN⁺ 4일전 | ★ favorite | 댓글 1개
  • 2025년 12월 5일 08:47 UTC에 Cloudflare 네트워크 일부가 심각한 장애를 겪었으며, 약 25분 후인 09:12에 완전히 복구됨
  • 전체 HTTP 트래픽의 약 28% 가 영향을 받았고, 특정 조건을 만족한 고객만 장애를 경험함
  • 원인은 React Server Components 취약점(CVE-2025-55182) 대응 중 수행된 WAF(body parsing logic) 변경으로, 사이버 공격과는 무관함
  • FL1 프록시의 코드 오류로 인해 HTTP 500 오류가 발생했으며, 새 Rust 기반 FL2 프록시에서는 동일 오류가 발생하지 않음
  • Cloudflare는 11월 18일 장애 이후에도 유사한 문제가 반복된 점을 인정하고, 배포 안전성·복원력 강화 프로젝트를 최우선 과제로 진행 중임

장애 개요

  • 2025년 12월 5일 08:47 UTC에 Cloudflare 네트워크 일부에서 장애 발생
    • 09:12에 모든 서비스 복구, 총 25분간 영향
    • 전체 HTTP 트래픽의 약 28%가 영향을 받음
  • 장애는 사이버 공격이나 악의적 행위와 무관, 내부 설정 변경 중 발생
  • React Server Components의 신규 취약점 대응을 위한 WAF 본문 파싱 로직 수정이 원인

장애 원인 및 기술적 배경

  • Cloudflare WAF는 악성 페이로드 탐지를 위해 HTTP 요청 본문을 메모리에 버퍼링
    • 기존 버퍼 크기 128KB에서 1MB로 확장 중이었음
  • 내부 테스트 도구가 새 버퍼 크기를 지원하지 않아 테스트 도구를 비활성화하는 두 번째 변경을 수행
    • 이 변경은 전역 설정 시스템을 통해 즉시 전체 서버에 전파됨
  • FL1 프록시에서 이 변경이 오류 상태를 유발, HTTP 500 응답 발생
    • 오류 메시지: attempt to index field 'execute' (a nil value)
  • 문제는 즉시 식별되어 09:12에 변경이 되돌려짐

영향 범위

  • FL1 프록시를 사용하고 Cloudflare Managed Ruleset을 적용한 고객만 영향
    • 해당 사이트의 모든 요청이 HTTP 500 오류 반환
    • /cdn-cgi/trace 등 일부 테스트 엔드포인트는 예외
  • 중국 네트워크 및 다른 구성의 고객은 영향 없음

런타임 오류 상세

  • Cloudflare의 rulesets 시스템은 요청마다 규칙을 평가
    • 규칙은 필터와 액션으로 구성되며, execute 액션은 다른 규칙 세트를 호출
  • 내부 로깅 시스템이 execute를 사용해 테스트 규칙을 평가
  • killswitch 시스템이 오작동 규칙을 비활성화하도록 설계되어 있으나,
    • execute 액션이 포함된 규칙에 killswitch를 적용한 것은 이번이 처음
  • execute 객체가 존재하지 않는 상태에서 접근 시도하여 Lua 오류 발생
  • 이 오류는 수년간 존재했으나 탐지되지 않았던 단순 코드 버그
    • Rust로 작성된 FL2 프록시에서는 동일 오류가 발생하지 않음

11월 18일 장애 이후의 개선 진행 상황

  • 11월 18일에도 유사한 전역 배포로 인한 광범위 장애 발생
  • 당시 고객 수백 명과 직접 소통하며 단일 업데이트의 전면 확산 방지 계획을 공유
  • 해당 개선 작업이 아직 완료되지 않아 이번 장애에 영향을 미침
  • Cloudflare는 이를 조직 전체의 최우선 과제로 지정

진행 중인 복원력 강화 프로젝트

  • Enhanced Rollouts & Versioning
    • 위협 대응용 데이터 및 설정 변경에도 점진적 배포·건강 검증·신속 롤백 기능 적용
  • Streamlined Break Glass Capabilities
    • 내부 서비스 및 제어 플레인 상호작용 시에도 비상 조작 가능성 확보
  • Fail-Open 오류 처리
    • 구성 파일 오류 시 요청을 차단하지 않고 기본 정상 상태로 전환하거나 트래픽 통과
    • 일부 서비스는 fail-open/fail-closed 선택 옵션 제공 예정
  • 다음 주 내에 모든 복원력 프로젝트의 세부 내역 공개 예정
  • 그 전까지 네트워크 변경을 전면 중단(lockdown) 상태로 유지

타임라인 (UTC)

  • 08:47 – 구성 변경 배포 및 네트워크 전파 시작
  • 08:48 – 전체 영향 발생
  • 08:50 – 자동 경보로 사고 선언
  • 09:11 – 변경 되돌리기 시작
  • 09:12 – 복구 완료, 모든 트래픽 정상화

결론

  • Cloudflare는 두 차례 연속된 장애의 심각성을 인정하고 고객 및 인터넷 전체에 사과
  • 향후 배포 안전성, 오류 허용성, 복원력 강화를 통해 유사 사고 방지 계획 추진
▲
GN⁺ 4일전  [-]
Hacker News 의견들

  • 이번 Cloudflare 장애는 단순한 Lua 버그가 아니라, 근본적인 아키텍처 문제를 드러낸 사건임
    원래의 분산형 웹 구조는 이런 전역 장애에 훨씬 강했음. 반면 Cloudflare처럼 동질적인 중앙집중형 시스템은 한 번의 실수로 전 세계 서비스가 동시에 멈출 수 있음. Rust로 짜도 사람은 실수함. 결국 견고한 설계가 중요함

    • 결국 Cloudflare나 AWS 같은 거대 사업자에 의존할수록 웹의 안정성이 떨어진다는 뜻임
    • “말벌 1,000마리 vs 개 1마리” 비유처럼, 전역 장애든 지역 장애든 고통의 형태만 다를 뿐임. Cloudflare가 멈추면 수백 명의 엔지니어가 즉시 대응하지만, 내 서버가 멈추면 담당자는 산속 별장에 있을 수도 있음
    • 독점이 나쁘다는 논의는 제쳐두고, Cloudflare의 장기적 가동률을 보면 오히려 개별 사이트가 직접 인프라를 운영하는 것보다 낫다고 봄. 모든 서비스가 동시에 1시간 멈추는 게, 각각 따로따로 1시간씩 멈추는 것보다 사용자 입장에서는 낫다는 논리임. 다만 Cloudflare의 안정성이 평균 이하로 떨어진다면 그 가치는 사라짐
    • 초당 8천만 요청을 처리하는 규모라면, 애초에 하나의 제품이 이렇게 커지는 구조 자체가 문제라고 생각함
    • Cloudflare는 여전히 전 세계 어디서나 가장 빠르게 글로벌 인프라를 복구하는 회사 중 하나임. 이번에도 28% 네트워크 장애를 25분 만에 해결했고, 다른 클라우드보다 다운타임이 객관적으로 적음

  • 어젯밤 Cloudflare 500 오류를 여러 사이트에서 봤음. 그런데 상태 페이지에는 아무 언급이 없고, 예정된 유지보수 공지만 있었음

    • 대부분의 상태 페이지가 그렇듯, 실제 문제를 인식하고 업데이트하기까지 시간이 걸림. 완전 자동화되기 전까지는 Cloudflare도 예외가 아님. 더 걱정되는 건 최근 AWS, Azure, Cloudflare가 연달아 다운된 점임. 내 직감으로는 LLM 사용 증가, 인력 부족, 팬데믹 여파, 정치적 불안 등이 복합적으로 작용하는 듯함
    • 이런 상태 페이지 문제는 공개적인 비판을 통해서만 개선될 것 같음. “Cloudflare는 장애 감지조차 제대로 못 한다”는 피드백이 많아져야 함

  • Cloudflare의 품질 엔지니어링이 생산 속도를 따라가지 못하는 듯함. 예전 방산업계에서는 품질팀이 항상 더 숙련됐다고 들었는데, 소프트웨어 업계는 반대인 것 같음

    • 방산업계에서도 메모리 누수를 알고도 “사용 시간 내엔 문제없다”며 무시한 적이 있었다는 일화가 떠오름
    • 이런 일이 한 달에 두 번 일어났는데 “칭찬할 일”은 아님. 반복은 변명의 여지가 없음

  • 인터넷의 패킷 스위칭 구조는 원래 이런 전역 장애를 견디도록 설계된 것임.
    냉전 시절 DARPA 네트워크는 핵 공격 상황에서도 지휘 체계를 유지하려는 목적이 있었음.
    지금이야말로 인터넷의 로컬 우선(local-first) 패러다임으로 돌아가야 할 때임

  • 최근 Cloudflare가 인터넷을 더 느리고 불편하게 만들고 있다고 느낌. “당신이 인간임을 증명하세요” 같은 절차가 늘었고, 페이지 로딩도 지연됨.
    이는 사이트 보호보다는 AI 크롤링 과금 정책 때문인 듯함 (Pay-per-crawl 소개)

    • 이런 인간 인증 절차가 구형 브라우저와 호환되지 않아, 아예 접근이 불가능한 사이트도 생김
    • 하지만 AI가 무단으로 콘텐츠를 긁어가는 것도 문제임. Cloudflare는 사이트 주인에게 콘텐츠 보호 옵션을 제공하는 셈이고, 원치 않으면 끌 수도 있음
    • “이제는 우리를 몰래 감시조차 못 하네”라는 냉소도 나옴

  • Cloudflare의 전역 설정 시스템이 점진적 롤아웃 없이 몇 초 만에 전체 네트워크로 퍼지는 구조라 위험함.
    설정 변경이 오류를 일으킬 때 즉시 상관관계를 파악할 수 있는 체계가 필요함

    • 문제는 경보가 너무 늦게 울린 것임. 2분 만에 알림이 왔는데, 초 단위로 감지했어야 함.
      배포 담당자는 실시간 지표를 보며 즉시 롤백 버튼을 눌렀어야 함.
      코드 라인까지 명확히 로그에 찍혔는데, 배포팀과 코드 이해팀이 단절돼 있었던 듯함
    • 경고 신호를 보고 롤백을 시도했는데, 그 과정이 오히려 문제를 일으킨 것으로 보임
    • 내부 도구는 종종 오탐지가 많고, 스스로 깨져 있는 경우도 많음
    • “엔진 경고등이 계속 켜지길래 그냥 전구를 뽑았다”는 농담처럼 들림

  • Cloudflare의 가동률이 99.9% 아래로 떨어졌음. 내 집 PC보다 못한 수준임

    • AWS도 마찬가지임. 클라우드의 존재 이유가 “더 높은 가용성”인데, 비싸고 불안정하다면 직접 호스팅할 이유가 충분함
    • 하지만 자가 호스팅은 하드웨어 고장이나 백업 실패 시 복구에 며칠 걸릴 수도 있음
    • 지역 정전이 잦은 곳에서는 노트북과 배터리로 버티기도 힘듦. 가끔은 자급자족형 인프라를 꿈꾸기도 함
    • 현재 Cloudflare의 정확한 업타임 통계를 어디서 확인할 수 있는지 궁금함
    • 그래도 개인 PC와 Cloudflare를 단순 비교하는 건 무의미한 비유임

  • Cloudflare 규모라면 반드시 테스트 환경이 있어야 함.
    모든 변경은 격리된 모델 환경에서 시뮬레이션 후 점진적으로 배포해야 함.
    강한 타입 시스템보다 중요한 건 절차적 안전장치임

    • 우리 회사는 세 단계 배포 체계를 씀: 개발 → 내부 통합 → 프로덕션.
      실수 잦은 팀은 속도를 늦추고, 신뢰도 높은 팀은 빠르게 진행함.
      결국 기술적 속도는 선택의 문제임. SLA 위협이 생기면 속도를 줄이고 테스트를 강화해야 함
    • 무료 사용자들을 테스트 베드로 삼고, 유료 고객에게는 안정된 버전을 제공하는 것도 방법임
    • “강한 타입 시스템이 널 구해주지 않는다”는 말은, 절차적 실패 앞에서는 언어가 무력하다는 뜻임

  • Cloudflare의 소프트웨어 품질이 흔들리는 듯함.
    엔터프라이즈 전용 기능의 접근 검증이 마지막 단계에서만 이뤄지는 버그도 있었음

    • 나도 Cloudflare API에서 롤백이 불가능한 설정을 경험했음.
      지원팀을 거쳐야만 변경 가능했고, 수정까지 며칠 걸렸음
      관련 사례 링크
    • 이런 버그는 AI가 작성한 코드일 가능성도 있다고 봄
    • “마지막 단계에서만 체크한다”는 게 무슨 뜻인지 더 구체적으로 듣고 싶음

  • Cloudflare의 운영 문화가 궁금함.
    보안 이슈 대응 중 오류가 발생했는데, 롤백 대신 전역 배포를 또 진행했다는 건 위험한 결정임.
    “의심스러우면 롤백하라”는 기본 원칙을 어긴 셈임

    • 다만 이번은 React Server RCE 취약점 대응처럼 긴급한 상황이었음.
      배포를 늦추면 고객이 실제로 해킹당할 수 있었기에, 속도가 곧 보안이 되는 케이스였음
    • 롤백이 항상 정답은 아님. 절차가 익숙하지 않으면 그 자체가 리스크가 됨
    • 사실 두 번의 배포는 서로 다른 컴포넌트였음.
      첫 번째 수정이 두 번째의 잠재 버그를 드러낸 셈이라, 롤백보다 전진 배포(roll forward) 가 더 현실적일 때도 있음
    • Cloudflare는 빠른 성장 속에서 기술 부채를 쌓아왔을 가능성이 큼.
      최근의 잦은 장애는 그 부채가 드러나는 신호일 수 있음
답변달기