レイヤーによる Lambda 依存関係の管理 - AWS Lambda
レイヤーによる Lambda 依存関係の管理 - AWS Lambda
レイヤーの使用方法レイヤーとレイヤーバージョン

レイヤーによる Lambda 依存関係の管理

Lambda レイヤーは、補助的なコードやデータを含む .zip ファイルアーカイブです。レイヤーには通常、ライブラリの依存関係、カスタムランタイム、または設定ファイルが含まれています。

レイヤーの使用を検討する理由は複数あります。

  • デプロイパッケージのサイズを小さくするため。関数コードとともにすべての関数依存関係をデプロイパッケージに含める代わりに、レイヤーに配置します。これにより、デプロイパッケージは小さく整理された状態に保たれます。

  • コア関数ロジックを依存関係から分離するため。レイヤーを使用すると、関数コードと独立して関数の依存関係を更新でき、その逆も可能となります。これにより、関心事の分離が促進され、関数ロジックに集中することができます。

  • 複数の関数間で依存関係を共有するため。レイヤーを作成したら、それをアカウント内の任意の数の関数に適用できます。レイヤーがない場合、個々のデプロイパッケージに同じ依存関係を含める必要があります。

  • Lambda コンソールのコードエディターを使用するため。コードエディターは、関数コードの軽微な更新をすばやくテストするのに便利なツールです。ただし、デプロイパッケージのサイズが大きすぎる場合は、エディターを使用できません。レイヤーを使用すると、パッケージのサイズが小さくなり、コードエディターの使用制限を解除できます。

Go や Rust で Lambda 関数を使用している場合は、レイヤーを使用しないことをお勧めします。Go 関数と Rust 関数の場合、関数コードが実行可能ファイルになります。つまり、コンパイル済みの関数コードがそのすべての依存関係と共に含まれています。レイヤーに依存関係を配置した場合、他に必要なアセンブリがあれば、初期化フェーズ中にいちいちロードされるため、コールドスタート時間が長くなる可能性があります。Go 関数と Rust 関数で最適なパフォーマンスが得られるよう、デプロイパッケージと共に依存関係を含めてください。

次の図は、依存関係を共有する 2 つの関数間の大まかなのアーキテクチャの違いを示しています。一方は Lambda レイヤーを使用し、もう一方は使用しません。

レイヤーを使用しない 2 つの関数と、レイヤーを共有する 2 つの関数の比較。

関数にレイヤーを追加すると、Lambda は関数の実行環境の /opt ディレクトリにレイヤーのコンテンツを抽出します。ネイティブにサポートされているすべての Lambda ランタイムには、/opt ディレクトリ内の特定のディレクトリへのパスが含まれています。これにより、関数はレイヤーコンテンツにアクセスできるようになります。これらの特定のパスの詳細とレイヤーを適切にパッケージ化する方法については、レイヤーコンテンツのパッケージング を参照してください。

各関数につき最大 5 つのレイヤーを含めることができます。また、レイヤーは、.zip ファイルアーカイブとしてデプロイされた Lambda 関数でのみ使用できます。コンテナイメージとして定義された関数では、コンテナイメージの作成時に、優先ランタイムとすべてのコード依存関係をパッケージ化します。詳細については、AWS コンピューティングブログの「コンテナイメージの Lambda レイヤーと拡張機能を使用する」を参照してください。

トピック

レイヤーの使用方法

レイヤーを作成するには、通常のデプロイパッケージの作成と同様に、依存関係を .zip ファイルにパッケージ化します。具体的には、レイヤーの作成と使用の一般的なプロセスには、次の 3 つのステップが含まれます。

レイヤーとレイヤーバージョン

レイヤーのバージョンは、レイヤーの特定のバージョンの不変のスナップショットです。新しいレイヤーを作成すると、Lambda はバージョン番号 1 の新しいレイヤーバージョンを作成します。レイヤーの更新を発行するたびに、Lambda はバージョン番号を増やし、新しいレイヤーバージョンを作成します。

すべてのレイヤーバージョンは、一意の Amazon リソースネーム (ARN) により識別されます。関数にレイヤーを追加する場合、使用したいレイヤーバージョンを正確に指定する必要があります。