要約

  • CloudflareはHKGデータセンターで、8月19日17時UTCから20日12時UTCまで保守を予定している。05時54分UTCの証拠固定時点では、事象は予定段階で、香港コンポーネントは稼働中だった。
  • 通常トラフィックは別拠点へ迂回する可能性がある一方、HKGに接続するPNI/CNI利用者には、現地インターフェースが一時的に使えなくなる場合に備えたフェイルオーバーが求められる。経路だけでなく余力が試される。

予備経路は、平常時に存在するだけでは十分ではない。複数の接続が同時に切り替わる瞬間に、必要な通信を受け止められるかどうかが継続性を決める。

Cloudflareの公式インシデントは、香港のHKG拠点で19時間の保守を予定している。開始は8月19日17時UTC、終了予定は20日12時UTCである。Cloudflareは、この拠点からトラフィックが迂回し、地域の利用者で遅延がわずかに増える可能性を示す。PNI/CNI利用者には、データセンター内のネットワークインターフェースが一時的に利用できなくなる可能性があるため、別拠点への切り替えを見込むよう求めている。

05時54分UTCの保守フィードでは、my45g1324mkkはscheduled、HKGコンポーネントはoperationalだった。したがって、固定した資料が示すのは準備すべき時間帯であり、障害、パケット損失、経路撤回、遅延増加がすでに起きたという事実ではない。

一般利用者向けの迂回はCloudflareの共有エッジが担う。同社のCDN参照アーキテクチャによると、Anycastは複数拠点から同じIPアドレスを広告し、BGPによって到達可能なノードへ要求を導く。ある拠点が使えなければ、別の近隣拠点が要求を受けられる。到達性は維持されても、経路が長くなれば遅延は変わり得る。

PNI/CNIには追加の制御面がある。Network Interconnectの文書は、CNIを私設のポイントツーポイントIP接続と説明する。ピアリング用途の接続は個々のPoPで成立する。HKG側のインターフェースが使えなくなれば、利用者は別の接続点またはインターネット経由の予備を持ち、自らのBGP方針で通信をそこへ移す必要がある。

ここで問題になるのがヘッドルームだ。予備BGPセッションが確立していても、必要なプレフィックスを受信していない場合がある。経路が見えてもlocal preferenceやフィルターで選ばれないことがある。選ばれても、HKGから移る通信量を収容できなければ輻輳する。さらに、主回線と予備回線が同じ装置、施設、通信事業者、物理区間を共有していれば、論理的な二重化は同一障害領域を残す。

CloudflareのCNI文書は責任分界を明確にする。提供される多様性は拠点ごとに異なる。装置レベルの多様性がある場所で別装置に終端すれば、保守中も接続を維持できる一方、単一装置構成では保守時に全面的な中断が起こり得る。CNIには代替インターネット接続が必要で、利用可能な回線全体の容量計画は顧客の責任とされる。

これは香港で問題が起きるという予測ではない。通知は施設、装置、回線、顧客、切替先を特定せず、予想通信量、代替容量、収束目標、ロールバック条件も示さない。「一時的に利用できない可能性」と「迂回する可能性」は条件付きであり、完了済みのフェイルオーバーとして扱えない。

運用者が保守前に確認できる項目は具体的だ。ポート状態、BGP隣接、受信・広告プレフィックス、フィルター、最大プレフィックス、経路優先度、トラフィックエンジニアリング、現在の使用率、ピーク時の余力を点検する。アプリケーション側でも遅延と損失の基準値を残す。第三者回線を使うなら、主系と予備系の物理的な重なりも確認する必要がある。

事象の範囲はHKG一拠点であり、Cloudflare全体の障害ではない。Anycastは共有サービスの単一拠点依存を減らす設計だ。個別のPNI/CNI、オリジン接続、香港優先のトラフィック方針は、公開ステータスの緑色だけでは評価できない。

20日12時UTC以降に「完了」となれば、Cloudflareの作業終了は確認できる。しかし余力の試験結果には、インターフェース変化、経路移動、収束時間、代替回線の使用率、基準値からの遅延・損失変化が必要だ。予備経路の価値は、切替後にどれだけ余裕を残せたかで決まる。

情報源