18

当深度学习遇到了微服务; 微服务部署预测模型 - Cloud-Native 产品级敏捷

 4 years ago
source link: https://www.deva9.com/productagile/%E5%BD%93%E6%B7%B1%E5%BA%A6%E5%AD%A6%E4%B9%A0%E9%81%87%E5%88%B0%E4%BA%86%E5%BE%AE%E6%9C%8D%E5%8A%A1-%E5%BE%AE%E6%9C%8D%E5%8A%A1%E9%83%A8%E7%BD%B2%E9%A2%84%E6%B5%8B%E6%A8%A1%E5%9E%8B/?
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

当深度学习遇到了微服务; 微服务部署预测模型

photo-1574725954448-7fe2fe20461e.jpeg

微服务部署预测模型已获得国家知识产权局的专利; 专利号: 201910652769.4; 在 35 卷 4301 期 2019 年 10 月 22 日专利公报上予以公布。

我们应该永远的只将人工智能运用在解决 “最关键路径” 上的问题;也就是,只专注解决那些 “发生概率很低”, 但是一旦发生,其所造成的后果往往是很难去弥补的;例如: 会造成整个产品没法运作、整间企业没法运营⋯等等。

微服务开发所面临的最大的挑战, 是要能保证微服务在云端分布式环境下的运维的质量。

微服务布署预测模型主要是当新部署的微服务在预发布 (蓝线)的环境下时, 便能预测新部署的微服务未来在正式运维 (绿线) 的环境下, 是否会使得产品发生运维上的异常 ? 以提升新部署的微服务在云端分布式环境下的运维的质量。

微服务布署预测模型是以多节点分布式的环境下的 231 个运维度量, 1 分钟的时间间隔, 运用深度学习, 进行时间序列的运算。

现有保证新部署的微服務在云端分布式环境下的运维的质量的方案是: 

  • 针对新部署的微服务在预发布 (蓝线) 的环境下, 所收集到的关键度量的临界值; 如: 内存的使用率或是响应延迟的时间…等等, 判断新部署的微服务在运维 (绿线) 的环境下是否会使得产品发生异常 ? 
  • 针对在预发布 (蓝线) 的环境下新部署的微服务进行心跳测试; 在某时间段内对新部署的微服务发出一定数量的请求, 观察新部署的微服务在某时间段内回覆请求的数量。

现有的方案:

现有保证新部署的微服務在云端分布式环境下的运维的质量的方案, 有著以下的缺点:

  • 在云端分布式环境下, 不论是根据关键度量的临界值或是心跳测试, 往往都很难区分出新部署的微服务是已使产品发生异常或是产品仍是处于正常运行的状态 ? 例如:新部署的微服务虽发生响应上的延迟, 但其实产品还是处于正常运行状态的。

微服务部署预测模型:

微服务部署预测模型是运用深度学习中的 LSTM Networks ( Long Short-Term Memory Networks), 训练 LSTM 能分类出产品的异常或正常的状态, 并能预测 60 分钟后新部署的微服务是否会使得产品发生异常 ? 

图一: 微服务持续发布、持续部署

当微服务部署到预发布 (蓝线) 的环境时, 微服务布署预测模型便会预测新部署的微服务在未来的 60 分钟是否会使得产品发生异常 ?

所以, 微服务的开发团队便可根据微服务在预发布 (蓝线) 的环境下, 经历了 N 个的不会使产品发生异常的 60 分钟, 而可更有自信的将微服务部署到正式运维 (绿线) 的环境下。

图二: 微服务会部署在多个节点

微服务会部署在多个节点上, 所以, 微服务布署预测模型是根据微服务在预发布 (蓝线) 的环境, 多节点下的运维数据, 进行预测; 每笔运维的数据相隔一分钟的时间。

特征集: 花 90% 的时间找出那些在数据采标上成本最低的 Features

微服务布署预测模型根据在预发布 (蓝线) 的环境, 多节点下, 微服务与数据库的连接、CPU/内存耗用的情况、事务的状态、线程、交换, 作为预测的特征集。

