AWSのLambdaで、2022年の年末より「Lambdaの最大の弱点」だったコールドスタートこれが「劇的に改善できるかもしれない」的な機能である「snapStart」がリリースされました。

そもそも「JavaでのLambda」は「コールドスタートが糞遅い」わけで、その根本理由が「Lambda自体がキャッシュ化で速度を稼ぐ系なものは""NG""」なわけで、だけどそもそもの「Javaはキャッシュやjitの最適化で高速化」されるわけで、なので「LambdaにJavaは実は""非常に相性が悪い""」ものなわけですよ。

しかしそれに対して去年の年末にリリースされた「snapStart」によって、この辺の問題の一つである「起動時のclassローディング」を「スナップショット」を取る事で、高速起動を可能したわけで、これにより「最大１０倍」の起動短縮化が取れるようになったそうなんですよ。

ただ、じゃあ具体的にどうすれば「最適な高速化？」ってのが「NextStep」にあるわけで、この辺の「最適化」方法が昨今色々ブログ等で記載されているわけですよ。

最初に見るべき内容がこれ。

ここでは「最適化を考えない」場合は「確かに""snapStart""なし」と比べると「早くなる」けど「１０倍早く」はならないわけでその辺の内容が記載されています。

ただここで記載されている「""暖機運転処理""」って何ってのが、いまいち上記ブログではわかりづらいので、次の内容を見てみます。

ここでは上記で語られた「""暖機運転処理""」とは「Coordinated Restore at Checkpoint (CRaC)」の事を指すそうで、その具体的な事とはつまり「static化」で宣言する事だそうです。

・・・そういえばjavaでstaticを使うと言うのは「staticおじさん」を思い出すわけで、この揶揄表現は「オブジェクト指向を理解できないが、java言語を扱ってるロートルおじさん」これを「staticおじさん」と言われてたわけですが、まあ「時代によってはstaticは正義」なんかと思います。

とは言え、ここでのstaticは主にインスタンスの初期化をstatic定義したり、static { .... } で処理する事を指すわけで、この辺の処理が先程のCRaCの範囲内で実行されるものであり、これがLambdaのsnapStartでの「スナップショット範囲」になるので、この辺でclassローディングが発生しなくできるから、だから「Lambdaが高速起動できる」となるわけです。

あと、snapStartとは別の話題ですが、実はAWS Lambdaでは、Node.jsのような sync / async 関連の非同期実行も「不要」なわけで、たとえば「lamba url function」実行でのHTTPSアクセスでは、同時アクセスがあれば別のLambdaデプロイ環境が作成され実行される事になり、なので従来のWebアプリ環境と違い並列実行環境が全く違う事から sync, async的なThread実行は不要なわけですよ。

このように、AWS,LambdaでのsnapStartでは、CRaCで最適化を進める事ができそうなわけで、うまくやれば「コールドスタート」が１秒未満で実装できれば、普通にLambdaで安価なWebアプリが作れるわけで、この辺「非常に面白そう」だと思いました。

現状私は上記を作成中でして、Rhinoを使って対象Githubリポジトリ内のjsファイルを実行できるWebアプリを作成中ですが、これがコールドスタートで１秒未満で返却されるような代物ができれば、これを持ってして「社内Webアプリ」程度なら、これを使って作ろう的なものができるようにしたいですね。

昨今では「コストが安い」ものについて「会社」が求めてる部分もあるので、安く社内システムが作れるものを目指して行ければと思います。