了解 Lambda 事件函數擴展

並行是 AWS Lambda 事件函數同時處理的傳輸中請求數量。Lambda 會針對每個並行請求佈建個別的執行環境執行個體。當您的事件函數收到更多請求時，Lambda 會自動處理擴展執行環境的數量，直到您達到帳戶的並行限制為止。根據預設，Lambda 會在 中的所有事件函數中為您的帳戶提供 1，000 個並行執行的總並行限制 AWS 區域。為了支援您的特定帳戶需求，您可以請求提高配額並設定函數層級並行控制，讓您的關鍵事件函數不會遇到限流。

本主題說明 Lambda 中的並行概念和事件函數擴展。本主題結束時，您將能了解如何計算並行、視覺化兩個主要並行控制選項 (預留和佈建)、預估適當的並行控制設定，以及檢視指標以進一步最佳化。

章節

• 了解和視覺化並行

• 計算事件函數的並行

• 了解預留並行和佈建並行

• 了解並行和每秒請求數

• 並行配額

• 設定事件函數的預留並行

• 設定事件函數的佈建並行

• 事件函數擴展行為

• 監控並行

了解和視覺化並行

Lambda 會在安全且隔離的執行環境中叫用您的事件函數。若要處理請求，Lambda 必須先初始化執行環境 (初始化階段)，才能使用它來調用您的事件函數 (調用階段)：

注意

實際初始化和調用持續時間可能會因許多因素而有所不同，例如您選擇的執行時間和 Lambda 事件函數程式碼。上圖表的用意並非表示初始化和調用階段持續時間的確切比例。

上圖使用矩形來代表單一執行環境。當您的 Event Function 收到其第一個請求 （由標籤為 的黃色圓圈表示1) 時，Lambda 會建立新的執行環境，並在初始化階段期間在您的主要處理常式外部執行程式碼。然後，Lambda 會在調用階段執行事件函數的主要處理常式程式碼。在整個過程中，此執行環境會處於忙碌狀態，無法處理其他請求。

當 Lambda 完成處理第一個請求時，此執行環境接著可以處理相同事件函數的其他請求。Lambda 不需要為後續請求重新初始化環境。

在上圖中，Lambda 重複使用執行環境來處理第二個請求 (以帶 2 標籤的黃色圓圈表示)。

目前為止，我們只將注意力放在執行環境的單一執行個體 (即並行 1)。實際上，Lambda 可能需要平行佈建多個執行環境執行個體，以處理所有傳入的請求。當您的事件函數收到新的請求時，可能會發生以下兩種情況之一：

• 如果預先初始化的執行環境執行個體可用，Lambda 會用它來處理請求。

• 若不可用，Lambda 便會建立新的執行環境執行個體來處理請求。

例如，讓我們來探索當您的事件函數收到 10 個請求時會發生什麼情況：

在上圖中，每個水平平面都代表單一執行環境執行個體 (以 A 至 F 標記)。以下是 Lambda 處理每個請求的方式：

請求	Lambda 行為	推理
1	佈建新環境 A	這是第一個請求；沒有可用的執行環境執行個體。
2	佈建新環境 B	現有的執行環境執行個體 A 忙碌中。
3	佈建新環境 C	現有的執行環境執行個體 A 和 B 都忙碌中。
4	佈建新環境 D	現有的執行環境執行個體 A、B 和 C 都忙碌中。
5	佈建新環境 E	現有的執行環境執行個體 A、B、C 和 D 都忙碌中。
6	重複使用環境 A	執行環境執行個體 A 已完成處理請求 1，現在可供使用。
7	重複使用環境 B	執行環境執行個體 B 已完成處理請求 2，現在可供使用。
8	重複使用環境 C	執行環境執行個體 C 已完成處理請求 3，現在可供使用。
9	佈建新環境 F	現有的執行環境執行個體 A、B、C、D 和 E 都忙碌中。
10	重複使用環境 D	執行環境執行個體 D 已完成處理請求 4，現在可供使用。

