Kafka Unclean Leader Electionを正しく判断する：データ損失リスクと可用性のバランス

Unclean Leader Election（以下、ULE）は、ISR内に生存レプリカがない非常時に、OSRからもリーダーを選出して可用性を回復する仕組みです。その代償は、未複製レコードの巻き戻し（データ損失）です。

本稿では、ULEの挙動、データ損失のメカニズム、設定判断の基準、関連パラメータとの組み合わせ、監視・演習、そしてCCAAKで問われやすい観点を、実務に即して整理します。Kafkaの公式ドキュメントと整合する安定概念を前提に説明します。

Unclean Leader Electionの基本とISR/OSRを正しく理解する

Kafkaの各パーティションはリーダーとフォロワーで構成され、十分に同期したレプリカの集合がISR（in-sync replicas）です。通常のリーダー選出はISRからのみ行われるため、整合性が守られます。

ULEは、障害でISR内に生存レプリカが1つもない場合でも、OSR（out-of-sync replicas）からリーダーを選出し、パーティションをオンラインに戻します。デフォルトは無効（false）で、無効時はISR復帰までパーティションはオフラインのままです。

• 目的: 可用性の緊急回復（ダウンタイム短縮）
• 副作用: 旧リーダーのみが保持していた未複製データの喪失・巻き戻し
• 設定単位: ブローカー既定値とトピック個別上書き（トピック値が優先）
• 関連: min.insync.replicas、プロデューサのacks、レプリケーション要件

障害時の選挙パス（ISRが全滅したケース）

パーティション P (RF=3)

初期状態:
  R1(Leader)  R2(Follower)  R3(Follower)
  ISR = {R1, R2}   OSR = {R3}

障害発生: R1ダウン、R2も同時障害
  生存: R3のみ（ただしOSR）

分岐:
  1) ULE=false（デフォルト）
     -> リーダー不在のまま待機
     -> パーティションPは一時オフライン
     -> ISR回復後に通常の選挙

  2) ULE=true
     -> OSRのR3を暫定リーダーに選出
     -> 旧R1にだけあった未複製レコードは失われる（ロールバック）
     -> 可用性は回復するが履歴は不連続になり得る

関連プロパティ（ブローカー既定とトピック上書き）

# broker（server.properties あるいは動的設定）
unclean.leader.election.enable=false  # 推奨デフォルト

# トピック単位で例外的に有効化（避難ログ等）
# Kafka (kafka-configs.sh)
 kafka-configs.sh --bootstrap-server <broker:9092> \
  --alter --topic critical-telemetry \
  --add-config unclean.leader.election.enable=true

# 有効値の確認
 kafka-configs.sh --bootstrap-server <broker:9092> \
  --describe --topic critical-telemetry | grep unclean

いつ発動し何が失われるか：選挙とデータ損失のメカニズム

ULEは「ISR内に生存レプリカが存在しない」かつ「生存するOSRがいる」状況でのみ意味を持ちます。無効の場合はパーティションが一時的にオフラインとなり、クライアントにはNotLeaderOrFollowerやLEADER_NOT_AVAILABLEに類するエラーが返り得ます。

有効の場合、コントローラはOSRから新リーダーを選びます。旧リーダーから新リーダーへ完全には複製されていないレコードは、新リーダーのログには存在しないため、旧リーダーが復帰した際にリーダーエポックおよび高水位（HW）に従ってトランケーションが行われ、結果的に当該レコードは履歴から消えます。acks=1で受領されていた書き込みは失われる可能性があります。acks=allかつmin.insync.replicasを適切に設定していれば、その条件を満たした書き込みは原理的にロスしませんが、条件未達の書き込みはACKされずに失敗として返るため、アプリ側で再試行設計が必要です。

• 発動条件: ISRに生存が0、OSRに生存が≥1
• データ損失の単位: 新旧リーダー間で未複製の末尾レコード範囲（高水位より先）
• 可観測性: トランケーション、エポック更新、オフラインパーティション数の変化

コントローラ/ブローカーのログ例（要点のみ）

[Controller] Partition P: No live ISR; unclean leader election is enabled
[Controller] Electing new leader from OSR: R3, new leader epoch=42
[Broker R3] Became leader for P-0 at epoch 42
[Broker R1] Truncating log for P-0 from offset 105 down to HW 102 (on recovery)

設定判断の指針：可用性とデータ保全のトレードオフ

金融勘定やオーダーイベントのように履歴一貫性が最重要なトピックでは、ULEは基本的に無効のままにし、RF≥3、min.insync.replicas≥2、プロデューサはacks=allを徹底します。ダウンタイムは許容し、誤差のない履歴を守ります。

逆に、短時間の欠落が業務に致命的でない観測・テレメトリ系では、SLAに応じて一部トピックでULEを有効化する判断があり得ます。この場合も、min.insync.replicasとacksの整合、アラート、再送ロジックの設計を合わせて行います。

• 原則: 重要データはULE無効。やむを得ない場合のみトピック例外で有効化。
• 伴走設定: RF、min.insync.replicas、acks、プロデューサ再試行・順序設計を一式で検討。
• 復旧時の整合: 消費側は重複・欠落検知（オフセット管理、冪等処理）を実装。

判断を反映する例（決済=厳格 / テレメトリ=可用性優先）

# 決済トピック（厳格）
 kafka-topics.sh --bootstrap-server <broker:9092> --alter --topic payments \
  --config unclean.leader.election.enable=false \
  --config min.insync.replicas=2
