- Cloudflare DashboardとAPIの障害は、Control Plane APIと製品サービスをポートランドの主要データセンターに戻した後、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とポートランド復旧
- Cloudflareは、データセンターに影響した電力喪失を評価しながら同時にサービスをfailoverした
- 北米の中核データセンターの電力が部分的に復旧した後、一部の重要サービスはバックアップデータセンターへfailoverされ、影響が緩和された
- 復旧過程では、複数の更新で「gradual improvement」と「restore full functionality」の状態が繰り返し示された
- 最終段階では、ポートランドの主要データセンターへControl Plane APIと製品サービスを戻した
- 2023-11-06 17:00 UTCから、ポートランドの 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もポートランドの主要データセンターへの復旧を開始
- 復旧完了後も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 を参照
1件のコメント
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 たちに同情する
Cloudflare は、データセンターに影響した電力喪失を評価しつつ、同時にサービスのフェイルオーバーを進めていると述べていた
商用電源が落ちて発電機に切り替えたが、その発電機も失敗し、一部の商用電源が戻ってサイトの一部復旧が進んでいるようだ
https://puck.nether.net/pipermail/outages/2023-November/0149...
ただし意図と現実は常にずれるもので、地球の反対側にあるデータセンターへ自動または緊急の手動フェイルオーバーを行うことが、多くのワークロードにとって現実的な解決策ではなかった理由はいくつも聞いた
Cloudflare はカオステストをかなり行っており、データセンター全体のネットワーク分離も非常に定期的にテストしている
今回の件がなぜそこまで違ったのかを議論する会議に、こっそり潜り込んでみたい
そのうち片方しか直接作っていないが、マーケティングではいつも一緒に括られていた
API で階層型キャッシュのトポロジーをカスタマイズしているエンタープライズユーザーでないなら、キャッシュトポロジーが数日や数週間古くなっても、おおむね問題ないと思う
ただし、述べたように他の多くのものは問題を抱える可能性がある
保守と事前計画をどれだけうまくやっても、最終的には想定外だった、またはコスト上備えられなかった条件が発生し、重要インフラが落ちる可能性はゼロではない
ダッシュボード UI は更新に API を使っているように見えるので、おそらく API アクセスの性能劣化が原因だった可能性が高い
UI では DNS 更新が反映されたように見えても実際には伝播されず、障害後に Cloudflare ダッシュボードでドメインを丸ごと削除して作り直さないと、SSL と DNS 伝播が再び動作しなかった
12時間が経ったのに、まだ問題が続いている
オンラインの音楽制作講座を受けているのだが、動画が Cloudflare Stream に載っていて、ひとつも再生されない
https://www.cloudflare.com/products/cloudflare-stream/
インターネットの半分にとっての単一障害点問題が、また頭をもたげている
https://www.cloudflarestatus.com/incidents/hm7491k53ppg
ダッシュボードとダッシュボード内の機能だけに影響があると思っていたが、Cloudflare の動画ストリーミングが動かないというなら、そうではないのかもしれない
よく分からないが、Cloudflare には少しもやもやする
なぜこれほど多くの人が、インターネットの大きな部分を一社に依存させてもよいと考えるのか分からない
自分の認識が間違っているかもしれないが、Cloudflare は寡占的な巨大企業に対抗する信頼できる挑戦者に見えるし、もっと多くの Cloudflare があればいいと思う
実際、Cloudflare ほど寛大な無料枠を提供する類似サービスはあまり知らない
TLS を正しく使えばエンドツーエンドのセキュリティを提供するが、Cloudflare を使うと Cloudflare がすべての平文トラフィックにアクセスできる
小さなサイトが DoS の標的になり得るなら、結局 Cloudflare を使うしかない
私個人の印象で、間違っているかもしれない
数日前にあのバグをまたコミットしたのかと思った
https://blog.cloudflare.com/cloudflare-incident-on-october-3...
そうではなく、中枢データセンターの電源障害のように見える
詳細は他のコメントにある
ここまで来ると、パブロフの犬のように障害を楽しむようになってきた
先週だけで、すでに2回目の障害
消えたコメントへの返信に付け加えると、これはプログラミング言語の選択とはまったく関係ない
DreamHost も太平洋時間午前4:54から PDX で問題が起きている
https://www.dreamhoststatus.com
Flexential PDX02 が、この件が始まったのとほぼ同じ時刻に電力を失ったと報告されている
Cloudflare がたった今、データセンターに影響した電力喪失を評価しつつ、同時にサービスのフェイルオーバーを進めていると発表した
うちの Flexential には発電機5台、地下のバッテリーバックアップ、隔離区域がある
一番印象的なのは、ステータスページは実際に動いているという点
もちろん別の場所でホスティングしている可能性が高いが、大規模障害のたびにいつも同じことを考えて笑ってしまう
あまり良さそうには見えない
今回の件で自社サービスの利用をやめないでほしい
Vercel のデプロイとエッジ関数全般も動作していない
ステータスページには「上位プロバイダーの1つの問題を根本原因として特定し、緩和に向けて協力中」とある
エッジ関数は内部的に Workers を使っているのかと思った
リンク: https://www.vercel-status.com/
同じスレッドの別リンクでは、Flexential PDX02 が同じ時刻に電力を失ったと出ている
商用電源が切れて発電機に切り替えたが、その発電機も失敗し、一部の商用電源が戻ってサイトの一部復旧が進行中のようだ
データセンター全体が落ち、Cloudflare のフェイルオーバーが期待ほどスムーズに処理できなかったように聞こえる
https://puck.nether.net/pipermail/outages/2023-November/0149...
こうした製品のかなり多くが Cloudflare 製品を包んだラッパーにすぎないという事実を、誇るべきなのか怖がるべきなのか分からない
この場合はラッパーではないようで、DO の App Platform は Workers の上に載せるだけにしてはかなり洗練されている
複数の中核ワークロードが Workers を使っているのではないかと推測される
タイミングが悪い
今日の午後が四半期決算発表だ