ClickHouse 迁移至 AWS Graviton 的总结

主要观点

ClickHouse 在过去六个月中成功将其云服务迁移至 AWS Graviton 架构，报告称最终用户的性能提升了 25%。这一迁移过程涉及性能基准的建立、兼容性评估、风险分析及缓解策略，旨在处理大规模生产工作负载。

关键信息

迁移背景与挑战

• 初始部署：ClickHouse Cloud 服务最初主要部署在基于 x86 架构的实例（如 M5 和 R5）上。
• 挑战：迁移数据密集型应用面临诸多挑战，尤其是在性能和成本优化方面。

迁移策略

• 兼容性评估：团队评估了 Intel 专用编解码器（如 deflate_qpl 和 zstd_qat）的兼容性。
• 性能基准测试：使用 ClickBench 类似的基准测试工具，对 ARM64 和 AMD64 架构进行性能测试。
• 混合实例策略：由于 Graviton 大实例的可用性限制，ClickHouse 采用了 Graviton2 和 Graviton3 通用实例与本地 NVMe SSD 存储（m7gd 和 m6gd）的混合部署。
• 自动扩展管理：使用 AWS Auto Scaling Groups 和自定义的 ClickHouse 自动扩展器管理 Graviton 实例，确保平滑的自动扩展。

性能提升

• 整体性能提升：在广泛查询测试中，整体性能提升了 25%。
• CI 日志集群：性能提升较为有限，主要因为从 S3 读取数据时受网络限制。
• ClickBench 测试：在 Graviton4 场景（r8g 实例）中，性能提升尤为显著。

重要细节

自动扩展优化

• 内存分配调整：调整 m6gd 实例的内存分配以匹配 m7gd，防止不可调度的 Pod。
• 动态 Pod 分配：通过 webhook 实现动态 Pod 分配，将小于 236Gi 的 Pod 定向到 ARM 实例。
• 容量预留与自动扩展逻辑优化：预留额外容量并优化自动扩展逻辑，以管理从大型 x86 实例到小型 ARM 实例的“架构跳跃”。

AWS Graviton 的演进

• Graviton1 到 Graviton4：从早期的 Graviton1（16 核 Cortex-A72）发展到最新的 Graviton4（96 核 Neoverse-V2 和 12 通道 DDR5-5600 内存），显著提升了吞吐量和降低了延迟。

生产环境现状

• Graviton3 实例占比：近 80% 的生产 vCPU 运行在 Graviton3 通用（m7gd 或 m7g）和内存密集型（r7g 和 r7gd）实例上。
• AMD 实例占比下降：AMD 实例占比下降至 17.32%。

结论

ClickHouse 的迁移策略展示了如何在处理大规模生产工作负载的同时，实现显著的性能提升和成本优化。AWS Graviton 架构的采用不仅提升了性能，还为未来的扩展和优化提供了坚实的基础。