kafka環境設定とzookeeperの説明（kafka、 zookeeper、 akhq、 quorum controller）

こんにちはcodeshowです。
今回はkafkaを練習します。

練習のためには、 codeshow githubのdevcontainers repositoryをcloneしてください。
kafkaフォルダからvscodeを実行してください。
devcontainersを実行してください。
container実行されるまでお待ちください。
containerが実行されたらdocker desktop を開きます。
3つのkafkaとzoo keeper AKHQが実行されます。

これらのコンテナを説明すると、
zoo keeper はdistribution system coordinatorです。
分散環境で複数のkafkaを管理します。

AKHQは、 kafkaを便利に管理するためのweb UIを提供しています。
8080 port を使用します。

zookeeperは定期的にすべてのkafkaノードに heart beat シグナルを飛ばします。 zookeeperはping要求、カフカはpong応答をします。一部のkafkaノードが応答しない場合、 zookeeperはそのkafkaノードを障害と見なします。

もし3回kafkaが障害になった場合、
ping、 pongは失敗し、
zookeeperは 3 回kafkaを管理ノードから削除します。
そして、残りのkafka 1と2に3番ノード障害を通知し、 kafka 1と2はもはや3と通信しません。
ちなみにkafka3が再生成されると、図のようにzookeeperに登録され、再びkafka 1、2、3はclusterになります。

ちなみに、実習ではzookeeperは一台だけ
図のように、 production環境では複数のzookeeperノードをインストールします。
zookeeper 1 つがダウンしても、サービスは動作できるように構成します。
授業では運用環境のような高可用性が不要なので、1つのzookeeperだけを使います。

browserでAKHQが提供するNodesメニューに入ります。
画面には合計3つのkafkaノードが実行しています。

docker desktopでkafka2を停止します。
AKHQのノードメニューに戻ってリフレッシュすると、
kafka2が消えたことを確認できます。
再度docker desktopでstartボタンを押します。
kafkaがロードされるのを待ってからAKHQのNodes画面を更新します。
kafka2が再び画面に表示されます。
このkafkaノードの中でcontrolノードを停止します。
既存のcontrolノードがhealth checkに失敗すると、他のノードがcontrolノードになることを確認できます。

kafkaは、分散環境でノード間の調整をzookeeperが担当します。
devcontainer設定でzookeeperのadmin server設定をtrueにしたので、
私たちはブラウザを介して8081portでzookeeper情報を見ることができます。

ブラウザでlocalhostコロン 8081 slash commandsをアドレスとして入力します。

commandsページでは、 zookeeperが提供するコマンドをリンクとして表示できます。
connectionsリンクを選択します。

http://localhost:8081/commands/connections

connectionsで照会したjsonデータを使用して、 zookeeperに関連付けられているkafkaノードの情報を確認できます。

この IP がkafkaノードが正しいかdocker containerに入って確認しましょう。

hostname -I

zookeeper connection 情報とkafkaノードの IP が一致することを確認できます。
connections配列にはkafkaノード 3 つの connection 情報を確認できます。
今では、合計3つのkafkaノードが定期的にpingチェックをしていることを確認できます。
先に図で説明したように、
zookeeperはping、 pongが失敗すると失敗したノードの情報を別のkafkaノードに渡して
残りの2つのkafkaノードは、もはや失敗したノードと通信しません。
そしてzookeeperに再びkafkaノードが生きてping、 pongが成功すれば、
残りの2台のノードに再びこの情報を伝播し、このkafkaノードは新しいノードと通信します。

さらに、すべてのkafkaノードは本質的に1つのcontrollerを必要とします。
このコントローラノードは、他のkafkaノードを管理制御する非常に重要なノードです。
zookeeperを使用する場合、 kafkaノードのうち 1 台だけが controller ノードになることができます。
この1台のcontrollerノードが障害時にすべてのkafka clusterは動作できません。
したがって、コントローラノードが故障した場合、他のkafkaノードの1つがコントローラノードとして選択される必要があります。
このとき、ノード間で投票を通じて選出されますが、この過程にzookeeperが関与します。
したがって、 zookeeperはkafka分散システムで重要な役割を果たします。
ちなみに、controllerノードを除く残りのノードはbrokerノードと呼ばれます。次のクラスで学習するpartitionを格納するノードは、 brokerノードで担当します。 controller ノードは、 brokerノードが使用する複数のメタデータを保存し、 brokerノードを管理します。

参考までに、 kafkaはバージョン2.8.0以降のquorumコントローラーを提供しています。
これは、 zookeeperでkafkaを調整せず、 KRaftprotocolを介してzookeeperを使用せずにkafkaノードから直接kafka metadataを管理します。
特徴としては既存のzookeeperは controller ノードを 1 台だけ置くのに比べ、
quorumコントローラは、複数のコントローラノードを置くことができます。
つまり、コントローラノードの障害が発生した場合は、すぐに別のコントローラノードを使用できます。
controller ノードは meta データを常に同期します。
既存のzookeeperから meta データをコピーする必要があるコストが削減され、非常に迅速にコントローラノードを起動できます。
今はzookeeperとquorum方式の2つを選択できます。
将来、 kafkaはzookeeperをdeprecateすることができます。
しかし、現在はトランジェントなので、順番にzookeeperを学習してquorum controller を学習するのが良いと思います。

簡単にzookeeperをshellコマンドを使って照会する練習をします。
kafkaがインストールされたcontainerのshellを実行します。

zookeeperを介してすべてのkafkaを検索します。

zookeeper-shell zookeeper:2181 ls /brokers/ids

配列で合計 3 台の 0、1、2 clusterがあることを確認しました。

getコマンドで0番目のkafka情報を見てみましょう。

zookeeper-shell zookeeper:2181 get /brokers/ids/0
zookeeper-shell zookeeper:2181 get /brokers/ids/1
zookeeper-shell zookeeper:2181 get /brokers/ids/2

zookeeperに保存されているkafka brokerの情報を確認できます。
以上の内容を通じて、 zookeeperで分散環境のkafkaの様々な情報を保存して調整することを学習しました。

以上、 kafka環境設定と内部動作について見てきました。
次回は、 topicとpartitionについて学びます。

サブスクリプションといいね！通知設定は、コンテンツ制作者に多くの役に立ちます。

ありがとうございます。