Kafka Replication Factor の選定: 3 を基本とした耐障害性設計

本番 Kafka では、トピックの Replication Factor(RF) を 3 にするのが実務の定石です。これは 1 台のブローカー障害を許容しつつ、データ損失リスクを抑え、可用性とコストのバランスを取りやすいからです。

ただし RF=3 とするだけでは不十分で、acks=all と min.insync.replicas の整合、unclean.leader.election の抑止、rack awareness による配置、再割り当て時のスロットリングなどを合わせて設計する必要があります。

なぜ Replication Factor は 3 が基本か

RF は各パーティションのレプリカ数を決め、耐障害性とコストを直接左右します。RF=3 は 1 台のブローカー障害を前提に、書き込み継続性とデータ保護のバランスが良い設定です。特に acks=all と min.insync.replicas=2 を組み合わせると、1 レプリカのダウンを許容しつつ、コミット済みデータの損失を避けられます。

RF=2 は一見コスト効率が良く見えますが、min.insync.replicas を 2 にすると単一障害で即座に書き込み不可、1 にすると書き込みは継続できるもののデータ損失リスクが上がります。RF=1 は実務では推奨されません。

• RF はストレージ消費をおよそ RF 倍に増やす。ネットワーク複製の上乗せは約 (RF-1) 倍。
• RF=3 + min.insync.replicas=2 + acks=all で単一障害時も可用性と耐久性の両立がしやすい。
• 既定の default.replication.factor をブローカー側で 3 に整備しておくと漏れを防げる。

例: トピック作成時に RF=3 を明示

kafka-topics.sh --bootstrap-server localhost:9092 \
  --create --topic orders \
  --partitions 12 --replication-factor 3

# 既定値の整備（ブローカー設定例）
# server.properties
# default.replication.factor=3
# min.insync.replicas はトピック/ブローカーのいずれでも設定可

書き込み耐障害性: acks と min.insync.replicas の整合

acks=all は、リーダーと ISR(同期中のレプリカ集合)全体によるコミット確認を要求します。min.insync.replicas(minISR) は、書き込み成功に必要な ISR 内レプリカ数の下限です。RF=3 では minISR=2 を推奨します。これにより 1 レプリカ障害時でも ISR を 2 に保てる間は書き込みを継続できます。

minISR を RF と同値にしてしまうと、単一障害で即座に書き込みが停止します。逆に minISR を低くし過ぎると書き込みは継続しますが、障害時のデータ損失リスクが増えます。acks=1 はレイテンシは低いものの、フォロワ未反映でも成功となるため実務本番では避けるべきです。

• 推奨コンボ: RF=3, acks=all, min.insync.replicas=2, enable.idempotence=true
• 書き込み継続条件: ISR サイズ >= min.insync.replicas
• ISR からの脱落はフォロワ遅延や障害で起こるため、レプリケーション帯域とディスク性能も設計要素

プロデューサ構成例（Java/Properties）

bootstrap.servers=broker-1:9092,broker-2:9092,broker-3:9092
acks=all
retries=2147483647
max.in.flight.requests.per.connection=1
enable.idempotence=true
# レイテンシと耐障害性のバランスを見て batch.size / linger.ms を調整

障害シナリオと可用性: 単一ブローカー、AZ 障害を想定する

RF=3, minISR=2 であれば、1 台のブローカー障害発生時も ISR が 2 を維持できる限り acks=all の書き込みは継続します。さらに rack awareness を使ってレプリカを別 AZ/ラックに分散させると、単一 AZ 障害への耐性が上がります。

データ保全の観点では unclean.leader.election.enable=false を推奨します。これにより ISR にいないレプリカをリーダーに昇格させず、可用性より整合性を優先します。可用性を優先して true にすると、短期的に書き込みを復旧できる可能性はありますが、コミット済みオフセットの巻き戻りが起き得ます。

• 単一障害想定: RF=3 + minISR=2 で書き込み継続、unclean リーダー選出は無効に
• AZ 配置: broker.rack を設定し、レプリカを AZ またぎで分散
• 読み取りは基本的に follower からも可能だが、整合要件に応じて設計（大半のクライアントはリーダー読取り）

トピック単位での保護的設定例

kafka-configs.sh --bootstrap-server localhost:9092 \
  --alter --topic orders \
  --add-config min.insync.replicas=2,unclean.leader.election.enable=false

# 確認
echo "describe configs"
kafka-configs.sh --bootstrap-server localhost:9092 \
  --describe --topic orders

RF と帯域/ストレージのトレードオフを数値で把握する

RF を上げると、ストレージは線形に増え、複製トラフィックも概ね (RF-1) 倍に増えます。生産トラフィックが 50 MB/s で RF=3 の場合、レプリケーションで約 100 MB/s の追加受信がブローカー間で発生します。ネットワークとディスクの余裕を見込んだ設計が必要です。

