このエントリーについて
このエントリーを書き始めた経緯は下記にあります。
1. はじめに(Introduction)
サーバーレスコンピューティングは、[4、16、50、51]などのパブリッククラウド環境と[11、41]などのオンプレミス環境の両方で、ソフトウェアやサービスをデプロイ、管理するためにますます一般的になっているモデルです。サーバーレスモデルは、サーバーの運用やキャパシティ管理、自動スケーリング、従量制の価格設定、イベントおよびストリーミングデータのソースとの統合など、いくつかの理由において魅力的です。コンテナは、Dockerによって最も一般的なかたちで具体化され、運用オーバーヘッドの削減や管理性の向上など、同様の理由で一般的になっています。コンテナとサーバーレスは、従来のサーバープロビジョニング処理に比べて明確な経済的利点を提供します。マルチテナンシーにより、多数のワークロードでサーバーを共有でき、新しい機能とコンテナをミリ秒単位でプロビジョニングできるため、需要の変化に応じてワークロード間でキャパシティをすばやく切り替えることができます。サーバーレスは、ビデオエンコーディング[13]、線形代数[20、53]、および並列コンパイル[12]のスケールアウトに関する研究を含む、研究コミュニティ[21,26,27,44,47]の注目を集めています。
マルチテナンシーは、その経済的効果にもかかわらず、ワークロードを互いに分離する上で大きな課題があります。ワークロードは、セキュリティと運用上の懸念の両方のために分離する必要があります。セキュリティ上分離することで、あるワークロードは別のワークロードに属するデータにアクセスしたり推測したりすることはできなくなりますし、運用上分離することで、ノイジーネイバーの影響によって他のワークロードの実行が遅くなることがなくなるからです。クラウドインスタンスプロバイダー（AWS EC2など）は同様の課題に直面しており、ハイパーバイザーベースの仮想化（QEMU/KVM[7、29]やXen[5]など）を使用するか、マルチテナンシーを回避してベアメタルインスタンスを提供することでそれらを解決しました。サーバーレスおよびコンテナモデルにより、従来のインスタンスモデルよりも多くのワークロードを単一のマシンで実行できます。これにより、マルチテナンシーの経済的利点が増幅されますが、分離に必要なオーバーヘッドも増加します。
DockerやLXCなどのLinux上での典型的なコンテナのデプロイは、Linuxカーネルに組み込まれた分離メカニズムに依存することにより、この集約度の課題に対処します。これらのメカニズムには、プロセスのグループ化、リソース調整、およびアカウンティングを提供するcgroupや、プロセスID（PID）などのLinuxカーネルリソースを分離するnamespace、システムコールへのアクセスを制御するseccomp-bpfが含まれます。これらのツールを組み合わせることで、コンテナを分離するための強力なツールキットが提供されますが、単一のオペレーティングシステムカーネルに依存するため、セキュリティとコードの互換性の間には根本的なトレードオフがあります。コンテナの実装者は、制限された呼び出しを必要とするコードを壊す代償にシステムコールを制限することで、セキュリティの改善が見込めますが、これは難しいトレードオフをもたらします。サーバーレスおよびコンテナサービスの実装者は、ハイパーバイザーベースの仮想化（およびそれに関連する潜在的に許容できないオーバーヘッド）とLinuxコンテナ（および関連する互換性とセキュリティのトレードオフ）のどちらかを選択することになります。我々はこのどちらも選びたくなかったため、Firecrackerを作りました。
Kata Containers[14]、IntelのClear Containers、NECのLightVM[38]などの他のプロジェクトは、分離の改善の必要性を認識し、それを実現する方法としてハイパーバイザーベースの仮想化を選択しています。QEMU/KVMはこれらのプロジェクトの大部分（Kata Containersなど）のベースでしたが、その他（LightVMなど）は、スリム化したXenに基づいています。QEMUはこれらのプロジェクトの成功した基盤でしたが、大規模なプロジェクト（QEMU 4.2で140万LOC以上）であり、オーバーヘッド、セキュリティ、高速起動などの機能よりも柔軟性と機能の完全性に重点を置いています。
FirecrackerではKVMを使い続ける選択をしましたが、QEMUを完全に置き換えて、MicroVMを管理および構成するための新しい仮想マシンモニター（VMM）、デバイスモデル、およびAPIを構築しました。Firecrackerは、KVMとともに、コンテナとファンクションの間の分離を実装するための新しい基盤を提供します。提供される最小のLinuxゲストカーネル構成により、コンテナあたり5MB未満のメモリオーバーヘッドを提供し、125ms未満でアプリケーションコードを起動し、ホストあたり毎秒最大150個のMicroVMを作成できます。2018年12月に、Apache 2ライセンスでFirecrackerをオープンソースソフトウェアとしてリリースしました。Firecrackerは2018年からLambdaの本番環境で使用されており、毎月数百万のワークロードと数兆のリクエストを処理しています。
セクション2では、LambdaとFargateの分離ソリューションの選択について検討し、コンテナ、言語VMの分離、および仮想化を比較します。セクション3では、Firecrackerの設計について説明します。セクション4では、Lambdaのコンテキストにおいて統合の方法と、そのサービスのパフォーマンスと経済面で果たす役割について説明します。セクション5では、パフォーマンス、集約度、オーバーヘッドについて、Firecrackerと他のテクノロジーを比較します。
1.1 Specialization
Firecrackerは、サーバーレスおよびコンテナアプリケーション専用に構築されました。Firecrackerが広く有用であり、Firecrackerが他の分野で採用されるのを楽しみにしていますが、Firecrackerのパフォーマンス、集約度、および分離の目標は、サーバーレスおよびコンテナでの利用のために設定されました。明確な目標セットのためにVMMを開発し、ゲストの属性や要件について想定することは、すべての用途に適したVMMを開発するよりもはるかに簡単でした。これらの単純化された前提は、Firecrackerの設計と実装に反映されています。この論文では、AWS Lambdaで使用されているFirecrackerのコンテキストを説明し、決定を下した理由と、既存のVMMの設計との相違点を説明します。LambdaでのFirecrackerの使用方法の詳細については、セクション4.1で説明します。
Firecrackerは、特にQEMUと比較したときに提供しないものにおいて注目を集めるでしょう。BIOSを提供せず、任意のカーネルを起動できず、レガシーデバイスやPCIをエミュレートせず、VM移行をサポートしません。Firecrackerを大幅に変更しない限り、FirecrackerはMicrosoft Windowsを起動できませんでした。FirecrackerのVMごとのプロセスモデルは、VMオーケストレーション、パッケージ化、管理、またはその他の機能を提供しないことも意味します。コンテナスタック内のDockerやKubernetesではなく、QEMUを置き換えます。シンプルさとミニマリズムは、開発プロセスの明確な目標でした。オーケストレーションやメタデータ管理などの高レベルの機能は、Kubernetes、Docker、containtedなどの既存のオープンソースソリューションによって、またはAWSサービス内の独自の実装によって提供されます。追加のデバイス（USB、PCI、サウンド、ビデオなど）、BIOS、およびCPU命令エミュレーションなどの下位レベルの機能は、一般的なサーバーレスコンテナおよび機能のワークロードには必要ないため、単に実装されていません。
