Cloudflareのメジャーな11月18日 アウトエイジ - 概要

2025年11月18日、インターネットの大部分が崩壊した。
ChatGPT、X（Twitter）、League of Legends、Shopify、Coinbase、あるいは数え切れないほどの小さなサイトを開くと、Cloudflareブランドの5xxエラーページが表示されるか、サイトがまったく読み込まれなくなった。当初は「インターネットが壊れた」大きな瞬間のように見えたが、もっと微妙で、ある意味ではもっと心配なものであることが判明した。

以下は、昨日のCloudflareの障害（2025年11月18日）で何が起こったのか、なぜ起こったのか、誰に影響があったのか、そしてインフラチームはそこからどのような教訓を得るべきかについての詳細なウォークスルーである。

昨日実際に何が起こったのか？

2025年11月18日火曜日、UTC深夜の頃、Cloudflareは同社のネットワークを通過したトラフィックに対して大量のHTTP 5xxサーバーエラーを返し始めました。エンドユーザーにとっては、多くの人気ウェブサイトやアプリにアクセスしようとすると、"Internal Server Error "や "Gateway Error "のページが表示されるということだった。

Cloudflare自身の事故後のブログによると、この障害は以下のようなものだった：

• 11:28UTCに顧客のHTTPトラフィックに影響開始

• コアCDNとセキュリティサービス全体で5xxエラーが広範囲に発生

• 13:05-14:30（UTC）頃に主要な緩和措置を実施

• 17:06UTCまでに5xxエラーの量をベースラインまで回復Cloudflareブログ

Cloudflare 自身は、この障害について、2019年以降で最悪の障害であると説明している。というのも、この障害は1つの機能やダッシュボードに影響しただけでなく、顧客のトラフィックの大部分をネットワーク経由でルーティングするコアプロキシレイヤーを混乱させたからだ。クラウドフレアのブログ

サードパーティのモニタリングがこれを裏付けた。Cisco ThousandEyesは、Cloudflareに影響するグローバルな機能停止を確認し、X、OpenAI (ChatGPT)、Anthropicなどのサービスでタイムアウトや5xxエラーが発生した一方、ネットワークパス自体は正常であることを確認しました。これは、ISPレベルやルーティングの問題ではなく、バックエンドのサービス障害であることを強く示唆している。サウザンドアイズ

誰が影響を受けたのか？

Cloudflareはインターネットの膨大な部分（ウェブのサイトの約20％がパフォーマンスとセキュリティのためにCloudflareに依存している）の前に位置しているため、爆発半径は莫大であった。AP News+1

影響を受けたと報告されたサービス

• ChatGPT / OpenAI

• X（旧ツイッター）

• Canva、Shopify、Dropbox、Coinbase

• リーグ・オブ・レジェンドなどのゲームプラットフォーム

• ニュージャージー・トランジットやフランスのSNCF鉄道デジタルシステムなど、様々な公共交通機関や政府のサイト AP News+1

Downdetectorのような障害トラッカーは、ピーク時に数千件の同時問題報告を記録した。ロイターは、一時はXだけで約5,000人のユーザーが影響を受けたと報告したが、その後、修正が展開されるにつれて件数は減少した。ロイター

ユーザーから見ると、これは次のように見える：

• サイトがまったく読み込まれない

• ログインフローがハングアップしたり、失敗したりした（特にCloudflare AccessやTurnstileが関係している場合）。

• APIが断続的に、または5xxエラーで応答する

• ダッシュボードや管理パネルのタイムアウト

言い換えれば、根本的な原因は単一のプロバイダーの内部システムに集中していたにもかかわらず、インターネットの膨大な部分が「ダウンしたように感じられた」ということだ。

Cloudflareの通常の仕組み（簡単に言うと）

今回の障害がなぜこれほど深刻だったのかを理解するには、Cloudflareのネットワークを通るリクエストの大まかな経路を知ることが役立ちます。

CloudflareはリバースプロキシCDNおよびセキュリティレイヤーとして機能します：

1. ブラウザやアプリはオリジンサイトに直接接続するのではなく、Cloudflareに接続します。

2. CloudflareはエッジでTLSとHTTPを終了します。

