まず、圧縮、ネットワークIn、ネットワークOutにかかった処理時間を比較してみます。
結果は以下のようになりました。
■計算能力(gzip圧縮処理)
メモリ割当量128MBと1536MBでは、処理時間に12.5倍の差がありました。メモリ割当量を増やすと計算性能も上がります。
■ネットワークIn(S3からのファイル読み込み)
メモリ割当量128MBと1536MBでは、処理時間に6.8倍の差がありました。
gzip圧縮処理より差は少ないですが、ネットワークIn性能が上がりました。CPUの計算能力の寄与もあると思われますが、メモリ割当量が増えると割り当てられるユニットのネットワーク性能自体も上がっていると考えられます。
■ネットワークOut(S3へのファイル書き出し)
メモリ割当量128MBと1536MBでは、処理時間に7.5倍の差がありました。
こちらもネットワークInと同様に、メモリ割当量がネットワーク性能向上に寄与するようです。
メモリ割当量を増やすほど、処理性能は向上して処理時間が短くなります。その結果、単位時間当たりのLambda利用料金は増加する一方で、処理時間が短くなることで課金対象時間は減少し課金額は減ります。
コストの増加と減少の要因が寄与する中で、最終的なコストがどうなるかも評価してみます。
コストの計算は、上の表のメモリ割当量ごとの処理時間にLambdaのコスト($/秒)をかけて試算しています。
実際にはLambdaの課金は利用時間(Duration)を100ms単位で切り上げた時間で課金されますが、今回は単純化のため、切り上げはせずに試算しています。
■コストベースの比較
計算能力(gzip圧縮処理)は横ばいです。同じ負荷の処理を行う場合、メモリ割当量を増やしても、処理時間が短くなる結果、全体のコストは変わらないようです。
ネットワークIn、ネットワークOutについては、メモリ割当量が増えるとコストは微増する傾向になりました。
まとめ
メモリ割当量を増やすと時間当たりのコストも上がりますが、性能があがって処理時間が短くなる分、最終的なコストは変わらない、という結果になりました。「時は金なり」という考え方で行けば、できるだけメモリ割当量を増やして、処理時間を短くする方が良さそうです。
ただし、時間当たりの課金コストは比例して大きくなるので、Lambdaの処理件数や１件当たりの処理時間などを検討した上でメモリ割当量を決めておかないと、コストが膨むので気を付けましょう。想定外の課金を避けるために、メモリ割当量を大きくした場合は、Lambdaのタイムアウト値を低めに設定したり、CloudWatchで処理件数をモニタリングしたりして、「Lambda破産」を防ぎましょう。
