設定函數的佈建並行 - AWS Lambda
設定佈建並行準確估算函數所需的佈建並行使用佈建並行時最佳化函數程式碼使用環境變數來檢視及控制佈建的並行行為透過佈建並行了解記錄和計費行為使用應用程式 Auto Scaling 自動化佈建的並行管理

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

設定函數的佈建並行

在 Lambda 中，並行是函數目前正在處理的傳輸中請求數目。有兩種類型的並行控制項可用：

  • 預留並行 – 它是分配給函數的並行執行個體數量上限。當某個函數具有預留並行時，其他函數都無法使用該並行。保留並發對於確保您最關鍵的函數始終具有足夠的並發性來處理傳入的請求非常有用。設定函數的預留並行不會產生額外費用。

  • 佈建並行 – 它是您分配給函數的預先初始化執行環境數目。這些執行環境已準備好立即回應傳入的函數請求。佈建的並行對於減少功能的冷啟動延遲非常有用。設定已佈建的並行會產生額外費用給您的. AWS 帳戶

本主題詳細說明如何管理及設定佈建並行。如需這兩種並行控制項的概念性概觀，請參閱預留並行與佈建並行。如需有關設定預留並行的詳細資訊，請參閱為函數配置保留並發。

注意

連結至 Amazon MQ 事件來源映射的 Lambda 函數具有預設並行上限。若使用 Apache Active MQ，並行執行個體數量上限為 5 個。若使用 ARabbit MQ，並行執行個體數量上限為 1 個。為函數設定保留或佈建並行不會改變這些上限。若要在使用 Amazon MQ 時要求增加預設的並行上限，請聯絡 AWS Support。

設定佈建並行

您可以使用 Lambda 主控台或 Lambda 為函數設定佈建的並行設定。API

若要為函數配置佈建並行 (主控台)

  1. 開啟 Lambda 主控台中的函數頁面。

  2. 選擇您要配置佈建並行的函數。

  3. 選擇 Configuration (組態)，然後選擇 Concurrency (並行)。

  4. 在 Provisioned concurrency configurations (佈建並行組態) 下方，選擇 Add configuration (新增組態)。

  5. 選擇限定詞類型，以及別名或版本。

    注意

    您無法將佈建並行與任何函數的 $ LATEST 版本搭配使用。

    如果您的函數有事件來源，請確定事件來源指向正確的函數別名或版本。否則，您的函數將不會使用佈建並行環境。

  6. 在佈建並行下輸入一個數字。Lambda 會提供每月預估費用。

  7. 選擇 Save (儲存)。

您最多可以在帳戶中設定的數量為未預留帳戶並行數量減去 100 的值。剩餘的 100 個並行單位會用於未使用預留並行的函數。例如，如果帳戶的並行限制為 1,000，而且您尚未將任何預留或佈建並行指派給任何其他函數，則單一函數最多可以設定 900 個佈建並行單位。

如果您嘗試配置過多的佈建並行，就會發生錯誤。

為函數設定佈建並行會影響其他函數可用的並行集區。例如，如果您為 function-a 設定 100 個佈建並行單位，則帳戶中的其他函數必須共用剩餘的 900 個並行單位。即使 function-a 沒有使用所有 100 個單位也是如此。

您可以為同一函數同時配置預留並行和佈建並行。在這種情況下，佈建並行不能超過預留並行。

此限制也適用於不同函數版本。您可以指派給特定函數版本的佈建並行上限等於函數的預留並行減去其他函數版本上的佈建並行。

若要設定與 Lambda 的佈建並行API，請使用下列API作業。

例如，若要使用 AWS 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

在前面的範例中，開發人員在 if 陳述式中初始化 CLIENT_A，而不是在主要處理常式之外進行初始化。如此一來，Lambda 只會在滿足 some_condition 的情況下執行此程式碼。如果您在主要處理常式之外初始化 CLIENT_A，Lambda 會在每次冷啟動時執行該程式碼。這可能會增加整體延遲。

使用環境變數來檢視及控制佈建的並行行為

您的函數可能會耗盡本身的所有佈建並行。Lambda 使用隨需執行個體來處理任何超出流量。為了判斷 Lambda 用於特定環境的初始化類型，請檢查 AWS_LAMBDA_INITIALIZATION_TYPE 環境變數的值。此變數有兩個可能的值：provisioned-concurrency 或 on-demand。AWS_LAMBDA_INITIALIZATION_TYPE 的值不可變，並且在整個環境的生命週期中保持不變。若要檢查函數程式碼中環境變數的值，請參閱擷取 Lambda 環境變數。

