2025年11月18日、Cloudflareのネットワークは、約2時間10分にわたり、ネットワークトラフィックの配信に重大な障害を経験しました。約3週間後の2025年12月5日、当社のネットワークは再度、ネットワークに接続されたアプリケーションの28%に対し、約25分間トラフィックを処理できませんでした。
2件のインシデントに関し、詳細な事後分析ブログ記事を公開いたしましたが、お客様からの信頼回復のため、更なる努力が必要であると認識しています。本日、このような障害の再発防止のため、Cloudflareで進行中の取り組みについて詳しくご紹介します。
当社は、このプランを「コードオレンジ：フェイルスモール」と呼んでいます。これは、大規模な障害につながる可能性のあるエラーや間違いに対するネットワークのレジリエンスを高めるという目標を反映したものです。「コードオレンジ」とは、このプロジェクトの作業が何よりも優先されるという意味です。背景として、Cloudflareは以前にも一度「コードオレンジ」を発令したことがあります。これは、全社を挙げて最優先で対応すべき別の大規模なインシデントが発生した後のことでした。最近の出来事についても、同様の取り組みが必要があると考えます。コードオレンジとは、それを実現するための手段であり、チームが必要に応じて部門横断的に連携して業務を遂行し、他の作業を一時停止できるようにするものです。
コードオレンジ作業の主要な3つの分野：
ソフトウェアバイナリのリリースに対して現在行っているように、ネットワークに伝播されるすべての構成変更に対して、制御されたロールアウトを要求します。
ネットワークトラフィックを処理するすべてのシステムの障害モードをレビュー、改善、テストし、予期しないエラー状態を含む、すべての条件下で明確に定義された動作を示すことを確認します。
社内の「ブレイクグラス」*手順を変更し、循環依存関係を解消することで、インシデント発生時に弊社とお客様が迅速に行動し、問題なくすべてのシステムにアクセスできるようにします。
これらのプロジェクトは、完了時に「ビッグバン」型の変更を一度に行うのではなく、進行に伴い反復的な改善を実現します。個々の更新は、Cloudflareのより高いレジリエンスに貢献します。最終的には、過去2か月間に発生した世界的インシデントの原因となった問題などを含め、Cloudflareのネットワークのレジリエンスが大幅に向上すると見ています。
これらのインシデントがお客様とインターネット全体にとって苦痛であることを理解しております。当社はこのことを非常に心苦しく思っており、この取り組みをCloudflare全員にとっての最優先事項といたしました。
* Cloudflareのブレークグラス手順では、特定の状況下において、特定の個人が権限を昇格させ、重大なシナリオを解決するために緊急措置を実行できます。
最初のインシデントでは、Cloudflareの顧客サイトにアクセスしたユーザーに、Cloudflareがリクエストに応答できないことを示すエラーページが表示されました。2つ目は、空白のページでした。
どちらの障害も同様のパターンでした。各インシデントが発生する直前に、当社は瞬時に世界数百都市のデータセンターにおいて構成変更をデプロイしました。
11月の変更は、ボット管理分類子の自動更新として自動的に行われました。当社は、ネットワークを流れるトラフィックから学習する様々な人工知能モデルを実行し、ボットを識別する検出機能を構築しています。これらのシステムは、常に更新され、セキュリティ保護を回避してお客様のサイトに到達しようとする悪意のある行為者に先手を打っています。
12月のインシデントにおいて、一般的なオープンソースフレームワークであるReactの脆弱性からお客様を保護する目的で、セキュリティアナリストが使用するセキュリティツールに変更をデプロイし、署名の改善を図りました。新しいボット管理更新の重要性と同様に、脆弱性を悪用しようとする攻撃者よりも先に行動する必要がありました。その変更がインシデントの開始の引き金となりました。
このパターンは、Cloudflareにおける構成変更のデプロイ方法と、ソフトウェア更新のリリース方法との間に、重大な隔たりがあることを明らかにしました。ソフトウェアのバージョン更新をリリースする際は、管理および監視された方法で実行します。デプロイメントは、新しいバイナリリリースごとに、グローバルトラフィックを処理できるようになる前に、複数のゲートを正常に完了する必要があります。まず従業員のトラフィックにデプロイし、その後、無料ユーザーから開始し、世界中のお客様に対して段階的に変更を適用していきます。いずれかの段階で異常が検出された場合、人手を介さずにリリースを元に戻すことができます。
その方法論は、構成の変更には適用されていません。ネットワークを支えるコアソフトウェアのリリースとは異なり、構成変更を行う場合、ソフトウェアの動作方法の値を変更することになり、即座に実行できます。この機能はお客様にも提供されています。Cloudflareで設定を変更すると、変更内容は数秒で世界中に反映されます。
そのスピードにはメリットがあるとはいえ、対処が必要なリスクも伴います。過去2件のインシデントから、ネットワークにおけるトラフィックの処理方法に適用される変更は、ソフトウェア自体の変更に適用するのと同等の、テスト済みの慎重さをもって扱う必要があることが示されました。
Cloudflareは、構成更新のデプロイ方法を刷新します
両インシデントに共通する本質的な要因として、設定変更が数秒でグローバルにデプロイされるという能力が挙げられます。どちらの事象においても、誤った構成によってネットワークは数秒で停止してしまいました。
ソフトウェアリリースで既に実施しているように、構成の段階的導入を導入することが、コードオレンジ計画における最重要の作業領域です。
Cloudflareの構成変更は、非常に迅速にネットワークに反映されます。ユーザーが新しいDNSレコードを作成するか、新しいセキュリティルールを作成すると、数秒以内にネットワーク上のサーバーの90%に到達します。これは、社内でQuicksilverと呼んでいるソフトウェアコンポーネントによって実現されています。
Quicksilverは、社内チームが必要とする構成変更にも使用されます。そのスピードは、当社のネットワークの動作を非常にすばやく反応してグローバルに更新することができる点です。しかし、どちらのインシデントでも、これにより破壊的変更がテストのためにゲートを通過するよりもむしろ、数秒でネットワーク全体に伝播しました。
ネットワークへの変更をほぼ瞬時にデプロイできる機能は多くの場合に役立ちますが、必須となるケースは稀です。現在、Quicksilver内で構成変更に対して管理されたデプロイメントを導入することで、コードと同様に構成を扱うための作業が進行中です。
当社では、Health Mediated Deployments（HMD）システムを通じて、1日に複数回、ネットワークにソフトウェア更新をリリースしています。このフレームワークにおいて、サービス（ネットワークにデプロイされたソフトウェア）を所有するCloudflareの各チームは、デプロイメントの成否を示す指標、ロールアウト計画、および失敗した場合の対応策を定義する必要があります。
サービスによって変数は若干異なります。別のデータセンターに移動する前に長い待ち時間が必要となる人もいれば、誤検出シグナルが発生した場合でも、エラー率に対する許容度が低い人もいます。
デプロイされると、当社のHMDツールキットは、各ステップを監視しながら、計画に沿って慎重に進行を開始します。いずれかのステップが失敗した場合、ロールバックが自動的に開始され、必要に応じてチームに通知されます。
コードオレンジ終了までに、構成更新も同様のプロセスに従います。これにより、過去の2件のインシデントで発生したような問題を、広範囲に拡大する前に迅速に発見できるようになると期待されます。
構成変更の管理を強化することで、インシデントが発生する前に多くの問題を捕捉できると期待していますが、ミスは起こり得るものと認識しています。どちらのインシデントでも、当社のネットワークのある部分におけるエラーが、お客様がCloudflareの利用方法を設定するために使用するコントロールプレーンを含め、当社の技術スタックの大部分で問題となりました。
地理的な拡大（より多くのデータセンターへの展開）や対象者（従業員や顧客タイプ）の拡大といった観点だけでなく、慎重かつ段階的なロールアウトについて検討する必要があります。また、サービスプログレッションによる障害（ボット管理サービスのようなある製品から、ダッシュボードのような関連性のない製品への拡散など）を含む、より安全なデプロイメントを計画する必要があります。
そのために、当社は、当社ネットワークを構成するすべての重要な製品とサービス間のインターフェース契約を見直しを行っております。これにより、a) 各インターフェース間で障害発生を前提とすること、b) その障害を可能な限り最も合理的な方法で処理することを確実にするのです。
ボット管理サービスの障害についてですが、少なくとも2つの重要なインターフェースがあり、そこで障害が発生することを想定していれば、お客様に影響が及ばない程度まで適切に対処できたはずです。1つ目は、破損した構成ファイルを読み取るインターフェースにありました。パニックに陥るのではなく、トラフィックがネットワークを通過できるようにする、検証済みの適切なデフォルト設定を用意すべきでした。そうすれば、最悪の場合でも、ボット検出の機械学習モデルに供給されるリアルタイムの微調整機能を失うだけで済んだはずです。
2番目のインターフェースは、当社のネットワークを実行するコアソフトウェアとボット管理モジュール自体の間にありました。ボット管理モジュールが故障した場合（発生したように）、デフォルトでトラフィックをドロップすべきではありませんでした。その代わりに、通過できる分類でトラフィックを許可するという、より控えめなデフォルトを考えることもできました。
インシデント発生時に、問題の解決に時間がかかりすぎました。いずれの場合も、セキュリティシステムが原因で、チームメンバーが問題解決に必要なツールにアクセスできなくなったこと、また、一部の内部システムが利用できなくなったことで、循環的な依存関係が発生し、遅延が発生しました。
セキュリティ企業として、当社のすべてのツールは、顧客データの安全を確保し、不正アクセスを防止するために、きめ細かいアクセス制御を備えた認証レイヤーによって保護されています。これは正しいことではあるものの、同時に、スピードが最優先事項であったにもかかわらず、現行のプロセスとシステムが対応を遅らせてしまったのです。
循環依存も顧客体験に影響しました。例えば、11月18日のインシデントの際、当社のNo CAPTCHAボットソリューションであるTurnstileが利用できなくなりました。CloudflareダッシュボードのログインフローでTurnstileを使用しているため、有効なセッションまたはAPIサービストークンを持たないお客様は、重大な変更を行う必要に迫られた際にCloudflareにログインできませんでした。
当社のチームは、緊急時における適切なツールへの迅速なアクセスを確保しつつ、セキュリティ要件を維持するため、すべてのブレイクグラス手順と技術の見直しおよび改善を行います。これには、循環依存関係の見直しと削除、またはインシデント発生時に迅速に「バイパス」できるようにすることが含まれます。また、訓練の頻度を増やし、将来起こりうる災害シナリオに先立ち、全チームがプロセスを十分に理解できるようにします。
この記事は、社内で行われているすべての作業を網羅しているわけではありませんが、上記のワークストリームは、チームが注力すべき最優先事項を示しています。これらのワークストリームはそれぞれ、Cloudflareのほぼすべての製品およびエンジニアリングチームに影響を与える詳細な計画に対応しています。まだまだ、やることがたくさんあります。
第1四半期終了日までに、そしてそれよりもずっと前に、以下を行います。
すべての運用システムが、構成管理のためにHealth Mediated Deployments（HMD）によって確実にカバーされているようにする。
各製品セットに応じて適切な故障モードに準拠するように、システムを更新する。
緊急時に適切な担当者が適切な修復を提供できるよう、適切なプロセスを整備する。
これらの目標の中には、恒久的に継続するものがあります。新しいソフトウェアをリリースする際には、常に循環依存関係をより適切に処理する必要があります。また、当社のセキュリティ技術の経時的な変化を反映するために、緊急避難手順を更新する必要があります。
過去2回のインシデントにおいて、当社はユーザーとインターネット全体に対し、ご迷惑をかけてしまいました。やるべき対応がまだあります。この作業の進捗に伴い、最新情報を共有していきます。また、お客様やパートナーから受け取った質問やフィードバックに感謝いたします。