Master Dissertation

week1

Microservice, Docker Explanation:

Service Grid and Microservice Communication: The Service Grid is an infrastructure layer that handles service-to-service communication. As the number of microservices increases, so does the complexity of communication between services. Service Grids such as Istio and Linkerd help solve this problem, but there is still much room for research and exploration, including communication efficiency, security, observability, and control.

Container orchestration and scheduling: With the growing popularity of containerized applications, how to effectively manage and schedule these containers has become an important issue. Although Kubernetes has become the de facto standard, further research is needed on how to optimize scheduling strategies, how to save resources while ensuring performance, and how to perform container scheduling in multi-cloud environments.

Performance and Scalability of Microservices: With the widespread adoption of microservice architectures, how to improve the performance and scalability of microservices is an important research issue. This includes how to design an efficient microservice architecture, how to optimize the performance of microservices, and how to effectively scale up and down microservices.

Security of containers and microservices: Due to the dynamic and decentralized nature of containers and microservices, their security becomes an important research issue. This includes how to ensure the isolation of containers, how to protect the communication between microservices, and how to prevent malicious code from running in container and microservice environments, etc.

Testing and verification of microservices: The independence and dynamic nature of microservices brings new challenges for testing and verification. How to conduct effective microservice testing, how to verify the correctness of microservices, and how to perform continuous integration and continuous deployment of microservices are all issues that need to be studied.

Fault detection and recovery: In a distributed environment, fault detection and recovery is a very important issue. This includes how to quickly detect faults, how to accurately locate the cause of faults, and how to automatically restore services.

How and why decoupling?

Decoupling and transforming a project into a microservice architecture while containerizing it using Docker can improve system scalability, maintainability, and disaster recovery. The following are some basic steps:

1. Determine microservice boundaries: The first step is to determine which microservices to decompose the large monolithic application into. This process requires understanding the business logic and identifying modules that can run independently and scale independently. A good microservice should be business-driven and can perform a specific business function independently.

2. Create inter-service communication mechanisms: In a microservice architecture, services need to communicate with each other over the network. You can choose to use REST, gRPC, or message queues for communication.

3. Designing data persistence: Each microservice should have its own independent database to reduce the coupling between services. But this also needs to address the issue of data consistency.

4. Build microservices: For each microservice, you can choose the programming language and framework that best suits the business logic of that service for development.

5. Create Docker containers: Pack each microservice into a Docker container. Each container contains all the dependencies and environments needed to run a microservice, which ensures that the microservice will run stably in any environment.

6. Orchestrate with Docker Compose or Kubernetes: These tools can help manage and deploy your Docker containers, as well as handle service discovery, load balancing, fault recovery, networking, and security.

7. Implement Continuous Integration and Continuous Deployment (CI/CD): Automating builds, tests, and deployments can greatly improve development speed and software quality.

The main benefits of doing so are as follows:

1. Scalability: When the system load increases, services with higher demand can be scaled individually without the need to scale as a whole.

2. Maintainability: Each service runs independently, with a small code base that is easier to understand and modify.

3. Fault isolation: If something goes wrong with one service, it will not affect other services, reducing the risk of system failure.

4. Fast iteration: Each microservice can be deployed independently, making it faster to develop and bring new features online.

5. Technology diversity: Each microservice can choose the technology stack that best suits its business needs.

Benefits from containerization: Using Docker containers simplifies the deployment process, ensures software consistency across environments, and provides better.

Fog computing:

Fog computing is a computing architecture in which a series of nodes receives data from IoT devices in real time. These nodes perform real-time processing of the data that they receive, with millisecond response time. The nodes periodically send analytical summary information to the cloud

Projects ideas:

Docker and distributed architecture application in cloud computing platform.

Decouple a project into microservices architecture (Monometer -> microservice, use brownfield projects).

Make sure every service we have is high cohesion, and low coupling.

Avoid underserving. The system says no more than four calls. This ensures a moderate level of service. In addition, it is important to think about the team in terms of making the team light enough to decouple microservices from each other. From the above aspects, to avoid the problem of microservices too small.

Some open source manometer projects: BroadleafCommerce, https://github.com/jhipster/generator-jhipster

Decompose by business capability model/Decompose by subdomain pattern (DDD).

week2

Paper review

Summary and baselines

Will_edge_autoscaling

ML-based scaling management for kube

PBScaler: A Bottleneck-aware Autoscaling Framework for Microservice-based Applications

Microscaler: Automatic Scaling for Microservices with an Online Learning Approach”

Autopilot: workload autoscaling at Google

Adaptive scaling of Kubernetes pods

Proactive Autoscaling for Edge Computing Systems with Kubernetes

SHOWAR: Right-Sizing And Efficient Scheduling of Microservices

Relative project

https://github.com/jthomperoo/custom-pod-autoscaler

Custom Pod Autoscaler

HPA cons: hard coded algorithm, CPA provides you flexibility in my scaling.

Week3

Autopilot/ LOTUS

CPA

Week4

PPA/PBScaler/LOTUS/Autopilot

Let’s start with PPA

摘要

随着物联网和5G技术的出现，边缘计算范式以更好的可用性、延迟控制和性能发挥着越来越重要的作用。然而，现有的边缘计算应用程序的自动缩放工具不能有效地利用边缘系统的异构资源，从而为性能改进留下了空间。在这项工作中，我们为Kubernetes上的边缘计算应用程序提出了一个主动Pod Autoscaler (PPA)。提议的PPA能够使用多个用户定义/自定义指标提前预测工作负载，并相应地扩展和缩小边缘计算应用程序。在一个cpu密集型边缘计算应用实例中，进一步对PPA进行了优化和评估。可以得出结论，所提出的PPA在资源利用效率和应用程序性能方面都优于Kubernetes默认的pod自动缩放器。文章还强调了拟议购电协议未来可能的改进。

一

在过去的几十年里，云计算应用在各种广泛的领域中越来越受欢迎[4,18]。云计算供应商为用户提供按需可用的大量资源，包括计算单元、存储、网络设备，甚至服务和应用程序。云计算已经被证明在商业和技术方面都是成功的，并且这种方法为许多流行的应用程序(例如Netflix, DropBox, Spotify)提供了动力[13,15]。然而，云计算存在应用程序延迟的问题，这主要受限于客户端与数据中心之间的地理距离和网络带宽[12]。因此，云计算不能完全满足对延迟敏感的应用程序(例如视频游戏流、实时数据分析)的需求。

边缘计算是解决传统云计算延迟问题的一种很有前途的方法[14]，它将对延迟敏感的计算和数据存储移动到靠近网络边缘的客户端位置。边缘计算具有较低的延迟、带宽占用和开销，在实现智慧城市、智能电网、智能交通等方面发挥着重要作用[11]。

在现实场景中，云计算和边缘计算应用程序的自动伸缩是必不可少的[3,20]。随着工作负载的变化，自动伸缩工具会动态调整资源量，以保持每个计算/存储单元的平均工作负载稳定。自动缩放为应用程序提供了更好的容错性、高可用性、高效的能耗和成本管理。

对于云计算，HPA作为Kubernetes提供的本地服务被广泛使用，Kubernetes是大多数云平台上事实上的云框架[8]。HPA以CPU利用率为衡量工作负载的指标，使用式1所示的算法以响应式方式扩展云应用程序。


然而，对于边缘计算，自动缩放是一个更复杂的问题[19]。尽管HPA在许多云计算案例中简单有效，但它并不完全能够自动扩展边缘计算应用，原因有三个:

HPA不是专门为边缘计算环境设计的，不知道异构边缘资源的约束和能力;

HPA仅考虑CPU利用率来估计工作负载。然而，对于边缘计算应用程序，在扩展应用程序时，有关系统的其他信息(例如作业队列、I/O、请求速率)也是必不可少的;

HPA是基于规则的，不可编程的，服务提供商很难定制HPA来满足他们对边缘计算应用的特定需求

一种很有前途的方法是为边缘计算应用程序开发一个主动的自动缩放器，该自动缩放器支持多个度量和可定制的算法。然而，开发这样的自动缩放器是具有挑战性的。从理论上讲，由于边缘资源的异质性和局限性，预测边缘系统的工作负载和扩展pod形成了一个时间序列分析和多目标优化的混合问题。实际上，从不同的来源收集多个度量标准并以统一的方式组织依赖于各种库的自定义算法是一个复杂的多框架工程问题。在这项工作中，我们提出了一个多指标支持和可定制的主动pod自动缩放器。自动扩展器能够收集多个指标，预测工作负载并提前扩展目标应用程序。此外，它允许用户自定义他们自己的扩展策略和预测模型，以更好地适应他们的应用程序。这项工作的主要贡献包括:

(1)为自动缩放边缘计算应用引入主动工作流。

(2)在Kubernetes上实现多指标支持和可定制的自动缩放器。

(3)提供一个示例应用程序，以演示所建议的自动缩放器的性能。

本文的其余部分组织如下。相关文献在第2节中进行了回顾。在第3节中，说明了本工作中边缘系统环境的设计。在第4节中，详细解释了所提出的自动缩放器的体系结构和算法。第5节和第6节介绍了所建议的自动缩放器的实验设计和结果。第7节总结了工作，并强调了进一步可能的改进。

二

考虑到HPA作为一个基准，许多研究工作已经开始探索HPA的替代方案，以用于托管在容器上的云/边缘应用程序。在本节中，将回顾有关被动和主动自动缩放技术的相关工作。此外，我们提出的主动Pod自动缩放器的必要性和其独特的功能进行了解释。

2.1

2019年，Fan等人报道了一种容器系统架构，提供了更高的自动缩放效率[22]。2020年，Salman和Marko的一篇文章探讨了除了CPU利用率之外应该考虑的其他关键因素[17]。可以肯定的是，为了更好地自动扩展云系统，除了CPU利用率之外，还需要多个指标。无功自缩放器的一个主要缺点是控制延迟。虽然一旦工作负载发生变化，容器就会被扩展，但是容器的初始化或终止需要时间。

2.2

为了改进响应式pod自动扩展器，它有望预测工作负载并提前做出扩展决策，即主动/预测自动扩展。2016年，Yang等人提出了一种基于时间序列分析预测容器CPU使用情况的主动自缩放算法CRUPA[9]。另一个例子来自Tian等人，他们在2017年报告了一个预测自动缩放框架[21]。为了提供更好的服务质量，提出了一种结合CPU利用率预测和服务水平协议的混合自扩展策略。机器学习模型在时间序列分析中得到了很多关注[16]，一些报道的主动自动标度器是基于机器学习模型的。2020年，Mahmoud, Imtiaz和Mohammad提出了一种基于机器学习的主动自动缩放器，它利用LSTM和多个指标来预测工作负载[6]。虽然有一些关于云系统的主动自动缩放的工作，但边缘计算系统的主动自动缩放很少。据我们所知，只有一篇文章报道了边缘系统的主动自动缩放[1]。建立了预训练的神经网络模型，并将其作为运行系统中CPU利用率的预测模型。预测的CPU指标用于估计副本的数量。表1比较了相关工作和我们提出的方法。我们提出的主动Pod自动缩放器(PPA)具有以下特点:

•考虑到异构资源的限制和约束，这是少数关注边缘计算应用程序自动缩放的研究之一。

•支持多个指标(CPU, RAM, I/O利用率)和自定义指标来自动扩展应用程序，为工作负载估计和预测提供替代指标。尽管CPU利用率在许多情况下能够预测工作负载，但一些应用程序需要多个或特定于应用程序的指标来做出扩展决策。

•PPA灵活且与模型无关。与其他具有固定预测模型的主动pod自动缩放器不同，拟议的PPA支持自定义模型和多个模型框架(例如TensorFlow, statmodels等)。用户可以将自己的模型注入到PPA中，以获得适合自己应用的最佳性能。

•购电协议可以考虑信心因素。如果注入的模型是贝叶斯模型，对每个预测产生置信度/不确定性估计，那么所提出的自动标度器只有在预测置信度超过预设置信度阈值时才会主动工作，否则它会被动工作

三

现在详细介绍了所考虑的云和边缘环境的设置。

3.1 边缘计算的环境



图1显示了我们为Kubernetes连接的云/边缘计算环境编排的拓扑结构。表2介绍了系统中节点分配的资源。不同节点分配的资源有限且大小不一，而云节点拥有更强的计算能力和更大的内存资源。该系统描绘了一个典型边缘计算环境的真实世界模型。


3.2 集群组件

除了Kubernetes核心之外，集群还包含三个用于系统监控的逻辑组件，包括导出器、Prometheus堆栈和自动缩放器。集群的监控系统对于成功运行所建议的云/边缘计算框架起着至关重要的作用。该系统基于Prometheus[5]，这是云计算和边缘计算环境中最流行的框架之一。不同类型的导出器负责生成不同的度量标准。在考虑的边缘计算环境中，节点导出器部署在每个节点上用于节点级指标，并为用户部署可自定义导出器以生成/提取用户自定义指标(例如请求率，排队任务数等)作为自定义指标。普罗米修斯堆栈由三部分组成——普罗米修斯、Grafana和普罗米修斯适配器。指标由Prometheus从出口商收集，并使用Grafana进行可视化。收集到的指标也由Prometheus Adapter在标准API中公开，以便其他pod能够以统一的方式获取它们。从Prometheus Adapter，自动扩展器获取所有类型的所需指标，评估所需副本的数量，并向Kubernetes主控制面板发出扩展决策请求。Kubernetes负责处理扩展请求和在节点上调度新的pod。

四

在本节中，介绍了所提出的主动Pod自动缩放器的体系结构和算法。首先阐述了PPA的结构和工作流程。然后，对PPA各组成部分的详细算法进行了推导和说明。

4.1 架构


图2显示了提议的主动pod自动缩放器的结构。PPA由三个组件(Formulator、Evaluator和Updater)组成，在两个循环中工作(控制循环和模型更新循环)，并维护两个文件(度量历史文件和模型文件)。PPA的初始化需要将预训练的种子模型作为初始模型文件注入框架中。

在每个控制循环中，PPA负责使用收集到的指标扩展目标pod。Formulator从Prometheus Adapter获取原始指标，并对其进行预处理。制定的度量存储在度量历史文件中，并传递给评估者。然后，Evaluator从model file中加载模型，预测所需副本的数量，并向Kubernetes控制面板发出缩放请求。

在每个模型更新循环中，Updater从度量历史文件中加载训练数据，更新模型，删除度量历史文件，并将模型重新保存到模型文件中。有了Updater，用于预测的模型就可以针对新的工作负载模式不断更新。

4.2算法

4.2.1 评估器evaluator

算法1描述了评估器的工作原理。对于每个PPA，必须将一个关键指标设置为工作负载的估计器，注入的预测模型使用收集的指标来预测关键指标。为了从预测的关键指标中获得所需的副本数量，应该定义一个静态策略。在本工作中，使用第1节中描述的基于阈值的HPA算法作为默认的静态策略。但是，静态策略是可定制的，用户可以在PPA中注入自己的策略。


model.isBayesian() 是检查模型是否为贝叶斯模型的条件。贝叶斯模型是一种统计模型，它使用贝叶斯定理进行推断和预测。在这段代码中，如果模型是贝叶斯模型并且预测的置信度低于阈值，就会选择使用当前的关键度量指标而不是模型预测的结果。

1
2
3
4
5
6
7
8
9
10
11
12

Result: Number of replicas to be requested

Get current_metrics, current_replicas;

Set max_relicas of system;

if bottleneck_check == False then
	num_replicas = 1
else if current_replicas < max_relicas then
	num_replicas = GA(Genetic_algorithm_init_parameters, current_metrics, current_replicas)
else
	num_replicas = max_relicas

​

4.2.2 模型的协议

所有满足以下协议的时间序列模型都可以注入进行指标预测:

(1)时间窗口大小:所有模型的时间窗口大小固定为1个单位，表明模型使用上一个回路的指标预测下一个控制回路的工作量。这是由新pod的初始化时间成本决定的，它通常需要不到一个时间间隔的控制循环。

(2)输入输出指标:模型的指标应按以下顺序输入[CPU, RAM，网络输入，网络输出，自定义指标]。该模型应该预测所有输入指标，但只有一个被设置为关键指标。

4.2.3升级器的模型更新策略Model Update Policy of the Updater

虽然Updater的工作流程是固定的，但我们提出了3种不同的策略来更新种子模型(称为模型更新策略):

(1)不重新训练模型:在整个执行过程中使用注入的种子模型而不更新。如果种子模型在稳定的工作负载下能够产生令人满意的结果，则无需定期更新模型，成本较大;

(2)从头开始重新训练模型:在每个模型更新循环中，Updater丢弃旧模型并从头开始训练具有与种子模型相同架构的新模型。在不同日子的工作负载变化很大的情况下，基于旧数据的模型不一定适合未来几天的工作负载模式;

(3)更新模型:使用上一个模型更新循环的数据对旧模型进行多几个epoch的再训练。在许多情况下，模式的工作负载确实会发生变化，但变化不大，并且可以将旧模型用作更新过程的起点。

这里我们提供了三个选项，对于不同的应用程序和不同的工作负载模式，最佳策略可能不同。

五. 实验

实验的目的是优化所提出的主动Pod自动缩放器的示例应用，并与HPA进行比较，验证其性能。在本节中，首先介绍示例应用程序和工作负载的生成。然后详细介绍了PPA优化和评价的实验细节。

5.1 示例应用


5.1.1 拓扑图

图3显示了托管在边缘计算集群上的示例应用程序的体系结构。示例应用程序分布在一个云和两个边缘区域中。在每个区域，都部署一些支持性的静态pod和服务，它们是固定的，不是为可扩展而设计的。只有每个区域中的worker pods才是自动缩放器要缩放的目标。

5.1.2 工作流和作业

在示例应用程序中，定义了两种不同类型的任务。第一种是对长度为3000的随机数组进行排序(称为sort task)，复杂度为𝑛log𝑛;第二种是计算维数为1000 × 1000的随机矩阵的特征值(称为eigen task)，复杂度为𝑛3。所有请求都是从设备生成的，它们到达最靠近其位置的边缘的入口点。每个请求要么是排序任务，要么是特征任务。具有排序任务的任务计算成本不高，由边缘工作者处理，而具有特征任务的任务由于计算成本高而转发给云工作者。本工作中的示例应用程序是模拟典型的cpu密集型应用程序，这些应用程序在一般和科学计算中都很常见(例如天气预报、搜索算法、音频/视频处理等)。基于示例应用的结论具有通用性。

5.2 工作负载生成

本工作中考虑了两种不同的工作负载，即随机存取和美国国家航空航天局(NASA)数据集。它们在下文中有描述。

5.2.1随机访问

如图算法2所示，Random Access的设计是为了生成随机工作负载进行优化实验。Sort和Eigen任务分别以0.9和0.1的概率生成，以模拟大多数成本低的请求在边缘处理，而成本高的任务在云中完成。通过定期使用3种不同的工作负载模式(即轻、中、重)访问应用程序，自动缩放器有望覆盖实际使用中可能出现的大多数情况。

5.2.2 NASA数据集

NASA数据集用于模拟真实世界的访问[10]，用于评估实验。所有的访问记录都是由NASA肯尼迪航天中心的WWW服务器收集的，每个日志都包含其访问时间戳。通过累积每分钟的访问请求来预处理原始日志文件，并使用聚合的日志数量向应用程序发出请求。包含2个月记录的数据集的所有请求的综合实验集将非常耗时。

在这项工作中，从数据集中选择2天的子集进行实验。同时，将请求数调整到适当的规模，使峰值工作负载不超过实验边缘环境的资源限制。

5.3 Experiments for optimization

对PPA的三个超参数进行了优化，包括工作量预测模型、更新策略和关键指标。优化问题如式2所示。其中，𝛾为应用程序的响应时间，𝑊为浪费资源的总和，𝑀为预测模型，𝑈为模型更新策略，𝐾为关键指标Key metric，A为目标应用, Rp是分配给pod p的资源, 𝑃𝑛是在节点𝑛上托管的所有pod的集合, 𝑁是所有节点的集合。在这里，目标应用程序A是固定的，并且要优化𝑀、𝑈、𝐾以最小化𝛾和𝑊。


5.3.1 预测模型优化

针对实例应用，对不同的指标预测模型进行了比较和优化，并以自回归移动平均(ARMA)模型和长短期记忆(LSTM)模型为典型模型。

实验采用ARMA(1,1,1)，表示其移动平均部分阶数和自回归部分阶数均设为1，模型时间窗为1。ARMA模型的超参数是根据收集到的数据预先选择的。

我们使用的LSTM模型由一个50个神经元的LSTM层和一个由ReLu函数激活的全连接层[2]组成。输出层的形状被设置为5，以适应所有未来的指标。LSTM模型的损失函数为均方误差(Mean Squared Error, MSE)，优化器为Adam optimizer[7]。

这两个模型都使用在单个不受约束的节点上运行示例应用程序10个小时并使用Random Access生成的工作负载收集的数据进行预训练。使用这两个模型对示例应用程序进行了200分钟的自动伸缩，并比较了CPU利用率的预测值和实际值。

5.3.2 优化Update策略

如4.2.3节所介绍的，提出并比较了3种不同的Updater方法。在本实验中，预训练的LSTM模型作为种子模型，并将CPU利用率定义为关键指标。为了缩短实验所需的时间，将模型更新循环的时间间隔设置为1小时。示例应用程序运行200分钟，每个PPA使用不同的更新策略自动缩放，并收集CPU利用率的预测值和实际值。

5.3.3 关键指标的优化

在本实验中，将所有pod的请求率或CPU利用率之和作为关键指标进行比较。同样，示例应用程序运行200分钟，每个PPA使用Random Access生成的工作负载自动缩放。由于关键指标的差异，不可能将两个ppa与预测指标进行定量比较。相反，将所有请求的响应时间和由两个ppa自动缩放的系统空闲资源进行比较，以量化两个ppa的性能。

5.4 评价实验

利用最优超参数对优化后的PPA进行真实场景评价。PPA通过最佳配置自动缩放，应用程序可以使用缩放后的NASA数据集的工作负载运行48小时。通过比较请求的响应时间和空闲资源，量化性能。应用程序的另一次运行是使用完全相同的配置进行的，这些配置由Horizontal Pod Autoscaler自动缩放，作为PPA的基线.

6结果与讨论

结果将在下文中提出和讨论。首先给出超参数优化结果，然后在已部署的场景中进行评估。

6.1预测模型优化

两种不同模型的PPA结果如图4所示。观察结果表明，两个模型都能够捕捉到CPU利用率的趋势，而ARMA模型在拟合方面稍好一些。但从数量上看，LSTM模型预测的MSE为53240.972,ARMA模型预测的MSE为96867.631，后者要大得多。这表明，在预测CPU利用率时，ARMA模型提供了显著的变化，而LSTM模型能够产生相对更准确的预测。可以得出结论，LSTM在预测示例应用程序的CPU利用率方面优于ARMA模型。


6.2优化升级策略

图5对具有不同策略的三个ppa进行了比较。采用策略1、策略2和策略3的PPA产生的利用率预测MSE分别为64769.882、42180.437和30994.449，表明策略3在提出的模型更新策略中表现最好。我们得出的结论是，策略3在每个模型更新循环中使用新收集的指标重新训练模型，为示例应用程序提供了优于其他策略的最佳性能。


6.3关键指标的优化

在示例应用程序上比较PPA的两个关键指标，即请求率和CPU利用率。请求的响应时间和空闲资源用于定量地比较ppa的性能。图6显示了使用不同关键指标自动缩放的应用程序上请求的响应时间分布。两个分布的巨大重叠表明两个运行的响应时间非常接近。根据CPU利用率自动缩放的应用程序的平均响应时间为0.5156秒，标准偏差(STD)为0.0421，而根据请求率自动缩放的应用程序的平均响应时间为0.5157秒，标准偏差为0.420。由于时间分布没有显著差异，因此可以得出结论，在响应时间方面自动扩展示例应用程序时，两个关键指标是等效的。(这个图里面的黄线和蓝线估计是基本上重叠了)

系统在𝑡时刻的相对空闲资源(RIR_t)(定义为公式3)用于定量地比较两个自动缩放器。具有两个关键指标的ppa的rir如图7所示。CPU请求率的平均RIR为0.317，标准差为0.161;CPU利用率的平均RIR为0.251，标准差为0.092。可以得出结论，以CPU利用率为关键指标的PPA效率更高，浪费的资源更少。此外，RIR的标准偏差较低表明，以CPU利用率为关键指标进行自动缩放时，系统更加稳定。


尽管具有不同关键指标的两个PPA为请求提供接近的响应时间，但是具有CPU利用率的PPA更节能，系统也更稳定。因此，CPU利用率是示例应用程序的最佳关键指标。

6.4实验评价结果

根据最优模型、关键指标和更新策略，对拟议的PPA进行5.4节所述的评估，并将PPA和HPA的性能与请求响应时间和空闲资源进行定量比较。

6.4.1响应时间。

图8显示了由PPA和HPA自动缩放的Sort任务的响应时间分布。HPA自动缩放的应用程序对边缘任务的平均响应时间为0.592秒，标准偏差(STD)为0.067;PPA自动缩放的应用程序的平均响应时间为0.508秒，标准偏差(STD)为0.038。PPA提供的响应时间明显小于HPA, p值小于10−3。此外，PPA提供的分布具有较小的标准差。可以看出，通过PPA自动伸缩的应用程序提供的边缘服务延迟更小，边缘系统更稳定。在特征任务中也观察到类似的结果。HPA和PPA提供的云任务的两个响应时间分布如图9所示。HPA自动缩放的应用程序对边缘任务的平均响应时间为13.382秒，标准差为1.606;PPA自动缩放的应用程序的平均响应时间为13.646秒，标准差为1.576。HPA提供的响应时间显著大于PPA，且p值小于10−3，对于Sort任务的标准差也是如此。因此，与HPA相比，PPA自动扩展的云服务具有更好的性能。

因此，可以得出结论，在边缘计算应用中，所提出的主动Pod Autoscaler在云服务和边缘服务方面都优于默认HPA，具有更低的延迟和更高的访问稳定性。



6.4.2空闲资源

图10显示了由PPA和HPA自动缩放的边缘工作节点的相对空闲CPU使用情况。HPA自动缩放的边缘工作线程平均相对空闲CPU为0.3209，标准差为0.1079;PPA自动缩放的边缘工作线程平均相对空闲CPU为0.2988,STD为0.1026。虽然两种自动缩放器的结果在视觉上是相似的，但PPA提供的相对空闲CPU明显小于PPA, p值小于10−3。因此，可以得出结论，PPA自动伸缩的应用程序的边缘工作节点比HPA自动伸缩的应用程序更有效地利用CPU资源。HPA和PPA自动伸缩的云工作节点的相对空闲CPU使用情况如图9所示。HPA自动伸缩的云工作者的平均相对空闲CPU为0.3373，标准差为0.1572;PPA自动伸缩的应用程序的平均相对空闲CPU为0.3098,STD为0.1453。HPA提供的相对空闲CPU明显大于PPA, p值小于10−3。因此，在云节点上，PPA自动伸缩的应用程序比HPA自动伸缩的应用程序浪费的CPU资源更少。综上所述，在请求响应时间和空闲资源方面，本文提出的Proactive Pod Autoscaler都优于默认的Horizontal Pod Autoscaler，为边缘计算应用带来更好的性能，获得更多的访问稳定性，并且浪费更少的资源。


7结论与未来工作

在这项工作中，我们提出了一种基于Kubernetes的边缘计算应用的主动pod自动缩放器(PPA)。PPA能够使用时间序列预测方法提前预测应用程序的到达工作负载，并根据需要伸缩应用程序。以cpu密集型应用程序为例，针对Kubernetes中的内置自动缩放器HPA对自动缩放器进行了优化和评估。可以得出结论，PPA能够更有效地利用资源，并为请求提供更快的响应时间。此外，所提出的自动缩放器具有高度的灵活性和可定制性，因此用户可以调整指标、预测模型和缩放策略，以更好地满足自己应用程序的需求。除了支持多个指标外，用户还可以定义自己的特定于应用程序的指标，以更好地扩展应用程序。这使得ppa能够适应各种类型的应用程序，例如实际使用中的数据密集型应用程序、IO密集型应用程序。拟议的PPA并不完美，因为它需要开发人员手动优化关键指标、模型和策略。在未来的工作中，可以通过自动化超参数优化来改进PPA。一种可能的方法可能涉及使用一组可能的指标运行应用程序，PPA的指定模块使用不同的方法自动建模收集的运行数据。然后可以使用验证技术从候选模型中选择最佳模型。通过这种方式，自动优化的PPA将更容易被开发人员部署和使用。

PBScaler:一个基于微服务的应用程序的瓶颈感知自动伸缩框架

Introduction

随着微服务架构的推进，越来越多的云应用从单片架构向微服务架构迁移[1]、[2]、[3]、[4]、[5]、[6]。这种新架构通过将一个单片应用程序分解为多个微服务，通过HTTP或RPC协议相互通信来减少应用程序耦合[7]。此外，每个微服务都可以由独立的团队独立开发、部署和扩展，从而实现快速的应用程序开发和迭代。然而，外部工作负载的不可预测性和微服务之间交互的复杂性会导致性能下降[8]，[9]，[10]。云提供商必须准备过多的资源来满足应用程序所有者的服务水平目标(service level objective, SLO)，这通常会造成不必要的资源浪费[11]，[12]。因此，满足SLO和最小化资源消耗之间的不平衡成为微服务中资源管理遇到的主要挑战。

微服务自动伸缩指的是根据工作负载变化弹性分配资源的能力[13]。通过利用微服务的弹性特性，自动扩展可以缓解资源成本和性能之间的冲突。然而，微服务的自动伸缩难以在短时间内准确地伸缩性能瓶颈(PB)。由于微服务之间通信的复杂性，PB的性能下降可能会通过消息传递传播给其他微服务[2]，导致同时出现大量异常微服务。我们通过在Google开发的开源微服务应用Online Boutique 1中向特定的微服务注入突发工作负载来证明这一点。图1显示，PB推荐中的性能下降会蔓延到上游微服务，如Checkout和Frontend。为了进一步验证准确扩展PB的重要性，我们进行了压力测试，并分别扩展了不同的微服务。如图2所示，微服务(前端)扩容异常并不能缓解SLO违规。然而，当我们确定并扩展PB推荐时，微服务应用程序的性能得到了改善。不幸的是，定位PBs通常很耗时，偶尔也会出错[14]。

