21장. 클러스터 재조정에 Cruise Control 사용

지원되는 목표는 사전 정의되어 있으며 Cruise Control 최적화 제안을 생성하는 데 사용할 수 있습니다. 지원되는 목표로 나열되지 않은 목표는 Cruise Control 작업에서 사용할 수 없습니다. 지원되는 일부 목표는 하드 목표로 사전 설정됩니다.

Kafka.spec.cruiseControl.config.goals 에서 지원되는 목표를 구성합니다.

최적화 제안이 생성되려면 하드 목표를 충족해야 합니다. 소프트 목표는 Cruise Control이 모든 하드 목표를 충족 한 후 달성하려고하는 가장 좋은 목표입니다. 하드 및 소프트 목표의 분류는 크루즈 제어 코드에서 수정되며 변경할 수 없습니다.

크루즈 컨트롤은 먼저 하드 목표를 충족하는 우선 순위를 지정한 다음 나열된 순서대로 소프트 목표를 해결합니다. 모든 하드 목표를 충족하는 제안은 일부 소프트 목표를 위반하더라도 유효합니다.

예를 들어 소프트 목표는 주제의 복제본을 균등하게 배포하는 것입니다. 크루즈 컨트롤은 소프트 목표를 완전히 충족하지 않더라도 최적화 제안을 계속 생성합니다.

Kafka.spec.cruiseControl.config.hard.goals 를 사용하여 Cruise Control 배포에서 하드 목표를 구성합니다.

구성된 하드 목표 수를 늘리면 Cruise Control이 최적화 제안을 생성할 가능성을 줄일 수 있습니다.

cruise Control은 기본 목표를 사용하여 최적화 제안을 생성합니다.

default.goals 가 Cruise Control 배포 구성에 지정되지 않은 경우 Apache Kafka의 Streams는 목표에 지정된 지원 대상 목록에 default.goals 를 구성합니다.

그런 다음 지원되는 이 목표 목록을 기반으로 최적화 제안이 생성되고 캐시됩니다.

Kafka.spec.cruiseControl.config.default.goals 에서 기본 목표를 구성합니다.

제안별 최적화 목표는 특정 목표 목록을 기반으로 최적화 제안을 작성할 수 있도록 지원합니다. KafkaRebalance 리소스에 제안 특정 목표를 설정하지 않으면 기본 목표를 사용합니다.

사용자 지정에 지원되는 최적화 목표의 하위 집합을 지정하여 KafkaRebalance.spec.goals 에서 제안별 목표를 구성합니다.

예를 들어 단일 제안별 목표를 정의하여 디스크 용량 또는 사용률을 고려하지 않고 Kafka 클러스터에서 주제 리더 복제본 배포를 최적화할 수 있습니다.

Cruise Control 배포 구성 을 변경하지 않는 한, Apache Kafka의 Streams는 Cruise Control의 목표를 내림차순으로 상속합니다.

다음 목록은 Cruise Control에서 Stream for Apache Kafka에서 상속하는 지원되는 목표를 내림차순으로 보여줍니다. 하드로 레이블이 지정된 목표는 최적화 제안서에 충족해야 하는 필수 제약 조건입니다.

리소스 배포 목표는 브로커 리소스에 대한 용량 제한 의 적용을 받습니다.

각 최적화 목표에 대한 자세한 내용은 Cruise Control Wiki의 목표를 참조하십시오.

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

skipHardGoalCheck: true 가 KafkaRebalance 사용자 정의 리소스에 지정된 경우 Cruise Control은 제안 특정 목표에 구성된 모든 하드 목표를 포함하는지 확인하지 않습니다. 이를 통해 최적화 제안을 더 유연하게 생성할 수 있지만 모든 어려운 목표를 충족하지 않는 제안이 발생할 수 있습니다.

그러나 제안 특정 목표에 포함된 모든 하드 목표는 skipHardGoalCheck: true 를 사용하여 Cruise Control의 어려운 목표로 계속 처리됩니다.

리밸런스에 대한 제안은 KafkaRebalance 사용자 정의 리소스의 spec.mode 속성을 사용하여 지정하는 네 가지 모드로 생성할 수 있습니다.

