要約

  • RIPE NCCの2026年第3四半期RIS計画は、RIS/RIPEstatデータを借用ベアメタルへ移す作業を終えたと記す。同じ項目で、データ処理の監視改善、技術的負債の整理、HBase依存を減らす代替ストレージの調査は進行中とされる。
  • Kafkaマシンの交換と新バージョンへの更新は別項目で、資源不足により延期された後も進行中だ。これはデータ移行の失敗や障害を示すものではない。
  • RIPEstatの過去計画は、移行によりバックエンドとの間に追加遅延が生じ、並列クエリなどの方法を検討し、影響を注意深く監視したと説明する。数値やサービス目標違反は公表されていない。
  • データ範囲、収集・輸送・処理・保存の世代、切替期間、再生・補完、MRT、RIS Live、RIPEstat別の検査、既知の例外、責任者、観察期間を束ねる「構成要素別移行受領記録」が必要だ。

完了したのは何か

RISの四半期計画は、よく読むほど慎重に書かれている。RIPE NCCが「完了」としたのは、RIS/RIPEstatデータの借用ベアメタルへの移行である。続く文では、その後の作業としてデータ処理の監視改善と技術的負債の整理を挙げる。さらにHBaseへの依存を減らすため、代替ストレージ構成を調査している。この項目自体の状態は進行中だ。

次の項目はKafkaである。Kafkaマシンを交換し、より新しいバージョンへ更新する。資源上の制約で延期された作業であり、こちらも進行中と表示されている。

ここから「移行は未完了だった」と読むのは正しくない。データの移動後に通常負荷を監視すること、別の機器更新を別予算で行うこと、次の保存方式を検討することは両立する。公開資料には、データ消失、破損、停止、切替失敗を示す記述はない。

しかし、「RIS全体の更新が完了した」と広げるのも正しくない。データ移動の受入れは、Kafka機器の受入れでも、すべての処理ジョブの検証でも、利用者向け出力の保証でもない。完了という判断を守るには、その対象を証拠と一緒に固定しなければならない。

RISの価値は来歴にある

Routing Information Serviceでは、参加ネットワークが世界各地のRemote Route CollectorとBGPセッションを張る。RRCは多くの場合IXPに置かれ、参加者から更新とwithdrawを受け取る。RIPE NCCはそのデータを保存・公開し、運用者や研究者が経路の挙動を調べられるようにする。

同じ「データ」でも、責任の境界は複数ある。参加者はどの視点を渡すかを決める。RRCは受信したメッセージを記録する。輸送層が処理へ運び、処理がファイルや検索可能な形に変え、保存層が世代を保持する。公開側にはアーカイブ、ストリーム、クエリがある。

この連鎖を通過した観測は、どの世代で作られたかが分かって初めて再検証できる。切替期間をまたいだデータは旧保存先、新保存先、再生キュー、あるいは混在期間のどれに由来するのか。公開日時とBGP観測時刻は同じ意味なのか。変換処理の版は何か。いまサービスが正常でも、失われた当時の来歴は復元できない。

移行受領記録は、稼働率の表ではない。観測がどの製造経路を通ったかを後から説明するための、限定された台帳である。

RIPEstatは別の受入れ点を示した

RIPEstatのアーカイブ計画によると、RIPEstatに関係する大規模データを借用ベアメタルへ移したことで、RIPEstatとバックエンドシステムの間に追加の遅延が生じた。チームは移行を支援し、並列クエリを含む遅延を見えにくくする方法を検討し、RIPEstatへの影響を注意深く監視した。この支援項目は2026年第3四半期に完了している。

資料は遅延の大きさを示していない。どのクエリが対象だったか、目標を超えたか、並列化が全面採用されたかも分からない。したがって障害や品質違反を主張する根拠にはならない。

重要なのは、保存先の移行が完了しても、クエリ利用者には独立した観測点があることだ。バックエンドが応答したという事実だけでは、末尾遅延やクエリ種別ごとの差を表せない。移行の検証には、データ層の整合と利用者側の分布の双方が必要になる。

