Firecracker の誕生秘話 - Lambda と Fargate を支えるマイクロ VM はなぜ作られたのか
AWS が Lambda と Fargate のために独自開発したマイクロ VM モニター Firecracker の設計思想、従来の仮想化技術との違い、125ms で起動する軽量性の秘密、オープンソース化の戦略的意図を解説します。
Lambda の初期アーキテクチャが抱えていた問題
2014 年に Lambda がローンチされた当初、関数の実行環境にはコンテナ技術が使用されていました。Linux の cgroups と namespaces を使って関数を隔離する方式です。この方式は起動が高速で効率的でしたが、セキュリティ上の懸念がありました。コンテナはカーネルを共有するため、カーネルの脆弱性を突かれると、1 つの関数から他の顧客の関数にアクセスできる可能性がありました。マルチテナント環境で数百万の顧客の関数を同一の物理ホスト上で実行する Lambda にとって、この隔離の弱さは根本的なリスクでした。従来の仮想マシン (VM) を使えばハードウェアレベルの隔離が得られますが、VM の起動には数十秒かかり、メモリのオーバーヘッドも大きいため、Lambda のようなミリ秒単位の課金モデルには適しません。AWS が必要としていたのは「VM レベルのセキュリティ隔離」と「コンテナレベルの起動速度と軽量性」を両立する技術でした。この要件を満たすものが市場に存在しなかったため、AWS は自ら開発することを決断しました。
Firecracker の設計思想 - 削ぎ落としの美学
Firecracker は 2018 年に発表された、KVM (Kernel-based Virtual Machine) ベースのマイクロ VM モニター (VMM) です。Rust で書かれており、約 5 万行のコードで構成されています。QEMU (従来の汎用 VMM) が数百万行のコードを持つのと比較すると、Firecracker のコードベースは桁違いに小さいです。この小ささは意図的な設計判断です。Firecracker は「サーバーレスワークロードの実行に必要な最小限の機能だけを提供する」という方針で設計されました。GPU パススルー、USB デバイスのサポート、グラフィカルコンソール、ライブマイグレーションなど、汎用 VM に必要な機能はすべて省かれています。エミュレートするデバイスは、virtio-net (ネットワーク)、virtio-block (ブロックストレージ)、シリアルコンソール、最小限の i8042 キーボードコントローラーだけです。この徹底的な削ぎ落としにより、攻撃対象面 (Attack Surface) が極めて小さくなり、セキュリティが向上しています。コードが少なければバグも少なく、監査も容易です。
125ms 起動の秘密
Firecracker のマイクロ VM は 125ms 以下で起動します。この速度を実現している要因は複数あります。第 1 に、最小限のデバイスエミュレーションです。QEMU は BIOS、PCI バス、USB コントローラーなど多数のデバイスをエミュレートしますが、Firecracker はこれらをすべて省略しています。ゲスト OS のカーネルは、Firecracker が提供する最小限のデバイスだけを認識すればよいため、カーネルの初期化が高速です。第 2 に、カスタムカーネルの使用です。Lambda の実行環境では、汎用の Linux カーネルではなく、不要なドライバーやサブシステムを除去したカスタムカーネルが使用されています。カーネルの起動時間自体が短縮されています。第 3 に、メモリのオーバーヘッドの最小化です。Firecracker のプロセス自体のメモリ使用量は約 5MB で、QEMU の数十〜数百 MB と比較して桁違いに小さいです。これにより、1 台の物理ホスト上で数千のマイクロ VM を同時に実行できます。Lambda が 1 つの関数に 128MB のメモリを割り当てた場合、VMM のオーバーヘッドが 5MB なら約 4% のオーバーヘッドですが、QEMU の 100MB なら約 44% のオーバーヘッドになります。この差は、大規模なマルチテナント環境では莫大なコスト差に直結します。
jailer - セキュリティの多層防御
Firecracker のセキュリティモデルは、マイクロ VM による隔離だけに依存していません。jailer と呼ばれるコンポーネントが、Firecracker プロセス自体をさらに隔離します。jailer は、Firecracker プロセスを chroot 環境に閉じ込め、seccomp-bpf でシステムコールをフィルタリングし、cgroups でリソース使用量を制限します。つまり、仮にマイクロ VM からのエスケープ (ゲスト OS からホスト OS への脱出) に成功したとしても、攻撃者は jailer の制限内に閉じ込められます。この多層防御 (Defense in Depth) の設計は、単一の防御層が突破されても全体のセキュリティが維持されることを保証します。Firecracker が許可するシステムコールは約 30 個に制限されており、Linux カーネルが提供する 300 以上のシステムコールの大部分がブロックされています。この厳格なフィルタリングにより、カーネルの脆弱性を悪用する攻撃の大部分が無効化されます。AWS は Firecracker のセキュリティモデルを「ゲスト OS を信頼しない」という前提で設計しており、悪意のあるコードがゲスト OS 内で実行されても、ホスト OS や他のマイクロ VM に影響を与えないことを目標としています。
オープンソース化の戦略的意図
AWS は 2018 年に Firecracker を Apache 2.0 ライセンスでオープンソース化しました。AWS の中核技術をオープンソースにするこの決定には、複数の戦略的意図があります。第 1 に、セキュリティの透明性です。Firecracker はセキュリティクリティカルなコンポーネントであり、コードを公開することで外部の研究者によるセキュリティ監査を受けられます。実際に、オープンソース化後に外部の研究者から複数のセキュリティ改善提案が寄せられています。第 2 に、エコシステムの拡大です。Firecracker は AWS 以外の環境でも利用可能で、Fly.io、Koyeb などのクラウドプラットフォームが Firecracker を採用しています。Firecracker のエコシステムが広がれば、Firecracker 上で動作するワークロードが増え、結果的に AWS への移行が容易になります。第 3 に、人材採用です。Firecracker のような先端技術をオープンソースで公開することは、優秀なシステムプログラマーを惹きつける強力な採用ツールになります。Firecracker は Rust で書かれており、Rust コミュニティからの注目も高いです。Firecracker の GitHub リポジトリは 2 万以上のスターを獲得しており、AWS のオープンソースプロジェクトの中でも最も成功した事例の一つです。仮想化技術の設計思想を深く理解するには、専門書籍 (Amazon)が参考になります。