要約

  • RIPE データベースの更新メッセージは、含まれるすべてのオブジェクトが一括で成功または取り消しになることを意味しない。全体の FAILED と個別の成功は両立する。
  • HTTP 接続が切れても、サーバー側の処理が止まるとは限らない。応答がない状態は、変更なしという判定ではなく、依頼側から結果を確認できていない状態である。
  • 通知には宛先ごとの範囲がある。既存の個別結果と権限内の照会を突き合わせ、再試行の対象を選ぶことが、情報を失わない復旧の出発点になる。

引き継ぎに残った一語

ある担当者が「更新失敗」とだけ記録を残し、次の担当者が同じ内容を送り直そうとする。仮にそんな引き継ぎがあったとして、後任は何を知っているだろうか。目的が全部は達成されなかったことは分かるかもしれない。しかし、どのデータが今も以前のままかまでは分からない。

RIPE データベースでは、この違いを文書から具体的に読み取れる。処理結果の応答を説明するページには、認識された五つのオブジェクトについて、四件の成功と一件の失敗を示す集計例がある。成功の内訳は新規作成一件、変更二件、変更を伴わない NOOP 一件。失敗は変更一件だ。

つまり、実際に内容を変える成功は三件である。四件という成功数を変更数だと思えば、一件分を読み違える。一件の失敗だけを見て何も変わらなかったと思えば、今度は三件の変更を見落とす。NOOP は、送ったオブジェクトが保存済みの内容と同じだったため、変える必要がなかったという成功だ。

これは公式文書の説明用の例であり、取材で確認した事故ではない。同じページは、メール形式の全体結果では一件でもエラーがあれば FAILED になると説明している。ただし、ページ内の別々の件名例と集計例をつなぎ合わせて、実際に捕捉した一通の応答として扱うこともできない。ここで確認できるのは、全体の判定と個々の処理結果が異なる単位を見ている、という仕組みである。

一緒に送ることと、一緒に取り消すこと

オブジェクト処理の説明によれば、処理は個別に行われる。一つが失敗しても、後続の処理が自動的に全部止まるわけではない。利用者が一つのメッセージにまとめたという事実から、全件成功か全件取り消しかの二択を導くことはできない。

個別処理は、依存関係がないという意味でもない。先に必要となるオブジェクトが作成できなければ、それを参照する後の処理が参照整合性の検査で失敗し得る。AUTO-n に関わる処理では順序が変わる場合もある。提出順に機械的に進むだけ、と説明するのも正確ではない。

仮に、組織がいくつかの関連レコードを変更しようとし、前提となる一件の作成は拒否された一方、それとは無関係の変更が成功したとする。組織の作業全体は未完了だが、データベースの状態は一部変わっている。次に必要なのは、元の依頼を丸ごと繰り返すこととは限らない。前提を直す必要があるのか、依存した処理を見直すべきか、既に目的を満たしたものを残すべきかを分ける作業だ。この場面は説明のための想定であり、特定の運用者の被害を示すものではない。

ここには独立処理を支持する理由もある。形式の誤った一件や権限不足の一件のために、関係のない適切な保守まで必ず止めるのが最善とは限らない。オブジェクトごとの認証・認可や整合性確認は、まとめて送信したから不要になるものではない。望んだ状態が既に存在するなら、NOOP で終わることにも合理性がある。

問題は、この設計を使う側が別の設計だと思い込むことだ。個別に処理されるものを、利用者向け画面だけで「一つの成否」に押し込めると、再開に必要な情報が見えなくなる。RIPE NCC の応答には、失敗した処理、成功した処理、認識できなかった段落を分けて示す仕組みがある。まず必要なのは新たな中央承認機関ではなく、既に返される区別を失わないことである。

通信が終わっても、処理が終わるとは限らない

通信の状態を加えると、判断にはもう一つの軸が必要になる。Syncupdates については、HTTP 200 が返っていても、オブジェクトのエラーを含む処理結果である場合が文書に説明されている。通信側の番号だけで個々の更新の成功を確定できない。これは Syncupdates の記載に基づく話であり、RIPE NCC のあらゆる HTTP 接続先についての一般則ではない。

