Kafka min.insync.replicasを実務と試験で押さえる: 耐久性と可用性のバランス設計

min.insync.replicasは、ISR(In-Sync Replica)に属するレプリカのうち、書き込み成功に最低限必要な台数を定義する設定です。acks=allと組み合わせることで、実効的な耐久性をコントロールします。

この記事では、公式ドキュメントの挙動に基づいてトレードオフを定量化し、障害時の具体的なふるまいと運用ベストプラクティスを整理します。CCAAKで頻出の論点も明示します。

基本概念: ISR、acks、min.insync.replicasの関係

Kafkaの各パーティションはLeaderと複数のFollowerで構成され、Leaderと十分に同期しているレプリカ集合がISRです。min.insync.replicas(以下minISR)は「書き込みを成功扱いにするためにISRに何台のackが必要か」の下限です。

acks=all(= -1)のとき、LeaderはISR全員のackを待ちます。ただしISRのサイズがminISRを下回っている場合、プロデューサーはNotEnoughReplicasエラーで失敗します。acks=1や0ではminISRは実質的に強制されず、Leaderのみ、またはネットワーク送信で即時成功します。

replication.factor(RF)とminISRの関係は厳格です。minISRはRF以下である必要があり、RF - minISR が「同時に許容できる障害(書き込み継続の観点)」のおおよその上限になります。

• minISRはトピック単位で設定。未指定時はブローカーのデフォルト(min.insync.replicas)が適用される
• acks=allのときにminISRが効く。ISR < minISR なら書き込みは失敗
• RFとminISRの差分が"どこまで壊れても書けるか"の目安
• unclean.leader.election.enable=falseが推奨。データ完全性を優先(ただし可用性は下がる)

acks=all と min.insync.replicas=2 (RF=3) のイメージ

耐久性と可用性のトレードオフを定量化する

実務でも試験でも問われるのは、minISRとacksの組み合わせが"どれだけの障害で書き込み・読み取りの可用性とデータ耐久性を保てるか"です。近似的に、書き込み継続のために同時に許容できる障害数は RF - minISR と覚えると整理しやすくなります(acks=all前提)。

acks=allはISR全員のackを待つため、ISRに遅延レプリカがいると待ち時間が増え、タイムアウトでNotEnoughReplicasAfterAppendになる可能性があります。minISRを高く設定するとデータ喪失リスクは下がりますが、書き込みの可用性とレイテンシに影響します。

• RFは障害耐性の上限、minISRは"実効耐久性"の下限
• acks=all + minISR↑ で耐久性↑・可用性↓・レイテンシ↑になりやすい
• acks=1 は可用性↑・レイテンシ↓だが、Leader喪失時のデータ喪失リスク↑

プロデューサーの耐久性優先プロパティ例

acks=all
enable.idempotence=true
retries=2147483647
max.in.flight.requests.per.connection=1
request.timeout.ms=30000
delivery.timeout.ms=120000
compression.type=snappy
linger.ms=10
batch.size=65536

ワークロード別の推奨設定パターン

一律の最適解はありません。SLA(遅延・可用性・完全性)と障害モデルに合わせてRF・minISR・acksを組み合わせます。試験では"RF=3, minISR=2, acks=all"が実務的な安全デフォルトとして頻出です。

低遅延が最重要なケースでも、最小限の完全性を担保するためにacks=all, minISR=2を維持し、バッチや圧縮、ネットワークを最適化する方が総合的に安定します。

• バランス型(汎用イベント): RF=3, minISR=2, acks=all
• 耐久性重視(監査・決済): RF=3〜5, minISR=RF-1以上, acks=all, unclean LE選挙無効
• 超低遅延重視(一時バッファ容認): RF=3, minISR=1, acks=1 または all、ただし喪失リスクを明示合意
• 局所障害多発環境: RF↑ よりもまずネットワーク/ディスク遅延の是正とISR安定化

トピック/ブローカー設定の具体例

# トピック作成時にminISRを指定
kafka-topics --bootstrap-server <broker> \
  --create --topic orders \
  --partitions 12 --replication-factor 3 \
  --config min.insync.replicas=2

# 既存トピックで変更
kafka-configs --bootstrap-server <broker> \
  --alter --entity-type topics --entity-name orders \
  --add-config min.insync.replicas=2

# ブローカーのデフォルト(サーバー設定)
# server.properties
min.insync.replicas=2
unclean.leader.election.enable=false

障害シナリオ時の挙動とエラーコード

ISRがminISR未満に縮小している状態でacks=allの書き込みを行うと、即座にNotEnoughReplicasが返ります。これは"開始時点で必要最小の同期者が不足"の意味です。

書き込み開始時にISR≥minISRでも、待機中にISRからノードが外れたりタイムアウトした場合、NotEnoughReplicasAfterAppendとなることがあります。これは"追記はされたが、期待通りの複製が間に合わなかった"状態です。

Leader障害時はISR内のレプリカから新規Leaderが選出されます。unclean.leader.election.enable=falseであれば、ISR外からの選出は行わず、可用性よりも整合性を優先します。

• NotEnoughReplicas: 開始時にISR < minISR
• NotEnoughReplicasAfterAppend: 途中で必要な複製が満たせず
• IsrShrinks/Expandsが頻発する場合はディスク/ネットワーク遅延を疑う
• Controlled shutdownでのリーダー移譲は整合性維持に有効

挙動確認のためのタイムアウト調整例(検証環境)

# プロデューサー(短めにしてエラーを顕在化)
acks=all
request.timeout.ms=10000
delivery.timeout.ms=20000
retries=10
max.in.flight.requests.per.connection=1

監視・SLO設計・チューニングの勘所

minISRを活かすには、ISRが安定していることが前提です。UnderReplicatedPartitionsが0付近で推移し、IsrShrinksPerSecがスパイクしないことをSLOとして設定すると実務的です。

書き込みSLOは"p99レイテンシ""エラーレート""ISR安定性"の3点で見ると因果が追いやすくなります。acks=all運用ではタイムアウト値を適切に取り、ネットワーク・ディスクのヘッドルームを確保してください。

• 必須メトリクス: UnderReplicatedPartitions, OfflinePartitionsCount, IsrShrinks/ExpandsPerSec
• プロデューサー側: record-error-rate, record-retry-rate, request-latency-avg/p99
• サイジング: RF=3, minISR=2時は少なくとも2台分の安定IO/ネットワーク帯域が必要
• アラート例: UnderReplicatedPartitions>0 が閾値T分継続、またはIsrShrinksPerSecが連続N分>0

acks=all運用のタイムアウトと再試行の目安

# 目安(ワークロードとネットワークに合わせて要実測チューニング)
request.timeout.ms=30000
delivery.timeout.ms=120000
retries=2147483647
retry.backoff.ms=100
socket.connection.setup.timeout.ms=10000

CCAAK対策ポイント整理

試験では"RFとminISRの差分"と"acks=all時のみminISRが効く"の2点が定番です。障害数の許容やエラーコードの違い、unclean leader electionの影響も押さえておきます。

また、トピック設定優先(ブローカーのデフォルトより強い)、minISR>RFはエラー、といった設定ルール問題も出題されます。

• 暗記: 許容障害数(書込継続) ≒ RF - minISR (acks=all前提)
• acks=1/0ではminISRは実質無関係(耐久性は下がる)
• NotEnoughReplicas vs NotEnoughReplicasAfterAppend の違い
• unclean.leader.election.enable=false はデータ完全性を優先
• トピック設定がブローカーデフォルトを上書き

問題で確認

よくある質問