背景

大数据场景下，数据存储的最常见三种形态是：

• Database、Data Warehouse
• Data Lake (on object store)
• Data Stream

Apache Kafka 是 Data Stream 中最老牌的系统，实时存储、上下游 pub/sub 生态构成流数据处理的实践标准。其后诞生了几个在多租户、低运维、存算分离上表现优秀的系统，诸如：AWS Kinesis、阿里云 SLS（LogHub）、Apache Pulsar 等。

Kafka 在开发者中影响力很高，参与的玩家分为三类：

• Confluent Kafka：Kafka 早期开发者成立的商业公司，21年中 IPO，市值百亿美元级。
• 云厂商托管 Kafka：例如 AWS、阿里云提供服务来替代用户 PaaS 自建系统。
• 其它系统提供 Kafka 协议兼容：用户不感知底层存储，系统兼容友好。

一个月前的 AWS Re-Invent 上发布了 MSK Serverless，本文从 Stream Storage 角度做一些调研解读。

AWS 流存储产品栈

关于消息、队列存储，目前 AWS 有四款产品：

1. Kinesis Data Streams
2. MSK（Managed Streaming for Kafka）
3. Simple Notification Service
4. Simple Queue Service

后两个主要定位是消息系统，本文比较前两者：

MSK Serverless Preview

今年 Re-Invent 上，AWS 大数据相关产品有两个突出趋势：软硬一体化、Serverless 化。像 Redshift、EMR、MSK 都推出了 Serverless 版本。

关键特性

MSK Serverless 在 2021/11/30 上线了第一个区域，其关键特性有：

1. 面向 on-demand 存储容量、写入流量，系统支持自动扩容
2. 按流量的定价方式
3. 自动 partition 布置（因 broker 机器对用户不可见）
4. 完全兼容 Kafka 使用方式
5. 和 MSK 一样的安全特性支持

通过 Serverless 版本，给客户带来的价值有三个：

• 更容易开通、使用，减少用户可见的组件
• 更低的运维负担
• 成本优化

使用场景

该怎么选择？

提一个问题，为什么不全部升级为 MSK Serverless 版本？

以下是笔者理解（如有错误，欢迎拍砖交流），MSK 实例版继续存在的原因有三点：

• 系统上限能力

参考系统 Quota，MSK 实例版对 Serverless 版本有一个数量级的存储容量、写入流量优势，是超大应用选型无法绕过的指标。

MSK：30 broker（kafka.m5.24xlarge：96 vcpu、394GB mem），最大支持 160 TB 存储（3 replica），5 GBps（按 5 MBps 单核性能估算）写入吞吐。

MSK Serverless：120 partition，最大支持 30 TB 存储，200 MBps 写入吞吐。

• 费用成本

在流量 burst 不明显，读、写次数多等情况下，实例版在成本上比 Serverless 版有较大优势。

• 个性化集群配置

例如最大 partition 数目、消息大小、partition 存储空间等参数在 Servleress 版本有硬性限制。用 MSK 实例版有更大的定制权。

Serverless 版可以指定 topic 级配置项如下（rentention.ms 最大支持 1 天，不知是否文档错误）：

MSK 产品深入

产品原理

我觉得 MSK 是又一个样板向客户展示 AWS 云基础设施的成熟度、如何用云产品搭建一个数据处理系统。

MSK 包括以下重要部分：

• broker（EC2）
• 存储（EBS）
• 虚拟 ZooKeeper 节点（ZK 不收费）
• VPC 网络

生态联动了以下 AWS 云产品：

• Lambda：MSK event sourcing
• IoT：IoT event sourcing
• Glue：Glue Schema Registry 可用于 Kafka 应用程序
• Kinesis：通过 Data Analytics 对 Kafka 数据做流计算（Flink），包括复用 Data Analytics Studio 来交互式使用 streaming SQL
• 等等

MSK 兼容包括 producer/consumer API 在内的大部分 Kafka 生态，但不支持需上传自定义 jar 文件到 borker 的应用（例如 Confluent Control Center、Confluent Data Balancer、Uber uReplicator 等）。

弹性架构

一个 Kafka 集群的 broker 分布在多个 AZ 实现高可用，AZ 组合布置是系统策略，用户不可修改。可用性：99.9%。

MSK 开放了少量配置项在集群初始化前由用户设置，但使用中的集群，用户无法修改 broker 配置。

Failover 过程：borker 失效后，MSK 将替换使用新 broker（尽量复用旧的 borker、避免数据复制成本），在故障恢复后，客户端（producer/consumer）访问的 broker IP 地址不改变。

关于集群 partition 分布管理：

1. 实例版使用开源工具 Cruise Control 管理 partition 分布。
2. MSK Serverless 会监听指标，自动进行集群内 partition 迁移。

broker 的存储扩容支持两种方式：

1. 手动：扩容 EBS。
2. 自动：设置自动扩容策略，每分钟检测指标，扩容粒度max(10GB，10% * current_storage)。

