summary
2020-11-25，AWS Kinesis 在 us-east-1 的前端服务器舰队（front-end fleet）扩容时，每台服务器与舰队中其他所有服务器各维持一条 OS 线程，舰队规模增大使每服务器线程数呈 O(N²) 增长并突破操作系统配置的最大线程数。线程创建失败后，前端服务器无法完成 shard-map 缓存构建，路由失效，Kinesis 及依赖它的 CloudWatch/Lambda/Cognito/API Gateway 等数十项服务中断，全程约 17 小时。
timeline
02:44-03:47 PST 向前端舰队添加容量（触发但非根因）。05:15 PST 首批 Kinesis 读写错误告警。07:51 PST 缩小根因到需全量重启前端舰队。09:39 PST 确认根因为线程数超限（非内存压力）。10:07 PST 第一组服务器恢复流量。因需避免惊群，仅能以每小数百台速度重启；Kinesis 于 22:23 PST 完全恢复正常。
root_cause
Kinesis 前端舰队采用线程-每-对等节点模型，线程数随舰队规模线性增长，聚合为 O(N²)。一次常规容量扩充使各前端服务器的 OS 线程总数超过系统配置上限，缓存（shard-map）构建失败，服务器拿到无效 shard-map 无法将请求路由到后端集群。
amplifiers
① 单体前端：前端非细胞化（未分舱），单点故障即舰队级。② 重启惊群：重启时 shard-map 构建与请求处理争用资源，过快重启会被判不健康并移除，重置进度，被迫限速（每小数百台）。③ 监控盲区：CloudWatch 依赖 Kinesis 摄取指标，故障后监控失明，Service Health Dashboard 发布工具经 Cognito 认证也失效。
mitigation
先移除触发扩容的新容量；为前端服务器增加配置使其直接从权威元数据_store 引导（避免启动期依赖对等节点）；以限速方式全量重启前端舰队。后续将前端架构从线程模型改为事件驱动模型，并提高 OS 线程上限测试覆盖。
lessons
隐藏的 O(N²) 依赖会在规模跨越阈值时爆发；监控/状态系统不得依赖其监控的对象；重启必须限速并消除资源争用。
checklist
① 容量模型压测覆盖舰队规模阈值。② 控制面与数据面依赖解耦（监控不依赖被监控服务）。③ 重启限速+启动期权威数据源。④ 前端细胞化以限制爆炸半径。