针对AWS上WordFreq应用的Auto Scaling策略指标选型咨询

核心推荐指标 #

• 单实例CPU利用率：别用总和，盯单个实例的（建议阈值设70%-80%）。WordFreq做词频统计属于CPU密集型任务，处理文档时CPU占用会明显飙升，单实例指标能直接反映每个节点的真实负载。ASG是按实例维度扩缩，总和指标会被实例数量稀释，比如10个实例各跑50%，总和看着很高，但单个实例根本没压力，容易误触发扩容。
• 任务队列长度（如果是异步架构）：要是你的应用是先把文档放进队列再异步处理（比如用SQS），队列待处理消息数是更精准的指标。比如设定当队列消息数超过100条/现有实例数时扩容，低于20条缩容——这比CPU指标更提前感知负载，避免CPU跑满后才扩容导致的处理延迟。
• 自定义业务指标：能埋点的话，统计每秒处理文档数或者单文档处理耗时更贴合场景。比如当单文档处理耗时超过5秒，说明实例负载顶不住了，直接触发扩容，比CPU指标更懂业务实际压力。

为啥不选CPU利用率总和 #

• 总和会被实例数量平均，没法反映单个节点的负载情况。举个例子：2个实例各跑90%，总和才180%；10个实例各跑50%，总和500%——后者单个实例负载低根本不需要扩容，但看总和会误判。
• ASG的扩缩动作是加/减实例，单实例指标才能精准触发合适的调整。

配置小技巧 #

• 先从单实例CPU利用率入手，AWS CloudWatch默认就能采集，设置阈值：比如CPU>=75%持续2分钟就加实例，<=30%持续5分钟就减实例，先跑起来再调。
• 要是用了队列，把队列深度作为辅助指标，和CPU指标配合着用，覆盖更多负载场景。
• 测试时上传不同大小的文档，观察指标变化，把阈值调到不会频繁扩缩（避免震荡）的范围。

内容的提问来源于stack exchange，提问作者Naman Agarwal