Dev Study
← 仮想化とクラウドの土台
レッスン 10 / 10·約 9 分·第8期 仮想化とクラウドの土台

サーバレスとmicroVM — コンテナとVMの合流点

アプリと DB の下に何が積まれているか(左が下、右が上)
  1. 物理機リージョン/AZ
  2. ハイパーバイザVM exit で捕まえる今ここ
  3. VMゲストOS
  4. コンテナnamespace / cgroup今ここ
  5. プロセスアプリ / DB

2本目(捕まえる)と4本目(表を差し替える)の両方が前提です。その2つが1つの製品の中で出会う場所を見ます。

まず結論

他人のコードを同じカーネルの上で動かすと、見える範囲と使える量は絞れますが、カーネル自身の穴は共有したままです。

そこで引き直す方向が2つ生まれました。システムコールの上にもう1枚カーネルを挟むか、デバイスを削ってハードウェアの境界を軽くするか。どちらも境界を増やし、何かを失っています。

? 読む前に予測

利用者が投稿したコードを実行するサービスを作ります。普通のコンテナで包めば隔離として十分でしょうか。

当てることが目的ではありません。外した予測ほど記憶に残るので、直感で選んでください。

抽象原理

分けたはずが、1つだけ共有されている

このコースで境界の引き方を2種類見てきました。ハイパーバイザは特権命令を捕まえてゲストに偽の機械を見せ、namespace は「見える世界」の表を差し替えます。どちらも隔離ですが、決定的な違いがあります。

コンテナは、カーネルを共有しています。 namespace も cgroup もカーネルの中にある仕組みで、分けているのは同じ1つのカーネルです。

自分たちが書いたコードだけを動かすなら足ります。問題は、動かすコードを自分たちが書いていない場合です。ブラウザ編『なぜプロセスを分けるのか — OSがやったことを、Webにもう一度』で引いた限界がそのまま当てはまります。

The sandbox cannot provide any protection against bugs in system components such as the kernel it is running on.

サンドボックスは、その上で動くカーネル自身のバグには保護を提供できない。コンテナも同じで、namespace と cgroup をどう分けても土台のカーネルは共有のままです。

具体実物

独自のカーネルを持っていないことを確かめる

1行で確認できます。コンテナ内で uname -a を実行します。

$ docker run --rm alpine sh -c 'hostname; uname -a'(macOS 26.5.2 / Docker Desktop 4.47.0 / Engine 28.4.0。初回は pull 行が入る)コマンド出力
c6e43be79d13
Linux c6e43be79d13 6.10.14-linuxkit #1 SMP Wed Sep 10 06:47:45 UTC 2025 aarch64 Linux

hostname はコンテナ固有の値です(uts namespace が分けています)。ところがカーネルの版 6.10.14-linuxkit はこのコンテナのものではありません。Docker Desktop が動かす Linux VM のカーネルがそのまま出ています。コンテナは自分のカーネルを持たないからです。

ホスト名・プロセス番号・ネットワークは namespace が、使える量は cgroup が分けます。すべて分かれていないカーネルの中にある機能です。

✓ ここまでの確認

コンテナ内の `uname -a` がホスト側と同じ版を返すのはなぜですか。

抽象原理

引き直す方向は、上か下かの2つしかない

共有するカーネルが問題なら、手は2つです。

(1) カーネルの上にもう1枚挟む。 システムコールを本物のカーネルに届く前に横取りし、別の実装が応える。第13週『システムコール — アプリとカーネルの境界線』の境界に、同じ形をもう一段積むことになります。

(2) カーネルの下に境界を引く。 それぞれに自分のカーネルを持たせ、その下にハードウェア仮想化の境界を置く。2本目で見たハイパーバイザそのものですが、問題は重さでした。

(2) を選ぶなら VM を軽くするしかなく、その中身は速い実行方式の発明ではなく、載せる仮想デバイスを削ることでした。

具体実物

2つの実装が削ったものと足したもの

gVisor(上に挟む方) は自分をこう説明します。

It is an application kernel that implements a Linux-like interface. Unlike Linux, it is written in a memory-safe language (Go) and runs in userspace.

システムコールを横取りしてゲストカーネルとして振る舞う部分を Sentry と呼びます。何でないかと代償も明記されています。

gVisor is not a syscall filter (e.g. seccomp-bpf), nor a wrapper over Linux isolation primitives (e.g. firejail, AppArmor, etc.). gVisor is also not a VM in the everyday sense of the term (e.g. VirtualBox, QEMU). However, this comes at the price of reduced application compatibility and higher per-system call overhead.

Firecracker(下に引く方) は KVM を使って microVM を作る VMM です。削った結果は仮想デバイスの一覧に出ています。

仮想デバイス(NSDI 2020 論文 §3.1)と数値(メモリ・起動は SPECIFICATION.md、生成速度は論文 §1)表
デバイス
Firecracker  ネットワーク、ブロック、シリアルポート、部分的な i8042
QEMU         40種類以上(USB・映像・音声を含む)
 
数値(条件付き)
メモリ余分   <= 5 MiB   1 vCPU / 128 MiB 構成、専用調整カーネル
起動        <= 125 ms  API 受信から /sbin/init 開始まで、シリアルコンソール無効、
                       最小カーネルと最小ルートFS、特定のベアメタル機上
