Not. werger.: Di vê gotarê de, Banzai Cloud mînakek karanîna amûrên xwe yên xwerû parve dike da ku hêsantir bike ku Kafka di nav Kubernetes de bimeşîne. Talîmatên li jêr destnîşan dikin ka hûn çawa dikarin mezinahiya binesaziya çêtirîn diyar bikin û Kafka bixwe bişopînin da ku bigihîje berbi hewce.
Apache Kafka ji bo avakirina pergalên weşana rast-demê pêbawer, berbelav û bi performansa bilind platformek streaming ya belavkirî ye. Kapasîteyên wê yên berbiçav dikarin bi Kubernetes re bêne dirêj kirin. Ji bo vê me pêş xist û amûrek bi navê . Ew dihêlin ku hûn Kafka li ser Kubernetes bimeşînin û taybetmendiyên wê yên cihêreng bikar bînin, wek mînak birêkûpêkkirina mîhengê broker, pîvandina bingeha metrîkê bi hevsengkirinê, hişmendiya rack (hişmendiya çavkaniyên hardware), "nerm" (narîne) derxistina nûvekirinan, hwd.
Supertubes li ser koma xwe biceribînin:
curl https://getsupertubes.sh | sh и supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>An jî serî lê bidin . Her weha hûn dikarin li ser hin taybetmendiyên Kafka bixwînin, xebata ku bi karanîna Supertubes û Kafka operator bixweber e. Me berê jî li ser wan blog kir:
- ;
- ;
- ;
- ;
- ;
- ;
- .
Gava ku hûn biryar didin ku komek Kafka li ser Kubernetes bicîh bikin, hûn ê bi dijwariya destnîşankirina mezinahiya çêtirîn a binesaziya bingehîn û hewcedariya ku hûn veavakirina Kafka-ya xwe baş rast bikin ji bo ku hewcedariyên karûbarê bicîh bînin re rû bi rû bimînin. Performansa herî zêde ya her brokerek ji hêla performansa hêmanên binesaziyê yên di bingeha wê de, wekî bîranîn, pêvajoyek, leza dîskê, firehiya torê, û hwd ve tê destnîşankirin.
Bi îdeal, veavakirina brokerê divê wusa be ku hemî hêmanên binesaziyê bi herî zêde kapasîteyên xwe bikar bînin. Lêbelê, di jiyana rast de, sazkirinek weha pir tevlihev e. Zêdetir e ku bikarhêner dê brokeran bi vî rengî mîheng bikin ku karanîna yek an du hêmanan (dîsk, bîranîn, an pêvajo) herî zêde bikin. Bi gelemperî, brokerek performansa herî zêde destnîşan dike dema ku veavakirina wê destûrê dide karanîna pêkhateya herî hêdî "bi tevahî". Ji ber vê yekê em dikarin li ser barkirina ku yek broker dikare hilgire ramanek berbiçav bistînin.
Ji hêla teorîkî ve, em dikarin hejmara brokerên ku hewce ne ku bi barek diyarkirî re bixebitin jî texmîn bikin. Lêbelê, di pratîkê de, di astên cihêreng de ew qas vebijarkên tunekirinê hene ku nirxandina performansa potansiyel a mîhengek diyar pir dijwar e (heke ne ne gengaz be). Bi gotinek din, pir dijwar e ku meriv mîhengek li ser bingeha hin performansa diyarkirî plansaz bike.
Ji bo bikarhênerên Supertubes, em bi gelemperî nêzîkatiya jêrîn digirin: em bi hin veavakirinê (binesaz + mîhengan) dest pê dikin, dûv re performansa wê dipîvin, mîhengên brokerê rast dikin û pêvajoyê dîsa dubare dikin. Ev diqewime heya ku potansiyela hêmaya herî hêdî ya binesaziyê bi tevahî were bikar anîn.
Bi vî rengî, em ramanek zelaltir distînin li ser çend brokeran ku komek pêdivî ye ku barek diyar bi dest bixe (hejmara brokeran jî bi faktorên din ve girêdayî ye, wek mînak hejmara hindiktirîn kopiyên peyamê ji bo misogerkirina rehetiyê, hejmara dabeşkirinê. rêber û hwd.). Wekî din, em ramanek distînin ka kîjan pêkhateya binesaziyê ji bo pîvandina vertîkal tê xwestin.
Ev gotar dê balê bikişîne ser gavên ku em diavêjin da ku "her tiştî" ji hêmanên herî hêdî di veavakirinên destpêkê de biqedînin û rêgezek komek Kafka bipîvin. Veavakirinek pir berxwedêr bi kêmî ve sê brokerên xebatkar hewce dike (min.insync.replicas=3) li sê Herêmên Berdestbûnê yên cihêreng belav dibe. Ji bo mîhengkirin, pîvandin û şopandina binesaziya Kubernetes, em platforma xweya rêveberiya konteynerê ji bo ewrên hybrid bikar tînin - . Ew li ser bingehê (metalê tazî, VMware) û pênc celeb ewran (Alibaba, AWS, Azure, Google, Oracle), û her weha her berhevoka wan piştgirî dike.
Ramanên li ser binesaziyê û veavakirina komek Kafka
Ji bo mînakên li jêr, me AWS wekî pêşkêşkarê ewr û EKS wekî belavkirina Kubernetes hilbijart. Veavakirinek bi vî rengî dikare bi kar were pêkanîn ji Banzai Cloud belavokek Kubernetes-erêkirî ya CNCF-ê ye.
dîskê
Amazon cûrbecûr pêşkêşî dike . Di bingeh de gp2 и io1 lêbelê, ajokarên SSD-ê derewîn dikin da ku pêbaweriya bilind peyda bikin gp2 krediyên berhevkirî dixwe (Krediyên I/O), ji ber vê yekê me celeb tercîh kir io1, ku berbi bilind a domdar pêşkêşî dike.
Cureyên nimûne
Performansa Kafka pir bi cache rûpela pergala xebitandinê ve girêdayî ye, ji ber vê yekê em ji bo brokeran (JVM) û cache rûpelê hewceyê mînakên bi têra bîranînê ne. Mînak c5.2xmezin - destpêkek baş, ji ber ku ew xwedî 16 GB bîra û . Kêmasiya wê ev e ku ew dikare her 30 demjimêran ji 24 hûrdeman bêtir performansa herî zêde peyda bike. Ger barê xebata we ji bo demek dirêjtir performansa herî zêde hewce dike, divê hûn celebên nimûneyên din bifikirin. Ya ku me li ser sekinîn tam ev e c5.4xmezin. Ew di hundurê de herî zêde hilber peyda dike 593,75 Mbps. EBS Volume Maximum Bandwidth io1 ji nimûneyê bilindtir c5.4xmezin, ji ber vê yekê perçeya herî hêdî ya binesaziyê xuya dike ku rêça I/O ya vê celebê nimûneyê ye (ku divê ceribandinên barkirina me jî piştrast bikin).
Network
Pêdivî ye ku berbi torê li gorî performansa mînaka VM û dîskê têra xwe mezin be, wekî din torgilok dibe hêlînek. Di rewşa me de, pêwendiya torê c5.4xmezin Leza heta 10 Gb / s piştgirî dike, ku ji guheztina I/O ya mînakek VM-ê pir girîngtir e.
Broker Deployment
Pêdivî ye ku broker (li Kubernetes-ê hatî plansaz kirin) li girêkên veqetandî werin bicîh kirin da ku ji nakokiyên pêvajoyên din ên ji bo CPU, bîranîn, torê û çavkaniyên dîskê dûr nekevin.
Versiyon ji Java
Java 11 bijareya mentiqî ye ji ber ku ew bi Docker re hevaheng e di vê wateyê de ku JVM bi rast pêvajo û bîranîna ku li konteynera ku broker tê de dimeşe peyda dike. Dizanin ku tixûbên CPU girîng in, JVM di hundurê xwe de û bi zelalî hejmara mijarên GC û mijarên berhevkarê JIT destnîşan dike. Me wêneyê Kafka bikar anî banzaicloud/kafka:2.13-2.4.0, ku Kafka 2.4.0 (Scala 2.13) li ser Java 11 dihewîne.
Heke hûn dixwazin li ser Kubernetes li ser Java / JVM bêtir fêr bibin, ji kerema xwe li weşanên me yên jêrîn binêrin:
- ;
- .
Mîhengên bîra Broker
Ji bo sazkirina bîra brokerek du aliyên sereke hene: mîhengên ji bo JVM û mîhengên ji bo Kubernetes pod. Sînorê bîranînê yê ku ji bo podek hatî danîn divê ji mezinahiya herî zêde ya girikê mezintir be da ku JVM ji bo metaspaceya Java ya ku di bîra xwe de dimîne û ji bo cache rûpela pergala xebitandinê ya ku Kafka bi çalak bikar tîne cîh hebe. Di ceribandinên xwe de, me brokerên Kafka bi parametreyan dan destpêkirin -Xmx4G -Xms2G, û sînorê bîra ji bo pod bû 10 Gi. Ji kerema xwe not bikin ku mîhengên bîranînê ji bo JVM dikarin bixweber bikar bînin -XX:MaxRAMPercentage и -X:MinRAMPercentage, li ser sînorê bîra ji bo pod.
Mîhengên processor Broker
Bi gelemperî, hûn dikarin bi zêdekirina hevdemiyê bi zêdekirina hejmara têlên ku ji hêla Kafka ve têne bikar anîn performansê baştir bikin. Ji bo Kafka çiqas bêtir pêvajo hene, ew qas çêtir. Di ceribandina xwe de, me bi sînorê 6 pêvajoyê dest pê kir û hêdî hêdî (di dubareyan de) hejmara wan zêde kir 15. Wekî din, me destnîşan kir num.network.threads=12 di mîhengên brokerê de ji bo zêdekirina hejmara herikên ku daneyan ji torê digirin û dişînin zêde bikin. Piştî ku tavilê fêhm kir ku brokerên şopîner nekarin bi têra xwe zû kopiyan bistînin, rabûn num.replica.fetchers berbi 4-ê da ku rêjeya ku brokerên şopînerê peyamên rêberan dubare dikin zêde bikin.
Amûra Nifşa Barkirinê
Pêdivî ye ku hûn pê ewle bin ku potansiyela jeneratorê barkirinê yê hilbijartî berî ku komika Kafka (ya ku tê pîvandin) bigihîje barkirina xweya herî zêde neqede. Bi gotinek din, pêdivî ye ku nirxandinek pêşîn a kapasîteyên amûra hilberîna barkirinê were kirin, û her weha celebên nimûneyê ji bo wê bi hejmarek têr pêvajoker û bîranîn hilbijêrin. Di vê rewşê de, amûra me dê ji berhevoka Kafka bêtir bar hilîne. Piştî gelek ceribandinan, em li ser sê nusxe rûniştin c5.4xmezin, di her yek ji wan de jenerator dest pê kir.
Benchmarking
Pîvana performansê pêvajoyek dubare ye ku gavên jêrîn pêk tîne:
- sazkirina binesaziyê (koma EKS, koma Kafka, amûra hilberîna barkirinê, û her weha Prometheus û Grafana);
- di heyamekê de barkirinê biafirînin da ku guheztinên rasthatî yên di metrîkên performansa berhevkirî de fîltre bikin;
- sererastkirina binesaziyê û veavakirina brokerê li ser bingeha nîşaneyên performansê yên hatine dîtin;
- dubarekirina pêvajoyê heya ku asta karûbarê pêdivî ya koma Kafka bigihîje. Di heman demê de, pêdivî ye ku ew bi domdarî were hilberandin û guheztinên hindiktirîn guheztinan nîşan bide.
Beşa jêrîn gavên ku di dema pêvajoya pîvana koma testê de hatine avêtin vedibêje.
Amûr
Amûrên jêrîn hatin bikar anîn da ku zû veavakirinek bingehîn, hilberîna barkirinê û pîvandina performansê bicîh bikin:
- ji bo organîzekirina komek EKS ji Amazon c (ji bo berhevkirina Kafka û metrîkên binesaziyê) û (ji bo dîtina van metrîkan). Me sûd wergirt entegre в karûbarên ku çavdêriya federatîf, têketina navendî, şopandina lawazbûnê, vegerandina karesatê, ewlehiya pola pargîdanî, û hêj bêtir peyda dikin.
- Amûrek ji bo ceribandina barkirinê komek Kafka ye.
- Tabloyên Grafana ji bo dîtina pîvan û binesaziya Kafka: , .
- Supertubes CLI ji bo riya herî hêsan a sazkirina komek Kafka li Kubernetes. Zookeeper, operator Kafka, Envoy û gelek hêmanên din têne saz kirin û bi rêkûpêk hatine mîheng kirin ku komek Kafka ya amade-hilberînê li ser Kubernetes bimeşînin.
- Ji bo sazkirinê supertubes CLI talîmatên pêşkêşkirî bikar bînin .
Cluster EKS
Klusterek EKS bi Nodên Karkerên Veqetandî re peyda bikin c5.4xmezin li deverên cûda yên hebûna ji bo podên bi brokerên Kafka, û her weha girêkên veqetandî yên ji bo hilberînerê barkirinê û binesaziya çavdêriyê.
banzai cluster create -f https://raw.githubusercontent.com/banzaicloud/kafka-operator/master/docs/benchmarks/infrastructure/cluster_eks_202001.jsonDema ku komika EKS-ê rabe û bixebite, wê ya yekbûyî vekin - ew ê Prometheus û Grafana di komekê de bicîh bike.
pêkhateyên sîstema Kafka
Bi karanîna supertubes CLI, pêkhateyên pergala Kafka (Zookeeper, kafka-operator) li EKS saz bikin:
supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>Koma Kafka
Bi xwerû, EKS cildên cureyê EBS bikar tîne gp2, ji ber vê yekê hûn hewce ne ku çînek hilanînê ya cihê li ser bingeha cildan biafirînin io1 ji bo koma 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
Parametreya brokeran saz bikin min.insync.replicas=3 û li sê Herêmên Hebûnê yên cihêreng pêlên broker li ser girêkan bicîh bikin:
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 600Mijar
Me sê mînakên jeneratorê barkirinê bi paralelî meşandin. Her yek ji wan li ser mijara xwe dinivîse, ango bi tevahî sê mijaran ji me re lazim in:
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
EOFJi bo her mijarê, faktora dubarekirinê 3 ye, nirxa herî kêm a pêşniyarkirî ji bo pergalên hilberîna pir berdest.
Amûra Nifşa Barkirinê
Me sê mînakên jeneratorê barkirinê meşandin (her yekê di mijarek cihê de nivîsand). Ji bo pêlên jeneratorê barkirinê, hûn hewce ne ku pêwendiya girêk diyar bikin da ku ew tenê li ser girêkên ku ji bo wan hatine veqetandin têne plansaz kirin:
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Çend xalên ku divê bala xwe bidinê:
- Generatorê barkirinê mesajên 512-byte çêdike û ji 500 peyaman re ji Kafka re diweşîne.
- Bi nîqaş
-required-acks=allWeşanek serkeftî tê hesibandin dema ku hemî kopiyên peyamên hevdemkirî ji hêla brokerên Kafka ve hatine wergirtin û pejirandin. Ev tê vê wateyê ku di pîvanê de, me ne tenê leza serokên ku peyaman distînin, lê di heman demê de şagirtên wan ên ku peyaman dubare dikin jî pîva. Armanca vê testê ne nirxandina leza xwendina xerîdaran e (serfkaran) di van demên dawî de peyamên ku hîn jî di cache rûpela OS-ê de ne hatine wergirtin, û berhevdana wê bi leza xwendina peyamên ku li ser dîskê hatine hilanîn. - Generatora barkirinê 20 karkeran bi paralelî dixebitîne (
-workers=20). Her karkerek 5 hilberînerên ku girêdana karker bi koma Kafka re parve dikin hene. Di encamê de, her jeneratorek 100 hilberîner hene, û hemî jî peyaman dişînin koma Kafka.
Rewşa komê bişopînin
Di dema ceribandina barkirina komê Kafka de, me tenduristiya wê jî şopand da ku em pê ewle bin ku ji nû ve destpêkirina pod, kopiyên ji hevdemkirinê, û guheztina herî zêde bi guheztinên hindiktirîn tune ne:
- Afirînerê barkirinê li ser hejmara peyamên hatine şandin û rêjeya xeletiyê statîstîkên standard dinivîse. Rêjeya xeletiyan divê di nirxê de bimîne
0,00%. - , ku ji hêla kafka-operator ve hatî bicîh kirin, tabloyek peyda dike ku em dikarin rewşa komê jî bişopînin. Ji bo dîtina vê panelê, bişopînin:
supertubes cluster cruisecontrol show -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> - asta ISR (hejmara kopiyên "li hevdem") kêmbûn û berfirehbûn 0 ye.
Encamên pîvandinê
3 broker, mezinahiya peyamê - 512 bytes
Bi dabeşên ku li ser sê brokeran bi rengek wekhev hatine belav kirin, me karîbû bigihîje performansê ~ 500 Mb/s (nêzîkî 990 hezar peyam di çirkekê de):
Xerca bîranîna makîneya virtual JVM ji 2 GB derbas nebû:
Rêbaza dîskê di her sê mînakên ku brokeran dimeşandin gihîşt asta herî zêde ya girêka I/O:
Ji daneyên li ser karanîna bîranînê ji hêla girêkan ve, wisa dixuye ku tampon û cachkirina pergalê ~ 10-15 GB girt:
3 broker, mezinahiya peyamê - 100 bytes
Her ku mezinahiya peyamê kêm dibe, ji ber dema ku ji bo her peyamê derbas dibe, bi qasî 15-20% kêm dibe. Wekî din, barkirina li ser pêvajoyê hema hema du qat bûye.
Ji ber ku girêkên broker hîn jî xwedan navikên nekarandî ne, performans dikare bi guheztina veavakirina Kafka were baştir kirin. Ev ne karekî hêsan e, ji ber vê yekê çêtir e ku meriv bi mesajên mezin re bixebite ji bo zêdekirina rêwiyan.
4 broker, mezinahiya peyamê - 512 bytes
Hûn dikarin bi hêsanî performansa komek Kafka bi lê zêdekirina brokerên nû zêde bikin û dabeşan hevseng bihêlin (ev piştrast dike ku bar di nav brokeran de wekhev tê dabeş kirin). Di rewşa me de, piştî lê zêdekirina brokerek, berbi komê zêde bû ~ 580 Mbps (~ 1,1M peyam di çirkekê de). Mezinbûn ji ya hêvîbûnê piçûktir derket holê: ev bi giranî ji ber bêhevsengiya dabeşan e (ne hemî broker di lûtkeya kapasîteyên xwe de dixebitin).
Xerca bîranîna makîneya JVM di binê 2 GB de ma:
Karê brokerên bi ajokeran ji ber nehevsengiya dabeşan bandor bû:
vebiguherin
Nêzîkatiya dubarekirî ya ku li jor hatî pêşkêş kirin dikare were dirêj kirin da ku senaryoyên tevlihevtir ên ku bi sedan xerîdar, ji nû ve dabeşkirin, nûvekirinên nûvekirin, ji nû ve destpêkirina pod, û hwd vedihewîne veşêre. Ev hemû rê dide me ku em sînorên komê Kafka di şert û mercên cihê de binirxînin, kêşeyên di xebata wê de nas bikin û rêyên mijûlbûna bi wan re bibînin.
Me Supertubes dîzayn kir ku zû û bi hêsanî komekê bi cih bike, wê mîheng bike, broker û mijaran lê zêde bike/rabike, bersivê bide hişyariyan, û piştrast bike ku Kafka li Kubernetes bi gelemperî bi rêkûpêk dixebite. Armanca me ew e ku em bala xwe bidin ser peywira sereke ("çêkirin" û "bixwe" peyamên Kafka), û hemî xebata dijwar ji Supertubes û Kafka operator'u re bihêlin.
Heke hûn bi teknolojiyê û projeyên Çavkaniya Vekirî ya Banzai Cloud re eleqedar in, bibin aboneyê pargîdaniyê , an .
PS ji wergêr
Li ser bloga me jî bixwînin:
- «»;
- «»;
- «".
Source: www.habr.com