AWS Lambda#
AWSのFaaSサービス。
Bare Metal EC2（Worker）上のKernel Virtual Machines上で、数百～数千のFirecracker MicroVMsを起動し、その中で動かす。
（出所：AWS Whitepaper: Security Overview of AWS Lambda）
Firecracker#
Linux Kernel-based Virtual Machine (KVM)を使ってmicroVMsを作り、管理するためのツール（virtual machine monitor: VMM）。
AWS LambdaやAWS Fargateで使われている。
Dockerのようなコンテナ仮想化技術はホストマシンのカーネルを複数のコンテナで共有しており、コンテナ間で環境が完全には分離されない。 AWS側が安全にサービスを提供するにあたって環境の分離が必要になり、Firecrackerが開発された。
ハイパーバイザにあたる（知らなくても困らないけど、知ると楽しいAWS Lambdaの裏側の世界 #devio2021 - YouTube）
デプロイ方法ごとの特色#
zipでのデプロイをしたときの扱い#
少なくともコンテナイメージでのデプロイをサポートする前は、zipをS3からダウンロードしてMicroVM上に展開していたらしい。
In the first generation architecture (before this work), when a new MicroVM is created with new capacity for a particular function, the Worker downloads the function image (a .zip file up to 250MiB in size) from Amazon S3, and unpacks it into the MicroVM guest’s filesystem. (Brooker, et al., 2023)
コンテナイメージをサポート後もzipデプロイ時のシステムは同様なのかはよくわからなかった。パッケージサイズが大きくなったときにimageほどinit Durationが短くないので、以前と変わらない方法をとっていそう。
コンテナイメージでデプロイした場合#
512KiBごとのチャンクに分割して重複削除してキャッシュするので、見た目のサイズより高速になる
公式のベースイメージだとインスタンスに近いところにキャッシュがあったり、すでにWorkerにロードされてたりするのでinitが高速
コンテナ読み込みを支える技術#
重複削除#
多くのイメージは同じ内容を含む：Lambda利用者のコンテナイメージの約75%は、ユニークなバイトが5%未満
重複を削除して効率的にキャッシュを作る
単一のフラット ファイル システムに展開し、そのファイル システムを 512KiB のチャンクに分割する。次に、チャンクをハッシュして一意のコンテンツを識別し、キャッシュ レイヤーに同じデータのコピーが多すぎるのを回避
Brooker et al. (2023). On-demand Container Loading in AWS Lambda
Brooker, M., Danilov, M., Greenwood, C., & Piwonka, P. (2023). On-demand Container Loading in AWS Lambda. In 2023 USENIX Annual Technical Conference (USENIX ATC 23) (pp. 315-328).
ATC ‘23 (paper & video)
arxiv.org/pdf/2305.13162 (paper)
Container Loading in AWS Lambda - Marc’s Blog (Brookerのブログでの解説)
Deep dive into AWS Lambda security: Function isolation (re:Invent 2021)
Lambdaの最適化#
公式ベースイメージを使う#
公式ベースイメージは見かけ以上に高速に読み込まれる
個人的には経験上これは感じていたが、実際にAWSのブログにも書かれている
Optimizing Lambda functions packaged as container images | AWS Compute Blog
の「Use AWS-provided base images」の部分には以下のようなことが書かれている。
たとえば、AWS が提供する Go ランタイム
public.ecr.aws/lambda/go:1のベースイメージは 670 MB あり、alpine:latest はわずか 5.58 MB です。ただし、AWS が提供するベースイメージを使用すると、3 つの利点があります。
キャッシュにより高速：AWS が提供するベースイメージは、Lambda サービスによってプロアクティブにキャッシュされます。これは、ベース イメージが近くの別の上流キャッシュにあるか、すでにワーカー インスタンス キャッシュに存在することを意味します。はるかに大きいにもかかわらず、キャッシュされない可能性があるサードパーティの基本イメージと比較すると、展開時間は依然として短い可能性があります。
initフェーズはメモリ割当を増やしても高速化しない#
boostされてるらしい
LambdaのINITフェーズではメモリ128MでもCPUパワーをフルに使える？！boost host CPUの動きを確認してみた | DevelopersIO
セキュリティ#
microVMsの中にGuest Kernelもあり、ホストマシンと環境が分離されている
Lambdaのセキュリティ関係の参考文献
参考#
Lambda関係の論文#
re: Invent#
A closer look at AWS Lambda (re: Invent 2022, SVS404-R)
Deep dive into AWS Lambda security: Function isolation (re: Invent 2020, SVS404)
A Serverless Journey: AWS Lambda Under the Hood (re: Invent 2019, SVS405)
A Serverless Journey: AWS Lambda Under the Hood (re: Invent 2018, SRV409)