[论文解读] Understanding Open Source Serverless Platforms: Design Considerations and Performance

Junfeng Li, Sameer G. Kulkarni+2 more|arXiv (Cornell University)|Nov 18, 2019

Peer-to-Peer Network Technologies参考文献 7被引用 19

一句话总结

本文评估了四种基于Kubernetes的开源无服务器平台——Knative、Kubeless、Nuclio和OpenFaaS，揭示了影响性能和自动伸缩的关键架构设计选择。研究发现，仅依赖RPS或并发数的自动伸缩机制不足以应对实际负载，且OpenFaaS和Knative在低负载下存在流量分发缺陷，导致吞吐量严重下降，其中Knative因错误的伸缩行为使RPS从1500降至200。

ABSTRACT

Serverless computing is increasingly popular because of the promise of lower cost and the convenience it provides to users who do not need to focus on server management. This has resulted in the availability of a number of proprietary and open-source serverless solutions. We seek to understand how the performance of serverless computing depends on a number of design issues using several popular open-source serverless platforms. We identify the idiosyncrasies affecting performance (throughput and latency) for different open-source serverless platforms. Further, we observe that just having either resource-based (CPU and memory) or workload-based (request per second (RPS) or concurrent requests) auto-scaling is inadequate to address the needs of the serverless platforms.

研究动机与目标

• 理解开源无服务器平台中的架构设计决策如何影响性能和自动伸缩行为。
• 识别在多个平台中请求路由、函数Pod伸缩和资源利用率方面的性能瓶颈。
• 评估RPS和并发数驱动的自动伸缩机制在真实工作负载中的局限性。
• 研究平台特定组件（如网关、看门狗、队列代理）对延迟和吞吐量的影响。
• 为改进基于Kubernetes的无服务器平台的设计与配置提供可操作的见解。

提出的方法

• 在Kubernetes集群上使用受控工作负载，对四种开源无服务器平台——Knative、Kubeless、Nuclio和OpenFaaS——进行评估。
• 在稳定状态和突发工作负载下测量性能，重点关注吞吐量（RPS）、延迟和自动伸缩行为。
• 通过CPU利用率配置Kubernetes水平Pod自动伸缩器（HPA），以评估各平台的基于资源的自动伸缩行为。
• 分析API网关和入口控制器在请求分发中的作用，并识别出OpenFaaS和Knative中的错误路由问题。
• 通过禁用临时解决方案（如OpenFaaS中的连接重置）进行消融研究，以隔离性能退化问题。
• 测量函数Pod的CPU和内存使用情况，以评估伸缩效率和资源开销。

实验结果

研究问题

• RQ1 网关、控制器和函数运行时组件的架构差异如何影响无服务器平台的基线性能和延迟？
• RQ2 RPS驱动和并发数驱动的自动伸缩机制在多大程度上独立地无法满足工作负载需求，其导致的性能后果是什么？
• RQ3 为何OpenFaaS在HPA配置下仍无法在低并发工作负载中有效伸缩，长连接路由在此过程中扮演了何种角色？
• RQ4 函数运行时选择（如Kubeless中的每请求派生进程模型）如何影响CPU利用率、请求丢弃率和自动伸缩响应速度？
• RQ5 平台特定组件（如队列代理和看门狗）对CPU开销和自动伸缩速度有何影响？

主要发现

• Knative在低负载下（9个并发请求）无法实现自动伸缩，仅维持一个函数Pod，导致吞吐量从1500 RPS下降至200 RPS。
• OpenFaaS由于错误的流量分发机制，在自动伸缩下吞吐量提升效果差：长连接将所有流量路由至第一个函数Pod，导致其他Pod处于空闲状态。
• 通过Kubernetes HPA实现的基于资源的自动伸缩表现出平台依赖性：Nuclio伸缩最快（实例数量翻倍仅需40秒），而Kubeless因高延迟和请求丢失，伸缩性能较差，这归因于其每请求派生进程模型。
• 即使启用了自动伸缩，内存使用量仍显著增加，但CPU利用率保持稳定，表明部分平台存在资源利用效率低下的问题。
• API网关与函数Pod之间的交互是主要性能瓶颈，错误路由导致已伸缩实例未能被充分利用。
• 仅依赖RPS或并发数驱动的自动伸缩机制是不足的；平台需要采用混合或工作负载感知的伸缩策略，以避免过度配置或配置不足。