第4章 KRaft モードの Kafka の使用


KRaft (Kafka Raft メタデータ) モードは、Kafka がクラスター管理のために依存していた ZooKeeper に代わるものです。KRaft モードは、メタデータ管理とクラスターの調整を Kafka に導入することで、Kafka クラスターのデプロイと管理を簡素化します。

KRaft モードの Kafka は、信頼性、スケーラビリティー、スループットの向上を実現するように設計されています。メタデータ操作が直接統合されるため、操作が効率化します。また、ZooKeeper クラスターを維持する必要がなくなるため、運用とセキュリティーのオーバーヘッドも削減されます。

Kafka 設定を通じて、ノードにブローカー、コントローラー、またはその両方のロールが割り当てられます。

  • コントローラー ノードは、コントロールプレーンで動作し、Raft ベースのコンセンサスプロトコルを使用してクラスターのメタデータとクラスターの状態を管理します。
  • ブローカー ノードは、データプレーンで動作し、メッセージのストリーミングを管理し、データを受信してトピックパーティションに保存します。
  • デュアルロール ノードは、コントローラーとブローカーの役割を果たします。

コントローラーの動的または静的クォーラムを使用できます。動的の場合、動的スケーリング がサポートされるため推奨されます。

コントローラーは、各ノードで単一パーティションのトピック (__cluster_metadata) として保存されるメタデータログを使用し、クラスターの状態を記録します。クラスター設定の変更要求が行われると、アクティブ (リード) コントローラーがメタデータログの更新を管理し、フォロワーコントローラーがこの更新をレプリケートします。メタデータログには、In-Sync レプリカの状態やパーティションリーダーシップなど、ブローカー、レプリカ、トピック、パーティションに関する情報が保存されます。Kafka はこのメタデータを使用して変更を調整し、クラスターを効率的に管理します。

ブローカーノードは、オブザーバーとして機能し、メタデータログをパッシブに保存して、クラスターの状態を最新の状態に保ちます。ノードはログの更新をそれぞれ個別に取得します。JBOD ストレージを使用している場合は、メタデータログを保存するディレクトリーを変更 できます。

注記

Kafka クラスターで使用される KRaft メタデータバージョンが、使用中の Kafka バージョンでサポートされている必要があります。

次の例では、Kafka クラスターは、フォールトトレランスと高可用性を実現するために、コントローラーノードとブローカーノードのクォーラムで構成されています。

図4.1 別々のブローカーノードとコントローラーノードを備えたクラスターの例

ブローカーとコントローラーの KRaft クォーラム

一般的な実稼働環境では、専用のブローカーノードとコントローラーノードを使用します。ただし、開発やテストのために、デュアルロール設定のノードを使用する必要がある場合があります。

複数の役割を兼ね備えるノードと 1 つの役割を果たすノードを組み合わせて使用できます。次の例では、3 つのノードが 2 つの役割 (デュアルロール) を果たし、2 つのノードがブローカーとしてのみ機能します。

図4.2 デュアルロールノードと専用ブローカーノードを備えたクラスターの例

複数のロールを兼ね備えるノードを備えた KRaft クラスター

4.1. KRaft モードへの移行

Kafka クラスターでのメタデータ管理に ZooKeeper を使用している場合は、KRaft モードで Kafka を使用するように移行できます。KRaft モードは ZooKeeper を置き換えて分散調整を行い、信頼性、スケーラビリティー、およびスループットを強化します。

クラスターを移行するには、次の手順を実行します。

  • クラスター管理用の ZooKeeper を置き換えるために、コントローラーノードのクォーラムをインストールします。
  • コントローラー設定で zookeeper.metadata.migration.enable プロパティーを true に設定して、KRaft の移行を有効にします。
  • コントローラーを起動し、同じ設定プロパティーを使用して現在のクラスターブローカーで KRaft の移行を有効にします。
  • ブローカーのローリング再起動を実行して、設定の変更を適用します。
  • 移行が完了したら、ブローカーを KRaft モードに切り替え、コントローラーで移行を無効にします。
重要

KRaft モードへの移行が完了すると、ZooKeeper へのロールバックができなくなります。移行を進める前に、この点を慎重に検討してください。

移行を開始する前に、ご使用の環境が KRaft モードの Kafka をサポートできることを確認してください。

  • 移行は専用コントローラーノードでのみサポートされ、broker と controller の二重のロールを持つノードではサポートされません。
  • 移行プロセス全体を通じて、ZooKeeper と KRaft コントローラーノードが並行して動作するため、クラスター内に十分なコンピュートリソースが必要です。
警告

以前に KRaft 移行をロールバックした場合は、再度移行を試みる前に、必要なクリーンアップ手順がすべて完了していることを確認してください。

  • 専用コントローラーノードが削除されている。
  • ZooKeeper の /migration znode は、zookeeper-shell.sh コマンド delete/migration を使用して手動で削除されている。

移行を再試行する前にこのクリーンアップを実行しないと、メタデータが失われ、移行エラーが発生する可能性があります。

前提条件

  • Red Hat Enterprise Linux に Kafka ユーザーとしてログインしている。
  • Streams for Apache Kafka が 各ホストにインストールされており、設定ファイルが使用可能である。
  • Kafka 3.7.0 以降と Streams for Apache Kafka 2.7 を使用している。以前のバージョンの Streams for Apache Kafka を使用している場合は、KRaft モードに移行する前にアップグレードしてください。
  • 移行プロセスを確認するためにログが有効になっている。

    クラスター内のコントローラーおよびブローカーのルートロガーに対して log4j.propertiesDEBUG レベルを設定してください。移行固有の詳細なログを取得するには、移行ロガーに TRACE を設定します。

    コントローラーロギング設定

    log4j.rootLogger=DEBUG
    log4j.logger.org.apache.kafka.metadata.migration=TRACE

手順

  1. Kafka クラスターのクラスター ID を取得します。

    zookeeper-shell ツールを使用します。

    ./bin/zookeeper-shell.sh localhost:2181 get /cluster/id

    このコマンドはクラスター ID を返します。

  2. KRaft コントローラークォーラムをクラスターにインストールします。

    1. controller.properties ファイルを使用して、各ホスト上でコントローラーノードを設定します。

      各コントローラーには少なくとも次の設定が必要です。

      • 一意のノード ID
      • 移行有効フラグの true への設定
      • ZooKeeper の接続の詳細
      • コントローラークォーラムが使用するリスナー名
      • コントローラーのクォーラム (動的設定を推奨)
      • ブローカー間通信のリスナー名

        コントローラー設定の例

        process.roles=controller
        node.id=1
        
        zookeeper.metadata.migration.enable=true
        zookeeper.connect=zoo1.my-domain.com:2181,zoo2.my-domain.com:2181,zoo3.my-domain.com:2181
        
        listeners=CONTROLLER://0.0.0.0:9090
        controller.listener.names=CONTROLLER
        listener.security.protocol.map=CONTROLLER:PLAINTEXT
        controller.quorum.bootstrap.servers=localhost:9090
        inter.broker.listener.name=PLAINTEXT

        コントローラークォーラムの形式は、コンマ区切りリストの <node_id>@<hostname>:<port> です。KRaft コントローラーが移行を開始するには、ブローカー間リスナー名が必要です。

    2. 各コントローラーノードのログディレクトリーをセットアップします。

      ./bin/kafka-storage.sh format -t <uuid> -c ./config/kraft/controller.properties

      戻り値:

      Formatting /tmp/kraft-controller-logs

      <uuid> は、取得したクラスター ID に置き換えます。クラスター内の各コントローラーノードに同じクラスター ID を使用します。

      デフォルトでは、controller.properties 設定ファイルで指定されたログディレクトリー (log.dirs) は /tmp/kraft-controller-logs に設定されます。/tmp ディレクトリーは通常、システムが再起動するたびにクリアされるため、開発環境のみに適しています。必要に応じて、コンマ区切りリストを使用して複数のログディレクトリーを設定します。

    3. 各コントローラーを起動します。

      ./bin/kafka-server-start.sh -daemon ./config/kraft/controller.properties
    4. Kafka が稼働していることを確認します。

      jcmd | grep kafka

      戻り値:

      process ID kafka.Kafka ./config/kraft/controller.properties

      各コントローラーのログをチェックして、KRaft クラスターに正常に参加していることを確認します。

      tail -f ./logs/controller.log
  3. 各ブローカーで移行を有効にします。

    1. 実行中の場合は、ホスト上で実行している Kafka ブローカーを停止します。

      ./bin/kafka-server-stop.sh
      jcmd | grep kafka

      マルチノードクラスターを使用する場合は、「Kafka ブローカーの正常なローリング再起動の実行」 を参照してください。

    2. server.properties ファイルを使用して移行を有効にします。

      各ブローカーには少なくとも次の追加設定が必要です。

      • ブローカー間プロトコルバージョンをバージョン 3.9 に設定する
      • 移行有効フラグ
      • コントローラーノードと一致するコントローラー設定
      • コントローラーのクォーラム

      ブローカー設定の例

      broker.id=0
      inter.broker.protocol.version=3.9
      
      zookeeper.metadata.migration.enable=true
      zookeeper.connect=zoo1.my-domain.com:2181,zoo2.my-domain.com:2181,zoo3.my-domain.com:2181
      
      listeners=CONTROLLER://0.0.0.0:9090
      controller.listener.names=CONTROLLER
      listener.security.protocol.map=CONTROLLER:PLAINTEXT
      controller.quorum.bootstrap.servers=localhost:9090

      ZooKeeper の接続の詳細はすでに存在するはずです。

    3. 更新したブローカーを再起動します。

      ./bin/kafka-server-start.sh -daemon ./config/kraft/server.properties

      移行は自動的に開始しますが、クラスター内のトピックとパーティションの数によっては時間がかかる場合があります。

    4. Kafka が稼働していることを確認します。

      jcmd | grep kafka

      戻り値:

      process ID kafka.Kafka ./config/kraft/server.properties
  4. アクティブなコントローラーのログをチェックして、移行が完了したことを確認します。

    ./bin/zookeeper-shell.sh localhost:2181 get /controller

    Completed migration of metadata from ZooKeeper to KRaft. という INFO ログエントリーを探します。

  5. 各ブローカーを KRaft モードに切り替えます。

    1. 前述の手順と同様にブローカーを停止します。
    2. server.properties ファイル内のブローカー設定を更新します。

      • broker.id を、同じ ID を使用する node.id に置き換えます。
      • ブローカーの broker KRaft ロールを追加します。
      • ブローカー間プロトコルバージョン (inter.broker.protocol.version) を削除します。
      • 移行有効フラグ (zookeeper.metadata.migration.enable) を削除します。
      • ZooKeeper 設定を削除します。
      • コントローラーおよびブローカー通信用のリスナー (control.plane.listener.name) を削除します。

      KRaft のブローカー設定の例

      node.id=0
      process.roles=broker
      
      listeners=CONTROLLER://0.0.0.0:9090
      controller.listener.names=CONTROLLER
      listener.security.protocol.map=CONTROLLER:PLAINTEXT
      controller.quorum.bootstrap.servers=localhost:9090

    3. ブローカー設定で ACLS を使用している場合は、authorizer.class.name プロパティーを使用して、オーソライザーを KRaft ベースの標準オーソライザーに更新します。

      ZooKeeper ベースのブローカーは authorizer.class.name=kafka.security.authorizer.AclAuthorizer を使用します。

      KRaft ベースのブローカーに移行する場合は、authorizer.class.name=org.apache.kafka.metadata.authorizer.StandardAuthorizer を指定します。

    4. 前述の手順と同様にブローカーを再起動します。
  6. 各コントローラーを移行モードから切り替えます。

    1. ブローカーと同じ前述の方法でコントローラーを停止します。
    2. controller.properties ファイル内のコントローラー設定を更新します。

      • ZooKeeper 接続の詳細を削除します。
      • zookeeper.metadata.migration.enable プロパティーを削除します。
      • inter.broker.listener.name を削除します。

      移行後のコントローラー設定の例

      process.roles=controller
      node.id=1
      
      listeners=CONTROLLER://0.0.0.0:9090
      controller.listener.names=CONTROLLER
      listener.security.protocol.map=CONTROLLER:PLAINTEXT
      controller.quorum.bootstrap.servers=localhost:9090

    3. ブローカーと同じ前述の方法でコントローラーを再起動します。

