分布式微服务场景下的灰度干扰研究和应用混部

1. 分布式微服务场景下的灰度干扰研究和应用混部杨亚南天津大学智能与计算学部 ynyang@tju.edu.cn !"#$%&'()$* College of Intelligence and Computing

2. 个人简介 • 学习科研经历： – 2013.9-2017.6 燕山大学信息与计算科学本科 – 2017.9-2019.6 天津大学软件工程专业硕士 – 2019.9 至今天津大学计算机应用技术专业博士在读 • 主要研究方向 – 云服务干扰研究及性能评测 • 成果：面向混合云数据中心的基准评测程序集设计 – 云混部隔离管控及资源效率优化 • 成果：基于Intel RDT ① 的性能隔离+组件级区分混部控制 – 无服务器计算系统研究及平台优化设计 • 联系方式 – ynyang@tju.edu.cn ①Intel RDT: Resource Director Technology 2

3. 目录 1 相关背景介绍 2 灰度干扰下性能预测 3 组件级区分混部技术 4 讨论与总结 3

4. 研究背景 p云计算已经历两个阶段 n 阶段I：虚拟化云 (企业数据中心) n 阶段II：大数据云 (仓库级数据中心) Reserved Used =3~5× [Delimitrou and Kozyrakis, 2014] 低资源使用效率 [1] Zhiwei Xu,Chundian Li, Low entropy cloud computing system [J]. Chinese science, information science, 2017 (9). 4

5. 研究背景 p日益增长的云基础设施规模 n微软：数据中心投入已超150亿美元 n阿里云：张北数据中心投入180亿元 p通过混部来改善数据中心资源使用效率 n阿里云:混部集群平均CPU利用率达到 40% [Guo, 2019] n相比10年前虽然有所改善, 但仍有很大的提升空间 [2] Jing Guo, Zihao Chang, Sa Wang, Haiyang Ding, Yihui Feng, Liang Mao, and Yungang Bao. 2019. Who Limits the Resource Efficiency of My Datacenter: An Analysis of Alibaba Datacenter Traces. In Pro- ceedings ofthe International Symposium on Quality ofService (IWQoS’ 19). ACM, New York, NY, USA, Article 39, 10 pages. 5

6. 研究背景 p云计算的下一个十年 n 保障应用性能同时具有高资源利用率 l 谷歌：Cloud 3.0追求速度、实时、隔离、利用率 l 阿里：开放数据中心Trace，广泛征求解决方案 l Berkeley：Cloud computing for the millions 课题来源：国家科技部重点研发计划“软件定义的云计算基础理论与方法”(2016-2021) 6

7. 研究路线 • 云混部评测基准，评价云计算系统负载混部能力 • 干扰感知混部技术+软件定义强控制提高系统效率微服务场景下的组件级区分混部技术在云场景局部干扰现象下，基于微服务组件的抗干扰不一致性进行区分混部和资源隔离控制，提高系统混部效率。干扰控制微服务场景下的局部干扰性能预测针对云场景下微服务应用组件在时-空维度的干扰变化进行分析建模，采用机器学习方法进行混部性能预测干扰评测混合负载基准评测工具SDCBench 6个在线+10个离线型典型云计算负载组成的混部评测程序集，支持不同云场景下的应用混部、性能测试与实验环境构建 7

8. 研究路线 SDCBench混部基准 • SDCBench：用于评测云计算系统在多应用混合部署下的性能隔离性，用于干扰场景构建和相关实验。 • 收集51种常见类型云应用并进行筛选：领域典型性资源密集型体验覆盖度 8

9. 研究路线 SDCBench混部基准 • SDCBench：包含6种典型在线应用和10种离线应用 • 基于聚类分析筛选得到的代表性程序集木兰社区-开源项目计算干扰型组合计算共生型组合 9

10. 目录 1 研究成果介绍 2 灰度干扰下性能预测 3 组件级区分混部技术 4 讨论与总结 10

11. 什么是灰度干扰？ [Jeffrey Dean2013] • 灰度干扰定义为只发生在应用部分组件或局部时间段内的干扰 11

