在短短三个月内无停机迁移到 ClickHouse Cloud：120 TB 数据之旅及其优势

这是一篇来自 Azur Games 首席解决方案架构师 Vladimir Rudev 的客座文章。

去年，我们意识到现有的技术解决方案已无法满足公司不断增长的需求。很明显，我们需要进行大规模基础设施改造，因为我们的技术债务已变得难以管理。

我们使用 ClickHouse 已有多年，因此探索 AWS 上的 ClickHouse Cloud 非常合理。

挑战在于迁移 120 TB 的数据库，同时不会导致分析出现任何停机时间，并确保平稳过渡。我们选择“完全复制”、验证和原子切换方法来实现这一点。您可能想知道这些数据来自哪里。作为下载量排名第一的移动游戏发行商，我们已经发布了 150 多个项目，总安装量超过 80 亿次。自然，这会生成大量的遥测数据。

超休闲游戏是一种简单易玩的移动游戏，入门门槛很低。这种快节奏、简单的游戏会从用户互动中生成大量的遥测数据，这对了解玩家行为、优化盈利、进行实验和改善整体游戏体验至关重要。这同样适用于 Azur Games 开发的休闲和中度核心游戏。对所有类型游戏而言，都需要进行数据分析。

在本文中，我将详细介绍迁移过程、我们面临的挑战以及我们获得的优势。

剧透：我们不仅成功完成了迁移，还获得了许多积极成果。迁移到云后，服务的最终成本与之前基本相当。此外，我们还为两名工程师节省了半数时间，减轻了许多压力，并将精力从维护转移到更具创意的任务上。

现在，让我们逐点回顾一下这个过程。

我们要实现的主要**目标**

1. 提高存储可靠性。
2. 提高运营可靠性，减少故障次数。
3. 简化维护。
4. 确保扩展灵活性。
5. 优化预算成本。

我们的起点

资源

• 20 台强大的数据库服务器 + 3 台用于 ZooKeeper 的低功率服务器。
• 11 台 Airflow 服务器（200 多个 vCPU）。
• 6 台 MinIO 服务器（S3 模拟器，Airflow 缓存）。
• 4 台 MySQL 数据库服务器。
• 4 台用于 BI 和支持服务的服务器。
• 2 名 Airflow 工程师。
• 1 名 DevOps 工程师。

总计：45 台服务器和 3 名专家。

还有许多托管单元，其中最重要的 7 个是：CH、ZK、MySQL、MinIO、Airflow（调度程序、工作程序）和 BI。

工具

• Ansible 用于管理所有服务器。
• Airflow 2.2.3，已经两年了。
• MinIO 版本也已经两年了。
• ClickHouse 21.3，已经两年多了。

简而言之：单个磁盘故障导致整个分片崩溃的风险是一个重大隐患。这会导致一些项目在较长时间内完全无法访问数据。我们一直最担心的问题是数据驱动器的级联故障。

这个问题在磁盘使用量很大的长期运行项目中并不罕见。安装在服务器中的磁盘通常来自同一批次，而且它们往往在相近的时间出现故障。相同的运行时间意味着相同的故障概率。当一个磁盘出现故障时，它相邻磁盘的负载会增加。在我们的服务器中，按照 RAID 10 组织，磁盘成对工作，这意味着一个磁盘出现故障会导致其伙伴（副本）出现故障的可能性增加。如果同一组中的两块磁盘出现故障，整个服务器就会崩溃。

当一个副本宕机 3-6 个小时时，我们并不担心。但是，如果一个 15 TB 的驱动器出现故障，同步可能需要大约一周时间。如果在此期间另一个伙伴磁盘出现故障，整个服务器就会崩溃，重新同步副本可能需要 3 天到一周的时间。在此期间，剩余的副本将承受 ETL 过程和与新服务器的同步的沉重负担。这就是为什么建议每个分片有三个副本，每个副本的负载不超过 60%，尽管这样会贵得多。

第二个主要问题是 MinIO。实时更新 MinIO 对我们来说风险很大。随着我们的数据量越来越大，服务故障变得更加频繁，向 MinIO 集群添加资源只能起到一点作用。很明显，我们要么做错了什么，要么遇到了特定 MinIO 版本中的一个错误，而我们还没有找到。随着时间的推移，故障变得更加频繁，导致 ETL 过程崩溃。Airflow 工程师不得不花费大量时间检查和恢复失败的 ETL。

总而言之，我们学会了忍受两个主要痛点

1. 当软件崩溃且没有直接的修复方法（不涉及更新）时，管理员会很头疼。
2. 当 ETL 过程崩溃时，Airflow 工程师会遇到持续中断，而这几乎每次发生故障都会发生。这影响了数据可用性时间线和新功能的开发。

尽管我们尽可能地实现了自动化来最大限度地减少这些问题，但 ETL 支持仍然需要大量时间，影响了士气。

找到合适的解决方案花了相当长的时间。请记住，我们要解决的主要任务是

1. 存储可靠性。
2. 运营可靠性。
3. 易于维护。
4. 扩展灵活性。
5. 预算成本最优。

我们的选择有

1. 保持裸机，但更改提供商 - 其他部分保持不变

这可以解决第四点，但不能保持成本不变。

2. 迁移到 AWS/Google/Azure

配置得当，此选项可以解决存储可靠性、运营可靠性和成本灵活性问题。如果拥有 Kubernetes 方面的专业知识，我们可以部分解决易于维护的问题。

然而，成本问题仍然需要解决。以下是详细说明：迁移到 AWS 而不使用 ClickHouse Cloud 提供更强大的硬件，但由于数据量庞大，价格也高得多。AWS 可以通过允许使用单个“胖”服务器来帮助缓解配置效率低下的问题。我们可以使用一个大型分片来代替多个较小的分片，并在其中添加大量驱动器，但我们仍然需要至少两个副本。这意味着在磁盘上管理 240 TB 的数据，仅存储费用就需要花费数千美元，还不包括其他费用。因此，成本仍然是一个重大问题。

还有选择可以将数据分成热存储和冷存储，这可能会使成本降低一半。但是，这些解决方案需要来自高素质工程师的大量规划、测试和时间。挑战在于找到适合我们数据处理模式的正确配置，同时不影响未来的速度和服务质量。

3. 留在之前的提供商，但在其框架内迁移

此选项将允许我们更新到最新软件版本并解决一些技术债务。然而，它只会表面上触及其他目标。

通过 AWS PrivateLink 无缝连接的 ClickHouse Cloud 提供了显著的成本节约，具有诸如将数据存储在 S3 而不是磁盘上以及零拷贝复制 (ZCR) 等功能。后者在这里起着至关重要的作用，因为 ZCR 允许在一个分片中使用两个副本而无需存储数据的两个副本。这样，存储数据的体积最终等于其实际大小。

S3 以低于用于存储的传统磁盘的成本提供 99.999999% 的数据持久性。

硬件

• Airflow 现在使用 24 到 40 个 vCPU 运行，并自动扩展。
• ClickHouse 现在拥有三个副本，所有数据都在 S3 上。所有请求都在实际容量上进行测试，并且没有一个请求的表现比旧的 ClickHouse 设置差（这很重要，我们多次检查过）。
• 现在有很大一部分请求处理速度更快，其余请求的处理速度大致相同。
• 剩下的数据库现在包含在 RDS 中。
• 管理员和 ETL 工程师的工作量显著减少。
• 虽然总成本（ClickHouse 数据库 + ETL 基础设施）略有增加，但它仍然可以比拟。

那我们的目标呢？

1. 存储可靠性：所有关键单元（DB、S3）都包含在一个保证可靠性的“服务”中。我们卸载了许多复杂的任务，使 SaaS 解决方案的成本不可比拟地低廉。

2. 运营可靠性、增长灵活性以及最佳成本：已实现 100%。

3. 易于维护：已解决 80-85%。问题没有完全消除，但已显著减少。考虑到投入的资源，这是一个不错的结果，超过了成本略微增加带来的补偿，因为我们节省了大量工程师的时间。

4. 增长灵活性：已实现 100%。

5. 我们花了两个工程师全职工作三个月，以及我自己的一个月时间用于迁移。服务的成本不仅仍然可以比拟，而且被我们获得的益处远远超过。

降低复杂性

1. MinIO 被 Amazon S3 取代。

2. 三个不同的 Airflow 部署。最新的版本在出色的硬件上完美地处理了整个负载。

3. 许多用于旧服务器设置和维护的不必要的配置和脚本。

获得的优势

1. 整个系统变得更简单、更快、更可靠。

2. 代码和结果之间的管理员层变得更薄。我们的团队现在拥有更多控制和能力，我们可以利用这些能力而无需涉及管理员。他们可以将必要的软件添加到 Python 中，并进行向上和向下扩展，而无需涉及管理员，从而减少日常操作中的中间步骤。

3. 我们从 Amazon 获得了出色的硬件。对于新的 Airflow 来说尤其如此。快速的 S3，再加上超高速网络和磁盘，极大地加快了我们的 ETL。

4. 我们获得了在需要时在几分钟内进行 2 倍、5 倍或 10 倍扩展的能力。例如，当数据提供商一方的集成暂时出现故障时，我们需要快速接受比平时更多的数据。

5. 我们获得了 ClickHouse 的最新版本，并获得了由 ClickHouse 团队管理的滚动更新，其中包含许多我们需要尝试的新功能和优化。

• 用于计算所有内容的新便捷函数；
• 可以加速我们某些查询的优化；
• 与数据存储相关的可以潜在地为我们节省空间（这会影响成本）并加快查询速度的新功能；
• 将有助于我们的 ETL 变得更快、更可靠、更直观的特性。

6. 需要实验的任务将更快完成。现在选择最佳服务器参数时，我通常甚至没有时间给自己泡杯茶，新配置就已应用。快速看到结果总是一件好事。在等待时无需切换到其他任务。

7. 实验现在易于管理。在我的脑海中，我始终有一份“我可以做得更好”的清单，几乎所有这些都与数据有关。任何需要对数据存储和记录电路进行重大改动才能进行的实验都会给磁盘带来压力，但这不再是问题。这个过程在旧的 ClickHouse 中令人生畏，但现在不再是这种情况。我们可以根据需要加载新的 ClickHouse，而不必担心失败。

主要好处是节省了员工时间，现在可以将这些时间用于更令人兴奋和更具战略性的任务。我们的一位管理员大约有 60% 的时间空闲，我们的 ETL 工程师现在节省了 40% 的时间。

这也节省了许多压力，尽管计算道德因素更具挑战性。现在，我们可以专注于创造，而不是不断维护复杂的的基础设施。公司总是有一个有趣的任务积压；例如，我们终于可以开始试验 DBT（数据构建工具）了，它现在在分析领域被广泛使用，并且完美地符合我们的需求。

此外，许多业务任务开始更快地发布。在许多情况下，花费的时间减少了一半或更多。

一个典型的例子是需要进行新的数据聚合，必须重新计算整个历史时期。

以前，为了做到这一点，我们需要计算集群中可用的空闲资源，估计其速度，将其乘以计算量，并获得完成的截止日期 - 假设一切顺利，没有出现严重故障，并且集群保持稳定。

现在，我们可以立即在 ETL 和 DBMS 方面添加计算能力。这意味着任务完成得更快，与使用的资源成正比。

通过以完全相同的资源成本更快地获得结果，企业自然会从中受益。

不完全是新问题，而是新的现实。云中的生活遵循不同的规则。云在成本方面通常无情。您需要为通过网络发送的每个字节和使用的每个处理器周期付费。如果您没有充分利用它，它仍在空闲运行。这迫使我们实施算法和架构来最大限度地提高效率。

但是，所有这一切都带来了积极的影响。结合非常快的扩展和超强大的硬件，可以以最小的努力将系统性能提高数倍。

新集群的架构也与我们以前使用的架构有很大的不同。以前对我们很有效的东西在新的集群中却无效。但是，出现了新的解决方案来解决相同的问题。在迁移期间，我们适应了新的现实。

**7 月。** 我们开始积极进行迁移工作。一个月的时间里，我们与 ClickHouse 团队合作，逐步熟悉产品并进行小型实验。

**8 月。** 意识到需要进行彻底的测试，我们开始迁移数据。我们的目标是在一个月内完成传输，或者最多六周内完成传输，同时执行必要的重构，这大约也需要一个月的时间。这是我们的第一个错误出现的地方。我们的两位工程师经常被业务相关的任务分散注意力，导致延误。因此，我们只能在计划的时间范围内完成一些事情。

**9 月。** 我们花了整个月的时间迁移数据并进行必要的调整。

**10 月。** 本月最初被计划为安全保障。我们完成了待处理的任务并进行了彻底的测试。到 9 月底，我们发现数据合并过程中存在我们之前没有注意到的问题。在 10 月上半月，我们继续添加数据。在下半月，我们专注于确保所有数据都被正确传输。尽管我们付出了努力，但工作仍然需要在 10 月底之前完成。

**11 月。** 距离迁移结束还有一个月，我们似乎可以喘口气，更仔细地专注于传输和验证数据。准确性是我们的首要任务。团队做得非常出色。到 11 月中旬，我们几乎准备将分析切换到新系统。

我们于 11 月 21 日进行了切换，并立即遇到了两个令人不快的问题。ClickHouse 中的一些查询开始表现出与预期不同的行为。我们将这些问题报告给了 ClickHouse 团队，他们很快为第一个问题提供了解决方法，并在他们的一端修复了第二个问题。

到 11 月 23 日，我们已将 BI 操作切换到新的 ClickHouse 系统。

11 月 27 日，我们签署了合同并关闭了旧服务器。

**总计**：3 个月的积极工作。

ClickHouse Cloud 的架构与传统的本地设置有很大不同。这导致我们在测试阶段遇到了一些问题。ClickHouse 团队非常支持我们，帮助我们找到替代解决方案，甚至在 ClickHouse 中专门为我们的需求快速进行代码更改。

在短短三个月的时间里，我们部署了一个新的、技术更先进的解决方案。这使我们能够在存储和服务方面实现近 100% 的可靠性，为未来的增长提供了可能性，并为我们的工程师节省了大量时间。从这些改进中获得的益处超过了维护成本略微增加带来的补偿。