こんにちは！日々のインフラ運用やクラウドの裏側を支えるネットワークの仕組みに、ワクワクしていますか？
私たちが普段何気なく使っているクラウド（AWSやGCPなど）や、オンプレミスのKubernetes基盤。その底层を支える仮想化技術の世界では、物理サーバーのメンテナンスや負荷分散のために、「動いている仮想マシン（VM）を、止めることなく別の物理サーバーへ引っ越させる」という、まるで魔法のような技術が使われています。
それが今回フォーカスする「ライブマイグレーション（Live Migration）」です。
「パケットがネットワークをどう駆け巡っているの？」「メモリの引っ越しってどうやってるの？」といった疑問を、身近な例えを交えながら、一歩ずつ優しく紐解いていきましょう！
—
1. ライブマイグレーションとは？（郵便配達の例えで理解する）
想像してみてください。あなたは今、たくさんの荷物（データ）が詰まった巨大な「動く倉庫（仮想マシン）」を管理しています。
この倉庫を、別の場所にある新しい土地（新しい物理サーバー）へ引っ越さなければなりません。しかも、倉庫の中では今も作業員が忙しく荷物を出し入れしています（＝OSやアプリが稼働中）。
さて、どうやって引っ越しますか？
一番簡単なのは、「一度作業をストップしてもらい、倉庫を丸ごとトラックに積んで運ぶ（コールド・マイグレーション）」方法です。これなら確実ですが、引っ越し完了までの間、サービスが止まってしまいます。ユーザーから「繋がらない！」とクレームの嵐になってしまいますよね。
そこで登場するのがライブマイグレーションです。その流れは、次のようなスマートな郵便配達にそっくりです。
1. 事前の下準備（事前メモリ転送）:
まずは、今倉庫にある荷物の「大部分（メモリの大部分）」のコピーを、新しい土地へそっと送り出します。作業員はまだ動き続けているので、荷物は少しずつ変わりますが、まずは大体のコピーを作っちゃうわけです。
2. 終わらない追いかけっこ（差分の同期）:
コピーを送っている間も、作業員は荷物を動かしますよね。だから、「さっき送ったあとに動かされた荷物（差分）」だけを、何度も何度も新天地へ追いかけて送ります。
3. 一瞬のバトンタッチ（最終差分転送と切り替え）:
最後に、作業員の手をほんの数ミリ秒だけ止めてもらいます（ここがキモです！）。その瞬間に、直前に変わった最後のわずかな荷物を送り、主導権を新しい土地の倉庫へバトンタッチします。
ユーザーから見ると、一瞬「ん？ 動作が少しだけフリッカー（カクついた）かな？」と思うくらいで、システムは止まらずに引っ越しが完了してしまうのです。これがライブマイグレーションの全貌です！
—
2. ネットワークの裏側で何が起きているのか？（通信シーケンス）
それでは、このダイナミックな引っ越し劇が、裏側のネットワークでどのように通信されているのか、パケットの動きを追いかけてみましょう。
移行元を「ホストA」、移行先を「ホストB」と呼びます。
ステップ1：お引越しの宣戦布告（初期化フェーズ）
ホストAのハイパーバイザーが、「よし、この仮想マシンをホストBへ引っ越すぞ！」と決めると、ホストBに対して「受け入れの準備はいいかい？」とネットワーク経由で打診します。ホストBが「OK、メモリ領域を空けて待ってるよ」と返事をすると、いよいよデータ転送のパイプライン（マイグレーション専用ネットワーク）が確立されます。
ステップ2：メモリの全量コピー（プッシュ・フェーズ）
ここからがネットワークの踏ん張りどころです。仮想マシンが積んでいるメモリ（例えば8GBや16GBなど）のデータを、ホストAからホストBへ、TCPなどの通信を使って猛烈な勢いで流し込みます。
このとき、仮想マシンはまだホストA上で元気に動いているため、メモリの内容は刻一刻と書き換わっています。
ステップ3：終わりの見えない差分送り（イテレーション・フェーズ）
全量コピーが終わった頃には、最初に送ったメモリの一部が古くなっています。
ハイパーバイザーは、メモリのページ（細かいブロック単位）を監視しており、「おっ、ここ書き換わったな」という変更部分（ダーティページと呼びます）を検知します。
そして、その書き換わった差分だけを、ホストAからホストBへ何度も繰り返し送り続けます。
この「差分を送るスピード」が、仮想マシン上のアプリが「メモリを書き換えるスピード」を上回った瞬間を見計らって、次の最終ステップへ進みます。
ステップ4：一瞬の静寂と切り替え（ストップ・アンド・コピー）
差分が十分に小さくなったら、ホストA上の仮想マシンの実行をほんの一瞬だけ停止（ポーズ）させます。
最後に残った最新の差分データをホストBへ送りきると同時に、ホストB側で仮想マシンのCPUレジスタや状態を復元し、「レディ、スタート！」と再開させます。
この瞬間、ネットワークの世界では何が起きているでしょうか？
仮想マシンのIPアドレスやMACアドレスはそのまま引き継がれますが、それが存在する「物理的なポート（物理ホストのNIC）」がホストAからホストBへと切り替わります。
そのため、ハイパーバイザーはネットワークスイッチに対して「Gratuitous ARP（無償ARP）」と呼ばれる特殊なブロードキャストパケットを放ちます。これにより、周囲のルーターやスイッチは「あれっ、あの仮想マシンの場所、ホストBに変わったんだな！」とルーティング情報を即座に書き換えるのです。
これで、外の世界からの通信も途切れることなく、新しいホストBへとルーティングされていきます。
—
3. 実務で役立つ設定とチューニングのポイント
さて、ここまでライブマイグレーションのロジックを見てきましたが、実際のインフラ現場（KVM/QEMUやOpenStack、KubernetesのKubeVirtなど）では、この仕組みを安定させるためにいくつかのパラメータ調整が必要です。
特に重要なのが、「ネットワーク帯域の確保」と「ダーティページの収束（Convergunece）」です。
ネットワーク設計のベストプラクティス
ライブマイグレーション中は、テラバイト級やギガバイト級のメモリデータが社内ネットワーク（データセンター内ネットワーク）を駆け巡ります。もしこれが通常の業務トラフィックと同じ回線を通っていたらどうなるでしょう？ そう、社内全体が猛烈なネットワーク渋滞（パケットロスや遅延）を起こしてしまいますよね。
そのため、実務では以下のようにマイグレーション専用のネットワーク（VLANや物理NIC）を切り出すのが鉄則です。
# 例: OpenStack (Nova) や KVM 環境におけるライブマイグレーション設定 (nova.conf のイメージ)
[libvirt]
live_migration_uri = qemu+tcp://%s/system
# マイグレーション専用の高速な内部ネットワークインターフェースを指定する
live_migration_inbound_addr = 192.168.100.50
# 転送時の圧縮を有効にしてネットワーク帯域の負荷を軽減する設定
live_migration_compression = trueデータベースなどの「重い」VMで引っ越しが失敗する場合の対策
メモリ書き換えのスピードが激しすぎるアプリ（例えば、巨大なインメモリデータベースなど）が動いているVMをライブマイグレーションしようとすると、いつまで経っても差分がなくならず、いつまでも引っ越しが終わらない（これをライブマイグレーションの収束失敗と呼びます）現象が起きます。
そんなときは、ハイパーバイザーの「自動スロットリング（Auto-converge）」機能を有効にします。これは、引っ越しが進まない場合に、仮想マシンのCPU実行速度を少しだけ意図的にスロットリング（ウェイトを入れる）して、メモリの書き換えスピードを強制的に落とすことで、無理やり差分を収束させるテクニックです。
# virsh コマンドを用いたライブマイグレーション実行時のフラグ例
# --auto-converge を付与することで、収束しない場合にCPU速度を落として転送を完了させます
virsh migrate --live --auto-converge --persistent --undefinesource <VM名> qemu+tcp://<宛先ホストIP>/system現場のSREとしては、「もしアプリ側がダウンタイムを一切許容できないのであれば、極端にメモリを消費するワークロードはライブマイグレーションではなく、あらかじめアプリ側の耐障害性（ステートレス設計）でカバーする」というアーキテクチャの選択も非常に重要な視点になります。
—
4. まとめ
いかがでしたでしょうか？
一見すると難解な「ライブマイグレーションのメモリ転送とネットワーク通信」も、
- 「大容量の荷物を先に送る」
- 「あとから変わった差分を追いかけて何度も送る」
- 「最後の一瞬だけ作業を止めてバトンタッチし、ARPで宛先を書き換える」
という郵便配達の流れに置き換えてみると、パケットがどのようにネットワークを駆け巡り、ハイパーバイザーがどう連携しているのかがイメージしやすくなったのではないでしょうか。
クラウドの便利さの裏側には、こうした泥臭くも洗練されたエンジニアたちの知恵とネットワーク技術が詰まっています。ぜひ、日々のインフラ構築やトラブルシューティングの引き出しの一つとして活かしてみてくださいね。
それでは、次回の技術解説でお会いしましょう！
コメント