AWS Lambda
サーバーの管理なしにコードを実行できるサーバーレスコンピューティングサービスで、リクエスト数と実行時間に基づく完全従量課金制を採用している
概要
AWS Lambda は、サーバーのプロビジョニングや管理を一切行わずにコードを実行できるサーバーレスコンピューティングサービスです。S3 へのファイルアップロード、API Gateway への HTTP リクエスト、DynamoDB のデータ変更など、200 以上の AWS サービスからのイベントをトリガーとして関数を自動実行します。Python、Node.js、Java、Go、.NET など主要なランタイムに対応し、コンテナイメージでのデプロイも可能です。月間 100 万リクエストと 40 万 GB 秒の無料枠が永続的に提供されるため、小規模なアプリケーションであれば実質無料で運用できます。実行時間の上限は 15 分、メモリは最大 10 GB まで設定可能です。
同期・非同期・イベントソースマッピングの使い分け
Lambda の呼び出しモデルは 3 種類あり、ワークロードの性質に応じて適切に選択する必要があります。同期呼び出しは API Gateway 経由の HTTP リクエストが代表例で、呼び出し元がレスポンスを待ちます。レイテンシが直接ユーザー体験に影響するため、コールドスタートの抑制が重要になります。非同期呼び出しは S3 イベント通知や SNS トピックからのトリガーで使われ、Lambda がイベントをキューに受け取って順次処理します。失敗時は自動で最大 2 回リトライされ、それでも失敗した場合はデッドレターキュー (SQS または SNS) に送信できます。イベントソースマッピングは SQS キューや Kinesis ストリームからメッセージをバッチで取得する方式で、バッチサイズやバッチウィンドウを調整することでスループットとコストのバランスを制御します。同時実行数はリージョンあたりデフォルト 1,000 で、引き上げリクエストにより数万まで拡張可能です。
コールドスタートの原因と対策
コールドスタートは、関数の実行環境が新規に作成される際に発生する数百ミリ秒から数秒の遅延です。原因はランタイムの初期化、デプロイパッケージの展開、関数コード外の初期化処理 (DB 接続の確立など) にあります。対策として最も確実なのは Provisioned Concurrency で、事前に指定した数の実行環境を温めておくことでコールドスタートを完全に排除できます。ただし待機中も課金が発生するため、常時トラフィックがある API バックエンドなど、レイテンシ要件が厳しいケースに限定するのが合理的です。Java ランタイムでは SnapStart 機能が利用でき、初期化済みのスナップショットから復元することでコールドスタート時間を最大 90% 短縮できます。Azure Functions も同様のコールドスタート課題を抱えていますが、SnapStart に相当する機能はなく、Premium プランでの常時ウォーム維持が主な対策です。また Azure Functions の従量課金プランでは実行時間の上限がデフォルト 10 分であるのに対し、Lambda は 15 分まで許容されます。サーバーレス開発の書籍 (Amazon) では、こうしたパフォーマンスチューニングの実践例が詳しく解説されています。
Step Functions との連携とデプロイ戦略
単一の Lambda 関数で完結しないワークフローには Step Functions が有効です。複数の Lambda 関数を順序制御・並列実行・条件分岐・エラーハンドリング付きで連携させるステートマシンを定義でき、リトライポリシーやタイムアウトも宣言的に設定できます。たとえば画像アップロード後に「サムネイル生成 → メタデータ抽出 → DB 登録 → 通知送信」を一連のワークフローとして管理するケースが典型的です。デプロイには AWS SAM や Serverless Framework を使った IaC 管理が推奨されます。SAM テンプレートで Lambda 関数、API Gateway、DynamoDB テーブルをまとめて定義し、CI/CD パイプラインに組み込むことで、コードの変更からデプロイまでを自動化できます。関数のバージョニングとエイリアスを活用すれば、カナリアデプロイやブルー/グリーンデプロイも実現可能です。