2025年11月18日、世界のインターネットトラフィックの動脈が数時間にわたり寸断された。何百万ものユーザーが「502 Bad Gateway」や「503 Service Unavailable」の画面を前に立ち尽くし、企業の業務アプリは沈黙した。

この日、インターネットインフラの巨人であるCloudflareを襲ったのは、高度なDDoS攻撃でも、国家ぐるみのサイバーテロでもない。それは、皮肉にも「セキュリティを向上させるための日常的なデータベース権限の更新」という、極めてありふれた内部操作に潜んでいた論理的な落とし穴だった。

本稿では、Cloudflareが公開した詳細な事後分析レポートを基に、なぜ1つの設定ミスが地球規模のネットワーク麻痺を引き起こしたのか、その技術的背景を見ていきたい。ClickHouseの仕様、Rust言語のエラーハンドリング、そしてクラウド集中化のリスクについて、表面的な事象の裏にある構造的な脆弱性を浮き彫りにする。

AD

インシデントの核心：11時20分、インターネットが「パニック」した理由

障害の発生は協定世界時（UTC）11時20分。日本時間では同日20時20分、まさにゴールデンタイムのインターネット利用がピークを迎える時間帯だった。

事象の直接的な原因は、Cloudflareの「Bot Management（ボット管理）」システムが参照する「機能ファイル（Feature File）」の破損にある。しかし、ファイルが破損したプロセスこそが、現代の分散システムの複雑さを物語っている。

1. トリガー：ClickHouseの権限変更が生んだ「二重の幻影」

すべての発端は、11時05分（UTC）に行われたデータベースの権限変更だった。Cloudflareは分析基盤としてClickHouseを使用している。エンジニアチームは、分散クエリのセキュリティと信頼性を向上させるため、システムテーブルへのアクセス権限を調整する作業を行っていた。

ClickHouseのアーキテクチャにおいて、分散テーブル（defaultデータベース）は、各シャード上の実データを持つテーブル（r0データベース）を参照する構造になっている。これまでの設定では、ユーザーがテーブルメタデータをクエリしても、defaultデータベースの情報しか返されなかった。

しかし、今回の変更により、ユーザーは明示的にr0（基礎テーブル）のメタデータも参照できるようになった。ここで問題となったのが、ボット管理システムが定期実行していた以下のクエリだ。

SELECT name, type FROM system.columns WHERE table = 'http_requests_features' order by name;

このSQLには重大な欠陥があった。WHERE句でデータベース名（database = 'default'）を指定していなかったのである。

権限変更前は、暗黙的にdefaultのみが見えていたため問題なかった。しかし、変更後はdefaultとr0の両方のカラム情報が返されるようになった。結果として、クエリ結果には同じカラム定義が重複して含まれることになったのである。

2. 連鎖：2倍に膨れ上がった設定ファイル

このクエリ結果は、機械学習モデルがボット判定を行うための「特徴量（Feature）」を定義する設定ファイルの生成に使われていた。重複したカラムデータを取り込んだ結果、生成された設定ファイルのサイズは予期せず2倍に膨れ上がった。

この「肥大化したファイル」が、Cloudflareのグローバルネットワーク上の全サーバーに配信された瞬間、時限爆弾のスイッチが入った。

3. 崩壊：Rustの「unwrap()」とハードコードされた制限

各エッジサーバー上で動作するプロキシシステム（FL2と呼ばれる新しいアーキテクチャ）は、Rust言語で記述されていた。このシステムは、メモリ効率とパフォーマンスを最適化するために、読み込む特徴量の数にハードコードされた上限を設けていた。その数は「200」。

通常時の使用量は約60程度であり、200という数字は十分なバッファに見えた。しかし、重複データによって肥大化したファイルはこの上限を突破した。

ここでRustのコードにおけるエラーハンドリングの実装が仇となる。制限を超えた際の処理において、適切なエラー回復ではなく、致命的なクラッシュを引き起こすコードパスが実行されたのである。

// 概念的なコードフロー
thread fl2_worker_thread panicked: called `Result::unwrap()` on an `Err` value

unwrap()は、結果がエラーでないことを前提に値を強制的に取り出すメソッドだ。もしエラーであれば、プログラムは即座に「パニック（強制終了）」を起こす。これにより、ボット対策モジュールだけでなく、プロキシプロセス全体がクラッシュし、ユーザーにはHTTP 5xxエラーが返される事態となった。

捜査を撹乱した「幻のDDoS攻撃」と「明滅するシステム」

障害対応において最もエンジニアを苦しめるのは、「完全に壊れている」状態ではなく、「壊れたり直ったりする」状態である。今回のケースはまさにそれだった。

段階的ロールアウトの罠

問題のClickHouseクラスタへの変更は、一度に全ノードへ適用されたわけではなかった。段階的なロールアウトが行われていたため、設定ファイルを生成するクエリは、ある時は「変更未適用のノード（正常なファイル生成）」で実行され、ある時は「変更適用済みのノード（破損ファイル生成）」で実行された。

この設定ファイルは5分ごとに再生成される仕様だった。その結果、ネットワーク全体に配信されるファイルは「正常」と「異常」が交互に入れ替わる状態（フラッピング）となった。これにより、エラーレートが急上昇したかと思えば正常に戻るという奇妙な挙動を示し、原因特定を困難にした。

ステータスページのダウンという不運

さらに事態を混乱させたのは、Cloudflareの外部ステータスページまでもが、まったく無関係な理由で同時にダウンしたことだ。

