Cloudflare の障害が示した BGP 変更ステージングの説明責任

要約

Cloudflare は2022年6月21日、ネットワーク設定変更が、Multi-Colo PoP アーキテクチャを採用した19のデータセンターで停止を引き起こしたと説明している。これらの拠点はネットワーク全体の約4%にすぎなかったが、トラフィックの大きな割合を処理していた。Cloudflare は、同時に総リクエストの約半分が影響を受けた可能性がある一方、拠点ごとに利用者影響が異なったと述べている。[1]
意図された変更は、サイトローカルプレフィックス上の情報系 BGP コミュニティを標準化することだった。MCP スパインルータでは、ポリシー項目（term）の再配列により、無効プレフィックスを示す項目が、サイトローカルルートを広告する項目より先に評価されるようになった。結果として、そのルートポリシーから該当プレフィックスが撤回された。[1]
撤回の影響は外部到達性の欠落以上である。Cloudflare は、サーバーが通常どおり通信できず顧客オリジンにも到達できない状態となり、Multimog が MCP 内でリクエストを再分散できなくなったことを示す。小規模なクラスターでも大規模クラスターと同等のトラフィックを受け、過負荷に陥った。[1]
技術者は対象拠点に到達して変更を元に戻すこと自体が難航した。バックアップ手順が必要となった。復旧中は、技術者が互いのロールバック操作を上書きしてしまい、問題が断続的に再発する場面があった。最終拠点が回復するまでそれは続いた。[1]
Cloudflare の変更プロセスには、変更チケット、ドライラン、ピアレビュー、段階的なデプロイが含まれていた。制御失敗はより具体的で、初期ロールアウト段階がどの段階でも MCP 拠点を実行対象としていなかった。最初の代表ステージが到達したのは最終段階で、MCP スパインすべてに適用した時点だった。[1]
BGP コミュニティはルーティングポリシーで使うメタデータである。コミュニティ自体はエクスポートポリシーの順序が正しいことや、必要プレフィックスが引き続き広告されることを保証しない。RPKI 起点検証は、発信元 AS がプレフィックスに対して権限を持つかを扱うが、内部項目順序、カナリ選定、ロールバック手順といった事項は検証対象外である。[10][11][12][14][15][16]
したがって説明責任は運用証拠を問う必要がある。変更前後の候補設定、機械的に検証可能な必要プレフィックス集合、ルートポリシーシミュレーション、MCP 固有カナリ、commit-confirm の挙動、独立管理到達経路、権限者を限定したロールバック実行者、拠点別変更記録、外部ルート観測とルータログの突合である。
公開経路コレクタは外部から見えるアナウンス・撤回を特定するのに役立つが、すべてのプライベートなサイトローカルルートや内部ポリシー判断までは示せない。運用者レベルの記録は依然として必要である。[17][18][19]
公開レコードは悪意、過失、規制違反、影響を受けた全プレフィックス、全顧客損失、あるいは全是正策が現在も展開されているかを確定しない。これらの境界は明示されるべきである。

レビュー済みの変更でも、未検証の変更になり得る

インフラ事業者は、運用上のコントロールを「プロセスがある」という短い表現で示しがちである。変更はチケット化された。ドライランは完了した。複数の技術者がレビューを行った。ロールアウトは段階的だった。いずれの記述も真実でありながら、運用上のリスクが未検証のまま残る場合がある。

Cloudflare の2022年6月21日障害の説明は、この区別を特に明瞭に示した。変更は変更要求チケットを通過し、ドライランを経て、ピアレビューを受け、段階的導入を行った。初期段階は停止を引き起こさなかった。問題が発生したのは、障害時に到達した19拠点であり、Cloudflare が Multi-Colo PoP、すなわち MCP と呼んだアーキテクチャを使っていた。前段階では MCP 拠点を実施していなかった。最初に代表性があると見なされ、同時に全 MCP スパインへ設定が適用されたのは、最終段階であった。[1]

これは、チケットやレビュー、ドライラン、段階展開が無価値という意味ではない。各コントロールには立証すべき対象が必要だからである。チケットは権限と意図を記録する。レビューは、変更の一部表現を特定人物が確認したことを記録する。ドライランは指定モデルまたは機器状態に対してツールが計算した結果を示す。段階展開は各段階が異なる障害ドメインを代表し、次段階へ進む前に停止可能な規模である場合にのみ効果的である。

したがって説明責任の問いは「プロセスが存在したか」ではなく、「各工程が何を証明したか」である。今回の事故では、初期ロールアウトは古いアーキテクチャを使う拠点では影響を出さないことを示したが、MCP スパインで必要な広告が維持されることは示せなかった。代表性のない位置での成功は、重要な問いへの回答にならない。

このギャップは、ネットワーク設定が実行可能な運用権限であるために重要である。ルートポリシー項目は、単なる「ここを通せばよい」という説明ではない。評価順序で、ルータがどのルートを広告し、どれを控えるかが決まる。コミット済み設定は、サーバー、ピア、オリジン、運用者、回復システムの到達可能性グラフを変更する。些細なメタデータ追加と大規模停止の差は、あるポリシーブランチが別のブランチより先に評価されたかどうかで生じる。

Cloudflare の報告を「悪い設定が障害を起こした」という標語に還元すべきではない。実際の教訓はより限定的で厳密だ。変更統制はアーキテクチャ、ルート不変条件、障害ドメイン、管理アクセス、ロールバックと結び付けて初めて意味を持つ。関連性のないアーキテクチャを飛び越える段階展開は、表面上の慎重さを保ったように見えても、実際に故障する系統については証拠を作らない。

