🔥

crosvm から firecracker へ - VMM と仮想化 -

2024/05/09に公開

https://zenn.dev/usaneko_xlarge/scraps/d9e9d2d618438e

Firecracker とは

Firecracker は、AWS が開発したオープンソースの仮想マシンモニター(VMM)です。VMM とは、ホストOS上で別のゲストOSを動作させるためのソフトウェアです。従来のVMMと比べ、セキュリティとパフォーマンスを大幅に向上させることを目的に設計されています。

Firecracker の背景

従来の AWS Lambda の課題

AWS Lambda は、イベントをトリガーとしてコードを実行するサーバーレスコンピューティングサービスです。従来のLambdaでは、アカウントごとにVMを用意し、その中で個別のコンテナを動作させていました。しかし、このアプローチには以下の課題がありました。

  • コンテナではセキュリティとアプリケーションの互換性を両立するのが難しい
  • 固定サイズのVMにワークロードを効率的にパッキングするのが難しい
  • 特権の昇格、情報の漏えい、隠れチャネルなどのリスクがある

そこで、以下の要件を満たす新しいアプローチが求められました。

  • 分離 : 同じハードウェア上で複数のワークロードを動かすが、特権昇格や情報の開示、隠れチャネルなどのリスクから守られている
  • オーバーヘッドと密度 : 同じハードウェア上で最小限の無駄で何千ものワークロードを動かせる
  • パフォーマンス : ネイティブに実行したときと同じパフォーマンスで動かせる。また、同じハードウェア上で隣接するワークロードたちのふるまいにかかわらず一定のパフォーマンスで動かせる
  • コード互換性 : ワークロードに含まれている Linux バイナリやライブラリを修正や再コンパイルせず動かせる
  • 迅速なスイッチング : ワークロードの開始と終了を高速に行える
  • 柔軟な分配 : CPU やメモリなどのリソースをオーバーコミットできる。権限のあるリソースを無為に消費するのではなく必要とするリソースだけを消費する

crosvm からの着想

Firecracker の設計では、Google の Chromium OS で使われている crosvm から多くの着想を得ています。crosvm は VMM の一種で、Linux カーネル上で別の OS を動作させるためのソフトウェアです。

crosvm ではコードの削減と seccomp-bpf によるセキュリティ強化、virtioに似たホストとゲスト間のキャッシュの利用による高速データ転送などの工夫がされています。Firecracker ではこれらの設計を参考にしつつ、さらにデバイスドライバを削除してコードの簡素化を図り、セキュリティとパフォーマンスを高めています。

https://youtu.be/7I0LcBlLYT0?si=Kno3T4l5qymeoJJ0

Firecracker の設計

Firecrackerは以下の設計によりセキュリティとパフォーマンスを実現しています。

  • 最小の Trusted Computing Base (TCB) を実現するため、USB や GPU などのデバイスドライバを削除し、ハードウェア仮想化機能のみに特化
  • Linux カーネルのセキュリティ機能である seccomp-bpf を利用し、許可されたシステムコールのみを実行
  • virtioに似たホストとゲスト間のキャッシュの利用による高速データ転送を行うことでオーバーヘッドを削減
  • マイクロ仮想マシン(MicroVM)のオーバーヘッドを最小限に抑え、数千ものワークロードを同じハードウェア上で実行可能

このように、Firecracker は最小のTCBと seccomp-bpfの活用、高速データ転送によりセキュリティを確保しつつ、ネイティブに近いパフォーマンスを実現しています。

Firecracker の AWS Lambda での利用

Firecracker は AWS Lambda でワーカーの仮想化に利用されています。Lambda のフロントエンドでイベントを受け付けると、ワーカーマネージャーがワーカーにタスクを割り振ります。ワーカーの中では Firecracker によって作成された MicroVM 上で実際のコードが実行されます。

Firecracker の起動が高速であることから、プールされた MicroVM の数を最小化でき、さらにリソースの効率的な利用が可能になっています。また、フロントエンドと MicroVM 間は TCP/IP 経由で疎結合されており、セキュリティとスケーラビリティを両立しています。

MicroVM 上では CPU やメモリなどのリソースをオーバーコミットでき、必要最小限のリソースのみを消費します。さらに、リソースの確保と開放が迅速に行えるため、急なワークロードの変動にも対応できます。

このように、Firecrackerを利用することで、Lambdaはセキュリティを確保しつつ、大規模な分散ワークロードを効率的に実行できるようになりました。

Fargate での Firecracker の利用

Firecracker は、AWS の別のコンテナサービスである Fargate でも利用されています。

Fargate はバージョン 1.4 から従来の Docker Engine に代わり、Containerd をコンテナ実行エンジンとして採用しました。Fargate ではデータプレーンに新しい Fargate エージェントを導入し、Containerd と統合しています。この新アーキテクチャでは、FargateはFirecracker microVMを使ってfirecracker-containerdランタイムでコンテナを実行できるようになります。