3. リクエストはFL（「フロントライン」）と呼ばれるCloudflareのコアプロキシシステムと、その新世代のFL2に流れ込みます。

4. そのコアプロキシは

   • WAF（ウェブアプリケーションファイアウォール）ルールの適用

   • ボット管理モデルの実行

   • DDoS防御、キャッシュ、オリジンへのイグレスの処理

   • Workers、R2、Accessなどの他の内部製品へのトラフィックのルーティングCloudflareブログ

あるデータセンターに問題が発生した場合、トラフィックは他のデータセンター経由でルーティングされ、設定変更は慎重にロールアウトされる。

昨日の停止は、障害が共通プロキシパスの内部にあり、世界中に頻繁に自動的にプッシュされる設定ファイルと密接に結びついていたため、まさに最悪でした。

根本的な原因：ボット管理機能ファイルの不正使用

Cloudflareの公式説明では、1つの重要な原因が指摘されている：
ボット管理システムで使用されている機能設定ファイルです。クラウドフレアのブログ

事象の連鎖をわかりやすく説明します：

1. ボットマネジメントは "機能ファイル "を使用

   • Cloudflareのボット検出モデルは、人間かボットかを判断するために使用される各リクエストに関するシグナルである一連の「フィーチャー」に依存しています。

   • これらの機能は設定ファイルにまとめられ、数分ごとに再生成されてグローバルに展開されるため、Cloudflareは新しい攻撃パターンに迅速に対応することができます。Cloudflareブログ

2. ClickHouseクエリの動作の変更

   • フィーチャーファイルはClickHouseデータベースに対するクエリによって生成されます。

   • Cloudflareは11:05 UTC頃に、分散クエリのセキュリティとパーミッションを向上させる変更を行いました。これにより、ユーザーはデフォルトスキーマだけでなく、基礎となるr0テーブルのメタデータも参照できるようになりました。Cloudflareブログ

   • 特徴リストを作成するクエリはデータベース名でフィルタリングしていませんでした。突然、 defaultと r0の両方から重複したカラムを取得し始め、特徴行の数が実質2倍になりました。

3. 特徴ファイルのサイズが爆発的に増加

   • ボットマネジメントモジュールには、受け付けられるフィーチャーの数にハードリミットがある（通常使用される60をはるかに超える200に設定）。

   • 新しく生成されたファイルがこの上限を超えると、モジュールは上限に達してパニックに陥りました。これは、エラー値に対してResult::unwrap() を使用した Rust コードで未処理のエラーが発生したためです。Cloudflare ブログ

4. コアプロキシサービスが 5xx エラーを返すようになった

   • ボット管理はコアプロキシパスに統合されているため、このパニックは、そのモジュールに依存するすべてのトラフィックのHTTP 5xx 応答として表面化しました。

   • 新しいFL2エンジンでは、明確な5xxエラーが表示されました。

   • 古いFLエンジンでは、ボットスコアが静かにゼロになり、ボットブロッキングルールで誤検出を引き起こす可能性がありました。Cloudflareブログ

5. 本当に厄介なのは、ファイルが "good "と "bad "の間で反転し続けることです。

   • ClickHouseクラスタは徐々に更新され、フィーチャーファイルは5分ごとに再生成された。

   • クエリは更新されたノードで実行されることもあれば（悪いファイルが生成される）、更新されていないノードで実行されることもあった（良いファイルが生成される）。

   • つまり、Cloudflareのネットワークはしばらくの間、ファイルの異なるバージョンが伝搬されるにつれて、正常動作と障害の間で揺れ動いたのです。Cloudflareブログ

この振動により、状況は内部的に非常に混乱しました。当初、Cloudflareのチームは、エラーパターンが単純なソフトウェアクラッシュには見えなかったため、大規模なDDoS攻撃を疑いました。自社のインフラ以外でホストされているCloudflareのステータスページでさえ、一時的にエラーが表示された。クラウドフレアのブログ+1

共通の要因がボット機能ファイルであることが分かって初めて、事態は明らかになった。

事件のタイムライン

Cloudflareの事後報告とサードパーティの報告に基づき、2025年11月18日の大まかなタイムラインをまとめることができる：クラウドフレアブログ+2ThousandEyes+2

• 11:05 UTC- データベースアクセス制御の変更がClickHouseに導入される。