12. 新的微服务场景—函数计算函数计算业务增长 - Google Trends 120 A Berkeley View on Serverless Computing [2019] 100 80 60 40 20 AWS lambda 0 Aug-15 Aug-16 Aug-17 Aug-18 Aug-19 Aug-20 Aug-21 [3] Eric Jonas, Johann Schleier-Smith, Vikram Sreekanti, Chia-che Tsai, Anurag Khan- delwal, Qifan Pu, Vaishaal Shankar, Joao Carreira, Karl Krauth, Neeraja Jayant Yad- wadkar, Joseph E. Gonzalez, Raluca Ada Popa, Ion Stoica, and David A. Patterson. 2019. Cloud Programming Simplified: A Berkeley View on Serverless Computing. 12

13. 函数计算负载特征间歇性触发负载 (BG) • IoT设备采集、监控事件等短期类计算任务 (SC) • Mapreduce/Spark、线性代数等. 延迟敏感性服务 (LC) • 搜索、电子商务、社交网站等小体积函数 0.125-3GB Memory 短生命周期 ≤ 900 s 13

14. 函数计算负载特征小体积函数高密度部署 • 单台服务器可以承载上千函数规模短生命周期更复杂的干扰问题高动态性 • 函数在任意时间都可能执行启动或释放操作 14

15. 应用性能干扰尾延迟平均延迟 The middle 80% The tail 1% [Jeffrey Dean2013] • 应用性能干扰会导致长尾延迟现象 15

16. 函数计算中的灰度干扰现象灰度干扰 • 理解灰度干扰 • 预测灰度干扰 • 干扰控制调度 16

17. 函数计算中的灰度干扰现象 • LS: 社交网站应用 (9个组件） • BG/SC: functions) • matrix multiplication, • video processing, • iperf, • dd, • LR, • Kmeans etc. • 函数计算场景中，灰度干扰的现象更为严重 17

18. 理解刻画灰度干扰灰度干扰场景 1 干扰的高可变性 • 无服务器函数具有不同的运行时和资源消耗特征， diff > ?× 这使得局部干扰更加具有不确定性 • 灰度干扰存在极大不确定性，其对应用性能带来的影响介乎于全部干扰和“零”干扰之间 • 在灰度干扰的场景中，99th百分位延迟的差异达到了7倍 18

19. 理解刻画灰度干扰灰度干扰场景 2 干扰的空间变化性 • 体积小，无状态的无服务 diff > ?× 器函数使得微服务场景下的局部干扰在空间上发生快速变化 • 关键路径(如1-2-3-8-9)上的局部干扰要比非关键路径上的干扰带来更严重的性能下降 19

20. 理解刻画灰度干扰 3 干扰的时间变化性 • 短生命周期的无服务器函数使得微服务场景下的局部干扰部分在短时间内发生快速变化 • 逻辑回归(LR)的JCT与Kmeans在空间维度的灰度干扰下最大性能差异变化超过2倍 20

21. 理解刻画灰度干扰 4 干扰的热点传播性 • 局部干扰会触发整个函数调用路径的连锁反应，并导致完全相反的效果 • 局部干扰发生所在组件后续调用函数的QPS下降 • 瓶颈网关降低了所有其它函数的业务处理速度 21

22. 理解刻画灰度干扰 5 干扰的恢复传播性 • 在灰度干扰节点上的施加局部控制可以改善性能，但会给临近节点带来影响 • 由于业务调用恢复，局部的干扰控制增加了其它函数的延迟 22

23. 理解刻画灰度干扰 6 干扰的可预测性 • 通过函数级的刻画可以实现对灰度干扰的精确预测，从而改善工作负载的QoS • 相比应用级的粗略性能刻画，函数级的粒度刻画可以降低平均2倍的预测误差 23

24. 灰度干扰可预测性干扰预测 • 高可变性 • 空间变化性灰度干扰 • 时间变化性 • 热点传播性 • 恢复传播性 • 可预测性时空干扰感知全局决策函数刻画 24

