実はアナタの身近にある！？ Linux のチェックポイント／レストア機能 (NTT Tech Conference 2025 発表資料)

© 2025 NTT DATA Japan Corporation
実はアナタの身近にある！？
Linuxのチェックポイント／レストア機能
NTT Tech Conference 2025
2025年3月5日
NTTデータグループ末永恭正

© 2025 NTT DATA Japan Corporation 2
おことわり
本資料記載の検証結果は、すべて以下の環境で検証したものであり、具体的な数値は環境により異なることがあります。
また、各技術への言及は2025/02現在の情報に基づいています。
仮想マシン Hyper-V 4vCPU、8GBメモリ
OS ディストリビューション Fedora 41 x86_64
カーネル 6.12.11-200.fc41.x86_64
glibc glibc-2.40-21.fc41.x86_64
CRIU criu-4.0-2.fc41.x86_64
Cコンパイラ gcc-14.2.1-7.fc41.x86_64
Java JDK 8 Temurin 8u442 b06 x64
JDK 21 Temurin 21.0.6+7 x64
コンテナエンジン podman-5.3.2-1.fc41.x86_64
コンテナビルドツール buildah-1.38.1-1.fc41.x86_64
Kubernetes v1.32.1 ※kubeadm
コンテナランタイム cri-o-1.32.1-150500.1.1.x86_64
ホスト環境 Windows 11 24H2（自作PC：Ryzen 3 3300X、16GBメモリ）

2022年秋某クラウドプロバイダの “再発明” イベントにて…
うちのFunction as a Serviceで
Javaのスタートアップパフォーマンスを
爆上げする仕組みを入れたよ！

なぜJavaのスタートアップパフォーマンスが注目されるのか？
#include <stdio.h>
int main(){
printf("Hello Worldn");
}
public class HelloWorld{
public static void main(String[] args){
System.out.println("Hello World");
}
}
real 0m0.001s
user 0m0.000s
sys 0m0.001s
real 0m0.030s
user 0m0.013s
sys 0m0.020s
ケタ違いの遅さ…

なぜJavaのスタートアップパフォーマンスが注目されるのか？
起動するJVMの決定
JVMのロード
引数のパース
各メモリ領域の初期化
一部Javaクラスの初期化
各種スレッドの起動
Mainクラスのロード
main()呼び出し
ざっくり Javaでmain()が動くまで ※正確には様々な条件を見つつ、もっといろいろな処理があります
仮想マシン方式だからこその様々な “事前作業” がある
• “塵積も” 的に遅くなりがち
• AppCDSやGraalVM Native Imageもあるが…
サーバレスコンピューティングなど
起動停止が頻繁に発生する状況では
Javaの起動の遅さは致命的！

某クラウドプロバイダはどうやってスタートアップパフォーマンスを ”爆上げ” したか？
※公式ブログより
ウチのFaaSとJava 11の組み合わせで
スナップショットを活用するんだよね
CRaCも使えるんだよね

それ、そのクラウドのマネージドサービスじゃないとダメですよね？
OSSで実現できます！

CONTENTS
1. チェックポイント／レストアを実現するライブラリ：CRIU
2.コンテナとCRIU
3. JavaとCRIUの連携
4.まとめ

CONTENTS
4.まとめ

Checkpoint/Restore In Userspace
• Linux上のプロセス（コンテナ含む）を
任意のタイミングでフリーズさせてチェックポイントを取得し
あとでレストアして処理を再開させるためのソフトウェア
• メジャーなLinuxディストリビューションの多くで
公式パッケージとして配布されている
• Ubuntu、openSUSE、Arch、RHEL、Fedoraなど
• GPGPU（AMD・NVIDIA）上のワークロードの
チェックポイントにも対応
• AArch64でも動きます！
• 今日ご紹介するものすべてラズパイ4で動きます！

最大のメリット：起動時間短縮
@Override
public void run(ApplicationArguments args) throws Exception {
if(args.containsOption("checkpoint")){
System.out.println("Ready to obtain checkpoint...");
// Wait restoring...
cpCoordinator.await();
}
System.out.println("from Spring Boot App");
}
real 0m0.993s
user 0m2.498s
sys 0m0.193s
real 0m0.332s
user 0m0.026s
sys 0m0.115s
レストア待ち合わせポイント
素の実行チェックポイントからの復帰
速いっ！！ Springにパッチ当ててます
[CRaC] Fix hangup after restoring

