Pinterest 基于 AWS 规模化使用 Apache Kafka 的实践经验

在 Pinterest，Apache Kafka 被用于为实时流应用程序传输数据、记录日志和可视化监控指标。Pinterest 的 Kafka 托管在 AWS 上，为了实现复制和高可用性，其安装使用了 MirrorMaker 和 DoctorKafka 工具。

Pinterest 的技术主管 Yu Yang 写道 ，Pinterest 的 Kafka 安装运行在 2000 多个“代理（broker）”上，分布在 AWS 的三个地区，每天处理 8 亿多条、1.2PB 消息。他们的主要 Kafka 工具集包括 Kafka 的 MirrorMaker 和 Pinterest 自己的 DoctorKafka。MirrorMaker 消费源集群中的数据并将其发布到目标集群，实际上是 创建源集群的副本 。Pinterest 的团队使用它在三个 AWS 区域之间传播数据。大多数代理都位于 us-east-1，尽管这是 AWS 历史最悠久的区域，但它也有自己的 问题 。每个集群中的 Kafka 代理分布在三个可用性区域中，每个主题分区的副本都分布在三个区域中，因此，最多可以承受两个代理失败。

Kafka 代理失败很常见。替换失败的代理和重新平衡工作负载“需要谨慎地创建和编辑分区再分配文件，并手动执行 Kafka 脚本命令”，Yang 在 前一篇文章 中写道。其结果是 DoctorKafka ，一个自动化这些步骤的开源工具。DoctorKafka 可以检测失败，并自动将工作负载分配给健康的代理。它基于“主代理（master-agent）”模型。“代理体（agent）”在每个代理上运行并收集指标，中央主服务器分析这些指标。中央服务器确定故障并运行命令采取纠正措施。DoctorKafka 是“保守”的，因为它 只有在确定的时候 才会采取纠正措施，否则就会发出警告。大多数大型 Kafka 部署都会使用一种复制策略，使用 MirrorMaker 或 类似的工具 。

Pinterest 在 AWS d2.2xlarge 实例上运行 Kafka。据 Yang 介绍，由于 EBS 争用导致的性能问题 ，他们从 st1 EBS 磁盘 经过吞吐量优化的 c3.2xlarge 实例转到了有本地存储的 d2 实例。然而，其他人在他们的基准测试中报告了相反的结果。Kafka 还构成了 Pinterest 日志基础设施的基础，每天处理 100+TB 的数据。服务将数据写到磁盘，日志代理 Singer 从磁盘获取数据并写到 Kafka。另一个自定义工具 Secor 从 Kafka 获取日志消息，并将它们持久化到 S3，以克服“Kafka 的弱最终一致性模型”的不足。

未来，Pinterest 将探索把 Kubernetes 作为 Kafka 部署的抽象层，一些组织 已经在这样做了 。Pinterest 的一些服务 已经转移到容器中 。另一个目标是再次探索 EBS 存储，因为新的 EBS 产品经过了更好的优化。

查看英文原文： Scaling Apache Kafka at Pinterest