Firecracker の誕生秘話 - Lambda と Fargate を支えるマイクロ VM はなぜ作られたのか
AWS が Lambda と Fargate のために開発したマイクロ VM モニター Firecracker の設計思想、従来の仮想化技術との違い、125 ms 級で起動する軽量性の秘密、オープンソース化の戦略的意図を解説します。
Lambda の初期アーキテクチャが抱えていた問題
2014 年に Lambda がローンチされた当初、AWS は求める隔離水準を満たすために、顧客ごとに専用の EC2 インスタンスを割り当てて関数を実行していました (AWS News Blog 2018 年 11 月)。ハードウェア仮想化による強固な境界は得られる一方、この方式は舞台裏の運用効率の面で妥協を強いるものでした。同一顧客の関数どうしは Linux の cgroups と namespaces を使ったコンテナで分けられますが、別の顧客の関数を同じインスタンスに混載することはできません。呼び出しが散発的なワークロードほど、隔離のために確保した計算資源が遊ぶ構造だったのです。Lambda は 2014 年の re:Invent での提供開始から 4 年で、公式発表によれば月あたり数兆回の実行と数十万の稼働顧客を処理する規模に達し (2018 年時点)、2017 年に登場した Fargate も週あたり数千万のコンテナを動かすようになりました。この規模になると、専用インスタンス方式が生む余剰は無視できません。かといって従来の汎用仮想マシン (VM) をそのまま使えば、起動に数十秒かかりメモリのオーバーヘッドも大きいため、ミリ秒単位の課金モデルには適しません。AWS 自身が示した問題認識は「既存の仮想化技術は、イベント駆動で時に短命なこの種のワークロード向けに最適化して作られたものではなかった」というものでした。必要だったのは、VM と同じハードウェア仮想化ベースのセキュリティ境界を保ちながら、コンテナや関数と同じ小さなパッケージサイズと機敏さを維持できる技術です。そこで AWS は、サーバーレスコンピューティングのために設計された仮想化技術を自ら用意する道を選びました。
Firecracker の設計思想 - 削ぎ落としの美学
Firecracker は 2018 年 11 月の re:Invent で発表された、KVM (Kernel-based Virtual Machine) ベースのマイクロ VM モニター (VMM) です。ゼロからの独自実装ではなく、Chromium OS の VMM である crosvm を出発点に、オーバーヘッドを削って安全なマルチテナンシーを実現するための最小限のデバイスモデルへ組み替える形で作られました (AWS News Blog 2018 年 11 月)。実装言語は 2017 年秋に Rust を選定しています。スレッド安全性とメモリ安全性を言語レベルで保証し、バッファオーバーフローをはじめ脆弱性につながるメモリ安全性のエラーを防げることが理由でした。コード規模は約 5 万行で、幅広いデバイスエミュレーションとレガシー互換を抱える汎用 VMM のコードベースとは桁が違います。この小ささは意図的な設計判断です。Firecracker は「安全で軽量な VM を動かすために必要なものだけを含む」という方針で設計されました。GPU などアクセラレーターのパススルーはなく、グラフィックスのサポートもなく、レガシーデバイスもほとんど扱いません。ブートもエミュレートされた BIOS に頼らず、完全なデバイスモデルを持たない最小のカーネル構成で行います。起動できるゲストカーネルは比較的新しい Linux カーネルで、かつ特定のコンパイル構成 (カーネルのコンパイルオプションは 1000 以上ある) でビルドされたものに限られます。発表時点でエミュレートしていたデバイスは、ネットワークデバイス、ブロック I/O デバイス、Programmable Interval Timer、KVM クロック、シリアルコンソール、そして VM をリセットできるだけの部分的なキーボードだけでした。その後 2019 年にゲストとホスト間の通信路である vsock が追加されるなど、必要と判断された最小限の範囲で拡張が続いています。この徹底的な削ぎ落としにより、攻撃対象面 (Attack Surface) が極めて小さくなり、セキュリティが向上しています。コードが少なければバグも少なく、監査も容易です。
125 ms 起動の秘密
公式に示されている起動時間は、i3.metal 上でデフォルトの microVM サイズ (1 vCPU・128 MiB メモリ) を使った場合の 125 ms 未満です (AWS Open Source Blog 2018 年 11 月)。実測値はホストのインスタンス種別やゲストの構成で変わりますが、この速度を支えている要因は複数あります。第 1 に、最小限のデバイスエミュレーションです。汎用 VMM は BIOS、PCI バス、USB コントローラーなど多数のデバイスをエミュレートしますが、Firecracker はこれらを持ちません。ゲスト OS のカーネルは Firecracker が提供する最小限のデバイスだけを認識すればよいため、カーネルの初期化が高速です (公式のブート引数の例でも pci=off が渡されています)。第 2 に、カーネル構成の絞り込みです。汎用の Linux カーネルをそのまま使うのではなく、不要なドライバーやサブシステムを除いた構成でビルドしたカーネルを起動するため、カーネルの起動時間自体が短くなります。第 3 に、メモリオーバーヘッドの最小化です。Firecracker のマイクロ VM 1 台あたりのメモリオーバーヘッドは 5 MiB 未満で、これにより 1 台のマシンに数千のマイクロ VM を詰め込めます。Lambda が 1 つの関数に 128 MB のメモリを割り当てる場合、VMM 側の上乗せが 5 MiB なら 4% 程度に収まります。大規模なマルチテナント環境では、この上乗せ分の差がそのままホスト台数の差、つまりコストの差に直結します。さらに Firecracker はプロセス内のレートリミッターを備え、数千のマイクロ VM をまたいでネットワークとストレージの共有を細かい粒度で制御できます。ゲストに見せるハードウェア計算資源はすべて安全にオーバーサブスクライブできる設計であり、1 ホストで動かせるワークロードの数を最大化できます。
jailer - セキュリティの多層防御
Firecracker のセキュリティモデルは、マイクロ VM による隔離だけに依存していません。jailer と呼ばれるコンポーネントが、Firecracker プロセス自体をさらに隔離します。jailer は、Firecracker プロセスを chroot 環境に閉じ込め、seccomp-bpf でシステムコールをフィルタリングし、cgroups でリソース使用量を制限します。firecracker のバイナリは静的リンクされており、jailer から起動することでホスト環境を可能な限り安全で清潔な状態に保ちます (AWS News Blog 2018 年 11 月)。つまり、仮にマイクロ VM からのエスケープ (ゲスト OS からホスト OS への脱出) に成功したとしても、攻撃者は jailer の制限内に閉じ込められます。この多層防御 (Defense in Depth) の設計は、単一の防御層が突破されても全体のセキュリティが維持されることを狙ったものです。Firecracker プロセスがアクセスできるシステムコールは、公式の表現によれば「小さく厳密に管理された許可リスト」に限られます。許可されるシステムコールの数は版によって変わるため件数で語るべきものではありませんが、方針は明確で、2019 年には最も厳格な seccomp レベルが既定値になりました (AWS Open Source Blog 2019 年 5 月)。この厳格なフィルタリングにより、ホストカーネルの脆弱性を悪用する攻撃の経路が大きく狭まります。AWS は Firecracker の設計原則として、顧客のワークロードを「神聖なもの (触れてはならない)」と「悪意のあるもの (防御すべき)」の両方として同時に扱うと明言しており、マルチテナントのワークロードを成立させる計算セキュリティの壁は、利用者が誤って無効化できない形で提供されます。悪意のあるコードがゲスト OS 内で実行されても、ホスト OS や他のマイクロ VM に影響を与えないことが目標です。
オープンソース化の戦略的意図
AWS は 2018 年に Firecracker を Apache 2.0 ライセンスでオープンソース化しました。AWS の中核技術をオープンソースにするこの決定には、複数の戦略的意図があります。第 1 に、セキュリティの透明性です。Firecracker はセキュリティクリティカルなコンポーネントであり、コードを公開することで外部の研究者や技術者による監査を受けられます。実際に、公開から半年後の公式報告 (AWS Open Source Blog 2019 年 5 月) では、30 名を超える外部コントリビューターからの 87 コミットが master ブランチへマージされ、これは同期間の全コミットの約 24% にあたるとされています。内容はデバイスモデルの virtio 仕様準拠、1 GiB の huge page を持たない CPU への対応、メモリモデルの改善に加え、ドキュメント・API 仕様・テスト・バグ修正にも及びました。同じ期間に外部から約 1 ダースのバグ報告も寄せられています。第 2 に、エコシステムの拡大です。Firecracker は AWS 以外の環境でも利用可能で、公式が挙げた初期の連携例には Kata Containers、UniK、OSv があり、Intel の Cloud Hypervisor も rust-vmm・Firecracker・crosvm のコードを活用して登場しました。Fly.io や Koyeb などのクラウドプラットフォームも Firecracker を採用しています。Firecracker のエコシステムが広がれば、Firecracker 上で動作するワークロードが増え、結果的に AWS への移行も容易になります。第 3 に、人材採用です。Firecracker のような先端技術をオープンソースで公開することは、優秀なシステムプログラマーを惹きつける強力な採用ツールになります。Firecracker は Rust で書かれており、Rust コミュニティからの注目も高いです。公式報告では 2019 年 5 月時点で GitHub の fork が 450 を超え、コミュニティの Slack には 900 人以上が参加していました。containerd から Firecracker のマイクロ VM をコンテナとして扱う firecracker-containerd のような連携も進み、Lambda と Fargate という AWS の基幹サービスを支える土台が、そのまま外部でも使える技術として広く採用されています。
参考資料 (AWS 公式)
本ページの一次情報は AWS 公式サイトおよび公式ドキュメントです。最新の仕様 / 料金は次の公式ページで確認できます。
本ページと公式ドキュメントの記述が食い違う場合は、公式ドキュメントを正としてください。