では、AWS Lambda において Lambda 関数が実行される仕組みをみていきましょう !

次のアニメーションは、Amazon API Gateway と Lambda 関数 を統合している環境を例に、Lambda 関数が呼び出された時の動きを示したものです。

このアニメーションから、Lambda 関数の実行環境は呼出しに応じて自動的に用意されることがわかりますね。

ただし、Lambda 関数を作成・更新した直後では、まず実行環境が作成され、初期化処理を経てハンドラーが実行されます。このような流れで Lambda 関数が実行されることを、一般的に「コールドスタート」と呼びます。ハンドラーのコードを実行する以外に、実行環境を作成して初期化処理を行う時間が必要になるので、その分のレイテンシーが発生することを把握しておきましょう。

コールドスタートを経て Lambda 関数の実行環境が作成されますが、作成されハンドラーが実行された後も、その実行環境はすぐには削除されず、残っています。次のアニメーションをご覧ください。

このアニメーションのように、実行環境が残っている期間内に再び同じ Lambda 関数を呼び出すと、その環境が再利用されることがあります。再利用された場合は、実行環境も作成済で初期化処理も完了しているので、ハンドラーだけが実行されます。 このような流れで Lambda 関数が実行されることを、一般的に「ウォームスタート」と呼びます。ウォームスタートの場合は、コールドスタートと比較すると実行環境作成や初期化処理は必要ないので、その分処理時間を短縮できます。

コールドスタートとウォームスタートは、「お風呂に最初に入る」か「2 番目以降に入る」かで例えるとわかりやすいかもしれません。お風呂に最初に入る場合は、湯船に湯がためて適温になるまで待つ必要がありますが、 2 番目に入る人はすでに湯船に適温のお湯があるので、待たずにそのまま入れますよね。

さて、実行環境は最終的にどうなるのでしょう ? 次のアニメーションをご覧ください。

実行環境を使わない状況が続くと、いずれ AWS Lambda サービスより不要と判断され、シャットダウン処理を経て自動的に実行環境が削除されます。その後、再び呼び出されるとコールドスタートを経て実行環境が作成される、というライフサイクルを繰り返します。

次に同じ Lambda 関数で複数の呼び出しが発生した場合の動作をアニメーションでみてみましょう。

このアニメーションが示しているように、AWS Lambda は Lambda 関数の呼び出し数や、現在使用中の実行環境の数に応じて、自動的に実行環境の数を増やします。

ただし、すでにコールドスタートを経て実行環境が複数残っている場合、同じクライアントが再び 同じ Lambda 関数を呼び出したとしても、前回と同じ実行環境が使用されるとは限りません。次のアニメーションをみてみましょう。

よって、Lambda 関数の実行環境内にセッションデータ (特定のクライアントの固有データ) を保存するべきではありません。つまり、Lambda 関数のコードはステートレスにする必要があることを理解しておきましょう !

これはリージョン単位の値なので、例えば 東京リージョンに Lambda 関数を A, B, C と 3 つ作成した場合、その A, B, C の合計の同時実行数が 1,000 までということになります。

また、Lambda 関数単位で同時に作成できる実行環境数を設定できます。この設定は「予約済同時実行数」または「Reserved Concurrency」と呼ばれます。次のアニメーションをみてみましょう。

このアニメーションで示しているように、1 つの Lambda 関数に対して同時に多くのリクエストが発生し、設定した予約済同時実行数を超える場合は、超えた分はエラー (ステータスコード: 429 エラーコード： TooManyRequestsException) になります。この状態をスロットリングといいます。極端な例として、予約済同時実行数に 0 を設定すると、その Lambda 関数はいくらリクエストがきても、一切実行されないということになります。

また、東京リージョンの同時実行数がデフォルト 1,000 なので、例えば Lambda 関数 X の予約済同時実行数もそれに合わせて 1,000 にしておく、ということもできません。リージョン内のすべての Lambda 関数の予約済同時実行数の合計は、最大でリージョンの同時実行数 -100 の値までしか設定できません。つまり東京リージョンでいうとすべての Lambda 関数の予約済同時実行数の合計は 900 までしか設定できないので、注意しておきましょう。

1 つの Lambda 関数に対して、複数のバージョンやエイリアスを作成できます。
次のアニメーションをご覧ください。

このアニメーションのように、Lambda 関数には $LATEST というデフォルトのバージョンがあり、コードの編集は常に $LATEST に対してのみ行います。その $LATEST から新しいバージョンを発行できます。ただし、発行されたバージョンのコードは変更できないので、注意しておきましょう。

また 、エイリアスを作成してバージョンと関連付けて使用できます。これにより、Lambda 関数の呼び出し元は常に特定のエイリアスだけを指定して Lambda 関数を呼び出せばよく、複数のバージョンの存在を意識する必要がなくなります。さらにエイリアスとバージョンの関連付けでは トラフィックの比重を設定できるので、次のアニメーションのように、新しいバージョンにはひとまず 10% にして確認し、問題がなければ 100% にするという運用も可能です。

さて、「4-1. Lambda 関数の実行環境のライフサイクル」のセクションでコールドスタートとウォームスタートの説明をしました。コールドスタートは、ウォームスタートと比較し、実行環境を作成して初期化処理を行う分のオーバーヘッドが発生していましたよね。コールドスタートが発生したタイミングとはいえ、このオーバーヘッドによるレイテンシーの遅延を避けたい場合はどうすればいいでしょうか ?

一つの対処法として、プロビジョニングされた同時実行数 (Provisioned Concurrency) を設定して、Lambda 関数の実行環境を事前に作成し、その数を維持するという方法があります。この設定は、Lambda 関数の特定のバージョンもしくはエイリアスに対して行います。

次のアニメーションをみてみましょう。

このアニメーションでは例として プロビジョニングされた同時実行数を 2 に設定しています。この設定により、Lambda 関数の実行環境が 2 つ作成され、その数は維持されます。作成されればコールドスタートが終わった状態になっているので、その後同時に 2 つの実行環境が必要になっても、ウォームスタートの状態からそれらのリクエストに対応できます。では、プロビジョニングされた同時実行数を超える実行環境が必要になった場合は、どうなるでしょう？ もし他に実行環境がなければ、必要な分の実行環境が追加で作成されコールドスタートが発生しますが、既に起動済の実行環境があれば、それを使用してウォームスタートでリクエストに対応します。いずれにしても、リクエストに対処できないということはありません。

「4-1. Lambda 関数の実行環境のライフサイクル」のセクションでは、コールドスタートを「お風呂に入るときに湯船に湯がたまるまで待つ」と比喩で説明しましたが、このプロビジョニングされた同時実行数の設定は、同じように比喩で表現するなら、「いつでもすぐにお風呂に入れるように常に湯船に湯をはっておく」ということになります。

ただし、このプロビジョニングされた同時実行数の設定には注意点もあります。それはコストです。この設定を行うと Lambda 関数の実行環境が維持されている時間に対してもコストが発生することは十分留意しておいて下さい。詳細は、AWS Lambda 料金の Web ページの「Provisioned Concurrency 料金」のセクション に記述がありますので、ご参照ください。

なお、コールドスタート対策という観点では、 Lambda SnapStart という機能も知っておきましょう。これはコールドスタートの時間短縮を期待できる機能で、Lambda 関数のランタイムとして、この記事を執筆している 2023 年 7 月時点で Corretto の Java 11 と Java 17 がサポート されています。詳細は ドキュメントの「Lambda SnapStart による起動パフォーマンスの向上」や Amazon Web Services ブログの「SnapStart で AWS Lambda 関数の Java コールドスタートを削減する」をご参照ください。