當 Event Function 收到更多並行請求時，Lambda 會擴展執行環境執行個體的數目以回應。以下動畫追蹤一段時間內並行請求的數目：

將上方動畫凍結在六個不同的時間點，我們可以得到下圖：

在上圖中，我們可以在任何時間點繪製一條垂直線，並計算與此線相交的環境數量。這可以得出該時間點並行請求的數量。例如，在 t1 時間點，有三個作用中環境可以處理三個並行請求。在 t4 時間點有六個作用中環境可處理六個並行請求，達到此模擬中的並行請求數上限。

總而言之，事件函數的並行是它同時處理的並行請求數量。為了回應事件函數並行增加，Lambda 會佈建更多執行環境執行個體以滿足請求需求。

計算事件函數的並行

在一般情況下，一個系統的並行是同時處理多個任務的能力。在 Lambda 中，並行是事件函數同時處理的傳輸中請求數量。測量 Lambda 事件函數並行的一種快速且實用的方法是使用下列公式：

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

並行與每秒請求數不同。例如，假設您的 Event Function 平均每秒收到 100 個請求。如果平均請求持續時間為一秒，那麼並行也會是 100：

Concurrency = (100 requests/second) * (1 second/request) = 100

但是，如果平均請求持續時間為 500 毫秒，則並行為 50：

Concurrency = (100 requests/second) * (0.5 second/request) = 50

在實務中並行 50 代表什麼意思？ 如果平均請求持續時間為 500 毫秒，則可以將函數的一個執行個體視為每秒能處理兩個請求。如此一來，函數需要 50 個執行個體來處理每秒 100 個請求的負載。並行 50 表示 Lambda 必須佈建 50 個執行環境執行個體，才能有效率地處理此工作負載，而不需要進行限流。底下以方程式的形式表示：

Concurrency = (100 requests/second) / (2 requests/second) = 50

