AWS Lambdaの実行環境とライフサイクル

AWS Lambdaは、イベントを受け取ると関数を実行します。そのためにLambdaは、関数のコードを動かす実行環境を用意し、ランタイムの起動、関数の呼び出し、環境の終了を管理します。開発者が実行ホストやOSを直接管理する必要はありませんが、実行環境のライフサイクルを理解すると、起動時の遅延、処理性能、同時実行数、権限、料金を適切に設計できます。

Lambda関数は、常に1つのサーバー上で動き続けるサービスではありません。イベントやスケジュールなどの呼び出しをきっかけに実行され、負荷に合わせて複数の実行環境を使います。環境が再利用される場合もありますが、いつまで残るか、次の呼び出しで同じ環境が使われるかは保証されません。

実行環境が担うもの

実行環境は、関数を実行するためのランタイムやリソースをまとめた独立した環境です。Lambdaは環境を起動し、関数の初期化と呼び出しを管理します。関数のコードに加え、設定情報、ランタイム、必要に応じてLambda Extensionsも実行環境内で動作します。

ランタイムと拡張機能は、Lambda Runtime APIやExtensions APIを通じてLambdaサービスと連携します。拡張機能はログ、メトリクス、トレースなどのテレメトリを受け取り、監視サービスなどに転送できます。拡張機能も初期化や終了のライフサイクルに参加するため、その処理時間や終了処理は関数全体の動作に影響します。

初期化・呼び出し・シャットダウン

実行環境の基本的なライフサイクルは、初期化 (Init)、呼び出し (Invoke)、シャットダウン (Shutdown) の3つのフェーズで考えられます。

初期化フェーズ

新しい実行環境を準備するとき、Lambdaは関数コードを利用可能にし、ランタイムを起動します。その後、ハンドラー関数の外にある初期化コードを実行し、必要なライブラリやモジュールを読み込みます。Extensionsを利用している場合は、それらも起動して初期化します。

初期化が完了すると、ランタイムは呼び出しを受け付けられる状態になります。初期化が失敗した場合、呼び出しは成功せず、ログやエラーの記録を調べる必要があります。

初期化フェーズには時間制限があります。オンデマンド実行環境では、初期化が最初の10秒以内に完了しない場合、Lambdaは初回の呼び出し時に初期化を再試行します。その場合の初期化には関数に設定したタイムアウトが適用されます。プロビジョニング済み同時実行数やSnapStartの環境準備では、通常のオンデマンド呼び出しと初期化のタイミングや制約が異なるため、設定方式に応じた公式仕様を確認します。

Lambda関数自体のタイムアウトは設定可能で、最大は900秒、つまり15分です。これは関数の実行時間の上限です。API Gatewayなど呼び出し元サービスのタイムアウトとは別の設定で、関数が15分まで実行できても、呼び出し元が先に応答待ちを打ち切る構成はあり得ます。エンドツーエンドの待ち時間は、関係する各サービスの制限を確認して設計します。

呼び出しフェーズ

呼び出しフェーズでは、ランタイムがハンドラーを実行し、呼び出し元から受け取ったイベントを処理します。ハンドラーは関数のエントリーポイントです。たとえば、宅配便の追跡イベントを受け取った関数なら、イベントの形式と値を検証し、追跡状態を更新して結果を記録します。

Lambdaの呼び出し方式には同期呼び出し、非同期呼び出し、イベントソースマッピングによるポーリングがあります。これらは結果の返し方や失敗時の再試行方法が異なります。関数内でエラーが起きた場合にLambdaが実行環境をリセットすることと、呼び出しそのものを再試行することは別です。同期呼び出しでは通常、呼び出し元がエラーを受け取り、必要なら再試行します。非同期呼び出しやイベントソースマッピングでは、それぞれの再試行・保持・バッチ処理の設定と連携元の仕様が影響します。

シャットダウンフェーズ

Lambdaが実行環境を終了するとき、ランタイムとExtensionsにシャットダウンの通知が送られます。Extensionsは、バッファしたテレメトリを送るなど、終了前に必要な処理を実行できます。ただし、終了通知を使って重要な業務データを保存する設計にはしないでください。突然の終了や時間制限に備え、永続化が必要な状態はデータベースやオブジェクトストレージなどに明示的に書き込みます。

