Contents
Kafka KRaft 移行 手順：Red Hatドキュメントに基づく実務ガイド
Kafkaの運用において、Zookeeper依存を解消するKRaftモードへの移行は今後の安定性向上に不可欠です。本記事では、Red Hat公式ドキュメントに基づいたステップバイステップガイドを提供し、移行手順や環境構成のポイントを明確にします。
導入：KRaftモード移行の概要
KafkaのKRaftモードは、クラスターコントロールをZookeeperから直接Kafka自身が管理する仕組みです。これにより高可用性の向上や運用簡略化が可能になります。一方で、Zookeeperとの同時運用は非推奨であり、移行計画を慎重に立案することが求められます。
本記事では、公式ドキュメントに記載された最新手順をもとに、移行前の環境確認から移行後の検証までを解説します。ITエンジニアやDevOps担当者が実務で導入する際の参考にしてください。
移行前の環境確認：KRaft対応の前提条件
KRaftモード移行を行う前に、クラスターが対応可能な環境かを明確にすることが重要です。以下に必要となる項目を整理し、公式ドキュメントとの整合性を確認してください。
環境要件の一覧と確認ポイント
- OS/コンテナの互換性
- RHEL 8.6以上や同等のLinuxディストリビューションで運用が可能
-
SELinuxおよびfirewalldの有効性を確認（セキュリティポリシーに注意）
-
Javaバージョンの対応
- OpenJDK 17またはOracle JDK 17の導入が必要（Kafkaバージョンに合わせて選択）
| 項目 | 要件 | 補足 |
|---|---|---|
| OS | RHEL 8.6以上、または同等のLinuxディストリビューション | SELinuxおよびfirewalldが有効な状態で運用可能 |
| コンテナ | Docker Engine 24.x以上、Kubernetes 1.25以上 | マイクロサービス構成時の互換性を確認 |
| Java | OpenJDK 17 or Oracle JDK 17 | Kafkaバージョンに応じたバージョン確認が必要 |
Red Hat公式ドキュメントでは、KRaftモードの前提となるシステム要件が明示されているため、事前にRed Hat Documentationで最新情報を確認してください。
ローリング再起動によるブローカー移行手順
クラスターを停止せずにKRaftモードへ切り替えるには、ローリング再起動が推奨されます。以下に具体的な実施手順と注意点を示します。
移行の基本ステップ
- Zookeeperとの接続解除
config/zoo.cfgでZookeeper接続設定をコメントアウト- KRaftモード用設定ファイル作成
kraft-start-distributed.shを使用し、--cluster-idと--controller-listを指定- ブローカーの順次停止・再起動
- 各ノードで
bin/kafka-server-stop.sh実行後、bin/kafka-server-start.sh config/server.propertiesでKRaftモード起動
移行時の注意事項
- コントローラーの冗長化設計
- ローリング再起動中に複数ノードでのコントローラー稼働を避け、別ノードに分散配置することを推奨します。
Red Hat公式ドキュメントでは、移行中のコントローラーの冗長性確保が重要であると強調しています。詳しくはRed Hat Documentationをご参照ください。
デュアルモードでの移行期間の運用考慮点
KRaftモードへの移行中は、Zookeeperとの共存状態（デュアルモード）が発生しますが、これを適切に管理しないとリスクが発生します。以下に具体的な問題点と対策を示します。
デュアルモード運用の主なリスク
- データ整合性の不安
-
Zookeeperに残るメタ情報とKRaft側で生成された情報の衝突を防ぐため、監視ツールでのリアルタイムログ確認が必要
-
パフォーマンス劣化
- ブローカーが両モード間で切り替え動作を行う際、レプリケーション遅延が発生するケースあり
移行期間の管理方針
- 移行時間制限
- Red Hat公式ドキュメントでは、デュアルモード期間は「最大24時間以内に完了させる」ことを推奨しています。この間に障害が発生した場合は即時停止と再評価を実施してください。
デュアルモード期間中のクラスター状態のリアルタイム監視は、移行の成功確率を高めるために不可欠です。監視ツールを活用し、異常検知に努めてください。
コントローラー専用ノード構成の重要性
KRaftモードにおいては、コントローラー機能が独立して運用されるため、適切な構成設計が求められます。以下の要点を押さえることで、冗長化と負荷分散を実現できます。
コントローラー専用ノードの設計ポイント
- 最低3ノードでの冗長化
-
フェールオーバー時の可用性確保と負荷分散
-
セキュリティ設定再確認
- クラスターコントローラーの接続先IPや認証方式を明確にし、ネットワーク層でのアクセス制限を実施
コントローラー専用ノードは、通常のブローカーとは物理的に分離すること。これにより、負荷集中を防ぎ、クラスター全体の安定性が向上します。
移行後の検証チェックリストと今後の対応
移行後にクラスターが正常に動作しているか確認するためには、以下の手順で検証を行ってください。また、公式ドキュメントとの整合性を定期的に確認することが重要です。
移行後の検証ポイント
- メッセージの正常な送信・受信
-
生産者/コンシューマーでのトランザクション確認（
kafka-producer-perf-test.sh,kafka-consumer-perf-test.shを使用） -
監視ツールでのクラスター状態確認
-
Prometheus + Grafanaで、CPU使用率やディスクI/Oの異常値をモニタリング
-
公式ドキュメントとの整合性チェック
bin/kafka-metadata-check.sh --cluster-id <CLUSTER_ID>により設定が正しいか確認
移行後は、少なくとも1週間の監視期間を設け、異常動作が発生していないかを継続的に観察してください。
まとめ
KRaftモード移行は複雑なプロセスであり、以下の点に注意しながら計画を立てることが求められます：
- 事前準備（OS環境確認、Javaバージョンチェック）
- ローリング再起動による可用性保証
- デュアルモード期間のリスク管理と監視体制
- コントローラー専用ノード構成による冗長化設計
- 移行後の検証チェックリストに基づく異常検知
Red Hat公式ドキュメントに則った実務ガイドとして、本記事を参考にしながらKafkaクラスターの安定性と運用効率化を図ってください。