Cloudflare CEOが語る大規模障害の原因と内部で起きたこと

Cloudflareで大規模な障害が発生し、世界中のサービスが一時的に5xxエラーを返しました。

直接の原因は、Bot Management用の設定ファイルがClickHouseの権限変更により肥大化し、プロキシが処理できなくなったことです。

Cloudflare 障害の発生経緯と原因の全体像

障害が始まった時刻とネットワークの状態

障害が表面化したのはUTC11時20分で、日本時間の夜に重なる時刻でした。この直後から世界規模で5xxが急増し、通常とは異なる急激な立ち上がりを示します。

それ以前のエラー率は安定しており、直前まで異常な増減は確認されていません。突発的に処理が詰まり始めた形で、基盤側の内部要因が強く疑われる状況でした。

しばらくの間、エラーが上昇と下降を繰り返す周期が続きました。設定ファイルが正常版と異常版で交互に配布され、各エッジの状態が一定しない動きを見せたためです。

応答遅延の増加も同時に発生し、従来より重いログ付与処理が動作した影響が残りました。内部の負荷が跳ね上がり、認証を含む多くのリクエストが滞留する構造です。

初期の5xxは11時28分から顕在化し、14時30分の巻き戻しによって落ち着きを取り戻しています。ただ、影響が完全に消えるまで時間差があり、17時台まで長い尾を引く形となりました。

誤認された攻撃疑惑と原因特定までの流れ

障害序盤ではWorkers KVのエラーが突出し、データ取得の遅延が別機能を巻き込んでいるようにも見えました。この段階で外部攻撃の可能性も候補に入り、広域監視が強化されます。

一時的にステータスページまで読み込み不良が発生したため、大規模DDoSの兆候と似た挙動に映りました。しかし、地域偏りやログの特徴が攻撃パターンと一致しない点が次第に明確になります。

調査が進むにつれて、新旧プロキシの両方でエラーが同時発生している点が重要視されました。外部要因ではなく共通設定ファイルの異常が根本にあった流れです。

特定の時刻でエラー率が下がる瞬間があり、そこでは古い設定に自動ロールバックされていた痕跡が残りました。この挙動が、設定ファイルの世代ごとの差を示しています。

異常設定ファイルの配布が連鎖を生んでいた点が決定的となり、原因調査の焦点はBot Managementが生成するfeatureファイルへと絞られていきました。

日本時間帯と国内利用者への影響

日本では夜間ピークに重なり、業務系から一般向けまで幅広いサービスで認証失敗が相次ぎました。Turnstileのチャレンジが表示されずログインできない状況も多く確認されています。

国内サービスはCDN、WAF、認証補助など複数のレイヤーを同じ基盤に載せる構成が多く、単一の設定不良でも広い範囲に影響が出やすい特徴があり、今回もその典型でした。

同じ時間帯でも問題なかったサイトも存在します。別CDNを使う構成や、認証を基盤外に置く方式では今回の設定ファイルを参照しないため、影響は限定的でした。

この差は、どの機能がどの層に依存しているかで明確に分かれます。影響が広がった理由は複数の重要機能が単一設定に依存していた構造にあります。

国内企業が依存層を正確に把握できていない課題が表面化した形で、障害の見え方と実態が大きく異なる例となりました。

Cloudflare Bot ManagementとClickHouse変更の問題点

featureファイルが肥大化した工程

featureファイルはBot判定のための特徴量リストで、数分ごとに自動生成されます。本来は数百行規模で安定しており、プロキシの読み込みも一定の範囲に収まる形式でした。

障害発生時はこのファイルが通常の倍以上に膨らみ、行数が一気に増える状態が続きました。内部クエリが想定外の列情報を取得し、出力内容が過剰になった影響です。

肥大化した特徴量が連続して配布されたことで、旧来のプロキシと新しいFL2の双方で読み込み上限を超えました。結果として設定ファイルの適用自体が停止する挙動につながります。

行数の急増は一時的な負荷ではなく、生成処理の段階で構造が崩れていた点に特徴があります。どのエッジに届くかで動作が異なり、安定しない状態が全階層へ波及しました。

このファイルは複数機能の判断材料に使われるため、正常と異常が交互に届く状況では挙動が揺れやすく、各エッジの状態が揃わない問題が残ります。

system.columnsの仕様変更で重複が生じた理由

ClickHouseの権限体系が変わった影響で、system.columnsテーブルから取得される列情報に重複が混じるようになりました。生成処理は列を一意に扱う前提だったため、この変化に対応していません。

重複列をそのまま扱う設計では、特徴量の抽出段階で行が二重化します。結果として通常より多い特徴リストが生成され、設定ファイルが肥大化する流れを生みました。