逆に、応答が届かなかった場合も注意が要る。Syncupdates の説明と処理文書は、HTTP 接続が閉じても、サーバー側の処理は完了まで進み得ることを示している。閉じた接続には処理結果を返せないが、返せないことと、処理をやめたことは同じではない。

ここでいう完了も、全部の更新が受け入れられたという意味ではない。それぞれの処理を評価し終えることであり、その中に失敗が含まれる可能性がある。依頼した側は、成功とも失敗とも確定できない状態に置かれる。タイムアウトを通常の拒否と同じ欄に入れると、この違いが消える。

接続を別方式に替えれば、自動的に一括更新の保証が得られるわけでもない。Syncupdates は複数オブジェクトを一通に含められる一方、REST APIはオブジェクト単位の操作と XML・JSON の応答モデルを持つ。しかし、複数の REST リクエストが一つの原子的な処理になるとは書かれていない。リクエストの単位を小さくしても、組織が複数の変更を一つの目的として管理する仕事は残る。

通知を受けた人の範囲

第三者への通知も、全体結果の代わりにはならない。通知メッセージの文書では、宛先は各オブジェクトの属性や参照関係から決まる。受信者によって届く対象の集合が違うため、一人の受信箱が作業全体を映しているとは限らない。

変更時の notify の宛先には、変更前のオブジェクトにあったアドレスが使われる。他の属性や参照から追加の宛先が生じることもあるので、新しいアドレスにはどんな経路でも絶対に届かない、と言い切るのも誤りだ。通常の変更成功に関する通知と、認証の失敗に関わる upd-to の通知も、同じ理由で送られるものではない。

ある一件の通知を受け取ったことは、残る全部が成功した証明にはならない。ある宛先に届かなかったことも、何も変わっていない証明にはならない。本稿でメール配送を測定したわけではない。確認しているのは、通知の設計上の範囲と、利用者が知りたい作業全体の範囲が一致しない場合があることだけだ。

確認できたものと、まだ分からないもの

再実行の前に作れる最小限の整理は、意図した対象ごとの結果である。変更が確認できたもの、明示的に拒否されたもの、同一内容で変更不要だったもの、結果が未確認のものを分ける。後から担当者が替わっても、なぜ次の操作を選んだのかが分かるよう、元の応答と実行時刻、使ったインターフェースを保管する。これは文書から導く運用上の提案であり、RIPE NCC が新しい様式を義務付けたという話ではない。

権限のある照会は判断を補える。ただし REST の文書は、更新への応答と、その後の検索・照会で変更が見える時点を区別している。直後の読み取りが古い内容だったというだけでは、更新が取り消された証拠にならない。特定の待ち時間を本稿で測った事実はなく、何秒待てば必ず分かると約束することも、短い間隔で繰り返し問い合わせることを勧めることもできない。

事前の dry-run は、構文、業務ルール、認可、参照整合性を、データを書き換えずに確認する手段になる。処理結果の応答は返るが、通常の変更通知は送られない。これは有用な検証であって、将来の状態を予約する仕組みではない。後の本番更新が同じ結果になることや、一連の更新が全件まとめて確定することの保証にはならない。本稿のために RIPE データベースへ dry-run を送信してはいない。

履歴照会では以前のオブジェクトの版を確認できる一方、過去の個人データは提供されない。この制限は、RIPE NCC の内部に記録がない証明ではない。復旧のためという理由で個人の連絡先や認証情報を広く複製してよいという意味でもない。照合に必要な記録と、誰にでも見せる記録を分ける必要がある。

もちろん、再試行を一律に危険視するのも行き過ぎだ。内容が変わらず、権限も有効で、既に同じ状態にあるオブジェクトなら、再送が変更なしで終わる場合はある。避けるべきなのは、その性質を結果不明の集合全体に広げることだ。「失敗」の一語は調査を始める理由にはなる。全件をやり直す理由を、それだけで完成させることはできない。

出典

  1. RIPE NCC — 処理結果の応答
  2. RIPE NCC — オブジェクトの処理
  3. RIPE NCC — Syncupdates
  4. RIPE NCC — 通知メッセージ
  5. RIPE NCC — RIPE データベース REST API
  6. RIPE NCC — 変更を適用しない検証
  7. RIPE NCC — 過去のデータ