待望のLambdaコールドスタート対策「Lambda SnapStart」機能を解説します！😎

こんにちは！

先日、AWS Lambda の SnapStart という新機能が発表されました。「コールドスタート時間の短縮」を目的とした機能ということで、使い方が気になっている方も多いのではないでしょうか？

そこで今回は、こちらの新機能について詳しく解説していきます！

はじめに

SnapStart は、特に Java 環境で大きな課題になっていたコールドスタート時間の短縮を目的とした機能。

Lambda を実行する直前に環境のスナップショットを取得し、多層キャッシュに保存することで、それ以後のコンテナの初期化を大幅に高速化します。現在 Java 11 の関数で使えるようになっています。

このスナップショット機能は、FireCracker の MicroVM スナップショット技術を利用しています。これは AWS Fargate や Lambda が使用している MicroVM フレームワークがベースになっているため、関数ハンドラーのコードを1秒未満の遅延時間（最大10倍の速度）で実行できるようになります。

また、現時点で SnapStart が利用できるのは Java (Amazon Corretto 11) だけですが、技術の基盤にある MicroVM のシステムがランタイムに関係なく使用できることを考えると、いずれ他のランタイムに対してもサポートされるようになっていくでしょう。

本記事では、SnapStartの機能の仕組み、利点、注意点、今後の見通しなどについて紹介します！

想定する読者

• AWS サーバーレス開発に関わるヒト
• Lambda SnapStart の機能が気になるヒト
• コールドスタート問題の解決に悩むヒト

Lambda SnapStart の機能とは

2021年の re:Invent で Julian Wood が行ったプレゼン「高度なサーバーレス開発者のベストプラクティス」のスライドを参考にしましょう。

従来のいわゆるオンデマンド実行と呼ばれるプロセスでは、 Lambda の実行を開始する際には、 Lambda の Placement Service によって新しい実行環境が作成されていることがわかります。具体的には、最初に開発者のプログラム（またはオープンコンテナイメージ）が環境にダウンロードされ、ランタイムが初期化された後に、ハンドラーがロードされ、実行されるという順番になります。

対して、SnapStart では新しいバージョンの実行環境が作られた後に、スナップショットが作成されます。

新しいバージョンを作成し出力するのは、単に $LATEST を使用するよりも、時間がかかるプロセスです。ですが、なんとスナップショットはその情報を長期間保存してくれるのです。その関数が数週間実行されなかった場合のみ Lambda が再取得を行うことになりますが、その場合、直後の実行はオンデマンドとなり新しいスナップショットが生成されます。

このようにして一度スナップショットが記録されてからは、完全修飾 Lambda ARN への新しいコンカレント処理はすべて、スナップショットを使用して再開されます。この点が SnapStart のメリットで、スナップショットから再開するプロセスは、新しい Lambda 実行環境を作成し初期化するのに比べると、最大10倍の早さになります。

ただし大きな注意点として、SnapStart は続けてウォームスタートを掛けた場合には何も変更を加えません。SnapStart が動作するのは、コンカレント処理をトリガーする新しいリクエストまたはイベントがあった（かつ新しい呼び出しを受け取るためのウォームな Lambda コンテナがない）時のみです。

スナップショットにはどんな情報が含まれる？

スナップショットには、初期化した後、実行を開始する直前の関数のメモリとディスクの状態が記録されています。 そして、スナップショットの情報は512kbのフラグメントに分割され、多層キャッシュで保存されます。

関数スナップショットが再開されると、関数のコード自体が必要とするチャンクのみが読み込まれます。これはmmap の MAP_PRIVATE を使用して行われており（Firecrackerリポジトリに記載があります）、とても上手い作りになっています。ただし、スナップショットのメモリやディスクの読み取りは遅延読み込みになります。 つまり、変数やその他のデータを参照する際には遅延が発生するということです。スナップショット再開時に、特定のデータ箇所にアクセスされるまで関数コード全体がロードされず、実行できないことがあるからです。

