Lambdaは便利ですが、性能チューニングで出来ることは結構限られ実質2つしかありません。
1つ目はリソース追加、2つ目はベストプラクティスに従いアプリを直すこと。
リソースの追加
Lambdaはリソースといってもメモリしかいじるところがありません。
CPUはメモリ量に応じて付与される設計になっているのでCPUを増やしたかったらメモリを増やしましょう。
とはいえメモリは最大1.5Gまでしか付与できず、メモリ1.5G時のCPUが最大になります。
Q: コンピューティングリソースはどのように AWS Lambda に割り当てられるのですか?
AWS Lambda のリソースモデルでは、お客様が関数に必要なメモリ量を指定するとそれに比例した CPU パワーとその他のリソースが割り当てられます。たとえば、256 MB のメモリを指定すると約 2 倍の CPU パワーが Lambda 関数に割り当てられます。128 MB のメモリを指定した場合と比較すると CPU パワーは倍となり、512 MB のメモリを指定した場合と比較すると半分になります。メモリは 128 MB から 1.5 GB まで、64 MB ごとに増加できます。
https://aws.amazon.com/jp/lambda/faqs/#functions
ベストプラクティスにしたがっているか確認する。
リソース的にいじれるのはメモリだけなので、メモリを1.5にしても遅かったら後はアプリを直すしかありません。
アプリを直すとしても大していじるところはなく、以下のベストプラクティスに従い見直すぐらいです。
- Lambda 関数はステートレススタイルで作成し、土台となるコンピューティングインフラストラクチャにコードが依存しないようにします。
http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/best-practices.html
- 接続の再利用を活用するために、ハンドラの範囲外で AWS のクライアントとデータベースのクライアントをインスタンス化します。
- Lambda がコードを実行できるように、アップロードした ZIP 内のファイルに対して +rx アクセス許可が設定されていることを確認してください。
- 現在のイベントの処理に直接関係しないスタートアップコードを最小限にすることで、コストを削減しパフォーマンスを改善します。
- 組み込みの CloudWatch モニタリング機能を利用して、Lambda 関数のリクエストのレイテンシーを表示し最適化します。
- もう使用していない古い Lambda 関数を削除します。
特に「データベースクライアントのインスタンス化の場所」と「直接関係しないスタートアップコードの削減」は効果があるのでこれはやるべきでしょう。
また不要なライブラリの同梱や使用を減らしコードサイズ自体を縮小することも効果があるようですが、一気に半減とかにはならないので覚悟しておきましょう。
そんなこんなでベストプラクティスに従って設計して、メモリも1.5Gで稼動させていたらもう打つ手はありません。
全体のアーキテクチャを考え直しましょう。
便利ですが、ちょっとしためんどくささもあるので使用するポイントは見極めて使いましょう。
