要約

  • Cloudflareによると、8月23日01時06分から01時54分（UTC）まで、北米オリジンとシンガポールのSINデータセンター間で、一部顧客に5xxエラー増加とタイムアウトが発生した可能性がある。
  • 機械可読のステータス記録は02時00分に作成され、唯一の説明文は02時30分06秒に作成された。顧客が見るアプリの時計と、事業者が公開する説明の時計は一致していない。

今回の記録が示したのは、シンガポール拠点全体の停止ではない。Cloudflareが特定したのは、同社のシンガポールデータセンターと北米に置かれた顧客オリジンの間を通るトラフィックである。そこで48分間、一部顧客が5xx応答とタイムアウトの増加を経験した可能性があり、問題は解消したという。

時間軸は事後的に組み立てられている。本文が示す影響時間は01時06分から01時54分。一方、機械可読記録では作成、開始、解消がいずれも02時00分で、影響終了の6分後になる。症状と地理的範囲を記した唯一の更新は02時30分06秒に作られ、表示上は02時00分にひも付く。

この差だけで、Cloudflareの社内検知が遅れたとは言えない。公開資料にない内部アラートや個別通知が存在した可能性は残る。ただし、公開の説明だけを判断材料にした運用者が具体的な範囲を知るのは、申告された影響終了後だったことは確認できる。

ステータス欄の読み方にも注意が要る。上位の影響フィールドはnoneで、対象コンポーネントも製品名もない。それでも本文は、一部顧客にエラーとタイムアウトが増えた可能性を明記している。noneを「顧客影響なし」と読むことはできず、逆に本文からSIN全体やシンガポールのCloudflareサービス全体の障害を導くこともできない。

Cloudflareの一般的な接続資料は、原因ではなく境界を説明する。利用者の要求はCloudflareのグローバルネットワークに入り、anycastとBGP経路によってデータセンターへ運ばれる。そこで応答できない要求は、Cloudflareが顧客オリジンへの接続を開いて転送する。アプリの成功は、エッジ処理、Cloudflareからオリジンまでの経路、オリジン自体の三つにまたがる。

今回、公開されたのはその依存関係の地理的な両端だけだ。利用者の所在地、物理経路、BGP変更、通信事業者、ピア、海底ケーブル、社内サブシステムは分からない。「北米オリジンとシンガポール間」は観測範囲であり、実際のネットワーク図ではない。

5xxも故障箇所を一意に示さない。オリジンアプリが返す場合も、オリジン接続に失敗する場合も、中間処理で生じる場合もある。タイムアウトは期限切れを示すだけで、時間を使い切った場所は教えない。エッジとオリジンが個別に稼働していても、両者の間が正常とは限らない。

切り分けに使えるのがCf-Rayだ。Cloudflareは、この識別子をオリジンログに保存してプロキシ要求と対応させるよう案内している。ただしArgo Smart Routingや階層キャッシュを使うと、オリジンが見る3文字コードは最初の流入拠点ではなく、オリジンへ接続した拠点を表すことがある。UTC時刻、Ray ID、取得可能な流入拠点、キャッシュ状態、該当するオリジンログを組み合わせなければならない。

キャッシュの有無でも影響は変わる。エッジにある応答は北米オリジンへの往復を避けられるが、動的APIやキャッシュミスは回源経路を必要とする。ただし、影響を受けた顧客がキャッシュ、Argo、負荷分散、代替オリジンをどう設定していたかは公表されていない。一般設計を個別事象の証拠にしてはならない。

規模にも分母がない。顧客数、要求数、失敗率、トラフィック量、顧客ごとの継続時間は不明だ。「一部顧客」という表現を、軽微とも広域とも勝手に読み替えられない。

解消時刻も同じである。Cloudflareの事象記録が閉じても、再試行、キュー、セッション、オリジン負荷が同時に平常化したとは限らない。事業者の記録、エッジからオリジンまでの疎通、アプリ全体の回復は別々に確認する必要がある。

確認できる結論は限定的だ。Cloudflareは、特定の地域間オリジン経路で48分のエラー時間帯があったことを事後に公表し、解消済みとした。原因は公表していない。運用者に必要なのは、公開ランプの色ではなく、エッジ、回源経路、オリジンの各証拠を同じ時刻で突き合わせることだ。

情報源