設定佈建並行 - AWS Lambda
SnapStart 和佈建並行設定佈建並行利用佈建並行最佳化延遲使用 Application Auto Scaling 管理佈建並行

設定佈建並行

在 Lambda 中，並行是函數可同時處理的請求數目。有兩種類型的並行控制可用：

  • 預留並行 - 預留並行可保證函數的並行執行個體的最大數量。當某個函數具有預留並行時，其他函數都無法使用該並行。設定函數的預留並行不收費。

  • 佈建並行 - 佈建並行會初始化請求的執行環境數目，以便立即回應函數的叫用。請注意，設定佈建並行會使您的 AWS 帳戶產生費用。

本主題詳細說明如何管理及設定佈建並行。如果您想要設定預留並行，請參閱管理 Lambda 預留並行。

當 Lambda 配置函數的執行個體時，執行時間會載入函數的程式碼，並執行您在處理常式外部定義的初始化程式碼。如果您的程式碼和相依性較大型，或您在初始化期間建立 SDK 用戶端，則此程序可能需要花費一些時間。當您的函數已有一段時間未使用、需要擴充規模或更新函數時，Lambda 會建立新的執行環境。這會導致新執行個體提供的請求部分，比其他執行個體具有更高的延遲，否則稱為冷啟動。

您可以在增加呼叫前配置佈建並行，來確保所有請求均由具有低延遲的初始化執行個體所提供。使用佈建並行設定的 Lambda 函數會以一致的啟動延遲執行，因此使它們非常適合建置互動式行動或 Web 後端、延遲敏感的微服務，以及同步叫用的 API。

注意

佈建並行計入函數的預留並行和區域配額。如果在函數版本和別名上佈建的並行數量加到函數的預留並行，則所有呼叫都會在佈建的並行上執行。此組態也有對未發佈版本函數 ($LATEST) 進行調節的效果，以防止其執行。您無法配置多於函數預留並行的佈建並行。

Lambda 也與 Application Auto Scaling 整合，讓您可以依據排程或根據使用率來管理佈建並行。

Lambda SnapStart 和佈建並行之間的差異

Lambda SnapStart 這是一種效能最佳化，可協助您將延遲敏感應用程式的啟動效能提升高達 10 倍，無需額外費用。佈建並行可讓函數保持初始化，並準備好在兩位數的毫秒內回應。設定佈建並行會對您的 AWS 帳戶 帳戶產生費用。如果您的應用程式有嚴格的冷啟動延遲需求，請使用佈建並行。您無法對相同的函數版本同時使用 SnapStart 和佈建並行。

設定佈建並行

若要管理版本或別名的佈建並行設定，請使用 Lambda 主控台。您可以在函數的某個版本或別名上設定佈建並行。

每個函數版本只能有一個佈建並行組態。這可以直接在版本本身，或指向版本的別名上。兩個別名無法配置相同版本的佈建並行。

如果您變更別名所指向的版本，Lambda 會從舊版本解除配置佈建並行，並將其配置給新版本。您可以將路由組態新增至具有佈建並行的別名。如需詳細資訊，請參閱 Lambda 函數別名。請注意，您無法在路由組態就位時，管理別名上的佈建並行設定。

注意

函數 ($LATEST) 的未發佈版本不支援佈建並行。在設定佈建並行之前，請確定您的用戶端應用程式未指向 $LATEST。

若要為別名或版本配置佈建並行

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

  2. 選擇一個函數。

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

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

  5. 選擇別名或版本。

  6. 輸入要配置的佈建並行數量。

  7. 選擇 Save (儲存)。

您也可以使用 Lambda API 並搭配下列作業，以設定佈建的並行：

若要為函數配置佈建並行，請使用 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": "2019-11-21T19:32:12+0000"
}

若要檢視您帳戶在區域中的並行配額，請使用 get-account-settings。

aws lambda get-account-settings

您應該會看到下列輸出：

{
    "AccountLimit": {
        "TotalCodeSize": 80530636800,
        "CodeSizeUnzipped": 262144000,
        "CodeSizeZipped": 52428800,
        "ConcurrentExecutions": 1000,
        "UnreservedConcurrentExecutions": 900
    },
    "AccountUsage": {
        "TotalCodeSize": 174913095,
        "FunctionCount": 52
    }
}

您可以從函數組態頁面管理所有別名和版本的佈建並行。佈建並行組態清單會顯示每個組態的配置進度。在每個版本和別名的組態頁面上，也提供佈建並行設定。

Lambda 會發出佈建並行的下列指標：

