新機能AWS Lambda Function URLsをServerlessFrameworkで対応😎メリットデメリットも語ります🚀

新機能AWS Lambda Function URLsをServerlessFrameworkで対応😎メリットデメリットも語ります🚀

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは!

今回は AWS Lambda Function URLs という新しい機能を紹介します!

想定する読者

  • AWS Lambda の新機能に興味のあるヒト
  • Severless Framework を使用しているヒト

初めに

AWS は Lambda Function URLs という新しい機能をリリースしました。
Serverless Framework が Lambda Function URLs をサポートしている点にも注目です。

Lambda Function URLs とは

Lambda Function URLs は AWS Lambda を使用して HTTP エンドポイントを作成するためのシンプルな機能です。
Function URLs は AWS Lambda や、Webhook などの単一機能アプリケーションや Web フレームワークで構築された API 構築を開始する場合に最適です。

より多くの機能を提供する API Gateway の完全な代替ではありませんが、Function URLs は追加コストがなく、タイムアウト制限がはるかに大きい、より単純な代替手段となっています。
この記事では、長所と短所について詳しく説明します。

Lambda Function URLs と Serverless Framework の使用は1つのステートメントで行うことができます。

functions:
  hello:
    handler: handler.hello
    url: true

この新機能を使用するには、Serverless Framework(v3.12.0以降)にアップグレードしてください。

Lambda URLsの詳細

Function URLs は、HTTPS エンドポイントとして関数を公開する AWS Lambda の新機能です。

URL を使用して関数をデプロイするには、serverless.yml の url プロパティを使用します。

functions:
  hello:
    handler: handler.hello
    url: true

サーバーレスデプロイを実行すると、URL が作成され、ターミナル出力に表示されます。

URL は次のようになります。

https://yti4le2qudflx43hh.lambda-url.eu-south-1.on.aws/

そのドメインは Lambda 関数に固有であり、任意の URI パスが関数ハンドラーを呼び出します。

リクエストとレスポンスのイベントペイロードは、API Gateway の HTTP API「バージョン2」ペイロードフォーマットと同じフォーマットに従います。
つまり、コードを変更することなく、Lambda Function URLs から API Gateway の HTTP API に切り替えることができます。

関数の URL に応答する単純な NodeJS Lambda ハンドラーは次のとおりです。

exports.handler = async (event) => {
  return {
    statusCode: 200,
    body: 'Hello world!',
  };
};

エンドポイント構成

エンドポイントはデフォルトでパブリックになっています。 IAM 認証によって保護することもできます。

functions:
  hello:
    handler: handler.hello
    # Public by default
    url: true
 
  world:
    handler: handler.hello
    # This URL is protected by IAM authentication
    url:
      authorizer: aws_iam

CORS は、Function URLs で構成することもできます。

functions:
  hello:
    handler: handler.hello
    url:
      # Allow CORS for all requests from any origin
      cors: true
 
  world:
    handler: handler.hello
    url:
      # Configure CORS in details:
      cors:
        allowCredentials: …
        allowedHeaders: …
        allowedMethods: …
        allowedOrigins: …
        exposedResponseHeaders: …
        maxAge: ….

HTTP API イベントドキュメントで、CORS を設定するためのオプションの完全なリストを表示します。

API Gateway とは異なり、Function URLs には最大実行時間がありません。実行時間は Lambda 関数のタイムアウト(最大15分)によって制限されます。
Function URLs はカスタムドメインをサポートしていないことに注意してください。
解決策は、Function URLs をオリジンとして CloudFront を使用することです。

Function URLs 対 API Gateway

Lambda Function URLs を使用すると、Lambda 関数の HTTP エンドポイントを作成できます。
ここで質問に答えましょう:それは API Gateway とどう違うのですか?

Function URLs は、すべて の HTTP リクエストを1つの Lambda 関数に送信します。

これは、Express や Apollo(ノード)、Flask(Python)などのバックエンドフレームワークとうまくペアになります。実際、これらのフレームワークは、HTTP ルーティング、認証、ミドルウェアなどを処理できます。Function URLs は、Webhook などの単一目的のエンドポイントにも最適です。

単純ですが、このアプローチの欠点は、API 全体が単一の Lambda 関数に含まれていることです。
デプロイされたパッケージのサイズが大きくなることでデバッグが複雑になる可能性があり、権限が実際よりも細かくなります。

API Gateway は、リクエストをフィルタリングし、さまざまな Lambda 関数にルーティングします

これにより、バックエンドフレームワークを使用する必要がなくなります。 API Gateway は、リクエストとレスポンスの変換、さまざまなメカニズムでのクライアントの認証、カスタムドメインのサポート、API キーを介した API アクセスの管理などを処理できます。

API Gateway 機能の正確なリストは v1(REST API)と v2(HTTP API)で異なることに注意してください。

API Gateway はより多くの機能を提供しますが、複雑さとコストも追加されます。

無料枠を超えると、API Gateway v1 は $3.5/ million リクエストで始まり、v2 は $ 1/million リクエストで始まります。
API Gateway とは異なり、Lambda Function URLs はコストを追加しません。

パフォーマンスに関しては、Function URLs の方が API Gateway よりもレイテンシが少ないと予想できます。
実際には、ごくわずかな違いです。クイックテストで測定したレイテンシは次のとおりです。

  • Function URLs は、HTTP 応答時間に9〜10ミリ秒を追加します
  • API Gateway v2 は、HTTP 応答時間に12〜15ミリ秒を追加します

上記のレイテンシは、Lambda の実行期間に追加されます。
これらすべてを詳細に比較してみましょう。

API Gateway RESTAPI Gateway HTTPFunction URL
PricingLambda + API Gateway
$3.5/million requests
Lambda + API Gateway
$1/million requests
Lambda only (no extra costs)
AuthorizersIAM, Lambda, CognitoIAM, Lambda, Cognito, OAuth 2IAM
Custom domainYesYesNo (but possible with CloudFront)
API key managementYesNoNo
CachingYesNoNo
Request transformationYesNoNo
Request/response validationYesNoNo
CORSYesYesYes
CloudWatch access logsYesYesNo
CloudWatch metricsYesYesYes
Maximum HTTP response timeout29s29s15 minutes

ユースケース

API Gateway との比較に基づいて、Lambda Function URLs は次のようなシナリオに最適であると結論付けることができます。

  • ExpressJS / Apollo/Flask などのバックエンドフレームワークで構築された API
  • API Gateway ではやり過ぎになる可能性のある単純な Webhook
  • CloudFront + Lambda(API Gateway をスキップ)で構築されたサーバー側でレンダリングされたウェブサイト
  • 応答時間が29秒(API ゲートウェイの最大タイムアウト)を超える API。たとえば、データのインポートや処理、または長いポーリングのシナリオ

Lambda 関数イベントは Function URLs と API Gateway の HTTP API の間で互換性があることにも注意してください。
つまり、Function URLs は、Lambda で HTTP を使い始め、後で API Gateway にアップグレードしてその機能を使用するための優れた方法になる可能性があります。

これらは単なるアイデアであり、開始するには、Lambda Function URLs に関する Serverless Frameworkのドキュメントを参考にしてください。

まとめ

APIGateway や AppSync による本格的な API 化をするまでもない小さな機能や、ちょっとしたバッチ処理を構築する際は AWS Lambda Function URLs の使用を検討してみてください。私たちは OpenSearch をデプロイした後の「PUT Mappings」で使用することが多々有ります。

低コスト・高速なサーバーレス開発はお気軽にお問い合わせください。