Määrame sobiva suuruse Kafka klastrile Kuberneteses

Märkus tõlke kohta.: Käesolevas artiklis jagab ettevõte Banzai Cloud näidet oma spetsiaalsete utiliitide kasutamisest, et lihtsustada Kafka haldamist Kuberneteses. Esitatud juhised illustreerivad, kuidas määrata infrastruktuuri optimaalset suurust ja seadistada Kafka, et saavutada vajalik läbilaskevõime.

Apache Kafka on jagatud voogedastuse platvorm usaldusväärsete, skaleeritavate ja kõrge jõudlusega reaalajas voogesitussüsteemide loomiseks. Selle muljetavaldavaid võimalusi saab laiendada Kubernetesega. Selleks oleme arendanud Open Source Kafka operaatori ja tööriista nimega Supertubes. Need võimaldavad käitada Kafka Kuberneteses ja kasutada selle erinevaid funktsioone, nagu brokerei konfiguratsiooni peenhäälestus, mõõtmete põhine skaleerimine koos uuesti tasakaalustamisega, rack awareness (riistvara teadlikkus), "pehme" (graceful) uuenduste rakendamine jne.

Proovige Supertubes oma klastris:

curl https://getsupertubes.sh | sh ja supertubes install -a --no-democluster --kubeconfig

Või pöörduge dokumentatsioon. Samuti saab lugeda mõningatest Kafka funktsioonidest, mille automatiseeritud haldamine toimub Supertubes ja Kafka operaatori kaudu. Oleme juba kirjutanud nendest meie blogis:

• Oh ei! Veel üks Kafka operaator Kuberneteses;
• Kafa jälgimine ja haldamine Prometheuse mõõtmete alusel;
• Kafka rack awareness Kuberneteses;
• Apache Kafka käitamine Istio -- tulemused;
• Kasutaja autentitud ja juurdepääsuga kontrollitud klastrid Kafka operaatori abil;
• Kafka üleminek ja dünaamiline konfiguratsioon Kuberneteses;
• Envoy protokolli filter Kafka jaoks, meshed.

Otsustades kasvatada Kafka klastri Kuberneteses, seisate tõenäoliselt silmitsi probleemiga määrata baas-infrastruktuuri optimaalset suurust ja vajadusega peenhäälestada Kafka konfiguratsiooni, et rahuldada läbilaskevõime nõudeid. Iga brokerei maksimaalne jõudlus sõltub selle aluseks olevate infrastruktuuri komponentide nagu mälu, protsessor, ketta kiirus, võrgu läbilaskevõime jne. jõudlusest.

Ideaalis peaks maakleri konfiguratsioon olema selline, et kõik infrastruktuuri elemendid oleksid oma võimekuse piiril kasutuses. Kuid reaalses elus on selline seadistus üsna keeruline. Tõenäolisem on, et kasutajad seadistavad maaklerite konfiguratsiooni nii, et maksimaalset kasu saadakse ühest või kahest komponendist (ketas, mälu või protsessor). Üldiselt näitab maakler maksimaalset jõudlust, kui tema konfiguratsioon võimaldab kõige aeglasema komponendi täielikku kasutamist. Nii saame ligikaudse ülevaate koormusest, millega üks maakler hakkama saab.

Teoreetiliselt saame me samuti hinnata maaklerite arvu, mis on vajalik antud koormuse töötlemiseks. Kuid praktikas on erinevaid seadistusvõimalusi nii palju, et on keeruline (kui mitte võimatu) hinnata mingi konfiguratsiooni potentsiaalset jõudlust. Teisisõnu, on väga keeruline planeerida konfiguratsiooni, lähtudes mingist antud jõudlusest.

Supertubesi kasutajate jaoks rakendame me tavaliselt järgmist lähenemist: alustame mõnest konfiguratsioonist (infrastruktuur + seadistused), seejärel mõõdame selle jõudlust, kohandame maakleri seadistusi ja kordame protsessi veel kord. Seda teeme seni, kuni kõige aeglasema infrastruktuuri komponendi potentsiaal on täielikult rakendatud.

