In Function as a Service (FaaS), a serverless computing variant, customers deploy functions instead of complete virtual machines or Linux containers. It is the cloud provider who maintains the runtime environment for these functions. FaaS products are offered by all major cloud providers (e.g. Amazon Lambda, Google Cloud Functions, Azure Functions); as well as standalone open-source software (e.g. Apache OpenWhisk) with their commercial variants (e.g. Adobe I/O Runtime or IBM Cloud Functions). We take the bottom-up perspective of a single node in a FaaS cluster. We assume that all the execution environments for a set of functions assigned to this node have been already installed. Our goal is to schedule individual invocations of functions, passed by a load balancer, to minimize performance metrics related to response time. Deployed functions are usually executed repeatedly in response to multiple invocations made by end-users. Thus, our scheduling decisions are based on the information gathered locally: the recorded call frequencies and execution times. We propose a number of heuristics, and we also adapt some theoretically-grounded ones like SEPT or SERPT. Our simulations use a recently-published Azure Functions Trace. We show that, compared to the baseline FIFO or round-robin, our data-driven scheduling decisions significantly improve the performance.
翻译:作为服务(FaaS),一个没有服务器的计算变体,客户部署功能,而不是完整的虚拟机器或Linux集装箱;是云提供方,维持这些功能的运行时间环境; FaaS产品由所有主要云提供方提供(如Amazon Lambda、谷歌云函数、Azure函数);以及独立的开放源软件(如Apache OpenWhisk)及其商业变体(如Adobe I/O Runtime或IBM Cloud函数),我们采用FaS集群中单一节点的自下而上的观点;我们假定分配给该节点的一套功能的所有执行环境都已安装。我们的目标是为单个援引由负载平衡器传递的功能安排时间,以尽量减少与响应时间相关的性能衡量标准。部署功能通常根据终端用户的多种变式(如Adobe I/O O Or Runtrea) 。因此,我们的时间安排决定是根据当地收集的信息作出的:已记录的频率和执行时间。我们提议了一些超常数,我们还将一些螺旋执行环境模型,并对比了我们最近出版的轨道数据。