Kubernetes에서 Kafka 클러스터에 적합한 크기 결정

메모. 번역: 이 기사에서 Banzai Cloud는 사용자 정의 도구를 사용하여 Kubernetes 내에서 Kafka를 더 쉽게 사용할 수 있는 방법의 예를 공유합니다. 다음 지침에서는 인프라의 최적 크기를 결정하고 필요한 처리량을 달성하도록 Kafka 자체를 구성하는 방법을 보여줍니다.

Apache Kafka는 안정적이고 확장 가능한 고성능 실시간 스트리밍 시스템을 만들기 위한 분산 스트리밍 플랫폼입니다. Kubernetes를 사용하면 인상적인 기능을 확장할 수 있습니다. 이를 위해 우리는 개발했습니다. 오픈 소스 Kafka 연산자 그리고 도구라는 슈퍼튜브. 이를 통해 Kubernetes에서 Kafka를 실행하고 브로커 구성 미세 조정, 재조정을 통한 메트릭 기반 확장, 랙 인식, "소프트"와 같은 다양한 기능을 사용할 수 있습니다. (우아한) 업데이트 출시 등

클러스터에서 Supertube를 사용해 보세요.

curl https://getsupertubes.sh | sh и supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>

아니면 연락하세요 선적 서류 비치. 또한 Supertubes 및 Kafka 연산자를 사용하여 자동화된 작업인 Kafka의 일부 기능에 대해 읽을 수도 있습니다. 우리는 이미 블로그에 이에 대해 썼습니다:

• 안 돼! Kubernetes를 위한 또 다른 Kafka 연산자;
• Prometheus 메트릭을 기반으로 Kafka 모니터링 및 운영;
• Kubernetes의 Kafka 랙 인식;
• Istio를 통해 Apache Kafka 실행 - 벤치마크;
• Kafka 운영자를 통한 사용자 인증 및 액세스 제어 클러스터;
• Kubernetes의 Kafka 롤링 업그레이드 및 동적 구성;
• Kafka용 Envoy 프로토콜 필터, 메시형.

Kubernetes에 Kafka 클러스터를 배포하기로 결정하면 기본 인프라의 최적 크기를 결정하고 처리량 요구 사항을 충족하기 위해 Kafka 구성을 미세 조정해야 하는 문제에 직면하게 될 것입니다. 각 브로커의 최대 성능은 메모리, 프로세서, 디스크 속도, 네트워크 대역폭 등과 같은 기본 인프라 구성 요소의 성능에 따라 결정됩니다.

이상적으로는 모든 인프라 요소가 최대 성능을 발휘하도록 브로커 구성을 구성해야 합니다. 그러나 실제 생활에서는 이 설정이 상당히 복잡합니다. 사용자는 하나 또는 두 개의 구성 요소(디스크, 메모리 또는 프로세서)의 사용을 최대화하도록 브로커를 구성할 가능성이 높습니다. 일반적으로 브로커는 가장 느린 구성 요소를 최대한 활용하도록 구성할 때 최대 성능을 발휘합니다. 이렇게 하면 하나의 브로커가 처리할 수 있는 부하에 대한 대략적인 아이디어를 얻을 수 있습니다.

이론적으로 특정 로드를 처리하는 데 필요한 브로커 수를 추정할 수도 있습니다. 그러나 실제로는 다양한 수준에 구성 옵션이 너무 많아서 특정 구성의 잠재적 성능을 평가하는 것이 매우 어렵습니다(불가능하지는 않지만). 즉, 특정 성능을 기반으로 구성을 계획하는 것은 매우 어렵습니다.

Supertubes 사용자의 경우 일반적으로 다음과 같은 접근 방식을 취합니다. 일부 구성(인프라 + 설정)으로 시작한 다음 성능을 측정하고 브로커 설정을 조정하고 프로세스를 다시 반복합니다. 이는 인프라에서 가장 느린 구성 요소가 완전히 활용될 때까지 발생합니다.

이러한 방식으로 우리는 클러스터가 특정 로드를 처리하는 데 필요한 브로커 수에 대한 더 명확한 아이디어를 얻습니다(브로커 수는 탄력성을 보장하기 위한 최소 메시지 복제본 수, 파티션 수와 같은 다른 요소에 따라 달라집니다). 리더 등). 또한 수직 확장이 필요한 인프라 구성 요소에 대한 통찰력을 얻습니다.

