Amazon Web Services
一つの実行環境で複数のリクエストを同時に処理でき、CPU料金は処理の開始から終了までの経過時間ではなく、実際にCPUを使った時間を基に計算する。
提供開始時点ではArm64上のNode.
ポートで待ち受け、HTTPリクエストを処理
AWSは今回、既存のLambda関数の呼称をLambda Event Functionsに変更した。Event Functionsでは、キューのメッセージや他のAWSサービスから届くイベントなどを、ハンドラーと呼ばれる関数に渡して処理する。
Web Functionsでは、アプリケーションがポートで待ち受け、HTTPリクエストを直接処理する。Lambdaのイベント形式をHTTPリクエストに変換するアダプターは不要で、Webフレームワークのルーティングやミドルウェアを使える。ただし、待受先はLambdaが環境変数AWS_で指定するホストとポートに合わせる必要がある。
このアプリケーションを公開するには、HTTPSリクエストを受け付けてアプリケーションへ渡すエンドポイントを、Lambda上に作成する。
AWSはWeb Functionsの用途として、Webページをリクエストごとに生成するサーバー側レンダリング、APIのバックエンド、生成AIの応答を順次返すストリーミング処理などを挙げている。
一つの実行環境で複数のリクエストを処理
Web Functionsの実行環境は、複数のリクエストを同時に扱う。たとえば、あるリクエストが非同期処理でデータベースの応答を待っている間に、Node.
環境ごとの同時実行数の上限は1〜128件の範囲で設定でき、デフォルトは64件。Lambdaは各環境のリソース使用状況に応じて、同時に受け付けるリクエスト数の上限を調整する。ただし、開発者が設定した値を超えることはない。
実行環境の数もトラフィックに応じて増減し、アクセスがなくなるとゼロになる。その状態で次のリクエストが届くと、新たな環境の起動を待つコールドスタートが発生する。リクエストが急増し、起動済みの環境だけでは処理しきれない場合にも、同様の待ち時間が生じる。
同じ実行環境内では、一つのNode.
CPUとメモリで異なる課金の仕組み
Web Functionsの料金は、リクエスト数、実際に使ったCPU時間、実行環境が消費するメモリ、データ転送に応じて計算される。Event Functionsを標準の実行方式で動かす場合、実行料金は割り当てたメモリ量とリクエストごとの実行時間で計算される。
Web Functionsでは、データベースや外部APIの応答待ちでCPUをほとんど使わなければ、その間のCPU料金も小さくなる。一方、メモリ料金は、実行環境が使うメモリ量と、リクエスト間の待機時間を含めて環境が動いている時間に応じて発生する。複数のリクエストを同じ環境で処理すれば、その環境のメモリも共有できる。AWSは、こうした仕組みにより、応答待ちの多いWebアプリケーションの費用を抑えられるとしている。
複数リージョンへの公開方法を選べる
エンドポイントの種類としてMultiRegionを選ぶと、開発者が指定したリージョンへLambdaがコードと設定を複製し、共通のドメイン名を用意する。リクエストを受け付ける際は、利用者から見た遅延に基づいてLambdaが送信先を選ぶため、地域ごとのURLを利用者側で切り替える必要がない[1]。
リージョンごとに異なるドメイン名で公開するPerRegionも選べる。こちらではLambdaが遅延に基づいて自動で振り分けることはなく、開発者が送信先を決められる。
フレームワークや通信方式ごとの実装例も公開
AWSのサーバーレスチームに所属するEric Johnson氏は、Web Functionsで複数のフレームワークや通信方式を試したブログ記事とサンプルコードを公開した。ExpressやFastifyによるREST APIに加え、サーバーからイベントを順次送るServer-Sent Events
ConnectとgRPC-Webを使ったRPCの実装例もある。同氏によると、Web FunctionsのエンドポイントはHTTP/