Kafka の Replica と In-Sync Replicas を正しく設計する: 耐障害性と一貫性

Kafka の耐障害性は「レプリケーション」と「ISR(In-Sync Replicas)」で成立します。単にレプリケーション係数を増やすだけではデータ損失を回避できません。acks と min.insync.replicas の組み合わせ、そして unclean.leader.election.enable をどう置くかが一貫性を左右します。

本稿は CCAAK などの資格対策を意識しつつ、現場で迷いがちな設計ポイントを公式ドキュメントの挙動に沿って整理します。特に RF=3 を前提とした安全な構成、ISR の縮小/拡大、HW(High Watermark) とコミットの意味、フェイルオーバー時の可用性トレードオフを具体的に解説します。

レプリカと ISR の基本

Kafka の各パーティションは 1 台のリーダーと複数のフォロワーで構成され、replication.factor(RF) により総レプリカ数が決まります。フォロワーはリーダーから順次取り込み、同じ順序でログを複製します。

ISR は「リーダーと十分に同期しているレプリカの集合」です。フォロワーが所定の時間しきい値内に追随できていない場合は ISR から外れ、自動で縮小/拡大します。プロデューサーの acks=all は ISR を基準にコミットの可否を判断します。

• リーダー: 書き込みの受付と順序の確定を担う唯一のレプリカ
• フォロワー: リーダーからフェッチし同一ログを構築
• ISR: 追随要件を満たすレプリカ集合。遅延が閾値超過で除外、追いつけば再編入
• 基本指針: 本番は RF=3 以上、acks=all と min.insync.replicas の併用が安全策

Producer から Leader、Follower、ISR の関係

トピック作成と最小ISRの設定例

kafka-topics --bootstrap-server broker1:9092 \
  --create --topic orders --partitions 6 --replication-factor 3

# トピック単位で最小ISR=2を設定 (RF=3 が前提)
kafka-configs --bootstrap-server broker1:9092 \
  --alter --topic orders --add-config min.insync.replicas=2

ISR の形成・縮小・拡大の条件

フォロワーは定期的にリーダーからデータをフェッチします。一定時間以上フェッチや追随ができない場合、フォロワーは ISR から外れます。再度追いつけば自動的に ISR に復帰します。

ISR はスループット制御の安全弁でもあります。追随できないレプリカを外すことでコミット前提の複製待ちが過度に遅延することを避けられます。ただし ISR が min.insync.replicas 未満に縮むと acks=all の書き込みはエラーになります。

• 除外の主因: ネットワーク断、ブローカ過負荷、ストレージ遅延
• 設定の目安: replica.lag.time.max.ms は環境の往復遅延とスループットに見合う値に
• 監視指標: UnderReplicatedPartitions、IsrShrinksPerSec / IsrExpandsPerSec
• 動作: ISR < min.insync.replicas で NotEnoughReplicas または NotEnoughReplicasAfterAppend を返す

ISR の確認 (Describe 出力に ISR が表示される)

kafka-topics --bootstrap-server broker1:9092 --describe --topic orders
# 出力例の一部
# Partition: 0	Leader: 2	Replicas: 2,1,3	ISR: 2,3

High Watermark とコミットの意味

Kafka のコミットは High Watermark(HW) に基づきます。HW は ISR 内レプリカの LEO(Log End Offset) の最小値で、これより小さいオフセットは全 ISR にレプリカ済みと見なされます。

acks=all のプロデューサー応答は、レコードがコミットされ HW がそのレコードを含む位置まで前進したときに返ります。ISR が遅ければ一時的に待たされ、ISR が縮んで再編成されれば進みます。

• HW は ISR に依存。ISR が大きいほどコミット要件が厳しくなる
• ISR 縮小によりコミットが再開することがあるが、下限は min.insync.replicas
• read_committed のコンシューマはコミット済みのみを可視化（トランザクション使用時）
• 非トランザクションでも HW は可視性の境界として機能

プロデューサーの一貫性寄り設定例

