碧茂科技 | 基于人工智能的Apache Kafka自动化运维(一)

基于人工智能的Apache Kafka自动化运维(一)
+ 查看更多

发布日期：2021-01-08 14:44

这篇文章需要读者有一定的Kafka的背景知识，如果还不了解Kafka能做什么，技术原理是怎样的，可以参考其他例如Apache Kafka 入门类文章。

摘要

由LinkedIn主推，Cloudera和RedHat及其他社区贡献者协助出品的Cruise Control提供了基于人工智能的自动化Apache KAFKA集群运维能力。用户可以通过Cruise Control来极大的缓解KAFKA日常运维的工作，并使得企业的KAFKA集群更稳定，更高效，更智能。

Cruise Control在LinkedIn的实测的效果，在演示的期间， Cruise Control在数小时内自动的，渐进式的平衡和优化Kafka Broker的负载，不仅移除了一个Broker，同时还使得每个Broker的写入吞吐负载更加平均。

当企业的Kafka集群初具规模的时候，就要面临着如何高效的去调整已有的Kafka的性能，来扩展和稳定kafka的集群的性能。但是，随着Kafka的集群的节点扩充，或者集群个数增多时，会遇到很多分布式系统都会遇到的问题，例如，数据倾斜，硬件故障以及扩容/缩容时带来的各种前置操作和后置操作。

在LinkedIn负责KAFKA运维的Adem同学，本着能干一次就不干多次，能自动化就不手工的初衷，开发出了Cruise Control来代替他的小组完成大量的KAFKA 日常运维工作。

既然是人工智能的自动化运维，抛开系统本身的技术设计和能力，首先第一个要解决的灵魂拷问是，什么场景下这个自动化运维不可以执行任务？（例如终结者条款: “ Humans must not be killed “）。

这个在Cruise Control中被定义为”Hard Goals“。也就是当需要执行一项优化任务时，如果优化策略的结果会违反某些基线目标，则不可以执行

例如，当需要对一些Partition进行迁移的时候，需要首先确定是否违反了机架感知的”Hard Goal“,也就是不能将Partition的Replica都放在同一个机架内。如果执行结果会违反这个”Hard Goals“，则这个运维任务就不能执行。

常见的Apache Kafka运维的标准操作包含但不限于下述的一些任务：

降级Kafka Broker (移除这个节点上的所有的Leader状态)

触发Preferred Leader Election

添加/移除Kafka Broker/s

检查Broker和Partition的健康状态

由于每一个可能的优化方案都或多或少的会影响其他指标，因此Kafka的优化策略实际是一个在多影响因子下寻找全局最优解的问题。确定和实施更合理的优化策略是Cruise Control最终体现其技术价值的真实所在。

Cruise Control的工作原理

Cruise Control考量了一些常用的数据分析和机器学习方法，并且通过CPU，磁盘，Bytes In, Bytes out 这几个原始的参数生成了一套和Partition有关的衍生参数，并将这些参数用作一个线性回归模型的输入。当这个模型被训练好之后，会根据新的监控指标输入并结合模型给出预测的集群负载，并将这个模型的输出作为异常检测器的输入并进行故障判断和生成优化策略。紧接着优化策略会被交给策略分析器来评估是否可以采纳（例如是否违反“终结者条款“），最终再将通过的优化策略交给执行器来执行。

这里再稍微展开说明一下Curise Control的这四个环节中用到的子功能模块：

Monitor（监控模块）：

从Kafka上周期性的收集基础指标，并且基于这些指标和训练后的模型生成当前的负载模型。

Anomaly Detector （检测模块）：

用于根据监控模块的输出结果进行检测，其中包含了四个预定义的子模块——

Goal Violation：判断是否出现了优化不及预期。

Metric Anomaly：判断是否出现了指标异常。

Disk Failure：判断是否出现了磁盘故障。

Broker Failure：判断是否出现了Broker故障。

Custom：其他可插拔的，用户自定义的检测功能。

Analyzer （分析模块）：

用于优化策略和预设目标的冲突比对，如果优化策略会影响预设目标，则不执行该优化策略。如果不影响基线目标，则执行该优化策略。预置的优化策略包括了——