18.3. 最適化プロポーザルの概要


KafkaRebalance リソースを設定して、最適化の提案を生成し、提案された変更を適用します。最適化プロポーザル は、パーティションのワークロードをブローカー間でより均等に分散することで、Kafka クラスターの負荷をより均等にするために提案された変更の概要です

各最適化プロポーザルは、それを生成するために使用された 最適化ゴール のセットに基づいており、ブローカーリソースに設定された 容量制限 が適用されます。

すべての最適化プロポーザルは、提案されたリバランスの影響の 見積もり です。提案は、承認または却下できます。最初に最適化プロポーザルを生成しなければに、クラスターのリバランスは承認できません。

次のリバランスモードのいずれかで最適化の提案を実行できます。

  • full
  • add-brokers
  • remove-brokers

18.3.1. リバランスモード

KafkaRebalance カスタムリソースの spec.mode プロパティーを使用して、リバランスモードを指定します。

full
full モードでは、クラスター内のすべてのブローカー間でレプリカを移動することにより、完全なリバランスが実行されます。これは、KafkaRebalance カスタムリソースで spec.mode プロパティーが定義されていない場合のデフォルトモードです。
add-brokers
add-brokers モードは、1 つ以上のブローカーを追加して Kafka クラスターをスケールアップした後に使用されます。通常、Kafka クラスターをスケールアップした後、新しいブローカーは、新しく作成されたトピックのパーティションのみをホストするために使用されます。新しいトピックが作成されないと、新たに追加されたブローカーは使用されず、既存のブローカーは同じ負荷のままになります。クラスターにブローカーを追加した直後に add-brokers モードを使用すると、リバランス操作によってレプリカが既存のブローカーから新しく追加されたブローカーに移動します。KafkaRebalance カスタムリソースの spec.brokers プロパティーを使用して、新しいブローカーをリストとして指定します。
remove-brokers
remove-brokers モードは、1 つ以上のブローカーを削除して Kafka クラスターをスケールダウンする前に使用されます。Kafka クラスターをスケールダウンすると、レプリカをホストする場合でもブローカーはシャットダウンされます。これにより、レプリケートが不十分なパーティションとなる可能性があり、一部のパーティションが最小 In-Sync レプリカ (ISR) を下回る可能性があります。この潜在的な問題を回避するために、remove-brokers モードは、削除されるブローカーからレプリカを移動します。これらのブローカーがレプリカをホストしなくなった場合は、スケールダウン操作を安全に実行できます。KafkaRebalance カスタムリソースの spec.brokers プロパティーで、削除するブローカーをリストとして指定します。

一般に、full リバランスモードを使用して、ブローカー間で負荷を分散することにより Kafka クラスターをリバランスします。add-brokers および remove-brokers モードは、クラスターをスケールアップまたはスケールダウンし、それに応じてレプリカを再調整する場合にのみ使用してください。

リバランスを実行する手順は、実際には 3 つの異なるモードで同じです。唯一の違いは、spec.mode プロパティーを介してモードを指定することと、必要に応じて、spec.brokers プロパティーを介して追加または削除されるブローカーを一覧表示することです。

18.3.2. 最適化提案の結果

最適化の提案が生成されると、概要とブローカーの負荷が返されます。

概要
要約は KafkaRebalance リソースに含まれています。サマリーは、提案されたクラスターリバランスの概要を提供し、関係する変更の規模を示します。正常に生成された最適化プロポーザルの要約は、KafkaRebalance リソースの Status.OptimizationResult プロパティーに含まれています。提供される情報は完全な最適化プロポーザルの概要になります。
ブローカーの負荷
ブローカーの負荷は、データが JSON 文字列として含まれる ConfigMap に保存されます。ブローカーの負荷は提案されたリバランスの前と後の値を表示するため、クラスターの各ブローカーへの影響を確認できます。

18.3.3. 最適化プロポーザルの手動承認または拒否

最適化プロポーザルのサマリーは、提案された変更の範囲を示しています。

KafkaRebalance リソースの名前を使用して、コマンドラインから要約を返すことができます。

最適化プロポーザルの要約を返す方法

oc describe kafkarebalance <kafka_rebalance_resource_name> -n <namespace>
Copy to Clipboard Toggle word wrap

jq コマンドライン JSON パーサーツールを使用することもできます。

jq を使用して最適化プロポーザルの要約を返す方法

oc get kafkarebalance -o json | jq <jq_query>.
Copy to Clipboard Toggle word wrap

サマリーを使用して、最適化プロポーザルを承認するか拒否するかを決定します。

最適化プロポーザルの承認
最適化プロポーザルを承認するには、KafkaRebalance リソースの strimzi.io/rebalance アノテーションを approve するように設定します。Cruise Control は、プロポーザルを Kafka クラスターに適用し、クラスターのリバランス操作を開始します。
最適化プロポーザルの拒否
最適化プロポーザルを承認しないことを選択した場合は、最適化ゴールの変更 または 任意のリバランスパフォーマンスチューニングオプションの更新 を行い、その後で別のプロポーザルを生成できます。strimzi.io/rebalance アノテーションを refresh に設定することで、KafkaRebalance リソースの新しい最適化提案を生成できます。