25. 预测灰度干扰 p 基于函数计算的微服务场景中消除尾延迟？ • 高密度 • 高动态被动控制线程线程#1 线程#2 线程#3 控制监控 CPU时间线被动控制控制机制生效 CPU • 通过细粒度的资源隔离和主动干扰控制有助于实现 • 高性能和高吞吐的云计算系统 25

26. Gsight 预测器 p基于 “时空干扰”- 感知的增量学习方法预测器, 通过对端到端调用路径中函数的刻画信息进行学习训练，可以快速收敛到较高精度单次函数级刻画时空重叠编码增量学习模型 26

27. Gsight 预测器 27

28. Gsight 预测器 • 函数级刻画 • 单独运行 • 非侵入式 • 系统层指标 • 微服务层指标 p16项刻画指标: CPU, memory, network, I/O, branch MPKI, context-switches, LLC, CPU frequency, L2/L3 MPKI等. 28

29. Gsight 预测器 • 增量学习 • 回归模型 • 时间重叠编码 • 空间重叠编码 29

30. Gsight 预测器行数 = VM节点数量 U 1 • 时空重叠编码 • (D 2 , D 3 ) = (0, t delay ) • U 1 , U 2 U 2 ? ? ?? : 表示负载i被部署到节点j上的第k个指标 30

31. Gsight 预测器 p机器学习模型 nIKNN, IRFR, IMLP, ILR, ISVR, ESP [Mishra2017], Pythia [Xu2018] nIRFR方法得到的IPC预测误差小于5% 31

32. 灰度干扰感知调度 • 设计一个简单的二分搜索算法 • 最大化资源分配效率, 在尽可能少的节点上部署所需的函数实例, 同时保障混部应用的性能 • 从完全重叠开始搜索部署方案 • 预测干扰违反SLO则减半混部数量，再次探索活动二分法探索干扰预测如果应用延迟无法保障结束 32

33. 实验评估 • 工作负载: • BG/SC: ServerlessBench [Yu2020], FunctionBench [Kim2019]; • LS: 社交网站和电子商务微服务系统; • Azure trace [Shahrad2020] • Testbed: • OpenFaas 33

34. 实验评估 • 快速稳定的收敛过程: • 函数级细粒度刻画使得Gsight可以快速收敛，同时收敛后的预测精度保持稳定. • 相比于有状态服务系统，Gsight-IRFR 仅需要1/3的训练样本数据大小便可以收敛到同等预测精度水平 34

35. 实验评估 • 函数部署密度 • 相比于Pythia 和 Worst Fit, Gsight 调度器平均可以分别提高18%和48% 的函数部署密度 35

36. 实验评估 • CPU 资源利用率 p相比于Pythia 和 Worst Fit， Gsight 调度器可以改善 30.02% 和 67.51% 的平均 CPU利用率 36

37. 实验评估 • SLA保障 • Gsight 调度器可以保障社交网站应用中 95.39% 的请求满足 SLA要求 37

38. 实验评估 p开销 • 3,000 样本点花费小于2 人-小时, 单次训练时间 < 10分钟 • Gsight 单次预测花费 3.48 ms • 调度的时间占用也很小 • Gsight需要高扩展的Gateway 支持 38

39. 本章小结 • 通过研究先前被忽视的局部干扰,有助于我们进一步理解尾延迟 • 函数计算使得云场景下的资源管理更加具有挑战性 • 在函数计算的微服务场景下，结合主动的干扰控制和细粒度的资源隔离将有助于实现高吞吐和高性能 • Gsight 只是在利用机器学习方法学习和预测灰度干扰方面迈出了一小步 39

40. 目录 1 研究成果介绍 2 灰度干扰下性能预测 3 组件级区分混部技术 4 讨论与总结 40

41. 被动应用混部控制 p 应用混部:改善资源利用率 p 先前的混部调度可以分为两类： p 依赖工作负载的事先刻画 p 实时负载和性能监控 p 基于共生互补进行调度决策 p 资源配置的被动调整 41

42. 被动应用混部控制 p 多组件的微服务应用场景: 来源: [Deathstarbench, ASPLOS’19] 来源: [Google, Datacenter Computers modern challenges in CPU design, 2015] p 基于社交网站的微服务应用评测基准 p 单次交易请求跨越 ~40 机架, ~60 服务器 p 31 微服务组件 p 模式: 客户端-服务器 RPC. 42

