Xanadu: Mitigating cascading cold starts in serverless function chain deployments

[KONY128]

https://dl.acm.org/doi/abs/10.1145/3423211.3425690

[KONY128]

Xanadu 介绍

Xanadu 是一个可以部署于数个云提供商之间的工具

Xanadu 可以基于资源的投机性（speculative）和及时性供应（just-in-time provisioning）而对 Serverless 级联冷启动问题进行针对性优化

Xanadu 能以极低的开销为代价，将 Serverless 级联调用的冷启动开销几近常数级地消除。在 Xanadu 的测试中，它比 Knative 快近 18 倍，比 Openwhisk 快近 10 倍

[KONY128]

概述

前言

Serverless 很潮流，但是有冷启动的问题。冷启动可能会占用函数执行生命周期的 50% 以上

这一点在链式调用中更是被级联放大，因为服务商为了供应和资源管理的目的，将 function 视为自主的实体 (autonomous entities)，严重加剧了链式调用中的延迟。

延迟的来源有编排开销、环境准备、库下载、容器启动时间、处理启动时间。链式调用还受网络传参、隔离性的要求等影响。

四个观察

1. 链式调用的冷启动是随着调用链长度线性增长的
2. 链式调用冷启动时间受到隔离性配置的影响
3. 隐式的函数调用（编码者自己都没发现）完全被排除在优化考虑之外
4. function 之间的依赖性要么是先验 (priori) 的 (有显式的指定)，要么是可以用 FaaS 平台推断出来

核心手段

在函数链式调用执行路径上，基于概率模型，推测性的部署资源 (就在资源需要之前，推进函数链的执行)

它使用投机的侵略性参数来控制主动部署的程度，这是根据函数调用链特性和部署开销来动态调整的

优化效果

将链式调用的线性增长延迟 overhead 控制在了常量级

[KONY128]

实现细节

核心概念

函数链式调用分类：

1. 继承关系上的分类：一对多、多对一、一对一、多对多
2. 显式和隐式：（显式的可以由平台编排，而隐式的只能函数自己编排）
   1. 显式：用户提供 Serverless 函数调用链的 schema
   2. 隐式：写进 Serverless 函数的 body 里，并不能被显式地得知

调查

1. 在正式讨论 Xanadu 前，作者在 AWS 和 Azure 上对不同时间间隔对链式调用进行实验，实际考察各个平台的容器留存时间
2. 后序论文中会模拟现实，尝试集中性地调用某些关键路径链（其他分支分布较小，这一分布来源于被引用论文），实验冷启动延迟的影响
3. 检查隔离级别对冷启动的影响（隔离级别实现：docker、light VM、V8 Isolate、Process），发现这些隔离级别的隔离性从高到低，性能从低到高（延迟线性增长的乘数不同）

衡量指标

1. C_d: 函数链式调用的冷启动额外延迟
2. C_r: 函数正式执行前，被锁住的 CPU 和内存，分为 C_rcpu, C_rmemory
   1. CPU 衡量：time slices (单位：秒)
   2. 内存衡量：每个产品的分配内存和总时间、执行时间差之间的乘积和
3. 惩罚因子：上述两个变量乘积

实现核心

1. MLP: 最可能的运行通路
2. Just-in-time deployment: 在刚要运行前部署
3. 基于历史，自动发现隐式的调用链

[linxuyalun]

Got it, thanks for your work, it looks very clear to me.