▲

Cloudflare 글로벌 네트워크 장애 발생

 (cloudflarestatus.com)
1P by GN⁺ 16일전 | ★ favorite | 댓글 1개
  • Cloudflare 글로벌 네트워크에서 내부 서비스 성능 저하가 발생해 여러 서비스가 간헐적으로 영향을 받음
  • Access, Bot Management, CDN/Cache, Dashboard, Firewall, Network, WARP, Workers 등 주요 서비스가 일시적으로 장애를 겪음
  • 엔지니어링 팀이 문제를 식별하고 수정 작업을 진행했으며, WARP와 Access 서비스가 먼저 복구됨
  • 이후 전 세계적으로 오류율과 지연이 점차 정상 수준으로 회복되고, 대시보드 서비스도 복원됨
  • 현재 모든 서비스가 정상적으로 운영 중이며, 사건은 완전히 해결된 상태

사건 개요

  • Cloudflare는 내부 서비스 성능 저하(Internal Service Degradation) 를 겪으며 일부 서비스가 간헐적으로 중단됨
    • 영향을 받은 서비스에는 Access, Bot Management, CDN/Cache, Dashboard, Firewall, Network, WARP, Workers 등이 포함됨
    • 회사는 즉시 복구 작업에 착수하고, 문제 해결 진행 상황을 지속적으로 업데이트함

문제 식별 및 초기 대응

  • Cloudflare는 문제를 조사 중(Investigating) 단계에서 내부 서비스 저하를 확인함
    • 일부 고객이 간헐적인 오류와 지연을 경험함
    • 엔지니어링 팀이 원인 분석과 복구 작업을 병행함
  • 이후 문제 원인을 식별(Identified) 하고 수정 작업을 시작함
    • 수정 도중 런던 지역의 WARP 접속이 일시적으로 비활성화되어, 해당 지역 사용자는 인터넷 연결 실패를 경험함

서비스 복구 진행

  • 수정 작업 후 Access와 WARP 서비스가 먼저 복구되어 오류율이 사고 이전 수준으로 돌아감
    • 런던 지역의 WARP 접속이 재활성화됨
  • 이후 Application Services 고객 대상 서비스 복원 작업이 이어짐
    • 대시보드 서비스 복구를 위한 변경 사항이 배포됨
    • 여전히 일부 고객이 로그인 또는 대시보드 사용 문제를 겪었으나, 추가 수정으로 해결됨

네트워크 전반의 안정화

  • 전 세계적으로 오류율과 지연(latency) 이 점차 감소하며 정상 수준으로 회복됨
    • Bot Management의 점수 계산(bot scores) 이 일시적으로 영향을 받았으나, 복구 과정에서 정상화됨
    • 엔지니어링 팀은 남은 오류를 제거하고 전체 네트워크 복구를 가속화함
  • 이후 모든 서비스가 정상적으로 작동하며, 오류율과 지연이 완전히 정상화됨

사건 종료 및 후속 조치

  • Cloudflare는 모든 서비스가 정상 운영 중임을 확인하고 사건을 종료함
    • 현재 추가적인 구성 변경은 없으며, 플랫폼을 면밀히 모니터링 중
    • 사고 원인에 대한 사후 조사(post-incident investigation) 가 진행 중이며, 결과는 추후 공개 예정
  • 이번 장애는 글로벌 네트워크 전반에 영향을 미친 사건으로 기록됨
