API Gateway + Lambda 响应时间极慢

Question

我正在使用 API 网关和 Lambda 函数创建应用程序的后端，但我遇到了请求响应时间的问题。

众所周知，Lambda 函数具有臭名昭著的“冷启动”，好吧，我们已经接受了这一点。但我遇到的问题似乎是新的冷启动，这次是由 API 网关启动。而且待机时间也不是几个ms，就是seconds（12-15秒左右）。天啊，这真是个大问题啊……

在第一次请求时以及一段时间不活动后（大约 1 小时），此响应延迟会发生 12-15 秒。

我的问题是：什么可能导致这种延迟以及如何解决它？

详细信息：
我的 lambda 函数配置为在 VPC 上运行。

来自 API Gateway 的 CloudWatch 日志：

(01) Extended Request Id: XXXXX=
(02) Verifying Usage Plan for request: XXXXX. API Key: API Stage: XXXXX
(03) API Key authorized because method 'GET /XXXXX' does not require API Key. Request will not contribute to throttle or quota limits
(04) Usage Plan check succeeded for API Key and API Stage XXXXX/v1
(05) Starting execution for request:
(06) HTTP Method: GET, Resource Path:
(07) Method request path:
(08) Method request query string:
(09) Method request headers:
(10) Method request body before transformations:
(11) Endpoint request URI:
(12) Endpoint request headers:
(13) Endpoint request body after transformations:
(14) Sending request to XXXXX
(15) Received response. Integration latency: 14497 ms
(16) Endpoint response body before transformations:
(17) Endpoint response headers:
(18) Method response body after transformations:
(19) Method response headers:
(20) Successfully completed execution
(21) Method completed with status: 200
(22) AWS Integration Endpoint RequestId :
(23) X-ray Tracing ID : 

Answer 1

2019 年 12 月 14 日更新：

AWS引入了预配置的Lambda：https://aws.amazon.com/blogs/aws/new-provisioned-concurrency-for-lambda-functions/

这里需要记住的事情很少，当 Lambda 运行的容器实际上“退役”时，就会发生冷启动 - 这意味着 AWS 基础设施已将其从“准备就绪”状态变为“没有人真正使用它，让我们搁置它” 。

VPC 外部的 Lambda 冷启动时间可能长达 6 秒，在 VPC 内部，您可以查看每个容器的任何位置长达 12 秒，因此，仅仅因为您有一个 Lambda 实例处于热状态，如果两个人同时访问该端点那么第二个人就会冷启动。

因此，正如 Dashmug 先生所说，有一个预定函数来预热 lambda 是一种简单的方法，现在要记住的一件事是，您的函数可能会预热 1 个容器，如果您预计每秒有数百个请求，则需要保留 X容器数量温暖。

有关如何简化此操作的示例，您可以查看此- 它是无服务器框架的插件，可以完全满足您的需求。

本质上，您需要一个能够为每个端点发出 X 个并发请求的函数 - 请注意，这是有成本的，尽管您可以每月花费不到 30 美元来保持相当不错的微服务的预热。

就我个人而言，我认为冷启动有点过分了——某些客户偶尔会遇到响应缓慢的情况，但如果您的 API 具有相对稳定的流量，那么我真的不会担心您的客户会保持正确数量的 Lambda 温暖，如果它很容易出现峰值的话值得让他们热身。

想想看，我所处理的 API 的平均请求时间是 < 400 毫秒 - 所以我需要每秒 2 个请求，每分钟 120 个，每小时 7200 个，甚至开始一直需要两个容器 - 如果你有像 app 这样的东西人们登录，然后调用主屏幕的 api 端点，您可以执行一些简单的操作，例如登录->SNS 向下一个端点触发预热事件。

基本上，如果您知道消费者将调用 api 的流程，您可以根据前一个调用的端点主动预热端点。