AWS Lambda Extensions（プレビュー）のご紹介

AWS Lambdaは、Lambda Extensionsのプレビューを発表しました。Lambda Extensionsは、お好みのモニタリング、オブザーバビリティ、セキュリティ、ガバナンス用ツールとLambdaとの統合を簡単にする新しい方法です。このブログでは、Lambda Extensionsがどのように動作するのか、どのように使い始められるか、さらに、AWS Lambda Ready パートナーの提供する現在利用できるextensionについて説明します。

お客様が既に使用しているツール群とLambdaを統合をしたいというリクエストは数多く寄せられており、Extensionsはその問題を解決するサポートをしてくれます。お客様からは、自分の使いたいツールとLambdaをつなげるために、追加の作業や設定を行うことが必要だという指摘が以前からありました。さらに、ログエージェントなどの長時間実行されるプロセスが必要なツールをLambda上で実行するのは、かなり難しいことでした。

Extensionsは、ツールがLambda環境と深く統合するための新しい方法です。複雑なインストレーションや設定は必要なく、お客様のアプリケーションポートフォリオ上にある好きなツールを簡単に使えるようになります。例えば以下のようなユースケースでExtensionsを使用できます：

• 関数呼び出し前、呼び出し中、呼び出し後の診断情報をキャプチャーする
• コード変更なしにコードの計測を自動的に行う
• 関数の呼び出し前に設定やシークレットを取得する
• 関数とは別のプロセス上で実行されている堅牢なセキュリティエージェントを通して、関数のアクティビティを検知・アラートする

ExtensionsはAWS、AWS Lambda Readyパートナー、またオープンソースプロジェクトから使用することができます。本日時点（2020年10月8日 PDT）で AppDynamics、Check Point、Datadog、Dynatrace、Spsagon、HashiCorp、Lumigo、New Relic、Thundra、Splunk SignalFX、AWS AppConfig、Amazon CloudWatch Lambda Insightsのextensionが利用可能です。

どのように自分用のextensionを作成するかや、Lambdaのライフサイクルの変化についてのディープダイブについては、関連記事である“AWS Lambda Extensions (プレビュー) を構築する“をご覧ください。

概要

Lambda Extensionsは、複雑なインストレーションや構成管理を必要とせずに、簡単にお客様が現在使用しているツールにつなぐことができるよう設計されています。ExtensionをAWSマネジメントコンソールやAWS Command Line Interface (AWS CLI)経由でLambdaレイヤーとしてデプロイすることができます。AWS CloudFormationやAWS Serverless Application Model (AWS SAM)、Serverless Framework、Terraformなどのinfrastructure as codeツールからも使用できます。 また、Epsagon、New Relic、Lumigo、Thundraからの統合をStackeryを使って自動化できます。

Lambda Extensionsの機能には、Extensions APIとextension自体の２つのコンポーネントが存在します。Extensionは、新規Lambda Extensions APIを使用して構築されます。Lambda Extensions APIは、関数の初期化時、呼び出し時、シャットダウン時にツールをより詳細に制御する方法を提供します。既存のランタイムインターフェースは、カスタムランタイムをLambdaに持ち込む機能があります。Lambda Extensions APIは、この機能を使用するためにランタイムインターフェース上に構築されています。

ほとんどの利用者は、内部で動いているExtensions APIの機能を知らなくてもextensionを使用することができます。お客様のLambda関数内でオプションの設定をするだけでextensionの機能を利用できます。Extensionを構築する開発者は関数と実行環境ライフサイクルイベントを登録するためにExtensions APIを使用します。

Extensionsはinternalとexternal二つのモードで実行することができます。

• Internal extensionsは、利用者のコードと同じランタイムプロセスの一部として実行されます。ランタイムプロセスの起動を言語固有の環境変数とラッパースクリプトを用いて変更できます。Internal extensionsを用いて、コードの自動計測などのユースケースを実現することができます。
• External extensionsは、対象のLambda関数のランタイムプロセスと同じ実行環境内の、別のプロセスで動作させることができます。External extensionsは、呼び出し前にシークレットを取得したり、関数呼び出しの外にいるカスタムな送信先へと測定情報を送信したりするようなユースケースで使用できます。こういったExtensionsはLambda関数に付随するプロセスとして実行されます。

より詳細なExtension APIやLambdaのライフサイクルの変更についての情報は、こちらの記事、“AWS Lambda Extensions (プレビュー) を構築する”をご覧ください。

ローンチ時に利用可能なAWS Lambda Readyパートナーextension

本日時点（2020年10月8日 PDT）で、以下のAWSサービスやAWS Lambda Readyパートナーツール向けにextensionが利用できます。今後さらに増えていく予定です。