公開可能な記録なら、個別利用者の要求を出さずに作れる。対象クエリ群、切替前後の期間、中央値と上位パーセンタイル、適用された緩和策、観察終了条件を記せばよい。

MRTの時刻表とRIS Liveの現在

MRTの文書は、外部から検査できる単位を示している。RISはRRCごとにファイルを保存する。bviewはある時点のルーティング状態、updateファイルは一定区間の変化を表す。現在の説明では、dumpは8時間ごと、updateは5分ごとに作成される。

この時刻表から、RRCと期間ごとの期待スロットを作れる。ただし期待名のファイルが存在するだけで、内容、処理世代、すべてのRRC、別サービスまで検証したことにはならない。ファイルの大きさやハッシュ、限定した内容比較、欠落、例外、再生・補完の有無を結びつける必要がある。

一方のRIS Liveは、ほぼリアルタイムのBGPメッセージを扱うストリームだ。いま新しいメッセージが流れていることは、過去のMRTアーカイブが完全であることを証明しない。MRTの各スロットが見えても、RIPEstatのクエリ遅延を測ったことにはならない。

確認した公開資料は、MRT、RIS Live、RIPEstatが同じ内部経路を共有するとまでは述べていない。したがって一つの緑色ランプを三つにコピーしてはいけない。MRTはRRC別の区間、RIS Liveはストリーム固有の鮮度、RIPEstatはクエリ種別と分布で検査する。その後に結果を関連づける。

過去の変更が残した教訓

RISの過去計画には、2023年に公開MRT dump生成パイプラインを交換し、遅延を大きく減らすとともにファイル構造を一部変更したとある。旧世代と新世代のファイルがどちらも妥当でも、同じ製造経路とは限らない。

2025年の記録では、削除済みの一つのIPv6 peerのデータがdatasetに残り続けた不整合を解決したと説明する。その事象と他の小さなartifactを公開文書にする作業は延期された。ここで延期されたのは文書化であり、不整合は解決済みとされている。現在も同じ問題が続くとは書けない。

外部向けKafka配信とRIS Liveのオープンソース化も過去に計画されたが、戦略見直しの中で優先度が下げられた。過去の公開Kafka試験と、現在交換中のKafkaマシンが同じ境界を指すという証拠はない。来歴には、関係が成立する箇所だけでなく、成立しない箇所も必要だ。

受領記録に必要な順序

最初に範囲を記す。対象dataset、RRC、時間範囲、利用者向けsurface、明示的な除外を並べる。「RISデータ」だけでは広すぎる。

次に世代を記す。対象となる収集・輸送・処理・保存の識別子を結ぶ。Kafkaが通らない経路なら「非適用」とし、無理に全体図へ組み込まない。HBase代替案は調査段階であり、選択済みの構成として書かない。

切替は一つの日時に潰さない。旧データ抽出、新環境への初期投入、並行観察、読書きの切替、旧環境停止は別の判断だ。RIPE 88の技術更新記録は、より広いデータ基盤の歴史的な説明の中で、抽出、クラスタ構築、新規データ投入、将来の本番切替、旧環境廃止を分けている。これは手順の参考であり、現在のRIS構成図ではない。

受入れ試験では、切替前後の等価なRRC・期間を選び、5分updateと8時間dumpを確認する。RIS Liveの鮮度は別に測り、RIPEstatはクエリ群ごとの遅延分布を見る。許容差、再生・補完の状態、既知artifact、観察期間、各判断の責任者を残す。

公開記録に内部ホスト名、資格情報、IPアドレス、raw logは不要だ。時間範囲、build識別子、hash、件数、パーセンタイル、例外状態で十分である。

この記録は移行完了を取り消すためのものではない。データ移行を明確に閉じ、Kafka、処理監視、保存方式、RIPEstatを別の工程として正しく開いておく。完了が一つの対象だけを意味するとき、その判断は最も強くなる。

情報源