이 기사에서는 초기 구성에서 가장 느린 구성 요소를 최대한 활용하고 Kafka 클러스터의 처리량을 측정하기 위해 취하는 단계에 대해 설명합니다. 복원력이 뛰어난 구성에는 실행 중인 브로커가 XNUMX개 이상 필요합니다(min.insync.replicas=3), 세 가지 다른 접근성 영역에 분산되어 있습니다. Kubernetes 인프라를 구성, 확장 및 모니터링하기 위해 우리는 하이브리드 클라우드를 위한 자체 컨테이너 관리 플랫폼을 사용합니다. 관로. 온프레미스(베어메탈, VMware)와 XNUMX가지 유형의 클라우드(Alibaba, AWS, Azure, Google, Oracle)는 물론 이들의 조합을 지원합니다.

Kafka 클러스터 인프라 및 구성에 대한 생각

아래 예에서는 클라우드 공급자로 AWS를 선택하고 Kubernetes 배포판으로 EKS를 선택했습니다. 유사한 구성을 다음을 사용하여 구현할 수 있습니다. PKE - CNCF 인증을 받은 Banzai Cloud의 Kubernetes 배포판입니다.

디스크

아마존은 다양한 EBS 볼륨 유형. 중심에서 gp2 и io1 그러나 높은 처리량을 보장하기 위해 SSD 드라이브가 있습니다. gp2 누적된 크레딧을 소모합니다. (I/O 크레딧), 그래서 우리는 다음 유형을 선호했습니다. io1, 이는 일관되게 높은 처리량을 제공합니다.

인스턴스 유형

Kafka의 성능은 운영 체제의 페이지 캐시에 크게 의존하므로 브로커(JVM) 및 페이지 캐시를 위한 충분한 메모리가 있는 인스턴스가 필요합니다. 사례 c5.2x 큰 - 16GB의 메모리와 XNUMXGB의 메모리를 갖추고 있어 시작이 좋습니다. EBS와 연동되도록 최적화. 단점은 30시간마다 최대 24분 동안만 최대 성능을 제공할 수 있다는 것입니다. 워크로드에 장기간에 걸쳐 최고 성능이 필요한 경우 다른 인스턴스 유형을 고려할 수 있습니다. 그게 바로 우리가 한 일입니다. c5.4x 큰. 최대 처리량을 제공합니다. 593,75MB/초. EBS 볼륨의 최대 처리량 io1 인스턴스보다 높음 c5.4x 큰따라서 인프라에서 가장 느린 요소는 이 인스턴스 유형의 I/O 처리량일 가능성이 높습니다(부하 테스트에서도 확인해야 함).

네트워크

네트워크 처리량은 VM 인스턴스 및 디스크의 성능에 비해 충분히 커야 합니다. 그렇지 않으면 네트워크에 병목 현상이 발생합니다. 우리의 경우 네트워크 인터페이스 c5.4x 큰 VM 인스턴스의 I/O 처리량보다 훨씬 높은 최대 10Gb/s의 속도를 지원합니다.

브로커 배포

CPU, 메모리, 네트워크 및 디스크 리소스에 대한 다른 프로세스와 경쟁하지 않으려면 브로커를 전용 노드에 배포(Kubernetes에서 예약)해야 합니다.

자바 버전

논리적인 선택은 Java 11입니다. 왜냐하면 JVM이 브로커가 실행되는 컨테이너에 사용 가능한 프로세서와 메모리를 올바르게 결정한다는 점에서 Docker와 호환되기 때문입니다. CPU 제한이 중요하다는 것을 알고 JVM은 내부적으로 투명하게 GC 스레드 및 JIT 스레드 수를 설정합니다. Kafka 이미지를 사용했습니다. banzaicloud/kafka:2.13-2.4.0, 여기에는 Java 2.4.0의 Kafka 버전 2.13(Scala 11)이 포함되어 있습니다.

Kubernetes의 Java/JVM에 대해 자세히 알아보려면 다음 게시물을 확인하세요.

• 내 Java 애플리케이션이 OOMKilled되는 이유;
• Java 10 애플리케이션용 컨테이너 크기를 올바르게 조정하는 방법.

브로커 메모리 설정