存储扩容有两项限制：

1. 只允许扩容（扩容器件，不影响服务可用性），但不支持缩小空间。
2. 扩容操作有一个冷却期（6~24 小时），限制两次扩容操作的最短间隔。

Kafka 集群数据迁移到另一个集群可以使用社区工具 Mirror Maker，例如缩容集群存储就得通过这样的工具腾挪。

安全性

包括多个层面的安全设计：

1. 数据传输：TLS。client 到 server 数据传输使用；MSK 内部 broker 之间、broker 到 ZK 之间请求也使用 TLS 加密。
2. 网络隔离：VPC Private Link；如果集群开公网访问，建议设置安全组等网络规则。
3. 存储加密：AWS KMS。
4. 权限隔离

1. 通过 AWS MSK API 访问：AWS IAM、AWS SLR。
2. 通过 Apache Kafka API 访问：

1. IAM：MSK 修改了少量Kafka 代码以支持该特性。
2. TLS：需 ACM Private CA 证书支持，不支持中国的区域。
3. SASL/SCRAM：通过 username/password 认证，可以将秘钥托管在 AWS Secrets Manager。
4. Kafka ACL：在 ZooKeeper 存储的 ACL 规则，格式为"Principal P is [Allowed/Denied] Operation O From Host H on any Resource R matching ResourcePattern RP"。

可观测性

1. 监控方案

内置方案是 AWS CloudWatch 上查看指标，每个月每个指标有一定免费额度，更细粒度的指标付费使用。

也可以使用 Promethueus 等开源方案查看 JMX 采集的指标。

2. 日志方案

Kafka broker、Kafka connect 组件产生的日志可以配置投递到 CloudWatch、S3 或者 OpenSearch（通过 Kinesis Firehose）查看。

注意，ZK 节点是虚拟的，日志需通过工单申请。

MSK Connect

源自社区 Kafka Connect，用于完成数据集成工作，将数据导入、导出到 Kafka 集群。

MSK Connect 算是一项独立功能，除了 MSK 以外，自建 Kafka 也可以使用它。

每个 MCU（1 vcpu，4 GB mem）每小时收费 $0.11。可以使用任意的 connector，性价比很高。

支持两种模式：

1. Provisioned：用户指定两个参数

1. worker 数目
2. 每 worker 上的 MCU 数

2. Auto Scaled：系统根据机器负载动态设定 worker 数目，用户可指定以下参数

1. worker 数上限、下限
2. 扩容、缩容的 CpuUtilization 阈值
3. 每 worker 上的 MCU 数

版本升级

版本升级都是由客户触发，有一定风险。但如果遇到安全风险、重大 bug 却又不得不去做。

Kafka 服务端版本只支持升级，不支持降级，可以通过 MSK 提供的升级功能完成。

Kafka 客户端上的程序需要用户提前评估好，自己做好兼容。

最佳实践

即使是托管服务，使用 Kafka 仍然需要掌握一定技巧，以下摘自官网文档。

1. 正确设置集群规模

1. 每个 broker 上的 partition 数目：根据 broker 的机器规格不同，其能承受的 partition 数目上限从 300 到 4000 不等。
2. broker 数目：可以通过压测工具来评估，一般建议以 P99 延迟低于 100ms 为参考。

2. 构建高可用集群

1. replication factor：2-AZ 集群建议取值 2，3-AZ 集群建议取值 3，取值 1 则升级时会出现 partition 不可用。
2. minimum in-sync replicas：建议设置为replication factor - 1，超出的值会在集群升级是导致 producer 阻塞。
3. client connection strings 设置多个 broker 地址，避免单个 broker 下线对客户端的影响。

3. 监控集群 CPU 使用率

1. MSK 强烈建议 broker 机器 CPU（usr+sys）使用率不超过 60%。Servlerless 版本有 partition 自动调度策略。
2. 如果是实例版，收到告警后，一般有三种处理方式：

1. 升级机器规格，是最简单的方案。
2. 增加 broker 数量，并且扩容 partition 数量，这样新 partition 会落在新机器上进行服务。
3. 增加 broker 数量，partition 数量不变，对已有 partition 做数据重分布（会消耗 cpu、IO、网络资源），不建议在 cpu 使用率超过 70% 时使用。

4. 监控集群磁盘使用率，并在超出后采取措施：

1. 磁盘扩容。
2. 删除不再需要的 topic 数据。
3. 减少 topic 数据存储周期。

MSK 竞争力分析

对比于用户购买 PaaS 自建，AWS 托管 MSK 有以下优势：

• Zookeeper 托管运维，0 成本
• 基础支持：版本升级、集群安全、秘钥轮转
• 存储：容量、性能规划，Servlerless 弹性优化
• 监控集成
• 技术支持

最后，我以 Confluent 平台作为对标服务，在差异项上对比 MSK 产品竞争力：

参考资料

AWS 官网文档