Lambda Extensionsは何が嬉しいのか

先日2020/10/09、Lambdaの新機能 Lambda Extensionsがプレビューリリースされました。

公式情報は以下です。

Introducing AWS Lambda Extensions – In preview
Building Extensions for AWS Lambda – In preview
aws-samples/aws-lambda-extensions - Github

これらをざっと読んでみたのですが、「いまいち何が嬉しいのかよくわからないなぁ…」というのが私の感想でした。理解力が乏しく悲しい。
ですが、今回公式パートナーとしてリリースと同時にExtensionを提供したLumigoのブログを読むと良く理解できたので、学んだ内容を私なりに編集してお伝えしたいと思います。

Lumigoはサーバーレスやマイクロサービスアプリケーション向けのモニタリングやデバッグを助けてくれる3rd Partyツールであり、そのベンダーです。
※ですので、以下の話はLumigoのようなモニタリング機能を提供するツールまたはそのベンダーの立場からの内容です。Extensionsにはモニタリング以外にもセキュリティの機能やガバナンスの機能などを持たせることができますし、そういったベンダーのExtensionsもすでに公開されています。

サーバーレスじゃない場合のモニタリングツール

まず、サーバーレスじゃない、例えばEC2インスタンス上で稼働しているアプリケーションのモニタリングを行なうことを考えてみましょう。こういう場合、通常はサーバー上にエージェントとかデーモンとか呼ばれる常駐プログラムを仕込んで、そいつが各種メトリクスを収集して、外部の（サーバー外の）そのモニタリングツールのエンドポイントにデータを定期的に送信します。その後そのデータをそのモニタリングツールで参照できるようになります。

この常駐プログラムはできるだけサーバーに負荷をかけないように設計されています。モニタリングツールがパフォーマンスのボトルネックになってしまうと本末転倒なので。たとえば、ツールのエンドポイントにデータを送信するのは、データ収集する度に行なうのではなく、何回かの分をまとめて送ったりします。そうすることでリクエスト数を減らして、負荷を減らします。

また、常駐プログラムはアプリケーションから独立しているので、アプリケーションと同じ言語で実装されている必要はありません。

Lambdaでは無理

このアプローチは、Lambdaでは不可能です。Lambda実行環境に常駐プログラムをインストールすることができないからです。3rd PartyではないAWSのみが、X-RayやCloudWatchを介してメトリクスを収集することができました。

というわけで、3rd Partyツールベンダーは別の方法を取る必要がありました。Lambdaの呼び出し内で、メトリクスデータを自分たちのエンドポイントに送信してもらうようにするか、CloudWatch Logsにデータを送ってもらい、CloudWatch Logsの内容を自分たちのツールから参照するかです。

前社の場合、各言語ごとのライブラリを用意する必要があります。後者の場合、CloudWatch Logsの料金が余計にかかります。多くの場合、これはLambda自体の料金より高く付きます。

どちらの方法をとる場合でも、常駐プログラムでやっていたような、データを貯めてあとでまとめて送る、ということはできません。送信前に実行環境が破棄される可能性があるからです。また、開発者にコードを追加してもらう実装コストが増えます。関数の実行時間も伸びます。

Lambda Extensionsで…

• Lambda Layer としてExtensionsを導入するだけで、Lumigoのような3rd Partyツールによるモニタリング（メトリクス送信）が可能になります。Lambda関数内に追加処理を入れる必要はありません。言語の縛りもありません。
  • ※Extensionsの設定のために、関数の環境変数の設定が必要な場合はあります。
  • ※ExtensionsでAWSリソースへのアクセスがある場合、関数にアタッチするロールにその権限を与える必要があります。
• データを貯めてあとでまとめて送る、ができます。実行環境が破棄される前に、ExtensionsにはSHUTDOWNイベントが送信され、2秒間何かしらの処理を実行することができます。
  • この2秒の処理については、プレビュー期間中は課金されませんが、GA以降は課金される予定です。
• 実行時間への影響は、発生する可能性があります。ざっくりとは、並列実行によってできるだけ処理時間を伸ばさないようにしていますが、Extensions含めすべての処理が終わらないとフェーズが終わらないので、影響が出る可能性がある、という感じです。
  • まず、Lambda実行環境作成時、いわゆるCold Start発生時には、ランタイム初期化 前 にExtensionの初期化は始まり、各Extensionの初期化は並列で、かつランタイム初期化とも並列で実行されます。が、関数全体のinitフェーズの終了はランタイムと全Extensionsの準備が整ったタイミングです。つまりExtensionsの準備に時間がかかるとCold Start時間が伸びる可能性があります。
  • また、関数実行時の処理は、各Extensionの処理と関数の処理、すべて並列で実行されます。が、この実行フェーズの終了は先程のinitフェーズと同じく、関数と全Extensionsの処理が終わったタイミングです。ですので、処理の長いExtensionがあれば実行時間が伸びますし、課金も増えます。
  • CloudWatchメトリクスにPostRuntimeExtensionsDurationというメトリクスが増えました。Extensionsによって余計にかかった実行時間が記録されるメトリクスです。これを使ってExtensionsがパフォーマンスに悪影響を与えているか調べましょう。

※ 処理の並列性と各フェーズの関係については、以下の図がわかりやすいかと思います。

まとめ

Extensionsの利点、伝わりましたでしょうか。端的にはAWSリリースブログに書かれている「あなたのお気に入りのツールをLambdaでかんたんに使えるようにする新機能」なのですが、それが具体的にどういうことなのかということが少しでも伝われば幸いです。