브로커 메모리 구성에는 JVM 설정과 Kubernetes Pod 설정이라는 두 가지 주요 측면이 있습니다. Pod에 설정된 메모리 제한은 JVM이 자체 메모리에 상주하는 Java 메타스페이스와 Kafka가 적극적으로 사용하는 운영 체제 페이지 캐시를 위한 공간을 확보할 수 있도록 최대 힙 크기보다 커야 합니다. 테스트에서 우리는 매개변수를 사용하여 Kafka 브로커를 출시했습니다. -Xmx4G -Xms2G, 포드의 메모리 한도는 다음과 같습니다. 10 Gi. JVM의 메모리 설정은 다음을 사용하여 자동으로 얻을 수 있습니다. -XX:MaxRAMPercentage и -X:MinRAMPercentage, 포드의 메모리 제한을 기준으로 합니다.

브로커 프로세서 설정

일반적으로 Kafka에서 사용하는 스레드 수를 늘려 병렬성을 높여 성능을 향상시킬 수 있습니다. Kafka에 사용할 수 있는 프로세서가 많을수록 좋습니다. 테스트에서는 6개의 프로세서로 시작하여 점차적으로 (반복을 통해) 그 수를 15개로 늘렸습니다. num.network.threads=12 브로커 설정에서 네트워크로부터 데이터를 받아 전송하는 스레드 수를 늘리는 것입니다. 팔로어 브로커가 복제본을 충분히 빨리 받을 수 없다는 사실을 즉시 발견한 그들은 num.replica.fetchers 팔로워 브로커가 리더의 메시지를 복제하는 속도를 높이려면 4로 설정하세요.

부하 생성 도구

벤치마킹 중인 Kafka 클러스터가 최대 로드에 도달하기 전에 선택한 로드 생성기의 용량이 부족해지지 않도록 해야 합니다. 즉, 로드 생성 도구의 기능에 대한 사전 평가를 수행하고 충분한 수의 프로세서와 메모리를 갖춘 인스턴스 유형을 선택해야 합니다. 이 경우 우리 도구는 Kafka 클러스터가 처리할 수 있는 것보다 더 많은 로드를 생성합니다. 많은 실험 끝에 우리는 XNUMX개의 사본을 결정했습니다. c5.4x 큰, 각각 발전기가 작동 중이었습니다.

벤치마킹

성과 측정은 다음 단계를 포함하는 반복 프로세스입니다.

• 인프라 설정(EKS 클러스터, Kafka 클러스터, 로드 생성 도구, Prometheus 및 Grafana)
• 수집된 성능지표의 무작위 편차를 필터링하기 위해 일정 기간 동안 로드를 생성하는 단계;
• 관찰된 성능 지표를 기반으로 브로커의 인프라 및 구성을 조정합니다.
• 필요한 수준의 Kafka 클러스터 처리량이 달성될 때까지 프로세스를 반복합니다. 동시에 일관되게 재현 가능해야 하며 처리량의 변화가 최소화되어야 합니다.

다음 섹션에서는 테스트 클러스터 벤치마킹 프로세스 중에 수행된 단계를 설명합니다.

도구

기본 구성을 신속하게 배포하고, 로드를 생성하고, 성능을 측정하는 데 다음 도구가 사용되었습니다.

• Banzai 클라우드 파이프라인 Amazon c에서 EKS 클러스터 구성 프로 메테우스 (Kafka 및 인프라 측정항목 수집) 및 그라 파나 (이러한 측정항목을 시각화하기 위해) 우리는 이점을 취했습니다 통합 в 관로 통합 모니터링, 중앙 집중식 로그 수집, 취약성 검색, 재해 복구, 엔터프라이즈급 보안 등을 제공하는 서비스입니다.
• 상그레넬 — Kafka 클러스터의 부하 테스트를 위한 도구입니다.
• Kafka 측정항목 및 인프라를 시각화하기 위한 Grafana 대시보드: 쿠버네티스 카프카, 노드 내보내기.
• Kubernetes에서 Kafka 클러스터를 설정하는 가장 쉬운 방법을 위한 Supertubes CLI. Zookeeper, Kafka 운영자, Envoy 및 기타 여러 구성요소가 설치되어 Kubernetes에서 프로덕션용 Kafka 클러스터를 실행하도록 올바르게 구성됩니다.
  • 설치용 슈퍼튜브 CLI 제공된 지침을 사용하십시오 여기에.

EKS 클러스터

전용 작업자 노드가 있는 EKS 클러스터 준비 c5.4x 큰 Kafka 브로커가 있는 포드의 다양한 가용성 영역과 부하 생성기 및 모니터링 인프라를 위한 전용 노드에 있습니다.