CRIUのユースケース
• スタートアップ処理のスキップ
• 時間のかかるアプリ初期化を完了してからスナップショットをとり、実行時にレストアする
• JavaのようにJITがかかるものは “暖機運転” 終了後のスナップショットをとり、実行時にレストアする
※ただし、レストア直後に脱最適化（Deopt）条件にかかったら意味ないので注意…
• ライブマイグレーション
• 動いているプロセス・コンテナをそのまま別環境へ移動！
• 移行先環境が移行元と大きく異ならないか、ネットワーク再接続時の問題が発生しないかは注意が必要
• 事後解析
• トラブル発生時のスナップショットをとり、本番環境は即時復旧しつつデバッグ環境でレストアしてじっくり解析
• 実行状態をそのままフリーズして持ち運べるので、フォレンジクスでも活用可能

CRIU – Quick Start
チェックポイント取得
チェックポイントからのレストア
sudo criu dump -t <PID> -D /path/to/checkpoint -j
sudo criu restore -D /path/to/checkpoint -j

CRIU – 注意点
• チェックポイント／レストア実行時に権限がなければならない
• CAP_CHECKPOINT_RESTOREかCAP_SYS_ADMIN
• そもそも特権ユーザーで動かしてしまう
• レストア時にチェックポイント取得時のTID（LWPID）が利用可能でなければいけない
• 基本はIDがオリジナルのまま復元されるので、1つでもアサイン済みの状態でレストアするとエラーになる
• 動的に最適化するアプリではチェックポイント元とレストア先の環境が似ていなければならない
• エルゴノミクスの自動調整（メモリサイズ、GCやJITのスレッド数等）はJVM起動直後の環境で決定する
• JavaのJITコード生成はCPU拡張命令に依存するため、レストア後に最悪クラッシュする可能性がある
• チェックポイント時にオープンしていたファイルはすべて同じ場所に同じものを配置する必要あり
• チェックポイント時に存在したFDはすべてレストア時に復元される

CONTENTS
4.まとめ

Podman × CRIU
sudo podman container checkpoint [コンテナ名 or ID] -c gzip -e /path/to/tgz
sudo podman container restore -i /path/to/tgz

Podman × CRIU – 注意点
• rootlessコンテナではチェックポイント／レストアできない
• Podman v5.4.0ではrootlessコンテナでは機能しないようにハードコードされている
• チェックポイント元となったコンテナイメージはレストア時に参照できなければならない
• チェックポイントで取得するのは実行時イメージだけ
• 使用していたバイナリやオープン中のファイルはチェックポイント元イメージを参照する

K8s × CRIU
Forensic container checkpointing in Kubernetes |
Kubernetes
• v1.30からチェックポイントがベータ機能として
導入済み
• ただしkube-apiではなくKubeletのほう
• 事後解析を題材とした具体的な方法が
Kubernetes公式ブログで紹介されている
• コンテナランタイムでも対応が進んでいる
• CRI-O：対応済み
• containerd：対応中
• 2025/03現在、checkpointのKubernetes
API登録に向けて議論中！
State of Checkpoint/Restore in Kubernetes
FOSDEM 2025でも
発表がありました

K8s × CRIU – 事前準備
/etc/crio/crio.conf.d/10-crio.conf
[crio.runtime]
#default_runtime = "crun"
default_runtime = "runc"
• 高レベルコンテナランタイムはCRI-Oを使う
• containerdではレストアがまだ実装されていない
• 低レベルコンテナランタイムをruncに変更する
• CRI-Oバンドルのcrunではチェックポイントが動作しない
• 直しておきました
• Fedoraバンドルのcrunを使ってもレストアができない
• Issue複数あり
• runc v1.2.0以降を使用すること！
• cgroups v2で動かないバグあり
• （少なくとも）CRI-O v1.31以降にバンドルされたものなら大丈夫
runcに変えましょう

K8s × CRIU –チェックポイント対象の起動
apiVersion: v1
kind: Pod
metadata:
name: cp-creator
labels:
app: springboot-k8s
spec:
containers:
- name: springboot-k8s
image: localhost/springboot-k8s:latest
imagePullPolicy: Never
ports:
- containerPort: 8080
startupProbe:
httpGet:
path: /actuator/health/readiness
port: 8080
failureThreshold: 10
periodSeconds: 30
①普通にPodを上げる
チェックポイント取得用なので
ready状態で上がってくるだけでOK

