こんにちは、エンジニアの小林です。2017年1月17日に開催されたServerless Meetup Tokyo #2に参加してきましたのでレポートしたいと思います。
Tune Up AWS Lambda
普段からお世話になっているAWSの西谷さん(@Keisuke69)の発表です。
発表内容レポート
AWS Lambdaのパフォーマンスの基本についての発表でした。
同時実行数
- 同時実行数の定義
- ストリームベースのイベントソース
- シャード数と等しい
- それ以外
- 1秒あたりのイベント数 * 関数の実行時間
- 関数の実行時間を可能な限り少なくするべし
- 1秒あたりのイベント数 * 関数の実行時間
- ストリームベースのイベントソース
- 上限
- デフォルトでは100
- 制限緩和可能だが、緩和が必要そうな実績がない状態でいきなり申請しても通らない可能性高い
ライフサイクル
- Lambdaはコンテナとして実行される
- sandbox
- dockerではない
- 開始
- Lambdaが始めて実行されるタイミング
- コードがコンテナ内にロード・展開
- VPCの場合はENI生成も
- 初期化コードが実行される
- これを コールドスタート という
- 終了
- 再利用
- コードの変更がなく前回の実行から時間が経っていない場合は再利用されることがある
- 再利用が担保されているわけではない
- これを ウォームスタート という
- コードの変更がなく前回の実行から時間が経っていない場合は再利用されることがある
- パフォーマンス関連設定
- メモリ設定
- 実際はコンピューティングリソース全体の設定
- メモリサイズに比例してCPU能力なども向上する
- 実際はコンピューティングリソース全体の設定
- バッチサイズ
- kinesis/dynamodbをイベントストリームとする際に一度に取得するレコード数
- メモリ設定
Lambdaを速くする方法
- コールドスタートを速くする
- コールドスタートを減らす
- 定常的にリクエストが発生するシステムではほとんど発生しない
- Lambdaに対してpingする
- 定期的にinvokeすることでコンテナが破棄されることを回避
- 5分間隔程度がオススメ
- 定期的にinvokeすることでコンテナが破棄されることを回避
- コンピューティングリソースを増やす
- ランタイムを変える
- 起動速度は Java > C# > Python > Node.js
- ただし起動後はコンパイル言語の方が速い傾向
- VPCを使わない
- ENIの生成とアタッチが遅い
- データストアはDynamoDBが鉄則
- どうしてもDBを使いたい場合はDynamoDB Streamsを利用した非同期反映を検討する
- パッケージサイズを小さくする
- コールドスタートを減らす
- ファンクションの実行時間を短くする
- 各言語のベストプラクティスに従う
- グローバルスコープを有効に使う
- 同時実行性の向上
- 並列実行によりスループットを上げる
感想
以前LambdaをVPCに入れてパフォーマンスが劇的に悪化したことがありましたが、やはりVPCを使わないように工夫する必要がありそうです。DynamoDB Streamsを利用する方法は技術検証してみたいと思います。
あとはやはり細かな工夫を粘り強く続けることが大事そう。パッケージサイズの縮小やコード自体のリファクタリングは言われてみれば当たり前ですが、Lambdaのパフォーマンス向上という点では私は観点漏れしていたので気にかけて実装しようと思います。
