Cloudflare API 다운

 (news.ycombinator.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Cloudflare Dashboard와 API 장애는 Control Plane API와 제품 서비스를 Portland 주요 데이터센터로 되돌린 뒤 resolved 상태가 됨
  • API 인프라에 의존하던 Dashboard 기능, Alerts, Zero Trust, WARP, Pages, Workers 등에서 요청 실패와 오류 표시가 발생할 수 있었음
  • Cloudflare는 데이터센터 전력 손실을 평가하며 서비스를 failover했고, 북미 핵심 데이터센터 전력이 일부 복구된 뒤 백업 데이터센터로 핵심 서비스를 넘겨 영향을 줄임
  • 영향은 데이터 플레인과 컨트롤 플레인으로 나뉘었고, Logpush·Analytics·Workers Analytics Engine·Radar·CASB·DEX·Stream·DNS Updates 등이 시점별로 unavailable, degraded, restored 상태를 오감
  • 일부 Logpush 로그와 분석 데이터는 incident 중 손실됐으며, 종료 시점 근처 로그는 복구 가능성이 있었지만 전체 영향 범위는 진행 중에는 확정되지 않았음

Dashboard와 API 장애가 미친 범위

  • Cloudflare는 Cloudflare Dashboard와 관련 API 문제를 조사·복구했으며, 사용자는 Dashboard/API 요청 실패나 오류 표시를 겪을 수 있었음
  • 장애는 Cloudflare API 인프라에 의존하는 여러 서비스로 번짐
    • Alerts
    • Dashboard functionality
    • Zero Trust
    • WARP
    • Cloudflared
    • Waiting Room
    • Gateway
    • Stream
    • Magic WAN
    • API Shield
    • Pages
    • Workers
  • Cloudflare는 이 문제가 Cloudflare CDN의 캐시 파일 제공이나 Cloudflare Edge의 다른 보안 기능에는 영향을 주지 않는다고 밝힘

전력 손실 이후 failover와 Portland 복구

  • Cloudflare는 데이터센터에 영향을 준 전력 손실을 평가하면서 동시에 서비스를 failover함
  • 북미 핵심 데이터센터 전력이 부분 복구된 뒤, 일부 핵심 서비스는 백업 데이터센터로 failover되어 영향이 완화됨
  • 복구 과정에서는 여러 업데이트에서 “gradual improvement”와 “restore full functionality” 상태가 반복됨
  • 마지막 단계에서는 Portland 주요 데이터센터로 Control Plane API와 제품 서비스를 되돌림
    • 2023-11-06 17:00 UTC부터 Portland의 primary HA datacenters로 Control Plane API와 Product Services 복구를 시작함
    • 복구 작업은 약 2시간으로 안내됐고, 이 기간 Cloudflare API와 Dashboard 가용성이 저하될 수 있었음
    • 2023-11-06 18:30 UTC부터 Pages와 Workers Control Plane API 및 Product Services도 Portland 주요 데이터센터로 복구를 시작함
    • 복구 완료 뒤에도 Cloudflare는 안정성과 edge case를 모니터링함

데이터 플레인에서 깨진 기능들

  • 데이터 플레인 영향은 제품의 전체 기능이 부분 또는 전체 영향을 받는 범위로 정의됨
  • 초기 영향 서비스에는 Logpush, WARP/Zero Trust device posture, Cloudflare dashboard, Cloudflare API, Stream API, Workers API, Alert Notification System이 포함됨
  • 복구 중 상태가 바뀐 주요 서비스는 다음과 같음
    • Logpush: 많은 고객이 로그를 받지 못했고, 일부 로그가 손실됐을 수 있음. 이후 더 많은 job이 복구됐고, 대다수 job은 07:00 UTC까지 복구될 것으로 안내됨
    • Analytics / GraphQL API: 많은 고객의 analytics data가 Dashboard와 API에서 unavailable 상태였고, 이후 일부 또는 대부분의 analytics가 복구됐지만 일부 dataset은 남아 있었음
    • Workers Analytics Engine: 여러 업데이트에서 unavailable 상태로 남음
    • Stream API: not available에서 degraded performance but available로 이동했고, 이후 restored 상태가 됨
    • Healthchecks: not available에서 analytics 없는 restored 상태가 됐고, 이후 Healthcheck analytics도 restored로 이동함
    • Radar: degraded 상태가 이어지다가 Cloudflare Radar가 operational status로 복구됨
    • Support Services: Support portal이 unavailable인 동안 Enterprise 고객은 Enterprise support email address로 ticket을 올릴 수 있었고, 이후 Portal·Phone·Chat이 operational 상태가 됨
    • CASB: not available 또는 degraded performance 상태였고, 기존 CASB Findings는 볼 수 있었지만 scanning은 offline이었음. 이후 CASB API가 online이 됐고 scanning engine은 복구 중이며 데이터 손실은 예상되지 않는다고 안내됨
    • DEX: not available 상태에서 DEX API online으로 이동했고, fleet status·HTTP·Traceroute Test Result data가 복구 중이었으며 Saturday Nov 4 15:00 UTC 전후 복구가 예상됨
    • DNS Updates: degraded에서 restored로 이동함

컨트롤 플레인에서 제한된 구성 변경

  • 컨트롤 플레인 영향은 제품 기능은 edge에서 동작하지만 기존 구성 변경이 영향을 받는 범위로 정의됨
  • 초기 영향 서비스에는 Magic Transit, Argo Smart Routing, Workers KV, WAF, Rate Limiting, Rules, WARP/Zero Trust Registration, Waiting Room, Load Balancing and Healthchecks, Cloudflare Pages, Zero Trust Gateway, DNS Authoritative and Secondary, Cloudflare Tunnel, Workers KV namespace operations, Magic WAN, Cloudflare Images가 포함됨
  • 복구 중 상태가 바뀐 주요 서비스는 다음과 같음
    • Cloudflare API: degraded but accessible 또는 restored 상태로 업데이트됨
    • Cloudflare Pages: degraded but online에서 restored로 이동했고, 한동안 project 생성/삭제와 direct upload deployments가 degraded 상태였음
    • Magic Transit / Magic WAN: 변경 불가 상태에서 configuration plane이 내부적으로 동작하는 상태로 이동했으며, 긴급 변경은 account team에 연락하라는 안내가 있었음
    • Argo Smart Routing: configuration은 동작했지만 smart updates와 analytics는 offline 상태였음
    • Billing API / Registrar API: 일정 기간 read-only operations만 가능함
    • Lists: list item update가 일시 중단됐고, Dashboard에서는 동작하지만 API에서는 429 오류를 반환할 수 있었음. 이후 restored status로 이동했지만 한동안 Dashboard로만 수정 가능했음
    • SSL / SSL for SaaS: SSL provisioning delay와 custom hostname validation delay가 있었고, 이후 restored 상태가 됨
    • Access API, Images API, SOC Proactive Alerts, ZT Gateway, Area 1 Email Security, Direct Upload Deployments도 업데이트별로 degraded, unavailable, restored 상태를 오감

손실된 로그와 사후 분석

  • Cloudflare는 incident 중 일부 Logpush 로그와 analytics data가 손실됐다고 밝힘
  • incident 종료 시점에 가까운 로그는 복구 가능성이 있었지만, 진행 중에는 전체 영향 범위를 아직 알 수 없었음
  • 한 업데이트에서는 모든 로그와 analytics pipeline이 Saturday 4th November 2023 7AM UTC까지 operational 상태가 될 것이라고 안내됨
  • 이후 업데이트에서는 “대부분의 로그가 incident 중 손실됐다”고 표현하며, incident 해결 뒤 전체 평가를 제공하겠다고 밝힘
  • 자세한 내용은 Cloudflare의 post-mortem on Cloudflare control plane and analytics outage에서 확인할 수 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 3년 조금 전 일했을 때는 PDX가 나가면 중추 시스템이 나가는 구조였음
    DDoS 방어 같은 것은 이미 각 PoP 안에서 처리돼서 L3/L7 플러드나 새로운 공격도 괜찮았지만, 거의 나머지는 PDX에서 계산한 뒤 설정 데이터로 각 PoP에 배포하는 방식이었음
    흐름은 PoP가 데이터 생성/수집 → PDX로 전송 → PDX에서 계산 → 업데이트/데이터를 PoP로 배포였고, PDX가 죽으면 최신 데이터에 의존하는 많은 기능이 점점 낡은 상태로 굴러가게 됨
    그 뒤 모든 게 바뀌었을 것 같지는 않아서, 단순히 “API 다운”이라기보다 부하 분산, 계층형 캐시, Argo Smart Routing, Warp/Zero Trust 같은 기능들이 PDX 업데이트 없이 오래된 상태 정보로 돌아가는 성능 저하 상태일 가능성이 큼
    설령 “API 다운”뿐이어도 많은 고객 자동화가 API 호출로 공격을 차단하니, 공격자에게는 꽤 큰 기회 창이 열리는 셈임
    퇴사 직전 AMS를 세우는 데 투자 중이었지만 큰 장애 조치 테스트는 성공한 적이 없었고, 최신 상태가 필요한 서비스 대부분은 그 방식을 알지 못했음
    덧붙이면 관측성 대부분도 PDX 기반이라, 지금 앞이 안 보이는 상태로 뛰고 있을 팀들과 SRE들에게 위로를 보냄

    • 다른 쪽에서 PDX02 전체 장애가 났다고 올렸고, 최신 상태 업데이트를 보면 이게 근본 원인처럼 보임
      Cloudflare는 데이터센터에 영향을 준 전력 손실을 평가하면서 동시에 서비스 장애 조치를 진행 중이라고 했음
      유틸리티 전원이 끊겨 발전기로 전환했는데 발전기도 실패했고, 일부 유틸리티 전원이 돌아와 사이트 일부 복구가 진행 중인 듯함
      https://puck.nether.net/pipermail/outages/2023-November/0149...
    • 기억이 맞다면 AMS는 기존에 PDX의 장애 조치 보조 역할도 하던 LUX를 대체하거나 보강하려는 새 데이터센터였음
      다만 의도와 현실은 늘 벌어지고, 지구 반대편 데이터센터로 자동 또는 비상 수동 장애 조치를 하는 것이 많은 워크로드에 현실적인 해법이 아니었던 여러 이유를 들었음
      Cloudflare는 카오스 테스트를 많이 하고, 전체 데이터센터 네트워크 분리도 아주 정기적으로 테스트함
      이번 사건이 왜 그렇게 달랐는지 논의하는 회의에 몰래 들어가 보고 싶음
    • 몇 년 전 기준으로 계층형 캐시와 Argo는 서로 다른 기능이었음
      둘 중 하나만 직접 만들었지만 마케팅에서는 항상 같이 묶어 부름
      API로 계층형 캐시 토폴로지를 커스터마이즈하는 엔터프라이즈 사용자가 아니라면, 캐시 토폴로지가 며칠이나 몇 주 낡아도 대체로 괜찮을 것 같음
      다만 말한 것처럼 다른 많은 것들은 문제를 겪을 수 있음
    • 발전기, 에어컨, UPS, 자동 전환 스위치는 모두 기계 장치라 고장에 취약함
      유지보수와 사전 계획을 아무리 잘해도, 결국 예상하지 못했거나 비용상 대비하지 못한 조건이 발생해 핵심 인프라가 내려갈 가능성은 0이 아님
    • 장애 상당 시간 동안 DNS 업데이트도 내려갔음
      대시보드 UI가 업데이트에 API를 쓰는 것으로 보이니 아마 API 접근 성능 저하 때문일 가능성이 큼
      UI에서 DNS 업데이트가 반영되는 것처럼 보여도 실제 전파는 되지 않았고, 장애 후 Cloudflare 대시보드에서 도메인을 통째로 삭제하고 다시 만들어야 SSL과 DNS 전파가 다시 동작했음

  • 12시간이 지났는데도 아직 문제가 계속됨
    온라인 음악 제작 강의를 듣고 있는데 영상이 Cloudflare Stream에 올라가 있고 하나도 재생되지 않음
    https://www.cloudflare.com/products/cloudflare-stream/
    인터넷 절반의 단일 장애점 문제가 계속 고개를 들고 있음

    • 이제 24시간이 지났는데도 Stream이 아직 복구되지 않았음
    • “이 문제는 Cloudflare CDN을 통한 캐시 파일 제공이나 Cloudflare Edge의 다른 보안 기능에는 영향을 주지 않는다”고 되어 있음
      https://www.cloudflarestatus.com/incidents/hm7491k53ppg
      대시보드와 대시보드 내부 기능에만 영향이 있는 줄 알았는데, Cloudflare 영상 스트리밍이 안 된다고 하니 그게 아닌 건가 싶음

  • 잘 모르겠지만 Cloudflare는 좀 찝찝함
    왜 그렇게 많은 이들이 인터넷의 큰 부분을 한 회사에 의존하게 둬도 된다고 생각하는지 모르겠음

    • 원칙적으로 동의하지만, 이런 말은 Amazon(AWS), Google, Microsoft 같은 회사보다 Cloudflare에 더 쉽게 붙는 느낌도 있음
      내 인식이 틀렸을 수도 있지만, Cloudflare는 과점적인 거대 회사들에 맞서는 신뢰할 만한 도전자로 보이고, 더 많은 Cloudflare가 있었으면 함
    • 사람들이 Cloudflare에 의존해야 한다고 생각한다기보다는, Cloudflare가 전반적으로 실적이 좋고 기본 서비스가 무료라서 그렇게 된 것 같음
      실제로 Cloudflare처럼 관대한 무료 등급을 주는 비슷한 서비스를 잘 모르겠음
    • 의존성뿐 아니라 Cloudflare가 설계상 막대한 TLS 트래픽의 중간자라는 점도 문제임
      TLS를 제대로 쓰면 종단 간 보안을 제공하지만, Cloudflare를 쓰면 Cloudflare가 모든 평문 트래픽에 접근할 수 있음
    • 무료이거나 심지어 저렴한 대안도 없음
      작은 사이트가 DoS 대상이 될 수 있다면 결국 Cloudflare를 써야 함
    • Cloudflare는 다른 클라우드 제공자처럼 마지막 한 푼까지 짜내려 하지 않는, 꽤 공정한 제품 구성을 가진 것처럼 느껴짐
      내 개인적 인상이고, 틀렸을 수도 있음

  • 며칠 전 그 버그를 다시 커밋한 건가 싶었음
    https://blog.cloudflare.com/cloudflare-incident-on-october-3...
    아니었고, 중추 데이터센터 전력 장애처럼 보임
    자세한 내용은 다른 댓글들에 있음

    • Cloudflare가 내려갈 때마다 흥미로운 글을 보상처럼 받게 됨
      이쯤 되니 파블로프처럼 장애를 즐기게 됐음

  • 지난주에만 벌써 두 번째 장애임
    죽은 댓글 답변에 덧붙이면, 이건 프로그래밍 언어 선택과는 아무 관련 없음

  • DreamHost도 태평양시각 오전 4:54부터 PDX에서 문제가 있음
    https://www.dreamhoststatus.com

  • Flexential PDX02가 이 일이 시작된 비슷한 시점에 전력을 잃었다고 알려짐

    • 관련 있어 보임
      Cloudflare가 방금 데이터센터에 영향을 준 전력 손실을 평가하면서 동시에 서비스 장애 조치를 진행 중이라고 발표했음
    • 어쩌다 그렇게 됐는지 궁금함
      우리 쪽 Flexential은 발전기 5대, 지하의 배터리 백업, 격리 구역을 갖추고 있음
    • 원인과 결과 중 어느 쪽이라고 보나?

  • 가장 인상적인 건 상태 페이지는 실제로 동작한다는 점임

    • “Atlassian Statuspage로 구동됨”
    • 장애 나는 서비스가 수두룩한데 상태 페이지는 좀처럼 내려가지 않는다는 게 아이러니함
      물론 다른 곳에 호스팅했을 가능성이 크지만, 큰 장애가 날 때마다 항상 같은 생각을 하며 웃게 됨

  • 별로 좋아 보이지 않음
    이번 일 때문에 자체 서비스 사용을 그만두지 않았으면 좋겠음
    Vercel 배포와 엣지 함수 전반도 동작하지 않음
    상태 페이지에는 “상위 제공자 중 하나의 문제를 근본 원인으로 확인했고, 완화를 위해 협력 중”이라고 되어 있음
    엣지 함수가 내부적으로 Workers를 쓰는 건가 싶음
    링크: https://www.vercel-status.com/

    • 엣지 함수는 지표 수집 같은 작은 추가 코드가 붙은 Workers일 가능성이 꽤 높음
    • Cloudflare 쪽 업데이트로는 데이터센터에 영향을 준 전력 손실을 평가하면서 동시에 서비스 장애 조치를 진행 중이라고 함
      같은 스레드의 다른 링크에서는 Flexential PDX02가 같은 시점에 전력을 잃었다고 나옴
      유틸리티 전원이 끊겨 발전기로 전환했는데 발전기도 실패했고, 일부 유틸리티 전원이 돌아와 사이트 일부 복구가 진행 중인 듯함
      전체 데이터센터가 내려갔고, Cloudflare의 장애 조치가 기대만큼 매끄럽게 처리하지 못한 것처럼 들림
      https://puck.nether.net/pipermail/outages/2023-November/0149...
    • DigitalOcean도 영향이 있음: https://status.digitalocean.com/incidents/bw3r3j9b5ph5
      이런 제품 상당수가 Cloudflare 제품을 감싼 래퍼에 불과하다는 사실을 자랑스러워해야 할지 무서워해야 할지 모르겠음
      이 경우에는 래퍼는 아닌 것 같고, DO의 App Platform은 Workers 위에만 올리기에는 꽤 정교함
      핵심 워크로드 여러 개가 Workers를 쓰고 있는 것으로 추측됨
    • 맞음: https://news.ycombinator.com/item?id=29003514

  • 타이밍이 나쁨
    오늘 오후가 분기 실적 발표임

    • 누군가 실적 발표에서 공개할 무언가를 서둘러 배포하려 했던 걸지도 모름
답변달기