Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

TomoyaIwata
February 15, 2023

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

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

TomoyaIwata

February 15, 2023
Tweet

More Decks by TomoyaIwata

Other Decks in Programming

Transcript

  1. SnapStartの未来についての期待と妄想
    2023年2⽉15⽇
    クラスメソッド CX事業本部 岩⽥ 智哉
    1

    View Slide

  2. 2
    ⾃⼰紹介
    l
    CX事業本部 Delivery部 サーバーサイドチーム
    l
    元サーバーレス開発部
    l
    好きなAWSサービス Lambda
    l
    回るのが好き
    岩⽥ 智哉

    View Slide

  3. 3
    アジェンダ
    l
    SnapStartの概要
    l
    SnapStartで使われている技術
    l
    今後についての期待と妄想

    View Slide

  4. 4
    SnapStartの概要

    View Slide

  5. 5
    re:Invent 2022のキーノートにて発表
    AWS re:Invent 2022 - Keynote with Peter DeSantisより
    https://youtu.be/R11YgBEZzqE

    View Slide

  6. 6
    SnapStartの概要
    l
    コールドスタートのレイテンシを改善
    する機能
    l
    Init処理終了後のLambda実⾏環境のス
    ナップショットを取得して再利⽤する

    View Slide

  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フェーズ

    View Slide

  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

    View Slide

  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を起動

    View Slide

  10. 10
    ランタイムフック
    l
    beforeCheckpoint
    l
    スナップショット作成前に実⾏されるフックポイント
    l
    初期化コードの制限時間にカウントされる
    l
    制限時間=Max(130s, 設定されたタイムアウト時間)
    l
    afterRestore
    l
    Restoreフェーズの最後に実⾏されるフックポイント
    l
    2秒以内に完了させる必要がある

    View Slide

  11. 11
    Provisioned Concurrencyとの違い
    l
    Provisioned Concurrencyはコールドスタートを
    発⽣させないための技術
    l
    とはいえ設定値以上のアクセスが来るとコール
    ドスタートが発⽣する
    l
    SnapStartはコールドスタートを⾼速化する技術

    View Slide

  12. 12
    制限事項①
    サポートされるランタイムは
    Java11(corretto)だけ︕︕

    View Slide

  13. 13
    制限事項②
    l
    Provisioned Concurrency
    l
    Arm64アーキテクチャ
    l
    EFS統合
    l
    アクティブトレース(X-Ray)の有効化
    l
    512 MB以上のエフェメラルストレージ(/tmp)
    SnapStartは以下の機能と併⽤不可

    View Slide

  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でチェック可能

    View Slide

  15. 15
    SnapStartで
    使われている技術

    View Slide

  16. 16
    Lambda実⾏環境についておさらい
    https://docs.aws.amazon.com/pdfs/whitepapers/latest/security-overview-aws-lambda/security-overview-aws-lambda.pdf
    Firecrackerを使ってMicroVMと呼ばれる軽量の仮想マシンを実⾏

    View Slide

  17. 17
    FirecrackerはSnapShotの取得・リストアに対応
    l
    PUT /snapshot/create
    l
    スナップショット作成
    l
    PUT /snapshot/load
    l
    スナップショットを読み込む
    l
    PATCH /vm
    l
    MicroVMを停⽌/再開する

    View Slide

  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

    View Slide

  19. 19
    予想当たってた⾃慢させて下さい

    View Slide

  20. 20
    FirecrackerのSnapShot機能概要
    l
    microVMの状態を2つのファイルで管理
    l
    ゲストOSのメモリのコピー
    l
    デバイスのモデルとエミュレーション状態
    l
    スナップショットは2種類
    l
    Full(完全)
    l
    Diff(差分= Incremental)

    View Slide

  21. 21
    SnapShot取得の流れ
    l
    vCPUの停⽌と状態のシリアライズ
    l
    まずはvCPUを停⽌し、スナップショット取得中にMicroVMの状態が変更されないよ
    うにする
    l
    状態の保存
    l
    KVMと通信するために使⽤している内部データ構造を全てシリアライズして保存
    l
    仮想デバイスのシリアライズ
    l
    MMIOデバイスをシリアライズして保存
    l
    メモリの同期
    l
    ゲストOSのダーティーページをメモリマップファイルにフラッシュ

    View Slide

  22. 22
    SnapShotリストアの流れ
    l
    スナップショットのチェック
    l
    ファイルがFirecrackerのスナップショットとして妥当であるかのチェック
    l
    メモリの復元
    l
    メモリマップファイルからゲストOSのメモリを復元
    l
    vCPUの再作成
    l
    保存されたMicroVMの状態を読み取り、必要な数のvCPUを再作成
    l
    デバイスの状態を復元
    l
    PIOデバイスは状態を持たないため再作成
    l
    MMIOデバイスは再作成され、保存された状態を復元
    l
    vCPUの再開

    View Slide

  23. 23
    SnapStartもDiff SnapShotを利用しているはず
    AWS re:Invent 2022 - Keynote with Peter DeSantisより
    https://youtu.be/R11YgBEZzqE

    View Slide

  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
    収束暗号化でセキュアな重複排除を実現

    View Slide

  25. 25
    今後についての
    期待と妄想

    View Slide

  26. 26
    ここからは話半分ぐら
    いで聞いて下さい

    View Slide

  27. 27
    Java11以外のランタイムに対応する︖︖
    l
    SnapShot⾃体はFirecrackerの機能
    l
    Firecrackerモデルでしか使えない

    View Slide

  28. 28
    Lambdaの実⾏モデルは2種類ある(あった︖)
    EC2モデル
    Lambdaローンチ直後から利⽤
    Firecrackerモデル
    2018年からEC2モデルと並⾏利⽤
    2019年時点のSecurity Overview of AWS Lambdaより引用

    View Slide

  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

    View Slide

  30. 30
    EC2モデルを使ってるから
    スナップショットが使えないという
    ランタイムは無さそう?

    View Slide

  31. 31
    SnapStartサポートの障害になりそうなポイント

    セキュリティ

    ランタイムフックの実装

    beforeCheckpoint & afterRestore

    これはあまり⼤変ではないと勝⼿に予想

    View Slide

  32. 32
    最⼤の障害はセキュリティ︖
    AWSにとって
    セキュリティ=ジョブゼロ
    セキュリティは他の何よりも優先される
    SnapStartによってセキュリティ上の問題が発⽣しないように、各ランタイ
    ムの検証と必要に応じてパッチの適⽤が必要になる

    View Slide

  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

    View Slide

  34. 34
    勝⼿な妄想…
    EOLの迫っているAmazon Linuxを今からSnapStartに対応させ
    るのは労⼒に合わないのでは︖︖
    https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/lambda-runtimes.html

    View Slide

  35. 35
    SnapStartサポートの障壁になりそうなもの

    各⾔語ランタイムのセキュリティテスト

    (上記結果次第で)パッチ作成

    AWSが⽅針をコントロールできるCorrettoに⽐べると時間
    がかかりそう

    各⾔語のメインラインからforkするのもあり︖︖どうなる︖

    View Slide

  36. 36
    次にSnapStartがサポートされるランタイムは︖
    カスタムランタイムなら⾔語レベルの検証が不要では︖︖
    なんせ⾔語が⾃由なので
    AmazonLinux2はJava11(Corretto)で実績があるのでSnapStart
    対応の障害になりそうなものは少ないように思う

    View Slide

  37. 37
    とはいえ…

    カスタムランタイムを利⽤しているユーザーは
    そんなに多く無さそう

    カスタムランタイムにおけるコールドスタート
    のペナルティ⼤⼩は実装依存

    View Slide

  38. 38
    ということで…
    アーキテクチャ的にコールドスタートの
    ペナルティが⼤きくなりがちなdotnet系
    ランタイムが次の本命と勝⼿に予想しま
    す︕︕

    View Slide

  39. 39
    Firecrackerのissueから対応時期が読める︖
    他のランタイムへのSnapStart適⽤可否はFirecrackerの
    issueが関連しているかもしれない。してないかもしれない。
    https://github.com/firecracker-microvm/firecracker/issues

    View Slide

  40. 40
    まとめ
    2023年もLambdaの
    さらなる進化に期待︕︕

    View Slide

  41. 41

    View Slide