confluent博客解读part2 confluent cloud speed,scale,storage

发表于 分类于 阅读次数： 本文字数： 1.6k 阅读时长 ≈ 5 分钟

背景

confluent博客解读是一个系列，主要是对confluent以下博客内容的一个阅读总结。

今天我们介绍的是第3篇，主要是关于confluent cloud从apache kafka到confluent cloud发展路径中关于speed、scale、stograe层面的思考。

前言

confluent重点关注的内容是性能、价格和可用性。旨在为任何负载都提供良好的性能范围。confluent持续优化的时候主要会遵循以下的原则：

  • The first principle is to know your users and plan for their workloads—it’s not a guessing game. （workload aware）
  • The second principle focuses on why infrastructure matters. Optimization in the cloud is as much about cost as it is about performance. Know the infrastructure that you have available to you. (cloud infra aware)
  • The third principle underscores the importance of effective observability, without which no performance effort will succeed. You can’t improve what you don’t see. (metric aware)

笔者解读：笔者自己将其总结为三种维度的aware，可以发现这几条原则本质上都和confluent提供高效的serveless kafka服务相关

原则1：workload aware

confluent当前做performance optimization的关键是去更好理解workload pattern然后动态地去调整和优化系统，形成一个紧密的反馈环。

负载模拟

confluent理解负载是从用户的实际性能诉求触发，聚焦那些最影响负载的负载特征。confluent通过模拟负载（使用的工具是TROGDOR）来助力他们快速的理解负载模型。例如，怎样的负载导致最坏和最好的性能。以Trogdor为例，一个workload可以用一个json文件来描述。更多负载例子也可以参考apache kafka repo

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
{
  "class": "org.apache.kafka.trogdor.workload.ProduceBenchSpec",
  "durationMs": 10000000,
  "producerNode": "node0",
  "bootstrapServers": "localhost:9092",
  "targetMessagesPerSec": 10000,
  "maxMessages": 50000,
  "activeTopics": {
    "foo[1-3]": {
      "numPartitions": 10,
      "replicationFactor": 1
    }
  },
  "inactiveTopics": {
    "foo[4-5]": {
      "numPartitions": 10,
      "replicationFactor": 1
    }
  }
}

confluent cloud性能包格线

workload的特征可以总结为有5个点是最影响性能的。通过优化这5个workload特征，可以有效改善性能。他们主要是：

  • Message characteristics: 消息特征主要包括消息大小、请求书、买个请求包含的消息数、请求类型、压缩等影响吞吐和延迟的特征因子。相同的吞吐采用不同的消息特征因子，延迟会有所不同。
  • topic分区布局：例如针对低吞吐的，使用较少的分区数资源消耗会更少
  • 集群拓扑：整个集群的节点数大小，broker数据倾斜(影响replication)都会影响某个workload的性能
  • 连接数：主要是连接的速率会影响workload的性能
  • 利用率：主要是聚焦在异步请求pipeline对性能的影响。

image.png
全局细致的metric信息是指导confluent理解客户workload并且执行相应动作的“北极星”。

每日性能测试

  • 每日通过模拟负载做性能测试，发现性能退化问题。
  • 每日测试也考虑故障注入场景：包括集群升级、硬件替换、消费者lagging等
  • 确保问题可复现性
  • 记录历史诊断信息(historical profile)观察趋势变化，来确认性能优化的效果。例如针对fetch api的优化

原则2：infrastructure aware

confluent将容量的问题全部抽象成一个CKU暴露给用户。confluent自己会充分利用云资源按照供应和价格模型在不影响用户的情况下做一些资源腾挪置换。

硬件

  • 跟踪新硬件的情况，使用新硬件带来更高的成本优势
  • 避免过度的硬件供应，例如broker上挂的云盘大小和计算实例的网络吞吐匹配
  • 关注资源供应的时间，避免使用有容量约束或者供应耗时的云资源
  • 不停机硬件调整
  • 自动回退更高容量的硬件资源

操作系统

  • 遵循操作系统最佳实践，例如Linux Kernel，像confluent就调整 dirty_background_bytes and dirty_bytes来更好利用底层存储设备来提升吞吐
  • 保持linux内核的更新，确保可以使用上一些新技术，例如io_uring异步I/O

JVM

  • 利用仿真负载充分测试，使用合理的JVM配置
  • 利用feature flag来支持动态调整JVM参数
  • 对周边的进程消耗的资源做合理配置，例如ZK等
  • 使用新的JVM GC例如G1 GC that supported a multi-threaded Full GC

Metric aware

metric 探针

confluet cloud提供了多种维度的探针来获取metric，利用系统内置的一系列探针获取数据，可以方便confluent更加直接有效的诊断问题或者进行优化

  • health check: 持续的对集群进行读写，检测失败和延迟
  • storage probe: 存储探针会尝试往磁盘进行一些写入
  • network probe: 网络探针，会尝试创建connection，探测网络问题

更多kafka metric可以参考： Monitoring Kafka Performance Metrics

技术栈

集群监控主要使用druid和bigquery来分析。作为调整内存、磁盘、负载均衡阈值等配置。SBC会依赖这些信息做重平衡。

性能诊断

confluent也利用很多工具来诊断性能问题，做进一步优化：

创新的架构

confluent cloud采用创新的架构，也获得了很多技术红利。

新存储引擎

一个分层存储引擎，称之为Infinite Storage，主要带来好处包括：

  • 提供了快速弹性的基础
  • 冷热数据分离，冷数据可以直接读S3

更多内容可以参考part1中介绍的内容。

JAVA SSL改进

用JDK9以上的优化过的SSL协议栈

升级过程优化

confluent做了很多优化来确保平滑、快速的升级，包括：

快速的升级与分发，大大加速了创新的速度，形成一个正向反馈环：

  • 分层存储使我们尝试新硬件成为可能
  • 新硬件上调优page cache和jvm，然后又进一步加强分层存储

image.png