FunPlus 基于 MSK Express Broker 构建游戏实时数据处理平台

关于 FunPlus

FunPlus，中文名为趣加，是一家全球多元化的游戏研发、运营、发行品牌，2010 年在美国硅谷创立，总部位于瑞士。FunPlus 致力于为全球用户提供创新的娱乐体验，多年来，FunPlus 成功研发并推出了众多全球流行的移动游戏产品，其主要代表产品包括《State of Survival》、《King of Avalon》、《Guns of Glory》、《DC：Dark Legion》等，凭借独特的游戏体验、创新的游戏内容和前卫的玩法设置，赢得了玩家的认可。FunPlus 旗下的工作室及项目团队凭借多年来在游戏开发中的技术积累和研发优势，不断拓展细分市场、持续进行差异化创新，聚焦探索新型电子游戏产品和前沿 AI 科技，推动游戏研发领域的生产力变革，不断提升游戏研发管道的自动化、智能化和游戏的自适应化。FunPlus 吸引了来自全球各地、拥有不同文化背景的 2000 多名专业游戏人才，并在中国大陆、日本、新加坡、西班牙和美国等多个国家和地区的十余个城市设有办事处 。

概述

在游戏行业，实时数据处理对于游戏运营、用户体验优化和业务决策至关重要。作为全球领先的游戏开发商，Funplus 一直致力于构建高效、可靠且具有成本效益的数据处理架构。本文将详细介绍 Funplus 如何通过迁移到 HAQM MSK Express Broker 服务，成功降低超过 50% 的运营成本，同时提升了系统性能和可靠性。

现有架构面临的问题

FunPlus 使用 HAQM MSK 的 Standard Broker 来收集玩家埋点数据进行分析，但随着业务规模的扩大，团队面临以下挑战：

1. 存储成本高：在 MSK Standard Broker 中保留 1 天数据，每个broker 存储 16TB，每个游戏业务需要1 – 3个broker不等，3 副本存储成本较高。
2. 数据保留期限受限：由于存储成本高，无法存储更长时间的数据，限制了历史数据分析能力。
3. 扩容时间长：Standard Broker 的扩容过程耗时较长，影响业务弹性。

HAQM MSK Express Broker 简介

HAQM MSK Express Broker 是 AWS 在 re:Invent 2024 推出的新型 Apache Kafka 托管服务，专为简化管理、提高成本效益和增强弹性而设计。与标准 MSK 相比，Express Broker 具有以下关键特性：

1. 无需存储管理：提供弹性、几乎无限的按需付费存储，无需预置或主动监控。
2. 更快的扩展速度：集群扩展和分区移动速度比标准 Broker 快 20 倍。
3. 更高的吞吐量：每个 Broker 可提供比标准 Broker 高 3 倍的吞吐量。
4. 配置为高弹性：自动应用各种最佳实践，提高集群的弹性。
5. 无维护窗口：AWS 自动持续更新集群硬件，无需固定维护窗口。
6. 存储成本优化：只为单个副本数据付费，而不是所有副本。

HAQM MSK Express Broker 通过创新性的存储架构设计，从根本上改变了 Kafka 集群的容错能力和资源利用方式。与Standard Broker 架构中每个 broker 独立管理各自存储空间的模式不同，Express Broker 实现了存储与计算的完全分离，所有 broker 共享由 HAQM MSK 统一管理的中央存储层。

这种结构变化显著改善了故障恢复机制：在 Standard Broker 中，当发生可用区或 broker 故障时，系统需通过大规模数据复制来恢复丢失的分区数据，这要求预留大量额外容量以应对潜在故障；而 Express Broker 架构下，数据已集中存储并得到保护，故障恢复只需启动新计算节点并连接到现有存储层，无需耗时的数据重建过程。这种架构优势使用户能够显著减少为故障恢复预留的容量，将更多资源用于提升日常处理吞吐量，同时享受更快的故障恢复速度（提升约 90%）、更高的资源利用率和简化的运维负担。本质上，这是云原生架构”存储计算分离”理念的成功应用，使系统在保障可靠性的同时实现了更优的性能和成本平衡。MSK Express Broker 完全基于 Graviton3 实例，无需进行配置管理，使 Kafka 更具弹性，更易于管理。

HAQM MSK Express Broker 性能测试

FunPlus 团队对 MSK Express Broker 进行性能测试，使⽤ Kafka 自带的测试脚本 kafka-producer-perf-test.sh、kafka-consumer-perf-test.sh，得到如下测试数据：

• 性能：Express Broker 在更大的实例规格和更高的分区数量下展现出优越的扩展性，特别是在 m7g.8xlarge 实例上，其写入吞吐量是 Standard MSK 的 2 倍以上，且延迟更低；
• 成本效益：Express Broker 不会对数据的副本收费，随着数据量增加其成本优势变得更加显著；
• 使用场景建议：Express Broker 更适合具有高吞吐量需求的大型工作负载。

迁移策略与实施

评估与规划

1. 流量分析：评估现有 MSK 集群的流量模式、吞吐量和存储需求。
2. 规模确定：基于流量分析，选择合适的 MSK Express Broker 实例类型和数量。
3. 迁移路径：选择双写方案进行迁移，确保业务连续性。
4. 监控与告警：设置 CloudWatch 监控和告警机制，确保迁移后的系统健康。

技术实施

FunPlus 选择了双写方案从 MSK Standard Broker 迁移到 Express Broker：

1. 环境准备

# 创建 MSK Express Broker 集群
aws kafka create-cluster \
  --cluster-name funplus-game-data \
  --broker-node-group-info file://broker-nodes.json \
  --kafka-version "3.6.0" \
  --number-of-broker-nodes 3 \
  --broker-type EXPRESS \
  --instance-type express.m7g.2xlarge