如果您的事件函數收到請求數量的兩倍 （每秒 200 個請求），但只需要處理每個請求的一半時間 (250 毫秒），則並行仍然是 50：

Concurrency = (200 requests/second) * (0.25 second/request) = 50

測驗您對並行的理解

假設您有一個平均需要 200 毫秒執行的事件函數。在峰值負載期間，您觀察到每秒有 5,000 個請求。在尖峰負載期間，您的事件函數會並行什麼？

答案

平均事件函數持續時間為 200 毫秒或 0.2 秒。使用並行公式，您可以插入數字來得出並行為 1,000：

Concurrency = (5,000 requests/second) * (0.2 seconds/request) = 1,000

或者，平均 Event Function 持續時間為 200 毫秒，表示您的 Event Function 可以每秒處理 5 個請求。若要處理每秒 5,000 個請求的工作負載，您需要 1,000 個執行環境執行個體。因此並行為 1,000：

Concurrency = (5,000 requests/second) / (5 requests/second) = 1,000

了解預留並行和佈建並行

根據預設，您的帳戶在區域中所有事件函數的並行限制為 1，000 個並行執行。您的事件函數會隨需共用此 1，000 個並行集區。如果您用盡可用的並行，您的事件函數會遇到限流 （也就是，它們開始捨棄請求）。

有些事件函數可能比其他事件函數更重要。因此，您可能想要設定並行設定，以確保關鍵事件函數取得所需的並行。並行控制項有兩種：預留並行和佈建並行。

• 使用預留並行來設定並行執行個體的最大和最小數量，以保留您帳戶的一部分並行給事件函數。如果您不希望其他事件函數接受所有可用的未預留並行，這會很有用。當 Event Function 已保留並行時，沒有其他 Event Function 可以使用該並行。

• 使用佈建並行來預先初始化事件函數的多個環境執行個體。這對於縮短冷啟動延遲很有幫助。

預留並行

如果您想要保證隨時為您的事件函數提供特定數量的並行，請使用預留並行。

預留並行會設定您要配置給事件函數的並行執行個體數量上限和下限。當您將預留並行專用於事件函數時，其他事件函數都無法使用該並行。換句話說，設定預留並行可能會影響其他事件函數可用的並行集區。沒有預留並行的事件函數會共用未預留並行的剩餘集區。

設定預留並行會計入您的整體帳戶並行上限。為事件函數設定預留並行無需付費。

為了更清楚理解預留並行，請參考下圖：

在此圖中，您在此區域中所有事件函數的帳戶並行限制預設為 1，000。假設您有兩個重要事件函數 function-blue和 function-orange，通常預期會取得高調用磁碟區。您決定將 400個單位的預留並行提供給 function-blue，並為 function-orange 提供 400 單位的預留並行。在此範例中，您帳戶中的所有其他事件函數必須共用剩餘的 200 個未預留並行單位。

本圖有五個特點：

• 在 t1，function-orange 和 function-blue 都開始接收請求。每個事件函數會開始用完其配置的預留並行單位部分。

• 在 t2，function-orange 和 function-blue 穩定接收更多的請求。同時，您可以部署一些其他 Lambda 事件函數，以開始接收請求。您不會將預留並行配置給這些其他事件函數。這些函數開始使用剩餘 200 單位的未預留並行。

• 在 t3，function-orange 達到並行上限 400。雖然您帳戶中的其他地方存在未使用的並行，但 function-orange 無法存取。紅線表示 function-orange 發生限流，Lambda 可能會捨棄請求。

• 在 t4，function-orange 接收的請求開始變少，而且不再限流。不過，您的其他 Event Functions 會遇到流量激增並開始限流。雖然您的帳戶中其他位置有未使用的並行，但這些其他事件函數無法存取它。紅線表示您的其他事件函數正在經歷限流。

• 在 t5，其他 Event Functions 開始接收較少的請求，且不再限流。

在此範例中，請注意預留並行產生了下列影響：

• 您的事件函數可以獨立於帳戶中的其他事件函數進行擴展。您帳戶在相同 區域中沒有預留並行的所有事件函數都會共用未預留並行集區。如果沒有預留並行，其他事件函數可能會耗盡所有可用的並行。這可防止關鍵事件函數視需要向上擴展。

• 您的事件函數無法超出控制範圍。預留並行會限制事件函數的最大並行數和最小並行數。這表示您的 Event Function 無法使用為其他 Event Functions 預留的並行，或來自未預留集區的並行。此外，預留並行可同時做為下限和上限 - 它只會為您的事件函數保留指定的容量，同時防止其擴展超過該限制。您可以保留並行，以防止事件函數使用帳戶中所有可用的並行，或讓下游資源過載。

• 您可能無法使用您帳戶的所有可用並行。保留並行會計入您的帳戶並行限制，但這也表示其他事件函數無法使用該預留並行區塊。如果您的 Event Function 未使用您為其保留的所有並行，則表示您實際上正在浪費該並行。除非帳戶中的其他事件函數可能受益於浪費的並行，否則這不是問題。

若要了解如何管理事件函數的預留並行設定，請參閱 設定事件函數的預留並行。

佈建並行

您可以使用預留並行來定義 Lambda 事件函數預留的執行環境數目上限。不過，這些環境都不會預先初始化。因此，您的 Event Function 調用可能需要更長的時間，因為 Lambda 必須先初始化新環境，才能使用它來調用您的 Event Function。當 Lambda 必須初始化新的環境來執行調用時，這稱為冷啟動。若要緩解冷啟動情形，您可以使用佈建並行。

佈建並行是您要配置給 Event Function 的預先初始化執行環境數量。如果您在 Event Function 上設定佈建並行，Lambda 會初始化該數目的執行環境，讓他們準備好立即回應 Event Function 請求。

注意

設定佈建並行時，您的帳戶會產生額外費用。如果您使用 Java 11 或 Java 17 執行期，您也可以使用 Lambda SnapStart 來解決冷啟動問題，而無需額外付費。SnapStart 會使用執行環境的快取快照來顯著改善啟動效能。您無法在相同的事件函數版本上使用 SnapStart 和佈建並行。如需有關 SnapStart 功能、限制和支援區域的詳細資訊，請參閱 使用 Lambda SnapStart 改善啟動效能。

使用佈建並行時，Lambda 仍會在背景回收執行環境。例如，調用失敗後可能會發生這種情況。不過，在任何指定時間，Lambda 一律會確保預先初始化環境的數量等於事件函數佈建並行設定的值。重要的是，即使您使用的是佈建並行，如果 Lambda 必須重設執行環境，您仍然可能會遇到冷啟動延遲。

相反地，使用預留並行時，Lambda 可能會在閒置一段時間後完全終止環境。下圖說明當您使用預留並行與佈建並行設定事件函數時，比較單一執行環境的生命週期。

本圖有四個特點：

時間	預留並行	佈建並行
t1	什麼都沒發生。	Lambda 會預先初始化執行環境執行個體。
t2	請求 1 傳入。Lambda 必須初始化新的執行環境執行個體。	請求 1 傳入。Lambda 使用預先初始化的環境執行個體。
t3	閒置一段時間後，Lambda 會終止作用中環境執行個體。	什麼都沒發生。
t4	請求 2 傳入。Lambda 必須初始化新的執行環境執行個體。	請求 2 傳入。Lambda 使用預先初始化的環境執行個體。

為了更清楚理解佈建並行，請參考下圖：

在此圖中，您的帳戶並行上限為 1,000。您決定將 400 單位的佈建並行提供給 function-orange。您帳戶中的所有事件函數，包括 function-orange，都可以使用剩餘的 600 個未預留並行單位。

本圖有五個特點：

• 在 t1，function-orange 開始接收請求。由於 Lambda 已預先初始化 400 個執行環境執行個體，因此 function-orange 已準備好立即進行調用。

• 在 t2，function-orange 達到 400 個並行請求。因此，function-orange 用盡了佈建並行。但是由於仍有未預留並行可用，Lambda 還是可以用來處理 function-orange 的其他請求 (沒有限流)。Lambda 必須建立新的執行個體，才能處理這些請求，而且您的事件函數可能會遇到冷啟動延遲。

• 在 t3，流量短暫達到峰值後 function-orange 回到 400 個並行請求。Lambda 再度能在沒有冷啟動延遲的情況下處理所有請求。

• 在 t4，您帳戶中的事件函數流量爆增。此爆量可能來自 function-orange或您帳戶中的任何其他事件函數。Lambda 使用未預留並行處理這些請求。

• 在 t5，您帳戶中的事件函數達到 1，000 個並行限制上限，並體驗限流。

上一個範例只考慮了佈建並行。實際上，您可以在事件函數上同時設定佈建並行和預留並行。如果您的事件函數在工作日處理一致的調用負載，但經常在週末看到流量激增，則可以這樣做。在這種情況下，您可以使用佈建並行設定環境的基準數量來處理平日的請求，並使用預留並行處理週末峰值流量。請思考下圖情形：

在此圖中，假設您為 function-orange 設定了 200 單位的佈建並行，以及 400 單位的預留並行。因為您已設定預留並行，因此 function-orange 完全無法使用 600 單位的未預留並行。

此圖有 5 個特點：

• 在 t1，function-orange 開始接收請求。由於 Lambda 已預先初始化 200 個執行環境執行個體，因此 function-orange 已準備好立即進行調用。

• 在 t2， function-orange 會使用其所有佈建並行。 function-orange可以使用預留並行繼續處理請求，但這些請求可能會遇到冷啟動延遲。

• 在 t3，function-orange 達到 400 個並行請求。因此，function-orange 用盡了所有預留並行。由於 function-orange 不能使用未預留並行，因此請求開始限流。

• 在 t4，function-orange 接收的請求開始變少，而且不再限流。

• 在 t5，function-orange 下降到 200 個並行請求，因此所有請求都能再次使用佈建並行 (即無冷啟動延遲)。

預留並行和佈建並行都會計入您的帳戶並行上限和區域配額中。換言之，配置預留和佈建並行可能會影響其他事件函數可用的並行集區。設定佈建並行會產生 費用 AWS 帳戶。

注意

如果 Event Function 版本和別名上的佈建並行數量加總到 Event Function 的預留並行，則所有調用都會在佈建並行上執行。此組態也會對未發佈版本的 Event Function ($LATEST) 進行限流，以防止其執行。您無法為事件函數配置比預留並行更多的佈建並行。

若要管理事件函數的佈建並行設定，請參閱 設定事件函數的佈建並行。若要根據排程或應用程式使用率自動佈建並行擴展，請參閱 使用 Application Auto Scaling 自動化佈建並行管理。

Lambda 如何配置佈建並行

佈建並行不會在設定後立即上線。Lambda 會在準備一兩分鐘後，開始配置佈建的並行。對於每個事件函數，Lambda 每分鐘最多可佈建 6，000 個執行環境，無論如何 AWS 區域。這與 Event Functions 的並行擴展率完全相同。

當您提交配置佈建並行的請求時，在 Lambda 完全配置完成之前，您無法存取任何這些環境。例如，如果您請求 5,000 個佈建並行，在 Lambda 完全完成分配 5,000 個執行環境之前，您的請求都無法使用佈建並行。

比較預留並行和佈建並行

下表總結並比較預留和佈建並行。

主題	預留並行	佈建並行
定義	Event Function 的執行環境執行個體數目上限。	為您的 Event Function 設定預先佈建的執行環境執行個體數目。
佈建行為	Lambda 會隨需佈建新的執行個體。	Lambda 預先佈建執行個體 （也就是，在您的事件函數開始接收請求之前）。
冷啟動行為	由於 Lambda 必須隨需建立新執行個體，因此可能會發生冷啟動延遲。	由於 Lambda 不需要隨需建立執行個體，因此不可能會冷啟動延遲。
限流行為	達到預留並行限制時調節的事件函數。	如果未設定預留並行：事件函數會在達到佈建並行限制時使用未預留並行。 如果預留並行集：達到預留並行限制時調節事件函數。
未設定情況下的預設行為	Event Function 會使用您帳戶中可用的未預留並行。	Lambda 不會預先佈建任何執行個體。反之，如果未設定預留並行：事件函數會使用您帳戶中可用的未預留並行。 如果預留並行集：Event Function 使用預留並行。
定價	不收取額外費用。	會產生額外費用。

了解並行和每秒請求數

如前一節所述，並行與每秒請求數不同。在使用平均請求持續時間小於 100 毫秒的事件函數時，這是特別重要的區別。

在您的帳戶中的所有事件函數中，Lambda 會強制執行每秒請求數限制，相當於您帳戶並行的 10 倍。例如，由於預設帳戶並行限制為 1，000，因此您帳戶中的事件函數每秒最多可處理 10，000 個請求。

例如，請考慮平均請求持續時間為 50 毫秒的事件函數。在每秒 20，000 個請求時，以下是此事件函數的並行：

Concurrency = (20,000 requests/second) * (0.05 second/request) = 1,000

根據此結果，您可能會預期帳戶並行限制為 1,000 就足以處理此負載。不過，由於每秒 10，000 個請求的限制，您的 Event Function 只能處理 20，000 個請求中的每秒 10，000 個請求。此事件函數會經歷限流。

課程是在為事件函數設定並行設定時，您必須同時考慮並行和每秒請求數。這種情況下，您需要請求將帳戶並行限制提高到 2,000，因為這會將每秒請求總數限制提高到 20,000。

注意

根據此每秒請求數限制，假設每個 Lambda 執行環境每秒最多只能處理 10 個請求是不正確的。計算配額時，Lambda 不會觀察任何個別執行環境的負載，而只會考慮整體並行情況和每秒的整體請求數。

測試您對並行的了解 （事件函數低於 100 毫秒）

假設您有平均需要 20 毫秒執行的事件函數。在峰值負載期間，您觀察到每秒有 30,000 個請求。在尖峰負載期間，您的事件函數會並行什麼？

答案

平均事件函數持續時間為 20 毫秒或 0.02 秒。使用並行公式，您可以插入數字來得出並行為 600：

Concurrency = (30,000 requests/second) * (0.02 seconds/request) = 600

依預設，1,000 的帳戶並行限制似乎足以處理此負載。不過，每秒 10,000 個請求的限制不足以應對每秒 30,000 個傳入請求的狀況。若要完全容納 30,000 個請求，您需要請求將帳戶並行限制提高到 3,000 或更高。

每秒請求數限制適用於 Lambda 中涉及並行的所有配額。換句話說，它適用於同步隨需事件函數、使用佈建並行的事件函數，以及並行擴展行為。例如，在以下幾種情況中，您必須仔細考慮並行和每秒請求數限制：

• 使用隨需並行的事件函數每 10 秒可能會爆增 500 個並行，或每 10 秒每秒增加 5，000 個請求，以先發生者為準。

• 假設您有一個佈建並行配置為 10 的事件函數。此事件函數會在每秒 10 個並行或 100 個請求後溢出到隨需並行，以先發生者為準。

並行配額

Lambda 會設定您可以跨區域中所有事件函數使用的並行總量配額。這些配額存在於兩個層級：

• 在帳戶層級，您的事件函數預設最多可以有 1，000 個並行單位。若要提升配額，請參閱《Service Quotas 使用者指南》中的請求提升配額。

• 在函數層級，您預設可以在所有事件函數之間保留最多 900 個單位的並行。無論您的總帳戶並行限制為何，Lambda 一律會為未明確保留並行的事件函數保留 100 個並行單位。例如，如果您將帳戶並行上限增加到 2,000，就可以在函數層級預留最多 1,900 單位的並行。

• 在帳戶層級和函數層級，Lambda 也會強制執行每秒 10 倍於對應並行配額的請求限制。例如，這適用於帳戶層級並行、使用隨需並行的事件函數、使用提供的並行的事件函數，以及並行擴展行為。如需詳細資訊，請參閱了解並行和每秒請求數。

若要檢查目前的帳戶層級並行配額，請使用 AWS Command Line Interface (AWS CLI) 執行下列命令：

aws lambda get-account-settings

您應該會看到類似以下的輸出：

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

ConcurrentExecutions 是您的帳戶層級並行總配額。 UnreservedConcurrentExecutions是您仍可配置給事件函數的預留並行數量。

當 Event Function 收到更多請求時，Lambda 會自動擴展執行環境的數目，以處理這些請求，直到您的帳戶達到其並行配額為止。但是，為了防止因應突然爆發的流量而過度擴展，Lambda 限制了函數擴展的速度。此並行擴展率是您帳戶中的 Event Functions 可以擴展以回應增加請求的最大速率。(也就是說，Lambda 建立新執行環境的速度可以有多快。) 並行擴展率與帳戶層級並行限制不同，即事件函數可用的並行總量。

在每個 AWS 區域和每個 Event Function 中，您的並行擴展速率為每 10 秒 1，000 個執行環境執行個體 （或每 10 秒每秒 10，000 個請求）。換句話說，Lambda 每隔 10 秒就可以為每個函數配置最多 1,000 個額外執行環境的執行個體，或者每秒容納 10,000 個額外請求。

通常情況下，您不需要擔心此限制。對於大多數使用案例，Lambda 的擴展速率已足夠。

重要的是，並行擴展速率是函數層級限制。這表示您帳戶中的每個事件函數都可以獨立於其他事件函數進行擴展。

如需擴展行為的詳細資訊，請參閱 事件函數擴展行為。