近年来，已经提出了几种方法来在自动扩展之前识别关键的微服务。例如，Kubernetes 2的默认自动缩放器根据计算资源的静态阈值过滤微服务进行直接缩放。Yu等[15]通过计算服务功率来定义弹性缩放的边界，服务功率是第50百分位响应时间(P50)与第90百分位响应时间(P90)之比。此外，Qiu等人[4]引入了一种基于支持向量机的方法，通过分析各种尾部延迟的比率来提取关键路径。尽管这些研究缩小了自动扩展的范围，但它们仍然考虑了可能影响扩展策略的非瓶颈微服务，特别是当应用程序中大量微服务同时异常时。因此，在自动扩展之前，迫切需要精确地定位瓶颈微服务。为了平衡资源消耗和性能，现有的工作采用在线优化算法来寻找接近最优的自动缩放策略。然而，由于自动扩展的可能策略范围很广，这些方法需要大量的尝试，这对于在线应用程序来说是有问题的。例如，Train Ticket3是最大的开源微服务应用程序，由近40个微服务组成。假设每个微服务最多可以有15个副本，确定此应用程序的最佳分配策略无疑是一个np难题，因为最多有1540个可扩展选项。此外，在线优化中反馈回路的持续时间过长，难以实现模型收敛。考虑由在线优化引起的性能下降的潜在风险也很重要。图3显示了突发工作负载对MicroScaler的副本波动和延迟波动的影响[15]，MicroScaler是一种在线自动扩展方法，采用在线贝叶斯优化来寻找总成本的全局最小值。由于在线优化导致频繁的在线尝试创建副本(图3a)，导致振荡和性能下降(图3b)。因此，我们受到启发，设计了一个离线优化过程，由模拟器的反馈推动。



本文介绍了PBScaler，这是一个横向自动扩展框架，旨在通过识别和解决瓶颈来防止基于微服务的应用程序的性能下降。与之前的工作[11]、[15]所做的针对所有异常微服务优化资源不同，我们提出了TopoRank，一种基于拓扑势理论(TPT)的随机游走算法，用于识别性能瓶颈(PBs)。通过考虑微服务依赖关系和潜在异常，TopoRank提高了瓶颈定位的准确性和可解释性。在通过TopoRank识别PBs后，PBScaler进一步采用遗传算法来寻找接近最优的策略。为了避免过度优化引起的应用振荡，该过程离线进行，并由SLO违例预测器指导，该预测器模拟在线应用并向缩放策略提供反馈。本文的主要贡献总结如下:

•我们提出PBScaler，这是一个瓶颈感知自动伸缩框架，旨在防止基于微服务的应用程序中的性能下降。通过精确定位瓶颈，PBScaler可以减少不必要的扩展并加快优化过程。

•我们采用基于遗传算法的离线优化过程来优化资源消耗，同时避免违反SLO。此过程由SLO违规预测器指导，旨在在不中断在线应用程序的情况下在资源消耗和性能之间取得平衡。

•我们在Kubernetes系统中设计和实现PBScaler。为了评估其有效性，我们在两个在线环境中运行的广泛使用的微服务系统上进行了大量的真实世界和模拟工作负载注入实验。实验结果表明，PBScaler比几种最先进的弹性缩放方法性能更好。本文的其余部分组织如下。在第2节中，我们将讨论微服务的瓶颈分析和自动扩展的相关工作。在第3节中，我们详细描述了整个系统。在第4节中，我们给出了评估和实验结果。第五部分总结了我们的工作，并讨论了未来的研究方向。

2 Related work

随着云计算的发展，学术界和工业界提出了许多云资源(如虚拟机或容器)的自扩展方法[16]、[17]、[18]、[19]。然而，由于微服务之间错综复杂的依赖关系，微服务的自动伸缩可能要复杂得多。

2.1 Bottleneck Analysis

近年来，已经开发了许多用于微服务场景瓶颈分析的方法，其中大多数依赖于三种类型的数据:logs、Trace和metrics。

1)日志。Jia等[20]和Nandi等[21]首先从正常状态的日志中提取模板和流程，与目标日志进行匹配，过滤掉异常日志。

2)痕迹。Trace是一个基于事件跟踪的记录，它再现微服务之间的请求过程。一些研究[22]，[23]，[24]，[25]已经引入使用轨迹来确定瓶颈。Yu等人[22]、[23]结合频谱分析和PageRank算法在trace构建的依赖图上定位瓶颈，Mi等人[24]提出了无监督机器学习原型，学习微服务的模式，过滤异常微服务。然而，使用跟踪可能会干扰代码，并且要求操作人员对微服务的结构有深入的了解。

3)指标。一些方法[2]，[26]，[27]利用图随机游走算法来模拟异常的传播过程，然后通过集成度量的统计特征和微服务之间的依赖关系来找到瓶颈。此外，CauseInfer[14]和MicroCause[28]等方法侧重于用因果推理构建指标因果图，这通常涉及指标之间隐藏的间接关系。

由于在监控指标时很少修改工作流代码，因此为微服务收集指标通常比使用跟踪更便宜。此外，使用度量作为主要监控数据可以降低集成瓶颈分析和自动伸缩的成本，因为度量在后一种场景中被广泛使用。尽管这些方法具有优势，但大多数方法在选择异常回溯的起始点时没有偏好。相比之下，我们的方法从具有更大异常潜力的微服务开始随机漫步，加快了收敛速度并提高了瓶颈定位精度。

2.2 Autoscaling for microservices

现有的微服务自动伸缩方法可以分为五类。

**1)基于规则的启发式方法 **KHPA、Libra[29]、KHPA- a[30]和PEMA[31]基于资源阈值和特定规则管理微服务副本的数量。然而，由于不同的微服务对特定资源的敏感性不同，因此需要专业知识来支持这些不同微服务的自动伸缩。

2)基于模型的方法 可以对微服务进行建模，以预测它们在特定配置和工作负载下的状态。排队论[32]、[33]和图神经网络(GNN)[12]常用来构建微服务的性能预测模型。

3)基于控制理论的方法 [11]，[32] 使用控制理论，SHOWAR[11]动态调整微服务副本，以纠正监控指标和阈值之间的错误。

4)基于优化的方法 这些方法[15]、[34]在给定当前资源和工作负载的情况下，进行了大量的尝试来寻找最优策略。这些方法的关键在于缩小决策范围，加快决策进程。

5)基于强化学习的方法 强化学习(RL)已广泛应用于微服务的资源管理。MIRAS[35]采用基于模型的RL方法进行决策，避免了真实环境的高采样复杂度。FIRM[4]利用支持向量机(SVM)识别微服务中的关键路径，并利用深度确定性策略梯度(DDPG)算法为路径上的微服务制定混合扩展策略。基于强化学习的方法需要在探索过程中不断与环境进行交互，并且无法适应动态微服务架构。

总之，尽管前面提到的自动缩放技术有各自的优势，但它们很少关注性能瓶颈。为非瓶颈微服务消耗计算机资源将不可避免地增加扩展成本和延长决策时间。另一方面，我们的方法侧重于定位性能瓶颈。

3.System Design

我们提出了PBScaler，一个以PB为中心的自动缩放控制器，用于定位PBs并优化它们的副本。如图4所示，PBScaler包括三个组件:

1)度量收集器Metric Collector:为了提供对应用程序状态的实时洞察，我们设计了一个度量收集器，它以固定的间隔从Prometheus4捕获并集成监视度量。

2)性能瓶颈分析Performance Bottleneck Analysis:在度量收集器的帮助下，该组件执行SLO违规检测和冗余检查，以识别异常行为的微服务。接下来，瓶颈定位过程将被触发以精确定位异常微服务中的PBs。

3)缩放决策Scaling Decision:该组件旨在使用进化算法确定PBs的最佳副本数量。最后，PBScaler生成具有优化策略的配置文件，并将其提交给kubernetes-client5, kubernetes-client5调节微服务的副本计数。

3.1 Metric Collector

自动伸缩系统依赖于对指标的实时访问，例如内存使用数据、系统负载和尾部延迟，以确定是否应该执行弹性伸缩以及应该在微服务应用程序中分配多少资源。与需要深入了解程序和代码注入的基于跟踪的监视器不同[7]，Metric Collector根据服务网格报告指标，以最大限度地减少对业务流的中断。如表1所示，PBScaler使用Prometheus和kube-state-metrics来收集和分类这些指标，包括响应延迟、微服务之间的调用关系、资源消耗和微服务工作负载。



例如，容器cpu使用秒总数是Prometheus中的一个标签，它记录了容器级别的中央处理单元(Central Processing Unit, cpu)使用情况。我们将Prometheus的监视间隔设置为5秒，并将收集到的指标数据存储在时间序列数据库中。每个微服务的P90尾部延迟被收集并用于表示应用程序的性能。调用关系暗示了微服务之间的关联，可用于构建微服务关联图。

服务网格Service Mesh

服务网格是一种基础设施，它使开发人员能够在不需要额外代码的情况下向云应用程序添加高级功能，如可观察性和流量管理。一个流行的开源服务网格实现是Istio7，旨在与Kubernetes无缝集成。当一个pod在Kubernetes中启动时，Istio在pod中启动一个特使代理来拦截网络流量，从而实现工作负载平衡和监控。

3.2 Performance Bottleneck Analysis

性能瓶颈分析(PBA)是一个旨在发现微服务应用程序中性能下降和资源浪费的过程，以推断当前问题的PBs。如第1节所述，通过准确定位这些瓶颈，PBA可以提高自动扩展的性能并减少过度的资源消耗。算法1描述了PBScaler中的PBA过程。


3.2.1 SLO Violation Detection

为了检测微服务中的异常，PBScaler使用服务水平目标(slo)与特定指标进行比较。如果微服务有大量的SLO违规，即性能下降，则被认为是异常的。如[14]、[27]所述，检测违反SLO是触发瓶颈定位的关键步骤。可以利用Metric Collector收集的调用关系来构建微服务关联图Gc。PBScaler每15秒检查Gc中所有调用边的P90尾部延迟，以及时检测性能下降。如果调用的尾部延迟超过预定的阈值(如SLO)，则调用的被调用微服务将被添加到异常微服务集中，并且将激活瓶颈本地化过程。为了考虑微服务延迟中偶尔出现的噪声，阈值设置为slox (1 + α/2)，其中α用于调整对噪声的容忍度

3.2.2 Redundancy Checking

在没有性能异常的情况下，一些微服务可能会被分配比所需更多的资源。然而，仅仅通过度量来识别这样的情况是很困难的，这可能会浪费有限的硬件资源。为了避免这种情况，有必要确定哪些微服务分配了多余的资源。PBScaler使用微服务每秒的工作负载变化率来确定资源是否冗余。

此策略比仅依赖资源消耗更有效，因为不同的微服务对异构资源的敏感性可能不同。冗余检查背后的主要思想是采用假设检验来检测微服务当前的工作负载wi c是否显著低于其过去的工作负载(表示为wi p)。显著程度通过参数βt来调整，假设检验可以表示为:


为了执行假设检验，我们首先从Metric Collector获取目标微服务的当前和历史工作负载。然后我们使用单侧检验来计算p-value P。如果P不超过置信水平cl(默认设置为0.05)，我们拒绝零假设H0，并认为微服务i具有冗余资源。


3.2.3 Bottleneck Localisation

由于微服务应用程序中复杂的交互[36]，并不是每个异常的微服务都需要扩展。例如，图5说明了瓶颈微服务(例如，Product)的性能下降如何沿着调用链传播到它的上游微服务(例如，recommendation, Frontend和Checkout)，即使上游微服务没有过载。因此，只有瓶颈微服务必须被扩展，而其他异常微服务只是被牵连。为了精确定位瓶颈微服务，我们引入了异常潜力的概念，它聚集了给定位置上所有微服务的异常影响。由于PB被许多受其影响的异常微服务所包围，因此PB的异常潜力通常很高。我们设计了一种新的瓶颈定位算法TopoRank，该算法在随机行走中引入拓扑势理论(TPT)来计算所有异常微服务的得分，并最终输出一个排名列表(rl)。在rl中得分最高的微服务可以被识别为PBs。


TPT源于物理学中“场”的概念，在各种著作中被广泛应用[37]，[38]来衡量复杂网络中节点之间的相互影响。由于微服务关联图也可以被视为一个复杂的网络，我们使用TPT来评估微服务的异常潜力。具体来说，我们已经观察到，在微服务关联图Gc中，离PBs更近的微服务，即那些跳数较少的微服务，更有可能出现异常，因为它们经常频繁地直接或间接调用PBs。基于这一观察，我们使用TPT评估微服务的异常潜力。为此，我们首先通过识别异常微服务及其在Gc中的调用关系来提取异常子图Ga。然后，我们使用TPT计算异常子图Ga中微服务vi的拓扑势。


N为vi的上游微服务数，mj为vj的异常程度。PBScaler将异常程度定义为微服务在一个时间窗口内违反SLO的次数。dji表示从vj到vi所需的最小跳数。我们使用影响因子σ来控制微服务的影响范围。

然而，具有高拓扑潜在值的微服务不一定是PBs，因为异常通常沿着微服务相关图传播。因此，单纯依靠TPT诊断PBs是不够的。为了解决这个问题，PBScaler结合了个性化PageRank算法[39]来逆转异常子图Ga上的异常传播并定位PBs。设P为Ga与Pi的转移矩阵，j为异常从vi跟踪到其下游节点vj的概率。给定输出度为d的vi，标准个性化PageRank算法将Pi,j集合为:


这意味着该算法不会偏向于任何下游微服务。然而，这个定义没有考虑下游微服务和当前微服务异常之间的关联。因此，PBScaler通过更多地关注与上游响应时间更相关的下游微服务来调整计算。对于每个微服务vi, PBScaler收集尾部延迟序列(li)和一组度量数组Mi = {m1, m2，···，mk}，其中mk可以被视为给定时间窗口内度量(例如，内存使用)的波动数组。PBScaler定义Pi,j取决于Mj中li与度量数组之间的Pearson相关系数的最大值:


个性化PageRank算法通过在有向图上随机行走来确定每个节点的受欢迎程度。然而，一些节点可能永远不会指向其他节点，导致所有节点的分数在多次迭代后趋于零。为了避免落入这个“陷阱”，应用了一个阻尼因子δ，它允许算法根据预定义的规则从这些节点跳出来。通常δ设为0.15。个性化PageRank表示如下:


其中v表示每个微服务节点被诊断为PB的概率。偏好向量u作为个性化规则，引导算法跳出陷阱。u的值由每个节点的异常势决定。异常潜力较大的节点优先作为算法的起始点。第k次迭代的方程可以表示为:


经过多轮迭代，v逐渐收敛。PBScaler然后对最终结果进行排序并生成排名列表。排名列表得分最高的前k个微服务可以被识别为PBs。TopoRank的整个过程描述为算法2。

3.3 Scaling Decision

给定性能瓶颈分析确定的PBs，将对PBs的副本进行缩放，以最小化应用程序的资源消耗，同时确保微服务的端到端延迟符合SLO。尽管大量的副本可以缓解性能下降问题，但它们也会消耗大量的资源。因此，必须在性能保证和资源消耗之间保持平衡。缩放决策的过程将被建模为一个约束优化问题，以实现这种平衡。

3.3.1 Constrained Optimation Model

我们场景中的自动缩放优化试图确定一个分配模式，该模式为每个PB分配可变数量的副本。给定n个需要缩放的PBs，我们将策略定义为集合X = {x1, x2，···，xn}，其中xi表示分配给pbi的副本数量。在优化之前，PBs的初始副本数量可以表示为C = {c1, c2，···，cn}。应该注意的是，PBScaler中的副本约束应该分别为按比例缩小和按比例扩大的流程定义。在扩展过程中，我们对PBs的副本数量进行了如下限制:


其中c^max表示给定有限的服务器资源，微服务可以扩展到的最大副本数量。在缩小过程中，副本数量的约束可以表示为:


在Eq.(8,就是上面这个公示)中，γ(默认值为2)表示复制减少的最大数量。这个限制是合理的，因为正如在实验中观察到的那样，大幅减少微服务副本的数量可能会导致短暂的延迟峰值。

缩放决策的目标是尽量减少应用程序的资源消耗，同时保持其性能。应用程序性能通常用用户更关心的SLO违规来表示。因此，应用程序性能奖励可以细化为:


在优化过程中，应用程序的资源消耗(如CPU和内存使用)是不可预测的。为了保守地估计资源消耗，我们考虑PB副本与可分配副本的最大数量的比率，而不是计算CPU和内存的成本。我们将资源奖励计算为:


我们的目标是在保证性能的同时尽量减少资源消耗。我们利用加权线性组合(WLC)方法来平衡这两个目标。最终优化目标定义为:


式中λ∈[0,1]。我们将λ设置为参数，以平衡应用程序性能和资源消耗。

3.3.2 SLO Violation Predictor

为了计算性能奖励R1，需要评估策略是否会导致在线应用程序违反SLO。一种简单的方法是直接在在线申请中执行候选策略，并等待监控系统的反馈。然而，在线应用程序中频繁缩放引起的振荡是不可避免的。另一种方法是使用历史度量数据训练评估模型，该模型可以模拟在线应用的反馈。在不与在线应用程序交互的情况下，该模型根据应用程序的当前状态预测应用程序的性能。

我们使用向量r来表示执行扩展策略x后每个微服务的副本数量。w是表示每个微服务当前工作负载的向量。由于瓶颈感知优化的时间成本较低，我们可以合理地假设w在此期间不会发生显著变化(参见4.2节)。给定由工作负载w和所有微服务副本r表示的应用状态，一个SLO违例预测器可以设计为:


其中ψ是一个二元分类模型。选择合适的分类模型的细节将在4.3节中讨论。用于训练的历史度量数据可以使用经典缩放方法(默认是Kubernetes自动缩放器)或随机方法生成。我们在3个节点(共44个CPU核和220gb RAM)上部署了一个开源微服务系统，并进行了弹性扩展。普罗米修斯以固定的时间间隔收集每个微服务的工作负载和P90尾部延迟。通过比较前端微服务的尾部延迟和SLO，可以很容易地标记每个时间间隔的监控数据。


Section 4.3。用于训练的历史度量数据可以使用经典缩放方法(默认是Kubernetes自动缩放器)或随机方法生成。我们在3个节点(共44个CPU核和220gb RAM)上部署了一个开源微服务系统，并进行了弹性扩展。普罗米修斯以固定的时间间隔收集每个微服务的工作负载和P90尾部延迟。通过比较前端微服务的尾部延迟和SLO，可以很容易地标记每个时间间隔的监控数据。

3.3.3 Autoscaling Optimisation

如第3.3.1节所述，性能和资源消耗之间的权衡可以建模为约束优化问题。为了找到接近最优的策略，PBScaler使用遗传算法(GA)来生成和优化扩展策略，以减少资源消耗，同时满足SLO要求。遗传算法通过模拟进化中的自然选择，在淘汰劣等子代的同时提高优等子代。首先，遗传算法执行随机搜索来初始化策略空间中的染色体种群，每条染色体表示优化问题的潜在策略。接下来，在每次迭代中，将选择具有高适应度的精英染色体(称为精英)进行交叉或突变以产生下一代。

我们场景中的自动缩放优化旨在确定一种缩放策略，该策略为每个PB分配可变数量的副本。自缩放优化过程如图6所示。一开始，PBScaler获得每个微服务当前的副本数量r和工作负载w。在性能瓶颈分析之后，PBScaler从r中识别PBs，并将它们过滤出来，得到r ‘。然后，决策者生成PBs策略的总体。由于要扩展的微服务数量会影响优化算法的速度和效果(第4.3节)，PBScaler假设只有PBs需要进行弹性扩展。换句话说，r ‘中的副本数量将保持不变。SLO违例预测器负责评估生成的策略。需要注意的是，该策略与r ‘合并，并与w一起输入到SLO违规预测器中。通过遗传算法选择优策略Xbest，并与r ‘合并，生成最终决策。


在优化阶段，决策者使用遗传算法生成并改进PB的缩放策略，如算法3所述。在每个PB的策略范围内随机生成一个种群(第1行)后，Decision Maker根据Eq.(11)估计每个策略的适应度，并存储精英(第2-3行)。在每次迭代中，遗传算法使用基于锦标赛的选择算子来挑选优秀的亲本(第6行)。通过使用两个点交叉算子和双染色体突变算子，通过重组和突变(第7-8行)产生新的后代。通过模拟自然选择，新的后代和亲本精英形成一个新的种群，进入下一个迭代(第9行)。当遗传算法达到指定的迭代次数时，Decision Maker返回适应度最高的缩放决策Xbest。

4 Evaluation

在本节中，我们详细介绍了自动缩放的实验场景，包括PBScaler与学术界和工业界几种最先进的自动缩放算法的比较。

4.1 Experimental Setup

4.1.1 Microserice Platform

实验在我们的私有云集群中进行，该集群由三台物理计算机(一个主节点和两个工作节点)组成，共有44个Intel 2.40 GHz CPU内核和220gb RAM。为了评估自动扩展，我们选择了两个开源微服务应用程序作为基准:a)在线精品8，一个由谷歌开发的基于web的电子商务演示应用程序。该系统通过10个无状态微服务和Redis缓存的协作，实现了浏览产品、将商品添加到购物车和支付处理等基本功能。b) Train Ticket9:复旦大学开发的大型开源微服务系统。Train Ticket拥有40多个微服务，并使用MongoDB和MySQL进行数据存储，可以满足各种工作流程，如在线门票浏览，预订和购买。由于集群资源的限制，我们将每个微服务限制为不超过8个副本。源代码可在Github上获得.

4.1.2 Workload

我们评估了PBScaler在各种流量场景下的有效性，使用了2015年3月16日Wiki-Pageviews[40]的真实维基百科工作负载，以及受Abdullah等人[41]的实验启发的五种模拟工作负载(EW1 ~ EW5)。我们将实际工作负载压缩到一个小时，并将其扩展到适合我们集群的级别。五个模拟工作负载表现出不同的模式，例如单峰、多峰、上升和下降，并且持续时间限制为20分钟。图7描述了这些工作负载的波动情况。

4.1.3 Baseline Metrics

我们将PBScaler与学术界和工业界的几种最先进的微服务自动扩展方法进行比较，这些方法从静态阈值、控制理论和黑盒优化的角度执行微服务的动态水平扩展。

Kubernetes水平Pod自动缩放(KHPA):这是Kubernetes默认的水平缩放方案。通过为特定的资源R定制阈值T (CPU使用率为默认值)，并从微服务的所有副本中聚合资源使用URi, KHPA将副本的目标数量定义为


MicroScaler[15]:这是一个自动扩展工具，它使用黑盒优化算法来确定微服务的最佳副本数量。MicroScaler计算微服务的P90/P50进行分类，然后执行贝叶斯优化的四次迭代来做出扩展决策。

SHOWAR[11]:它是一种混合自缩放技术。我们在SHOWAR中再现了水平缩放部分，它使用PID控制理论使观察到的度量逐渐接近用户指定的阈值。在我们的实现中，我们用更常见的P90延迟替换了运行队列延迟，因为前者需要额外的eBPF工具。

4.1.4 Experimental Parameters and Evaluation Criteria

在我们的实验中，我们将普罗米修斯的收集间隔固定为5秒。随着实验时间和工作负载的增加，MongoDB等有状态微服务所需的数据量也会增加。最终，数据量将超过可用内存，从而需要使用磁盘存储。这种转换可能导致无法通过自动缩放来补救的性能下降。因此，我们将工作负载测试限制为无状态跟踪。在线精品店和火车票的SLO值分别设置为500毫秒和200毫秒。在SLO违例检测和冗余检查模块中，PBScaler首先将动作边界α设置为0.2，以减少噪声干扰。然后，我们根据经验将显著度β设置为0.9，以控制触发扩展的工作负载水平。对于瓶颈定位，将拓扑势的影响因子σ设为1，将rl中得分最高的top-k (k =2)个微服务视为PBs。

我们选择了SLO违规率、资源消耗和响应时间来评估自缩放方法的性能。如果自动缩放方法可以减少响应时间、SLO违规率和资源消耗，则认为它更有效。我们将SLO违例率定义为端到端P90尾部延迟超过SLO的百分比。资源消耗按照[42]给出的方法计算，其中CPU价格为0.00003334$ (vCPU/s)，内存价格为0.00001389$ (G/s)。总资源消耗由内存成本和CPU成本相加得到。



4.2 Performance Evaluation

表2比较了具有不同工作负载的两个微服务应用程序中四种自动伸缩方法的SLO违反率和资源成本。None方法用作引用，不执行自动缩放操作。其结果以灰色表示，并被排除在比较之外。


一般来说，PBScaler在减少两个微服务系统中六个工作负载下的SLO违规和最小化资源开销方面优于其他竞争方法。其中，PBScaler在火车票中的SLO违规率比基线方法平均降低4.96%，资源成本平均降低0.24美元。结果表明，PBScaler可以快速、精确地对大规模微服务系统中的瓶颈微服务进行弹性扩展，从而减少了SLO违规，节省了资源。对于Online Boutique中的6个工作负载，PBScaler还在其中4个模拟工作负载中实现了最低的SLO违规，并在3个模拟工作负载中实现了最低的资源消耗。

图8描绘了六种工作负载下不同方法的延迟分布箱形图，探讨了每种方法对微服务系统性能的影响。可以看出，大多数自动缩放方法都可以保持延迟分布的中位数低于红色虚线(SLO)。但是，只有PBScaler进一步将第三个四分位数降低到所有工作负载的SLO以下。

为了评估使用PBScaler进行弹性缩放的时间成本，收集并计算了PBScaler中每个模块所需的平均时间。如表3所示，Online Boutique中所有PBScaler模块的总时间成本小于一个监控间隔(即5s)，而Train Ticket的相同度量小于两个监控间隔。由于PBA缩小了决策范围，当应用程序从Online Boutique切换到Train Ticket时，尽管微服务的数量增加了，但决策者的时间成本并没有增加太多(不超过6.6%)。然而，我们认识到随着微服务规模的增长，PBA的时间消耗会迅速增加，这将是我们未来的工作。



4.3 Effectiveness Analysis of Components

4.3.1 Performance Comparision of Bottleneck Localization

为了评估TopoRank算法是否能有效定位突发工作负载引起的PBs，我们通过Chaos Mesh将CPU过载、内存溢出和网络拥塞等异常注入到Online Boutique和Train Ticket中。这些异常通常是由高工作负载条件引起的。使用TopoRank算法分析度量并确定这些异常的性能瓶颈。然后将定位结果与micrororca[27]进行比较，micrororca是微服务根本原因分析的基线方法。AC@k测量前k个结果中实际PBs的精度，Avg@k是前k个结果的平均精度。这些指标的计算方法如下。A表示微服务的集合，RT@k表示排名列表中排名前k的微服务。


图9给出了TopoRank和MicroRCA在不同微服务应用中的AC@1和Avg@5值。结果表明，TopoRank在这两个指标上都优于MicroRCA。这主要是由于TopoRank在执行个性化PageRank时考虑了异常可能性和微服务依赖关系。

瓶颈定位的主要目的是缩小策略空间，加快最优策略的发现。我们在PBs和所有微服务上执行遗传算法迭代，以证明瓶颈定位对优化的影响。图10描述了微服务系统下的迭代过程，并表明随着人口(Pop)的增加，pb感知策略在适应度方面明显优于适用于所有微服务的方法。该策略可以在不到5次迭代中获得较好的适应度。相比之下，涉及所有微服务的方法需要更大的种群和更多的迭代才能达到相同的适应度水平。这是由于pb感知策略帮助遗传算法精确地缩小了优化范围，加速了优解的获取。

4.3.2 Effectiveness of the SLO Violation Predictor

SLO违例预测器的目标是直接预测优化策略的结果，而不是等待在线应用程序的反馈。我们根据每个微服务的副本数量和工作负载来确定是否会出现性能问题。为预测任务选择合适的二分类模型至关重要。以5秒的数据收集间隔，我们在我们的集群中收集了两个数据集，包括3.1k的火车票历史采样数据集(a)和1.5k的在线精品数据集(B)。为了对这两个数据集进行训练和测试，我们采用了四种经典的机器学习方法，包括支持向量机(SVM)、随机森林(Random Forest)、多层感知器(Multilayer Perceptron)和决策树(Decision Tree)。表4给出了四种模型对SLO违规预测的准确率和召回率。根据两个数据集的效果，我们最终选择随机森林作为SLO违例预测的主要算法。

为了证明SLO违例预测器可以替代来自真实环境的反馈，我们将使用SLO违例预测器的PBScaler与从在线系统收集反馈的MicroScaler进行了比较。我们将突发工作负载注入Online Boutique，并仅使一个微服务异常，以消除两种方法在瓶颈定位方面的差异。如图11所示，在预测器的引导下，PBScaler的决策尝试次数和频率远低于MicroScaler。减少集群中的在线尝试将明显降低振荡的风险。

5 Conclusion

本文介绍了PBScaler，一个瓶颈感知自动伸缩框架，旨在防止基于微服务的应用程序的性能退化。PBScaler使用服务网格技术收集应用程序的实时性能指标，并动态构建微服务之间的关联图。为了处理由外部动态工作负载和微服务之间复杂调用引起的微服务异常，PBScaler采用基于拓扑势理论的随机游动算法TopoRank来识别瓶颈微服务。此外，PBScaler采用离线进化算法，在SLO违规预测器的指导下优化缩放策略。实验结果表明，PBScaler可以在最小化资源消耗的同时实现较低的SLO违规。在未来，我们计划从以下两个方面改进我们的工作。首先，我们将探索在细粒度资源(例如，CPU和内存)管理中使用瓶颈感知的潜力。其次，我们将探讨如何规避自扩展中有状态微服务的干扰，因为有状态微服务的性能下降可能会破坏自扩展控制器。第三，提高大规模微服务系统性能瓶颈分析的效率。