このように、Firecracker は AWS の主要コンテナサービスである Lambda と Fargate の両方で、セキュリティとパフォーマンスを確保しながら、大規模なコンテナワークロードを実行するために重要な役割を果たしています。




以下、読まなくてもいいです(過去版)




crosvm とは、VMM (バーチャルマシンモニター) とは

crosvm は Linux のカーネル上で別のOSを動かすためのソフトウェア (VMM)。類似するものとしては QEMU や VirtualBox がある。

VMM とハイパーバイザーとの違い

VMM がハードウェアをエミュレートする役割を持つのに対し、ハイパーバイザー、つまり KVM などは CPU の仮想化を担当する。
CPUで直接実行できる命令はゴリゴリゲストOSに実行させられる。その時、ゲストカーネルと CPU が紐づいていないといけないので、紐付けるためにそれぞれのカーネルでのレジスタなどの値を持っておいて、複数のCPUがあるように見せる働きをするのが、ハイパーバイザー。一方で、特権命令やデバイス IO などの命令はホストOSに影響が出る可能性がある。そういった命令に関しては VMM が仲介して、ホスト OS に影響がでないよう処理する。

crosvm のアーキテクチャ、普通の VMM と何が違っているか

  • QEMU や VirtualBox にくらべて、Linux VM を動かす機能に絞って開発されており、他のOSイメージは動かない。これにより、アーキテクチャがシンプルになり、爆発半径が小さくなる。
  • seccomp mode2 を使っている。すなわち、eBPF によりシステムコールのフィルタリングを行い、プロセスが利用できるシステムコールを制限することで、セキュリティを強固にしている。
  • VMM は特権命令やデバイス IO などのホスト OS に影響があるような命令を処理している。この処理をするモードに移行するときのオーバーヘッドは非常に重いので、できるだけなくしたい。そのために、ホストとゲストでキューを共有して、その上でデータをやり取りしている。つまり、virtio のように、デバイスとの通信をキャッシュしたり最適化したりして、ベアメタル並みの速度を実現している。

Chromiumでどのように使われているか

Chromium OS で Linux や Android を動かすのに使われている。たとえば、 Chromium OS でシェルを使いたいときはこれをつかって OS 上に Linux をインストールする。


Firecracker は crosvm から着想に至りました。

Firecracker はどのような要件から実装に至ったか

Firecracker 以前の Lambda は、アカウントごとに VM を用意して、その中でワークロードごとに別のコンテナを動かしていた。
しかし、コンテナではセキュリティを担保しながらコードの互換性を保つことができないことや、ワークロードのコンテナを VM の中に無駄なく配置することが難しいことに不満があった。
そのため、以下の要件を満たすような別の方法を考える必要があり、Firecracker の実装に至った。

  • 同じハードウェア上で複数のワークロードを動かすが、特権昇格や情報の開示、隠れチャネルなどのリスクから守られている
  • 同じハードウェア上で最小限の無駄で何千ものワークロードを動かせる
  • ネイティブに実行したときと同じパフォーマンスで動かせる
    同じハードウェア上で隣接するワークロードたちのふるまいにかかわらず一定のパフォーマンスで動かせる
  • ワークロードに含まれている Linux バイナリやライブラリを修正や再コンパイルせず動かせる
  • ワークロードの開始と終了を高速に行える
  • CPU やメモリなどのリソースをオーバーコミットできる
  • 権限のあるリソースを無為に消費するのではなく必要とするリソースだけを消費する

crosvm とどのような違いがあるか

crosvm にくらべて USB や GPU などのデバイスドライバを削除することでコードを半分程度に減らした。(アーキテクチャがシンプルになり、爆発半径が小さくなる)

Firecracker は AWS の中でどのように使われているか

AWS Lambda というサービスで使われている。

AWS Lambda とは

(簡単に言うと、HTTPリクエストなどのイベントをトリガーとしてコードを実行するサービスです)
AWS Lambda では様々な言語のランタイムを提供しており、ワークロードをコードスニペットで提供することや、HTTP/REST API もサポートしているため、API の中身をあらゆる言語で開発し言語実装とともにバイナリやバンドルとして提供することができる。

Firecracker がどこでどのように使われているのか

具体的に Firecracker がどこで使われているかというと、Lambda では Frontend でイベントをトリガーする命令を受け付け、ワーカーマネージャーがワーカーにそれをわりふるのだが、このワーカーにおいて使われている。
ワーカーの中身はこのようになっている。

Frontend とこの MicroVM の中は、 TCP/IP を介して情報をやり取りしており、疎結合が保たれている(図の λ Shim と Micro Manager の通信)。
ワーカーの中では何千もの MicroVM が実行されており、これはそれぞれひとつの Firecracker によって作成管理されている。Firecracker の起動時間が短いことで、プールされている MicroVM のスロットが少なくても済んでいる。

Discussion