[レポート] AWS Lambda layers deep dive #SVS321 #reinvent
CX事業本部@大阪の岩田です。 本エントリはSVS321-R AWS Lambda layers deep dive
のレポートとなります。
セッション情報
AWS Lambda layers and runtime API let developers publish and share libraries and runtimes that are compatible with Lambda. Using layers allows separation of concerns. Publishers can build reliable, hardened software and share it as Lambda layers for other AWS developers to consume. Application developers can consume one or more layers in their functions, letting them focus on writing business logic. The Lambda runtime API codifies the runtime-calling conventions and integration points of a Lambda-compatible runtime. In this session, you learn best practices for designing, using, and sharing Lambda layers to make your serverless app more robust while writing less code.
レポート
サーバーレスアプリケーションとは
- イベントソース
- データソースに対する変更
- エンドポイントへのリクエスト
- リソースの状態変更
- Lambda Function
- Node.jsやPython等様々なランタイムで関数を書くことができる
- サービス
- Lambda Functionから連携するAWSの各種サービス
Lambda Functionの構造
- Lambda Functionの構成要素は以下の3つ
- Handler function
- ユーザーが作成したコード
- イベント発生都度実行される
- Event object
- Lambda function実行時に送られてきたデータ
- イベント発生元から送られてくる
- Context object
- ランタイムの情報を取得するためのオブジェクト
- リクエストIDやロググループ等の情報を含む
- コードの性質からLambda Functionを分類すると以下のようになる
- ライブラリの依存関係やimport処理、設定情報
- 共通のヘルパー関数
- ビジネスロジックが書かれたSub Function
- Sub Functionは肥大化していく
- 例えばLambdaの初期化処理内でSecretManagerからシークレットを取得してDBに接続するような処理は、多くのLambda Functionで共通化したいヘルパー関数になる
Lambda Layers
- Layerを使うことでこういった共通処理をLamba Function間で共有することが容易になる
- Lambda Functionに対してLayersを紐づけることで利用する
- Layerを使うことで様々なものをLamba Function間で共有できる
- 依存ライブラリ
- トレーニング用のデータ
- 設定ファイル
- LayerとFunctionで責務を分離することでイテレーションが高速化し、開発者はビジネスロジックの実装に集中できるようになる
Lambda Layersのユースケース
- 2つ以上のLambda Functionから共通利用されるコードの共有
- ビジネスロジックの実装をシンプルにするためのライブラリ、モジュール、フレームワークの共有
Lambda Layersの使い方
- 共通部品をZIP化してLayerとしてアップロードする
- Layersはイミュータブル(変更不可)でLayersの更新はバージョンIDで管理される
- バージョンが削除されたり、権限が剥奪されたとしても、対象バージョンのLayersを利用している作成済みLambda Functionは動作を継続することができる。ただし、新しくLayersとひもづけることはできなくなる。
- 1つのLambda Functionに対してLayersを5つまで紐づけることが可能。また、Layersはカスタムランタイムとして利用することも可能。カスタムランタイムを使うことで、どんな言語でもLambda上で実行することができる。そう、COBOLでも
Lambda Layersを使うメリット
- ビジネスロジックと依存関係の関心の分離を促進する
- Lambda Functionのコードベースを小さく保つことができ、ビジネスロジックの実装に集中することができる
- デプロイ時に毎回依存ライブラリをパッケージングする必要がなくなり、デプロイが高速化する
Lambda Layersがどのように動作するか
- ZIPファイルがLambda実行環境の
/opt
に展開される。1~5のLayersが順番に展開されるので、1つ目のLayersで展開したファイルは2~5番目のLayersで展開したファイルで上書きされる可能性がある。 - このアプローチをLambda実行環境のカスタマイズ用に使うことが可能
- 1つ目のLayerをカスタムラインタイムとして利用
- 2つ目のLayerには利用したいライブラリの特定バージョンを追加する など
- LayersのサイズもLambdaFunctionのストレージ上限(75G)に計上される
Layer内のライブラリの依存関係解決について
- ランタイムごとにライブラリを配置するパスが決まっているので、それに合わせた階層構造でZIPファイルを作成する
Lambda Layersのパーミッションについて
- Layersの以下のパターンで共有利用できる
- 1つのAWSアカウント内の複数Lambda Functionで共有利用
- AWSアカウントを跨いで共有利用
- SAR(Serverless Application Repository)を利用してパブリックに公開して共有利用
SAMとの統合
- SAMもLambda Layersに対応している
- AWS::Serverless::LayerVersionという記法が利用可能
- SAM CLIを利用することでローカル環境でLayersを含むLambda Functionのテストが実行できる
- ローカル環境のテスト用にDockerイメージをビルドする際、Layersのソースとして指定されたディレクトリとFunctionのソースとして指定したディレクトリをそれぞれDockerコンテナにマウントする
デモ
- 最新版のboto3をLayersとしてデプロイし、Functionから利用するデモ
- 共通関数をLayersとしてデプロイし、Function間で共有するデモ
- SARで公開されているLayersの紹介
等
まとめ
昨年のre:inventで紹介されたLambda Layersの機能についてまとまった良いセッションでした。まだLayersを使ったことのないLambdaビギナーの方は是非Layersの利用に挑戦してみて下さい。