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

配置预配置并发

在 Lambda 中，并发是您的函数同时处理的正在进行的请求数。有两种类型的并发控件可用：

  • 预留并发 – 预留并发是您要分配给函数的最大并发实例数。当一个函数有预留并发时，任何其他函数都不可以使用该并发。为函数配置预留并发不收取任何费用。

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

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

配置预配置并发

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

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

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

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

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

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

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

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

    注意

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

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

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

  8. 选择 Save（保存）。

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

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

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

您可以为同一函数同时分配预留并发和预置并发。如果您这样做，则预置并发数量不能超过预留并发数量。

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

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

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

aws lambda put-provisioned-function-concurrency --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 函数指标。

对于预置并发，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 将哪种类型的初始化用于特定环境，请检查 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 定价。

有关使用预置并发优化函数的更多指南，请参阅 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 的目标跟踪扩展策略。