使用托管数据库的隐性成本

本文要点

• 托管关系型数据库有代管、可扩展和成本方面的优势，其使用量近来急剧上升。

• 用户需要监控服务成本，其中包括出口费，并修改其工作负载的默认设置。

• 用户应该了解使用托管服务时所涉及的运营成本。

• 用户必须更多地了解其局限性，例如缺乏灵活性、可观察性等。

• 用户必须对何时使用托管数据库解决方案做出明智的决定。

2024 年，云计算无处不在，但很多时候并不引人注意（如 iCloud 和 Google Docs）。云计算已经变得像真正的云一样无处不在。云计算的许多优点，如弹性、可扩展性和易用性，现在都得到了很好的理解。它们缩短了新产品上市的时间，并解决了现有产品的扩展挑战，而且无需经历艰辛的计划和采购过程。

由于存在这些优势，我们看到，人们对数据库、消息队列、应用程序运行时等托管服务有着巨大的需求。然而，本文要讨论的是云计算较少讨论的一面：使用托管服务（特别是托管关系型数据库）的隐性成本。

作为Cloudflare数据库从业者和Omnigres构建人员，我有在纯内部部署、公有云和混合等环境中开发、管理和操作数据库的经验。从业务角度来看，每种模式各有其优缺点。一旦公司采用了公有云，使用任何托管服务都变得相当简单，数据库只是一次点击而已。

一项服务想要吸引用户使用首先得具备易用性。如果它在大多数情况下都有效，那还有什么理由不继续使用，甚至更进一步呢？为什么不创造更多这样的东西呢？

成本——实实在在的美元

来自云提供商的托管数据库在运行、备份和监控等方面提供了很多价值。它们还提供了高可用性。在 SCaLE20x 大会上，我介绍了构建自托管数据库服务的挑战：将这项工作转移给提供商可以减少运营成本，缩短上市时间，并带来更多的灵活性。当然，提供商提供了这些好处，就得向用户收费。

首先，计算托管数据库的成本并不简单。成本取决于多种因素，例如：

1. 实例大小和类型（小、大、超大）

2. 定价模型（按需、预留）

3. 存储（通用、预配置 IOPS、实际 IOPS）

4. 数据传输成本（VPC 内/VPC 外、区域间/区域内）

5. 实例引擎（PostgreSQL、MySQL、SQL Server 等）

6. 备份存储频率和保留时限

7. 部署类型（单/多 AZ、无服务器）

尽管很复杂，但还是可以量化的。有些第三方工具可以简化价格计算。此外，诸如禁用多可用区域、停用开发环境实例等也是很常见的成本优化措施。沃尔玛等公司开始转向混合云。与此同时，像Basecamp这样小一些的公司出于成本考虑，已经将他们的大部分服务从云上迁移了出去。

要了解托管服务的成本是否值得，就必须了解其使用模式。云计算的主要优点是灵活性；如果不需要这个，也可以在自己的硬件上运行数据库。让我们看一些成本更主观、更难以度量的领域。

负载失控，无谓支出

云计算独有的价值主张之一是可扩展性。如果网站或产品一夜成名，也不需要购买基础设施来支撑暴涨的工作负载。这很好，但有一个问题，如果不谨慎使用，也可能会造成意外。想象一下，数据库上有一个失控的或恶意的工作负载，由于许多云提供商都是根据 IOPS 或 CPU 时间等收费，所以这些工作负载可能会无谓地产生一笔数额巨大的账单。

出口费——数据进来容易，要出去就不那么简单了

在多云或混合云设置中，服务需要跨不同提供商的网络进行通信。通常，将数据（入口）传入托管数据库不会产生数据传输成本。然而，将数据传出（出口）则是有成本的。对于需要从托管数据库服务传出数据的企业来说，出口费是一个重要的成本因素。从某种意义上说，这是为了限制用户迁出他们的数据。

像 Cloudflare 这样的提供商非常清楚这一挑战，他们创建了带宽联盟，旨在降低或免除成员提供商之间的数据传输成本。最近，谷歌云取消了将数据迁移到另一家云提供商的数据传输费。这种做法是如此的不公平，以至于欧盟和英国的监管机构正在积极进行调查。

运营成本——还是有很多事情要做

虽然服务提供商负责第 0 天的操作，但用户还是要面对第 1 天和第 2 天的挑战。期望提供商解决所有的运营挑战是不合理的。不过，了解下需要做些什么操作以及涉及哪些成本还是好的。

a）二次备份

数据是业务的核心。我认为，如果数据完好无损，任何软件业务都可以重建。作为一名数据库工程师，数据丢失是我迄今为止最大的噩梦。执着于备份并不是一件坏事。完全依赖提供商进行备份就像把所有鸡蛋放在一个篮子里。即使提供商提供了一个很好的 SLA/SLO，但是完全丢失备份的风险依然存在。

