要約

  • 大量のBGPメッセージがKafkaの単一パーティションに負荷をかけた。プロセス再起動後、潜在バグにより大量データの再スキャンとタイムアウトが繰り返されたとRIPE NCCは説明する。
  • 設定を修正すると処理は復旧し、10月2日以降のBVIEWと更新ファイルが生成された。再起動時のバグに対する構造的な修正は、次のスプリントで取り組む段階に残っていた。
  • 公開ファイルの復旧は、故障経路そのものの解消を意味しない。これはRIPE RISのデータ生成に関する事象であり、経路や利用者の通信が失われた証拠ではない。

ファイルが戻った時点で、修復はまだ終わっていなかった

RIPE NCCは10月6日、RRC12のMRT更新ファイルとBVIEWを生成できないとしていたインシデントを解決扱いにした。その説明には、別々に読むべき二つの状態がある。プロセス復旧後、10月2日以降のファイルは正常に生成された。直近の復旧は設定修正によるもので、潜在バグの構造的な修正は次のスプリントで進めるという。

公開アーカイブは補われた。一方、再起動のたびに処理を止めた仕組みまで構造的に直ったとは、まだ説明されていない。サービスが再開しても、エンジニアリング作業が完了していないことはある。前者を後者の証明にしてしまえば、ステータスページに書かれた範囲を超えて読むことになる。

RIPE NCCによると、発端は10月2日01:30 UTC。DE-CIXのあるピアがRRC12へ通常よりはるかに多くのBGPメッセージを送り始めた。Kafkaからデータを消費する処理系が追いつかず、プロセスがタイムアウトした。再起動後も十分に進む前に再びタイムアウトした。その後、他のRRCの更新ファイル生成にも遅れが及んでいるとRIPE NCCは報告した。

後日の説明は、障害を長引かせた要因を追加した。大量の入力がKafkaの一つのパーティションに負荷を集中させた。プロセスの再起動時には潜在バグが動き、起動時に大量のデータを再スキャンした。スキャンは何度もタイムアウトし、進行を妨げた。さらに設定上の問題で、スキャン時間は本来より一桁長くなっていたという。設定を直すと復旧したが、構造的な変更はこれからだ。

ファイルが示すもの

RRC12はフランクフルトのDE-CIXにあるRIPEのルートコレクターだ。RIPEの文書によると、BVIEWはある時点のルーティング状態を記録するスナップショットで、更新ファイルは一定区間の変化を記録する。通常の頻度はダンプが8時間ごと、更新ファイルが5分ごと。RIPEはMRTファイルをBGPの調査、事後分析、長期傾向の把握に使えると説明している。

そのため公開ファイルの遅延は、過去の時間帯を公開記録から再構成する人に影響する。ただし、それだけでルーティング障害を意味するわけではない。公開された事実が示すのはファイル生成の遅れであり、経路の消失、通信断、ピアの悪意、顧客への被害ではない。ピアの特定、メッセージ量、キューの深さ、他のコレクターの遅延時間、影響した分析数も公表されていない。

10月のRRC12アーカイブには現在、10月7日までのBVIEWと更新ファイルの名前が並んでいる。後続ファイルが公開ディレクトリに存在することを示す現在時点の確認にはなる。しかし個々のファイルが完全であること、独立した整合性チェックを通ったこと、連続したライブデータがあった場合と同じ分析結果になることまでは証明しない。

復旧には複数の完了条件がある

インシデントを一つの緑色表示にまとめるべきではない。まず入力の急増が処理を妨げなくなった。次に再起動したプロセスが進めるようになった。その後、欠けたファイルが生成された。それとは別に、故障した起動経路は構造的な作業項目として残った。それぞれ異なる運用上の主張だ。

測定サービスでアーカイブを復旧するのは、「ファイルがまた作られているか」への回答になる。しかし「追いつく処理を脆くした条件がなくなったか」や「再生成されたデータ列は完全性を確認済みか」には、それだけでは十分答えられない。公開更新は最初の問いに答え、二つ目には今後の作業があると述べる。三つ目の独立した検証記録は示していない。

これでRIPE NCCの対応が不十分だったと結論づけることはできない。公開通知の範囲が完全な事後報告より狭いだけだ。そこには引き金、一つのパーティションへの負荷、再起動時のスキャン、設定修正、今後の構造対応が書かれている。一方、ピアの識別情報、処理率、キュー指標、コレクター別の遅延時間、検証方法、修正版の識別子は載っていない。

公開された測定アーカイブを使う人に有用な終結記録は、機微な実装詳細を明かさずに論点をつなげるものだ。対象となるコレクターと時間帯、ファイル再生成の有無、実施した検証、当面の回避策、残る構造変更、その変更の確認時期を一つの記録に残せる。時系列があれば、可用性が戻った段階と信頼性修正が終わった段階を後から区別できる。

慎重に言えるのはここまでだ。負荷の急増がRRC12の再起動経路の弱点を露呈し、設定がそれを増幅した。ファイルは再生成され、RIPE NCCは構造的な対応を今後の作業として挙げた。アーカイブはインターネット全体のルーティング表ではなく、公開ファイルの停止は経路障害の証拠でもない。それでも「ファイルが戻った」と「復旧経路が直った」は、サービスが明確に区別すべき状態だ。

出典