微服务(microservice, MS) 是面向服务系统结构(SOA) ^[1]的一种变体架构方式, 它将复杂臃肿的单一服务根据业务领域或架构等原因拆分成耦合性较低、可单独部署的较小组件或服务, 通过同步或异步的方式进行通讯^[2]. 由于微服务结构拥有降低故障影响、满足快速变化的业务需求、提高开发和运维效率等优势, 其已被业界广泛用. 随着电子商务浪潮的兴起, 企业用户越来越多的选择把服务部署在互联网数据中心(Internet data center, IDC) 以此节约成本、提高效率.

由于不同服务对于资源维度的需求存在多样性, 多个微服务部署于同一物理节点时可能出现资源消耗倾斜的现象. 例如某些数据操作型业务会对磁盘 I/O和网络带宽造成大量消耗, 对于内存和CPU资源的需求却低很多. 如图1为两个裸机节点CPU和内存资源利用率情况, 其中图1(a)所示节点资源消耗均衡, 而图1(b)上的资源消耗存在明显倾斜, 这种情况产生的资源碎片对集群的资源造成了浪费. 为了提高经济效益, 企业通常通过高效的调度算法进行动态资源管理和智能化容器部署方案, 尽量避免资源消耗倾斜, 让节点利用率处在最佳经济效益的状态区间.

在提供IaaS服务的公共云中, 已有研究者针对容器资源自动管理问题进行研究^[3-6]. Vinay等人^[7]提出使用结合按需点播和spot instance提出了一种新的混合自动缩放策略, 并未针对在线服务需求变化频繁的特点进行优化. Habib等人^[8]提出应用强化学习模型训练资源仲裁器和集群监视器的方式, 动态调整实例运行中的容器资源上限, 但这种方法没有考虑到微服务对资源消耗存在的特征, 使用过程中会频繁出现资源调整增加计算负担. John等人^[9]提出一种将工作负荷预测与Q学习相结合的优化算法. Schuler等人^[10]提出针对Kubernetes 容器下serverless服务, 使用Q-learning算法优化资源伸缩. 但该算法未使用深度神经网络对历史负荷进行感知, 且未针对容器资源利用情况进行优化^[11-14].

在实例部署到节点的过程中, 需要为容器申请资源. 虽然节点中的容器可以通过cGroup^[15]等技术共享内存和CPU等资源, 但是仍需要对容器使用上限进行限制. 在一条调用链中, 上游无状态服务的调用量激烈变化将对下游服务的调用量造成明显影响. 如果能感知上游服务的资源需求变化, 并提前合理的对下游高权重路径上的容器进行扩容/缩容, 将会极大提升调用链上的资源利用率. 如何合理地分配容器资源, 在实例Qos得到满足的条件下, 将节点的资源碎片率降到最低成为提升集群经济效益的关键问题之一.

深度强化学习具备高维数据特征感知能力、较强的自主决策能力, 常被用来解决复杂状态空间的决策问题, 常常在智能决策、实时仿真、游戏AI等领域发挥重要作用. 在本文研究中, 我们尝试使用深度双Q网络来决定容器资源分配策略, 让模型决定接下来一段时间内的容器资源上限, 进而达到释放节点资源碎片的目的.

本文使用阿里巴巴2021年发布的微服务交易跟踪作为主要数据来源, 通过对容器在裸机节点上资源消耗情况进行分析和对微服务在容器内的资源利用率进行整理挖掘, 我们发现容器资源分配存在不合理的情况, 进而导致裸机节点上的资源消耗倾斜, 产生资源碎片. 我们提出一种基于深度强化学习的调度模型, 通过对上游服务状态变化和节点资源消耗情况进行感知, 调整容器资源分配为手段, 有效提升了容器的资源利用率并缓解了节点资源消耗倾斜的情况.

1 跟踪信息 1.1 跟踪轨迹概览

尽管云计算资源管理和作业调度领域的研究受到越来越多的关注, 但公开可用的集群工作负载数据集仍然很少. 长期以来的主要开源数据集来源是: 谷歌集群跟踪^[16]和Facebook发布的SWIM跟踪^[17]等. 然而由于不同来源集群数据的异构性和特殊性使得其负载特征存在巨大差异^[18]. 阿里巴巴集团2018年至今发布更新一系列跟踪轨迹, 包含多种领域的标准化、多维度集群运行信息和任务特征信息^[19-22].

