第21章 Cruise Control を使用したクラスターのリバランス

サポートされているゴールは事前に定義されており、Cruise Control 最適化プロポーザルの生成に使用できます。サポートされているゴールとしてリストされていないゴールは、Cruise Control 操作では使用できません。サポートされているゴールの一部は、ハードゴールとして事前設定されています。

Kafka.spec.cruiseControl.config.goals でサポートされているゴールを設定します。

最適化プロポーザルを生成するには、ハードゴールを満たす必要があります。ソフトゴールは、すべてのハードゴールが満たされた後に Cruise Control が達成しようとするベストエフォートゴールです。ハードゴールとソフトゴールの分類は、Cruise Control コードで固定されており、変更できません。

Cruise Control は、まずハードゴールの達成を優先し、次にリストされている順序に従ってソフトゴールに取り組みます。すべてのハードゴールを満たすプロポーザルは、たとえソフトゴールの一部に違反していたとしても有効です。

たとえば、ソフトゴールとしては、トピックのレプリカを均等に分散することが考えられます。Cruise Control は、ソフトゴールが完全に満たされていない場合でも、最適化プロポーザルを生成し続けます。

Kafka.spec.cruiseControl.config.hard.goals を使用して、Cruise Control デプロイメントでハードゴールを設定します。

ハードゴールの数を増やすと、Cruise Control が最適化プロポーザルを生成する可能性が低くなります。

Cruise Control はデフォルトゴールを使用して最適化プロポーザルを生成します。

Cruise Control デプロイメント設定で default.goals が指定されていない場合、Streams for Apache Kafka は、goals で指定されたサポートされているゴールのリストに default.goals を設定します。

このサポートされているゴールリストに基づく最適化プロポーザルがその後生成され、キャッシュされます。

Kafka.spec.cruiseControl.config.default.goals でデフォルトゴールを設定します。

プロポーザル固有の最適化ゴールは、特定のゴールリストに基づいた最適化プロポーザルの作成をサポートします。KafkaRebalance リソースにプロポーザル固有ゴールが設定されていない場合は、デフォルトゴールが使用されます。

KafkaRebalance.spec.goals でプロポーザル固有ゴールを設定し、サポートされている最適化ゴールのサブセットをカスタマイズ用に指定します。

たとえば、単一のプロポーザル固有のゴールを定義することで、ディスク容量や使用率を考慮せずに、Kafka クラスター全体でトピックリーダーレプリカの分散を最適化できます。

Cruise Control の デプロイメント設定 を変更しない限り、Streams for Apache Kafka は Cruise Control からゴールを優先度の降順で継承します。

次のリストは、Streams for Apache Kafka が Cruise Control から継承したサポートされているゴールを、優先順位の降順で示しています。ハードとラベル付けされたゴールは、最適化プロポーザルのために満たす必要がある必須の制約です。

リソース配分ゴールは、ブローカーリソースの 容量制限 の影響を受けます。

各最適化ゴールの詳細は、Cruise Control Wiki の Goals を参照してください。

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
  annotations:
    strimzi.io/node-pools: enabled
    strimzi.io/kraft: enabled
spec:
  kafka:
    # ...
  entityOperator:
    topicOperator: {}
    userOperator: {}
  cruiseControl:
    brokerCapacity:
      inboundNetwork: 10000KB/s
      outboundNetwork: 10000KB/s
    config:
      #`default.goals` (superset) must also include all `hard.goals` (subset)
      default.goals: >
        com.linkedin.kafka.cruisecontrol.analyzer.goals.RackAwareGoal,
        com.linkedin.kafka.cruisecontrol.analyzer.goals.ReplicaCapacityGoal,
        com.linkedin.kafka.cruisecontrol.analyzer.goals.DiskCapacityGoal
        com.linkedin.kafka.cruisecontrol.analyzer.goals.NetworkInboundCapacityGoal,
        com.linkedin.kafka.cruisecontrol.analyzer.goals.NetworkOutboundCapacityGoal
      hard.goals: >
        com.linkedin.kafka.cruisecontrol.analyzer.goals.RackAwareGoal
        com.linkedin.kafka.cruisecontrol.analyzer.goals.NetworkInboundCapacityGoal,
        com.linkedin.kafka.cruisecontrol.analyzer.goals.NetworkOutboundCapacityGoal
      # ...

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaRebalance
metadata:
  name: my-rebalance
  labels:
    strimzi.io/cluster: my-cluster
spec:
  goals:
    - RackAwareGoal
    - TopicReplicaDistributionGoal
  skipHardGoalCheck: true

KafkaRebalance カスタムリソースで skipHardGoalCheck: true が指定されている場合、Cruise Control は、プロポーザル固有ゴールに設定されたすべてのハードゴールが含まれているか確認しません。これにより、最適化プロポーザルを生成する際の柔軟性が向上しますが、すべてのハードゴールを満たさないプロポーザルにつながる可能性があります。

