CRIU（チェックポイント・リストア）

チェックポイント・リストアとは何をする技術か

CRIU（Checkpoint/Restore In Userspace）は、実行中のプロセス（またはプロセスツリー）の状態を丸ごとディスク上のイメージに固め、任意のタイミング・任意のホストで元通りに再開するためのツールです。プロセスを止めて保存し、後から続きから走らせる。ここで言う「状態」とは、メモリ内容だけではありません。オープン中のファイルディスクリプタ、TCPソケットの接続情報、シグナルハンドラの設定、子プロセスとの親子関係、名前空間の所属など、プロセスを取り巻くカーネル内部の情報すべてが対象です。

名前が示す通り、実装のほとんどはユーザー空間で完結します。カーネルに専用のチェックポイント機構が用意されているわけではなく、/proc以下の各種情報とptraceによるプロセス制御、そしていくつかの補助的なカーネルインタフェースを組み合わせて、外側から状態を読み出し・書き戻します。この設計により、CRIUはカーネル本体に大きな変更を要求せずに実現されています。

チェックポイント：何をどう集めるか

チェックポイントの手順は、大きく分けて「凍結」「収集」「保存」の3段階です。

まず対象プロセスをptrace(PTRACE_SEIZE)で捕捉し、実行を止めます。SEIZEは古典的なPTRACE_ATTACHと異なり、対象にSIGSTOPを送らずに捕捉できるため、プロセス側のシグナル処理系を乱しません。プロセスツリー全体（親子関係にある複数プロセス）を対象にする場合は、全プロセスを同時に凍結してからでないと、片方だけ状態が進んでしまい整合性が崩れます。

次に状態を収集します。主な情報源は次の通りです。

• メモリ：/proc/<pid>/mapsでVMA（仮想メモリ領域）の一覧を取得し、/proc/<pid>/memまたはprocess_vm_readvでページ内容を読み出す。匿名メモリはページ単位でダンプし、ファイルバックドなマッピング（実行ファイル・共有ライブラリ）はパスだけを記録してページ内容自体は保存しない。
• ファイルディスクリプタ：/proc/<pid>/fd/でオープン中のfd一覧とその指す先（通常ファイル・パイプ・ソケット・デバイス）を取得し、ファイルはオフセットやフラグも含めて記録する。
• ソケット：TCPなら/proc/net/tcp相当の情報やソケットオプションを収集する。特にTCP接続は後述の理由で特別扱いが要る。
• シグナル状態：ペンディング中のシグナル、ハンドラの設定、シグナルマスクを/proc/<pid>/statusや関連インタフェースから取得する。
• プロセス関係：親子関係、プロセスグループとセッション、スレッド構成をまとめて記録する。

収集した情報はプロセスごとのイメージファイル（pstree.img、mm-<pid>.img、fdinfo-<pid>.imgなど）としてディスクへシリアライズされます。イメージはネットワーク越しに別ホストへ転送でき、この転送こそがライブマイグレーションの実体です。

リストア：状態をどう作り直すか

リストアは収集の逆順ではなく、新しいプロセスを一から作り、システムコールの実行によってカーネル内部状態を再構築するという形を取ります。CRIUのイメージには「メモリのバイト列」以上に「これを再現するために発行すべきシステムコール列」という性格があります。

典型的な流れは次の通りです。

1. pstree.imgからプロセスツリーを読み、fork/cloneで骨格となる子プロセス群を先に作る
2. 各プロセスは自分自身を「CRIUが用意した復元用の小さなコード（restorer blob）」に
   execで置き換える
3. restorer blobがmmapでメモリ領域を再構築し、保存済みページ内容をコピーする
4. open/dup2でファイルディスクリプタを元の番号に復元する
5. TCP_REPAIRモードでソケットを復元し、シーケンス番号等を書き戻す
6. シグナルマスク・ハンドラ・レジスタ値を復元する
7. 最後にrestorer blobから、元のプログラムカウンタ位置へジャンプして実行を再開する

ここで重要なのは、リストア後のプロセスは元のプロセスとPIDが一致するという点です。多くのプログラムは自分のPIDやファイルディスクリプタ番号を前提に動いているため、番号がずれると復元後に破綻します。CRIUは/proc/sys/kernel/ns_last_pidへの書き込みで次に割り当てられるPIDを操作し、clone直後に狙ったPIDを引き当てます。同様にfd番号もdup2で元の番号へ強制的に揃えます。

復元が困難な資源

チェックポイント・リストアは万能ではありません。ホストのハードウェアや外部エンティティに直接結びついた資源は、別ホストは元よりチェックポイント元のホストに戻す場合でも、再現が原理的に難しい、あるいは前提条件を要します。

これらに共通するのは、状態の一部がCRIUの外側（ハードウェア、相手ホスト、別プロセス）に存在し、チェックポイント対象のプロセスだけでは閉じていないという点です。原理的な限界であり、CRIUのバージョンが上がっても本質的には残り続けます。

コンテナのライブマイグレーションへの応用

コンテナは実体としてはホスト上の通常プロセス群であり、名前空間による隔離を伴うだけなので、CRIUを直接適用できます。ライブマイグレーションの典型的な流れは以下です。

1. 移行元でコンテナ内の全プロセスをチェックポイントし、イメージを生成する
2. イメージを移行先ホストへ転送する
3. 移行先で同じ名前空間構成（PID/ネットワーク/マウント等）のコンテナを用意する
4. イメージからプロセスツリーをリストアする
5. コンテナのネットワーク設定を切り替え、移行元を停止する

ダウンタイムを縮めるための最適化がプレコピー方式です。実行中のうちにメモリページを先行して転送し、その後の差分（ダーティページ）だけを都度追跡して転送します。最終的に凍結する時間はダーティページの再送分だけで済むため、完全に止めてから丸ごと転送するより移行時間を短縮できます。ただしメモリ書き込みが激しいワークロードでは差分が収束しにくく、プレコピーの効果は限定的です。

まとめ

CRIUは、/procとptraceを軸にプロセスのメモリ・fd・ソケット・シグナル状態を収集してイメージ化し、リストア時はシステムコールの再実行によって同じ状態を作り直します。PIDとfd番号を厳密に一致させる工夫、TCP_REPAIRによるソケット凍結が中核です。一方でGPUコンテキストや相手ホスト依存の資源など、プロセスの外側に状態がまたがる資源は原理的に復元できず、事前の分離や個別対応が前提になります。コンテナのライブマイグレーションはこの仕組みの直接的な応用であり、プレコピーによる差分転送でダウンタイムを縮めます。