AWSが“Firecracker”をリリース - コンテナとサーバレスワークロードのためのRustベースのオープンソースmicroVM

AWS re:Invent 2018で、AmazonがFirecrackerのリリースを発表した。“マルチテナントなコンテナと関数ベースのサービスを開発し、安全に管理する”ことを目的に構築された、オープンソースの仮想テクノロジだ。Firecrackerは、Rustで記述されたオープンソースのVMMであるChromium OS's Virtual Machine Monitor(crosvm)からのフォークで、そのテクノロジはAmazonのAWS FargateやAWS Lambdaサービスを支えるために使用されている。

AWS Open Sourceブログによると、Firecrackerは、マイクロ仮想マシンあるいは“microVM”のデプロイを実現する、新たな仮想化テクノロジだ。Kata ContainersやgVisorといった、既存の軽量VMプロジェクトとほぼ同じ手法を用いるFirecracker microVMは、従来のVMが持つセキュリティやワークロード分割と、コンテナによって実現される速度やリソース効率を両立することを目的としている。AWSチーフエバンジェリストのJeff Barr氏によると、AWSの“サーブレス”サービスの人気が高まっていることが、Firecracker開発のモチベーションになったという。

[AWS Lambdaをローンチした時には]強力なセキュリティとカスタマ間のアイソレーションを提供するために、カスタマ毎のEC2インスタンスを使用していました。Lambdaが普及するにつれて、LambdaやFarhgateといったサービスのために、高度にセキュアでフレキシブル、かつ効率的なランタイム環境を提供するテクノロジの必要を感じたのです。ハードウェア仮想化テクノロジを使った分離型EC2インスタンス構築の経験を活かして、コンテナエコシステムに統合可能な、分離型のVMM構築の開発に着手しました。

Firecrackerの中核にあるのは、LinuxのKVM(Kernel-based Virtual Machine)を使用した仮想マシンモニタ(VMM)である。Firecrackerはミニマリストデザインを採用しており、各マイクロサービスのメモリフットプリントとセキュリティ攻撃対象領域を削減するために、不必要なデバイスやゲスト向け機能は排除されている。デバイスは、virtio-net、virtio-block、シリアルコンソール、microVMを停止すつためにのみ使用されるワンボタンのキーボードコントローラの４つのみだ。カーネルローディングプロセスの合理性とも相まって、125ms以下の起動時間を実現している、とAWSは主張する。

プロジェクトのGitHubリポジトリには設計判断に関する詳細な資料があり、コアアーキテクチャの選択について論じられている。例えば、Forecrackerの各プロセスはただひとつのmicroVMにカプセル化されており、このプロセスでAPI、VMM、vCPU(複数)の各スレッドが動作する。仕様資料には、“コンテナとサーバレスワークロードを最小限のオーバーヘッドで実行する”ことを可能にするという、Firecrackerの公約を定量化したランタイム保障が記載されている。これらの仕様は、PRやマスタブランチのマージ毎に実施されるインテグレーションテストによって拡張され、ハイパースレッディングを有効にしたベアメタルのl3.metalインスタンスで実行される。

FirecrackerにはRESTfulなコントロールAPIが用意されており(OpenAPIフォーマットで定義されている)、microVMのリソース使用率制限を処理する。ホストとゲスト間でコンフィギュレーション情報を共有するためのmicroVMメタデータサービスも提供されている。APIスレッドはFirecrackerのAPIサーバと関連するコントロールプレーンに関するすべての責務はAPIスレッドが担う。このスレッドが仮想マシンのファストパスに入ることはない。

VMMスレッドは、“マシンモデル、最小限のレガシデバイスモデル、microVMメタデータサービス(MMDS)、VirtIOデバイスがI/Oレートおよび制限も含めて完全にエミュレートする NetおよびBlockデバイス”を公開する。vCPUスレッドはひとつないし複数(ゲストCPUのコア単位)存在し、KVMによって生成され、KVM RUNメインループを実行し、デバイスモデル上で同期I/OとメモリマップドI/O操作を行う。