Selle viisi abil saame selgema arusaama sellest, kui palju maaklereid on klastrile vajalik, et toime tulla määratud koormusega (maaklerite arv sõltub samuti teistest teguritest, nagu sõnumite minimaalne replikate arv vastupidavuse tagamiseks, partition-juhid jne). Lisaks saame ülevaate sellest, millise infrastruktuuri komponendi puhul on soovitav vertikaalne skaleerimine.

Selles artiklis räägime sammudest, mida me astume, et "välja pressida kõik" kõige aeglasematest komponentidest algtaseme konfiguratsioonides ja mõõta Kafka klastrite läbilaskevõimet. Kõrge vastupidavusega konfiguratsioon nõuab vähemalt kolme töötavat maaklerit (min.insync.replicas=3), mis jagatakse kolme erineva kättesaadavuse tsooni. Kubernetes'i infrastruktuuri seadistamiseks, skaleerimiseks ja jälgimiseks kasutame meie enda konteinerihaldusplatvormi hübriidpilvede jaoks — Pipeline. See toetab on-premise (bare metal, VMware) ja viit tüüpi pilvi (Alibaba, AWS, Azure, Google, Oracle), samuti nende igasuguseid kombinatsioone.

Mõtted Kafka infrastruktuuri ja klastrite konfiguratsiooni kohta

Allpool toodud näidetes valisime AWS-i pilveteenuse pakkujaks ja EKS-i Kubernetes'i jaotuseks. Sarnast konfiguratsiooni saab rakendada, kasutades PKE — Banzai Cloud'i Kubernetes'i jaotust, mis on CNCF-i poolt sertifitseeritud.

Kettaruum

Amazon pakub erinevaid EBS-i mahtude tüüpe. Aluseks gp2 ja io1 on SSD-diskid, kuid kõrge läbilaskevõime tagamiseks gp2 kasutab kogutud krediiti I/O krediidi (I/O credits), seega eelistasime tüüpi io1, mis pakub stabiilset kõrget läbilaskevõimet.

Instantside tüübid

Kafka jõudlus sõltub tugevalt operatsioonisüsteemi lehtede vahemälust, seega vajame piisava mäluga instantsse, et toita brokereid (JVM) ja lehtede vahemälu. Instants c5.2xlarge on hea algus, kuna sellel on 16 GB mälu ja on optimeeritud EBS-i jaoks.Selle puuduseks on see, et see suudab tagada maksimaalse jõudluse mitte kauem kui 30 minutit 24 tunni jooksul. Kui koormus nõuab maksimaalset jõudlust pikema aja jooksul, tuleks kaaluda muid instantside tüüpe. Just nii me tegime, valides c5.4xlarge.See tagab maksimaalse läbilaskevõime 593,75 MB/s.Maksimaalne EBS-i mahtu läbilaskevõime io1 on suurem kui instantsil c5.4xlarge., seega tundub, et infrastruktuuri kõige aeglasem element on selle instantsi I/O läbilaskevõime (mida peavad kinnitama ka meie koormustestide tulemused).

Võrk

Võrgu läbilaskevõime peaks olema piisavalt suur võrreldes VM-i ja ketta jõudlusega, vastasel juhul muutub võrk kitsaskohaks. Meie juhul toetab võrgu liides c5.4xlarge. kiirus kuni 10 Gbps, mis on oluliselt suurem kui VM-i instantsi I/O läbilaskevõime.

Brokerite juurutamine

Brokereid peavad kasutama (planeerima Kubernetesis) eraldatud sõlmi, et vältida konkurentsi teiste protsesside eest CPU, mälu, võrgu ja ketta ressursside osas.

Java versioon

Loogiliseks valikuks on Java 11, kuna see on kooskõlas Dockeriga, nii et JVM määrab õigesti protsessorid ja mälu, mis on konteineris, kus broker töötab, saadaval. Teades, et protsessorite piirangud on olulised, määrab JVM sisemiselt ja läbipaistvalt GC ja JIT kompilaatori kiiruste arvu. Kasutasime Kafka pilti banzaicloud/kafka:2.13-2.4.0, mis sisaldab Kafka versiooni 2.4.0 (Scala 2.13) Java 11 peal.

