Kafka Rack Awareness 実践ガイド：障害分離のためのブローカー配置

Rack Awareness は、ブローカーとレプリカを物理/論理的に分離（ラック、アベイラビリティゾーン、データセンター）して、単一障害によるサービス停止やデータ喪失の確率を下げるための標準機能です。運用では「すべてのブローカーに正しい rack を設定する」ことと、「レプリケーション設定をラック障害前提で決める」ことが肝になります。

本稿は、公式ドキュメントに基づく安定的な挙動を前提に、ブローカー配置、パーティション配置アルゴリズム、RF と min.insync.replicas の組み合わせ、障害時の動作を整理します。最後に CCAAK 向けの出題ポイントも明確化します。

Rack Awareness の目的と前提条件

Kafka の Rack Awareness は、トピック作成時やレプリカ再割り当て時に、可能な限り異なる rack にレプリカを分散させる仕組みです。これにより、ラック全体の障害や計画停止があっても、他ラック上のレプリカでリーダーを維持し、書き込み・読み取りを継続できます。

前提はシンプルで、すべてのブローカーに一貫した rack ラベル（broker.rack）を設定することです。これが欠けると、コントローラはラック情報を利用できず、同一ラック内に複数レプリカが偏るリスクが高まります。

• Rack Awareness は「レプリカ配置」の話であって、クラスタ間レプリケーションやクライアントの近接読み取りとは別機能。
• 耐障害性は RF（replication.factor）と min.insync.replicas、Producer の acks 設定と組み合わせて成立。
• ラック数 < RF の場合、全レプリカを別ラックに置くことは不可能で、同一ラック内に複数レプリカが載る可能性がある。

ブローカーの rack 設定と安全なローリング適用

broker.rack は各ブローカーの静的設定です。ラック名や AZ 名はクラスタ内で一貫しており、誤記や重複を避ける必要があります。設定後はローリング再起動で反映します。既存トピックのレプリカ配置は自動では変わらないため、必要に応じて再割り当てを計画します。

検証は、管理 API でブローカー構成を参照する、あるいは新規に作成したテストトピックのレプリカが異なる rack に分散しているかを確認するのが実務的です。

• ブローカーIDと物理ラック/AZ の対応表を作成してレビュー。
• 全ブローカーに broker.rack を設定し、ローリングで再起動。
• テストトピック（RF≥ラック数）を作成し、レプリカの rack 分散を確認。
• 既存トピックをラック分散させたい場合は、計画的に再割り当てを実施（スロットル設定を忘れない）。
• rack 名の変更は慎重に。誤った変更は一時的なリーダー偏りや再同期増加を招く。

broker.rack の設定例と検証用トピック作成

# 各ブローカー server.properties（一例）
broker.id=1
broker.rack=r1
# 他設定は省略

# Kubernetes 等では環境変数を使ってテンプレート展開する例もある
# KAFKA_BROKER_RACK=r1

# 検証用に RF=3 のトピックを作成
kafka-topics --bootstrap-server <host:port> \
  --create --topic rack-test --partitions 3 --replication-factor 3

# 配置の確認（レプリカが複数 rack に分散しているか）
kafka-topics --bootstrap-server <host:port> --describe --topic rack-test
# AdminClient(API)でブローカー構成(broker.rack)を参照しても良い

パーティション配置アルゴリズムと障害分離の仕組み

トピック作成時、コントローラは broker.rack を考慮して可能な限りレプリカを異なる rack に配置します。ブローカー間のバランス（パーティション数・レプリカ数）も考慮しつつ、同一 rack への過剰な集中を避けるように割り当てます。

ラック障害時は、ISR に残る別ラック上のレプリカからリーダーを選出します。RF=3、min.insync.replicas=2、acks=all の組み合わせなら、1ラック（=1レプリカ）喪失時も書き込み継続が可能です。

• 1ラック障害に耐える目安: RF=3, min.insync.replicas=2, acks=all, unclean.leader.election.enable=false。
• ラック数 < RF のときは最大限分散するが、完全分離は保証できない。
• 再割り当てツール実行時も rack を尊重して配置を提案できる（ツールのデフォルト挙動を確認のうえ運用）。

ラック分散の例（RF=3, 3ラック, 6ブローカー）

トピック設計：RF と min.insync.replicas と acks の要点

ラック障害に耐えるには、レプリカを別ラックへ分散させるだけでなく、書き込みクォーラム条件を適切に設定する必要があります。特に RF と min.insync.replicas（minISR）と Producer の acks はセットで考え、障害時の継続可否とデータ安全性のトレードオフを理解しておきます。

一般的に、3ラック構成では RF=3、minISR=2、acks=all を推奨します。これにより1ラック喪失時も書き込みを継続しつつ、unclean リーダー選出を無効にしてデータ損失を防止できます。

• minISR はトピックまたはブローカーデフォルトで設定可能。RF より小さく、障害時に満たせないと書き込みは失敗する。
• acks=all を使わない場合、ラック障害下で見かけ上成功しても後でデータ欠損が顕在化するリスクがある。
• パーティション数が多いとラック内のブローカー間での分散も重要になる（ホットスポット回避）。

障害・保守時の挙動と実務パターン

計画メンテナンスではラック単位の作業を避け、可能ならブローカー単位でローリングを行います。どうしてもラック全停止が必要な場合は、事前に minISR とトラフィックパターンを確認し、必要に応じて一時的なスロットルやプロデューサのバックオフ調整を行います。

レプリカ再割り当て時は、rack を尊重したプランを生成し、リバランスのスロットルを適切に設定します。監視では、パーティションのリーダー分布が特定ラックに偏っていないか、ISR 収縮が連鎖していないかを重点的に確認します。

• リバランスのスロットル設定（replica.fetch.max.bytes, follower.fetch 配下の帯域、ツールのスロットル）
• 優先リーダー選出を計画的に実施し、リーダーを各ラックに均等化
• 大量のパーティション移動は分割して実施。観測指標（UnderReplicatedPartitions, ISR 変動）を見ながら進める

CCAAK 試験対策チェックリストと落とし穴

CCAAK では、rack を使ったレプリカ分散の原理、RF/minISR/acks の相互作用、ラック障害時の書き込み可否、設定の適用順序（全ブローカーに broker.rack を設定）といった実務基本が問われます。以下の観点を押さえておくと取りこぼしを減らせます。

また、クライアントの近接読み取りは別の設定領域であり、Rack Awareness（レプリカ配置）と混同しないことが重要です。

• 全ブローカーに broker.rack を設定しなければラック分散は成立しない。
• RF=3, minISR=2, acks=all は 1ラック障害に耐える代表構成。
• ラック数 < RF の場合、完全分離は不可能で一部同ラック配置になる可能性あり。
• unclean.leader.election.enable=false によりデータ損失を防止（可用性とのトレードオフ）。
• レプリカ再割り当てをしない限り、既存トピックの配置は自動では変わらない。

問題で確認

よくある質問