要約

  • Cloudflareは8月3日11時05分13秒（UTC）、インシデント7dk3g4k188kyを開設し、影響をminorと分類した。
  • 最初の告知は、ロンドンにひもづく専用IPv4 Egress IPの顧客が公共インターネットへ到達できない可能性を示した。
  • 影響対象はGatewayコンポーネントで、状態はoperationalからdegraded performanceへ変わった。
  • 11時25分29秒に問題はidentifiedとなり、Cloudflareは修正を実装中だと説明した。
  • 13時10分13秒に修正済みとして監視へ移り、13時23分03秒に解決した。
  • 原因、影響顧客数、トラフィックの分母、回避策、攻撃やデータ損失を示す情報は公開されていない。

調査中は症状の共有であり、原因の説明ではない

11時05分13秒の最初の状態はinvestigatingだった。Cloudflareは、専用IPv4の出口がロンドンにひもづく顧客という対象と、公共インターネットへ到達できない可能性という症状を示した。Gatewayも性能低下へ変更された。この時点で、利用者は自社の接続失敗を共通の事象と照合できるようになった。

一方、調査中という語は原因が分かったことを意味しない。外部サービスの停止、DNS、顧客設定、端末側の問題など、似た症状を生む他の要因はまだ排除されていない。公開告知は調査の方向を与えるが、個々のエラーを自動的にCloudflareへ帰属させるものではない。

「到達できない可能性がある」という表現も重要だ。対象群の全員が同じ時間、同じ宛先で失敗したとは書かれていない。minorという分類にも顧客数や失敗率の分母は添えられていない。

特定済みは修正の選択を示すが、成功を示さない

11時25分29秒、状態はidentifiedに変わり、修正を実装しているとの更新が出た。これは、運用者が症状の観察から対処方針へ進んだ証拠である。ただし、技術的な原因と修正内容はいずれも公開されなかった。

したがって、この段階からルーティング、設定、ソフトウェア、設備、通信事業者のいずれかを原因として選ぶことはできない。社内で原因が特定されていても、公開読者が検証できるのは「修正を実装中」という状態までだ。

実装中は完了形ではない。変更が対象へ届いたか、指標が回復したか、顧客の通信が戻ったかは別の証拠を要する。状態ページが段階を分ける価値は、この先走りを防ぐ点にある。

監視の12分50秒が提供する限定的な証拠

13時10分13秒、Cloudflareは修正を実装したとしてmonitoringへ移行した。ここで初めて、予定されていた行動が完了し、その結果を観察していることが示された。だが、監視指標、観測地点、成功率、再発判定の基準は不明である。

13時23分03秒に解決済みとなり、Gatewayはdegraded performanceからoperationalへ戻った。監視時間は12分50.210秒、公開インシデント全体は2時間17分50.246秒だった。

この時間差は、修正の実装と即時閉鎖を同一視しなかったことを示す。ただし、12分50秒を長期安定性の保証に変えることはできない。公開上の解決はCloudflareの判断であり、すべての顧客セッションが同じ秒に正常化したことの測定ではない。

専用出口の「所在地」は利用者の所在地ではない

対象はロンドンにhomedされた専用IPv4 Egress IPだった。これは出口サービスの帰属を示す。社員、アプリケーション、接続先がすべてロンドンにあるという意味ではない。世界各地の利用者が一つの地域出口へ集約される設計もあり得る。

そのため、本件をロンドン全域の障害と表現するのは過大である。全Gateway顧客、全Cloudflare製品、全専用出口が失敗したとも書かれていない。逆に、対象群が小さいから個別企業への影響も小さいとは限らない。

固定出口は、相手側の許可リストに登録するために使われる。別回線が動いても、別IPが相手に拒否されれば業務経路は復旧しない。通信経路と信頼される送信元という二つの条件がそろって初めて代替となる。

解決後も技術原因と安全性は未開示のまま

公開記録は、ソフトウェア、設定、容量、経路、施設、通信事業者のいずれも原因としていない。修正内容も明らかでない。似た症状を起こし得る層を列挙することは、テスト計画には役立つが、事後の原因認定には使えない。

攻撃、侵入、情報流出、改ざん、データ損失の記述もない。公共インターネットへ到達できないことは可用性の症状であり、それ自体からセキュリティ事象を導くことはできない。

解決は、Cloudflareが観測したGatewayの状態を正常へ戻し、記録を閉じたという証拠である。恒久対策、再発確率、顧客ごとの損失を証明するものではない。そこには別の事後報告と顧客側データが必要になる。

顧客側の復旧確認は業務結果まで追う必要がある

対象顧客は、自社ログの失敗時間を公開タイムラインと比較し、復旧した専用IPから重要な宛先を再試験できる。接続の成功だけでなく、認証、API応答、取引結果まで確認することで、経路と業務の回復を区別できる。

書き込み処理の再試行には注意が要る。応答が戻らなくても相手側で処理が完了している場合があるからだ。本件で重複処理やデータ破損が報告されたわけではない。これは結果が不明なネットワーク障害に対する一般的な照合手順である。

今後の説明で必要なのは、障害領域、対象数、修正内容、切替設計、検証方法だ。それまでは、ロンドンにひもづく専用IPv4出口の限定的なGateway障害が解決した、という範囲を越えるべきではない。

情報源