Amazon Web Services(AWS)がLambda@Edgeを一般向けにリリースした。これにより、AWSの世界各地のPOP(point-of-presence)ロケーションにわたって、Node.jsのLambda関数を“最先端”で実行できるようになり、エンドユーザへの動的レスポンスが非常に低いレイテンシで可能になる。
Lambda@Edgeでは、開発者がNode.jsコードをAmazonの“サーバレス”サービスであるAWS Lambdaにアップロードすると、そのLambdaが自動的に起動し、エンドユーザに近いAWSロケーションで高可用性を備えたコードにスケールされる。これによってレイテンシを改善するとともに、初期ロード時間を削減することができる。Lambda@EdgeのコードはAmazon CloudFrontからのイベントによって起動される。Amazon CloudFrontは低いレイテンシと高い転送速度で、データやビデオ、アプリケーション、APIをセキュアに提供するCDN(Content Delivery Network)サービスである。
Lambda@Edgeは、ユーザが世界中に配置されていて、(理想的には)意思決定に必要なすべての情報がCloudFront上の関数や要求で取得可能であり、なおかつレイテンシが重要なユースケースに最適化されている。これによって開発者は、次のようなことが可能になる。
- クッキーを検査し、A/Bテストを実行するためにURLの透過的な書き換えを行なう。
- エッジで生成された動的コンテントを返す。例えば、認証されていないユーザを、オンデマンドで生成されたログインページにリダイレクトする。
- 特定のオブジェクトで応答することにより、User-Agentヘッダに基づいてユーザが目にするWebサイトをカスタマイズする。
- ユーザを別のキャッシュに誘導するために、ヘッダを追加、削除、あるいは変更する(次のような制限が適用される)。
- ヘッダあるいはURLを変更ないし圧縮することにより、キャッシュ使用率を向上させる。
- 他のインターネットリソースのHTTPリクエストを生成して、その結果をレスポンスをカスタマイズするために使用する(ただし、リクエスト生成によるレイテンシ増加を最小限にするように、開発者は注意を払う必要がある)。
Lambda@Edge関数は、４つのCloudFrontイベントに応答してトリガすることができる。
- Viewer Request — このイベントは、エンドユーザまたはインターネット上のデバイスがCloudFrontにHTTP(S)リクエストを行なって、それがユーザに最も近いエッジに到達すると発生する。イベントには、着信したHTTPリクエストが含まれている。
- Viewer Response — このイベントは、エッジのCloudFrontサーバが、リクエストを生成したエンドユーザまたはデバイスに応答する準備ができた時に発生する。イベントにはHTTPレスポンスが含まれている。
- Origin Request — このイベントは、要求されたオブジェクトがCloudFrontエッジサーバのキャッシュ上になく、バックエンドのOrigin(Amazon EC2、アプリケーションロードバランサ、Amazon S3など)にリクエストを送信する準備ができた時に発生する。
- Origin Response — このイベントは、エッジのCloudFrontサーバがバックエンドOriginからレスポンスを受信した時に発生する。
以下の図はAWS Lambda@Edgeのドキュメントから引用したもので、リクエスト/レスポンスライフサイクル中のイベントトリガの位置を示したものだ。
Lambda@Edgeの開発者は、標準的なAWS Lambda開発パラダイムを熟知した上で、以下の制限下で動作するコードを開発する必要がある。
- ランタイム環境 — 現時点ではNode.jsで記述された関数のみがサポートされている。各関数には128MBのメモリが提供されるが、組込みライブラリや/tmpへのアクセスはできない。
- タイムアウト — Origin RequestおよびOrigin Responseイベントを処理する関数は、3秒以内で処理を完了する必要がある。Viewer RequestとViewer Responseを処理する関数は、1秒以内に完了しなければならない。
- Webサービスアクセス — Origin RequestとOrigin Responseイベントを処理する関数は、3秒以内の制限において、AWS APIにアクセスしてHTTP経由でコンテンツを取得することができる。これらのリクエストは常に、元になったリクエストへのリクエストあるいはレスポンスと同期して生成される。
- バージョニング — Lambda Consoleでコードが更新された場合には、新たにトリガセットの設定された新バージョンが公開されなければならない。開発者はレプリケーションの完了を待つ必要がある。関数は常にバージョン番号で参照されなくてはならない — $LATESTおよびエイリアスは適用されない。
- ヘッダ — どのヘッダがアクセス可能か、制限付きか、読み取り専用か、ブラックリストに登録されているかを判断するには、“Headers Restrictions”の資料を参考にすること。
現時点では、Lambda@Edgeの無料使用枠はない — コードの実行が開始してから戻るか終了するまで、関数の実行時間が計算され、GB-秒毎に0.00005001ドルが課金される。Lambda@Edge関数には実行毎に128MBのメモリが固定的に提供されるため、時間課金は128MB-秒毎に0.00000625125ドルになる。標準のAWS Lambdaの粒度が100msであるのに対して、Lambda@Edge関数は50ms単位で測定される点に注意が必要だ。
AWS Lambda@Edgeに関する詳細情報は、AWS BlogのJeff Barr氏の記事“Lambda@Edge — Intelligent Processing of HTTP Requests at the Edge”や、AWS Lambda@Edgeの製品情報、開発者ガイドで見ることができる。
この記事を評価
- 編集者評
- 編集長アクション