影武者は、本番の邪魔をしてはいけない — そっくりな予備機を、母艦を止めずに最新へ保つ

控えを、一台だけ立てる

現行の団体は、同じ機種のマシンを2台並べて動かしている。1台が本番。もう1台が控えだ。ねらいはひとつ。本番の機器が壊れた日に、慌てず入れ替えて使えるようにする。切り替えは人が管理コンソールのボタンで行う。秒を争う自動フェイルオーバーではない。おかしくなったら控えに出てもらう。それで足りる運用だ。

次の10年に備えて建て始めた仮想マシンの上に、本番の複製を1台こしらえた。同じOS、同じ設定、同じ中身。片方を MAIN、もう片方を CLONE と呼ぶ。

今回の作業は CLONE を建てることのように見えて、難所はそこではなかった。建てた CLONE を、本番に負担をかけずに最新へ保ち続ける。 ここに落とし穴が並んでいた。

同じ識別子のまま、ぶつからない

最初に肝を冷やしたのは、複製が似すぎていることだった。忠実に複製すると、ネットワーク上の識別子まで本番と同じになる。同じ識別子の機械を同じ島に2台つなげば、通信は混乱する。どちらに話しかけているのか分からなくなるからだ。

両機を突き合わせて確認した。同じ識別子のまま、ぶつかっていなかった。

仮想マシンはそれぞれ自分専用の閉じたネットワークの中で動く。外へは Mac 本体が窓口になって取り次ぐ。だから2台は、互いの識別子を同じ島の上で見ることがない。複製が事故らないのは、環境が隔離しているからだった。似ていることを恐れて小細工をしなくていい。これは大きかった。

設計図はあった。実装は無かった

本丸は MAIN→CLONE の定期同期だ。手をつける前に既存の資産を眺めた。作り込まれた設計が既にあった。昇格スクリプト。監視スクリプト。構築手順書。文面はどれも「本番から控えへ、データベースをレプリケーションで流し、ファイルは常時ミラーする」。理想形を前提に書かれていた。

設計文書と、実際に動いているものは別だ。稼働状態を一つずつ突き合わせた。レプリケーションの土台となる更新履歴（binlog）は切られていた。2台は同じ内部IDを持ったままだった。常時ミラーの仕組みも入っていない。

設計図には配管が描かれている。蛇口をひねっても水は出ない。 昇格スクリプトには「同期を止めてから昇格する」と書いてある。止めるべき同期そのものが、まだ存在していなかった。

立派な設計図を実装済みと読み違えない。動いている状態を確かめずに手順書だけ信じていたら、動かない同期を「止めた」つもりになっていた。

派手な道具より、本番に触れない道具

同期をゼロから作る。まっさきに浮かぶのは教科書どおりのレプリケーションだ。だが代償が大きい。更新履歴を有効にし直す。2台に別々のIDを振る。外から接続できるよう扉を開ける。そして本番のデータベースを再起動する。

本番を止める。それだけで気が重い。

止まって、要件を裏返した。切り替えは人がボタンで行う。秒単位で追いつく必要はない。 数時間ぶんの遅れは、この運用では許容できる。だとすれば、リアルタイム性と引き換えに本番を止める取引は割に合わない。

選んだのは地味な方式だった。本番のデータを丸ごと書き出し、安全な経路で控えへ送り、控え側で復元する。添付ファイルは差分ミラーで送る。それを定期実行する。 レプリケーションの華やかさはない。だが本番のデータベースには指一本触れない。既にある堅牢な書き出し・復元の資産もそのまま活かせる。リアルタイム性がどうしても要るなら、後からレプリケーションへ昇格すればいい。

派手さより、本番を止めないことを選んだ。

二度は汲まない

方式が決まり、頻度の相談になった。利用者からの指示は的確だった。

既にある1日4回のバックアップに相乗りしてくれ。業務中に別途バックアップを走らせると、テーブルがロックされて動作が重くなる。

本番の体感を守るための現場の判断だ。

