Snap Startだけでは速くならないJava＋AWS Lambda

Posted at 2025-02-02

はじめに

Java＋AWS LambdaはSnap Startさえしておけばなんとかなる！って思ってた愚かな自分が、少しパフォーマンスチューニングしてみたお話です。

なお、今回検証に使ったソースは以下に格納しています。

ソースのベースは、以下を利用させていただき、２つの改造をしております。

DynamoDBへの接続
Powertools for AWS Lambda (Java)のTracing適用

何もしていない状態

DynamoDBの初期化などをハンドラ外に定義しているだけの状態で動作確認してみます。

初回起動時

トータル7.27秒でした。
起動に4.4秒、実際の処理は2.57秒くらいです。

初回だけとはいえ、流石に遅すぎです！

２回目以降

ちなみに２回目は29ミリ秒。さすがJavaさんです！

Lambda SnapStart適用

次にLambda SnapStartを有効にしてみます。

Lambda SnapStartはコールドスタート時間を大幅に短縮するための機能で、初期化済み状態のスナップショットを作成・保存し、それを新しい実行環境のベースとして使用することで、起動時間を大幅に軽減する機能です。

デプロイの時間は少し長くなりましたが、初回起動時の性能はトータル7.27→3.73秒となり、半減しました。

起動時間が約80％程度まで削減されていることがわかります。
（Init->Restoreになってる。）

ただし、起動以降の処理時間は変化がなく、２回目以降のスピードが出ていません。

Snap Startを使えば、常に２回目以降のスピードが出るものとずっと思い込んでました。。

公式のページ通りですが、リストアにも803ミリ秒と結構時間かかってますね。

Warm up（クラスローディング対応）

以下のベストプラクティスを参考に、初回起動時にクラスローディングされない部分を手動コールするようにしてみます。

サンプルでは、実際にハンドラから呼び出しをしていますが、クラスローディングが主目的だと思うので、ハンドラのStaticイニシャライザからPetsControllerを手動でコールしてみました。

public class StreamLambdaHandler implements RequestStreamHandler {
    private static final Logger logger = LoggerFactory.getLogger(StreamLambdaHandler.class);
    private static SpringBootLambdaContainerHandler<AwsProxyRequest, AwsProxyResponse> handler;
    static {
        try {
            handler = SpringBootLambdaContainerHandler.getAwsProxyHandler(Application.class);

registration.addMappingForUrlPatterns(EnumSet.of(DispatcherType.REQUEST), false, "/*");
            });

            DynamoDbClient dynamoDbClient = DynamoDbClient.create();
            PetsController controller = new PetsController(dynamoDbClient);
            controller.listPets(Optional.of(1), null);

            logger.info("warm up！");
        } catch (ContainerInitializationException e) {
            e.printStackTrace();
            throw new RuntimeException("Could not initialize Spring Boot application", e);
        }
    }