配置预配置并发 - Amazon Lambda
配置预配置并发准确估计所需预置并发使用预置并发优化延迟使用 Application Auto Scaling 管理预置并发
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

配置预配置并发

在 Lambda 中，并发指您的函数当前正在进行的请求数。有两种类型的并发控件可用：

  • 预留并发 – 指分配给函数的最大并发实例数。当一个函数有预留并发时，任何其他函数都不可以使用该并发。为函数配置预留并发不产生任何额外费用。

  • 预置并发 – 指分配给函数的预初始化执行环境的数量。这些执行环境已准备就绪，可以立即响应传入的函数请求。配置预置并发会让您的 Amazon Web Services 账户 产生额外费用。

本主题详细介绍了如何管理和配置预置并发。有关这两种并发控制的概念概述，请参阅预留并发和预置并发。有关配置预留并发的更多信息，请参阅配置预留并发。

注意

关联到 Amazon MQ 事件源映射的 Lambda 函数具有默认的最大并发数。对于 Apache Active MQ，最大并发实例数为 5。对于 Rabbit MQ，最大并发实例数为 1。为函数设置预留或预调配的并发不会更改这些限制。要在使用 Amazon MQ 时请求增加默认的最大并发数，请联系 Amazon Web Services Support。

配置预配置并发

您可以使用 Lambda 控制台或 Lambda API 为函数配置预置并发设置。

要为函数分配预置并发（控制台）

  1. 打开 Lamba 控制台的函数页面。

  2. 选择要为其分配预置并发的函数。

  3. 选择 Configuration（配置），然后选择 Concurrency（并发）。

  4. 在 Provisioned concurrency configurations（预配置并发配置）下，选择 Add configuration（添加配置）。

  5. 选择预留并发。输入要为该函数预留的并发数量。

  6. 选择限定符类型以及别名或版本。

    注意

    您不能将预置并发与任何函数的 $LATEST 版本一起使用。

    如果函数具有事件源，请确保该事件源指向正确的函数别名或版本。否则，您的函数将不会使用预置并发环境。

  7. 在预置并发下输入一个数字。Lambda 会提供每月成本的估算值。

  8. 选择保存。

您最多可以在账户中配置的单位数量为非预留账户并发减去 100。剩余 100 个单位的并发可用于不会使用预留并发的函数。例如，如果您的账户的并发限制为 1000，并且您没有为任何其他函数分配任何预留或预置并发，则可以为单个函数配置最多 900 个单位的预置并发。

如果您尝试分配过多预置并发，则会发生错误。

为函数配置预置并发会影响可用于其他函数的并发池。例如，如果您为 function-a 配置 100 个单位的预置并发，则您账户中的其他函数必须共享剩余的 900 个单位的并发。即使 function-a 不使用所有 100 个单位的预置并发也是如此。

可以为同一函数同时分配预留并发和预置并发。在这种情况下，预置并发数不能超过预留并发数。

此限制也适用于函数版本。您可以分配给特定函数版本的最大预置并发数等于该函数的预留并发减去其他函数版本上配置的预置并发。

要使用 Lambda API 配置预置并发，请使用以下 API 操作：

例如，要使用 Amazon Command Line Interface（CLI）配置预置并发，请使用 put-provisioned-concurrency-config 命令。以下命令将为名为 my-function 的 BLUE 别名分配 100 个单位的预置并发：

aws lambda put-provisioned-concurrency-config --function-name my-function \
  --qualifier BLUE \
  --provisioned-concurrent-executions 100

您应该会看到类似如下输出：

{
  "Requested ProvisionedConcurrentExecutions": 100,
  "Allocated ProvisionedConcurrentExecutions": 0,
  "Status": "IN_PROGRESS",
  "LastModified": "2023-01-21T11:30:00+0000"
}

准确估计所需预置并发

您可以使用 CloudWatch 指标查看任何活动函数的并发指标。具体而言，ConcurrentExecutions 指标显示了您账户中函数的并发调用数。

该图显示函数长期以来的并发。

前面的图表显示，在给定的任何时间，此函数平均处理 5 到 10 个并发请求，峰值为 20 个请求。假设您的账户中还有许多其他函数。如果此函数对您的应用程序至关重要，并且您的每次调用都需要低延迟响应，请配置至少 20 个单位的预置并发。

请注意，您也可以使用以下公式计算并发数：

Concurrency = (average requests per second) * (average request duration in seconds)

