Kafkaに溜まった画像変換などのジョブを、Lambdaでもっと並列に処理したい。そんなとき、処理能力を増やすためにトピックのパーティション数まで変える必要があるのか、という設計上の悩みがあります。

2026年11月2日に発表されたAWS LambdaのQueue消費モードは、この結び付きを緩める選択肢です。ただし、並列処理を広げる代わりに、同じパーティション内でも処理順序を保証しなくなります。

どの仕事なら順序を外してよいのでしょうか。Share Groupsによる分担の仕組みから、再配信への備え、設定と容量の制約までたどると、Queueモードを採用できる条件が見えてきます。

Share Groupsがパーティション単位の分担を変える

従来のStreamモードでは、同じコンシューマーグループ内の各パーティションを1つのコンシューマーが担当します。例えば10パーティションなら、担当を持って同時に消費するコンシューマーは最大10個です。この排他的な割り当てが、パーティション内の順序を保つ土台になります。

QueueモードはShare Groupsを使い、同じパーティションを複数のコンシューマーで分担します。パーティション全体を占有する代わりに、取得したレコードを期限付きでロックする仕組みです。KafkaShareConsumerの仕様でも、柔軟な分担と引き換えに順序保証を失うことが明記されています。

LambdaでKafkaからレコードを取得し、関数を呼び出す役割がイベントポーラーです。Queueモードでは、このポーラーをパーティション数に縛られずに増やせます。例えば1つのパーティションに独立した画像変換ジョブが並んでいても、複数の関数呼び出しへ仕事を分けられるわけですね。

この土台となるQueues for Kafkaは、Kafka 4.2で本番利用可能になった機能です。Kafka側の消費モデルをLambdaのイベントソースマッピング（ESM）から選べるようになった、と捉えると関係が分かりやすくなります。

順序を外せる仕事でも、重複処理への備えは必要

Queueモードが合うのは、各レコードを独立した仕事として扱える場合です。別々の画像の変換なら完了順を入れ替えられても、同じ対象への状態更新を順番どおり適用する処理では、順序の変更が結果を変えます。

取得中のレコードはロックで他のコンシューマーから保護され、成功時には確認応答されます。処理中はLambdaのポーラーがロックを更新し、失敗した呼び出しのレコードは再配信の対象になります。ロックには期限があるため、処理担当が失われても別の担当へ仕事を戻せます。

ただし、ロックは業務処理の「厳密に1回」を保証するものではありません。LambdaのESMは少なくとも1回の配信を前提とするため、関数には冪等性が必要です。設計例として、変換済み画像の保存が終わってから呼び出しが失敗した場合にも、同じジョブの再処理で結果を壊さない形を考えます。

また、LambdaのMaximumRetryAttemptsだけでなく、Kafkaのgroup.share.delivery.count.limitも再配信に関わります。Kafka 4.2のブローカー設定では後者は配信試行回数の上限です。失敗先としてKafkaトピック、SQS、SNSを使う構成を含め、失敗を意図的に起こし、再配信と失敗先への到達を確かめるのがよいでしょう。

Queue用ESMでは、Kafkaの要件と読み始める位置をそろえる

対象は、Share Groupsが有効なKafka 4.2以降へ接続するSelf-managed Apache KafkaのESMです。自分で運用するクラスターだけでなく、要件を満たす外部のマネージドKafkaも対象になり得ます。一方、2026年11月3日に確認したLambda開発者ガイドでは、Amazon MSKは対象外です。

対応バージョンの下限と、運用で選ぶパッチ版も分けて考えたいところです。Kafkaのアップグレードガイドには、4.2.1でShare Group経路のデッドロックを修正した記録があります。4.2以上という条件だけで導入版を決めず、利用する系列の修正情報まで見ておきます。

Queue用のESMを作る際に指定する設定部分は次の形です。これは作成リクエスト全体ではなく、ブローカー接続先、トピック、関数、必要なネットワーク・認証設定と組み合わせる断片です。

{
  "SelfManagedKafkaEventSourceConfig": {
    "ConsumptionMode": "Queue"
  }
}

ConsumptionModeを省略すると従来のStreamになり、既存ESMが自動的にQueueへ変わることはありません。QueueではStartingPosition、StartingPositionTimestamp、MaximumBatchingWindowInSecondsを指定できないため、既存設定をそのままコピーする前にQueueモードの設定制約を反映します。

特に、読み始める位置を見落としたくありません。新しいShare Groupの開始位置を初期化するshare.auto.offset.resetは、Kafka 4.2のグループ設定では既定値がlatestです。既存の未処理データを扱いたい検証では、ESMの作成だけで過去のレコードを読み直せると考えず、グループの開始位置と既存の消費状態を合わせて設計します。

並列数の次の上限はポーラーとブローカーに移る

パーティション数との結び付きが外れても、処理能力が無制限になるわけではありません。Queueモードのオンデマンド構成は、ESM全体で最大5 MB/sまたは50同時呼び出しのうち、先に達した方が上限です。プロビジョンド構成では、1ポーラーあたり最大5 MB/s・10同時呼び出しとなり、EPU（Event Poller Unit）の利用に応じた課金が加わります。スケーリング方式の比較で、この単位の違いを押さえておきたいですね。

例えば300同時呼び出しを目標にするなら、同時実行数だけから計算した必要ポーラー数の下限は300 ÷ 10 = 30です。これは実効性能の保証ではなく、入力帯域や処理時間、接続先の受け入れ能力を検討する出発点になります。

さらに、Kafka 4.2のgroup.share.max.sizeは既定値200、設定可能な上限1,000です。Lambda側で大きなMaximumPollersを指定しても、ブローカーが参加を許さなければ増やせません。パーティションごとの処理中レコード数にもgroup.share.partition.max.record.locksという上限があるため、グループ人数とレコードロックの設定を容量計画に含めます。

採用の判断は、まず仕事を独立に処理できるかどうかです。その条件を満たすなら、順序を入れ替えたテストと再配信のテストを通し、ポーラーと接続先を段階的に増やして滞留の変化を測る、という進め方ができます。Queueモードは、Kafkaに置いた独立ジョブの処理能力を、トピックの分割設計から切り離して調整するための選択肢になります。

出典

• Title: Introducing queue consumption mode for Apache Kafka in AWS Lambda
• URL: https://aws.amazon.com/blogs/compute/introducing-queue-consumption-mode-for-apache-kafka-in-aws-lambda/