在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

创作场景

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