aws-lambda - 预置并发对 Lambda 函数的响应时间影响较小

Question

我们正在使用无服务器架构以及 AWS Lambda 和 API 网关。 lambda 的执行时间在几毫秒的范围内 . 以秒为单位收到客户端的最终响应 (即使考虑到冷启动场景，init 持续时间也被考虑在内，这远远超过 lambdas 的执行时间)。
在使用 API 网关日志进行调试时，存在以秒为单位的集成延迟，这使得端到端响应相当缓慢。为了删除初始化持续时间或冷启动，我在 CloudWatch 中添加了规则，用于定期调用 lambdas 以保持它们温暖。
init 持续时间被完全删除，这也有助于减少集成延迟。由于调用它们需要身份验证，因此无法安排 Lambda，为此我添加了 5 的预配置并发。
这个 Lambda 在日志中也有初始化持续时间。 Lambda 配置是摆脱冷启动的另一种选择，但这不会影响 Lambda 响应在 API 网关上可用的时间。
我已按照以下链接将预配置的并发分配给 Lambda:

Provisioned Concurrency: What it is and how to use it with the Serverless Framework

AWS News Blog – Provisioned Concurrency for Lambda Functions

我已向其添加配置的 Lambda 的 CloudWatch 日志: Duration: 1331.38 ms Billed Duration: 1332 ms Memory Size: 256 MB Max Memory Used: 130 MB Init Duration: 1174.18 ms我在 API Gateway 和 Lambda 日志中注意到的一件事是，对 lambda 的请求是从 API Gateway 发送的，地址为 2021-02-15T11:51:36.621+05:30但是，它是在 Lambda 收到的 2021-02-15T11:51:38.535+05:30 .在 Lambda 上获取请求有大约 2 秒的延迟。
AWS X 射线追踪

我已经为 API 网关和 Lambda 启用了 AWS X-Ray 日志记录，这就是我的跟踪记录。此请求总共耗时 595 毫秒，但 Postman 的响应在 1558 毫秒内收到。从何处添加大约 1 秒的延迟以接收来自 API 网关的响应？

Answer 1

我相信原因是 5 的预配置并发还不够，您仍然会遇到 Lambda 函数的冷启动。这意味着如果外部服务正在调用您的 API 端点(即 API 网关后面的 Lambda 函数)，则您的 Lambda 函数具有 5 个实例。如果我们假设您的 Lambda 函数每秒可以处理 2 个请求(每次调用 500 毫秒)，那么您的 Lambda 函数每秒大约可以处理 10 个请求。如果外部服务每秒发出 20 个请求，AWS Lambda 会尝试启动新实例，因为现有实例正忙于处理请求。这会导致外部服务由于您的函数冷启动而经历高响应时间。
另外，请考虑您的 Lambda 函数的实例不会“永远”存在，而是在某个时间点后被清除。 IE。如果您的流量模式遇到许多高峰，那么这可能意味着在一次高峰后，实例的存活时间大约为 15 分钟，然后 AWS Lambda 将它们关闭以仅保留 5 个已配置的实例，如果随后出现另一个高峰，您将看到和以前一样的问题。
请注意:这是对幕后发生的事情的非常简化的解释 - 更像是基于您的描述的一个很好的猜测。如果您提供一些示例数字(例如初始化持续时间、执行持续时间、响应时间)以及您在 Lambda 函数中所做的一些示例代码，这将有所帮助。另外:您使用的是哪个运行时？您的流量模式如何？
潜在的解决方案

减少 Lambda 函数的冷启动时间 -> 对于 API 网关后面的 Lambda 函数来说总是一个好主意

提供更多实例 -> 仅可能达到某个(软)限制