AWS Lambdaのイベント駆動実行とハンドラー

AWS Lambdaは、アプリケーションのコードを関数として実行するサーバーレスコンピューティングサービスです。関数を単位にコードを提供して実行するサービスは、Function as a Service (FaaS) とも呼ばれます。イベントを受け取ると関数を起動し、リクエスト量に応じて実行環境を増減します。開発者はサーバーの起動、OSのパッチ適用、実行ホストの台数管理を担当せず、関数のコード、依存ライブラリ、権限、設定、監視に集中できます。

「サーバーレス」は物理的なサーバーが存在しないという意味ではありません。基盤のプロビジョニングと管理をAWSに任せる運用モデルです。また、運用作業がすべてなくなるわけではなく、コードの品質、アクセス制御、エラー処理、スケーリング先の容量、コストなどは設計・運用の対象です。

イベントを起点に関数を実行する

イベントとは、システム内で発生した出来事や処理要求を表すデータです。Lambda関数はイベントを受け取り、入力に応じた処理を行います。呼び出し元のサービスによってイベントの構造は異なります。

たとえば、会場の座席予約APIでは、クライアントからの空席確保要求がAPI Gatewayを通ってLambdaに届きます。関数は要求内容と利用者を検査し、DynamoDBの予約状態を更新して、処理結果をAPI Gatewayへ返します。このように、APIの要求を受ける処理以外にも、オブジェクトのメタデータ登録、定期的なキャッシュ整理、メッセージの変換などをイベント起点で実行できます。

イベントを送る仕組みには複数の種類があります。

呼び出し方式	代表的な用途	結果の扱い
同期呼び出し	API GatewayからのHTTP要求など、呼び出し元が結果を必要とする処理	Lambdaの完了を呼び出し元が待ち、戻り値やエラーを受け取る
非同期呼び出し	イベント通知など、呼び出し元が処理完了を待たずに先へ進む処理	呼び出し元は受け付けられたことを確認し、関数の実行結果は別途ログや再試行設定などで扱う
イベントソースマッピング	SQSキューやストリームなど、Lambdaがレコードを読み取って処理する連携	Lambda側のマッピングがソースをポーリングし、レコードをまとめて関数へ渡す

サービス名だけで同期・非同期を決めつけないことが大切です。同じLambdaでも、どの連携機能を通じて呼び出すかによって、応答の返し方、再試行、バッチ処理、失敗時の扱いが変わります。たとえば、Lambdaの非同期呼び出し機能と、イベントソースマッピングでSQSを読み取る方式は、イベントを関数へ届ける仕組みも障害時の制御も異なります。

関数、ランタイム、ハンドラー

Lambda関数は、ユーザーがデプロイするコードと、そのコードを実行するランタイムや設定で構成されます。ランタイムは、選んだ言語のコードを実行し、Lambdaサービスとの間でイベントを受け渡す環境です。LambdaにはNode.js、Python、Java、.NET、Rubyなどのマネージドランタイムが用意されており、要件によってはOS専用ランタイムやカスタムランタイムも使えます。ランタイムの種類やサポート期間は更新されるため、バージョンを選ぶときはLambdaランタイムの公式一覧を確認します。

ハンドラーは、関数が呼び出されたときに実際の処理を始めるエントリーポイントです。ランタイム設定では、どのファイルとエクスポート済み関数をハンドラーとして呼ぶかを指定します。処理の役割は、入力の検証、業務ロジックの実行、必要なAWSサービスへのアクセス、呼び出し元が理解できる結果の返却です。

初期化処理とハンドラーのライフサイクル

Lambdaは、呼び出しを処理するための実行環境を用意します。新しい実行環境が起動すると、ランタイムを準備して関数コードを読み込み、ハンドラーを最初に呼び出す前の初期化処理を行います。その後、イベントごとにハンドラーを呼び出します。

モジュールの読み込み、SDKクライアントの生成、変更されない設定値の読み込みなど、複数の呼び出しで再利用できる初期化は、ハンドラーの外に置くのが基本です。同じ実行環境が次の呼び出しにも再利用されれば、これらの初期化を毎回繰り返さずに済み、応答時間の短縮につながる場合があります。

ただし、実行環境は恒久的なものではありません。新しい環境が作られると初期化は再度行われ、環境が終了すればメモリ上の値も失われます。ハンドラー外の変数を永続ストレージやユーザー間の状態共有先として使ってはいけません。また、呼び出しごとに変わる値を初期化領域に残すと、後続リクエストに誤ったデータを使う危険があるため、リクエスト固有のデータはハンドラー内で扱います。