意図は情報付与だったが、実効は到達性の消失だった

Cloudflare は、広告プレフィックスの一部に対して付加情報として BGP コミュニティを標準化したと説明している。具体的には、サイトローカルプレフィックスへ情報系コミュニティを付与した。BGP コミュニティは、運用者がルートにラベルを与え、ルーティングポリシーに影響を与える属性である。標準コミュニティ仕様は、1つずつではなくクラス単位で経路決定を扱えるよう宛先をグループ化する方法を定める。Large Communities はこれを現代の運用ニーズに合わせて拡張する形式である。[1][11][12]

意図された追加変更は、サービス経路の撤回を目的としていなかった。Cloudflare は報告内の通常ルータ上で、これを単なる無害な情報追加として説明している。だが実効差は MCP スパインルータで現れた。構成差分が集約エクスポートポリシー内で項目順を並べ替え、無効プレフィックスの項目がサイトローカルルートを広告する項目より先に評価されるようになった。[1]

これは、意味論上の意図と実効挙動の差である。変更の作成者はメタデータ付与の意図を持ち、レビュー担当者はコミュニティ追加を見ているかもしれない。チケットタイトルに “standardize communities” とあってもよい。だが、どの表現もルータの制御を最終的に上書きしない。ルータは生成済みのポリシーを順次評価する。生成あるいは描画後の設定で順序が変われば、実効効果はその評価結果になる。

BGP 自体が到達性の機構を提供する。ネットワークはプレフィックスを通じて、特定ピアに「この経路は到達可能である」ことを通知する。到達できない、または引き続き広告すべきでない場合にルートは撤回される。撤回されたプレフィックスは特定経路から消え、関連アドレスがその経路からは到達不能になる可能性がある。BGP-4 仕様はこれらのアナウンスと撤回の意味論を定義するが、特定ポリシー項目に対する運用者のビジネス意図を知るものではない。[10]

この差分がもたらすのは証拠要件の再定義である。変更承認は、要求書や生成テンプレートだけでなく、ルータが評価する正確な候補設定に対して結び付くべきである。レビュー記録は次の内容を示す必要がある。

変更前後のレンダリング済みポリシーの完全比較。
影響を受ける全ての項目に対する評価順序。
受理、拒否、広告、撤回されるルート集合。
各ルート集合の由来ソース。
ポリシー実行対象となる機器ロールとアーキテクチャ。
代表的な経路入力を用いたシミュレーションまたはラボ結果。
ポリシー出力が誤る場合でも到達可能な管理・ロールバック経路。

これらの結合がないままレビューが進むと、リクエストは検証できるが、コンパイル後の実効を取り逃す。インフラの説明責任は、実行中システムが消費する設定に従う。

サイトローカルプレフィックスはサービス経路の一部だった

「サイトローカル」という語は補助的に見え、影響の薄い整備用ルートと誤認されがちだが、Cloudflare の報告では逆である。これらのプレフィックスはサーバー間通信を可能にし、顧客オリジンへの到達を維持していた。撤回によりこれらの経路が途切れ、処理経路全体に影響した。[1]

Cloudflare はこれらのプレフィックスを MCP 拠点の内部負荷分散システム Multimog と結び付けている。関連する到達性が消えると、Multimog は MCP 内サーバー間でリクエストを再配分できなくなった。サイズの異なる計算クラスターが同じトラフィック負荷を受け、より小規模なクラスターが過負荷になった。[1]

この仕組みは、プレフィックス欠落の数だけでは説明できない影響を説明する。1つのプレフィックスは多数サービスの依存を収束的に担える。そこにオリジン到達性、内部通信、あるいは負荷分散経路が載るなら、その撤回は単純な件数より大きな機能劣化を生む。エッジでトラフィックを受けながら、内部転送や整形処理に必要なルートがないため安全に処理できないという状態が起こり得る。

この事例は、運用者が経路重要度をどう分類するかの試金石となる。プレフィックス台帳は所有権や起点認証で止まってはならず、運用ロールも記録すべきである。

プレフィックスはインターネット向け、管理専用、サイトローカル、顧客オリジン向け、クラスター間向けのどれか。
誰がそれを広告しているルータとポリシーか。
どのサービスが依存しているか。
到達性を示す監視は何か。
同一のポリシーテンプレートを共有する拠点はどこか。
経路が消えても受信トラフィックが継続する場合、どの影響が出るか。
管理アクセスが同じ経路族・ポリシーを使うか。
依存を代替する別経路は何か。

この記録自体がネットワークを支配するわけではない。経路を存在させるものではない。代わりに、観測可能な期待状態の台帳を作る。運用者は台帳とルート情報ベース、転送情報ベース、外部観測、アクティブプローブ、サービス指標を照合できる。正確かつ一意で変更管理された台帳が観測動作と一致すれば、顧客が監視前に検知可能な撤回が捉えられる。

Multimog の例は、トラフィックの容量評価にもトポロジー文脈が必要であることを示す。Cloudflare は、影響を受けた MCP 拠点に異なる規模のクラスターがあると述べている。内部転送が停止すると、小規模クラスターが大規模クラスターと同等の流量を受ける。総サイト能力のダッシュボードは、実際に利用可能な能力を過大評価しうる。経路停止は、集約能力を利用可能にしていた分散制御自体を失わせた。

