Firecracker microVM をやさしく解説：1 秒足らずで起動する本物の VM

AI が生成したコードを安全に実行する方法について何か読んだことがあれば、microVM という言葉を見たことがあるはずです。たいていは Firecracker と並んでいます。説明はたいてい「軽量な VM」（正しいけれど役に立たない）か、カーネル内部の図のどちらかです。ここではその中間の説明をします。

2 つの古い選択肢と、どちらも合わない理由

まず、microVM がその間に位置する 2 つのものから始めましょう。

コンテナは、あなたのマシン上にある普通のプロセスの集まりで、カーネルがそれらに「うそをつく」ことに同意したものです。namespaces はそれらに独自のファイルシステム、プロセス一覧、ネットワークを見せ、cgroups は使える CPU とメモリの量を制限します。何も新しく起動しないので、ミリ秒で立ち上がります。しかし、ホスト上のすべてのコンテナは同じカーネルと話しています。1 つのコンテナの中から到達できるカーネルのバグは、すべてのコンテナからの抜け道になります。

仮想マシンは自前のカーネルを持ちます。ホストの CPU はハードウェア仮想化（Linux では KVM）によって、ゲストを自分専用のコンピューターを持っているかのように動かします。境界はハイパーバイザーで、カーネルの何百ものシステムコールよりはるかに少ないものしか公開しません。代償は重さです。従来の VM は PC 全体をエミュレートします。ファームウェア、PCI バス、USB コントローラー、グラフィックカード、ときにはサウンドカードまで。それらをすべて通って起動するので数秒から数分かかり、インスタンスごとに数十から数百メガバイトのオーバーヘッドを抱えます。

それなりに当てはまるたとえを挙げると、コンテナは同じ建物の中のアパートの部屋で、基礎も配管も配線も共有しています。VM は別々の一軒家です。一軒家の方が安全な隣人ですが、20 秒の訪問のために家を建てる人はいません。

Firecracker が取り除いたもの

Firecracker は virtual machine monitor（KVM の上で VM を用意して動かすプログラム）で、Rust で書かれ、2018 年にオープンソース化されました。目的はただ 1 つ、互いを信頼しない短命なワークロードを共有ハードウェア上で大量に動かすことです。そのために主にやったのは、ものを削ることでした。

• ファームウェアなし、ハードウェア検出なし。 カーネルはメモリに直接読み込まれて起動します。存在しないデバイスを探し回るものは何もありません。
• 極小のデバイスモデル。 ネットワークカード、ブロックデバイス、シリアルコンソールなど少数だけで、すべて virtio（物理デバイスの模倣ではなく、仮想マシン向けに設計されたデバイス）です。USB もグラフィックも PCI もありません。
• 小さく、メモリ安全なコードベース。 デバイスをエミュレートするコードが少なければ、ゲストがホストに到達できるようなバグが潜む場所も少なくなります。
• VMM 自体を囲む檻。 各 Firecracker プロセスは chroot の中で動き、自身のシステムコールは seccomp フィルターで、リソースは cgroups で制限されています。仮に何かがゲストから抜け出しても、たどり着くのはホストではなく檻の中です。

プロジェクト自身が公表している数字は、最短 125 ms でユーザー空間に到達し、microVM あたりのメモリオーバーヘッドは 5 MiB 未満というものです。これは最良の条件での実験値です。実際のサンドボックスでは、ディスクとネットワークの準備や、コマンドを受け付ける中のエージェントの起動も必要なので、私たちのものは約 1 秒で使えるようになります。それでもタスクごとに 1 つ作って使い終わったら捨てられるくらい、コンテナの速さに近いと言えます。

コンテナと microVM、実際の違い

重要なのは 2 行目です。コンテナの場合、「このコードは抜け出せるか？」という問いは「ホストのカーネルのどこかに到達可能なバグはあるか？」になります。microVM の場合は「ハイパーバイザーか、少数の仮想デバイスにバグはあるか？」になります。後者の攻撃面ははるかに小さく、クラウドプラットフォームが自社のマルチテナントホスティングのためにすでに守っているのもこちらです。

あきらめるもの

microVM は無料のアップグレードではありません。

• GPU も画面もありません。 コードを動かすためのもので、デスクトップやグラフィック処理向けではありません。
• デバイスが少なく、柔軟性も低い。 本物のハードウェアや長いカーネルモジュールのリストを前提とするものは、居心地がよくありません。
• 境界にはやはりポリシーが必要です。 送信が開放された microVM は、あなたが望まない通信を送ることができます。API キーが入った microVM は、それを漏らすことができます。隔離が守るのはゲストからのホストであって、あなたが手渡したコードからあなたの秘密情報を守るわけではありません。

私たちのサンドボックスでの使い方

EQVPS のサンドボックスはそれぞれ、独自のカーネルを持つ 1 つの Firecracker microVM で、0.25 vCPU・512 MB から 8 vCPU・16 GB まであります。Python 3.12、Node.js 22、bash、git、curl が入っており、インターネットへの送信はでき、受信ポートはありません。一時的なサンドボックスは使い終わると削除され、persistent のものはディスクを保持します。一時停止すると microVM のスナップショットがディスクに書き込まれるので、再開するまで料金はかかりません。一時停止中のスナップショットは 14 日間保管されます。 その後サンドボックスは削除され、id には 410 sandbox_deleted が返ります。

コンテナではなく microVM を選んだ理由は 1 つです。サンドボックスで動くコードは、その性質上、誰もレビューしていないコードだからです。AI エージェントの出力、見知らぬ人の pull request、モデルが書いた 1,000 本のプログラムからなるベンチマーク。そうしたものには、独自のカーネルこそお金を払う価値のある境界です。その周りに用意したもの、つまりプラン、クォータ、同期コマンドの 55 秒制限などの詳細はサンドボックスのドキュメントにあります。

この境界をほかの選択肢ともっと詳しく比べたいなら、信頼できないコードのための隔離レベル がプロセス、コンテナ、microVM、完全な VM を並べて比較しています。秒単位の価格が気になったなら、秒単位課金は実際にどう計算されるか で計算の中身を紹介しています。