最適化プロポーザルを使用して、リバランスに必要な動作を評価します。たとえば、要約ではブローカー間およびブローカー内の動きについて記述します。ブローカー間のリバランスは、別々のブローカー間でデータを移動します。JBOD ストレージ設定を使用していると、ブローカー内のリバランスでは同じブローカー上のディスク間でデータが移動します。このような情報は、プロポーザルを承認しない場合でも有用な場合があります。

リバランスの際には Kafka クラスターに追加の負荷がかかるため、最適化プロポーザルを却下したり、承認を遅らせたりする場合があります。

次の例では、プロポーザルは別々のブローカー間のデータのリバランスを提案しています。リバランスには、ブローカー間での 55 個のパーティションレプリカ (合計 12 MB のデータ) の移動が含まれます。パーティションレプリカのブローカー間の移動は、パフォーマンスに大きな影響を与えますが、データ総量はそれほど多くありません。合計データが膨大な場合は、プロポーザルを却下するか、リバランスを承認するタイミングを考慮して Kafka クラスターのパフォーマンスへの影響を制限できます。

リバランスパフォーマンスチューニングオプションは、データ移動の影響を減らすのに有用です。リバランス期間を延長できる場合は、リバランスをより小さなバッチに分割できます。一回のデータ移動が少なくなると、クラスターの負荷も軽減できます。

最適化プロポーザルサマリーの例

Name:         my-rebalance
Namespace:    myproject
Labels:       strimzi.io/cluster=my-cluster
Annotations:  API Version:  kafka.strimzi.io/v1alpha1
Kind:         KafkaRebalance
Metadata:
# ...
Status:
  Conditions:
    Last Transition Time:  2022-04-05T14:36:11.900Z
    Status:                ProposalReady
    Type:                  State
  Observed Generation:     1
  Optimization Result:
    Data To Move MB:  0
    Excluded Brokers For Leadership:
    Excluded Brokers For Replica Move:
    Excluded Topics:
    Intra Broker Data To Move MB:         12
    Monitored Partitions Percentage:      100
    Num Intra Broker Replica Movements:   0
    Num Leader Movements:                 24
    Num Replica Movements:                55
    On Demand Balancedness Score After:   82.91290759174306
    On Demand Balancedness Score Before:  78.01176356230222
    Recent Windows:                       5
  Session Id:                             a4f833bd-2055-4213-bfdd-ad21f95bf184
Copy to Clipboard Toggle word wrap

このプロポーザルでは、24 のパーティションリーダーも別のブローカーに移動します。これには、パフォーマンスへの影響が少ない ZooKeeper の設定を変更する必要があります。

バランススコアは、最適化プロポーザルが承認される前後の Kafka クラスターの全体的なバランスの測定値です。バランススコアは、最適化ゴールに基づいています。すべてのゴールが満たされていると、スコアは 100 になります。達成されないゴールごとにスコアが減少します。バランススコアを比較して、Kafka クラスターのバランスがリバランス後よりも悪いかどうかを確認します。

18.3.4. 最適化プロポーザルの自動承認

時間を節約するために、最適化プロポーザルの承認プロセスを自動化できます。自動化により、最適化の提案を生成すると、クラスターのリバランスに直接進みます。

最適化プロポーザルの自動承認メカニズムを有効にするには、strimzi.io/rebalance-auto-approval アノテーションを true に設定して KafkaRebalance リソースを作成します。アノテーションが設定されていないか、false に設定されている場合、最適化プロポーザルには手動承認が必要です。

自動承認メカニズムが有効になっているリバランス要求の例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaRebalance
metadata:
  name: my-rebalance
  labels:
    strimzi.io/cluster: my-cluster
  annotations:
    strimzi.io/rebalance-auto-approval: "true"
spec:
  mode: # any mode
  # ...
Copy to Clipboard Toggle word wrap

最適化の提案を自動的に承認する場合でも、ステータスを確認できます。リバランスが完了すると、KafkaRebalance リソースのステータスは Ready に移動します。

18.3.5. 最適化プロポーザルサマリーのプロパティー

以下の表は、最適化プロポーザルのサマリーセクションに含まれるプロパティーについて説明しています。

Expand
表18.1 最適化プロポーザルに含まれるプロパティーの概要
JSON プロパティー説明

numIntraBrokerReplicaMovements

ディスクとクラスターのブローカーとの間で転送されるパーティションレプリカの合計数。

リバランス操作中のパフォーマンスへの影響度: 比較的高いが、numReplicaMovements よりも低い。

excludedBrokersForLeadership

サポートされていません。空のリストが返されます。

numReplicaMovements

個別のブローカー間で移動されるパーティションレプリカの数。

リバランス操作中のパフォーマンスへの影響度: 比較的高い。

onDemandBalancednessScoreBefore, onDemandBalancednessScoreAfter

最適化プロポーザルの生成前および生成後における、Kafka クラスターの全体的な 分散度 (balancedness) の値。

