游戏卡顿白皮书 › L13 服务器架构与运维
弹性伸缩延迟 Autoscaling lag
原因 ID in-autoscale · 主责 运维团队·系统运维 · 配合 研发团队·服务器开发
在含图示和实验的完整版中打开此卡片 →
人一多就会自动增加服务器，但准备要几分钟，这段时间现有服务器处于过载状态。
起因 活动开始，连接数激增 → 结果 新服务器从启动到就绪要几分钟 → 画面表现 活动开始后的几分钟内出现慢动作、连不上
症状 慢动作 , 连不上/无限加载 因素 停顿
谁会遇到 全服
何时出现 人多的时候, 刚登录/维护结束后
负责方 主责 运维团队·系统运维 · 配合 研发团队·服务器开发
研发团队要做的事 分线分流（已经在拥挤分线里的人无法迁到新服务器），缩短新服务器的启动和数据加载时间。
运维团队要做的事 活动前提前扩容，准备好已预热的备用服务器，缩容时等剩下的人离开后再关机。
数值参考 检测到负载需要 1 到几分钟（指标按几分钟的平均值来看），启动新服务器、读取游戏数据、填充缓存又要几分钟。
监控图上 查看位置 把弹性伸缩的活动记录（决定扩容的时刻、新实例开始提供服务的时刻）叠加到 CPU 利用率、连接数的监控图上。AWS 看 Auto Scaling 组指标（需开启才能看到）GroupDesiredCapacity（目标台数）、GroupPendingInstances（准备中）、GroupInServiceInstances（服务中） 确认依据 连接激增后的几分钟里，只有目标台数和准备中的实例增加，现有服务器 CPU 一直顶在上限，从服务中实例增加的时刻起才缓解 排除依据 新实例加入后仍然慢，则是服务器台数以外的原因（DB 等公共资源、级联故障） 确认手段 运维工具即可确认（无需游戏代码）
深入了解 弹性伸缩主要用在登录、网关、副本这类只要让新服务器接新玩家就行的地方。缩容时也会出问题。凌晨人少时缩减服务器，如果不等剩下的人离开就关机，这些人就会掉线。
真实案例 AWS 2021: AWS us-east-1 内部网络拥塞 AWS 2025: AWS us-east-1 DynamoDB DNS 故障与漫长的恢复
出处 Target tracking scaling policies for Amazon EC2 Auto Scaling AWS EC2 基础指标为 5 分钟粒度（开启详细监控为 1 分钟），想要快速响应，建议使用 1 分钟及以下粒度的指标 Amazon CloudWatch metrics for Amazon EC2 Auto Scaling AWS 组指标需要开启才会按 1 分钟粒度发布，GroupDesiredCapacity（要维持的台数）、GroupPendingInstances（尚未投入服务的实例数）、GroupInServiceInstances（服务中的实例数） Scheduled scaling for Amazon EC2 Auto Scaling AWS 针对可预测的负载变化，在设定的时间提前扩容和缩容 Decrease latency for applications with long boot times using warm pools AWS 启动耗时长的应用，用预先初始化好的实例池（暖池，warm pool）减少扩容延迟 相关原因
同一层：L13 服务器架构与运维
其他层中同样导致“慢动作”的原因
查看含图示和实验的原卡片