AWS Lambdaのコールドスタートの謎の解明と軽減

Pulisher : Managed & Support Center イ・スンヒ
Description : Lambdaのcold startの問題解決方法及び性能最適化の紹介セッション

はじめに

AWS Lambdaとサーバーレスアーキテクチャーの理解を得ようとすることです。 特に、Lambdaのコールドスタート問題は実際の顧客ワークロードで重要な考慮事項であり、これを解決する戦略と技術を学ぶために申し込みました。セッションで提供されるLambdaの初期化過程の詳細な分析とベンチマーク比較は、実際のシナリオでの性能最適化に大きな助けになると期待しています。

セッションの概要紹介

このセッションでは、Lambdaの初期化プロセスを詳細に確認し、一般的なアーキテクチャパターンを比較するベンチマークと、さまざまなRAM構成とペイロードサイズのベンチマークを確認します。 その後、初期化遅延を増加させる可能性のある一般的な間違いについて学び、AWS Lambdaのコールドスタートを解消するためのさまざまな戦略を学びます。

Lambdaの異常な遅延を語る上で避けて通れないトピックであるコールドスタートについて説明します。 Lambdaへの呼び出しの99%以上は、呼び出しが発生した時点で既にアクティブな実行環境で処理されます。これをウォームスタートと呼びます。 しかし、時折、アイドル状態であったり、呼び出しが増加した場合、関数コードを実行する前に新しい実行環境を起動する必要があります。 これがコールドスタートです。

初期化期間(Init duration)とは、提供された最初のリクエストの場合、ランタイムがハンドラーメソッド外で関数をロードしてコードを実行するのにかかった時間です。

上記のようなベンチマーキングツールを利用してcold start traceを通じて持続時間を測定することができ、Kinesisのローディングが約260msかかることを確認することができます。

同様に、DynamoDBをロードするのが約360msであることが分かります。DynamoDBクライアントもAWS STSクライアントに依存しており、これはSNSやその他のほとんどのサービスに当てはまります。

上記のように、関数の初期化と呼び出しの間に大きな違いがあることがわかりますが、この場合、サンドボックスがウォームアップしてから約12秒が経過するまで、クライアントは呼び出しを要求しませんでした。

また、最初の呼び出しが行われる数分前に初期化が行われることも、表には記載されていませんが、観察することができました。

1日後、63のプロアクティブな初期化ラムダサンドボックスがあり、コールドスタートはわずか11でした。 初期化の85%がプロアクティブな初期化でした。

AWS Serverless HeroのKen Collinsは、非常に人気のあるRails-Lambdaパッケージを管理しています。 数回の議論の後、彼はプロアクティブな初期化を追跡する機能を追加し、同様の結論に達しました。 彼の場合、カスタマイズされたランタイムと一緒にRubyを使用して3日間テストしたところ、初期化の80%が事前に防止されました。

ラムダ機能に割り当てられるメモリを選択することは、速度（時間）とコストのバランスをとる最適化プロセスです。関数のテストを手動で実行し、異なるメモリ割り当てを選択して完了するまでの時間を測定することができますが、AWS Lambda Power Tuningツールを使用すると、このプロセスを自動化することができます。

このツールは、AWS Step Functionsを使用して、異なるメモリ割り当てで複数のバージョンのLambda関数を同時に実行し、パフォーマンスを測定します。入力関数は、ライブプロダクションシナリオで可能なパフォーマンスを測定するために、ライブHTTP呼び出しとSDKインタラクションを実行するAWSアカウントで実行されます。このツールを使用して、CI/CDプロセスを実装してデプロイする新機能のパフォーマンスを自動的に測定することもできます。

セッションを終えて

このセッションを通じて、AWS Lambdaでのコールドスタートとウォームスタートの重要性とその影響を深く理解することができました。 また、初期化期間とKinesisおよびDynamoDBのロード時間に関するベンチマークデータは、Lambdaの性能最適化に重要な情報を提供しました。AWS Lambda Power Tuningツールによるメモリ割り当ての最適化方法についても知ることができました。