証拠ベースのレビューでは、各 MCP に対して、Multimog がサイトローカル到達性を失った際に外部排出をドレインできる低下モードをテストすべきである。サイトローカル到達性喪失時に小規模クラスターはアドミッション制御で自己防衛できるか。カナリーには BGP セッション健全性だけでなく、オリジン到達、クラスター間転送、管理アクセスのプローブが含まれていたか。公開報告は依存を明示するが、保護制御をすべて公開していない。

19の拠点が、分散ネットワーク内の集中を浮き彫りにした

Cloudflare は、19の MCP 拠点はネットワークの約4%でありながら、合計リクエストの約50%を停止時に影響を受けたとした。さらに、拠点ごとに影響が異なったと強調する。ある場所では Cloudflare を利用するプロパティに到達できなかったが、他の場所は通常稼働を継続していた。[1]

これらの数字は、人員・顧客・ウェブサイト・金銭損失の人数換算には変換すべきでない。ただし、重要な示唆を持つ。地理的に分散したネットワークでも、トラフィックは高容量の少数拠点に集中し得る。拠点数と、トラフィック比率、顧客依存、ピア能力、オリジン接続性は一致しない指標である。

MCP プログラムは最も混雑する拠点の回復力を高める目的で設計された。Cloudflare は追加のルーティングレイヤとスパイン接続メッシュを持つ Clos 系アーキテクチャを説明している。アーキテクチャは、保守や故障時に内部ネットワークの一部を有効・無効化することを可能にする。これらは正当な回復力向上の目的である。事故はこのアーキテクチャ自体の欠陥を証明しない。[1]

しかし、物理的に離れた拠点を同一のポリシーパスが結ぶことがある。最終ロールアウト段階で同一レンダリングルートポリシーが全 MCP スパインに到達すると、そのテンプレート自体が共通障害ドメインになる。物理分散だけで、同一コントロール依存を消せない。

これは繰り返し見られるネットワーク説明責任の形だ。複数のルータ、設備、キャリア、経路を持っていても、自動化テンプレートや認証体系、ルートポリシー、コントローラ、ロールアウト段階が共通故障を作ることがある。多重化は、故障を起こした制御表面で測定される必要がある。

MCP 展開では、有効な変更マップは次のとおりである。

次元	必要な証拠
物理拠点	各カナリーおよびロールアウト群の施設名と都市識別子
アーキテクチャ	旧世代 PoP 対 MCP、スパイン役割、ソフトウェア列、ハードウェア系統
ポリシー	各ロール向けの完全レンダリングポリシーと項目順序
経路役割	必要なサイトローカル、顧客オリジン、管理、サービスプレフィックス
トラフィック比率	ロールアウト群別の通常時リクエストと帯域シェア
管理	一次および独立アクセス経路
ロールバック	commit-confirm の状態、タイマー、所有者、拠点別結果
観測	経路、到達性、負荷分散、容量、顧客検証

この表は、低リスクの最初の段階が代表的であるという思い込みを防ぐ。カナリーは小さくなるべきだが、対象機能・アーキテクチャを必ず実行する必要がある。カナリー段階の代表拠点が過大トラフィックを担うなら、ラボミラー、影の評価、より小規模な代表ドメイン、あるいはより強い静的不変条件の整備が必要となる。

管理到達性の喪失が回復問題を変えた

Cloudflare は経路撤回により、技術者が影響拠点へ到達して設定を元に戻すことが難しくなったと述べている。バックアップ手順が用いられて制御権限を確保した。[1]

この点は分析の中核に置くべきである。ネットワーク変更は、ロールバックコマンドが存在するだけでは安全に戻せるとは限らない。復旧者は認証、デバイス到達、正しい状態の特定、同期したロールバック判断を障害時に実行しなければならない。管理トラフィック自体が変更対象の経路に依存しているなら、回復経路は同じ故障ドメインに入る。

独立アクセスは、各デバイスに別個の世界的ネットワークを用意することを必ずしも要しない。故障を想定した生存設計が必要である。選択肢には、別ルーティングされた管理ネットワーク上のコンソールサーバ、アウト・オブ・バンド回線、ローカル自動化でタイムドロールバックを実行する仕組み、commit-confirm の機能、権限保護された端末アクセス、候補ポリシーに依存しない制御チャネルなどがある。

ただし選択肢はすべて限界を持つ。アウト・オブ・バンド回線は同じ施設や電源に依存しうる。コンソールサーバが同一 ID 基盤や DNS サービスに依存しうる。commit-confirm のタイマーは早期解除や、依存状態の完全復元失敗で無効になる可能性がある。ローカル自動化は誤った基準値を適用することもある。説明責任の観点では、選んだ経路が故障条件下で実際に機能することを検証する演習が不可欠である。

今回の relevant test（実効試験）は明快である。代表的な MCP 環境で、通常のサイトローカルと管理到達を提供する経路集合を撤回・抑制し、依然として監視者が状態を確認し承認済み設定へ復帰できるかを検証する。アクセス開始時間、障害の同定時間、ロールバック開始時間、必要広告の再掲時間、サービス回復確認時間を測定すべきである。

平常日でのログイン成功スクリーンショットは十分でない。試験は障害が実際に起きた依存を除去し、再現しなければならない。運用的証拠は、単に「帯域外の経路」と図示された経路より優先される。

公開報告は、Cloudflare が使用したすべてのバックアップ手順を明示しない。これはセキュリティと運用上妥当である。敏感なトポロジーや認証情報は公開してはならない。しかし、アクセス下では監査可能な証拠を保持できる。演習タイムスタンプ、機器対象範囲、独立証明、経路プローブ、成功判定基準、例外対応が公開されるべきである。

