AWS 工程师用动画演示系统故障：从 Raft、Postgres 到 etcd 的元稳定性问题

关于我

我叫 Marc Brooker。我喜欢构建能正常运作的东西，也喜欢做点酷炫的事。我喜欢构建大型系统。我也偶尔涉猎机械加工、焊接、烹饪和滑雪。

我是位于西雅图的 Amazon Web Services (AWS) 的一名工程师，从事 agentic AI 相关工作，尤其是 agentic AI 的安全与策略。在此之前，我从事过 EC2、EBS、数据库、无服务器以及无服务器数据库方面的工作。
以上均为个人观点。

链接

我的出版物和视频
Mastodon 上的 @marcbrooker Twitter 上的 @MarcJBrooker

这个博客是 AI 写的吗？

漂亮的图片也许能帮助我们学习？

我喜欢用 LLM 做的事情之一，就是帮助我更好地理解系统。在 Strands Decider 那篇文章中，我写到过我经常让模型向我提问，以检验我是否理解了这一点。我现在很喜欢的另一种技巧，也是我很高兴看到身边的人也在用的，就是构建动画。

动画可以帮助我们建立直觉，理解系统如何运作、为何如此运作，或者如何失效、为何失效。

这里有一个例子：你知道吗，一个 Raft 集群即使只有一个成员的存储层在 fsync() 上撒谎，也可能丢失写入？

当我构建 Stability Sim 时，我想帮助工程师更好地理解亚稳态故障。这在抽象层面上效果相当不错（例如 重试和队列让亚稳态非常容易被触发），但我仍然听到有人怀疑这些行为是否真的会发生在真实系统中。毕竟，那些真实系统都经过了生产环境的验证，如果这些行为存在，我们不是早就应该把它们排查掉了吗？

让我们从 Postgres 开始。

在这个例子中，数据采集自运行在真实 MicroVM 中的真实 Postgres 16 的跟踪记录。在负载尖峰之前，数据库轻松应对每秒 20 次查询的负载，因为整个工作集都驻留在页缓存中。但在负载尖峰之后，我们运行查询占用了大量内存（每个查询占用 12MB），这些查询现在变慢了，因为它们是从磁盘而不是页缓存中读取的。我喜欢这个例子，因为它表明即使是简单的、非分布式系统也会有这些行为。

那 etcd 呢？

同样，我们有负载尖峰触发了亚稳态。这次是写入。过载的对等节点看起来像是不可用，这触发了应用层重发风暴。我喜欢这个例子，因为 etcd 是被广泛使用的高质量软件。运维经验似乎并不能有效地排查掉这类问题。

当我写 垃圾回收与亚稳态时，一位知名的系统领域学者告诉我，这是幻想。我在现实中见过这种情况发生，只是无法分享，而且基于博客中含糊其辞的论述，我能原谅人们不相信这会发生。

所以能有一个真实世界的例子是件好事，这次又拿 etcd 开刀。

一开始，我们以每秒 500 次读取平稳运行，之后将负载尖峰提升到每秒 1000 次读取。读取尖峰增加了 GC 花费的时间，提高了平均存活时间，并减少了可用于读取工作负载的 CPU。这是一个自我强化的循环，系统在没有干预的情况下无法恢复。

我相信同样的事情也可能发生在没有 GC 的运行时上，原因是分配器中的工作量增加，但还没能复现这一点。

这里的动画全部由 Kiro 和 KiroCrew 生成，主要使用 Opus 5.5。实际结果来自真实的测试环境，该环境捕获了支撑这些动画的轨迹。