要約

  • RIPE NCC によると、2026年11月8日、RIS Looking Glass のデータベースが設定上の 32k ファイルディスクリプター上限に達した。内部 API が処理枠を使い切り、Looking Glass や RIS Peers など複数の RIPEstat API が利用できなくなった。
  • データベースと API は同日午後に回復したが、BGP メッセージの再生は続いた。20:06 UTC 時点で RRC25 の peer の約1割に遅れが残った。翌日05:00 UTC ごろの回復は見込みであり、本稿確認時の事故表示は Monitoring だった。

観測所を止めたのは、経路ではなく取っ手の数

経路を見せる施設の入口が、施設自身の小さな設定値に押しつぶされた。RIPE NCC の障害記録が示すのは、RIS Looking Glass 用データベースのファイルディスクリプター枯渇だ。上限は 32k。そこから Looking Glass の要求を扱う内部 API が利用可能な処理枠をすべて占有し、Looking Glass、RIS Peers ほか多数の公開 API が使えなくなった。データベース一つの制限が、複数の観測窓を閉じた。

32k は失われた経路数でも、影響を受けた peer 数でもない。プロセスが使うファイルや接続の取っ手に対する設定上限である。公開記録には、その時点の使用量の推移や上限を選んだ理由はない。ただし障害が広がった順序は明瞭だ。局所的な枯渇を内部 API の処理枠が吸収できず、利用者の問い合わせまで止めた。

最初の顧客チケットは8日00:58 UTC に届いたと RIPE NCC は述べる。最初の公開通知は12:51 UTC。差は11時間53分だが、チケットの時刻を全 API の停止開始時刻と読み替えることはできない。13:20 UTC に原因の連鎖を公表し、13:39 UTC にはデータベースが回復、API の処理量は通常に近いと報告した。ここまでなら復旧の話は一行で終わる。

窓口が開いても、窓から見える時刻は戻らない

実際にはもう一つの時計が残った。13:39 UTC の更新は、Looking Glass のデータベースが過去数時間の BGP メッセージを再生中で、データが遅れると明記した。Looking Glass の公式説明は、このサービスをほぼリアルタイムの RIS 観測と位置づけ、収集機と peer ごとの情報、latest_time を返す。HTTP 応答の速さと、応答が表す経路観測の新しさは別の指標だ。

20:06 UTC の更新では、RRC25 の peer のおよそ10分の1に遅れが残り、メッセージ量が理由とされた。翌日05:00 UTC ごろまでに回復するというのは予測で、完了報告ではない。RIS Peers の資料も収集機単位で情報を示し、履歴の基準時刻を 00:00、08:00、16:00 UTC にそろえる。復旧の確認単位は「API が緑色か」だけでなく、どの収集機のどの peer がいつの情報を返すかである。

障害が起きたのは RIPE NCC の経路観測サービスであり、その後に観測データの遅れが残った。8日に先に直ったのは質問に答える仕組みであり、答えの時刻はまだ追いかけていた。