呼び出し後に環境がアイドル状態になっても、Lambdaが同じ環境をどれくらい保持するかは保証されません。一定時間後に終了することもあれば、次の呼び出しに再利用されることもあります。実行環境の存続を前提にせず、必要な状態を外部の永続ストレージに保存します。

実行環境の再利用とハンドラーの内外

同じ実行環境が複数の呼び出しに使われる場合、初期化フェーズはその環境の起動時に一度実行され、後続の呼び出しでは通常繰り返されません。この性質を利用するには、複数回使えるものと、リクエストごとに変わるものをコード上で分けます。

ハンドラーの外に置くもの

ハンドラーの外側には、複数の呼び出しで再利用できる初期化を置きます。たとえば、ライブラリの読み込み、変更されない設定値の読み取り、AWS SDKクライアントの生成などです。毎回同じ初期化を避けられれば、実行環境が再利用された際に呼び出しごとの処理時間を抑えられる場合があります。

データベース接続のような外部接続を共有する場合は、アイドル中に接続が切断されたり期限切れになったりする可能性を考慮します。接続をハンドラー外で準備しても、その接続が永続的に有効であるとは限りません。利用時に接続状態を確認して再接続できるようにするか、RDS Proxyなど適切な接続管理を利用します。

環境変数はLambdaの関数設定として実行環境に渡される値です。起動時に読み込んで設定として利用できますが、機密情報を通常の環境変数に直接保存する場合は暗号化、アクセス制御、更新方法を検討してください。シークレット管理の要件に応じてAWS Secrets ManagerやSystems Manager Parameter Storeなどを使います。

ハンドラー内に置くもの

ハンドラー内には、イベントに含まれる入力の検証、呼び出しごとの業務処理、リクエスト単位で変化する値の作成などを置きます。ハンドラー外のグローバル変数に利用者ごとの情報や処理途中の値を残すと、再利用された環境で後続リクエストに値が混入するおそれがあります。

実行環境のメモリ上にある状態は、同じ環境の呼び出し間で残ることがありますが、他の実行環境とは共有されず、環境終了時には失われます。キャッシュとして使う場合も、データの古さや環境ごとの不一致を許容できるか確認します。永続化や関数インスタンス間での共有が必要な状態には、外部ストレージを使います。

コールドスタートとウォームスタート

新しい実行環境を用意し、ランタイムの起動や初期化コードの実行を終えてから関数を呼び出すときには、準備のための時間がかかります。この追加遅延をコールドスタートと呼びます。関数への最初の呼び出しに限らず、しばらく呼び出されず環境が終了した後や、同時リクエストの増加に合わせて新しい環境が必要になったときにも発生します。

すでに準備済みの環境が再利用され、初期化をやり直さずに呼び出しが始まる状態は、一般にウォームスタートと呼ばれます。ウォームスタートでは環境の準備時間を省けることがありますが、再利用は保証されません。また、コールドスタートの時間が常に1秒以上になるわけでもありません。ランタイム、関数パッケージの大きさ、初期化コード、拡張機能、ネットワーク設定などにより実測値は変わります。

初期化コードを軽くする、不要な依存ライブラリを減らす、初期化を必要なタイミングまで遅らせるなどの工夫は、コールドスタートを短くするのに役立ちます。関数を定期的に呼び続けても、実行環境が維持される保証にはなりません。厳しいレイテンシー要件に対して、環境を事前に準備する必要がある場合はプロビジョニング済み同時実行数を検討します。

同時実行数とスロットリング

同時実行数は、ある時点で同時に処理中の関数呼び出し数です。リクエストの到着が重なると、Lambdaは必要に応じて複数の実行環境を起動し、それぞれで呼び出しを並行処理します。おおまかには、同時実行数は1秒あたりのリクエスト数と平均実行時間の両方に左右されます。たとえば、同じリクエスト率でも処理時間が延びると、同時に実行中の呼び出しが増えます。

同時実行数にはアカウントとAWSリージョンごとのクォータがあります。多くの環境で既定値は1,000ですが、アカウントやリージョンによって異なることがあるため、Service Quotasで実際の値を確認します。クォータを超える要求はスロットリングされます。エラーの見え方や再試行の有無は、同期・非同期・イベントソースマッピングなど呼び出し方式と連携元の挙動によって異なります。

