EBS 的真实故障率分析
⚡ 现已推出具有无限 IOPS 的超快 NVMe 驱动器。了解 PlanetScale Metal ⚡
EBS 的真实故障率
By Nick Van Wiggeren | 2025 年 3 月 18 日
PlanetScale 已在全球部署了数百万个 Amazon Elastic Block Store (EBS) 卷。 我们每天创建和销毁数万个 EBS 卷，以便为客户启动数据库、进行备份以及端到端地测试我们的系统。 通过这种经验，我们对 EBS 的故障率和机制有了独特的见解，并且花费了大量时间来研究如何缓解这些问题。
在复杂的系统中，故障不是一个二元结果。 云原生系统构建时没有单点故障，但部分故障仍然可能导致性能下降、用户面临的可用性降低以及未定义的行为。 通常，堆栈中某个部分的微小故障会表现为其他部分的完全故障。
例如，如果多节点分布式缓存系统中的单个实例耗尽了网络资源，则下游应用程序会将错误情况解释为缓存未命中，以避免请求失败。 这将导致应用程序向数据库发送大量查询以获取数据，就像数据丢失一样，从而使数据库不堪重负。 在这里，一个级别的部分故障会导致数据库层的完全故障，从而导致停机。
Defining Failure
虽然 EBS 的完全故障和数据丢失非常罕见，但“慢”通常与“失败”一样糟糕，而且这种情况发生的频率要高得多。
以下是“慢”在 AWS Console 中的表现：
该卷已经稳定运行了至少 10 个小时。 AWS 报告称，它的空闲率为 67%，写入延迟测量值为个位数毫秒/操作。 完全符合预期。 突然，在 16:00 左右，写入延迟飙升至 200ms-500ms/操作，空闲时间降至零，并且该卷实际上被阻止读取和写入数据。
对于运行在此数据库之上的应用程序而言：这是一个故障。 对于用户而言，这是在等待 10 秒后网页上显示的 500 响应。 对你来说，这是一个事件。 在 PlanetScale，我们认为这是完全故障，因为我们的客户也这么认为。
EBS 文档 可帮助我们理解 AWS 的 gp3 能够做出的承诺：
当连接到 EBS 优化实例时，通用 SSD（gp2 和 gp3）卷旨在在一年中的 99% 的时间内提供至少 90% 的预配置 IOPS 性能
这意味着预计卷在 1% 的时间内会遇到低于 90% 的预配置性能。 这相当于每天 14 分钟或每年 86 小时的 潜在 影响。 这种性能下降率 远远 超过单个磁盘驱动器或 SSD 的性能下降率。 这是分离存储和计算以及客户端和卷的后备磁盘之间的软件和网络组件的巨大复杂性的代价。
根据我们的经验，该文档是准确的：有时卷会在很短的时间窗口内进入和退出其预配置的性能：
但是，这些短时间窗口足以对实时工作负载产生影响：
生产系统并非旨在处理这种程度的突然变化。 如果没有任何保证，即使过度配置也无法解决问题。 如果这是百万分之一的机会，那将是不同的，但正如我们将在下面讨论的那样，事实远非如此。
The True Rate of Failure
在 PlanetScale，我们每天都会看到这样的故障 - 故障发生得足够频繁，以至于我们构建了直接监控 EBS 卷的系统，以最大限度地减少影响。
这不是秘密，它来自文档。 AWS 没有描述 gp3 卷的故障是如何分布的，但根据我们的经验，它往往持续 1-10 分钟。 这可能是网络或计算组件中进行故障转移所需的时间。
让我们假设以下情况：每个降级事件都是随机的，这意味着性能降低的程度介于预配置的 1% 和 89% 之间，并且你的应用程序旨在承受丢失 50% 的预期吞吐量然后才会出错。 如果每个单独的故障事件持续 10 分钟，则每个卷每月将经历约 43 个事件，其中至少有 21 个事件会导致停机！
在一个由许多分片组成的大型数据库中，这种故障会加剧。 假设一个 256 个分片的数据库，其中每个分片都有一个主分片和两个副本：总共配置了 768 个 gp3 EBS 卷。 如果我们采用上述 50% 的阈值，则在任何给定时间，你至少有 99.65% 的几率至少有一个节点正在经历影响生产的事件。
即使你使用 io2（AWS 以 4 到 10 倍的价格出售），你仍然预计在一年中的大约三分之一的时间内处于故障状态，仅仅是在这一个数据库上！
更糟糕的是，我们还经常看到这些作为单个区域内的相关故障，即使使用 io2 卷也是如此：
有了足够的卷，体验 EBS 故障的几率是 100%：我们的自动化缓解措施始终在回收性能不佳的 EBS 卷，以减少客户的影响，并且我们预计每天会看到多个事件。
这就是 EBS 的真实故障率：它是恒定的、可变的，并且完全是按设计进行的。 由于当卷未按其规格运行时，没有任何性能保证，因此对于需要一致性能的工作负载来说，很难围绕其进行规划。 你可以为额外的 9 个 9 付费，但是随着足够多的驱动器在足够长的时间内运行，故障是有保证的。
Handling Failure
在 PlanetScale，我们的缓解措施已限制了影响窗口的预期最大时间。 我们密切监控读取/写入延迟和空闲百分比等指标，甚至开发了基本测试，例如确保我们可以写入文件。 这使我们能够快速响应性能问题，并确保 EBS 卷不会“卡住”。
当我们使用这些启发式方法检测到 EBS 卷处于降级状态时，我们可以在几秒钟内对集群中的另一个节点执行零停机重新父化，并自动启动一个替换卷。 这不会将影响降至零，因为不可能在故障发生之前检测到该故障，但它确实确保了大多数情况不需要人工干预，并且在用户注意到之前就已经结束了。
这就是我们构建 PlanetScale Metal 的原因。 通过使用本地存储而不是像 EBS 这样的网络连接存储的无共享架构，数据库中的其余分片和节点能够继续正常运行而不会出现问题。