特征集特征
微服务与数据库的连接微服务使用的数据库的连接数目
微服务建立一数据库的连接所需花费的时间; milliseconds
微服务从 JDBC 连接池中使用的 JDBC 的连接数目
数据库是启用或是禁用
微服务对数据库的连接请求的次数
微服务对数据库的连接请求失败的次数
微服务需先等待以获得一数据库的连接, 并且最终能成功连接数据库的次数
微服务需先等待以获得一数据库的连接, 最终连接数据库失败的次数
微服务调用数据库缓存的次数
事务微服务提交更改的次数
微服务回滚更改的次数
内存微服务使用的 JVM 堆内存
微服务使用的 JVM 棧内存
微服务最多可使用的 JVM 堆内存
微服务最多可使用的 JVM 棧内存
微服务最多可使用的内存
尚未使用的内存
CPU微服务 CPU 使用率
微服务线程的CPU 使用率
线程微服务堵塞线程数目
微服务守护线程数目
微服务全部线程数目
交换微服务的虚拟内存的使用率
微服务的内存交换到虚拟内存的空间大小; kilobytes
微服务所加载类的数目
微服务所卸载类的数目

LSTM 数据外形 (Shape):

图三: LSTM 数据外形 (Shape); N x D x T

LSTM 数据外形是 3D 的阵列; N x D x T

  • N = 样本的数目
  • D = 特征的数目
  • T = 在时间序列中, Time steps 的数目

将 Training datasets; anomaly_training_set; 的外形转化为:

  • N = len(anomaly_training_set) – 60
  • D = 231
  • T = 60; 预测新部署的微服务在未来的 60 分钟是否会使得产品发生异常 ?
K = 60
   for i in range(K, len(anomaly_training_set)):
       X_anomaly_train.append(anomaly_training_set_scaled[i-K:i, 1:])
       y_anomaly_train.append(anomaly_training_set_scaled[i, 0])

微服务布署预测模型 LSTM Network:

微服务布署预测模型 LSTM Network:

  • Time steps 为 60
  • LSTM layer 数目为 4
  • 每个 LSTM layer 包含 60 个 cells; 因为 Time steps 为 60
  • 每个 cells 包含 1500 个 units
  • Dropout 为 0.4

图四: 微服务布署预测模型 LSTM Network图五: 微服务布署预测模型 LSTM Layer; 1st LSTM Layer

微服务布署预测模型的输入数据是时间序列 (Time Series):

P: time steps= 60

N: 度量的数目= 231

图六:微服务布署预测模型 LSTM Layer; 1st LSTM Layer; 与时间序列 (Time Series) 的输入数据

微服务布署预测模型的训练与评估结果:

微服务布署预测模型是:

  • 采用 Adam 演算法, 进行 optimization
  • 以 mean squared error (MSE) 度量微服务布署预测模型的预测能力
  • 以每 1 分钟在预发布 (蓝线) 的环境, 多节点下的运维数据; 共 12,900 分钟; 进行 100 个 epochs 的训练; 训练时产生的 MSE = 0.189
  • 以另外的 9,912 分钟多节点下的运维数据, 评估微服务布署预测模型的预测能力; 评估时产生的 MSE = 0.196

图七:微服务布署预测模型的训练与评估结果

我们应该永远的只将人工智能运用在解决 “最关键路径” 上的问题;也就是,只专注解决那些 “发生概率很低”, 但是一旦发生,其所造成的后果往往是很难去弥补的;例如:会造成整个产品没法运作、整间企业没法运营⋯等等。

微服务布署预测模型可预测由多个分布式微服务实例, 所构成的 231 个度量的值,60 分钟后新部署的微服务会不会使得产品发生异常 ? 

微服务布署预测模型可完全的避免只是根据关键度量的临界值或是心跳测试, 所造成的产品是在正常、或是在异常间的误判。

微服务布署预测模型解决了微服务在持续部署、持续发布上 “信心度评估” 的难题; 使得微服务的开发能更有效率、更有质量、更有信心的完成持续部署、持续发布。

微服务布署预测模型预期将会成为微服务开发上的关键技术之一。


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK