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

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

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

我们已经使用 ClickHouse 多年了，因此探索 AWS 上的 ClickHouse Cloud 是合理的。

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

超休闲游戏是一种简单易玩、准入门槛低的手机游戏。这种快节奏、简单的游戏会从用户互动中产生大量的遥测数据，这对于了解玩家行为、优化盈利、进行实验以及改善整体游戏体验至关重要。这对于 Azur Games 开发的休闲和中核游戏也是如此。数据分析的需求适用于所有游戏类型。

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

剧透：我们不仅成功完成了迁移，还体验了许多积极的成果。迁移到云端后，最终服务成本与之前相比保持相当。此外，我们还解放了两名工程师一半的时间，减轻了很多压力，并将我们的重点从维护转移到创造和更有趣的任务上。

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

我们旨在实现的主要目标

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

我们的起点

资源

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

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

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

工具

• Ansible 用于管理所有服务器。
• Airflow 2.2.3，已有两年历史。
• MinIO 版本也已两年。
• ClickHouse 21.3，已有两年以上历史。

简而言之：单个磁盘故障导致整个分片崩溃的风险是一个重大担忧。这将导致某些项目在很长一段时间内完全无法使用数据。最令人担忧的始终是数据驱动器的级联故障。

这个问题在长期运行且磁盘使用量大的项目中并不少见。服务器中安装的磁盘通常来自同一批次，并且它们倾向于在相似的时间发生故障。相同的运行时间意味着相同的故障概率。当一个磁盘发生故障时，其相邻磁盘上的负载会增加。在我们的服务器中，以 RAID 10 组织，磁盘成对工作，这意味着一个磁盘的故障可能会增加其伙伴（副本）也发生故障的可能性。如果同一组中的一对磁盘发生故障，则整个服务器都会宕机。

当一个副本宕机 3-6 小时时，我们并不担心。但是，如果 15 TB 的驱动器发生故障，同步可能需要大约一周的时间。如果在此期间另一个伙伴磁盘也发生故障，则整个服务器都会发生故障，并且重新同步副本可能需要三到一周的时间。在此期间，剩余的副本会因 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 的专业知识，我们可以部分解决易于维护的问题。

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

还有将数据拆分为热存储和冷存储的选项，这可能会使成本减半。但是，这些解决方案需要经验丰富的工程师进行广泛的计划、测试和花费时间。挑战在于找到适合我们数据处理模式的正确配置，而不会在未来影响速度和服务质量。

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

此选项将允许我们更新到最新的软件版本并解决一些技术债务。但是，它只会肤浅地触及其他目标。

ClickHouse Cloud 通过 AWS PrivateLink 无缝连接，通过诸如将数据存储在 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 端添加计算能力。这意味着任务完成得更快，与使用的资源成正比。

通过以相同的资源成本更快地取得成果，企业自然会受益。

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

然而，所有这一切都带来了积极的影响。结合非常快速的扩展和超强大的硬件，只需最少的努力即可将系统性能提高数倍。

新集群的架构也与我们以前的架构有很大不同。过去对我们有效的方法在新集群中变得无效。但是，已经出现了新的解决方案来解决相同的问题。在迁移过程中，我们适应了新的现实。

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

八月。意识到需要进行彻底的试验，我们开始移动数据。我们的目标是在一个月内，最多六周内完成传输，同时还进行必要的重构，这也将花费大约一个月的时间。这是我们第一个错误浮出水面的地方。我们的两位工程师经常因与业务相关的任务而分心，导致延误。因此，我们只能在计划的时间范围内完成一些事情。

九月。我们整个月都在移动数据并进行必要的调整。

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

十一月。还剩一个月的时间，我们似乎能够稍微喘口气，更细致地专注于传输和验证数据。准确性是我们的首要任务。团队做得非常出色。到 11 月中旬，我们几乎准备好将分析切换到新系统。

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

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

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

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

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

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