• 処理速度・応答速度
  • メモリと処理時間の制限
  • 失敗時のリトライ

 

処理速度・応答速度

JSPなどがアプリケーションサーバーが「常駐型プロセス」を実行するインフラストラクチャだとすれば、Lambdaは「非常駐型プロセス」をイベントによってトリガーするサーバレスアーキテクチャの一種ということができます。

アプリケーションのプロセスを起動するコストは一般に高く、複雑なアプリケーションでは読み込むべきクラス数も膨大になります。簡単な処理の場合には、そのイベント処理自体にかかる実行時間よりも、プロセスを起動するためのオーバーヘッドが大きくなってしまうことがあります。
そこでアプリケーション起動のオーバーヘッドを省くために、いちど立ち上げたプロセスを使い回してたくさんのリクエストを処理させる方式、つまりアプリケーションプロセス常駐型のアプリケーションサーバーというアーキテクチャが用いられるようになってきたというトレンドなどを背景として、Lambdaなどのサーバレスアーキテクチャに対する処理速度・応答速度に対する疑念が示されることがあります。

同じLambdaでも、Amazon API gateway経由の場合と、S3などのイベントソースから呼ぶ場合も違うという報告もありますし、node.jsでは速いものの、Javaでは遅いという報告などもあり、具体的な構成・設定により大きく処理速度が変わる可能性もありますが、システム設計時に処理速度・応答速度を気をつけることは必要なようです。

なお、Cloudwatchを用いて、レイテンシのモニタリングが可能です。

 

 

メモリと処理時間の制限

Lambdaで動くインスタンスにはメモリの制限があります。デフォルトは128MBですが、Lambda関数(ファンクション)の設定時に使用メモリの上限を設定することが可能です。ただし、設定できる最大値が1.5GBですので、1.5GB以上のメモリが確保できないサービスです。メモリが大量に必要になる処理だとメモリを確保できずに、Lambdaが使えないこともあります。

また、処理時間の制限もあります。デフォルトは3秒ですが、やはり設定時に処理時間の上限を設定することができます。ただし、設定できる最大値は300秒ですので、300秒以上かかる処理の場合、Lambdaが使えないので、普通にEC2で実現する必要があります。

 

 

失敗時のリトライ

Amazon S3 バケット通知およびカスタムイベントに関しては、コードにエラーがある場合、サービスまたはリソースの上限を超えた場合、AWS Lambda は関数の実行を 3 回試行します。Amazon DynamoDB ストリームおよび Amazon Kinesis ストリームなどお客様に代わって AWS Lambda がポーリングする指定イベントソースに関しては、開発者のコードにエラーがある場合、Lambda はデータの有効期限が切れるまで実行を繰り返します。

再実行してほしい場合は良いのですが、再実行しても失敗するような場合は注意が必要です。実行回数や時間が追加されてしまうので、コストも無駄になってしまいます。このような場合は、context.done()を呼び出すと再実行せずに終了します。

 

 

 

本サイト上に掲載されているまとめ記事が、毎週ステップメールで受け取ることもできます。

 

参考文献