Kafka Idempotent Producer徹底解説: enable.idempotenceと重複防止の実務とCCDAK対策

Kafkaの再送は可用性を高めますが、そのままだとブローカ再試行で重複書き込みが起こります。Idempotent Producerは、プロデューサ側だけで「同一パーティション内での重複なし」を実現する定番機能です。

本稿では、enable.idempotenceの内部動作、必須／推奨設定、障害シナリオ、運用と試験対策をまとめます。バージョン差異で揺れやすい点は慎重に表現しています。詳細はKafkaおよびConfluentの公式ドキュメントの記載に従ってください。

なぜenable.idempotenceが必要か

プロデューサはネットワーク断やリーダー交代で送信失敗を検出すると再送します。通常の再送だけでは、同一レコードが同一パーティションに二重書き込みされることがあります。これをアプリケーション側で除外するのは負担が大きく、特にキューイングや決済系では致命的です。

Idempotent Producerは、プロデューサIDとシーケンス番号により、ブローカでの重複受理を防ぎます。これにより、再送を前提としつつ、同一パーティション内での挿入を一意に保てます。CCDAKでは「必要な設定の組み合わせ」「どこまで保証できるか（範囲）」の理解が頻出です。

• 対象範囲はパーティション内。トピック全体や複数パーティション横断の一意性は対象外。
• enable.idempotenceはプロデューサ側の保証。コンシューマの重複は別問題（トランザクションやアプリ側で扱う）。
• acks=all、retries>0、max.in.flight.requests.per.connectionが制約に入る点を覚える。

内部動作: ProducerIdとシーケンス番号による重複排除

Idempotent Producerは、ブローカから割り当てられるProducerId（PID）と、パーティションごとの単調増加シーケンス番号で各レコードバッチを識別します。ブローカ（リーダー）は受信したPIDとシーケンス番号を保持し、既知の組み合わせは重複として破棄し、正しい順序のみを受け付けます。

acks=allにより、ISR全体でのレプリカ反映を待ってから成功応答するため、ネットワーク断やリーダー交代でも同一レコードの二重可視化を抑制できます。プロデューサはOutOfOrderSequenceやUnknownProducerIdなどのエラーに対して自動リカバリを行い、必要に応じてエポックを更新して再初期化します。

• ProducerId: プロデューサ起動時のハンドシェイクで割り当てられる識別子。
• シーケンス番号: パーティション単位でインクリメントされる連番。再送でも同じ番号。
• 重複排除の状態はブローカのリーダーで維持。ログ切り詰めや長期停止後のリーダー切替では再初期化が発生し得る。

Idempotent Producerの重複排除フロー（概念）

主要設定と推奨値

Idempotent Producerを有効化するには、enable.idempotence=trueが中核です。これに整合するため、acks=all、retries>0（多くの実装では実質的に大値）、max.in.flight.requests.per.connectionは制約内（一般に5以下）とする必要があります。クライアント実装により、矛盾する設定はエラーにしたり、自動的に上書き・制限する場合があります。試験では要件関係を問われやすいです。

delivery.timeout.msは全リトライの上限時間です。これを超えると送信は失敗として扱われますが、途中の再送での重複はIdempotent Producerが防ぎます。スループット最適化にはlinger.msやbatch.sizeを併用するとよいですが、遅延許容と相談してください。Confluent Cloudなどマネージド環境ではacks=allが前提のことが多く、Idempotent Producerは通常サポートされます。

注意: 既定値や自動調整の挙動はクライアントとバージョンに依存する場合があります。最新の公式ドキュメントを確認してください。

• enable.idempotence=true（必須）
• acks=all（実質必須。矛盾設定は拒否または強制調整される）
• retriesは0より大きく（実務では大値）、delivery.timeout.msと併せて制御
• max.in.flight.requests.per.connectionは5以下を推奨（順序と整合性を保つ）
• linger.ms, batch.sizeでスループット最適化。レイテンシ要件に応じて調整
• request.timeout.ms, retry.backoff.msの整合性に注意

Java Producerの最小設定例（冪等＋スループット配慮）

Properties props = new Properties();
props.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "broker:9092");
props.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
props.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());