• 11:20-11:30 UTC- ボット管理機能ファイルの悪いバージョンが生成され、伝播し始める。

• 11:28 UTC- 最初の顧客への影響：顧客のトラフィックで HTTP 5xx エラーが増加。

• 11:30-11:32 UTC- 外部監視ツールと自動テストが断続的な障害を検出し始める。

• 11:35 UTC- Cloudflareが内部インシデントコールを開き、調査を開始。

• ~11:48 UTC- Cloudflare がインシデントを確認するステータスアップデートを発表。再送信

• 11:30-13:05 UTC- チームは、Workers KV の動作が低下していると思われる現象に注目し、考えられる複数の原因（攻撃シナリオを含む）を調査する。

• 13:05 UTC- 重要な緩和策：Workers KVとCloudflare Accessはコアプロキシをバイパスするように変更され、影響は軽減された。Cloudflareブログ

• 14:30 UTC- 根本原因が特定され、不良機能ファイルの生成と伝播が停止。既知の正常な設定ファイルを手動で挿入し、コアプロキシを再起動。ほとんどのコアのトラフィックは正常に戻りました。Cloudflare ブログ

• 14:40-15:30 UTC- Turnstileと認証試行のバックログが二次的な負荷スパイクを引き起こすため、ダッシュボードとログインの問題が長引く。Cloudflare ブログ

• 17:06 UTC- エラー率が基準値に戻り、Cloudflareはシステムが完全に正常であることを宣言。Cloudflareブログ

ユーザーから見ると、この障害はUTCの深夜から午後の早い時間帯に最もひどく感じられましたが、正確な影響範囲は地域によって、また各サービスがどのCloudflare製品に依存しているかによって異なりました。

この停電が重要な理由

集中化のリスク

Cloudflareは、主要なクラウドプラットフォーム（AWS、Azure、GCP）や他の大規模CDNと並んで、インターネットインフラの中心的プロバイダーの小さな集合の一部です。これらのプレイヤーの1つに障害が発生した場合、その影響は広範囲に及び、多くの場合明白ではありません。

今回の障害は

• BGPルーティングの不具合やISPのケーブル切断によるものではありません。

• 悪意ある攻撃によるものではない（当初は疑われたが）。

• 内部コンポーネントの1つのコンフィギュレーションと制限のバグに起因する。

これは、複雑で緊密に結合したシステムが、外部からの干渉がなくても、いかに壊滅的な障害を起こす可能性があるかを示すものとして重要である。多くの組織が同じプロバイダー上に構築すると、そのプロバイダーは事実上、システム的に重要なインターネットの一部となる。

"ソフト "な依存関係も痛手

影響を受けたサービスの中には、Cloudflareを単にダムCDNとして使用していたわけではありません。以下のようなサービスもありました：

• 認証とゼロトラストアクセスにCloudflare Accessを使用していた。

• 内部制御プレーンの一部としてWorkers KVを使用していた。

• ボットに強いログインのためにTurnstileを利用している。クラウドフレアのブログ+1

これらの製品に障害が発生した場合、ダウンするのはウェブサイトのコンテンツだけではなく、ログイン、管理機能、内部APIも同様にダウンします。ステータスページ、インシデントツール、管理UIも、障害が発生したプロバイダに依存している可能性があります。

Cloudflareは何を変更すると言っているか

Cloudflareのブログでは、同様のことが再発するリスクを低減するために同社がすでに講じているいくつかの改善措置の概要が紹介されています：Cloudflare ブログ

1. 自動生成された設定ファイルの取り込みを強化する。
   ロールアウト前のスキーマとサイズの厳密なチェックを含め、内部で生成された設定ファイルを、ユーザーが入力したものと同じように懐疑的に扱い、検証する。

2. よりグローバルなキルスイッチ
   ネットワーク全体で問題のある内部モジュール（ボット管理など）を迅速に無効にすることを容易にし、プロキシパス全体をパニックに陥れるのではなく、オープンな状態で失敗するようにします。

3. エラーストームからシステムリソースを保護
   エラーが急増し始めたときに、コアダンプ、デバッグメタデータ、および観測可能性ツールがCPUとメモリを圧倒できないようにします。

