用于无服务器自动扩缩容的动态CPU阈值自适应机制：一种受TCP慢启动算法启发的方法

《Computer Networks》：Dynamic CPU Threshold Adaptation for Serverless Auto-scaling: A TCP Slow-Start Inspired Approach

　　摘要：无服务器计算通过根据当前工作负载动态分配资源，实现了可扩展且经济高效的计算方式。然而，传统的自动扩缩容技术往往依赖静态的CPU使用率阈值，这可能导致性能不佳，进而出现资源过度配置、配置不足或延迟增加的问题。另一方面，工作负载的快速变化使得固定的CPU阈值难以调整，从而导致不必要的或延迟的扩缩容反应，进而降低性能并增加成本。为解决这些问题，已有不少研究展开。受TCP慢启动机制的启发，本文提出了一种动态CPU阈值自动扩缩容策略。该策略为Knative的自动扩缩容引入了动态CPU阈值方法，模仿TCP慢启动机制。该方法会根据实时工作负载情况动态调整初始的保守型CPU使用率标准。首先，算法会以指数方式提升阈值以适应不断增长的需求；当检测到使用率上升时，则降低阈值并转为线性增长模式，从而实现可控且稳定的扩缩容。通过部署Knative函数，并利用Azure Functions数据集、FunctionBench基准测试以及Hey负载生成器创建多种真实和模拟的工作负载，对所提算法的性能进行了评估。在实际应用中，对比应用动态CPU阈值技术前后，收集并分析了响应时间、吞吐量、CPU使用率、扩缩容事件次数、错误率以及延迟波动性等关键性能指标。仿真结果表明，在高并发工作负载下，吞吐量可提升约10%至25%，而延迟在较高百分位数（p95–p99）下的改善更为显著，提升幅度约为10%至15%。此外，在高负载扩缩容场景下，弹性方面的提升可达约80%。