2021年发布的cluster–trace-microservices-v2021 (记为CTM21)^[23]记录了阿里巴巴大于一万个裸机节点上部署的近两万个微服务在12 h内的调用关系、运行状态、部署情况等详细信息. CTM21采用Kubernetes^[24]管理裸机云^[25], 微服务在容器中运行, 由Kubernetes直接调度. 本文采用CTM21作为数据分析来源, 为了方便读者阅读本文其余部分, 此处对本文用到的部分数据结构和内在关联进行简述.

(1) 节点资源

节点表(NodeTable.csv)记录了裸机节点的实时运行信息, 每条数据都含有时间戳(timestamp)、节点标识ID (nodeid)以及内存和CPU利用率. 某些节点未部署服务时处在关闭状态.

(2) 容器资源

微服务以实例(instance)为最小单位部署在容器中, 通常一个微服务需要多个实例同时部署以满足业务的需要. 实例所处容器在节点上的部署情况、容器的资源消耗情况被详细记录在微服务资源表(MS_ Resource_Table.csv)中. 其以时间戳(timestamp)对齐, 通过微服务名(msname)和服务实例名(msinstanceid)可获得实例与微服务的关系和实例运行资源消耗情况. 节点ID (nodeid)、容器CPU利用率和内存利用率获取实例的运行对节点的影响. 值得注意的是, 由于有状态服务在其他专用集群中运行, 此处记载的实例均为无状态服务.

(3) 服务调用关系

在响应时间/调用率表(MS_RT_Qps_Table.csv, RTQps)和调用图表(MS_CallGraph_Table.csv)中记录了上下游服务的详细调用信息. 为了让研究人员更好的分析微服务的调用关系特征, 调用图表记录了多于MS_Resource_Table和RTQps中的微服务运行记录.

1.2 微服务体系结构

不同的服务类型对资源的需求不同, CTM21采用在线服务和离线服务混合部署的方式, 提高裸机集群整体资源利用率. 图2(a)为CTM21集群体系结构, 裸机节点由Kubernetes分配POD进行资源管理, 其中POD部署了两种容器(container): 在线微服务容器和专门为离线任务提供服务的安全容器. 安全容器相当于一个轻量级的虚拟机, 通过将离线任务容器调度到“安全容器”中实现与在线任务容器的资源隔离, 从而有效降低彼此之间的互相干扰, 保证在线任务容器的服务质量(QoS).

在CTM21中根据状态不同, 微服务可分为无状态服务和有状态服务, 分别对应图2(b)中的圆形和平行四边形或圆柱体. 无状态服务对请求信息不予保存、服务无差别处理各个请求. 用户请求往往需要通过会话(session)、内存缓存(memCache)、数据库(database)等持久化层获取业务的上下文数据, 从而获得状态信息.

微服务之间的通信方式主要有3种: 进程间通信、远程RPC调用和异步调用. 当一次请求开始后, 将会触发涉及本业务的多个微服务之间一系列调用, 这些包含层级关系的调用被称为调用图(call graph). 两个服务之间存在调用和被调用关系, 调用发起者称之为上游微服务(upstream microservice, UM) , 调用承接者称为下游微服务(downstream microservice, DM). 图2(b)中所展示了一次请求的完整调用图, 它揭示了有状态服务与无状态服务之间的调用关系和调用方式. 图中的1号无状态服务调用2号持久化服务过程中, 服务1作为UM, 服务2作为DM. 在1号服务接收请求后, 通过与cache和database的通信进行数据读写, 在本服务处理完成后向下一层业务所需的无状态服务传递请求, 在所有业务完成处理后结束本次请求.

2 资源消耗特征分析 2.1 指标计算 2.1.1 相关性计算

皮尔森相关性系数(Pearson product-moment correlation coefficient, r)^[26], 是最常用的线性相关系数之一, 它常用来衡量两组变量的线性相关程度. r值介于 −1到1之间, 绝对值越大表明相关性越强. 其具体关系如下:

$\left\{ \begin{gathered} {\rm{strong}} \; {\rm{correlation}}, \qquad\;\;\;\;\; 0.8 \lt |r| \leqslant 1 \\ {\rm{correlation}}, \qquad\qquad\quad\;\;\;\; 0.3 \leqslant |r| \leqslant 0.8 \\ {\rm{weak}} \; {\rm{or}} \; {\rm{no}} \;{\rm{correlation}}\, , \, \, \, \, \, \, \, \, \, \, |r| < 0.3 \\ \end{gathered} \right.$

(1)

为了理解多组指标数据之间的逻辑关系并衡量影响程度, 我们将相关性系数作为一种分析手段, 用来分析不同维度的资源消耗关系.

2.1.2 资源碎片率计算

在理想的状态下, 假设宿主机同时拥有M种可用资源. 在某段时间之中, 由于其第i种资源到达部署上限, 而无法继续分配新任务时, 宿主机此时的资源碎片率 (debris rate, D)应满足:

$D{\text{ = }}\frac{{\displaystyle\sum\limits_{{{i = }}1}^{{n}} {\left(1 - \frac{{{\lambda _i} \times {U_i}}}{{{T_i}}}\right)} }}{M} \times 100{\text{%}}$

(2)

其中, U_i表示第i种资源的使用量, T_i表示第i种资源的总量, λ_i为第i种资源的权重.

资源碎片率可用来衡量资源使用情况, 碎片率越高意味着节点中被浪费的资源越多, 可优化空间越大. 在实际工作环境中对于容器而言, 为了保证服务QoS, 服务申请到的容器资源必须保证一段时间段内的峰值资源需求可以被满足. 为了满足其低频率出现的资源消耗峰值, 而申请远高于常态需求的资源, 会产生大量资源碎片. 对于裸机节点而言, 除了上述碎片来源外还有另一种情况: 节点在已部署部分容器后, 由于某个维度的资源已被容器预定达到阈值的而无法部署新的容器, 此时未被占满的其他种类资源均为碎片.

2.1.3 内存/CPU利用率差平均值计算

将跟踪轨迹的内存利用率和CPU利用率根据其时间戳对齐. 在长度为T的内存/CPU观测对序列中, 第i对观测值的内存利用率记为 ${M}_{i}$ , CPU利用率记为 ${C}_{i}$ , 则观测周期内的利用率差平均值G应满足:

$G = \frac{{\displaystyle\sum\limits_{i = 1}^T {|{C_i} - {M_i}|} }}{T} \times 100{\text{%}}$

(3)

通过计算内存/CPU利用率差平均值, 我们能够直观理解当前内存与CPU资源消耗的差距.

2.2 利用率变化原因分析

结合对部分节点中容器部署情况与服务调用图数据, 分析得到结论如表1. 集群资源利用率变化的主要原因是上游服务请求的处理和微服务部署变动. 不同类型的上游服务请求对于CPU与内存利用率波动分别存在不同程度的影响^[27], 而在没有请求需要处理的情况下MS的部署或释放对于内存的影响更加明显.

2.3 资源利用率相关性分析 2.3.1 数据处理与感知

将所有节点在全时段内的CPU、内存利用率按照时间对齐, 可整理为三元组结构. 对每个节点计算CPU和内存利用率的相关性系数, 以分析节点中的内存资源和CPU资源消耗关系. 将所有节点的结果按照相关性系数值从小到大排序后绘制得到图3(a). 图中纵坐标为相关性系数, 横坐标为其rank值. 由此将曲线划分为3个区域: 内存与CPU利用率呈负相关性区(r<−0.3, 记为A区)、若相关性或无关区(−0.3≤r＜0.3, 记为B区)、正相关性(r≥0.3, 记为C区).

表2记录了各区域所含节点信息. 由其可初步得出以下结论: 在观测样本中, 内存利用率波动情况比CPU更稳定. 在线请求往往对CPU的要求更高, 利用率波动也更为激烈. 当无状态服务部署达到稳定后, 内存使用情况普遍比较稳定, 只有在处理新计算型请求时会明显增加、处理完毕后触发内存回收才有可能出现大幅下降.

2.3.2 相关性区域特征表达

(1) 强相关性区域

在A区域中, 存在部分节点的内存、CPU利用率具有强烈或明显负相关性将这类节点中部分具有代表性的CPU、内存利用率按照时间戳绘制成图得到图4(a), 由其结合对具体节点数据的分析, CPU利用率波动主要出现在以下两种情况.

1) 利用率在多个相邻时间戳中出现较大幅度的周期性的增减, 且整体呈现下降趋势.

