see: Lambda execution environment
import time time.sleep(1) def lambda_handler(event, context): time.sleep(2) return {}
ログの例
# cold start REPORT RequestId: ... Duration: 1.54 ms Billed Duration: 2 ms Memory Size: 128 MB Max Memory Used: 36 MB Init Duration: 3117.04 ms # hot start REPORT RequestId: ... Duration: 1.09 ms Billed Duration: 2 ms Memory Size: 128 MB Max Memory Used: 36 MB
ハンドラ内でしか呼ばれていないコードパスにおいて高負荷なクラスロードが発生していないか切り分けを行う。
例えばハンドラ内の処理のうち可能なかぎり static イニシャライザにて同様の処理をあらかじめダミーで実行し、ひきつづきリストア時とそれ以外で実行時間に差がでるか確認をする。もし、実行時間が改善するならばそのなかにリストア後の初回実行時の実行時間に影響を及ぼすクラスロードなどがおこなわれる要因となる処理があると推定できる。
SnapStart のメリットを最大限に活用するためにも、起動時のレイテンシーの原因となるクラスは、関数ハンドラーではなく、初期化コードに事前ロードしておくことをお勧めします。そうすることで、高負荷のクラスローディングに関連するレイテンシーが呼び出しパスから排除され、SnapStart での起動パフォーマンスが最適化されます。 初期化中にクラスを事前ロードできない場合は、ダミー呼び出しを使用してクラスを事前ロードすることをお勧めします。
Lambda SnapStart を使用するためのベストプラクティス
一般的に Lambda から RDS へ直接クエリする構成と、Lambda〜RDS 間に RDS Proxy を挟む構成が考えられる。
Lambda 関数の同時実行数が想定でき、かつ RDS の最大同時接続数を超えないのであれば単に Lambda から RDS へクエリする形で問題ないだろう。その一方で、次のようなケースにおいては RDS Proxy を利用して RDS の最大同時接続数の超過を防ぐことを検討すると良い。
see also: Amazon RDS Proxy の使用 - Amazon Relational Database Service
TODO
ウェブ界隈でエンジニアとして労働活動に励んでいる @gomi_ningen 個人のブログです