broker-nodes.json 配置示例：

{
  "InstanceType": "express.m7g.2xlarge",
  "ClientSubnets": [
    "subnet-1234abcd",
    "subnet-5678efgh",
    "subnet-9012ijkl"
  ],
  "SecurityGroups": [
    "sg-1234abcd5678efgh"
  ]
}

2. 双写迁移实施

FunPlus 采用生产者双写方案进行迁移，执行过程包含以下步骤：

1. 生产者配置双写：修改生产者配置，同时向 MSK Standard Broker 和 MSK Express Broker 写入数据。
2. 消费者迁移：由于双写方案不会同步消费者组偏移量，消费者迁移到目标集群时需要指定较早的偏移量开始消费，确保不会丢失数据。
3. 数据验证：验证两个集群的数据一致性，确保迁移过程中数据完整性和准确性。
4. 完全切换：确认所有消费者已成功迁移并正常工作后，停止向 MSK Standard Broker 写入数据，完全切换到 MSK Express Broker。

3. 数据压缩优化

FunPlus 在迁移过程中实施了数据压缩优化策略：

• 在 Producer 端配置启用 LZ4 压缩算法（compression.type=lz4），基于其高压缩率与低 CPU 开销的平衡特性
• 通过性能测试验证压缩影响：
  • 对比测试显示压缩处理对 Express Broker 实例 CPU 利用率增加不超过 5%
  • 解压缩操作主要发生在 Consumer 端，对 Broker 集群整体吞吐量影响有限
• 压缩成效量化：
  • 带宽使用减少约 40-50%（取决于数据类型）
  • 存储成本降低约 45%
  • 在高峰期网络传输性能提升约 25%

综合考量压缩算法选择：在 gzip、Snappy、LZ4 和 ZStandard 等算法中，LZ4 在压缩率和性能之间提供了最优平衡。

迁移成果

成本节约

迁移到 MSK Express Broker 后，FunPlus 实现了显著的成本节约：

1. 存储成本大幅降低：从原来需要支付 3 副本存储费用，变为只需支付 1 份存储费用。
2. 总体成本降低 50%：综合考虑存储、Broker 和网络成本，总体成本降低了 50%。
3. 运维成本降低：存储按需扩展、计费，无需担心存储扩容，大幅降低了运维成本。

架构优化

迁移后的架构优化包括：

1. 计算实例升级换代：从 m5.2xlarge 优化为 m7g.2xlarge，充分利用 AWS Graviton3 处理器提供的更高性价比。
2. 存储管理彻底简化：存储层完全由 MSK 托管服务接管，团队无需再投入精力进行手动规划和扩展。
3. 数据传输效率提升：启用了数据压缩机制，在保持处理性能的同时，进一步优化了存储空间利用率和网络资源消耗。

性能提升

迁移后，FunPlus 的实时数据处理系统性能得到了显著提升：

1. 吞吐量提高：Express Broker 提供了比 Standard Broker 更高的吞吐容量，部分场景下性能提升达到 3 倍。
2. 扩展速度提升：集群扩展速度从传统的小时级别缩短到分钟级别，提升了约 20 倍，极大增强了系统弹性。
3. 恢复速度提升：系统故障恢复速度提高了 90%，显著提升了服务可靠性和业务连续性。

最佳实践与经验分享

FunPlus 在详细评估多种迁移方案的基础上，结合业务特点选择了最适合的解决方案：

1. MSK Replicator 方案：

MSK Replicator 可以使您可以更轻松地在 MSK 集群之间可靠地设置跨区域和同区域复制，并自动扩展以处理您的工作负载。您可以将 MSK Replicator 用于预配置和无服务器 MSK 集群类型，如下图所示，可以分批，分步骤的来迁移 Producer/Consumer 程序。

• 优势：作为托管服务，配置简便，支持跨区域数据同步和 offset 同步
• 局限性：仅提供 at-least-once 数据保证，可能导致下游消费重复数据
• 适用场景：生产者数量众多、业务连续性要求高、迁移窗口期较长且能够处理数据重复的场景

2. 双写方案（最终选择）：

• 优势：实现逻辑简洁，无需引入额外组件，控制复杂度低
• 局限性：不支持元数据同步，包括消费组偏移量的同步
• 适用场景：生产者相对集中，实现双写投入较小的场景
• 特别注意事项：消费者迁移到目标集群后，需要指定较早的 offset 在目标集群消费数据，并确保下游系统能够优雅处理可能出现的数据重复情况

3. MirrorMaker2 方案：

• 优势：支持 topic 和 consumer group offset 的自动同步，保证迁移的完整性，灵活的 topic 管理，支持保留原名或添加前缀
• 局限性：数据保证模式为 At-least-once，理论上会有数据重复，需要额外部署和维护 MirrorMaker2 组件
• 适用场景：从自建 Kafka 完整迁移到 MSK Express broker

结论

FunPlus 从 MSK Standard Broker 成功迁移到 HAQM MSK Express Broker 的案例，生动展示了云原生托管服务如何帮助企业降本增效、提升性能并简化运维。通过这次技术升级，FunPlus 不仅实现了超过 50% 的成本节约，还显著增强了系统性能和可靠性，为游戏业务的持续增长奠定了坚实的技术基础。展望未来，FunPlus 将继续探索和扩大 MSK Express Broker 和 Graviton 处理器在更多业务场景中的应用，推动基础设施向更高效、更可靠、更具成本效益的方向演进，为全球玩家提供更卓越的游戏体验。

本篇作者