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

　　在过去这几年，Apache Kafka的人气急剧上升。实际上，LinkedIn部署的系统最近每天处理的消息超过2万亿个，有 1800多台Kafka服务器（即代理，broker）。虽然事实证明Kafka很稳定，但是在规模如此庞大的环境下运行Kafka还是面临运维方面的挑战。代理每天都在失效，这导致我们的集群上工作负载不均衡。因而，网站可靠性工程师（SRE）投入大量的时间和精力来重新分配分区，以便让Kafka集群恢复均衡。

　　在这种情况下，智能自动化至关重要，这就是为什么我们开发了Cruise Control（https://github.com/linkedin/cruise-control）：这个通用系统可不断监控我们的集群，自动调整分配给集群的资源，以满足预定的性能目标。实际上，用户明确指定目标，Cruise Control负责监控有无违反这些目标，分析集群上的现有工作负载，并自动执行管理运维，以满足那些目标。你可以在此查看视频（https://www.youtube.com/watch?v=lf31udm9cYY），内容关于去年秋天的数据流处理大会上介绍的Cruise Control。

　　今天我们很高兴宣布开源Cruise Control，现在它放在Github上。我们在本文中将描述Cruise Control的一般用途和其在LinkedIn的用途、体系结构，以及我们当初开发它时面临的一些独特挑战。想进一步深入了解本文中使用的Kafka术语，这份参考资料（https://github.com/jet/kafunk/wiki/Kafka-Crash-Cource）大有帮助。

　　设计目标

　　我们当初设计Cruise Control时想到了几个重要的需求：

　　可靠的自动化：CruiseControl应该能够准确地分析集群工作负载，并生成执行计划，这些计划可放心地运行，根本不需要人干预。

　　节省资源：CruiseControl足够智能化，在执行操作时并不给集群处理正常工作负载的可用性带来负面影响，

　　可扩展性：Kafka用户对于部署的Kafka系统在可用性和性能方面有不同的需求，会使用不同的部署工具、管理端点和度量指标收集机制。Cruise Control必须能够满足用户指定的随意目标，并执行用户指定的操作。

　　通用性：我们很早就认识到，其他分布式系统也能得益于需要这类可识别应用的监控/分析/操作周期的类似的运维自动化。虽然一些现有的产品有助于集群中的资源利用率实现均衡，但大多数与应用无关，通过迁移整个应用过程来执行重新均衡。虽然这适用于无状态的系统，不过由于与这个过程有关的大量状态，面对有状态的系统（比如Kafka）时，它通常无能为力。因此，我们想要Cruise Control成为一种通用框架，可以明白具体的应用，只迁移部分状态，可以用在任何有状态的分布式系统中。

　　LinkedIn的CruiseControl

　　我们目前针对Kafka部署的Cruise Control旨在解决下列重要的运维和报告目标：

　　必须从磁盘、网络和CPU利用率方面不断均衡Kafka集群。

　　某个代理失效时，我们需要自动将该代理上的副本重新分配到集群中的其他代理，并恢复原来的复制因子（replication factor）。

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

　　我们需要支持低接触（low-touch）的集群扩展和代理停用。由于为集群添加代理或从集群删除代理后需要手动重新分配分区，这些操作原本很费劲。

　　能够运行配备异构硬件的集群很有用，比如说，缺少同样的硬件时，可以迅速修复硬件故障。然而，异构硬件加大了运维开销，因为SRE在均衡这类集群时，对硬件差异要非常留意。Cruise Control应该能够支持异构的Kafka集群和每台机器的多个代理。

　　它是如何工作的？

　　Cruise Control遵循监控/分析/操作这个工作周期。下图描述了Cruise Control的体系结构。许多组件是可插入的，如该图重点显示的（比如度量指标采样器和分析器等）。

　　REST API

　　Cruise Control提供了一个REST API，让用户可以与之交互。REST API支持工作负载查询和Kafka集群的优化方案，还支持管理运维的触发。

　　负载监控器

　　负载监控器（Load Monitor）从集群收集标准的Kafka度量指标，并根据分区获得并不直接可用的资源度量指标（比如根据每个分区估计CPU利用率）。然后，它生成一个准确记录集群资源利用率的集群工作负载模型，资源利用率包括磁盘利用率、CPU利用率、字节输入速率和字节输出速率，达到了副本的精细度。然后，它将集群模型馈入到检测器和分析器。

　　分析器

　　分析器好比是Cruise Control的“大脑”。它使用启发式方法，基于用户提供的优化目标和来自负载监控器的集群工作负载模型来生成优化方案。

　　优化目标拥有基于用户配置的优先级。优先级较高的目标比优先级低的目标更有可能达到。低优先级目标的优化并不会违反高优先级目标。

　　Cruise Control还允许指定硬性目标和软性目标。硬性目标是指必须满足的目标（比如副本布置必须做到可识别机架）。另一方面，软性目标可以不用达到，如果这么做可以满足所有的硬性目标。如果经过优化的结果违反了硬性目标，优化就会失效。硬性目标的优先级通常会高于软性目标。到目前为止，我们已实现了下列硬性和软性目标：

