1. 概要
高スループットの分散パブリッシュ/サブスクライブ メッセージ システムとして、Kafka はメッセージ アプリケーション、特にリアルタイムのデータ処理とアプリケーション アクティビティの追跡を必要とするシナリオで広く使用されています。Kafka は推奨されるサービスになりました。Kafka2.8 より前では、Kafka は強力でしたクラスターのメタデータの管理を ZooKeeper に依存すると、ZooKeeper クラスターのパフォーマンスが変動すると、Kafka のパフォーマンスが大きな影響を受けます。バージョン 2.8 以降、kafka3.x は KRaft (Kafka Raft、Java 8+ に依存) モードを提供し始め、Zookeeper への依存を削除し始めました。最新バージョン 3.5 でも、Kafka は Zookeeper コントローラーと互換性がありますが、Kafka Raft メタデータ モードは既に Zookeeper に依存せずに独立して Kafka を起動できます。
クラフトモードの利点:
1. 導入と管理の簡素化 - アプリケーションを 1 つだけインストールして管理することで、Kafka の運用フットプリントが大幅に小さくなりました。これにより、エッジの小型デバイスで Kafka を利用することも容易になります;
2. スケーラビリティの向上 - KRaft の回復時間は ZooKeeper よりも桁違いに高速です。これにより、単一クラスター内の数百万のパーティションに効率的に拡張できるようになります。ZooKeeper の有効な制限は数万です;
3. より効率的なメタデータ伝播 - ログベースのイベント駆動型メタデータ伝播により、Kafka の多くのコア機能のパフォーマンスを向上させることができます。さらに、メタデータ トピックのスナップショットもサポートします。
データリンク：公式サイト kraft、kafka_jira
2. トポロジー
2.1. 初期のトポロジー
古いコントローラー選出の原則:コントローラーとして選出できるブローカーは 1 つだけです。コントローラーが配置されているブローカーがダウンすると、他のブローカーがコントローラーとして選出されるために競合する可能性があります。
Kafka は、エポック番号 (エポック番号、分離トークンとも呼ばれます) を使用してこれを行います。エポック番号は単調増加する数値です。コントローラーを初めて選択したときのエポック番号の値は 1 です。新しいコントローラーを再度選択すると、エポック番号は 2 となり、単調増加します。
新しく選択された各コントローラーは、Zookeeper の条件付きインクリメント操作を通じて、新しくて大きなエポック番号を取得します。他のブローカーが現在のエポック番号を知った後、コントローラーから送信された古い (小さい) エポック番号を含むメッセージを受信した場合、それらはそれらを無視します。つまり、ブローカーは最大のエポック番号に従って現在の最新のコントローラーを区別します。
一般的なレプリカの状態がいくつかあります。
新規: コントローラーがレプリカを作成したときのレプリカのステータス。この状態のレプリカは、
フォロワー レプリカにのみなれます
。ブローカーがダウンすると、レプリカの状態はオフライン
ReplicaDeletionStarted に変わります。Kafa クラスターがトピックを有効にしたときReplicaDeletionSuccessful : レプリカの
削除に成功すると、レプリカはこの状態になります。
ReplicaDeletionIneligible : レプリカの削除に失敗した場合、レプリカはこの状態になります。 NonExistent: レプリカが正常に削除されると、レプリカは
この状態になり、トピックによって作成されたばかりのレプリカが確立されていない場合、レプリカはこの状態になります。
Kafka トピックが作成されたばかりのとき、トピックのコピーはNonExistent 状態にありますが、このとき、コントローラーは Zookeeper 内のトピックの各パーティションのコピー情報をメモリにロードし、同時にコピーを次のように更新します。 New状態にすると、コントローラーはパーティションの最初のコピーを選択し、リーダー レプリカとして機能し、すべてのレプリカを ISR に設定し、その決定を Kafka で永続化します。
パーティションのコピーとリーダーを決定した後、コントローラーは各コピーに情報を送信し、コピーのステータスをすべてのブローカーに同時に同期します。上記の操作が完了すると、コピーはオンライン状態になります。
トピック削除操作が有効になると、コントローラーはすべてのレプリカを停止します。フォロワー レプリカの場合は、リーダー レプリカからのデータのフェッチを停止します。リーダー レプリカの場合、コントローラーは部門のリーダーを NO_LEADER に設定します。その後、レプリカはオフライン状態になります。その直後、コントローラーはレプリカのステータスを ReplicaDeletionStarted に変更し、トピックの削除が開始されたことを示します。コントローラはすべてのレプリカに削除リクエストを送信し、ローカル レプリカ データを削除するように要求します。すべてのレプリカが正常に削除されると、 ReplicaDeletionSuccessful 状態になります。削除プロセス中にレプリカの 1 つを削除できなかった場合、レプリカは ReplicaDeletionIneligible 状態になり、コントローラが再試行するまで待機します。同時に、ReplicaDeletionSuccessful 状態にある場合は、自動的に NonExistent 状態に変更され、コントローラーのコンテキスト キャッシュはレプリカ情報をクリアします。
パーティションのステータスは次のとおりです。
NonExistent: パーティションが存在しないか、パーティションが削除されたことを示します。
New: パーティションが作成されると、パーティションはこの状態になります。現時点では、Kafka はパーティション リストを決定しましたが、リーダーと ISR はまだ選択されていません。
オンライン: パーティション リーダーが選択されると、この状態になり、パーティションが正常に動作できることを示します。
オフライン: パーティション リーダーが配置されているブローカーがダウンすると、この状態になり、パーティションが正常に動作できないことを示します。
トピックを作成するとき、コントローラーはパーティション オブジェクトの作成を担当します。まず、すべてのパーティションを一時的にNonExistent 状態に設定し、次に Zookeeper でレプリカ割り当てプランを読み取り、パーティションをNew 状態にします。新しい状態のパーティションは、リーダー コピーと ISR が選択されるとオンライン状態になります。
ユーザーがトピック削除操作を開始すると、パーティションは NonExistent 状態になり、そのパーティションの下のレプリカ削除操作も有効になります。ブローカーの操作が終了するか、システムがクラッシュした場合、コントローラーはブローカーがパーティション リーダーであるかどうかを判断し、パーティション リーダーである場合は、新しいラウンドのパーティション リーダー選出を開始してから、パーティションの状態をオンライン状態に戻す必要があります。
2.2. kRaft コントローラーのトポロジー
Kafka クラフト モード クラスター: 奇数のノードである必要があります。3 つのノードの最大フォールト トレランスは 1、5 つのノードの最大フォールト トレランスは 2 です。
KRaft クラスターでは、すべてのコントローラー エージェントが最新のメモリ内メタデータ キャッシュを維持するため、必要に応じて任意のコントローラーがアクティブ コントローラーとして引き継ぐことができます。すべてのブローカーはコントローラーと通信し、アクティブ コントローラーがブローカーによって通信されます。他のブローカーによるメタデータの変更。KRaftは、KIP-500 の一部として Kafka に導入されたRaft コンセンサス プロトコルに基づいており、詳細は他の関連 KIP で定義されています。アクティブ コントローラーは、kafka クラフト クラスター内のメタデータ トピックの単一パーティションのリーダーであり、他のコントローラーはレプリカ フォロワー、ブローカーはレプリカ オブザーバーです。したがって、コントローラーがメタデータの変更を他のコントローラーまたはブローカーにブロードキャストする代わりに、それぞれがアクティブに変更をフェッチします。これにより、すべてのコントローラーとブローカーの同期を非常に効率的に維持できるようになり、ブローカーとコントローラーの再起動時間も短縮されます。
KRaft モードでは、クラスター メタデータ (コントローラーで管理されているすべてのリソースの現在の状態を反映する) は、__cluster_metadata という名前のトピックに保存されます。KRaft は、このトピックを使用してコントローラー ノードとエージェント ノード間でクラスター状態の変更を同期します。KRaft モードでは、Kafka クラスターは専用モードまたは共有モードで実行できます。専用モードでは、一部のノードの process.roles 構成がコントローラーに設定され、残りのノードはブローカーに設定されます。共有モードの場合、これらのノードの process.roles はコントローラー、ブローカーに設定されます。つまり、一部のノードは二重の役割を実行します。「コントローラー」と呼ばれるこのモードの特別なノードは、クラスター内のエージェントの登録を管理する責任を負います。これは通常、controller.quorum.voters の最初のノードです。ブローカー アクティビティには 2 つの条件があります。
1、ブローカーは定期的なメタデータ更新を受信するために、コントローラーとのアクティブ セッションを維持する必要があります。一方、「アクティブ セッション」はクラスター構成によって異なり、アクティブ セッションはコントローラーに定期的にハートビートを送信することによって維持されます。Broker.session.timeout.msで設定されたタイムアウトが期限切れになる前にコントローラーがハートビートの受信に失敗した場合、ノードはオフラインとみなされます。
2、フォロワーとして機能するブローカーは、リーダーからの書き込みを複製し、「あまりにも」後れを取らないようにする必要があります。
Kradt モードでは、コントローラーはクラスターのメタデータを、metadata.log.dir/最初のログ ディレクトリで指定されたディレクトリに保存します。特に、新しいコントローラー ノードを追加する場合は、既存のコントローラーがすべてのデータを送信するまで待つ必要があります。大部分のコントローラーにすべてのコミットされたデータが含まれるまで、新しいコントローラー ノードをフォーマットして開始しないでください。次のコマンドで確認します。kafka-metadata-quorum.sh --bootstrap-server broker_host:port describe --replication表示されているラグ値が 0 であることが最善です。少なくとも、ラグ値がコントローラにとって十分小さいことを確認するか、リーダーの終端オフセットが増加していない場合は、ラグがゼロになるまで待つことができます。大多数の場合は 0; 0 でない場合はチェックしてください LastFetchTimestamp と LastCaughtUpTimestamp の 2 つの値、すべてのコントローラーの 2 つの値は可能な限り近くなければなりません、つまり、読み取りと消費が一貫している必要があります。新しいコントローラのメタデータ ストレージ パスをフォーマットします。混合モードであることに注意してください。bin/kafka-storage.sh format --cluster-id uuid --config server_propertiesこの場合、ストレージ フォーマットはエラーを報告します: ログ ディレクトリ ... はすでにフォーマットされています。この状況は混合モードでのみ発生し、元のコントローラのログ パスが失われたり破損したりした場合は、次のコマンドを実行できます。その他の場合に使用することはお勧めできませんbin/kafka-storage.sh format --cluster-id uuid --ignore-formatted --config server_properties。コントローラーは、他のコントローラーやボーカーからのリクエストを受信するために使用されます。したがって、サーバーでコントローラーの役割が有効になっていない場合でも (つまり、サーバーが単なるブローカーである場合)、コントローラー リスナーとその構成に必要なセキュリティ プロパティを定義する必要があります。構成参考例：
process.roles=broker
listeners=BROKER://localhost:9092 #broker does not expose the controller listener itself
inter.broker.listener.name=BROKER #区别于下面的controller.listener.names
controller.quorum.voters=0@localhost:9093
controller.listener.names=CONTROLLER #仅用于controller
listener.security.protocol.map=BROKER:SASL_SSL,CONTROLLER:SASL_SSL
#混合模式
process.roles=broker,controller
listeners=BROKER://localhost:9092,CONTROLLER://localhost:9093 #listeners独立配置用户kafka 客户端访问
inter.broker.listener.name=BROKER #配合上面的与kafka client交互，隔离开controller
controller.quorum.voters=0@localhost:9093
controller.listener.names=CONTROLLER #The controller will accept requests on all listeners defined by controller.listener.names，多个controller时，the first one in the list will be used for outbound requests.
listener.security.protocol.map=BROKER:SASL_SSL,CONTROLLER:SASL_SSL
詳細については、 「KRaft プリンシパル転送」を参照してください。注: クラフト モードの混合モードは主に開発環境で使用され、運用環境では推奨されません。ハイブリッド モードの明らかな問題は、コントローラーがシステムの残りの部分からあまり分離されないこと、つまり、ブローカーから分離できないことです。典型的なシナリオは、コントローラーを弾力的に拡張またはロールバックして個別にアップグレードできないことです。 ; KRaft モードでは、特定の Kafka サーバーがコントローラーとして選択されます。定義されたすべての候補コントローラーがメタデータの選択に参加し、アクティブなコントローラーの場合、他のコントローラーがホット スタンバイの役割として機能します。したがって、一般的なプラクティスは次のとおりです。 process.role をブローカー/コントローラーとして構成するには、両方が使用可能 (混合モード) ではなく、Kafka クラスターで 3 つのコントローラーを使用することが推奨され、3 つを超えるコントローラーは推奨されません。Kafka コントローラーはクラスターのすべてのメタデータをメモリとディスクに保存します。公式の推奨事項は、これらのメタデータ ログを保存するためにメモリとディスクに 5G スペースを割り当てることです。また、kraft にはいくつかの制限もあります。たとえば、次の関数があります。 KRaft モードではありません。完全に実装されているのは次のとおりです。
1. 管理 API を使用して SCRAM ユーザーを構成します。
2. 複数のストレージ ディレクトリを使用して JBOD 構成をサポートします。
3. スタンドアロン KRaft コントローラーで一部の動的構成を変更します
。 4. デリゲート トークン
KRaft メタデータ レプリケーション プロセス:
クラスター メタデータは Kafka トピックに保存され、アクティブ コントローラーはメタデータ トピックの単一パーティションのリーダーとなり、すべてのデータを受信して書き込みます。他のコントローラーはフォロワーとして機能し、これらの変更を積極的に取得します。従来のレプリカ レプリケーションと比較すると、新しいリーダーを選出する必要がある場合、レプリカ セットを同期させるのではなく、調停によって行われます。したがって、メタデータのレプリケーションには ISR は関与しません。もう 1 つの違いは、メタデータ レコードが各ノードのローカル ログに書き込まれるとすぐにディスクにフラッシュされることです。
Kraft モードとセキュリティ認証の構成:
SASL/GSSAPI: Kerberos 認証方式、一般的にランダムなパスワードによる keytab 認証方式を使用し、パスワードは暗号化され、企業で最もよく使用される認証方式でもあります; SASL/PLAIN: この方式は実際にはアカウント/パスワード認証方式ですが、
ユーザー名とパスワードがファイルに保存される、動的に追加できない、パスワードが平文であるなど、多くの欠陥があります。利点は非常にシンプルであることです。
SASL/SCRAM: SASL/PLAIN 方式の欠点を補うために提供される別の認証方式です。この方法でユーザー名とパスワードはzookeeperに保存されるため、ユーザーの動的な追加をサポートできます。この認証方法では、パスワードの暗号化に sha256 または sha512 も使用します。これは比較的安全であり、バージョン 0.10.2 で導入されました。
3. 導入構成
wget https://archive.apache.org/dist/kafka/3.4.0/kafka_2.13-3.4.0.tgz
tar -zxvf kafka_2.13-3.4.0.tgz -C /opt/
mv /opt/kafka_2.13-3.4.0. /opt/kafka
chown kafka:kafka -R /opt/kafka
cd /opt/kafka/
mkdir data
vim /opt/kafka/config/kraftserver.properties //如下所示
# The role of this server. Setting this puts us in KRaft mode
process.roles=broker,controller #the server acts as both a broker and a controller
# The node id associated with this instance's roles
node.id=2
# The connect string for the controller quorum 集群选举控制器配置，默认走 PLAINTEXT协议除非显示定义其他协议
controller.quorum.voters=1@172.18.1.176:9093,[email protected]:9093,[email protected]:9093
############################# Socket Server Settings #############################
# The address the socket server listens on.
# Combined nodes (i.e. those with `process.roles=broker,controller`) must list the controller listener here at a minimum.
# If the broker listener is not defined, the default listener will use a host name that is equal to the value of java.net.InetAddress.getCanonicalHostName(),
# with PLAINTEXT listener name, and port 9092.
# FORMAT:
# listeners = listener_name://host_name:port
# EXAMPLE:
# listeners = PLAINTEXT://your.host.name:9092
listeners=PLAINTEXT://172.31.7.237:9092,CONTROLLER://172.18.1.217:9093
# Name of listener used for communication between brokers. it is used exclusively仅用于 for requests between brokers
inter.broker.listener.name=PLAINTEXT #注意与controller.listener.names不要冲突
# Listener name, hostname and port the broker will advertise to clients.
# If not set, it uses the value for "listeners".
#advertised.listeners=PLAINTEXT://172.18.1.217:9092
#完成后，生成整个集群有一个唯一的ID标志，使用uuid。可使用官方提供的 kafka-storage 工具生成
/opt/kafka/bin/kafka-storage.sh random-uuid
或
KAFKA_CLUSTER_ID="$(bin/kafka-storage.sh random-uuid)"
#用上述ID格式化存储路径
/opt/kafka/bin/kafka-storage.sh format -t clust_ID -c /opt/kafka/config/kraft/server.properties
或
bin/kafka-storage.sh format -t $KAFKA_CLUSTER_ID -c config/kraft/server.properties
#完成后以kraft模式启动服务
bin/kafka-server-start.sh -daemon ./config/kraft/server.properties
#创建topic
bin/kafka-topics.sh --create --topic First_Kafka_Topic --partitions 1 --replication-factor 3 --bootstrap-server 172.31.7.237:9092
#查看
bin/kafka-topics.sh --list --bootstrap-server 172.31.7.237:9092
2) Kafka 起動スクリプト
#!/bin/bash
#kafka集群启动脚本
case $1 in
"start"){
for i in 172.18.1.176,172.18.1.217,@172.18.1.150
do
echo "--------启动 $i kafka with kraft-------"
ssh $i "/home/kafka/bin/kafka-server-start.sh -daemon /home/kafka/config/kraft/server.properties"
done
};;
"stop"){
for i in 172.18.1.176,172.18.1.217,@172.18.1.150
do
echo "------停止 $i kafka--------"
ssh $i "/home/kafka/bin/kafka-server-stop.sh"
done
};;
esac
3) kafka kRaft SASL/PLAIN セキュリティ認証構成:
次のように、新しい構成ファイル config/kafka_server_jaas.conf を作成します。
KafkaServer {
org.apache.kafka.common.security.plain.PlainLoginModule required
serviceName="kafka"
username="admin"
password="admin"
user_admin="admin";
};
kafka-server-start.sh のコピーをコピーし、kafka-server-start-sasl.sh 起動スクリプトの名前を変更し、名前を変更して、暗号化されたファイルをインポートします。
……
if [ "x$KAFKA_HEAP_OPTS" = "x" ]; thenexport KAFKA_HEAP_OPTS="-Xmx1G -Xms1G -Djava.security.auth.login.config=/opt/kafka/kafka_2.13-3.4.0/config/kafka_server_jaas.conf"
fi
……
server_sasl.properties のコピーをコピーし、名前を server_sasl.properties に変更して、セキュリティ以外の認証から分離し、次のように編集します。
node.id=1
controller.quorum.voters=1@kraft1:9093
listeners=SASL_PLAINTEXT://172.31.7.237:9092,CONTROLLER:///172.18.1.217:9093
inter.broker.listener.name=SASL_PLAINTEXT
advertised.listeners=SASL_PLAINTEXT://172.31.7.237:9092
sasl.enabled.mechanisms=PLAIN
sasl.mechanism.inter.broker.protocol=PLAIN
完了したら、kafka を開始します。sh ./bin/kafka-server-start-sasl.sh -daemon ./config/kraft/server_sasl.properties
4. 付録: 知識の確認
4.1、一般的に使用されるメッセージ キューの比較
1）ラビットMQ
RabbitMQ は、Erlang で書かれたオープン ソースのメッセージ キューです。AMQP、XMPP、SMTP、STOMP などの多くのプロトコルをサポートしています。このため、非常に重量があり、エンタープライズ レベルの開発に適しています。同時に、ブローカー アーキテクチャが実装されます。これは、メッセージがクライアントに送信されるときに、まず中央のキューに入れられることを意味します。ルーティング、負荷分散、またはデータの永続性が適切にサポートされています。
2）レディス
Redis は Key-Value ペアに基づく NoSQL データベースであり、その開発と保守は非常に活発です。Key-Value型のデータベースストレージシステムですが、それ自体がMQ機能をサポートしているため、軽量なキューサービスとして利用できます。RabbitMQ と Redis のエンキュー操作とデキュー操作をそれぞれ 100 万回実行し、100,000 回ごとの実行時間を記録します。テスト データは、128 バイト、512 バイト、1K、10K の 4 つの異なるサイズのデータに分割されます。実験によると、チームに参加したときはデータが比較的小さい場合は Redis のパフォーマンスが RabbitMQ よりも高く、データ サイズが 10K を超えると Redis は耐えられないほど遅くなり、チームを離れるときはデータのサイズに関係なく、 , Redis は非常に優れたパフォーマンスを示しますが、RabbitMQ のデキュー パフォーマンスは Redis よりもはるかに低くなります。
3) ゼロMQ
ZeroMQ は、特に高スループットの需要シナリオ向けに、最速のメッセージ キュー システムとして知られています。ZeroMQ は RabbitMQ が苦手とする高度で複雑なキューを実装できますが、開発者は複数の技術フレームワークを自分で組み合わせる必要があり、技術的な複雑さがこの MQ の適用を成功させるための課題となります。ZeroMQ には独自の非ミドルウェア モデルがあり、アプリケーションがこのサーバーの役割を果たすため、メッセージ サーバーやミドルウェアをインストールして実行する必要はありません。NuGet を使用してインストールできる ZeroMQ ライブラリを参照するだけで、アプリケーション間でメッセージを簡単に送信できるようになります。ただし、ZeroMQ は非永続キューのみを提供するため、ダウンするとデータが失われます。このうち、Twitter の Storm バージョン 0.9.0 より前のバージョンでは、デフォルトでデータ ストリーム送信として ZeroMQ が使用されます (Storm は、バージョン 0.9 から送信モジュールとして ZeroMQ と Netty の両方をサポートします)。
4）アクティブMQ
ActiveMQ は Apache のサブプロジェクトです。ZeroMQ と同様に、ブローカーおよびピアツーピア テクノロジーを使用してキューを実装できます。同時に、RabbitMQ と同様に、少量のコードで高度なアプリケーション シナリオを効率的に実装できます。
5) カフカ/ジャフカ
Kafka は Apache のサブプロジェクトで、言語をまたいだ高性能分散パブリッシュ/サブスクライブ メッセージ キュー システムであり、Jafka は Kafka のアップグレード バージョンである Kafka 上でインキュベートされます。次の特徴があります: 高速永続性、メッセージ永続性は O(1) システム オーバーヘッドの下で実行可能、高スループット (通常のサーバーで 10W/s のスループット レートに達する可能性があります)、完全な分散システム、ブローカー、プロデューサー、およびコンシューマーすべてネイティブかつ自動的に分散型自動負荷分散をサポートし、ログ データや Hadoop などのオフライン分析システム向けに Hadoop データの並列読み込みをサポートしますが、リアルタイム処理の制限が必要なため、これは実現可能なソリューションです。Kafka は、Hadoop の並列読み込みメカニズムを通じて、オンラインとオフラインのメッセージ処理を統合します。Apache Kafka は、ActiveMQ と比較して非常に軽量なメッセージング システムであり、非常に優れたパフォーマンスに加えて、適切に機能する分散システムでもあります。Kafka3.0 の軽量の単一プロセス デプロイメントは、ActiveMQ や RabbitMQ などの従来のメッセージ キューを置き換えるだけでなく、エッジ シナリオや軽量ハードウェアを使用するシナリオにも適しています。このデータは、200 万のパーティションを管理できるクラスターにおいて、kafka3.0 の新バージョンのクォーラム コントローラーの移行プロセスが数分から 30 秒に短縮され、データの制限を制限するメタデータ管理の主なボトルネックを突破できることを示しています。 Kafka クラスターのスコープ、シャットダウンと再起動は kafka2.8 よりも 10 倍以上速く、パフォーマンスは完全に破壊されています。
4.2. カフカの原理
Kafka 2.4 で導入された Kafka の新しいレプリケーション プロトコル。Kraft プロトコルの目標は、Kafka の信頼性と保守性を向上させ、分散ストリーム処理のニーズを満たすことであり、主に次の側面が含まれます。
1.分散化: Kraft プロトコルはKafka のコントローラー ノードを分散化し、各コピーがコントローラーになることができるため、システムの信頼性とフォールト トレランスが向上します。
2. アトミック性: Kraft プロトコルは、アトミック ブロードキャスト プロトコルを使用してメッセージのアトミック性を保証します。つまり、すべてのレプリカが同じメッセージを受信することで、データの一貫性が確保されます。 3. スケーラビリティ
: Kraft プロトコルは、レプリカの動的な追加と削除をサポートします。システムの拡張性と保守性が向上します。
4. 信頼性: Kraft プロトコルはRaft アルゴリズムを使用してレプリカ間の一貫性を確保し、システムの信頼性と耐障害性を向上させます。
4.3. DoctorKafka 管理ツール
これは Pinterest 製品から派生したプロジェクトであり、Kafka サービスの運用と保守の規模を拡大するために、Pinterest は Kafka クラスターの自己修復とワークロード バランシングを管理するための DoctorKafka を構築しました。DoctorKafka は、Kafka ブローカーの障害を検出し、障害が発生したブローカーの負荷を正常なブローカーに自動的に転送できます。現在、Pinterest はこのプロジェクトを GitHub でオープンソース化しています。DoctorKafka は 3 つの部分で構成されており、アーキテクチャは次のとおりです。
1. 各ブローカーにデプロイされたメトリック コレクターは、Kafka プロセスとホストのメトリックを定期的に収集し、Kafka トピックに公開します。ここでは、ブローカーの状態ストレージとして Kafka が使用されています。このようにして、DoctorKafka の構築プロセスを簡素化し、他のシステムへの依存を減らすことができます。各ブローカーは、入力と出力を収集するインジケーター コレクターを実行します。 Kafka ブローカーのネットワーク トラフィック メトリクスと各レプリカのステータス。
2. 集中化された DoctorKafka サービスは、複数のクラスターを管理し、ブローカーのステータス インジケーターを分析してブローカーの障害を検出し、クラスターの自己修復コマンドと負荷分散コマンドを実行します。DoctorKafka は、実行されたコマンドを「アクション ログ」という名前の別のトピックに記録します;
3. Kafka クラスターのステータスと実行プロセスを参照するための Web UI ページ。
DoctorKafka サービスが開始されると、まず過去 24 ～ 48 時間のブローカーのステータスを読み取り、これに基づいて、DoctorKafka は各レプリカ ワークロードに必要なリソースを推測します。Kafka のワークロードは主にネットワーク集約型であるため、DoctorKafka は主にレプリカのネットワーク帯域幅の使用量に焦点を当てています。DoctorKafka が開始されると、各クラスターのステータスが定期的にチェックされます。ブローカーの障害を検出すると、障害が発生したブローカーのワークロードを十分な帯域幅を持つブローカーに転送します。クラスター内に再割り当てするのに十分なリソースがない場合は、警告が表示されます。同様に、DoctorKafka がワークロード バランシングを実行する場合、ネットワーク トラフィックが設定を超えているブローカーを特定し、トラフィックの少ないブローカーにワークロードを転送するか、より適切なリーダー選挙 (リーダー選挙) スキームを実行してトラフィックを迂回します。
DoctorKafka は Pinterest で数か月間稼働しており、運用スタッフによる 1000 を超えるクラスターの管理を支援しています。詳細については、プロジェクトのアドレスを参照してください。
4.4、Kafka WebUIのKowl
Kowl (Kafka Owl): 優れた UI に重点を置き、メッセージ、コンシューマー、構成などを探索するための Kafka WebUI。詳細については、「プロジェクト アドレス」を参照してください。
上記に加えて、LogiKM と kafka-console-ui に加えて、9 つの一般的な Kafka UI ツールがあります。Kafka-UI は完全に機能し、無料であるため、お勧めします。
1 AKHQ 無料
2 Kowl 部分課金
3 Kafdrop 無料
4 Apache Kafka 用 UI 無料
5 レンズ無料
6 CMAK 無料
7 Confluent CC 課金
8 Conduktor 課金
9 LogiKM 無料
10 kafka-console-ui 無料
通常、プログラムは Docker コンテナを通じて実行されます。Kowl の最大の利点は、その優れたユーザー インターフェイスです。便利で、ユーザーフレンドリーで、使いやすいです; 起動後のインターフェイスは次のとおりです:
Kowl は、メッセージの閲覧、リアルタイム追跡、および Protobuf、Avro、Amazon MSK IAM のサポートを提供しますが、ログイン システム (Google、GitHub、 Okta) およびグループ同期による RBAC 権限 有料の Kowl Business プランでのみ利用可能。Kowl には、マルチクラスター管理、動的なトピック構成、パーティションの追加、レプリカの変更、Kafka Connect 管理、スキーマ レジストリ、KSQL 統合、Kafka Streams トポロジ、読み取り専用モード、JMX メトリクスの視覚化とグラフ化などの機能もありません。