43. 问题定义 p 当多个组件协同服务一个请求时，我们如何进行反馈控制? • 端到端延迟: L overall = L cpn 1 + L cpn 2 • 尾延迟: TL overall = TL cpn 1 + TL cpn 2 8VHU 1HWZRUN 1HWZRUN 给定整体的端到端延迟约束 TL, 如何分配每一个组件上的延迟来保障整体SLA? 或: 如何通过组件-控制来保障整体的延迟? 43

44. 组件抗干扰不一致性 Redis 架构: 电子商务网站架构: p 在相同的干扰源下，不同的服务组件受到干扰时整体应用的性能影响可能差异巨大 (~435%) 44

45. Rhythm 系统设计 p Rhythm 设计思想: n 对整体延迟贡献度更小的组件可以被积极地混部更多的BE应用,从而改善系统资源利用率 p 新的挑战: n 如何定义和量化组件的延迟贡献度? n 如何积极地控制BE作业的部署? l 决定何时进行混部? l 决定给LC组件混部多少BE作业? 45

46. Rhythm 系统设计 p Rhythm系统组件: n 请求追求器 n 贡献度分析器 n 混部控制器进程绑定进程到核心 CPU 映射LLC到CPU核心 LLC • Intel RDT CPU核心级别隔离组件级区分混部系统架构 46

47. 请求追求器 p 追踪请求调用: User Network Server 1 Network Server 3 Server 2 User Component Network Network 47

48. 请求追求器 p 因果路径图 n Send/Receive events: ACCEPT, RECV, SEND, CLOSE n Event: < type , timestamp , context identifier , message identifier> n Context: < hostIP , programName , processID , threadID > n Message: < senderIP , senderPort , receiverIP , receivePort , messageSize > 48

49. 请求追求器 Server 1 Server 2 User Component Network User Servpod 1 Network Network Servpod 2 Network Servpod 3 p Servpod 抽象: n部署在同一物理服务器内部的LC应用的相同组件的集合 n用于计算每个请求在每个服务器上的停留时间 49

50. 请求追求器 User Servpod 1 LC Servpod 1贡献度 Network Servpod 2 LC Servpod 2 贡献度 Network Servpod 3 LC Servpod 3 贡献度 p 贡献度分析: n受到干扰时对整体延迟影响较大的Servpod具有更大的贡献度 50

51. 贡献度分析器均值变异系数 n Servpods 具有较高平均执行时间 n Servpods 具有较大的执行时间变化波动 n Servpods 的执行时间同尾延迟有较大的相关性 51

52. 贡献度分析器 p 贡献度定义的合理性? n 敏感性 v.s. 贡献度 n当单个Servpod受到不同BEs的干扰时，99th分位延迟增加: l 将BEs同 wordCount, imageClassify, LSTM, CPU-stress, stream-Dram 和stream-llc混部 l DRAM 压力: Stream-dram l CPU 压力: CPU-stress l LLC 压力: Stream-llc 52

53. 混部控制器 LC Servpod 1贡献度 BE jobs … Agent 4 LC LC Servpod 2 贡献度 Agent 2 Server 1 Servpod 3 贡献度 Agent 3 LC LC BE LC BE Server 2 BE Server 3 p 控制器阈值: n Loadlimit: 当 load<loadlimit时, 允许进行混部（决定是否混部）; l 性能-负载曲线的拐点“Knee point” n Slacklimit: 用来控制BEs作业负载增加下限（决定混部多少） l Slack = 延迟SLA目标 – 当前延迟 l 贡献度小的组件具有更宽松的slacklimit约束值 53

54. 混部控制器 p 混部控制器架构 n 全局控制器 (负责子控制器的决策信号) n 节点控制器（负责节点内的应用混部）全局控制器算法子控制器算法结构 54

55. 混部控制器 p 如何设定Loadlimit阈值? nServpod具有独立的LoadLimit设定 n取值定义为“允许该Servpod混部BE作业的请求负载上限” nknee point拐点：当负载超过某个值导致延迟剧烈变化的点 55

56. 混部控制器 p 如何设定Slacklimit阈值? nSlacklimit: 当前服务延迟距离违反SLA的“余量” Init. Slacklimt _ 1 = 1 Init. Slacklimt_2 = 1 1-contribution2 1-contribution1 … 1-contribution2 1-contribution1 迭代探索 SlackLimit Slacklimit2 1-contribution1 Slacklimit1 Servpod 1 Slacklimit设定算法 1-contribution2 … Servpod 2 • contribution_1 < contribution_2 • slacklimit_1 < slacklimit_2 56

57. 实验评估 p基准程序： n LC服务 n BE作业 l Apache Solr：Solr engine+Zookeeper l CPU-Stress; Stream-LLC; Stream-DRAM l Elasticsearch：Index+Kibana l Iperf：Network l Elgg：Webserver+Memcached+Mysql l LSTM：Mixed l Redis：Master + Slave l Wordcount l E-commerce: Haproxy+Tomcat+Amoeba+Mysql l ImageClassify： deep learning n 实验环境 16 Sockets, 64 GB of DRAM per socket, L3 cache 20MB. CPU 型号：Intel Xeon E7-4820 v4 @ 2.0 GHz: 32 KB L1, 256 KB L2 操作系统：Ubuntu 14.04 with kernel version 4.4.0-31. 57

58. 整体性能 EMU CPU Utilization MemBan utilization p 整体对比 (对比 Heracles [ISCA 2015]) n改善EMU (=LC 吞吐+ BE 吞吐) 11.6%~24.6% n改善CPU 利用率 19.1%~35.3% n改善内存带宽利用率 16.8%~33.4% 58

59. 系统控制过程 p 时间轴： n Time 3.3： suspendBE()； n Time 5.6： allowBEGrowth()； n Time 7.7： cutBE(); n Time 9.3: suspendBE(). 59

60. 本章小结 p Rhythm是一个分布式的混部控制器，通过利用组件间的抗干扰不一致性，在保障LC服务性能的同时尽可能多地混部 BE作业，从而改善系统吞吐 p 设计架构简单，全局决策+局部控制+细粒度的软硬件隔离机制保障混部性能。 p Rhythm提供了设计思想，在实际生产环境落地需要进一步修改和适配，比如结合Dapper追踪系统[Google 2010]。 p 后续增量工作—基于优先级的BE作业控制，避免“用而无用”，进一步改善混部效率 [4]Benjamin H. Sigelman, Luiz André Barroso, Mike Burrows, Pat Stephenson, Manoj Plakal, Donald Beaver, Saul Jaspan, and Chandan Shanbhag. 2010. Dapper, a Large-Scale Distributed Systems Tracing Infrastructure. Technical Report. Google, Inc 60

61. 未来展望 p 在学术界和工业界，干扰研究已经存在大量的工作 p 基于性能预测的主动控制或者基于监控的被动资源调整 p 采用的方法大致包括单独刻画、分类放置、机器学习模型、启发式探索等 p 硬件隔离机制 CPU核心级别隔离，同一个socket内部CPU 核心共享缓存，内存带宽以及总线 p 线程级资源隔离，引入标签机制打通软硬件全通路，变革现有云计算技术栈 61

62. 交流与讨论 p 相关资料 Gsight文章：Laiping Zhao, Yanan Yang, Yiming Li, Xian Zhou, Keqiu Li: Understanding, predicting and scheduling serverless workloads under partial interference. SC 2021: 22:1-22:15 Rhythm文章：Laiping Zhao, Yanan Yang, Kaixuan Zhang, Xiaobo Zhou, Tie Qiu, Keqiu Li, Yungang Bao: Rhythm: component-distinguishable workload deployment in datacenters. EuroSys 2020: 19:1-19:17 SDCBench设计实现：https://gitee.com/jiaxuechao/sdcbench Gsight设计实现: https://github.com/tjulym/gray Rhythm设计实现: https://github.com/yananYangYSU/Rhythm 62

63. 谢谢观看 63