Odredite odgovarajuću veličinu za Kafka klaster u Kubernetesu

Bilješka. transl.: U ovom članku Banzai Cloud dijeli primjer kako se njegovi prilagođeni alati mogu koristiti kako bi Kafka bila lakša za korištenje unutar Kubernetesa. Sljedeće upute ilustruju kako možete odrediti optimalnu veličinu svoje infrastrukture i konfigurirati samu Kafku da postigne potrebnu propusnost.

Apache Kafka je distribuirana platforma za striming za kreiranje pouzdanih, skalabilnih i visokih performansi sistema za striming u realnom vremenu. Njegove impresivne mogućnosti mogu se proširiti pomoću Kubernetesa. Za to smo se razvili Kafka operator otvorenog koda i alat tzv Supertubes. Oni vam omogućavaju da pokrenete Kafku na Kubernetes-u i koristite njegove različite funkcije, kao što je fino podešavanje konfiguracije brokera, metričko skaliranje s ponovnim balansiranjem, svijest o racku, „meko“ (graciozan) uvođenje ažuriranja itd.

Isprobajte Supertubes u svom klasteru:

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

Ili kontaktirajte dokumentaciju. Također možete pročitati o nekim od mogućnosti Kafke, rad s kojima je automatiziran pomoću Supertubes i Kafka operatora. O njima smo već pisali na blogu:

• O ne! Još jedan Kafka operater za Kubernetes;
• Nadgledajte i upravljajte Kafkom na osnovu Prometheus metrike;
• Kafka rack svijesti na Kubernetes;
• Pokretanje Apache Kafke preko Istia - benchmark;
• Korisnički autentificirani i kontrolirani klasteri s Kafka operatorom;
• Kafka nadogradnja i dinamička konfiguracija na Kubernetesu;
• Filter protokola poslanika za Kafku, isprepleten.

Kada odlučite da primenite Kafka klaster na Kubernetesu, verovatno ćete se suočiti sa izazovom određivanja optimalne veličine osnovne infrastrukture i potrebom da fino podesite svoju Kafka konfiguraciju kako bi zadovoljila zahteve propusnosti. Maksimalne performanse svakog brokera određuju se performansama osnovnih infrastrukturnih komponenti, kao što su memorija, procesor, brzina diska, propusni opseg mreže, itd.

U idealnom slučaju, konfiguracija brokera treba da bude takva da se svi infrastrukturni elementi koriste do svojih maksimalnih mogućnosti. Međutim, u stvarnom životu ova postavka je prilično složena. Vjerovatnije je da će korisnici konfigurirati brokere da maksimiziraju korištenje jedne ili dvije komponente (disk, memorija ili procesor). Uopšteno govoreći, broker pokazuje maksimalne performanse kada njegova konfiguracija dozvoljava da se najsporija komponenta koristi u najvećoj mjeri. Na ovaj način možemo dobiti grubu predstavu o opterećenju koje jedan broker može podnijeti.

Teoretski, također možemo procijeniti broj brokera potrebnih za rukovanje datim opterećenjem. Međutim, u praksi postoji toliko mnogo opcija konfiguracije na različitim nivoima da je vrlo teško (ako ne i nemoguće) procijeniti potencijalne performanse određene konfiguracije. Drugim riječima, vrlo je teško planirati konfiguraciju zasnovanu na nekim datim performansama.

Za korisnike Supertubesa obično koristimo sljedeći pristup: počinjemo s nekom konfiguracijom (infrastruktura + postavke), zatim mjerimo njenu izvedbu, prilagođavamo postavke brokera i ponovo ponavljamo proces. To se dešava sve dok se najsporija komponenta infrastrukture u potpunosti ne iskoristi.

Na ovaj način dobijamo jasniju predstavu o tome koliko brokera klaster treba da podnese određeno opterećenje (broj brokera ovisi i o drugim faktorima, kao što je minimalni broj replika poruka da bi se osigurala otpornost, broj particija vođe itd.). Osim toga, dobijamo uvid u to koje infrastrukturne komponente zahtijevaju vertikalno skaliranje.

Ovaj članak će govoriti o koracima koje poduzimamo kako bismo izvukli maksimum iz najsporijih komponenti u početnim konfiguracijama i izmjerili propusnost Kafka klastera. Visoko otporna konfiguracija zahtijeva najmanje tri pokrenuta brokera (min.insync.replicas=3), raspoređenih u tri različite zone pristupačnosti. Da bismo konfigurirali, skalirali i nadgledali Kubernetes infrastrukturu, koristimo vlastitu platformu za upravljanje kontejnerima za hibridne oblake - cjevovod. Podržava on-premise (goli metal, VMware) i pet vrsta oblaka (Alibaba, AWS, Azure, Google, Oracle), kao i bilo koju njihovu kombinaciju.

