Apache Kafka的4个混沌工程实验 | IDCF
DevOps
共 8074字,需浏览 17分钟
·
2021-07-14 20:17
来源:混沌工程实践 作者:李大山 原文作者:Andree Newman 原文来源:Gremlin.com 原文标题:The first 4 chaos experiments to run on Apache Kafka
Apache Kafka是一个开放源代码的分布式消息传递平台,高吞吐量和低延迟交付数据。在规模上,它每天可以处理数万亿条记录,同时还提供容错、复制和自动灾难恢复功能。
尽管Kafka有许多不同的使用场景,但最常见的是作为应用程序之间的消息broker。Kafka可以从多个上游源头接收、处理和重新分配消息到多个下游使用者,而无需重新配置应用程序。这就可以流式传输大量数据,同时保持应用程序的松散耦合,支持诸如分布式计算、日志记录和监控、网站活动跟踪以及物联网(IoT)设备通信之类的场景。
由于Kafka提供了应用程序之间的关键管道,因此可靠性至关重要。我们需要计划来减轻几种可能的故障模式,包括:
消息broker中断和其他不正常的群集状况; Apache ZooKeeper失效,这是Kafka的关键依赖项; 上游和下游应用程序中的故障。
一、Apache Kafka架构概述
二、为何要对Kafka进行混沌工程?
三、在Kafka上运行混沌实验
第一步:设定假说要回答的问题以及预期结果是什么。例如,如果实验是测试承受broker中断的能力,则假说可能会指出:“如果broker节点发生故障,则消息会自动路由到其他broker,而不会丢失数据。” 第二步:定义爆炸半径,受实验影响的基础架构组件。减小爆炸半径限制了实验可能对基础架构造成的潜在危害,同时还可以将精力集中在特定系统上。我们强烈建议从尽可能小的爆炸半径开始,然后随着对进行混沌实验的适应性提高,将其增大。另外,还应该定义幅度,即注入攻击的规模或影响力。例如,低幅度的实验可能是在生产者和broker之间的网络流量中增加20毫秒的延迟。大幅度的实验可能是增加500毫秒的延迟,因为这将对性能和吞吐量产生显着的影响。与爆炸半径一样,从低幅度开始,然后逐渐增大。 第三步:监控基础架构。确定哪些指标将助力得出有关假说的结论,在测试之前进行观测以建立基线,并在整个测试过程中记录这些指标,以便可以监测预期和意外的变化。借助Confluent平台,我们可以使用Control Center从Web浏览器实时直观地观察群集的性能。 第四步:运行实验。Gremlin允许以简单、安全和可靠的方式在应用程序和基础架构上运行实验。我们通过运行注入攻击来做到这一点,它提供了各种向系统中注入故障的方法。我们还要定义中止条件,这是我们应该停止测试以避免意外损坏的条件。使用Gremlin,我们可以将状态检查定义为场景的一部分。通过状态检查,我们可以在进行注入攻击时验证服务状态。如果基础架构运行不正常,并且状态检查失败,将自动停止实验。另外,我们可以使用内置的暂停按钮立即停止实验。 第五步:从观察结果得出结论。它是否证实或反驳了原先的假设?使用收集的结果来修改基础架构,然后围绕这些改进设计新的实验。随着时间的推移,重复此过程将有助于使Kafka部署更具韧性。本文中介绍的实验绝不是详尽无遗的,而应将其作为在系统上进行实验的起点。请记住,尽管我们正在Confluent平台上运行这些实验,但它们可以在任何Kafka集群上执行。
假设:磁盘I/O的增加将导致吞吐量的相应下降。 结论:即使将磁盘I/O增加到150 MB/s以上,技术攻击也不会对吞吐量或延迟产生明显影响。两项指标均保持稳定,我们的broker均未失去同步或复制不足,也没有消息丢失或损坏。
使用更快的存储设备,例如更高的RPM磁盘或固态存储; 使用更有效的压缩算法,例如Snappy或LZ4。
比追随者低的时间间隔,发送连续的消息流,启动实验,并寻找使用者输出中的空白(replica.fetch.wait.max.ms)。 发送消息后,立即使用Gremlin API从生产者应用程序触发混沌实验。
假设:由于领导者失败,我们将丢失一些消息,但是Kafka将迅速选出新的领导者,并再次成功复制消息。 结果:尽管领导者突然失败,消息列表仍显示所有成功通过的消息。由于实验前后记录了额外的消息,因此我们的管道总共产生了336个事件,每个消息在上一个事件之后大约有100毫秒的时间戳。消息没有按时间顺序显示,但这很好,因为Kafka不保证分区之间消息的顺序。这是输出示例:
假设:Kafka的吞吐量将暂时停止,但是两个broker节点都将重新加入群集,而不会出现问题。 结果:控制中心仍列出了三个broker,但显示其中两个不同步且分区复制不足。这是预料之中的,因为节点已经失去了与其余broker和ZooKeeper的联系。
假设:Kafka可以忍受短期的ZooKeeper中断,而不会崩溃,丢失数据或损坏数据。但是,直到ZooKeeper重新联机之前,对群集状态的任何更改都将无法解决。 结果:运行实验对消息吞吐量或broker可用性没有任何结果。正如我们所假设的,可以继续产生和使用消息而不会出现意外问题。
四、进一步提高Kafka的可靠性
评论