Amazon Web Services上极短的流量峰值的正确Cloudwatch/Autoscale设置是什么？

Question

我有一个运行亚马逊弹性豆茎的网站,具有以下流量模式:

• 通常约50个并发用户.
• 当发布到Facebook页面时,约2000个并发用户持续1/2分钟.

亚马逊网络服务声称能够快速扩展到这样的挑战,但云观察的"大于x超过1分钟"的设置对于这种流量模式来说似乎不够快？

通常在几秒钟内,所有ec2实例都会崩溃,导致所有cloudwatch指标崩溃,整个网站停机4/6分钟.到目前为止,我还没有找到适合这种情况的配置.

这是一个小型事件的图表,也杀死了网站:

Answer 1

AWS的建议如下：

我们一直致力于使我们的系统更具响应性，但根据您的用例需要自动配置虚拟服务器并具有几秒钟的响应时间是一项挑战。也许有一种解决方法可以在请求开始增加时响应更快或者更具弹性。

您是否观察过，如果在稳定状态下使用更大的实例类型或更多的实例，站点的性能是否会更好？这可能是一种能够应对入站请求快速增长的方法。尽管我认识到这可能不是最具成本效益的，但您可能会发现这是一个快速解决方案。

另一种方法可能是调整警报以使用能够更快反映（或预测）您的需求增长的阈值或指标。例如，如果您将警报设置为在超过 75 或 100 个用户后添加实例，您可能会看到更好的性能。您可能已经在这样做了。除此之外，您的用例可能还有另一个预测需求增加的指标，例如，您的 Facebook 页面上的帖子可能会先于请求的显着增加几秒钟甚至一分钟。使用 CloudWatch 自定义指标来监控该值，然后为其设置自动缩放警报也可能是一种潜在的解决方案。

因此，我认为最好的答案是以较低的流量运行更多实例，并使用自定义指标来预测来自外部源的流量。例如，我将尝试监控 Facebook 和 Twitter 上包含该网站链接的帖子，并立即扩大规模。