KRaftは、Apache Kafkaがクラスタのメタデータを自分自身のRaftログで管理する動作モードです。ZooKeeperという別クラスタを立てずに、ブローカーの一覧やトピック構成、リーダー情報を保持します。公式ダウンロードページを2026年8月30日に確認した時点で、サポート対象は4.3.1・4.2.1・4.1.2の3系統。ZooKeeper構成を選べる3.9系はアーカイブ側へ移りました。この記事では、メタデータの持ち方、process.rolesやクォーラムの設定値、ZooKeeper構成から移す順序を、設定ファイルとコマンドの粒度で整理します。移行を急ぐ条件と、いま踏み込まない方がよい場面も条件付きで示します。
まとめ｜KRaftへ移行する判断基準と3.9系で足を止める条件
結論から言えば、自前でKafkaを運用しているなら移行の期限はすでに過ぎつつあります。ZooKeeperを使えるのは3.9系までで、4.0.0（2025年3月18日リリース）以降はKRaftしか選べません。公式のサポート対象は上位3系統に限られるため、3.9系に留まる判断は「セキュリティ修正の提供が細る側に立つ」という意味になります。
設計で押さえる点は3つです。第一に、ZooKeeper構成から直接4.x系へは跳べません。3.9.1へ上げ、デュアルライトを経てファイナライズし、それから4.x系へ進む二段構えになります。第二に、ファイナライズを終えるとZooKeeperモードへは戻れず、切り戻しの検討はその手前で終わらせます。第三に、コントローラはブローカーと分けた専用ノードで3台または5台に置くのが本番の基本形です。
一方で、移行を急がなくてよい構成もあります。Amazon MSKなどのマネージドサービスを使っていて、サービス側が2026年8月に提供を始めたin-place移行の枠内にいるなら、自前で工程を組む必要はありません。
KRaftの定義とメタデータ管理｜Raftログでクラスタ状態を持つ仕組み
KRaftという名前は「Kafka Raft」に由来します。ZooKeeperが担っていたブローカーの死活管理、パーティションのリーダー選出、トピック設定の保管を、Kafka自身の内部トピックへ移した設計です。Kafkaそのものの役割や用途はApache Kafkaの特徴とメリットの解説で整理しているため、ここではメタデータ層の構造に絞ります。
メタデータをイベントログで持つKRaftとZooKeeper構成の状態管理の差
ZooKeeper構成では、クラスタの状態はznodeという階層データとしてZooKeeper側に置かれ、Kafkaのコントローラがそれを読み書きしていました。KRaftでは同じ情報が__cluster_metadataという単一パーティションの内部トピックに、追記型のイベント列として積まれます。
この違いは復旧の速さに効きます。znode方式では、コントローラが切り替わるたびに全メタデータをZooKeeperから読み直していました。イベントログ方式なら、各ノードは読み終えたオフセットの続きだけを取り込めば済みます。メタデータログの置き場所はmetadata.log.dirで指定し、公式の運用ドキュメントはメモリとディスクにそれぞれ5GB程度を見込む記述を置いています。パーティション数が増えるほどログ量も増えるため、5GBは出発点の値です。
アクティブコントローラの選出と__cluster_metadataの複製の流れ
コントローラのうち1台がアクティブになり、メタデータログのリーダーとして書き込みを受け付けます。残りのコントローラはフォロワーとして複製を追いかけ、リーダーが落ちればRaftの投票でアクティブが入れ替わります。ZooKeeperのセッション切れを起点にした選出と違い、外部システムのタイムアウト設定に振り回されません。
ブローカー側はクォーラムに参加せず、オブザーバとしてメタデータログを購読します。kafka-metadata-quorum.shの出力にCurrentVotersとCurrentObserversが並ぶのはこのためです。投票権を持つのはコントローラだけ。この線引きが次章のprocess.rolesの設計に直結します。
KRaftクラスタの構成設定｜process.rolesとクォーラム設計の実装値
KRaftのクラスタ構築は、役割の指定・接続先の共有・ストレージの初期化という3段階で進みます。ZooKeeper構成のzookeeper.connectに相当する設定は存在せず、代わりにコントローラ群のアドレスを全ノードで揃えます。
process.rolesの3つの値と専用構成・combined構成の使い分け条件
process.rolesに指定できるのはbroker、controller、broker,controllerの3通りです。3つ目が両方を1プロセスで兼ねるcombined構成にあたります。
| 設定値 | 役割 | 想定する場面 |
|---|---|---|
| broker | データの読み書きを処理 | 本番のブローカーノード |
| controller | メタデータの管理と選出 | 本番の専用コントローラ（3台または5台） |
| broker,controller | 両方を1プロセスで兼務 | 開発環境・検証用の小規模構成 |
公式ドキュメントはcombined構成について、小規模な用途では運用が簡単になる一方、コントローラが他の処理から隔離されなくなる点を欠点として挙げています。ブローカー側の負荷でコントローラまで巻き添えになる構造のため、本番では分ける判断が基本です。開発環境の1ノード構成をそのまま本番へ持ち込み、負荷試験でメタデータ更新が詰まる失敗は避けられます。
controller.quorum.bootstrap.serversで揃える接続先
クラスタ内の全ノードが、コントローラの所在をcontroller.quorum.bootstrap.serversで知ります。書式はcontroller1.example.com:9093,controller2.example.com:9093,controller3.example.com:9093のようにホストとポートを並べる形です。あわせてcontroller.listener.namesにコントローラ用リスナー名（CONTROLLERなど）を指定し、リスナー定義側でそのポートを開けます。
各ノードの識別子はnode.idで与えます。ZooKeeper構成のbroker.idと自動採番のbroker.id.generation.enableは削除されたため、番号は運用側で管理する前提に変わりました。IaCで台帳を持たずに手で振っていると、ノード再作成時の重複で起動しなくなります。
kafka-storage.shでのクラスタID発行とストレージ初期化の手順
KRaftではログディレクトリの初期化が必須の工程になりました。クラスタIDを発行し、各ノードのディレクトリへ書き込んでから起動します。
kafka-storage.sh random-uuidでクラスタIDを1つ生成する- 最初のコントローラを
kafka-storage.sh format --cluster-id <ID> --standalone --config controller.propertiesで初期化する - 複数台を同時に立てる場合は
--initial-controllers "0@controller-0:1234:<ディレクトリUUID>,..."の形で構成を渡す - 後から加えるノードは
--no-initial-controllersを付けて初期化し、起動後にクォーラムへ参加させる
クラスタIDはクラスタ全体で1つです。ノードごとにrandom-uuidを実行して別々のIDを配ると、クォーラムが組めずに起動が止まります。手順書ではIDの生成を1回だけの工程として切り出しておきます。
コントローラ3台と5台で変わる障害耐性と必要なメモリ・ディスク量
公式の運用ドキュメントは、コントローラに3台または5台を選ぶのが一般的だと述べています。耐えられる同時障害は2N+1台構成でN台、つまり3台なら1台、5台なら2台です。
台数を増やすほど選出時の投票参加者も増えるため、無条件に多くすればよいわけではありません。ブローカーが10台規模までなら3台、リージョンをまたいで冗長化するなら5台が実務的な出発点になります。1台ずつのメモリとディスクは各5GB程度が目安で、ブローカーノードほどのリソースは要りません。
ZooKeeper構成からの移行手順｜3.9系ブリッジとデュアルライトの実務
既存クラスタの移行は、3.9系をブリッジとして通す設計です。ZooKeeper構成のまま4.x系へ上げる経路はないため、順序を守ります。
移行の前提となる3.9系へのアップグレードとプロトコル版の固定
公式の移行手順では、まずブローカーを3.9.1へ上げ、inter.broker.protocol.versionを3.9に設定した状態を作ります。ここでプロトコル版を固定しておかないと、移行の途中で切り戻す余地がなくなります。
4.x系ではinter.broker.protocol.versionそのものが削除され、metadata.versionが同じ役割を引き継ぎます。移行前後で設定名が入れ替わるため、Ansibleやconfigmapのテンプレートは両系統ぶん用意しておくと、設定ミスによる起動失敗を避けられます。
migration.enableを立てて入るデュアルライト状態の工程
移行の本体は、KRaftコントローラを既存クラスタと同じクラスタIDで立ち上げるところから始まります。コントローラ側にはzookeeper.metadata.migration.enable=trueとzookeeper.connectを設定し、既存のZooKeeperを参照させます。
次にブローカー側へcontroller.quorum.bootstrap.servers、controller.listener.names、zookeeper.metadata.migration.enable=trueを加えてローリング再起動します。最後のZooKeeperモードのブローカーが再起動された時点で、移行が自動的に始まる仕組みです。この段階がデュアルライトで、KRaftコントローラがメタデータの正本を持ちながら、ZooKeeperモードのブローカーへUpdateMetadataやLeaderAndIsrといった旧来のRPCを送り続けます。停止時間を確保する工程ではなく、ローリングで進められる点が実務上の利点です。
移行をファイナライズする手順と、切り戻しが不可能になる時点の見極め
デュアルライトの状態で運用に問題がないことを確認したら、KRaftコントローラの設定からzookeeper.metadata.migration.enableを外し、1台ずつ再起動してファイナライズします。完了後はZooKeeperクラスタを停止できます。
公式ドキュメントは、ファイナライズを終えた後にZooKeeperモードへ戻すことはできないと明記しています。途中段階でのロールバックは進行度に応じた手順が用意されていますが、ZooKeeperのepoch調整を伴うため手作業の比重が上がる設計です。したがって検証環境で本番相当のトピック数・パーティション数を再現し、デュアルライト状態での挙動を確認してからファイナライズへ進む段取りが要ります。移行工程の設計や検証環境の再現に人手が足りない場合は、データ分析基盤の構築・運用支援のような外部の設計支援を組み合わせる選択肢もあります。
移行後の検証観点｜metadata-quorumで確かめるクォーラムの健全性
移行後は、メタデータ層が正しく動いているかを自分で確かめる手段が要ります。ZooKeeperのCLIで見ていた情報は、すべてKafka側のツールへ移りました。
describe –statusで確かめるリーダーと追従遅延の判定基準
確認の起点はkafka-metadata-quorum.sh --bootstrap-server localhost:9092 describe --statusです。出力にはClusterId、LeaderId、LeaderEpoch、HighWatermark、MaxFollowerLag、CurrentVoters、CurrentObserversが並びます。
見るべきは3点に絞れます。CurrentVotersに想定したコントローラが全台並んでいるか、CurrentObserversに全ブローカーが現れているか、MaxFollowerLagが小さい値で安定しているか。LeaderEpochが短時間に何度も上がるようなら、コントローラ間の通信が不安定で選出が繰り返されている疑いがあります。移行直後の数日は、この出力を定期取得してログに残しておくと原因の切り分けが速くなります。
コントローラを止めずに入れ替えるadd-controllerの運用手順
クォーラムの構成は動的に変更できます。追加はkafka-metadata-quorum.sh --bootstrap-server localhost:9092 add-controllerを新ノード側の設定で実行し、削除はremove-controller --controller-id <id> --controller-directory-id <ディレクトリID>で対象を指定します。
削除にディレクトリIDまで要求されるのは、同じnode.idで再作成された別ノードを誤って外さないためです。インスタンス入れ替えの手順を書くときは、先にdescribeでディレクトリIDを控える工程を必ず挟みます。台数を保ったまま入れ替えるなら、追加してから削除する順序にすると、作業中も過半数を割りません。
ZooKeeper由来の監視項目を置き換えるメトリクスの入れ替え方針
ZooKeeperを外すと、そのセッション数やznode数を見ていたダッシュボードのパネルは値を返さなくなります。あわせて、複数のコントローラチャネル管理に関するメトリクスなど、ZooKeeper構成に紐づいていた指標も廃止されています。
置き換え先はメタデータログ側の指標です。クォーラムのリーダー変更頻度、MaxFollowerLag、メタデータ適用の遅延を軸に組み直します。ZooKeeperプロセスの死活監視をそのまま残して「常に異常」の警報を鳴らし続ける状態も起きがちなので、移行のファイナライズと同じ日に監視設定の棚卸しまで済ませる段取りが現実的です。Kafka Connectの構成とコネクタ運用を併用している場合は、コネクタ側のブートストラップ設定がブローカーを向いていることも確認対象に入ります。
既存クラスタでのKRaft採用判断｜移行を急ぐ条件と据え置いてよい場面
ここまでの工程を踏まえて、いつ動くかを決めます。運用形態によって妥当な時期は変わります。
4.x系へ上げる必要を決めるサポート対象バージョンの現状と期日
2026年8月30日に公式ダウンロードページを確認した時点で、サポート対象として掲示されているのは4.3.1（2026年6月25日）、4.2.1（2026年5月30日）、4.1.2（2026年3月17日）です。3.9系の最終パッチは3.9.2（2026年2月21日）で、アーカイブ側へ移っています。
この状態が意味するのは、ZooKeeper構成に留まる限り新しい脆弱性修正が届く保証が薄れるということです。金融・医療のように脆弱性対応の期限が契約で縛られる領域では、移行計画を年度内の課題として扱う判断になります。逆に社内向けの小規模なログ集約用途で、外部からの到達経路がない構成なら、次のインフラ更改に合わせる判断も成り立ちます。
移行を急がなくてよい構成と、いま踏み込むべきでない場面の条件
移行に踏み込むべきでない場面ははっきりしています。以下の条件に当てはまるなら、いま自前で工程を組む判断は見送ってよいと考えます。
- 本番相当のトピック数・パーティション数を再現できる検証環境が用意できない
- Kafkaクラスタの構成管理がIaC化されておらず、手作業のsshで設定を配っている
- 移行作業の期間中、切り戻し判断を下せる担当者を確保できない
- クラスタの入れ替え自体を半年以内に別要件で予定している
とくに1つ目は決定的です。ファイナライズ後に戻せない以上、本番でぶっつけ本番の工程を走らせる設計は成立しません。検証環境が作れないなら、先にそこへ投資する方が結果として早く終わります。4つ目に当てはまるなら、移行ではなく新クラスタを4.x系で立ててKafka互換ブローカーRedpandaの採用判断も含めて選び直し、データを流し替える設計の方が工程を減らせます。商用ディストリビューションへ寄せる選択肢も含めて比べるなら、Confluent Kafkaの構成差とライセンス境界の解説が判断材料になります。
マネージドKafkaを使う場合の判断とin-place移行が届く範囲
Amazon MSKを使っているなら、判断は自前運用とまったく違います。AWSは2026年8月10日に、既存のZooKeeperベースのクラスタを新しいインフラの作成やデータ移行、クライアント設定の変更なしでKRaftへ移せるin-place移行の提供を発表しました。移行中もクラスタは利用可能とされ、コンソール・CLI・APIから実行できます。
ブローカー数の上限もKRaft側が広く、ZooKeeper構成の30台に対してKRaftモードでは60台まで、申請なしで扱えます。マネージドを選んでいる場合はサービス側の手順に従うのが最短で、この記事の移行工程を自分で組む必要はありません。料金体系やブローカー種別の詳細はAmazon MSKの仕組みと料金の解説を参照してください。
よくある質問
KRaftの導入と移行について、設計時に判断へ迷いやすい点を5つ整理します。
KRaftモードは本番環境で使える段階にあると判断してよいですか？
2026年8月30日時点で公式がサポート対象として掲示している4.3.1・4.2.1・4.1.2は、いずれもKRaftのみの構成です。ZooKeeperを選べるバージョンがサポート対象から外れている以上、判断すべきなのは可否ではなく、いつどの手順で移すかになります。
ZooKeeperを残したまま4.0系へアップグレードできますか？
できません。4.0.0以降はZooKeeper関連の設定そのものが削除されており、zookeeper.connectを含む20以上の設定項目が受け付けられなくなります。ZooKeeper構成のクラスタは、いったん3.9.1へ上げてKRaftへの移行を完了させてから4.x系へ進む二段階の移行経路が前提です。順序を飛ばすと起動時に設定が弾かれます。
KRaftへの移行にサービスの停止時間はどの程度必要ですか？
公式の移行手順はローリング再起動を前提に書かれており、全体を止める工程は含まれていません。コントローラのプロビジョニング、ブローカーの再起動、ファイナライズの各段階を1台ずつ進める工程です。ただしパーティションのリーダー切り替えは発生します。停止時間の確保よりも、プロデューサ側のリトライ設定の点検に時間を割く方が実務では効きます。
コントローラはブローカーと同居させる構成で運用できますか？
process.roles=broker,controllerのcombined構成として起動できる仕組みです。公式ドキュメントは、開発環境のような小規模用途では運用が簡単になる一方、コントローラが他の処理から隔離されなくなる点を欠点として挙げています。ブローカー側の負荷やGCの停止がメタデータ管理に波及するため、本番では専用ノードへ分ける構成を採ります。
移行の途中で問題が起きた場合にZooKeeperへ戻せますか？
ファイナライズ前であれば戻せます。公式ドキュメントには進行度に応じたロールバック手順が用意されており、ZooKeeper側のepoch調整を伴う作業になります。一方、コントローラからzookeeper.metadata.migration.enableを外してファイナライズを終えた後は、ZooKeeperモードへの復帰はできません。切り戻しの判断は、この境界の手前で下す設計にします。
関連記事
- Apache Kafkaが選ばれる理由とは？特徴とメリットを徹底解説：Kafka本体の構成要素と用途を押さえられます。
- Kafka Connectとは？構成要素とコネクタ運用を実装視点で解説：移行後に点検が要るコネクタ側の運用をまとめています。
- RabbitMQとKafkaの違いとは？設計思想・性能・使い分けの判断基準：そもそもKafkaを選ぶべきかを、メッセージキューとの比較から検討できます。
- Redpandaとは？Kafka互換ブローカーの構造・ライセンス・採用判断：ZooKeeperもJVMも持たない代替ブローカーとの比較検討に使えます。
- Apache Pulsarとは？Kafkaとの構造差と採用判断を実装視点で解説：メタデータ管理の設計が異なる別系統の基盤です。
