Cloudflare大規模障害を技術的に解説：一行のSQLミス → Rust unwrap → FLプロセス全落ちの連鎖

2025年11月、世界中の Cloudflare PoP が同時多発的にダウンし、
多くのサービスが 502/500 エラー を返す大規模障害が発生しました。

本記事では、Cloudflare公式ブログを元に 「なぜ一行のミスで世界中が落ちたのか」 を、アーキテクチャ図付きで分かりやすく解説します。

全体アーキテクチャ（問題発生までの流れ）

以下は、今回の障害を簡略化した Cloudflare の構造と
トラブル発生までの因果関係 を表すアーキテクチャ図です。

               [Developer / Operator]
                         │
                         │ ① DB権限調整中のSQLミス
                         ▼
               +----------------------+
               |   Config Database    |
               | (Sharded: US/EU/AS)  |
               +----------------------+
                  │       │       │
    ② DB名指定なし │       │       │ ② DB名指定なし
                  ▼       ▼       ▼
          +---------+ +---------+ +---------+
          |  us-db  | |  eu-db  | | asia-db |
          +---------+ +---------+ +---------+
               │            │           │
            └────③ 重複データが全DBに作成────┘

                    ④ 設定ファイル生成
                         ▼
             +----------------------+
             |  Feature File (巨大化) |
             +----------------------+
                         │
                         │ ⑤ 全PoPへ配信
                         ▼
        +---------------------------------------+
        |        Cloudflare Global PoPs         |
        | (東京 / 大阪 / SG / FRA / LAX / ...)  |
        +---------------------------------------+
              │                     │
     ⑥ FLプロセスが巨大ファイル   ⑥ 同じくパニック
              ▼                     ▼
    +----------------+     +----------------+
    |  FL Process    |     |  FL Process    |
    | (Front Line)   |     | (Front Line)   |
    +----------------+     +----------------+
           │                        │
     unwrap() panic!!        unwrap() panic!!

               ⑦ 全PoPの FL が次々死亡

                        ▼▼▼

           ❌ 世界規模で 502/500 エラー発生

① 原因：DB名を指定しないSQLが複数シャードに刺さった

DB名指定なしの SQL（例：INSERT INTO table ...）が
Bot管理モジュールのデータ調整中に実行されました。

Cloudflare のデータベースは シャード構成 のため、
ノードごとに「デフォルトDB」が異なります。

ノード	デフォルトDB
A	us-db
B	eu-db
C	asia-db

結果：

同じ INSERT が us/eu/asia すべての DB に複製されてしまった

これが featureファイルに反映され、巨大化。

② 巨大化した設定ファイルが全 PoP へ配信

Cloudflare は global configuration system を使い、
設定ファイルを 全PoPへ即時配信します。

巨大化したファイルは想定サイズを超えており、
次のステップの引き金になります。

③ Rust の unwrap() で FL プロセスが次々クラッシュ

FL（Front Line）プロセスは PoP で HTTP 交通の中心を担います。

読み込む際、Rust の以下のような実装が残っていました：

let config = load_config().unwrap(); // ← エラーを復帰できない

巨大になりすぎたファイル → Err が返る
→ unwrap() が panic
→ FLプロセスが落ちる

PoP 内の FL が落ちると、その PoP は HTTP処理が不可能 になり
Cloudflare を利用するサービスがすべて 502/500 を返します。

④ なぜ世界中で波状的に落ちたのか？

• 新旧のエンジン（Pingora世代/旧世代）が混在

• 設定配信のタイミングが PoP によって微妙にズレる

• → 復帰 → 設定再同期 → 再クラッシュ を繰り返す

そのためネットでは
「5分ごとに復活した」「また落ちた」が多数報告されました。

⑤ Cloudflare の対策（公式）

Cloudflare は以下の改善を発表：

• featureファイルに対する 強バリデーション

• 配信前のサニタイズ

• FL プロセスを unwrap禁止に

• 異常設定を PoP に配布しない kill-switch 導入

⑥ まとめ：一行のミス → 世界的障害の構図

• DB名を省略した SQL がシャード間で重複データを生成

• 設定ファイルが巨大化

• Rust の unwrap() が耐えきれず panic

• FL プロセス全落ち

• 世界中の Web サイトが 502/500 を返す事態に