ただし、skipHardGoalCheck: true の場合でも、プロポーザル固有ゴールに含まれるハードゴールは、Cruise Control にハードゴールとして扱われます。

リバランスのプロポーザルは 4 つのモードで生成できます。モードは、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 <kafka_rebalance_resource_name> -n <namespace> -o json | jq '.status.optimizationResult'

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

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

リバランスの際には Kafka クラスターに追加の負荷がかかるため、最適化プロポーザルを却下したり、承認を遅らせたりする場合があります。プロポーザルが長期間遅れると、クラスターの負荷が大幅に変化する可能性があるため、新しいプロポーザルをリクエストしたほうがよい場合があります。

次の例では、プロポーザルは別々のブローカー間のデータのリバランスを提案しています。リバランスには、ブローカー間での 55 個のパーティションレプリカ (合計 12 MB のデータ) の移動が含まれます。このプロポーザルでは、24 のパーティションリーダーも別のブローカーに移動します。これにはクラスターメタデータの変更が必要ですが、パフォーマンスへの影響はわずかです。

バランススコアは、最適化プロポーザルが承認される前後の Kafka クラスターの全体的なバランスの測定値です。バランススコアは、最適化ゴールに基づいています。すべてのゴールが満たされていると、スコアは 100 になります。達成されないゴールごとにスコアが減少します。バランススコアを比較して、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

パーティションレプリカのブローカー間の移動は、パフォーマンスに大きな影響を与えますが、データ総量はそれほど多くありません。合計データが膨大な場合は、プロポーザルを却下するか、リバランスを承認するタイミングを考慮して 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 に移動します。

ブローカーの負荷データは、リバランス後のリソースの現在の使用状況と予想される使用状況に関する情報を提供します。データは ConfigMap (KafkaRebalance リソースと同じ名前) に JSON 形式の文字列として保存されます。

Kafka のリバランスプロポーザルが ProposalReady 状態になると、Streams for Apache Kafka は、Cruise Control から生成されたブローカーメトリクスの JSON 文字列を含む ConfigMap (KafkaRebalance カスタムリソースの名前から命名) を作成します。各ブローカーには、次の 3 つの値で表される主要なメトリクスのセットがあります。

この ConfigMap は、リバランスが完了した後もアクセスできます。

コマンドラインからこのデータを表示するには、ConfigMap の名前を使用します。

oc describe configmaps <my_rebalance_configmap_name> -n <namespace>

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

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

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

ワークロードが急速に変化するクラスターの場合は、最適化プロポーザルが最新の状態を反映するように、更新間隔を短くすることが推奨されます。ただし、間隔を短くすると、Cruise Control サーバーの負荷が増加します。更新レートを調整するには、Cruise Control デプロイメント設定の proposal.expiration.ms 設定を変更します。

クラスターリバランスのパフォーマンスは、パーティション再割り当てコマンドのバッチに適用される レプリカ移動ストラテジー の影響も受けます。デフォルトでは、Cruise Control は BaseReplicaMovementStrategy を使用し、生成された順序で再割り当てを適用します。ただし、このストラテジーでは、大規模なパーティションの再割り当てが生成され、最初に順序付けされると、他のパーティションの再割り当てが遅延される可能性があります。

Cruise Control は、最適化プロポーザルに適用できる代替のレプリカ移動ストラテジーを 4 つ提供します。

これらのストラテジーをシーケンスとして設定できます。最初のストラテジーは、内部ロジックを使用して 2 つのパーティション再割り当ての比較を試みます。再割り当てが同等である場合は、順番を決定するために再割り当てをシーケンスの次のストラテジーに渡します。

ブローカー内のバランス調整では、同じブローカー上のディスク間でデータをシフトします。これは、JBOD ストレージと複数のディスクを使用したデプロイメントに役立ちます。このタイプのバランス調整では、ブローカー間でのバランス調整よりもネットワークオーバーヘッドが少なくなります。

ブローカー内のバランス調整を有効にするには、KafkaRebalance.spec で rebalanceDisk を true に設定します。これが有効になっている場合、Cruise Control はブローカー内ゴールを自動的に設定し、ブローカー間のゴールを無視するため、goals フィールドは指定しないでください。Cruise Control はブローカー間およびブローカー内の分散を同時に実行しません。

Cruise Control または個別のリバランスを設定するときに、次のリバランスチューニングオプションを設定できます。

デフォルト設定を変更すると、リバランスの完了までにかかる時間と、リバランス中の Kafka クラスターの負荷に影響します。値を小さくすると負荷は減りますが、かかる時間は長くなります。その逆も同様です。