LOTUS

概要：边缘计算系统通常面临资源分配效率低下的问题，导致不必要的等待时间和服务质量(QoS)的降低。本文提出了一种延迟优化混合自动缩放器(LOTUS)的体系结构来解决这个问题。这是通过实施深度学习模型来预测未来的工作负载，从而优化边缘的资源使用来实现的。LOTUS主动预测资源需求，并相应地对其进行扩展，以减少总体延迟，并从最终用户的角度改进QoS。为了证明准确的工作负载预测的重要性，我们将提出的系统架构设计为部署在具有有限可用资源的分布式Kubernetes集群中。通过动态预测传入工作负载的资源需求，LOTUS可以有效地分配资源，从而减少最终用户的往返时间。索引术语:边缘计算，自动缩放，深度学习，延迟优化

介绍

边缘计算是一种分布式计算，它使计算资源更接近网络的边缘，数据在那里生成和使用。边缘计算的目标是减少处理数据的延迟，从而提高最终用户的服务质量(QoS)。传统上，计算资源集中在大型数据中心，当需要长距离发送数据时，这可能导致高延迟。有了边缘计算，资源分布在一个大的地理区域，允许数据在更靠近它们产生的地方进行处理。

然而，边缘计算的分布式特性对有效的资源分配提出了挑战。与传统数据中心相比，边缘设备通常具有有限的资源，因此优化其使用以满足QoS要求至关重要。实现这一目标的一种方法是使用自动缩放技术，这是一个动态过程，使系统能够根据当前和预期的需求自适应提供资源。通过这样做，这些技术可以帮助确保有效的资源利用和最佳的QoS级别。由于Kubernetes的流行，Kubernetes Horizontal Pod Autoscaler (HPA)是Kubernetes集群中广泛使用的管理工作负载扩展的工具[1]。它使用一个预定义的比率来根据环境的变化计算所需的pod数量，如:

其中m_c是要优化的度量的当前值，m_d是期望值。度量可以是CPU利用率、内存利用率或自定义度量。

然而，这种方法并没有针对边缘计算的动态和资源受限环境进行优化。因此，它可能无法快速有效地实时响应变化。因为它只在发生更改之后才扩展资源，所以这种方法可能会增加总体往返时间(RTT)并影响性能，特别是在对时间敏感的应用程序中。

主动自缩放技术最近成为克服边缘被动自缩放器所面临的延迟问题的有希望的解决方案[2]。它们的目标是在工作负载生成之前对其进行预测，以便系统可以为预测的工作负载分配足够的资源。这种主动行为可以改善系统响应时间、资源利用率和应用程序性能。然而，尽管各种时间序列预测技术和机器学习算法已被用于在基于云的基础设施中实现这一目标，但缺乏对边缘计算系统的主动自动缩放技术的研究。现有文献(如[3]，[4])大多侧重于水平扩展，而不是采用混合方法，这阻碍了它们的潜在效益。

本文提出了一种创新的边缘主动混合自动缩放解决方案，称为延迟优化混合自动缩放(LOTUS)。我们的方法通过利用深度学习(DL)进行工作负载预测和资源分配，克服了现有自动缩放技术的局限性。它使用了一种混合缩放方法，结合了基于预测模型和算法权重的水平和垂直缩放技术。LOTUS的主要目标是通过主动预测工作负载并相应地分配资源来最小化延迟和缓解冷启动问题。通过这样做，LOTUS可以确保资源得到最佳配置，以处理预期的工作负载，并提高系统的性能。

LOTUS的体系结构采用了MAPE-K[10]循环，并且专门设计用于部署在分布式Kubernetes集群上，使其具有可伸缩性和灵活性，可以处理各种边缘计算资源配置。使用深度学习进行工作负载预测确保了我们方法的准确性和可靠性，使LOTUS能够准确预测工作负载变化并主动分配资源，从而在边缘实现高效和有效的自动扩展。具体而言，本文提出了以下重大贡献，这些贡献推动了边缘计算环境中自动缩放领域的发展:

1. 一种新型的主动混合自动缩放器，利用深度学习技术优化资源分配并减少延迟。

2. Kubernetes平台上自动缩放器的详细实现

3. 包括工作量建模和资源预测的定量评估。

本文的其余部分组织如下。在第二节中，我们回顾了相关文献，并强调了它们的局限性。第三部分概述了系统设计，概述了其关键组件和功能。接下来，在第四节中，我们描述了方法，并提供了有关系统设计和所采用算法的详细信息。在第五节中，我们介绍了实验评估的设置。接下来是第六节，在那里我们提出了结果。然后，我们在第七节中对我们的发现进行了深入分析。最后，在第八部分，我们对本文进行了总结，并对未来的工作进行了讨论。

二 相关工作

本节探讨了最近在边缘计算环境中提出的用于自动缩放的不同技术。表一也对它们进行了总结和比较。

自动扩展策略可以分为被动策略和主动策略。反应式（被动）自动缩放器只是对系统和环境的变化做出“反应”，并相应地调整资源。反应式自动缩放器最常见的用途是水平Pod自动缩放器(HPA)，这是因为它是Kubernetes提供的标准自动缩放器[1]。其他例子还包括[5]、[6]、[11]。这种响应式自动缩放技术对用户定义指标的变化做出反应，导致其明显的缺点。这个缺点是变更和行动之间的时间延迟导致系统整体效率降低。这是由于pod需要时间来初始化、重新分配或终止。由于网络流量的变化是对其作出反应，而不是准确预测，因此这种时间延迟是无法消除的[4]。

解决响应式自动缩放器所面临的时间延迟的一种常用技术是在流量在网络上生成之前预测它将是什么。这些技术的共同点是使用时间序列预测技术来预测工作负载，使用机器学习方法来估计所需的资源[8]，[12]。使用这些技术，网络可以在工作负载生成之前就拥有最佳的节点配置。如果实现正确，这些技术的好处是显而易见的，包括与响应式自动缩放相比，改进的资源利用率、更好的应用程序性能和成本优化。[8]提出的算法采用时间序列分析来预测容器的CPU使用情况，并主动调整容器的扩容。[13]中的工作提出了一种混合扩展策略，以在预测未来资源需求时平衡性能和成本。其他项目通过实施深度强化学习来推进自动扩展方法，例如[14]，旨在通过最小化响应时间和数据包丢失来最大化服务质量。

然而，上述方法的主要局限性在于它们是设计用于云计算平台，而不是边缘计算系统。尽管边缘计算基础设施的采用越来越多，但缺乏对边缘主动自缩放技术的研究，这可以显着提高此类系统的效率和可靠性。我们对文献的回顾表明，在边缘工作的自动缩放技术的发展仅由[4]，[9]，[15]解决。[15]提出了一种基于深度学习模型的自动扩展架构，用于水平扩展。[9]的工作使用延迟估计来垂直扩展应用程序容器。这两篇文章都只关注响应式扩展。[4]的工作使用主动Pod自动缩放器实现了时间序列预测，以提高资源利用率。结果显示效率得到了提高，但也存在一些缺点，比如预测不准确，需要考虑意外的工作负载。这些工作的另一个限制是它们只关注水平扩展，因此进一步这项工作的自然进展将是混合自动扩展的结合，以最大限度地利用可用资源。

表1是LOTUS与现有相关作品的比较。之前的大多数研究都强调横向自动扩展，并且仅限于基于虚拟机的云基础设施，同时使用一组受限的性能指标进行决策。相比之下，LOTUS为容器化应用程序提供了一种新的混合预测自动缩放模型，该模型依赖于一组固定的指标，并在边缘操作。它提供了一个独特的解决方案，结合了水平和垂直自动缩放技术的优点。

三 系统设计

本节深入研究LOTUS所采用的体系结构和算法的细节。

A. LOTUS Architecture

图1概述了组成LOTUS体系结构的组件及其相互连接。它还突出了系统内的数据流。LOTUS体系结构可以分为两个不同的部分。第一个是包含Kubernetes集群的边缘网络。我们故意混淆了这一部分，以解释实际环境中硬件配置的异构性质。第二部分是我们的自动缩放系统，它执行以下核心功能:

•请求处理。请求处理程序接收用于集群的传入请求，并随后传输它们。它包含度量评估器的细分。这个功能很简单:在发送请求之前，启动计时器，一旦接收到响应，计时器停止，并计算RTT。HTTP响应代码也被记录下来，使我们能够深入了解系统状态。该信息使我们能够通过跟踪故障错误代码来检测系统故障或超时的实例。此外，这使我们能够记录更少的常见错误代码，从而扩展了系统的整体可用性，这些错误代码可能表明系统中的特定问题。

•工作量建模。这是自动扩展体系结构的一个关键功能，使系统能够根据预期的工作负载需求做出如何扩展基础设施的明智决策，以及何时做出此扩展决策。该组件的输出将是对未来工作负载需求的预测，然后将用于为底层基础设施的扩展决策提供信息。LOTUS使用基于gru(门控循环单元)的时间序列模型来预测工作负载需求[16]。GRU模型用于捕获输入数据中的时间依赖性，这允许模型对未来的工作负载需求做出准确的预测。

•控制。此功能负责根据预测的工作负载做出扩展决策。这对LOTUS体系结构的成功至关重要，因为它决定是根据预测的工作负载水平扩展还是垂直扩展。根据接收到的工作负载预测，控制器预测所需的资源(以pod的数量为单位)，并确定是水平扩展还是垂直扩展。如果预测的工作负载表明应用程序将经历需求激增，控制器可能决定通过向集群添加更多pod来水平扩展它。这种方法确保应用程序可以通过将流量分配到工作pod来处理增加的流量负载。如果预测的pod数量与当前数量相同，则控制器假定预测的工作负载将需要更多的资源，例如CPU或内存。然后控制器决定通过向每个pod分配更多资源来垂直扩展。如果预测的工作负载表明需求下降，控制器还可以决定缩小集群的规模。值得一提的是，控制器的决策过程完全依赖于预测模型的准确性，因为它永远无法访问工作负载的实际请求计数。值得注意的是，控制器做出准确缩放决策的能力在很大程度上依赖于预测模型的准确性。由于控制器无法访问工作负载的实际请求计数数据，因此它完全依赖于预测模型生成的预测工作负载。

•知识存储。知识库组件的核心是一个数据存储，用于收集和存储来自系统内各种来源的相关数据。这些数据可能包括正在处理的请求数量、每个请求的处理时间、活动实例数量以及可用的系统资源(如CPU、内存和磁盘空间)等信息。知识库组件通过从体系结构中的其他组件收集信息来获取信息，这些组件依次访问知识库以实现各自的功能。

B. LOTUS Algorithms

工作负载建模。GRU模型被用于模拟我们在本研究中使用的两个数据集的工作量(这些将在下一节中介绍)。这些模型允许我们预测指定时间戳的HTTP请求计数。然后将此预测传递给我们的资源预测系统。

资源预测. 最初，我们假设水平缩放，并利用线性回归pod数模型来确定预测的pod数。然后将其与当前的pod计数进行比较，如果不同，我们通过添加或删除pod来水平缩放以达到我们的新预测值。否则，将启动垂直缩放。这是因为我们的预测表明集群将需要与当前使用的pod数量相同的pod。我们首先比较之前发送到集群的请求数量以及我们对新请求的新模型预测。计算两个值之间的百分比变化。如果这个变化落在我们预定的可接受范围内，我们根据这个量调整CPU利用率。

四 方法论

本节概述了本研究中遵循的方法，并提供了有关LOTUS功能的详细信息。

A.数据收集和预处理

为了测试自动缩放系统的有效性，我们需要大量的数据作为实时使用数据。为了获得这一点，我们获得了公开可用的数据集，这些数据集以前曾在其他作品中用于此目的。具体来说，我们选取了NASA[17]和1998年世界杯网站[18]的HTTP访问请求数据。这提供了两个不同的web访问数据集，允许我们模拟系统的实际使用情况，并测试系统在实际数据上的有效性。

数据集1 - NASA-HTTP。NASA-HTTP数据集是1995年7月运行的NASA肯尼迪航天中心网络服务器的HTTP访问日志的集合。这些日志 记录了用户在该时间段内访问web服务器上各种资源的请求。数据集包含匿名日志，其中包括诸如每个请求的时间戳、请求的文件/资源、返回的HTTP状态码、响应的大小以及其他相关详细信息。

数据集2 - 1998年世界杯(WC98)。我们介绍的第一个数据集是1998年世界杯数据集，它为1998年世界杯网站提供了大约四个月的HTTP请求(≈13亿)。数据集包含各种相关指标，包括调用计数，这些指标将用于训练我们的深度学习模型。数据集允许我们在选定的时间段或整个时间段内检查系统的行为。WC98数据集是公开可用的，尽管它時間久遠，已被广泛用于研究评估web系统的性能，由于其完整性和代表性。

为了处理数据，我们从两个数据集中消除了任何不完整的数据源，并对剩余数据执行最小-最大规范化。这有助于缩小我们正在处理的值的范围，这是一种成熟的深度学习模型技术。在仔细检查数据集的基础上，我们选择了60/40分割测试和训练数据

数据集。我们注意到数据中存在显著差异，使用小的、非随机的分段进行测试将导致样本不具代表性。通过选择60/40分割，我们的目标是创建代表数据总体分布的训练和测试集。这种方法可以帮助防止模型过度拟合多数类，这将对少数类的性能产生负面影响。

B. Deep learning model for workload forecasting

我们创建了一个PyTorch GRU模型来预测工作负载数据集。模型的输入大小为1，隐藏大小为128，输出大小为1。使用Adam优化器以0.001的学习率和均方误差(MSE)损失函数对模型进行200次训练。表2列出了模型配置。一旦对模型进行了训练，我们只需将时间戳格式的字符串传递给模型。该模型对工作负载进行预测。对于世界杯数据集，这将是预期的HTTP请求计数。与WC98数据集记录每分钟的总请求相比，NASA数据集以每个请求为基础，以最近的秒为单位存储数据。为了将GRU模型用于NASA数据集，我们将其转换为NASA数据集的每分钟请求率。这样做允许我们使用为两个数据集创建的相同的模型体系结构，因为它们现在具有相同的内容格式。选择128的隐藏大小是一个相对较大的值，可能有助于模型捕获输入和输出之间更复杂的关系。这个时间序列模型的主要问题是它依赖于有序时间。这防止了训练过程中数据的洗牌;然而，GRU模型捕获顺序数据中的时间依赖性的能力抵消了这一限制，允许模型根据先前的有序观察准确预测未来的HTTP请求计数。我们在清单1中为GRU模型的训练部分提供了伪代码，该模型采用表II中提供的值，例如criterion、optimizer，并执行一个基本的200次迭代循环来训练模型。

C. Resource forecasting