Kui soovite rohkem teada Java/JVM kohta Kubernetesis, vaadake meie järgmisi väljaandeid:

• Miks minu Java rakendus sai OOMKilled;
• Kuidas õigesti mõõta konteinerite suurust Java 10 rakenduste jaoks.

Brokereid mälu seaded

Brokereid mälu seadistamisel on kaks peamist aspekti: seadistused JVM-ile ja Kubernetesi pod'ile. Pod'ile määratud mälu piir peab olema suurem kui maksimaalne heap size, et JVM-il jääks ruumi Java metaruumiks, mis asub enda mälus, ja operatsioonisüsteemi lehe vahemälu jaoks, mida Kafka aktiivselt kasutab. Meie testides käivitasime Kafka brokereid seadistustega -Xmx4G -Xms2G, samas kui pod'i mälu piir oli 10 Gi. Pange tähele, et JVM-i mälu parameetrid saavad automaatselt tuvastada, kasutades -XX:MaxRAMPercentage ja -X:MinRAMPercentage, tuginedes pod'i mälu piiridele.

Brokereid protsessori seaded

Üldiselt on võimalik tõsta jõudlust, suurendades paralleelsust, suurendades Kafka kasutatavate kiiruselade arvu. Mida rohkem protsessoreid on Kafka jaoks saadaval, seda parem. Meie testis alustasime 6 protsessori piiranguga ja tõstsime nende arvu järk-järgult (iteraatsioonide kaudu) kuni 15. Lisaks määrasime num.network.threads=12 brokeri seadetes, et suurendada kiiruselade arvu, mis saavad andmeid võrgust ja saadavad neid. Kohe märkasin, et sekundaarsed brokerid ei suuda repliike piisavalt kiiresti vastu võtta, seetõttu tõstsime num.replica.fetchers kuni 4, et suurendada kiirus, millega sekundaarsed brokerid replitseerivad sõnumeid liidritelt.

Koormuse genereerimise tööriist

Oluline on veenduda, et valitud koormusgeneraatori potentsiaal ei ammenduks enne, kui Kafka klaster (mille jõudlust testitakse) saavutab oma maksimaalse koormuse. Teisisõnu, tuleb eelnevalt hinnata koormusgeneraatori võimalusi ja valida selle jaoks instance'id, millel on piisavalt protsessoreid ja mälu. Sel juhul toodab meie tööriist rohkem koormust, kui Kafka klaster suudab taluda. Pärast mitmeid katseid lõppesime kolme eksemplariga c5.4xlarge., millest igaühes käivitus generaator.

Jõudluse testimine

Jõudluse mõõtmine on iteratiivne protsess, mis hõlmab järgmisi etappe:

• infrastruktuuri (EKS klaster, Kafka klaster, koormusgeneraator ning Prometheus ja Grafana) seadistamine;
• koormuse genereerimine kindla ajaperioodi jooksul, et filtreerida välja juhuslikud kõikumised kogutud jõudlusnäitajates;
• infrastruktuuri ja brokendi seadistuste kohandamine jälgitud jõudlusnäitajate põhjal;
• protsessi kordamine, kuni on saavutatud soovitud jõudluse tase Kafka klastris. Samuti peab see olema stabiilselt korduv ja näitama minimaalset jõudluse kõikumist.

Järgmises osas on kirjeldatud samme, mida tehti testklastri jõudluse testimise protsessis.

Tööriistad

Kiireks baasconfiguratsiooni seadistamiseks, koormuse genereerimiseks ja jõudluse mõõtmiseks kasutati järgmisi tööriistu:

