2022/12/20　岡野兼也 Firecracker Snapshottingを調べてみた @Juju_62q

※本発表は一部推測混じりな部分がある他、発表者が読解ミスをしている可能性 があります。そのことにご留意の上温かく聞いていただければ幸いです。

LambdaのSnapStartがすごい！

ということでLambdaのSnapStartを支えている（であろう）技術を調べてみました

岡野兼也 / @Juju_62q 株式会社タイミー プロダクト本部 ワーキングリレーションチーム （Stream Aligned Team） Backend Engineer

目次 ● SnapStartとは ● Firecrackerとは ● Firecracker Snapshotting ● Snapshottingの問題 ● おわりに

1 SnapStartとは

Javaで書いたLambdaがめっちゃ早く動く技術

2 Firecrackerとは

ServerlessのためのMicroVMを素早く動かす軽量VMM

3 Firecracker Snapshotting

Snapshotについておさらい ディスクの中身を保存 保存したファイルから VMを復元

Lambdaでは？（従来） Lambdaを構成するZipファイル （Snapshot） Amazon S3 AWS Lambda Lambdaの実行環境 Lambdaの関数や実行環境 新VMを立ち上げる際にLoad ファイルから初期化&関数実行

Lambdaでは？（SnapStart） Lambdaを構成するZipファイル （Snapshot） Amazon S3 AWS Lambda Lambdaの実行環境 Lambdaの関数や実行環境 +初期化済みメモリ 新VMを立ち上げる際にLoad ファイルから関数実行

つまりメモリが保存されるようになった

In order to make restoring possible, Firecracker snapshots save the full state of the following resources: ● the guest memory, ● the emulated HW state (both KVM and Firecracker emulated HW). The state of the components listed above is generated independently, which brings flexibility to our snapshotting support. This means that taking a snapshot results in multiple files that are composing the full microVM snapshot: ● the guest memory file, ● the microVM state file, ● zero or more disk files (depending on how many the guest had; these are managed by the users). Firecracker.「Firecracker Snapshotting」.https://github.com/firecracker-microvm/firecracker/blob/main/docs/snapshotting/snapshot-support.m d, (2022/12/19) Firecracker Snapshottingの対象

Firecracker Snapshottingの対象 1. ゲストマシンのメモリ 2. VMのHWの状態 3. ディスク（MicroVMについている分）

あ〜なんか行けそう

必要なところ全部コピペってことね ※パフォーマンスやファイル等の共有のためCoWを採用していたりめちゃくちゃ工夫がされています

とはいえ問題があるらしい

4 Snapshottingの問題

アプリケーションでの乱数生成に関して、ユーザランドで動くアプリケーションの実装に よっては十分に乱数であることが保証できない場合があるらしい

ちゃんと動くとされている乱数（諸説あり） Hardware Firecracker MicroVM MicroVM ユーザー空間 ユーザー空間 GetRand

問題がありそうなパターン Hardware Firecracker MicroVM MicroVM ユーザー空間 ユーザー空間 GetRand

現状の対応 1. `/var/lib/systemd/random-seed` などある程度問題の有りそうなファイルを 削除する 2. それ以外に関しては殆どの場合十分に安全 a. できるだけ安全性を上げるにはエントロピープールにカーネルから取得した乱数を追加する b. これにより、乱数生成を再シードする

解決策①: MADV_WIPEONSUSPENDの利用 仮想マシンのSUSPEND時にsnapshotを取ってはいけないメモリをマークする 結果として問題の対象になりそうなメモリをコピーしない これにより、ユーザランドの乱数をカーネルから再生成するようにする

解決策①: MADV_WIPEONSUSPENDの利用 仮想マシンのSUSPEND時にsnapshotを取ってはいけないメモリをマークする 結果として問題の対象になりそうなメモリをコピーしない これにより、ユーザランドの乱数をカーネルから再生成するようにする Linuxカーネルに追加したとのこと

解決策②: SysGenIdの利用 Restoreされたことを検知し、乱数の再生成を可能にする （論文から読み取りきれなかったですが、Issueとかを見る感じはおそらく） Restore等のたびにincrementされるIDを仮想デバイスとして提供し、 値の差分からRestoreされたことを検知する。 Linuxのデバドラとして提供済みとのこと。

Issueの雰囲気的には②が採用されそう？

5 おわりに

感想 プラットフォーマーは悪意のあるコードを前提としないといけないので大変そう たまに少し技術について調べてみると面白い 今度コードも読んでみようかなと思いました

参考にした資料 Firecracker.「Firecracker Snapshotting」.https://github.com/firecracker-microvm/firecracker/blob/main/docs/snapshotting/snapshot-support.md, (2022/12/19) Marc Brooker et al., 2021. Restoring Uniqueness in MicroVM Snapshots

ご清聴ありがとうございました