佈建並行指標

  • ProvisionedConcurrentExecutions – 在佈建並行上處理事件的函數執行個體數目。針對具有佈建並行之別名或版本的每次叫用，Lambda 都會發出目前的計數。

  • ProvisionedConcurrencyInvocations – 在佈建並行上執行函數程式碼的次數。

  • ProvisionedConcurrencySpilloverInvocations - 當所有佈建並行在使用中時，在標準並行上執行函數程式碼的次數。

  • ProvisionedConcurrencyUtilization - 對於版本或別名，則為 ProvisionedConcurrentExecutions 的值除以配置的佈建並行總量。例如，.5 表示 50% 已配置的佈建並行正在使用中。

如需詳細資訊，請參閱 使用 Lambda 函數指標。

利用佈建並行最佳化延遲

佈建並行不會在設定後立即上線。Lambda 會在準備一兩分鐘後，開始配置佈建的並行。類似函數在負載下擴展的方式，一次最多可初始化 3000 個函數執行個體，實際視區域而定。初始高載之後，將以每分鐘 500 個穩定的速率配置執行個體，直到滿足請求為止。當您為相同區域中的多個函數或函數版本請求佈建並行時，擴展配額會套用至所有請求。

透過佈建並行擴展。
圖例

  • 函數執行個體

  • 開啟請求

  • 佈建並行

  • 標準並行

若要最佳化延遲，您可以自訂使用佈建並行之函數的初始化行為。您可以針對佈建並行執行個體來執行初始化程式碼，而不會影響延遲，因為初始化程式碼會在配置時執行。然而，隨需執行個體的初始化程式碼會直接影響第一次叫用的延遲。針對隨需執行個體，您可以選擇延遲特定功能的初始化，直至函數需要該功能。

若要確定初始化的類型，請檢查 AWS_LAMBDA_INITIALIZATION_TYPE 的值。Lambda 會將此環境變數設定為 provisioned-concurrency 或 on-demand。AWS_LAMBDA_INITIALIZATION_TYPE 的值不可變，並且不會在執行環境的生命週期內變更。

如果您使用 .NET 3.1 執行時間，您可以設定 AWS_LAMBDA_DOTNET_PREJIT 環境變數，以改善使用佈建並行函數的延遲。.NET 運行時間會延遲編譯和初始化程式碼第一次呼叫的每個程式庫。因此，Lambda 函數的第一次叫用可能需要比後續叫用更長的時間。將 AWS_LAMBDA_DOTNET_PREJIT 設定為 ProvisionedConcurrency 時，LAMBDA 會針對一般系統相依性執行預先 JIT 編譯。Lambda 僅會針對佈建並行執行個體執行此初始化最佳化，這會使第一次叫用的效能更快。如果您將環境變數設定為 Always，則 Lambda 會針對每次初始化執行預先 JIT 編譯。如果您將環境變數設定為 Never，則會停用預先 JIT 編譯。AWS_LAMBDA_DOTNET_PREJIT 的預設值為 ProvisionedConcurrency。

針對佈建並行執行個體，由於函數的執行中執行個體已回收，函數的初始化程式碼會在配置期間每隔幾小時執行一次。您可以在執行個體處理要求之後，在記錄和追蹤中查看初始化時間。但是，即使執行個體從未處理請求，初始化也會計費。佈建並行會持續執行，並與初始化和叫用成本分開計費。如需詳細資訊，請參閱 AWS Lambda 定價。

如需使用佈建並行最佳化函數的詳細資訊，請參閱 Lambda 操作員指南。

使用 Application Auto Scaling 管理佈建並行

Application Auto Scaling 可讓您依據排程或根據使用率來管理佈建並行。如果想要您的函數維持指定的使用率百分比，請使用目標追蹤擴展政策，並使用排程擴展來增加佈建並行，以預期尖峰流量。

目標追蹤

使用目標追蹤，Application Auto Scaling 會建立和管理可觸發擴展政策的 CloudWatch 警示，並根據您定義的指標和目標值來計算擴展調整。這非常適合於沒有排程時間增加流量，但具有特定流量模式的應用程式。

若要視需求自動增加佈建並行，請使用 RegisterScalableTarget 及 PutScalingPolicy Application Auto Scaling API 作業來註冊目標及建立擴展政策：

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

  • 函數執行個體

  • 開啟請求

  • 佈建並行

  • 標準並行

依預設，這兩個警示都使用平均統計數字。具有快速高載流量模式的函數可能不會觸發您佈建的並行進行擴充。例如，如果您的 Lambda 函數快速執行 (20–100 毫秒)，且您的流量模式進入快速高載，這可能會導致傳入要求在高載期間超過您配置的佈建並行，但如果高載未持續 3 分鐘，則自動擴展不會觸發。或者，如果 CloudWatch 沒有取得命中目標平均值的三個資料點，則自動擴展政策不會觸發。

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

排程擴展

按照排程來擴展可讓您根據可預測的負載變化來設定自己的擴展排程。如需詳細資訊和範例，請參閱為週期性尖峰使用量排程 AWS Lambda 佈建並行功能。