K8s × CRIU – コンテナのチェックポイント
$ sudo curl -sS -XPOST --insecure
--cert /etc/kubernetes/pki/apiserver-kubelet-client.crt
--key /etc/kubernetes/pki/apiserver-kubelet-client.key
"https://fc41k8s:10250/checkpoint/default/cp-creator/springboot-k8s"
| jq
{
"items": [
"/var/lib/kubelet/checkpoints/checkpoint-cp-creator_default-springboot-k8s-2025-02-12T11:21:27+09:00.tar"
]
}
②Kubeletにチェックポイント取得を指示する
• 現状Kubeletに直接指示するしかないため、証明書と鍵を指定しなければならない
• パーミッションの関係で特権が必要なため、sudoしてcurlする
• チェックポイント保存場所はレスポンスボディ内のJSONで返される
• このファイルも特権ユーザーでなければアクセスできない
名前空間 Pod コンテナ

K8s × CRIU – レストアコンテナの作成
buildah from scratch
buildah add working-container <チェックポイントのアーカイブ> /
buildah config --annotation=io.kubernetes.cri-o.annotations.checkpoint.name=springboot-k8s working-container
buildah commit working-container springboot-k8s-restored:latest
buildah rm working-container
③取得したチェックポイントを利用してレストア用コンテナイメージをスクラッチから作る
コンテナ

K8s × CRIU – レストアコンテナのデプロイ
apiVersion: apps/v1
kind: Deployment
metadata:
name: springboot-k8s
spec:
selector:
matchLabels:
app: springboot-k8s
replicas: 1
template:
metadata:
labels:
app: springboot-k8s
spec:
containers:
- name: springboot-k8s-restored
image: localhost/springboot-k8s-restored
ports:
name: http
readinessProbe:
httpGet:
port: 8080
periodSeconds: 30
④普通にデプロイする
名前空間やPod名が違ってもOK

• チェックポイントがKubernetes APIではない
• kubectlに機能追加する話はKEP化が議論中
• チェックポイントのコンテナイメージ仕様がまだ固まっていない
• OCIスペック化について議論中
• レストアについて仕様が十分議論されていない
• Podのライブマイグレーションにおけるユースケースは示されているが…
K8s × CRIU – 課題

CONTENTS
4.まとめ

思い出してください

Javaスタートアップパフォーマンスの救世主！CRaC
OpenJDK Wiki CRaC • チェックポイント／レストア機能を
Javaに統合するOpenJDK公式プロジェクト
• jcmdで
チェックポイントの取得とレストアが可能
• CRIUを活用
• チェックポイント／レストアを
イベントとしてフック可能
• まだまだ開発中のプロジェクト
• 一部JDKベンダは商用プロダクトを提供中
（JDK 17と21など）

CRaCの動き Anatomy of CRaC Processes
• チェックポイント
1. アプリを普通に起動する
2. ユーザーがjcmdでチェックポイント取得を要求する
3. criuengineなるプロセスがJVMプロセスツリーから
抜け出し、チェックポイントを取得する
• レストア
1. ユーザーが –XX:CRaCRestoreFrom で
チェックポイントを指定して java を実行する
2. criuengineがプロセスをレストアする
独自に拡張したCRIUを利用している！

CRaCのイベントフック
Resource (crac 1.5.0 API)
• CRaCのJavaライブラリを使用することで
チェックポイント直前／レストア直後の
イベントハンドラを記述することが可能
• 外部システムとの接続／切断など
任意の処理をチェックポイント前後で行える
• Spring BootやQuarkusなど
一部フレームワークはCRaCに標準対応
• チェックポイントと連動してLifeCycleが変化する

CRaC使わないとチェックポイント／レストア使いにくくない？

checkpointer – CRaCなしにチェックポイント／レストアイベントをフック！
YaSuenag/checkpointer: Primitive CRaC implementation
• CRaCイベントハンドラをコールする
WebAPIエンドポイントを提供する
JVMTI Javaエージェント
• CRIUを実行してjavaプロセスの
チェックポイント／レストアと
CRaCイベントハンドラの呼び出しを
ワンストップで行うためのシェルも提供
• Java固有の対処も自動で実施
某クラウドプロバイダよりも幅広く！
Java 8から対応！！

checkpointer × 素のJava
sudo checkpointer.sh checkpoint [PID] /path/to/checkpoint/dir
sudo checkpointer.sh restore /path/to/checkpoint/dir
仕込み
$JAVA_HOME/bin/java -javaagent:checkpointer-0.2.0.jar …

