cruisecontrol LinkedIn开源Kafka Cruise Control，旨在使Kafka实现大规模运维自动化！

作者简介:秦，领英高级软件工程师

在过去的几年里，阿帕奇卡夫卡的知名度急剧上升。事实上，LinkedIn部署的系统最近每天处理超过2万亿条消息，卡夫卡服务器(即经纪人)超过1800台。虽然事实证明卡夫卡是稳定的，但是在如此大规模的环境下运行卡夫卡仍然面临着操作上的挑战。代理每天都失败，这导致我们集群上的工作负载不平衡。因此，现场可靠性工程师(SRE)投入了大量的时间和精力来重新分配分区，以恢复卡夫卡集群的平衡。

在这种情况下，智能自动化非常重要，这也是我们开发Cruise Control(https://github . com/LinkedIn/Cruise-Control)的原因:这个通用系统可以持续监控我们的集群，并自动调整分配给集群的资源，以满足预定的性能目标。事实上，用户明确指定目标，巡航控制负责监控是否违反这些目标，分析集群上现有的工作负载，并自动执行管理操作以满足这些目标。你可以在这里观看视频(https://www.youtube.com/watch？V=lf31udm9cYY)，关于去年秋天在数据流处理会议上推出的巡航控制。

今天，我们很高兴地宣布开源巡航控制，它现在在Github上。在这篇文章中，我们将描述巡航控制的一般用途，它在领英中的使用，它的架构，以及我们第一次开发它时的一些独特挑战。这个参考(https://github.com/jet/kafunk/wiki/Kafka-Crash-Cource)对进一步理解这篇文章中使用的卡夫卡术语有很大帮助。

设计目标

当我们设计巡航控制时，我们想到了几个重要的要求:

可靠的自动化:CruiseControl应该能够准确地分析集群工作负载并生成执行计划，这些计划可以在完全没有人工干预的情况下安全运行。

节省资源:CruiseControl足够智能，可以执行操作，而不会对集群处理正常工作负载的可用性产生负面影响。

可扩展性:卡夫卡用户对部署的卡夫卡系统的可用性和性能有不同的要求，会使用不同的部署工具、管理端点和度量收集机制。巡航控制必须能够满足用户指定的任意目标，并执行用户指定的操作。

普遍性:我们早就认识到，其他分布式系统也可以从类似的操作和维护自动化中受益，这些自动化需要对这些可识别的应用程序进行监控/分析/操作周期。虽然现有的一些产品有助于平衡集群中的资源利用率，但大多数与应用程序无关，整个应用程序过程都是迁移来执行重新平衡的。虽然这适用于无状态系统，但当面对有状态系统(如卡夫卡)时，由于有大量的状态与这个过程相关，它通常是无能为力的。所以我们希望Cruise Control是一个通用的框架，可以理解具体的应用，只迁移一些状态，可以用在任何有状态的分布式系统中。

领英的巡航控制

我们目前针对卡夫卡的巡航控制部署旨在实现以下重要的操作和报告目标:

卡夫卡集群必须在磁盘、网络和CPU利用率方面不断平衡。

当代理出现故障时，我们需要自动将代理上的副本重新分发到群集中的其他代理，并恢复原始复制因子。

我们需要能够识别消耗集群中最多资源的主题分区。

我们需要支持低接触集群扩展和代理停用。因为在向集群添加代理或从集群中删除代理后，需要手动重新分配分区，所以这些操作很费力。

能够运行具有异构硬件的集群非常有用。例如，如果缺少相同的硬件，可以快速修复硬件故障。然而，异构硬件增加了操作和维护开销，因为SRE在平衡这种集群时应该非常注意硬件差异。巡航控制应该能够支持异构的卡夫卡集群和每台机器多个代理。

它是如何工作的？

巡航控制遵循监测/分析/操作的工作循环。下图描述了巡航控制的体系结构。许多组件是可插拔的，如图中突出显示的(如公制取样器和分析仪等。).

应用程序接口

巡航控制提供了一个允许用户与之交互的休息应用编程接口。REST API支持工作量查询和卡夫卡集群优化方案，也支持管理运维的触发。

负载监视器

负载监视器从集群中收集标准的卡夫卡度量，并根据分区获得不直接可用的资源度量(例如根据每个分区估计CPU利用率)。然后生成准确记录集群资源利用率的集群工作负载模型，包括磁盘利用率、CPU利用率、字节输入率和字节输出率，从而达到副本的精细度。然后，它将集群模型输入检测器和分析器。

分析器

分析仪就像巡航控制的“大脑”。它使用启发式方法根据用户提供的优化目标和负载监测器的集群负载模型生成优化方案。

优化目标具有基于用户配置的优先级。优先级高的目标比优先级低的目标更容易实现。低优先级目标的优化不会违反高优先级目标。

巡航控制还允许您指定硬目标和软目标。硬目标是必须满足的目标(例如，副本布局必须是机架可识别的)。另一方面，软目标不需要达到，如果硬目标都能达到的话。如果优化结果违反了硬目标，优化将失败。硬目标通常比软目标优先级高。迄今为止，我们已经实现了以下硬目标和软目标:

硬性目标

重复布局必须是机架可识别的。同一个分区的副本被放置在不同的机架上，因此在一个机架停机后，任何分区最多都会丢失一个副本。这有助于控制断层边界，使卡夫卡更可靠。

代理的资源利用率必须在预定义的阈值内。

网络利用率不得超过预定义的容量，即使代理上的所有副本都成为领导者。在这种情况下，所有用户流量都将被重定向到代理，导致网络利用率高于通常水平。

软目标

尝试为所有代理实现一致的资源利用率。

尝试为所有代理的引导分区实现一致的字节输入速率(即来自客户端而不是来自复制的字节输入速率)。

尝试将特定主题的分区平均分配给所有代理。

试图将副本(全局)平均分配给所有代理。

目标优化逻辑一般如下:

异常检测器

异常检测器可以识别两种类型的异常:

代理失败:即非-空代理离开集群，导致分区副本数量不足。由于这将发生在正常的集群反弹过程中，异常检测器在触发通知程序和修复集群之前提供了一个可配置的宽限期。

违反目标:违反优化目标。如果启用自愈功能，巡航控制将自动分析工作负载并执行优化方案，从而积极尝试解决目标违规问题。

执行机构

执行器负责从分析器执行优化方案。重新平衡卡夫卡集群通常需要重新分配分区。执行器确保可感知资源的执行，并且不会淹没任何代理。重新分配分区也可能是一个长期运行的过程——在一个巨大的卡夫卡集群中，可能需要几天才能完成。有时，用户希望停止正在进行的分区重新分配。致动器的设计应确保在执行方案时能够安全中断。

值得关注的挑战

我们在开发和使用巡航控制时遇到了许多挑战。下面列出了其中的一些挑战。

为卡夫卡创建一个可靠的集群工作负载模型

事情没有听起来那么简单。有很多细节需要注意。例如，从代理收集CPU利用率的指标既简单又直观，但是我们如何量化每个分区对CPU利用率的影响？维基页面(https://github . com/LinkedIn/cruise-control/wiki/build-the-cluster-workload-model)解释了我们如何解决这个问题。

你愿意等多久的优化方案？

分析仪组件取得了很大进展。我们最初使用了带有复杂参数化损失函数的通用优化器。在一个中等规模的卡夫卡集群上获得一个优化解决方案至少需要几周，如果不是几年的话。后来，我们切换到当前的启发式优化器解决方案，这使得我们在几分钟内获得了相当好的结果。

内存还是速度？

巡航控制会消耗大量内存，因为我们需要在一段时间(例如一周)内保存许多指标，以便分析卡夫卡集群中分区的流量模式。因为优化方案的生成必然需要相应的计算操作，也消耗了CPU资源。然而，这两个方面有些相互冲突。为了加快方案生成速度，我们希望处理更多的缓存和并行方案计算，但是这样会消耗更多的内存。最后，我们做出了一些设计决策，以平衡两者。例如，我们提前计算优化方案并缓存它，这样用户就可以避免在开始查询时等待很长时间。另一方面，我们错开执行内存密集型任务(如方案预计算和异常检测等)。)，从而避免大量内存消耗。

今后的工作

实现更多卡夫卡集群优化目标！

由于巡航控制的优化目标可以插入，用户可以根据自己的需要提出复杂的目标来优化他们的卡夫卡集群。例如，我们使用LinkedIn内部的卡夫卡监视器来监控集群可用性。由于卡夫卡monitor是根据向话题“Monitor”发送消息的功能来报告代理的可用性的，所以我们需要确保这个话题的分区的负责人覆盖所有代理。作为一个开源项目，我们也希望鼓励用户创建自己的目标，并将其贡献给社区。

与云管理系统集成

目前，巡航控制通过从损坏的代理迁移分区来修复集群。我们假设巡航控制预计将与其他内容管理系统集成。当利用率达到某个阈值时，它可以自动扩展群集，或者如果需要，用空闲代理池中的新代理替换坏代理。如上所述，我们欢迎社区为这一未来职能做出贡献。

用洞察力帮助运营

巡航控制有助于深入分析从卡夫卡收集的指标。我们相信，这将使SRE能够量化各种资源利用率指标的影响，并获得有助于容量规划和性能调整的洞察力。

同样

当我们开发巡航控制时，我们意识到动态负载平衡机制是任何分布式系统的实用工具。巡航控制的度量聚合、资源利用分析和优化方案生成组件也适用于其他分布式系统。从长远来看，我们希望提取这些核心组件，并将其提供给其他项目。我们对巡航控制的愿景是使人们能够轻松地与任何分布式系统集成，并促进特定应用程序的性能分析、优化和执行。