生成速度     最大 150/秒  1ホストあたりの microVM 生成数

i8042 はキーボードコントローラですが、主にゲストの再起動要求を受け取るために置かれています。

数値は条件を落とすと意味が変わります。表の 125 ms は SPECIFICATION.md の定義で InstanceStart API 受信から /sbin/init 開始まで。アプリの起動はその先です。論文 §1 は "boots to application code in less than 125ms" と緩く書き、§5.1 の実験は「VMM プロセスの fork からゲストカーネルが init を fork するまで」を測り、区間が違います。数字だけ覚えると応答までの時間と読み違えます。

✓ ここまでの確認

Firecracker が起動を速くできている理由は、公式の記述ではどれですか。

⇄ 2つを見比べる
具体例 A

システムコールの上に1枚挟む(gVisor)

アプリのシステムコールを、ユーザ空間のアプリケーションカーネルが横取りして応えます。公式が挙げる代償は、互換性の低下とシステムコール1回あたりの費用です。

システムコールが通る道表
方式          間に入るもの             ホストのカーネルへ
コンテナ       なし                     全部届く
gVisor        アプリケーションカーネル    絞られた分だけ届く
具体例 B

カーネルの下に境界を引く(Firecracker)

ゲストに自分のカーネルを持たせ、その下に KVM の境界を置きます。重さの原因だったデバイスモデルを4種類程度に絞っています。代償は、備えないデバイスを前提にする作業が動かないことです。

絞った結果と引き換えに得たもの表
絞った結果                        得たもの
備えるデバイスは4種類程度          メモリ使用量と攻撃面の縮小、
(QEMU は40種類以上に対応)         起動時間の短縮

片方はシステムコールの上、もう片方はカーネルの下。この2つは何を犠牲に何を得ているのでしょうか。

それぞれの公式文書が「代償」として挙げる項目を並べてみてください。位置は違っても種類は似ています。

抽象原理

3つの位置を1枚に

他人のコードの境界をどこに引くか
他人のコード利用者が投稿した処理
システムコールを出す
普通のコンテナnamespace / cgroup
境界はカーネルの中
gVisorアプリケーションカーネル
境界はカーネルの上
microVMゲスト自身のカーネル
境界はカーネルの下
その下にあるもの
ホストのカーネルここを共有
ホストのカーネル届く量が絞られる
KVMVM exit で捕まえる
  • ・右へ行くほど境界が増え、そのぶん費用か再現の範囲かを失う

こう並べると「コンテナか VM か」という二択が成り立たないことが見えます。問いはカーネルの上と下、どちらに境界を足すかに変わり、コンテナは両方で「足していない」状態です。README はこの合流点を1文で書いています。

Firecracker runs workloads in lightweight virtual machines, called microVMs, which combine the security and isolation properties provided by hardware virtualization technology with the speed and flexibility of containers.

この章のまとめ

  • コンテナは見える世界と使える量を分けるが、カーネルそのものは共有したまま。コンテナ内の uname がホスト側の版を返す。
  • 「サンドボックスはその上で動くカーネルのバグには保護を提供できない」はコンテナにも当てはまる。
  • 手は2つ。システムコールの上に1枚挟む(gVisor)か、カーネルの下に境界を引く(microVM)。
  • gVisor は自ら「syscall フィルタでも普段の意味の VM でもない」と書く。代償は互換性の低下と1回あたりの費用。
  • Firecracker は KVM を使う VMM で、仮想デバイスを4種類程度に絞る。速いのは削ったからで、VM の境界は残っている。
  • <= 125 ms と <= 5 MiB は SPECIFICATION.md の値で、構成・測る区間まで指定された条件付き。区間は SPEC の定義で読む。

この先の学びにどう繋がるか

境界の位置という見方は、クイズ群『仮想化とコンテナ隔離の原理』の「仮想化I(ハイパーバイザとハードウェア支援)」と「仮想化VI(イメージ層と隔離の限界)」で定着します。どの層をどう組み合わせているかは、/courses/aws-internals「AWSサービスの内部原理」の『Lambdaは小さな仮想マシンで動く — Firecrackerと多層隔離』と『Fargateは1タスク=1つの小さなVMである — Lambdaと同じFirecrackerが境界を引く』で追えます。

自分の現場で確かめる

読んだだけでは身につきません。手元の環境で実際に見てみてください。

環境:

理解度チェック

読んだ直後は「分かった」と感じやすいものです。実際に解いて確かめてください。

問題 1 / 3正解: 0

「microVM は速い VM の別名で、境界の強さはコンテナと同程度」の誤りはどこですか。

用語集(4語)
microVM
README の言い方では “lightweight virtual machines ... which combine the security and isolation properties provided by hardware virtualization technology with the speed and flexibility of containers”。仮想デバイスを絞った軽い VM で、VM であることは変わらない。
VMM (virtual machine monitor)
VM を作って走らせるソフトウェア。Firecracker では KVM を使って microVM を作る VMM がその中核。
アプリケーションカーネル
gVisor の自称 (application kernel)。ユーザ空間で動き、Linux 風のインタフェースを実装してシステムコールに応答する部分を Sentry と呼ぶ。
多テナント
1つの基盤の上で無関係な複数の利用者の処理を動かす形。共有相手が信頼できないので境界の位置が主題になる。

出典(一次ソース)