基于马尔可夫性的云原生应用资源动态分配策略的研究

曲左阳 王伟萌 朱韦桥

（中国铁道科学研究院集团有限公司电子计算技术研究所 北京市 100081）

云化数据中心应用系统自适应资源动态预分配机制能有效提高信息系统稳定性，配合其他运维手段可降低集群能耗，具有较高的研究价值。本文研究是在掌握云原生的资源走向的同时，对计算资源、网络资源等多个资源实体进行操作和管理。资源管理的范畴包括生命周期、虚拟机状态计算、资源分布等。资源动态适配的目的是信息系统工作负载的合理运用以及云端资源的高效分配。从业务角度出发，研究资源动态匹配技术对信息系统服务质量的进一步发展具有长远的意义。

云计算中的资源调度问题有两个主要视角：来自基础设施资源池和来自应用服务。从基础设施资源池的角度来看，调度策略应该具有收敛边界并降低维护和能耗成本。已有研究表明，云原生应用的资源动态分配策略不可能通过使用简单的算法或规则找到全局最优解。而采用近似方法或深度学习方法，结果不可预测或需要大量的工程成本，这在实际环境中不实用。此外，大量信息系统堆叠后的工作负载的产生可能过于复杂，取决于环境的业务方向，因此很难找到一种通用的资源调度策略能够很好的应对各类业务场景，因此本文试图通过从铁路主数据中心既有的应用运行情况研究资源调度特征结合事件驱动思想，建立一个适用的资源分配模型。

1 主数据中心信息系统资源调度方式

在传统模式下，资源管理的方式是将物理或者虚拟的操作系统分配给用户，通常是使用专用的配置管理工具来进行安装和部署软件，然后通过标准化、自动化的工具达到简化处理流程的目的。定额分配资源模式难以支撑业务发展，围绕如何有效调整资源配置，提高资源利用率这一问题，国内外开展可一系列研究，提出了很多基于CPU 利用率、内存使用占比的资源配置方案，或者根据资源预测模型，结合热迁移技术对资源进行垂直伸缩，达到动态分配资源提高资源利用率的目的。AWS 提供了Lambda 商用计算服务在可用性高的计算基础设施上运行用户代码，执行计算资源的所有管理工作，其中包括服务器和操作系统维护、容量预置和自动扩展、代码监控和记录。该服务实现只在需要时执行代码并自动缩放。

云原生数据具有数据容量大，种类繁多，对数据处理时效性要求高的特点，目前运维团队已经开展了响应的云环境下智能运维关键技术研究，其中在监控智能化和感知分析领域进行了较多的工作，对云环境下基础设施运行状态进行监控，并依托于Hadoop 环境、ELK(Elasticsearch,Logstash, Kibana)架构和传统Zabbix 数据监控环境。但此类工作的最终目的在于应对系统的故障分析与定位处置，虽然从被动运维向主动运维不断发展，但对于应用系统层面的资源响应力度不足，对于应用系统因部分资源短板导致的服务降级缺乏敏感性。

目前，企业私有云资源响应机制主要是通过用户侧与开发运维侧共同完成，资源响应机制如图1 所示。由于目前虚拟机计算资源无法跨宿主机调配，所以没有进行服务拆分或服务拆分粒度较大的应用系统，在资源告警引发服务降级时，依然要面临垂直扩容和迁移，虽然这一过程可通过技术手段实现了自动化处理，但依然存在两个较为显著的问题，第一是资源配置响应时间内，应用系统服务会降级或熔断；第二是部分应用运维团队会以应用系统峰值流量水平超量申请资源导致资源的闲置和浪费。

图1：铁路主数据中心资源响应策略

2 动态分配策略的业务量特征分析

以本文研究的铁路主数据中心为例，所承载业务可归属分类为6 个领域，且已有研究表明，旅客运输，铁路建设等业务领域具有明显的周期性波动，因此对于业务压力导向的资源需求变动可以将信息系统对于资源的需求划分为离散的有限状态。本文仅讨论计算资源的动态分配策略，并由遵循下列假设：

有余量资源可供应用系统直接扩容；

每一个工作任务都可以在有限的时间内完成处理。

收集主数据中心某可用域内三套系统50 周监控数据，取其中CPU 监控数据分别记为PC PM PQ，以自然周作为时间维度，对数据进行切片，对数据进行标准化处理和等比例赋权，具体方法如下：

系统CPU 使用频率{{PC, PM, PQ|n∈R}}；对于任意时间点n，0

将三类监控数据标准化后等比加权，作为特征变量，即

其中 X∈{C,M,Q};且0< n < 50，均值为m 标准差为s

根据特征变量均值回归特性，设定分级如表1 所示，依据特征值偏离程度进行分级。

表1：分级标准

根据上述描述对数据进行处理如下：