必要な容量が現在のクォータを超える場合は、Service Quotasから引き上げを申請します。どのアカウントでも決まった値まで必ず増やせるという保証はありません。依存先データベースやAPIの処理能力、下流サービスのスロットルも確認し、Lambdaだけを増やして下流を過負荷にしないようにします。

プロビジョニング済み同時実行数

プロビジョニング済み同時実行数 (Provisioned Concurrency) は、指定数の実行環境を事前に準備し、初期化済みの状態で呼び出しに備えさせる機能です。リクエストが来る前にランタイムと初期化コードを実行しておくため、対象範囲の呼び出しでコールドスタートを抑えられます。応答時間が重要な同期APIなど、低遅延を安定させたい用途で使います。

プロビジョニング済み同時実行数はバージョンまたはエイリアスに設定します。指定数を超える呼び出しが来た場合、追加の呼び出しは通常のオンデマンド実行環境で処理され、コールドスタートが生じる可能性があります。ピークに備えて必要数を見積もり、メトリクスやトラフィックの変化に合わせて調整します。

準備済み環境は呼び出しを処理していない時間にも確保されるため、その容量と時間に応じた料金が発生します。常時エンジンをかけて待機する車のように、即応性のために事前の準備を維持する機能と考えるとよいでしょう。正確な課金単位と条件はリージョンや設定によって確認します。

予約済み同時実行数との違い

予約済み同時実行数 (Reserved Concurrency) は、アカウントとリージョンの同時実行容量の一部を特定の関数に割り当てる機能です。指定した数までは他の関数に消費されない実行枠として確保し、同時にその関数が使える最大数も指定値に制限します。重要な関数の容量を他の関数から隔離したい場合や、下流サービスへの同時アクセスを抑えたい場合に利用できます。

予約済み同時実行数は実行環境を事前に初期化する機能ではありません。予約数が確保されても新しい環境が必要になればコールドスタートは起こり得ます。通常、予約済み同時実行数そのものに追加料金はありませんが、確保した分だけ他の関数が利用できる共有の未予約容量が減ります。

比較項目	プロビジョニング済み同時実行数	予約済み同時実行数
主な目的	実行環境を事前初期化し、起動遅延を抑える	関数に実行枠を確保し、その関数の最大同時実行数を制御する
環境の事前起動	指定数の環境を初期化して待機させる	事前初期化はしない
追加料金	準備済み容量と時間などに基づく料金がある	機能そのものの追加料金はない
よく使う場面	レイテンシーに厳しい同期処理	関数間の容量分離、下流保護、最大実行数の制御

両方を同じ関数で設定することもできます。その場合、予約済み同時実行数が関数の総上限となり、その範囲内でプロビジョニング済み容量を設定します。予約済み同時実行数を超えるリクエストはスロットリングされ、プロビジョニング済み同時実行数を超えたものの予約済み上限内にあるリクエストはオンデマンド環境に流れる可能性があります。レイテンシーと最大処理量の要件を分けて設定します。

試験で押さえるポイント

• Lambda実行環境は関数のコード、ランタイム、拡張機能などを動かし、初期化・呼び出し・シャットダウンのライフサイクルを持つ。
• 初期化コードはハンドラーの外で実行され、環境が再利用される呼び出しでは再実行されないことがある。再利用や保持期間は保証されない。
• Lambda関数の最大タイムアウトは15分。呼び出し元サービスのタイムアウトとは別に確認する。
• 初めての呼び出しだけでなく、スケールアウトなどで新しい環境が必要なときもコールドスタートが発生し得る。
• プロビジョニング済み同時実行数は環境を事前に初期化して低遅延を狙い、待機中の容量にも課金される。
• 予約済み同時実行数は関数の実行枠を確保し最大同時実行数を制限する。ウォーム状態を保証する機能ではなく、追加料金も発生しない。
• アカウント・リージョン別の同時実行クォータ超過はスロットリングにつながる。具体的な上限と失敗時の扱いはクォータと呼び出し方式で確認する。

公式ドキュメント

• Lambda実行環境のライフサイクル
• Lambda関数の設定とタイムアウト
• Lambda同時実行数
• Lambdaクォータ
• プロビジョニング済み同時実行数の設定
• 予約済み同時実行数
• Lambda料金