要約

  • Statuspageのインシデント記録によると、2026年8月18日、エリア指定がworldwide以外の測定でプローブ割り当てに問題が発生した。
  • 内部バックエンドの修正は13時30分ごろCESTに展開された。16時45分の解決判定まで再発は見られず、RIPE NCCは追加監視に取り組むとした。
  • 公開記録には影響測定のIDや件数、要求プローブ数と実際の割り当て数の照合がない。データ消失を示すものではなく、プライバシーを守る影響台帳が必要だという限定的な指摘である。

観測対象ではなく観測の入口で起きた

分散測定では、ユーザーが見たいネットワークと、実際に観測を行うプローブ集合の間に選択処理がある。対象、測定方式、開始時刻を決めても、希望した地域のプローブが仕事を受け取らなければ、結果の地理的な形は変わる。

最初の告知は12時27分CESTだった。問題は、worldwide以外のエリア選択を使う測定へのプローブ割り当てと説明された。原因は特定済みで、修正中だという。これはAtlas全体の停止を意味しない。ルーティング、公開レジストリ、RPKI、DNSの障害を示すものでもない。公表された境界は、スケジューラの一つの条件分岐である。

IsDownの保存記録でも、13時30分ごろに内部バックエンドの修正を展開し、その後は現象が再び出なかったため16時45分に解決とした流れが確認できる。最初の公表から解決まで約4時間18分。ただし、これは障害そのものの発生時間ではない。技術的な開始時刻は公表されていない。

サービス運用の説明としては具体的だ。影響条件、修正箇所、解決判断が一つの線になる。残る問題は、その線に測定オブジェクトが結び付いていないことだ。

緑になったサービスと、終わった測定は同じではない

運用チームにとって「修正後に再発していない」は妥当な終了条件になり得る。利用者にとっては、自分の測定が要求どおりのプローブを得たか、保留分が再投入されたか、再作成が必要だったかが終了条件になる。

公開インシデントには、影響を受けた測定IDも総数もない。worldwide以外のどのエリア値が対象だったか、検知時・修正時・終了時の要求数と割り当て数がどう変わったかも分からない。再試行、失敗、取消、保留の件数、結果欠落を調べたかどうか、ユーザー操作が必要かどうかも記載されていない。

ここから内部ログの欠如を推測してはならない。非公開測定の所有者が別途通知を受けた可能性も、全件が自動的に整合した可能性もある。公開面から言えるのは、これらの状態を第三者が確かめられないという一点だけだ。

ユーザー側の単位はすでに整っている。RIPE Atlas開発者が保守しRead the Docsで公開するCousteauの利用文書では、エリア型のソースは値と要求プローブ数で構成され、世界全体の例にはWWを使う。作成後には測定IDが返り、メタデータも取得できる。したがって、公開台帳は私有バックエンドの構造を明かさず、既存の利用者向け単位で作れる。

少ない結果はネットワークの事実とは限らない

ある地域からの到達性を調べて、期待した地点の一部から結果が返らなかったとする。対象ネットワークに障害があるかもしれない。プローブが切断中かもしれない。割り当てが完了していないかもしれない。結果ファイルだけを見ても、この三つは自動的には分離されない。

Atlasの規模は、この区別を小さくしない。2025年の一次研究は、代表的な1日に50,885件の測定と13億件超の結果を分析した。要求されたプローブと実際に参加したプローブが、未接続など通常の事情でも一致しないことを示している。この数値を今回の影響件数に転用することはできない。重要なのは、観測元の来歴も測定品質の一部だという点である。

欠測を扱った2017年の研究も、欠けたデータ点とプローブ接続イベントの関係を調べた。今回のスケジューラ障害による欠測を証明する資料ではない。ただし、空白を直ちにインターネット側の現象とみなさない、という分析上の注意は今も有効だ。

インシデント時間帯に狭いエリアで障害調査をした技術者は、得られた結果を捨てる必要はない。その代わり、期待したプローブ集合が完成したかを確認できるまで、測定基盤由来の偏りを一つの仮説として残す必要がある。

非公開測定を隠したまま照合する

必要なのは長大な障害報告ではない。安定したインシデントIDと公開観測窓、影響した選択条件、確認した作成・変更要求の件数、公開測定ID、非公開測定の総数と秘匿化した集合指紋、検知・修正・終了時の要求／割り当てプローブ数、完了・再試行・失敗・取消・保留の内訳、結果欠落の評価、ユーザー操作、追加監視の条件と閾値、公開責任者と訂正履歴があればよい。

非公開のターゲット、APIキー、所有者、定義内容を開示する必要はない。公開測定はIDで再現性を確保し、非公開分は件数とソルト付き指紋で「同じ集合を確認した」ことだけを固定できる。結果の連続性を調べていないなら、「未評価」と明記する方が沈黙より正確だ。

追加監視を作るという表明は前向きである。さらに、何を一件として数え、どの閾値で異常とし、どのスケジューリング状態を検査し、どれだけ再発がなければ終了とするのかを公開すれば、将来の緑表示にも再現可能な根拠が加わる。

実行状態を履歴へ変換する

Lu HengはRunning-Code Primacy: The Patch Needed to Preserve the Internet's Original Designで、制度上の説明を実際の稼働状態で検証する考え方を示す。本件への適用は限定的だ。ステータスページを否定するのではなく、その最終状態を処理対象の記録で支える。

RIPE NCCは測定消失を発表しておらず、本稿もそれを主張しない。確認できるのは、修正の展開、終了まで再発がなかったこと、監視強化の予定である。影響件数、結果誤り、終了後の再発は確認できない。

サービスとしての終点はある。証拠としての終点がまだない。両者を同じ場所に置くのが、測定影響台帳の役割だ。

出典

  • Statuspageが配信するRIPE NCCインシデント記録、Issue with scheduling some RIPE Atlas measurements
  • IsDown、RIPE Atlasスケジューリング障害のミラー
  • RIPE Atlas Cousteau、Use & Examples
  • Nosykほか、Day in the Life of RIPE Atlas: Operational Insights and Applications in Network Measurements
  • Shaoほか、Missing measurements on RIPE Atlas
  • Lu Heng、Running-Code Primacy: The Patch Needed to Preserve the Internet's Original Design