• AppDynamicsは、Lambda用のエンドツーエンドトランザクショントレーシングを提供します。AppDynamics extensionを使用すると、開発時の関数コードにAppDynamicsトレーサの依存性をインクルードしなくても良くなります。ハイブリッドアーキテクチャを跨がるトランザクショントレーシングをより一層単純化できます。
• Datadog extensionは、利用者のサーバーレスアプリケーションに、包括的でリアルタイム性の高い可視性をもたらします。既に存在しているDatadogとAWSの統合と組み合わせることによって、どのような規模に対しても監視、検知、そして問題の解決ができるような、メトリクスやトレース、ログが手に入ります。Datadog extensionはサーバーレスワークロードからの測定情報の取得をかつてないほど簡単にします。
• Dynatrace extensionは、DynatraceプラットフォームへのAWS Lambdaメトリクスやトレースをより一層簡単にし、その情報をインテリジェント・オブザーバビリティと根本原因の自動検知のために利用することができます。包括的なエンドツーエンド・オブザーバビリティを、スイッチ一つでコード変更なしに手に入れましょう。
• Epsagonは、Lambda関数の監視やトラブルシュート、コスト削減のサポートをしてくれます。Espagonのextensionは、関数へのパフォーマンス影響を最小限に、Espagonサービスへのトレース送信のオーバヘッドを削減してくれます。
• HashiCorp Vaultを利用して、アプリケーションのシークレットや機微データを、保護、蓄積さらに厳重にアクセス制御をすることができます。Vault extensionを使用すると、Lambda関数が実行される前に認証を行うことにより、動的なシークレットを安全に取得することができるようになります。
• Lumigoは、サーバーレスとマイクロサービスのアプリケーション向けに監視やオブザーバビリティが目的のプラットフォームを提供しています。Lumigo extensionは、新しいLumigo Lambda Profilerを有効にし、CPUやメモリ、またネットワークメトリクスといった関数リソースの詳細を見ることができるようになります。実用的なインサイトを受け取って、Lambdaランタイムの実行時間やコストの削減、ボトルネックの修正や効率化をしていきましょう。
• Check Point CloudGuardは、サーバレスアプリケーションの完全なライフサイクルセキュリティを提供します。CloudGuard extensionは、アプリケーション層への攻撃の検知やアラートを提供するFunction Self Protectionデータ集約を外部プロセスで動作するextensionとして有効化します。
• New Relicは、利用者のソフトウェアスタック全体に対して、統一的なオブザーバビリティ体験を提供します。New Relic extensionは、関数の測定情報をレポートするためのシンプルなコンパニオンプロセスを使用します。こうすることにより、New Relicをアプリケーションへ導入する際に必要なAWSパーミッションが少なくなるという効果もあります。
• Thundraは、サーバレスやコンテナ、またバーチャルマシン（VM）のワークロードを対象に、アプリケーションのデバッグとオブザーバビリティ、セキュリティ向けプラットフォームを提供します。Thundra extensionは、非同期的に観測情報をレポートする機能をThundraエージェントに追加し、ネットワークレイテンシを排除します。
• Splunkは、大規模でリアルタイムかつフルスタックな可視性を実現するためのエンタープライズレベルのクラウド監視ソリューションを提供します。Splunk extensionは、最小限のオーバーヘッドで高精度なオブザーバビリティデータを収集するための、ランタイムが独立している簡略化されたインターフェースを提供します。サーバーレスアプリケーションの監視、管理、そしてパフォーマンスやコストの最適化をSplunkオブザーバビリティソリューションで実現してください。
• AWS AppConfigは、ランタイム上のホストに対して、アプリケーションの設定の管理・保持・安全なデプロイをサポートします。AWS AppConfig extensionは、LambdaとAWS AppConfigをシームレスに統合します。Lambda関数は、素早く簡単に外部の設定情報に対するシンプルなアクセス方法を手に入れることができ、開発者は、堅牢な検証の仕組みを安全に利用しながら、動的にLambda関数の設定を変更することができるようになります。
• Amazon CloudWatch Lambda Insightsは、Lambda関数を効率的に監視、トラブルシュート、そして最適化することのできるツールです。Lambda Insights extensionは詳細な計算パフォーマンスメトリクスや、エラー、ログに対する収集・可視化・調査を簡素化することができます。パフォーマンス問題をより一層簡単に分離・関連付けを行うことにより、Lambda環境を最適化することができるようになります。

組織のツールと統合して、自分用のextensionを構築することもできます。例えば、Square社のCloud Foundationsチームは、彼ら用のextensionを構築しました。彼らはこのように述べています：

