【问题标题】:Autoscale AWS Lambda concurrency based off throttling errors根据限制错误自动缩放 AWS Lambda 并发
【发布时间】:2020-10-29 02:38:09
【问题描述】:

我有一个 AWS Lambda 函数,它使用 AWS SQS 触发器来提取消息,使用 AWS Comprehend 端点处理它们,并将输出放入 AWS S3。 AWS Comprehend 端点有一个速率限制,根据我可以控制的东西全天上下波动。处理我的数据的最快方法,也优化了我为 AWS Comprehend 端点启动所支付的成本,是将并发设置设置得足够高,以便我从 api 返回限制错误。然而,这有一个警告,我正在为更多的 AWS Lambda 调用付费,另一方面,为了优化我为 AWS Lambda 支付的成本,我想要 0 个限制错误。

是否可以为 lambda 的并发限制设置自动缩放,使其在没有出现任何限制错误时会增加,但如果出现太多错误则减少?

【问题讨论】:

  • 可能是因为我不了解 AWS Comprehend,所以我不理解这个问题。为什么限制错误会为您提供处理数据的最快方法?是不是意味着通过 lambda 的一些数据被延迟了?

标签: amazon-web-services aws-lambda autoscaling


【解决方案1】:

非常有趣的用例。

让我首先指出一些我在与 AWS 技术支持长达近 4 小时的通话中困惑了几天后发现的一些困难。

使用 SQS 作为 AWS Lambda 的触发器,并发不能超过 1K。即使 Lambda 的并发设置了更高的限制。

现在在知识中心有一个详细的post

除此之外,假设您在任何给定时间点都低于 1K 限制,因此只需要使用一个 SQS 队列,我觉得可以探索以下内容:

要么使用现有的 cloudwatch 指标(通过 Comprehend),要么发布一个新指标,以指示您在任何给定时间点可以处理的负载。然后,您可以使用它为 lambda 函数设置适当的并发限制。这将确保即使您的 SQS 队列中充斥着要处理的消息,lambda 也会以实际可以处理的速度拾取它们。

请注意:这源于我自己的主动与被动哲学。我不会等待某些事情无法触发其他进程,例如在这种情况下调用错误来调整并发性。系统故障应该很少见,实际上会引起警报(如果不是恐慌!),而不是每天发生几次的正常情况!

在此基础上,如果可能的话,我建议您以另一种方式处理此问题,即根据 SQS 队列(积压)中的消息或此积压和一天中的时间等。这样,如果您的管道的每个部分都是队列中积压数量的函数,那么您可以放心,您在任何给定时间点的支出都不会超过您的支出。

更重要的是,如果出现需求或发生异常情况,您总是有足够的能力。

【讨论】:

    猜你喜欢
    • 2021-05-30
    • 2018-01-12
    • 1970-01-01
    • 2016-05-14
    • 2020-11-15
    • 2018-12-13
    • 1970-01-01
    • 2018-11-28
    • 1970-01-01
    相关资源
    最近更新 更多