Kafkaコントローラーブローカー徹底整理: 役割とメタデータ管理（CCAAK対応）

コントローラーブローカーは、トピック/パーティションのリーダー選出、ブローカーの生死監視、再割り当てなどクラスタ全体のメタデータと状態遷移を統括します。クライアントが直接接続する先ではありませんが、安定運用と試験対策のカギになります。

本稿では、ZooKeeperベースとKRaft（Kafka Raft）ベースの両方を押さえ、現場で迷いやすいポイントを図・比較表・コマンド例付きで整理します。対象はCCAAK相当の管理者レベルです。

コントローラーの基本と選出（ZooKeeper / KRaft）

コントローラーブローカー（以下、コントローラー）は、クラスタの唯一のアクティブ管理者です。ZooKeeperモードでは通常のブローカーの中から1台がZooKeeperのエフェメラルZNodeを用いて選出されます。KRaftモードではブローカーとは独立したコントローラー・クォーラム（Raft）からリーダーが選ばれ、これが"アクティブコントローラー"として振る舞います。コントローラー障害時は自動でフェイルオーバーします。

注意点として、パーティションのリーダーとクラスタのコントローラーは別役割です。各パーティションに1つのリーダーレプリカが存在しますが、クラスタ全体のリーダー（=コントローラー）は常に1つです。コントローラーはメタデータの確定・配信を担い、クライアントは通常ブローカーにのみ接続します。

ZooKeeperモード: ブローカー1台がZK経由で選出。イベントはLeaderAndIsr/UpdateMetadata等のRPCで配布
KRaftモード: コントローラー・クォーラムのRaftリーダーがアクティブに。メタデータはメタデータログとしてコミット・複製
コントローラー不在は短時間でもクラスタ操作に影響（例: 新規トピック作成、リーダー切替）

ZooKeeper と KRaft におけるコントローラーの位置づけ

メタデータの範囲とライフサイクル

Kafkaの"メタデータ"は、クラスタID/ブローカー登録、トピック・パーティション構成、ISR（In-Sync Replicas）、割り当て、ACL、各種コンフィグ（トピック/クォータ/ユーザー/ブローカー）などを含みます。これらはコントローラーが一次的に確定し、ブローカーのメタデータキャッシュへ反映されます。

ZooKeeperモードでは、変更はZooKeeperに書き込まれ、アクティブコントローラーがLeaderAndIsr/UpdateMetadata等のRPCで各ブローカーへ配信します。KRaftモードでは、コントローラー・クォーラムのメタデータログにコミットされ、ブローカーはコントローラーからスナップショット/デルタを取り込みキャッシュを更新します。クライアントは接続先ブローカーのメタデータキャッシュを参照してルーティング（パーティションのリーダー位置など）を決定します。

メタデータは強整合に近い管理を志向：コントローラーが単一の真実源として確定
クライアントはコントローラーに直接問い合わせない（ブートストラップ先のブローカー経由）
ISRの変化・ブローカーの出入りはコントローラーがトリガーしてリーダーを再選出

ZooKeeperモードとKRaftモードの違い（比較表）

移行期のいまは両アーキテクチャが併存しています。名称が似ていても挙動や運用ポイントは異なるため、試験では用語と責務の対応を正確に押さえてください。特に"どこで選挙が行われ、どこにメタデータが永続化されるか"が頻出ポイントです。

KRaftではコントローラーをブローカーと同居（process.roles=broker,controller）させる構成と、専用ノードに分離（process.roles=controller）の構成を選べます。大規模では分離が推奨されることが多いです。

選挙先: ZooKeeperはZNodeベース、KRaftはRaftベース
伝播: ZooKeeperはRPC配信、KRaftはメタデータログにコミット後に取り込み
運用: KRaftはZKが不要、起動順序や設定キーが変わる

観点	ZooKeeperモード	KRaftモード（同居）	KRaftモード（専用コントローラー）
コントローラー選出先	ブローカーの1台（ZKのエフェメラルZNode）	同一プロセス内でコントローラー役に昇格（Raft）	コントローラーノード群からRaftで選出
メタデータ永続化	ZooKeeperツリー（/brokers, /controller 他）	メタデータログ（Raft）	メタデータログ（Raft）
ブローカーへの反映	LeaderAndIsr/UpdateMetadata RPCで配信	スナップショット/デルタの取り込み	スナップショット/デルタの取り込み
起動要件	ZooKeeper起動→ブローカー起動	コントローラー・クォーラム到達→ブローカー起動	コントローラークォーラム起動→ブローカー起動
主な運用ポイント	ZK健全性、/controller監視、ActiveControllerCount	controller.quorum.voters・リスナー設計	専用ネットワーク/リソース、フェイルオーバー速度

コントローラーの責務と主要フロー

コントローラーは、パーティションのリーダー/ISR管理、ブローカーの登録・心拍監視、障害/計画停止時のリーダー再配置、トピック作成/削除に伴う割り当て確定、再割り当てや優先リーダー選出の実行、ACLやクォータ等のメタデータ変更の確定を担います。

イベント駆動で動作し、ZooKeeperモードではControllerEventManagerがイベントを順序立てて処理、KRaftではメタデータログへのコミット順序が全体整合性を保証します。不整合時はスナップショット/フルフェッチで回復します。

障害検知: ブローカー心拍の欠落やセッション切断でオフライン判定
リーダー再選出: ISRを基に安全に選出。必要に応じてUnclean leader election設定に依存
計画停止: Controlled shutdownでリーダーを事前に他レプリカへ移譲
再割り当て: スループット制御付きで段階的に移動
優先リーダー: Preferred leader electionで初期割り当ての優先リーダーに戻す

