Նշում. թարգմ.Այս հոդվածում Banzai Cloud-ը ներկայացնում է օրինակ, թե ինչպես կարելի է օգտագործել իր հատուկ գործիքները՝ Kafka-ին ավելի հեշտ օգտագործելու համար Kubernetes-ում: Հետևյալ հրահանգները ցույց են տալիս, թե ինչպես կարող եք որոշել ձեր ենթակառուցվածքի օպտիմալ չափը և կարգավորել Kafka-ն՝ հասնելու պահանջվող թողունակությանը:
Apache Kafka-ն բաշխված հոսքային հարթակ է իրական ժամանակում հուսալի, մասշտաբային և բարձր արդյունավետությամբ հոսքային համակարգեր ստեղծելու համար: Նրա տպավորիչ հնարավորությունները կարող են ընդլայնվել Kubernetes-ի միջոցով: Դրա համար մենք մշակել ենք և մի գործիք, որը կոչվում է . Նրանք թույլ են տալիս գործարկել Kafka-ն Kubernetes-ում և օգտագործել դրա տարբեր հնարավորություններ, ինչպիսիք են բրոքերի կազմաձևի ճշգրտումը, մետրային վրա հիմնված մասշտաբը վերաբալանսի միջոցով, դարակի իրազեկում, «փափուկ»: (նուրբ) թարմացումների տարածում և այլն:
Փորձեք Supertubes-ը ձեր կլաստերում.
curl https://getsupertubes.sh | sh и supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>Կամ կապվեք . Կարող եք նաև կարդալ Kafka-ի որոշ հնարավորությունների մասին, որոնց հետ աշխատանքը ավտոմատացված է Supertubes-ի և Kafka օպերատորի միջոցով: Նրանց մասին բլոգում արդեն գրել ենք.
- ;
- ;
- ;
- ;
- ;
- ;
- .
Երբ դուք որոշեք տեղակայել Kafka-ի կլաստերը Kubernetes-ում, դուք, հավանաբար, կբախվեք հիմքում ընկած ենթակառուցվածքի օպտիմալ չափը որոշելու և ձեր Kafka կոնֆիգուրացիան ճշգրտելու անհրաժեշտության հետ՝ թողունակության պահանջները բավարարելու համար: Յուրաքանչյուր բրոքերի առավելագույն կատարումը որոշվում է հիմքում ընկած ենթակառուցվածքի բաղադրիչների գործունակությամբ, ինչպիսիք են հիշողությունը, պրոցեսորը, սկավառակի արագությունը, ցանցի թողունակությունը և այլն:
Իդեալում, բրոքերի կոնֆիգուրացիան պետք է լինի այնպիսին, որ ենթակառուցվածքի բոլոր տարրերն օգտագործվեն իրենց առավելագույն հնարավորություններով: Այնուամենայնիվ, իրական կյանքում այս կարգավորումը բավականին բարդ է: Ավելի հավանական է, որ օգտվողները կկարգավորեն բրոքերներին, որպեսզի առավելագույնի հասցնեն մեկ կամ երկու բաղադրիչների օգտագործումը (սկավառակ, հիշողություն կամ պրոցեսոր): Ընդհանուր առմամբ, բրոքերը ցույց է տալիս առավելագույն կատարողականություն, երբ նրա կոնֆիգուրացիան թույլ է տալիս ամենադանդաղ բաղադրիչն օգտագործել իր առավելագույն չափով: Այս կերպ մենք կարող ենք մոտավոր պատկերացում կազմել այն բեռի մասին, որը կարող է հաղթահարել մեկ բրոքեր:
Տեսականորեն մենք կարող ենք նաև գնահատել բրոքերների քանակը, որոնք անհրաժեշտ են տվյալ բեռը կարգավորելու համար: Այնուամենայնիվ, գործնականում կան տարբեր մակարդակներում կազմաձևման այնքան շատ տարբերակներ, որ շատ դժվար է (եթե ոչ անհնար) գնահատել որոշակի կոնֆիգուրացիայի հնարավոր կատարումը: Այլ կերպ ասած, շատ դժվար է պլանավորել կոնֆիգուրացիա, որը հիմնված է որոշակի կատարողականի վրա:
Supertubes-ի օգտատերերի համար մենք սովորաբար ընդունում ենք հետևյալ մոտեցումը. մենք սկսում ենք որոշ կոնֆիգուրացիաներից (ենթակառուցվածք + կարգավորումներ), այնուհետև չափում ենք դրա կատարողականը, կարգավորում բրոքերի կարգավորումները և նորից կրկնում գործընթացը: Դա տեղի է ունենում այնքան ժամանակ, մինչև ենթակառուցվածքի ամենադանդաղ բաղադրիչն ամբողջությամբ օգտագործվի:
Այս կերպ մենք ավելի հստակ պատկերացում ենք ստանում այն մասին, թե կլաստերին քանի բրոքեր է անհրաժեշտ որոշակի բեռը կարգավորելու համար (բրոքերների թիվը կախված է նաև այլ գործոններից, ինչպիսիք են հաղորդագրության կրկնօրինակների նվազագույն քանակը՝ ճկունություն ապահովելու համար, բաժանման քանակը։ առաջնորդներ և այլն): Բացի այդ, մենք պատկերացում ենք ստանում, թե որ ենթակառուցվածքի բաղադրիչներն են պահանջում ուղղահայաց մասշտաբավորում:
Այս հոդվածը կխոսի այն քայլերի մասին, որոնք մենք ձեռնարկում ենք սկզբնական կոնֆիգուրացիաներում ամենադանդաղ բաղադրիչներից առավելագույն օգուտ քաղելու և Կաֆկա կլաստերի թողունակությունը չափելու համար: Բարձր ճկուն կոնֆիգուրացիան պահանջում է առնվազն երեք գործող բրոքերներ (min.insync.replicas=3), բաշխված երեք տարբեր հասանելիության գոտիներում: Kubernetes ենթակառուցվածքը կարգավորելու, մասշտաբավորելու և վերահսկելու համար մենք օգտագործում ենք մեր սեփական կոնտեյներների կառավարման հարթակը հիբրիդային ամպերի համար. . Այն աջակցում է տեղում (մերկ մետաղ, VMware) և հինգ տեսակի ամպեր (Alibaba, AWS, Azure, Google, Oracle), ինչպես նաև դրանց ցանկացած համակցություն:
Մտքեր Կաֆկայի կլաստերի ենթակառուցվածքի և կազմաձևման վերաբերյալ
Ստորև բերված օրինակների համար մենք ընտրեցինք AWS-ը որպես ամպային մատակարար և EKS-ը՝ որպես Kubernetes բաշխում: Նմանատիպ կոնֆիգուրացիան կարող է իրականացվել օգտագործելով - Kubernetes բաշխում Banzai Cloud-ից, վավերացված CNCF-ի կողմից:
սկավառակ
Amazon-ն առաջարկում է տարբեր . Հիմնականում gp2 и io1 կան SSD կրիչներ, սակայն, բարձր թողունակություն ապահովելու համար gp2 սպառում է կուտակված վարկերը (I/O վարկեր), ուստի մենք նախընտրեցինք տեսակը io1, որն առաջարկում է հետևողական բարձր թողունակություն:
Օրինակների տեսակները
Կաֆկայի կատարումը մեծապես կախված է օպերացիոն համակարգի էջերի քեշից, ուստի մեզ անհրաժեշտ են բրոքերների (JVM) և էջի քեշի համար բավարար հիշողությամբ օրինակներ: Օրինակ c5.2x մեծ - լավ սկիզբ, քանի որ այն ունի 16 ԳԲ հիշողություն և . Դրա թերությունն այն է, որ այն ունակ է ապահովել առավելագույն արդյունավետություն միայն 30 ժամը մեկ 24 րոպեից ոչ ավելի: Եթե ձեր ծանրաբեռնվածությունը պահանջում է առավելագույն կատարողականություն ավելի երկար ժամանակահատվածում, դուք կարող եք դիտարկել օրինակների այլ տեսակներ: Դա հենց այն է, ինչ մենք արեցինք, կանգ առնելով c5.4x մեծ. Այն ապահովում է առավելագույն թողունակություն 593,75 Մբ/վ. EBS ծավալի առավելագույն թողունակությունը io1 ավելի բարձր, քան օրինակը c5.4x մեծ, ուստի ենթակառուցվածքի ամենադանդաղ տարրը, ամենայն հավանականությամբ, կլինի այս օրինակի տիպի I/O թողունակությունը (որը նույնպես պետք է հաստատեն մեր բեռնվածության թեստերը):
Сеть
Ցանցի թողունակությունը պետք է բավականաչափ մեծ լինի՝ համեմատած VM օրինակի և սկավառակի կատարման հետ, հակառակ դեպքում ցանցը դառնում է խցան: Մեր դեպքում ցանցային ինտերֆեյսը c5.4x մեծ աջակցում է մինչև 10 Գբ/վ արագություն, ինչը զգալիորեն ավելի բարձր է, քան VM օրինակի I/O թողունակությունը:
Բրոքերի տեղակայում
Բրոքերները պետք է տեղակայվեն (պլանավորված է Kubernetes-ում) հատուկ հանգույցներում՝ CPU-ի, հիշողության, ցանցի և սկավառակի ռեսուրսների այլ գործընթացների հետ մրցակցությունից խուսափելու համար:
Java տարբերակը
Տրամաբանական ընտրությունը Java 11-ն է, քանի որ այն համատեղելի է Docker-ի հետ այն առումով, որ JVM-ը ճիշտ է որոշում այն կոնտեյների համար հասանելի պրոցեսորներն ու հիշողությունը, որում աշխատում է բրոքերը: Իմանալով, որ CPU-ի սահմանները կարևոր են, JVM-ն ներքին և թափանցիկ կերպով սահմանում է GC թելերի և JIT թելերի քանակը: Մենք օգտագործեցինք Կաֆկայի կերպարը banzaicloud/kafka:2.13-2.4.0, որը ներառում է Kafka տարբերակը 2.4.0 (Scala 2.13) Java 11-ում։
Եթե ցանկանում եք ավելին իմանալ Java/JVM-ի մասին Kubernetes-ում, ստուգեք մեր հետևյալ գրառումները.
- ;
- .
Բրոքերի հիշողության կարգավորումներ
Բրոքերային հիշողության կազմաձևման երկու հիմնական ասպեկտ կա՝ կարգավորումներ JVM-ի և Kubernetes pod-ի համար: Փոդի համար սահմանված հիշողության սահմանաչափը պետք է ավելի մեծ լինի, քան կույտի առավելագույն չափը, որպեսզի JVM-ն տեղ ունենա Java մետատարածության համար, որը գտնվում է իր սեփական հիշողության մեջ և օպերացիոն համակարգի էջի քեշի համար, որն ակտիվորեն օգտագործում է Կաֆկան: Մեր թեստերում մենք գործարկեցինք Kafka բրոքերները պարամետրերով -Xmx4G -Xms2G, իսկ պատիճի համար հիշողության սահմանաչափը եղել է 10 Gi. Խնդրում ենք նկատի ունենալ, որ JVM-ի հիշողության կարգավորումները կարելի է ավտոմատ կերպով ստանալ՝ օգտագործելով -XX:MaxRAMPercentage и -X:MinRAMPercentage, հիմնված պատիճի հիշողության սահմանաչափի վրա:
Բրոքերային պրոցեսորի կարգավորումներ
Ընդհանուր առմամբ, դուք կարող եք բարելավել կատարողականությունը՝ ավելացնելով զուգահեռությունը՝ ավելացնելով Կաֆկայի կողմից օգտագործվող թելերի քանակը: Որքան շատ պրոցեսորներ հասանելի լինեն Kafka-ի համար, այնքան լավ: Մեր թեստում մենք սկսեցինք 6 պրոցեսորների սահմանաչափով և աստիճանաբար (կրկնումների միջոցով) դրանց թիվը հասցրինք 15-ի: Բացի այդ, մենք սահմանեցինք. num.network.threads=12 բրոքերի կարգավորումներում՝ ավելացնելու ցանցից տվյալներ ստացող և ուղարկող թելերի քանակը: Անմիջապես պարզելով, որ հետևորդ բրոքերները չեն կարող բավական արագ կրկնօրինակներ ստանալ, նրանք բարձրացրել են. num.replica.fetchers մինչև 4՝ բարձրացնելու արագությունը, որով հետևորդ բրոքերները կրկնում են առաջնորդների հաղորդագրությունները:
Բեռնման ստեղծման գործիք
Դուք պետք է համոզվեք, որ ընտրված բեռնվածքի գեներատորը չի սպառի իր հզորությունը մինչև Kafka կլաստերը (որը ստուգվում է) հասնի իր առավելագույն բեռնվածությանը: Այլ կերպ ասած, անհրաժեշտ է նախնական գնահատում կատարել բեռի ստեղծման գործիքի հնարավորությունները, ինչպես նաև ընտրել դրա համար օրինակների տեսակները բավարար քանակությամբ պրոցեսորներով և հիշողությամբ: Այս դեպքում մեր գործիքը կստեղծի ավելի շատ բեռ, քան Կաֆկա կլաստերը կարող է հաղթահարել: Բազմաթիվ փորձերից հետո մենք կանգ առանք երեք օրինակի վրա c5.4x մեծ, որոնցից յուրաքանչյուրում աշխատում էր գեներատոր։
Հենանիշավորում
Արդյունավետության չափումը կրկնվող գործընթաց է, որը ներառում է հետևյալ փուլերը.
- ենթակառուցվածքների ստեղծում (EKS կլաստեր, Կաֆկա կլաստեր, բեռների ստեղծման գործիք, ինչպես նաև Պրոմեթևս և Գրաֆանա);
- որոշակի ժամանակահատվածում բեռի առաջացում՝ հավաքագրված կատարողականի ցուցանիշների պատահական շեղումները զտելու համար.
- բրոքերի ենթակառուցվածքի և կոնֆիգուրացիան կարգավորելը` հիմնված դիտարկված կատարողականի ցուցանիշների վրա.
- գործընթացը կրկնելով մինչև Կաֆկա կլաստերի թողունակության պահանջվող մակարդակը ձեռք բերվի: Միևնույն ժամանակ, այն պետք է լինի հետևողականորեն վերարտադրելի և ցուցադրի թողունակության նվազագույն տատանումներ:
Հաջորդ բաժինը նկարագրում է այն քայլերը, որոնք իրականացվել են թեստային կլաստերի համեմատական գործընթացի ընթացքում:
Գործիքներ
Հետևյալ գործիքներն օգտագործվել են բազային կոնֆիգուրացիան արագ տեղակայելու, բեռներ ստեղծելու և կատարողականությունը չափելու համար.
- Amazon-ից EKS կլաստերի կազմակերպման համար ք (Կաֆկայի և ենթակառուցվածքի չափումներ հավաքելու համար) և (այս չափորոշիչները պատկերացնելու համար): Մենք օգտվեցինք ինտեգրված в ծառայություններ, որոնք ապահովում են դաշնային մոնիտորինգ, գրանցամատյանների կենտրոնացված հավաքագրում, խոցելիության սկանավորում, աղետների վերականգնում, ձեռնարկությունների մակարդակի անվտանգություն և շատ ավելին:
- — Կաֆկա կլաստերի բեռնվածության փորձարկման գործիք:
- Grafana վահանակներ Կաֆկայի չափումների և ենթակառուցվածքների պատկերացման համար. , .
- Supertubes CLI Kubernetes-ում Kafka կլաստեր ստեղծելու ամենահեշտ ձևի համար: Zookeeper-ը, Kafka-ի օպերատորը, Envoy-ը և շատ այլ բաղադրիչներ տեղադրվել և պատշաճ կերպով կազմաձևվել են Kubernetes-ում արտադրության համար պատրաստ Kafka կլաստերը գործարկելու համար:
- Տեղադրման համար գերխողովակներ CLI օգտագործեք տրված հրահանգները .
EKS կլաստեր
Պատրաստեք EKS կլաստեր՝ նվիրված աշխատող հանգույցներով c5.4x մեծ Կաֆկա բրոքերների հետ պատիճների հասանելիության տարբեր գոտիներում, ինչպես նաև բեռի գեներատորի և մոնիտորինգի ենթակառուցվածքի հատուկ հանգույցներում:
banzai cluster create -f https://raw.githubusercontent.com/banzaicloud/kafka-operator/master/docs/benchmarks/infrastructure/cluster_eks_202001.jsonԵրբ EKS կլաստերը գործարկվի և աշխատի, միացրեք դրա ինտեգրումը — նա Պրոմեթևսին և Գրաֆանային կտեղակայի կլաստերի մեջ:
Կաֆկա համակարգի բաղադրիչները
Տեղադրեք Kafka համակարգի բաղադրիչները (Zookeeper, kafka-operator) EKS-ում՝ օգտագործելով գերխողովակներ CLI:
supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>Կաֆկա կլաստեր
Լռելյայնորեն, EKS-ն օգտագործում է EBS տիպի ծավալներ gp2, այնպես որ դուք պետք է ստեղծեք առանձին պահեստային դաս՝ հիմնված ծավալների վրա io1 Կաֆկա կլաստերի համար.
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
Սահմանեք պարամետրը բրոքերների համար min.insync.replicas=3 և տեղադրեք բրոքերային պատյաններ հանգույցների վրա երեք տարբեր հասանելիության գոտիներում.
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 600Թեմաներ
Մենք զուգահեռաբար գործարկեցինք բեռնվածքի գեներատորի երեք օրինակ: Նրանցից յուրաքանչյուրը գրում է իր թեմային, այսինքն՝ մեզ ընդհանուր առմամբ երեք թեմա է պետք.
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
EOFՅուրաքանչյուր թեմայի համար կրկնօրինակման գործակիցը 3 է՝ առաջարկվող նվազագույն արժեքը բարձր հասանելի արտադրական համակարգերի համար:
Բեռնման ստեղծման գործիք
Մենք գործարկեցինք բեռի գեներատորի երեք օրինակ (յուրաքանչյուրը գրել է առանձին թեմայում): Բեռի գեներատորի պատյանների համար դուք պետք է կարգավորեք հանգույցների մերձեցումը, որպեսզի դրանք պլանավորվեն միայն իրենց համար հատկացված հանգույցներում.
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Պետք է նշել մի քանի կետ.
- Բեռի գեներատորը ստեղծում է 512 բայթ երկարությամբ հաղորդագրություններ և դրանք հրապարակում Կաֆկային 500 հաղորդագրությունների խմբաքանակով:
- Օգտագործելով փաստարկ
-required-acks=allՀրապարակումը համարվում է հաջողված, երբ հաղորդագրության բոլոր սինխրոնացված կրկնօրինակները ստացվում և հաստատվում են Կաֆկա բրոքերների կողմից: Սա նշանակում է, որ հենանիշում մենք չափել ենք ոչ միայն հաղորդագրություններ ստացող առաջնորդների արագությունը, այլև նրանց հետևորդների՝ հաղորդագրությունները կրկնօրինակելու արագությունը: Այս թեստի նպատակը սպառողի ընթերցանության արագությունը գնահատելը չէ (սպառողներ) վերջերս ստացված հաղորդագրություններ, որոնք դեռ մնում են ՕՀ-ի էջի քեշում, և դրա համեմատությունը սկավառակի վրա պահվող հաղորդագրությունների ընթերցման արագության հետ: - Բեռի գեներատորը զուգահեռ աշխատում է 20 աշխատողի (
-workers=20). Յուրաքանչյուր աշխատող պարունակում է 5 արտադրող, որոնք կիսում են աշխատողի կապը Կաֆկա կլաստերի հետ: Արդյունքում յուրաքանչյուր գեներատոր ունի 100 արտադրող, և նրանք բոլորն էլ հաղորդագրություններ են ուղարկում Կաֆկա կլաստերին։
Կլաստերի առողջության մոնիտորինգ
Kafka կլաստերի բեռնվածության փորձարկման ընթացքում մենք նաև վերահսկել ենք նրա առողջությունը՝ համոզվելու համար, որ չկան pod վերագործարկումներ, չհամաժամեցված կրկնօրինակներ և առավելագույն թողունակություն՝ նվազագույն տատանումներով:
- Բեռի գեներատորը ստանդարտ վիճակագրություն է գրում հրապարակված հաղորդագրությունների քանակի և սխալի մակարդակի մասին: Սխալների մակարդակը պետք է մնա նույնը
0,00%. - , որը տեղադրված է kafka-օպերատորի կողմից, ապահովում է վահանակ, որտեղ մենք կարող ենք նաև վերահսկել կլաստերի վիճակը: Այս վահանակը դիտելու համար կատարեք.
supertubes cluster cruisecontrol show -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> - ISR մակարդակը («համաժամեցված» կրկնօրինակների թիվը) նեղանալը և ընդլայնումը հավասար են 0-ի:
Չափման արդյունքները
3 բրոքեր, հաղորդագրության չափը՝ 512 բայթ
Երեք բրոքերների վրա հավասարաչափ բաշխված միջնորմներով մենք կարողացանք հասնել կատարողականի ~500 Մբ/վ (մոտավորապես 990 հազար հաղորդագրություն վայրկյանում):
JVM վիրտուալ մեքենայի հիշողության սպառումը չի գերազանցել 2 ԳԲ.
Սկավառակի թողունակությունը հասել է I/O հանգույցի առավելագույն թողունակությանը բոլոր երեք օրինակներում, որոնց վրա աշխատում էին բրոքերները.
Հանգույցների կողմից հիշողության օգտագործման վերաբերյալ տվյալներից հետևում է, որ համակարգի բուֆերացումը և քեշավորումը տևել են ~ 10-15 ԳԲ:
3 բրոքեր, հաղորդագրության չափը՝ 100 բայթ
Քանի որ հաղորդագրության չափը նվազում է, թողունակությունը նվազում է մոտավորապես 15-20%-ով. յուրաքանչյուր հաղորդագրության մշակման վրա ծախսված ժամանակը ազդում է դրա վրա: Բացի այդ, պրոցեսորի ծանրաբեռնվածությունը գրեթե կրկնապատկվել է:
Քանի որ բրոքերային հանգույցները դեռևս ունեն չօգտագործված միջուկներ, կատարումը կարող է բարելավվել՝ փոխելով Kafka-ի կոնֆիգուրացիան: Սա հեշտ գործ չէ, ուստի թողունակությունը մեծացնելու համար ավելի լավ է աշխատել ավելի մեծ հաղորդագրությունների հետ:
4 բրոքեր, հաղորդագրության չափը՝ 512 բայթ
Դուք կարող եք հեշտությամբ բարձրացնել Kafka կլաստերի կատարողականը` պարզապես ավելացնելով նոր բրոքերներ և պահպանելով միջնորմների հավասարակշռությունը (սա ապահովում է բեռի հավասարաչափ բաշխումը բրոքերների միջև): Մեր դեպքում, բրոքեր ավելացնելուց հետո, կլաստերի թողունակությունը մեծացավ մինչև ~580 Մբ/վ (~ 1,1 միլիոն հաղորդագրություն վայրկյանում). Աճը սպասվածից քիչ է ստացվել. դա հիմնականում բացատրվում է միջնորմների անհավասարակշռությամբ (ոչ բոլոր բրոքերներն են աշխատում իրենց հնարավորությունների գագաթնակետին):
JVM մեքենայի հիշողության սպառումը մնացել է 2 ԳԲ-ից ցածր.
Սկավառակներ ունեցող բրոքերների աշխատանքի վրա ազդել է միջնորմների անհավասարակշռությունը.
Արդյունքները
Վերևում ներկայացված կրկնվող մոտեցումը կարող է ընդլայնվել՝ ներառելով հարյուրավոր սպառողների ներգրավված ավելի բարդ սցենարներ, վերաբաշխում, թարմացումներ, պատի վերագործարկում և այլն: Այս ամենը մեզ թույլ է տալիս գնահատել Կաֆկա կլաստերի հնարավորությունների սահմանները տարբեր պայմաններում, բացահայտել նրա գործունեության խոչընդոտները և գտնել դրանց դեմ պայքարելու ուղիներ:
Մենք նախագծել ենք Supertubes-ը, որպեսզի արագ և հեշտությամբ տեղակայի կլաստերը, կազմաձևի այն, ավելացնի/հեռացնի բրոքերներ և թեմաներ, արձագանքի ծանուցումներին և ապահովի, որ Kafka-ն, ընդհանուր առմամբ, ճիշտ է աշխատում Kubernetes-ում: Մեր նպատակն է օգնել ձեզ կենտրոնանալ հիմնական առաջադրանքի վրա («ստեղծել» և «սպառել» Կաֆկայի հաղորդագրությունները) և ամբողջ ծանր աշխատանքը թողնել Supertubes-ին և Kafka օպերատորին:
Եթե դուք հետաքրքրված եք Banzai Cloud տեխնոլոգիաներով և բաց կոդով նախագծերով, բաժանորդագրվեք ընկերությանը հետևյալ հասցեով , կամ .
PS թարգմանչից
Կարդացեք նաև մեր բլոգում.
- «";
- «";
- «.
Source: www.habr.com