PiezÄ«me. tulk.: Å”ajÄ rakstÄ Banzai Cloud dalÄs ar piemÄru, kÄ tÄ pielÄgotos rÄ«kus var izmantot, lai atvieglotu Kafka lietoÅ”anu Kubernetes. TÄlÄk sniegtie norÄdÄ«jumi ilustrÄ, kÄ varat noteikt savas infrastruktÅ«ras optimÄlo izmÄru un konfigurÄt paÅ”u Kafka, lai sasniegtu nepiecieÅ”amo caurlaidspÄju.
Apache Kafka ir izplatÄ«ta straumÄÅ”anas platforma uzticamu, mÄrogojamu un augstas veiktspÄjas reÄllaika straumÄÅ”anas sistÄmu izveidei. TÄs iespaidÄ«gÄs iespÄjas var paplaÅ”inÄt, izmantojot Kubernetes. Å im nolÅ«kam mÄs esam izstrÄdÄjuÅ”i un rÄ«ks, ko sauc . Tie ļauj palaist Kafka vietnÄ Kubernetes un izmantot tÄs dažÄdÄs funkcijas, piemÄram, starpnieka konfigurÄcijas precizÄÅ”anu, uz metriku balstÄ«tu mÄrogoÅ”anu ar lÄ«dzsvaroÅ”anu, statÄ«va apzinÄÅ”anos, āmÄ«kstoā (graciozs) atjauninÄjumu ievieÅ”ana utt.
IzmÄÄ£iniet Supertubes savÄ klasterÄ«:
curl https://getsupertubes.sh | sh Šø supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>Vai arÄ« sazinieties . Varat arÄ« lasÄ«t par dažÄm Kafkas iespÄjÄm, ar kurÄm darbs tiek automatizÄts, izmantojot Supertubes un Kafka operatoru. Par tiem jau rakstÄ«jÄm emuÄrÄ:
- ;
- ;
- ;
- ;
- ;
- ;
- .
Kad jÅ«s nolemjat izvietot Kafka klasteru Kubernetes, jÅ«s, iespÄjams, saskarsities ar izaicinÄjumu noteikt pamatÄ esoÅ”Äs infrastruktÅ«ras optimÄlo izmÄru un vajadzÄ«bu precizÄt savu Kafka konfigurÄciju, lai tÄ atbilstu caurlaidspÄjas prasÄ«bÄm. Katra brokera maksimÄlo veiktspÄju nosaka pamatÄ esoÅ”o infrastruktÅ«ras komponentu veiktspÄja, piemÄram, atmiÅa, procesors, diska Ätrums, tÄ«kla joslas platums utt.
IdeÄlÄ gadÄ«jumÄ brokera konfigurÄcijai jÄbÅ«t tÄdai, lai visi infrastruktÅ«ras elementi tiktu izmantoti maksimÄli. TomÄr reÄlajÄ dzÄ«vÄ Å”Ä« iestatÄ«Å”ana ir diezgan sarežģīta. VisticamÄk, ka lietotÄji konfigurÄs brokerus, lai maksimÄli izmantotu vienu vai divus komponentus (disku, atmiÅu vai procesoru). VispÄrÄ«gi runÄjot, brokeris parÄda maksimÄlu veiktspÄju, ja tÄ konfigurÄcija ļauj pilnÄ«bÄ izmantot lÄnÄko komponentu. TÄdÄ veidÄ mÄs varam iegÅ«t aptuvenu priekÅ”statu par slodzi, ar kuru viens brokeris var tikt galÄ.
TeorÄtiski mÄs varam arÄ« novÄrtÄt brokeru skaitu, kas nepiecieÅ”ams, lai apstrÄdÄtu noteiktu slodzi. TomÄr praksÄ ir tik daudz konfigurÄcijas iespÄju dažÄdos lÄ«meÅos, ka ir ļoti grÅ«ti (ja ne neiespÄjami) novÄrtÄt konkrÄtas konfigurÄcijas iespÄjamo veiktspÄju. Citiem vÄrdiem sakot, ir ļoti grÅ«ti plÄnot konfigurÄciju, pamatojoties uz noteiktu veiktspÄju.
Supertubes lietotÄjiem mÄs parasti izmantojam Å”Ädu pieeju: mÄs sÄkam ar kÄdu konfigurÄciju (infrastruktÅ«ra + iestatÄ«jumi), pÄc tam izmÄrÄm tÄ veiktspÄju, pielÄgojam brokera iestatÄ«jumus un atkÄrtojam procesu vÄlreiz. Tas notiek, lÄ«dz infrastruktÅ«ras lÄnÄkÄ sastÄvdaļa ir pilnÄ«bÄ izmantota.
TÄdÄ veidÄ mÄs iegÅ«stam skaidrÄku priekÅ”statu par to, cik brokeru ir nepiecieÅ”ams klasterim, lai apstrÄdÄtu noteiktu slodzi (brokeru skaits ir atkarÄ«gs arÄ« no citiem faktoriem, piemÄram, minimÄlÄ ziÅojumu kopiju skaita, lai nodroÅ”inÄtu elastÄ«bu, nodalÄ«jumu skaita vadÄ«tÄji utt.). TurklÄt mÄs gÅ«stam ieskatu par to, kuriem infrastruktÅ«ras komponentiem nepiecieÅ”ama vertikÄla mÄrogoÅ”ana.
Å ajÄ rakstÄ tiks runÄts par darbÄ«bÄm, ko veicam, lai sÄkotnÄjÄs konfigurÄcijÄs maksimÄli izmantotu lÄnÄkos komponentus un izmÄrÄ«tu Kafka klastera caurlaidspÄju. Ä»oti elastÄ«gai konfigurÄcijai ir nepiecieÅ”ami vismaz trÄ«s strÄdÄjoÅ”i brokeri (min.insync.replicas=3), sadalÄ«ts trÄ«s dažÄdÄs pieejamÄ«bas zonÄs. Lai konfigurÄtu, mÄrogotu un pÄrraudzÄ«tu Kubernetes infrastruktÅ«ru, mÄs izmantojam savu konteineru pÄrvaldÄ«bas platformu hibrÄ«diem mÄkoÅiem - . TÄ atbalsta lokÄlos (bezmetÄla, VMware) un piecu veidu mÄkoÅus (Alibaba, AWS, Azure, Google, Oracle), kÄ arÄ« jebkuru to kombinÄciju.
PÄrdomas par Kafka klastera infrastruktÅ«ru un konfigurÄciju
TÄlÄk norÄdÄ«tajos piemÄros mÄs izvÄlÄjÄmies AWS kÄ mÄkoÅa nodroÅ”inÄtÄju un EKS kÄ Kubernetes izplatÄ«Å”anu. LÄ«dzÄ«gu konfigurÄciju var ieviest, izmantojot - Kubernetes izplatÄ«Å”ana no Banzai Cloud, sertificÄta CNCF.
disks
Amazon piedÄvÄ dažÄdus . PamatÄ gp2 Šø io1 tomÄr ir SSD diskdziÅi, lai nodroÅ”inÄtu augstu caurlaidspÄju gp2 patÄrÄ uzkrÄtos kredÄ«tus (I/O kredÄ«ti), tÄpÄc mÄs izvÄlÄjÄmies veidu io1, kas nodroÅ”ina nemainÄ«gi augstu caurlaidspÄju.
InstanÄu veidi
Kafkas veiktspÄja ir ļoti atkarÄ«ga no operÄtÄjsistÄmas lapas keÅ”atmiÅas, tÄpÄc mums ir nepiecieÅ”ami gadÄ«jumi ar pietiekami daudz atmiÅas starpniekiem (JVM) un lapas keÅ”atmiÅai. PiemÄrs c5.2xliels - labs sÄkums, jo tam ir 16 GB atmiÅa un . TÄ trÅ«kums ir tÄds, ka tas spÄj nodroÅ”inÄt maksimÄlo veiktspÄju tikai ne vairÄk kÄ 30 minÅ«tes ik pÄc 24 stundÄm. Ja jÅ«su darba slodzei ir nepiecieÅ”ama maksimÄlÄ veiktspÄja ilgÄkÄ laika periodÄ, iespÄjams, vÄlÄsities apsvÄrt citus gadÄ«jumu veidus. TieÅ”i tÄ mÄs arÄ« darÄ«jÄm, pieturoties c5.4xliels. Tas nodroÅ”ina maksimÄlu caurlaidspÄju 593,75 Mb/s. MaksimÄlÄ EBS apjoma caurlaidspÄja io1 augstÄks par gadÄ«jumu c5.4xliels, tÄpÄc vislÄnÄkais infrastruktÅ«ras elements, visticamÄk, ir Ŕī gadÄ«juma veida I/O caurlaidspÄja (kas arÄ« jÄapstiprina mÅ«su slodzes testiem).
TÄ«kls
TÄ«kla caurlaidspÄjai jÄbÅ«t pietiekami lielai salÄ«dzinÄjumÄ ar VM instances un diska veiktspÄju, pretÄjÄ gadÄ«jumÄ tÄ«kls kļūst par saÅ”aurinÄjumu. MÅ«su gadÄ«jumÄ tÄ«kla saskarne c5.4xliels atbalsta Ätrumu lÄ«dz 10 Gb/s, kas ir ievÄrojami augstÄks nekÄ VM instances I/O caurlaidspÄja.
Brokeru izvietoŔana
Brokeri ir jÄizvieto (ieplÄnoti programmÄ Kubernetes) speciÄlos mezglos, lai izvairÄ«tos no konkurences ar citiem procesiem par CPU, atmiÅu, tÄ«klu un diska resursiem.
Java versija
LoÄ£iska izvÄle ir Java 11, jo tÄ ir saderÄ«ga ar Docker tÄdÄ nozÄ«mÄ, ka JVM pareizi nosaka procesorus un atmiÅu, kas ir pieejama konteineram, kurÄ darbojas brokeris. Zinot, ka CPU ierobežojumi ir svarÄ«gi, JVM iekÅ”Äji un pÄrredzami nosaka GC pavedienu un JIT pavedienu skaitu. MÄs izmantojÄm Kafkas attÄlu banzaicloud/kafka:2.13-2.4.0, kas ietver Kafka versiju 2.4.0 (Scala 2.13) uz Java 11.
Ja vÄlaties uzzinÄt vairÄk par Java/JVM vietnÄ Kubernetes, skatiet mÅ«su Ŕīs ziÅas:
- ;
- .
Brokera atmiÅas iestatÄ«jumi
Brokera atmiÅas konfigurÄÅ”anai ir divi galvenie aspekti: JVM un Kubernetes pod iestatÄ«jumi. AtmiÅas ierobežojumam, kas iestatÄ«ts podam, ir jÄbÅ«t lielÄkam par maksimÄlo kaudzes lielumu, lai JVM bÅ«tu vieta Java metavietai, kas atrodas tÄ atmiÅÄ, un operÄtÄjsistÄmas lapas keÅ”atmiÅai, ko aktÄ«vi izmanto Kafka. MÅ«su testos mÄs uzsÄkÄm Kafka brokerus ar parametriem -Xmx4G -Xms2G, un atmiÅas ierobežojums podam bija 10 Gi. LÅ«dzu, Åemiet vÄrÄ, ka JVM atmiÅas iestatÄ«jumus var iegÅ«t automÄtiski, izmantojot -XX:MaxRAMPercentage Šø -X:MinRAMPercentage, pamatojoties uz podziÅas atmiÅas ierobežojumu.
Brokeru procesora iestatījumi
VispÄrÄ«gi runÄjot, veiktspÄju var uzlabot, palielinot paralÄlismu, palielinot Kafkas izmantoto pavedienu skaitu. Jo vairÄk Kafka procesoru ir pieejams, jo labÄk. PÄrbaudÄ mÄs sÄkÄm ar 6 procesoru ierobežojumu un pakÄpeniski (izmantojot iterÄcijas) palielinÄjÄm to skaitu lÄ«dz 15. TurklÄt mÄs iestatÄ«jÄm num.network.threads=12 brokera iestatÄ«jumos, lai palielinÄtu to pavedienu skaitu, kas saÅem datus no tÄ«kla un nosÅ«ta tos. Uzreiz atklÄjot, ka sekotÄju brokeri nevar pietiekami Ätri saÅemt kopijas, viÅi izvirzÄ«ja jautÄjumu num.replica.fetchers uz 4, lai palielinÄtu Ätrumu, kÄdÄ sekotÄju brokeri atkÄrto ziÅojumus no lÄ«deriem.
Slodzes Ä£enerÄÅ”anas rÄ«ks
Jums jÄnodroÅ”ina, lai izvÄlÄtÄ slodzes Ä£eneratora jauda neiztrÅ«ktu, pirms Kafka klasteris (kas tiek veikts etalonuzÅÄmumÄ) sasniedz maksimÄlo slodzi. Citiem vÄrdiem sakot, ir jÄveic iepriekÅ”Äjs slodzes Ä£enerÄÅ”anas rÄ«ka iespÄju novÄrtÄjums, kÄ arÄ« jÄizvÄlas tam instanÄu veidi ar pietiekamu skaitu procesoru un atmiÅas. Å ajÄ gadÄ«jumÄ mÅ«su rÄ«ks radÄ«s lielÄku slodzi, nekÄ spÄj izturÄt Kafka klasteris. PÄc daudziem eksperimentiem mÄs nolÄmÄm trÄ«s eksemplÄrus c5.4xliels, no kuriem katrÄ darbojÄs Ä£enerators.
SalÄ«dzinoÅ”Ä novÄrtÄÅ”ana
VeiktspÄjas mÄrÄ«Å”ana ir iteratÄ«vs process, kas ietver Å”Ädus posmus:
- infrastruktÅ«ras izveidoÅ”ana (EKS klasteris, Kafka klasteris, slodzes Ä£enerÄÅ”anas rÄ«ks, kÄ arÄ« Prometheus un Grafana);
- slodzes Ä£enerÄÅ”ana uz noteiktu periodu, lai filtrÄtu nejauÅ”Äs novirzes savÄktajos darbÄ«bas rÄdÄ«tÄjos;
- brokera infrastruktÅ«ras un konfigurÄcijas pielÄgoÅ”ana, pamatojoties uz novÄrotajiem darbÄ«bas rÄdÄ«tÄjiem;
- atkÄrtojot procesu, lÄ«dz tiek sasniegts nepiecieÅ”amais Kafka klastera caurlaidspÄjas lÄ«menis. TajÄ paÅ”Ä laikÄ tai ir jÄbÅ«t konsekventi reproducÄjamai un jÄuzrÄda minimÄlas caurlaidspÄjas atŔķirÄ«bas.
NÄkamajÄ sadaÄ¼Ä ir aprakstÄ«tas darbÄ«bas, kas tika veiktas testÄÅ”anas klastera salÄ«dzinoÅ”Äs novÄrtÄÅ”anas procesÄ.
Darbarīki
Lai Ätri izvietotu bÄzes konfigurÄciju, Ä£enerÄtu slodzes un novÄrtÄtu veiktspÄju, tika izmantoti Å”Ädi rÄ«ki.
- par EKS klastera organizÄÅ”anu no Amazon c (lai savÄktu Kafkas un infrastruktÅ«ras rÄdÄ«tÄjus) un (lai vizualizÄtu Å”os rÄdÄ«tÄjus). MÄs izmantojÄm priekÅ”rocÄ«bas integrÄta Š² pakalpojumi, kas nodroÅ”ina apvienoto uzraudzÄ«bu, centralizÄtu žurnÄlu vÄkÅ”anu, ievainojamÄ«bu skenÄÅ”anu, avÄriju atkopÅ”anu, uzÅÄmuma lÄ«meÅa droŔību un daudz ko citu.
- ā rÄ«ks Kafka klastera slodzes testÄÅ”anai.
- Grafana informÄcijas paneļi Kafka metrikas un infrastruktÅ«ras vizualizÄÅ”anai: , .
- Supertubes CLI, lai vienkÄrÅ”Äkais veids, kÄ Kubernetes iestatÄ«t Kafka klasteru. Zookeeper, Kafka operators, Envoy un daudzi citi komponenti ir instalÄti un pareizi konfigurÄti, lai Kubernetes palaistu ražoÅ”anai gatavu Kafka klasteru.
- UzstÄdÄ«Å”anai supertubes CLI izmantojiet sniegtos norÄdÄ«jumus .
EKS klasteris
Sagatavojiet EKS kopu ar Ä«paÅ”iem darbinieku mezgliem c5.4xliels dažÄdÄs pieejamÄ«bas zonÄs podiem ar Kafka brokeriem, kÄ arÄ« Ä«paÅ”iem mezgliem slodzes Ä£eneratoram un uzraudzÄ«bas infrastruktÅ«rai.
banzai cluster create -f https://raw.githubusercontent.com/banzaicloud/kafka-operator/master/docs/benchmarks/infrastructure/cluster_eks_202001.jsonKad EKS klasteris ir izveidots un darbojas, iespÄjojiet tÄ integrÄto ā viÅa izvietos Prometeju un GrafÄnu klasterÄ«.
Kafka sistÄmas sastÄvdaļas
InstalÄjiet Kafka sistÄmas komponentus (Zookeeper, kafka-operator) EKS, izmantojot supertubes CLI:
supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>Kafkas klasteris
PÄc noklusÄjuma EKS izmanto EBS tipa sÄjumus gp2, tÄpÄc jums ir jÄizveido atseviŔķa krÄtuves klase, pamatojoties uz apjomiem io1 Kafka klasterim:
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
Iestatiet parametru brokeriem min.insync.replicas=3 un izvietot brokeru blokus mezglos trÄ«s dažÄdÄs pieejamÄ«bas zonÄs:
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 600TÄmas
MÄs paralÄli palaidÄm trÄ«s slodzes Ä£eneratora gadÄ«jumus. Katrs no viÅiem raksta par savu tÄmu, tas ir, mums ir vajadzÄ«gas trÄ«s tÄmas:
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
EOFKatrai tÄmai replikÄcijas koeficients ir 3 ā minimÄlÄ ieteicamÄ vÄrtÄ«ba ļoti pieejamÄm ražoÅ”anas sistÄmÄm.
Slodzes Ä£enerÄÅ”anas rÄ«ks
MÄs iedarbinÄjÄm trÄ«s slodzes Ä£eneratora kopijas (katrs rakstÄ«ja atseviÅ”Ä·Ä tÄmÄ). Slodzes Ä£eneratora blokiem ir jÄiestata mezglu afinitÄte, lai tie tiktu ieplÄnoti tikai tiem pieŔķirtajos mezglos:
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: 30Daži punkti, kas jÄÅem vÄrÄ:
- Slodzes Ä£enerators Ä£enerÄ ziÅojumus, kuru garums ir 512 baiti, un publicÄ tos Kafkai 500 ziÅojumu grupÄs.
- Izmantojot argumentu
-required-acks=allPublikÄcija tiek uzskatÄ«ta par veiksmÄ«gu, ja Kafka brokeri ir saÅÄmuÅ”i un apstiprinÄjuÅ”i visas ziÅojuma sinhronizÄtÄs kopijas. Tas nozÄ«mÄ, ka etalonÄ mÄs mÄrÄ«jÄm ne tikai lÄ«deru ziÅojumu saÅemÅ”anas Ätrumu, bet arÄ« viÅu sekotÄju ziÅojumu atkÄrtoÅ”anas Ätrumu. Å Ä« testa mÄrÄ·is nav novÄrtÄt patÄrÄtÄja lasÄ«Å”anas Ätrumu (patÄrÄtÄji) nesen saÅemtie ziÅojumi, kas joprojÄm ir palikuÅ”i OS lapas keÅ”atmiÅÄ, un to salÄ«dzinÄjums ar diskÄ saglabÄto ziÅojumu lasÄ«Å”anas Ätrumu. - Slodzes Ä£enerators paralÄli darbina 20 strÄdniekus (
-workers=20). Katram darbiniekam ir 5 ražotÄji, kuriem ir kopÄ«ga darbinieka saikne ar Kafkas kopu. RezultÄtÄ katram Ä£eneratoram ir 100 ražotÄji, un tie visi sÅ«ta ziÅojumus Kafka klasterim.
Klastera veselības uzraudzība
Kafkas klastera slodzes testÄÅ”anas laikÄ mÄs arÄ« uzraudzÄ«jÄm tÄ stÄvokli, lai nodroÅ”inÄtu, ka nav podziÅas restartÄÅ”anas, nav nesinhronizÄtu kopiju un maksimÄlo caurlaidspÄju ar minimÄlÄm svÄrstÄ«bÄm.
- Slodzes Ä£enerators raksta standarta statistiku par publicÄto ziÅojumu skaitu un kļūdu biežumu. Kļūdu Ä«patsvaram vajadzÄtu palikt nemainÄ«gam
0,00%. - , ko izvietojis kafka-operator, nodroÅ”ina informÄcijas paneli, kurÄ varam arÄ« pÄrraudzÄ«t klastera stÄvokli. Lai skatÄ«tu Å”o paneli, rÄ«kojieties Å”Ädi:
supertubes cluster cruisecontrol show -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> - ISR lÄ«menis (āsinhronizÄtoā reprodukciju skaits) sarauÅ”anÄs un izpleÅ”anÄs ir vienÄda ar 0.
MÄrÄ«jumu rezultÄti
3 brokeri, ziÅojuma lielums - 512 baiti
Ar starpsienÄm, kas vienmÄrÄ«gi sadalÄ«tas starp trim brokeriem, mÄs varÄjÄm sasniegt veiktspÄju ~500 Mb/s (apmÄram 990 tÅ«kstoÅ”i ziÅojumu sekundÄ):
JVM virtuÄlÄs maŔīnas atmiÅas patÄriÅÅ” nepÄrsniedza 2 GB:
Diska caurlaidspÄja sasniedza maksimÄlo I/O mezgla caurlaidspÄju visos trÄ«s gadÄ«jumos, kuros darbojÄs brokeri:
No datiem par atmiÅas lietojumu mezglos var secinÄt, ka sistÄmas buferizÄcija un keÅ”atmiÅa aizÅÄma ~10-15 GB:
3 brokeri, ziÅojuma lielums - 100 baiti
Samazinoties ziÅojuma lielumam, caurlaidspÄja samazinÄs par aptuveni 15ā20%: katra ziÅojuma apstrÄdei patÄrÄtais laiks to ietekmÄ. TurklÄt procesora slodze ir gandrÄ«z dubultojusies.
TÄ kÄ starpnieku mezglos joprojÄm ir neizmantoti kodoli, veiktspÄju var uzlabot, mainot Kafka konfigurÄciju. Tas nav viegls uzdevums, tÄpÄc, lai palielinÄtu caurlaidspÄju, labÄk ir strÄdÄt ar lielÄkiem ziÅojumiem.
4 brokeri, ziÅojuma lielums - 512 baiti
JÅ«s varat viegli palielinÄt Kafka klastera veiktspÄju, vienkÄrÅ”i pievienojot jaunus brokerus un saglabÄjot starpsienu lÄ«dzsvaru (tas nodroÅ”ina vienmÄrÄ«gu slodzes sadalÄ«jumu starp brokeriem). MÅ«su gadÄ«jumÄ pÄc brokera pievienoÅ”anas klastera caurlaidspÄja palielinÄjÄs lÄ«dz ~580 Mb/s (~1,1 miljons ziÅojumu sekundÄ). Izaugsme izrÄdÄ«jÄs mazÄka, nekÄ gaidÄ«ts: tas galvenokÄrt skaidrojams ar starpsienu nelÄ«dzsvarotÄ«bu (ne visi brokeri strÄdÄ savu iespÄju maksimumÄ).
JVM maŔīnas atmiÅas patÄriÅÅ” palika zem 2 GB:
Brokeru darbu ar diskdziÅiem ietekmÄja starpsienu nelÄ«dzsvarotÄ«ba:
Atzinumi
IepriekÅ” aprakstÄ«to iteratÄ«vo pieeju var paplaÅ”inÄt, lai aptvertu sarežģītÄkus scenÄrijus, kuros iesaistÄ«ti simtiem patÄrÄtÄju, pÄrdalÄ«Å”ana, slÄ«doÅ”ie atjauninÄjumi, podziÅu restartÄÅ”ana utt. Tas viss ļauj novÄrtÄt Kafkas klastera spÄju robežas dažÄdos apstÄkļos, identificÄt vÄjÄs vietas tÄ darbÄ«bÄ un atrast veidus, kÄ ar tÄm cÄ«nÄ«ties.
MÄs izstrÄdÄjÄm Supertubes, lai Ätri un viegli izvietotu klasteru, konfigurÄtu to, pievienotu/noÅemtu starpniekus un tÄmas, reaÄ£Ätu uz brÄ«dinÄjumiem un nodroÅ”inÄtu, ka Kafka kopumÄ darbojas pareizi Kubernetes. MÅ«su mÄrÄ·is ir palÄ«dzÄt jums koncentrÄties uz galveno uzdevumu (āÄ£enerÄtā un āpatÄrÄtā Kafka ziÅojumus) un atstÄt visu smago darbu Supertubes un Kafka operatora ziÅÄ.
Ja jÅ«s interesÄ Banzai Cloud tehnoloÄ£ijas un atvÄrtÄ koda projekti, abonÄjiet uzÅÄmumu plkst , vai .
PS no tulka
Lasi arÄ« mÅ«su emuÄrÄ:
- Ā«";
- Ā«";
- Ā«'.
Avots: www.habr.com