# Lambda での Apache Kafka イベントポーラーのスケーリングモード
<a name="kafka-scaling-modes"></a>

Amazon MSK およびセルフマネージド Apache Kafka イベントソースマッピングのイベントポーラースケーリングについて、2 つのモードのいずれかを選択できます。
+ [オンデマンドモード (デフォルト)](#kafka-default-mode)
+ [プロビジョニングモード](#kafka-provisioned-mode)

## オンデマンドモード (デフォルト)
<a name="kafka-default-mode"></a>

初めて Kafka イベントソースを作成すると、Lambda は Kafka トピック内のすべてのパーティションを処理するために、デフォルトの数のイベントポーラーを割り当てます。Lambda は、メッセージ負荷に基づいて[イベントポーラー](invocation-eventsourcemapping.md#invocation-eventsourcemapping-provisioned-mode)の数を自動的にスケールアップまたはスケールダウンします。

Lambda は、1 分間隔でトピック内のすべてのパーティションのオフセットラグを評価します。オフセットラグが大きすぎる場合、パーティションは Lambda で処理できる速度よりも速くメッセージを受信します。必要に応じて、Lambda はトピックのイベントポーラーを追加または削除します。イベントポーラーを追加または削除するこの自動スケーリングプロセスは、評価から 3 分以内に実行されます。

ターゲットの 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 です。イベントポーラーの最大数 (`MaximumPollers`) の許容値の範囲は 1～2,000 です。`MaximumPollers` は `MinimumPollers` 以上である必要があります。また、パーティション内での順序付き処理を維持するために、Lambda は `MaximumPollers` をトピック内のパーティション数に制限します。

イベントポーラーの最小数および最大数に適切な値を選択する方の詳細については、「[ベストプラクティス](#kafka-provisioned-mode-bp)」を参照してください。

Kafka イベントソースマッピングのプロビジョンドモードを設定するには、コンソールまたは Lambda API を使用できます。

**既存のイベントソースマッピングに対してプロビジョンドモードを設定する手順 (コンソール)**

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>

イベントソースマッピングの最小および最大イベントポーラー数の最適な設定は、アプリケーションのパフォーマンス要件によって異なります。パフォーマンスプロファイルのベースラインを確立する際には、最初はデフォルトの最小イベントポーラー数から始めることをお勧めします。観測されたメッセージ処理パターンと望ましいパフォーマンスプロファイルに基づいて設定を調整します。

トラフィックの急増が発生しやすく、厳格なパフォーマンス要件があるワークロードの場合、メッセージの突然の急増を処理できるように、最小イベントポーラーを増やします。必要な最小イベントポーラー数を決定するには、ワークロードの 1 秒あたりのメッセージ数と平均ペイロードサイズを考慮し、1 つのイベントポーラーのスループットキャパシティ (最大 5 MBps) を参考にします。

パーティション内での順序付き処理を維持するために、Lambda は最大イベントポーラー数をトピック内のパーティション数に制限します。さらに、イベントソースマッピングがスケーリングできる最大イベントポーラー数は、関数の同時実行設定によって異なります。

プロビジョンドモードを有効にする際には、ネットワーク設定を更新して AWS PrivateLink VPC エンドポイントと関連するアクセス許可を削除します。

## プロビジョンドモードのコスト最適化
<a name="kafka-cost-optimization"></a>

### プロビジョンドモードの料金
<a name="kafka-provisioned-pricing"></a>

プロビジョンドモードは、プロビジョニングされた最小イベントポーラーと、自動スケーリング中に消費されたイベントポーラーに基づいて課金されます。料金は、Event Poller Unit (EPU) と呼ばれる請求単位を使用して計算されます。Event-Poller-Unit-hours で測定される、使用された EPU の数と期間に対して料金が発生します。プロビジョンドモードは、パフォーマンス重視のアプリケーション用に 1 つの ESM で使用することも、同じ VPC 内で複数の ESM をグループ化して EPU の容量とコストを共有することもできます。プロビジョンドモードのコストを最適化するのに役立つ 2 つの機能について詳しく説明します。料金の詳細については、「[AWS Lamdba の料金](https://aws.amazon.com/lambda/pricing/)」を参照してください。

### EPU 使用率の向上
<a name="kafka-enhanced-epu-utilization"></a>

各 EPU は、イベントポーリング用に最大 20 MB/秒のスループットキャパシティをサポートし、デフォルトの 10 個のイベントポーラーをサポートします。最小ポーラーと最大ポーラーを設定して Kafka ESM のプロビジョンドモードを作成すると、デフォルトで EPU あたり 10 個のイベントポーラーに基づき、最小ポーラー数を使用して EPU をプロビジョニングします。ただし、各イベントポーラーは、最大 5 MB/秒のスループット容量をサポートするように個別にスケーリングできます。特定の EPU でイベントポーラーの密度を低くする必要がありますが、EPU のスケーリングをトリガーできます。EPU に割り当てられるイベントポーラーの数は、各イベントポーラーが消費するコンピューティング容量によって異なります。EPU 使用率を高めるこのアプローチにより、さまざまなスループット要件を持つイベントポーラーは EPU 容量を効果的に活用できるようになり、すべての ESM のコスト削減が実現します。

### ESM のグループ化
<a name="kafka-esm-grouping-cost"></a>

プロビジョンドモードのコストをさらに最適化するには、複数の Kafka ESM をグループ化して EPU 容量を共有できます。ESM グループ化と EPU 使用率の拡張を使用すると、単一 ESM モードの実行と比較して、低スループットワークロードのプロビジョンドモードのコストを最大 90% 削減できます。1 つ未満の EPU 容量を必要とするすべての ESM は、ESM グループ化の恩恵を受けます。このような ESM では通常、スループットのニーズをサポートするために必要になる最小限のイベントポーラーはほとんどありません。この機能を使用すると、すべての Kafka ワークロードにプロビジョンドモードを採用でき、スキーマ検証、Avro/Protobuf イベントのフィルタリング、低レイテンシー呼び出し、プロビジョンドモードでしか利用できない拡張エラー処理などの機能を利用できます。

同じ Amazon VPC 内の複数の ESM に対して同じ値で `PollerGroupName` パラメータを設定すると、それらの ESM、それぞれが専用 EPU 容量を必要とするのではなく、EPU リソースを共有します。ポーラーグループごとに最大 100 ESM をグループ化でき、グループ内のすべての ESM における合計最大ポーラー数は 2,000 を超えることはできません。

#### 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. **[Poller グループ名]**には、グループの識別子を入力します。グループ化する他の ESM には同じ名前を使用します。

1. **[保存]** を選択します。

#### ESM グループを設定するには (AWS CLI)
<a name="kafka-esm-grouping-cli-cost"></a>

次の例では、`production-app-group` という名前のポーラーグループを持つ ESM を作成します。

```
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 を別のグループに移動するか、`PollerGroupName` に空の文字列 ("") を渡すことで ESM をグループから削除できます。

```
# 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>
+ **アプリケーションの境界** – コスト配分と管理の向上のために、同じアプリケーションまたはサービスに属する ESM をグループ化します。`app-name-environment` のような命名規則を使用することを検討してください (例: `order-processor-prod`)。
+ **トラフィックパターン** – リソースの競合につながる可能性があるため、高いスループットと急激なトラフィックパターンのある ESM をグループ化することは避けてください。
+ **ブラスト半径** – 共有インフラストラクチャで問題が発生した場合の影響を考慮してください。同じグループ内のすべての ESM は、共有リソースの制限の影響を受けます。ミッションクリティカルなワークロードでは、個別のグループまたは専用の ESM を使用できます。

#### コスト最適化の例
<a name="kafka-cost-optimization-example"></a>

それぞれが 1 つのイベントポーラーで設定され、スループットが 2 MB/秒未満の ESM が 10 個あるシナリオを考えてみましょう。

**グループ化なし:**
+ 各 ESM には専用の EPU が必要です
+ 必要な EPU の合計: 10
+ EPU あたりのコスト: 米国東部 (バージニア北部) では 0.185 USD/時間
+ 毎月の EPU コスト (720 時間): 10 × 720 × 0.185 USD = 1,332 USD

**グループ化の場合:**
+ 10 ESM すべてが EPU 容量を共有
+ 10 個のイベントポーラーを 1 EPU に収容 (EPU サポートごとに新しい 10 個のポーラーを使用)
+ 必要な EPU の合計: 1
+ 毎月の EPU コスト (720 時間): 1 × 720 × 0.185 USD = 133.20 USD
+ **コスト削減: 90%** (1 か月あたり 1,198.80 USD の削減)