要估计您需要的并发数，请将每秒的平均请求数与平均请求持续时间（以秒为单位）相乘。您可以使用 Invocation 指标估算每秒的平均请求数，并使用 Duration 指标估计平均请求持续时间（以秒为单位）。

对于配置预置并发，Lambda 建议在函数通常需要的并发的基础上添加 10% 的浮动。例如，如果函数通常在出现 200 个并发请求时达到峰值，请将预置并发设置为 220（200 个并发请求 + 10% = 220 个预置并发）。

使用预置并发优化延迟

要优化延迟，函数代码结构可以根据您使用的是预置并发环境还是按需环境而有所不同。对于在预置并发上运行的函数，Lambda 会在分配期间运行任何初始化代码（例如加载库和实例化客户端）。因此，建议将尽可能多的初始化放在主函数处理程序之外，以避免影响实际函数调用期间的延迟。相比之下，如果您在主处理程序代码中初始化库或实例化客户端，则无论您是否使用预置并发，函数都必须在每次调用时运行相应代码。

对于按需调用，每次函数出现冷启动时，Lambda 可能需要重新运行您的初始化代码。对于此类函数，您可以选择将特定功能的初始化推迟到函数需要该功能的时候。例如，请为 Lambda 处理程序考虑以下控制流：

def handler(event, context):
    ...
    if ( some_condition ):
        // Initialize CLIENT_A to perform a task
    else:
        // Do nothing

在前面的示例中，开发人员没有在主处理程序之外初始化 CLIENT_A，而是在 if 语句中对其进行初始化。这样一来，Lambda 只有在 some_condition 得到满足时才会运行此代码。如果您在主处理程序之外初始化 CLIENT_A，Lambda 会在每次冷启动时运行该代码。这可能会增加总体延迟。

函数可能会用尽其所有预置并发。Lambda 使用按需实例来处理任何过多流量。为了确定 Lambda 将哪种类型的初始化用于特定环境，请检查 AWS_LAMBDA_INITIALIZATION_TYPE 环境变量的值。此变量可能有两个值：provisioned-concurrency 和 on-demand。AWS_LAMBDA_INITIALIZATION_TYPE 的值是不可变的，并且在环境的整个生命周期中保持不变。

如果使用的是 .NET 6 或 .NET 7 运行时系统，则可以配置 AWS_LAMBDA_DOTNET_PREJIT 环境变量以改善函数的延迟，即使函数不使用预置并发。.NET 运行时系统会延时编译和初始化代码首次调用的每个库。因此，首次调用 Lambda 函数的时间可能比后续调用的时间更长。要缓解此问题，可以为 AWS_LAMBDA_DOTNET_PREJIT 从以下三个值中任选一个：

  • ProvisionedConcurrency：Lambda 会使用预置并发为所有环境执行提前 JIT 编译。这是默认值。

  • Always：Lambda 会为每个环境执行提前 JIT 编译，即使函数不使用预置并发也是如此。

  • Never：Lambda 会为所有环境禁用提前 JIT 编译。

对于预置并发环境，函数的初始化代码在分配期间定期运行一次，因为 Lambda 会回收环境实例。在环境实例处理请求后，您可以在日志和跟踪中查看初始化时间。需要注意的是，即使环境实例从不处理请求，Lambda 也会对初始化进行计费。预配置并发连续运行，并且与初始化和调用成本分开计费。有关更多详细信息，请参阅 Amazon Lambda 定价。

此外，当您配置具有预调配并发的 Lambda 函数时，Lambda 会预先初始化该执行环境，使其在函数调用请求之前可用。但是，只有在实际调用函数时，您的函数才会将调用日志发布到 CloudWatch。因此，初始化持续时间字段会出现在第一次函数调用的 REPORT 日志行中，即使初始化是提前进行的。这并不意味着该函数经历了冷启动。

有关使用预置并发优化函数的更多指南，请参阅 Serverless Land 上的 Lambda execution environments。

使用 Application Auto Scaling 管理预置并发

您可以使用 Application Auto Scaling 根据计划或基于利用率管理预置并发。如果函数的流量模式是可预测的，请使用计划扩展。如果您希望函数保持特定利用率，请使用目标跟踪扩展策略。

计划扩展

借助 Application Auto Scaling，您可以按照可预测的负载变化来设置自己的扩展计划。有关更多信息和示例，请参阅《Application Auto Scaling 用户指南》中的 Application Auto Scaling 的计划扩展，以及在 Amazon 计算博客上的为经常出现的峰值使用情况计划 Amazon Lambda 预置并发。

