はじめに
こんにちは！フューチャー Advent Calendar 2022の6日目を担当します、佐藤と申します！
今回はつい1週間前にAWS re:Inventで発表された新機能「Lambda SnapStart」について機能のお試し＋効果の検証を行ってみたので、お伝えして行きたいと思います。
ちょうど気になってたんだよな〜という人も、aws...?lambda...?という人も読めるように書いていますので、どうぞお茶でも飲みながら読んでいただけたらと思います。よろしくお願いします！
Lambda SnapStartとは？
まずLambdaとは？というところですが、一言で言ってしまえば
自分で作った関数を置いといて、何かのトリガーで実行してくれる君
です。
例えば、利用者がログインを試行した時トークンを発行する関数を実行してくれる、あるメールが来た時ストレージにメールを保存する関数を実行してくれる、そんな感じのサービスです。
で、今回追加されたSnapStartについてですが、これも一言で言うと
lambdaのコールドスタートの待ち時間を劇的に減らすことができるオプション
となっていて、これはAWS最大のイベントであるre:Inventで、しかも初日に発表されたものなので期待大...!なものです。
※コールドスタート...電源を入れてない状態から何か実行することで、要するに時間がかかると思えばOK
具体的には、コールドスタートにおける
- lambdaがコールされる
- 新しいMicroVMを起動する
- 全ての言語ランタイムをプリインストールする
- （自分達が実際に書いた）関数を実行できる形に変換する
- 言語ランタイムに応じた初期化処理を行う
- 関数を実行する
というプロセスにおける、5.のスナップショットを取得し、次回以降の実行時にそれを復元することで
1.~5.（特に時間がかかると言われる5.の初期化処理）の処理時間をすっ飛ばすことが出来るというもので、
正確にはスナップショットの復元時間があるので完全に省略できるわけではないですが、
これによって"劇的に"lambdaのコールドスタート時間が短縮できるそうです。
コストについては、スナップショットを取ったり保存したりするだけだからか
このオプションを有効にすることによって追加料金は発生しない
とのことです！嬉しい！
（一方Provisioned Concurrencyオプションは常にインスタンスを構えてるのでコスト爆上がり。今まで高コストだったものが無料で使える革新さ...!）
※2022年12月6日現在、Java 11ランタイムかつx86_64アーキテクチャでのみ利用可能。
（ここを見ると分かるが、javaがレベチでコールドスタートが遅いという背景がありそう）
オプションを有効化する方法
-
まず
Java 11ランタイム、x86_64アーキテクチャのlambda関数を作る
-
設定 > 一般設定 > 編集 を押下する
-
SnapShotを
PublishedVersionsに変更し、保存を押下する！
実際に動かして、タイムを比較してみた！
用意するもの
- 以下の
Lambda関数-
snapstart_on_func：Java 11、x86_64でSnapStartオプションはON -
snapstart_off_func：Java 11、x86_64でSnapStartオプションはOFF
-
手順
-
オプションを有効化する方法項に従って、snapstart_on_funcとsnapstart_off_funcを作る -
それぞれテスト実行してみる
計測結果
ということで、↑の手順に従ってテスト実行時間を計測していきます！
-
SnapStartなし：コールドスタート（460.31ms）
-
SnapStartあり：コールドスタート（425.37ms）
-
SnapStartなし：ホットスタート（1.15ms）
-
SnapStartあり：ホットスタート（1.16ms）
結果発表ーーーーっっ！！！
はい。ということでSnapStartあり/なしの比較実験の結果は以下となりました。
| SnapStartなし | SnapStartあり | |
|---|---|---|
| コールドスタート | 460.31ms | 425.37ms |
| ホットスタート | 1.15ms | 1.16ms |
うーん、、、正直パッとしない結果ですね、、笑
（一応460.31msに対して425.37msなので、約8%の短縮）
ホットスタートは両者条件が同じなので差はほとんどなし、一方でコールドスタートは予想通りタイムが縮まっている、で定性的には予想通りなものの、もう少し短縮されると思っていただけに少し残念。
とはいえ、今回の検証はlambda関数を作った時に勝手に作られる空の関数を使っており、必要なパッケージや処理が極端に少なかったという事情があるので、実際にプロジェクトで使うとなればもっと恩恵を受けられると思っています。
（恐らくSnapStartなしxコールドスタートが際限なく長くなる一方、SnapStartありxコールドスタートはあまり変わらないと予想。この記事を見たどなたか、追加検証オネガイシマス。。。）
感想
ということで、数値はパッとしなかったもの、効果は明確にあるということが分かり、更にコストを含めたデメリットが特にないということで、このオプションは常にONで良いんじゃないかな〜なんて思いました。
このスピードじゃ満足出来ないよ！って人はProvisioned Concurrencyなり別のサービス使うなりで明確に住み分け出来ているので、低コストでLambda×Javaを高速化させたい、という人は是非活用してみてください！
それでは、Future株式会社のAdvent Calendarはまだまだ続きますので、明日以降も乞うご期待！