AWS Lambda Web Functionsを発表

本日、AWS Lambda Web Functionsを発表します。これは、コードをイベントハンドラーに書き換えることなく、標準的なHTTP WebアプリケーションをLambda上で実行できる新しいフォームファクターです。Express、Hono、Fastify、Next.js、またはその他のNode.jsフレームワークで構築された標準的なポートリスニングサーバーを、単一のコマンドでデプロイできます。Lambdaは自動的にスケーリング、マルチリージョン配信、アクティブCPU課金を処理します。アダプターや管理すべきインフラストラクチャ、フレームワークのロックインはありません。 このローンチにより、AWS Lambdaは、同じFirecracker分離技術上に構築され、それぞれ異なるプログラミングモデル向けに設計された3つの異なるフォームファクターを提供するようになりました。 Lambda Event Functionsは、すでにLambda関数としてご存知のものです。これらは、イベント駆動型の単一同時実行ハンドラーモデルと壁時計課金を使用します。このプログラミングモデルを強調するために「Event Functions」という名称を導入します。関数はイベントを受け取り、それを処理し、応答を返します。イベント駆動型プログラミングモデルは、イベント処理、キューコンシューマー、および他のAWSサービスによってトリガーされる呼び出しに最適です。 Lambda Web Functionsは、HTTPネイティブなプログラミングモデルとマルチ同時実行実行およびアクティブCPU課金を使用します。コードはポートをリッスンし、標準的なHTTPリクエストを処理します。このプログラミングモデルは、複数の同時リクエストとI/O負荷の高い処理が一般的であるWebアプリケーション、APIバックエンド、およびインタラクティブなHTTPワークロードに最適です。 Lambda MicroVMsは、信頼されていない、またはユーザー生成コードを実行するための、顧客管理ライフサイクルを持つ分離されたステートフルなサンドボックス環境を提供します。 これら3つは互いを補完します。アプリケーションは、非同期バックエンド処理にEvent Functions、ユーザーインターフェイスのAPIおよびサーバーサイドレンダリングレイヤーにWeb Functions、インタラクティブなコード実行機能にMicroVMsを使用し、これらすべてを同じAWSアカウント内で、同じ運用モデルを共有して実行できます。 なぜWeb Functionsなのか 最新のWebアプリケーションは、開発者が標準フレームワークを使用し、迅速にイテレーションを行う自由を与えながら、高速で一貫した応答時間でグローバルなオーディエンスにサービスを提供する必要があります。これを構築するには通常、複数のインフラストラクチャコンポーネントを組み立て、マルチリージョンのデプロイメントを設定し、レイテンシーベースのルーティングを設定し、I/O待機に対する支払いを回避するために課金モデルを調整する必要があります。開発者はしばしば、特定のコンピューティングモデルにアプリケーションコードを適合させることに追われ、既存のHTTPサーバーをデプロイできなくなります。 Lambda Web Functionsはこの複雑さを解消します。各実行環境は複数のリクエストを同時に処理します（環境あたり最大128の同時リクエスト）。これは、着信トラフィックのバーストが、各リクエストを新しいものにマッピングするのではなく、ウォームな環境を共有できることを意味します。Web Functionsはコードが使用するCPU時間を計測するため、データベースクエリやAPI呼び出しを待機している間に消費されるCPU時間はほとんどありません。メモリは、実行環境が存在する限り計測されます。サーバーサイドレンダリング、APIバックエンド、およびトークン応答をストリーミングするAI推論エンドポイントのようなI/O負荷の高いWebワークロードでは、これによりコンピューティングコストを削減できます。 試してみましょう 開始するために、簡単なExpress.jsサーバーを作成しました。これは、Lambda固有のアダプターやラッパーを必要とせずに、ローカルで node index.js を実行するのと同じコードです。 import express from 'express'; const app = express(); const [host, port] = process.env.AWS_LAMBDA_HTTP_ENDPOINT.split(':'); app.get('/', (req, res) => { res.json({ message: 'Hello from Lambda Web Functions!' }); }); app.listen(port, host, () => { console.log(`Server running on port ${port}`); }); ローカル実行との唯一の違いは、Lambdaがサーバーがリッスンする必要のあるホストとポートに設定する AWS_LAMBDA_HTTP_ENDPOINT 環境変数です。ローカルで実行するには、例えば AWS_LAMBDA_HTTP_ENDPOINT=127.0.0.1:3000 node index.js のように自分で設定します。 コードの準備ができたので、AWS Command Line Interface（AWS CLI）を使用してデプロイしました。 aws lambda-web deploy --name my-web-app --code ./my-app 1つのコマンド。事前のリソース設定は不要です。CLIはソースをバンドルし、Web Functionを作成し、最初のバージョンを発行し、Web Functionエンドポイントをアタッチし、1分未満でライブHTTPS URLを返しました。バージョンとは、デプロイしたコードの不変のスナップショットです。エンドポイントは、トラフィックをバージョンにルーティングしたり、バージョン間でトラフィックを分割したりするHTTPS URLです。これらは、イテレーションやコードの移動方法を制御するために使用するリソースです。 すぐにテストしました。 $ curl https://<domain-id>.<shard-id>.lambda-web.us-east-1.on.aws/ {