Lambda冷启动可能的解决方案？

Posted 2023-03-04

【中文标题】Lambda冷启动可能的解决方案？

【英文标题】：Lambda cold start possible solution?

【发布时间】：2016-10-22 05:02:39

【问题描述】：

使用 CloudWatch 安排 lambda 函数每 20 分钟调用一次是摆脱 lambda 冷启动时间的最佳方法吗？ （没有完全摆脱）...

这是否会变得昂贵，或者我是否缺少某些东西，因为我现在已经设置了它并且我认为它正在工作。

在我的冷启动时间大约为 10 秒之前，每个后续调用将在大约 80 毫秒内完成。现在，无论多么频繁，每次通话都在 80 毫秒左右。这是一个好方法，直到说您的用户群增长，然后您可以将其关闭？

我的第二个选择是只使用 beanstalk 并让服务器 24/7 运行，但这听起来很昂贵，所以我不喜欢它。

【问题讨论】：

如果我们关注最新趋势，aws.amazon.com/blogs/aws/… 就是您正在寻找的解决方案。自 12.2019 + 以来，AWS 基础设施有了额外的改进。

【参考方案1】：

Lambda 的冷启动取决于多种因素，例如您的实施、您使用的语言运行时以及代码大小等。如果您为 Lambda 函数提供更多内存，也可以减少冷启动。你可以阅读最佳实践https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html

无服务器社区也有性能建议https://atlas.serverless.tech-field-community.aws.a2z.com/Performance/index.html

Lambda 团队也推出了Provisioned Concurrency。您现在可以请求将多个 Lambda 容器保持在“超级就绪”状态，准备好重新运行您的函数。这是降低冷启动可能性的新的最佳实践。 官方文档https://docs.aws.amazon.com/lambda/latest/dg/configuration-concurrency.html?icmpid=docs_lambda_console

【参考方案2】：

从 2019 年 12 月开始，AWS Lambda 支持预留并发（因此您可以设置准备就绪并等待新调用的 lambda 函数的数量）[1]

这样做的缺点是，您需要为保留的并发支付费用。如果您配置 1 的并发性，对于 128MB 的 lambda 在整个月 24 小时内处于活动状态，您将被收费：1 个实例 x 30 天 x 24 小时 x 60 分钟 x 60 秒 x (128/1024) = 324,000 GB-秒（AWS 为 lambda 免费套餐提供的几乎所有容量）[2]

从上面你会得到一个响应非常快的 lambda 实例……但是，后续的并发调用可能仍然会遭受“冷启动”。

此外，您可以配置应用程序自动缩放以动态管理您的 lambda 的预置并发。 [3]

参考：

https://aws.amazon.com/blogs/aws/new-provisioned-concurrency-for-lambda-functions/ https://aws.amazon.com/lambda/pricing/ https://docs.aws.amazon.com/lambda/latest/dg/configuration-concurrency.html

【参考方案3】：

点击服务器无法解决用户同时请求的情况，或者同一页面异步发送一些 api 请求的情况。

更好的解决方案是将“预热”转储到 docker 检查点。当预热很快但所有库的加载速度很慢时，它对于动态语言特别有用。

详情请阅读

https://criu.org/Docker

https://www.imperial.ac.uk/media/imperial-college/faculty-of-engineering/computing/public/1819-ug-projects/StenbomO-Refunction-Eliminating-Serverless-Cold-Starts-Through-Container-Reuse.pdf

其他提示：

使用更多内存 将 Python 或 javascript 与大多数基本库一起使用，尽量消除笨重的库 创建多个“微服务”以减少多个用户访问同一服务的机会

在https://www.jeremydaly.com/15-key-takeaways-from-the-serverless-talk-at-aws-startup-day/查看更多信息

【参考方案4】：

Azure 有无服务器实例的预热解决方案 (Link)。如果他们实现它，这将是 AWS lambda 中的一个很棒的功能。

用户无需在应用程序级别对实例进行加热，而是由平台中的云提供商处理。

【参考方案5】：

在为 lambda 添加更多内存的同时，还有一种减少冷启动的方法：使用 Graal 原生映像工具。 jar 被翻译成字节码。基本上，我们会做部分工作，这是在 aws 上完成的。当您构建代码时，在加载到 AWS 时 - 选择“自定义运行时”，而不是 java8。

有用的文章：https://engineering.opsgenie.com/run-native-java-using-graalvm-in-aws-lambda-with-golang-ba86e27930bf

小心：

但它也有其局限性；不支持动态类加载，反射支持也有限

【参考方案6】：

您可以通过为 Lambda 函数分配更多内存来缩短冷启动时间。使用默认的 512MB，我看到用 Java 编写的函数的冷启动时间为 8-10 秒。使用 1536MB 内存时，这会缩短到 2-3 秒。

Amazon says 说 CPU 分配才是真正重要的，但是没有办法直接改变它。 CPU 分配与内存成比例增加。

如果您希望冷启动时间接近于零，如 rsp 所建议的那样，保持函数温暖是可行的方法。

【讨论】：

将内存设置为 1536mb 对我有用。冷启动时间从 12 秒减少到 3 秒。

Big lambdas 启动速度更快，垃圾收集也更早。换句话说，它们的空闲超时时间更短。

【参考方案7】：

据我所知，这是目前保持该功能热门的唯一方法。只有当你拥有很多这些功能时，它才会变得昂贵。

考虑到您拥有多少个函数、每次运行它们需要多长时间以及需要多少内存，您必须自己计算要为保持函数的运行支付多少费用。

但是每 20 分钟一次相当于每月 2000 次，所以如果您使用例如128MB 并使它们在 100 毫秒内完成，那么您可以以 20 分钟的间隔保持相当多的此类功能处于活动状态，并且仍然处于免费套餐之下 - 每个功能每月需要 20 秒。在获得更大的负载后，您甚至不需要将其关闭，因为此时它将无关紧要。此外，您永远无法确保始终获得均匀的负载，因此即使在那时您也可能会保持心跳代码处于活动状态。

虽然我的猜测是，因为让函数保持活动状态非常便宜（特别是如果你有一个让它们立即返回的特殊参数）并且差异如此之大（10 秒与 80 毫秒）那么几乎每个人都会这样做——几乎没有理由不这样做。在这种情况下，我希望亚马逊要么与这种做法作斗争（通过使其变得更难或更昂贵——这不是明智之举），要么在未来不再需要它。如果热启动和冷启动之间的差异是 100 毫秒，那么没有人会打扰。如果它是 10 秒，那么每个人都需要解决它。

运行一秒钟前运行的代码和一个月前运行的代码之间总是存在差异的，因为将它们全部放在 RAM 中并准备好运行会浪费大量资源，但是我看不出有什么理由不能让这种差异变得不那么明显，甚至可以多做几个步骤，而不仅仅是热启动和冷启动。

【讨论】：

感谢您的提示。功能代码外部有什么特别的东西可以延迟启动吗？我有 2 个 nodejs lambda，尽管即使来自冷调用，一个 (158Kb) 开始低于 ~1 秒，而另一个在 VPC-Elasticache (54Kb) 下大约需要 10 秒。但也许这仅与它加载的 redis 库有关，这可能是 CPU 密集型的，而不是设置本身？