ロールバック権限の失敗は調整統制の問題だった

Cloudflare のタイムラインは、最終ロールバックの遅延を、技術者同士の操作上書きに起因すると示す。あるロールバックが先行のロールバックを取り消し、問題が断続的に再発した。[1]

これは、単なる人為エラーではない。インシデントレスポンスにおける排他制御の欠如を示す。高インパクト障害時、複数の技術者が正当な権限を持ち、行動の必要性を持つ。変更システムに一つの権威ある望ましい状態、明確な所有者、拠点単位ロック、共通進行記録がなければ、並行作業は状態の振動を生む。

運用教訓は、必ずしも1人だけが対応すべきということではない。調査、経路観測、顧客連絡、サービス検査、ロールバック準備は並行に進められる。しかし同一ルーティング状態の変更は調整の下でなければならない。システムは、ある対応者がもう一人の対応で再導入した構成を簡単に戻せない設計が必要である。

有効な統制は次を含む。

明示されたインシデントコマンダーとネットワーク変更オーナーの指定。
回復時の凍結された望ましい状態コミット。
ロールバック中のデバイスまたはポリシー領域ロック。
試行と完了リバーとを記録する単一オーケストレータ。
管理確認を失うと自動で前状態を復元する commit-confirm タイマー。
ルートとサービス回復を変更せずに検証する読取専用監視者。
緊急時手動変更は、通常自動化へ戻る前に権威状態へ再統合する規則。
チームや地域を跨る時の明示的なハンドオフ。

これらは拠点ごとの台帳を生成する。各 MCP ごとに、悪い構成識別子、ロールバックコマンドまたは commit、実行者、開始・終了時刻、機器確認、ルートテーブル結果、管理到達性、サービスプローブ、同一ポリシーを後から触れた変更を記録する。台帳が介入の可視化を担い、最後の拠点復旧を確定的に主張できる。

Cloudflare の是正措置には、自動化した commit-confirm ロールバックと段階強制（stagger enforcement）の改善が含まれていた。[1] commit-confirm は、ルート変更で管理到達性が失われる場面で特に関連性が高い。オペレータが可用性条件と不変条件の確認後に管理を再確認し、受理されない場合、ルータは自動で前状態へ戻すことができる。

commit-confirm が万能ではない。タイムアウトは検証が終わるのに十分でありつつ、影響を長引かせないよう短く保つ必要がある。前状態自体が安全であることが前提である。確認は弱いシグナルだけで自動化してはならない。複数デバイス変更は整合的な意味論を必要とする。1台だけ旧状態へ戻ると不整合が起きる。機構には実演と証拠が依然必要である。

プロセスは存在したが、証明義務は不十分だった

Cloudflare の報告は、変更にチケット、ドライラン、段階展開、複数ピアレビューがあったと明示する。[1] これは、既に成熟した変更管理語彙を持つ組織にとって有用な事例となる。

弱い復旧報告は、さらに承認を一段増やすだけである。追加署名だけでは、欠けた条件を検証できない。証拠は4つのより強い問いへ収束する。

第一に、ドライランは何を入力としていたか。古いアーキテクチャ向けのみをレンダリングしたなら、MCP の項目順効果を検出できない。ドライランは、生成ロジックで影響を受ける全てのロールを含めるべきであり、特に異なるテンプレートや継承を持つロールを含む。

第二に、ドライランは何を検証したか。構文的に正しい設定でも必要プレフィックスを撤回する可能性がある。検証は経路出力比較を行うべきで、構文結果だけで終わるべきではない。必須のサイトローカル、管理、オリジン向け、サービス向けプレフィックスが予期せず変化するなら、ツールは失敗を返すべきである。

第三に、ロールアウト群はどのように定義されたか。地理順だけでは、早期群が古い設計のみによるならアーキテクチャ起因障害を捉えられない。群はハードウェア、ソフトウェア、トポロジー、ポリシーロール、コントロールプレーン版、トラフィック比率、管理経路を含めるべきである。

第四に、どの条件で進行を停止したか。段階展開が有効なら、明示的な観測窓と自動ゲートが必要である。次段階に進む前に、カナリーが必要な経路、オリジン到達性、内部負荷分散、管理アクセス、サービス成功を維持しているという証拠を出す必要がある。

ピアレビューにも同様の義務がある。レビュー担当者には、全ロール向けのレンダリング差分、期待経路出力、カナリ行列、ロールバック計画、回復経路の独立性証拠が必要である。高レベルのチケットから推論を求めると同じ欠落が起こる。

狙いは官僚的完璧主義ではない。プロセスを故障メカニズムに結び付けることである。BGP ポリシーでは、運用上の主張は「指定したプレフィックスが、意図した属性変更を行いながら、指定ピアへ提示され続ける」ことである。この主張は機械的に検証できる。

ルート不変条件は意図をテストへ変換する

ルート不変条件とは、変更前・変更中・変更後に必ず成立するべき命題である。例えば以下がある。

全 MCP スパインが承認済みのサイトローカルプレフィックス集合を広告する。
管理プレフィックスが指定した独立アクセス点から到達可能である。
顧客オリジン接続のプローブが各計算クラスターから成功する。
内部負荷分散が異なるサイズのクラスター間でリクエスト移動を維持する。
予期しない公開プレフィックスが広告されない。
保護対象プレフィックスが撤回されない。
変更されたルートの数と属性が承認スコープと一致する。