目标跟踪

借助目标跟踪，Application Auto Scaling 可根据您定义扩展策略的方式创建和管理一组 CloudWatch 警报。当这些警报激活时，Application Auto Scaling 会使用预置并发自动调整分配的环境数量。针对流量模式不可预测的应用程序，使用目标跟踪。

要使用目标跟踪扩展预置并发，请使用 RegisterScalableTarget 和 PutScalingPolicy Application Auto Scaling API 操作。例如，如果您使用的是 Amazon Command Line Interface（CLI），请按照以下步骤操作：

  1. 将函数的别名注册为扩展目标。以下示例注册名为 my-function 的函数的 BLUE 别名：

    aws application-autoscaling register-scalable-target --service-namespace lambda \
    --resource-id function:my-function:BLUE --min-capacity 1 --max-capacity 100 \
    --scalable-dimension lambda:function:ProvisionedConcurrency

  2. 将扩展策略应用于目标。以下示例配置 Application Auto Scaling，调节别名的预置并发配置，以使利用率保持接近 70%。

    aws application-autoscaling put-scaling-policy \
    --service-namespace lambda \
    --scalable-dimension lambda:function:ProvisionedConcurrency \
    --resource-id function:my-function:BLUE \
    --policy-name my-policy \
    --policy-type TargetTrackingScaling \
    --target-tracking-scaling-policy-configuration '{ "TargetValue": 0.7, "PredefinedMetricSpecification": { "PredefinedMetricType": "LambdaProvisionedConcurrencyUtilization" }}'

应看到类似如下内容的输出：

{
    "PolicyARN": "arn:aws:autoscaling:us-east-2:123456789012:scalingPolicy:12266dbb-1524-xmpl-a64e-9a0a34b996fa:resource/lambda/function:my-function:BLUE:policyName/my-policy",
    "Alarms": [
        {
            "AlarmName": "TargetTracking-function:my-function:BLUE-AlarmHigh-aed0e274-xmpl-40fe-8cba-2e78f000c0a7",
            "AlarmARN": "arn:aws:cloudwatch:us-east-2:123456789012:alarm:TargetTracking-function:my-function:BLUE-AlarmHigh-aed0e274-xmpl-40fe-8cba-2e78f000c0a7"
        },
        {
            "AlarmName": "TargetTracking-function:my-function:BLUE-AlarmLow-7e1a928e-xmpl-4d2b-8c01-782321bc6f66",
            "AlarmARN": "arn:aws:cloudwatch:us-east-2:123456789012:alarm:TargetTracking-function:my-function:BLUE-AlarmLow-7e1a928e-xmpl-4d2b-8c01-782321bc6f66"
        }
    ]
}

Application Auto Scaling 会在 CloudWatch 中创建两个警报。当预置并发的利用率持续超过 70% 时，第一个警报会触发。发生这种情况时，Application Auto Scaling 会分配更多的预配置并发以降低利用率。当利用率持续低于 63%（70% 目标的 90%）时，第二个警报会触发。发生这种情况时，Application Auto Scaling 会减少别名的预配置并发。

在以下示例中，函数会根据利用率在最小和最大预置并发量之间进行扩缩。

使用 Application Auto Scaling 目标跟踪自动伸缩预置并发。
图例

  • 函数实例

  • 打开请求

  • 预配置并发

  • 标准并发

打开的请求数量增加时，Application Auto Scaling 会大幅度增加预置并发，直到达到配置的最大值。达到最大值后，如果账户尚未达到账户并发数限制，则函数可能会在标准的非预留并发上继续扩展。利用率下降并保持较低时，Application Auto Scaling 会以较短周期逐步减少预置并发。

默认情况下，Application Auto Scaling 的两个警报都使用平均统计数据。具有快速突发流量的函数可能不会触发这些警报。例如，假设 Lambda 函数执行速度很快（如 20-100 毫秒），并且您的流量出现快速突发。在这种情况下，请求数超过了在突发期间分配的预置并发数。但是，突发负载需要维持至少 3 分钟，Application Auto Scaling 才能预置更多环境。此外，两个 CloudWatch 警报都需要获得 3 个达到目标平均水平的数据点，然后才能激活自动扩缩策略。

有关目标跟踪扩展策略的更多信息，请参阅适用于 Application Auto Scaling 的目标跟踪扩展策略。