

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

# Lambda 中的 Apache Kafka 事件輪詢器擴展模式
<a name="kafka-scaling-modes"></a>

對於 Amazon MSK 和自我管理的 Apache Kafka 事件來源映射，可從以下兩種事件輪詢器擴展模式中任擇其一：
+ [隨需模式 (預設)](#kafka-default-mode)
+ [佈建模式](#kafka-provisioned-mode)

## 隨需模式 (預設)
<a name="kafka-default-mode"></a>

當您最初建立 Kafka 事件來源時，Lambda 會配置預設數量的事件輪詢器來處理 Kafka 主題中的所有分割區。Lambda 會根據訊息負載自動增加或減少[事件輪詢器](invocation-eventsourcemapping.md#invocation-eventsourcemapping-provisioned-mode)數量。

每 1 分鐘，Lambda 會評估主題中所有分割區的偏移延遲。如果偏移延遲太高，則表示分割區接收訊息的速度比 Lambda 處理訊息的速度更快。如有必要，Lambda 會新增或移除主題的事件輪詢器。此新增或移除事件輪詢器的自動擴展程序會在評估後三分鐘內發生。

如果您的目標 Lambda 函數遭限流，則 Lambda 會減少事件輪詢器的數量。此動作可透過減少事件輪詢器可擷取和傳送至函數的訊息數量，減少函數的工作負載。

## 佈建模式
<a name="kafka-provisioned-mode"></a>

對於您需要微調事件來源映射輸送量的工作負載，可以使用佈建模式。在佈建模式中，可以定義佈建的事件輪詢器數量的下限和上限。這些佈建的事件輪詢器專用於您的事件來源映射，並且可以透過回應性自動擴展處理意外的訊息尖峰。我們建議您針對效能需求嚴格的 Kafka 工作負載使用佈建模式。

在 Lambda 中，事件輪詢器是具有不同事件來源類型之輸送量功能的運算單位。對於 Amazon MSK 和自我管理的 Apache Kafka，每個事件輪詢器最多可以處理 5 MB/秒的輸送量或最多 5 個並行調用。例如，如果您的事件來源產生平均承載 1 MB，且函數的平均持續時間為 1 秒，則單一 Kafka 事件輪詢器可以支援 5 MB/秒輸送量和 5 個並行 Lambda 調用 （假設沒有承載轉換）。對於 Amazon SQS，每個事件輪詢器最多可以處理每秒 1 MB 的輸送量或最多 10 個並行調用。使用佈建模式會根據您的事件輪詢器用量產生額外費用。如需定價詳細資訊，請參閱 [AWS Lambda 定價](https://aws.amazon.com/lambda/pricing/)。

**注意**  
使用佈建模式時，您不需要建立 AWS PrivateLink VPC 端點，也不需要在網路組態中授予相關聯的許可。

在佈建模式中，事件輪詢器數目下限 (`MinimumPollers`) 的接受值範圍介於 1 到 200 之間，包括 1 和 200 在內。事件輪詢器數目上限 (`MaximumPollers`) 的接受值範圍介於 1 到 2,000 之間，包括 1 和 2,000 在內。`MaximumPollers` 必須大於或等於 `MinimumPollers`。此外，為了在分割區內維持有序處理，Lambda 將 `MaximumPollers` 限制為不超過主題中的分割區數量。

如需選擇適當的事件輪詢器數量下限值和上限值的詳細資訊，請參閱[最佳實務](#kafka-provisioned-mode-bp)。

您可以使用主控台或 Lambda API，為 Kafka 事件來源映射設定佈建模式。

**為現有事件來源映射設定佈建模式 (主控台)**

1. 開啟 Lambda 主控台中的[函數頁面](https://console.aws.amazon.com/lambda/home#/functions)。

1. 選擇具有要設定佈建模式之事件來源映射的函式。

1. 選擇**組態**，然後選擇**觸發條件**。

1. 選擇要設定佈建模式的事件來源映射，然後選擇**編輯**。

1. 在**佈建模式**欄位中，選取**設定**。
   + 針對**事件輪詢器下限**，輸入介於 1 到 200 之間的值。如果您沒有指定值，則 Lambda 會選擇預設值 1。
   + 針對**事件輪詢器上限**，輸入介於 1 到 2,000 之間的值。此值必須大於或等於**事件輪詢器下限**值。如果您沒有指定值，則 Lambda 會選擇預設值 200。

1. 選擇**儲存**。

您可以使用 [EventSourceMappingConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_EventSourceMappingConfiguration.html) 中的 [ProvisionedPollerConfig](https://docs.aws.amazon.com/lambda/latest/api/API_ProvisionedPollerConfig.html) 物件，以程式設計方式設定佈建模式。例如，下列 [UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html) CLI 命令會將 `MinimumPollers` 值設定為 5，將 `MaximumPollers` 值設定為 100。

```
aws lambda update-event-source-mapping \
    --uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
    --provisioned-poller-config '{"MinimumPollers": 5, "MaximumPollers": 100}'
```

設定佈建模式後，可以透過監控 `ProvisionedPollers` 指標來觀察工作負載的事件輪詢器使用情況。如需詳細資訊，請參閱[事件來源映射指標](monitoring-metrics-types.md#event-source-mapping-metrics)。

若要停用佈建模式並返回預設 (隨需) 模式，您可以使用下列 [UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html) CLI 命令：

```
aws lambda update-event-source-mapping \
    --uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
    --provisioned-poller-config '{}'
```

## 進階錯誤處理和效能功能
<a name="services-kafka-advanced-features"></a>

對於已啟用佈建模式的 Kafka 事件來源映射，您可以設定其他功能來改善錯誤處理和效能：
+ [重試組態](kafka-retry-configurations.md) – 控制 Lambda 如何處理失敗的記錄，以及重試次數上限、記錄存留期限制、批次分割和部分批次回應。
+ [Kafka 失敗的目的地](kafka-on-failure-destination.md) – 將失敗的記錄傳送至 Kafka 主題，以供日後處理或分析。

## 使用佈建模式時的最佳實務和考量
<a name="kafka-provisioned-mode-bp"></a>

事件來源映射的事件輪詢器上限和下限的最佳組態取決於應用程式的效能需求。我們建議您從預設的事件輪詢器下限開始，以基準化效能設定檔。根據觀察到的訊息處理模式和所需的效能設定檔來調整您的組態。

對於具有尖峰流量和嚴格效能需求的工作負載，請增加事件輪詢器下限，以處理訊息的突然激增。若要判斷所需的事件輪詢器下限，請考慮工作負載的每秒訊息數和平均承載大小，並使用單一事件輪詢器的輸送容量 (至多 5 MBps) 做為參考。

為了在分割區內維持有序處理，Lambda 將事件輪詢器的上限限制為主題中的分割區數量。此外，事件來源映射可以擴展到的事件輪詢器上限取決於函數的並行設定。

啟用佈建模式時，請更新您的網路設定以移除 AWS PrivateLink VPC 端點和相關聯的許可。

## 佈建模式的成本最佳化
<a name="kafka-cost-optimization"></a>

### 佈建模式定價
<a name="kafka-provisioned-pricing"></a>

佈建模式會根據佈建的最低事件輪詢器，以及在自動擴展期間使用的事件輪詢器來收費。使用稱為事件輪詢單位 (EPU) 的計費單位來計算費用。您支付使用的 EPUs數量和持續時間，以 Event-Poller-Unit-hours 為單位。您可以將佈建模式與效能敏感應用程式的單一 ESM 搭配使用，也可以將相同 VPC 中的多個 ESMs 分組，以共用 EPU 容量和成本。我們將深入了解可協助您最佳化佈建模式成本的兩項功能。如需定價詳細資訊，請參閱 [AWS Lambda 定價](https://aws.amazon.com/lambda/pricing/)。

### 增強的 EPU 使用率
<a name="kafka-enhanced-epu-utilization"></a>

每個 EPU 最多支援 20 MB/s 的事件輪詢輸送量容量，並支援預設 10 個事件輪詢器。當您透過設定最低和最高輪詢器為 Kafka ESM 建立佈建模式時，它會根據每個 EPUs 的預設 10 個事件輪詢器，使用最低輪詢器編號來佈建 EPU。不過，每個事件輪詢器可以獨立擴展，以支援高達 5 MB/s 的輸送量容量，這可能需要特定 EPU 上較低的事件輪詢器密度，並且可以觸發 EPUs 的擴展。EPU 上配置的事件輪詢器數量取決於每個事件輪詢器耗用的運算容量。這種增強型 EPU 使用率的方法可讓具有不同輸送量需求的事件輪詢器有效地利用 EPU 容量，從而降低所有 ESMs 的成本。

### ESM 分組
<a name="kafka-esm-grouping-cost"></a>

若要進一步最佳化佈建模式成本，您可以將多個 Kafka ESMs 分組以共用 EPU 容量。透過 ESM 分組和增強的 EPU 使用率，相較於在單一 ESM 模式下執行，您可以降低低輸送量工作負載的佈建模式成本高達 90%。所有需要少於 1 個 EPU 容量ESMs ESM 都將受益於 ESM 分組。這類 ESMs通常只需要幾個最低事件輪詢器，即可支援其輸送量需求。此功能可讓您針對所有 Kafka 工作負載採用佈建模式，並受益於結構描述驗證、Avro/Protobuf 事件篩選、低延遲調用和僅在佈建模式下可用的增強型錯誤處理等功能。

當您為相同 Amazon VPC 中的多個 ESMs 設定具有相同值的`PollerGroupName`參數時，這些 ESMs 會共用 EPU 資源，而不是每個需要專用 EPU 容量。每個輪詢器群組最多可以分組 100 ESMs，且群組中所有 ESMs 的彙總輪詢器上限不能超過 2000 個。

#### 設定 ESM 分組 （主控台）
<a name="kafka-esm-grouping-console-cost"></a>

1. 開啟 Lambda 主控台中的[函數頁面](https://console.aws.amazon.com/lambda/home#/functions)。

1. 選擇函數。

1. 選擇**組態**，然後**觸發條件**。

1. 建立新的 Kafka 事件來源映射或編輯現有的事件來源映射時，請選取**佈建模式下****的設定**。

1. 針對**事件輪詢器下限**，輸入介於 1 到 200 之間的值。

1. 針對**事件輪詢器上限**，輸入介於 1 到 2,000 之間的值。

1. 針對**輪詢器群組名稱**，輸入群組的識別符。針對您要分組的其他 ESMs 使用相同的名稱。

1. 選擇**儲存**。

#### 設定 ESM 分組 (AWS CLI)
<a name="kafka-esm-grouping-cli-cost"></a>

下列範例會使用名為 的輪詢器群組建立 ESM`production-app-group`：

```
aws lambda create-event-source-mapping \
  --function-name myFunction1 \
  --event-source-arn arn:aws:kafka:us-east-1:123456789012:cluster/MyCluster/abcd1234 \
  --topics topic1 \
  --starting-position LATEST \
  --provisioned-poller-config '{
    "MinimumPollers": 1, 
    "MaximumPollers": 10, 
    "PollerGroupName": "production-app-group"
  }'
```

若要將另一個 ESM 新增至相同的群組 （共用 EPU 容量），請使用相同的 PollerGroupName：

```
aws lambda create-event-source-mapping \
  --function-name myFunction2 \
  --event-source-arn arn:aws:kafka:us-east-1:123456789012:cluster/MyCluster/abcd1234 \
  --topics topic2 \
  --starting-position LATEST \
  --provisioned-poller-config '{
    "MinimumPollers": 1, 
    "MaximumPollers": 10, 
    "PollerGroupName": "production-app-group"
  }'
```

**注意**  
您可以更新 `PollerGroupName`，將 ESM 移至不同的群組，或傳遞 的空字串 ("")，從群組中移除 ESM`PollerGroupName`：

```
# Move ESM to a different group
aws lambda update-event-source-mapping \
  --uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
  --provisioned-poller-config '{
    "MinimumPollers": 1, 
    "MaximumPollers": 10, 
    "PollerGroupName": "new-group-name"
  }'

# Remove ESM from group (use dedicated resources)
aws lambda update-event-source-mapping \
  --uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
  --provisioned-poller-config '{
    "MinimumPollers": 1, 
    "MaximumPollers": 10, 
    "PollerGroupName": ""
  }'
```

#### 分組策略考量事項
<a name="kafka-grouping-strategy-considerations"></a>
+ **應用程式界限** – 屬於相同應用程式或服務的群組 ESMs，以實現更好的成本分配和管理。考慮使用命名慣例，例如 `app-name-environment`（例如 `order-processor-prod`)。
+ **流量模式** – 避免將具有高輸送量和尖峰流量模式ESMs 分組，因為這可能會導致資源爭用。
+ **爆量半徑** – 如果共用基礎設施遇到問題，請考慮影響。相同群組中的所有 ESMs都會受到共用資源限制的影響。對於關鍵任務工作負載，您可能想要使用不同的群組或專用 ESMs。

#### 成本最佳化範例
<a name="kafka-cost-optimization-example"></a>

假設您擁有 10 ESMs，每個 ESM 設定了 1 個事件輪詢器，輸送量低於 2 MB/s：

**沒有分組：**
+ 每個 ESM 都需要自己的 EPU
+ 所需的 EPUs 總數：10
+ 每個 EPU 的成本：美國東部 （維吉尼亞北部） 每小時 0.185 美元
+ 每月 EPU 成本 (720 小時）：10 × 720 × $0.185 = $1，332

**使用分組：**
+ 所有 10 ESMs 共用 EPU 容量
+ 10 個事件輪詢器適合 1 個 EPU （每個 EPU 支援有新的 10 個輪詢器）
+ 所需的 EPUs 總數：1
+ 每月 EPU 成本 (720 小時）：1 × 720 × $0.185 = $133.20
+ **節省成本：90% **（每月節省 1，198.80 美元）