設定生成ロジックは上限を前提に動きますが、今回はその前提条件が崩れました。空間的な制御を持たずに増加した行数が新旧プロキシに届き、読み込み不能を引き起こした形です。

列情報の重複が直接featureファイルの肥大化へ結びついた点が今回の重要ポイントです。内部処理の整合性が保てず、読み込み上限チェックへ直撃しました。

仕様変更自体は計画的なものでしたが、依存する内部ロジックが追随していなかったため、構造的な齟齬が形になったケースといえます。

正常ファイルと異常ファイルが交互に配布された経緯

生成処理は複数ノードで独立して動き、各ノードはそれぞれのタイミングでファイルを出力します。この仕組みが、正常版と異常版が混在する背景にあります。

一部ノードは重複列を含むクエリ結果を返し、別のノードでは従来どおりの列構造を取得していました。この差が出力の差分となり、二種類の設定ファイルが作られる状況が続きました。

配布はエッジ単位で行われるため、どのタイミングでどちらのファイルが届くかは均一になりません。異なるバージョンが短時間で切り替わり、各エッジの状態が揺れる原因になります。

異常版と正常版が交互に届いたことで挙動が安定しない構造となり、5xxの増減が周期的に現れる結果へつながりました。

最終的には生成処理を止め、正常だった過去バージョンを固定配布する方針に切り替えています。この切り替えで周期的な変動は徐々に収束していきました。

Cloudflare FL2新プロキシのエラーと5xxの理由

事前割り当て上限超過で起きたエラー動作

プロキシ内部では特徴量の最大数があらかじめ決められ、実行時に余計な領域を確保しない仕組みになっています。処理の安定性と速度を維持するための前提です。

異常なfeatureファイルが届いた際、この最大数より多い特徴量が並ぶ状態となり、読み込みの段階で制限を超過しました。通常は到達しない条件で、保護のために動作が止まります。

読み込み段階で上限を超えた瞬間に処理が止まる動作は、性能最適化の名残であり、異常値を想定していない設計が原因と言えます。負荷を抑えるための仕組みが逆に停止を招いた形です。

設定ファイルはネットワーク全体に短時間で展開されるため、一部のエッジだけが停止するのではなく、複数地点が同時に上限へ到達しました。これが広範囲の停止につながります。

補正が入らない限り、この条件は自動的に解消されません。異常版が連続して届けば、各地点で停止が繰り返される構造になります。

Rustコードのunwrapが発生させたパニック

FL2ではRustで書かれた処理が多く、その内部で読み込み結果を評価する際にunwrapが使われていました。エラーが返る前提ではない箇所です。

実際には読み込み上限を超えてエラーが返り、unwrapが失敗してパニックに至りました。これはRustの標準的な保護機構で、異常値を許容しない挙動です。

想定外の戻り値がunwrapに渡った瞬間にパニックへ落ちる構造が今回表面化しました。安全性のための仕組みが停止として現れた例です。

Rust側は内部の型と制約に従って動くため、例外的な戻り値を無視して処理を継続する動きは取りません。異常値は必ず明示的に扱う必要があります。

パニック後はプロキシが再起動し、安定するまで5xxが継続しました。異常版が再配布されればまた同じ動きが繰り返されます。

FLとFL2で影響が異なった理由

旧来のFLは独自の実装で動き、特徴量の扱いにより緩い制限を持っていました。肥大化したfeatureファイルでも、bot判定が無効になる形で処理は継続できます。

FL2では機能ごとに細かい制約が設けられ、内部で扱う型や構造が整理されています。上限超過のような異常値は許容せず、停止が優先される動作です。

そのためFLはbot判定が壊れるだけで通過するが、FL2は停止する構造となりました。同じファイルでも影響が大きく違う部分です。

両者は併存して稼働していたため、サービスによっては5xxが多発し、別のサービスはbot機能の誤判定が増えるだけで済むなど、影響範囲がばらつきました。

プロキシの世代差がそのまま影響差となり、今回の挙動に混乱を生む原因になった流れです。

Cloudflare Workers KVやAccessなど下流サービスの障害

Workers KVが返した高いエラー率

Workers KVは読み込み要求をプロキシ経由で処理する構造のため、上流が不安定になるとエラーが直接跳ね返ります。障害当時はプロキシ停止と再起動が繰り返されました。

その結果、KVのフロントゲートが大量の5xxを返し、キャッシュ参照や設定読み込みが一時的に成立しない状況が続きました。通常の耐障害性が活かせない条件です。

上流のプロキシ停止がそのままKVの高いエラー率を生む構造で、下流側には独立した迂回経路がありませんでした。依存している順番が動作に直結した形です。