checkpointerがやる、Javaだからこその “気配り”
• beforeCheckpoint()、afterRestore()の呼び出し
• criuの--action-script内でJVMTI Javaエージェントに向けてHTTPリクエストを発行
• hsperfdataの保存／復元
• /tmp/hsperfdata_<ユーザー名>/<PID>
• Javaのパフォーマンス情報が記録されているファイル
• jcmdやjpsなどのツール類はこのファイルからプロセスをリストしている
• 全beforeCheckpoint()実行後のGC実行
• JVMTI Javaエージェントにgc=trueを与えたとき、beforeCheckpoint()後にSystem.gc()を実行する
• スナップショット取得時のJavaヒープをできるだけクリーンな状態にできる

checkpointer × Spring Boot × Kubernetes
• コンテナの起動を早められる
• サーバレスなどPodの立ち上がりが頻繁に発生しうる環境でJavaが使いやすくなる
• “暖まった” 状態から始められる
• マスタデータの読み込みなどの初期動作完了後でスナップショットを取得してもOK
• 定型的な重い処理があるのならJITコンパイル後のスナップショット取得もアリ
• SpringのLifeCycleが適切に変化する
• アプリの考慮事項を最小限にできる
メリット

checkpointer × Spring Boot × Kubernetes - チェックポイント対象の起動
apiVersion: v1
kind: Pod
metadata:
name: cp-creator
labels:
app: springboot-k8s
spec:
containers:
- name: springboot-k8s
image: localhost/springboot-k8s:latest
ports:
name: checkpointer
startupProbe:
httpGet:
port: 8080
periodSeconds: 30
---
apiVersion: v1
kind: Service
metadata:
name: checkpointer
spec:
selector:
app: springboot-k8s
ports:
- name: checkpointer
port: 10095
targetPort: checkpointer
①普通にPodを上げる
• チェックポイント取得用なので
ready状態で上がってくるだけでOK
• checkpointerのリクエスト受信用Service
（ポート：10095）を開けておく

checkpointer × Spring Boot × Kubernetes - beforeCheckpoint発動
②checkpointerの /before-checkpoint にPOSTリクエストを発行する
kubectl run curl-checkpoint --image=curlimages/curl -it --rm --restart=Never --
-XPOST http://checkpointer.default.svc.cluster.local:10095/before-checkpoint

checkpointer × Spring Boot × Kubernetes - チェックポイント～レストア
Kubeletへのチェックポイント要求からレストアコンテナイメージの作成までは先の例と同じ

checkpointer × Spring Boot × Kubernetes - レストアコンテナのデプロイ
apiVersion: apps/v1
kind: Deployment
metadata:
name: springboot-k8s
spec:
selector:
matchLabels:
app: springboot-k8s
replicas: 1
template:
metadata:
labels:
app: springboot-k8s
spec:
containers:
- name: springboot-k8s-restored
image: localhost/springboot-k8s-restored
ports:
name: http
startupProbe:
exec:
command:
- curl
- -XPOST
- -s
- http://localhost:10095/after-restore
periodSeconds: 1
readinessProbe:
httpGet:
port: 8080
periodSeconds: 30
④普通にデプロイする
ただしレストアイベントを呼ばないと
LifeCycleがリスタートしない
• 外部から呼ぶ or startupProbeを使う

CONTENTS
4.まとめ

まとめ
• スタートアップスピードの向上が見込めるチェックポイント／レストア
• コンテナランタイムはだいたいサポートしはじめているが、Kubernetesではまだまだこれから
• JavaもCRaCがあるが、まだまだこれから
プロプラ製品やサービスを持ってこなくても…
フルOSSで
Javaでチェックポイント／レストアはできます！

実はアナタの身近にある！？ Linux のチェックポイント／レストア機能 (NTT Tech Conference 2025 発表資料)

実はアナタの身近にある！？ Linux のチェックポイント／レストア機能 (NTT Tech Conference 2025 発表資料)

More Related Content

Similar to 実はアナタの身近にある！？ Linux のチェックポイント／レストア機能 (NTT Tech Conference 2025 発表資料) (20)

More from NTT DATA Technology & Innovation (20)

実はアナタの身近にある！？ Linux のチェックポイント／レストア機能 (NTT Tech Conference 2025 発表資料)