第20章 パーティション再割り当てツールの使用
Kafka クラスターをスケーリングする場合、ブローカーを追加または削除し、パーティションの分散またはトピックのレプリケーション係数を更新する必要がある場合があります。パーティションとトピックを更新するには、kafka-reassign-partitions.sh
ツールを使用できます。
Streams for Apache Kafka Cruise Control 統合も Topic Operator も、トピックのレプリケーション係数の変更をサポートしていません。ただし、kafka-reassign-partitions.sh
ツールを使用してトピックのレプリケーション係数を変更できます。
このツールを使用して、パーティションを再割り当てし、ブローカー間でパーティションの分散のバランスをとり、パフォーマンスを向上させることもできます。ただし、パーティション再割り当てとクラスターの再バランシングを自動化するための Cruise Control を使用することを推奨します。Cruise Control は、ダウンタイムなしでトピックをあるブローカーから別のブローカーに移動でき、パーティションを再割り当てする最も効率的な方法です。
kafka-reassign-partitions.sh
ツールは、ブローカーコンテナー内ではなく、別個の対話型 Pod として実行することを推奨します。ブローカーコンテナー内で Kafka bin/
スクリプトを実行すると、JVM が Kafka ブローカーと同じ設定で起動する可能性があり、潜在的に中断を引き起こす可能性があります。kafka-reassign-partitions.sh
ツールを別の Pod で実行すると、この問題を回避できます。-ti
オプションを使用して Pod を実行すると、Pod 内でシェルコマンドを実行するためのターミナルを備えた対話型 Pod が作成されます。
ターミナルを使用した対話型 Pod の実行
oc run helper-pod -ti --image=registry.redhat.io/amq-streams/kafka-37-rhel9:2.7.0 --rm=true --restart=Never -- bash
oc run helper-pod -ti --image=registry.redhat.io/amq-streams/kafka-37-rhel9:2.7.0 --rm=true --restart=Never -- bash
20.1. パーティション再割り当てツールの概要
パーティション再割り当てツールは、Kafka パーティションとブローカーを管理するための次の機能を提供します。
- パーティションレプリカの再配布
- ブローカーを追加または削除してクラスターをスケールアップおよびスケールダウンし、負荷の高いブローカーから使用率の低いブローカーに Kafka パーティションを移動します。これを行うには、移動するトピックとパーティションとそれらをどこに移動するかを特定するパーティション再割り当て計画を作成する必要があります。クラスターのリバランスプロセスを自動化 する Cruise Control は、このタイプの操作に推奨されます。
- トピックレプリケーション係数の増減のスケーリング
- Kafka トピックのレプリケーション係数を増減します。これを行うには、パーティション間の既存のレプリケーション割り当てと、レプリケーション係数の変更を伴う更新された割り当てを識別するパーティション再割り当て計画を作成する必要があります。
- 優先リーダーの変更
- Kafka パーティションの優先リーダーを変更します。これは、現在優先されているリーダーが使用できない場合、またはクラスター内のブローカー間で負荷を再分散したい場合に役立ちます。これを行うには、レプリカの順序を変更して各パーティションの新しい優先リーダーを指定するパーティション再割り当て計画を作成する必要があります。
- 特定の JBOD ボリュームを使用するようにログディレクトリーを変更する
- 特定の JBOD ボリュームを使用するように Kafka ブローカーのログディレクトリーを変更します。これは、Kafka データを別のディスクまたはストレージデバイスに移動する場合に便利です。これを行うには、トピックごとに新しいログディレクトリーを指定するパーティション再割り当て計画を作成する必要があります。
20.1.1. パーティション再割り当て計画の生成
パーティション再割り当てツール (kafka-reassign-partitions.sh
) は、どのパーティションを現在のブローカーから新しいブローカーに移動する必要があるかを指定するパーティション割り当てプランを生成することによって機能します。
計画に満足したら、実行できます。その後、ツールは次の処理を実行します。
- パーティションデータを新しいブローカーに移行する
- Kafka ブローカー上のメタデータを更新して、新しいパーティションの割り当てを反映する
- 新しい割り当てが確実に有効になるように、Kafka ブローカーのローリング再起動をトリガーする
パーティション再割り当てツールには 3 つの異なるモードがあります。
--generate
- トピックとブローカーのセットを取得し、再割り当て JSON ファイル を生成します。これにより、トピックのパーティションがブローカーに割り当てられます。これはトピック全体で動作するため、一部のトピックのパーティションを再度割り当てる場合は使用できません。
--execute
- 再割り当て JSON ファイル を取得し、クラスターのパーティションおよびブローカーに適用します。その結果、パーティションを取得したブローカーは、パーティションリーダーのフォロワーになります。特定のパーティションで、新しいブローカーが ISR (In-Sync レプリカ) に参加すると、古いブローカーがフォロワーでなくなり、そのレプリカが削除されます。
--verify
-
--verify
は、--execute
ステップと同じ 再割り当て JSON ファイル を使用して、ファイル内のすべてのパーティションが目的のブローカーに移動されたかどうかをチェックします。再割り当てが完了すると、--verify
は有効なトラフィックスロットル (--throttle
) も削除します。スロットルを削除しないと、再割り当てが完了した後もクラスターは影響を受け続けます。
クラスターでは、1 度に 1 つの再割り当てのみを実行でき、実行中の再割り当てをキャンセルすることはできません。再割り当てをキャンセルする必要がある場合は、完了するまで待ってから別の再割り当てを実行して、最初の再割り当ての効果を元に戻します。kafka-reassign-partitions.sh
によって、元に戻すための再割り当て JSON が出力の一部として生成されます。大規模な再割り当ては、進行中の再割り当てを停止する必要がある場合に備えて、複数の小さな再割り当てに分割するようにしてください。
20.1.2. パーティション再割り当て JSON ファイルでのトピックの指定
kafka-reassign-partitions.sh
ツールは、再割り当てを行うトピックを指定する再割り当て JSON ファイルを使用します。特定のパーティションを移動させたい場合は、再割り当て JSON ファイルを生成するか、手動でファイルを作成します。
基本的な再割り当て JSON ファイルの構造は次の例に示されており、2 つの Kafka トピックに属する 3 つのパーティションが記述されています。各パーティションは、ブローカー ID によって識別される新しいレプリカのセットに再割り当てされます。プロパティー version
、topic
、partition
、replicas
はすべて必須です。
パーティションの再割り当ての JSON ファイル構造の例
{ "version": 1, "partitions": [ { "topic": "example-topic-1", "partition": 0, "replicas": [1, 2, 3] }, { "topic": "example-topic-1", "partition": 1, "replicas": [2, 3, 4] }, { "topic": "example-topic-2", "partition": 0, "replicas": [3, 4, 5] } ] }
{
"version": 1,
"partitions": [
{
"topic": "example-topic-1",
"partition": 0,
"replicas": [1, 2, 3]
},
{
"topic": "example-topic-1",
"partition": 1,
"replicas": [2, 3, 4]
},
{
"topic": "example-topic-2",
"partition": 0,
"replicas": [3, 4, 5]
}
]
}
JSON に含まれていないパーティションは変更されません。
topics
配列を使用してトピックのみを指定すると、パーティション再割り当てツールは、指定されたトピックに属するすべてのパーティションを再割り当てします。
トピックのすべてのパーティションを再割り当てするための再割り当て JSON ファイル構造の例
{ "version": 1, "topics": [ { "topic": "my-topic"} ] }
{
"version": 1,
"topics": [
{ "topic": "my-topic"}
]
}
20.1.3. JBOD ボリューム間のパーティションの再割り当て
Kafka クラスターで JBOD ストレージを使用する場合は、特定のボリュームとログディレクトリー (各ボリュームに単一のログディレクトリーがある) との間でパーティションの再割り当てできます。
パーティションを特定のボリュームに再割り当てするには、再割り当て JSON ファイル内の各パーティションの log_dirs
値を追加します。各レプリカは特定のログディレクトリーに割り当てる必要があるため、各 log_dirs
配列には、replicas
配列と同じ数のエントリーが含まれます。log_dirs
配列には、ログディレクトリーへの絶対パスまたは特別な値 any
が含まれます。any
値は、Kafka がそのレプリカに対して使用可能な任意のログディレクトリーを選択できることを示します。これは、JBOD ボリューム間でパーティションを再割り当てするときに役立ちます。
ログディレクトリーを含む再割り当て JSON ファイル構造の例
{ "version": 1, "partitions": [ { "topic": "example-topic-1", "partition": 0, "replicas": [1, 2, 3] "log_dirs": ["/var/lib/kafka/data-0/kafka-log1", "any", "/var/lib/kafka/data-1/kafka-log2"] }, { "topic": "example-topic-1", "partition": 1, "replicas": [2, 3, 4] "log_dirs": ["any", "/var/lib/kafka/data-2/kafka-log3", "/var/lib/kafka/data-3/kafka-log4"] }, { "topic": "example-topic-2", "partition": 0, "replicas": [3, 4, 5] "log_dirs": ["/var/lib/kafka/data-4/kafka-log5", "any", "/var/lib/kafka/data-5/kafka-log6"] } ] }
{
"version": 1,
"partitions": [
{
"topic": "example-topic-1",
"partition": 0,
"replicas": [1, 2, 3]
"log_dirs": ["/var/lib/kafka/data-0/kafka-log1", "any", "/var/lib/kafka/data-1/kafka-log2"]
},
{
"topic": "example-topic-1",
"partition": 1,
"replicas": [2, 3, 4]
"log_dirs": ["any", "/var/lib/kafka/data-2/kafka-log3", "/var/lib/kafka/data-3/kafka-log4"]
},
{
"topic": "example-topic-2",
"partition": 0,
"replicas": [3, 4, 5]
"log_dirs": ["/var/lib/kafka/data-4/kafka-log5", "any", "/var/lib/kafka/data-5/kafka-log6"]
}
]
}
20.1.4. パーティション再割り当てのスロットル
パーティション再割り当てには、ブローカーの間で大量のデータを転送する必要があるため、処理が遅くなる可能性があります。クライアントへの悪影響を防ぐため、再割り当て処理をススロットルできます。--throttle
パラメーターを kafka-reassign-partitions.sh
ツールと共に使用して、再割り当てをスロットルします。ブローカー間のパーティションの移動の最大しきい値をバイト単位で指定します。たとえば --throttle 5000000
は、パーティションを移動する最大しきい値を 50 MBps に設定します。
スロットリングにより、再割り当ての完了に時間がかかる場合があります。
- スロットルが低すぎると、新たに割り当てられたブローカーは公開されるレコードに対応できず、再割り当ては完了しません。
- スロットルが高すぎると、クライアントに影響します。
たとえば、プロデューサーの場合は、確認応答を待つ通常のレイテンシーよりも高い可能性があります。コンシューマーの場合は、ポーリング間のレイテンシーが大きいことが原因でスループットが低下する可能性があります。