Shën. përk.: Në këtë artikull, kompania Banzai Cloud ndan një shembull të përdorimit të utiliteteve të saj speciale për të lehtësuar operimin e Kafka në Kubernetes. Udhëzimet e dhëna ilustrojnë se si mund të përcaktohet madhësia optimale e infrastrukturës dhe si të konfigurohet Kafka për të arrijtur kapacitetin e kërkuar.
Apache Kafka është një platformë e shpërndarë për transmetimin e të dhënave, e cila mundëson krijimin e sistemeve të besueshme, të shkallëzueshme dhe me performancë të lartë në kohë reale. Mundësitë e saj frymëzuese mund të zgjerohet me ndihmën e Kubernetes. Për këtë qëllim, ne zhvilluam dhe një mjet të quajtur . Këto lejojnë ekzekutimin e Kafka në Kubernetes dhe përdorimin e funksioneve të saj të ndryshme, të tilla si optimizimi i konfigurimit të brokerit, shkallëzimi mbi baza metrikash me ribalancim, vetëdijesimi për kapacitetet e pajisjeve, "shkëputja e butë" (graceful) e azhurnimeve etj.
Provoni Supertubes në klasterin tuaj:
curl https://getsupertubes.sh | sh dhe supertubes install -a --no-democluster --kubeconfigOse kontaktoni . Mund të lexoni gjithashtu për disa mundësi të Kafka, me të cilat punimi është automatizuar përmes Supertubes dhe Kafka operatorit. Ne kemi shkruar tashmë për to në blogun tonë:
- ;
- ;
- ;
- ;
- ;
- ;
- .
Duke vendosur të ngrisni një grup Kafka në Kubernetes, padyshim që do të përballeni me problemin e përcaktimit të madhësisë optimale të infrastrukturës themelore dhe nevojën për të nxjerrë përfundime të detajizuara të konfiguracionit të Kafka për të përmbushur kërkesat për kapacitetin. Përformanca maksimale e çdo broker-i përcaktohet nga performanca e komponenteve të infrastrukturës në bazë të tij, siç janë memoria, procesori, shpejtësia e disku, kapaciteti i rrjetit etj.
Idealja, konfigurimi i brokerit duhet të jetë i tillë që të gjitha elementët e infrastrukturës të përdoren në maksimumin e mundësive të tyre. Megjithatë, në jetën reale, një konfigurim i tillë është mjaft i komplikuar. Më shumë gjasa, përdoruesit do të konfigurojnë brokerat në mënyrë që të maksimizojnë përdorimin e një apo dy komponenteve (diskut, memorie ose procesor). Në përgjithësi, brokeri tregon performancën maksimale kur konfigurimi i tij lejon që komponenti më i ngadalshëm të angazhohet 'në mënyrë të plotë'. Kështu, ne mund të marrim një ide të përafërt mbi ngarkesën që një broker është në gjendje të përballojë.
Teorikisht, ne gjithashtu mund të vlerësojmë numrin e brokerave të nevojshëm për të përballuar një ngarkesë të caktuar. Megjithatë, në praktikë, opsionet e konfigurimit në nivele të ndryshme janë aq të shumta saqë vlerësimi i performancës potenciale të një konfigurimi është shumë i vështirë (nëse jo i pamundur). Me fjalë të tjera, është shumë e vështirë të planifikosh një konfigurim duke u bazuar në një performancë të caktuar.
Për përdoruesit e Supertubes, zakonisht përdorim qasjen e mëposhtme: fillojmë me një konfigurim të caktuar (infrastrukturë + cilësime), pastaj matim performancën e saj, korrektojmë cilësimet e brokerit dhe e përsërisim procesin përsëri. Kjo ndodh derisa potenciali i komponentit më të ngadalshëm të infrastrukturës të jetë plotësisht i angazhuar.
Me këtë mënyrë ne marrim një pamje më të qartë se sa brokerë i nevojiten klasterit për të përballuar një ngarkesë të caktuar (numri i brokerëve gjithashtu varet nga faktorë të tjerë, si numri minimal i replikave të mesazheve për të siguruar qëndrueshmëri, numri i liderëve të partition-it etj.). Përveç kësaj, ne marrim një ide se për cilin komponent infrastrukture është e dëshirueshme shkallëzimi vertikal.
NĂ« kĂ«tĂ« artikull do tĂ« flitet pĂ«r hapat qĂ« ne ndĂ«rmarrim pĂ«r tĂ« "shkĂ«lqyer gjithçka" nga komponentĂ«t mĂ« tĂ« ngadalshĂ«m nĂ« konfigurimet fillestare dhe pĂ«r tĂ« matur kapacitetin kalues tĂ« klasterit Kafka. NjĂ« konfigurim me qĂ«ndrueshmĂ«ri tĂ« lartĂ« kĂ«rkon tĂ« paktĂ«n tre brokerĂ« qĂ« funksionojnĂ« (min.insync.replicas=3), tĂ« shpĂ«rndara nĂ« tre zona tĂ« ndryshme disponueshmĂ«rie. PĂ«r konfigurimin, shkallĂ«zimin dhe monitorimin e infrastrukturĂ«s Kubernetes, ne pĂ«rdorim platformĂ«n tonĂ« tĂ« menaxhimit tĂ« kontejnerĂ«ve pĂ«r mjete hibride â . Ajo mbĂ«shtet on-premise (bare metal, VMware) dhe pesĂ« lloje tĂ« mjeteve (Alibaba, AWS, Azure, Google, Oracle), si dhe çdo kombinim tĂ« tyre.
Mendime mbi infrastrukturën dhe konfigurimin e klasterit Kafka
PĂ«r shembujt e dhĂ«nĂ« mĂ« poshtĂ«, ne zgjodhĂ«m AWS si ofruesin e shĂ«rbimeve tĂ« mjeteve dhe EKS si shpĂ«rndarjen e Kubernetes. NjĂ« konfigurim tĂ« ngjashĂ«m mund tĂ« realizohet me â shpĂ«rndarja e Kubernetes nga Banzai Cloud, e certifikuar nga CNCF.
Disku
Amazon ofron lloje të ndryshme . Në thelb, gp2 dhe io1 janë bazuar në disqe SSD, megjithatë për të siguruar një kapacitet të lartë kalimi, gp2 ai konsumon kredite I/O (kredite I/O), prandaj ne preferuam një tip io1, i cili ofron një kalim të qëndrueshëm të lartë.
Llojet e instancave
Performanca e Kafka varet shumĂ« nga cache-i i faqeve tĂ« sistemit operativ, prandaj na nevojiten instanca me mjaft memorie pĂ«r brokerĂ«t (JVM) dhe cache-in e faqeve. Instanca c5.2xlarge â njĂ« fillim i mirĂ«, pasi ka 16 GB memorie dhe . Disavantazhi i tij Ă«shtĂ« se ai mund tĂ« ofrojĂ« performancĂ« maksimale pĂ«r maksimumi 30 minuta çdo 24 orĂ«. NĂ«se ngarkesa e punĂ«s kĂ«rkon performancĂ« maksimale pĂ«r njĂ« periudhĂ« mĂ« tĂ« gjatĂ«, Ă«shtĂ« e nevojshme tĂ« shqyrtohen lloje tĂ« tjera instancash. Ne e bĂ«mĂ« shtĂ«pinĂ« tonĂ«, duke u ndalur nĂ« c5.4xlarge. Ai ofron njĂ« kapacitet maksimal prej 593.75 MB/s. Kapaciteti maksimal i volumit EBS io1 Ă«shtĂ« mĂ« i lartĂ« se ai i instancĂ«s c5.4xlarge, kĂ«shtu qĂ« element dhe mĂ« i ngadalshĂ«m nĂ« infrastrukturĂ«, duket se Ă«shtĂ« kapaciteti I/O i kĂ«tij lloji instance (çka gjithashtu duhet ta konfirmojnĂ« rezultatet tona tĂ« testeve tĂ« ngarkesĂ«s).
RRjeti
Kapaciteti i rrjetit duhet të jetë mjaft i madh në krahasim me performancën e instancës VM dhe diskut, në të kundërt do të shndërrohet në një pikë të ngushtë. Në rastin tonë, ndërfaqja rrjetit c5.4xlarge mbështet një shpejtësi deri në 10 GB/s, që është dukshëm më e lartë se kapaciteti I/O i instancës VM.
Zhvillimi i brokerëve
Brokers duhet të shtrihen (planifikohen në Kubernetes) në node të dedikuar, për të shmangur konkurrencën me procese të tjera për burimet e procesorëve, memories, rrjetit dhe disqeve.
Versioni i Java
Zgjedhja logjike është Java 11, pasi ajo është e përputhshme me Docker, në kuptimin që JVM e përcakton saktësisht procesorët dhe memorien e disponueshme për kontejnerin në të cilin funksionon brokeri. Duke e ditur se kufizimet e procesorëve janë të rëndësishme, JVM brenda saj dhe në mënyrë transparente përcakton numrin e telave të GC dhe telave të kompilatorit JIT. Ne përdorëm imazhin Kafka banzaicloud/kafka:2.13-2.4.0, duke përfshirë versionin Kafka 2.4.0 (Scala 2.13) në Java 11.
Nëse dëshironi të mësoni më shumë rreth Java/JVM në Kubernetes, ju lutemi shikoni publikimet tona të mëposhtme:
- ;
- .
Cilësimet e memories së brokerit
Ka janë dy aspekte kyçe në konfigurimin e memorjes së brokerit: konfigurimet për JVM dhe për pod'in Kubernetes. Kufiri i memories, i vendosur për pod'in, duhet të jetë më i madh se madhësia maksimale e heap-it, në mënyrë që JVM të ketë hapësirë për metapësirën Java, e cila ndodhet në memorien e saj, dhe për cache-in e faqeve të sistemit operativ, të cilin Kafka e përdor aktivisht. Ne në testet tona kemi ekzekutuar brokerët Kafka me parametrat -Xmx4G -Xms2G, ndërsa kufiri i memories për pod'in ishte 10 Gi. Vini re se konfigurimet e memories për JVM mund të merren automatikisht me anë të -XX:MaxRAMPercentage dhe -X:MinRAMPercentage, në përputhje me kufirin e memories për pod'in.
Konfigurimet e procesorit të brokerit
Në përgjithësi, është e mundur të rritet performanca duke rritur paralelizmën përmes rritjes së numrit të thesareve që përdoren nga Kafka. Sa më shumë procesorë të jenë të disponueshëm për Kafka, aq më mirë. Në testin tonë kemi filluar me një kufi prej 6 procesorësh dhe gradualisht (në iteracione) e rritëm numrin e tyre në 15. Për më tepër, kemi vendosur num.network.threads=12 në cilësimet e brokerit, për të rritur numrin e rrjedhave që marrin të dhëna nga rrjeti dhe i dërgojnë ato. Menjëherë duke e kuptuar se brokerët ndiqës nuk mund të marrin replika mjaftueshëm shpejt, rritëm num.replica.fetchers në 4, për të përshpejtuar shpejtësinë me të cilën brokerët ndiqës replikonin mesazhet nga liderët.
Mjeti i gjenerimit të ngarkesës
Duhet të sigurohemi që potenciali i gjeneratorit të zgjedhur të ngarkesës të mos shterrojë para se klusteri Kafka (benchmark-u i të cilit po kryhet) të arrijë ngarkesën maksimale. Në fjalë të tjera, është e nevojshme të bëhet një vlerësim paraprak i kapaciteteve të mjetit të gjenerimit të ngarkesës, si dhe të zgjidhen llojet e instancave me një numër të mjaftueshëm procesorësh dhe memories. Në këtë rast, mjeti ynë do të prodhojë më shumë ngarkesë sesa klusteri Kafka është në gjendje të përballojë. Pas shumë eksperimenteve, ne ndaluam në tre instanca c5.4xlarge, në secilën prej të cilave ishte aktivizuar një gjenerator.
Benchmarkimi
Matja e performancës është një proces iterativ që përfshin fazat e mëposhtme:
- konfigurimi i infrastrukturës (klasteri EKS, klasteri Kafka, mjeti i gjenerimit të ngarkesës, si dhe Prometheus dhe Grafana);
- gjenerimi i ngarkesës për një periudhë të caktuar për të filtruar deviacione të rastit në shënimet e performancës të mbledhura;
- përshtatja e infrastrukturës dhe konfigurimit të brokerit në bazë të metrikeve të performancës së vëzhguara;
- përsëritja e procesit derisa të arrihet niveli i kërkuar i kapacitetit të klasterit Kafka. Ky duhet të jetë stabilisht i riprodhueshëm dhe të tregojë variacione minimale të kapacitetit.
Në seksionin e ardhshëm përshkruhen hapat që janë ndjekur gjatë procesit të benchmark-ut të klasterit për prova.
Mjetet
Për implementimin e shpejtë të konfigurimit themelor, gjenerimin e ngarkesës dhe matjen e performancës janë përdorur mjetet e mëposhtme:
- për organizimin e klasterit EKS nga Amazon me (për mbledhjen e metrikeve të Kafka dhe infrastrukturës) dhe (për vizualizimin e këtyre metrikeve). Ne kemi përdorur të integruar. në shërbimeve që ofrojnë monitorim federativ, grumbullim të centralizuar të logjeve, skanimin e dobësive, rikuperimin pas dështimeve, sigurinë e nivelit korporativ dhe shumë të tjera.
- â njĂ« mjet pĂ«r testimin e ngarkesĂ«s sĂ« klasterit Kafka.
- Grafana panels për vizualizimin e metrikeve të Kafka dhe infrastrukturës: , .
- Supertubes CLI për konfigurimin sa më të thjeshtë të klasterit Kafka në Kubernetes. Zookeeper, Kafka operator, Envoy dhe shumë komponentë të tjerë janë të instaluar dhe të konfiguruar siç duhet për të drejtuar një klaster Kafka të gatshëm për prodhim në Kubernetes.
- Për instalimin supertubes CLI përdorni udhëzimet e dhëna .
Klaster EKS
PĂ«rgatitni klasterin EKS me nodet e dedikuara c5.4xlarge nĂ« zona tĂ« shumta tĂ« disponueshmĂ«risĂ« pĂ«r podâĂ«t me brokerĂ«t Kafka, si dhe nodet e veçuara pĂ«r gjeneratorin e ngarkesĂ«s dhe infrastrukturĂ«n e monitorimit.
banzai cluster create -f https://raw.githubusercontent.com/banzaicloud/kafka-operator/master/docs/benchmarks/infrastructure/cluster_eks_202001.jsonKur klasteri EKS tĂ« jetĂ« nĂ« punĂ«, aktivizoni â do tĂ« shpĂ«rndajĂ« Prometheus dhe Grafana nĂ« klaster.
Pjesët sistemike të Kafka
Instaloni pjesët sistemike të Kafka (Zookeeper, kafka-operator) në EKS duke përdorur supertubes CLI:
supertubes install -a --no-democluster --kubeconfigKlusteri Kafka
Me default, në EKS përdoren volume EBS të tipit gp2, prandaj është e nevojshme të krijohet një klasë e veçantë magazinimi të bazuar në volume io1 për klusterin 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 Vendosni parametrin për brokerët min.insync.replicas=3 dhe shpërndani pod-të e brokerëve në node në tri zona të ndryshme të aksesit:
supertubes cluster create -n kafka --kubeconfig -f https://raw.githubusercontent.com/banzaicloud/kafka-operator/master/docs/benchmarks/infrastructure/kafka_202001_3brokers.yaml --wait --timeout 600Temat
Ne kemi ekzekutuar paralelisht tre instanca të gjeneratorit të ngarkesës. Secili prej tyre shkruan në temën e tij, që do të thotë se na nevojiten gjithsej tri tema:
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
EOFPĂ«r çdo temĂ«, faktori i replikimit Ă«shtĂ« 3 â vlera minimale e rekomanduar pĂ«r sistemet production me disponueshmĂ«ri tĂ« lartĂ«.
Mjeti i gjenerimit të ngarkesës
Ne ekzekutuam tre instanca të gjeneratorit të ngarkesës (secili shkruante në një temë të veçantë). Për pod'ët e gjeneratorit të ngarkesës është e nevojshme të specifikohet afiniteti i nyjave, në mënyrë që ato të planifikohen vetëm në nyjat e dedikuara për ta:
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: 30Disa pika që duhet të keni parasysh:
- Generatori i ngarkesës gjeneron mesazhe me gjatësi 512 byte dhe i publikon ato në Kafka në grupe prej 500 mesazhesh.
- Dhe me argumentin
-required-acks=allPublikimi konsiderohet i suksesshĂ«m kur tĂ« gjitha replikat e sinkronizuara tĂ« mesazheve janĂ« marrĂ« dhe konfirmuar nga brokerat Kafka. Kjo do tĂ« thotĂ« se nĂ« benchmarkun matĂ«m jo vetĂ«m shpejtĂ«sinĂ« e liderĂ«ve qĂ« marrin mesazhe, por edhe tĂ« pasuesve tĂ« tyre qĂ« riplikojnĂ« mesazhet. Testi i kĂ«tij testi nuk pĂ«rfshin vlerĂ«simin e shpejtĂ«sisĂ« sĂ« leximit nga konsumatorĂ«t. (konsumatorĂ«t) e mesazheve tĂ« sapopranuara, tĂ« cilat ende qĂ«ndrojnĂ« nĂ« cache-nĂ« e sistemit tĂ« operimit, dhe krahasimi i saj me shpejtĂ«sinĂ« e leximit tĂ« mesazheve qĂ« ruhen nĂ« disk. - Gjenaratori i ngarkesĂ«s niste paralelisht 20 workerâĂ« (
-workers=20). Ădo worker pĂ«rmban 5 prodhues, tĂ« cilĂ«t e pĂ«rdorin bashkĂ« vetĂ«m lidhjen e worker-it me klustĂ«rin Kafka. KĂ«shtu, çdo gjenarator numĂ«ron 100 prodhues, dhe tĂ« gjithĂ« ata dĂ«rgojnĂ« mesazhe nĂ« klustĂ«rin Kafka.
Vëzhgimi i gjendjes së klustërin
Gjatë testimit të ngarkesës së klustërin Kafka, ne gjithashtu ndoqëm shëndetin e saj, për t'u siguruar që nuk kishte rindizje pod-esh, replika të asinkronizuara dhe kapacitet maksimal me variacione minimale:
- Generatori i ngarkes jep statistikën standarde për numrin e mesazheve të publikuara dhe nivelin e gabimeve. Përqindja e gabimeve duhet të mbetet në vlerën
0,00%. - , i vendosur nga kafka-operator, ofron një panel monitorimi ku gjithashtu mund të vëzhgojmë gjendjen e klasterit. Për të parë këtë panel, ekzekutoni:
supertubes cluster cruisecontrol show -n kafka --kubeconfig - Niveli ISR (numri i replikave «in-sync») shrink dhe expansion është 0.
Rezultatet e matjeve
3 brokerĂ«, madhĂ«sia e mesazheve â 512 byte
Me partitionet, të shpërndara në mënyrë të barabartë mes tre brokerëve, arritëm një performancë ~500 Mb/s (afërsisht 990 mijë mesazhe në sekondë):
Konsumimi i memories nga makina virtuale JVM nuk e kaloi 2 Gb:
Kapaciteti i diskut arriti kapacitetin maksimal I/O të nodit në të tre instancat ku ishin duke funksionuar brokerët:
Nga të dhënat mbi përdorimin e memories nga nodet, rezulton se sistemet e buferimit dhe keqkësimi zënë ~10-15 Gb:
3 brokerĂ«, madhĂ«sia e mesazheve â 100 byte
Me uljen e madhësisë së mesazheve, kapaciteti bie rreth 15-20%: ndikon koha e shpenzuar për përpunimin e çdo mesazhi. Për më tepër, ngarkesa në procesor është rritur pothuajse dyfish.
Duke qenë se në nyjat e brokerëve ende ka bërthama të papërdorura, performanca mund të përmirësohet përmes ndryshimit të konfigurimit të Kafka-s. Kjo është një detyrë e vështirë, prandaj për të rritur kapacitetin është më mirë të punoni me mesazhe më të mëdha.
4 brokerĂ«, madhĂ«sia e mesazheve â 512 byte
ĂshtĂ« e lehtĂ« tĂ« rritet performanca e klustrit Kafka thjesht duke shtuar brokerĂ« tĂ« rinj dhe duke ruajtur balansin e partition-eve (kjo siguron shpĂ«rndarje tĂ« barabartĂ« tĂ« ngarkesĂ«s midis brokerĂ«ve). NĂ« rastin tonĂ«, pas shtimit tĂ« njĂ« brokeri, kapaciteti i klustrit u rrit deri nĂ« ~580 Mb/s (~1.1 milion mesazhe nĂ« sekondĂ«). Rritja ishte mĂ« e vogĂ«l se sa pritej: kryesisht kjo shpjegohet nga disbalancat e partition-eve (jo tĂ« gjithĂ« brokerĂ«t punojnĂ« nĂ« kapacitetin e plotĂ«).
Konsumimi i memories nga makina JVM mbeti nën 2 Gb:
Disbalancat e partition-eve ndikuan në funksionimin e brokerëve me ruajtës:
PĂ«rfundimet
Qashtu i paraqitur qasje iteruese mund të zgjerohet për të përfshirë skenarë më të komplikuar, që përfshijnë qindra konsumatorë, riparticionim, azhurnime të instaluara, rindezje pod-esh etj. Të gjitha këto na lejojnë të vlerësojmë kufijtë e mundësive të klasterit Kafka në kushte të ndryshme, të identifikojmë ngushticat në funksionimin e tij dhe të gjejmë mënyra për t'u përballur me to.
Ne kemi krijuar Supertubes pĂ«r vendosjen, konfigurimin, shtimin/zhvendosjen e brokerĂ«ve dhe temave nĂ« mĂ«nyrĂ« tĂ« shpejtĂ« dhe tĂ« lehtĂ«, reagimin ndaj alarmeve dhe pĂ«r tĂ« siguruar qĂ« Kafka tĂ« funksionojĂ« siç duhet nĂ« Kubernetes nĂ« pĂ«rgjithĂ«si. QĂ«llimi ynĂ« Ă«shtĂ« tĂ« ndihmojmĂ« nĂ« pĂ«rqendrimin nĂ« detyrĂ«n kryesore (âtĂ« gjeneroshâ dhe âtĂ« konsumoshâ mesazhe Kafka), duke ia lĂ«nĂ« tĂ« gjitha punĂ«t e rĂ«ndĂ«sishme Supertubes dhe operatorit Kafka.
Nëse jeni të interesuar për teknologjitë dhe projektet Open Source të Banzai Cloud, ndiqni kompaninë në , ose .
P.S. nga përkthyesi
Lexoni gjithashtu në blogun tonë:
- «»;
- «»;
- «».
Burimi: habr.com