引言：在云计算环境中，无服务器计算是一种抽象出服务器管理的架构，允许开发者构建和运行基于事件的按需应用程序，从而在无需维护底层基础设施的情况下优化资源使用和成本。这种架构非常适合开发可扩展的Web、移动及物联网应用程序。尽管AWS Lambda[1]和Google Cloud Functions[2]等平台能够自动管理资源分配，但开发者仍需配置某些参数，以确保效率、安全性，并满足性能与成本要求。此外，无服务器架构中的自动扩缩容功能能够根据工作负载的变化动态调整资源，从而在不需人工干预的情况下提升灵活性、效率并节省成本[[3], [4], [5]]。在自动扩缩容方面，无服务器平台通常会根据每个应用组件在任何给定时间所处理的工作负载变化，实时做出水平扩缩容决策。这种方法主要适用于需要应对突发需求的应用部分，但也可用于其他类型的应用。无服务器解决方案提供了多种自动扩缩容策略，无需开发者进行干预即可控制弹性行为。不过，由于仍需对无服务器平台进行适当配置，这些方案会给云服务提供商带来一定的管理负担[[5], [6], [7], [8]]。鉴于手动驱动的扩缩容管理方案会带来管理成本、浪费资源，且常常违反既定的资源限制，因此有必要引入更敏捷、自动化的手段来管理动态且突发性的工作负载，从而实现在无需高级应用知识的情况下按需扩缩容[6,8]。在无服务器计算中，动态阈值面临着诸多挑战，尤其是在应对不断变化的工作负载时优化资源分配和性能方面。这些挑战包括不可预测的工作负载、对延迟的敏感性、成本管理、相互依赖的服务、实时定制需求、特定于应用的要求、工作负载的波动性、任务的临界性以及成本考量等。一些研究试图通过基于人工智能/机器学习的预测性扩缩容、事件驱动架构、自动调优算法、详细监控以及无服务器框架等方法来解决这些挑战。虽然这些策略有望提高扩缩容效率、减少人工干预并提升资源利用率，但目前仍有许多未被探索的途径[5,6,[9], [10], [11], [12]]。近年来，图神经网络（GNNs），包括图卷积网络（GCNs）和图注意力网络（GATs）等基于图的学习方法被用于在动态环境中建模复杂的结构化数据[13]。此外，还有诸如量子点元胞自动机（QCA）之类的新兴硬件级方法被提出，旨在为物联网系统设计低功耗、高能效的计算架构，从而在资源受限的环境中提升安全性并降低能耗[14,15]。选择TCP慢启动机制作为所提自动扩缩容机制的灵感来源，是因为它能够在保持系统稳定的同时，通过指数级的资源增长快速适应工作负载的变化。与基于预测和学习的方法不同，它不需要历史数据、模型训练或复杂的参数调优。这些特点使其轻量级、响应迅速，非常适合动态且不可预测的无服务器环境[16]。表1总结了选择TCP慢启动机制作为所提自动扩缩容框架基础的依据。与强化学习、基于LSTM的预测方法以及基于反馈控制的方法相比，TCP慢启动提供了一种轻量级且与模型无关的解决方案，具有极低的计算开销且无需训练。其指数增长阶段能够快速适应工作负载的变化，而其可控的扩缩容行为则有助于提升稳定性并避免资源过度分配。这些特点使得TCP慢启动特别适合无服务器环境，因为在这些环境中，响应速度、弹性、较低的运营复杂性以及对不可预测流量模式的快速响应都是至关重要的要求。像OpenFaaS和Knative这样的无服务器计算平台，能够根据工作负载需求动态分配资源，从而实现可扩展且成本效益高的应用执行。然而，传统的自动扩缩容机制往往依赖静态的CPU使用率阈值，这在工作负载高度动态且具有突发性的情况下，可能导致资源过度配置、配置不足、延迟增加以及资源利用效率低下。尽管HPA、KPA、KEDA以及XFaaS等自适应框架已提升了系统的可扩展性，但在实现快速响应式的扩缩容的同时，最小化冷启动、资源浪费以及性能不稳定问题方面，仍存在诸多挑战。虽然XFaaS也采用了受TCP启发的理念，但其核心目标与本文提出的方法有本质区别。XFaaS侧重于自适应并发控制、函数执行管理、减少冷启动、全局调度以及超大规模数据中心的资源优化。具体而言，XFaaS运用类似TCP的AIMD控制循环来调节请求接收率（每秒请求数），并通过下游的背压信号来控制执行的并发程度。相比之下，本文提出的框架则是通过直接控制函数副本的数量，来解决基于Kubernetes的无服务器环境中的自动扩缩容控制问题[17,18]。为克服这些局限性，本文提出了一种受TCP慢启动启发的、基于动态CPU阈值机制的Knative自动扩缩容策略。与传统基于阈值的方法不同，该方法会根据实时工作负载状况逐步调整CPU使用率阈值。该算法受到TCP拥塞控制原理的启发，最初以指数方式提升阈值，以便快速适应工作负载的增长；当资源使用率接近饱和时，则转为可控的线性调整模式。这种渐进式的容量发现机制能够在确保系统稳定的同时，实现快速决策以进行扩缩容。此外，我们的方法还引入了几项XFaaS未考虑的新特性，包括动态CPU阈值调整、对工作负载差异的感知、通过融合CPU和内存使用情况来进行多资源决策，以及受TCP启发的副本扩缩容机制。与调节请求执行速率不同，所提框架是根据工作负载特征和资源使用信号来动态分配资源，从而形成了截然不同的控制目标和决策机制。该方法已在基于Knative的无服务器平台上实施，并使用Hey负载测试工具在多种工作负载模式下进行了评估。性能评估采用了响应时间、吞吐量、CPU使用率、内存消耗、延迟百分位数以及系统稳定性等关键指标。实验结果表明，与传统的静态阈值自动扩缩容方法相比，所提出的动态阈值机制在保持系统稳定性的同时，显著提升了响应速度、吞吐量以及资源利用效率，尤其适用于处理突发性工作负载。此外，为解决上述潜在问题，本研究的主要贡献可总结如下：• 受TCP启发的动态扩缩容机制：我们为Knative提出了一种全新的动态CPU阈值自动扩缩容策略，该策略明确受到了TCP慢启动机制的启发。与传统静态或基于规则的政策不同，该方法引入了一种自适应的阈值演化过程，从而能够在高度动态的工作负载环境下实现既响应迅速又稳定的扩缩容。• 自适应阈值演化模型：所提方法采用双阶段控制机制，即在需求不断增加时通过指数增长实现快速适应，在负载持续较高时则通过线性调整来保障稳定性。这种混合设计有效减少了波动，提升了扩缩容的稳健性。• 具备工作负载感知能力的资源优化：该方法整合了实时监控驱动的调整机制，能够根据观察到的工作负载模式持续优化CPU使用率阈值，从而在提升资源利用效率的同时，避免资源过度配置或配置不足。• 全面的实验验证：通过在实际场景和模拟场景下（如Azure Functions数据集、FunctionBench以及Hey负载生成器）在Knative上部署应用，对所提方法进行了全面评估，且实验结果十分有力。本文的其余结构如下：第2节介绍无服务器自动扩缩容方案的背景，第3节阐述相关研究进展。第4节详细介绍所提出的方法。第5节则对所提方法的性能进行评估。第6节呈现实验结果。第7节探讨存在的问题与挑战。最后，第8节为结论部分。