• Banzai Cloud Pipeline Amazon EKS klastrite organiseerimiseks koos Prometheus (Kafka ja infrastruktuuri mõõdikute kogumiseks) ja Grafana (nende mõõdikute visualiseerimiseks). Kasutasime integreeritud ja Pipeline teenuseid, mis pakuvad föderaalset jälgimist, keskset logide kogumist, haavatavuste skannimist, taastumist tõrgetest, ettevõtte taseme turvalisust ja palju muud.
• Sangrenel on tööriist Kafka klastri koormustestimiseks.
• Grafana paneelid Kafka ja infrastruktuuri mõõdikute visualiseerimiseks: Kubernetes Kafka, Node Exporter.
• Supertubes CLI maksimaalse lihtsuse saavutamiseks Kafka klastrite seadistamisel Kuberneteses. Zookeeper, Kafka operaator, Envoy ja mitmed teised komponendid on installitud ja korrektselt konfigureeritud produktsiooniks valmis Kafka klastriks Kuberneteses.
  • Paigaldamiseks supertubes CLI kasutage antud juhiseid siin.

EKS klaster

Valmistage ette EKS klaster eraldatud töötlustöötlusülesannetega c5.4xlarge. erinevates saadavuspiirkondades Kafka vahendajatega pod'ide jaoks, samuti eraldatud sõlmed koormuse genereerimiseks ja jälgimistarkvara jaoks.

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

Kui EKS klaster töötab, aktiviseerige selle integreeritud jälgimisteenus — see paigutab Prometheuse ja Grafana klastrisse.

Kafka süsteemikomponendid

Paigaldage Kafka süsteemikomponendid (Zookeeper, kafka-operaator) EKS-i supertubes CLI abil:

supertubes install -a --no-democluster --kubeconfig

Kafka klaster

EKS-is kasutatakse vaikimisi EBS tüüpi mahuteid, gp2seega tuleb luua eraldi salvestusklass mahutite jaoks io1 Kafka klastrile:

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

Määrake vahendajatele parameeter min.insync.replicas=3 ja paigutage vahendajate pod'id kolmesse erinevasse saadavuspiirkonda:

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

Teemad

Käivitame samaaegselt kolm koormuse genereerimise eksemplari. Igaüks kirjutab oma teemasse, st kokku on meil vaja kolme teemat:

supertubes cluster topic create -n kafka --kubeconfig  -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  -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  -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

Iga teema replikatsioonifaktor on 3 — minimaalne soovitatud väärtus kõrge kättesaadavusega produktsioonisüsteemide jaoks.

Koormuse genereerimise tööriist

Me käivitasime kolm koormuse genereerimise eksemplari (igaüks saatis eraldi teema). Koormuse generaatori pod’ide jaoks on vajalik määrata node affinity, et need planeeritaks ainult neile määratud sõlmedele:

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

Mõned punktid, millele tasub tähelepanu pöörata:

• Koormuse generaator genereerib 512 baitiseid sõnumeid ja avaldab need Kafka-s 500 sõnumi kaupa.
• Argumentidega -required-acks=all loetakse avaldamine edukaks, kui kõik sünkroonitud sõnumi koopiad on saadud ja kinnitatud Kafka brokerite poolt. See tähendab, et mõõdsime testis mitte ainult liidrite kiirus, kellel on sõnumid, vaid ka nende järglaste kiirus, kes kopeerivad sõnumeid. Kõnealuse testi eesmärk ei ole tarbijate (consumers) ärakäidud sõnumite lugemise kiirus, mis on praegu OS-i lehe vahemikus, ja selle võrdlemine sõnumite lugemise kiirusest, mis on salvestatud kettale.
• Koormuse generaator käivitab samal ajal 20 worker’it (-workers=20). Iga worker sisaldab 5 produtsenti, kes jagavad ühiselt worker’i ühendust Kafka klastri. Tulemusena on iga generaatoril kokku 100 produtsenti, kes kõik saadavad sõnumeid Kafka klastrisse.

Klastri oleku jälgimine

Kafka klastrite koormustestimise ajal jälgisime ka selle terviseseisundit, et veenduda pod’ide taaskäivitamiste, sünkroonimata koopiate ja maksimaalse läbilaskevõime minimali kõikumiste puudumises:

