要約

  • クリーンアップ用タスクが値のないpending_deleteを送信した。Addressing APIは全BYOIPプレフィックスの取得と解釈し、タスクはプレフィックスと依存するサービスバインディングを削除した。
  • 約1,100のプレフィックスが撤回された。そのうち約800は再広告で戻ったが、約300はエッジのサービス設定も失っており、後続の全体的な復旧を要した。経路の再広告はサービス復旧の一段階にすぎなかった。

復旧には二つ目の時計がある

Cloudflareの2026年2月20日の障害をBGP障害と呼ぶのは正しい。しかし、重要な事実は経路が戻り始めてから表面化した。一部の顧客プレフィックスは再広告されたものの、Cloudflareのエッジには、そのアドレス宛ての通信をどのサービスで処理するかを示すバインディングが残っていなかった。経路が先に戻り、サービスは後から戻った。

パブリックIPアドレスそのものはアプリケーションではない。プレフィックスには、顧客による保有、事業者への広告委任、事業者のアドレス台帳への登録、BGP広告、製品へのバインディング、エッジ機器への設定反映という別々の状態がある。つながってはいるが、同じ状態ではない。外から経路が見えるだけでは、パケットが正しい顧客サービスに届くとはいえない。

Cloudflareの事後報告によると、定期クリーンアップタスクは顧客がBYOIPから削除を依頼したプレフィックスの処理を自動化するものだった。ところがタスクはpending_deleteを値なしでAPIに渡した。報告に記載されたサーバー実装では、パラメーター値が空文字列でなければ削除待ちを検索する。値が空だったため、APIは削除待ちだけでなく全BYOIPプレフィックスを返した。タスクはその全件を削除対象とみなし、サービスバインディングなどの依存オブジェクトも消した。

Cloudflareは、攻撃や悪意によるものではないと説明している。Addressing APIのリリースは17:46 UTCに完了し、10分後にタスクが実行を開始した。技術者は18:46に問題を特定し、プロセスを停止した。この間に約1,100のプレフィックスが撤回された。Cloudflareによれば、これは世界に広告していたBYOIPプレフィックス4,306件の25%に当たる。報告には特定のピアから見える6,500件という別の数字もあるが、世界全体のBYOIP件数と混同すべきではない。

設定変更は段階的に適用されていたため、全顧客に広がる前に止められた。段階展開が障害範囲を抑えたことは評価できるが、それだけで復旧計画になるわけではない。

「広告中」と「サービス提供中」は別の状態

Cloudflareの製品資料はBGP広告とサービスバインディングを分けている。前者はプレフィックス宛ての通信をCloudflareのネットワークに引き寄せ、後者はCDN、Spectrum、Magic Transitなどの製品へ通信を割り当てる。CDNではアドレスマップがさらに関わることもある。自動処理が経路とバインディングの両方を消せば、再広告で通信が事業者のネットワークに届いても、エッジにある製品経路は復元されない可能性がある。

そのため、ダッシュボードの自己復旧策はすべての顧客に使えたわけではない。19:19 UTC、Cloudflareは顧客にプレフィックスを再広告するよう案内した。20:20ごろには約800件が復旧した。しかし約300件は、対応するサービス設定がエッジから削除されていたため、広告状態を切り替えるだけでは直らなかった。顧客の画面から、すでに存在しないバインディングを作り直すことはできない。技術者が設定を復元し、全体向け設定を配布する必要があり、それが23:03 UTCに完了した。同社が公表した障害時間は合計6時間7分だった。

公開報告は影響を受けた顧客数、地域、売上損失、SLA補償額を明らかにしていない。一方、復旧経路は異なっていた。経路だけが撤回された顧客、バインディングの一部を失った顧客、すべてのサービスバインディングを失った顧客がいた。「BYOIP障害」という同じ見出しの内側に、異なる責任者と時計があった。