在大多数情况下，保护数据是企业对最终用户的责任。大多数成熟的组织在其主要服务提供商之外都有二次备份。要做到这一点，就得付出存储和计算、数据传输和工程成本。

b）备份恢复

备份的质量由恢复能力决定。如果备份无法恢复，那么它们还有什么价值呢？遗憾的是，在这方面，许多提供商都没有做任何事情，而是把这部分工作留给了他们的用户。这个问题很复杂，但也很容易理解，因为提供商无法知道每家企业的需求。因此，用户需要经常进行自动或手动测试，以验证备份及恢复过程的完整性。

服务停止——这是常有的事

遗憾的是，随着事情的发展，有些服务可能会停止。去年，Azure 上的MariaDB就退役了。Aurora Serverless V1在2024年后也将不再支持。如果数据库是闭源的，那么唯一的出路就是使用提供商提供的工具将其导出到其他地方。实际上，数据迁移的架构必须能够减少数据丢失和服务停机时间。如果服务是基于像 Postgres 这样的开源数据库，甚至是使用了开放协议（例如 Postgres Wire Protocol），那么迁移起来就更容易一些。然而，数据库/数据迁移总的来说是很痛苦的。

缺乏灵活性——无法完全控制

由于托管服务往往会专注于解决常见的问题，所以有时很有局限性。提供商必须为数千客户管理许多服务，因此很难甚至不可能提供充分的灵活性。可能开始的时候，这听起来并不是什么问题，但随着业务的发展，那可能会开始造成伤害。例如，Postgres 有一个庞大的扩展生态系统。

许多托管服务只允许安装其中的一部分扩展。例如，AWS和GCP不支持pg_ivm（增量视图维护）和zombodb（简化 Postgres 中的搜索）等开源扩展，这可能严重限制你可以构建或依赖的特性。

缺乏可见性——发生了什么？

作为一名工程师，没有什么比有工程问题无法解决更让我沮丧的了。在某种程度上，数据库可以看作是一个黑盒子。大多数数据库用户都把它们作为存储和检索数据的地方。他们不用太关心数据库里发生了什么。尽管如此，当某些东西出现故障时，用户仍然可以使用提供商提供的工具排除故障。

通常，提供商会使用一些虚拟化技术（虚拟机、容器）来运行数据库，有时甚至由编排器（如 k8）来操作。而且，对于运行数据库的服务器，它们不一定会提供完整的访问权限。多层抽象并没有让事情变得更简单。

虽然提供商不提供完整的访问权限是为了防止用户“搬起石头砸自己的脚”，但可能会有高级用户需要更高的权限来了解不同栈上发生的事情并解决潜在的问题。这是我选择自托管软件时考虑的主要因素，目的是获得最大的控制权限。这可能涉及到托管在我本地的数据中心或利用一些基本组件，如虚拟机和对象存储，让我可以创建和管理我的服务。

此外，在Hacker News等论坛上也有大量关于自托管与托管服务的讨论。其中一条评论总结道：

这里（自托管）肯定有一些东西需要考虑。不过，我发现大多数人都大大高估了与之相关的工作量。

 

此外，他们往往低估了使用托管解决方案时所需的工作量。例如，即使对于托管选项，你肯定也希望进行二次备份和恢复测试。

我注意到，还有一个副作用是，团队倾向于在遇到问题时投入更多的资金（增加实例大小），希望借此在无法确定根本原因的情况下解决他们的一些挑战。根据Ottertune（一家专门从事数据库工作负载调优的公司）的说法，如果不经过专业的调优配置，即使是增加实例类型，也不会带来成比例地性能提升。

无论你的技能水平如何，这个挑战也都几乎是无法解决的。例如，Kyle Kingsbury是分布式系统专家，也是Jepsen test（用于验证分布式系统的安全性和一致性）的作者。在测试 MySQL 8.0 版本的正确性时，他遇到了一个数据库复制问题，并向服务提供商寻求了支持。

一个越来越明显的趋势是，服务提供商依赖于其他托管提供商来交付解决方案。然而，当基础提供商未能满足期望或表现不佳时，他们就会产生挫败感。关键是，即使支付了高昂的价格，并与供应商签订了业务 SLA，他们也无能为力。

权衡

你可能已经注意到，本文有一个不变的主题，就是权衡。本文的目的不是阻止任何人使用云计算或托管服务。本文主要是为了让人们意识到其中所涉及的成本、保持开放和提供商锁定之间的界限、有限的功能集、可见性的缺失以及必须进行的 Day-2 操作。

当第一次开始使用托管数据库服务时，我并没有留意到这些方面。希望本文能帮助开发商和运营商做出明智的决定。

声明：本文为 InfoQ 翻译，未经许可禁止转载。

原文链接：https://www.infoq.com/articles/managed-relational-databases-costs/