Determinante la taŭgan grandecon por Kafka areto en Kubernetes

Notu. transl.: En ĉi tiu artikolo, Banzai Cloud dividas ekzemplon pri kiel ĝiaj kutimaj iloj povas esti uzataj por faciligi la uzadon de Kafka ene de Kubernetes. La sekvaj instrukcioj ilustras kiel vi povas determini la optimuman grandecon de via infrastrukturo kaj agordi Kafka mem por atingi la bezonatan trairon.

Apache Kafka estas distribuita fluanta platformo por krei fidindajn, skaleblajn kaj alt-efikecajn realtempajn fluajn sistemojn. Ĝiaj impresaj kapabloj povas esti etenditaj per Kubernetes. Por tio ni evoluis Open Source Kafka-funkciigisto kaj ilo vokis Supertuboj. Ili permesas vin ruli Kafka sur Kubernetes kaj uzi ĝiajn diversajn funkciojn, kiel fajnagordi la makleristan agordon, metrik-bazitan skaladon kun rebalancado, rako-konscio, "mola" (gracia) disvolvado de ĝisdatigoj ktp.

Provu Supertubojn en via areto:

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

Aŭ kontaktu dokumentado. Vi ankaŭ povas legi pri iuj el la kapabloj de Kafka, kies laboro estas aŭtomatigita uzante Supertubes kaj Kafka-funkciigiston. Ni jam skribis pri ili en la blogo:

• Ho ne! Ankoraŭ alia Kafka-funkciigisto por Kubernetes;
• Monitoru kaj funkciigu Kafka surbaze de Prometheus-metrikoj;
• Kafka rako-konscio sur Kubernetes;
• Kurante Apache Kafka super Istio - komparnormo;
• Uzanto aŭtentikigitaj kaj alirkontrolitaj aretoj kun la Kafka-funkciigisto;
• Kafka ruliĝanta ĝisdatigo kaj dinamika agordo ĉe Kubernetes;
• Envoy-protokolo-filtrilo por Kafka, maŝita.

Kiam vi decidas disfaldi Kafka-grupon sur Kubernetes, vi verŝajne alfrontos la defion determini la optimuman grandecon de la subesta infrastrukturo kaj la bezonon agordi vian Kafkan-agordon por plenumi la traigajn postulojn. La maksimuma rendimento de ĉiu makleristo estas determinita de la agado de la subaj infrastrukturaj komponantoj, kiel memoro, procesoro, disko-rapideco, reta bendolarĝo ktp.

Ideale, la maklerista agordo devus esti tia, ke ĉiuj infrastrukturaj elementoj estas uzataj al siaj maksimumaj kapabloj. Tamen, en la reala vivo ĉi tiu aranĝo estas sufiĉe kompleksa. Estas pli verŝajne, ke uzantoj agordos makleristojn por maksimumigi la uzon de unu aŭ du komponantoj (disko, memoro aŭ procesoro). Ĝenerale parolante, makleristo montras maksimuman rendimenton kiam ĝia agordo permesas la plej malrapidan komponanton esti uzata en sia plej plena mezuro. Tiel ni povas akiri malglatan ideon pri la ŝarĝo, kiun unu makleristo povas manipuli.

Teorie, ni ankaŭ povas taksi la nombron da makleristoj necesaj por trakti donitan ŝarĝon. Tamen, praktike ekzistas tiom da agordaj elektoj je malsamaj niveloj, ke estas tre malfacile (se ne neeble) taksi la eblan rendimenton de aparta agordo. Alivorte, estas tre malfacile plani agordon bazitan sur iu donita agado.

Por uzantoj de Supertubes, ni kutime prenas la sekvan aliron: ni komencas per iu agordo (infrastrukturo + agordoj), poste mezuras ĝian rendimenton, ĝustigu la makleristajn agordojn kaj ripetas la procezon denove. Ĉi tio okazas ĝis la plej malrapida komponento de la infrastrukturo estas plene utiligita.