ところが、素直に同じ時刻へ並べるだけでは逆効果になるところだった。同期の仕組みは、放っておくと自分でもう一度データを書き出す。バックアップと同時刻に置けば、同じ本番から二重に汲み上げる。ロックも負荷も倍だ。相乗りのつもりが、いちばん避けたかった業務時間帯の負担増を招く。

本当の相乗りはこうだった。バックアップが既に汲んだものを、そのまま分けてもらう。 同期は自前で書き出すのをやめ、直前のバックアップが作ったファイルを流用して、送って復元するだけにする。

本番側の追加の書き出しはゼロになった。重い復元——1団体ぶんで20分超——は控え側だけで回る。本番がするのは軽い転送だけだ。この一手で、業務時間帯でも安心して同期を挟めるようになった。

正は、いつも MAIN にある

同期を常設すると、間違えやすい落とし穴がもうひとつある。どちらが正なのか。

はっきりさせた。正は、いつも MAIN。 同期は CLONE のデータを毎回まるごと置き換える。添付ファイルも余分を消してミラーする。つまりCLONE 側で加えた変更は、次の同期で消える。検証は「本番で操作し、控えでは見るだけで確かめる」向きに固定した。逆向きの誤解が、いちばん事故を生む。

ただし、控えが本番として立った瞬間だけは話が逆転する。そのために、昇格したら「もう本番だ」という印を控えに立て、同期はこの印があれば絶対に上書きしないという約束にした。MAIN の復活後にうっかり同期が走って、稼働中の控えを塗り潰す。両者が同時に正を名乗る。この一枚の印が、それを止める。

仕上げに同期を二本のロックに分けた。データベースの復元は20分以上かかる。その最中でも、ファイルの同期は1秒で別に走り抜ける。最終的な体制はこうなった。データは1日4回、ファイルは5分ごと。 片方の重い処理が、もう片方の軽い処理を待たせない。

番人が、自分を見張っていた

最後は控えを本番の姿に寄せる作業だった。検証の都合で複数団体ぶんのデータが入っていたのを、本番と同じ1団体だけに絞る。余分を落とすと大きな空きが戻り、控えは本番の忠実な写しに近づいた。

道中、自分の仕掛けに自分で足をすくわれた。

「先行する同期の完了を待ってから次を動かす」という待ち合わせの番人を仕込んだのである。ところが待てど暮らせど動かない。ログを見ると、律儀に「まだ同期が動いています」と言い続けている。何が動いているのか調べたら、番人自身だった。自分を「まだ動いている同期」と数えて、自分が終わるのを待っていたのだ。永久に終わらない。

幸い、伝播そのものは別の検証で証明済みだったので実害はない。静かに取り下げて後片付けをした。便利な自動化ほど、自分自身を勘定に入れていないかを疑うべきである。私はしばらく、番人という言葉を使うのをやめた。

こうして本番そっくりの控えが1台、MAIN の背後に並んだ。壊れた日にはコンソールのボタンひとつで表に出る。平時は、本番に指一本触れずに静かに最新へ追いついていく。

AIとの協働作業での学び

設計図と、通っている配管は別物。 立派な手順書があっても実装済みとは限らない。「止めるべき同期」がそもそも動いていないこともある。手を動かす前に、いま本当に動いているものを突き合わせる。
派手な道具に飛びつかない。 リアルタイム同期は美しいが、本番の再起動という代償を伴う。要件を裏返せば「秒単位は要らない」と分かる。制約から逆算して、本番に触れない地味な手を選ぶ。
二度汲まない。 同時刻に並べる相乗りは二重の負荷を生む。既にある成果物を流用すれば、本番の負担はゼロになり、重い処理は控え側だけで回せる。
正は一つに固定する。 どちらが本物かを曖昧にしない。片方をまるごと写す同期では、写される側の変更は必ず消える。そして昇格の瞬間だけは、印一枚で正を入れ替える。
自動化は、自分自身を勘定に入れ忘れる。 動いている処理を待つ仕組みが、自分を数えて永遠に待つ。便利な仕掛けほど、その視野に自分が入っていないかを疑う。
似すぎた複製は、環境が隔離してくれる。 恐れて小細工をする前に、なぜ大丈夫なのかを一度、実測で確かめる。