AWS Lambda+Docker Cold Startをふまえたコンテナサイズとメモリの最適解ベンチマーク
AWS Lambda関数とECR
AWS Lambdaはサーバーレスアーキテクチャの一つで、マネージドサービスであるため、インフラストラクチャの管理が必要なく、コストも最適化された計算時間の分だけ支払うことで利用できます。しかし、Lambdaは実行環境が制限されており、プレーンなLambdaのデータサイズ上限が250MBであるため、大きなAIモデルやライブラリを持ち込めず、S3やEFSからgetする場合にはその転送時間、コストから運用ケースには乗せられない問題があります。
そこで、Dockerイメージを使用したECR（Elastic Container Registry）を利用することで、Lambdaが持つデータサイズ上限の問題を解決することができます。ECRは10GBまでのデータサイズまで対応しており、コードや推論モデルを丸ごとイメージにビルドしてデプロイすることができます。
コンテナでのLambda関数のcold start性能
この記事では、ECRを利用したLambda関数のcold start性能に焦点を当て、10種類の組み合わせで、cold start時間のベンチマークを実施しました。ECRのイメージサイズを5種類、Lambda関数スペックのメモリを2種類に設定し、初回の関数デプロイを終えた後でそれぞれ100回実行した際のinitDurationを計測し、平均値、各パーセンタイル（P5、P25、P75、P95）を算出しました。
上記のテーブルとグラフは、Lambda関数のメモリスペックとECRイメージのサイズに応じて、AWS Lambda関数の初期化時間(initDuration)の性能を測定したものです。
初期化時間の結果と考察
結果を見ると、
10GBのECRイメージを1024MBのLambda関数で実行した場合のみ初期化時間の幅が大きくなったものの、 それ以外の設定ではイメージの大きさ、Lambdaメモリスペックによって初期化時間に大きな差は出ませんでした。
この部分はLambdaメモリスペックを更に引き上げた場合の測定が必要かもしれません。1024MBを超えた場合に初期化時間に変化が見られる可能性があります。
まとめ
今回の測定で出る結論としては、
ECRイメージで用意できるプログラムのファイルサイズは最大の10GBまでどれだけ大きくしてもそれによってデプロイ、作成されたLambda関数の実行時間には影響は出ないことがわかりました。
（勿論、デプロイの時間はサイズの分だけ長くなる事には注意が必要。）