# Lambda が Kafka をキューのように消費！パーティション数の壁を越えたよ

みんな、しぃちゃんだよ！Lambda と Kafka の組み合わせに、並列度の悩みを解決する新機能が来たよ！

## なにが発表されたの？

AWS の「AWS What's New」で、AWS Lambda がセルフマネージド Kafka のイベントソースマッピング（ESM）で、**Apache Kafka 用のキュー**に対応したと発表されたよ。自分で運用する Kafka クラスターでも、Confluent Cloud のようなマネージドサービスでも使えるの。

## 今までどうだったの？

これまでの Kafka ESM は、Kafka のコンシューマーグループのプロトコルを使っていたよ。このプロトコルは、1 つのパーティションをコンシューマーグループ内のちょうど 1 つのコンシューマーに割り当てるの。

だから並列度を上げたいときは、トピックのパーティションを増やしすぎる（オーバーパーティション）か、別のキューシステムにトラフィックを移す必要があったよ。運用するインフラも、プロデューサー側のコードも増えてしまうんだね。

## これで何が変わるの？

キューモードなら、処理をトピックのパーティション数を超えてスケールできるよ。トラフィックのスパイク時にスループットが上がって、処理も壊れにくくなるの。遅いイベントや失敗したイベントが、他のイベントをブロックしないからね。

プロデューサー、トピックの設定、関数コードの変更は要らないよ。

向いているのは、各イベントが独立した作業単位で、厳密な順序より処理速度が大事なワークロードだよ。原文に挙がっていた例はこちら。

- 画像・動画のエンコード
- 不正検知
- 通知の配信
- テレメトリの取り込み

## 深く潜ってみよう

仕組みと注意点をまとめるよ。

- 土台は Kafka share groups で、Apache Kafka 4.2 で一般提供されている
- 複数のイベントポーラーが、同じパーティションから同時に消費できる
- 各イベントポーラーは、最大 10 の同時呼び出しをサポートする
- **パーティション内の順序は保たれない**ので、順序に依存するワークロードには向かない
- Kafka クラスター側で share groups が有効になっている必要がある（Apache Kafka 4.2 以降など）

有効化は、セルフマネージド Kafka の ESM を作るときに ConsumptionMode を Queue にするだけだよ。AWS マネジメントコンソール、Lambda API、AWS CLI、AWS CloudFormation、AWS SAM、AWS CDK から設定できるの。

料金は標準の Lambda 料金で、セルフマネージド Kafka ESM でプロビジョンドモードを使う場合は、Event Poller Unit（EPU）の使用料も加わるよ。セルフマネージド Kafka ESM が使えるすべての商用 AWS リージョンで利用できるの。

## まとめ

- セルフマネージド Kafka ESM がキューモードに対応（Kafka share groups ベース）
- パーティション数に縛られずに並列処理できる
- 各ポーラーは最大 10 の同時呼び出し
- 順序は保証されないので、順序不問のワークロード向け
- ConsumptionMode を Queue にして有効化する

Kafka のオーバーパーティションに悩んでいた人や、イベント駆動の処理を速くしたい人に刺さるよ！