Noat. transl.: Yn dit artikel dielt Banzai Cloud in foarbyld fan hoe't har oanpaste ark kinne wurde brûkt om Kafka makliker te brûken binnen Kubernetes. De folgjende ynstruksjes yllustrearje hoe't jo de optimale grutte fan jo ynfrastruktuer kinne bepale en Kafka sels konfigurearje om de fereaske trochslach te berikken.
Apache Kafka is in ferspraat streamingplatfoarm foar it meitsjen fan betroubere, skalberbere en hege prestaasjes real-time streamingsystemen. Syn yndrukwekkende mooglikheden kinne wurde útwreide mei Kubernetes. Foar dit hawwe wy ûntwikkele en in ark neamd . Se kinne jo Kafka op Kubernetes útfiere en har ferskate funksjes brûke, lykas it fine-tunen fan 'e brokerkonfiguraasje, metrysk-basearre skaalfergrutting mei rebalânsjen, rackbewustwêzen, "sêft" (grasjeus) updates útrolje, ensfh.
Besykje Supertubes yn jo kluster:
curl https://getsupertubes.sh | sh и supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>Of kontakt . Jo kinne ek lêze oer guon fan 'e mooglikheden fan Kafka, it wurk mei dat wurdt automatisearre mei help fan Supertubes en Kafka operator. Wy hawwe al oer har skreaun op it blog:
- ;
- ;
- ;
- ;
- ;
- ;
- .
As jo beslute om in Kafka-kluster op Kubernetes yn te setten, sille jo wierskynlik te krijen hawwe mei de útdaging om de optimale grutte fan 'e ûnderlizzende ynfrastruktuer te bepalen en de needsaak om jo Kafka-konfiguraasje te fine om te foldwaan oan trochputeasken. De maksimale prestaasjes fan elke broker wurdt bepaald troch de prestaasjes fan 'e ûnderlizzende ynfrastruktuerkomponinten, lykas ûnthâld, prosessor, skiifsnelheid, netwurkbânbreedte, ensfh.
Ideaallik soe de brokerkonfiguraasje sa wêze moatte dat alle ynfrastruktuer-eleminten wurde brûkt foar har maksimale mooglikheden. Yn it echte libben is dizze opset lykwols frij kompleks. It is wierskynliker dat brûkers makelders sille konfigurearje om it gebrûk fan ien of twa komponinten (skiif, ûnthâld of prosessor) te maksimalisearjen. Yn 't algemien toant in makelder maksimale prestaasjes as syn konfiguraasje it stadichste komponint mooglik makket om syn folsleine omfang te brûken. Op dizze manier kinne wy in rûch idee krije fan 'e lading dy't ien makelder kin omgean.
Teoretysk kinne wy ek skatte it oantal makelders nedich om in opjûne lading te behanneljen. Yn 'e praktyk binne d'r lykwols safolle konfiguraasjeopsjes op ferskate nivo's dat it heul lestich (as net ûnmooglik) is om de potensjele prestaasjes fan in bepaalde konfiguraasje te evaluearjen. Mei oare wurden, it is heul lestich om in konfiguraasje te planjen basearre op guon opjûne prestaasjes.
Foar Supertubes-brûkers nimme wy meastentiids de folgjende oanpak: wy begjinne mei wat konfiguraasje (ynfrastruktuer + ynstellings), mjit dan har prestaasjes, oanpasse de brokerynstellingen en werhelje it proses nochris. Dit bart oant de stadichste komponint fan 'e ynfrastruktuer folslein brûkt wurdt.
Op dizze manier krije wy in dúdliker idee fan hoefolle makelders in kluster nedich is om in bepaalde lading te behanneljen (it oantal makelders hinget ek ôf fan oare faktoaren, lykas it minimale oantal berjochtreplika's om fearkrêft te garandearjen, it oantal partitionen lieders, ensfh.). Dêrnjonken krije wy ynsjoch yn hokker ynfrastruktuerkomponinten fertikale skaalfergrutting nedich binne.
Dit artikel sil prate oer de stappen dy't wy nimme om it measte út 'e stadichste komponinten yn inisjele konfiguraasjes te heljen en de trochstreaming fan in Kafka-kluster te mjitten. In tige fersterke konfiguraasje fereasket op syn minst trije rinnende makelders (min.insync.replicas=3), ferdield oer trije ferskillende berikberenssônes. Om de Kubernetes-ynfrastruktuer te konfigurearjen, te skaaljen en te kontrolearjen, brûke wy ús eigen kontenerbehearplatfoarm foar hybride wolken - . It stipet on-premise (bleate metal, VMware) en fiif soarten wolken (Alibaba, AWS, Azure, Google, Oracle), lykas elke kombinaasje dêrfan.
Gedachten oer Kafka-klusterynfrastruktuer en konfiguraasje
Foar de foarbylden hjirûnder hawwe wy AWS keazen as de wolkprovider en EKS as de Kubernetes-distribúsje. In ferlykbere konfiguraasje kin wurde ymplementearre mei help - Kubernetes distribúsje út Banzai Cloud, sertifisearre troch CNCF.
skiif
Amazon biedt ferskate . By de kearn gp2 и io1 der binne SSD driuwfearren, lykwols, te garandearjen hege trochstreaming gp2 konsumearret opboude credits (I/O credits), dus wy leaver it type io1, dy't konsekwint hege trochslach biedt.
Instance types
Kafka's prestaasje is heul ôfhinklik fan 'e side-cache fan it bestjoeringssysteem, dus wy hawwe eksimplaren nedich mei genôch ûnthâld foar de brokers (JVM) en side-cache. Instance c5.2x grut - in goede start, sûnt it hat 16 GB ûnthâld en . It neidiel is dat it allinich yn steat is om maksimale prestaasjes foar net mear as 30 minuten elke 24 oeren te leverjen. As jo wurkdruk peakprestaasjes oer in langere perioade fereasket, wolle jo miskien oare eksimplaartypen beskôgje. Dat is krekt wat wy dien hawwe, stopje by c5.4x grut. It soarget foar maksimale trochslach yn 593,75 Mb/s. Maksimum trochfier fan in EBS folume io1 heger as it eksimplaar c5.4x grut, dus it stadichste elemint fan 'e ynfrastruktuer is wierskynlik de I/O-trochput fan dit eksimplaartype (wat ús loadtests ek moatte befestigje).
Netwurk
De netwurktrochput moat grut genôch wêze yn ferliking mei de prestaasjes fan 'e VM-eksimplaar en skiif, oars wurdt it netwurk in knelpunt. Yn ús gefal is de netwurkynterface c5.4x grut stipet snelheden fan maksimaal 10 Gb / s, wat signifikant heger is as de I / O-trochput fan in VM-eksimplaar.
Broker Deployment
Makelaars moatte wurde ynset (pland yn Kubernetes) nei tawijde knopen om konkurrearjen mei oare prosessen foar CPU-, ûnthâld-, netwurk- en skiifboarnen te foarkommen.
Java ferzje
De logyske kar is Java 11, om't it kompatibel is mei Docker yn 't sin dat de JVM de processors en ûnthâld korrekt bepaalt dy't beskikber binne foar de kontener wêryn de broker rint. Wittende dat CPU-grinzen wichtich binne, stelt de JVM yntern en transparant it oantal GC-threads en JIT-threads yn. Wy brûkten it Kafka-ôfbylding banzaicloud/kafka:2.13-2.4.0, dy't Kafka ferzje 2.4.0 (Scala 2.13) op Java 11 omfettet.
As jo mear wolle leare oer Java / JVM op Kubernetes, besjoch dan ús folgjende berjochten:
- ;
- .
Broker ûnthâld ynstellings
D'r binne twa wichtige aspekten foar it konfigurearjen fan brokerûnthâld: ynstellings foar de JVM en foar de Kubernetes-pod. De ûnthâldlimyt ynsteld foar in pod moat grutter wêze as de maksimale heapgrutte, sadat de JVM romte hat foar de Java-metaspace dy't yn syn eigen ûnthâld sit en foar it bestjoeringssysteem-sidecache dat Kafka aktyf brûkt. Yn ús tests lansearren wy Kafka-makelaars mei parameters -Xmx4G -Xms2G, en it ûnthâld limyt foar de pod wie 10 Gi. Tink derom dat ûnthâldynstellingen foar de JVM automatysk kinne wurde krigen mei -XX:MaxRAMPercentage и -X:MinRAMPercentage, basearre op de ûnthâld limyt foar de pod.
Broker prosessor ynstellings
Yn 't algemien kinne jo prestaasjes ferbetterje troch parallelisme te ferheegjen troch it oantal threads te ferheegjen dat troch Kafka brûkt wurdt. Hoe mear processors beskikber foar Kafka, hoe better. Yn ús test binne wy begûn mei in limyt fan 6 processors en stadichoan (troch iteraasjes) har oantal ferhege nei 15. Dêrneist sette wy num.network.threads=12 yn 'e makelderynstellingen om it oantal threads te ferheegjen dy't gegevens fan it netwurk ûntfange en ferstjoere. Fuortendaliks ûntdutsen dat de follower-makelaars gjin replika's fluch genôch koene ûntfange, brochten se op num.replica.fetchers nei 4 om de snelheid te fergrutsjen wêryn followermakkers berjochten fan lieders replikeare.
Laden Generation Tool
Jo moatte derfoar soargje dat de selekteare loadgenerator net út kapasiteit rint foardat it Kafka-kluster (dat wurdt benchmarked) syn maksimale lading berikt. Mei oare wurden, it is nedich om te fieren in foarriedige beoardieling fan de mooglikheden fan de load generaasje ark, en ek selektearje eksimplaar typen foar it mei in foldwaande oantal processors en ûnthâld. Yn dit gefal sil ús ark mear lading produsearje dan it Kafka-kluster kin omgean. Nei in protte eksperiminten, wy fêstigen op trije eksimplaren c5.4x grut, elk fan dat hie in generator running.
Benchmarking
Prestaasjemeting is in iteratyf proses dat de folgjende stadia omfettet:
- it opsetten fan ynfrastruktuer (EKS-kluster, Kafka-kluster, loadgeneraasje-ark, lykas Prometheus en Grafana);
- it generearjen fan in lading foar in bepaalde perioade om willekeurige ôfwikingen te filterjen yn 'e sammele prestaasje-yndikatoaren;
- oanpasse de ynfrastruktuer en konfiguraasje fan 'e makelder basearre op waarnommen prestaasjes yndikatoaren;
- it werheljen fan it proses oant it fereaske nivo fan Kafka-klustertrochput wurdt berikt. Tagelyk moat it konsekwint reprodusearber wêze en minimale fariaasjes yn trochset sjen litte.
De folgjende paragraaf beskriuwt de stappen dy't waarden útfierd tidens it testkluster benchmarkingproses.
Tools
De folgjende ark waarden brûkt om fluch in baseline-konfiguraasje yn te setten, loads te generearjen en prestaasjes te mjitten:
- foar it organisearjen fan in EKS-kluster fan Amazon c (om Kafka en ynfrastruktuer metrics te sammeljen) en (om dizze metriken te visualisearjen). Wy namen foardiel yntegrearre в tsjinsten dy't federearre tafersjoch leverje, sintralisearre logsammeling, kwetsberens skennen, disaster recovery, enterprise-grade feiligens en folle mear.
- - in ark foar load testen fan in Kafka-kluster.
- Grafana-dashboards foar fisualisearjen fan Kafka-metriken en ynfrastruktuer: , .
- Supertubes CLI foar de maklikste manier om in Kafka-kluster op Kubernetes yn te stellen. Zookeeper, Kafka-operator, Envoy en in protte oare komponinten binne ynstalleare en goed konfigureare om in produksje-klear Kafka-kluster op Kubernetes út te fieren.
- Foar ynstallaasje supertubes CLI brûk de ynstruksjes oanbean .
EKS kluster
Bereid in EKS-kluster mei tawijde arbeidersknooppunten c5.4x grut yn ferskillende beskikberens sônes foar pods mei Kafka makelders, likegoed as tawijd knopen foar de load generator en monitoring ynfrastruktuer.
banzai cluster create -f https://raw.githubusercontent.com/banzaicloud/kafka-operator/master/docs/benchmarks/infrastructure/cluster_eks_202001.jsonSadree't it EKS-kluster op en rint, aktivearje it yntegreare - se sil Prometheus en Grafana ynsette yn in kluster.
Kafka systeem komponinten
Ynstallearje Kafka-systeemkomponinten (Zookeeper, kafka-operator) yn EKS mei supertubes CLI:
supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>Kafka kluster
Standert brûkt EKS EBS-voluminten fan type gp2, dus jo moatte in aparte opslachklasse oanmeitsje op basis fan folumes io1 foar Kafka-kluster:
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
Stel de parameter foar brokers yn min.insync.replicas=3 en ynsette brokerpods op knopen yn trije ferskillende beskikberensônes:
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 600Underwerpen
Wy rûnen trije loadgenerator-eksimplaren parallel. Elk fan har skriuwt nei har eigen ûnderwerp, dat is, wy hawwe yn totaal trije ûnderwerpen nedich:
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
EOFFoar elk ûnderwerp is de replikaasjefaktor 3 - de minimale oanbefellende wearde foar heul beskikbere produksjesystemen.
Laden Generation Tool
Wy lansearre trije kopyen fan de lading generator (elk skreau yn in apart ûnderwerp). Foar pods foar loadgenerator moatte jo de knooppuntaffiniteit ynstelle sadat se allinich binne pland op 'e knopen dy't foar har tawiisd binne:
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: 30In pear punten om op te merken:
- De loadgenerator genereart berjochten fan 512 bytes yn 'e lingte en publisearret se oan Kafka yn batches fan 500 berjochten.
- Mei help fan in argumint
-required-acks=allDe publikaasje wurdt as suksesfol beskôge as alle syngronisearre replika's fan it berjocht wurde ûntfongen en befêstige troch Kafka-makelaars. Dit betsjut dat wy yn 'e benchmark net allinich de snelheid mjitten fan lieders dy't berjochten ûntfange, mar ek har folgers dy't berjochten replikearje. It doel fan dizze test is net om konsumintlêssnelheid te evaluearjen (konsuminten) koartlyn ûntfongen berjochten dy't noch yn 'e OS-side-cache bliuwe, en syn ferliking mei de lêssnelheid fan berjochten opslein op skiif. - De loadgenerator rint 20 arbeiders parallel (
-workers=20). Elke arbeider befettet 5 produsinten dy't de ferbining fan 'e arbeider diele mei it Kafka-kluster. As gefolch hat elke generator 100 produsinten, en se stjoere allegear berjochten nei it Kafka-kluster.
Tafersjoch op de sûnens fan it kluster
Tidens loadtesten fan it Kafka-kluster hawwe wy ek de sûnens kontroleare om te soargjen dat d'r gjin pod-opstarten wiene, gjin replika's dy't net syngronisearre wiene, en maksimale trochstreaming mei minimale fluktuaasjes:
- De loadgenerator skriuwt standertstatistiken oer it oantal publisearre berjochten en it flaterrate. It flaternivo moat itselde bliuwe
0,00%. - , ynset troch kafka-operator, jout in dashboard dêr't wy ek kinne tafersjoch op de steat fan it kluster. Om dit paniel te besjen, dwaan:
supertubes cluster cruisecontrol show -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> - ISR nivo (oantal "yn-sync" replika's) krimp en útwreiding binne gelyk oan 0.
Meetresultaten
3 makelders, berjocht grutte - 512 bytes
Mei partysjes lykweardich ferdield oer trije makelders, koenen wy prestaasjes berikke ~500 Mb/s (likernôch 990 tûzen berjochten per sekonde):
It ûnthâldferbrûk fan 'e JVM firtuele masine wie net mear as 2 GB:
Skiif trochfier berikte de maksimale I / O-knooppunt trochfier op alle trije eksimplaren wêrop de makelders rinne:
Ut de gegevens oer ûnthâldgebrûk troch knooppunten folget it dat systeembuffering en caching ~10-15 GB namen:
3 makelders, berjocht grutte - 100 bytes
As de berjochtgrutte ôfnimt, sakket de trochstreaming mei sawat 15-20%: de tiid dy't bestege oan it ferwurkjen fan elk berjocht hat ynfloed op it. Dêrneist is de prosessor lading hast ferdûbele.
Sûnt brokerknooppunten noch net brûkte kearnen hawwe, kinne prestaasjes ferbettere wurde troch de Kafka-konfiguraasje te feroarjen. Dit is gjin maklike taak, dus om de trochslach te fergrutsjen is it better om te wurkjen mei gruttere berjochten.
4 makelders, berjocht grutte - 512 bytes
Jo kinne de prestaasjes fan in Kafka-kluster maklik ferheegje troch gewoan nije makelders ta te foegjen en in lykwicht fan partysjes te behâlden (dit soarget derfoar dat de lading evenredich ferdield wurdt tusken makelders). Yn ús gefal, nei it tafoegjen fan in makelder, de kluster trochfier tanommen nei ~580 Mb/s (~1,1 miljoen berjochten per sekonde). De groei blykte minder te wêzen as ferwachte: dit wurdt benammen ferklearre troch it ûnbalâns fan partysjes (net alle makelders wurkje op it hichtepunt fan har mooglikheden).
Unthâldferbrûk fan 'e JVM-masine bleau ûnder 2 GB:
It wurk fan makelders mei driuwfearren waard beynfloede troch it ûnbalâns fan partysjes:
befinings
De hjirboppe presintearre iterative oanpak kin wurde útwreide om mear komplekse senario's te dekken wêrby't hûnderten konsuminten, repartitioning, rollende updates, pod opnij starte, ensfh. Dit alles lit ús de grinzen fan 'e kapasiteiten fan' e Kafka-kluster yn ferskate omstannichheden beoardielje, knyppunten yn 'e operaasje identifisearje en manieren fine om se te bestriden.
Wy hawwe Supertubes ûntworpen om in kluster fluch en maklik yn te setten, it te konfigurearjen, makelders en ûnderwerpen ta te foegjen / te ferwiderjen, te reagearjen op warskôgings, en soargje dat Kafka yn 't algemien goed wurket op Kubernetes. Us doel is om jo te helpen konsintrearje op 'e haadtaak ("generearje" en "konsumearje" Kafka-berjochten), en al it hurde wurk oerlitte oan Supertubes en de Kafka-operator.
As jo ynteressearre binne yn Banzai Cloud technologyen en Open Source projekten, abonnemint op it bedriuw by , of .
PS fan oersetter
Lês ek op ús blog:
- «";
- «";
- «".
Boarne: www.habr.com