https://dshimizu.hatenablog.com/entry/2024/08/11/000000

はじめに

Firecracker に関する論文を読んでのメモです。

とりあえず1章で概要を大まかに掴むことができました。 Firecrackerが開発されるに至った経緯、従来のコンテナや仮想化を利用するにあたってマルチテナントでのリソース分離とセキュリティのバランス, Firecrackerのベースの仕組み(KVM + microVM (Quemu からの置き換え))のメリデメなどが簡単に解説されていました。

https://www.usenix.org/system/files/nsdi20-paper-agache.pdf

Dockerのコンテナの場合、(dockerd + containerd + )runC でLinux カーネルの上に複数のコンテナプロセスを起動するようなイメージですが、Firecrackerでコンテナを起動する場合、firecracker-containerd を利用してLinux カーネルの上に複数のmicroVM(FirecrackerでのKVM)を起動してそこでコンテナを起動する、といったようなイメージのように思いました。これにより隔離性を持たせつつ、起動のスピードもある程度高めようとしているようです。

メモ

書きかけです

1. Abstruct


Firecrackerが開発されるに至った経緯、従来のコンテナや仮想化とFirecrackerのベースの仕組み(KVM + microVM (Quemu からの置き換え))のメリデメなどが簡単に解説されていました。
また、各章でその詳細について記載されています。

---
サーバーレスなコンピューティング基盤を顧客に提供するためには、1つのハードウェア上で複数の顧客のワークロードを稼働させつつも、セキュリティとパフォーマンスを適切に分離し、複数の顧客のワークロードを最小限のオーバーヘッドで同じハードウェアで実行することが求めれている。
従来の考え方では、強力なセキュリティはありながら高いオーバーヘッドの仮想化と、セキュリティレベルが低下するもののオーバーヘッドが最小限のコンテナテクノロジのどちらかを選択する必要がある。

このトレードオフは、強力なセキュリティと最小限のオーバーヘッドの両方を必要とするパブリック インフラストラクチャ プロバイダーには受け入れられません。このニーズを満たすために、私たちは Firecracker を開発した。

Firecracker は、サーバーレス ワークロードに特化した新しいオープン ソースの仮想マシンモニター(VMM) ですが、合理的な一連の制約内では、コンテナ、関数、その他のコンピューティング ワークロードにも一般的に役立つ。
Amazon Web Services (Lambda と Fargate) の 2 つの公開サーバーレス コンピューティング サービスに Firecracker をデプロイし、数百万の運用ワークロードと毎月数兆のリクエストをサポートしている。

サーバーレスに特化することで Firecracker の設計がどのように変わったか、また Lambda のお客様を Firecracker にシームレスに移行することで何を学んだかについて説明する。
---


1 Introduction

Firecrackerの概要について簡単に解説されています。

サーバーレスモデルは、サーバーの運用と容量管理の作業の削減、自動スケーリング、従量課金制、イベント ソースとストリーミング データとの統合など、いくつかの理由で魅力的であり、Docker によって最も一般的に実現されるコンテナーは、運用オーバーヘッドの削減や管理性の向上など、同様の理由で人気が高まっている。

コンテナーやサーバーレスは、従来のサーバープロビジョニングプロセスに比べて、サーバーの運用と容量管理の作業の削減、自動スケーリング、運用管理面で明確な経済的利点を提供しており、人気が高くなっていると記載されている。
しかし、マルチテナントとして実行する場合には、セキュリティ (1 つのワークロードが別のワークロードに属するデータにアクセスしたり推測したりできないようにするため) と運用上の懸念 (1 つのワークロードのノイジーネイバー効果によって他のワークロードの実行速度が低下しないようにするため)があり、異なる顧客間ではワークロードを互いに分離する必要がある、というのが大きな課題となっているとのこと。
クラウドインスタンスプロバイダー (AWS EC2 など) も同様の課題に直面しており、ハイパーバイザーベースの仮想化 (QEMU/KVM や Xen など) を使用するか、マルチテナンシーを回避してベアメタルインスタンスを提供することで解決している。

サーバーレスやコンテナモデルでは、この従来のインスタンスモデルよりも多くのワークロードを単一のマシンで実行できるため、マルチテナンシーの利点が増えるが、分離に必要なオーバーヘッドも増加するため、Linux 上の一般的なコンテナ デプロイメント (Docker や LXC を使用するものなど) では、Linux カーネルに組み込まれた分離メカニズム(プロセスのグループ化、リソースのスロットリング、アカウンティングを提供するコントロール グループ (cgroup)、プロセス ID (PID) などの Linux カーネル リソースを名前空間に分離する名前空間、およびシステム コールへのアクセスを制御する seccomp-bpf など)を利用して、この密度の課題に対処している。

これらのツールを組み合わせると、コンテナを分離するための強力なツールキットが提供されますが、単一のオペレーティング システム カーネルに依存しているため、セキュリティとコード互換性の間には根本的なトレードオフがあります。コンテナ実装者は、システム コールを制限することでセキュリティを向上させることができるが、その代償として、制限された呼び出しを必要とするコードが壊れることがあるという難しいトレードオフが発生する。

サーバーレスやコンテナサービスの実装者は、ハイパーバイザ ベースの仮想化 (およびそれに関連する許容できない可能性のあるオーバーヘッド) と Linux コンテナ (および関連する互換性とセキュリティのトレードオフ) のどちらかを選択できるが、Firecracker を構築したのは、選択を望まなかったからとのこと。

Kata Containers 、Intel の Clear Containers、NEC の LightVM などの他のプロジェクトも同様のところからスタートし、分離の改善の必要性を認識し、それを実現する方法としてハイパーバイザベースの仮想化を選択している。QEMU/KVM はこれらのプロジェクトの大半 (Kata Containers など) のベースとなっていますが、LightVM などは Xen をベースとしているらしい
QEMU はこれらのプロジェクトの成功したベースとなっていますが、大規模なプロジェクト (QEMU 4.2 時点で 140 万 LOC 超) であり、オーバーヘッド、セキュリティ、高速起動よりも柔軟性と機能の完全性に重点を置いている。

Firecracker では、KVM を維持しながら QEMU を完全に置き換え、MicroVM を管理および構成するための新しい仮想マシン モニター (VMM)、デバイス モデル、API を構築することを選択したとのこと。
Firecracker は KVM とともに、コンテナと関数間の分離を実装するための新しい基盤を提供し、最小限の Linux ゲストカーネル構成により、コンテナあたり 5 MB 未満のメモリオーバーヘッド、125 ミリ秒未満でのアプリケーションコードの起動、ホストあたり最大 150 個の MicroVM 毎秒の作成が可能となっている。

Firecracker は、2018 年 12 月に Apache 2 ライセンスの下でオープンソースソフトウェアとしてリリースされた。

* [https://github.com/firecracker-microvm/firecracker:title]
* [https://firecracker-microvm.github.io/:title]

Firecracker は 2018 年から Lambda の本番環境で使用されており、毎月数百万のワークロードと数兆のリクエストを処理している。

セクション 2 では、Lambda と Fargate の分離ソリューションの選択について検討し、コンテナ、言語 VM 分離、仮想化との比較について書かれている
セクション 3 では、Firecracker の設計について説明されている
セクション 4 では、Firecracker を Lambda のコンテキストに当てはめ、Firecracker がどのように統合されているか、またそのサービスのパフォーマンスと経済性において Firecracker が果たす役割について説明されている
セクション 5 では、パフォーマンス、密度、オーバーヘッドに関して Firecracker を他のテクノロジーと比較している

Firecracker に関する論文を読んだメモ

はじめに

メモ

参考