第8章 Cruise Control によるクラスターのリバランス

Cruise Control は、分散された Kafka クラスターを効率的に実行するための時間および労力を削減します。

通常、クラスターの負荷は時間とともに不均等になります。大量のメッセージトラフィックを処理するパーティションは、使用可能なブローカー全体で不均等に分散される可能性があります。クラスターを再分散するには、管理者はブローカーの負荷を監視し、トラフィックの多いパーティションを容量に余裕のあるブローカーに手作業で再割り当てします。

Cruise Control はクラスターのリバランス処理を自動化します。CPU、ディスク、およびネットワーク負荷を基にして、クラスターにおけるリソース使用のワークロードモデルを構築し、パーティションの割り当てをより均等にする、最適化プロポーザル (承認または拒否可能) を生成します。これらのプロポーザルの算出には、設定可能な最適化ゴールが複数使用されます。

最適化プロポーザルを承認すると、Cruise Control はそのプロポーザルを Kafka クラスターに適用します。クラスターのリバランス操作が完了すると、ブローカー Pod はより効率的に使用され、Kafka クラスターはより均等に分散されます。

Cruise Control は Kafka クラスターをリバランスするために、最適化ゴールを使用して、承認または拒否可能な最適化プロポーザルを生成します。

最適化ゴールは、Kafka クラスター全体のワークロード再分散およびリソース使用の制約です。AMQ Streams は、Cruise Control プロジェクトで開発された最適化ゴールのほとんどをサポートします。以下に、サポートされるゴールをデフォルトの優先度順に示します。

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

AMQ Streams カスタムリソースでのゴールの設定

Kafka および KafkaRebalance カスタムリソースで最適化ゴールを設定します。Cruise Control には、必ず満たさなければならない ハード 最適化ゴールの設定と、マスター、デフォルト、およびユーザー提供最適化ゴールの設定があります。リソースディストリビューションの最適化ゴール (ディスク、ネットワークインバウンド、ネットワークアウトバウンド、および CPU) は、ブローカーリソースの 容量制限 の対象となります。

以下のセクションでは、各ゴール設定の詳細を説明します。

ハードゴールおよびソフトゴール

ハードゴールは最適化プロポーザルで必ず満たさなければならないゴールです。ハードゴールとして設定されていないゴールはソフトゴールと呼ばれます。ソフトゴールは ベストエフォート 型のゴールと解釈できます。最適化プロポーザルで満たす必要はありませんが、最適化の計算に含まれます。すべてのハードゴールを満たし、1 つ以上のソフトゴールに違反する最適化プロポーザルは有効です。

Cruise Control は、すべてのハードゴールを満たし、優先度順にできるだけ多くのソフトゴールを満たす最適化プロポーザルを算出します。すべてのハードゴールを満たさない最適化プロポーザルは Cruise Control によって拒否され、ユーザーには送信されません。

Cruise Control では、以下のマスター最適化ゴールがハードゴールとして事前設定されています。

RackAwareGoal; MinTopicLeadersPerBrokerGoal; ReplicaCapacityGoal; DiskCapacityGoal; NetworkInboundCapacityGoal; NetworkOutboundCapacityGoal; CpuCapacityGoal

Kafka.spec.cruiseControl.config の hard.goals プロパティーを編集し、Cruise Control のデプロイメント設定でハードゴールを設定します。

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
  zookeeper:
    # ...
  entityOperator:
    topicOperator: {}
    userOperator: {}
  cruiseControl:
    brokerCapacity:
      inboundNetwork: 10000KB/s
      outboundNetwork: 10000KB/s
    config:
      hard.goals: >
        com.linkedin.kafka.cruisecontrol.analyzer.goals.NetworkInboundCapacityGoal,
        com.linkedin.kafka.cruisecontrol.analyzer.goals.NetworkOutboundCapacityGoal
      # ...

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

skipHardGoalCheck: true が KafkaRebalance カスタムリソースに指定された場合、Cruise Control はユーザー提供の最適化ゴールのリスト (KafkaRebalance.spec.goals 内) に設定済みのハードゴール (hard.goals) がすべて含まれていることをチェックしません。そのため、すべてではなく一部のユーザー提供の最適化ゴールが hard.goals リストにある場合、skipHardGoalCheck: true が指定されていてもハードゴールとして処理されます。

