要約

  • RIPE NCCは11月3日15時55分39秒（CET）にLIR Portalの資源情報への断続的なアクセス問題を調査中とし、16時50分45秒に解決と記録した。この約55分は公表された対応の間隔である。
  • 17時17分の事後報告は、負荷分散器のフェイルオーバーがデータベース利用アプリケーションに影響したと説明する。古い接続の除去で当面対応し、接続プール設定と接続利用の監視を見直す方針を示した。

障害を読むとき、つい「いつ復旧したか」に目が向く。今回のRIPE NCCの報告では、もう一つ読むべき動詞がある。「切り替えた」だ。負荷分散器が別の経路へ移っても、アプリケーションには以前のデータベース接続が残った。運用チームはそれを消し、資源情報へのアクセス問題を解消した。交代したのは案内役だけで、客を乗せた車は前の道を見ていた。

公開APIの時刻は細かい。調査開始の記録は15:55:39.649、解決の記録は16:50:45.437。差は55分5.788秒だ。ただし、個々の会員がいつ何回失敗したかを示すリクエスト記録は公表されていない。したがって、この数字は利用者ごとの停止時間ではなく、公開された調査から解決までの区間を指す。

LIR Portalの資源画面は、会員がIPv4、IPv6、ASNを確かめる入口だ。RIPE NCCが10月に紹介したMy Resourcesの設計も、割り当ての階層、登録情報、利用状況、RIPE Databaseのオブジェクト、経路情報を一つの作業面で扱おうとしている。記事の木構造表示や自動チェックは当時まだ開発・会員テストの段階だった。新機能の完成を事故の日にさかのぼらせる必要はない。既存の入口から自分の資源を読めること自体が、会員の日常業務の前提だからだ。

ここで「登録簿が無事ならよい」という採点は甘い。登録情報を保管することと、権限ある会員がそこへ到達できることは連続した一つのサービスである。RIPE NCCの報告は後者の通路に起きた具体的な不一致を示した。フェイルオーバー後に接続が更新されず、手作業で古い接続を片付けた。原因となった切替の発端、影響を受けた会員数や失敗リクエスト数は公表されていない。これらの数値と次回の切替試験が出れば、規模と改善の効き目を測れる。

事後報告の宿題は二つある。接続プール設定の見直しは、経路が変わった後にアプリケーションが古い接続をどう捨てるかという挙動の問題。接続利用の監視改善は、その挙動を運用者が見抜けるかという観測の問題だ。緑色の稼働表示が先に戻り、会員の資源照会が後から戻るなら、表示は肝心な瞬間を見落とす。今回の報告は、どちらの改善についても完了日を示していない。

RIPE NCCは古い接続を除去して当日の問題を解決した。次に必要なのは、切替を実施してから会員の資源照会が成功するまでを、一本の試験として公開することだ。

RIPE NCCの一次資料