# プロデューサは acks=all を必須化

# テレメトリ（可用性優先）
 kafka-topics.sh --bootstrap-server <broker:9092> --alter --topic telemetry \
  --config unclean.leader.election.enable=true \
  --config min.insync.replicas=2
# ただし未達はアプリ側で再送・欠落許容の前提設計を行う

実務設定と検証手順

監査から始めます。ブローカー既定とトピック個別の双方を点検し、期待と不整合がないか確認します。変更は可能ならトピック単位で最小限に行うのが安全です（広域既定の変更は影響が大きい）。

動的設定の変更はローリングリスタート不要ですが、既存のクライアントSLAや再試行戦略と矛盾しないか、ステージングで障害注入（ブローカー停止）をして検証します。

• 監査: 重要トピックでULE=trueが紛れ込んでいないか確認
• ロールアウト: 1トピック→数トピック→全体と段階的に検証
• リスク緩和: RF≥3、min.insync.replicas≥2、acks=all、冪等プロデューサを併用

設定監査と変更の具体例

# ブローカー既定（ランタイムの動的設定も含む）
 kafka-configs.sh --bootstrap-server <broker:9092> --entity-type brokers --entity-name 0 --describe
# （クラスタ全体を見たい場合は各ブローカー、または--allや外部CMDBを使用）

# トピックの有効値
 kafka-configs.sh --bootstrap-server <broker:9092> --describe --topic <topic>

# 既定値の変更（慎重に）
 kafka-configs.sh --bootstrap-server <broker:9092> --entity-type brokers --entity-name 0 \
  --alter --add-config unclean.leader.election.enable=false

# トピック単位の上書き
 kafka-configs.sh --bootstrap-server <broker:9092> --alter --topic <topic> \
  --add-config unclean.leader.election.enable=true

# 期待するmin.insync.replicasと合わせて設定
 kafka-topics.sh --bootstrap-server <broker:9092> --alter --topic <topic> \
  --config min.insync.replicas=2

監視・SLA運用：メトリクスと演習

ULEの有無に関わらず、障害時に何が起きたかを即座に把握できるメトリクスとログの整備が重要です。特にオフラインパーティション数、ISRの縮退/回復、レイテンシ/エラー率を監視します。

演習では、ステージング環境でブローカーを計画停止し、ULEの有効/無効それぞれでプロデュース/コンシュームの失敗/成功パターン、ログのトランケーション発生有無を確認します。

• 重要メトリクス（JMX名の一例）: kafka.controller:name=OfflinePartitionsCount, type=KafkaController
• ISR変動: kafka.server:type=ReplicaManager,name=IsrShrinksPerSec / IsrExpandsPerSec
• プロデュース失敗: kafka.producer:type=producer-metrics,record-error-rate / record-retry-rate
• ログ監査: Truncating, Leader epoch, HW のキーワード

簡易演習レシピ（ステージングでのみ実施）

# 準備：テストトピック（RF=3, minISR=2）
 kafka-topics.sh --bootstrap-server <broker:9092> --create --topic t_ule_test \
  --partitions 3 --replication-factor 3 \
  --config min.insync.replicas=2 \
  --config unclean.leader.election.enable=<true|false>

# プロデュース（acks=all）
 kcat -b <broker:9092> -t t_ule_test -P -X acks=all -l msgs.txt &

# ブローカー2台を順に停止（ISRを枯渇させる）
 systemctl stop kafka@<brokerA>
 systemctl stop kafka@<brokerB>

# 観測
 kafka-topics.sh --bootstrap-server <broker:9092> --describe --topic t_ule_test | grep Leader
# JMX/メトリクス: OfflinePartitionsCount, IsrShrinksPerSec を確認
# ログに Truncating が出るか（ULE=true）/パーティション停止（ULE=false）を確認

試験対策ポイント（CCAAK）

CCAAKでは、ULEの定義、デフォルト、データ損失の条件、min.insync.replicasやacksとの関係が頻出です。特に「acks=allなら常に安全」という誤解を突く設問に注意してください。条件を満たさない状況（ISR不足）では、ACKされずに失敗させることが安全動作であり、ULEを有効化すると履歴が巻き戻る可能性がある、という関係を整理して覚えます。

また、Preferred Leader Election（健全な候補間の優先リーダー切替）と、Unclean Leader Election（OSRからの非常時選出）を混同させる設問もあります。前者は整合性を崩しませんが、後者はデータ損失の可能性があります。

• ULEのデフォルト: false。無効時はオフライン維持、整合性優先。
• ULE有効: OSRから選出、可用性↑、未複製データ喪失の可能性。
• acks=all + min.insync.replicas≥2: 条件を満たしたACKは堅牢。未達は失敗させるのが正しい。
• Preferred Leader Electionは別物（整合性を壊さない）。

覚えておくCLI断片

# ULEのトピック上書き
kafka-configs.sh --bootstrap-server <broker:9092> --alter --topic <t> \
  --add-config unclean.leader.election.enable=true

# min.insync.replicas の設定
kafka-topics.sh --bootstrap-server <broker:9092> --alter --topic <t> \
  --config min.insync.replicas=2

# Preferred Leader Election（別概念、整合性は維持）
kafka-preferred-replica-election.sh --bootstrap-server <broker:9092>

問題で確認

よくある質問