SnapStart の注意すべき点

SnapStart は、完全修飾 Lambda ARN を呼び出す場合にのみ使用できます。つまり、特定の関数バージョンを出力して実行する場合です。

AWS は、 Lambda を使用したシステム構築にはバージョン管理を行うことを公式に推奨しています。

しかしながら、AWS が支援する CDK や SAM を含む多くの開発ツールはデフォルトでそのような仕様にはなっていません。つまり、 SnapStart を利用したい場合は、IaCツールに何らかの変更を加える必要がある可能性が高いということです。

参考までに、非修飾 ARN ( バージョン指定有 ) と修飾 ARN ( バージョン指定無 ) の比較を載せておきます。

修飾ARN:

arn:aws:lambda:aws-region:acct-id:function:helloworld:42

非修飾ARN:

arn:aws:lambda:aws-region:acct-id:function:helloworld

SnapStart の料金

無料です！Lambda SnapStart の機能は無料で使うことができます。

ランダム性と一意性

MicroVM スナップショットには元々、一意性とランダム性の問題があります。一つの処理の実行から作られたメモリのスナップショットが複数の処理で（多くは同時に）再利用されるからです。ただし、通常の擬似乱数ジェネレータの代わりに暗号論的擬似乱数ジェネレータを使用することで、この問題は軽減できます。

AWS は、関数が一意性に基づいているかどうかチェックしてくれるツールも提供しています。こちらから入手できます。

一時的なデータ、一時的な認証情報

スナップショットから再開を行う場合の注意として、一時的なデータや認証情報に有効期限が保証されないという点があります。例えば、期限が切れるトークンを関数で作成するライブラリを使っていると、SnapStart を用いて新しいコンテナを起動したときに、想定外にトークンが期限切れになっている場合があります。したがって、 エフェメラルなデータや認証情報を使用する際には、それが有効であることの確認を挟むのが望ましいでしょう。

ネットワーク接続

最後に紹介するサーバーレス開発者にとっての注意点は、ネットワーク接続の記憶と再開の問題です。一般的な方法では、データベースまたはネットワーク接続の情報は関数ハンドラーの外部で記憶させることで、その後の実行に使用できるようにします。しかしこの方法は SnapStart では使えません。SnapStart でも HTTP やデータベースライブラリは初期化されますが、ソケット接続そのものを新しいコンテナに転送したり多重化したりできないからです。そのため、接続を再構築する必要があります。

また、ドキュメントでは VPC 接続についての記載がありませんが、こちらも SnapStart では使えないと思われます。一般的な方法論では関数を VPC の中で作成するのに対し、SnapStart では、関数のコンテナが作成されてからネットワークデバイスが VPC に接続されるからです。

今後についての考察

私の意見としては、SnapStart は、Lambda に最初の時点からあるべき機能だったと思います。今後計画通りにアップデートが続いていけば、サーバーレス界や業界全体で Lambda のスケーリングに対する見方も変わるでしょう。それほど、SnapStart は重要で魅力的な機能です。

しかし、依然として開発者が抱える負担については懸念があります。SnapStart が今後追加される新しい Lambda 関数のデファクトスタンダードになる可能性は高いですが、これを扱えるようにするために、IaC ツールを修正する必要が生じます。

SnapStart を使用するということは、バージョン管理によって修飾 ARN のみを呼び出すということです。前述の通り、これは現状のツールのデフォルトではなく、今よりも複雑なデプロイの手順を構築しなければならない可能性もあります。

まとめ

Lambda SnapStart について紹介しました。今後の AWS 開発において、特にコールドスタート時間の短縮を考えるうえでは欠かせない機能になりそうですね。

ただし、前の章で書いた通り SnapStart に対応するために各種ツールの修正が必要な場合もあるので注意しましょう。

AWS Lambdaの実装、サーバーレス開発についてはお気軽にお問い合わせください。