要約

  • RIPE NCCは9月8日、Kafkaのパーティションを扱う処理が起動時に異常に多い記録を処理し、タイムアウトしたと発表した。RRC24のファイルは公開されたという。
  • 先行するRRC18の問題との関連は、現在では可能性が低いと判断している。具体的な修復措置や、試験で確認した起動時の処理能力は説明されていない。

動き続けられることと、動き始められることは別である。RRC24のデータ公開停止についてRIPE NCCが示した新しい説明は、その違いを具体的な処理負荷の問題にした。平常時に追いつけるサービスでも、起動時に集中する仕事を制限時間内に終えられるとは限らない。

RIPE NCCの稼働状況ページは、9月8日16時01分、中央ヨーロッパ夏時間の更新で、起動時のKafkaパーティション処理に異常な量の記録が入り、タイムアウトしたと報告した。updatesとbviewsは公開済みとしている。前日はRRC18との共通原因を疑っていたが、新しい評価では関連の可能性は低く、ほかの収集装置への影響も予想していない。この見解の変更は重要だが、あらゆる装置の安全を実証したという意味ではない。

遅れたのは、経路の観測結果を利用者へ届けるファイルである。MRTの説明では、収集装置ごとに、ある時点の状態を示すダンプと、一定期間の変化を記録する更新ファイルを保存する。文書に記された生成間隔は、それぞれ8時間と5分だ。ファイルが遅れれば分析の材料も遅れるが、観測対象のネットワークが通信を転送できなくなったとまでは言えない。本稿では復旧後の全ファイルの完全性を検査していない。

収集装置の一覧によれば、RRC24はウルグアイのモンテビデオにあるマルチホップ型で、対象はLACNIC地域、スポンサーはLACNICだ。マルチホップの接続先は同じ交換拠点のLANに限定されない。ただし、所在地や支援関係を理由に、処理障害の責任をLACNICへ帰す根拠はない。

ここから導ける運用上の提案は、起動負荷を独立した試験対象にすることだ。発表には記録数も、制限時間の値も、処理の実装も示されていない。公開を再開させた変更も特定されていないため、Kafka製品の欠陥、BGPの停止、データ消失と断定することはできない。過去の別のRIS障害の原因も、この説明へ持ち込むべきではない。

短い状況報告に完全な技術報告を求める必要はない。RIPE NCCは原因の一端を示し、以前の仮説も修正した。サービスを利用する側に残る問いは、次の起動に対する信頼を、どの条件の試験で裏づけるのかというものだ。

現実の記述と主張のための発信を区別するLu Hengの論考を、本稿の編集原則とした。これは障害の技術的根拠ではない。運営側が報告した事実と、そこから提案する試験を区別して読む必要がある。