일반적으로 전체 리밸런스 모드를 사용하여 브로커 간에 부하를 분산하여 Kafka 클러스터를 재조정합니다. 클러스터를 확장하거나 축소하고 그에 따라 복제본을 재조정하려는 경우에만 add-brokers 및 remove-brokers 모드를 사용합니다.

리밸런스를 실행하는 절차는 세 가지 모드에서 실제로 동일합니다. 유일한 차이점은 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'

요약을 사용하여 최적화 제안을 승인하거나 거부할지 여부를 결정합니다.

재조정에 필요한 효과를 평가하기 위해 최적화 제안을 사용하십시오. 예를 들어 요약은broker 및 intra-broker 이동을 설명합니다. 브랜드 간 리밸런스(broker)는 별도의 브로커 간에 데이터를 리밸런싱합니다. Intra-broker 재조정은 JBOD 스토리지 구성을 사용할 때 동일한 브로커의 디스크 간에 데이터를 이동합니다. 이러한 정보는 귀하가 진행하지 않고 제안을 승인하더라도 유용할 수 있습니다.

재조정할 때 Kafka 클러스터에서 추가 로드로 인해 최적화 제안을 거부하거나 승인을 지연할 수 있습니다. 제안서가 너무 오래 지연되면 클러스터 부하가 크게 변경될 수 있으므로 새로운 제안을 요청하는 것이 더 좋습니다.

다음 예에서 제안서는 별도의 브로커 간 데이터 재조정을 제안합니다. 리밸런스에는 브로커 간에 총 12MB의 데이터가 있는 55 파티션 복제본의 이동이 포함됩니다. 이 제안은 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 로 이동합니다.

브로커 로드 데이터는 재조정에 따른 리소스의 현재 및 예상 사용량에 대한 통찰력을 제공합니다. 데이터는 JSON 형식 문자열과 KafkaRebalance 리소스와 동일한 이름으로 ConfigMap 에 저장됩니다.

Kafka 리밸런스 제안서가 ProposalReady 상태에 도달하면 Streams for Apache Kafka는 Cruise Control에서 생성된 브로커 지표의 JSON 문자열이 포함된 ConfigMap ( KafkaRebalance 사용자 정의 리소스 뒤에 이름이 지정됨)을 생성합니다. 각 브로커에는 다음 세 가지 값으로 표시되는 주요 지표 세트가 있습니다.

이 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은 BaseReplica CryostatmentStrategy 를 사용하여 생성된 순서대로 재할당을 적용합니다. 그러나 이 전략은 대규모 파티션 재할당이 생성된 경우 다른 파티션 재할당이 지연될 수 있습니다.

cruise Control은 최적화 제안에 적용할 수 있는 네 가지 대체 복제본 이동 전략을 제공합니다.

이러한 전략은 시퀀스로 구성할 수 있습니다. 첫 번째 전략은 내부 논리를 사용하여 두 파티션 재할당을 비교하려고 합니다. 재할당이 동일한 경우 순서에서 다음 전략으로 전달하여 순서를 결정하는 등의 작업을 수행합니다.

Intra-broker balancing는 JBOD 스토리지 및 여러 디스크를 사용한 배포에 유용합니다. 이러한 유형의 분산은 브루커 간 분산보다 네트워크 오버헤드가 줄어듭니다.

intra-broker 밸런싱을 활성화하려면 KafkaRebalance.spec 에서 rebalanceDisk 를 true 로 설정합니다. 이 기능이 활성화되면 목표 필드를 지정하지 마십시오. Cruise Control은 브랜드 내 목표를 자동으로 구성하고 브랜드 간 목표를 무시하기 때문입니다. 크루즈 컨트롤은broker와 intra-broker 밸런싱을 동시에 수행하지 않습니다.

Cruise Control 또는 개별 리밸런스를 구성할 때 다음과 같은 재조정 튜닝 옵션을 설정할 수 있습니다.

기본 설정을 변경하면 리밸런스가 완료하는 데 걸리는 시간과 재조정 중 Kafka 클러스터에 배치된 로드에 영향을 미칩니다. 더 낮은 값을 사용하면 로드가 줄어들지만 사용된 시간이 증가하고 그 반대의 경우도 마찬가지입니다.