マスター最適化ゴール

マスター最適化ゴールはすべてのユーザーが使用できます。マスター最適化ゴールにリストされていないゴールは、Cruise Control 操作で使用できません。

Cruise Control の デプロイメント設定を変更しない限り、AMQ Streams は以下のマスター最適化ゴールを優先度順 (降順) に Cruise Control から継承します。

RackAwareGoal; ReplicaCapacityGoal; DiskCapacityGoal; NetworkInboundCapacityGoal; NetworkOutboundCapacityGoal; CpuCapacityGoal; ReplicaDistributionGoal; PotentialNwOutGoal; DiskUsageDistributionGoal; NetworkInboundUsageDistributionGoal; NetworkOutboundUsageDistributionGoal; CpuUsageDistributionGoal; TopicReplicaDistributionGoal; LeaderReplicaDistributionGoal; LeaderBytesInDistributionGoal; PreferredLeaderElectionGoal

これらのゴールの 6 個が ハードゴール として事前設定されます。

複雑さを軽減するため、1 つ以上のゴールを KafkaRebalance リソースでの使用から完全に除外する必要がある場合を除き、継承されるマスター最適化ゴールを使用することが推奨されます。必要な場合、マスター最適化ゴールの優先順位は デフォルトの最適化ゴール の設定で変更できます。

マスター最適化ゴールは、必要であれば Cruise Control のデプロイメント設定である Kafka.spec.cruiseControl.config.goals で設定できます。

デフォルトの最適化ゴール

Cruise Conrol はデフォルトの最適化ゴール を使用して キャッシュされた最適化プロポーザル を生成します。キャッシュされた最適化プロポーザルの詳細は、「最適化プロポーザルの概要」 を参照してください。

ユーザー提供の最適化ゴール を KafkaRebalance カスタムリソースに設定すると、デフォルトの最適化ゴールを上書きできます。

Cruise Control のデプロイメント設定に default.goals を指定しない限り、マスター最適化ゴールがデフォルトの最適化ゴールとして使用されます。この場合、マスター最適化ゴールを使用して、キャッシュされた最適化プロポーザルが生成されます。

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
  zookeeper:
    # ...
  entityOperator:
    topicOperator: {}
    userOperator: {}
  cruiseControl:
    brokerCapacity:
      inboundNetwork: 10000KB/s
      outboundNetwork: 10000KB/s
    config:
      default.goals: >
         com.linkedin.kafka.cruisecontrol.analyzer.goals.RackAwareGoal,
         com.linkedin.kafka.cruisecontrol.analyzer.goals.ReplicaCapacityGoal,
         com.linkedin.kafka.cruisecontrol.analyzer.goals.DiskCapacityGoal
      # ...

デフォルトの最適化ゴールの指定がない場合、マスター最適化ゴールを使用して、キャッシュされたプロポーザルが生成されます。

ユーザー提供の最適化ゴール

ユーザー提供の最適化ゴールは、特定の最適化プロポーザルの設定済みのデフォルトゴールを絞り込みます。必要に応じて、KafkaRebalance カスタムリソースの spec.goals で設定できます。

KafkaRebalance.spec.goals

ユーザー提供の最適化ゴールは、さまざまな状況の最適化プロポーザルを生成できます。たとえば、ディスクの容量やディスクの使用率を考慮せずに、Kafka クラスター全体でリーダーレプリカの分散を最適化したい場合があります。この場合、リーダーレプリカ分散の単一のユーザー提供ゴールが含まれる KafkaRebalance カスタムリソースを作成します。

ユーザー提供の最適化ゴールには以下が必要になります。

最適化プロポーザルの生成時に設定済みのハードゴールを無視するには、skipHardGoalCheck: true プロパティーを KafkaRebalance カスタムリソースに追加します。「最適化プロポーザルの生成」 を参照してください。

最適化プロポーザルは、パーティションのワークロードをブローカー間でより均等に分散することで、Kafka クラスターの負荷をより均等にするために提案された変更の概要です各最適化プロポーザルは、そのプロポーザルの生成に使用された 最適化ゴール のセットが基になっており、ブローカーリソースの設定済みの容量制限 の対象になります。

