如何以具有成本效益的方式自动扩展 AWS 和 GCP 中的突然请求峰值？

Posted 2023-02-19

【中文标题】如何以具有成本效益的方式自动扩展 AWS 和 GCP 中的突然请求峰值？

【英文标题】：How to auto scale sudden request spike in AWS and GCP in cost effective way?

【发布时间】：2022-01-15 15:36:59

【问题描述】：

我们有 SaaS 应用程序，我们有成千上万的客户。当我们的客户网站获得流量时，我们也会获得与跟踪客户网站访问者活动相同的流量。

由于客户网站的流量导致我们的请求突然激增，我们无法得知我们在什么时候突然出现峰值，并且我们所有的服务器都停机了。为了解决这个问题，我们配置为在 CPU 或内存使用率超过 60% 时进行扩展。这意味着我们要为未使用的资源支付 40% 的额外费用。如果我们将其设置为 90%，那么我们的所有服务器都会由于突然的负载和资源使用而变得无响应。

我们希望利用我们支付的至少 90% 的资源，而不是 60% 的规模。有没有更好的方法以经济高效的方式进行扩展？

注意：我们正在使用 AWS ElasticBeanstalk 以及 GoogleCloud 的 Kubernetes Engine 服务。

【参考方案1】：

我们希望利用我们支付的至少 90% 的资源，而不是 60% 的规模

90% 是一个相当高的要求。然后您需要将缩放阈值设置为 90% 级别。显然，如果您无法足够快地扩展或无法估计预期负载，您就会发现问题。 60% 听起来安全的方法（而且更昂贵）。仍然 - 玩阈值有什么问题？

为了完全与负载保持一致，您可以使用无服务器（AWS 和 GCP 都提供某种无服务器功能）。在高永久负载下，它们可能更昂贵，但如果您的问题是不断变化的负载和过度配置，那么这些功能是巧妙的答案。

另一种方法是使用异步处理，例如队列或流，并使用您拥有的资源按照自己的节奏处理数据。您可能会在接收数据和生成结果之间引入一些延迟，但在大多数情况下这可能是可以接受的。

【讨论】：

OP，仅供参考，在 Lambda 上进行缩放确实有限制 - docs.aws.amazon.com/lambda/latest/dg/invocation-scaling.html

@ErmiyaEskandary 当然。问题提到了跟踪网站访问者，所以我期望/假设执行时间很短，如果 1000 次并发执行还不够（可以要求增加限制），那么事情就大错特错了。到目前为止，我发现使用 lambdas 的最大限制是使用现有的产品/框架，缺乏技能和开发人员的心态。流/队列是网站分析的常见用例，因此这可能是比将所有内容重写为无服务器更好的方法