スコアは、違反した各ソフトゴールの BalancednessScore の合計を 100 から引いて算出されます。Cruise Control は、複数の要因を基にして BalancednessScore を各最適化ゴールに割り当てます。要因には、default.goals またはユーザー提供のゴールのリストでゴールの位置を示す優先順位が含まれます。

Before スコアは、Kafka クラスターの現在の設定を基にします。After スコアは、生成された最適化プロポーザルを基にします。

intraBrokerDataToMoveMB

同じブローカーのディスク間で移動される各パーティションレプリカのサイズの合計 (numIntraBrokerReplicaMovements も参照してください。

リバランス操作中のパフォーマンスへの影響度: 場合による。値が大きいほど、クラスターのリバランスの完了にかかる時間が長くなります。大量のデータを移動する場合、同じブローカーのディスク間で移動する方が個別のブローカー間で移動するよりも影響度が低くなります (dataToMoveMB 参照)。

recentWindows

最適化プロポーザルの基になるメトリックウインドウの数。

dataToMoveMB

個別のブローカーに移動される各パーティションレプリカのサイズの合計 (numReplicaMovements も参照してください。

リバランス操作中のパフォーマンスへの影響度: 場合による。値が大きいほど、クラスターのリバランスの完了にかかる時間が長くなります。

monitoredPartitionsPercentage

最適化プロポーザルの対象となる Kafka クラスターのパーティションの割合 (パーセント)。excludedTopics の数が影響します。

excludedTopics

KafkaRebalance リソースの spec.excludedTopicsRegex プロパティーに正規表現を指定した場合、その式と一致するすべてのトピック名がここにリストされます。これらのトピックは、最適化プロポーザルではパーティションレプリカとリーダーの移動の計算からは除外されます。

numLeaderMovements

リーダーが別のレプリカに切り替えられるパーティションの数。ZooKeeper 設定の変更を伴います。

リバランス操作中のパフォーマンスへの影響度: 比較的低い。

excludedBrokersForReplicaMove

サポートされていません。空のリストが返されます。

18.3.6. ブローカーのロードプロパティー

ブローカーの負荷は、JSON 形式の文字列として ConfigMap (KafkaRebalance カスタムリソースと同じ名前) に保存されます。この JSON 文字列は、各ブローカーのいくつかのメトリックにリンクする各ブローカー ID のキーを持つ JSON オブジェクトで設定されます。各メトリックは 3 つの値で設定されます。1 つ目は、最適化プロポーザルの適用前のメトリックの値です。2 つ目はプロポーザルの適用後に期待される値、3 つ目は、最初の 2 つの値の差 (後の値から前の値を引いた) です。

注記

ConfigMap は、KafkaRebalance リソースが ProposalReady 状態にあると表示され、リバランスが完了すると残ります。

ConfigMap の名前を使用して、コマンドラインからデータを表示できます。

ConfigMap データを返す方法

oc describe configmaps <my_rebalance_configmap_name> -n <namespace>
Copy to Clipboard Toggle word wrap

jq コマンドライン JSON パーサーツールを使用して、ConfigMap から JSON 文字列を抽出することもできます。

jq を使用した ConfigMap からの JSON 文字列の抽出

oc get configmaps <my_rebalance_configmap_name> -o json | jq '.["data"]["brokerLoad.json"]|fromjson|.'
Copy to Clipboard Toggle word wrap

以下の表は、最適化プロポーザルのブローカー負荷 ConfigMap に含まれるプロパティーについて説明しています。

Expand
JSON プロパティー説明

leaders

パーティションリーダーであるこのブローカーのレプリカ数。

replicas

このブローカーのレプリカ数。

cpuPercentage

定義された容量の割合をパーセントで表す CPU 使用率。

diskUsedPercentage

定義された容量の割合をパーセントで表す ディスク 使用率。

diskUsedMB

絶対ディスク使用量 (MB 単位)

networkOutRate

ブローカーのネットワーク出力レートの合計。

leaderNetworkInRate

このブローカーのすべてのパーティションリーダーレプリカに対するネットワーク入力レート。

followerNetworkInRate

このブローカーのすべてのフォロワーレプリカに対するネットワーク入力レート。

potentialMaxNetworkOutRate

このブローカーが現在ホストしているレプリカすべてのリーダーであった場合に実現される、仮定上の最大ネットワーク出力レート。

18.3.7. キャッシュされた最適化プロポーザル

Cruise Control は、設定済みのデフォルト最適化ゴールを基にして キャッシュされた最適化プロポーザル を維持します。キャッシュされた最適化プロポーザルはワークロードモデルから生成され、Kafka クラスターの現在の状況を反映するために 15 分ごとに更新されます。デフォルトの最適化ゴールを使用して最適化プロポーザルを生成する場合、Cruise Control は最新のキャッシュされたプロポーザルを返します。

キャッシュされた最適化プロポーザルの更新間隔を変更するには、Cruise Control デプロイメント設定の proposal.expiration.ms 設定を編集します。更新間隔を短くすると、Cruise Control サーバーの負荷が増えますが、変更が頻繁に行われるクラスターでは、更新間隔を短くするよう考慮してください。

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hat