• Koormuse generaator salvestab standardseid statistikaid avaldatud sõnumite arvu ja vigade taseme kohta. Vigade protsent peab jääma 0,00%.
• Cruise Control, mille on seadistanud kafka-operator, pakub jälgimisplaati, kus saame samuti jälgida klastrite seisundit. Selle plaadi vaatamiseks teostage:

  supertubes cluster cruisecontrol show -n kafka --kubeconfig

• ISR tase (sünkroonitud koopiate arv) shrink ja expansion on null.

Mõõtmistulemused

3 brokereid, sõnumite suurus - 512 baiti

Partition’ed, ühtlaselt jaotatult kolme brokori vahel, õnnestus meil saavutada jõudlus ~500 Mb/s (umbes 990 tuhat sõnumit sekundis):

JVM virtuaalmasina mälu tarbimine ei ületanud 2 Gb:

Kettaläbilaskevõime saavutas kõigil kolmel instantsil brokerite töötamisel maksimumi I/O kaudu:

Node’de mälu kasutuse andmete põhjal vajusid süsteemi puhverdamine ja vahemälu umbes 10-15 Gb:

3 brokereid, sõnumite suurus - 100 baiti

Sõnumite suuruse vähenemisega kukub läbilaskevõime umbes 15-20%: see mõjutab aega, mis kulub iga sõnumi töötlemiseks. Lisaks kasvas protsessori koormus peaaegu kahekordseks.

Kuna brokeri sõlmedes on endiselt kasutamata tuumikud, saab Kafka konfiguratsiooni muutmisega jõudlust parandada. See ei ole lihtne ülesanne, seetõttu on parem saavutada suuremat läbilaskevõimet suuremate sõnumitega.

4 brokereid, sõnumite suurus - 512 baiti

Kafka klastrite jõudluse suurendamine on lihtne, kui lihtsalt lisada uusi brokereid ja hoida partition'ide tasakaalu (see tagab koormuse ühtlasema jaotuse brokerite vahel). Meie puhul tõusis klastrite läbilaskevõime pärast brokori lisamist ~580 Mb/s (~1,1 miljon sõnumit sekundis). Tõus osutus väiksemaks, kui oodati: seda seletab peamiselt partition’ide tasakaalutuse olemasolu (kõik brokertid ei tööta oma maksimumvõimsusel).

JVM-i mälutarbimine jäi alla 2 GB:

Brokereid, kellel on klienditeenindajad, mõjutas partition'ide tasakaaluhäired:

Järeldused

Ülaltoodud iteratiivset lähenemist saab laiendada, et hõlmata keerulisemaid stsenaariume, mis sisaldavad sadu tarbijaid, repartitioningut, uuendusi ja podide taaskäivitamist jne. See võimaldab meil hinnata Kafka klastri võimekuse piire erinevates tingimustes, tuvastada kitsaskohti ja leida lahendusi nende ületamiseks.

Oleme välja töötanud Supertubes kiireks ja lihtsaks klastri juurutamiseks, konfigureerimiseks, brokerite ja teemade lisamiseks/eemaldamiseks, teavitustele reageerimiseks ning Kafka nõuetekohase töö tagamiseks Kuberneteses üldiselt. Meie eesmärk on aidata keskenduda põhitegevusele („toota” ja „tarbida” Kafka sõnumeid), samas kui kõik rasketööd teeme Supertubes ja Kafka operaatori kaudu.

Kui olete huvitatud tehnoloogiatest ja Banzai Cloudi avatud lähtekoodiga projektidest, siis jälgige meid GitHub, LinkedIn või Twitteris.

P.S. tõlkijalt

Lugege ka meie blogist:

• «Üks lugu Redis'i operaatorist K8s-is ja miniülevaade selle andmebaasi analüüsi tööriistadest»;
• «Kompleksne RabbitMQ migratsioon Kubernetesesse»;
• «zetcd CoreOS'ilt: ZooKeeper asendamine... etcd salvestusega».

Allikas: habr.com