Apache Kafka的性能验证（1）：验证环境和参数调优的内容
初始版本：2018年10月19日
作者：伊藤雅博，日立制作株式会社
首先
在这个帖子中，我将介绍我在2017年企业开源大会上发表的演讲《追求Kafka大师——如何在Apache Kafka中实现最佳性能》时所进行的调查内容（共计8篇）。这篇帖子的内容是基于Kafka 0.11.0版本于2017年6月发布时的情况。
从本次第四次开始，我们将介绍实际进行Kafka性能验证时的测量结果。首先，我们将介绍验证环境的系统配置和验证方法。
投稿一覧：
1. Apache Kafka的概述和架构
2. Apache Kafka的生产者/代理/消费者工作原理和设置列表
3. Apache Kafka的推荐配置和性能估算方法
4. Apache Kafka性能验证(1)：验证环境和参数调优内容（本投稿）
5. Apache Kafka性能验证(2)：生产者调优结果
6. Apache Kafka性能验证(3)：代理调优结果
7. Apache Kafka性能验证(4)：生产者再调优和消费者调优结果
8. Apache Kafka性能验证(5)：整体系统延迟问题
验证的目的 de
如果使用Kafka的异步复制，可以达到接近磁盘/网络性能上限的吞吐量。然而，关于同步复制时的性能信息较少。通常，在生产环境中，需要同步复制来保护数据。因此，我们进行了性能验证，以测量同步复制时的吞吐量。
就像在前面的帖子中所解释的那样，在数据生成者（Producer）发送数据后，消费者群（Consumer Group）立即读取的流数据处理系统中，性能最低的部分将成为瓶颈。因此，在Kafka中实现高吞吐量，需要在生成者-代理（Producer-Broker）之间的通信、代理-代理（Broker-Broker）之间的通信、代理的磁盘I/O和代理-消费者（Broker-Consumer）之间的通信全部实现高吞吐量。
在这个验证中，我们专注于数据处理的吞吐量进行了调优。通常情况下，吞吐量的增加会导致延迟的增加，但本次调优并没有考虑延迟。关于延迟的测量结果将在以后的发布中进行介绍。
验证内容
下面展示了验证系统的整体情况。在本次验证中，生产者节点会持续生成验证数据（每条记录为1KB），多个生产者会将数据发送到经纪人中心600秒。同时，一个消费者群组将持续从经纪人中心获取数据。为了最大化消费者在这个系统中600秒内的平均接收吞吐量，我们进行了生产者、经纪人中心和消费者的参数调整。
为了测量同步复制时的性能，我们将Replica副本数设为3，最小ISR数设为2，并将acks设置为all。
由于代理商的总磁盘数为24个，为了充分利用所有磁盘并发挥性能，至少需要24个副本。此次性能验证使用1个主题，所以这个主题的分区数必须至少是24个磁盘 ÷ 3个副本 = 8个。
然而，并不能保证所有分区的数据都能平均读写，可能会出现每个分区偏倚的情况。因此，我们决定为每个磁盘分配6个副本，在此次设置中，将分区数量设置为24个磁盘×6个副本÷3个复制=48个。
验证环境
在生产者使用两台节点、Broker使用三台节点，消费者使用一台节点中，我们使用了以下规格的物理机器。此外，关于软件参数设置，我们使用了之前发布的推荐设置进行了配置。
OS用に2台でRAID1、Brokerは8台をJBODでLogディレクトリに割り当て。
検証前に測定したディスクのシーケンシャルアクセス速度は約150MB/s。OSRHEL 6.7JDKJDK 1.8.0.121ファイルシステムEXT4（マウントオプション：defaults,noatime）KafkaバージョンKafka 0.11.0
由于本次是性能验证，因此ZooKeeper仅采用单台服务器，没有冗余性。以下是ZooKeeper节点的规格。
以下是验证系统的网络配置。生产者、中间人和消费者节点之间通过10 Gbps线路连接，ZooKeeper通过1 Gbps线路连接。在进行验证之前，使用iperf命令测量了节点之间的吞吐量，并确认生产者、中间人和消费者节点同时能够达到约1,170MB/s的吞吐量。
在理论上的最大吞吐量。
我們在上述的驗證環境中，展示了理論上的最大吞吐量。 在驗證中，我們通過調整生產者、經紀人和消費者的參數，來追求這個最大吞吐量。
在本次验证中，我们将假设存在一个流式数据处理系统，其中Producer发送的数据可以被Consumer Group立即读取。在该系统中，假设只要没有发生复制或由Consumer Group引起的读取延迟，所有数据都保存在页缓存中。因此，在这里我们假设不存在磁盘读取。
在这个系统中，当两个Producer节点以总计1,170 MB/s的速度发送数据时，Broker的发送和接收以及Consumer的接收网络带宽将达到理论上的最大吞吐量1,170 MB/s。由于这些地方成为瓶颈，即使Producer节点以更高的吞吐量发送数据，整个系统的吞吐量也不会提高。因此，整个系统的理论上的最大吞吐量是1,170 MB/s。
参数调整
调音的顺序
Kafka分为Producer、Broker和Consumer这三个组件，在流处理中，整个系统的性能很重要，不能有任何一个成为瓶颈。然而，要调查这三个组件所有参数的组合是困难的，因此在本次验证中，我们将调整分成以下四个范围，并依次进行调优。
1. 为了在系统中传输足够量的数据（理论值为1,170MB/s），我们首先优化了Producer与Broker之间的通信吞吐量。在此验证中，我们使用 acks=0 进行了调优，以消除Broker端的日志刷新和复制的影响。
经过优化，我们提升了Broker的日志刷新（磁盘I/O）性能，包括吞吐量。在此验证中，为了消除复制的影响，我们使用acks=1进行了测量。
3. 优化了Broker之间的复制性能
我们优化了包括Broker之间复制在内的吞吐量。为了观察Produce/Replicate吞吐量的变化，我们首先进行了acks=1的调优，最后改为acks=all。
4. 消费者的获取性能
通过对acks=all进行调优，优化了包括消费者获取在内的整个系统吞吐量。
调整的参数
以下是在本次验证中调整的参数。有关每个参数的详细信息，请参阅第2篇文章。
固定参数
以下是本次验证中设定的固定参数。由于本次性能验证的目的是最大化吞吐量，对于定义上限值的参数，我们设置了一个较大的值，以不受限制的方式进行。在生产环境中，需要设置适当的上限值。有关每个参数的详细信息，请参阅第二篇文章。
性能指标的收集方法
Kafka使用JMX公开性能指标等信息。在此次性能验证中，我们使用Prometheus监控吞吐量等指标的监测，并使用JMX Exporter收集指标。
以下展示了与吞吐量相关的指标。需要注意的是，这些吞吐量是生产者、中间代理和消费者发送和接收的记录大小，不包括元数据获取等吞吐量。除了这些指标，我们还监视线程的CPU使用率等各种指标，以帮助参数调整。
（以降、Produceスループットと呼ぶ）kafka.server.replica-fetcher-metrics.incoming-byte-rateBrokerのReplica fetcherがFetchリクエストで取得した秒間Recordサイズ
（以降、Replicateスループットと呼ぶ）kafka.consumer.consumer-fetch-manager-metrics.bytes-consumed-rateeConsumerがFetchリクエストで取得した秒間Recordサイズ
（以降、Consumeスループットと呼ぶ）
测量步骤
這裡列出了一次測量的步驟。我們通過改變參數，重複執行了這個步驟。
-
- 删除Topic并重新创建
-
- 清除所有节点的页面缓存
-
- 重启Broker（应用Broker的参数更改）
-
- 启动Producer和Consumer并执行处理（应用Producer和Consumer的参数更改）。Producer持续向Broker发送1KB的记录，Consumer不断获取它们。
-
- 在经过600秒时，根据Prometheus收集的指标计算吞吐量的平均值等。
- 停止Producer和Consumer。
結論として
在本文中，我们介绍了验证环境的系统构建和验证方法。下次我们将介绍调优生产者并进行性能测试的结果。
第5回：Apache Kafka性能测试(2)： Producer调优结果
