要約

  • RIPE NCCは10月2日のRRC12ファイル生成停止を、DE-CIXの一ピアからの大量のBGPメッセージ、単一Kafkaパーティションへの負荷、再起動後の再走査タイムアウトに結び付けた。
  • ほかのコレクターの更新ファイルも遅れたという。設定修正で処理は復旧したが、潜在バグの構造的な修正は後続作業として残った。

この障害で重要なのは、RRC12の出力だけが止まったわけではないという点だ。RIPE NCCは、RRC12への入力急増による処理停止に加え、ほかのroute collectorの更新ファイル生成も遅れたと発表した。公開されたのはルーティング観測データの生成障害であり、インターネット上のパケット転送が停止したという報告ではない。

RIPE NCCのインシデント記録によると、10月2日01:30 UTCに、DE-CIXの一ピアがRRC12へ通常よりかなり多くのBGPメッセージを送信し始めた。Kafkaからデータを取り込む処理が追いつかず、プロセスはタイムアウトした。再起動後には大量データの再走査が始まり、進捗が出る前にまたタイムアウトした。さらに運営者は、コードの設定ミスにより走査に本来より一桁長い時間がかかっていたと説明した。設定を直すとプロセスは進み始めたが、潜在バグを構造的に直す作業は次のスプリントに予定された。

記録は、二つの異なる負荷を示している。入口でのメッセージ量が処理能力を上回ったこと、そして再起動による回復が重い走査を繰り返したことだ。前者は未処理の仕事を生み、後者は再起動を脱出経路にしなかった。公開記録には、ピア名、メッセージ率、パーティション構成、キュー長、タイムアウト値、走査コードは示されていない。運営者が公表した因果関係を記述することはできるが、未知の実装詳細を補うことはできない。

RISはBGPルーティング情報を集める観測サービスだ。コレクターの説明は、物理または仮想マシンがピア接続を通じてデータを受け取ると説明し、RRC12をフランクフルトのDE-CIXに置いている。MRT文書によれば、データはコレクター単位で保存される。dumpはある時点の状態を、updateファイルは一定時間内に観測された変化を表す。通常の生成間隔はdumpが8時間、updateが5分だ。これは予定されたサービス周期であり、障害時に各ファイルが完全かつ適時に利用できたことを示す証拠ではない。

10月2日09:42 CESTのステータス更新では、RRC12で最後に利用できたupdateのタイムスタンプは01:00 UTC、bviewは00:00 UTCとされた。これはその時点でのアーカイブの鮮度を示す一枚の記録だ。生成停止の正確な開始時刻でも、滞留の最大量でもない。その後、初期プロセスが復旧し、2日以降のbviewとupdateファイルを公開したとRIPE NCCは説明した。これは運営者による追いつき処理の報告であり、ファイル単位の完全性監査や利用者への影響評価ではない。

ネットワーク内の経路と、その経路の記録は区別しなければならない。RFC 6396はルーティング情報のMRTエクスポート形式を定める。MRTファイルが遅れると、その時刻のアーカイブから確認できる情報が減る。しかし、それだけでBGPセッションの切断、実際の経路撤回、利用者の到達性喪失が分かるわけではない。一方、観測ファイルが欠けることは、事後分析を行う運用者や研究者にとって重要な支障になり得る。RIPE NCCは今回の記録で下流への影響を定量化していないため、ここで想像して埋めるべきではない。

範囲が広がった理由は、単一障害の隔離に関わる。負荷はRRC12で受けた入力から生じたが、RIPE NCCは他のRRCのupdate生成も遅れたとした。説明では単一のKafkaパーティションに負荷が集中した。共有依存の存在を示唆するが、全体の処理図やデータ分割方式を確定するものではない。ここで言えるのは、運営者の説明では影響が入口のコレクターに留まらなかったことだ。複数コレクターを横断する鮮度指標と、出力間の隔離は管理上の論点になる。

事故前の作業計画は背景にはなるが、原因とは言えない。RIPE NCCの2026年第4四半期RIS計画は9月17日に更新され、事故より前に、RIS/RIPEstatデータ処理の監視改善を第4四半期の進行中作業として掲げていた。Kafkaマシンの交換と新バージョンへの更新も進行中で、資源制約により以前延期されたと記載されている。HBaseへの依存を減らす別のストレージ設計の検討も進行中だった。計画ページはこれらと10月の事故を結び付けず、復旧が計画作業によって実現したとも述べていない。

同じ計画は、関連性と多様性のあるピアを保ちながらデータ量を持続可能にする、新しいピアリング方針も示している。観測元が増えればアーカイブは豊かになるが、入力処理の負担も増える。今回の記録から、当該ピアが不要だった、問題行動をした、あるいは処理設計の責任を負うとは言えない。運営上の課題は、有益な入力を保ちつつコストを見えるようにし、ある入力の急増がほかのコレクターの出力に波及しないようにすることだ。

次に必要なのは、復旧を検証できる記録だ。遅れたファイル、予定された期間、公開が再開した時刻、滞留分に欠落や重複がないか、誰がどう確認したかを示す。負荷テストでは、試した入力規模、処理遅延の上限、滞留時の再起動動作、他コレクターに影響が出る条件を明らかにする。「解決済み」を、何が回復しどの構造的リスクが残るかという証拠につなげられる。

Heng LuのNote 70「技術と実務上の現実」は、技術信号と、そこから導ける実際上の結論を分ける視点としてのみ参照した。RIPEの技術事実を裏付ける資料ではない。事故と計画の事実はRIPE NCCの公開記録による。ここで示す信頼性要件は編集上の分析であり、未公開の内部設計についての主張ではない。

RIPE NCCは10月6日に事故を解決済みとした。設定変更によって処理が再開したことと、潜在バグを構造的に修正することは別の到達点だ。前者は当面の進捗を戻した。後者は、負荷と再起動を含むテストを通じて、次の入力急増で同じループが起きにくいと示す必要がある。公開情報はこの区別を支えるが、テスト結果はまだ示していない。

出典