SnapStartの未来についての期待と妄想

2023/2/15に開催された「サーバーレスLT大会 in 肥後橋」の登壇資料です

Transcript

1. SnapStartの未来についての期待と妄想 2023年2⽉15⽇ クラスメソッド CX事業本部 岩⽥ 智哉 1
2. 2 ⾃⼰紹介 l CX事業本部 Delivery部 サーバーサイドチーム l 元サーバーレス開発部 l 好きなAWSサービス Lambda l 回るのが好き 岩⽥ 智哉
3. 3 アジェンダ l SnapStartの概要 l SnapStartで使われている技術 l 今後についての期待と妄想
4. 4 SnapStartの概要
5. 5 re:Invent 2022のキーノートにて発表 AWS re:Invent 2022 - Keynote with Peter DeSantisより https://youtu.be/R11YgBEZzqE
6. 6 SnapStartの概要 l コールドスタートのレイテンシを改善 する機能 l Init処理終了後のLambda実⾏環境のス ナップショットを取得して再利⽤する
7. 7 Lambdaの実⾏モデルについておさらい l Lambda実⾏環境の構築 l MicroVMの起動 ※実際には起動済みのMicroVMを利⽤するケースがほとんど l Inner sandboxの構築 l S3からデプロイパッケージのダウンロード ※⾮コンテナイメージ形式の場合 l Initフェーズ l Extension init l Runtime init l Function init l Invokeフェーズ
8. 8 Lambdaの実⾏モデルについておさらい l Lambda実⾏環境の構築 l MicroVMの起動 ※実際には起動済みのMicroVMを利⽤するケースがほとんど l Inner sandboxの構築 l S3からデプロイパッケージのダウンロード ※⾮コンテナイメージ形式の場合 l Initフェーズ l Extension init l Runtime init l Function init l Invokeフェーズ ここまで終わった段階でMicroVMのスナップショットを 取得して利⽤するのがSnapStart
9. 9 スナップショットからmicroVMを起動すると… l Lambda実⾏環境の構築 l MicroVMの起動 ※実際には起動済みのMicroVMを利⽤するケースがほとんど l Inner sandboxの構築 l S3からデプロイパッケージのダウンロード ※⾮コンテナイメージ形式の場合 l Initフェーズ l Extension init l Runtime init l Function init l Restoreフェーズ l Invokeフェーズ この辺の処理が丸々スキップできるはず︕︕ スナップショットからmicroVMを起動
10. 10 ランタイムフック l beforeCheckpoint l スナップショット作成前に実⾏されるフックポイント l 初期化コードの制限時間にカウントされる l 制限時間=Max(130s, 設定されたタイムアウト時間) l afterRestore l Restoreフェーズの最後に実⾏されるフックポイント l 2秒以内に完了させる必要がある
11. 11 Provisioned Concurrencyとの違い l Provisioned Concurrencyはコールドスタートを 発⽣させないための技術 l とはいえ設定値以上のアクセスが来るとコール ドスタートが発⽣する l SnapStartはコールドスタートを⾼速化する技術
12. 12 制限事項① サポートされるランタイムは Java11(corretto)だけ︕︕
13. 13 制限事項② l Provisioned Concurrency l Arm64アーキテクチャ l EFS統合 l アクティブトレース(X-Ray)の有効化 l 512 MB以上のエフェメラルストレージ(/tmp) SnapStartは以下の機能と併⽤不可
14. 14 SnapStart利⽤時の注意事項 l ⼀意性に注意 l 暗号学的に安全な乱数ジェネレータを使う l java.util.Randomではなくjava.security.SecureRandomを l /dev/randomと/dev/urandomは安全に利⽤可能 l 詳細はSnapStartに関する論⽂参照 l https://arxiv.org/pdf/2102.12892.pdf l AWS Lambda SnapStart Bug Scannerでチェック可能
15. 15 SnapStartで 使われている技術
16. 16 Lambda実⾏環境についておさらい https://docs.aws.amazon.com/pdfs/whitepapers/latest/security-overview-aws-lambda/security-overview-aws-lambda.pdf Firecrackerを使ってMicroVMと呼ばれる軽量の仮想マシンを実⾏
17. 17 FirecrackerはSnapShotの取得・リストアに対応 l PUT /snapshot/create l スナップショット作成 l PUT /snapshot/load l スナップショットを読み込む l PATCH /vm l MicroVMを停⽌/再開する
18. 18 実はre:invent2019の時点で紹介されている https://dev.classmethod.jp/articles/reinvent2019-opn402/ https://youtu.be/yDplzXEdBTI https://d1.awsstatic.com/events/reinvent/2019/Firecracker_open-source_innovation_OPN402.pdf
19. 19 予想当たってた⾃慢させて下さい
20. 20 FirecrackerのSnapShot機能概要 l microVMの状態を2つのファイルで管理 l ゲストOSのメモリのコピー l デバイスのモデルとエミュレーション状態 l スナップショットは2種類 l Full(完全) l Diff(差分= Incremental)
21. 21 SnapShot取得の流れ l vCPUの停⽌と状態のシリアライズ l まずはvCPUを停⽌し、スナップショット取得中にMicroVMの状態が変更されないよ うにする l 状態の保存 l KVMと通信するために使⽤している内部データ構造を全てシリアライズして保存 l 仮想デバイスのシリアライズ l MMIOデバイスをシリアライズして保存 l メモリの同期 l ゲストOSのダーティーページをメモリマップファイルにフラッシュ
22. 22 SnapShotリストアの流れ l スナップショットのチェック l ファイルがFirecrackerのスナップショットとして妥当であるかのチェック l メモリの復元 l メモリマップファイルからゲストOSのメモリを復元 l vCPUの再作成 l 保存されたMicroVMの状態を読み取り、必要な数のvCPUを再作成 l デバイスの状態を復元 l PIOデバイスは状態を持たないため再作成 l MMIOデバイスは再作成され、保存された状態を復元 l vCPUの再開
23. 23 SnapStartもDiff SnapShotを利用しているはず AWS re:Invent 2022 - Keynote with Peter DeSantisより https://youtu.be/R11YgBEZzqE
24. 24 Diff SnapShotとsparse filesystemで効率化 (参考) https://d1.awsstatic.com/events/Summits/reinvent2022/SVS404-R_A-closer-look-at-AWS-Lambda.pdf https://d1.awsstatic.com/events/reinvent/2020/Deep_dive_into_AWS_Lambda_security_Function_isolation_SVS404.pdf https://youtu.be/0_jfH6qijVY https://youtu.be/FTwsMYXWGB0 l チャンク単位に分割しオンデマンドでロード l 多重キャッシュ l 収束暗号化でセキュアな重複排除を実現
25. 25 今後についての 期待と妄想
26. 26 ここからは話半分ぐら いで聞いて下さい
27. 27 Java11以外のランタイムに対応する︖︖ l SnapShot⾃体はFirecrackerの機能 l Firecrackerモデルでしか使えない
28. 28 Lambdaの実⾏モデルは2種類ある(あった︖) EC2モデル Lambdaローンチ直後から利⽤ Firecrackerモデル 2018年からEC2モデルと並⾏利⽤ 2019年時点のSecurity Overview of AWS Lambdaより引用
29. 29 EC2モデルはもう使ってない︖︖ 最新の 「Security Overview of AWS Lambda 」 からはEC2モデルに関する記載が消えている ということは… 全⾯的にFirecrackerモデルへの移⾏が完了した︖ https://docs.aws.amazon.com/pdfs/whitepapers/latest/security-overview-aws-lambda/security-overview-aws-lambda.pdf
30. 30 EC2モデルを使ってるから スナップショットが使えないという ランタイムは無さそう？
31. 31 SnapStartサポートの障害になりそうなポイント • セキュリティ • ランタイムフックの実装 • beforeCheckpoint & afterRestore • これはあまり⼤変ではないと勝⼿に予想
32. 32 最⼤の障害はセキュリティ︖ AWSにとって セキュリティ＝ジョブゼロ セキュリティは他の何よりも優先される SnapStartによってセキュリティ上の問題が発⽣しないように、各ランタイ ムの検証と必要に応じてパッチの適⽤が必要になる
33. 33 SnapStartのためにLinuxカーネル等も修正 https://youtu.be/ZbnAithBNYY https://d1.awsstatic.com/events/Summits/reinvent2022/SVS320_AWS-Lambda-SnapStart-Fast-cold-starts-for-your-Java-functions.pdf
34. 34 勝⼿な妄想… EOLの迫っているAmazon Linuxを今からSnapStartに対応させ るのは労⼒に合わないのでは︖︖ https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/lambda-runtimes.html
35. 35 SnapStartサポートの障壁になりそうなもの • 各⾔語ランタイムのセキュリティテスト • (上記結果次第で)パッチ作成 • AWSが⽅針をコントロールできるCorrettoに⽐べると時間 がかかりそう • 各⾔語のメインラインからforkするのもあり︖︖どうなる︖
36. 36 次にSnapStartがサポートされるランタイムは︖ カスタムランタイムなら⾔語レベルの検証が不要では︖︖ なんせ⾔語が⾃由なので AmazonLinux2はJava11(Corretto)で実績があるのでSnapStart 対応の障害になりそうなものは少ないように思う
37. 37 とはいえ… • カスタムランタイムを利⽤しているユーザーは そんなに多く無さそう • カスタムランタイムにおけるコールドスタート のペナルティ⼤⼩は実装依存
38. 38 ということで… アーキテクチャ的にコールドスタートの ペナルティが⼤きくなりがちなdotnet系 ランタイムが次の本命と勝⼿に予想しま す︕︕
39. 39 Firecrackerのissueから対応時期が読める︖ 他のランタイムへのSnapStart適⽤可否はFirecrackerの issueが関連しているかもしれない。してないかもしれない。 https://github.com/firecracker-microvm/firecracker/issues
40. 40 まとめ 2023年もLambdaの さらなる進化に期待︕︕