こんにちは！SREの現場を渡り歩いているクラウドアーキテクトです。日々のインフラ運用、本当にお疲れ様です！
突然ですが、みなさんは「サーバーの引っ越し」と聞いて、何を思い浮かべますか？
「夜中にメンテナンス時間を設けて、えいやっとサービスを停止し、新しいマシンにデータを移して再起動する……」そんな泥臭い作業を想像する方が多いかもしれません。
しかし、現代のクラウドの世界では、「システムを1秒も止めずに、動いている心臓部（メモリ）をまるごと別の物理サーバーへ引っ越す」という、魔法のような技術が日常茶飯事で行われています。それが「ライブマイグレーション」です。
今回は、そのライブマイグレーションの裏側を支える最もポピュラーな技術、「事前コピー方式（Pre-copy Migration）」と、引っ越しを完了させるための「反復停止の条件」について、難しい専門用語の壁をすっと取り払って、一緒に紐解いていきましょう！
—
1. ライブマイグレーションってどんな魔法？
一歩ずつ理解していきましょう！
例えば、あなたが今、超巨大なシステム手帳を持って執筆作業をしているとします。この手帳がサーバーの「メモリ（RAM）」です。
「この手帳の持ち主を、今すぐ隣のデスクの人に引き継いでほしい。ただし、執筆の手は1秒も止めてはいけない！」と言われたら、どうしますか？
普通に考えたら無理ですよね。あなたがペンを走らせている横で、他の人が手帳のページを猛スピードでコピーしようとしても、書き込んでいるそばから内容が変わってしまうからです。
この「動いている最中のデータをどうやって引っ越し先へコピーするか」という難問を解決するために生まれたのが、事前コピー方式（Pre-copy Migration）なんです。
—
2. 郵便配達に例える「事前コピー方式」の流れ
事前コピー方式の仕組みを、リアルな世界に例えてみましょう。Aさん（元のサーバー）からBさん（移行先のサーバー）へ、分厚いノートを引っ越しさせるケースを想像してください。
1. 最初のまるごとコピー（初回の全転送）
まずは、ノートの全ページを、AさんはBさんへコピーして送ります。「とりあえず、今の最新版はこれだよ！」と渡すわけです。
2. 書き換えられた部分だけの追いかけコピー（反復ステージ）
ノートをコピーして送っている間も、Aさんは執筆を続けています。当然、すでにコピーし終わったページの後から、新しい書き込み（これをコンピュータの世界では「ダーティページ」＝汚れたページ、と呼びます）が次々と生まれます。
そこで、Aさんは「さっき送った後から、ここが書き換わったよ！」という変更差分だけを、何度も何度も繰り返しBさんへ送り続けます。これが「事前コピー」の名の由来です。
3. ほんの一瞬だけペンを止める（ストップ＆コピー）
変更のスピードよりもコピーのスピードが上回り、「差分がほんのわずかになった！」というタイミングを見計らって、Aさんはほんの一瞬だけペンを止めます。そして、その残った数行の差分を一気に送り、同時に「はい、ここから先はBさん、君の番だ！」とバトンタッチを完了させます。
この「一瞬ペンを止める時間」は、人間が気づかないほどのわずかな時間（ミリ秒単位）なので、エンドユーザーから見ると「サービスが止まったことすら気づかない」という状態を作り出せるのです。
—
3. なぜ何度も繰り返すの？「反復停止の条件」の正体
ここで、ひとつの疑問が浮かびますよね。
「変更差分を何度も送るって言うけれど、もしアプリケーションがめちゃくちゃ忙しくて、ものすごい勢いでメモリを書き換え続けたらどうなるの？」
その通り！例えば、巨大なデータベースを動かしているサーバーのように、毎秒何ギガバイトものメモリが書き換わっている環境では、いつまで経っても差分がなくなりません。このままでは、いつまで経っても引っ越しが終わらない「無限ループ（終わらない片付け状態）」に陥ってしまいます。
そこで登場するのが、反復停止の条件（Stop-and-Copyのトリガー）です。
システムは、以下のような条件（閾値）を監視しています。
- 残りのダーティページ数が指定された閾値を下回ったか（例：残りが数メガバイト以下になったか）
- コピーの反復回数が上限（マックス何回まで）に達したか
- 前回の反復から転送された差分の量が、一定の割合より減らなくなったか
これらの条件のいずれかに達すると、ハイパーバイザー（仮想化の管理ソフト）は「よし、これ以上粘っても差分が減らないから、ここで強制的に仮想マシンのCPUを一時停止（Pause）させよう！」と判断します。
この瞬間こそが、反復停止の条件が満たされた瞬間であり、最後の数キロバイトの差分を送り届けて、完全な引っ越しが完了するドラマチックな瞬間なのです。
—
4. 現場で役立つ！KVM/QEMUにおけるマイグレーション設定の裏側
「なるほど、概念は分かったけれど、実際のインフラ現場ではどう設定されているの？」という方のために、Linuxの仮想化基盤として広く使われているKVM/QEMU環境を例に、実際のパラメーターを覗いてみましょう。
例えば、OpenStackなどのクラウドオーケストレーターや、直接QEMUのコマンドを叩く際、ライブマイグレーションの収束性をコントロールするための設定が存在します。
以下は、QEMUのモニター経由でマイグレーションのパラメータを確認・調整する際のイメージです。
# 現在のマイグレーション設定（ダウンタイムの目標値など）を確認するコマンド例
(qemu) info migrate_parameters
# 仮想マシンを停止（Pause）させるまでのダウンタイムの許容値をミリ秒単位で設定
# （例：許容ダウンタイムを300ミリ秒に設定し、収束を急がせる）
(qemu) migrate_set_parameter dls-time 300
# ダーティページの最大転送レート（帯域制限）を設定し、
# ネットワーク帯域がすべてマイグレーションに食いつぶされて
# 肝心のアプリ通信が死んでしまわないようにバランスを取る
(qemu) migrate_set_speed 1Gまた、近年の賢いハイパーバイザーには、メモリの書き換え頻度が高すぎるページをあらかじめ予測して効率よく送るアルゴリズムや、CPUの機能を制限してダーティページの発生スピードを意図的に抑え込む「Auto-converge（自動収束）」という素晴らしい機能も備わっています。
現場のSREとしては、「アプリの性質（バッチ処理系なのか、静的なWebサーバーなのか）」に合わせて、このネットワーク帯域や収束条件のチューニングをどう行うかが腕の見せ所になります。
—
まとめ：パケットの旅路に思いを馳せて
今回は、ライブマイグレーションの心臓部である「事前コピー方式」と「反復停止の条件」についてお話ししました。
- 事前コピー方式は、動いているノートのコピーを最初に渡し、あとから変わった部分（ダーティページ）を何度も追いかけて送るスマートな仕組み。
- 反復停止の条件は、終わりなき書き換えループにハマらないよう、見切りをつけて一瞬だけCPUを止め、バトンタッチを成功させるための安全装置。
日頃私たちが何気なく使っているクラウドサービスの裏側では、こうしたパケットたちの細やかなキャッチボールと、システムたちの賢い判断が瞬時に行われています。
「今、あのサーバーの裏でダーティページが追いかけっこをしているんだな……」なんて想像できるようになると、インフラやネットワークのトラブルシューティングも、ぐっとエキサイティングで楽しいものに変わっていきますよ！
それでは、また次回の技術解説でお会いしましょう。あなたのクラウドライフが安定した素晴らしいものになりますように！
コメント