必要プレフィックス集合は、サービス責任とリンクした正確な運用レジストリから導くべきであり、一度きりのチケット内で書かれた非公式リストでは不十分である。プレフィックスの識別、役割、起点、想定ピア、セキュリティメタデータ、変更履歴は継続的な所有権で維持される必要がある。

コミット前に、候補ポリシーは代表的経路とピア文脈で評価できる。カナリコミット後、ルータのルート情報ベースと広告経路ビューを不変条件と突合する。アクティブプローブでサービス経路を検証し、外部コレクタは公開広告の別視点を補完する。[17][18][19]

比較は期待変更と予期外変更を分離する。変更目的がコミュニティ追加であるなら、経路存在は安定し、属性のみが承認セット内で変化するはずである。必須のサイトローカルプレフィックスが撤回されれば、即時のゲート失敗として扱い、全体 HTTP エラーを待ってから評価するべきではない。

ルート不変条件は、インシデント報告の精度も改善する。「ネットワークは回復中」と言う代わりに、何拠点で必要広告が再掲されたか、管理到達性が戻ったか、内部転送が通るか、顧客リクエスト成功率が定義範囲内かを報告できる。各主張は証拠と境界を持つ。

ただし過剰な自信には注意が必要だ。不変条件の集合自体が不完全である可能性がある。経路が存在しても実際に転送されない場合がある。制御プレーン表示はデータプレーンと異なる可能性がある。したがって、経路検査は転送およびサービスプローブと併せて行う必要がある。新たな依存が事故で示された場合、テスト群は更新されるべきである。

BGP コミュニティ単体では障害は説明できない

「BGP コミュニティが Cloudflare を壊した」という要約は不正確である。コミュニティはルートに付与されるメタデータであり、運用ではポリシー、タグ付け、トラフィックエンジニアリング、運用シグナル用途で使われる。RFC 1997 と RFC 8092 がコミュニティ形式を定義しても、Cloudflare のポリシー順序を決めるものではない。[11][12]

意図されたコミュニティ追加は変更の文脈の一部だった。障害の原因は、MCP スパインでの有効なポリシー順序と、結果としての必要プレフィックス撤回である。[1] これは、失敗した制御を修復するべきであり、標準メカニズムを烙印付けるべきではないことを示す。

コミュニティは、意味が一意に記録され、継続的に適用される場合に説明責任を高める。ルートクラス、想定扱い、保守状態、地理、顧客関係を識別できる。しかし、ラベルは、必要結果が維持される場合にのみ有効である。先頭項目が経路を拒否すると、“サイトローカル” のラベルを付けてもルートは広告されない。

同じ原則は変更名とコメントにも当てはまる。人間向けラベルはレビューを支援するが、実行されるポリシーが到達性を決定する。運用者はコミュニティ定義からルート集合、ポリシー分岐、想定広告、観測結果へ追跡できる必要がある。追跡がドキュメントで止まるなら、証拠は不完全である。

RPKI は重要だが、直接の修復ではない

RPKI は IP アドレス資源を許可された発信元 AS に結びつける仕組みを提供する。ROV（Route Origin Validation）により、ルータはアナウンスが Route Origin Authorization の AS とプレフィックス長の整合で正しいかを分類できる。RFC 6480 がアーキテクチャを、RFC 6811 が起点検証を定義する。[15][16]

これらの制御は、2022年6月障害の質問とは別だ。RPKI は Cloudflare の AS が公開プレフィックスを起点として権限を持つかを判断できるが、内部のエクスポートポリシー項目がサイトローカルプレフィックスを広告すべきか、項目順序が正しいか、MCP カナリーが代表的か、ロールバック到達性が独立かを判定しない。

認可されたルートでも誤って撤回されることがある。妥当な起点は可用性を保証しない。逆に、内部のサイトローカルルートは公開 RPKI や外部コレクタに見えないことがある。RPKI を万能の修復策として提示すると、実際の統制失敗を覆い隠す。

RPKI は依然として証拠モデルの一部である。ネットワーク資源の権威化、ポリシー動作、運用継続性は相互作用する。運用者は正確な資源台帳とセキュリティメタデータを維持し、別系統でポリシー挙動とサービス到達性を検証すべきである。登録情報の健全性と実行コード証拠は代替ではなく補完関係にある。

この境界は公開説明でも有用である。事後報告では、事故が起点認証、ルートリーク、ハイジャック、内部ポリシー撤回、他のルーティング事故のどれだったかを明確に分類できる。分類精度が、BGP 関連事象を同一視する誤りを避け、適切な修復を支える。

外部経路観測は有用だが不完全である

RIPE NCC の Routing Information Service はピアから BGP データを収集し、RIS Live は更新ストリームを公開する。CAIDA の BGPStream は複数収集点のルーティングデータの処理を支援する。これらのシステムは、参加観測点から見えるアナウンス、撤回、経路変更、復旧を把握するのに有効である。[17][18][19]

公開プレフィックス障害においては、外部観測は以下の点を答える。

対象プレフィックスがいつ、どの収集点から消えたか。
どのピアや地域が撤回を観測したか。
広告はいつ復旧したか。
復旧後に経路や属性が変化したか。
事故時系列が運用者の公開タイムラインと一致するか。

2022年6月の事後報告は、公開プレフィックスだけでなく、サイトローカル経路と内部 MCP の挙動、および内部で観測される障害体験にも関係する。公開コレクタはすべての関連ルートを見られるわけではない。プライベートポリシー項目、ルータ候補設定、管理到達性、Multimog 状態は露出しない。外部シグナルがないことは、プライベート系が健全であることの証明にならない。