影響中はバックエンドへの再要求が増え、負荷が徐々に積み上がりました。この挙動が他機能にも連鎖し、全体的な応答速度低下を後押ししています。

最終的にはKV側に専用のバイパスが適用され、プロキシを経由しないルートで処理する形に切り替わりました。これにより応答は安定へ向かいました。

Access認証失敗と既存セッションの扱い

Accessの認証はログイン要求をプロキシへ送り、検証後に利用可能となる構造です。プロキシが停止するとログイン要求そのものが成立しません。

障害中は新規認証の多くが失敗し、ログインページから先へ進めない利用者が続出しました。一方で、既に発行済みのセッションは残り続けています。

新規は失敗するが既存セッションは維持される二層の状態が起き、利用者によって結果が異なる状況でした。認証基盤の構造がそのまま表面化した事例です。

設定変更もほぼ反映されず、更新に時間がかかる状態になりました。認証の内部データもプロキシ依存で、同期処理が止まると一時的に整合性が取れません。

この状態はプロキシ経路を切り替えた後に徐々に解消され、安定した認証フローに戻っていきました。

Turnstileとダッシュボードに連鎖した影響

Turnstileはログインページなどで利用される検証機能で、これもプロキシ経由で動作します。障害発生時は読み込み自体が行えず、ページが先へ進みませんでした。

その影響でダッシュボードのログイン成功率が大きく低下しました。Turnstileが反応しない限りログイン処理へ到達できず、認証前の段階で止まる流れです。

検証機能が動かずログインに入れない状態は、利用者が状況を把握しづらい問題を生みました。画面上は単なる読み込み失敗に見えるためです。

後半ではリトライ要求が集中し、通常の処理量を超える負荷がダッシュボード側に発生しました。この追加負荷が応答遅延をさらに押し広げました。

最終的には検証処理の安定後に集中負荷が解消され、管理画面の動作も通常の状態へ戻っています。

Cloudflare 再発防止策と企業が取れる対応の要点

内部生成ファイルへの厳格な検証とkillスイッチ

今回の障害では内部処理で作られる設定ファイルが原因となり、全体の挙動が不安定になりました。外部入力ではなく内部生成物に対する検証不足が表面化した形です。

対策として生成段階での構造チェックと内容の上限検証が重要になります。異常値を検知した時点で展開を止める仕組みが求められる流れです。

生成した設定を即座に無効化できるkillスイッチは、広範囲への配布を防ぐ要素として扱えます。内部配布の速度が速いほど、この仕組みの重要度は高まります。

企業側でも自社の設定反映プロセスが一方向になっていないか確認できます。誤った設定を巻き戻す手段が用意されているかは障害時の安定性に直結します。

内部生成処理が複雑なほど、途中段階での検証ポイントを増やす設計が求められます。異常値を吸収せず明示的に扱う流れが必要です。

エラー報告や監視機構がリソースを圧迫しない設計

障害時にはエラー情報を収集する観測機構が動きますが、今回はこれがCPU負荷を引き上げる要因になりました。エラーが増えるほど負荷も増す構造です。

観測は必要ですが、異常時だけ重くなる仕組みは健全とは言えません。軽量化された監視と重複報告を抑える処理が求められています。

障害発生中に監視そのものが処理能力を奪わない構造は重要で、全体の復旧速度にも影響します。正常時と異常時の負荷差を抑える設計です。

企業側では計測対象を増やしすぎていないか、状態変化を過度に記録しすぎていないかを確認できます。情報収集がサービス運用を阻害しない構造が必要です。

監視機構は「必要な最小限を確実に取る」方向へ調整し、異常時の負荷を抑える流れが望まれます。

日本企業が自社の運用設計で見直せるポイント

外部サービスに依存した構造では一部の設定変更が全体へ影響します。今回の障害は依存階層が深いほど影響が大きくなる例として扱えます。

まず押さえるべきは単一点故障への備えで、外部の認証やCDNが止まった場合にどこまで自社サービスが動くかを把握する流れです。

認証経路や設定反映の複線化は障害時の耐性を高めます。外部依存が増えるほど複数経路の用意が重要になります。

設定の巻き戻しや一時停止を自社側で制御できるかも確認ポイントです。外部停止に合わせて一部機能を切り替える仕組みが役立ちます。

障害の影響範囲を想定し、依存階層ごとに「止まると何が起きるか」を可視化することで、運用設計全体の安定性を高められます。

メグルテ編集部

テックの今を伝える編集部

MEGURUTE編集部は、国内外のテクノロジー・IT・AIニュースを日本語でわかりやすく届けるメディアです。SNSで話題のサービスや革新的な研究も、実用目線で解説。初心者にも読みやすく、信頼できる情報発信を心がけています。特集して欲しい事があればお問い合わせよりご連絡ください。