Tiamaniere ni ricevas pli klaran ideon pri kiom da makleristoj bezonas areto por trakti certan ŝarĝon (la nombro da makleristoj ankaŭ dependas de aliaj faktoroj, kiel la minimuma nombro da mesaĝokopioj por certigi fortikecon, la nombro da sekcio. gvidantoj, ktp.). Krome, ni akiras sciojn pri kiuj infrastrukturaj komponantoj postulas vertikalan skalon.

Ĉi tiu artikolo parolos pri la paŝoj, kiujn ni faras por profiti la plej malrapidajn komponantojn en komencaj agordoj kaj mezuri la trairon de Kafka-areto. Tre rezistema agordo postulas almenaŭ tri kurantajn makleristojn (min.insync.replicas=3), distribuita trans tri malsamaj alireblaj zonoj. Por agordi, skali kaj monitori la Kubernetes-infrastrukturon, ni uzas nian propran ujadministradplatformon por hibridaj nuboj - Pipeline. Ĝi subtenas surloke (nuda metalo, VMware) kaj kvin specojn de nuboj (Alibaba, AWS, Azure, Google, Oracle), same kiel ajnan kombinaĵon de ili.

Pensoj pri Kafka-clusterinfrastrukturo kaj agordo

Por la ekzemploj sube, ni elektis AWS kiel la nuba provizanto kaj EKS kiel la Kubernetes-distribuo. Simila agordo povas esti efektivigita uzante P.K.E. - Kubernetes-distribuo de Banzai Cloud, atestita de CNCF.

disko

Amazon ofertas diversajn EBS-volumotipoj. Ĉe la kerno gp2 и io1 ekzistas SSD-diskoj, tamen, por certigi altan trairon gp2 konsumas amasigitajn kreditojn (I/O-kreditoj), do ni preferis la tipon io1, kiu ofertas konsekvencan altan trairon.

Specoj de petskriboj

La agado de Kafka tre dependas de la paĝa kaŝmemoro de la operaciumo, do ni bezonas okazojn kun sufiĉa memoro por la makleristoj (JVM) kaj paĝa kaŝmemoro. Kazo c5.2xgranda - bona komenco, ĉar ĝi havas 16 GB da memoro kaj optimumigita por labori kun EBS. Ĝia malavantaĝo estas, ke ĝi nur kapablas provizi maksimuman rendimenton dum ne pli ol 30 minutoj ĉiujn 24 horojn. Se via laborkvanto postulas maksimuman rendimenton dum pli longa tempodaŭro, vi eble volas konsideri aliajn ekzemplertipojn. Ĝuste tion ni faris, ĉesante c5.4xgranda. Ĝi disponigas maksimuman trairon en 593,75 Mb/s. Maksimuma trairo de EBS-volumeno io1 pli alta ol la petskribo c5.4xgranda, do la plej malrapida elemento de la infrastrukturo verŝajne estos la I/O-trafluo de ĉi tiu kazo (kiun niaj ŝarĝtestoj ankaŭ devus konfirmi).

Reto

La reta trafluo devas esti sufiĉe granda kompare kun la agado de la VM-instanco kaj disko, alie la reto fariĝas botelkolo. En nia kazo, la reto-interfaco c5.4xgranda subtenas rapidojn de ĝis 10 Gb/s, kio estas signife pli alta ol la I/O-trairo de VM-instanco.

Broker Deplojo

Makleristoj devus esti deplojitaj (planitaj en Kubernetes) al diligentaj nodoj por eviti konkuri kun aliaj procezoj pri CPU, memoro, reto kaj diskresursoj.

Java versio

La logika elekto estas Java 11 ĉar ĝi estas kongrua kun Docker en la senco, ke la JVM ĝuste determinas la procesorojn kaj memoron disponeblajn al la ujo en kiu la makleristo funkcias. Sciante, ke CPU-limoj estas gravaj, la JVM interne kaj travideble fiksas la nombron da GC-fadenoj kaj JIT-fadenoj. Ni uzis la bildon de Kafka banzaicloud/kafka:2.13-2.4.0, kiu inkluzivas Kafka version 2.4.0 (Scala 2.13) sur Java 11.

