Cloudflare Tunnelの復旧時刻と、顧客の復旧時刻は同じではなかった

要約

状態ページは供給者が見ている部品を示す。利用者が必要なのは、認証を通り、私有名を解決し、経路を進み、目的のアプリケーションから正常な応答を得ることだ。この二つの観測点が同時に正常化するとは限らない。

最初の通知は複数顧客のTunnelが低下または全面停止したと述べた。構成要素は重大障害から部分障害に変わり、18時28分に特定、18時52分に修正を監視、20時44分に解消という順序をたどった。

「特定」は対処可能な問題を絞った段階であり、「監視」は修正の効果を見ている段階である。「解消」は公開案件を閉じた段階だ。どの言葉も、すべての顧客のアプリケーション試験が成功したことを意味しない。

公開記録には国、コネクター版、影響トラフィック比率、個別停止時間がない。最終原因もない。したがって、複数顧客という表現を世界的全面停止へ拡大したり、更新失敗や攻撃などの原因を推測したりしてはならない。

Cloudflare Tunnelでは、顧客環境からCloudflareへ外向き接続を張り、公開到達可能な起点を用意せずに私有資源への経路を作る。この構成は外部公開を減らす一方、コネクターの状態とCloudflare側の経路制御をアクセス経路に組み込む。

再起動が必要なら、運用担当者は単にプロセスが動いているかを見るだけでは足りない。各コネクターの接続、冗長インスタンスの配置、私有経路、名前解決、本人確認方針、代表アプリケーションの応答まで確認する必要がある。

再起動は一台ずつ行うべきだ。全コネクターを同時に止めれば、復旧作業そのものが新たな停止になる。対象、実施時刻、再接続時刻、アプリケーション試験結果を記録すれば、状態ページとは別の復旧証拠になる。

ただし、案内文から再起動が必要になった技術理由は分からない。状態破損や特定の不具合を証明する材料ではなく、中央修正後にも顧客側作業が残り得たという証拠である。

公式の障害接口には同日、西部北米のDurable Objectsエラー、イスタンブールのネットワーク性能問題、フランクフルトのHTTP 530増加も載っている。それぞれ製品、地域、時刻、説明が異なる。

CloudflareはこれらとTunnelを結び付けていない。同じ日に通知が集中すれば運用負荷を疑う理由にはなるが、時間の近さは共通原因の証明ではない。四件を世界規模の一障害として描けば、公表された境界を消してしまう。

確実に言えるのは、Tunnelには独自の私有アクセス障害、修正過程、再起動案内があったということだ。他の通知は同日の別事象として扱うべきである。

Tunnelを仮想私設網の代替として使う組織は、複数拠点から実際のログインとアプリケーション要求を行う監視を持つ必要がある。コネクターの心拍だけでは、私有名、認証、方針、最終応答のどこが壊れているか分からない。

冗長性も演習で確かめる。同じホスト、同じ出口回線、同じ配布工程を共有する二つのコネクターは同時に失われる可能性がある。重要資源には別経路を用意し、一要素を止めても利用者が到達できるか試すべきだ。

今回の資料だけでは、どの設計が影響を抑えたか比較できない。それでも、顧客自身による終端確認を供給者の表示へ全面委託できないことは明らかだ。

事後説明には、発端、影響した顧客または通信の割合、再起動が必要だった条件、検知や巻き戻しの改善が必要である。中央修正と顧客側の実復旧を分けた時刻も有用だ。

それまでは、独立性のあるコネクター、終端監視、段階再起動、アプリケーション到達を終了条件にする手順を整えられる。

20時44分に止まったのはCloudflareの公開時計である。顧客の時計は、私有アプリケーションが再び応答した時に止まる。