最適化プロポーザルは KafkaRebalance カスタムリソースの Status.Optimization Result プロパティーに含まれます。提供される情報は完全な最適化プロポーザルの概要になります。概要を使用して以下を決定します。

最適化プロポーザルはすべてドライランです。最適化プロポーザルを最初に生成しないと、クラスターのリバランスを承認できません。生成できる最適化プロポーザルの数に制限はありません。

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

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

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

最適化プロポーザルの内容

以下の表は、最適化プロポーザルに含まれるプロパティーを表しています。

クラスターリバランスのパフォーマンスチューニングオプションを調整できます。これらのオプションは、リバランスのパーティションレプリカおよびリーダーシップの移動が実行される方法を制御し、また、リバランス操作に割り当てられた帯域幅も制御します。

パーティション再割り当てコマンド

最適化プロポーザル は、個別のパーティション再割り当てコマンドで構成されています。プロポーザルを 承認 すると、Cruise Control サーバーはこれらのコマンドを Kafka クラスターに適用します。

パーティション再割り当てコマンドは、以下のいずれかの操作で構成されます。

Cruise Control によって、パーティション再割り当てコマンドがバッチで Kafka クラスターに発行されます。リバランス中のクラスターのパフォーマンスは、各バッチに含まれる各タイプの移動数に影響されます。

レプリカの移動ストラテジー

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

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

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

リバランスチューニングオプション

Cruise Control には、上記のリバランスパラメーターを調整する設定オプションが複数あります。これらのチューニングオプションは、Cruise Control サーバー または 最適化プロポーザル レベルのいずれかに設定できます。

関連する設定の概要を以下に示します。

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

Kafka.spec.cruiseControl の config プロパティーには設定オプションがキーとして含まれ、それらの値は以下の JSON タイプの 1 つになります。

AMQ Streams によって直接管理されるオプション以外は、Cruise Control ドキュメント の「Configurations」セクションにリストされているすべてのオプションを指定および設定できます。ここに示されているキーの 1 つと同等の設定オプションまたはキーの 1 つで始まる設定オプションは、編集できません。

制限されたオプションが指定された場合、そのオプションは無視され、警告メッセージが Cluster Operator のログファイルに出力されます。すべてのサポートされるオプションは Cruise Control に渡されます。

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  # ...
  cruiseControl:
    # ...
    config:
      default.goals: >
         com.linkedin.kafka.cruisecontrol.analyzer.goals.RackAwareGoal,
         com.linkedin.kafka.cruisecontrol.analyzer.goals.ReplicaCapacityGoal
      cpu.balance.threshold: 1.1
      metadata.max.age.ms: 300000
      send.buffer.bytes: 131072
    # ...

CORS (Corss-Origin Resource Sharing) の設定

CORS (Cross-Origin Resource Sharing) を使用すると、REST API へのアクセスに許可されるメソッドおよびアクセス元 URL を指定できます。

デフォルトでは、Cruise Control REST API の CORS は無効になっています。有効にすると、Kafka クラスターの状態の読み取り専用アクセスを要求する GET リクエストのみが許可されます。そのため、AMQ Streams コンポーネントとは異なるオリジンで実行されている外部アプリケーションは、Cruise Control API に POST リクエストを送信できません。ただし、これらのアプリケーションは、現在のクラスターの負荷や最新の最適化プロポーザルなどの、Kafka クラスターに関する読み取り専用の情報へアクセスするための GET リクエストを送信できます。

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  # ...
  cruiseControl:
    # ...
    config:
      webserver.http.cors.enabled: true
      webserver.http.cors.origin: "*"
      webserver.http.cors.exposeheaders: "User-Task-ID,Content-Type"
    # ...

詳細は、Cruise Control Wiki の「REST APIs」を参照してください。

容量の設定

Cruise Control は 容量制限 を使用して、リソース分散の最適化ゴールが破損しているかどうかを判断します。このタイプには 4 つのゴールがあります。

Kafka ブローカーリソースの容量制限は、Kafka.spec.cruiseControl の brokerCapacity プロパティーに指定します。これらはデフォルトで有効になっており、デフォルト値を変更できます。容量制限は、標準の OpenShift バイト単位 (K、M、G、および T) または同等 (2 のべき乗) の bibyte (Ki、Mi、Gi、および Ti) を使用して、以下のブローカーリソースに設定できます。

