通过 cpu 利用率自动扩展 t3 实例？

Posted 2023-03-04

【中文标题】通过 cpu 利用率自动扩展 t3 实例？

【英文标题】：Auto-scaling t3 instances by cpu utilization?

【发布时间】：2019-07-10 19:23:07

【问题描述】：

t3 实例是burstable above baseline，那么CPUUtilization 必须如何考虑自动缩放？

假设我们使用 t3.small instances 和：

每小时获得 24 个 CPU 积分 2 个 vCPU 每个 vCPU 20% 的基准性能

我会为CPUUtilization 设置这个缩放触发器：

统计：平均 单位：百分比 周期：5分钟 突破持续时间：5 分钟 上限：15% 下限：5%

因此，上限阈值设置为刚好低于基线，以避免在基线以上停留太久（并用完 CPU 积分）时产生额外成本。

此外，当任何实例的CPUUtilization 长时间保持在 20% 以上时，我设置了 CloudWatch 警报。这至少会在自动缩放达到最大值时触发。允许的实例数。

这一切有意义吗？

【参考方案1】：

在使用 T1/2/3 可突增实例类型时，不建议使用 CPU 利用率作为 Auto Scaling 的指标。

原因是这些实例上的 CPU 可能受到人为限制，从而给人一种它们有多忙的错误印象。

如果您激活“无限制”选项，那么这没关系，因为实例可以根据需要无限制地突增。不要害怕额外费用，因为它只会在超过每月平均数时才会额外收费，而且您只需为在忙碌时实际“使用”的 CPU 付费。

或者，选择不同的（非突发）实例类型。

【讨论】：

t3 似乎是最合适的，但可能的人为限制是一个有趣的方面。您对改用延迟有什么想法？

您需要测量延迟以确定它是否是可靠因素。或者，生成反映应用程序正在做什么的自定义指标。这一切都取决于应用程序在忙碌时会做什么——可能是 RAM 变得紧张，或者磁盘访问，或者数据库，或者......其他的东西！

实际上，现在使用这个指标 2 天，它似乎工作正常。人为限制是理论限制还是实际限制？

@Manuel 希望能与您跟进此事，因为我现在面临类似的困境。您问题中的原始计划最终对您有用吗？如果不是，您认为哪种方式效果最好？

它工作了一段时间，放大阈值 >18%，缩小阈值 30个实例时，问题尤其突出。我认为这取决于您的用例，但一旦您扩大规模，这些小问题加起来就会因成本问题而不得不加以解决。