我们在工作量预测的基础上使用Pod预测模型。这个PyTorch线性回归模型的目的是预测水平缩放的pod计数。模型的配置见表三。它有一个输入特性，即请求计数，和一个输出特性，即pod计数。由于我们从WC98和NASA数据集中获取相同的输入，我们只需要这个单一模型进行资源预测。我们只根据时间戳获取预测的请求计数，并使用它将线性关系映射到HPA用于水平扩展的水平pod计数。在训练过程中，使用均方误差(MSE)损失函数和随机梯度下降(SGD)优化器对模型进行100次训练，学习率为0.01。通过在可用数据上训练模型，它有望学习请求计数和pod计数之间的线性关系，然后它可以使用它对新的输入做出准确的预测。我们在清单2中提供了用于训练简单线性回归模型的伪代码。此代码分配表III中列出的值，并循环100次迭代，训练模型。

我们提出的自动缩放器中的缩放决策机制是一种结合了水平缩放和垂直缩放的混合方法。垂直扩展机制不需要深度学习，因为它被用作请求计数变化过低而无法启动或关闭新pod的情况的备份。最初，我们通过预测pod数来假设水平pod缩放。如果预测计数与当前活动计数相同，我们将改为垂直缩放。这是通过计算以前和新的预测计数之间的百分比变化来完成的。我们在listing3中提供了缩放机制的逻辑流。如果预测的数量较高，我们假设需要更多的资源，如果较低，我们假设需要更少的资源。我们的预测模型考虑了各种因素，例如网络流量和资源利用率的变化，以预测未来的工作负载变化。这使我们的自动缩放器能够主动调整资源分配，防止启动或停止运行容器造成的延迟。我们还设置了90%的CPU使用率和至少50%的硬性限制，以防止资源过度使用或使用不足。总的来说，我们的混合自动缩放方法具有预测功能和备份垂直缩放机制，通过根据需要合并垂直缩放并根据预测的工作负载变化主动调整资源分配，改进了以前水平自动缩放器的局限性。这导致更高效和有效的资源扩展，以处理边缘计算环境中的动态工作负载变化。

五 实验和评估

在本节中，我们将描述评估LOTUS性能的设置。具体来说，我们评估了工作负载建模的准确性和系统在不同条件下的性能。

A. Experimental setup

图1中描述的边缘计算系统通过直接以太网连接和Microk8s服务(一种轻量级Kubernetes实现)展示了一个完全连接的拓扑。需要注意的是，这种体系结构安排是灵活的，不需要静态配置，因为它可以容纳一个节点集群。边缘网络是使用树莓派设备构建的，选择树莓派设备是因为它们的硬件限制。LOTUS体系结构是使用Python实现的，并部署在通过直接以太网链路连接到网络的笔记本电脑上。用于实验的硬件和软件组件如表4所示。

B. Measurable objectives

正如前面介绍中所述，我们对自动缩放器的主要目标是通过最小化请求延迟来提高最终用户的服务质量。这是我们的关键评估指标。我们通过记录我们执行的每个测试中每个请求的RTT并计算平均值(排除异常值)来确定这个指标。我们只考虑有效请求的RTT，因为从最终用户的角度来看，只有完成有效请求所需的持续时间才是重要的。此外，我们根据均方误差损失来评估深度学习的准确性，这是评估模型准确性的公认指标[4]。我们在训练和测试阶段都使用它。与HPA相比，RTT的降低以及模型精度的几乎为零的损失将证明成功的结果。

C. Experiments

我们开发了两个不同的实验来评估系统在不同条件下的性能。这些测试是指数增加和指数减少的情况，在下面解释。

1)指数增长压力测试: 我们需要确定LOTUS将如何适应重大的突然负载变化。为此，我们故意以一种戏剧性和突然的方式增加工作负载，以评估系统处理突发需求高峰的能力。指数增长将从最小负载开始，然后以指数方式增加对集群的请求数量。我们将这样做，直到系统崩溃，通过延迟超过阈值检测到，因此没有返回任何结果。我们将记录成功请求的数量，以查看崩溃点。指数递增算法的伪代码如清单4所示。Kubernetes API的“/healthz”端点用于监控集群的状态。如果响应状态码表明群集不健康，则假定群集已崩溃，并返回请求号。

2)指数下降压力测试: 该实验评估系统在面对工作量急剧下降时的弹性。指数下降的情况与指数上升的情况相反。我们将从一个恒定的高负荷开始，这个负荷要高到足以引起剧烈震动，但又不能高到足以导致坠机。然后，我们将开始以指数方式减少负载，并记录延迟时间，以查看在负载减少的情况下是否分配了太多的资源。指数递减算法的伪代码如清单5所示。

我们选择这些特定的实验来衡量系统对不可预见的边缘情况的反应能力。压力测试特别重要，因为它们可以帮助我们评估系统在不可预测的情况下有效适应和扩展的能力。例如，在1998年世界杯期间，比赛日的网络流量激增，但在比赛结束后迅速消退。尽管这种模式可能在某种程度上是可预测的，但确保我们的系统能够有效地处理和适应它们仍然是必不可少的。

六 实验结果

本节包含来自NASA和WC98数据集的工作负载预测的DL模型的实验结果，以及我们的自动缩放器测试的性能结果。所执行的测试是指数增长和减少用例测试，它们的伪代码分别显示在清单4和5中。在描述模型精度的图形中，x轴表示时间戳(以分钟为单位)，y轴表示发送到边缘网络的相应规范化请求计数。

A.工作量建模的准确性

图2和图3分别展示了NASA和WC98数据集的实际结果和预测结果。图2b提供了完整数据集的概述，而图2c则绘制了我们的预测模型。这些数字证明了我们模型的准确性，因为它与实际数据非常吻合。这也适用于WC98数据集，如图3a和3c所示。在整个训练阶段中，loss值在训练周期中呈现出明显的下降趋势，最终达到0.0021 (NASA)和0.0016 (WC98)。整个训练阶段损失值的稳定下降表明我们的模型随着时间的推移正在学习和改进，从而导致更准确的预测。这可以在图4中看到，我们可以看到向Epoch 100的快速收敛，其余的在Epoch 200之前提供较小的精度改进。

B. 压力测试

1)指数增长测试:图5显示了LOTUS和HPA在指数增长实验场景下平均10次的性能对比实验结果。该图显示了两个系统在一段时间内的性能，并显示LOTUS在整个实验过程中始终优于HPA。我们在此图中包含了3个注意点，其中我们已经确定了消除冷启动问题的好处，其中HPA发生超时，而LOTUS不受影响，以及系统之间发生性能反转的未知异常(在32个请求点)。

2)指数下降测试:图6显示了LOTUS和HPA在指数下降实验场景下平均10次的性能对比实验结果。该图显示了两个系统随时间的性能。我们把这张图细分为两部分。第一个标记部分强调了LOTUS在突然和强烈负载条件下有效减少往返时间。本节将演示LOTUS如何以最小的性能损失有效地处理要求苛刻的场景。第二个确定的部分对于结论性的性能评估似乎是不确定的，因为所得到的曲线相互交织，并且没有任何明显的模式来区分两个系统的性能。

七 讨论

本节讨论已确定的趋势和其他值得注意的观察结果。

A.模型精度分析

NASA和WC98的完整数据集与预测一起提供给读者，以提供额外的背景。我们的分析显示，正如两个模型的结果所表明的那样，两个数据集在特定时间间隔内预测请求计数的准确度很高。然而，经过仔细检查，我们观察到WC98数据集并不能准确预测更高水平的计数。这种限制可以归因于这样一个事实，即60%的分割包含相当多的接近零的值，从而导致较不准确的预测。特别是，这在比赛日更加明显，因为接近零的数值更为普遍。尽管存在这些限制，但预测的总体准确性是显而易见的。然而，NASA的数据集显示出略有不同的趋势，几乎所有的高结果都被准确预测，而低结果往往被低估。尽管存在局限性，但预测的总体准确性是明确的，接近于零的损失值进一步加强了这一点。此外，基于我们对完整数据集的分析，我们认为NASA数据集更适合指数用例测试。这是因为NASA数据集训练部分包含一个非常大的值，如图X中NASA数据集图所示，这在WC98数据集中是不存在的。因此，该模型可以在NASA数据集中更准确地预测更高的计数值。总的来说，我们得出结论，GRU时间序列模型非常适合预测请求计数，这是我们研究的关键发现之一。高精确度和可忽略不计的损失值进一步证实了我们的结论，并强调了GRU时间序列模型在这些数据集中预测请求计数的适用性。

B.计算权衡和自动缩放性能

我们使用的时间序列以分钟为单位记录了HTTP请求计数。这意味着在我们的自动缩放器的实际实现中，用于缩放的窗口大小是每分钟一次。然而，我们必须注意到，对于我们的实验测试，我们有充分的理由不能使用这个窗口大小。我们以WC98数据集为例。测试集包含大约51,000个数据条目。要准确地运行它，大约需要连续运行35天。然后必须重复多次，才能在去除异常值后获得可靠的结果。作为替代方案，我们使用数据集逐个索引执行此操作。然而，这个窗口的大小引起了一些担忧。如果我们增加预测的频率，我们可以基于动态请求变化更准确地预测资源需求。然而，这是一个权衡，这是一个自动缩放不稳定。我们越频繁地分配资源，自动缩放器和集群就会变得越不稳定。这可以由其他自动缩放器证明，除了我们的自动缩放器。例如，HPA的缺省更新时间为15秒。这意味着每隔15秒，根据HPA度量公式对度量进行评估和必要的更新。如果我们将其更新为1秒，系统将变得不稳定，因为决策是在更小且可能更不稳定的数据上做出的。此外，我们的自动缩放器有一个权衡，HPA和其他反应式自动缩放器没有。我们需要时间来训练我们的深度学习模型。我们训练了一个基于服务器访问请求的GRU时间序列模型，从中我们将请求发送到集群并记录pod计数。这些数据用于线性回归预测pods数。当我们为我们的数据集和集群硬件训练这些模型时，任何新的数据集或集群硬件重构都需要模型再训练。这是我们的预测式自动缩放器和其他反应式自动缩放器之间最大的折衷。然而，应该注意的是，对于我们的数据集，模型训练和硬件重新配置所需的时间不足减轻了这种权衡，因为数据集和硬件已经建立，这使得我们的系统的性能优势可以看到，正如我们的实验结果所示。

C.消除“冷启动”问题

基于图5所示的发现，我们的指数增长用例结果表明，与HPA相比，冷启动问题得到了明确的消除。这个功能是由LOTUS的主动资源分配提供的，它允许我们提前预测哪些工作负载进入系统，从而有效地消除了响应式自动伸缩方法中固有的时间间隔。LOTUS的这个优势非常有价值，特别是对于时间敏感的应用程序或类似的场景，因为它允许快速的启动时间，可以充分利用。

D.高工作负载环境中的系统性能

就高工作负载能力而言，与HPA相比，LOTUS表现出了明显的性能优势，如图5所示。在这个实验场景中，当HPA在1024个并发请求之后超时时，LOTUS显示RTT没有变化，这表明超时与自动伸缩机制有关，而不是物理硬件限制。此外，图6显示，在高工作负载环境中，LOTUS在达到低工作负载环境之前几乎呈线性下降。相比之下，HPA最初遵循类似的下降，但在256个同时请求时经历了明显的下降。我们假设这种下降是由于与HPA的反应性水平缩放相比，LOTUS的主动混合缩放实施了主动混合缩放，这解释了两个系统之间的差异。

八 总结

本研究提出了一种基于深度学习的自动缩放器架构，以实现边缘计算集群的自主缩放管理。提出的体系结构通过多个用例场景进行测试，为其有效性提供可量化的结果，并展示其实现所需的算法。进行了压力测试以检查架构在极端负载下的性能，结果表明“冷启动”问题显着减少。未来的工作可能需要将工作负载卸载到云端，扩展架构可以部署的集群范围，并实现完整的深度学习垂直扩展，而不是本研究中使用的深度学习水平和数学垂直扩展。

SHOWAR

PBS

摘要–在具有动态工作负载的云应用程序中，自动扩展对于确保最佳性能和资源利用率至关重要。然而，由于工作负载模式的多样性和微服务之间复杂的交互，传统的自动扩展技术通常不再适用于基于微服务的应用。具体来说，性能异常会通过交互传播，导致大量微服务异常，从而难以确定根本的性能瓶颈（PB）并制定适当的扩展策略。此外，为了平衡资源消耗和性能，现有的基于在线优化算法的主流方法需要多次迭代，从而导致振荡，提高了性能下降的可能性。为了解决这些问题，我们提出了 PBScaler，这是一个瓶颈感知自动伸缩框架，旨在防止基于微服务的应用出现性能下降。PBScaler 的关键在于定位 PB。因此，我们提出了 TopoRank，一种基于拓扑潜力的新型随机行走算法，以减少不必要的扩展。通过将 TopoRank 与离线性能感知优化算法相结合，PBScaler 在不中断在线应用的情况下优化了副本管理。综合实验证明，PBScaler 在缓解性能问题的同时有效节约资源，其性能优于现有的最先进方法。

1 介绍

随着微服务架构的发展，越来越多的云应用正在从单体架构向微服务架构迁移[1], [2], [3], [4], [5], [6]。这种新架构将单体应用分解成多个微服务，这些微服务通过 HTTP 或 RPC 协议相互通信，从而降低了应用耦合度[7]。此外，每个微服务都可以由不同的团队独立开发、部署和扩展，从而实现快速的应用程序开发和迭代。然而，外部工作负载的不可预测性和微服务之间交互的复杂性会导致性能下降 [8]、[9]、[10]。云提供商必须准备过多的资源来满足应用程序所有者的服务级别目标（SLO），这通常会造成不必要的资源浪费[11]，[12]。因此，满足 SLO 与尽量减少资源消耗之间的不平衡成为微服务资源管理面临的主要挑战。

微服务自动扩展 微服务自动扩展指的是根据工作负载变化弹性分配资源的能力[13]。通过利用微服务的弹性特性，自动伸缩可以缓解资源成本与性能之间的冲突。然而，微服务的自动扩展在短时间内难以准确扩展性能瓶颈（PB）。由于微服务间通信的复杂性，一个 PB 的性能下降可能会通过消息传递传播到其他微服务[2]，导致大量微服务同时出现异常。我们通过向谷歌开发的开源微服务应用程序在线精品 1 中的特定微服务注入突发工作负载来证明这一点。图 1 显示，PB Recommend 中的性能下降会蔓延到上游微服务，如 Checkout 和 Frontend。为了进一步验证精确扩展 PB 的重要性，我们进行了压力测试，并分别扩展了不同的微服务。如图 2 所示，微服务（Frontend）的异常扩展无法缓解 SLO 违规情况。但是，当我们识别并扩展 PB 建议时，微服务应用的性能得到了改善。遗憾的是，定位 PB 通常很耗时，而且偶尔会出错[14]。

近年来，人们提出了几种在自动扩展前识别关键微服务的方法。例如，Kubernetes 2 的默认自动分级器会根据计算资源的静态阈值过滤微服务以进行直接分级。Yu 等人[15]通过计算服务功率（即第 50 百分位响应时间（P50）与第 90 百分位响应时间（P90）之比）定义了弹性扩展的边界。此外，Qiu 等人[4] 引入了一种基于 SVM 的方法，通过分析各种尾部延迟的比率来提取关键路径。虽然这些研究缩小了自动缩放的范围，但它们仍然考虑到了可能影响缩放策略的非瓶颈微服务，尤其是当应用程序中的大量微服务同时出现异常时。因此，迫切需要在自动扩展前准确定位瓶颈微服务。

