Nota. transl.: In questu articulu, Banzai Cloud sparte un esempiu di cumu i so strumenti persunalizati ponu esse aduprati per fà Kafka più faciule d'utilizà in Kubernetes. L'istruzzioni seguenti illustranu cumu pudete determinà a dimensione ottima di a vostra infrastruttura è cunfigurà Kafka stessu per ottene u throughput necessariu.
Apache Kafka hè una piattaforma di streaming distribuita per creà sistemi di streaming in tempu reale affidabili, scalabili è di altu rendiment. E so capacità impressiunanti ponu esse allargate cù Kubernetes. Per questu avemu sviluppatu è un strumentu chjamatu . Permettenu di eseguisce Kafka nantu à Kubernetes è aduprà e so diverse funzioni, cum'è a fine-tuning di a cunfigurazione di u broker, a scala basata in metrica cù rebalancing, a cuscenza di rack, "soft" (grazioso) lanciari l'aghjurnamenti, etc.
Pruvate Supertubes in u vostru cluster:
curl https://getsupertubes.sh | sh и supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>O cuntattate . Pudete ancu leghje alcune di e capacità di Kafka, u travagliu cù quale hè automatizatu cù l'operatore Supertubes è Kafka. Avemu digià scrittu annantu à elli nantu à u blog:
- ;
- ;
- ;
- ;
- ;
- ;
- .
Quandu decide di implementà un cluster Kafka in Kubernetes, probabilmente sarete affruntatu cù a sfida di determinà a dimensione ottima di l'infrastruttura sottostante è a necessità di sintonizà a vostra cunfigurazione Kafka per risponde à i requisiti di throughput. U rendimentu massimu di ogni broker hè determinatu da a prestazione di i cumpunenti di l'infrastruttura sottostanti, cum'è memoria, processore, velocità di discu, larghezza di banda di rete, etc.
Ideale, a cunfigurazione di u broker deve esse cusì chì tutti l'elementi di l'infrastruttura sò usati à e so capacità massimi. Tuttavia, in a vita reale, sta configurazione hè abbastanza cumplessa. Hè più prubabile chì l'utilizatori cunfigurà i brokers per maximizà l'usu di unu o dui cumpunenti (discu, memoria o processore). In generale, un broker mostra u massimu rendimentu quandu a so cunfigurazione permette à u cumpunente più lento per esse usatu à a so misura massima. Questu modu pudemu avè una idea approssimativa di a carica chì un broker pò trattà.
Teoricamente, pudemu ancu stimà u numeru di brokers necessariu per trattà una carica data. In ogni casu, in pratica, ci sò tanti opzioni di cunfigurazione à diversi livelli chì hè assai difficiule (se ùn hè micca impussibile) di valutà a prestazione potenziale di una cunfigurazione particulare. In altri palori, hè assai difficiuli di pianificà una cunfigurazione basatu annantu à qualchì prestazione.
Per l'utilizatori di Supertubes, di solitu pigliamu l'approcciu seguente: cuminciamu cù una certa cunfigurazione (infrastruttura + paràmetri), poi misurà a so prestazione, aghjustà i paràmetri di u broker è ripetite u prucessu di novu. Questu succede finu à chì u cumpunente più lento di l'infrastruttura hè cumplettamente utilizatu.
In questu modu, avemu una idea più chjara di quanti brokers un cluster hà bisognu à trattà una certa carica (u numeru di brokers dipende ancu da altri fattori, cum'è u numeru minimu di rèpliche di messagi per assicurà a resilienza, u numeru di partizioni). capi, ecc.). Inoltre, avemu una visione di quali cumpunenti di l'infrastruttura necessitanu scala verticale.
Questu articulu parlerà di i passi chì facemu per ottene u più di i cumpunenti più lenti in cunfigurazioni iniziali è misurà u throughput di un cluster Kafka. Una cunfigurazione altamente resistente richiede almenu trè broker in esecuzione (min.insync.replicas=3), distribuite in trè zone di accessibilità diverse. Per cunfigurà, scala è monitorizà l'infrastruttura Kubernetes, usemu a nostra propria piattaforma di gestione di container per i nuvuli hibridi - . Supporta on-premise (bare metal, VMware) è cinque tippi di nuvole (Alibaba, AWS, Azure, Google, Oracle), è ancu qualsiasi cumminazione di elli.
Pensieri nantu à l'infrastruttura è a cunfigurazione di u cluster Kafka
Per l'esempii sottu, avemu sceltu AWS cum'è u fornitore di nuvola è EKS cum'è a distribuzione Kubernetes. Una cunfigurazione simili pò esse implementata usendu - Distribuzione Kubernetes da Banzai Cloud, certificata da CNCF.
u discu
Amazon offre diverse . À u core gp2 и io1 Ci sò unità SSD, però, per assicurà un altu throughput gp2 cunsuma i crediti accumulati (crediti I/O), cusì avemu preferitu u tipu io1, chì offre un altu throughput consistente.
Tipi di istanza
U rendiment di Kafka hè assai dipendente da a cache di a pagina di u sistema operatore, cusì avemu bisognu di istanze cù memoria abbastanza per i brokers (JVM) è a cache di pagina. Istanza c5.2xlarge - un bonu principiu, postu chì hà 16 GB di memoria è . U so svantaghju hè chì hè solu capace di furnisce un rendimentu massimu per micca più di 30 minuti ogni 24 ore. Se a vostra carica di travagliu richiede un rendimentu di punta per un periudu di tempu più longu, pudete vulete cunsiderà altri tipi di istanza. Hè esattamente ciò chì avemu fattu, fermendu c5.4xlarge. Fornisce u massimu throughput in 593,75 Mb/s. Massimu throughput di un voluminu EBS io1 più altu ch'è l'istanza c5.4xlarge, cusì l'elementu più lento di l'infrastruttura hè prubabile di esse u throughput I / O di stu tipu d'istanza (chì i nostri testi di carica anu da cunfirmà ancu).
Network
U flussu di a rete deve esse abbastanza grande cumparatu cù u rendiment di l'istanza VM è u discu, altrimenti a reta diventa un collu di buttiglia. In u nostru casu, l'interfaccia di a reta c5.4xlarge supporta velocità di finu à 10 Gb/s, chì hè significativamente più altu ch'è u throughput I/O di una istanza VM.
Impiegazione di broker
I brokers anu da esse implementati (scheduled in Kubernetes) à i nodi dedicati per evità a cumpetizione cù altri prucessi per CPU, memoria, rete è risorse di discu.
versione Java
L'scelta logica hè Java 11 perchè hè cumpatibile cù Docker in u sensu chì a JVM determina currettamente i processori è a memoria dispunibuli à u cuntinuu in quale u broker hè in esecuzione. Sapendu chì i limiti di CPU sò impurtanti, a JVM internu è trasparenti stabilisce u numeru di fili GC è fili JIT. Avemu usatu l'imaghjini di Kafka banzaicloud/kafka:2.13-2.4.0, chì include a versione Kafka 2.4.0 (Scala 2.13) in Java 11.
Se vulete sapè più nantu à Java / JVM nantu à Kubernetes, verificate i nostri post:
- ;
- .
Paràmetri di memoria di u broker
Ci hè dui aspetti chjave per cunfigurà a memoria di u broker: paràmetri per a JVM è per u pod Kubernetes. U limitu di memoria stabilitu per un pod deve esse più grande di a dimensione massima di l'heap in modu chì a JVM hà spaziu per u metaspace Java chì reside in a so memoria è per a cache di pagina di u sistema operatore chì Kafka usa attivamente. In i nostri testi avemu lanciatu Kafka brokers cù paràmetri -Xmx4G -Xms2G, è u limitu di memoria per u pod era 10 Gi. Per piacè nutate chì i paràmetri di memoria per a JVM ponu esse ottenuti automaticamente usendu -XX:MaxRAMPercentage и -X:MinRAMPercentage, basatu annantu à u limitu di memoria per u pod.
Paràmetri di u processatore di broker
In generale, pudete migliurà u rendiment aumentendu u parallelismu aumentendu u numeru di fili utilizati da Kafka. U più prucessori dispunibili per Kafka, u megliu. In a nostra prova, avemu principiatu cù un limitu di processori 6 è gradualmente (per mezu di iterazioni) hà elevatu u so numeru à 15. Inoltre, avemu stabilitu num.network.threads=12 in i paràmetri di u broker per aumentà u nùmeru di filamenti chì ricevenu dati da a reta è mandà. Immediatamente scopre chì i brokers di seguitori ùn puderanu micca riceve rèpliche abbastanza rapidamente, anu risuscitatu num.replica.fetchers à 4 per aumentà a velocità à quale i broker di seguitori replicanu i missaghji da i capi.
Strumentu di generazione di carica
Avete da assicurà chì u generatore di carica selezziunatu ùn esce micca di capacità prima chì u cluster Kafka (chì hè benchmarked) righjunghji a so carica massima. In altri palori, hè necessariu di fà una valutazione prelimiunale di e capacità di l'uttellu di generazione di carica, è ancu selezziunà i tipi di istanza per questu cun un numeru abbastanza di processori è memoria. In questu casu, u nostru strumentu pruducerà più carica chì u cluster Kafka pò trattà. Dopu parechji esperimenti, avemu stallatu nantu à trè copie c5.4xlarge, ognuna di e quali avianu un generatore in funzione.
Benchmarking
A misurazione di u rendiment hè un prucessu iterativu chì include e seguenti tappe:
- a creazione di infrastruttura (Cluster EKS, cluster Kafka, strumentu di generazione di carica, è ancu Prometheus è Grafana);
- generà una carica per un certu periodu per filtrà e deviazioni aleatorii in l'indicatori di rendiment raccolti;
- aghjustà l'infrastruttura è a cunfigurazione di u broker basatu annantu à l'indicatori di rendiment osservati;
- ripetendu u prucessu finu à chì u livellu necessariu di u flussu di u cluster Kafka hè ottenutu. À u listessu tempu, deve esse riproducibile constantemente è dimustrà variazioni minime in u throughput.
A sezione dopu descrive i passi chì sò stati realizati durante u prucessu di benchmarking di u cluster di teste.
Ferramenti
I seguenti strumenti sò stati utilizati per implementà rapidamente una cunfigurazione di basa, generà carichi, è misurà u rendiment:
- per urganizà un cluster EKS da Amazon c (per cullà Kafka è metrica di l'infrastruttura) è (per visualizà queste metriche). Avemu apprufittatu integratu в servizii chì furnisce un monitoraghju federatu, cullezzione di log centralizata, scanning di vulnerabilità, ricuperazione di disastru, sicurezza di qualità di l'impresa è assai di più.
- - un strumentu per a prova di carica di un cluster Kafka.
- Dashboards Grafana per visualizà e metriche è l'infrastruttura Kafka: , .
- Supertubes CLI per u modu più faciule per stabilisce un cluster Kafka in Kubernetes. Zookeeper, l'operatore Kafka, Envoy è parechji altri cumpunenti sò stallati è cunfigurati bè per eseguisce un cluster Kafka prontu per a produzzione in Kubernetes.
- Per a stallazione supertubi CLI aduprate l'istruzzioni furnite .
cluster EKS
Preparate un cluster EKS cù nodi di travagliu dedicati c5.4xlarge in diverse zone di dispunibilità per pods cù i brokers Kafka, è ancu nodi dedicati per u generatore di carica è l'infrastruttura di monitoraghju.
banzai cluster create -f https://raw.githubusercontent.com/banzaicloud/kafka-operator/master/docs/benchmarks/infrastructure/cluster_eks_202001.jsonUna volta chì u cluster EKS hè in funzione, attivate u so integratu - hà da implementà Prometheus è Grafana in un cluster.
Cumpunenti di u sistema Kafka
Installa i cumpunenti di u sistema Kafka (Zookeeper, kafka-operator) in EKS usendu supertubes CLI:
supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>cluster Kafka
Per automaticamente, EKS usa volumi EBS di tipu gp2, cusì avete bisognu di creà una classa di almacenamiento separata basatu nantu à volumi io1 per u cluster 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
Definite u paràmetru per i brokers min.insync.replicas=3 è implementà pods di broker in nodi in trè zone di dispunibilità diverse:
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 600Temi
Avemu eseguitu trè istanze di generatore di carica in parallelu. Ognunu di elli scrive à u so propiu tema, vale à dì, avemu bisognu di trè temi in totale:
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
EOFPer ogni tema, u fattore di replicazione hè 3 - u valore minimu cunsigliatu per i sistemi di produzzione altamente dispunibili.
Strumentu di generazione di carica
Avemu lanciatu trè copie di u generatore di carica (ognuna hà scrittu in un tema separatu). Per i pod di generatori di carica, avete bisognu di stabilisce l'affinità di i nodi in modu chì sò pianificati solu nantu à i nodi assignati per elli:
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: 30Uni pochi punti da nutà:
- U generatore di carica genera missaghji di 512 bytes di lunghezza è li publica à Kafka in batchs di 500 missaghji.
- Utilizà un argumentu
-required-acks=allA publicazione hè cunsiderata successu quandu tutte e rèpliche sincronizate di u messagiu sò ricevuti è cunfirmati da i brokers Kafka. Questu significa chì in u benchmark avemu misuratu micca solu a rapidità di i capi chì ricevenu missaghji, ma ancu i so seguitori chì replicanu i missaghji. U scopu di sta prova ùn hè micca di valutà a velocità di lettura di u cunsumadore (consumatori) Recentemente ricevutu missaghji chì restanu sempre in a cache di a pagina di l'OS, è u so paragone cù a velocità di lettura di i missaghji almacenati in u discu. - U generatore di carica gestisce 20 travagliadori in parallelu (
-workers=20). Ogni travagliadore cuntene 5 pruduttori chì sparte a cunnessione di u travagliu cù u cluster Kafka. In u risultatu, ogni generatore hà 100 pruduttori, è tutti mandanu messagi à u cluster Kafka.
Monitorà a salute di u cluster
Durante a prova di carica di u cluster Kafka, avemu ancu monitoratu a so salute per assicurà chì ùn ci era micca riavvia di pod, nisuna replica fora di sincronia, è u massimu throughput cù fluttuazioni minime:
- U generatore di carica scrive statistiche standard nantu à u numeru di messagi publicati è a rata di errore. A rata d'errore deve esse u listessu
0,00%. - , implementatu da kafka-operator, furnisce un dashboard induve pudemu ancu monitorà u statu di u cluster. Per vede stu pannellu fate:
supertubes cluster cruisecontrol show -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> - Livellu ISR (numeru di repliche "in-sync") shrink è espansione sò uguali à 0.
I risultati di a misura
3 brokers, dimensione di u messagiu - 512 bytes
Cù partizioni distribuite uniformemente in trè brokers, avemu pussutu ottene u rendiment ~ 500 Mb/s (circa 990 mila missaghji per seconda):
U cunsumu di memoria di a macchina virtuale JVM ùn hà micca più di 2 GB:
U flussu di u discu hà righjuntu u massimu di u nodu I/O in tutti i trè casi in cui i brokers eranu in esecuzione:
Da i dati nantu à l'utilizazione di memoria da i nodi, segue chì u buffering di u sistema è a caching hà pigliatu ~ 10-15 GB:
3 brokers, dimensione di u messagiu - 100 bytes
Quandu a dimensione di u messagiu diminuisce, u throughput scende da circa 15-20%: u tempu passatu à processà ogni missaghju l'affetta. Inoltre, a carica di u processatore hè quasi radduppiata.
Siccomu i nodi di broker anu ancu core inutilizati, u rendiment pò esse migliuratu cambiendu a cunfigurazione Kafka. Questu ùn hè micca un compitu faciule, cusì per aumentà u throughput hè megliu travaglià cù missaghji più grande.
4 brokers, dimensione di u messagiu - 512 bytes
Pudete facilmente aumentà a prestazione di un cluster Kafka solu aghjunghjendu novi brokers è mantene un equilibriu di partizioni (questu assicura una distribuzione uniforme di carica trà i brokers). In u nostru casu, dopu avè aghjustatu un broker, u flussu di u cluster hà aumentatu à ~ 580 Mb/s (~ 1,1 milioni di missaghji per seconda). A crescita hè diventata menu di l'espertu: questu hè principalmente per u squilibrio di partizioni (micca tutti i brokers travaglianu à u piccu di e so capacità).
U cunsumu di memoria di a macchina JVM resta sottu à 2 GB:
U travagliu di i brokers cù unità hè stata affettata da u sbilanciamentu di partizioni:
scuperti
L'approcciu iterativu presentatu sopra pò esse allargatu per copre scenarii più cumplessi chì implicanu centinaie di cunsumatori, ripartizioni, aghjurnamenti rolling, riavvia di pod, etc. Tuttu chistu ci permette di valutà i limiti di e capacità di u cluster Kafka in diverse cundizioni, identificà i buttiglii in u so funziunamentu è truvà modi per cummattiri.
Avemu cuncepitu Supertubes per implementà rapidamente è facilmente un cluster, cunfigurà lu, aghjunghje / sguassate brokers è temi, risponde à alerti, è assicurà chì Kafka in generale funziona bè in Kubernetes. U nostru scopu hè di aiutà vi cuncentrazione nantu à u compitu principale ("generate" è "cunsumà" missaghji Kafka), è lasciate tuttu u travagliu duru à Supertubes è l'operatore Kafka.
Sè site interessatu à e tecnulugia Banzai Cloud è i prughjetti Open Source, abbonate à a cumpagnia à , o .
PS da u traduttore
Leghjite puru nant'à u nostru blog:
- «";
- «";
- «».
Source: www.habr.com