Kafka ZooKeeper接続問題の徹底解説
Apache Kafkaは、クラスタ調整、メタデータ管理、リーダー選出、設定保存のためにApache ZooKeeperに大きく依存しています。KafkaブローカーがZooKeeperへの接続を失うと、ブローカーは正しく機能しなくなり、自身を登録したり、リーダー選出リクエストに応答したり、トラフィックを提供したりできなくなります。この不安定さは、しばしばNoControllerEpochエラー、頻繁なブローカー再起動、またはパーティションの利用不可として現れます。
このガイドは、KafkaブローカーとそのZooKeeperアンサンブル間の永続的な接続問題を診断および解決するための包括的なトラブルシューティングマニュアルとして機能します。安定した高スループットの分散イベントストリーミングプラットフォームを維持するためには、これら2つのシステム間の相互依存性を理解することが不可欠です。
KafkaとZooKeeperの関係性の理解
接続性のトラブルシューティングを行う前に、KafkaがなぜZooKeeperを必要とするのかを認識することが不可欠です。ZooKeeperはクラスタメタデータの単一の信頼できる情報源として機能します。具体的には、KafkaはZooKeeperを以下の目的で使用します。
- ブローカー登録: ブローカーは起動時にZooKeeperに自身を登録します。
- トピック設定: パーティション割り当て、レプリカ配置、設定の上書きを保存します。
- コントローラー選出: パーティションとブローカーステータスの管理を担当するKafkaコントローラーを選出し、維持します。
ブローカーがZooKeeperへの接続をセッションタイムアウト設定を超えて長時間失った場合、最終的にシャットダウンするか孤立し、クラスタパフォーマンスの低下や完全な障害につながります。
フェーズ1: 設定の検証
ZooKeeper接続問題のほとんどは、Kafkaクライアント設定またはZooKeeperサービス設定自体の設定ミスに起因します。必ずここから開始してください。
1. Kafkaブローカー設定（server.properties）の確認
ZooKeeperアンサンブルを指す接続文字列が、すべてのブローカーから正しく、アクセス可能であることを確認します。
zookeeper.connect パラメータ
このプロパティには、アンサンブル内のすべてのZooKeeperサーバーのホスト名/IPとポートをカンマ区切りでリストする必要があります。カスタムルートパスを使用しない限り、Znodeパスを含めるべきではありません。
設定例:
# アンサンブルメンバーをすべてリストする
zookeeper.connect=zk01.example.com:2181,zk02.example.com:2181,zk03.example.com:2181
# オプション: 接続タイムアウトを設定する（デフォルトは6秒）
zookeeper.connection.timeout.ms=6000
Znodeパスの指定
Kafkaが特定のZnodeパス（例：/kafka）を使用するように設定されている場合は、このパスがZooKeeper内に存在し、Kafka設定で正しく設定されていることを確認してください。
# 特定のパスを使用する場合は、ここに記載されていることを確認する
zookeeper.connect=zk01:2181,zk02:2181/kafka
2. ZooKeeperサーバー設定（zoo.cfg）の確認
ZooKeeper自体の使用ポートを確認します。デフォルトのリスニングポートは2181です。
ZooKeeperアンサンブルが標準以外のポートで実行されている場合は、Kafkaブローカーがserver.propertiesでこれらのポートに一致するように設定されていることを確認してください。
フェーズ2: ネットワークとファイアウォールの診断
KafkaブローカーとZooKeeperノード間の接続問題は、ネットワークの中断や制限的なファイアウォールルールによって頻繁に発生します。
1. 基本的な接続テスト
標準的なツールを使用して、KafkaブローカーとZooKeeperアンサンブルの各メンバーとの間でポートが開いており、到達可能であることを検証します。
nc (Netcat) または telnet の使用:
このコマンドを各Kafkaブローカーから各ZooKeeperノードに対して実行します。
# zk01のポート2181への接続性をテスト
telnet zk01.example.com 2181
# または
nc -zv zk01.example.com 2181
接続が成功した場合、ポートが開いていることを示します。これが失敗した場合は、ファイアウォールルール（iptables、セキュリティグループなど）を調査してください。
2. 遅延とジッターの分析
高いネットワーク遅延やパケット損失は、ポートが開いていても接続タイムアウトを引き起こす可能性があります。ZooKeeperは遅延に非常に敏感です。
ヒント: pingを使用して往復時間（RTT）を確認します。RTTが継続的に50msを超える場合は、KafkaブローカーをZooKeeperアンサンブルの近くに移動するか、基盤となるネットワークの輻輳を調査する必要があるかもしれません。
フェーズ3: サービスとセッションタイムアウトのトラブルシューティング
ZooKeeperはセッションを管理するために時間ベースのメカニズムを使用します。クライアント（Kafkaブローカー）がセッションタイムアウト期間内にハートビートを送信できない場合、ZooKeeperはそのセッションを期限切れにし、ブローカーに再接続またはシャットダウンを試行させます。
1. ZooKeeperセッションタイムアウトの設定
セッションの安定性を管理する主要なパラメーターは次のとおりです。
zookeeper.session.timeout.ms(Kafka): KafkaがZooKeeper接続が無効であると見なし、リカバリ/シャットダウンを開始するまでの待機時間。デフォルトは通常6000ms（6秒）です。tickTime(ZooKeeperzoo.cfg): ハートビートとタイムアウトに使用される時間計算の基本単位。デフォルトは通常2000ms（2秒）です。
Kafkaのセッションタイムアウトは、ZooKeeperのtickTimeに基づいて計算されます。Kafkaクライアントの最大セッションタイムアウトは、通常 $2 \times \text{tickTime}$ です（ただし、Kafkaのデフォルトセッションタイムアウトは内部的または設定で明示的に高く設定されていることがよくあります）。
高負荷時の頻繁な切断が観察される場合は、Kafkaのserver.propertiesでzookeeper.session.timeout.msを増やすか、ZooKeeperのzoo.cfgでtickTimeを増やす必要がある場合がありますが、Kafkaの設定との互換性を確保してください。
警告: ZooKeeperの
tickTimeの変更には、すべてのZooKeeperアンサンブルメンバーを順次再起動する必要があり、ピーク時間を避けて慎重に行う必要があります。
2. ブローカーログのエラー分析
Kafkaサーバーログは、接続損失を診断するための決定的な情報源です。ZooKeeperとの相互作用に関連するパターンを探します。
| ログメッセージパターン | 意味 |
|---|---|
[Controller node: ... ] Lost connection to ZooKeeper. |
セッションが期限切れになったか、ネットワークに障害が発生しました。 |
[Controller node: ... ] Reconnecting to ZooKeeper... |
一時的な切断。遅延が低い場合は回復可能である可能性が高いです。 |
[Controller node: ... ] Could not connect to ZooKeeper |
初期接続の失敗。通常はホスト名/ポートが間違っているか、ファイアウォールの問題です。 |
[SessionExpiredError] |
ZooKeeperがハートビート不足により接続を明示的に閉じました。 |
頻繁にLost connectionメッセージが表示される場合は、タイムスタンプ間の差を確認します。それらが定期的に（例：6秒ごと）発生する場合、それはネットワークジッターやブローカーのリソース枯渇によるハートビート失敗を直接示しています。
3. ブローカーリソースの競合
Kafkaブローカーが過度の負荷（CPU飽和や高いI/O待機）下にある場合、プロセスが時間内にZooKeeperにハートビートを送信できず、ネットワーク経路がクリーンであってもセッション期限切れにつながる可能性があります。
確認すべきアクション: 接続が切断されたときに、KafkaブローカーのCPU使用率とガベージコレクション（GC）一時停止を監視します。長いGC一時停止は、ハートビートスレッドが期限を逃す原因となる可能性があります。
フェーズ4: クラスタの回復とベストプラクティス
再起動戦略
接続問題が特定され修正された場合（例：ファイアウォールルールが更新された）、ブローカーは再接続する必要があります。Kafkaサービスの再起動は、クリーンな再接続試行を強制する最も速い方法であることがよくあります。
# systemdを使用するシステムでの例
sudo systemctl restart kafka
安定性のためのベストプラクティス
- クォーラム管理: 分割脳シナリオを回避し、クォーラム機能を維持するために、常に奇数（3または5）のZooKeeperノードを実行します。
- 専用ネットワーク: 可能な場合は、KafkaブローカーとZooKeeperノードを低遅延の専用ネットワークセグメントに配置します。
- 設定の一貫性: すべてのKafkaブローカーがまったく同じ
zookeeper.connect文字列を使用していることを確認します。一貫性のない文字列は、ブローカーが無効なサーバーに接続しようとする原因になります。 - 監視: ZooKeeperの遅延とKafkaブローカーの
[Lost connection]ログについて、プロアクティブな監視を実装します。ユーザーからの苦情を待ってからこれらの問題を検出しないでください。
設定を体系的に検証し、ネットワークパスをテストし、ZooKeeperのハートビート設定に関連してセッションタイムアウトを調整することで、永続的なKafka ZooKeeper接続問題の大部分を解決し、信頼性の高いクラスタ運用を確保できます。