Se vi ŝatus lerni pli pri Java/JVM ĉe Kubernetes, rigardu niajn sekvajn afiŝojn:

• Kial mia Java aplikaĵo estas OOMKilled;
• Kiel ĝuste grandeco ujojn por Java 10-aplikoj.

Makleristo-memoraj agordoj

Estas du ŝlosilaj aspektoj por agordi brokermemoron: agordojn por la JVM kaj por la Kubernetes-podo. La memorlimo fiksita por pod devas esti pli granda ol la maksimuma amasograndeco tiel ke la JVM havas lokon por la Java metaspaco, kiu loĝas en sia propra memoro, kaj por la operaciuma paĝa kaŝmemoro, kiun Kafka aktive uzas. En niaj provoj ni lanĉis Kafka makleristojn kun parametroj -Xmx4G -Xms2G, kaj la memorlimo por la balgo estis 10 Gi. Bonvolu noti, ke memoraj agordoj por la JVM povas esti akiritaj aŭtomate uzante -XX:MaxRAMPercentage и -X:MinRAMPercentage, surbaze de la memorlimo por la balgo.

Makleristo procesoro agordoj

Ĝenerale, vi povas plibonigi rendimenton pliigante paralelecon pliigante la nombron da fadenoj uzataj de Kafka. Ju pli da procesoroj disponeblaj por Kafka, des pli bone. En nia testo, ni komencis kun limo de 6 procesoroj kaj iom post iom (per ripetoj) altigis ilian nombron al 15. Krome, ni starigis num.network.threads=12 en la makleristo-agordoj por pliigi la nombron da fadenoj, kiuj ricevas datumojn de la reto kaj sendas ĝin. Tuj malkovrante, ke la sekvaj makleristoj ne povis ricevi kopiojn sufiĉe rapide, ili levis num.replica.fetchers al 4 por pliigi la rapidecon, per kiu sekvaj makleristoj reproduktis mesaĝojn de gvidantoj.

Ŝarĝi Generacio Ilo

Vi devas certigi, ke la elektita ŝarĝgeneratoro ne elĉerpiĝas antaŭ ol la Kafka-areto (kiu estas komparmarkita) atingas sian maksimuman ŝarĝon. Alivorte, necesas fari preparan takson de la kapabloj de la ŝarĝa genera ilo, kaj ankaŭ elekti ekzemplertipojn por ĝi kun sufiĉa nombro da procesoroj kaj memoro. En ĉi tiu kazo, nia ilo produktos pli da ŝarĝo ol la Kafka-grupo povas manipuli. Post multaj eksperimentoj, ni decidis por tri ekzempleroj c5.4xgranda, ĉiu el kiuj havis generatoron funkcianta.

Benchmarking

Efikecmezurado estas ripeta procezo kiu inkluzivas la sekvajn stadiojn:

• starigado de infrastrukturo (EKS-areto, Kafka-areto, ŝarĝogenera ilo, same kiel Prometeo kaj Grafana);
• generi ŝarĝon por certa periodo por filtri hazardajn deviojn en la kolektitaj agado-indikiloj;
• ĝustigi la infrastrukturon kaj agordon de la makleristo surbaze de observitaj rezultaj indikiloj;
• ripetante la procezon ĝis la bezonata nivelo de Kafka-clustertrairo estas atingita. En la sama tempo, ĝi devas esti konstante reproduktebla kaj montri minimumajn variojn en trairo.

La sekva sekcio priskribas la paŝojn kiuj estis faritaj dum la testa cluster benchmarking procezo.

Iloj

La sekvaj iloj estis uzataj por rapide deploji bazlinian agordon, generi ŝarĝojn kaj mezuri rendimenton:

• Banzai Nuba Dukto por organizado de EKS-areto de Amazon ĉ Prometeo (kolekti Kafkan kaj infrastrukturan metrikon) kaj grafana (por bildigi ĉi tiujn metrikojn). Ni profitis integrita в Pipeline servoj kiuj provizas federacian monitoradon, centralizitan protokolan kolekton, vundeblecon skanadon, katastrofan reakiron, entreprenan sekurecon kaj multe pli.
• Sangrenel — ilo por ŝarĝtestado de Kafka-grupo.
• Grafana paneloj por bildigi Kafka-metrikon kaj infrastrukturon: Kubernetes Kafka, Nodo-Eksportilo.
• Supertubes CLI por la plej facila maniero starigi Kafka-grupon sur Kubernetes. Zookeeper, Kafka-funkciigisto, Envoy kaj multaj aliaj komponentoj estas instalitaj kaj konvene agorditaj por ruli produktadpretan Kafka-grupon sur Kubernetes.
  • Instali supertuboj CLI uzu la instrukciojn provizitajn tie.

EKS-grupo

Preparu EKS-grupon kun dediĉitaj labornodoj c5.4xgranda en malsamaj haveblecaj zonoj por podoj kun Kafka makleristoj, same kiel dediĉitaj nodoj por la ŝarĝgeneratoro kaj monitora infrastrukturo.

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

Post kiam la EKS-areo funkcias, ebligu ĝian integran servo de monitorado — ŝi deplojos Prometeon kaj Grafanan en areton.

Kafka-sistemaj komponantoj

Instalu Kafka-sistemajn komponantojn (Zookeeper, kafka-operatoro) en EKS per supertuboj CLI:

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

Kafka areto

Defaŭlte, EKS uzas EBS-volumojn de tipo gp2, do vi devas krei apartan stokan klason bazitan sur volumoj io1 por Kafka areto:

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

Agordu la parametron por makleristoj min.insync.replicas=3 kaj deploji makleristpodojn sur nodoj en tri malsamaj havebleczonoj:

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

Temoj

Ni kuris tri ŝarĝgeneratorokazojn paralele. Ĉiu el ili skribas al sia temo, tio estas, ni bezonas tri temojn entute:

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

Por ĉiu temo, la reproduktadfaktoro estas 3—la minimuma rekomendita valoro por tre haveblaj produktadsistemoj.

Ŝarĝi Generacio Ilo

Ni lanĉis tri kopiojn de la ŝarĝgeneratoro (ĉiu skribis en aparta temo). Por ŝarĝaj generatoraj podoj, vi devas agordi nodan afinecon tiel ke ili estu planitaj nur sur la nodoj asignitaj por ili:

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

Kelkaj punktoj por noti:

• La ŝarĝgeneratoro generas mesaĝojn de 512 bajtoj en longo kaj publikigas ilin al Kafka en aroj de 500 mesaĝoj.
• Uzante argumenton -required-acks=all La publikigo estas konsiderata sukcesa kiam ĉiuj sinkronigitaj kopioj de la mesaĝo estas ricevitaj kaj konfirmitaj de Kafka makleristoj. Ĉi tio signifas, ke en la komparnormo ni mezuris ne nur la rapidecon de gvidantoj ricevantaj mesaĝojn, sed ankaŭ iliaj sekvantoj reproduktantaj mesaĝojn. La celo de ĉi tiu testo ne estas taksi konsumantlegan rapidon (konsumantoj) ĵus ricevis mesaĝojn, kiuj ankoraŭ restas en la paĝa kaŝmemoro de OS, kaj ĝia komparo kun la legado de mesaĝoj konservitaj sur disko.
• La ŝarĝgeneratoro kuras 20 laboristojn paralele (-workers=20). Ĉiu laboristo enhavas 5 produktantojn kiuj dividas la ligon de la laboristo al la Kafka areto. Kiel rezulto, ĉiu generatoro havas 100 produktantojn, kaj ili ĉiuj sendas mesaĝojn al la Kafka areto.

Monitorante la sanon de la areto

Dum ŝarĝtestado de la Kafka-areto, ni ankaŭ monitoris ĝian sanon por certigi, ke ne ekzistas pod-rekomencoj, neniuj ne-sinkronigitaj kopioj kaj maksimuma trairo kun minimumaj fluktuoj:

