本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
設定函數的佈建並行
在 Lambda 中,並行是函數目前正在處理的傳輸中請求數目。有兩種類型的並行控制項可用:
-
預留並行 – 它是分配給函數的並行執行個體數量上限。當某個函數具有預留並行時,其他函數都無法使用該並行。預留並行有助於確保最重要的函數始終有足夠的並行數量來處理傳入請求。設定函數的預留並行不會產生額外費用。
-
佈建並行 – 它是您分配給函數的預先初始化執行環境數目。這些執行環境已準備好立即回應傳入的函數請求。佈建並行有助於減少函數的冷啟動延遲。設定佈建並行會產生額外費用 AWS 帳戶。
本主題詳細說明如何管理及設定佈建並行。如需這兩種並行控制項的概念性概觀,請參閱預留並行與佈建並行。如需有關設定預留並行的詳細資訊,請參閱設定函數的預留並行。
注意
連結至 Amazon MQ 事件來源映射的 Lambda 函數具有預設並行上限。若使用 Apache Active MQ,並行執行個體數量上限為 5 個。若使用 ARabbit MQ,並行執行個體數量上限為 1 個。為函數設定保留或佈建並行不會改變這些上限。若要在使用 Amazon MQ 時要求增加預設的並行上限,請聯絡 支援。
章節
設定佈建並行
您可以使用 Lambda 主控台或 Lambda API 設定函數的佈建並行設定。
若要為函數配置佈建並行 (主控台)
開啟 Lambda 主控台中的函數頁面
。 -
選擇您要配置佈建並行的函數。
-
選擇 Configuration (組態),然後選擇 Concurrency (並行)。
-
在 Provisioned concurrency configurations (佈建並行組態) 下方,選擇 Add configuration (新增組態)。
-
選擇限定詞類型,以及別名或版本。
注意
您無法將佈建並行與任何函數的 $LATEST 版本搭配使用。
如果您的函數有事件來源,請確定事件來源指向正確的函數別名或版本。否則,您的函數將不會使用佈建並行環境。
-
在佈建並行下輸入一個數字。
-
選擇 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 環境變數。
如果您使用的是 .NET 8 執行期,您可以設定AWS_LAMBDA_DOTNET_PREJIT
環境變數來改善函數的延遲,即使它們不使用佈建並行。.NET 執行期會對第一次呼叫的每個程式庫採用延遲編譯和初始化。因此,Lambda 函數的第一次調用可能需要比後續調用更長的時間。若要減輕此問題,您可以針對 AWS_LAMBDA_DOTNET_PREJIT
選擇以下三個值之一:
-
ProvisionedConcurrency
:Lambda 會使用佈建並行,針對所有環境執行預先 JIT 編譯。這是預設值。 -
Always
:Lambda 會針對每個環境執行預先 JIT 編譯,即使函數未使用佈建並行。 -
Never
:Lambda 會針對所有環境停用預先 JIT 編譯。
了解使用佈建並行的記錄和計費行為
針對佈建並行環境,函數的初始化程式碼會在配置期間執行,且定期執行一次,因為 Lambda 會回收環境的執行個體。即使環境執行個體從未處理請求,Lambda 仍會向您收取初始化的費用。佈建並行會持續執行,並與初始化和調用成本分開計費。如需詳細資訊,請參閱 AWS Lambda 定價
當您使用佈建並行設定 Lambda 函數時,Lambda 會預先初始化該執行環境,以便在調用請求之前可供使用。Lambda 每次初始化環境時,都會以 JSON 記錄格式在 platform-initReport 日誌事件中記錄函數的 Init 持續時間欄位。若要查看此日誌事件,請將您的 JSON 日誌層級設定為至少 INFO
。您也可以使用遙測 API 來取用報告初始化持續時間欄位的平台事件。
使用 Application Auto Scaling 自動化佈建並行管理
Application Auto Scaling 可讓您依據排程或根據使用率來管理佈建並行。如果您的函數接收到可預測的流量模式,請使用排程擴展。如果您想要讓函數維持特定的使用率百分比,請使用目標追蹤擴展政策。
注意
如果您使用 Application Auto Scaling 來管理函數的佈建並行,請確保先設定初始佈建並行值。如果您的函數沒有初始佈建並行值,Application Auto Scaling 可能無法正確處理函數擴展。
排程擴展
Application Auto Scaling 可讓您根據可預測的負載變化來設定自己的擴展排程。如需詳細資訊和範例,請參閱《Application Auto Scaling 使用者指南》中的 Application Auto Scaling 的排程擴展,以及 AWS 運算部落格上針對週期性尖峰用量排程 AWS Lambda 佈建並行
目標追蹤
使用目標追蹤時,Application Auto Scaling 會會根據您定義擴展政策的方式,建立並管理一組 CloudWatch 警示。這些警示啟動時,Application Auto Scaling 會自動調整使用佈建並行配置的環境數量。對沒有可預測流量模式的應用程式使用目標追蹤。
若要使用目標追蹤擴展佈建並行,請使用 RegisterScalableTarget
和 PutScalingPolicy
Application Auto Scaling API 作業。例如,如果您使用的是 AWS Command Line Interface (CLI),請遵循下列步驟:
-
請將函數的別名註冊為擴展目標。以下範例會為函數
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
-
將擴展政策套用至目標。以下範例會設定 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 會減少別名的佈建並行。
注意
Lambda ProvisionedConcurrencyUtilization
只會在您的函數作用中且接收請求時發出指標。在閒置期間,不會發出任何指標,而且您的自動擴展警示將進入 INSUFFICIENT_DATA
狀態。因此,Application Auto Scaling 將無法調整函數的佈建並行。這可能會導致意外帳單。
在下列範例中,函數會根據使用率在佈建並行的最小和最大數量之間進行擴展。

圖例
-
函數執行個體
-
開啟請求
-
佈建並行
-
標準並行
當開啟的請求數量增加時,Application Auto Scaling 會大幅增加佈建並行,直到達到設定的最大值為止。在此之後,如果您尚未達到帳戶並行限制,則函數可以繼續按標準、未預留並行的方式擴展。當利用率下降且保持偏低時,Application Auto Scaling 會定期小幅減少佈建並行。
依預設,兩個 Application Auto Scaling 警示都會使用平均統計資料。經歷快速暴增流量的函數可能不會觸發這些警示。例如,假設您的 Lambda 函數執行速度很快 (即 20-100 毫秒),而您的流量會快速暴增。在此情況下,請求數量將在暴增期間超過配置的佈建並行。不過,Application Auto Scaling 需要暴增負載維持至少 3 分鐘,才能佈建其他環境。或者,兩個 CloudWatch 警示都需要達到目標平均值的 3 個資料點,才能啟用自動擴展政策。如果您的函數遇到快速的流量爆增,使用最大統計資料而非平均統計資料,可以更有效地擴展佈建並行,將冷啟動降至最低。
如需目標追蹤擴展政策的詳細資訊,請參閱 Application Auto Scaling 的目標追蹤擴展政策。