AWS Lambdaのウォームアップリクエスト検証

はじめに

この記事書くときに知った、Lambdaのウォームアップリクエストはどれくらいの頻度で実行すれば効果的なのか検証した記事です！

前提

まず、最初にウォームアップリクエストをつかったパフォーマンス改善は、コールドスタート問題の完全な対応策にはなり得ません。

下記サイトにその旨の説明があるので、まとめていきます。

理由1:存続時間は決まっていない。

Lambdaは、実行後すぐには実行環境を破棄せず保持しつづけますが、存続時間は一定ではありません。

また、目安となる時間も公開はされていません。

理由2:実行環境はスケールアップする。

トラフィック量に応じて、Lambdaはいつでも異なるAZ、同一AZで実行環境を追加作成する可能性があります。

その結果、短時間に複数回呼び出されたとしても、この負荷分散の挙動によりコールドスタートが発生します。

正しいコールドスタート対策は「Provisioned Concurrency」

公式なコールドスタート問題の対処法はProvisioned Concurrencyです。

有効にすると、プロビジョニングされた環境は、２桁ミリ秒で応答するように機能を初期化してくれます。

なんですが、料金がサーバレスっぽくないのが悩みどころですね。
（従量課金ではなく、時間課金）

では、試してみます！

検証方法

ハンドラー外の変数bodyをインクリメントして、ログに出すだけのプログラム。

これを一定周期でEventBridge Schedulerからキックし、bodyの値が上がっていけばウォームアップし続けているということになります。

let body=0;

export const handler = async (event) => {

    let statusCode = '200';   
    const headers = {
        'Content-Type': 'application/json',
    };

    try {
        body++;
        console.log('body:', body);
    } catch (err) {
        statusCode = '400';
        body = err.message;
    } finally {
        body = JSON.stringify(body);
    }

    return {
        statusCode,
        body,
        headers,
    };
};

20分周期

インクリメントされていません。

実行の都度、新しい実行環境ができているということなので、これはNGです。

2024-12-28T20:40:02.445Z 8d677062-2039-4aab-bf64-7c186ba418e7 INFO body: 1

2024-12-28T21:00:02.483Z 8d677066-d039-4aab-bf64-7c186ba418e7 INFO body: 1

3~4分くらい？

少しづつ時間を短縮して確認した結果、４分くらいから実行環境が残るようになりました。

2024-12-29T20:12:02.134Z 2e6771ad-1054-4769-bee2-b595a826dbf7 INFO body: 6

2024-12-29T20:16:02.123Z 2e6771ae-0054-4769-bee2-b595a826dbf7 INFO body: 7

まとめ

完全ではないですが、お手軽かつ、ほぼ無料でコールドスタート対策ができるかとも？と思い、記事にしてみました〜！