　　硬性目标

　　副本布置必须做到可识别机架。同一分区的副本放在不同的机架上，那样某个机架宕机后，任何分区顶多损失一个副本。这有助于控制故障边界，让Kafka来得更可靠。

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

　　网络利用率不得超过事先定义的容量，即便该代理上的所有副本都成为leader。在这种情况下，所有使用者流量将重定向至该代理，因而导致网络利用率高于平常。

　　软性目标

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

　　试图诸代理的leader分区都实现一致的字节输入速率（即来自客户端而不是来自复制的字节输入速率）。

　　试图将特定主题的分区均衡地分配到所有代理上。

　　试图将副本（全局性）均衡地分配到所有代理上。

　　目标优化逻辑大体上如下：

　　异常检测器

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

　　代理故障：即非空代理离开集群，这导致了副本数不足的分区。由于这在正常的集群bounce过程中也会发生，异常检测器在触发通知器、修复集群之前提供了一段可配置的宽限期。

　　目标违反：即违反优化目标。如果启用了自愈功能，Cruise Control会自动分析工作负载，执行优化方案，从而积极地试图解决目标违反问题。

　　执行器

　　执行器负责执行来自分析器的优化方案。重新均衡Kafka集群通常需要重新分配分区。执行器确保执行可感知资源，并不让任何代理不堪重负。重新分配分区还可能是个长时间运行的过程――在庞大的Kafka集群中，可能要好几天才能完成。有时候，用户想要停止进行中的分区重新分配。执行器采用了这样的方式来设计：执行方案时，可以安全地中断。

　　值得关注的挑战

　　我们在开发和使用Cruise Control时遇到了许多值得关注的挑战。下面列出了其中的几个挑战。

　　为Kafka打造一种可靠的集群工作负载模型

　　这不像听起来那么简单。有好多细节地方要注意。比如说，从代理收集CPU利用率的度量指标简单直观，但是我们如何量化每个分区给CPU利用率带来的影响？这个维基页面（https://github.com/linkedin/cruise-control/wiki/Build-the-cluster-workload-model）解释了我们是如何解答这个问题的。

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

　　分析器组件取得了巨大的进展。我们最初使用了一种通用优化器，带有复杂的参数化损失函数。在中等大小的Kafka集群上获得优化方案就算不需要数年，至少也需要数周。后来我们改用了目前的启发式优化器解决方案，这让我们在短短几分钟内获得了相当好的结果。

　　内存还是速度？

　　由于我们要将众多的度量指标保存一段时间（比如一周），以便分析Kafka集群中分区的流量模式，Cruise Control非常耗费内存。由于生成优化方案势必需要相应的计算操作，它还很耗费CPU资源。然而，那两个方面有点彼此冲突。为了加快生成方案的速度，我们想要处理更多的缓存和并行方案计算，但是这么做耗用更多的内存。我们最终做了一些设计方面的决定，以便兼顾两者。比如说，我们预先计算优化方案，并缓存起来，那样用户开始查询时，可避免长时间等待。另一方面，我们还错开内存密集型任务（比如方案预先计算和异常检测等）的执行，避免同时大量耗用内存的情况出现。

　　未来的工作

　　实现更多的Kafka集群优化目标！

　　由于Cruise Control的优化目标可插入，用户可能会根据需要，提出错综复杂的目标来优化各自的Kafka集群。比如说，我们在LinkedIn内部使用Kafka监控器，监控集群可用性。由于Kafka监控器根据每个代理向“监控器”主题发送消息的功能，报告代理的可用性，我们需要确保该主题的分区的leader覆盖所有代理。作为一个开源项目，我们还希望鼓励用户创建各自的目标，并将它们贡献给社区。

　　与云管理系统（CMS）整合起来

　　目前，Cruise Control通过从坏掉的代理迁移分区来修复集群。我们设想，Cruise Control有望与其他CMS整合起来，利用率达到某个阈值时，可自动扩展集群，或者必要时，用来自闲置代理池的新代理替换坏的代理。如上所述，我们欢迎社区献计献策，为这项未来的功能作出贡献。

　　借助洞察力助力运维

　　Cruise Control便于对从Kafka收集的度量指标执行深度分析。我们认为，它将让SRE能够量化各个资源使用率度量指标的影响，并获得洞察力，从而帮助容量规划和性能调优。

　　推而广之

　　我们在开发Cruise Control时就认识到，对任何分布式系统而言，动态的负载均衡机制是一种实用的工具。Cruise Control针对度量指标聚合、资源利用率分析和生成优化方案的各组件同样适用于其他分布式系统。从长远来看，我们希望抽取那些核心组件，将它们提供给其他项目。我们对Cruise Control怀有的愿景是，让人们可以与任何分布式系统轻松整合起来，为针对特定应用的性能分析、优化和执行提供便利。