【论文】略读笔记40-前沿-针对云原生的尾部延迟优化CPU架构
📖《μManycore: A Cloud-Native CPU for Tail at Scale》
🎯需求
- 微服务正在成为一种流行的云计算范式。
- 云计算的模式正在发生转变，大型单体应用正在被许多轻量级、松散耦合的微服务所取代。
- 在这些 “云原生 “工作负载中，每个微服务都作为单独的程序实现和部署，并执行应用程序的部分逻辑，如 HTTP 连接终止、键值服务、协议路由或广告服务。
- 这种可组合的应用设计简化了开发过程，实现了编程语言和框架的异构性。此外，每个微服务都可以在多个应用程序之间共享，同时可以独立于其他微服务进行扩展和更新。亚马逊、Netflix、阿里巴巴、Twitter、Uber、Facebook 和谷歌等所有主要云提供商都在采用这种新模式。此外，管理微服务工作负载的开源环境（如 Kubernetes 和 Docker Compose）也大量涌现。
- 微服务环境执行的是典型的短服务请求，这些请求通过远程过程调用（通常是跨机器）进行交互，并受到严格的尾延迟限制。
- 微服务环境具有新的特点，会影响其运行平台的系统和硬件架构。
- 具体来说，应用程序中的微服务请求通常是短时间运行的，并可能在不同的机器上执行。不同微服务的请求不共享内存状态，而是通过远程过程调用（RPC）进行交互。
- 此外，请求的工作集较小，经常被突发调用，执行前经常在队列中等待。
- 最后，应用程序的分解会对单个服务设定严格的亚毫秒级延迟服务级别目标（SLO）。因此，虽然减少平均延迟和提高吞吐量很重要，但这些环境中的关键性能目标现在是最大限度地减少尾部延迟（例如，提高第 99 百分位数响应）。在基于微服务的新兴部署方法（如功能即服务（FaaS）环境）中也发现了许多此类特性。
- 微服务环境具有新的特点，会影响其运行平台的系统和硬件架构。
🚧现状
相比之下，当前的处理器是为传统的单体应用而设计的。它们支持全局硬件高速缓存一致性，提供大型高速缓存，采用微体系结构以实现长时间运行、可预测的应用（如高级预取），并进行了优化，以最大限度地减少平均延迟而非尾部延迟。
- 目前的处理器并不是专门为这些环境设计的。事实上，多核处理器为支持全局硬件缓存一致性投入了大量的硬件和设计复杂性。它们拥有大型高速缓存来捕获长期运行应用程序的工作集。相对而言，它们并不关心支持短时间运行的 RPC 通信程序。相反，它们针对长期运行、可预测的应用程序进行了微体系结构优化，如高级预取器和分支预测器。这些优化措施大大增加了硬件的复杂性，对于微服务来说，充其量只能起到微不足道的作用。
- 也许最重要的是，目前的处理器经过高度优化，最大限度地减少了程序或事务的平均延迟，而忽略了尾部延迟的考虑。
应该如何改变处理器的设计，使其符合微服务的要求呢？
- 首先，应该重新考虑一些会带来设计复杂性但微服务几乎不需要的硬件优化，如全局硬件缓存一致性。
- 其次，应全面优化以减少尾端延迟。优化既要针对影响所有请求的低效问题，也要针对可能影响部分请求的基于争用的开销。
虽然最终产生的处理器在通用负载方面没有竞争力，但它可以成为微服务密集型数据中心的首选 CPU。
为了更具体地说明问题所在，我们首先分析了 阿里巴巴 的生产级微服务跟踪和 DeathStarBench 的微服务应用。
- 我们的分析表明，突发的服务请求会产生高需求期，在高需求期很可能会出现长时间的等待队列。
- 此外，请求的大部分时间都被阻塞，等待完成对存储的访问或对其他服务的调用。在此期间，CPU 会频繁地进行上下文切换，从而带来开销。
- 此外，内核之间由服务发起的消息会受到互连网络（ICN）的延迟，经常会出现争用延迟，从而进一步增加尾部延迟。
- 最后，虽然请求的工作集很小，但微服务却受益于附近的大型内存池，该内存池存储了每个微服务的最多读取状态。
🛩创新
- 为了解决这一不平衡问题，本文提出了μManycore，一种针对云原生微服务工作负载进行了高度优化的处理器架构。μManycore 不是加速器，它保留了通用处理器的功能，尽管对于单片应用来说可能不那么有竞争力。
- 基于对微服务应用的特征分析，我们设计了基于芯片组的 μManycore。尽量减少不必要的微架构，降低开销以减少尾部延迟。
- μManycore不支持全包硬件缓存一致性，而是通过多个小型硬件缓存一致性域（称为 “村”）来构建。微服务被分配到各个村落。几个村落和一个内存芯片组（存储最多读取的状态）组成一个群集。
- 集群通过叶刺 ICN 互联。这种拓扑结构在任何两个集群之间都有许多冗余的低跳数路径，因此可以最大限度地减少具有相同源集群和目标集群的多条信息之间的争用，并减少尾部延迟。（相当于原本只有一条大路，后来变成了很多小路。那么小路为什么比大路快？）
- 为了尽量减少调度开销，μManycore 在硬件中对服务请求进行排队、去排队和调度。
- 最后，为了尽量减少频繁切换上下文的开销，内核包括保存和恢复进程状态的硬件支持。
- 基于对微服务应用的特征分析，我们设计了基于芯片组的 μManycore。尽量减少不必要的微架构，降低开销以减少尾部延迟。
- 本文的贡献如下：
- 1）描述传统处理器中的微服务工作负载行为。
- 2）提出μManycore，一种针对微服务工作负载高度优化的处理器架构。
- 3）对 μManycore 进行评估，将其与两个传统服务器级多核处理器进行比较：一个功率相同，一个面积相同。
📊效果
- 我们的模拟结果表明，μManycore 可为微服务工作负载提供高性能。我们将 1024 核的 μManycore 与两个传统的服务器级多核进行了比较：一个具有与 μManycore 相同的功率，一个具有与 μManycore 相同的面积。
- 与使用等功率传统多核的集群相比，使用 μManycore 的 10 台服务器集群的平均延迟降低了 3.7 倍，吞吐量提高了 15.5 倍，更重要的是，尾部延迟降低了 10.4 倍。
- 与采用等功耗传统多核的集群相比，也取得了类似的良好效果。最后，包上叶脉 ICN、硬件请求调度和硬件上下文切换对提高微服务工作负载的性能非常有效。
🧠疑问
- 多核处理器架构如何实验？仅通过模拟实验是否会导致结果与实际不符？
- 在落地方面的可行性很需要考虑，“设计的芯片结构是否符合现实”，“是否能够真正落地到硬件”都是需要有足够的芯片相关背景知识才能不出常识性错误。
- 在落地方面的必要性也值得考虑，当且仅当微服务应用确实成为主流，且有数据支撑现有CPU架构对性能影响极大的前提下，该问题才值得成为真问题。因此作者的introduction和motivation部分非常重要。（看到在introduction的最后几段，说明了数据是来源于对阿里巴巴等应用的分析）
- 写作结构很规范，背景、问题、创新说得很清楚，读者理解难度很低，值得学习。
- 希望这篇博客对你有帮助！如果你有任何问题或需要进一步的帮助，请随时提问。
- 如果你喜欢这篇文章，欢迎动动小手 给我一个follow或star。
🗺参考文献
- 标题: 【论文】略读笔记40-前沿-针对云原生的尾部延迟优化CPU架构
- 作者: Fre5h1nd
- 创建于 : 2024-07-01 20:32:06
- 更新于 : 2024-07-02 09:37:27
- 链接: https://freshwlnd.github.io/2024/07/01/literature/literatureNotes40/
- 版权声明: 本文章采用 CC BY-NC-SA 4.0 进行许可。
评论