摘要

  • Kinesis 新增前端服务器时，旧服务器也要为更多同伴建立线程；扩容把整个前端集群推过了操作系统设定的线程上限。
  • 修复随后受制于另一种容量：重建路由信息与处理用户请求争抢资源，数千台服务器只能以每小时数百台的节奏接回服务。

AWS 给 2020 年 11 月 25 日那场故障开出的一项短期药方，听起来很不云计算：换更大的服务器，把服务器总数降下来。

云的广告喜欢向右增长的曲线。机器更多，容量更大，业务随时放量。Kinesis 这次把曲线拧了回来。新机器不仅增加处理请求的能力，也给已经工作的机器增加了协调任务。后一笔账先撞上天花板，前一笔账便暂时失去了兑现的入口。

这件事发生在美国北弗吉尼亚的 US-EAST-1 区域。AWS 在官方事故复盘里，明确把一次规模较小的扩容称为触发因素，把操作系统线程上限列为根因。两者分开，才看得清楚问题：日常增加机器这件事，碰上了一个会随集群扩大而逼近的限制。

机器到了，路由表没准备好

Kinesis 的后端按单元集群处理分片数据流。前端负责认证、限流，把请求送去正确的后端分片。每台前端服务器需要一份映射，知道集群成员与分片归属；构建这份映射还要同其他前端交换消息，为同伴创建操作系统线程。

增加一台服务器，影响的就不止那台新机器。旧成员发现新同伴后，也得承担新的通信工作。AWS 说，已有成员发现新增节点最多会花一个小时。因此，安装完成的时刻，也未必是全部协调负担已经显现的时刻。

线程用到上限，映射构建无法完成。后端有处理能力，前端却拿着无法使用的地图。对一个请求而言，目的地存在、入口找不到路，照样办不成事。

后端已经划分故障隔离单元，也没替前端交掉这笔协调账。架构图上画了几个方框，不能自动证明所有共享环节都被关进各自的方框。

找到问题之后，还得排队恢复

这场事故的第二个价格标签，贴在恢复速度上。

AWS 撤掉了新增容量，也没有在缺少进一步测试时直接调高操作系统限制。下一步是重启前端。但服务器启动时重建映射，与服务器上线后处理请求，需要争用资源。接回来太快，机器就会响应缓慢、被判为不健康、再退出集群，恢复反而倒退。

数千台机器，只能每小时接回数百台。AWS 还修改了启动方式，让前端直接向权威元数据存储取信息，减少对邻居的依赖。第一组前端在太平洋标准时间上午 10 时 07 分开始接流量，Kinesis 到晚上 10 时 23 分恢复正常；过程中错误率逐步下降。

根因找到了，生意还没有立即恢复。设备数量与恢复吞吐量，在这里成了两个不同的经营指标。平时跑得快的系统，重新学会自己负责哪条路时，可能跑得很慢。

原来只是记个日志，后来挡住了登录

账又传给下游。Cognito 用 Kinesis 收集、分析接口访问模式，原本采取尽力而为的设计，并在本地缓冲。持续故障触发缓冲代码中的潜在缺陷，积压开始阻塞网页服务器，一些用户无法认证或取得临时凭证。

附属信息的传输，挤进了主要业务能否继续的条件。缓冲最初争取了时间，持续时间一长，便暴露出另一条失效路径。把缓冲做大可以延后满载；积压满了以后会发生什么，才决定它究竟隔开了故障，还是只替故障安排了晚一点的约会。

CloudWatch 的指标与日志处理也受影响，部分告警进入数据不足状态，依赖这些指标的反应式自动扩容出现延迟。Lambda 则因指标缓冲造成主机内存争用而增加调用错误。它们继承了同一个上游事件，却没有以同一种方式失败。

甚至普通状态公告工具也因依赖 Cognito 而一度无法更新。备用工具能用，操作更手工、员工较不熟悉，公告仍被拖慢。服务出问题时，帮助人看懂问题的工具，也需要自己的生存空间。

少一些邻居，多一些余地

AWS 的整改清单值得按机制读。更大的机器意味着所需前端数量减少，每台服务器要维持的同伴线程也随之减少；更细的线程告警照顾渐近的限制；缓存独立、部分大型服务的前端分区，以及加快前端单元化，则着手缩小共同失效的范围。

这里真正值钱的是边界。卖家交付的机器越多，每台机器需要知道和照顾的世界是否也越大？一次局部新增，能否给所有既有节点添工作？恢复时谁先取得元数据，谁先接客户流量，限速又由谁承担？这些问题，比机柜总数更接近能兑现的容量。

AWS 的静态稳定性说明把目标落在依赖失灵时仍能工作的系统上；故障容忍与隔离白皮书也直说，预先准备冗余资源要花钱。便宜的待命与昂贵的等待，总得有人选。

这份历史复盘没有今天的前端规模上限和完整重启测试；有条件、有负载的现行测试，才足以改变对当前恢复能力的判断。2020 年留下的经营问题已经很具体：采购容量时，顺便问一句，系统重新站起来的速度，是否也在报价里面。