// 冪等化の中核
props.put(ProducerConfig.ENABLE_IDEMPOTENCE_CONFIG, "true");
props.put(ProducerConfig.ACKS_CONFIG, "all");
props.put(ProducerConfig.RETRIES_CONFIG, Integer.toString(Integer.MAX_VALUE));
props.put(ProducerConfig.MAX_IN_FLIGHT_REQUESTS_PER_CONNECTION, "5"); // 順序と整合性

// スループットと安定性
props.put(ProducerConfig.LINGER_MS_CONFIG, "20");
props.put(ProducerConfig.BATCH_SIZE_CONFIG, "65536");
props.put(ProducerConfig.DELIVERY_TIMEOUT_MS_CONFIG, "120000");

KafkaProducer<String, String> producer = new KafkaProducer<>(props);
ProducerRecord<String, String> rec = new ProducerRecord<>("orders", "order-123", "payload");
producer.send(rec, (md, ex) -> {
  if (ex != null) {
    // 失敗時の補足ロギング。冪等化により重複は防がれる
    ex.printStackTrace();
  }
});
producer.flush();
producer.close();

障害シナリオとエラーの扱い

ネットワーク断、リーダー交代、ログ切り詰めなどで、プロデューサとブローカ間の状態がずれることがあります。Idempotent Producerはエポック管理とシーケンス制御で回復を試みますが、アプリ側でのリトライ設計と監視が重要です。

代表的なエラーと挙動は次の通りです。詳細な発生条件はブローカとクライアントのバージョン、設定に依存するため、運用環境に合わせてテストしてください。

• OutOfOrderSequenceException: 再送順序が前後した場合。max.in.flightを5以下にし、アプリ側の同時送信パターンを見直す。
• UnknownProducerId: ブローカ側の状態が失われた、またはログ切り詰め後など。プロデューサはエポック更新で再初期化して継続。
• NotEnoughReplicas / Timeout: acks=allでISRが不足。delivery.timeout.ms超過で失敗確定。重複は防がれるが、アプリは失敗処理が必要。
• ProducerFenced（トランザクション時）: 複数プロデューサが同一transactional.idを使用。単一アクティブ制御が働く。

運用と監視: メトリクス、チューニング、クラウド

冪等化の有効・無効は設定で明確ですが、実運用では再送率、スロットリング、レイテンシの傾向を継続監視します。プロデューサメトリクス（record-error-rate, record-retry-rate, request-latency-avg, produce-throttle-time-avg, batch-size-avg, records-per-request-avgなど）をダッシュボード化し、delivery.timeout.ms到達のエラー数と合わせて確認しましょう。

スループット最適化は、linger.msとbatch.sizeでバッチングを強化しつつ、max.in.flight<=5の制約下で並列度を確保するのが基本線です。キーの設計は重要で、同一キーを同一パーティションへ安定的にルーティングすることで、アプリケーション上の整合性も保ちやすくなります。

マネージド環境（例: Confluent Cloud）では、acks=allが前提・推奨であり、Idempotent Producerは標準的に利用可能です。クライアント側の既定値や制約は随時更新され得るため、導入時に該当環境のドキュメントを確認してください。

• 監視の第一歩: record-error-rate, record-retry-rate, request-latency-avg
• 再送と遅延の両立: linger.msとdelivery.timeout.msのバランス
• パーティションキーの安定化: 同一ビジネスキーは同一パーティションへ
• バックプレッシャー検知: produce-throttle-time-avgの上昇に注意

CCDAK対策の要点と落とし穴

試験では、Idempotent Producerの保証範囲と必須設定の組み合わせ、トランザクションとの違いが問われがちです。単なるretries増加は重複を防がないこと、acks=allの意味、max.in.flightの制約を整理しておきましょう。

また、Idempotent Producerは「書き込み側の重複防止」であり、消費側の重複読取りとは別問題です。エンドツーエンドのExactly-Onceを目指すケースでは、トランザクションやKafka StreamsのEOSモードを使うことを区別して答えられるようにします。

• enable.idempotence=trueはパーティション内の重複防止。複数パーティション横断は対象外。
• 必須組み合わせ: enable.idempotence=true, acks=all, retries>0, max.in.flight<=5。
• コンシューマ重複は別。必要に応じてread_committedやトランザクションを併用。
• max.in.flight=1は順序最重視だがスループット低下。冪等化下では5まで許容が一般的。
• delivery.timeout.ms超過時は失敗として扱う。重複は防がれるがリカバリ戦略は必要。

問題で確認

よくある質問