この制約を根拠に外部証拠を否定してはいけない。むしろ対照確認の対象を定義する。運用者はルータログ、設定コミット、広告ルートのスナップショット、アクティブプローブ、サービス指標を保持できる。外部コレクタは独立した一層として機能する。信頼できる終結報告は、どの観測で一致し、どこで可視性が異なり、なぜかを明示する。

証拠は一貫した時刻基準で時刻管理されるべきである。ルーティング更新、構成コミット、インシデント宣言、ロールバック、到達性プローブ、顧客エラーを不一致なく並べるには、時系列整合と改ざん不能ログが必要である。これらがなければ、対応順序の判断が崩れる。

インパクト指標は独自の境界を持つ

Cloudflare は、19 MCP 拠点がネットワーク全体の約4%でありながら、障害時の合計リクエストの約50%を影響を受けたとした。また、リクエスト量グラフと送出帯域ビューを公開した。[1]

これらの数字は、高容量サイトへのトラフィック集中を示す。約半分のインターネット利用者、Cloudflare 全顧客、全ウェブサイトが完全停止したことを示すものではない。リクエスト数は母集団数を意味しない。一部拠点は通常運転を続け、顧客影響は地理とサービス経路に依存した。

適切な影響評価は次を分けて扱う。

失敗したリクエスト。
遅延または再試行されたリクエスト。
必要経路を失った拠点。
過負荷に至ったクラスター。
影響拠点から到達不能になった顧客オリジン。
無影響の拠点から継続稼働したサービス。
初回回復までの時間と最終ロールバックまでの時間。
経路復旧後の残存エラー。

公開報告はこれら次元のうちいくつかを明確にしているが、顧客別の完全なインベントリを示してはいない。記事は不必要な精密性を作ってはならない。

将来の障害では、提供者は母数と不確実性を明記すると改善される。50%リクエストが影響なら、測定区間、成功判定基準、再試行処理、地理、他拠点への流量転送を含めた条件を定義するべきだ。こうした明確な指標設計により、顧客は自社ログと比較しやすくなる。

説明責任は露出の大きさではなく制御で決まる

Cloudflare はルートポリシー、ロールアウト手順、MCP 分群、ドライラン範囲、レビュー資料、管理アクセス、自动化、ロールバック調整を統括していた。事後報告は、この障害が攻撃ではなく自社のエラーであると受け止めている。[1] この事実は、説明責任の中心は Cloudflare のネットワーク運用にあることを示す。

これは、全ての結果が法的責任に直結することを意味しない。すべての技術者が均等に過失を負うわけではない。公開記録は個人の故意や過失を確定しない。ガバナンスは責任をチームとシステムへ対応づけるべきである。

ネットワークアーキテクトが MCP ロールと障害ドメインを定義。
ポリシー所有者がエクスポート項目とコミュニティ運用を定義。
自動化所有者が設定をレンダリングし配布。
変更所有者が段階と観測窓を選定。
レビュー担当が提示証拠を評価。
インシデント司令が回復を調整。
デバイス/プラットフォームチームが rollback と commit-confirm を提供。
サービスチームがオリジン到達性、Multimog、クラスター負荷、顧客リクエストを監視。
経営陣が許容されるトラフィック集中度と変更リスクを定義。

ルータやソフトウェアベンダーは利用可能な安全機構に影響するが、Cloudflare の公開報告はこの項目順入れ替えをベンダー欠陥とは示していない。標準はプロトコルの挙動を定義するが、Cloudflare のポリシーは運用者が操作する。

顧客にも依存関係の責任がある。CDN や権威 DNS 経路へ依存する組織は、その依存関係を理解し、代替到達手段を技術的・運用的に検証し、提供者が到達不能な際の連絡方針を定義すべきである。これは Cloudflare のルータ権限を顧客へ移転することを意味せず、依存が回避不可能だと示すものでもない。

規制当局と大規模契約者は、プライベート設定を要求することなく、証拠を求めることができる。評価すべきは、アーキテクチャ代表カナリー、ルート不変条件、独立管理アクセス、逐次的ロールバック、演習結果である。契約は公開レベルでの開示と回復証拠を定義できる。

実用的なエビデンス・パック

最も強い事後報告は、同じ誤りが再発しないという保証ではない。変化した点と新しい統制がどのように機能するかを示す、境界付きの証拠パックである。

管理	保持される証拠	運用テスト	重要な制約
変更承認	チケット、承認者、範囲、リスク分類	チケットが完全なレンダリング候補設定へ紐づく	承認は経路挙動を保証しない
ポリシーレビュー	ルータロールごとの前後項目順	レビュー工具が変更対象の一致箇所と作用を特定	レビュー担当が不完全な経路モデルを見逃す可能性
必要プレフィックス不変条件	役割と所有者付きの版管理済みプレフィックス一覧	候補およびカナリ時に保護済み広告を維持	経路存在は転送成功を必ずしも保証しない
アーキテクチャカナリー	MCP ロール、ハードウェア、ソフトウェア、トラフィック・管理経路記録	カナリーが後段の方針パスを同一に実行	単一カナリーでは全 MCP を代表しない
ルートシミュレーション	代表入力経路と期待出力	予期しない撤回・広告が生じない	シミュレーションは機器挙動と異なる可能性
commit-confirm	タイマー、前状態、確認条件	管理喪失や不変条件失敗時にロールバックする	複数デバイスの整合制御は困難
独立アクセス	依存関係、トポロジー、演習記録	通常の経路喪失後にデバイスへ到達・復旧できる	電力、認証、DNS の隠れた共有が残る
ロールバック所有	インシデント所有者、ロック状態、拠点別台帳	同時進行者が回復状態を上書きできない	緊急時の手動作業が自動化を回避することがある
外部観測	RIPE RIS、BGPStream 等のコレクタ記録	公開経路変化が運用タイムラインと整合	プライベートルートや全ピアは可視化されない
サービス検証	オリジン、内部転送、クラスター負荷、リクエストプローブ	経路再掲が運用品質回復に結び付く	合成プローブは顧客固有経路を見落とす
是正持続性	デプロイ証拠と繰返し演習結果	MCP 特化ステージとロールバックが継続的に合格	1回の検証は永続準拠を証明しない

