Lambda 函数的新的预置并发

时间确实过得真快，尤其是当您不必考虑服务器时：AWS Lambda 推出刚刚 5 年，团队一直在寻找新的方法来帮助客户以更轻松的方式构建和运行应用程序。

随着越来越多的关键任务应用程序转向无服务器，客户需要更多地控制其应用程序性能。 今天，我们将推出预置并发功能，该功能可以使函数保持初始化状态，在两位数毫秒的超短时间内做出响应。 这是实现交互式服务（例如 Web 和移动后端、对延迟敏感的微服务或同步 API）的理想选择。

调用 Lambda 函数时，该调用将路由到执行环境以处理请求。如果某个函数一段时间未使用、需要处理更多并发调用或更新函数，则会创建新的执行环境。执行环境的创建后，可安装功能代码并启动运行时。根据部署包的大小以及运行时和代码的初始化时间，这可能导致路由到新执行环境的调用延迟。此类延迟通常称为“冷启动”。 对于大多数应用程序，此额外延迟不是问题。但是，对于某些应用程序，此延迟可能不可接受。

针对某项功能启用预置并发时，Lambda 服务将初始化请求数量的执行环境，以便它们可以随时响应调用。

**配置预置并发

**我创建了两个使用相同 Java 代码的 Lambda 函数，这两个函数可以由 Amazon API Gateway 触发。为了模拟生产工作负载，这些函数在初始化阶段重复进行了 1000 万次数学运算，每次调用重复 200000 次。计算使用 java.Math.Random 和条件（如果...）来避免编译器优化（例如“取消循环”迭代）。每个函数都有 1GB 的内存，代码大小为 1.7 MB。

我只想为这两个函数之一启用预置并发，以便可以比较它们对类似工作负载的反应。在 Lambda 控制台中，选择一个函数。在配置选项卡中，我看到了新的预置并发设置。

我选择添加配置。可以为特定的 Lambda 函数版本或别名（您不能使用 $LATEST）启用预置并发。您可以为函数的每个版本使用不同的设置。使用别名，可以更容易地将这些设置启用为函数的正确版本。在本例中，我使用 [](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/automating-updates-to-serverless-apps.html) 函数首选项，选择根据最新版本实时更新的别名。对于预置并发，我输入 500 并保存。

现在，预置并发配置正在进行中。正在根据我的输入准备执行环境，以服务于并发的传入请求。 在此期间，该函数将保持可用状态并继续服务流量。

几分钟后，并发就绪。使用这些设置，最多 500 个并发请求将找到一个处理就绪的执行环境。如果超出此数量，Lambda 函数的通常扩张功能仍然适用。

为了生成一些负载，我在同一区域中使用了 Amazon Elastic Compute Cloud (EC2) 实例。为了简单起见，我使用与 Apache HTTP 服务器捆绑在一起的 [](https://httpd.apache.org/docs/2.4/programs/ab.html) 工具，以 500 并发数调用两个 API 终端节点 10000 次。由于这些是新函数，因此我希望：

• 对于已启用预置并发并设置为 500 的函数，我的请求由预初始化执行环境管理。

• 对于已禁用预置并发的其他功能，需要预置约 500 个执行环境，在相同数量的调用上增加一些延迟，约占总数的 5％。

ab 工具的一项强大功能是报告一定时间内服务的请求的百分比。这是查看 API 延迟的一种非常好的方法，如 Tim Bray 有关无服务器延迟的本博文中所述。

以下是禁用了预置并发的函数的结果：

一定时间内服务的请求百分比 (ms)

50% 351

66% 359

75% 383

80% 396

90% 435

95% 1357

98% 1619

99% 1657

100% 1923（最长请求）

查看这些数字后，我发现在 351 ms 内服务了 50％ 的请求，在 359 ms 内服务了 66％ 的请求，依此类推。很明显，当我查看 95％ 或以上的请求时，就会发生以下事情：时间突然增加大约一秒钟。

这是启用了预置并发的函数造成的：

一定时间内服务的请求百分比 (ms)

50% 352

66% 368

75% 382

80% 387

90% 400

95% 415

98% 447

99% 513

100% 593（最长请求）

让我们在图表中比较这些数字。

正如我的测试工作负载所预期的，我发现最慢的 5％ 请求（在 95％ 和 100％ 之间）的响应时间存在巨大差异，禁用预置并发的函数在创建新执行环境和（缓慢）初始化函数代码时，延迟增加。

通常，添加的延迟量取决于使用的运行时、代码的大小以及代码首次调用所需的初始化。因此，延迟增加量可能多于或少于我在这里遇到的。

受此额外延迟影响的调用数量取决于 Lambda 服务需要创建新执行环境的频率。通常，当并发调用的数量超出已提供的数量，或者部署函数的新版本时，会发生这种情况。

一小部分缓慢的响应时间（通常称为尾部等待时间）确实会改变最终用户的体验。在较长的一段时间内，大多数用户在某些交互过程中会受到影响。启用预配置并发后，用户体验将更加稳定。

预配置并发是 Lambda 功能，可与任何触发器配合使用。例如，您可以将其与 WebSockets API、GraphQL 解析器或IoT 规则配合使用。在构建需要低延迟的无服务器应用程序（例如 Web 和移动应用程序、游戏或作为复杂事务一部分的任何服务）时，此功能可为您提供更多控制。

**现已推出

**可以使用控制台、AWS 命令行界面 (CLI)或适用于新的或现有 Lambda 函数的 AWS 开发工具包配置预置并发，该服务已在以下 AWS区域推出：美国东部（俄亥俄）、美国东部（弗吉尼亚北部）、美国西部（加利福尼亚北部）、美国西部（俄勒冈）、亚太地区（香港）、亚太地区（孟买）、亚太地区（首尔）、亚太地区（新加坡）、亚太地区（悉尼）、亚太地区（东京）、加拿大（中部）、欧洲（法兰克福）、欧洲（爱尔兰）、欧洲（伦敦）、欧洲（巴黎）、欧洲（斯德哥尔摩）、中东（巴林）以及南美（圣保罗）。

您还可以使用 AWS 无服务器应用程序模型 (SAM) 和 SAM CLI 来测试、部署和管理使用预置并发的无服务器应用程序。

借助 Application Auto Scaling，您可以自动配置函数所需的并发数。作为策略，支持目标跟踪和计划的扩展。 使用这些策略，您可以在高需求时自动增加并发数，并在需求减少时减少并发数。

您现在还可以将预置并发与 AWS 合作伙伴工具配合使用，包括使用 Serverless Framework 和 Terraform 配置预置并发设置，或者使用 Datadog、Epsagon、Lumigo、New Relic、SignalFx、 SumoLogic 和 Thundra 查看指标。

您只需支付配置的并发数和配置的时间段的费用。在美国东部（弗吉尼亚北部），预置并发的定价为每 GB 每小时 0.015 USD，而持续时间的定价为每 GB 每小时 0.035 USD。请求数量的收费与正常函数相同。 您可以在 Lambda 定价页面中找到更多信息。

这项新功能使开发人员可以将 Lambda 用于需要高度一致延迟的各种工作负载。快来告诉我您打算怎么使用它吧！

本文转载自 AWS 技术博客。

原文链接：https://amazonaws-china.com/cn/blogs/china/new-provisioned-concurrency-for-lambda-functions/