为了平衡资源消耗和性能，现有研究采用了在线优化算法来寻找接近最优的自动缩放策略。然而，由于自动伸缩的可能策略种类繁多，这些方法需要大量的尝试，这对在线应用来说是个问题。例如，火车票3 是最大的开源微服务应用，由近 40 个微服务组成。假设每个微服务最多可以有 15 个副本，那么为该应用确定最优分配策略无疑是一个 NP 难问题，因为最多有 1540 种扩展选择。此外，在线优化中的反馈循环持续时间太长，无法实现模型收敛。此外，还必须考虑在线优化导致性能下降的潜在风险。图 3 展示了突发工作负载对 MicroScaler [15] 的副本波动和延迟波动的影响，MicroScaler 是一种在线自动缩放方法，采用了在线贝叶斯优化，以找到总成本的全局最小值。在线优化造成的频繁在线尝试创建副本（图 3a）导致了振荡和性能下降（图 3b）。因此，我们受到启发，设计了一种离线优化流程，由模拟器提供反馈。

本文介绍了 PBScaler，这是一个水平自动扩展框架，旨在通过识别和解决瓶颈问题，防止基于微服务的应用出现性能下降。我们没有像以前的工作[11]、[15]那样为所有异常微服务优化资源，而是提出了基于拓扑势理论（TPT）的随机行走算法 TopoRank，以识别性能瓶颈（PB）。TopoRank 考虑了微服务依赖性和异常可能性，提高了瓶颈定位的准确性和可解释性。通过 TopoRank 确定 PB 后，PBScaler 会进一步采用遗传算法找到近乎最优的策略。为避免过度优化造成应用振荡，该过程采用离线方式，并由 SLO 违反预测器提供指导，该预测器可模拟在线应用并为扩展策略提供反馈。本文的主要贡献概述如下：

• 我们提出的 PBScaler 是一个瓶颈感知自动扩展框架，旨在防止基于微服务的应用程序性能下降。通过精确定位瓶颈，PBScaler 可以减少不必要的扩展并加快优化过程。
• 我们采用基于遗传算法的离线优化流程来优化资源消耗，同时避免违反 SLO。该过程由 SLO 违规预测器指导，旨在实现资源消耗与性能之间的平衡，同时又不影响在线应用。
• 我们在 Kubernetes 系统中设计并实施了 PBScaler。为了评估其有效性，我们在在线环境中运行的两个广泛使用的微服务系统上进行了大量的真实工作负载注入和模拟工作负载注入实验。实验结果表明，PBScaler 的性能优于几种最先进的弹性扩展方法。

本文接下来的内容安排如下。第 2 节，我们将讨论有关微服务瓶颈分析和自动扩展的相关工作。第 3 节，我们将详细介绍整个系统。第 4 节介绍评估和实验结果。第 5 节总结了我们的工作并讨论了未来的研究方向。

2 相关工作

随着云计算的发展，学术界和工业界提出了许多针对虚拟机或容器等云资源的自动扩展方法[16], [17], [18], [19]。然而，由于微服务之间错综复杂的依赖关系，微服务的自动伸缩可能要复杂得多。

性能瓶颈分析（也称为根本原因分析）是快速定位导致微服务性能下降的瓶颈的有效方法，从而减少自动扩展所需的时间和精力。在本节中，我们将分析有关微服务瓶颈分析和自动扩展的相关工作。

2.1 瓶颈分析

近年来，微服务场景中的瓶颈分析方法层出不穷，其中大多数都依赖于三类数据：日志、跟踪和度量。1) 日志。Jia 等人[20]和 Nandi 等人[21]首先从正常状态日志中提取模板和流量，将其与目标日志进行匹配，然后过滤掉异常日志。2) 跟踪。跟踪是一种基于事件跟踪的记录，它再现了微服务之间的请求过程。有几项研究[22]、[23]、[24]、[25]介绍了如何利用跟踪来找出瓶颈。Yu 等人[22]、[23]通过结合频谱分析和 PageRank 算法，在痕迹构建的依赖图上定位瓶颈，而 Mi 等人[24]提出了一种无监督机器学习原型，用于学习微服务的模式并过滤掉异常微服务。不过，使用痕迹可能会对代码造成干扰，而且要求操作员对微服务的结构有深入的了解。3) 指标。一些方法[2]、[26]、[27]利用图随机漫步算法来模拟异常的传播过程，然后通过整合指标的统计特征和微服务之间的依赖关系来找到瓶颈。此外，CauseInfer [14] 和 MicroCause [28] 等方法侧重于通过因果推理构建指标因果关系图，这通常涉及指标之间隐藏的间接关系。

由于在监控指标时很少修改工作流代码，因此为微服务收集指标的成本通常比使用跟踪更低。此外，使用指标作为主要监控数据可以降低整合瓶颈分析和自动扩展的成本，因为指标在后一种情况中被广泛使用。尽管这些方法都有优势，但大多数方法在选择异常回溯的起点时都没有偏好。相比之下，我们的方法从具有更大异常潜力的微服务开始随机回溯，从而加快了收敛速度，提高了瓶颈定位的准确性。

2.2 微服务的自动扩展 微服务的现有自动扩展方法可分为五类。1) 基于规则的启发式方法。KHPA、Libra[29]、KHPA-A[30]和 PEMA[31]根据资源阈值和特定规则管理微服务副本的数量。然而，由于不同的微服务对特定资源的敏感度不同，因此需要专家知识来支持这些不同微服务的自动扩展。2) 基于模型的方法。微服务可以通过建模来预测其在特定配置和工作负载下的状态。排队理论[32]、[33]和图神经网络（GNN）[12]常用于为微服务建立性能预测模型。3) 基于控制论的方法[11]、[32]。SHOWAR [11]利用控制论动态调整微服务副本，以纠正监控指标与阈值之间的误差。4) 基于优化的方法。这些方法[15]、[34]进行了大量尝试，以在现有资源和工作负载的情况下找到最优策略。这些方法的关键在于缩小决策范围以加快进程。5) 基于 RL 的方法。强化学习（RL）已广泛应用于微服务的资源管理。MIRAS [35] 采用基于模型的 RL 方法进行决策，以避免真实环境的高采样复杂性。FIRM[4]利用支持向量机（SVM）识别微服务中的关键路径，并利用深度确定性策略梯度（DDPG）算法为路径上的微服务制定混合扩展策略。基于 RL 的方法在探索过程中需要不断与环境交互，无法适应动态的微服务架构。总之，虽然上述自动扩展技术各有优势，但它们很少关注性能瓶颈。为无瓶颈的微服务消耗计算机资源势必会增加扩展成本，延长决策时间。而我们的方法则侧重于定位性能瓶颈。

3 SYSTEM DESIGN

我们提出的 PBScaler 是一种以 PB 为中心的自动扩展控制器，用于定位 PB 并为其优化副本。如图 4 所示，PBScaler 由三个部分组成： 1) 指标收集器： 为了实时了解应用程序的状态，我们设计了一个指标收集器，以固定的时间间隔捕获并整合来自 Prometheus4 的监控指标。2) 性能瓶颈分析： 在指标收集器的协助下，该组件可执行 SLO 违规检测和冗余检查，以识别存在异常行为的微服务。接下来，将触发瓶颈定位流程，找出异常微服务中的 PB。3) 扩展决策： 该组件旨在使用进化算法确定 PB 的最佳副本数量。最后，PBScaler 会生成具有优化策略的配置文件，并将其提交给 kubernetes-client5，从而控制微服务的副本数量。

3.1 指标收集器

自动伸缩系统依赖于对内存使用数据、系统负载和尾部延迟等指标的实时访问，以确定是否应执行弹性伸缩，以及应在微服务应用程序中分配多少资源。与需要深入了解程序和代码注入的基于跟踪的监控器[7]不同，指标收集器根据服务网格报告指标，以最大限度地减少对业务流的干扰。如表 1 所示，PBScaler 使用 Prometheus 和 kube-statemetrics 来收集和分类这些指标，包括响应延迟、微服务之间的调用关系、资源消耗和微服务工作量。
例如，容器 cpu 使用率秒总数是 Prometheus 中的一个标签，它记录了容器级别的中央处理器（CPU）使用情况。我们将 Prometheus 的监控间隔设为 5 秒，并将收集到的指标数据存储在时间序列数据库中。我们收集每个微服务的 P90 尾端延迟，并用它来表示应用程序的性能。调用关系意味着微服务之间的关联，可用于构建微服务关联图。服务网格。服务网格是一种基础设施，它能让开发人员为云应用添加可观察性和流量管理等高级功能，而不需要额外的代码。Istio7 是一种流行的开源服务网格实现，旨在与 Kubernetes 无缝集成。当 pod 在 Kubernetes 中启动时，Istio 会在 pod 中启动一个特使代理来拦截网络流量，从而实现工作负载平衡和监控。

3.2 Performance Bottleneck Analysis

性能瓶颈分析（PBA）是一个旨在发现微服务应用程序中性能下降和资源浪费的过程，从而推断出当前问题的瓶颈。正如第 1 节所述，通过准确定位这些瓶颈，PBA 可以提高自动缩放的性能并减少过多的资源消耗。PBScaler 中的 PBA 流程如算法 1 所示。

3.2.1 SLO Violation Detection

为了检测微服务的异常情况，PBScaler 使用服务级别目标（SLO）与特定指标进行比较。如果微服务多次违反 SLO，即性能下降，就会被视为异常。正如文献[14]和[27]所述，检测 SLO 违规行为是触发瓶颈定位的关键一步。度量收集器收集的调用关系可用于构建微服务关联图 Gc。PBScaler 每 15 秒检查一次 Gc 中所有调用边的 P90 尾延迟，以便及时发现性能下降。如果某个调用的尾延迟超过了预定阈值（如 SLO），则该调用所调用的微服务将被添加到异常微服务（S）集合中，并启动瓶颈定位流程。为了考虑微服务延迟中偶尔出现的噪音，阈值设定为 SLO×(1 + α 2 )，其中 α 用于调整对噪音的容忍度。

3.2.2 Redundancy Checking

在没有出现性能异常的情况下，一些微服务可能会被分配超过所需的资源。但是，仅通过度量很难识别这种情况，可能会导致浪费有限的硬件资源。为了避免这种情况，必须确定哪些微服务分配了过多的资源。PBScaler 使用微服务每秒的工作负载变化率来确定资源是否多余。这种策略比仅依赖资源消耗更有效，因为不同的微服务对异构资源的敏感度可能不同。冗余检查的主要思路是利用假设检验来检测微服务当前的工作量 wi c 是否显著低于其过去的工作量（表示为 wi p）。显著程度由参数 β 调整，假设检验可表述为：

为进行假设检验，我们首先从度量收集器中获取目标微服务的当前和历史工作量。如果 P 不超过置信水平 cl（默认设置为 0.05），我们就拒绝零假设 H0，并认为微服务 i 存在冗余资源。

3.2.3 Bottleneck Localization

由于微服务应用程序中复杂的交互[36]，并不是每个异常的微服务都需要扩展。例如，图5说明了瓶颈微服务(例如，Product)的性能下降如何沿着调用链传播到它的上游微服务(例如，recommendation, Frontend和Checkout)，即使上游微服务没有过载。因此，只有瓶颈微服务必须被扩展，而其他异常微服务只是被牵连。为了精确定位瓶颈微服务，我们引入了异常潜力的概念，它聚集了给定位置上所有微服务的异常影响。由于PB被许多受其影响的异常微服务所包围，因此PB的异常潜力通常很高。我们设计了一种新的瓶颈定位算法TopoRank，该算法在随机行走中引入拓扑势理论(TPT)来计算所有异常微服务的得分，并最终输出一个排名列表(rl)。在rl中得分最高的微服务可以被识别为PBs。

TPT源于物理学中“场”的概念，在各种著作中被广泛应用[37]，[38]来衡量复杂网络中节点之间的相互影响。由于微服务关联图也可以被视为一个复杂的网络，我们使用TPT来评估微服务的异常潜力。具体来说，我们已经观察到，在微服务关联图Gc中，离PBs更近的微服务，即那些跳数较少的微服务，更有可能出现异常，因为它们经常频繁地直接或间接调用PBs。基于这一观察，我们使用TPT评估微服务的异常潜力。为此，我们首先通过识别异常微服务及其在Gc中的调用关系来提取异常子图Ga。然后，我们使用TPT计算异常子图Ga中微服务vi的拓扑势。

其中，N 代表 vi 的上游微服务数量，mj 代表 vj 的异常度。PBScaler 将异常度定义为某个微服务在某个时间窗口内违反 SLO 的次数。dji 表示从 vj 到 vi 所需的最小跳数。我们使用影响因子 σ 来控制微服务的影响范围。

然而，拓扑潜能值高的微服务并不一定是 PB，因为异常通常会沿着微服务相关图传播。因此，仅仅依靠 TPT 不足以诊断 PB。为了解决这个问题，PBScaler 采用了个性化 PageRank 算法 [39]，以逆转异常子图 Ga 上的异常传播并定位 PB。假设 P 是 Ga 的转换矩阵，Pi,j 是异常从 vi 跟踪到其下游节点 vj 的概率。给定外度为 d 的 vi，标准个性化 PageRank 算法将 Pi,j 设为

这意味着算法不会偏向任何下游微服务。然而，这一定义没有考虑到下游微服务与当前微服务异常之间的关联。因此，PBScaler 会调整计算方法，更多地关注指标与上游响应时间更相关的下游微服务。对于每个微服务 vi，PBScaler 都会收集一个尾部延迟序列（li）和一组度量数组 Mi = {m1, m2, - - , mk}，其中 mk 可视为给定时间窗口内度量数组（如内存使用率）的波动数组。PBScaler 的定义是，Pi,j 取决于 li 与 Mj 中度量数组之间皮尔逊相关系数的最大值：

个性化PageRank算法通过在有向图上随机行走来确定每个节点的受欢迎程度。然而，一些节点可能永远不会指向其他节点，导致所有节点的分数在多次迭代后趋于零。为了避免落入这个“陷阱”，应用了一个阻尼因子δ，它允许算法根据预定义的规则从这些节点跳出来。通常δ设为0.15。个性化PageRank表示如下:

其中v表示每个微服务节点被诊断为PB的概率。偏好向量u作为个性化规则，引导算法跳出陷阱。u的值由每个节点的异常势决定。异常潜力较大的节点优先作为算法的起始点。第k次迭代的方程可以表示为:

经过多轮迭代，v逐渐收敛。PBScaler然后对最终结果进行排序并生成排名列表。排名列表得分最高的前k个微服务可以被识别为PBs。TopoRank的整个过程描述为算法2。

3.3 Scaling Decision

给定性能瓶颈分析确定的PBs，将对PBs的副本进行缩放，以最小化应用程序的资源消耗，同时确保微服务的端到端延迟符合SLO。尽管大量的副本可以缓解性能下降问题，但它们也会消耗大量的资源。因此，必须在性能保证和资源消耗之间保持平衡。缩放决策的过程将被建模为一个约束优化问题，以实现这种平衡。