bootstrap.servers=broker1:9092,broker2:9092,broker3:9092
acks=all
enable.idempotence=true
retries=2147483647
max.in.flight.requests.per.connection=1
request.timeout.ms=30000
delivery.timeout.ms=120000

acks と min.insync.replicas の設計指針

acks はリーダーがどの段階で応答するかの方針、min.insync.replicas はコミットのための最小 ISR サイズの下限です。RF=3 の一般的な安全策は「acks=all ＋ min.insync.replicas=2」。これにより 1 台障害時でも新規書き込みが安全に継続し、さらに 2 台目が失われた場合は書き込みを停止してデータ損失を避けます。

低レイテンシ志向なら acks=1 ですが、リーダー単独障害で直前の書き込みが失われる可能性があります。バッチや重要データは acks=all と min.insync.replicas の併用を基本にしましょう。

• RF=3 かつ acks=all, minISR=2 で 1 台障害時に無損失継続
• ISR が 1 に縮むと acks=all の送信は失敗しプロデューサーで再試行・待機へ
• 可用性優先で minISR を下げると、フェイル時の損失リスクが上がる

トピックごとの acks 運用と設定確認の流れ

# プロデューサー側 (例: アプリ設定)
acks=all

# トピック側の最小ISRを 2 にしておく (RF=3 前提)
kafka-configs --bootstrap-server broker1:9092 \
  --alter --topic payments --add-config min.insync.replicas=2

# 設定確認
kafka-configs --bootstrap-server broker1:9092 \
  --describe --topic payments | grep min.insync.replicas

クリーン/アンクリーンなリーダー選出とデータ損失

健全なフェイルオーバーでは、ISR 内のレプリカのみから新しいリーダーを選出します。これがクリーンなリーダー選出で、順序と整合性を保ちます。一方、unclean.leader.election.enable を許可すると、ISR 外の遅延レプリカがリーダーになる場合があり、未複製の書き込みが巻き戻されデータ損失が発生します。

強い一貫性を求めるなら unclean.leader.election.enable=false を推奨します。その場合、ISR が完全に失われるとパーティションは一時的に書読不可となりますが、データは失われません。

• 推奨: unclean.leader.election.enable=false
• RF=3 以上で可用性と一貫性の両立が容易に
• RF=2 は分断シナリオでジレンマが増えるため避ける
• 停止やローリング時はフォロワーの追随を確認してから作業

トピック単位のアンクリーン選出禁止

kafka-configs --bootstrap-server broker1:9092 \
  --alter --topic orders --add-config unclean.leader.election.enable=false

# 確認
diff <(kafka-configs --bootstrap-server broker1:9092 --describe --topic orders | sort) /dev/null | cat

運用の要点: 監視・テスト・よくある落とし穴

ISR とレプリカ遅延は継続監視が不可欠です。UnderReplicatedPartitions が 0 を維持できているか、IsrShrinks/Expands の増減、ネットワークとディスク待ち時間を把握しましょう。プロデューサー側では NotEnoughReplicas 系エラーの再試行戦略と警告の整備が必要です。

本番前に障害注入テストを繰り返し、1 台停止時の acks=all + min.insync.replicas=2 の継続性、2 台停止時に書き込みが止まること、復旧後に順序と整合性が保たれることを確認します。

• 監視: UnderReplicatedPartitions、OfflinePartitionsCount、IsrShrinks/Expands、ネットワーク往復遅延
• プロデューサー: 再試行・バックオフ・タイムアウトと idempotence を適切化
• ローリング再起動時は ISR が安定してから次を再起動
• スローフォロワーの常態化はハードまたは GC/IO のボトルネックを疑う

CLI での健全性チェック例

# アンダーレプリケートの検出
kafka-topics --bootstrap-server broker1:9092 --under-replicated-partitions --describe

# パーティションのリーダー/ISR 一覧
kafka-topics --bootstrap-server broker1:9092 --describe --topic orders

# ブローカ毎の負荷は外部監視や JMX エクスポートを活用

問題で確認

よくある質問