banzai cluster create -f https://raw.githubusercontent.com/banzaicloud/kafka-operator/master/docs/benchmarks/infrastructure/cluster_eks_202001.json

EKS 클러스터가 실행되면 통합을 활성화합니다. 모니터링 서비스 — 그녀는 Prometheus와 Grafana를 클러스터에 배포할 것입니다.

카프카 시스템 구성 요소

supertubes CLI를 사용하여 EKS에 Kafka 시스템 구성 요소(Zookeeper, kafka-operator)를 설치합니다.

supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>

카프카 클러스터

기본적으로 EKS는 다음 유형의 EBS 볼륨을 사용합니다. gp2, 따라서 볼륨을 기반으로 별도의 스토리지 클래스를 생성해야 합니다. io1 Kafka 클러스터의 경우:

kubectl create -f - <<EOF
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: kubernetes.io/aws-ebs
parameters:
  type: io1
  iopsPerGB: "50"
  fsType: ext4
volumeBindingMode: WaitForFirstConsumer
EOF

브로커에 대한 매개변수 설정 min.insync.replicas=3 세 가지 다른 가용성 영역의 노드에 브로커 포드를 배포합니다.

supertubes cluster create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f https://raw.githubusercontent.com/banzaicloud/kafka-operator/master/docs/benchmarks/infrastructure/kafka_202001_3brokers.yaml --wait --timeout 600

주제

세 개의 부하 생성기 인스턴스를 병렬로 실행했습니다. 그들 각각은 자신의 주제에 글을 씁니다. 즉, 총 세 가지 주제가 필요합니다.

supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
  name: perftest1
spec:
  name: perftest1
  partitions: 12
  replicationFactor: 3
  retention.ms: '28800000'
  cleanup.policy: delete
EOF

supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
    name: perftest2
spec:
  name: perftest2
  partitions: 12
  replicationFactor: 3
  retention.ms: '28800000'
  cleanup.policy: delete
EOF

supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
  name: perftest3
spec:
  name: perftest3
  partitions: 12
  replicationFactor: 3
  retention.ms: '28800000'
  cleanup.policy: delete
EOF

각 항목의 복제 인수는 고가용성 프로덕션 시스템에 대한 최소 권장 값인 3입니다.

부하 생성 도구

우리는 로드 생성기의 복사본 XNUMX개를 출시했습니다(각각 별도의 주제에 작성). 부하 생성기 포드의 경우 할당된 노드에서만 예약되도록 노드 선호도를 설정해야 합니다.

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  labels:
    app: loadtest
  name: perf-load1
  namespace: kafka
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: loadtest
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: loadtest
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: nodepool.banzaicloud.io/name
                operator: In
                values:
                - loadgen
      containers:
      - args:
        - -brokers=kafka-0:29092,kafka-1:29092,kafka-2:29092,kafka-3:29092
        - -topic=perftest1
        - -required-acks=all
        - -message-size=512
        - -workers=20
        image: banzaicloud/perfload:0.1.0-blog
        imagePullPolicy: Always
        name: sangrenel
        resources:
          limits:
            cpu: 2
            memory: 1Gi
          requests:
            cpu: 2
            memory: 1Gi
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30

참고할 몇 가지 사항:

• 부하 생성기는 512바이트 길이의 메시지를 생성하여 500개 메시지 일괄 처리로 Kafka에 게시합니다.
• 인수 사용 -required-acks=all 메시지의 동기화된 모든 복제본이 Kafka 브로커에 의해 수신되고 확인되면 게시가 성공한 것으로 간주됩니다. 이는 벤치마크에서 리더가 메시지를 받는 속도뿐만 아니라 팔로워가 메시지를 복제하는 속도도 측정했음을 의미합니다. 이 테스트의 목적은 소비자의 읽기 속도를 평가하는 것이 아닙니다. (소비자) OS 페이지 캐시에 아직 남아 있는 최근 수신 메시지와 디스크에 저장된 메시지 읽기 속도를 비교합니다.
• 부하 생성기는 20개의 작업자를 병렬로 실행합니다(-workers=20). 각 작업자에는 Kafka 클러스터에 대한 작업자 연결을 공유하는 5개의 생산자가 포함되어 있습니다. 결과적으로 각 생성자는 100개의 생성자를 가지며 모두 Kafka 클러스터에 메시지를 보냅니다.

