要約

  • Cloudflareは8月19日06時59分（UTC）、香港で「Durable Objects」と関連製品に過負荷エラーが増えている可能性を調査し始めた。07時06分に修正を実施し、07時20分に解決済みとした。
  • コンポーネント履歴で性能低下に変わったのは「Durable Objects」だけだった。香港拠点、RealtimeKit、Realtime SFUは稼働中のままで、製品経路と拠点全体の状態が別の事実であることを示した。

香港拠点は「稼働中」のままだった。その内側で、「Durable Objects」だけが「性能低下」に変わった。さらにCloudflareは、緑表示だったRealtimeKitとRealtime SFUの利用者にも過負荷エラーが出る可能性を告知した。

公式インシデントは、8月19日06時59分19秒（UTC）に始まった。Cloudflareは香港地域の複数顧客に影響する可能性があるとして、「Durable Objects」と、それに依存するRealtimeKit、Realtime SFUの利用時に過負荷エラーが増える恐れがあると説明した。07時06分33秒には修正を実施して監視へ移行し、07時20分23秒に解決済みとした。

記録上の継続時間は約21分、影響区分は minor である。一方、根本原因、修正内容、顧客数、エラー率、対象の名前空間やオブジェクトIDは示されなかった。データ消失や通話切断の報告もない。確認できるのは地域限定の短い性能低下であり、香港全体の停止ではない。

「Durable Objects」の役割を見れば、広域コンポーネントが緑でもアプリケーションが失敗し得る理由が分かる。Cloudflareの技術文書によると、各オブジェクトは計算処理と専用のトランザクション型・強整合ストレージを組み合わせる。世界で一意の名前を持ち、複数クライアントが同じ状態を調整する一点になる。

一つのオブジェクトは一つの場所で、単一スレッドとして動く。異なるオブジェクトを多数配置して水平に拡張することはできるが、同じ状態を持つオブジェクトを、通常のステートレス要求のように任意の正常拠点へ投げ直すことはできない。その順序と整合性こそが製品の価値だからだ。

したがって、HKGが到達可能でも、特定の状態調整が過負荷エラーを返せば、その処理に依存する機能は完了しない。ステータスAPIでは「Durable Objects」が operational から degraded_performance に変わり、HKG、RealtimeKit、Realtime SFUは operational のままだった。この差は、緑表示の粒度を明確にする。

ただし「過負荷」は原因名ではない。Cloudflareのトラブルシューティング文書は、待機要求の件数、待機データ量、待ち時間、短時間に一つのオブジェクトへ集中する極端な要求など、複数のエラーを挙げている。香港の告知はどれかを特定していない。顧客の設計やトラフィックが原因だったと結論する根拠もない。

それでも利用側の防御策はある。エラー処理ガイドは、.overloaded が付いた例外を直ちに再試行しないよう求める。再試行が負荷とエラー率を上げるためだ。これは一般的な製品仕様であり、今回の全エラーに同じ属性があったという事実ではない。アプリケーションはエラー種別を識別し、待ち時間を広げるか、処理を拒否するか、限定機能へ移るかを決める必要がある。

Realtimeへの影響も同じ精度で読むべきだ。CloudflareはRealtimeKitをライブ音声・映像向けSDKとAPIの集合とし、音声・映像を転送するRealtime SFUの上に構築していると説明する。今回、会議作成、参加者状態、シグナリング、トラック管理、メディア転送のどこでエラーが出たかは非公表である。通話や録画の消失は推定できない。

利用者側で確認できる材料はある。Cloudflareのメトリクス機能は名前空間単位と要求単位の分析を提供し、オブジェクトのIDまたは名前で絞り込める。06時59分から07時20分までのエラー、遅延、対象オブジェクト、業務操作を重ねれば、広範な事象か一部の集中かを判別しやすい。

同日後刻に予定されていたHKG相互接続メンテナンスと結び付けることもできない。凍結した情報源には因果関係がない。同じ都市コードと日付は、同じ施設、回線、機器、変更作業を意味しない。

21分で復旧したことは運用上の成果である。しかし、強整合の調整点が利用できない時に何を守るかは顧客が決めなければならない。オブジェクトの分割、上限付きバックオフ、冪等処理、読み取り専用化、機能の一時停止は候補になる。それぞれが可用性と状態の意味を変える。

次に必要なのは、香港が稼働していたか否かという粗い答えではない。障害モード、影響した製品境界、修正を説明する原因分析と、同じ時間帯のオブジェクト別データである。それまでは、「Durable Objects」が約21分低下し、拠点の緑表示だけではそれを表現できなかった、という範囲を守るべきだ。

情報源