クラウド・オンプレミスなどの環境において、リソースの効率的な活用に対する関心が高まっている。
例えば、各クラウドベンダでオートスケール[1]と呼ばれる技術は、クラウド上のインスタンス数を負荷に応じて自動で増減することで、その時の負荷を捌き切る上で過剰でも不足でもない、必要十分なリソースを割り当てる事を目的としている。オートスケールという考え方はオープンソースのコンテナ管理ツールであるKubernetes[2]などでも採用されている。
また、AWS Lambda[3]やGoogleのCloud Run[4]のようなサービスは、計算機の資源を関数やコンテナの起動という形でユーザの必要な場合のみ利用し、その分のみを課金するという仕様で利用できる。
このように、「必要な計算を必要な時にだけ」というアーキテクチャを採用する場面は増えており、背景として本質的に有限な計算機リソースの効率的活用は利用者側、運用者側ともにメリットが大きいためであろう。
また、松本・近藤らによるFastContainerアーキテクチャ[5]でも、HTTPリクエストがあったときに初めてコンテナが起動するアーキテクチャを提案している。その効用として効率的なリソース利用、集約率の向上が挙げられている。
一方で、「必要な計算を必要な時にだけ」行うためには技術的な障壁も存在する。最たるものは、コンピュータ資源が利用できるようになるまでのオーバヘッド、すなわち起動時間であると考えられる。
例えばオートスケールにおいては、いざリクエスト数の激増や負荷の急上昇を検知しても、サーバインスタンスを増やす指令をクラウドのコントロールプレーンに送り、実際にインスタンスが立ち上がり、リクエストを受け切れる間までには若干のタイムラグが生じうる。この中でも大きな時間を占めるのはインスタンスが立ち上がってReadyになるまでの時間である。
また、Cloud Runでも初回起動時のオーバヘッドは問題とされており、たとえばCloud Scheduler[6]による定期リクエストなどの解決策が考えられる。
あるいは、データセンターマイグレーションの文脈でも起動時間は重要になるだろう。ある処理を受け持つサーバをデータセンターAからBに移設する際、ライブでマイグレーションするとなると、移設中は処理を受け付けることができないダウンタイムとなる。コンテナの場合でも、たとえばKubernetesにはnode drain[7]という仕組みがあり、特定のノードに存在するコンテナ（Pod）を別のノードに移動させることができるが、コンテナとはいえ移動中には若干のダウンタイムが生じてしまう仕様となる。そのダウンタイムをいかに低減させるかは運用上重要である。
起動時間を低減させる手法は多くは知られていないが、オープンソースかつ有力のものの一つにLinuxにおけるCRIUがある。CRIU（Checkpoint and Restore In Userspace）[8]は起動しているプロセスのランタイムメモリの状態や、PIDやユーザなどプロセスの各種属性、利用しているfile descriptorやソケットの情報をダンプしてイメージ化し、それをもとにプロセスの状態を再現するツールである。
CRIUを用いると、プログラムを読み込んでメモリに読み込んだり、スクリプトの解釈と実行、あるいはデータベースクエリなどのキャッシュの溜め込みの時間を省略でき、プログラムがReadyになるまでの時間を劇的に短縮できることが考えられる。松本・近藤らは、コンテナのメモリイメージを事前作成した上でリクエスト到達時にCRIU経由で起動すると、起動時間を短縮することができる旨の報告をしている[9]。
CRIUの利用自体はいまだ実験的な例が多いとはいえ、後述する通りいくつかの事例が見られる。そうした中で出てくるであろう運用上の課題を考察した。
CRIUは2011年に最初のコードが発表され、2013年にバージョン1.0となった[10]。ソフトウェアとしては安定するようになってきているが、一方でLinuxカーネルのアップデートに従い機能更新も盛んである。
エコシステムとしても年に10件程度の利用報告がある[11]が、基本的に特定の環境での利用報告が目立ち、現実のプロジェクトにどう導入するかは毎回の手探りが必要であろう。定番・標準的な構成が確立されていないと考えられる。また、先述したように機能の更新が盛んであり、古い情報も目立つ。
CRIUの現在の実装では、メモリダンプなどのイメージは当然同一サーバに作成される。プロセスのリストアもそのイメージファイルの存在が前提となる。