このパックは、記録と運用証明を分離する。プレフィックス台帳は一意性、所有権、役割、想定ピア、セキュリティメタデータ、変更履歴を保持するため有用であるが、パケットを通過させる権威ではない。ルートシミュレーションは挙動を予測するため有用だが、カナリと実経路観測がまだ必要である。公開事後報告は、イベント記述として価値が高いが、後続すべてのコミットが有効であることを自動で保証しない。

センシティブ情報は保護可能である。正確な管理アドレス、資格情報、トポロジー、ルータ設定は公開するとセキュリティ上のリスクを生む可能性がある。独立監査人、規制当局、契約上の顧客は機密下で確認できる。公開の説明では、制御成果、時刻、範囲、未解決の制約を要約すればよい。

比較境界が重要である

Cloudflare は他のルーティング・設定障害も経験している。これを一括して同種扱いすると分析の精度が下がる。

2022年6月の事象は外部ルートリークではなかった。

2020年7月の Cloudflare 障害はルータルール障害であり、2022年の MCP ステージング障害とは直接同一ではない。

2025年3月の事象は ROA 不備が関連しており、2022年ではルートは内部ポリシーで撤回されている。公開記録に ROA 不具合が直接原因である根拠はない。

Cloudflare の2025年機能ファイル障害も、BGP エクスポートポリシー事象ではない。

共通する抽象的教訓は、局所的な制御入力が全体到達へ拡張しうるという点だが、具体的な証拠と是正は事象ごとに異なる。ネットワーク説明責任は、実際に失敗したプロトコル、層、権限、伝播経路、回復境界を明示しなければならない。

公開記録が立証しない事項

Cloudflare の事後報告は詳細が豊富であるが、第一者の説明である。メカニズムと時系列を知る一次ソースとしては最も強い。一方で重要な情報は非公開のままである。

公開記録は、撤回されたすべてのプレフィックス、完全なルータ設定、全変更チケット本文、レビューコメント、実装コード、プライベートトポロジー、管理アクセス設計、全サービス依存を開示しない。全デバイスのルート情報ベースや転送状態の完全な可視化も示されない。

トラフィック図は、全ての影響顧客、利用者、リクエスト種別、オリジン、財務影響を特定できない。記事はサービスクレジット、損失収益、規制上の罰則、契約違反、顧客過失の主張を推定してはならない。

事後報告は事故の起点が攻撃ではなく Cloudflare のエラーであると述べるが、悪意の有無、隠蔽、違法行為、個人の過失責任までは立証していない。法律上の注意義務基準を単独で満たす根拠にもならない。

是正節で示された計画・実施は、すべての MCP 固有カナリー、ポリシー再設計、段階自動化、commit-confirm 機構が現時点で維持され効果的かどうかは自動的に示さない。現在公開されるドキュメントは設計と統制を説明できても、2022年時点の完全状態をそのまま証明しない。

RIPE RIS と BGPStream は独立したルーティング観測を提供するが、公開情報だけでは全サイトローカル撤回を各サイトで完全再構成するには不足する。外部可視性には限界がある。

これらの未知数は説明責任分析を妨げない。むしろ、証拠保有者が回答すべき質問を定義し、技術記事を根拠のない非難に変換しないための境界線を与える。

運用者、取締役会、顧客、監査側の問い

ネットワーク運用者は次を問うべきである。

アーキテクチャやルータロールでルートポリシーはどこまで異なるか。
ドライランはすべての影響ロールをレンダリングしているか。
変更後も広告を維持すべきプレフィックスはどれか。
必要プレフィックス一覧は版管理され、所有者が定義され、サービス依存に紐づけられているか。
ポリシーシミュレーションは代表経路入力と項目順を評価しているか。
最初のカナリーは小さく、かつアーキテクチャ代表として成立しているか。
進行停止を決める観測窓と自動ゲートは何か。
候補ポリシーが通常の管理経路を除去した後でも、運用者はデバイスへ到達できるか。
commit-confirm は複数デバイスの状態を一貫して復元できるか。
責任者はインシデント時の変更において誰か。
設定を変えずにルートとサービスを観測できる読み取り専用チームがいるか。

取締役会・リスク委員会は次を問うべきである。

最混雑コントロールドメインに依存するトラフィック比率はどれだけか。
地理分散が共有ポリシー/自動化依存を隠していないか。
主要管理、認証、DNS、電源、キャリア依存が復旧経路で重複していないか。
再発防止が継続演習で確認されているか。
顧客インパクト指標が経路・サービス証拠で整合されているか。

顧客は次を問うべきである。

