サーバレスプラットフォームの性能比較

主要なクラウドプロバイダのほとんどがFunction as a Service（FaaS）を提供するサーバレスプラットフォームを提供している。最近のベンチマークでは、ランタイム、コールドスタート時間、依存関係、およびリソース割り当てに対するパフォーマンスの違いを検証しているものがある。

AWS Lambda、Google Cloud Function、Azure Function、IBM Cloud FunctionはBernd Strehlが性能を比較するためにテストしたサーバーレスのプロバイダである。Node.js関数を使って実行されたこれらのテストで、これらのプロバイダがさまざまな要求負荷にどのように応答するかについて、いくつかの事実が明らかになった。しかし、このテスト方法は、サンプルが小さい、サイズ、およびベースとなるインスタンスタイプなどの他の要因を考慮していないために批判されている。他のチームによるテストでは、別のアプローチ（PDF）が採用された。

サーバレスプロバイダは、CPU、メモリ、要求数だけでなく、ネットワークとストレージにも課金する。プロバイダによって、指定のCPU要件のためにメモリをどのように調整するかが異なる。たとえば、AWSは、より多くのメモリを持つインスタンスに、より多くのCPUサイクル（PDF）を与える。Googleも同様の方式である。Azureでは、CPUが「CPUシェアを増やす傾向のある4-vCPU VM」でどのように割り当てられているかによって異なる。

並行リクエストによって関数の平均応答時間が変わる。非並行リクエストの場合、リソースの割り当ては、Google以外のすべてのプロバイダでほぼ同じである（30％前後で変動する）。AWSの計算時間は、同じコールが50回同時に呼び出される場合、並行リクエストでは46％増加した。GoogleとAzureではそれぞれ7％と3％であったが、IBMでは154％増加した。他のテストでは、並行実行に関してAWSが最も高いパフォーマンスとなることがわかった。

コールドスタート時間は、しばらくの間使用されていないサーバーレス機能が最初の要求に応答するのに必要な時間である。結果を見る限り、一定のパフォーマンスを保つことはすべてのプロバイダにとって課題である。特定の用途に限定しない、つまり一般的なワーカ（インスタンス）のプールは、クラウドプロバイダによって常に実行されている。最初の要求に対しては、設定を行い、処理する。インスタンスは、最初のリクエストの後に保持される。ただし、保持される時間はプロバイダごとに異なる。Mikhail Shilkovは、自身の記事で、Azureの場合は20分、Google Cloud Functionの場合はその時間が変化することを測定した。 AWSは公式に5分と述べているが、実際にはエンジニアリングチームによる調整のために長くなっている。コールドスタートは、サービスが水平方向に拡大し、新しいインスタンスを起動しなければならない場合にも発生する。

ランタイムの選択もパフォーマンスに影響を与える。Node.jsアプリは開始するのにCPUをあまり使用する必要はないが、.NET Coreランタイムでは（AWS Lambdaで）多くのメモリが必要なる。コールドスタート時間は、割り当てられたメモリの増加とともに低下する。 Javascriptの場合、テストでは、AWSがコールドスタート時間が最速であり、その後にGCPとAzureが続く。