eventとcontextを使う

ハンドラーは主に2つの情報を受け取ります。

• イベント (event): 呼び出し元が渡した処理対象のデータです。API Gateway経由なら、HTTPメソッド、パス、ヘッダー、クエリ文字列、リクエスト本文などが含まれます。SQS経由なら、メッセージ本文などのレコード情報が含まれます。具体的なフィールドと形式は、呼び出し元と統合設定に依存します。
• コンテキスト (context): 現在の呼び出しや実行環境について、Lambdaが提供するメタデータです。リクエストID、関数名、実行時間の残りなど、実行状況に関する情報を得られます。業務上の入力データそのものではありません。

イベントの形式を前提に処理を実装する場合は、そのイベントを生成するサービスや統合方式を確認します。同じHTTP APIでも、API Gatewayの設定やペイロード形式が異なればイベントの形は変わり得ます。入力検証を行い、不正な形式や不足したフィールドを明示的に扱うことで、予期しないデータによる障害を減らせます。

API GatewayとLambdaの同期連携

HTTPクライアントとLambdaをつなぐ代表的な構成では、API Gatewayがリクエストを受け取り、Lambdaを同期的に呼び出します。Lambdaは処理を終えると、ステータスコード、ヘッダー、本文などを含む応答を返し、API GatewayがそれをHTTPレスポンスとしてクライアントに返します。

たとえば座席の仮押さえAPIでは、リクエストの本文から会場と座席の情報を取り出し、認可・入力検証をした後、DynamoDBの該当項目を条件付きで更新できます。更新できた場合は成功を示す応答を返し、すでに確保済みなら競合を示す応答を返します。API GatewayのLambdaプロキシ統合では、関数が返すオブジェクトの形式がHTTP応答に影響するため、ステータスコードと本文を適切に組み立てます。本文は統合仕様に合わせて文字列として返す形式が一般的です。

この連携では、API GatewayはLambdaの同期呼び出しが終わるまで結果を待ちます。関数のエラーやタイムアウトはHTTP APIの失敗につながるため、適切なタイムアウト、入力検証、エラーログを設計します。処理に時間がかかり、即時応答が不要な場合は、キューなどを介した非同期処理に分け、受付結果とバックグラウンド処理の結果を別々に扱う方法もあります。

IAM権限は「呼び出す権限」と「実行中に使う権限」を分ける

Lambdaが他のAWSサービスを操作するには、関数に実行ロールを設定します。Lambdaサービスが関数の実行時にこのロールを引き受け、ロールに付与されたポリシーの範囲でDynamoDBの読み書きやCloudWatch Logsへの記録などを行います。必要な操作とリソースを絞った最小権限にし、アプリケーションコードに長期アクセスキーを埋め込まないことが基本です。

実行ロールは、関数が他のサービスを呼び出すときの権限です。一方、API Gatewayなどの呼び出し元がLambdaを起動できるかどうかは、呼び出し元のIDポリシーやLambda関数のリソースベースポリシーなどで制御します。API Gateway統合では、API Gatewayに対象関数の呼び出しを許可する設定も必要です。関数内からDynamoDBを更新できることと、API Gatewayから関数を呼び出せることは別の許可です。この2種類を混同すると、実行時にアクセス拒否が起きたり、必要以上に広い権限を付与したりします。

コストと設計上の見方

Lambdaの標準的な利用料は、関数のリクエスト数と実行時間を基準に計算され、割り当てメモリやアーキテクチャなどが実行料金に関係します。常時稼働するサーバーを確保せずに済む一方、リクエストが少なくても、プロビジョニング済み同時実行など一部機能には別の料金要素があります。実際の費用はリージョン、機能、利用量によって変わるため、設計時にはLambda料金ページを確認します。

Lambdaがサーバー管理を軽減しても、関数の実行時間、同時実行数、依存先サービスの容量、再試行や重複処理への備えは引き続き重要です。呼び出し方式ごとにイベントがどのように到着し、成功・失敗がどこへ伝わるかを把握すると、LambdaをAPIバックエンドにもイベント処理にも適切に使い分けられます。

公式ドキュメント

• Lambdaの呼び出し方法
• Lambda実行環境のライフサイクル
• Lambdaの実行ロールとアクセス権限
• API GatewayからLambdaを呼び出す
• AWS Lambda料金