2) 利用率在某时刻开始崖式下跌. 由于内存利用率未随CPU利用率的整体下降而出现明显变化, 故其r值表现出负相关性.

容器调度对内存和CPU影响具有同期性, 推测此类节点的利用率波动来源是执行上游服务的请求而非容器调度.可由此理解为调度器将部分CPU需求变化复杂、内存需求稳定型服务部署在此类节点中.

C区域CPU/内存利用率呈现出正相关选取部分具有代表性的节点CPU/内存随时间变化的利用率曲线如图4(b), 结合instance部署情况, 我们发现: C区域中的r值极高部分的节点利用率波动主要原因是节点中instance部署情况变化, 导致的资源回收或资源分配. 当部署变化后, 内存和CPU变化呈现同期性.

(2) 弱相关或无关区域

由表2可知, B区域中稳定在较高的CPU消耗水平的节点数量较多, 观察其内存利用率均值、中位数和标准差均值可发现其内存利用率稳定在较高的利用率区间. 在B区观测时段内, 实例部署情况的变化较少.

2.4 利用率差分析

对第2.3节中得到的各区域CPU/内存利用率差平均值D进行计算分析, 发现D值在部分区间的节点数占比满足长尾分布^[28]. 尽管多数节点的 资源消耗较为平衡, 但在尾部仍有部分节点的资源消耗存在倾斜且不容忽视. 如图5(a)所示, 两张图横坐标是D, 纵坐标是D值对应节点数量占总数的百分比. 在图5(b)中展示了放大尾部的数据, 其节点数量占比随着r值增加而增加. D值处于0.5附近的节点较多, 区域具有较高的优化价值. 由表3可知, D值大于等于0.5的节点仍有百余个, 提升其资源平衡度仍有较高的经济价值.

在CPU/内存相关性高的区域, 出现CPU/内存差值均值大的概率就越高, 其资源消耗倾斜出现概率越大. 在优化容器调度算法时, 关注r值较高的区域, 通过变更节点上的资源使用情况, 减少资源碎片从而提升整体利用率.

2.5 实例运行特征分析

在MSResource系列文件中记录了无状态服务的部署详情和微服务实例在每个时刻的具体资源消耗情况, 同时还包括微服务与实例的映射关系. 如图6所示, 一个微服务可能部署了多个实例, 他们共同协作以满足服务的功能需求. 实例部署依赖于集群的调度策略, 一个微服务的实例可能因节点状态和服务优先级等因素影响而部署到多个节点上. 然而从服务调度关系的角度出发, 某些上下游服务之间的调用率远高于平均水平, 将这类实例部署到同一个网域甚至同一节点上可以大幅提高响应效率^[29].

图7是容器数量与资源利用率热力图. 调度器在一个节点部署容器数量集中在5–12之间, 让节点内存利用率集中在70%左右, CPU利用率集中在60%左右. 表4将节点和容器的资源消耗进行对比, 二者内存利用率差距并不明显, 然而CPU利用率却差别巨大. 容器的CPU使用均值和峰值比节点的对应指标低. 在部分容器CPU使用率上限为200%的情况下, 其峰值均值仍然徘徊在30%左右, 说明大量节点的CPU利用率处于低水平. 这也说明部分容器分配的资源不合理, 资源申请量高于周期内的实际使用量.