Firecrackerは4.14以降のカーネルを持つLinixホストとLinuxゲストOSで動作する。現在はIntel CPUがサポート対象だが、AMDおよびArmのサポートも計画中だ。一般的なコンテナランタイムとも統合されており、firecracker-containered実装のプロトタイプがGitHubにある。元々このプロジェクトでは、microVM毎にひとつのコンテナをローンチすることが可能である。スケジューリングフレームワークであるHashiCorpのNomadでのFirecrackerサポートも、未解決のイシューとして残っている。

firecracker-containerdのロードマップには、このプロジェクトは“コンテナ化されたさまざまなアプリケーションを実行可能なドロップインコンポーネント”を目的としたものであり、当面はOpen Container Initiative(OCI)とContainer Networking Interface (CNI)のサポート開発が計画中である、と述べられている。このプロジェクトの完了時には、一般的なKubernetesコンテナオーケストレーションフレームワークでFirecrackerのワークロードを実行することが可能になるはずだ。

セキュリティの観点からは、すべてのFirecracker vCPUスレッドは、実行開始時点から悪意のあるコードを実行していると見なされるため、“これら悪意を持ったスレッドはコンテナ化しなければならない”。封じ込めは、“信頼性が最低または安全性が最低(ゲストvCPUスレッド)”から“信頼性または安全性が最高(ホスト)”までを実装した、複数の“信頼ゾーン”を重ねることで実装されている。運用環境では、Firecrackerはjailer(看守)バイナリを介してのみ実行するべきだ(現在はFirecrackerバイナリを直接実行可能だが、将来のリリースでこの機能は削除される予定である)。

Firecracker jailerバイナリは、パーミッションの昇格(cgroupやchrootなど)に必要なシステムリソースをセットアップした上でFirecrackerバイナリにexec()し、権限を持たないプロセスを実行する。これ以降のFirecrackerは、例えばchroot内へのファイルのコピーやファイルディスクリプタの転送などによって、特権を持つサードパーティが許可したリソースのみにアクセスできるようになる。Firecrackerが使用可能なシステムコールをさらに制限するために、Seccompフィルタが使用されている。

AWSのプリンシパルオープンソーステクノロジストであるArun Gupta氏と、シニアプロダクトマーケティングマネージャのLinda Lian氏によれば、Firecrackerはカスタマや開発者コミュニティからのコントリビューションを積極的に求めているということだ。FirecrackerはApache Licenseバージョン2.0でライセンスされている。Crosvmコードの部分についてはBSD-3-Clauseライセンスである。プロジェクトの目的に沿ったものであれば、どのようなコントリビューションも歓迎される。

Heptio(先日VMwareによって買収された)の創設者でCTOのJoe Beda氏は、関連するTwitterスレッドの中で、プロジェクトのメンテナのリストはあるが、現時点ではプロジェクトに携わるAmazonチームのリストに過ぎず、“外部メンテナに対する規定があるとは思えない”と記している。さらに氏は、CLA(Contributor Licence Agreement)やDCO(Developer Certificate of Origin)のないことも指摘している。

Firecrackerに欠けているもののひとつがDCOないしCLAです。これは非常に驚くべきことです。外部のコントリビュータを受け入れる場合には、このどちらかを用意するのが普通です。外部PRの参加が始まったら、この状況が可能な限り早急に 修正されることを期待しています。どのようなものになるのか、興味深いところです。

Gupta氏はフィードバックを提供したBeda氏に謝意を述べるとともに、“私たちはコミュニティやユーザの声を積極的に聞いて、進化していきます！”と述べている。

FirecrackerのGitHubリポジトリでは、詳細なスタートアップガイドが提供されている。Katacodaチームも、ローカルへのインストールを望まない開発者のために、インタラクティブなWebベースのスタートアップのためのチュートリアルを提供している。

Firecrackerに関する詳細な情報は、プロジェクトのWebサイト、FirecrackerのGitHiubリポジトリ経由、あるいはSlackスペース経由で入手可能だ。