【论文】略读笔记39-前沿-图神经网络预测应用延迟

📖《PERT-GNN: Latency Prediction for Microservice-based Cloud-Native Applications via Graph Neural Networks》

🎯需求

• 使用微服务架构的云原生应用正在迅速取代传统的单体应用。
  • 微服务架构是云原生领域的一个重要软件开发框架。它将应用程序构建为一个小型、独立、自足的服务集合，可以独立部署和管理。与单体框架相比，微服务框架具有灵活扩展资源的优势。
  • 图 1 显示了一个由多个微服务组成微服务调用图（MCG）的社交网络应用程序。用户客户端通过 API 端点向应用程序发送 API 调用请求。然后会调用具有专用功能的微服务来满足用户的特定请求。当应用程序的负载不断增加时，服务提供商可以定位并扩展负载较重的单个微服务，而不是扩展整个应用程序。
    
• 为了满足端到端 QoS 保证并提升用户体验，必须为每个组件微服务配置足够的资源，以处理传入的 API 调用。准确预测基于微服务的应用的延迟对于优化资源分配至关重要，而由于微服务之间的复杂依赖关系和固有的随机性，预测延迟具有极大的挑战性。
  • 尽管具有灵活性，但微服务架构在生产环境中提供端到端 QoS 保证方面带来了巨大挑战，因为单个用户请求需要由数百个细粒度微服务处理。
  • 如今的生产集群通常会过度配置资源以提供此类保证，这很容易导致整体资源利用率低下，例如，阿里巴巴微服务集群的 CPU 利用率低至 20%。因此，设计更高效的资源扩展解决方案来满足 QoS 保证变得至关重要。
  • 微服务的资源扩展主要有两种方法：被动式和主动式。
    • 被动式方法根据系统的性能反馈实时调整资源。
    • 相比之下，前瞻性方法是建立预测模型，提前估算不同资源配置下用户请求的尾端（如第 95 百分位数）端到端延迟，然后选择最佳配置。
    • 被动式解决方案虽然易于实施，但很容易造成违反 QoS 的情况，因为获得端到端反馈可能为时已晚，无法进行扩展，尤其是在呼叫链很长的情况下。因此，近年来，主动式扩展往往是微服务更有前途的方法。

🚧现状

• 为了解决这个问题，人们设计了各种基于微服务调用图的预测器。然而，微服务调用图没有考虑到特定于应用程序接口的信息，无法捕捉重要的时间依赖性，也无法扩展到大规模应用。
  • 实现高效主动扩展的能力在很大程度上取决于对尾端到端延迟的准确预测，但这仍然具有相当大的挑战性。
    • 首先，同一应用中的组件微服务之间会形成复杂的交互。一个微服务的响应会极大地影响其下游微服务，进而影响整个跟踪的端到端延迟。因此，如果不能捕捉到微服务之间的复杂依赖关系，就会导致预测不准确。
    • 其次，尾部延迟因其固有的随机性而不稳定，因为它考虑的是最坏的情况。如图 2 所示，虽然社交网络应用程序的工作量在整个一周内会发生周期性变化（图 2a），但中位延迟（响应时间）却保持在 13 毫秒到 17 毫秒之间（图 2b，橙色曲线）。相比之下，第 95 百分位数的延迟时间波动较大，介于 60ms 和 510ms 之间（图 2b，蓝色曲线）。
      
• 在文献中，很多人致力于捕捉微服务及其操作之间的复杂依赖关系，以预测尾端到端延迟。特别是，这些著作主要采用深度神经网络来模拟基于整个 MCG 的依赖关系。然而，基于 MCG 的预测器存在以下三个局限性。
  • 1）MCG 不具备 API 感知能力，包含大量无关信息，可能导致预测结果不理想。在给定的 API 调用中，只有 MCG 中的一小部分微服务参与其中。例如，如图 1 所示，readTimeline 与发送到 MediaNGINX 的 API 调用的执行无关。如果不过滤噪声，延迟预测将非常不准确。此外，对于大型应用而言，如果无法捕获具有 API 感知的相关微服务，很容易产生大量计算开销。
  • 2）MCG 是一种静态图，无法捕捉调用之间的时间动态。例如，PostStorageService 微服务随后会调用另外两个微服务，但 MCG 不会显示哪个微服务先被调用。此外，MCG 也不会区分这两个微服务是并行调用还是顺序调用。
  • 3）MCG 无法识别运行时动态。对于相同的 API 调用，运行时动态可能因输入参数的不同而不同。例如，/api/home-timeline/read API 调用可以使用或不使用 userId 参数。这将影响是否调用 UserTimelineMongoDB:find 微服务操作，进而影响 /api/home-timeline/read API 调用的端到端延迟。但是，MCG 无法包含这些信息，因为它使用单个静态图将所有运行时行为耦合在一起。