Razmišljanja o infrastrukturi i konfiguraciji Kafka klastera

Za primjere ispod, odabrali smo AWS kao dobavljača oblaka i EKS kao Kubernetes distribuciju. Slična konfiguracija se može implementirati pomoću P.K.E. - Kubernetes distribucija iz Banzai Cloud-a, certificirana od strane CNCF-a.

disk

Amazon nudi razne EBS tipovi volumena. U srži gp2 и io1 postoje SSD diskovi, međutim, kako bi se osigurala visoka propusnost gp2 troši akumulirane kredite (I/O krediti), pa smo preferirali ovaj tip io1, koji nudi konstantno visoku propusnost.

Tipovi instanci

Kafkine performanse u velikoj meri zavise od keša stranica operativnog sistema, tako da su nam potrebne instance sa dovoljno memorije za brokere (JVM) i keš stranice. Instance c5.2xlarge - dobar početak, jer ima 16 GB memorije i optimiziran za rad sa EBS-om. Nedostatak mu je što je sposoban da pruži maksimalne performanse samo za ne više od 30 minuta svaka 24 sata. Ako vaše radno opterećenje zahtijeva vrhunske performanse tokom dužeg vremenskog perioda, možda biste trebali razmotriti druge tipove instanci. Upravo to smo i uradili, zaustavili smo se c5.4xlarge. Pruža maksimalnu propusnost 593,75 Mb/s. Maksimalni protok EBS volumena io1 viši od instance c5.4xlarge, tako da će najsporiji element infrastrukture vjerovatno biti I/O propusnost ovog tipa instance (što bi naši testovi opterećenja također trebali potvrditi).

Mreža

Mrežna propusnost mora biti dovoljno velika u poređenju sa performansama VM instance i diska, inače mreža postaje usko grlo. U našem slučaju, mrežni interfejs c5.4xlarge podržava brzine do 10 Gb/s, što je znatno veće od I/O propusnosti VM instance.

Broker Deployment

Brokeri bi trebali biti raspoređeni (planirani u Kubernetesu) na namjenskim čvorovima kako bi se izbjeglo nadmetanje s drugim procesima za resurse CPU, memorije, mreže i diska.

Java verzija

Logičan izbor je Java 11 jer je kompatibilan sa Dockerom u smislu da JVM ispravno određuje procesore i memoriju dostupne kontejneru u kojem broker radi. Znajući da su ograničenja CPU-a važna, JVM interno i transparentno postavlja broj GC niti i JIT niti. Koristili smo Kafkinu sliku banzaicloud/kafka:2.13-2.4.0, koji uključuje Kafku verziju 2.4.0 (Scala 2.13) na Javi 11.

Ako želite da saznate više o Javi/JVM na Kubernetesu, pogledajte naše sljedeće postove:

• Zašto je moja Java aplikacija OOMKilled;
• Kako pravilno odrediti veličinu kontejnera za Java 10 aplikacije.

Postavke brokerske memorije

Postoje dva ključna aspekta za konfigurisanje brokerske memorije: postavke za JVM i za Kubernetes pod. Ograničenje memorije postavljeno za pod mora biti veće od maksimalne veličine hrpe tako da JVM ima prostora za Java metaprostor koji se nalazi u sopstvenoj memoriji i za keš stranice operativnog sistema koji Kafka aktivno koristi. U našim testovima smo pokrenuli Kafka brokere sa parametrima -Xmx4G -Xms2G, a ograničenje memorije za pod je bilo 10 Gi. Imajte na umu da se postavke memorije za JVM mogu dobiti automatski koristeći -XX:MaxRAMPercentage и -X:MinRAMPercentage, na osnovu ograničenja memorije za pod.

Postavke procesora brokera

Uopšteno govoreći, možete poboljšati performanse povećanjem paralelizma povećanjem broja niti koje koristi Kafka. Što je više procesora dostupno za Kafku, to bolje. U našem testu smo počeli s ograničenjem od 6 procesora i postepeno (kroz iteracije) povećavali njihov broj na 15. Osim toga, postavili smo num.network.threads=12 u postavkama brokera da povećate broj niti koje primaju podatke s mreže i šalju ih. Odmah otkrivši da brokeri sljedbenika ne mogu dovoljno brzo primiti replike, podigli su num.replica.fetchers do 4 kako bi se povećala brzina kojom su brokeri sljedbenika replicirali poruke od lidera.