one.one.one.oneのウェブサイトにはHTTP 403エラーも発生した。ただしCloudflareによると、1.1.1.1 Public ResolverのDNS解決はDNS over HTTPSを含めて影響を受けていない。サイトで見えたエラーはBYOIPを使うウェブ面の障害であり、リゾルバーが応答を止めた証拠ではない。両者を混同すれば、障害対応の切り分けを誤る。

設定もネットワークの一部

CloudflareはAddressing APIを権威あるアドレスデータセットと説明し、変更をグローバルネットワークへ反映していた。顧客の要求からデータベースとワークフローが動き、広告と製品バインディングを更新する仕組みだった。同社は、保存されたデータが顧客の設定意図と本番操作の両方を担っていたため、手動ロールバックが難しくなったと説明した。意図した状態と実際の動作を比べるより、データベースのスナップショット復元が必要だった。

テストの不足も具体的だ。ステージングや模擬データはこのケースを再現できなかった。顧客が自分で操作するAPIの流れはテストされたが、別のタスクランナーが明示的な顧客操作なしにデータを変更するケースは対象外だった。人が開始する経路が安全でも、同じAPIを使う定期タスクは危険になりうる。画面だけのテストでは、自動化の実行主体と権限がモデルから抜け落ちる。

Cloudflareが公表した対策は、パラメーター修正にとどまらない。APIスキーマの標準化、設定状態と運用状態の分離、健全性指標を確認しながら設定スナップショットを段階配布すること、異常時の自動停止・ロールバック、撤回数や速度が過大なときの遮断機構が含まれる。顧客サービスの健全性を停止信号に使う案も示された。ただし、2月の事後報告は対策の発表であって、後日の完了を証明するものではない。

BYOIPの価値は、顧客が認知されたIPアドレスを保ちながら事業者のネットワークやサービスを利用できる点にある。運用上は役割が分かれる。顧客はアドレスブロックを保有し、事業者に広告を認める一方、経路を撤回し、製品を割り当て、エッジへ設定を配布する制御面は事業者が運営する。移転可能な資産でも、所有者が自分だけでは戻せない状態に依存することがある。

これはマネージドルーティングを否定する話ではない。継続性をサービス境界で定義する必要があるということだ。Cloudflareの動的広告資料は、APIの成功応答が示すのは要求の登録であり、経路の伝播には別の時間がかかると説明している。また、本番広告の前にサービスバインディングを完成させるよう求めている。受付確認とサービス稼働は別々の証拠である。

継続性の約束に必要な検証

顧客に必要なのは、事業者がプレフィックスを広告できるかだけではない。どの状態が壊れ、誰が直す権限を持つのかが分かることだ。復旧時間は少なくとも四つに分けたい。危険なタスクの停止、外部観測点からの経路再確認、サービスバインディングとエッジ設定の復元、アプリケーション通信の成功確認である。それぞれに責任者と時間軸がある。

受け入れ試験では、経路は戻ったのにサービスバインディングが欠けている状態を作るとよい。事業者は検知できるか。全体データベースの危険な巻き戻しをせず、特定顧客だけを復元できるか。展開停止の条件に、経路本数だけでなくサービス健全性が入っているか。障害中に顧客が変更できる設定と、その凍結時間は何か。

顧客側で代替経路を用意することは計画の一部になりうるが、事業者の復旧に常に代わるわけではない。Cloudflareの運用ガイドは、重複する広告と経路選好を慎重に扱うよう注意している。代替経路が役立つのは、起点の認可、トラフィック処理、サービス動作を一緒に試験した場合だけだ。アプリケーション設定のないネットワークにパケットを集めても、障害の場所が移るだけである。

測れる結論は明快だ。アドレスは識別子、経路は到達可能性の主張、バインディングは通信先の選択、稼働中のサービスは結果である。継続性レポートがこれらを一つの緑色表示に潰すべきではない。プレフィックスの復帰は進展だった。しかし復旧の終点ではなかった。

出典