AWS Lambdaが自己管理型Kafkaにキューモードを追加：複数のポーラーが順序なしで同じパーティションを読む、Amazon MSKは未対応
AWSは2026年11月2日、Lambdaの自己管理型Kafkaイベントソースマッピングでキューモードを発表しました。Kafkaのシェアグループに基づき、複数のイベントポーラーが同じパーティションを同時に読み、各ポーラーは最大10の同時呼び出しができ、プロデューサー、トピック、関数コードの変更は不要ですが、パーティションの順序は保たれません。発表は自己管理型クラスターとConfluent Cloudのようなマネージドサービスが対象だと述べますが、デベロッパーガイドはキューモードは自己管理型Kafka専用でAmazon MSKは現在未対応、ポーラーにはKafka 4.2以降が必要と明記しています。
2026年11月2日、AWSはAWS Lambdaが自己管理型Kafkaのイベントソースマッピングで、Apache Kafkaのキューをサポートすると発表した。これまでKafkaのイベントソースマッピングは、各パーティションをグループ内のちょうど一つのコンシューマーに割り当てるKafkaのコンシューマーグループプロトコルを使っていた。並列度を上げたいチームは、トピックを過剰にパーティション分割するか、別のキューシステムにトラフィックを移すしかなく、運用するインフラと保守するプロデューサーのコードが増えた。新しいキューモードはKafkaのシェアグループに基づいており、複数のイベントポーラーが同じパーティションから同時に読み取れる。
AWSによれば、各イベントポーラーは最大10の同時呼び出しをサポートし、並列度はパーティション数に縛られなくなり、プロデューサー、トピック設定、関数コードの変更は要らない。遅いイベントや失敗したイベントが、同じパーティション内の他のイベントを止めることもなくなる。発表はその代償も率直に述べている。キューモードはパーティションの順序を保たず、順序を必要としないワークロード向けである。例として挙げられているのは、各イベントが独立した作業単位で、順序よりも速度が重要な用途で、画像や動画のエンコード、不正検知、通知配信、テレメトリの取り込みなどだ。
要件は見出しの印象より狭い。発表によれば、クラスターはシェアグループが有効でなければならず、たとえばApache Kafka 4.2以降が該当する。機能は、自己管理型Kafkaのイベントソースマッピングが使えるすべてのAWS商用リージョンで利用できる。対象は顧客が自分で運用するクラスターと、Confluent Cloudのようなマネージドサービスだとされる。Lambdaのデベロッパーガイドはさらに踏み込んでいる。シェアグループはApache Kafka 4.0で登場したが、Kafka Queue Pollerには4.2以降が必要で、キューモードは自己管理型クラスターのみが対象だという。ガイドの表現では、Amazon MSKは現在キューモードをサポートしておらず、MSKがシェアグループを有効にしたKafka 4.2以降を提供した時点で、AWSがMSKのサポートを追加する。したがって、Amazon MSKを使うチームは、この発表が自分のクラスターを含むと受け取ってはいけない。
使うには、ConsumptionModeをQueueに設定した自己管理型Kafkaのイベントソースマッピングを、コンソール、Lambda API、AWS CLI、CloudFormation、SAM、CDKのいずれかで作成する。モードを指定しなければ、既定のStreamモードになる。ガイドは両者を比較している。Streamはパーティション内の順序を保ち、ポーラーあたり最大5の同時呼び出し、Queueは順序を保証せず最大10である。比較表ではどちらもポーラーあたり最大5MB/sのスループットとされているが、キューモードのオンデマンドの節ではポーラーあたり最大1MB/s、ポーラーは最大5つで、合計5MB/s、50の同時呼び出しとされている。プロビジョンドモードでは最小・最大ポーラー数を設定でき、最小は1〜200、最大は1〜2,000で、ここではポーラーあたり最大5MB/sとされる。ページによって、モードごとに異なる上限が書かれているので、実際に動かすモードの記述を読む必要がある。
いくつかのなじみのある設定が変わる。キューモードではMaximumBatchingWindowInSecondsがサポートされず、指定すると検証エラーになる。Kafkaのシェアコンシューマーがバッチ内のすべてのレコードの明示的な確認応答を必要とするからだ。StartingPositionとStartingPositionTimestampもサポートされない。キューモードは常にシェアグループのコミット済み位置から読むためである。MaximumRetryAttemptsの既定値は0で、失敗時の送信先が設定されていなければブローカーが再試行する。最大5パターンのイベントフィルタリング、スキーマレジストリ、失敗時の送信先、イベントソースマッピングのログはサポートされる。キューのマッピングは、他のキューのマッピングとだけイベントポーラーユニットを共有する。一般的なKafkaのガイドも、マッピングは各イベントを少なくとも1回処理するので、関数コードは冪等にすべきだと警告している。
費用について、発表は標準のLambda料金が適用され、プロビジョンドモードを設定した顧客はイベントポーラーユニットの使用分も支払うと述べている。妥当な試し方は、重要でないトピックから始めることだ。クラスターのバージョンとシェアグループが有効であることを確認し、テストアカウントでキューのマッピングを作り、バーストを送って、スループット、重複、失敗レコードの扱いを測る。キューモードは順序を失わせるので、どのコンシューマーに順序が必要かを先に決める。記事にスループット向上のベンチマークはないので、高速化の主張は自分のテストから得る必要がある。
設計の観点では、この機能は、並列度をパーティション数で買う方式から、メッセージ単位で受け取る方式に置き換えるもので、キューサービスの使い方に近い。ただし、コンシューマーグループの単純な代替ではない。同じ注文や同じアカウントのイベントの前後関係に頼るパイプラインは、Streamモードのままにすべきだ。トピックごとに選ぶのがよく、順序が必要なものはStreamに残し、互いに独立したタスク型のトピックをQueueに移し、各マッピングで選んだ理由を記録しておく。
Sources
FAQ
LambdaのKafkaキューモードは何を解決しますか？
これまで各パーティションはグループ内の一つのコンシューマーにしか割り当てられず、並列度を上げるには過剰なパーティション分割か別のキューシステムが必要でした。キューモードはシェアグループを使い、複数のポーラーが同じパーティションを読み、各ポーラーは最大10の同時呼び出しができます。代償はパーティション内の順序が保たれないことです。
Amazon MSKのユーザーは使えますか？
発表は自己管理型クラスターとConfluent Cloudのようなマネージドサービスが対象だと述べますが、デベロッパーガイドは、キューモードは自己管理型Kafka専用で、Amazon MSKは現在サポートしておらず、MSKがシェアグループ有効のKafka 4.2以降を提供してからだと明記しています。MSKの利用者は現時点で使えると考えてはいけません。
頼る前にどの制限を確認すべきですか？
シェアグループ有効のKafka 4.2以降、順序要件、冪等性を確認します。キューモードにはバッチウィンドウと開始位置がなく、フィルターは最大5パターンです。MaximumRetryAttemptsパラメータの既定値は0ですが、on-failure destination未設定なら失敗レコードはKafka brokerが再試行します。既定で処理を再試行しないという意味ではありません。オンデマンドとプロビジョンドのスループット上限は使うモードで確認してください。