運用: フェイルオーバー、監視、トラブルシュート

フェイルオーバーは自動ですが、検出・復帰の速さはタイムアウトとネットワーク健全性に依存します。ZooKeeperモードではセッションタイムアウト、KRaftではRaftハートビート/選挙タイムアウトの設定が影響します。実運用では"早すぎる"切り替えがチャーンを生まないよう、ネットワーク特性に合わせます。

監視の基本は、アクティブコントローラー指標、メタデータ処理待ち行列、リーダー移動回数、ISRの安定性、コントローラーチャネルのエラー/遅延、メタデータ伝播レイテンシです。ログではZooKeeperモードのControllerEventManager、KRaftのQuorumController付近を重点確認します。

アクティブ判定: ZKなら/controller、KRaftならメタデータクォーラムのリーダーを確認
伝播遅延: UpdateMetadataやメタデータログ適用遅延が高いとクライアントのルーティング失敗が増える
計画メンテ: controlled shutdownでリーダー移譲、スループット制御で再割り当て

現場で使う確認コマンド（ZooKeeper / KRaft）

# ZooKeeperモード: アクティブコントローラーを確認
bin/zookeeper-shell.sh zk1:2181 get /controller
# 出力のbrokeridがアクティブコントローラー

# ZooKeeperモード: ブローカーの生存（エフェメラルノード）
bin/zookeeper-shell.sh zk1:2181 ls /brokers/ids

# KRaftモード: コントローラー・クォーラムの状態
bin/kafka-metadata-quorum.sh describe --bootstrap-server controller1:9093 --status
# Leader(=Active Controller) とVoterの健全性を確認

# KRaftモード: クォーラム内の全履歴の短縮表示
bin/kafka-metadata-quorum.sh describe --bootstrap-server controller1:9093 --log-snapshot

# 参考: パーティション配置とリーダー（どのブローカーが担当か）
bin/kafka-topics.sh --bootstrap-server broker1:9092 --describe --topic my-topic

# KRaftサンプル設定（同居構成）
# server.properties（一例）
process.roles=broker,controller
node.id=1
controller.listener.names=CONTROLLER
listeners=PLAINTEXT://:9092,CONTROLLER://:9093
inter.broker.listener.name=PLAINTEXT
controller.quorum.voters=1@host1:9093,2@host2:9093,3@host3:9093

CCAAK試験対策: ひっかけ回避の要点

試験では、用語の取り違え（コントローラー vs パーティションリーダー vs グループコーディネーター）が頻出です。クライアントが直接コントローラーに接続することはありません。また、ZooKeeperとKRaftの設計差に起因する選出・永続化・伝播の違いも問われやすいです。

安全なリーダー選出（ISRに基づく）、Unclean leader electionのリスク、controlled shutdownの効果、再割り当て中のスロットリング、メタデータキャッシュの役割と限界（反映遅延による一時的なルーティング失敗）など、運用実務の観点も理解しておきましょう。

コントローラーは1クラスタに1つ（アクティブ）だが、パーティションのリーダーは各パーティションに存在
クライアントはブローカーのメタデータキャッシュを参照（Describe/Metadata API）
ZooKeeper: /controllerと/brokers/idsで状態把握。KRaft: metadata quorumコマンドで把握
"コントローラーノードが落ちても既存データの読み書きは概ね継続可能だが、管理操作は影響"が基本線

問題で確認

CCAAK

問題 1

Kafkaクラスタのコントローラーに関する正しい説明はどれか。最も適切なものを1つ選べ。

クライアントは通常、コントローラーではなく任意のブローカーからメタデータを取得する。
各パーティションごとに必ず1つのコントローラーが存在し、リーダーと同義である。
KRaftモードではメタデータは各ブローカーのローカルログにのみ書かれ、コントローラーは関与しない。
ZooKeeperモードではコントローラーの選出はブローカー間の投票で行われ、ZooKeeperは関与しない。

正解: A

コントローラーはクラスタ全体に1つのアクティブが存在し、メタデータを確定・伝播するが、クライアントは通常接続したブローカーからメタデータを取得する（A）。Bはコントローラーとパーティションリーダーの混同、CはKRaftのメタデータログ/Raftを無視しており誤り、DはZooKeeperが選出に関与するため誤り。

よくある質問

コントローラー障害時、読み書きは止まるのか？

進行中のプロデュース/コンシュームは多くの場合継続します。ただし新規トピック作成、リーダー切替、再割り当て等の管理操作はコントローラー復帰まで影響を受けます。長引けばブローカー障害時のリーダー再選出もできず影響が拡大します。

KRaft移行時、コントローラーはブローカーと分離すべき？

小規模や検証では同居構成でも十分ですが、本番の可用性・分離性を重視するなら専用コントローラー（process.roles=controller）を推奨します。ネットワーク/リソースを分け、controller.quorum.votersとリスナー設計を明確にします。

コントローラーとグループコーディネーターの違いは？

コントローラーはクラスタ全体のメタデータ・状態遷移を管理します。グループコーディネーターはコンシューマグループのメンバーシップとパーティションアサインを担当するブローカー内の役割で、対象範囲も責務も異なります。

この記事で学んだ内容を問題で確認しましょう

16,000問以上の問題で実力チェック

無料で問題を解いてみる

この記事の著者

NicheeLab編集部

データエンジニアリング・クラウド資格の専門家。Databricks・Snowflake等の認定資格を保有し、実務経験に基づいた問題作成・解説を行っています。NicheeLab運営。

Kafkaコントローラーブローカー徹底整理: 役割とメタデータ管理