lambda 和 fargate 错误/超时

Question

我有一个我在 vms、fargate 和 lambda 上尝试过的 python api。

vms - 容量足够大时错误更少

fargate - 当容量足够大时，错误会减少第二次，但在自动缩放时，我会收到大约 500 个错误。看起来它的自动缩放速度不够快。

lambda - 不太一致。当有很多 api 调用时，错误更少。但从冷启动开始，它可能会定期失败。我不预先提供。当我这样做时，我得到的错误也更少。

我在下面的帖子中看到，lambda 的冷启动不到 1 秒？似乎更多了。需要注意的是，每个 lambda 函数都会检查现有的“env”文件。如果它不存在，它将从 s3 下载。然而，只有在点击 api 时才会这样做。 lambda 函数正在侦听和响应。当您点击 api 时，lambda 函数将响应并连接，下载 .env 文件，并进一步处理 api 调用。 fargate 也做同样的事情，但错误更少。有什么想法吗？

我可以预先提供，但有点贵。那时，我可能会回到带有自动缩放组的虚拟机，但它不是云原生的。 vm 提供了迄今为止最快的响应，但更难管理。

Can AWS Lambda coldout cause API Gateway timeout(30s)?

我在 lambda 和 fargate 前面使用 ALB。虚拟机只是使用循环 dns。

问题：

1. 我是否在使用 Fargate 或 lambda 时做错了什么？他们可以使用 apis 还是我应该回到 vms？

2. 当 lambda 从冷启动启动时，是什么或谁维护 api 连接？我可以让它重试或保持连接更长时间吗？

谢谢！

Answer 1

我是否在使用 Fargate 或 lambda 时做错了什么？他们可以使用 apis 还是我应该回到 vms？

让我印象深刻的一件事是从 s3 下载 env。将环境数据保存在 SSM 参数存储中不是更容易、更快捷吗？或者，将它们作为环境变量传递给 lambda 函数本身。

当 lambda 从冷启动启动时，是什么或谁维护 api 连接？我可以让它重试或保持连接更长时间吗？

API 网关。可悲的是，您不能延长 30 秒的时间限制。它的硬限制。

我在 lambda 和 Fargate 前面使用 ALB。

在我看来你有API gateway->ALB->Lambda function。为什么你需要 ALB 呢？通常不需要。

我可以预先提供，但有点贵。

遗憾的是，这是减少冷启动的唯一方法。