▲
GN⁺ 16일전  [-]
Hacker News 의견

  • Cloudflare API 토큰이 있는 사람이라면 CF 프록시를 비활성화할 수 있는 명령어를 공유함
    curl 명령으로 zone ID와 DNS 레코드를 가져오고, PATCH 요청으로 "proxied": false로 설정하면 됨
    다만 SSL 인증서 손실, 보안/성능 저하, 그리고 백엔드 IP 노출 위험이 있으니 주의해야 함

    • 오래된 Global API Key만 있는 경우에는 X-Auth-Email과 X-Auth-Key 헤더를 사용하면 됨
      그리고 Cloudflare 트래픽만 허용하도록 설정해둔 사람은 그 규칙을 잠시 꺼야 함
    • 다음번에는 이 방법을 써야겠다고 생각했는데, API 토큰을 미리 만들어두지 않아 기다릴 수밖에 없었음
      다행히 지금은 다시 온라인 상태로 복구됨
    • Terraform provider로 처리했지만, 대시보드 접근이 안 되는 사람에게는 이 방법이 유용함
    • 좋은 팁임. 참고로 curl에서 GET 요청은 기본값이라 -X GET은 필요 없음
      -d 옵션을 쓰면 자동으로 POST가 되고, PATCH에는 -X PATCH가 맞음
    • Cloudflare WARP를 켜면 일부 사이트가 다시 작동함. 1.1.1.1도 비슷한 효과가 있을 듯함
      다만 터널링 후에도 일부 사이트는 여전히 부분적으로 다운 상태임

  • Cloudflare CTO가 밝히길, 봇 차단 시스템의 잠재 버그가 설정 변경 후 폭주하면서 네트워크 전반에 장애를 일으켰다고 함
    공격이 아니라 내부 문제였다고 출처에서 설명함

    • 대형 기업들이 아직도 구성 변경을 단계적으로 배포하지 않는 것이 놀라움
      코드나 설정 모두 데이터인데, 전 세계에 한 번에 배포하다가 대형 장애가 나는 패턴이 반복됨
    • 이런 핵심 정보가 댓글 상단에 올라갔으면 좋겠음. 사이버 공격 추측 댓글 사이에서 찾기 힘들었음
    • 설정 변경 하나로 CF 주가가 4% 하락했음. 이런 장애가 업계 전체에 미치는 경제적 영향이 궁금함

  • 동료가 갑자기 뛰어와서 자신이 Cloudflare 설정을 바꾼 직후 사이트가 다운돼서 자기가 망친 줄 알고 놀랐다고 함
    이 글을 보고 안도했다고 함

    • “그보다 더 심각함, 네가 Cloudflare 전체를 다운시킨 거야”라고 농담함
    • 그래도 정말 아닐까? 예전에 Fastly 대규모 장애도 있었으니까 의심은 남음
    • 누군가 실수한 게 아니라는 걸 알고 느끼는 이상한 안도감에 딱 맞는 단어가 있을까 궁금함
    • 혹시 그 동료가 Cloudflare 직원일지도 모름
    • 나도 클라이언트들한테 사이트가 안 된다는 메시지를 수십 개 받았는데, 어제 설정을 바꿔서 식은땀 흘렸음
      “Cloudflare down” 메시지를 보고 진심으로 안도했음

  • 네덜란드에서 확인해보니 거의 모든 서비스가 다운 상태였음
    Cloudflare 대시보드도 접속 불가였고, Betterstack 대시보드도 마찬가지였음
    아이러니하게도 상태 페이지는 살아 있어서 고객에게 공지를 못 하는 상황이었음

    • 나도 같은 경험을 했음. HN만 멀쩡한 이유는 Cloudflare를 안 쓰기 때문임
      “필요 없으면 Cloudflare 뒤에 두지 말라”는 블로그 글을 썼음
    • AWS나 Cloudflare에 과도하게 의존하는 게 위험하다는 걸 매년 깨닫지만, 대체가 쉽지 않음
      그래도 이런 대규모 장애가 나면 고객들이 의외로 이해심을 보여줌
    • Cloudflare 대시보드가 완전히 죽은 건 아니고, 집요하게 시도하면 프록시를 끌 수 있음
      몇 분 걸렸지만 hcker.news를 CF에서 분리함
    • 이런 상황을 보니 로컬 VPS에 상태 페이지를 올려주는 서비스를 만들면 비즈니스 기회가 있을 듯함
    • 내 사이드 프로젝트 Total Real Returns에서는
      하단에 외부 상태 페이지와 연결된 실시간 가동률 위젯을 넣어둠
      상태 SVG와
      외부 상태 페이지를 참고하면 됨

  • Cloudflare나 AWS가 멈췄을 때 내 self-hosted 서비스가 멀쩡히 작동하는 걸 보는 쾌감이 있음
    그들의 99.999% 가용성보다 지금은 내가 더 안정적임

    • 내 허접한 개인 사이트도 AWS, Azure, Cloudflare 장애 때 전부 살아 있었음
      이제 업타임 트래커를 달아볼까 함
    • 내 self-hosted 사이트는 Cloudflare 프록시 때문에 오히려 다운됨. 허탈함
    • 전통 기업들이 Oracle, SAP 같은 시스템은 멀쩡한데, 신규 클라우드 기반 서비스만 멈춘 상황을 겪고 있음
      신생 SaaS 기업들이 배워야 할 교훈임
    • DNS를 어떻게 처리하냐는 질문이 많음. 나도 라즈베리파이에서 호스팅 중인데 DNS를 Cloudflare로 옮긴 직후라
      내 작은 사이트가 다운된 게 웃기면서도 묘하게 만족스러움

  • 최근 들어 대규모 인프라 장애가 급증한 것 같음. AWS, Cloudflare 모두 SLA보다 훨씬 못 미침

    • 대형 기업들이 대규모 해고 후 AI로 대체하겠다고 한 시점과 맞물려 있음
    • 이런 장애를 통해 SLA의 ‘9의 개수’가 의미 없다는 것을 깨달음
      실제 가동률이 아니라 기업이 임의로 정의한 수치일 뿐임
    • 어떤 사람은 “vibe code theory”라고 부름. 감으로 짠 코드가 늘수록 버그와 장애도 늘어난다는 농담 섞인 이론임
    • 연말 배포 금지 기간과 Q4 목표 압박이 겹쳐서 서둘러 배포하는 문화가 원인이라는 분석도 있음
    • 혹은 국가 단위의 사이버 공격일 수도 있다는 음모론적 시각도 있음

  • Cloudflare나 AWS가 멈추면 웹의 절반이 멈추는 중앙화 문제가 심각함

    • 사용자들도 크게 신경 쓰지 않음. “인터넷이 멈췄다”는 인식 덕분에 개별 서비스는 책임 회피가 가능함
      이런 구조가 바뀌지 않는 이유임
    • DDoS 방어에는 규모의 경제가 작용함. 고객이 많을수록 대역폭이 커지고 방어력이 강해짐
      작은 CDN은 경쟁이 어렵고, 결국 자연 독점 구조가 형성됨
      Cloudflare가 무료 요금제를 제공한 건 이런 네트워크 효과를 노린 전략이었음
    • 단일 장애 지점보다 더 걱정되는 건, 이런 중앙화가 웹 표준과 자율 호스팅의 미래를 왜곡할 수 있다는 점임
      또한 정부 검열의 집중 타깃이 될 가능성도 큼
    • Let's Encrypt도 잠재적 위험이 있음.
      웹의 2/3가 의존하고, 인증서 수명이 점점 짧아지며, 만약 해킹이나 장애가 발생하면 웹 전체가 마비될 수 있음
      지금은 선한 조직이지만, 과거의 Google도 그랬다는 점을 잊지 말아야 함
    • AWS 열풍 이후 개발자들이 전용 서버 대신 클라우드에만 의존하게 된 게 문제임
      소프트웨어 레벨의 백업은 많지만, 인프라 레벨의 다중 호스팅 상식이 사라졌음

  • 아이러니하게도 DownDetector도 Cloudflare Turnstile을 써서 같이 다운됨

    • AWS 장애 보고도 폭증했지만, 아마 오탐일 가능성이 큼
    • 나도 그 현상을 봤음

  • Cloudflare의 “Your browser: Working / Host: Working / Cloudflare: Error”라는 시각적 사과 메시지가 인상적이었음

    • 이런 화면은 처음 봄. 다만 내 경우 “Host”가 Cloudflare Pages라서 의미가 애매했음
    • “Cloudflare”를 클릭하면 여전히 고객 서버 문제라고 안내하는 건 좀 웃김
    • 솔직한 메시지라 좋았지만, 사용자들은 “와이파이 고쳐달라”는 반응뿐이었음
    • 그래도 상황을 명확히 알고 대응할 수 있었음. 필요하면 프록시를 비활성화해 서비스 영향 최소화 가능함
    • 나도 한 시간 동안 로그를 뒤지다가 내 서버 문제가 아니라는 걸 깨달았음

  • Cloudflare Challenge(“I’m not a robot”)를 쓰는 사이트들도 HTTP 500 오류를 내며 멈춤
    “challenges.cloudflare.com을 차단 해제하라”는 메시지가 뜸

    • 요즘 에러 처리 수준이 너무 낮음. 기업들이 책임을 회피하려고 사용자 탓으로 돌리거나
      무한 로딩 화면만 보여줌. 실제로는 백엔드가 명확한 에러를 반환하는데 프론트가 숨김
      최근엔 비밀번호가 너무 길다는 에러를 “이메일이 이미 사용 중”으로 바꿔 보여주는 사례도 봄
    • 이 장애로 chat.bing.com의 AI 검색(GPT5) 도 멈춤
      아이러니하게도 AI에게 인간임을 증명해야 하는 상황이 됨
    • 일부 사이트(pinkbike 등)는 “you have been blocked” 메시지를 표시함
    • 로봇뿐 아니라 실제 사람도 차단당하는 셈임 /s
    • 프론트엔드가 사용자가 DNS나 확장 프로그램으로 도메인을 차단했다고 오인하는 듯함
      Cloudflare Captcha가 다운될 리 없다는 /s식 부정이 웃김
답변달기