Kafka プロデューサの acks=0 / 1 / all を使い分ける: 耐久性とレイテンシの実務設計

Kafka のプロデューサ設定 acks は、書き込みの耐久性とレイテンシのトレードオフを直接左右します。単に速い/遅いではなく、ISR と min.insync.replicas（MinISR）の関係を踏まえて選ぶ必要があります。

本稿は CCDAK（Confluent Certified Developer for Apache Kafka）で問われやすい公式挙動に寄せ、実務の判断軸として使える具体策に落とし込みます。バージョン差異に敏感な部分は注意書きで保守的に扱います。

acks の基礎と ISR/MinISR の関係

acks はプロデューサが送信後にどの段階の確認応答（ACK）を待つかを指定します。acks=0 は待たない、acks=1 はリーダーのみ、acks=all（= -1）は ISR（In-Sync Replicas）全員の ACK を待ちます。ISR はリーダーと最新のフォロワー集合で、割り当てレプリカ全員ではありません。

min.insync.replicas（MinISR）は acks=all のときに意味を持ち、成功とみなすために必要な ISR の最小人数をサーバ側で定義します。たとえばレプリケーション係数 3、MinISR=2 のトピックに acks=all で書くと、ISR が 2 以上なら成功、1 しかいなければ NotEnoughReplicas 系のエラーで失敗します。これは耐久性の下限を担保する代わりに、一部障害時は書き込み不可となる可能性があります。

• acks=0: 最短レイテンシ。ブローカー未到達やリーダー障害でもエラーは返らない。データロス許容の用途向け。
• acks=1: リーダーに届けば成功。リーダー故障直後の狭い窓でロスが起き得るが、一般にレイテンシは低い。
• acks=all: ISR の遅いノードまで待つためレイテンシは増え得るが、MinISR と組み合わせて耐久性下限を定義できる。

acks と複製の応答フロー（概念図）

Producer --> Leader P
              |
              v
followers: F1, F2

acks=0:   P -send-> L   (即返答)  [F1/F2待ちなし]
acks=1:   P -send-> L -ACK-> P    [F1/F2の複製は非同期]
acks=all: P -send-> L -> F1/F2
                         ^   ^
                         |   |
                     ACK(F1,F2 in ISR)
                         \   /
                          --> L -ACK-> P

主要設定の関連（概念メモ）

プロデューサ側: acks, retries, delivery.timeout.ms, request.timeout.ms, enable.idempotence
ブローカー/トピック側: replication.factor, min.insync.replicas, unclean.leader.election.enable
注意: acks=all は ISR 全員の ACK。MinISR を満たせないとプロデューサはエラー（NotEnoughReplicas など）。

acks=0: 最短レイテンシだが無保証

acks=0 は送信直後に成功とみなすため、ネットワーク往復遅延がほぼ乗りません。ブローカー未到達やバッチ破棄が起きても検知できない点が本質的なリスクです。retries を増やしてもエラーが返らないので効果は限定的です。

用途としては、ロス許容のテレメトリや一時的なクリックストリームなどに絞るのが無難です。後段の集計が冪等・推定可能で、喪失に耐える設計であることを確認しましょう。

• メリット: 往復遅延ゼロに近い、最大スループット
• デメリット: ロス検知不可、再送や順序保証の意味が薄い
• 避ける場面: 金融取引、注文、監査証跡などの重要イベント

acks=0 の最短経路

Producer -> Leader (即成功返却)
           (フォロワー複製は結果に影響しない)

失敗: ネットワーク断/リーダーダウンでも Producer は未検知

プロデューサ設定例 (acks=0)

props.put("acks", "0");
props.put("linger.ms", 0);
props.put("batch.size", 131072);
props.put("retries", 0); // 効果は限定的
// ロス許容の用途に限定して使用

acks=1: リーダー確認まで待つバランス型

acks=1 はリーダーが受領しログに追記した時点で ACK を返します。フォロワーへの複製は非同期のため、リーダー故障直後の狭い時間窓で未複製データが失われる可能性があります。多くの業務では十分なバランスですが、厳格な耐久性要件には届きません。

レイテンシは acks=all より低く出やすく、可用性も高い一方で、失敗窓を縮めるにはフォロワーの複製を速くする（ネットワーク/ストレージ健全性、適切な負荷）ことが前提です。

• メリット: 低レイテンシ、広い可用性、エラーは検知可能
• デメリット: リーダー故障直後のデータロス窓が残る
• 補強策: 再送(retries)、delivery.timeout.ms の調整、監視でレプリケーション遅延を抑制

acks=1 の失敗窓（概念タイムライン）

t0: send -> Leader append -> ACK to Producer
     |<--- 未複製ウィンドウ --->|
フォロワー追従完了 t1

故障が [t0, t1) に発生: 未複製データは失われ得る

安全側の併用設定例

props.put("acks", "1");
props.put("retries", Integer.MAX_VALUE);
props.put("delivery.timeout.ms", 120000);
props.put("request.timeout.ms", 30000);
// 再送中の順序性はクライアント/バージョンに依存。必要なら max.in.flight を下げるなどで制御