클러스터 상태 모니터링

Kafka 클러스터의 로드 테스트 중에 포드가 다시 시작되지 않고, 동기화되지 않은 복제본이 없고, 변동을 최소화하면서 최대 처리량을 보장하기 위해 상태도 모니터링했습니다.

• 부하 생성기는 게시된 메시지 수와 오류율에 대한 표준 통계를 작성합니다. 오류율은 동일하게 유지되어야 합니다. 0,00%.
• 크루즈 컨트롤kafka-operator가 배포한 는 클러스터 상태도 모니터링할 수 있는 대시보드를 제공합니다. 이 패널을 보려면 다음을 수행하십시오.

  supertubes cluster cruisecontrol show -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file>

• ISR 수준 (“동기화” 복제본 수) 축소 및 확장은 0과 같습니다.

측정 결과

브로커 3개, 메시지 크기 - 512바이트

XNUMX개의 브로커에 파티션이 균등하게 분산되어 성능을 달성할 수 있었습니다. ~500Mb/s(초당 약 990만 개의 메시지):

JVM 가상 머신의 메모리 소비는 2GB를 초과하지 않았습니다.

디스크 처리량이 브로커가 실행 중인 세 인스턴스 모두에서 최대 I/O 노드 처리량에 도달했습니다.

노드별 메모리 사용량 데이터에 따르면 시스템 버퍼링 및 캐싱에 ~10-15GB가 소요되었습니다.

브로커 3개, 메시지 크기 - 100바이트

메시지 크기가 줄어들면 처리량이 약 15-20% 감소합니다. 즉, 각 메시지를 처리하는 데 소요되는 시간이 영향을 미칩니다. 또한 프로세서 로드가 거의 두 배로 늘어났습니다.

브로커 노드에는 아직 사용되지 않은 코어가 있으므로 Kafka 구성을 변경하여 성능을 향상시킬 수 있습니다. 이는 쉬운 작업이 아니므로 처리량을 늘리려면 더 큰 메시지로 작업하는 것이 좋습니다.

브로커 4개, 메시지 크기 - 512바이트

새 브로커를 추가하고 파티션 균형을 유지하면 Kafka 클러스터의 성능을 쉽게 높일 수 있습니다(이를 통해 로드가 브로커 간에 균등하게 분산됩니다). 우리의 경우 브로커를 추가한 후 클러스터 처리량이 다음과 같이 증가했습니다. ~580Mb/s(초당 ~1,1만 메시지). 성장은 예상보다 낮은 것으로 나타났습니다. 이는 주로 파티션의 불균형으로 인해 설명됩니다(모든 브로커가 최고 성능으로 작동하는 것은 아닙니다).

JVM 시스템의 메모리 소비는 2GB 미만으로 유지되었습니다.

드라이브가 있는 브로커의 작업은 파티션 불균형의 영향을 받았습니다.

조사 결과

위에 제시된 반복적 접근 방식은 수백 명의 소비자, 재분할, 롤링 업데이트, 포드 다시 시작 등을 포함하는 보다 복잡한 시나리오를 포괄하도록 확장될 수 있습니다. 이 모든 것을 통해 우리는 다양한 조건에서 Kafka 클러스터 기능의 한계를 평가하고, 작동 중 병목 현상을 식별하고, 이에 대처할 방법을 찾을 수 있습니다.

우리는 클러스터를 빠르고 쉽게 배포하고, 구성하고, 브로커와 주제를 추가/제거하고, 경고에 응답하고, 일반적으로 Kafka가 Kubernetes에서 제대로 작동하도록 Supertubes를 설계했습니다. 우리의 목표는 사용자가 주요 작업(Kafka 메시지 "생성" 및 "소비")에 집중할 수 있도록 돕고 모든 노력은 Supertubes 및 Kafka 운영자에게 맡기는 것입니다.

Banzai Cloud 기술 및 오픈 소스 프로젝트에 관심이 있으시면 다음 회사를 구독하세요. GitHub의, 링크드인 또는 트위터.

번역가의 추신

블로그에서도 읽어보세요.

• «K8s의 Redis 운영자에 대한 이야기와 이 데이터베이스의 데이터를 분석하기 위한 유틸리티에 대한 간략한 검토";
• «RabbitMQ를 Kubernetes로 원활하게 마이그레이션";
• «CoreOS의 zetcd: ZooKeeper를 etcd 스토리지로 교체".

출처 : habr.com