我们跟踪了节点中CPU利用率均值达到70%以上的2387个节点, 和低于30%的371个节点. 发现节点CPU利用率高, 其部署的容器数量越多且其容器的CPU利用率均值越高. 我们还寻找了资源消耗更偏向内存维度而造成CPU碎片率较高的1500个节点, 发现他们部署的容器CPU利用率均值仅为0.2922, 标准差均值为0.0625, 这说明这类节点资源消耗倾斜与其部署的容器CPU利用率偏低存在关联关系.

3 容器资源分配优化研究 3.1 深度双Q网络

Q-learning 通过学习最优动作价值函数Q*(s, a), 在给定状态s_t下求得最优动作, 其核心思想是查询Q表中s状态下所有可选动作的价值, 并选择价值最高的动作执行. 当状态和动作空间高维连续时Q表将变得十分巨大, 这对于Q表的维护和查询将变得极为困难. DQN使用人工神经网络近似模拟Q表, 可以有效地对连续状态与动作空间进行特征提取, 使得特征相似的输入会得到相近的输出, 让Q学习泛化能力更强. 使用价值函数决策与策略梯度、actor-critic等算法相比具有结构更简单、响应速度更快、可在线训练等特点, 更符合本文的应用环境.

在本文的问题中, 状态序列的前后关联性强. 为了减少这种关联性对训练造成的副作用, 我们使用了优先经验回放(prioritized experience replay) 技术, 将状态序列顺序打乱, 并优先学习高误差值的经验. 深度双Q网络(deep dual-Q network, DDQN) 是基于DQN改进而得来. 为了解决本文DQN训练中出现的非均匀高估值问题, 进一步加快训练速度和收敛速度而使用目标网络(target network) , 使用一个DQN用来控制agent并收集经验(transitions) , target network用来提供价值估计maxQ. 如式(4) 描述了DDQN的目标值计算过程:

${y_t} = {r_t}_{ + 1} + q \times ({s_t}_{ + 1}, \arg \mathop {\max }\limits_a q({s_{t + 1}}, a;{w_e});{w_t})$

(4)

其中, y_t表示目标值, γ表示折扣系数, w_e表示评估网络参数, w_t表示目标网络参数. 在步长达到C, 将评估网络权重整体更新至目标网络, 即使w_t=w_e.

3.2 MDP和人工神经网络结构

将若干连续时间视为一个决策周期, 智能体在获取到环境的状态反馈后按照一定策略进行下一步动作, 这类问题可以使用马尔可夫决策过程(Markov decision process, MDP) 来进行建模. 本文方法中的 MDP可以被定义为一个四元组, 用S, A, P, R表示, 分别代表状态空间、动作空间、状态转移函数和奖励函数.

3.2.1 状态空间

状态空间定义为一个三元组, 表示如下:

$s = \{ {I_{{\text{um}}}}{\text{, }}{I_{{\text{current}}}}{\text{, }}{I_{{\rm{node}}}}\}$

(5)

其中, I_um 代表上游系列服务的性能指标, I_current代表容器当下的状态, I_node代表所部署节点的性能状态. 图8描述了状态转移的过程, s₀是初始状态, 经过某次动作a后以概率p到达s'并最终在终止状态s_t停止转移.

在模型的输入层包含两类数据: 智能体所处的状态信息 ${s}_{t}$ 中环境给出的上游服务状态 $I _{{{\rm{um}}}_t}$ , $I_{{{\rm{um}}}_t}$ 是一个容器的所有直接上游服务状态加权指标向量, 见式(6). CPU_{avg_θ}, CPU_{max_θ}, MEM_{avg_θ}, MEM_{max_θ}分别代表CPU和内存在对应周期内的加权平均值和加权最大值, G_θ代表CPU和内存利用率差值平均值(见式(3)) , T_θ则是上游服务吞吐量加权和.

$\begin{split} {I_{{\text{um}}}}_{_{{t}}} = &{{(CP}}{{{U}}_{{\text{avg\_}}}}_\theta , {{CP}}{{{U}}_{{\text{max\_}}}}_\theta , {{ME}}{{{M}}_{{\text{avg\_}}}}_\theta ,\\ &{{ME}}{{{M}}_{{\text{max\_}}}}_\theta , {{{G}}_\theta }, {{{T}}_\theta }{\text{)}} \end{split}$

(6)