• 由于这些局限性，目前的预测器预测准确率较低，导致违反服务质量和浪费资源。

🛩创新

• 为了解决这个问题，我们引入了 PERT-GNN，这是一个图神经网络（GNN）模型，可根据给定时间内的 API 调用和资源利用率预测基于微服务的应用的端到端延迟。PERT-GNN 是一种通用模型，适用于任何基于微服务的应用，只需将具有节点特征和/或图特征的图作为输入即可。在这项工作中：
  • 图（Span/PERT）是由分布式跟踪工具（如 Jaeger）收集的轨迹构建而成的。详见第 3 章。
  • 节点特征是指应用程序中每个微服务组件的资源利用率（CPU/内存/磁盘/网络负载）。这些特征由数据遥测工具（如 Prometheus）定期采集。
  • 图特征指的是 API 调用的类型、跟踪的时间戳以及历史请求数/响应时间的时间序列。
• PERT-GNN 可感知应用程序接口，并能在给定的应用程序接口调用中纳入微服务之间的时间依赖性。我们的贡献总结如下：
  • 1）为了解决局限性（1）-（2），我们提出了一种基于程序评估和审查技术（PERT）的新设计，以构建可感知应用程序接口并能捕捉微服务之间时间依赖关系的图。图的构建由数据驱动，基于分布式跟踪工具（如 Jaeger）收集的原始微服务跟踪数据，无需任何人工干预。
  • 2）为解决局限性（3），我们提出了一种通用图混合方法，可识别同一 API 调用的不同运行时动态。这样，我们就能在同一个应用程序接口调用中确定不同运行时动态的相关微服务之间的关系。
  • 3）我们提出的 PERT-GNN 是一种基于transformer的 GNN，它通过捕捉微服务的结构和位置信息，预测微服务应用的不同端到端延迟百分位数，并进行端到端训练。
• PERT-GNN 利用程序评估和审查技术（PERT）从应用程序先前的执行轨迹中观察组件微服务的交互或依赖关系。然后，我们根据生成的 PERT 图构建图神经网络，并使用图转换器方法将延迟预测任务表述为有监督的图回归问题。PERT-GNN 可以捕捉不同微服务跟踪的复杂时间因果关系，从而为各种应用提供更准确的延迟预测。

📊效果

• 基于常见基准和大规模阿里巴巴微服务踪迹生成的数据集进行的评估表明，PERT-GNN 的性能远远优于其他模型。特别是，PERT-GNN 能够以低于 12% 的平均绝对百分比误差预测微服务应用的延迟。

🧠疑问

1. 现有集群利用率低的原因是“过度配置资源”吗？阿里巴巴没有使用负载预测技术吗？如果没有，原因是什么？
2. 面向的是单个应用内部的复杂关系，多个应用之间是否存在关联关系？

---

---

• 希望这篇博客对你有帮助！如果你有任何问题或需要进一步的帮助，请随时提问。
• 如果你喜欢这篇文章，欢迎动动小手给我一个follow或star。

🗺参考文献

[1] Da Sun Handason Tam, Yang Liu, Huanle Xu, Siyue Xie, and Wing Cheong Lau. 2023. PERT-GNN: Latency Prediction for Microservice-based Cloud-Native Applications via Graph Neural Networks. In Proceedings of the 29th ACM SIGKDD Conference on Knowledge Discovery and Data Mining (KDD ‘23). Association for Computing Machinery, New York, NY, USA, 2155–2165. https://doi.org/10.1145/3580305.3599465