Alat za generiranje opterećenja

Trebali biste osigurati da odabrani generator opterećenja ne ostane bez kapaciteta prije nego što Kafka klaster (koji se mjeri) dostigne svoje maksimalno opterećenje. Drugim riječima, potrebno je provesti preliminarnu procjenu mogućnosti alata za generiranje opterećenja, kao i odabrati tipove instance za njega s dovoljnim brojem procesora i memorije. U ovom slučaju, naš alat će proizvesti više opterećenja nego što Kafka klaster može podnijeti. Nakon mnogo eksperimenata, odlučili smo se za tri primjerka c5.4xlarge, od kojih je svaki radio generator.

Benchmarking

Mjerenje učinka je iterativni proces koji uključuje sljedeće faze:

• postavljanje infrastrukture (EKS klaster, Kafka klaster, alat za generisanje opterećenja, kao i Prometej i Grafana);
• generiranje opterećenja za određeni period za filtriranje slučajnih odstupanja u prikupljenim pokazateljima učinka;
• prilagođavanje infrastrukture i konfiguracije brokera na osnovu uočenih pokazatelja učinka;
• ponavljanje procesa dok se ne postigne potreban nivo propusnosti Kafka klastera. U isto vrijeme, mora biti dosljedno reproducibilan i pokazati minimalne varijacije u propusnosti.

Sljedeći odjeljak opisuje korake koji su izvedeni tokom procesa benčmarkinga testnih klastera.

Alati

Korišteni su sljedeći alati za brzo postavljanje osnovne konfiguracije, generiranje opterećenja i mjerenje performansi:

• Banzai Cloud Pipeline za organizovanje EKS klastera iz Amazona c Prometej (za prikupljanje Kafkinih i infrastrukturnih metrika) i grafana (za vizualizaciju ovih metrika). Iskoristili smo prednost integrisan в cjevovod usluge koje pružaju federalni nadzor, centralizovano prikupljanje dnevnika, skeniranje ranjivosti, oporavak od katastrofe, sigurnost na nivou preduzeća i još mnogo toga.
• Sangrenel — alat za testiranje opterećenja Kafka klastera.
• Grafana kontrolne ploče za vizualizaciju Kafkinih metrika i infrastrukture: Kubernetes Kafka, Node Exporter.
• Supertubes CLI za najlakši način za postavljanje Kafka klastera na Kubernetes. Zookeeper, Kafka operater, Envoy i mnoge druge komponente su instalirane i pravilno konfigurirane za pokretanje Kafka klastera spremnog za proizvodnju na Kubernetesu.
  • Za ugradnju supertubes CLI koristite priložena uputstva ovdje.

EKS klaster

Pripremite EKS klaster s namjenskim radničkim čvorovima c5.4xlarge u različitim zonama dostupnosti za podove sa Kafka brokerima, kao i namenskim čvorovima za generator opterećenja i infrastrukturu za praćenje.

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

Kada se EKS klaster pokrene, omogućite njegovu integrisanost usluga praćenja — ona će rasporediti Prometeja i Grafanu u klaster.

Komponente Kafka sistema

Instalirajte komponente Kafka sistema (Zookeeper, kafka-operator) u EKS koristeći supertubes CLI:

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

Kafka klaster

Podrazumevano, EKS koristi EBS volumene tipa gp2, tako da morate kreirati zasebnu klasu skladištenja na osnovu volumena io1 za Kafka klaster:

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

Postavite parametar za brokere min.insync.replicas=3 i rasporedite brokerske podove na čvorove u tri različite zone dostupnosti:

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

Teme

Pokrenuli smo tri instance generatora opterećenja paralelno. Svaki od njih piše na svoju temu, odnosno potrebno nam je ukupno tri teme:

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

Za svaku temu, faktor replikacije je 3—minimalna preporučena vrijednost za visoko dostupne proizvodne sisteme.

Alat za generiranje opterećenja

Pokrenuli smo tri kopije generatora opterećenja (svaki je napisao u posebnoj temi). Za module generatora opterećenja morate postaviti afinitet čvorova tako da budu zakazani samo na čvorovima koji su im dodijeljeni:

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

Treba napomenuti nekoliko tačaka:

• Generator opterećenja generiše poruke dužine 512 bajtova i objavljuje ih Kafki u grupama od 500 poruka.
• Koristeći argument -required-acks=all Objavljivanje se smatra uspješnom kada sve sinhronizirane replike poruke prime i potvrde Kafka brokeri. To znači da smo u benčmarku mjerili ne samo brzinu lidera koji primaju poruke, već i njihove sljedbenike koji repliciraju poruke. Svrha ovog testa nije procijeniti brzinu čitanja potrošača (potrošači) nedavno primljene poruke koje i dalje ostaju u kešu stranice OS-a i njihovo poređenje sa brzinom čitanja poruka pohranjenih na disku.
• Generator opterećenja pokreće 20 radnika paralelno (-workers=20). Svaki radnik sadrži 5 proizvođača koji dijele vezu radnika s Kafka klasterom. Kao rezultat, svaki generator ima 100 proizvođača, i svi oni šalju poruke Kafka klasteru.

Praćenje zdravlja klastera

Tokom testiranja opterećenja Kafka klastera, pratili smo i njegovo zdravlje kako bismo osigurali da nema ponovnih pokretanja modula, nema nesinhroniziranih replika i maksimalne propusnosti uz minimalne fluktuacije:

• Generator opterećenja piše standardne statistike o broju objavljenih poruka i stopi greške. Stopa greške bi trebala ostati ista 0,00%.
• Cruise Control, koji je implementirao kafka-operator, pruža kontrolnu tablu na kojoj takođe možemo pratiti stanje klastera. Za pregled ovog panela uradite sljedeće:

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

• ISR nivo (broj "sinhroniziranih" replika) skupljanje i širenje jednaki su 0.

Rezultati mjerenja

3 brokera, veličina poruke - 512 bajtova

Sa particijama ravnomjerno raspoređenim na tri brokera, uspjeli smo postići performanse ~500 Mb/s (približno 990 hiljada poruka u sekundi):

Potrošnja memorije JVM virtuelne mašine nije prelazila 2 GB:

Propusnost diska je dostigla maksimalnu propusnost I/O čvora na sve tri instance na kojima su brokeri radili:

Iz podataka o korištenju memorije po čvorovima proizilazi da je sistemsko baferovanje i keširanje zauzelo ~10-15 GB:

3 brokera, veličina poruke - 100 bajtova

Kako se veličina poruke smanjuje, propusnost opada za otprilike 15-20%: vrijeme provedeno u obradi svake poruke utiče na nju. Osim toga, opterećenje procesora se gotovo udvostručilo.

Pošto brokerski čvorovi još uvijek imaju neiskorištena jezgra, performanse se mogu poboljšati promjenom Kafka konfiguracije. Ovo nije lak zadatak, pa je za povećanje propusnosti bolje raditi s većim porukama.

4 brokera, veličina poruke - 512 bajtova

Možete jednostavno povećati performanse Kafka klastera jednostavnim dodavanjem novih brokera i održavanjem ravnoteže particija (ovo osigurava da je opterećenje ravnomjerno raspoređeno između brokera). U našem slučaju, nakon dodavanja brokera, propusnost klastera se povećala na ~580 Mb/s (~1,1 milion poruka u sekundi). Pokazalo se da je rast manji od očekivanog: to se uglavnom objašnjava neravnotežom particija (ne rade svi brokeri na vrhuncu svojih mogućnosti).

Potrošnja memorije JVM mašine je ostala ispod 2 GB:

Na rad brokera s diskovima utjecala je neravnoteža particija:

nalazi

Iterativni pristup koji je gore predstavljen može se proširiti tako da pokrije složenije scenarije koji uključuju stotine potrošača, ponovno particioniranje, ažuriranja koja se ponavljaju, ponovno pokretanje modula itd. Sve to nam omogućava da procijenimo granice mogućnosti Kafka klastera u različitim uvjetima, identificiramo uska grla u njegovom radu i pronađemo načine za borbu protiv njih.

Dizajnirali smo Supertubes da brzo i jednostavno implementira klaster, konfigurira ga, dodaje/uklanja brokere i teme, odgovara na upozorenja i osigurava da Kafka općenito ispravno radi na Kubernetesu. Naš cilj je da vam pomognemo da se koncentrišete na glavni zadatak („generisanje“ i „potrošnja“ Kafka poruka), a sav težak posao prepustimo Supertubesu i Kafka operateru.

Ako ste zainteresovani za Banzai Cloud tehnologije i Open Source projekte, pretplatite se na kompaniju na GitHub, LinkedIn ili cvrkut.

PS od prevodioca

Pročitajte i na našem blogu:

• «Jedna priča sa Redis operaterom u K8s i mini-pregled uslužnih programa za analizu podataka iz ove baze podataka»;
• «Besprekorna migracija RabbitMQ-a na Kubernetes»;
• «zetcd iz CoreOS-a: Zamjena ZooKeeper-a sa...etcd memorijom".

izvor: www.habr.com