Lambda Layers とデプロイパッケージ

Lambdaのデプロイパッケージは自己完結している必要があります。つまり、すべての依存関係（ライブラリ、SDK、バイナリ）をZIPに含めなければなりません。そのため、パッケージサイズはすぐに大きくなります。たとえば、NumPy、Pandas、SciPyを使用するPythonのデータサイエンス関数では、解凍後のサイズが200 MBを超えることがあります。関数コードを更新するたびに、変更していないライブラリも含めたバンドル全体を再アップロードする必要があります。Lambda Layersは、共有依存関係を関数コードから分離することで、この問題を解決します。

Lambda Layerは、ライブラリ、カスタムランタイム、データ、設定ファイルなどを含むZIPアーカイブです。Layerは関数コードとは別に保存され、関数の実行環境内の/optにマウントされます。複数の関数で同じLayerを共有できるため、Layerを一度更新するだけで、それを使用するすべての関数に反映されます。各Lambda関数には最大5つのLayerを設定でき、展開後の合計サイズは250 MB未満にする必要があります。

Layerを作成するには、使用するランタイムに適したディレクトリ構造（Pythonの場合はpython/lib/python3.12/site-packages/など）で依存関係をパッケージ化し、ZIPに圧縮して公開します。公開すると、LayerにバージョンARNが付与されます。関数にLayerをアタッチするときは、このARNを指定します。Layerを更新するたびに新しいバージョンが作成されます。関数は明示的に更新するまで、設定時に指定されたバージョンを使い続けます。

関数の作成時または更新時に--layersパラメータを使用して、Layerを追加します。Lambdaは関数の開始前に、アタッチされたすべてのLayerを/optにマウントします。/opt/python配下のPythonパッケージは自動的にPythonパスに追加され、/opt/nodejs/node_modules配下のNode.jsモジュールは自動的に検出されます。関数コードでは、Layerのパッケージをローカルにインストールした場合と同じようにimportまたはrequireできます。

AWSは、自分で構築しなくても利用できる公式Layerを公開しています。例として、構造化ログ、トレース、機能フラグを提供するAWS Lambda Powertools Layer、データベースドライバーLayer、SSMやSecrets Managerの値をローカルにキャッシュするAWS Parameters and Secrets Lambda Extension Layerなどがあります。DatadogやNew Relicなどのサードパーティベンダーも、監視エージェント用のパブリックLayerを公開しています。利用可能なパブリックLayerは、Serverless Application RepositoryとLambdaコンソールで確認してください。

Lambda Extensionsは、同じ実行環境内で関数コードと並行して別プロセスとして実行されます。Lambdaのライフサイクルイベント（init、invoke、shutdown）にフックし、テレメトリの収集、セキュリティスキャン、設定のキャッシュなどのタスクを実行します。ExtensionsはLambda Layersとして配布されます。AWSはCloudWatch Lambda Insights extensionとAWS AppConfig extensionを提供しており、ベンダーは拡張機能としてカスタム監視エージェントを提供しています。

Lambdaは、次の2つのデプロイ形式をサポートしています。

• ZIP（圧縮後最大50 MB、展開後最大250 MB）：アップロードが高速で、Layerをサポートし、すべてのランタイムで使用できます。
• Container Image（最大10 GB）：Amazon ECRに保存し、標準のDockerツールを使用します。Layerはサポートしませんが、非常に大きな依存関係（MLモデルや大容量バイナリなど）に適しています。

Container imageでは、Lambdaがハンドラーの呼び出し方法を認識できるように、Lambda Runtime Interface（AWSが提供するベースイメージを使用）を実装する必要があります。

Lambdaのコンテナイメージの構築とデプロイは、標準的なコンテナワークフローに従います。docker buildでビルドし、Amazon ECRにpushしてから、Lambda関数の作成時または更新時にイメージURIを指定します。コンテナイメージはイミュータブルです。各イメージタグは、特定の関数バージョンに対応します。Lambdaはインフラストラクチャ内にコンテナイメージをキャッシュするため、初回以降のコールドスタートはより高速になります。

LambdaのVersionsは、関数コードと設定のイミュータブルなスナップショットです。バージョンを公開するたびに、Lambdaはデプロイパッケージ、環境変数、Layerを固定します。Aliasesは、特定のバージョンを指す名前付きポインターです。たとえば、prodはバージョン5を、stagingはバージョン6を指すように設定できます。また、weighted aliasesを使用して、新しいバージョンに一定割合のトラフィックをルーティングし、カナリアデプロイを行うこともできます（例：v6に10%、v5に90%）。

Layerにもバージョンがあります。新しいLayerバージョンを公開しても、既存の関数は更新されるまで、固定されたバージョンを使い続けます。そのため、共有Layerを安全に更新し、すべての関数を同時に壊すことなく、新しいバージョンを段階的に展開できます。最終的には、ストレージと保守の負担を減らすため、古いLayerバージョンを非推奨にしてください。コンソールから削除しても、どの関数からも参照されなくなるまで、LambdaはLayerバージョンを保持します。

展開後の合計サイズが250 MB未満で、複数の関数間で依存関係を共有したい場合や、Layerを一度更新するだけですべての関数に反映させるなど、迅速に反復したい場合はLayersを使用します。依存関係が250 MBを超える場合、カスタムベースOSパッケージを使う必要がある場合、既存のDockerワークフローがある場合、または大容量アセット（MLモデルや参照データベースなど）をまとめたい場合はContainer Imagesを使用します。コンテナイメージはLambda Layersと互換性がありませんが、より高い柔軟性を提供します。

このレッスンで扱ったAWS Solutions Architect（SAA-C03）の概念について、理解度を確認しましょう。

このレッスンでは、Lambda Layersによって共有依存関係を関数コードとは別にパッケージ化し、パッケージサイズを削減するとともに複数の関数で再利用できること、Container Images（ECR経由で最大10 GB）は依存関係がZIPの上限である250 MBを超える場合や、すでにDockerワークフローを利用している場合に適していること、そしてVersioning and Aliasesによってイミュータブルなリリースと、重み付けしたトラフィック分割によるカナリアデプロイを実現できることを学びました。次はLambda@Edgeとイベント駆動パターンについて学びます。