AMQ Streams の Kafka ブーカーは同種であるため、Cruise Control は監視している各ブローカーに同じ容量制限を適用します。

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  # ...
  cruiseControl:
    # ...
    brokerCapacity:
      disk: 100Gi
      cpuUtilization: 100
      inboundNetwork: 10000KiB/s
      outboundNetwork: 10000KiB/s
    # ...

ロギングの設定

Cruise Control には独自の設定可能なロガーがあります。

Cruise Control では Apache log4j 2 ロガー実装が使用されます。

logging プロパティーを使用してロガーおよびロガーレベルを設定します。

ログレベルを設定するには、ロガーとレベルを直接指定 (インライン) するか、またはカスタム (外部) ConfigMap を使用します。ConfigMap を使用する場合、logging.valueFrom.configMapKeyRef.name プロパティーを外部ロギング設定が含まれる ConfigMap の名前に設定します。ConfigMap 内では、ロギング設定は log4j.properties を使用して記述されます。logging.valueFrom.configMapKeyRef.name および logging.valueFrom.configMapKeyRef.key プロパティーはいずれも必須です。Cluster Operator の実行時に、指定された正確なロギング設定を使用する ConfigMap がカスタムリソースを使用して作成され、その後は調整のたびに再作成されます。カスタム ConfigMap を指定しない場合、デフォルトのロギング設定が使用されます。特定のロガー値が設定されていない場合、上位レベルのロガー設定がそのロガーに継承されます。inline および external ロギングの例は次のとおりです。

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
# ...
spec:
  cruiseControl:
    # ...
    logging:
      type: inline
      loggers:
        rootLogger.level: "INFO"
    # ...

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
# ...
spec:
  cruiseControl:
    # ...
    logging:
      type: external
      valueFrom:
        configMapKeyRef:
          name: customConfigMap
          key: cruise-control-log4j.properties
    # ...

Cruise Control を AMQ Streams クラスターにデプロイするいは、Kafka リソースの cruiseControl プロパティーを使用して設定を定義した後、リソースを作成または更新します。

Kafka クラスターごとに Cruise Control のインスタンスを 1 つデプロイします。

自動作成されたトピック

以下の表は、Cruise Control のデプロイ時に自動作成される 3 つのトピックを表しています。これらのトピックは、Cruise Control が適切に動作するために必要であるため、削除または変更しないでください。

Cruise Control に必要なレコードを削除しないようにするため、自動作成されたトピックではログの圧縮は無効になっています。

KafkaRebalance リソースを作成または更新すると、Cruise Control は 設定済みの最適化ゴールを基にして、Kafka クラスターの 最適化プロポーザル を生成します。

最適化プロポーザルの情報を分析して、プロポーザルを承認するかどうかを決定します。

状態が ProposalReady の場合、Cruise Control によって生成された最適化プロポーザルを承認できます。その後、Cruise Control は最適化プロポーザルを Kafka クラスターに適用して、パーティションをブローカーに再割り当てし、パーティションのリーダーを変更します。

クラスターリバランス操作を開始すると、完了まで時間がかかることがあり、Kafka クラスターの全体的なパフォーマンスに影響します。

実行中のクラスターリバランス操作を停止するには、stop アノテーションを KafkaRebalance カスタムリソースに適用します。これにより、現在のパーティション再割り当てのバッチ処理を完了し、リバランスを停止するよう Cruise Control が指示されます。リバランスの停止時、完了したパーティションの再割り当てはすで適用されています。そのため、Kafka クラスターの状態は、リバランス操作の開始前とは異なります。さらなるリバランスが必要な場合は、新しい最適化プロポーザルを生成してください。

KafkaRebalance リソースの作成時や、Cruise Control との対話中に問題が発生した場合、エラーとその修正方法の詳細がリソースの状態で報告されます。また、リソースも NotReady の状態に変わります。

クラスターリバランス操作を続行するには、KafkaRebalance リソース自体の問題または Cruise Control デプロイメント全体の問題を修正する必要があります。問題には以下が含まれる可能性があります。

問題の修正後、refresh アノテーションを KafkaRebalance リソースに付ける必要があります。「refresh」(更新) 中、Cruise Control サーバーから新しい最適化プロポーザルが要求されます。