如果您使用的是. NET6 或. NET7 執行階段，您可以設定AWS_LAMBDA_DOTNET_PREJIT環境變數以改善函數的延遲時間，即使它們不使用佈建的並行。的. NET執行階段會針對程式碼第一次呼叫的每個程式庫採用延遲編譯和初始化。因此，Lambda 函數的第一次調用可能需要比後續調用更長的時間。若要減輕此問題，您可以針對 AWS_LAMBDA_DOTNET_PREJIT 選擇以下三個值之一：

  • ProvisionedConcurrency：Lambda 使用佈建的並行功能，針對所有環境執行 ahead-of-time JIT編譯。這是預設值。

  • Always：即使函數不使用佈建的並行，Lambda 也會針對每個環境執行 ahead-of-time JIT編譯。

  • Never: Lambda 停用所有環境的 ahead-of-time JIT編譯功能。

透過佈建並行了解記錄和計費行為

針對佈建並行環境，函數的初始化程式碼會在配置期間執行，且定期執行一次，因為 Lambda 會回收環境的執行個體。在環境執行個體處理請求之後，您可以在記錄和追蹤中查看初始化時間。請特別注意，即使環境執行個體從未處理請求，Lambda 也會針對初始化計費。佈建並行會持續執行，並與初始化和調用成本分開計費。如需詳細資訊，請參閱 AWS Lambda 定價。

此外，當您使用佈建並行設定 Lambda 函數時，Lambda 會預先初始化該執行環境，以便在函數叫用請求之前提供該函數。但是，您的函數僅在實際調用函數時 CloudWatch 才發布調用日誌。因此，即使初始化事先發生，初始化持續時間欄位仍會出現在第一個函式叫用的REPORT記錄行中。這並不意味著該功能經歷了冷啟動。

使用應用程式 Auto Scaling 自動化佈建的並行管理

Application Auto Scaling 可讓您依據排程或根據使用率來管理佈建並行。如果您的函數接收到可預測的流量模式，請使用排程擴展。如果您想要讓函數維持特定的使用率百分比，請使用目標追蹤擴展政策。

排程擴展

Application Auto Scaling 可讓您根據可預測的負載變化來設定自己的擴展排程。如需詳細資訊和範例，請參閱應用程式 Auto Scaling 使用指南中的應用程式自動調整排程調整，以及在 AWS Compute Blog 上針對週期尖峰使用量排定 AWS Lambda佈建的並行。

目標追蹤

透過目標追蹤，Application Auto Scaling 會根據您定義擴展政策的方式，建立和管理一組 CloudWatch 警示。這些警示啟動時，Application Auto Scaling 會自動調整使用佈建並行配置的環境數量。對沒有可預測流量模式的應用程式使用目標追蹤。

若要使用目標追蹤調整佈建的並行，請使用RegisterScalableTarget和PutScalingPolicy應用程式自動調整規模API作業。例如，如果您使用的是 AWS Command Line Interface (CLI)，請依照下列步驟執行：

  1. 請將函數的別名註冊為擴展目標。下列範例會註冊BLUE名為的函數別名my-function：

    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%，但您可以套用 10% 到 90% 之間的任何值。

    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 目標追蹤，自動擴展佈建的並行。
圖例

  • Orange line = function instances 函數執行個體

  • Gray line = function instances 開啟請求

  • Diagonal orange stripes = provisioned concurrency. 佈建並行

  • Vertical orange stripes = standard concurrency. 標準並行

當開啟的請求數量增加時，Application Auto Scaling 會大幅增加佈建並行，直到達到設定的最大值為止。在此之後，如果您尚未達到帳戶並行限制，則函數可以繼續按標準、未預留並行的方式擴展。當利用率下降且保持偏低時，Application Auto Scaling 會定期小幅減少佈建並行。

依預設，兩個 Application Auto Scaling 警示都會使用平均統計資料。經歷快速暴增流量的函數可能不會觸發這些警示。例如，假設您的 Lambda 函數執行速度很快 (即 20-100 毫秒)，而您的流量會快速暴增。在此情況下，請求數量將在暴增期間超過配置的佈建並行。不過，Application Auto Scaling 需要暴增負載維持至少 3 分鐘，才能佈建其他環境。此外，這兩個 CloudWatch 警報都需要 3 個達到目標平均值的資料點，才能啟動 auto 擴展政策。如果您的函數經歷快速爆發的流量，則使用最大統計資料而非平均統計資料可以更有效地擴展佈建並行，以將冷啟動降至最低。

如需目標追蹤擴展政策的詳細資訊，請參閱 Application Auto Scaling 的目標追蹤擴展政策。