Square社のCloud Foundationチームは、クラウドをアクセシブルでセキュアにするためのチームです。我々は、同じくSquare社内の機微情報を保護するインフラストラクチャを構築するチームである、セキュリティインフラストラクチャチームとパートナーを組んで、Squareにサーバーレスアプリケーションの導入を行ったり、mTLSアイデンティティのLambdaへの提供を行ったりしました。

Lambdaに対する業務の初期から、我々は合理化された開発体験を構築することに集中していました。Lambdaを使用しているチームはAWSのことをたくさん学ばなければなりませんでしたが、extensionsは共通のユースケースを無視して考えることのできる良い方法だと気付きました。初期調査では、シークレットにより簡単にアクセスできるような方法を探そうとしました。我々の使用しているツールでは、それぞれのLambda関数が大体3-5個ほどのシークレット情報を取得するようになっていたためです。

我々が構築しオープンソース化したextensionは、コールドスタート時、Lambda関数が実行される前にシークレットを取得します。それぞれの関数は設定ファイルを含んでおり、そのファイル上でどのシークレットを取得するかを指定することができます。この設定ファイルが、「Lambda関数は実行する必要があることだけを実行すべき」という考え方に対しての解答であるという確信がありました。シークレットはローカルの/tmpフォルダにキャッシュされ、関数は必要な時にそのフォルダからシークレットデータを読み込みます。こうすることにより、Lambda関数はただ単に高速化されるだけでなく、シークレットにアクセスするためのコード量も削減することができるのです。

Square社のCloud Foundationsチームが構築したextensionは、“Lambda-Secrets-Prefetch“でご覧になれます。より詳細については、“Using AWS Lambda Extensions to accelerate AWS Secrets Manager access“をご覧ください。

AWS AppConfigを使用したextensionsの実行例

このデモでは、Lambda関数を通してAWS AppConfigを利用する例を示します。AWS AppConfigは、AWS Systems Managerの機能の一つで、アプリケーション設定を作成、管理、そして高速にデプロイすることができるというものです。アプリケーション自体の再デプロイを行うことなく、外部設定を動的にデプロイすることができるようになります。AWS AppConfigは堅牢な検証機能を有しており、全ての設定変更について、アプリケーションに投入する前に安全にテストを行うことができます。

AWS AppConfigには、利用可能なextensionがあります。このextensionを使うことにより、Lambda関数は外部設定情報に素早く簡単にアクセスすることができるようになります。このextensionは、独立したローカルプロセスで実行されており、AWS Configサービスから、設定情報を取得しキャッシュを行います。関数コードは、ネットワーク越しに行うよりも高速に、設定情報をローカルから取得することができるようになります。

今回の例は、こちらのGitHubリポジトリのREADME.mdファイルに記載された指示に従って設定を行ってください。

この例は、AWS AppConfigのアプリケーション、環境、そして設定プロファイルを作成するものとなります。設定プロファイルは、 loglevelの値を格納しており、初期値はnormalとなっています。

AWS AppConfigのデプロイが実行され、初期設定が投入されます。

今回の例では、二つのLambda関数がAWS AppConfig extensionを使用しています。AppConfig extensionを含んだレイヤーのリストについては、AWS AppConfig documentationをご覧ください。

ExtensionはLambda関数と同じ権限を共有するので、関数はAppConfigの設定を取得する許可をもつ実行ロールを保持している必要があります。

関数は、loglevelの値をAWS AppConfigから取得するためにextensionを利用し、戻り値として値が返ってきます。本番アプリケーションでは、この値は関数コードの中でどのレベルの情報をCloudWatch Logsに送信するかを決定するために使用されるかもしれません。例えば、アプリケーションの問題をトラブルシュートする際、一元的にloglevelの値を変更することができます。どちらの関数についても、後続の関数呼び出しには更新された値が使用されることになります。

また、どちらのLambda関数についても、どのAWS AppConfigの設定プロファイルと値を使用するかを特定するために、環境変数に設定があります。

この関数は、呼び出しがコールドスタートかどうかも返却します。

テスト用のペイロードで実行した関数は、loglevelの値をnormalで返します。最初の呼び出しはコールドスタートです。

{
  "event": {
    "hello": "world"
  },
  "ColdStart": true,
  "LogLevel": "normal"
}

続いての呼び出しは、ColdStartがfalseになって返ってきていますが、それ以外は同じ値です。

{
  "event": {
    "hello": "world"
  },
  "ColdStart": false,
  "LogLevel": "normal"
}

