監視移設で凍結コピーを読ませない、初回状態引き継ぎの設計

移設したはずの監視が、新環境の処理として動いていませんでした。旧環境のある日付で止まったコピーにあるスクリプトを実行し、観測結果もそのコピー配下へ書き続けていたためです。

これは、旧側が動き続けて二重実行になる問題とは反対向きですが、移設完了を誤認しやすい点は同じです。先に起きた二重実行の話は旧側が動き続けて二重になる移設トラブルに記録しています。今回は「新側が動いている」ように見えながら、入力と出力が凍結コピーへ戻っていたケースでした。

対象は監視系の定期処理9本、合計約1300行です。新環境の正式な置き場へ移植し、書き込み先をメトリクス用と機器設定用の2区画を持つ単一の置き場へまとめました。設定の世代情報には秘密情報が含まれ得るため、公開領域には置かず、書き込み専用の内部置き場に制限権限で格納しています。

止まったコピーを実行時の入力にしていた

移設初期の仮設運用では、旧環境側のスケジューラが、日付の進まない旧環境コピー内の本体を実行していました。観測結果は凍結コピー配下と、別のローカル置き場へ分散していました。

凍結コピーは、移設時点の状態を保存するには役立ちます。しかし実行時に読む場所、まして継続的に書く場所として扱うと、保存物と稼働系の境界が消えます。コピーがあるから監視が動いているように見えても、そのデータの更新先は新環境自身ではありません。

段階	スクリプトと状態の扱い	運用上の意味
仮設運用	凍結コピーを実行し、観測結果もコピー側を含む複数箇所へ書く	新環境へ移したつもりでも、凍結コピーへの依存が残る
移植後	9本・約1300行を正式な置き場へ移し、書き込み先を2区画の単一置き場へ集約	新環境が実行時の状態を自分で保持する
初回起動時	凍結コピーを一度だけ読み、新環境側へ状態・世代・観測ログを書き切る	以後は凍結コピーを読まない

差分ゼロを、差分ゼロのまま渡す

監視の移設で厄介なのは、処理本体だけではありません。前回の観測値、既知の機器一覧、設定の世代といったベースラインも引き継ぐ必要があります。

ベースラインなしで監視を開始すると、本来は変化していない対象まで全件が新規に見えます。差分ゼロのはずが全部新規扱いになり、一斉に誤通知することがあります。そこで初回起動時だけ、凍結コピー側から必要な状態を読み込み、その場で新環境側へ永続化する処理を入れました。一度書き切れば、以後の実行は新環境の状態だけを使えます。

初回発火を実測できたのは9本中7本でした。NASの死活、スイッチのリンク、IPv6ルータ広告、ルーターのメトリクス、仮想化ホストの温度、仮想化基盤のアラート、ディスクを対象にした処理です。7本すべてで引き継ぎは成功し、誤通知は0件でした。

観測した項目	初回発火時の結果	引き継ぎから読めること
7本の監視処理	引き継ぎ成功、誤通知0件	起動直後に既存状態を失っていない
ディスク監視	19ノードを点検、状態遷移0件	既存の状態が新規障害として扱われなかった
ルーターのメトリクス収集	新しい置き場へ記録が到着、新規MACアドレス0件	機器一覧のベースラインが効いている

作業中には、呼び出すスクリプトの実行権限が欠けていたため、1回だけ起動に失敗しました。権限を戻すと回復しています。移設後の初回発火は、状態移行の検証であると同時に、実行権限や呼び出し経路を点検する機会でもあります。

同じ型は、外部へ書き込む別の処理にもあった

この引き継ぎは監視だけの都合ではありませんでした。同じ移設作業の中で、公開済みのショート動画にブログ導線のコメントを付ける別の日次処理にも、初回に読んだ状態を永続化する実装がありました。

ここで状態を読みっぱなしにすると、凍結コピーが消えた、または読めなくなった時点で状態が空に戻ります。その結果、すでにコメント済みの動画すべてに重複投稿しかねません。外部へ書き込む処理では、初回に状態を書き切ることが冪等性の前提になります。

監視では誤通知、コメント処理では重複投稿という違いがあります。ただし、どちらも「過去に処理した」という事実を次回へ渡せなければ壊れる点は同じです。凍結コピーを参照する必要があるのは移設の最初だけに限定し、読んだ結果をその場で自分の状態へ移す。この形にして初めて、コピーは履歴として残り、稼働系は自立します。

移設元が静かに壊れても後続処理が気づけない問題は、移した元が静かに壊れるケースでも別の角度から現れました。移設では、止まったものだけでなく、残っているコピーを何に使っているかも追う必要があります。

7本は動いた。残る2本は翌朝の記録を待つ

今回、初回発火まで確認できたのは9本中7本です。残る2本は、朝方に走るスイッチ設定バックアップとルーター設定バックアップで、執筆時点では初回発火の成否がまだ分かっていません。

同じ日に、監視系9本の移設と動画コメント付与の1本という、別々の定期処理で「凍結コピーを初回に読んだら、その場で自分のものへ書き切る」形が現れました。凍結コピーという制約に何度も当たり、同じ答えへ到達した結果でしょう。

ただし、この型が移設作業全体の標準になっているかは、まだ断言できません。残る2本が初回を迎えたときも、コピーへの依存をそこで終えられるかが次の観測点です。

移設中の定期処理を一つ選び、実行時に読む状態と書く状態がどこにあるかを並べてください。凍結コピーを読む必要があるなら、初回の直後に新しい置き場へ書き切れているかまで確認すると、移設後の誤通知や重複実行を減らせます。