第14章 ブローカーの追加または削除によるクラスターのスケーリング
ブローカーを追加して Kafka クラスターをスケーリングすると、クラスターのパフォーマンスと信頼性が向上します。ブローカーを追加すると、利用可能なリソースが増加し、クラスターがより大きなワークロードを処理し、より多くのメッセージを処理できるようになります。また、より多くのレプリカとバックアップを提供することでフォールトトレランスを向上させることもできます。逆に、十分に活用されていないブローカーを削除すると、リソースの消費が削減され、効率が向上します。中断やデータ損失を避けるために、スケーリングは慎重に行う必要があります。クラスター内のすべてのブローカーにパーティションを再分散することにより、各ブローカーのリソース使用率が削減され、クラスターの全体的なスループットが向上します。
Kafka トピックのスループットを向上させるには、そのトピックのパーティションの数を増やすことができます。これにより、トピックの負荷をクラスター内の異なるブローカー間で共有できるようになります。ただし、すべてのブローカーが特定のリソース (I/O など) によって制約されている場合、パーティションを追加してもスループットは向上しません。この場合、クラスターにブローカーをさらに追加する必要があります。
マルチノード Kafka クラスターの実行時にブローカーを追加すると、レプリカとして機能するクラスター内のブローカーの数に影響します。トピックの実際のレプリケーション係数は、default.replication.factor および min.insync.replicas の設定、および使用可能なブローカーの数によって決まります。たとえば、レプリケーション係数 3 は、トピックの各パーティションが 3 つのブローカー間でレプリケーションされ、ブローカーに障害が発生した場合のフォールトトレランスを確保することを意味します。
レプリカ設定の例
default.replication.factor = 3
min.insync.replicas = 2
ブローカーを追加または削除しても、Kafka はパーティションを自動的に再割り当てしません。これを行う最良の方法は、Cruise Control を使用することです。クラスターをスケールアップまたはスケールダウンするときに、Cruise Control の add-brokers モードと remove-brokers モードを使用できます。
-
Kafka クラスターをスケールアップした後、
add-brokersモードを使用して、パーティションレプリカを既存のブローカーから新しく追加したブローカーに移動します。 -
Kafka クラスターをスケールダウンする前に、
remove-brokersモードを使用して、削除されるブローカーからパーティションレプリカを移動します。
14.1. スケールダウン操作後のノードの登録解除 リンクのコピーリンクがクリップボードにコピーされました!
Kafka クラスターからノードを削除した後、kafka-cluster.sh スクリプトを使用して、クラスターメタデータからノードを登録解除します。削除したノードを登録解除しないと、メタデータが古くなり、運用上の問題が発生します。
前提条件
ノードを登録解除する前に、次のタスクが完了していることを確認してください。
-
Cruise Control の
remove-nodes操作を使用して、削除する予定のノードのパーティションを残りのブローカーに再割り当てします。 -
必要に応じてクラスター設定を更新し、トピックのレプリケーション係数 (
default.replication.factor) と In-Sync レプリカ確認応答の必要最小数 (min.insync.replicas) を調整します。 - ノード上の Kafka ブローカーサービスを停止し、クラスターからノードを削除します。
手順
削除したノードをクラスターから登録解除します。
/opt/kafka/bin/kafka-cluster.sh unregister \ --bootstrap-server <broker_host>:<port> \ --id <node_id_number>次のトピックの詳細を表示して、クラスターの現在の状態を確認します。
/opt/kafka/bin/kafka-topics.sh \ --bootstrap-server <broker_host>:<port> \ --describe