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

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

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

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

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

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

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

oc describe kafkarebalance <kafka_rebalance_resource_name> -n <namespace>

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

oc get kafkarebalance -o json | jq <jq_query>.

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

最適化プロポーザルを使用して、リバランスに必要な動作を評価します。たとえば、要約ではブローカー間およびブローカー内の動きについて記述します。ブローカー間のリバランスは、別々のブローカー間でデータを移動します。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

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

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

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

最適化プロポーザルの自動承認メカニズムを有効にするには、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
  # ...

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

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

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

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

oc describe configmaps <my_rebalance_configmap_name> -n <namespace>

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

oc get configmaps <my_rebalance_configmap_name> -o json | jq '.["data"]["brokerLoad.json"]|fromjson|.'

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

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

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