背景部分：本节介绍了无服务器自动扩缩容方案的背景，重点阐述了水平Pod自动扩缩容器（HPA）和动态资源使用率阈值的相关内容。

文献综述：近年来，由于具有较高的效率且有助于优化性能，关于动态无服务器自动扩缩容环境的研究日益增多。本节回顾了与动态无服务器自动扩缩容方法相关的研究，最后还将通过表格对这些研究进行并列对比。尽管近年来无服务器平台的自动扩缩容技术取得了显著进步，但仍需应对诸多问题。

所提方法：本节将更详细地描述所提出的方法及其问题定义。该方法旨在实现多指标扩缩容，即同时响应请求率、CPU使用率和内存使用率，从而确保资源的最佳利用。显然，所提出的方法是一种确定性的、基于规则的自动扩缩容算法，其设计灵感来自TCP的拥塞控制机制，具有无需训练阶段、无需奖励函数、无需在探索与利用之间权衡等特点。

性能评估：本节介绍了所提方法实现过程中的若干重要方面，包括实验设置、性能指标以及负载生成器的相关信息。

实验结果：本节将讨论实验结果。值得注意的是，本节的所有图表都旨在对比OpenFaaS、Knative、Apache OpenWhisk中所采用的静态阈值自动扩缩容方式，以及所提方法中使用的动态阈值自动扩缩容方式。作为第一步。

挑战与未解问题：本节旨在强调现有研究中尚未得到充分关注的、与无服务器动态阈值相关的更为重要的挑战。虽然还存在诸如相互依赖的服务、实时调整以及特定于应用的需求等一些较少被探索的方面，这些都可以视为未来的研究方向，但本文更侧重于深入探讨工作负载的波动性、任务的临界性以及成本考量等问题。值得关注的是，有一些……

结论：无服务器开源自动扩缩容方法较为简单，其扩缩容决策主要基于请求队列的长度。该方法采用谨慎的缩减策略、指数级增长策略以及固定阈值。然而，那些依赖静态CPU使用率阈值的传统自动扩缩容技术往往会导致性能不佳，进而造成资源配置质量下降或延迟增加。另一方面，工作负载的快速变化又使得……

未引用参考文献：[[46], [47], [48], [49], [50], [51], [52]]

CRediT作者贡献说明：Mohammad Tari：撰写——初稿、可视化、方法论；Mostafa Ghobaei：撰写——审阅与编辑、资源获取、项目管理；Jafar Pouramini：验证、研究、数据整理。Mohammad Tari|Mostafa Ghobaei|Jafar Pouramini