トップ > Apache Kafka > Zookeeper から KRaft モードへの移行

Zookeeper から KRaft モードへの移行

Apache Kafka Middleware OpenShift Red Hat Application Foundations Red Hat AMQ Streams

Streams for Apache Kafka の リリースサイクルと Zookeeper のサポートについて

レッドハットのソリューションアーキテクトの森です。

Red Hat の Apache Kafka 製品「Streams for Apache Kafka」(旧 Red Hat AMQ Streams) は、2025年3月に LTS版の 2.9 をリリースしました。 このバージョンでは Zookeeper も KRaft も両方サポートされていますが、次のバージョン（3.0）から Zookeeper のサポートが終了する予定です。

そのため、2.9 以降に Kafka クラスタを新たに構築する場合や、既存の Zookeeper モードを継続利用している場合でも、KRaft モードへの移行が必須となってきます。

access.redhat.com

ZookeeperとKRaftの違いとは？

従来の Apache Kafka は、クラスタのメタデータ管理に外部の Zookeeper を必要としていました。 KRaft（Kafka + Raft）はこれを置き換えるもので、Kafka 自身がクラスタの構成・状態管理を内包するアーキテクチャです。 （Raftとは、分散システムにおけるコンセンサスアルゴリズムの一種ですが、詳細についてはここでは割愛します）

KRaft モードに移行すると、主に以下のメリットがあります。

  • 構成がシンプルに
    • Kafka のみでクラスタ管理が完結し、Zookeeper の構築や監視が不要になります。
  • 可観測性とデバッグ性が向上
    • メタデータが Kafka 内部に統合されているため、Kafka の API やログからクラスタ状態を一貫して確認可能です。
  • 高可用なメタデータ管理
    • Raft アルゴリズムによりメタデータが複製され、リーダー障害時も高速にフェイルオーバーします。

KRaftモードにおける2種類のKafka Node管理

KRaftモードにおいて、Kafkaクラスターの各Nodeには、BrokerロールもしくはControllerロール、あるいはその両方のどちらかが割り当てれられます。

  • Broker ロール
    • メッセージの受信・送信・ログ保存を担当
    • パーティションデータのレプリケーションを行い、可用性を確保
  • Controller ロール
    • クラスタ構成のメタデータを管理（トピック作成・ISR更新・リーダー選出 など）
    • 3台構成が一般的で、1台が Active Controller に選出
    • Raftアルゴリズムにより、3台の間で強い整合性を持ってメタデータを複製

この構成により、トピック作成やパーティション移動などのメタデータ操作は Controller ノードが一元的に担当し、Broker はデータ処理に専念できます。

下の図は、KRaftモードにおいて、BrokerとControllerを分離した構成と、BrokerとControllerを兼任するNodeがある場合の構成です

  • BrokerとControllerを分離した構成

  • BrokerとControllerを兼任するNodeがある場合の構成

Streams for Apache Kafka on OpenShift での KRaft モード移行手順

ここでは、実際にStreams for Apache Kafka on OpenShift において、KRaftモードに移行するための手順をご紹介します。

まだ移行が完了していない場合、Kafka クラスターのカスタムリソースにKRaftへの移行に関するWarning通知が表示されるようになっています。

手順1. KafkaNodePool (broker ロール) の作成

  • name: kafka にすること（PVC の再利用ができず、データが消失してしまいます）
  • replicas, storage は 移行対象の Kafkaクラスター の カスタムリソース の内容と完全に一致させる

手順2. Kafkaクラスターのカスタムリソース に strimzi.io/node-pools アノテーションを追加

以下のアノテーションを Kafkaクラスターのカスタムリソース に追加します。

  • KafkaNodePool を使った管理に切り替える宣言
    • このアノテーションを 追加するだけでは KRaft移行 はまだ始まらない
metadata:
  annotations:
    strimzi.io/node-pools: enabled

手順3. Kafkaクラスターのカスタムリソース から不要な設定を削除

  • これらは KafkaNodePool 側に管理を移すため削除が必要です
spec.kafka.replicas
spec.kafka.storage
spec.kafka.config.inter.broker.protocol.version

手順4. KafkaNodePool (controller ロール) の作成

  • name : controller で作成する
    • 名前は任意だが、クラスタ YAML 内の可読性や整合性のため controller が推奨
  • Storage は既存zookeeperの設定と一致させる必要はない。少し余裕をもって 10〜20Gi程度にしておく

手順5. Kafkaクラスター の カスタムリソース に strimzi.io/kraft　アノテーションを追加

  • 下記アノテーションを追加することで、KRaftモードへの移行がスタートします
metadata:
  annotations:
    strimzi.io/kraft: migration

手順6. 数分待機し、移行の完了を待つ

KafkaMetadataState: KRaftPostMigration になったらKRaftへの移行完了です。

手順7. Kafka クラスターのカスタムリソース の strimzi.io/kraft アノテーションを更新して移行完了を宣言する

  • これで完全に KRaft に移行完了を宣言します
  • 宣言後は、Zookeeperを使った管理にはロールバックができなくなります
metadata:
  annotations:
    strimzi.io/kraft: enabled
    strimzi.io/node-pools: enabled

手順8. Kafka クラスターのカスタムリソース から不要な spec.zookeeper を削除

手順9. zookeeperで使用していた PVC も不要になるので削除しておく

手順10. KRaft移行した Kafka クラスターのコンディションを確認し、Warning通知がないことを確認

参考情報

今回はOpenShiftのKafka Operatorを使用したKRaftモードへの移行についてご紹介しました。Streams for Apache kafka を RHEL上でご利用の場合は、マイグレーションの手順が異なりますので、RHEL版のマイグレーション手順のドキュメントをご確認頂ければと思います。

  • on OpenShift でのマイグレーション手順

docs.redhat.com

  • on RHEL でのマイグレーション手順

docs.redhat.com

終わりに

いかがでしたでしょうか？

Red Hat Streams for Apache Kafka は、次のメジャーリリース（3.0）で Zookeeper のサポートが終了予定です。 今後も Kafka を安定的に活用していくためには、KRaft モードの理解と早めの移行準備が重要になります。

本記事や公式ドキュメントを参考に、今のうちから構成や移行手順を見直しておくことをぜひご検討ください。

なお、KRaft への移行に関する具体的な技術検討や、より詳細な構成相談などが必要な場合は、Red Hat からの技術支援も提供可能です。お気軽に担当営業までお問い合わせいただければと思います。

* 各記事は著者の見解によるものでありその所属組織を代表する公式なものではありません。その内容については非公式見解を含みます。