依据表 2, 得到该集群加权CPU 利用率的均值m=9.269，标准差 s=5.388，由于集群在该阶段的CPU 利用率较为平稳，为便于观察将其划分为极低利用率、低利用率、高利用率、极高利用率4 个状态，可将该时段内信息系统资源用量划分为如表3 所示的4 个状态。

表2：50 周特征数据及状态

表3：系统状态分级

可采用卡方统计量对上述加权CPU 利用率序列进行马尔可夫性检测, 设研究序列包含 c 个可能的状态用

f(i,jϵE)记为转移频数概率矩阵，边际概率P的计算方法如下：

表5：卡方统计量计算

转移概率矩阵元素为P(i,jϵE)，卡方统计量可做如下计算：

若卡方分布统计量服从自由度为(c-1)，通过查询卡方分布表，在给定置信度α 下，若

则拒绝零假设，认为该集群加权CPU 利用率具备马尔可夫性

根据表2 可知：

α=0.05，c=4

一步转移概率矩阵为：

一步转移频数矩阵边际概率见表4。

表4：一步转移频数边际概率

拒绝0 假设，检验完成。

上述结果采用CPU 利用率进行计算，在实际生产环境中，针对无状态应用可采用更加细致的监控数据，如数据库或缓存的计算资源使用情况。

3 资源动态分配模型设计与验证

3.1 模型设计

通过信息系统既有监控数据，依据当前状态输出资源预分配策略是模型设计的主要目的。当状态发生转换时，已预先完成资源配置。为此需要明确策略前端的输入源、状态转移概率阈值以及扩展策略。

设某系统的资源用量离散状态空间为S，每种状态对应的资源用量阈值为TS，在当前监控状态下选择最大转移概率的状态进行资源分配，资源动态分配策略为：

可以将各类随机事件的状态值作为输入源数据，主要分为如下四类：

系统事件：CPU 内存等计算资源变动产生的事件，如利用率告警事件；

平台事件：云平台变动产生的事件，如平台负载变动事件；

监控事件：应用监控事件，如从Prometheus 等监控平台消费事件；

中间件事件：由应用系统中间件产生的事件，如数据库，消息队列产生的事件；

外部事件：在上述事件之外提供外部事件扩展，如通过gRPC 的事件扩展。

同时在模型内部设置两个关键角色，用来平衡模型边界：

阈值适配：一种阈值指标服务，暴露了大量与事件相关的数据， 例如队列长度，允许基于事件的扩展，消耗特定类型的事件数据。阈值适配与HPA 等云平台扩缩容机制进行通信，以驱动平台部署副本的扩展。然后由部署直接从源头消费事件。这样可以保留丰富的事件集成，让完成或丢弃队列消息之类的可以立即使用。

扩展策略：支持激活、注销和动态伸缩，在没有状态事件情况下将资源实例数量缩减注销至零。扩展策略还可以用于检测是否应激活或取消激活部署，然后将其反馈送到特定事件源中，模型部署如图2 所示。

图2：资源动态分配机制

3.2 模型验证

模型验证主要评估面向无状态应用服务的集群资源响应效果、资源分配策略的准确性和扩容的响应时间。

选择部署于独立区域的系统K 的CPU 利用率监控数据作为模型验证的输入数据源，累计收集数据量372 天，使用其中186 天数据按照表1 分级标准确定状态，并计算状态转移概率矩阵。使用剩余186 天的数据进行验证。如图3 所示，下方滑块代表所用数据的切分，折线主图内对于所有数据进行按天的均值上采样，可以看到，由于测试系统的CPU 利用率最大峰值在50%之下，任务量整体不活跃，资源分配策略以缩减或维持实例数量为主，仅在部分突发任务时下发正向扩容策略。这说明，该策略具有一定的贪婪性响应，虽然可以适用业务激增的场景，但存在部分资源浪费的情况。

图3：CPU 利用率与资源分配曲线

计算策略结果的资源分配增量和CPU 利用数据的皮尔逊系数为0.56，模型策略的最终分配结果表明，本文设计的信息系统资源动态分配策略的预分配结果与信息系统业务量后续变化水平具有一定的相关性。

4 结语

包括铁路主数据中心在内，大多数云平台的资源动态分配问题都可以归类为非确定多项式完全问题，在多项式时间内求解较为困难，本文尝试基于系统的业务特性，将系统的资源需求划分为有限状态，每个状态固定资源增量，通过状态转移概率，对下一周期的资源需求状态进行预分配，这是一种在响应精度和应用效率之间的折衷；模型最终的分配结果呈现资源贪婪性，虽然对于缩容较为友好，但在一定程度上增加了数据中心的能耗，并存在一定的概率导致资源利用率较低。因此，要在资源响应的稳定性和资源利用之间进行平衡，研究如何增加贪婪权重系数是进一步工作的方向。