[论文解读] Mitigating Cold Starts in Serverless Platforms: A Pool-Based Approach

Ping-Min Lin, Alex Glikson|arXiv (Cornell University)|Mar 28, 2019

Cloud Computing and Resource Management参考文献 3被引用 50

一句话总结

本文在 Knative Serving 中实现了一个温热函数实例池，以降低冷启动延迟，对单一 Pod 池的 P99 延迟降低高达 85%。

ABSTRACT

Rapid adoption of the serverless (or Function-as-a-Service, FaaS) paradigm, pioneered by Amazon with AWS Lambda and followed by numerous commercial offerings and open source projects, introduces new challenges in designing the cloud infrastructure, balancing between performance and cost. While instant per-request elasticity that FaaS platforms typically offer application developers makes it possible to achieve high performance of bursty workloads without over-provisioning, such elasticity often involves extra latency associated with on-demand provisioning of individual runtime containers that serve the functions. This phenomenon is often called cold starts, as opposed to the situation when a function is served by a pre-provisioned "warm" container, ready to serve requests with close to zero overhead. Providers are constantly working on techniques aimed at reducing cold starts. A common approach to reduce cold starts is to maintain a pool of warm containers, in anticipation of future requests. In this report, we address the cold start problem in serverless architectures, specifically under the Knative Serving FaaS platform. We describe our implementation leveraging a pool of function instances, and evaluate the latency compared to the original implementation, resulting in a 85% reduction of P99 response time for a single instance pool.

研究动机与目标

• 促使在无服务器（FaaS）平台中降低冷启动延迟。
• 在 Knative Serving 内提出基于池的温热 Pod 策略以缓解冷启动。
• 将池实现为 Knative 资源并将 Pod 迁移与自动扩缩容集成。
• 在简单初始化和较重初始化的基线 Knative（无池）上评估时延改进。

提出的方法

• 将池实现为一个 Knative 自定义资源定义（CRD），其结构模仿 revision 结构以管理温热 Pod。
• 修改 Knative 自动扩缩容，在生成新 Pod 之前将来自池的 Pod 迁移到目标 revision。
• 通过重新标注并激活指标收集，将 Pod 迁移到目标 replicaSets，然后仅在缺口时生成新 Pod。
• 在 GCP 上用两个应用（Go HTTP 服务器和 TensorFlow 图像分类器）测量性能，比较冷启动与温热启动。
• 使用 Pareto 并发间到达时序进行大规模模拟，评估不同池大小下的分位延迟改进。

实验结果

研究问题

• RQ1 温热 Pod 池在多大程度上降低无服务器函数的冷启动延迟（P95、P99、P99.5）？
• RQ2 单 Pod 池在具有不同应用初始化开销的工作负载上的影响？
• RQ3 池辅助自动扩缩容对 Knative Serving 的延迟和迁移时间有何影响？
• RQ4 增加池所带来的资源与实现开销（行数 LOC、迁移时间）是什么？

主要发现

应用	冷启动（秒）	热启动（秒）
HTTP Server	12.123 (1.638)	5.076 (1.055)
Image Classifier	39.25 (1.475)	7.458 (0.641)

• 单 Pod 池将 HTTP 服务器的冷启动从 12.123s 降至 5.076s（σ 1.638, 1.055 分别）。
• 单 Pod 池将图像分类器的冷启动从 39.25s 降至 7.458s（σ 1.475, 0.641 分别）。
• 如结论所述，单实例池在 P99 冷启动延迟方面最高可实现约 85% 的降低。
• 模拟结果表明，单个池中一个 Pod 即可完全消除短/长应用的 P95；P99 至少降低 50%。
• 将池化 Pod 迁移到目标 revision 约需 2 秒；池资源定义约 200 行代码；迁移代码约 350 行代码。