EBS 的真实故障率
引言
PlanetScale 已在全球范围内部署了数百万个 Amazon Elastic Block Store (EBS) 卷。每天，我们创建并销毁数万个 EBS 卷，用于满足客户数据库需求，完成备份，以及进行端到端系统测试。通过这一丰富经验，我们对 EBS 的故障率及其机制有独特的视角，并且通过大量工作探索了如何减轻它们的影响。
在复杂系统中，故障并不是一个简单的二进制问题。云原生系统设计为避免单点故障，但部分故障仍可能导致性能下降、用户可见的不可用以及定义行为异常。通常，堆栈中的某个部分出现的小故障会影响其它部分并显现为全面故障。
例如，如果分布式缓存系统中的某个节点耗尽了网络资源，下游应用程序可能将错误情况解释为缓存未命中，以避免请求失败。然而，当应用以查询洪流向数据库获取数据时，这会导致数据库负载过重。在这种情况下，某一层级发生的局部故障会演变为数据库故障，从而引发宕机。
重新定义“故障”
对于 EBS，尽管发生完全故障和数据丢失的概率非常低，“慢速”对系统来说陪并不比“失败”情况好多少，而且慢速状况发生得更频繁。
看看 AWS 控制台中的慢速表现：
该 EBS 卷已连续运行至少 10 小时，AWS 控制台显示其任务闲置率为 67%，写入延迟保持在单位毫秒范围内，符合预期。然而，忽然在某时间点（16:00 左右），写入延迟飙升至每操作 200 毫秒至 500 毫秒，闲置率降至零，卷无法正常处理读写任务。
对于运行在该数据库之上的应用程序来说，这就是一次“故障”。对用户来说，这表现为网页返回 500 错误并等待约 10 秒。对你来说，这是一个事故。对于 PlanetScale 来说，我们将这视为完全故障，因为我们的客户也这样认为。
AWS 的 EBS 文档定义
AWS 的 EBS 文档提供的信息帮助我们理解 gp3 可以承诺的性能：
当连接到支持 EBS 的优化实例时，通用 SSD（gp2 和 gp3）卷设计为在一年中超过 99% 的时间内至少能提供其工作性能的 90%。
换言之，在理论上，1% 的时间内 EBS 性能可能会低于其规定的速度，大约每天 14 分钟，或者全年 86 小时。这远超单个硬盘或 SSD 设备的故障率。这是将存储和计算分离以及客户端与存储磁盘之间复杂的的软件与网络设计的代价。
实践中，文档中的描述是准确的：某些卷确实从它们的设定性能进进出出，持续时间在短窗口范围内：
然而，即便短时间窗口，仍会对实时工作负载产生影响：
生产系统并非为此类突如其来的性能波动量身打造。当性能表现没有保障时，即便过度配置资源也无法解决问题。而且，这种情况并非百万分之一次——实际上相去甚远。
真实的故障率
在 PlanetScale，我们每天都能感受到类似故障——故障的出现频率足以促使我们构建直接监控 EBS 卷的系统，尽量减少其对用户产生的影响。
这些并不是什么秘密，它们早已包含于 AWS 文档中。AWS 没有详细描述 gp3 卷的故障分布，但根据我们的经验，其波动情况多持续 1 到 10 分钟，可能是网络或计算组件切换故障的时段。
假设以下情况：
- 每个性能下降事件是随机的，降级程度在规定性能的 1% 到 89% 之间；
- 你的应用设计为能承受吞吐量丢失 50%；
- 每次故障事件持续 10 分钟。
那么，每个 EBS 卷大约每月会经历约 43 次故障事件，其中至少 21 次会导致宕机！
分片数据库的冲击
在一个由许多分片组成的大型数据库中，这种故障会进一步加剧。假设一个 256 分片数据库，每个分片有一个主库和两个副本，总计 768 个 gp3 EBS 卷。如果我们以上述 50% 承受阈值作为标准，则任意时间点，该数据库至少会有一个节点存在生产影响事件的概率是 99.65%。
即使使用 AWS 售价 4 倍甚至 10 倍 gp3 的 io2 卷，这样的数据库一年仍有三分之一的时间处于故障状态！
更糟糕的是，我们发现单一可用性区域内的故障常常具有相关性，即使是使用 io2 卷：
当卷数量足够多时，故障的出现率几乎是 100%：我们的自动化机制可以持续筛选性能较低的 EBS 卷以降低客户影响，但我们仍在每天看到多起性能下降事件。
EBS 的真实故障率就在这里：它是恒定的、可变的，且归因于设计。由于当卷性能低于设定规格时没有任何保障，对于需要稳定性能的工作负载，它非常难以规划。你可以为额外的性能数据付费，但只要卷数量足够多、时间足够长，故障就是不可避免的。
如何处理故障
在 PlanetScale，我们的缓解方法已将性能下降的最大窗口时间限制到最低范围内。我们紧密监控读写延迟、闲置率等指标，甚至运行基本测试（例如，确保可以正常写入文件）。这使我们能够快速判断性能问题，并确认某个 EBS 卷是否陷入“卡住”状态。
当通过这些启发式检测发现某 EBS 卷处于性能下降状态时，我们可以在数秒内无停机时间重新分配集群中的节点，并自动启动替换卷。尽管无法在故障发生前检测，但这一机制确保绝大多数情况下无需人工干预，且用户未注意到问题前故障已经解决。
EBS 的设计使其在存储与计算分离方面具有发展便利，但它带来的性能局限性无法忽视。通过自动化和冗余系统，PlanetScale 有效缓解了 EBS 的可预测故障影响，同时继续为客户提供可靠的服务。
关注公众号：程序新视界，一个让你软实力、硬技术同步提升的平台
除非注明，否则均为程序新视界原创文章，转载必须以链接形式标明本文链接