例如, 图9所示的容器D拥有3个直接上游服务, D在观测周期内的调用全部来自UM_a、UM_b、UM_c, 其调用次数分别为a, b, c. 则t时段内三者所占权重分别是:

${\theta _a} = \frac{a}{{a + b + c}}, \; {\theta _b} = \frac{b}{{a + b + c}}, \; {\theta _c} = \frac{c}{{a + b + c}}$

(7)

其计算方法见式(8) , 其中N_i为第i个上游服务对本服务的调用数量, $\displaystyle \sum {{N}}$ 是本服务的被调用数之和.

${\theta _i} = \frac{{N_i}}{{\displaystyle\sum N }}$

(8)

3.2.2 动作空间

在本模型中, 智能体决定在下一时间段内, 容器各维度资源分配上限变化情况. 动作空间的定义见式(9):

$A = \{ ad{d_i}, reduc{e_j}, kee{p_k}\}$

(9)

其中, add_i表示对容器中第i个资源维度的上限进行扩容动作, reduce_j表示同时对第j个资源维度的上限进行缩容动作, keep_k则代表了保持第k个资源维度的上限不变. 在扩容和缩容动作中, 具体执行的扩缩规格应根据容器所在环境决定.

本文探讨CPU与内存两种资源维度情况下的优化问题. 以CPU内核分配数量 $R_{CPU}$ 为例, $R_{CPU} \in ( 0, n]$ 根据可部署节点的最大可用内核数做调整. 将多个维度的资源上限离散化后做向量叉乘, 得到的结果向量即可作为动作空间, 这样可以保证每次的动作选择不会超出动作空间, 简化神经网络输出层的设计. 我们使用最大置信度上界(UCB)方法平衡探索和利用, 如式(10) 所示, q_a是动作a的初始评估价值, n是所有动作执行次数, q_a是a动作执行的次数, c是平衡系数. 通过UCB算法, 我们期望智能体更趋近于探索从未选择过的动作.

${q_{UCB}} = {q_a} + c \times {n^{\tfrac{1}{2}}} \times {n_a}^{ - 1}$

(10)

3.2.3 价值函数和更新策略

在本问题中, 智能体既要对容器本身的资源使用情况进行维护, 还要参考节点资源碎片和资源倾斜等情况. 智能体在S状态下做出a决策后, 奖励R表达形式如式(11):