通常、ステータスページはインフラ障害時でも情報提供できるよう、別系統でホストされる。しかし、このタイミングでのダウンは、調査チームに「Cloudflare全体を標的とした大規模かつ複合的な攻撃が行われているのではないか」という誤った仮説（バイアス）を植え付けた。社内チャットでは、最近猛威を振るっていたAisuruなどのボットネットによるDDoS攻撃の可能性が真剣に議論されたという。

AD

影響の広がり：アーキテクチャの違いが生んだ「明暗」

今回の障害では、Cloudflare内部のプロキシアーキテクチャの新旧によって、影響の出方が異なった点が興味深い。

  • FL2（新アーキテクチャ・Rustベース）: 前述の通り、メモリ割り当てのパニックによりプロセスがクラッシュ。HTTP 5xxエラー（完全なサービス停止）を返した。
  • FL（旧アーキテクチャ）: クラッシュは免れたものの、ボットスコアの計算に失敗。安全側に倒すのではなく、すべてのトラフィックに対して「ボットスコア：0（完全にボットである）」を返してしまった。これにより、ボット遮断ルールを設定していた顧客のサイトでは、正規の人間によるアクセスまでもがブロックされる事態となった。

二次被害：TurnstileとDashboardの死

影響はWebサイトの表示だけにとどまらない。

  • Turnstile: Cloudflareが提供するCAPTCHA代替技術も機能不全に陥った。これにより、Turnstileをログイン画面に実装している多くのSaaSやWebサービスで、ユーザーがログインできない事態が発生した。
  • Cloudflare Dashboard: 自社の管理画面へのログインにもTurnstileが使われていたため、皮肉なことに、顧客が障害状況を確認したり設定を変更したりするためのダッシュボード自体にログインできないという、二重のロックアウト状態が発生した。
  • Workers KV: エッジストレージであるWorkers KVも、プロキシの不具合の影響を受け、エラー率が上昇。これに依存するCloudflare Accessなどの認証サービスも連鎖的に機能不全となった。

復旧への道のり：手動介入と「既知の良品」

エンジニアチームが「DDoS攻撃ではない」と確信し、設定ファイルの問題であることを突き止めたのは、障害発生から数時間が経過してからだった。

  1. 13:05 UTC: Workers KVなどの重要サービスに対し、問題のあるプロキシコアをバイパスする措置を実施。部分的な緩和に成功。
  2. 14:24 UTC: 自動生成システムを停止。問題のあるファイルの伝播を食い止める。
  3. 14:30 UTC: 過去に生成された「既知の正常な設定ファイル（Known Good File）」を手動で挿入し、強制的にプロキシを再起動。これにより、主要なトラフィックフローが回復した。
  4. 17:06 UTC: 残存するシステムの再起動や、溜まっていた処理の消化が完了し、完全復旧。

CEOのMatthew Prince氏は、「主要なインターネットサービスプロバイダとして、このような障害は容認できない」と謝罪し、2019年以来最悪のコアトラフィック障害であったことを認めた。

AD

構造的課題：2025年のクラウドはなぜ「脆い」のか

今回のインシデントは、単なる一企業のミスとして片付けるべきではない。2025年に入り、Microsoft Azure（10月29日、CDN設定ミス）、Amazon Web Services (AWS)（10月20日、US-East-1障害）と、ハイパースケーラーの障害が相次いでいる。

これらに共通するのは、「設定変更（Configuration Change）」がトリガーとなっている点だ。

1. 「信頼された入力」の不在

Cloudflareは今後の対策として「内部生成されたファイルであっても、ユーザー入力と同じように厳格なバリデーションを行う」としている。

これまで多くのシステム設計において、外部からの入力（HTTPリクエストなど）は「悪意がある可能性がある」として厳重に検証される一方、内部システムが生成する設定ファイルは「信頼できるもの（Trusted）」として扱われ、チェックが甘くなる傾向があった。今回のケースは、内部システム同士の連携においても「ゼロトラスト」的な検証思想が必要であることを痛感させる。

2. メモリ安全性と可用性のトレードオフ

Rustのようなメモリ安全性を重視する言語は、予期せぬメモリ状態になった際に「安全に停止（パニック）」することを選ぶ。これはセキュリティやデータ整合性の観点からは正しいが、可用性（Availability）が最優先されるインフラのコア部分では、プロセス全体を道連れにする諸刃の剣となる。エラー発生時にデフォルト値で動作継続するのか、停止するのか。その設計思想（Fail-open vs Fail-closed）の難しさが露呈した。

3. 単一障害点としての「集中化」

Cloudflare、AWS、Azureへの依存度が高まるにつれ、たった一つの設定ミスが世界中のデジタル経済を停止させるリスクは増大している。Amazonでの買い物、Microsoft 365での業務、そしてCloudflareで守られたニュースサイトの閲覧。これらが同時に止まる可能性を示唆する一連の障害は、マルチクラウド構成や、CDNの冗長化といった「脱・単一ベンダー」の議論を加速させるだろう。

運用精度への回帰

今回の障害は、AIによる自律制御や高度なサイバー防御といった華々しい技術の足元で、データベースのクエリ設計やファイルサイズの制限といった「泥臭いエンジニアリング」がいかに重要かを再認識させた。

Matthew Prince氏の言葉通り、クラウドエコシステムが拡大すればするほど、求められるのは魔法のような新機能ではなく、極めて退屈で、しかし完璧な「運用の精度（Operational Precision）」なのだ。

エンジニアリングの世界に「絶対」はない。しかし、システムが失敗したときにどう振る舞うか、その設計品質こそが、次の「インターネット崩壊」を防ぐ唯一の防波堤となる。

Sources