RF=5 はミッションクリティカルなワークロードで採用されますが、コストが跳ね上がるため、RF=3 を基準に SLO と障害想定（AZ/ラック級）で再評価するのが現実的です。

• 概算式: ストレージ消費 ≈ 入力データ量 × RF（+ インデックス/オーバーヘッド）
• 概算式: 複製受信帯域 ≈ 生成レート × (RF-1)
• 保守作業時の再複製ピークも考慮（スロットリングで平準化）

概算のラフ試算（シェル）

# 入力 50 MB/s, RF=3 の場合
IN_MBPS=50
RF=3
REPL_MBPS=$(( IN_MBPS * (RF-1) ))
echo "Replicate ingress ~ ${REPL_MBPS} MB/s"

# 日次 500 GB のトピック、RF=3 のストレージ概算（圧縮オフ時）
DAILY_GB=500
STORAGE_GB=$(( DAILY_GB * RF ))
echo "Storage per day ~ ${STORAGE_GB} GB (+index/overhead)"

配置戦略: Rack awareness と AZ 分散

broker.rack を設定すると、Kafka のパーティションアサインメントは可能な限りレプリカを異なるラック/AZ に分散します。RF=3 の場合、3 つの AZ に 1 レプリカずつ配置される構成が望ましいです。AZ 障害時も minISR を満たす設計を意識します。

手動のレプリカ配置を避け、ブローカーの rack メタデータを正しく設定したうえでトピック作成を行うのが堅実です。既存トピックの再配置は再割り当てツールで計画的に実施します。

• 各ブローカーに broker.rack（例: az-a, az-b, az-c）を設定
• トピック作成時は自動割り当てに任せるのが基本（rack-aware）
• RF=3 のときは 3 AZ 構成が理想。2 AZ の場合は AZ 障害で minISR を満たせない局面に注意

3 AZ 構成でのレプリカ分散（P0 の例）

rack awareness の基本設定

# 各ブローカーの server.properties
broker.rack=az-a   # ブローカーごとに az-a / az-b / az-c を設定

# トピック作成（自動割り当てを利用）
kafka-topics.sh --bootstrap-server localhost:9092 \
  --create --topic payments --partitions 24 --replication-factor 3

運用ガードレール: 再割り当て、リーダー選出、スロットリング

ブローカー追加・退役や RF 変更ではパーティション再割り当てが発生します。再複製の帯域はスロットリングして、通常トラフィックへの影響を抑えます。長時間に及ぶ場合はメンテナンスウィンドウも検討します。

リーダー偏りはレイテンシ悪化につながるため、必要に応じて preferred leader election を実行してバランスさせます。unclean leader election は無効のままにし、可用性よりデータ保全を優先します。

• 再割り当ては計画実行 + スロットリング（replication.quota）
• RF 変更は再割り当てが必要（単純 alter では不可のことに注意）
• ピーク帯域や ISR 安定性を監視し、minISR を割り込む前に対処

代表的な運用コマンド

# パーティション数の増加（RF は維持）
kafka-topics.sh --bootstrap-server localhost:9092 \
  --alter --topic orders --partitions 36

# 再割り当てプラン生成と適用（例）
# 1) JSON を用意（対象トピック/ブローカー）
# 2) ツールで --execute、--throttle を指定
kafka-reassign-partitions.sh --bootstrap-server localhost:9092 \
  --reassignment-json-file plan.json --execute --throttle 104857600

# Preferred leader election（偏り是正）
kafka-leader-election.sh --bootstrap-server localhost:9092 \
  --election-type PREFERRED --topic orders

試験対策: CCAAK で問われやすい要点と落とし穴

基本の型を暗記: RF=3 を基準に acks=all + minISR=2、unclean.leader.election=false、broker.rack 設定、という 4 点セット。これを障害シナリオと合わせて説明できるようにします。

RF=2 の落とし穴: minISR=1 だと単一障害で書き込みは続くがデータ損失リスクが上がる、minISR=2 だと単一障害で書き込み停止。どちらも試験で選択肢に出やすいポイントです。

RF の増加はストレージ/帯域コストを線形に押し上げるため、RF=5 の採否は SLO と AZ/リージョン要件で正当化できるかが鍵になります。

• 用語整理: RF, ISR, acks, min.insync.replicas, unclean.leader.election, rack awareness
• 可用性より整合性優先: unclean を無効化。acks=all + minISR をセットで問われる
• コスト設計: ストレージ ≈ RF 倍、レプリカ帯域 ≈ (RF-1) 倍

暗記用チート（コメント付き）

# 推奨の基本線（本番）
# RF=3, acks=all, min.insync.replicas=2, enable.idempotence=true
# unclean.leader.election.enable=false, broker.rack=<AZ/Rack>
# rack-aware による 3 AZ 分散、単一障害で書き込み継続
# コスト: ストレージ 3x, レプリケーション帯域 2x

問題で確認

よくある質問