社内ブログは初投稿の中途4ヶ月目の脇田です！

先日ミロゴス社との合同勉強会にて「Lambda SnapStartを完全に理解してみた」というタイトルで発表させてもらいましたので今回はその発表内容についての記事になります。（来月にはLambda SnapStartなにも分からない、になっていることでしょう）

AWS re:Invent 2022で発表されたLambda SnapStartですがどうやらjvm実行環境を選んだ際のコールドスタートをSnapshotを利用して改善してくれるなにやらイカしたやつのようです。

といったもののSnapshotってなんですか？といった状態です、なにかしらの状態をキャッシュしていることは文字通り分かりますがよくわからないものはあまり使いたくないですよね。ということでまずSnapshotについて深掘りをしてみました。

Snapshot深掘り

AWSオフィシャルブログ、その他諸々を巡回したところ....以下のようなことが見えてきました。

LambdaのライフサイクルにおけるInit Pahseの処理後の状態をSnapshotとしてCacheしている
Snapshotには恐らく２段階存在している(公式で言及はされていないです)
- LambdaをホストしているVMを対象としたSnapshot
- ある時点のJavaプロセスを対象としたSnapshot

Init Phase Snapshot

Lambdaには上記スライド内の画像で説明されているようなライフサイクルが存在します。

SnapStartモードではリクエストが発生した場合、INITをスキップしRESTOREが発生、INIT済みの実行環境から処理が再開されることとなっているようです、実行環境自体をキャッシュしているのでコールドスタート改善も納得ですね。

またLambdaの新しいバージョンを公開した時点でINITが発生し実行環境がスナップショットされるのでSnapshotが作成されていなくてコールドスタートに時間を取られてしまうrequestが発生することもなさそうです。

VM Snapshot

Lambdaの裏側ではFirecrackerという仮想マシンが動いています。 https://aws.amazon.com/jp/blogs/opensource/firecracker-open-source-secure-fast-microvm-serverless

このFirecreckerですが、これ自体に自身のプロセスをスナップショットする機能が備わっているのでおそらくSnapStart機能にはこちらが使われていることが考えられます。

開発者はあまり気にするレイヤーではないと思いますので私はそうなんだなぁ程度に受け止めております。

Javaプロセス Snapshot

ところでCoordinated Restore at Checkpoint (CRaC)はみなさんご存知でしょうか？（私は全然知りませんでした。。。）

CRaCとはJavaプロセスをSnapshotするプロジェクトとなるのですが、後述する資料に出てくるSnapStartで使えるJavaプロセスのランタイムフックではこのCRaCの機能が使われています。てことはCRaCでJavaプロセスのスナップショット作成してるんじゃね？？、と考えられそうです。(こちらは公式に言及されていないのであくまで推察に過ぎないですが)

こちらはランタイムフックを利用することもあり開発者が関心を持った方がよさそうに思えます。

開発者が利用する際に気をつけた方がよさそうなこと

Snapshotについて解像度が上がったところで開発者が利用する際に気をつけた方がよさそうなことを調べたので主にCRaC周りですが併せて紹介します。

重い処理はstaticに移してパフォーマンスアップ

CRaCはJavaプロセスの任意タイミングでのスナップショットになります、つまりクラスローディングは終わっていそうなのでstaticな処理はコールされてスナップショット対象となるとみてよさそうです、こちらはAWS公式ブログのベストプラクティスでも紹介されています。

SnapStart の利点を最大限に活用するには、関数ハンドラーではなく、初期化コードで起動待機時間の原因となるクラスをプリロードすることをお勧めします。これにより、重いクラスのロードに関連するレイテンシが呼び出しパスから移動し、SnapStart による起動パフォーマンスが最適化されます。初期化中にクラスをプリロードできない場合は、ダミーの呼び出しでクラスをプリロードすることをお勧めします。これを行うには、次のペットストア関数の例に示すように、関数ハンドラーコードを更新します。

private static SpringLambdaContainerHandler<AwsProxyRequest, AwsProxyResponse> handler;
  static {
      try {
          handler = SpringLambdaContainerHandler.getAwsProxyHandler(PetStoreSpringAppConfig.class);

          // Use the onStartup method of the handler to register the custom filter
          handler.onStartup(servletContext -> {
              FilterRegistration.Dynamic registration = servletContext.addFilter("CognitoIdentityFilter", CognitoIdentityFilter.class);
              registration.addMappingForUrlPatterns(EnumSet.of(DispatcherType.REQUEST), false, "/*");
          });

          // Send a fake Amazon API Gateway request to the handler to load classes ahead of time
          ApiGatewayRequestIdentity identity = new ApiGatewayRequestIdentity();
          identity.setApiKey("foo");
          identity.setAccountId("foo");
          identity.setAccessKey("foo");

          AwsProxyRequestContext reqCtx = new AwsProxyRequestContext();
          reqCtx.setPath("/pets");
          reqCtx.setStage("default");
          reqCtx.setAuthorizer(null);
          reqCtx.setIdentity(identity);

          AwsProxyRequest req = new AwsProxyRequest();
          req.setHttpMethod("GET");
          req.setPath("/pets");
          req.setBody("");
          req.setRequestContext(reqCtx);

          Context ctx = new TestContext();
          handler.proxy(req, ctx);


      } catch (ContainerInitializationException e) {
          // if we fail here. We re-throw the exception to force another cold start
          e.printStackTrace();
          throw new RuntimeException("Could not initialize Spring framework", e);
      }
  }

上記のコードではSpringでの例となってます。DI対象のFilterの登録、認証情報の取得は通常であればSpring起動時のDIコンテナ初期化時に処理されるためstaticに移して事前に処理しておきSnapshot対象としている、というところでしょうか。