CDNの構成変更が数秒で世界中に反映される功罪 Cloudflareのインシデント再発防止プランとは：「React2Shell」脆弱性対応も引き金に

Cloudflareは、2025年11月18日と12月5日に発生した2件の重大なネットワーク障害を受け、インシデント再発防止プラン「コードオレンジ：フェイルスモール」を発表した。

[＠IT]

　CDN（コンテンツ配信ネットワーク）を提供・運営するCloudflareは2025年12月19日（米国時間）、直近で発生した2件の重大なネットワーク障害を受け、再発防止に向けたレジリエンス計画「コードオレンジ：フェイルスモール」を発表した。

　Cloudflareでは、2025年11月18日に約2時間10分にわたる重大な障害が発生し（参考）、さらに約3週間後の12月5日にも、接続されたアプリケーションの28％が約25分間トラフィックを処理できない事態に陥った。同社はこれらの事態を重く受け止め、全社を挙げて最優先で対応する「コードオレンジ」を発令した。

「コードオレンジ：フェイルスモール - 最近のインシデント発生後の当社のレジリエンス計画」から引用）

インシデント再発防止プラン「コードオレンジ：フェイルスモール」とは

　「コードオレンジ：フェイルスモール」は、大規模な障害につながる可能性のあるエラーに対するネットワークのレジリエンスを高めることを目的としている。コードオレンジの期間中は、チームが部門横断的に連携して業務を遂行し、他の作業を一時停止して復旧プロジェクトを最優先で進める。

　計画における主要な3つの分野は次の通り。

• 構成変更の段階的ロールアウト（本番環境への展開）
  • ネットワークに広がる全ての構成変更に対し、ソフトウェアバイナリのリリースと同様に制御されたロールアウトを要求する
• 障害モードのレビューとテスト
  • 全てのシステムの障害モードを確認、改善、テストし、予期しないエラー状態を含む条件下で動作を明確化する
• 緊急手順の刷新
  • 社内の「ブレークグラス」（非常措置ルール）手順を変更して循環依存関係を解消し、インシデント発生時にシステムへ迅速にアクセスできるようにする

CDNの構成変更が数秒で世界中に反映される功罪―構成更新のデプロイ方法を刷新

　2025年11月の障害はbot管理サービスの自動更新が原因であり、12月の障害はオープンソースライブラリ「React」の脆弱（ぜいじゃく）性から保護するためのセキュリティツールへの変更が引き金になった。どちらの事象も、世界数百都市のデータセンターにおいて構成変更をデプロイした直後に発生している。

　同社ではソフトウェアのバージョン更新については、従業員、無料ユーザー、全世界の顧客に段階的に適用し、異常があれば自動でロールバックする管理体制を敷いている。一方で、構成変更（社内コンポーネント「Quicksilver」による配信）は数秒で世界中に反映される仕組みになっている。このスピードはメリットである半面、誤った設定が瞬時にネットワーク全体を停止させるリスクになっていた。

　コードオレンジ計画における最重要課題は、構成変更にもソフトウェアリリースと同等の段階的導入を適用することだ。具体的には、社内のHMD（Health Mediated Deployments）システムを通じて構成更新を管理する。

　HMDでは、サービスを所有する各チームがデプロイの成否を示す指標やロールアウト計画、失敗時の対応策を定義する。デプロイ中は各ステップが監視され、不具合が検出された場合は自動でロールバックが開始される仕組みだ。このプロセスを構成更新にも適用することで、問題が広範囲に拡大する前に発見できる体制を整える。

サービス間の障害モードへの対処

　構成変更の管理強化に加え、サービス間インタフェースのルールの見直しも進めている。ある製品の障害がコントロールプレーンなど他のスタックに波及することを防ぐため、次の2点を徹底する。

1. 各インタフェース間で障害が発生することを前提とする
2. 障害発生時に、検証済みのデフォルト（既定）設定を使用してトラフィックを通過させるなど、合理的な方法で処理する

　bot管理サービスの障害を例に挙げると、破損した構成ファイルを読み取った際にパニックに陥るのではなく、適切なデフォルト設定を適用していれば、最小限の影響でトラフィックを維持できた可能性がある。

緊急事態における対応スピードの向上

　過去のインシデントでは、問題解決に時間を要した点も課題になった。セキュリティシステムの影響でチームメンバーが必要なツールにアクセスできなくなったことや、内部システム間の循環依存により、対応が遅延したためだ。

　2025年11月の障害時には、bot管理サービス「Cloudflare Turnstile」が利用できなくなった結果、ダッシュボードのログインフローで同機能を使用していた顧客がログインできない事態が発生した。こうした循環依存を解消またはバイパスできるように手順を改善し、訓練の頻度を増やすことで、有事の際の迅速な復旧を図る。

今後のスケジュール

　同社は2026年第1四半期（1〜3月）終了時までに、以下の目標を達成するとしている。

• 全ての運用システムを構成管理のHMDでカバーする
• 各製品セットを適切な故障モードに準拠するように更新する
• 緊急時に適切な担当者が修復を提供できるプロセスを整備する

　これらは完了時に一度に変更するのではなく、進行に伴って反復的に改善していく計画だ。