$R(S, a) = \left\{ \begin{aligned} &\frac{{{\alpha _0} \times \ln (K + 1)}}{{{R_{{\rm{container}}}} + {R_{{\rm{node}}}} + {\beta _0}}}, \; {\rm{Not}} \; {\rm{overflow}} \\ & - C, \qquad\qquad\qquad\quad\; {\rm{Overflow}} \\ \end{aligned} \right.$

(11)

当周期内容器正常运行时, 根据式(11)计算奖励. 若某时段内的容器资源需求溢出, 将会给予负数奖励并立即结束当前动作周期, 开始新动作选择. 在公式中, K是所有维度连续选择keep动作的周期数量, 我们称为动作惯性量. 我们鼓励智能体尽可能多的减少扩容和缩容行为, 原因在于资源上限的变更将加大容器被重新调度的概率, 这相当于增加了集群开销. 动作惯性系数α∈(0, 1), C、β₀是平衡常数.

R_container是根据容器运行指标综合评估而得, 具体见式(12) . 其中, CPU_avg、CPU_max代表容器在t时段内的CPU平均值和最大值.MEM_avg、MEM_max是内存平均值和最大值. G_container是对应时段容器中的利用率差值平均值, 计算方法见式(3) . 通过R_container衡量t时段内动作a_t对容器产生的影响. 我们鼓励容器在每个决策时段内的利用率都尽量接近所分配的资源上限, 并且必须保证节点内的资源倾斜程度尽量降低. γ_i是平衡系数.

$\begin{split} &{R_{{\text{container}}}} = \\ &\frac{{{\gamma _1} \times CP{U_{{\rm{avg}}}} + {\gamma _2} \times CP{U_{{\rm{max}}}} + {\gamma _3} \times ME{M_{{\rm{avg}}}} + {\gamma _4} \times ME{M_{{\rm{max}}}}}}{{{\gamma _5} \times {G_{{\rm{container}}}}}} \end{split}$

(12)

R_node是容器所部署的节点运行指标综合评估而得, 具体见式(13). D_node是节点在对应时段内的资源碎片率, 其计算方式见式(2). G_node是节点在对应时段中的CPU和内存利用率差值平均值. 我们希望容器所部署的节点能够产生尽量少的资源碎片, 提升其资源消耗的平衡性. γ_i是平衡系数.

${R_{{\rm{node}}}} = {\gamma _6} \times {G_{{\rm{node}}}} + {\gamma _7} \times {D_{{\rm{node}}}}$

(13)

关于更新策略, 考虑到容器在某时刻出现的动作, 其原因可能是之前的动作不合理导致的. 如图10为了让智能体的动作拥有更加长远的考虑, 我们使用式(14)求得的t时刻奖励r_t的折扣值 $r'_i$ , 对之前m次动作进行折扣更新, 其中i代表被折扣的奖励.

${r'_i} = \left\{ \begin{gathered} {r_t}^{\tfrac{1}{{t - i + 1}}} , \, \, \, \, \, \, \, i < t \\ {r_t} , \; \; \; \qquad i = t \\ \end{gathered} \right.$

(14)

图11所示, 对神经网络输入以下类数据: 环境反馈的容器当前状态、节点当前状态、上游服务加权状态向量, 经过5层CNN网络提取特征后, 进入2层全连接层, 最后是动作空间映射. 我们的实验中, 动作空间是离散的. 为了简化模型的实现, 我们把智能体在每个状态下的可选择的行动制作成了表格. 每个容器最多申请4个CPU核心和4 GB内存.

本文使用CloudSim仿真框架^[30]作为实验平台, CloudSim是一个用于在云计算中建模、模拟场景的工具包, 它可以模拟出机器的负载情况和容器调用情况. 我们对CloudSim进行了扩展, 重写了其中部分方法, 增加其作为智能体运行环境, 计算并反馈节点状态、容器状态、上游服务加权向量的能力. 我们以JSON格式在Java开发的CloudSim与Python训练的智能体进行数据交互, 在CPU和内存两个资源维度进行实验. 如表5, 我们在CloudSim中设置了两种资源规格的节点, 以此降低由资源规格不合理对消耗倾斜的影响. 由于模型将节点的运行情况作为状态空间的一部分, 为了让模型更具普适性, 我们在容器的调度上选择了2种经典调度算法: 先到先匹配算法(FF)和最高降序调度算法(FFD). FD是选择每次放置容器后资源碎片率最低的节点进行调度. 两种容器调度算法各控制一半数量的节点.

我们根据CTM21的调用关系和容器利用率信息, 整理出分布在330个拥有不同特征的完整调用链上, 共计1722个容器的仿真数据. 每个容器利用率信息数据均包含1440个时间周期, 每个周期内提供了本阶段的CPU需求量和内存需求量. 这些仿真数据共2个文件: 记录了调用关系信息的calltable.csv, 其中字段包括了timestamp、UM、DM等. 记录容器运行状态的containerState.csv, 其中字段包括timestamp, containerID, cpuNeed, memNeed, 二者根据timestamp对齐, DM是containerID的外键. 实验中我们使用MySQL存储实验数据, 以便于在CloudSim中快速查询状态信息等数据. 为了加快模型收敛速度, 我们在开始的阶段使用了小规模数据样本进行初始化训练. 将每一个epoch的长度控制在64步之内, 通过挑选出30组具有代表性的调用链数据, 我们在11个节点上部署了225个容器, 对智能体进行了100轮的初步训练.

如图12(a)显示了epoch=1000的训练结果. 由于采用了小样本训练初始化了网络参数, agent在训练初期表现出比较好的水平. Agent在经过650轮训练后, 奖励逐渐收敛于91.5分. 在前200轮训练中, agent表现出的不稳定性主要来自于使用UCB算法对未知动作的探索. 此情况说明预训练好的网络模型对收敛速度起到了正向作用.

在实验过程中, 我们发现如果K值设置过高, 将导致智能体更倾向于在前几个动作空间就做出较大的资源占用, 使整体资源利用率偏低, 而K值设置过低则会出现容器QoS低下, 经常出现CPU占用超出设置上限的情况. 经过几轮调整得到的一组较为均衡的参数, 其QoS在训练过程中变化情况见图12(b). 其中纵坐标为容器出现资源需求超出分配份额的决策周期占全部决策周期的比例. 在epoch达到800后, 出现容器分配资源不能满足需求的情况占到3.32%, 容器的平均可用情况达到了96.68%.

为了对比观察模型效果, 我们设置了2种其他虚拟机配置选择方案. 最小选择法(MS) 是在所有规格的容器中默认选择最小配置进行初始部署, 当出现资源需求超出上限的情况时, 选择更大一号的资源配置. 随机部署法(MN) , 根据MS方法运行后产生的配置数量生成选择概率. 新容器按概率选择一款配置, 当资源需求超出上限时, 选择更大一号的资源配置. 我们为这两种选择算法添加了4个不同的容器规格见表6. 模型可以选择任意小于4核的CPU和小于4 GB的内存, 内存调整粒度是1 GB.

将训练好的DDQN模型和两种经典算法使用170组容器数据进行测试, 对比结果见表7. 因CTM21是真实生产轨迹数据, 其集群使用了资源共享等技术, 并且其资源细分的粒度要精细于仿真数据, 故此处实验结果不能直接同第3节的轨迹分析结果直接对比. 我们参考DDQN与MS、MN的结果, 分析得出了以下两个结论.

1) 本文提出的DDQN模型, 其CPU利用率和内存利用率远高于其他两种经典算法, 原因在于DDQN能够根据状态s动态调整容器资源上限, 当容器处于低效运行时, 模型将回收部分资源以达到贴合容器运行特征的效果. 而其他两种模型则仅有资源扩展, 没有资源回收功能.

2) 在容器资源使用维度观察, 本文的DDQN模型CPU利用率远远高于对比算法MS和MN, 而内存利用率DDQN与MS相差并不明显. 由于MN倾向于初始就选择较高的配置, 所以其资源利用率最低. 得益于对容器的资源管理, DDQN在节点维度的表现比较优异, 它有效缓解了节点资源消耗倾斜的情况, 相比于MS算法的明显倾斜, DQN将节点利用率差值均值控制在了11%.