acks=all(= -1): MinISR と組み合わせた耐久性の確立

acks=all は ISR 全員の ACK を待ちます。これにより最も遅い ISR にレイテンシが引っ張られますが、MinISR と組み合わせることで「少なくとも N 台に複製されなければ失敗」という耐久性下限を強制できます。

ISR が MinISR を下回る場合、プロデューサは書き込みに失敗し、例えば NotEnoughReplicas または NotEnoughReplicasAfterAppend といったエラーが返り得ます。これは可用性低下を許容してデータロスを避ける設計です。

• 重要イベントやトランザクションでは acks=all が基本線
• MinISR は replication.factor より小さい必要がある（例: RF=3 なら MinISR=2 が一般的）
• 障害時の一時的な書き込み不可を運用で許容できるかを事前に合意

acks=all と ISR/MinISR

RF=3, MinISR=2
ISR={Leader, F1, F2}

ケースA: ISR=3 -> L<=F1, F2 両方ACK -> L ACK -> P (成功)
ケースB: ISR=2 -> L<=F1のみACK -> L ACK -> P (成功)
ケースC: ISR=1 -> フォロワーACK不足 -> エラー返却

トピックとクライアントの両面設定

# トピックで MinISR を設定
kafka-topics --alter --topic critical-events \
  --config min.insync.replicas=2 --bootstrap-server <broker>

# プロデューサ（例）
props.put("acks", "all");
props.put("retries", Integer.MAX_VALUE);
props.put("delivery.timeout.ms", 120000);
props.put("enable.idempotence", true);  // 厳密な重複排除が必要な場合
# 注意: 具体的なデフォルト値はクライアント/バージョンで異なるため、利用バージョンの公式ドキュメントを確認

レイテンシに効く周辺設定と監視

acks に加えて、linger.ms と batch.size は送信側の待ち時間とバッチ化を制御します。小さなメッセージ多数では linger を適度に上げてバッチ化し、ネットワーク/システムコールのオーバーヘッドを amortize するのが実務上有効です。

delivery.timeout.ms は全体のリトライ予算、request.timeout.ms は 1 リクエストの待ち時間です。圧縮（compression.type）や適切なパーティション数もレイテンシ/スループットに効きます。メトリクスではプロデューサ側の request-latency、ブローカー側の replica.lag を必ず可視化して、acks 選定の妥当性を継続検証します。

• 小さなメッセージ多数: linger.ms を 5–20ms 程度で検討
• 大きなメッセージ少数: linger は 0 に近く、batch.size は大きめ
• ネットワーク遅延が支配的: 圧縮有効化、バッチ化で往復回数削減
• レプリカ遅延が顕著: acks=all はレイテンシ増。原因（I/O 遅延、GC、スローブローカー）を先に解消

レイテンシ分解のイメージ

送信待ち(linger) |-> 送信/待機(RTT×往復) |-> ブローカー処理 |-> フォロワー複製(acks依存)
               |----------------- クライアント側 ------------------| |------ サーバ側 ------|

遅延の予算化（ラフな見積もり）

# 例: RTT=5ms, linger=10ms, ブローカー処理=2ms, フォロワー複製=8ms
# acks=0:  ~ linger(10) + 送信(OS/キュー) ≈ 10–12ms
# acks=1:  linger(10) + RTT(5) + 処理(2) ≈ 17ms
# acks=all: linger(10) + RTT(5) + 処理(2) + 複製(8) ≈ 25ms
# 実際はバッチ化・負荷・GC・I/O で変動。メトリクスで補正すること

CCDAK 試験観点と実務チェックリスト

CCDAK では acks と MinISR、ISR の関係、障害時の結果、そして idempotent producer やトランザクションとの組み合わせを問う出題が定番です。特に「acks=all は ISR 全員であり、割り当て全レプリカではない」「MinISR 未満だと書き込みが失敗する」点の理解が重要です。

実務では、unclean.leader.election.enable を無効にしてデータロスを避ける方針が一般的です。設定のデフォルトや厳密な振る舞いはバージョン依存のため、運用環境の公式ドキュメントで最終確認してください。

• 要件が「ロス不可」なら acks=all と MinISR≥2（RF≥3）をセットで検討
• 「停止中も書けること」が最重要なら acks=1 を検討し、失敗窓を監視で最小化
• idempotence/transactions を使う場合、acks=all が前提（クライアントが自動調整する実装もある）
• 障害時の期待動作（失敗で良いか、遅延で良いか）を関係者と合意

acks 選定の簡易ディシジョン

ロス許容? --yes--> acks=0
    |
    no
    v
停止中も可用性優先? --yes--> acks=1
                        |
                        no
                        v
                        acks=all (+ MinISR 設定)

設定テンプレート（プロファイル別）

# Durable（ロス不可）
acks=all
retries=Integer.MAX_VALUE
delivery.timeout.ms=120000
enable.idempotence=true  # 必要に応じて transactions も

# Balanced（一般業務）
acks=1
retries=Integer.MAX_VALUE
delivery.timeout.ms=120000

# Ultra-low-latency（ロス許容）
acks=0
linger.ms=0
batch.size=131072

問題で確認

よくある質問