AWS Lambda 実行環境のライフサイクル
サーバー管理不要でコードを実行できるサーバーレスコンピューティングサービス
📌Lambda とは何か
AWS Lambda は、サーバーのプロビジョニングや管理なしにコードを実行できる「サーバーレスコンピューティングサービス」です。EC2 のようにインスタンスを起動・管理する必要がなく、コードをアップロードするだけで、イベント（API リクエスト、S3 へのファイルアップロード、SQS メッセージなど）に応じて自動的にコードが実行されます。
Lambda の最大の特徴は「使った分だけ課金」される点です。リクエスト数と実行時間（1ms 単位）に基づいて課金されるため、リクエストがない時間帯はコストがゼロです。EC2 のように24時間稼働させる必要がないため、不定期に発生する処理や、リクエスト量に大きな波があるワークロードに特に適しています。
Lambda は Node.js、Python、Java、Go、.NET、Ruby のランタイムをサポートしており、カスタムランタイムを使えば任意の言語で関数を作成できます。各関数は独立した実行環境（Firecracker microVM）で実行されるため、セキュリティの分離が保証されています。最大メモリは 10GB、最大実行時間は 15 分です。
🚀実行環境のライフサイクル
Lambda 関数が呼ばれると、裏側では ① → ② → ③ → ④ → ⑤ の5つのフェーズを順に通ります。普段は意識しませんが、この流れを知ることでコールドスタートやウォームスタートの仕組みが理解できます。
AWS が関数専用の軽量サーバーを作成します。ここはユーザーには課金されません。
Node.js / Python を起動し、コードを読み込み、handler の外側に書いた初期化コード（DB 接続の準備など）を実行します。①② の合計が「コールドスタート」の遅延の正体です。
あなたの handler(event, context) が実行されます。1ms 単位で課金されるのはこの部分だけです。
実行後、環境はすぐ消えずに待機します。メモリのデータは残っているので、次のリクエストは ①② をスキップして即 ③ から実行できます（ウォームスタート）。
しばらくリクエストが来ないと環境ごと破棄されます。次はまた ① からやり直しです。
🔍各フェーズの詳細解説
5つのフェーズそれぞれで何が起きているのか、もう少し詳しく見てみましょう。
AWS が Firecracker という軽量仮想化技術で、関数専用の小さなサーバー（microVM）を作ります。EC2 のような大きな VM ではなく、数十ms で起動できる超軽量な VM です。
microVM の中で3つのことが順に行われます:
- ランタイム起動 — Node.js / Python / Java などを起動
- コードダウンロード — あなたの関数コードを S3 からダウンロード
- 初期化コード実行 — handler の外側に書いたコード（DB 接続の準備、SDK の初期化など）を実行
あなたの handler(event, context) が実行されます。event にはリクエスト内容、context には残り時間やリクエスト ID などの情報が入っています。
handler の実行が終わると、環境は「凍結（Frozen）」されて待機します。CPU は完全に停止しますが、メモリ上のデータはそのまま残ります。
- DB 接続プール → そのまま再利用可能
- グローバル変数 → 前回の値が残っている
- /tmp に書いたファイル → そのまま読める（最大 512MB）
一定時間リクエストが来ないと、AWS が環境を破棄します。メモリのデータ、DB 接続、/tmp のファイル、全て消えます。
- ランタイムに最大 2秒 の shutdown hook が提供される
- ただし確実に実行される保証はない
- 重要なデータは ③ の実行中に保存しておくべき
⏱️タイムアウトの仕組み
Lambda 関数のタイムアウトは、Invoke フェーズ（ハンドラー関数の実行）の最大時間を制限する設定です。1秒〜900秒（15分）の範囲で設定でき、デフォルトは3秒です。タイムアウトに到達すると、Lambda サービスが関数を強制的に終了させます。
タイムアウトで強制終了された場合、Task timed out after X.XX seconds というメッセージが CloudWatch Logs に記録されます。try-finally ブロックのクリーンアップ処理も実行されません。同期呼び出しの場合はエラーレスポンスが返り、非同期呼び出しの場合は自動で最大2回リトライされます。
タイムアウトの防止策として、context.getRemainingTimeInMillis() で残り時間を監視し、タイムアウト前に graceful に処理を終了する方法があります。また、外部 API 呼び出しには必ず HTTP クライアント側のタイムアウトを設定し、Lambda のタイムアウトよりも短くするのがベストプラクティスです。API Gateway 経由の場合、API Gateway 自体のタイムアウトは最大29秒であることにも注意が必要です。
💾メモリ設定と CPU 割り当ての関係
Lambda ではメモリサイズのみを設定し、CPU はメモリ量に比例して自動的に割り当てられます。128MB〜10,240MB（10GB）の範囲で1MB 単位で設定でき、1,769MB で1 vCPU 相当の CPU パワーが割り当てられます。つまり、メモリを2倍にすると CPU も2倍になります。
この仕組みにより、CPU 依存の処理（画像処理、データ変換など）でもメモリを増やすことで実行時間を短縮できます。コストは「メモリ量 x 実行時間」で計算されるため、メモリを増やしても実行時間が大幅に短縮されれば、トータルコストが下がる場合もあります。最適なメモリサイズは AWS Lambda Power Tuning ツールで見つけることができます。
10,240MB（10GB）に設定すると約6 vCPU が割り当てられ、マルチスレッド処理が効果的に機能します。ただし、Lambda のコストは「GB-秒」単位で計算されるため、必要以上にメモリを増やすとコストが増加します。パフォーマンスとコストのバランスを考慮して最適な設定を見つけることが重要です。
| メモリ | CPU | 用途の目安 |
|---|---|---|
| 128 MB | ~0.08 vCPU | 超軽量処理（簡単なJSON変換） |
| 512 MB | ~0.3 vCPU | 一般的なAPI処理 |
| 1,769 MB | 1 vCPU | CPU依存処理（画像リサイズ） |
| 3,538 MB | 2 vCPU | マルチスレッド処理 |
| 10,240 MB | ~6 vCPU | 大規模データ処理・ML推論 |
🔧Provisioned Concurrency とは何か
Provisioned Concurrency は、指定した数の実行環境を事前に Init フェーズまで完了させた状態で常時待機させる機能です。リクエストが到着すると、コールドスタートなしで即座にハンドラー関数が実行されるため、レイテンシが安定します。
Provisioned Concurrency は Lambda 関数のエイリアスまたはバージョンに対して設定します。$LATEST には設定できません。Auto Scaling と組み合わせることで、トラフィックパターンに応じて Provisioned 数を動的に調整することも可能です。
注意点として、Provisioned Concurrency は待機中も課金が発生します。使用量に関わらず、設定した数の実行環境分のコストがかかるため、常に一定のリクエストが来ることが予想される本番環境や、レイテンシ要件が厳しい API 向けに使用します。コスト面では、オンデマンド料金の約 25% が追加されます。
⚠️Lambda の制約とベストプラクティス
- 最大実行時間: 15分（900秒）
- 最大メモリ: 10GB（メモリに比例して CPU も増加）
- デプロイパッケージ: 50MB（zip）/ 250MB（展開後）
- /tmp ストレージ: 最大 10GB
- 同時実行数: アカウントあたりデフォルト 1,000
- DB 接続は handler の外側で初期化 → ウォームスタートで再利用
- 設定値は環境変数で管理（ハードコードしない）
- デプロイパッケージを小さくする → コールドスタートが速くなる
- Lambda Layers で共通ライブラリを関数間で共有
- X-Ray でパフォーマンスをトレース
- Dead Letter Queue（DLQ）でエラー時のメッセージロストを防止
- API バックエンド（API Gateway + Lambda）
- S3 / DynamoDB Streams のイベント処理
- 定期バッチ（15分以内）
- IoT データ処理、チャットボット
- 15分を超える長時間処理
- 常時稼働の WebSocket サーバー
- 大量メモリの機械学習トレーニング
- セッション管理などステートフルな処理
