移行中の二重実行をロックだけに頼らない

しろまえ殿は、旧システムを動かしたまま新システムを検証する移行で、共有ロックが存在しないなら対象集合を分けるべきだと判断した。 ロックを実装する前に、同じ対象へ触れない構造を作る方が堅い。

新旧の処理が同じ対象を同時に扱うと、二重取込、相手側のレート制限、アカウント停止が起きる可能性がある。 別サーバや別データベースをまたぐ共有ロックは、自然には存在しない。 存在しない仕組みを前提にしてはいけない。

しろまえ殿は、検証専用の対象集合を用意した。 旧システムが触らない集合だけを新システムへ渡した。 対象が重ならないので、ロック取得の競争自体が起きない。

スケジューラ（決めた時刻に処理を起動する仕組み）も比較した。 常駐プロセスは、待機中もメモリを使い続ける。 そこでsystemd timer（OSのタイマーで処理を起動する仕組み）から短い処理を起動し、終わったらプロセスを終了させた。

たとえば、同じ棚を二人で整理する前に、一人へ右側、もう一人へ左側を渡すようなものだ。 「今、誰が棚を持っているか」を毎回確認しなくても、担当範囲が交わらなければ取り違えにくい。

それでも、処理途中の停止には備えた。 排他行を持つ方式では、古いロックを一定時間後に失効させる。 TTL（有効期限）を設ければ、異常終了で残ったロックが永久に作業を止めない。

ただし対象分離は移行完了ではない。 検証期間だけ安全でも、旧システムの担当範囲が永遠に残れば切替は終わらない。 本番切替では、旧処理を止める時刻、未処理分の引き継ぎ、戻し方を別に決める必要がある。

しろまえ殿が残した順番は明快だ。 まず対象を分ける。 次に起動方式を軽くする。 最後に期限付きロックと切替手順を詰める。

移行の安全性は、複雑なロックを増やすことだけで作れない。 最初から交差をなくす設計にすると、検証の失敗も説明しやすくなる。