4. コアプロキシモジュール全体の障害モードをレビューする
   各内部モジュールが予期しない入力や構成の下でどのように動作するかを系統的に監査し、グローバルな障害ではなく、gracefulな劣化を保証する。

5. ロールアウトと分離を洗練させる
   このインシデントは、Cloudflareが新しいコンフィグとDBの動作がどのように伝播するかをさらに細分化し、単一の悪い変更がフリート全体に影響する可能性を減らすことを示唆している。

Cloudflareはまた、このインシデントを自社の期待する回復力の絶対的な失敗と位置づけ、「容認できない」とし、顧客と一般インターネットユーザーの双方に苦痛を与えたことを明確に認めている。Cloudflareブログ

インフラとSREチームへの教訓

Cloudflareのような巨大なものを運営していなくても、今回の障害には非常に実践的な設計と運用の教訓がいくつかあります：

内部設定を信頼できない入力のように扱う

自分たちで」生成した設定が常に正しいと思い込むのは簡単だ。昨日は、それがなぜ危険なのかを示している：

• コンフィグファイルを適用する前に、そのサイズ、形状、制限を常に検証すること。

• 最初にトラフィックやノードの小さなサブセットにコンフィグをカナリア的に適用し、異常があれば自動でロールバックすることを検討する。

• 機能数、メモリーの事前割り当て、CPU使用量について、厳密な上限とサーキットブレーカーを維持する。

グレースフル・パーシャル・フェイルの設計

ボット管理モジュールの1つのバグがプロキシ経路全体をパニックに陥れてはならない：

• 完全な停止という選択肢がある場合、セキュリティのいくつかのレイヤーでフェイルオープン対フェイルクローズドをデフォルトにする。

• 非中核機能のための明確でテストされたキルスイッチを構築する。

• 重要なサブシステム(認証、ステータスページ、インシデントツール)が、デグレードモードで、あるいは代替経路で動作できることを確実にする。

正しいシグナルを監視する

5分ごとに「良いコンフィグ」と「悪いコンフィグ」の間で揺れ動くシグナルは、攻撃トラフィックやノイズの多い外部動作のように見えます：

• 観測可能なパイプラインに、バージョンごとまたはコンフィグごとの相関関係があることを確認してください。

• エラーグラフの上にコンフィギュレーションの変更を視覚的に明らかにするダッシュボードを構築する。

• 外部の視点からの強力な合成テストを含め、内部障害とネットワーク/パスの問題を素早く区別できるようにする。

1つのインフラバスケットにすべての卵を入れない

Cloudflareを使用している組織の場合：

• 本当にミッションクリティカルなプロパティには、マルチCDNセットアップを検討してください。

• ステータスページをプライマリスタックと同じプロバイダに完全に依存させることは避けること（Cloudflareはこれを実践しているが、昨日はステータスページのホストに偶然トラブルが発生し、事態をさらに混乱させた）。Cloudflareブログ+1

• 認証、APIコントロールプレーン、フロントエンド配信をフォールバックパスなしで同じベンダーに緊密に結合する前に、よく考えてください。

全体像

ここ数カ月だけでも、Microsoft Azure、Amazon Web Services、そして今回のCloudflareで大規模な障害が発生し、消費者や企業のサービスの大部分が一時的にオフラインになった。APニュース+2ワシントン・ポスト+2

パターンは明らかだ：

• インターネットは、一握りの巨大インフラ・プロバイダーにますます依存するようになっている。

• 機能停止は、外部からの攻撃ではなく、複雑な内部変更によって引き起こされることが多い。

• 世界トップクラスのSREを実践しているプロバイダーでさえ、コンフィギュレーション、データベースの動作、ハードコードされた制限の間の予期せぬ相互作用によってつまづくことがある。

昨日のCloudflareの事件は、"クラウド "が魔法ではないことを思い知らされた。結局のところ、クラウドは人間によって書かれたソフトウェアであり、他のアプリケーションと同じようにバグの影響を受ける。

ユーザーにとっては、「あの朝、XとChatGPTがロードされなかった」と記憶されるだろう。
エンジニアにとっては、中核となる分散システムの微妙な設定バグが、いかにグローバルなインターネット・イベントに波及しうるかの教科書的な例として研究されることだろう。