原生状态的无服务器框架：描述和优化大型云提供商的无服务器工作负载

论文地址：原生状态的无服务器框架：描述和优化大型云提供商的无服务器工作负载，Shahrad等人，arXiv 2020

这是上星期乔纳森·梅斯（Jonathan Mace，@mpi_jcmace）在Twitter上引起我注意的一篇arXivs论文的新内容，谢谢乔纳森！

这是一个典型的权衡：所提供的服务质量（更好的服务可能在相同的成本点上驱动更多的业务量）与提供该服务的成本。这是一个权衡，至少，只要一个经典的假设成立，一个高质量的产品生产/提供成本更高。这一假设似乎在我们许多人心中根深蒂固——例如解释了为什么高成本的商品往往隐含着更高的质量。每隔一段时间，虽然在设计空间的某个点可以发现，我们不必权衡质量和成本，在那里我们可以有更高质量的产品和更低的单位成本。

今天的论文分析了Azure上的无服务器工作负载（这些工作负载的特性本身就很有趣），用户希望快速的功能启动时间（避免冷启动），云提供商希望将资源消耗（成本）降到最低。通过细粒度的、基于使用的计费，用于保持函数执行环境温暖的资源直接消耗到利润中。作者展示了一种将函数运行时的保持活动时间与预热相结合的策略，该策略支配了当前流行的策略，即在函数使用后将其执行环境简单地保持一段时间，以期它能被重用。使用此策略，用户看到的冷启动更少，而云提供商使用的资源更少。这是下表中红色（实践状态）和绿色（本文）策略的区别。双赢！

我们提出了一个实用的资源管理策略，它可以显著减少功能冷启动的次数，同时比实践状态策略花费更少的资源。
在我们开始了解该策略的工作原理之前，首先让我们看一下本文对Azure上的实际生产无服务器工作负载（所有Azure上的函数调用，2019年7月15日至28日）的介绍。这些见解为政策设计提供了依据。

###现实世界中的无服务器，服务提供商的观点

数据集包括调用计数、执行时间、内存使用量，以及有关日期内通过Azure调用的每个函数的元数据（例如，触发器类型）。在Azure中，函数逻辑地分组在应用程序中，应用程序是调度和资源分配的单元。
超过一半的应用程序只有一个功能，95%的应用程序最多有10个功能，0.04%的应用程序有100多个功能。从整体上看，应用程序中函数的数量并不是一个有用的调用频率预测器。具有更多函数的应用程序只显示出一个非常小的趋势，即这些函数被更频繁地调用。触发函数执行的最常用方法是HTTP请求。只有2.2%的函数具有基于事件的触发器，但这些触发器占所有调用的27.4%。同时，许多函数都有一个基于计时器的触发器，但它们只占所有调用的2%。一、 事件发生的频率比计时器过期的频率要高得多！

基于计时器的触发器非常适合预测何时调用函数，但86%的应用程序要么没有计时器，要么有计时器和其他触发器的组合。
每天调用的次数在不同的函数和应用程序之间可能相差超过8个数量级，这意味着需要非常不同的资源级别。
……绝大多数应用程序和函数平均被调用的频率非常低……平均每小时调用一次或更少的应用程序占45%，平均每分钟调用一次或更少的应用程序占81%。这表明，相对于这些应用程序的总执行（计费）时间而言，让它们保持温暖的成本可能高得令人望而却步。
对这些函数执行的到达间隔时间（IATs）的分析表明，真实的IAT分布比简单的周期分布或无记忆分布更为复杂。对于许多应用来说，预测IATs并不是一件小事。
当函数执行时，它们执行的时间相对较短（50%的函数执行1s或更少）。

其主要含义是，函数执行时间与为主要提供程序报告的冷启动时间具有相同的数量级。这使得避免和/或优化冷启动对于FaaS产品的整体性能极为重要。
此外，对于大多数应用程序，平均执行时间至少比平均IAT小两个数量级。
内存消耗也有很大的变化，但是调用频率和内存分配之间，或者内存分配和执行时间之间没有很强的相关性。
简而言之，大多数函数在短生命周期内很少被调用，并且保持这些常驻函数的开销很大。但预测函数下次何时被调用的任务并不简单。

何时以及多长时间使函数执行环境保持活动
从服务提供商的角度来看，有两个重要的问题控制着应用程序性能和资源消耗：
当（如果有的话）应用程序执行环境应该在预期即将进行的调用时进行预热，并且
应用程序执行环境加载到内存中后，它应该保持活动（keep alive）多长时间。（如果应用程序是预热的，则此定义不是从预热时刻开始的）

正如我们所看到的，每个应用程序对这些问题的答案都需要不同。在没有任何强相关性的情况下，我们可以收回，这意味着我们需要学习每个函数的行为-但我们需要这样做的跟踪和执行开销低。
该解决方案是一种混合直方图策略，可根据每个应用程序的调用频率和模式进行调整。它有三个主要组成部分：

• 为每个应用程序捕获空闲时间（IT）分布的范围限制直方图。每一个1分钟宽的箱子都会记录下发生的相应长度的箱子的数量，最多持续4小时。这个分布的头部（取第5百分位）用于设置预热窗口，尾部（取第99百分位）用于设置保持活动窗口。

• 当尚未观察到足够的ITs或IT分布正在发生变化时使用的标准生存策略。当变异系数大于某个阈值时，直方图是最有效的。低于这一标准，则采用不预热、4小时保持活力的标准。”在直方图学习新体系结构时，保守的“保持活动”窗口选择旨在尽量减少冷启动的次数
• 当一个应用程序经历许多超出界限（超过4小时）的空闲时间时，直方图方法永远不会很好地工作。对于这些应用，使用更昂贵的ARIMA模型来预测空闲时间。此模型是从关键路径计算出来的，只需要少数调用，因此计算需求是可管理的。

一切都是这样的：

现行混合策略
混合策略通过基于完整Azure跟踪的模拟和重放其中一部分的基于Open Whisk的实现进行评估。我们在这篇文章的顶部看到了一个标题结果，如图15所示：混合策略显著减少了冷启动的次数，同时也降低了内存浪费。

10分钟固定生存策略[当前的云提供商方法]在75%时需要大约2.5倍的冷启动时间，同时使用与直方图相同的内存量，范围为4小时…总体而言，混合策略形成一个平行的、比固定策略（红色曲线）更优的帕累托前沿（绿色曲线）。
如果您对深入研究感兴趣，评估还将显示直方图范围限制、检查直方图代表性以返回到标准保持活动策略以及使用超出限制的空闲时间应用程序的ARIMA模型所做的贡献。
尽管我们特意设计了简单实用的策略，我们还是取得了这些积极的结果：（1）直方图箱的分辨率为1分钟，（2）直方图有一个最大范围，（3）它们不需要任何复杂的模型更新，（4）当直方图不能很好地工作时，我们会还原为简单有效的替代方案。