3.3.1 Constrained Optimization Model

我们场景中的自动缩放优化试图确定一个分配模式，该模式为每个PB分配可变数量的副本。给定n个需要缩放的PBs，我们将策略定义为集合X = {x1, x2，···，xn}，其中xi表示分配给pbi的副本数量。在优化之前，PBs的初始副本数量可以表示为C = {c1, c2，···，cn}。应该注意的是，PBScaler中的副本约束应该分别为按比例缩小和按比例扩大的流程定义。在扩展过程中，我们对PBs的副本数量进行了如下限制:


其中cmax表示在给定有限服务器资源的情况下，微服务可以扩展到的最大副本数量。在缩小过程中，副本数量的约束可以表示为:


在Eq.(8)中，γ(默认值为2)表示复制减少的最大数量。这个限制是合理的，因为正如在实验中观察到的那样，大幅减少微服务副本的数量可能会导致短暂的延迟峰值。缩放决策的目标是尽量减少应用程序的资源消耗，同时保持其性能。应用程序性能通常用用户更关心的SLO违规来表示。因此，应用程序性能奖励可以细化为:


在优化过程中，应用程序的资源消耗(如CPU和内存使用)是不可预测的。为了保守估计资源消耗，


我们考虑的是PB副本与可分配副本的最大数量的比率，而不是计算CPU和内存的成本。我们将资源奖励计算为:


我们的目标是在保证性能的同时尽量减少资源消耗。我们利用加权线性组合(WLC)方法来平衡这两个目标。最终优化目标定义为:


式中λ∈[0,1]。我们将λ设置为参数，以平衡应用程序性能和资源消耗。

3.3.2 SLO Violation Predictor

为了计算性能奖励R1，需要评估策略是否会导致在线应用程序违反SLO。一种简单的方法是直接在在线申请中执行候选策略，并等待监控系统的反馈。然而，在线应用程序中频繁缩放引起的振荡是不可避免的。另一种方法是使用历史度量数据训练评估模型，该模型可以模拟在线应用的反馈。在不与在线应用程序交互的情况下，该模型根据应用程序的当前状态预测应用程序的性能。我们使用向量r来表示执行扩展策略x后每个微服务的副本数量。w是表示每个微服务当前工作负载的向量。由于瓶颈感知优化的时间成本较低，我们可以合理地假设w在此期间不会发生显著变化(参见4.2节)。给定由工作负载w和所有微服务副本r表示的应用状态，一个SLO违例预测器可以设计为:


其中ψ是一个二元分类模型。选择合适的分类模型的细节将在4.3节中讨论。用于训练的历史度量数据可以使用经典缩放方法(默认是Kubernetes自动缩放器)或随机方法生成。我们在3个节点(共44个CPU核和220gb RAM)上部署了一个开源微服务系统，并进行了弹性扩展。普罗米修斯以固定的时间间隔收集每个微服务的工作负载和P90尾部延迟。通过比较前端微服务的尾部延迟和SLO，可以很容易地标记每个时间间隔的监控数据。


3.3.3 Autocaling Optimization

如第3.3.1节所述，性能和资源消耗之间的权衡可以建模为约束优化问题。为了找到接近最优的策略，PBScaler使用遗传算法(GA)来生成和优化扩展策略，以减少资源消耗，同时满足SLO要求。遗传算法通过模拟进化中的自然选择，在淘汰劣等子代的同时提高优等子代。首先，遗传算法执行随机搜索来初始化策略空间中的染色体种群，每条染色体表示优化问题的潜在策略。接下来，在每次迭代中，将选择具有高适应度的精英染色体(称为精英)进行交叉或突变以产生下一代。

我们场景中的自动缩放优化旨在确定一种缩放策略，该策略为每个PB分配可变数量的副本。自缩放优化过程如图6所示。一开始，PBScaler获得每个微服务当前的副本数量r和工作负载w。在性能瓶颈分析之后，PBScaler从r中识别PBs，并将它们过滤出来，得到r ‘。然后，决策者生成PBs策略的总体。由于要扩展的微服务数量会影响优化算法的速度和效果(第4.3节)，PBScaler假设只有PBs需要进行弹性扩展。换句话说，r ‘中的副本数量将保持不变。SLO违例预测器负责评估生成的策略。需要注意的是，该策略与r ‘合并，并与w一起输入到SLO违规预测器中。通过遗传算法选择优策略Xbest，并与r ‘合并，生成最终决策。


从r中识别出PBs然后过滤出来得到r ‘然后，决策者生成PBs策略的总体。由于要扩展的微服务数量会影响优化算法的速度和效果(第4.3节)，PBScaler假设只有PBs需要进行弹性扩展。换句话说，r ‘中的副本数量将保持不变。SLO违例预测器负责评估生成的策略。需要注意的是，该策略与r ‘合并，并与w一起输入到SLO违规预测器中。通过遗传算法选择优策略Xbest，并与r ‘合并，生成最终决策。在优化阶段，决策者使用遗传算法生成并改进PB的缩放策略，如算法3所述。在每个PB的策略范围内随机生成一个种群(第1行)后，Decision Maker根据Eq.(11)估计每个策略的适应度，并存储精英(第2-3行)。在每次迭代中，遗传算法使用基于锦标赛的选择算子来挑选优秀的亲本(第6行)。通过使用两个点交叉算子和双染色体突变算子，通过重组和突变(第7-8行)产生新的后代。通过模拟自然选择，新的后代和亲本精英形成一个新的种群，进入下一个迭代(第9行)。当遗传算法达到指定的迭代次数时，Decision Maker返回适应度最高的缩放决策Xbest。

4 EVALUATIONS

在本节中，我们详细介绍了自动缩放的实验场景，包括PBScaler与学术界和工业界几种最先进的自动缩放算法的比较。

4.1 Experimental

Setup 4.1.1 Microservice Platform

实验在我们的私有云集群中进行，该集群由三台物理计算机(一个主节点和两个工作节点)组成，共有44个Intel 2.40 GHz CPU内核和220gb RAM。为了评估自动扩展，我们选择了两个开源微服务应用程序作为基准:a)在线精品8，一个由谷歌开发的基于web的电子商务演示应用程序。该系统通过10个无状态微服务和Redis缓存的协作，实现了浏览产品、将商品添加到购物车和支付处理等基本功能。b) Train Ticket9:复旦大学开发的大型开源微服务系统。Train Ticket拥有40多个微服务，并使用MongoDB和MySQL进行数据存储，可以满足各种工作流程，如在线门票浏览，预订和购买。由于集群资源的限制，我们将每个微服务限制为不超过8个副本。源代码可在Github10上获得

4.1.2 Workload

我们评估了PBScaler在各种流量场景下的有效性，使用了2015年3月16日Wiki-Pageviews[40]的真实维基百科工作负载，以及受Abdullah等人[41]的实验启发的五种模拟工作负载(EW1 ~ EW5)。我们将实际工作负载压缩到一个小时，并将其扩展到适合我们集群的级别。五个模拟工作负载表现出不同的模式，例如单峰、多峰、上升和下降，并且持续时间限制为20分钟。图7描述了这些工作负载的波动情况。

4.1.3 Baseline Methods

我们将PBScaler与学术界和工业界的几种最先进的微服务自动扩展方法进行比较，这些方法从静态阈值、控制理论和黑盒优化的角度执行微服务的动态水平扩展。

•Kubernetes水平Pod自动缩放(KHPA):这是Kubernetes默认的水平缩放方案。通过为某个资源R定制阈值T(默认为CPU使用率)，并从微服务的所有副本中聚合资源使用U R i, KHPA将副本的目标数量定义为n = d∑i∈ActiveP ods U R i / T e。

•MicroScaler[15]:这是一个自动扩展工具，它使用黑盒优化算法来确定微服务的最佳副本数量。MicroScaler计算微服务的P90/P50进行分类，然后执行贝叶斯优化的四次迭代来做出扩展决策。

•SHOWAR[11]:它是一种混合自动缩放技术。我们在SHOWAR中再现了水平缩放部分，它使用PID控制理论使观察到的度量逐渐接近用户指定的阈值。在我们的实现中，我们用更常见的P90延迟替换了运行队列延迟，因为前者需要额外的eBPF工具

4.1.4 Experimental Parameters and Evaluation Criteria

在我们的实验中，我们将普罗米修斯的收集间隔固定为5秒。随着实验时间和工作负载的增加，MongoDB等有状态微服务所需的数据量也会增加。最终，数据量将超过可用内存，从而需要使用磁盘存储。这种转换可能导致无法通过自动缩放来补救的性能下降。因此，我们将工作负载测试限制为无状态跟踪。在线精品店和火车票的SLO值分别设置为500毫秒和200毫秒。在SLO违例检测和冗余检查模块中，PBScaler首先将动作边界α设置为0.2，以减少噪声干扰。然后，我们根据经验将显著度β设置为0.9，以控制触发扩展的工作负载水平。对于瓶颈定位，将拓扑势的影响因子σ设为1，将rl中得分最高的top-k (k =2)个微服务视为PBs。我们选择了SLO违规率、资源消耗和响应时间来评估自缩放方法的性能。如果自动缩放方法可以减少响应时间、SLO违规率和资源消耗，则认为它更有效。我们将SLO违例率定义为端到端P90尾部延迟超过SLO的百分比。资源消耗按照[42]给出的方法计算，其中CPU价格为0.00003334$ (vCPU/s)，内存价格为0.00001389$ (G/s)。总资源消耗由内存成本和CPU成本相加得到。



4.2 Performance Evaluation

表2比较了具有不同工作负载的两个微服务应用程序中四种自动伸缩方法的SLO违反率和资源成本。None方法用作引用，不执行自动缩放操作。其结果以灰色表示，并被排除在比较之外。一般来说，PBScaler在减少两个微服务系统中六个工作负载下的SLO违规和最小化资源开销方面优于其他竞争方法。其中，PBScaler在火车票中的SLO违规率比基线方法平均降低4.96%，资源成本平均降低0.24美元。结果表明，PBScaler可以快速、精确地对大规模微服务系统中的瓶颈微服务进行弹性扩展，从而减少了SLO违规，节省了资源。对于Online Boutique中的6个工作负载，PBScaler还在其中4个模拟工作负载中实现了最低的SLO违规，并在3个模拟工作负载中实现了最低的资源消耗。图8描绘了六种工作负载下不同方法的延迟分布箱形图，探讨了每种方法对微服务系统性能的影响。可以看出，大多数自动缩放方法都可以保持延迟分布的中位数低于红色虚线(SLO)。但是，只有PBScaler进一步将第三个四分位数降低到所有工作负载的SLO以下。为了评估使用PBScaler进行弹性缩放的时间成本，收集并计算了PBScaler中每个模块所需的平均时间。如表3所示，Online Boutique中所有PBScaler模块的总时间成本小于一个监控间隔(即5s)，而Train Ticket的相同度量小于两个监控间隔。由于PBA缩小了决策范围，当应用程序从Online Boutique切换到Train Ticket时，尽管微服务的数量增加了，但决策者的时间成本并没有增加太多(不超过6.6%)。然而，我们认识到随着微服务规模的增长，PBA的时间消耗会迅速增加，这将是我们未来的工作。

4.3 Effectiveness Analysis of Components
4.3.1 Performance Comparision of Bottleneck Localization



为了评估TopoRank算法是否能有效定位突发工作负载引起的PBs，我们通过Chaos Mesh将CPU过载、内存溢出和网络拥塞等异常注入到Online Boutique和Train Ticket中。这些异常通常是由高工作负载条件引起的。使用TopoRank算法分析度量并确定这些异常的性能瓶颈。然后将定位结果与micrororca[27]进行比较，micrororca是微服务根本原因分析的基线方法。AC@k测量前k个结果中实际PBs的精度，Avg@k是前k个结果的平均精度。这些指标的计算方法如下。


其中A表示微服务集合，RT @k表示排名前k的微服务。图9给出了TopoRank和MicroRCA在不同微服务应用中的AC@1和Avg@5值。结果表明，TopoRank在这两个指标上都优于MicroRCA。这主要是由于TopoRank在执行个性化PageRank时考虑了异常可能性和微服务依赖关系。

瓶颈定位的主要目的是缩小策略空间，加快最优策略的发现。我们在PBs和所有微服务上执行遗传算法迭代，以证明瓶颈定位对优化的影响。图10描述了微服务系统下的迭代过程，并表明随着人口(Pop)的增加，pb感知策略在适应度方面明显优于适用于所有微服务的方法。该策略可以在不到5次迭代中获得较好的适应度。相比之下，涉及所有微服务的方法需要更大的种群和更多的迭代才能达到相同的适应度水平。这是由于pb感知策略帮助遗传算法精确地缩小了优化范围，加速了优解的获取。

4.3.2 Effectiveness of the SLO Violation Predictor

SLO违例预测器的目标是直接预测优化策略的结果，而不是等待在线应用程序的反馈。我们根据每个微服务的副本数量和工作负载来确定是否会出现性能问题。为预测任务选择合适的二分类模型至关重要。以5秒的数据收集间隔，我们在我们的集群中收集了两个数据集，包括3.1k的火车票历史采样数据集(a)和1.5k的在线精品数据集(B)。为了对这两个数据集进行训练和测试，我们采用了四种经典的机器学习方法，包括支持向量机(SVM)、随机森林(Random Forest)、多层感知器(Multilayer Perceptron)和决策树(Decision Tree)。表4给出了四种模型对SLO违规预测的准确率和召回率。根据两个数据集的效果，我们最终选择随机森林作为SLO违例预测的主要算法。为了证明SLO违例预测器可以替代来自真实环境的反馈，我们将使用SLO违例预测器的PBScaler与从在线系统收集反馈的MicroScaler进行了比较。我们将突发工作负载注入Online Boutique，并仅使一个微服务异常，以消除两种方法在瓶颈定位方面的差异。如图11所示，在预测器的引导下，PBScaler的决策尝试次数和频率远低于MicroScaler。减少集群中的在线尝试将明显降低振荡的风险。

5 CONCLUSIONS

本文介绍了PBScaler，一个瓶颈感知自动伸缩框架，旨在防止基于微服务的应用程序的性能退化。PBScaler使用服务网格技术收集应用程序的实时性能指标，并动态构建微服务之间的关联图。为了处理由外部动态工作负载和微服务之间复杂调用引起的微服务异常，PBScaler采用基于拓扑势理论的随机游动算法TopoRank来识别瓶颈微服务。此外，PBScaler采用离线进化算法，在SLO违规预测器的指导下优化缩放策略。实验结果表明，PBScaler可以在最小化资源消耗的同时实现较低的SLO违规。

在未来，我们计划从以下两个方面改进我们的工作。首先，我们将探索在细粒度资源(例如，CPU和内存)管理中使用瓶颈感知的潜力。其次，我们将探讨如何规避自扩展中有状态微服务的干扰，因为有状态微服务的性能下降可能会破坏自扩展控制器。第三，提高大规模微服务系统性能瓶颈分析的效率。