由此可知, 与经典算法相比, 具备资源回收功能的DDQN方法在资源利用率方面和节点资源碎片率方面都拥有明显优势. 它的部署手段更加灵活、集群状态感知更加敏感. 虽然在QoS达标率方面, DDQN获得了远高于其他两种方法的成绩, 但低于训练数据的96.68%, 模型可能对训练数据拟合较高. 且其资源上限变更占比在所有方法中最高, 频繁变更容器上限将对容器在节点上的部署造成压力, 这些问题有待后续研究优化.

4 结论与展望

本文通过对CTM21轨迹数据的分析, 发现大规模集群中的节点存在资源消耗倾斜的情况. 深入挖掘其原因, 我们发现容器资源分配过量是导致节点资源消耗倾斜的原因之一. 由此我们提出了一种基于深度双Q网络的容器资源优化模型, 通过对上游微服务的运行情况和容器状态进行感知, 让智能体对容器资源分配进行自动维护, 以达到优化容器资源利用率、改善集群节点资源消耗倾斜的情况. 随后使用CTM21数据制作的仿真数据在CloudSim仿真环境中对模型进行了验证. 经过验证, 本文提出的模型可以在较大规模的集群环境中, 针对复杂的服务调用环境提供有效的容器CPU——内存资源管理、并对节点的资源倾斜起到调整的作用, 提高了节点运行效率, 能够有效节约集群运行成本.

考虑到影响节点资源消耗平衡因素的多样性, 后续工作将从优化容器部署角度和增加资源维度的方面入手. 尝试通过对调度时机选择、调度对象的选择以及加入容器网络带宽、硬盘I/O等资源的管理, 进一步优化节点的资源消耗情况, 提升集群整体经济效益.