Cloudflare の到達性、DNS、CDN、セキュリティ、アクセス、オリジン経路にどのサービスが依存しているか。
提供者とステータス情報経路が同時に障害した場合、重要通信を継続できるか。
代替事業者や直接オリジン経路は技術的・運用的に検証されているか。
迂回・フェイルオーバーにはどのセキュリティ上のトレードオフが生じるか。
顧客自身のログで普遍障害と仮定せず、実影響を確認する方法は何か。

監査人・レビュー担当は次を問うべきである。

チケットではなく、完全なレンダリングポリシーを検査したか。
カナリーは MCP トポロジーとスパインポリシーと一致したか。
サイトローカルと管理経路を不変条件に含めたか。
独立測定とルータログは一致したか。
2人の技術者が互いのロールバックを上書きできたか。
各是正主張は最新の検証結果と例外記録に紐づいているか。

これらの問いは、ゼロ障害を前提にしない。既知のルーティングエラー群がどこまで境界化、観測、回復可能かを検証する。

結論: ステージは、代表するシステムだけに意味を持つ

Cloudflare の2022年障害は、管理された変更から始まった。変更にはチケット、ドライラン、ピアレビュー、複数ステージ展開があった。それでも、まだ検証されていない MCP アーキテクチャに初めて到達した時点で、必要なサイトローカルプレフィックスが撤回された。これにより、サーバーとオリジンの到達性、内部負荷再配分、回復に必要な管理パスが失われた。並行ロールバックが発生し、障害が断続的に再発した。[1]

この事例は BGP 変更ステージングを説明責任テストへ転換した。ステージが先行したからといって、それだけで証拠にはならない。対象トポロジー、ポリシーロール、ソフトウェア、経路入力、トラフィック集中、管理依存を代表しなければならない。成功判定基準は、到達すべき経路とサービスを含まなければならない。

修復モデルは具体的である。承認はレンダリング設定と結合する。必要プレフィックスと運用役割の正確な台帳を維持する。ポリシー出力をシミュレートする。MCP 固有のカナリーを用いる。アナウンス、転送、オリジン到達、内部負荷分散、管理到達を観測する。commit-confirm と権威ある変更所有者でロールバックを保護する。プライベートルータ記録を独立の公開測定と照合する。

BGP コミュニティ、RPKI、経路コレクタ、チケット、図示は補助証拠を提供する。いずれも実行結果の代替ではない。コミュニティは経路をラベル付けし、ポリシー順序が意思決定を制御する。RPKI は起点認証を検証し、内部ポリシー整合性や可用性を示さない。コレクタは公開される観点を追加するが、すべてのプライベート依存は見えない。チケットは意図を記録するが、プレフィックスを生かすものではない。

この現実レイヤーが残る教訓である。分散ネットワークの耐性は、実行中の経路、制御ポリシー、管理アクセス、ロールバック機構が、代表的な障害条件下でサービスを維持したときに成立する。証拠はプロセス名ではなく、到達を維持した経路、停止を止めたカナリー、別者が上書きできない回復完了である。

ソース

Cloudflare, "Cloudflare outage on June 21, 2022":https://blog.cloudflare.com/cloudflare-outage-on-june-21-2022/
Cloudflare, 2022 Impact Report:https://cf-assets.www.cloudflare.com/slt3lc6tev37/fBTOgkechN3IcaoT3kbA3/c9b74ee483d28c795d3c7891d8d36034/2022_Cloudflare_Impact_Report.pdf
Cloudflare, "Cloudflare Backbone: A Fast Lane on the Busy Internet Highway":https://blog.cloudflare.com/cloudflare-backbone-internet-fast-lane/
Cloudflare, "The backbone behind Cloudflare's Connectivity Cloud":https://blog.cloudflare.com/backbone2024/
Cloudflare, "Load Balancing without Load Balancers":https://blog.cloudflare.com/cloudflares-architecture-eliminating-single-p/
Cloudflare, CDN Reference Architecture:https://developers.cloudflare.com/reference-architecture/architectures/cdn/
Cloudflare, IP addresses and anycast network:https://developers.cloudflare.com/fundamentals/concepts/cloudflare-ip-addresses/
Cloudflare, Peering Policy:https://www.cloudflare.com/peering-policy/
PeeringDB, Cloudflare network record:https://www.peeringdb.com/net/4224
IETF / RFC Editor, RFC 4271, Border Gateway Protocol 4:https://www.rfc-editor.org/rfc/rfc4271
IETF / RFC Editor, RFC 1997, BGP Communities Attribute:https://www.rfc-editor.org/rfc/rfc1997
IETF / RFC Editor, RFC 8092, BGP Large Communities Attribute:https://www.rfc-editor.org/rfc/rfc8092
IETF / RFC Editor, RFC 8326, Graceful BGP Session Shutdown:https://www.rfc-editor.org/rfc/rfc8326
IETF / RFC Editor, RFC 7454, BGP Operations and Security:https://www.rfc-editor.org/rfc/rfc7454
IETF / RFC Editor, RFC 6811, BGP Prefix Origin Validation:https://www.rfc-editor.org/rfc/rfc6811
IETF / RFC Editor, RFC 6480, RPKI Architecture:https://www.rfc-editor.org/rfc/rfc6480
RIPE NCC, RIS Live Manual:https://ris-live.ripe.net/manual/
RIPE NCC, Routing Information Service:https://www.ripe.net/analyse/internet-measurements/routing-information-service-ris/
CAIDA, BGPStream:https://bgpstream.caida.org/
Cloudflare, "What is BGP?":https://www.cloudflare.com/learning/security/glossary/what-is-bgp/

Cloudflare の 2022 年障害は BGP 変更ステージングを説明責任の試験に変えた

要約