新しいAWS Configのhosted configuration profile versionを作成し、loglevelの値をverboseに設定します。新しいAWS AppConfigデプロイを実行し、値を更新します。どちらの関数のextensionも新しい値を取得します。関数の設定自体の変更はありません。

もう一度両方の関数を呼び出してみると、コールドスタートではないにもかかわらず、更新された値が返されます。

{
  "event": {
    "hello": "world"
  },
  "ColdStart": false,
  "LogLevel": "verbose"
}

AWS AppConfigがLambdaとシームレスに連携し、複数のLambda関数に対して関数設定を再デプロイすることなく、動的に外部設定情報を更新できることが確認できました。

関数設定で必要とされるのは、AWS AppConfig extensionを含むレイヤーを追加することだけです。

AWS AppConfig extensionについてさらに情報が必要であれば、“Deploying application configuration to serverless: introducing the AWS AppConfig Lambda extension“をご覧ください。

価格体系

ExtensionsはLambda関数と請求モデルを共有しています。Lambda関数をextensionを含めて使用すると、リクエスト回数での課金と、お客様のコードと全てのextensionを実行するために使用した計算時間の合計が100ms単位で課金が発生します。Extensionsの料金についてより詳細が必要であれば、Lambdaのよくある質問ページをご覧ください。

Extensionsのリソース、セキュリティ、そしてパフォーマンス

Extensionsは関数コードと同じ実行環境で実行されます。そのため、CPUやメモリ、ディスクストレージ、環境変数などについては、実行対象の関数と共有することになります。また、対象の関数と同じAWS Identity and Access Management (IAM) ロールを使用するため、パーミッションを共有することになります。

一つの関数に一度に最大5個のレイヤーを使用でき、最大10個のextensionを設定できます。複数のextensionを一つのレイヤーに含めることができます。

Extensionのサイズは、デプロイパッケーサイズのリミットのカウントの対象になります。これは、非圧縮時のデプロイパッケージのサイズの上限が250MBを超えてはならないというものです。

External extensionsは、ランタイムが開始される前に初期化されるので、関数が呼び出される前の遅延が増加することがあります。現在のところ、関数呼び出しのレスポンスは、全てのextensionsが完了してから返されます。完了に時間のかかるextensionは関数のレスポンスが返却されるまでの時間を遅延させる可能性があります。Extensionが計算負荷の高い操作を行う場合、関数の実行時間が増加することがります。関数実行の後に発生するextensionの追加の実行時間を計測したければ、PostRuntimeExtensionsDurationいう新しいCloudWatchメトリクスを使用して、関数実行後にextensionにかかった延長時間を計測することができます。特定のextensionの影響を理解するには、DurationやMaxMemoryUsedといったCLoudWatchメトリクスを使用し、対象のextensionを使用した場合としない場合の違うバージョンでの実行を比べて見ることができます。関数にメモリを追加すると、追加量に比例してCPUとネットワークスループットを増加させることができます。

関数と付随するextensionsは、その関数のタイムアウト設定内に完了しなければなりません。これは呼び出しフェーズ全体に適用されるものです。

結論

Lambda extensionsを用いると、Lambdaサービスをお好みのモニタリング、オブザーバビリティ、セキュリティ、ガバナンス用ツールと統合可能にします。

現在のところ、AWS Lambda Readyパートナーから様々なextensionsが利用可能で、インストールをすることができます。ユースケースとして、アプリケーションのパフォーマンス監視、シークレット管理、構成管理、脆弱性検知などがあります。Extensionsを利用することにより、現在お客様が使用しているツールをサーバーレスアプリケーションに簡単に導入できます。

AWS AppConfig extensionを試す場合は、こちらのGitHubリポジトリのREADME.mdファイルの記載された指示に従って設定を行ってください。

また、Extensions APIを使用して、現在利用しているツールと統合するためのextensionをご自身で構築することもできます。より詳細な情報については、関連記事の“AWS Lambda Extensions (プレビュー) を構築する“をご覧ください。

Extensionsは現在プレビューとして、次のリージョンでご利用いただけます： US East (N. Virginia), US East (Ohio), US West (N. California), US West (Oregon), AWS GovCloud (US-East), AWS GovCloud (US-West), Canada (Central), EU (Ireland, EU (London), EU (Paris), EU (Frankfurt), EU (Stockholm), EU (Milano), South America (Sao Paulo), Africa (Cape Town), Middle East (Bahrain), Asia Pacific (Tokyo), Asia Pacific (Seoul), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Mumbai), and Asia Pacific (Hong Kong)。

サーバーレスのことをより詳しく学びたければ、https://serverlessland.comをご参照ください。

翻訳はソリューションアーキテクト野村が担当しました。原文はこちらです。