本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 了解 Lambda 函數擴展
**並行**是 AWS Lambda 函數同時處理的傳輸中請求數量。Lambda 會針對每個並行請求佈建個別的執行環境執行個體。函數收到更多請求時，Lambda 會自動處理執行環境的擴展數量，直到達到帳戶的並行上限為止。根據預設，Lambda 會為您的帳戶提供一個 AWS 區域中所有函數的總並行上限 1,000 個並行執行數。為了支援您的特定帳戶需求，您可以[請求提高配額](https://aws.amazon.com/premiumsupport/knowledge-center/lambda-concurrency-limit-increase/)，並設定函數層級並行控制項，讓您的重要函數不會發生限流。
本主題說明 Lambda 中的並行和函數擴展。本主題結束時，您將能了解如何計算並行、視覺化兩個主要並行控制選項 (預留和佈建)、預估適當的並行控制設定，以及檢視指標以進一步最佳化。
**Topics**
+ [
## 了解和視覺化並行
](#understanding-concurrency)
+ [
## 計算函數的並行
](#calculating-concurrency)
+ [
## 了解預留並行和佈建並行
](#reserved-and-provisioned)
+ [
## 了解並行和每秒請求數
](#concurrency-vs-requests-per-second)
+ [
## 並行配額
](#concurrency-quotas)
+ [
# 設定函數的預留並行
](configuration-concurrency.md)
+ [
# 設定函數的佈建並行
](provisioned-concurrency.md)
+ [
# Lambda 擴展行為
](scaling-behavior.md)
+ [
# 監控並行
](monitoring-concurrency.md)
## 了解和視覺化並行
Lambda 會在安全且隔離的[執行環境](lambda-runtime-environment.md)中調用函數。為了處理請求，Lambda 必須先初始化執行環境 ([初始化階段](lambda-runtime-environment.md#runtimes-lifecycle-ib))，然後才能用它來調用函數 ([調用階段](lambda-runtime-environment.md#runtimes-lifecycle-invoke))：
![\[\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/concurrency-1-environment.png)
**注意**
實際初始化和調用持續時間可能因許多因素而異，例如您選擇的執行階段和 Lambda 函數程式碼。上圖表的用意並非表示初始化和調用階段持續時間的確切比例。
上圖使用矩形來代表單一執行環境。當函數收到第一個請求 (以帶有 `1` 標籤的黃色圓圈表示)，Lambda 會建立一個新的執行環境，並在初始化階段於主處理常式之外執行程式碼。接著 Lambda 會在調用階段執行函數的主要處理常式程式碼。在整個過程中，此執行環境會處於忙碌狀態，無法處理其他請求。
Lambda 完成處理第一個請求後，此執行環境就可以處理同一個函數的其他請求。Lambda 不需要為後續請求重新初始化環境。
![\[\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/concurrency-2-two-requests.png)
在上圖中，Lambda 重複使用執行環境來處理第二個請求 (以帶 `2` 標籤的黃色圓圈表示)。
目前為止，我們只將注意力放在執行環境的單一執行個體 (即並行 1)。實際上，Lambda 可能需要平行佈建多個執行環境執行個體，以便處理所有傳入的請求。當函數收到新請求，可能會發生的情況有以下兩種：
+ 如果預先初始化的執行環境執行個體可用，Lambda 會用它來處理請求。
+ 若不可用，Lambda 便會建立新的執行環境執行個體來處理請求。
例如，我們來看看當函數收到 10 個請求時會發生什麼情形：
![\[\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/concurrency-3-ten-requests.png)
在上圖中，每個水平平面都代表單一執行環境執行個體 (以 `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**，現在可供使用。 |
當函數收到更多並行請求時，Lambda 會擴展執行環境執行個體的數量做為回應。以下動畫追蹤一段時間內並行請求的數目：
![\[\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/concurrency-4-animation.gif)
將上方動畫凍結在六個不同的時間點，我們可以得到下圖：
![\[\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/concurrency-5-animation-summary.png)
在上圖中，我們可以在任何時間點繪製一條垂直線，並計算與此線相交的環境數量。這可以得出該時間點並行請求的數量。例如，在 `t1` 時間點，有三個作用中環境可以處理三個並行請求。在 `t4` 時間點有六個作用中環境可處理六個並行請求，達到此模擬中的並行請求數上限。
總之，函數的並行就是代表函數同時處理的請求數目。為了回應函數並行的增加，Lambda 會佈建更多執行環境執行個體以滿足請求的需求。
## 計算函數的並行
在一般情況下，一個系統的並行是同時處理多個任務的能力。在 Lambda 中，並行是函數可同時處理的傳輸中請求數目。測量 Lambda 函數並行的快速實用方法是使用以下公式：
```
Concurrency = (average requests per second) * (average request duration in seconds)
```
**並行與每秒請求數不同。**例如，假設函數平均每秒收到 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
```
或者，平均函數持續時間為 200 毫秒表示函數每秒可以處理 5 個請求。若要處理每秒 5,000 個請求的工作負載，您需要 1,000 個執行環境執行個體。因此並行為 1,000：
```
Concurrency = (5,000 requests/second) / (5 requests/second) = 1,000
```
## 了解預留並行和佈建並行
根據預設，您帳戶設有一個區域中所有函數的並行執行數上限 1,000。您的函數會隨需共用此 1,000 並行的集區。如果您用完可用的並行，您的函數會遇到限流 （也就是，它們開始捨棄請求）。
某些函數的重要性可能高於其他函數。因此，您可能會想配置並行設定，確保重要函數可獲得所需的並行。並行控制項有兩種：預留並行和佈建並行。
+ 使用**預留並行**即可設定並行執行個體數量上限與下限，為函式保留帳戶中的一部分並行配額。如果您不希望其他函數占用所有可用的未預留並行，此功能非常有用。當某個函數具有預留並行時，其他函數都無法使用該並行。
+ 使用**佈建並行**為函數預先初始化多個環境執行個體。這對於縮短冷啟動延遲很有幫助。
### 預留並行
如果您想要保證函數隨時可以使用一定數量的並行，請使用預留並行。
預留並行會設定要配置給函式的並行執行個體數量上限與下限。將預留並行專門留給某個函數時，其他函數都無法使用該並行。換句話說，設定預留並行可能會影響其他函數可用的並行集區。沒有預留並行的函數會共用未預留剩餘的並行集區。
設定預留並行會計入您的整體帳戶並行上限。設定函數的預留並行不收費。
為了更清楚理解預留並行，請參考下圖：
![\[\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/concurrency-6-reserved-concurrency.png)
在本圖中，您的帳戶在此區域中所有函數的並行上限為預設值 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` 接收的請求開始變少，而且不再限流。但是，其他函數出現流量尖峰並開始限流。雖然您帳戶中的其他地方存在未使用的並行，但這些其他函數無法存取。紅線表示其他函數正在進行限流。
+ 在 `t5`，其他函數接收的請求開始變少，而且不再限流。
在此範例中，請注意預留並行產生了下列影響：
+ **函數可以獨立於帳戶中的其他函數進行擴展。**您的帳戶下相同區域中沒有預留並行的所有函數，都會共用未預留的並行集區。如果沒有預留並行，其他函數可能會用盡所有可用的並行。這可以視需要防止您的重要數擴展。
+ **您的函數無法無止盡擴展。**預留並行會對函式的並行上下限設定限制。這表示函數不能使用為其他函數預留的並行，也不能使用未預留集區中的並行。此外，預留並行兼具下限與上限作用：會預留指定的容量專用於您的函式，也會防止容量擴展超過上限。您可以預留並行以防止函數用完帳戶中的所有可用並行，或過載下游資源。
+ **您可能無法使用帳戶可用的所有並行。**預留並行會計入您帳戶的並行上限，但這也表示其他函數無法使用該部分預留並行。如果函數沒有用盡您為它預留的所有並行，那麼實際上就浪費了這些並行。除非浪費的並行可讓您帳戶中的其他函數獲益，這才不會成為問題。
若要管理函數的預留並行設定，請參閱：[設定函數的預留並行](configuration-concurrency.md)。
### 佈建並行
您可以使用預留並行來定義為 Lambda 函數預留的執行環境數目上限。不過，這些環境都不會預先初始化。因此，函數調用可能需要花更長的時間，因為 Lambda 必須先初始化新環境，才能用來調用函數。當 Lambda 必須初始化新環境才能執行調用時，就稱為[冷啟動](lambda-runtime-environment.md#cold-start-latency)。若要緩解冷啟動情形，您可以使用佈建並行。
佈建並行是您要分配給函數的預先初始化執行環境數。如果您為函數設定了佈建並行，Lambda 便會初始化該數量的執行環境，以便立即回應函數請求。
**注意**
設定佈建並行時，您的帳戶會產生額外費用。如果您使用 Java 11 或 Java 17 執行期，您也可以使用 Lambda SnapStart 來解決冷啟動問題，而無需額外付費。SnapStart 會使用執行環境的快取快照來顯著改善啟動效能。您無法對相同的函數版本同時使用 SnapStart 和佈建並行。如需有關 SnapStart 功能、限制和支援區域的詳細資訊，請參閱 [使用 Lambda SnapStart 改善啟動效能](snapstart.md)。
使用佈建並行時，Lambda 仍會在背景回收執行環境。例如，[調用失敗後](lambda-runtime-environment.md#runtimes-lifecycle-invoke-with-errors)可能會發生這種情況。但是在任何給定時間，Lambda 總是會確保預先初始化的環境數量等於函數佈建並行設定的值。重要的是，即使您使用的是佈建並行，如果 Lambda 必須重設執行環境，您仍然可能會遇到冷啟動延遲。
與之相反，如果使用的是預留並行，Lambda 可能會在閒置一段時間後完全終止環境。下圖說明這一點，比較為函數設定預留並行和佈建並行的情況下，單一執行環境的生命週期有何差異。
![\[\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/concurrency-7-reserved-vs-provisioned.png)
本圖有四個特點：
| 時間 | 預留並行 | 佈建並行 |
| --- | --- | --- |
| t1 | 什麼都沒發生。 | Lambda 會預先初始化執行環境執行個體。 |
| t2 | 請求 1 傳入。Lambda 必須初始化新的執行環境執行個體。 | 請求 1 傳入。Lambda 使用預先初始化的環境執行個體。 |
| t3 | 閒置一段時間後，Lambda 會終止作用中環境執行個體。 | 什麼都沒發生。 |
| t4 | 請求 2 傳入。Lambda 必須初始化新的執行環境執行個體。 | 請求 2 傳入。Lambda 使用預先初始化的環境執行個體。 |
為了更清楚理解佈建並行，請參考下圖：
![\[\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/concurrency-8-provisioned-concurrency.png)
在此圖中，您的帳戶並行上限為 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，並且發生限流。
上一個範例只考慮了佈建並行。實際上，您可以對函數同時設定佈建並行和預留並行。如果您有一個函數在工作日期間負責處理調用的一致性負載，但週末期間經常會遇到流量峰值，便可以這麼做。在這種情況下，您可以使用佈建並行設定環境的基準數量來處理平日的請求，並使用預留並行處理週末峰值流量。請思考下圖情形：
![\[\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/concurrency-9-reserved-and-provisioned.png)
在此圖中，假設您為 `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 個並行請求，因此所有請求都能再次使用佈建並行 (即無冷啟動延遲)。
預留並行和佈建並行都會計入您的帳戶並行上限和[區域配額](gettingstarted-limits.md)中。換句話說，分配預留和佈建並行可能會影響其他函數可用的並行集區。設定佈建並行會產生 費用 AWS 帳戶。
**注意**
如果在函數版本與別名功能上佈建的並行數量加到函數的預留並行，則所有呼叫都會在佈建的並行上執行。此組態也有對未發佈版本函數 (`$LATEST`) 進行節流的效果，以防止其執行。您無法配置多於函數預留並行的佈建並行。
若要管理函數的佈建並行設定，請參閱 [設定函數的佈建並行](provisioned-concurrency.md)。若要根據排程或應用程式使用率自動佈建並行擴展，請參閱 [使用 Application Auto Scaling 自動化佈建並行管理](provisioned-concurrency.md#managing-provisioned-concurency)。
### Lambda 如何配置佈建並行
佈建並行不會在設定後立即上線。Lambda 會在準備一兩分鐘後，開始配置佈建的並行。對於每個函數，Lambda 每分鐘最多可以佈建 6，000 個執行環境，無論如何 AWS 區域。這與函數的[並行擴展率](scaling-behavior.md#scaling-rate)完全相同。
當您提交配置佈建並行的請求時，在 Lambda 完全配置完成之前，您無法存取任何這些環境。例如，如果您請求 5,000 個佈建並行，在 Lambda 完全完成分配 5,000 個執行環境之前，您的請求都無法使用佈建並行。
### 比較預留並行和佈建並行
下表總結並比較預留和佈建並行。
| 主題 | 預留並行 | 佈建並行 |
| --- | --- | --- |
| 定義 | 函數的執行環境執行個體數目上限。 | 為函數設定預先佈建的執行環境執行個體數目。 |
| 佈建行為 | Lambda 會隨需佈建新的執行個體。 | Lambda 會預先佈建執行個體 (即在函數開始接收請求之前)。 |
| 冷啟動行為 | 由於 Lambda 必須隨需建立新執行個體，因此可能會發生冷啟動延遲。 | 由於 Lambda 不需要隨需建立執行個體，因此不可能會冷啟動延遲。 |
| 限流行為 | 達到預留並行上限時，會對函數限流。 | 如果沒有設定預留並行：達到佈建並行上限時，函數會使用未預留的並行。 如果有設定預留並行：達到預留並行上限時，會對函數限流。 |
| 未設定情況下的預設行為 | 函數會使用帳戶中可用的未預留並行。 | Lambda 不會預先佈建任何執行個體。反之，如果沒有設定預留並行：函數會使用帳戶中可用的未預留並行。 如果有設定預留並行：函數會使用預留並行。 |
| 定價 | 不收取額外費用。 | 會產生額外費用。 |
## 了解並行和每秒請求數
如前一節所述，並行與每秒請求數不同。這是使用平均請求持續時間小於 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 個請求的限制，您的函數每秒只能處理 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 中涉及並行的所有配額。換句話說，它適用於同步隨需函數、使用佈建並行的函數，以及[並行擴展行為](scaling-behavior.md)。例如，在以下幾種情況中，您必須仔細考慮並行和每秒請求數限制：
+ 使用隨需並行的函數每 10 秒的並行可能爆增 500，或每 10 秒內的每秒請求數增加 5,000，以先發生者為準。
+ 假設您有一個函數，其佈建並行分配為 10。此函數會在 10 個並行或每秒 100 個請求後 (以先發生者為準) 溢出到隨需並行。
## 並行配額
Lambda 會針對區域中所有函數可用的並行總量設定配額。這些配額存在於兩個層級：
+ **帳戶層級**，預設情況下，函數最多可有 1,000 單位的並行。若要提升配額，請參閱《Service Quotas 使用者指南》**中的[請求提升配額](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)。
+ **函數層級**，預設情況下，您可在所有函數間保留最多 900 單位的並行。無論您的總帳戶並行限制為何，Lambda 一律會為未明確保留並行保留的函數保留 100 個並行單位。例如，如果您將帳戶並行上限增加到 2,000，就可以在函數層級預留最多 1,900 單位的並行。
+ 在帳戶層級和函數層級，Lambda 也會強制執行每秒 10 倍於對應並行配額的請求限制。例如，這適用於帳戶層級並行、使用隨需並行的函數、使用佈建並行的函數，以及[並行擴展行為](scaling-behavior.md)。如需詳細資訊，請參閱[了解並行和每秒請求數](#concurrency-vs-requests-per-second)。
若要檢查目前的帳戶層級並行配額，請使用 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` 是您仍可配置給函數的保留並行數量。
函數收到更多請求時，Lambda 會自動提高執行環境的數量來處理這些請求，直到您的帳戶達到並行配額為止。但是，為了防止因應突然爆發的流量而過度擴展，Lambda 限制了函數擴展的速度。此**並行擴展速率**是您帳戶中的函數可擴展以因應增加的請求的最高速率。(也就是說，Lambda 建立新執行環境的速度可以有多快。) 並行擴展速率與帳戶層級並行限制不同，後者是您的函數可用的並行總量。
**在每個 AWS 區域和每個函數中，您的並行擴展速率為每 10 秒 1，000 個執行環境執行個體 （或每 10 秒每秒 10，000 個請求）。**換句話說，Lambda 每隔 10 秒就可以為每個函數配置最多 1,000 個額外執行環境的執行個體，或者每秒容納 10,000 個額外請求。
通常情況下，您不需要擔心此限制。對於大多數使用案例，Lambda 的擴展速率已足夠。
重要的是，並行擴展速率是函數層級限制。這意味著帳戶中的每個函數都可以獨立於其他函數進行擴展。
如需擴展行為的詳細資訊，請參閱 [Lambda 擴展行為](scaling-behavior.md)。
# 設定函數的預留並行
在 Lambda 中，[並行](lambda-concurrency.md)是函數目前正在處理的傳輸中請求數目。有兩種類型的並行控制項可用：
+ 預留並行 – 此控制項設定配置給函式的並行執行個體數量上限與下限。當某個函數具有預留並行時，其他函數都無法使用該並行。預留並行有助於確保最重要的函數始終有足夠的並行數量來處理傳入請求。此外，預留並行可用於限制並行量，防止資料庫連線等下游資源不堪重負。預留並行兼具下限與上限作用 – 會預留指定的容量專用於您的函式，也會防止容量擴展超過上限。設定函數的預留並行不會產生額外費用。
+ 佈建並行 – 它是您分配給函數的預先初始化執行環境數目。這些執行環境已準備好立即回應傳入的函數請求。佈建並行對於降低函式的冷啟動延遲非常有用，旨在使函式的回應時間降低到兩位數的毫秒級。一般而言，互動式工作負載能從這項功能中獲益最多。這些是使用者啟動請求的應用程式 (例如 Web 和行動應用程式)，對延遲最敏感。非同步工作負載 (如資料處理管道) 通常對延遲較不敏感，因此通常不需要佈建並行。設定佈建並行會對您的 AWS 帳戶 帳戶產生額外費用。
本主題詳細說明如何管理及設定預留並行。如需這兩種並行控制項的概念性概觀，請參閱[預留並行與佈建並行](https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html#reserved-and-provisioned)。如需有關設定佈建並行的資訊，請參閱 [設定函數的佈建並行](provisioned-concurrency.md)。
**注意**
連結至 Amazon MQ 事件來源映射的 Lambda 函數具有預設並行上限。若使用 Apache Active MQ，並行執行個體數量上限為 5 個。若使用 ARabbit MQ，並行執行個體數量上限為 1 個。為函數設定保留或佈建並行不會改變這些上限。若要在使用 Amazon MQ 時要求增加預設的並行上限，請聯絡 支援。
**Topics**
+ [
## 設定預留並行
](#configuring-concurrency-reserved)
+ [
## 準確估計函數所需的預留並行
](#estimating-reserved-concurrency)
## 設定預留並行
您可以使用 Lambda 主控台或 Lambda API 設定函數的預留並行設定。
**預留函數並行的方式 (主控台)**
1. 開啟 Lambda 主控台中的 [函數頁面](https://console.aws.amazon.com/lambda/home#/functions)。
1. 選擇要預留並行的函數。
1. 選擇 **Configuration (組態)**，然後選擇 **Concurrency (並行)**。
1. 在 **Concurrency (並行)** 下，選擇 **Edit (編輯)**。
1. 選擇 **Reserve concurrency (預留並行)**。輸入要為函式預留的並行數量。
1. 選擇**儲存**。
您最多可以預留的數量為**未預留帳戶並行數量**減去 100 的值。剩餘的 100 個並行單位會用於未使用預留並行的函數。例如，如果您帳戶的並行上限為 1,000，則您無法為單一函數預留全部 1,000 個並行單位。
![\[\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/concurrency-reserve-over-limit.png)
為函數預留並行會影響其他函數可用的並行集區。例如，如果您為 `function-a` 預留 100 個並行單位，則帳戶中的其他函數必須共用剩餘的 900 個並行單位 (即使 `function-a` 未使用全部 100 個預留並行單位也一樣)。
若要刻意節流函數，請將其預留並行設為 0。此動作會防止函數處理任何事件，直到您移除限制為止。
若要透過 Lambda API 設定預留並行，請使用下列 API 操作。
+ [PutFunctionConcurrency](https://docs.aws.amazon.com/lambda/latest/api/API_PutFunctionConcurrency.html)
+ [GetFunctionConcurrency](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConcurrency.html)
+ [DeleteFunctionConcurrency](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunctionConcurrency.html)
例如，若要透過 AWS Command Line Interface (CLI) 來設定預留並行，請使用 `put-function-concurrency` 命令。下列命令會為名為 `my-function` 的函數預留 100 個並行單位：
```
aws lambda put-function-concurrency --function-name my-function \
--reserved-concurrent-executions 100
```
您應該會看到類似以下的輸出：
```
{
"ReservedConcurrentExecutions": 100
}
```
## 準確估計函數所需的預留並行
如果函數目前正在為處理流量，您可以使用 [CloudWatch 指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)輕鬆檢視其並行指標。具體而言，`ConcurrentExecutions` 指標會顯示帳戶中每個函數的並行調用次數。
![\[\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/concurrency-concurrent-executions-metrics.png)
前一張圖表顯示此函數一天平均可處理 5 到 10 個並行請求，峰值時段則為 20 個請求。假設帳戶中還有很多其他函數。**如果此函數對您的應用程式很重要，且您不想要捨棄任何請求**，則請將預留並行設為 20 (或以上)。
或者，回想一下您也可以使用以下公式[計算並行](https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html#calculating-concurrency)：
```
Concurrency = (average requests per second) * (average request duration in seconds)
```
將每秒平均請求乘以平均請求持續時間 (以秒為單位)，可讓您粗略估計需要預留多少並行。您可以使用 `Invocation` 指標來預估每秒平均請求數，並使用 `Duration` 指標預估平均請求持續時間 (以秒為單位)。如需詳細資訊，請參閱[將 CloudWatch 指標與 Lambda 搭配使用](monitoring-metrics.md)。
您應熟悉您的上游和下游輸送量限制。雖然 Lambda 函數可隨負載進行無縫擴展，但上游和下游相依性可能不具有相同的輸送量能力。如果您需要限制函數可擴展的高度，可以在函數中設定預留並行。
# 設定函數的佈建並行
在 Lambda 中，[並行](lambda-concurrency.md)是函數目前正在處理的傳輸中請求數目。有兩種類型的並行控制項可用：
+ 預留並行 – 此控制項設定配置給函式的並行執行個體數量上限與下限。當某個函數具有預留並行時，其他函數都無法使用該並行。預留並行有助於確保最重要的函數始終有足夠的並行數量來處理傳入請求。此外，預留並行可用於限制並行量，防止資料庫連線等下游資源不堪重負。預留並行兼具下限與上限作用 – 會預留指定的容量專用於您的函式，也會防止容量擴展超過上限。設定函數的預留並行不會產生額外費用。
+ 佈建並行 – 它是您分配給函數的預先初始化執行環境數目。這些執行環境已準備好立即回應傳入的函數請求。佈建並行對於降低函式的冷啟動延遲非常有用，旨在使函式的回應時間降低到兩位數的毫秒級。一般而言，互動式工作負載能從這項功能中獲益最多。這些是使用者啟動請求的應用程式 (例如 Web 和行動應用程式)，對延遲最敏感。非同步工作負載 (如資料處理管道) 通常對延遲較不敏感，因此通常不需要佈建並行。設定佈建並行會對您的 AWS 帳戶 帳戶產生額外費用。
本主題詳細說明如何管理及設定佈建並行。如需這兩種並行控制項的概念性概觀，請參閱[預留並行與佈建並行](https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html#reserved-and-provisioned)。如需有關設定預留並行的詳細資訊，請參閱[設定函數的預留並行](configuration-concurrency.md)。
**注意**
連結至 Amazon MQ 事件來源映射的 Lambda 函數具有預設並行上限。若使用 Apache Active MQ，並行執行個體數量上限為 5 個。若使用 ARabbit MQ，並行執行個體數量上限為 1 個。為函數設定保留或佈建並行不會改變這些上限。若要在使用 Amazon MQ 時要求增加預設的並行上限，請聯絡 支援。
**Topics**
+ [
## 設定佈建並行
](#configuring-provisioned-concurrency)
+ [
## 準確估算函數所需的佈建並行
](#estimating-provisioned-concurrency)
+ [
## 使用佈建並行時最佳化函數程式碼
](#optimizing-latency)
+ [
## 使用環境變數來檢視和控制佈建並行行為
](#pc-environment-variables)
+ [
## 了解使用佈建並行的記錄和計費行為
](#pc-logging-behavior)
+ [
## 使用 Application Auto Scaling 自動化佈建並行管理
](#managing-provisioned-concurency)
## 設定佈建並行
您可以使用 Lambda 主控台或 Lambda API 設定函數的佈建並行設定。
**若要為函數配置佈建並行 (主控台)**
1. 開啟 Lambda 主控台中的 [函數頁面](https://console.aws.amazon.com/lambda/home#/functions)。
1. 選擇您要配置佈建並行的函數。
1. 選擇 **Configuration (組態)**，然後選擇 **Concurrency (並行)**。
1. 在 **Provisioned concurrency configurations (佈建並行組態)** 下方，選擇 **Add configuration (新增組態)**。
1. 選擇限定詞類型，以及別名或版本。
**注意**
您無法將佈建並行與任何函數的 \$1LATEST 版本搭配使用。
如果您的函數有事件來源，請確定事件來源指向正確的函數別名或版本。否則，您的函數將不會使用佈建並行環境。
1. 在**佈建並行**下輸入一個數字。
1. 選擇**儲存**。
您最多可以在帳戶中設定的數量為**未預留帳戶並行數量**減去 100 的值。剩餘的 100 個並行單位會用於未使用預留並行的函數。例如，如果帳戶的並行限制為 1,000，而且您尚未將任何預留或佈建並行指派給任何其他函數，則單一函數最多可以設定 900 個佈建並行單位。
![\[\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/provisioned-concurrency-over-limit.png)
為函數設定佈建並行會影響其他函數可用的並行集區。例如，如果您為 `function-a` 設定 100 個佈建並行單位，則帳戶中的其他函數必須共用剩餘的 900 個並行單位。即使 `function-a` 沒有使用所有 100 個單位也是如此。
您可以為同一函數同時配置預留並行和佈建並行。在這種情況下，佈建並行不能超過預留並行。
此限制也適用於不同函數版本。您可以指派給特定函數版本的佈建並行上限等於函數的預留並行減去其他函數版本上的佈建並行。
若要透過 Lambda API 設定佈建並行，請使用下列 API 操作。
+ [PutProvisionedConcurrencyConfig](https://docs.aws.amazon.com/lambda/latest/api/API_PutProvisionedConcurrencyConfig.html)
+ [GetProvisionedConcurrencyConfig](https://docs.aws.amazon.com/lambda/latest/api/API_GetProvisionedConcurrencyConfig.html)
+ [ListProvisionedConcurrencyConfigs](https://docs.aws.amazon.com/lambda/latest/api/API_ListProvisionedConcurrencyConfigs.html)
+ [DeleteProvisionedConcurrencyConfig](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteProvisionedConcurrencyConfig.html)
例如，若要透過 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](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) 指標來檢視任何作用中函數的並行指標。具體而言，`ConcurrentExecutions` 指標會顯示帳戶中函數的並行調用次數。
![\[\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/concurrency-concurrent-executions-metrics.png)
前一張圖表顯示此函數在任何特定時間平均可處理 5 到 10 個並行請求，峰值時段則為 20 個請求。假設帳戶中還有很多其他函數。**如果此函數對您的應用程式很重要，而且每次調用都需要低延遲回應**，請將佈建並行設為至少 20 個單位。
回想一下，您也可以使用以下公式[計算並行](https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html#calculating-concurrency)：
```
Concurrency = (average requests per second) * (average request duration in seconds)
```
若要預估您需要多少並行，將每秒平均請求乘以平均請求持續時間 (以秒為單位)。您可以使用 `Invocation` 指標來預估每秒平均請求數，並使用 `Duration` 指標預估平均請求持續時間 (以秒為單位)。
設定佈建並行時，Lambda 建議在函數通常需要的並行量上額外加上 10% 的緩衝。例如，如果函數通常在 200 個並行請求達到峰值，可將佈建並行設定為 220 (200 個並行請求 \$1 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 會在每次冷啟動時執行該程式碼。這可能會增加整體延遲。
您可以新增 X-Ray 監控到函數，以測量 Lambda 向上擴展時的冷啟動。使用佈建並行的函式不會顯示冷啟動行為，因為執行環境在調用之前已準備妥當。不過，佈建並行必須套用至函式的[特定版本或別名](https://docs.aws.amazon.com/lambda/latest/dg/configuration-versions.html)，而不是 \$1LATEST 版本。如果持續看到冷啟動行為，請確保調用的是已設定佈建並行的別名版本。
## 使用環境變數來檢視和控制佈建並行行為
您的函數可能會耗盡本身的所有佈建並行。Lambda 使用隨需執行個體來處理任何超出流量。為了判斷 Lambda 用於特定環境的初始化類型，請檢查 `AWS_LAMBDA_INITIALIZATION_TYPE` 環境變數的值。此變數有兩個可能的值：`provisioned-concurrency` 或 `on-demand`。`AWS_LAMBDA_INITIALIZATION_TYPE` 的值不可變，並且在整個環境的生命週期中保持不變。若要檢查函數程式碼中環境變數的值，請參閱[擷取 Lambda 環境變數](configuration-envvars.md#retrieve-environment-variables)。
若您使用 .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 定價](https://aws.amazon.com/lambda/pricing/)。
當您使用佈建並行設定 Lambda 函式時，Lambda 會預先初始化該執行環境，使其在函式調用請求之前可供使用。每當環境初始化時，Lambda 都會以 JSON 日誌格式在 [platform-initReport](telemetry-schema-reference.md#platform-initReport) 日誌事件中記錄函式的[初始化持續時間欄位](lambda-runtime-environment.md#runtimes-lifecycle-ib)。若要查看此日誌事件，至少將 [JSON 日誌層級](monitoring-cloudwatchlogs-logformat.md)設定為 `INFO`。您也可以使用[遙測 API](telemetry-api-reference.md) 來取用報告初始化持續時間欄位的平台事件。
## 使用 Application Auto Scaling 自動化佈建並行管理
Application Auto Scaling 可讓您依據排程或根據使用率來管理佈建並行。如果您的函數接收到可預測的流量模式，請使用排程擴展。如果您想要讓函數維持特定的使用率百分比，請使用目標追蹤擴展政策。
**注意**
如果您使用 Application Auto Scaling 來管理函數的佈建並行，請確保先[設定初始佈建並行值](#configuring-provisioned-concurrency)。如果您的函數沒有初始佈建並行值，Application Auto Scaling 可能無法正確處理函數擴展。
### 排程擴展
Application Auto Scaling 可讓您根據可預測的負載變化來設定自己的擴展排程。如需詳細資訊和範例，請參閱 Application Auto Scaling 使用指南中的 [Application Auto Scaling 的排程擴展](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html)，以及 AWS 運算部落上的[為週期性尖峰使用量排程 AWS Lambda 佈建並行](https://aws.amazon.com/blogs/compute/scheduling-aws-lambda-provisioned-concurrency-for-recurring-peak-usage/)。
### 目標追蹤
使用目標追蹤時，Application Auto Scaling 會會根據您定義擴展政策的方式，建立並管理一組 CloudWatch 警示。這些警示啟動時，Application Auto Scaling 會自動調整使用佈建並行配置的環境數量。對沒有可預測流量模式的應用程式使用目標追蹤。
若要使用目標追蹤擴展佈建並行，請使用 `RegisterScalableTarget` 和 `PutScalingPolicy` Application Auto Scaling API 作業。例如，如果您使用 AWS 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
```
1. 將擴展政策套用至目標。以下範例會設定 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` 狀態。因此，應用程式自動擴展將無法調整函式的佈建並行。這可能導致非預期的計費。
在下列範例中，函數會根據使用率在佈建並行的最小和最大數量之間進行擴展。
![\[\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/features-scaling-provisioned-auto.png)
**圖例**
+ ![\[\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/features-scaling-provisioned.instances.png) 函數執行個體
+ ![\[\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/features-scaling-provisioned.open.png) 開啟請求
+ ![\[\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/features-scaling-provisioned.provisioned.png) 佈建並行
+ ![\[\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/features-scaling-provisioned.standard.png) 標準並行
當開啟的請求數量增加時，Application Auto Scaling 會大幅增加佈建並行，直到達到設定的最大值為止。在此之後，如果您尚未達到帳戶並行限制，則函數可以繼續按標準、未預留並行的方式擴展。當利用率下降且保持偏低時，Application Auto Scaling 會定期小幅減少佈建並行。
依預設，兩個 Application Auto Scaling 警示都會使用平均統計資料。經歷快速暴增流量的函數可能不會觸發這些警示。例如，假設您的 Lambda 函數執行速度很快 (即 20-100 毫秒)，而您的流量會快速暴增。在此情況下，請求數量將在暴增期間超過配置的佈建並行。不過，Application Auto Scaling 需要暴增負載維持至少 3 分鐘，才能佈建其他環境。或者，兩個 CloudWatch 警示都需要達到目標平均值的 3 個資料點，才能啟用自動擴展政策。如果您的函數遇到快速的流量爆增，使用**最大**統計資料而非**平均**統計資料，可以更有效地擴展佈建並行，將冷啟動降至最低。
如需目標追蹤擴展政策的詳細資訊，請參閱 [Application Auto Scaling 的目標追蹤擴展政策](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html)。
# Lambda 擴展行為
函數收到更多請求時，Lambda 會自動提高執行環境的數量來處理這些請求，直到您的帳戶達到並行配額為止。但是，為了防止因應突然爆發的流量而過度擴展，Lambda 限制了函數擴展的速度。此**並行擴展速率**是您帳戶中的函數可擴展以因應增加的請求的最高速率。(也就是說，Lambda 建立新執行環境的速度可以有多快。) 並行擴展速率與帳戶層級並行限制不同，後者是您的函數可用的並行總量。
## 並行擴展率
**在每個 AWS 區域和每個函數中，您的並行擴展速率為每 10 秒 1,000 個執行環境執行個體 (或每隔 10 秒每秒 10,000 個請求)**。換句話說，Lambda 每隔 10 秒就可以為每個函數配置最多 1,000 個額外執行環境的執行個體，或者每秒容納 10,000 個額外請求。
通常情況下，您不需要擔心此限制。對於大多數使用案例，Lambda 的擴展速率已足夠。
重要的是，並行擴展速率是函數層級限制。這意味著帳戶中的每個函數都可以獨立於其他函數進行擴展。
**注意**
實際上，Lambda 會進行最佳嘗試在一段時間內持續重新填滿並行擴展速率，而不是每 10 秒重新填滿 1,000 個單位。
Lambda 不會累積並行擴展比率的未使用部分。這意味著在任何時刻，您的擴展速率最大始終為 1,000 個並行單位。例如，如果您沒有在 10 秒的間隔內使用任何可用的 1,000 個並行單位，則不會在接下來的 10 秒間隔內額外累積 1,000 個單位。在接下來的 10 秒間隔內，您的並行擴展速率仍然是 1,000。
只要您的函數持續接收到越來越多的請求，Lambda 就會以您可用的最快速率進行擴展，最高可達您帳戶的並行限制。您可以透過[設定保留並行](configuration-concurrency.md)來限制個別函數可以使用的並行數量。當請求傳入的速度超過您函數可擴展的速度，或當您的函數達到最大並行時，額外請求會因為限流錯誤而請求失敗 (狀態碼為 429)。
# 監控並行
Lambda 會發出 Amazon CloudWatch 指標，協助您監控函數的並行。本主題將說明這些指標及其解譯方式。
**Topics**
+ [
## 一般並行指標
](#general-concurrency-metrics)
+ [
## 佈建並行指標
](#provisioned-concurrency-metrics)
+ [
## 使用 `ClaimedAccountConcurrency` 指標
](#claimed-account-concurrency)
## 一般並行指標
使用下列指標來監控 Lambda 函數的並行。每個指標的精細程度為 1 分鐘。
+ `ConcurrentExecutions` – 在指定時間點的作用中並行調用數。Lambda 會針對所有函數、版本和別名發出此指標。對於 Lambda 主控台中的任何函數，Lambda 會在**監控**索引標籤的**指標**下以原生方式顯示 `ConcurrentExecutions` 的圖表。使用 **MAX** 檢視此指標。
+ `UnreservedConcurrentExecutions` – 使用未預留並行的作用中並行調用數。Lambda 會針對區域中的所有函數發出此指標。使用 **MAX** 檢視此指標。
+ `ClaimedAccountConcurrency` – 無法用於隨需調用的並行數量。`ClaimedAccountConcurrency` 等於 `UnreservedConcurrentExecutions` 加上配置並行的數量 (亦即預留並行總數加上佈建並行總數)。如果 `ClaimedAccountConcurrency` 超過帳戶並行限制，您可以[請求提高帳戶並行上限](https://aws.amazon.com/premiumsupport/knowledge-center/lambda-concurrency-limit-increase/)。使用 **MAX** 檢視此指標。如需詳細資訊，請參閱[使用 `ClaimedAccountConcurrency` 指標](#claimed-account-concurrency)。
## 佈建並行指標
使用下列指標來監控使用佈建並行的 Lambda 函數。每個指標的精細程度為 1 分鐘。
+ `ProvisionedConcurrentExecutions` – 目前使用佈建並行處理調用的執行環境執行個體數。Lambda 會針對已設定佈建並行的每個函數版本和別名發出此指標。使用 **MAX** 檢視此指標。
`ProvisionedConcurrentExecutions` 與您配置的佈建並行總數不同。例如，假設您將 100 個佈建並行單位配置給函數版本。在任何指定的分鐘內，如果在這 100 個執行環境中最多 50 個同時處理調用，則 **MAX**(`ProvisionedConcurrentExecutions`) 的值為 50。
+ `ProvisionedConcurrencyInvocations` - Lambda 使用佈建並行調用函數程式碼的次數。Lambda 會針對已設定佈建並行的每個函數版本和別名發出此指標。使用 **SUM** 檢視此指標。
`ProvisionedConcurrencyInvocations` 與 `ProvisionedConcurrentExecutions` 不同，`ProvisionedConcurrencyInvocations` 計算調用總數，`ProvisionedConcurrentExecutions` 則計算作用中環境數。若要了解這種區別，請考慮以下案例：
![\[\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/concurrency-metrics-pc-executions-vs-invocations.png)
在此範例中，假設您每分鐘收到 1 次調用，而且每次調用都需要 2 分鐘才能完成。每個橘色水平長條代表一個請求。假設您將 10 個佈建並行單位配置給此函數，這樣每個請求都會在佈建並行上執行。
在分鐘 0 和 1 之間，收到 `Request 1`。**在分鐘 1 時**，**MAX**(`ProvisionedConcurrentExecutions`) 的值為 1，因為在過去一分鐘內最多有 1 個執行環境處於作用中狀態。**SUM**(`ProvisionedConcurrencyInvocations`) 的值也是 1，因為在過去一分鐘內收到 1 個新請求。
在分鐘 1 和 2 之間，收到 `Request 2`，且 `Request 1` 繼續執行。**在分鐘 2 時**，**MAX**(`ProvisionedConcurrentExecutions`) 的值為 2，因為在過去一分鐘內最多有 2 個執行環境處於作用中狀態。不過，**SUM**(`ProvisionedConcurrencyInvocations`) 的值為 1，因為在過去一分鐘內只收到 1 個新請求。此指標行為會一直持續到範例結束為止。
+ `ProvisionedConcurrencySpilloverInvocations` – 當所有佈建並行都在使用中時，Lambda 使用標準 (預留或未預留) 並行調用函數的次數。Lambda 會針對已設定佈建並行的每個函數版本和別名發出此指標。使用 **SUM** 檢視此指標。`ProvisionedConcurrencyInvocations` \$1 `ProvisionedConcurrencySpilloverInvocations` 的值應等於函數調用總數 (即 `Invocations` 指標)。
`ProvisionedConcurrencyUtilization` – 使用中佈建並行百分比 (即 `ProvisionedConcurrentExecutions` 的值除以配置的佈建並行總數)。Lambda 會針對已設定佈建並行的每個函數版本和別名發出此指標。使用 **MAX** 檢視此指標。
例如，假設您將 100 個佈建並行單位佈建給函數版本。在任何指定的分鐘內，如果在這 100 個執行環境中最多 60 個同時處理調用，則 **MAX**(`ProvisionedConcurrentExecutions`) 的值為 60，**MAX**(`ProvisionedConcurrencyUtilization`) 的值為 0.6。
`ProvisionedConcurrencySpilloverInvocations` 的值偏高可能表示您需要為函數配置額外的佈建並行。或者，您可以[設定 Application Auto Scaling，以根據預先定義的閾值來處理佈建並行的自動擴展](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html#managing-provisioned-concurency)。
相反地，`ProvisionedConcurrencyUtilization` 的值持續偏低可能表示您為函數配置過多佈建並行。
## 使用 `ClaimedAccountConcurrency` 指標
Lambda 會使用 `ClaimedAccountConcurrency` 指標來判斷您的帳戶可用於隨需調用的並行數量。Lambda 會使用以下公式計算 `ClaimedAccountConcurrency`：
```
ClaimedAccountConcurrency = UnreservedConcurrentExecutions + (allocated concurrency)
```
`UnreservedConcurrentExecutions` 是使用未預留並行的作用中並行調用數目。配置的並行是下列兩個部分的總和 (以「預留並行」取代 `RC`，以「佈建並行」取代 `PC`)：
+ 區域中所有函數的 `RC` 總數。
+ 區域中使用 `PC` 的所有函數的 `PC` 總數，使用 `RC` 的函數除外。
**注意**
您不能為一個函數配置多於 `RC` 的 `PC`。因此，一個函數的 `RC` 總是大於或等於它的 `PC`。對於同時具有 `PC` 和 `RC` 的函數，Lambda 在計算這些函數的配置並行比重時僅考慮 `RC`，即兩者當中的較大值。
Lambda 會使用 `ClaimedAccountConcurrency` 指標來判斷可用於隨需調用的並行數量，而不使用 `ConcurrentExecutions`。雖然 `ConcurrentExecutions` 指標對於追蹤作用中並行調用的數量很有用，但並不總是反映您真正的並行可用性。這是因為 Lambda 也會考慮預留並行和佈建並行來確定可用性。
為了說明 `ClaimedAccountConcurrency`，請考慮一種情況，即您可以跨函數設定大量預留並行和佈建並行，但其中有很多未被使用。在下列範例中，假設您的帳戶並行限制為 1,000，而您的帳戶中有兩種主要的函數：`function-orange` 和 `function-blue`。您為 `function-orange` 配置 600 個單位的預留並行。您為 `function-blue` 配置 200 個單位的佈建並行。假設隨著時間推移，您要部署額外的函數並觀測以下流量模式：
![\[\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/claimed-account-concurrency.png)
在上一張圖表中，黑線表示隨時間推移的實際並行使用，紅線表示隨時間推移的 `ClaimedAccountConcurrency` 值。在這種情況下，儘管函數的實際並行利用率較低，但 `ClaimedAccountConcurrency` 始終至少為 800。這是因為您為 `function-orange` 和 `function-blue` 配置了 800 個單位總數的並行。從 Lambda 的角度來看，您已經「聲明」這些並行供使用，因此對於其他函數，您實際上只剩下 200 個單位的並行。
針對這個情況，在 `ClaimedAccountConcurrency` 公式中配置的並行是 800。然後，我們可以在圖表的不同點衍生 `ClaimedAccountConcurrency` 值。
+ 在 `t1`，`ClaimedAccountConcurrency` 為 800 (800 \$1 0 `UnreservedConcurrentExecutions`)。
+ 在 `t2`，`ClaimedAccountConcurrency` 為 900 (800 \$1 100 `UnreservedConcurrentExecutions`)。
+ 在 `t3`，`ClaimedAccountConcurrency` 還是 900 (800 \$1 100 `UnreservedConcurrentExecutions`)。
### 在 CloudWatch 中設定 `ClaimedAccountConcurrency` 指標
Lambda 會在 CloudWatch 中發出 `ClaimedAccountConcurrency` 指標。使用此指標和 `SERVICE_QUOTA(ConcurrentExecutions)` 的值取得有關您的帳戶的並行利用率百分比，如下方公式所示：
```
Utilization = (ClaimedAccountConcurrency/SERVICE_QUOTA(ConcurrentExecutions)) * 100%
```
下列螢幕截取畫面說明如何在 CloudWatch 中繪製此公式的圖形。綠色 `claim_utilization` 線代表此帳戶中的並行利用率，約為 40％：
![\[\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/claimed-account-concurrency-cloudwatch-graph.png)
先前的螢幕截取畫面還包含 CloudWatch 警示，該警示會在並行利用率超過 70% 時進入 `ALARM` 狀態。您可以使用 `ClaimedAccountConcurrency` 指標和類似的警示來主動確定您何時可能需要請求更高的帳戶並行上限。