• La ŝarĝgeneratoro skribas normajn statistikojn pri la nombro da mesaĝoj publikigitaj kaj la eraroprocento. La eraroprocento devus resti la sama 0,00%.
• Rapideco de Rapideco, deplojita de kafka-operatoro, disponigas panelon kie ni ankaŭ povas monitori la staton de la areto. Por vidi ĉi tiun panelon faru:

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

• ISR-nivelo (nombro da "sinkronigitaj" kopioj) ŝrumpado kaj vastiĝo estas egalaj al 0.

Rezultoj de mezurado

3 makleristoj, mesaĝo grandeco - 512 bajtoj

Kun sekcioj egale distribuitaj tra tri makleristoj, ni povis atingi rendimenton ~500 Mb/s (ĉirkaŭ 990 mil mesaĝoj je sekundo):

La memorkonsumo de la JVM virtuala maŝino ne superis 2 GB:

Diska trairo atingis la maksimuman I/O-nodan trairon en ĉiuj tri okazoj, sur kiuj la makleristoj funkciis:

El la datumoj pri memoruzo de nodoj, sekvas, ke sistema bufro kaj kaŝmemoro prenis ~10-15 GB:

3 makleristoj, mesaĝo grandeco - 100 bajtoj

Ĉar la mesaĝgrandeco malpliiĝas, trafluo malpliiĝas je proksimume 15-20%: la tempo pasigita por prilabori ĉiun mesaĝon influas ĝin. Krome, la procesoro-ŝarĝo preskaŭ duobliĝis.

Ĉar makleristaj nodoj ankoraŭ havas neuzatajn kernojn, rendimento povas esti plibonigita ŝanĝante la agordon de Kafka. Ĉi tio ne estas facila tasko, do por pliigi trafluon, estas pli bone labori kun pli grandaj mesaĝoj.

4 makleristoj, mesaĝo grandeco - 512 bajtoj

Vi povas facile pliigi la agadon de Kafka-grupo simple aldonante novajn makleristojn kaj konservante ekvilibron de sekcioj (ĉi tio certigas, ke la ŝarĝo estas egale distribuita inter makleristoj). En nia kazo, post aldonado de makleristo, la amasa traigo pliiĝis al ~580 Mb/s (~1,1 milionoj da mesaĝoj je sekundo). La kresko montriĝis malpli ol atendita: ĉi tio estas ĉefe klarigita per la malekvilibro de sekcioj (ne ĉiuj makleristoj laboras ĉe la pinto de siaj kapabloj).

Memorkonsumo de la JVM-maŝino restis sub 2 Gb:

La laboro de makleristoj kun diskoj estis tuŝita de la malekvilibro de sekcioj:

trovoj

La ripeta aliro prezentita supre povas esti vastigita por kovri pli kompleksajn scenarojn implikantajn centojn da konsumantoj, redistribuadon, ruliĝantajn ĝisdatigojn, pod-rekomencojn, ktp. Ĉio ĉi permesas al ni taksi la limojn de la kapabloj de la Kafka-grupo en diversaj kondiĉoj, identigi botelojn en ĝia funkciado kaj trovi manierojn kontraŭbatali ilin.

Ni desegnis Supertubojn por rapide kaj facile deploji areton, agordi ĝin, aldoni/forigi makleristojn kaj temojn, respondi al atentigoj kaj certigi, ke Kafka ĝenerale funkcias ĝuste en Kubernetes. Nia celo estas helpi vin koncentriĝi pri la ĉefa tasko ("generi" kaj "konsumi" Kafka mesaĝojn), kaj lasi la tutan malfacilan laboron al Supertubes kaj la Kafka-funkciigisto.

Se vi interesiĝas pri Banzai Cloud-teknologioj kaj Open Source-projektoj, abonu la kompanion ĉe GitHub, LinkedIn aŭ Twitter.

PS de tradukisto

Legu ankaŭ en nia blogo:

• «Unu rakonto kun la Redis-funkciigisto en K8s kaj mini-revizio de utilecoj por analizi datumojn de ĉi tiu datumbazo»;
• «Senjunta migrado de RabbitMQ al Kubernetes»;
• «zetcd de CoreOS: Anstataŭigante ZooKeeper per... ktp".

fonto: www.habr.com