Django应用EC2出现短时CPU峰值 应选用什么AWS服务优化？

现有负载评估 #

你当前使用的t3.large属于AWS突发性能型实例，本身就适配低平均负载、偶发高CPU消耗的业务场景。从给出的CPU指标来看，平均使用率仅2-3%，峰值最高40%，现有实例的计算资源完全可以覆盖当前业务需求，不需要升级更高规格的通用/计算优化型实例，优化核心围绕资源隔离、可靠性、成本三个方向展开。

• 服务拆分资源隔离
  把Celery worker进程和Django Web服务拆分到不同EC2实例部署，避免混布场景下短信CPU密集任务抢占Web服务的CPU资源，导致普通用户的接口响应变慢。Celery侧可以选择更低配的t3.small/t3.medium实例，毕竟任务耗时短、整体负载低，额外增加的成本极低，还能彻底避免资源竞争问题。
• t3实例参数适配
  确保你的t3实例开启了无限制积分模式（Unlimited Mode），AWS突发型实例默认的CPU积分机制刚好匹配你短时间高CPU消耗的任务特征，开启无限制模式后可以避免短时间大量任务触发导致积分耗尽、CPU被限流的问题，当前30-40%的峰值就算业务量翻2倍也不会产生额外的超额积分费用，性价比远高于换用C系列计算优化实例。
• 任务队列调度优化
  给Celery配置独立的短信任务专属队列，和其他IO密集型异步任务分开调度，避免不同类型任务相互阻塞。后续如果短信任务量上涨，只需要给短信队列新增Celery worker节点即可水平扩容，不需要调整Web服务的资源配置。
• 成本优化可选方案
  目前你的实例CPU资源空置率极高，如果压测验证后t3.medium可以稳定支撑Web服务负载，可以直接降配到t3.medium，成本直接降低50%。也可以把Celery短信任务替换为AWS Lambda无服务架构，只有任务触发时才会计费，无任务时不产生成本，比长期保有EC2实例性价比更高，天生适配短耗时CPU密集任务的场景。
• 监控告警补全
  新增三个核心指标的告警规则：EC2 CPU使用率超过70%、Celery任务队列堆积超过100条、短信任务执行延迟超过5秒，触发告警后及时处理，提前感知业务增长带来的资源压力。

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