4.1.1. 移行時のロールバックの実行

移行を完了した場合、ロールバックはできません。

移行を完了する前で、クラスターがまだ移行モードの場合に、ZooKeeper モードにロールバックできます。手順は、移行がどの程度進んでいるかによって異なります。

  • 準備とコントローラークォーラムのセットアップのみを完了している場合は、専用の KRaft コントローラーノードを停止してクラスターから削除します。その他の変更は必要なく、クラスターは ZooKeeper モードで引き続き動作します。
  • ブローカーでメタデータの移行を有効にしている場合は、次の手順に従います。

    1. 専用の KRaft コントローラーノードを停止し、クラスターから削除します。
    2. zookeeper-shell.sh を使用して次の操作を実行します。

      • delete/controller を実行して、ZooKeeper ベースのブローカーがアクティブコントローラーになることを許可します。
      • get/migration を実行し、次に delete/migration を実行して、移行メタデータ (znode に保存されている) を検査して消去します。これにより、移行を再試行するために ZooKeeper の初期状態に復元されます。
      警告

      コントローラーのダウンタイムを最小限に抑えるには、delete/controller をすぐに実行してください。ロールバックが完了するまで、ブローカーログに一時的なエラーが発生する可能性があります。

    3. 各ブローカーで以下を行います。

      • 次の KRaft 関連の設定を削除します。

        • zookeeper.metadata.migration.enable
        • controller.listener.names
        • controller.quorum.bootstrap.servers
      • node.idbroker.id に置き換えます。
    4. すべてのブローカーのローリング再起動を実行します。
  • ブローカーを KRaft に移行し始めた場合は、次の手順に従ってください。

    1. 各ブローカーで以下を行います。

      • process.roles を削除します。
      • node.idbroker.id に置き換えます。
    2. zookeeper.connect と必要な ZooKeeper 設定を復元します。
    3. ブローカーの最初のローリング再起動を実行します。

      重要

      最初の再起動では zookeeper.metadata.migration.enable=true は維持されます。

    4. 専用の KRaft コントローラーノードを停止し、クラスターから削除します。
    5. zookeeper-shell.sh を使用して次の操作を実行します。

      • delete/controller を実行して、ZooKeeper ベースのブローカーがアクティブコントローラーになることを許可します。
      • get/migration を実行し、次に delete/migration を実行して、移行メタデータ (znode に保存されている) を検査して消去します。これにより、移行を再試行するために ZooKeeper の初期状態に復元されます。
    6. 各ブローカーで、KRaft 関連の設定を削除します。

      • zookeeper.metadata.migration.enable
      • controller.listener.names
      • controller.quorum.bootstrap.servers
    7. ブローカーの 2 回目のローリング再起動を実行します。
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hat
トップに戻る