はじめに
はじめまして。マクアケという会社でエンジニアをしている @inooka です。
この記事は、Makuake Product Team Advent Calendar 2018 10日目の記事です。
今回は re:Invent で発表されたプロジェクトの中で気になった Firecracker について書きたいと思います。
よろしくお願いします。
AWS Lambda & Firecracker
今年の re:Invent 2018 では Lambda の新機能（Ruby, Custome runtime対応、ALB対応など）の追加が目立ち、今後も注力していく意思を感じました。
また 「Under the Hood of AWS Lambda」 というセッションでは Lambda のバックエンドのしくみを解説しています。
https://www.youtube.com/watch?v=QdzV04T_kec
この中で Firecracker という Lambda を支えている技術の話がでてきます。
（動画の27分ぐらいから）
Firecracker は 11/26 の「Monday Night Live」 でオープンソース化の発表もされていて、面白そうだったので調べてみました。
Firecrackerとは
Firecracker は、KVM 上で動作するVirtual Machine Monitor (VMM) を実装した仮想化技術で、現在 Lambda や Fargate などサーバレスアーキテクチャのサービスで利用されています。
https://firecracker-microvm.github.io/
KVM はハイパーバイザの一つで、ホストとなる一つのハードウェアの上で複数のゲストOSを起動するための技術です。同じハイパーバイザとして他には Xen などがあります。
KVMは10年以上前からある技術なのですが、Firecracker はその上で microVM と呼ばれる軽量な VM を素早く大量に起動することを可能にしています。
その microVM 上でゲストOSやコンテナなどが起動しているようです。
下の図のようなイメージで紹介されています。
インスタンスはベアメタルを使っているようですね。
Firecracker は Rust で書かれており、最初は crosvm - The Chrome OS Virtual Machine Monitorという VMM プロジェクトで始まったのが、派生して独立したプロジェクトになったようです。
なぜ作ったか
2014年にリリースされた Lambda は当初はセキュリティを意識し、顧客ごとに個別のEC2を立てて、その上で起動していました。
しかし、規模が大きくなり Fagate などのプロダクトもリリースされ、強いセキュリティを維持しつつより拡張性のあるしくみが必要と考えるようになり開発を始めたそうです。
顧客毎に EC2 個別だと拡張性が損なわれるが、同居させるとセキュリティの懸念がある。
この２つを解決するために生まれたのだと解釈しました。
※ここで「顧客」という言葉を使ってますが、これは原文を直訳してます。
特徴
ミッション
Firecracker は下記ミッションを持っています。
Our mission is to enable secure, multi-tenant, minimal-overhead execution of container and function workloads.
- enable secure
- 強いセキュリティ
- multi-tenant
- 一つのインスタンスに異なるアカウントを含めた複数のゲストOS + Function を同居可能にする
- minimal-overhead
- 軽量なVMを素早く大量に起動可能に
ということを表しているのかと思いました。
Tenets
開発でのガイドラインとして以下が定義されています。
Built-In Security: We provide compute security barriers that enable multi-tenant workloads, and cannot be mistakenly disabled by customers. Customer workloads are simultaneously considered sacred (shall not be touched) and malicious (shall be defended against).
Light-weight Virtualization: We focus on transient or stateless workloads over long-running or persistent workloads. Firecracker's hardware resources overhead is known and guaranteed.
Minimalist in Features: If it's not clearly required for our mission, we won't build it. We maintain a single implementation per capability.
Compute Oversubscription: All of the hardware compute resources exposed by Firecracker to guests can be securely oversubscribed.
- セキュアであること
- 無駄な要素は排除して、ミニマム構成を意識する（オーバーヘッドを最小限に）
- ハードウェアのリソースを最大限に利用する
などについて重要視しているように見えます。
Compute resources の考え方については、セッションの中でも複数台のインスタンスを平均的に利用するのではなく、各インスタンスのリソースを99%まで使い切り、残りは0%で開けておいて Auto scaling 可能な状態にしておくのが良い、などの説明もありました。
パフォーマンス
パフォーマンス的な話では以下についての内容が公表されています。
- 起動速度
- 1 microVM を 約 125ms で起動することが可能
- オーバーヘッド
- 1 microVM あたりで消費するメモリは 約 5 MiB
- 1インスタンスにさまざまなCPU、メモリ構成を持った数千のVMをセキュアに起動することが可能
最後に
今回は Firecracker について簡単にまとめてみましたが、正直まだ分からないことだらけです。
しかしコアな技術をオープンソースとして公開はAWSでは今まではあまり無かったと思うので、とても刺激があり興味がそそられました。
今後の動きについても注目していきたいと思います。
また、今回紹介したセッションのように Under the Hood シリーズが他のAWSサービスでもたくさん公開されています。
以前、Aurora のセッションが日本であり聞いたのですが面白かったので、他もいろいろチェックしてみたいと思います。
参考
https://firecracker-microvm.github.io/
https://github.com/firecracker-microvm/firecracker
https://aws.amazon.com/jp/blogs/aws/firecracker-lightweight-virtualization-for-serverless-computing/
https://www.slideshare.net/AmazonWebServices/a-serverless-journey-aws-lambda-under-the-hood-srv409r1-aws-reinvent-2018
https://www.youtube.com/watch?v=QdzV04T_kec