从青铜到王者，揭秘 Serverless 自动化函数最佳配置
作者：丛霄
背景介绍
全托管的 Serverless 计算平台能给用户带来更少的运维代价、更强的稳定性和更快的弹性能力。
Serverless 的目标之一是免运维，但仍旧存在一些障碍，在 Serverless 场景特有的一些关键服务配置比如 “并发度”、“最小实例数”、“最大实例数” ，如何配置参数才是最合适的？怎么确定自己配置的参数是否合理？仍旧一直是让用户头痛的事情。
本文介绍了函数计算团队在自动化推荐 Serverless 函数最佳配置上的思考和相关工作，希望帮助用户解决目前使用 Serverless 的痛点问题，彻底解放用户的双手，释放 Serverless 服务的价值。
评估 Serverless 服务最佳配置的难点
用户使用 Serverless 服务的预期是：更低的成本、更快的弹性、更优的性能、更稳定的环境，这同时也是 Serverless 平台承诺提供给用户的能力。尽管如此，很多用户在使用过程中还是出现了各种问题：
- 为什么使用 Serverless 后发现成本还变高了？
- 为什么使用 Serverless 的冷启动时间那么长？
- 在 Serverless 平台上的性能延迟表现为什么更差了？
Serverless 平台能提供一定的基础能力，但是针对不同的业务逻辑，需要采取合适的配置才能更好的发挥 Serverless 的效果。但是如何评估某函数的最佳配置，其中涉及到多变量的协同优化问题，并不是一个简单的问题。具有以下几个难点：
难点1：成本和性能的权衡
- 一定的单实例多并发数，可以提高单实例并行处理请求的数量，减少实例数，从而降低成本；
- 并发数过高时，会增加资源竞争，导致性能延迟增加，从而增加成本；
- 较低的实例规格单价成本更低，但是延时更大；较高的实例规格单价成更高，但是延时可能更低
如何针对用户的偏好场景（性能优先还是成本优先），为用户推荐最佳的函数配置，成为首先需要考虑的一大难点。
难点2：不同函数业务逻辑的复杂度
除了成本和性能维度的衡量，针对不同类型的函数逻辑，不同的配置参数效果也有差异。很多函数业务逻辑复杂，只针对单一逻辑分支进行评估最佳配置并不代表整体的最优；不合适的配置可能增大用户非预期的成本。比如：
- 对于 CPU 密集型的函数，规格增加对单实例性能的提升有较大的改善
- 对于 IO 密集型的函数，规格增加对单实例性能的提升存在边际效应递减的情况，当超过某规格后，规格的提升对性能提升的效果基本没有
比如下图展示了 CPU 密集型函数在不同规格下的压测数据：
CPU 密集型的规格越高，maxTPS 越大；并且规格与 maxTPS 呈现明显的线性关系。
规格越大，maxRT 越低 ，说明CPU密集型的函数，增大资源规格可以显著降低 RT。但是规格增大到 4G、8G 后，对 RT 的降低效果边际效应递减。
下图展示了 IO 密集型函数在不同规格下的压测数据：
规格的提升对 IO 密集型的性能改善作用有限，特别到了高规格，比如 3G 后，maxTPS 增幅不大
难点3: 函数配置对平台侧资源的影响
函数的并发度、最小实例数、最大实例数等配置会影响到平台侧资源池的容量规划，如何保证单函数的资源刚性交付，多函数的资源隔离；如何优化平台侧弹性调度能力，提高平台侧的资源利用率，是另一个难点问题。
- 较低的单实例并发度，函数流量波动变化的场景，会提前达到单实例并发上限，导致实例扩缩容频繁，对用户体感来说的冷启动更频繁，对平台来说需要创建和维护更多的实例个数，整体的资源利用率偏低
- 最大实例数的配置，如何保证实例资源的刚性交付
如何评估 Serverless 服务的最佳配置
通过以上几个难点分析，我们知道评估 Serverless 服务的最佳配置并非易事，下面的几个演化阶段，介绍了用户使用 Serverless 进行服务配置的方式变化，从青铜到王者，我们一直在为用户提供最好的 Serverless 服务努力。
青铜用户：拍脑袋设置
在上线初期，用户需要面对一堆配置参数，如果是初次使用函数计算的新用户，还需要翻看文档才了解配置含义，反复折腾后也不知道配置参数多少才合适，最后还是“拍脑袋”随便设置了一个值。
白银用户：人工反复调整
函数上线后，可能会发现之前的配置不合理，仍旧需要反复修改函数配置验证。如果修改了函数逻辑，可能会发现之前的配置会出现问题，比如请求延迟变大，或者函数偶然出现 OOM 错误。
有一些经验的开发者会选择自己进行压测，确定函数的最佳配置。但是压测的使用具有一定的门槛，并且压测得到数据一般用户也不知道怎么分析，可能会产生更多的疑问。最终折腾一番，用户也不是很确定压测得到的配置是否是最符合自己预期的最优选择。
为了解决青铜和白银用户的这些困扰，我们推出了自动化推荐配置的王者功能。
王者：性能探测+数据分析的自动化推荐
近期函数计算重磅推出了函数的性能探测功能， 性能探测的目的是帮助用户评估函数单个实例在不同规格下的性能上限，并且推荐出满足用户预期延迟的最佳并发度和函数规格配置。
具体的探测方法，根据 little's law 排队理论，我们知道服务的吞吐量、并发数和响应时间之间存在着一个等式关系：并发数 = 请求的平均延迟 * TPS
如果我们使用图形化表示，如下图所示：
横坐标是并发数，左边的纵坐标是 TPS，右边的纵坐标是延迟。由于每个服务器的处理能力都有限，所以会出现
- 吞吐量-并发数：随着并发数上升，吞吐量先上升后平缓，可能出现下降，即性能恶化；
- 延迟-并发数：当并发度过高时，延迟会变高，甚至会急剧恶化；
通过性能探测，我们会得到每种规格的关键性能数据：
- 每个规格的最高能承受的 QPS：基于此，用户如果对业务流量比较清楚，可以计算得到函数所需的最小实例数和最大实例数。
- 推荐的最佳规格和规格下的最佳并发度。
比如用户预期自己的函数调用端到端延迟是 1000 毫秒，那么我们会根据 1000 毫秒的延迟限制，推荐出最佳的规格，以及该规格下的最佳并发度，即满足延迟限制的最高 QPS 时对应的并发度。
整个功能采用流程图的方式指引，先压测单实例，再压测多实例，因为在性能表现平稳的系统，多实例的性能是单实例性能的线性叠加，所以只需要压测出单实例的性能，就可以推算出多实例的性能。
用户能够根据引导使用性能探测，并得到推荐结果；同时性能探测功能是完全免费的，用户只需要为函数承接的请求流量付费，不需要为压测功能付费。
单实例压测结果分析页面：
单实例压测数据详情页面：
目前函数性能压测功能已经在函数计算控制台上线，具体详细的使用方式可以参考文档。
性能探测推荐的函数配置优先保证满足性能需求，实现最高的资源利用率，但是真正实现最低成本配置，需要结合函数线上历史流量数据分析，进行推荐。
在进行成本优化推荐规格时，不仅需要达到节约成本的目的，还需要保证不破坏现有服务的 QoS，即性能不会因为实例规格的降低，而导致延迟增大。
比如下面这张图表示用户实际资源使用量较低，实际配置的规格偏大，我们可以推荐更低的规格，以帮助用户节约成本。
通过结合性能探测+历史流量数据分析，可以自动化给用户推荐得到保证性能的同时，成本最低的最佳函数配置。
至尊王者：智能动态调整并发度
最后我们期待的至尊王者，是彻底解放用户的双手，能够智能动态地调整函数的并发度，不管流量变化或业务逻辑如何变化，用户再也不需要关心或重新配置函数并发度的大小。
智能动态并发度未来一个演化方向，在这种模式下，用户不需要通过手动配置参数，而是在函数运行时动态调整，根据实例 CPU 负载的健康指标自动调整到最佳值。函数计算也会继续努力，打造体验更好的，更帮用户节省成本，更 Serverless 的自动化配置方案。
总结与展望
目前性能探测功能已经在函数计算控制台开放，基于历史流量评估能够降低成本的最佳配置也会在近期公测开放。基于性能探测的自动化推荐函数配置功能，极大降低了用户上手以及运维函数配置的复杂度，期望能给用户使用 Serverless 带来王者般的体验。
附加链接
[1] 函数性能探测
https://help.aliyun.com/document_detail/477504.html
[2] 参考《Little's Law Wikipedia RobustScaler: QoS-Aware Autoscaling for Complex Workloads》
