Jegyzet. ford.: Ebben a cikkben a Banzai Cloud megoszt egy példát arra, hogyan lehet egyéni eszközeivel megkönnyíteni a Kafka használatát a Kubernetesen belül. A következő utasítások bemutatják, hogyan határozhatja meg az infrastruktúra optimális méretét, és hogyan konfigurálhatja magát a Kafkát a szükséges átviteli sebesség eléréséhez.
Az Apache Kafka egy elosztott streaming platform megbízható, méretezhető és nagy teljesítményű valós idejű streaming rendszerek létrehozására. Lenyűgöző képességei a Kubernetes segítségével bővíthetők. Erre fejlesztettük ki és egy olyan szerszámot, amit . Lehetővé teszik a Kafka futtatását Kubernetesen, és különféle funkcióinak használatát, például a brókerkonfiguráció finomhangolását, a metrika alapú méretezést újrakiegyenlítéssel, a rack tudatosítást, a „soft” funkciót. (kecses) frissítések bevezetése stb.
Próbáld ki a Supertubes-t a klaszteredben:
curl https://getsupertubes.sh | sh и supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>Vagy lépjen kapcsolatba . Olvashatunk a Kafka egyes képességeiről is, amelyek munkáját a Supertubes és a Kafka operátor segítségével automatizálják. A blogon már írtunk róluk:
- ;
- ;
- ;
- ;
- ;
- ;
- .
Amikor úgy dönt, hogy Kafka-fürtöt telepít a Kubernetes rendszerre, valószínűleg azzal a kihívással kell szembenéznie, hogy meghatározza az alapul szolgáló infrastruktúra optimális méretét, és finomhangolnia kell a Kafka-konfigurációt, hogy megfeleljen az átviteli követelményeknek. Az egyes brókerek maximális teljesítményét a mögöttes infrastruktúra-összetevők teljesítménye határozza meg, mint például a memória, a processzor, a lemez sebessége, a hálózati sávszélesség stb.
Ideális esetben a közvetítő konfigurációjának olyannak kell lennie, hogy az összes infrastruktúra-elemet maximálisan kihasználják. A való életben azonban ez a beállítás meglehetősen bonyolult. Valószínűbb, hogy a felhasználók úgy konfigurálják a közvetítőket, hogy maximalizálják egy vagy két összetevő (lemez, memória vagy processzor) használatát. Általánosságban elmondható, hogy a bróker akkor mutat maximális teljesítményt, ha konfigurációja lehetővé teszi a leglassabb komponens teljes körű használatát. Így hozzávetőleges képet kaphatunk arról, hogy egy bróker mekkora terhelést tud elviselni.
Elméletileg azt is meg tudjuk becsülni, hogy egy adott teher kezeléséhez hány brókerre van szükség. A gyakorlatban azonban olyan sok konfigurációs lehetőség létezik különböző szinteken, hogy nagyon nehéz (ha nem lehetetlen) értékelni egy adott konfiguráció potenciális teljesítményét. Más szavakkal, nagyon nehéz egy adott teljesítmény alapján konfigurációt megtervezni.
A Supertubes felhasználók esetében általában a következő megközelítést alkalmazzuk: kezdünk valamilyen konfigurációval (infrastruktúra + beállítások), majd mérjük a teljesítményét, módosítjuk a bróker beállításait, és ismételjük meg a folyamatot. Ez addig történik, amíg az infrastruktúra leglassabb összetevőjét teljesen kihasználják.
Így tisztább képet kapunk arról, hogy egy fürtnek hány közvetítőre van szüksége egy bizonyos terhelés kezeléséhez (a közvetítők száma más tényezőktől is függ, mint például a rugalmasságot biztosító üzenetreplikák minimális száma, a partíciók száma vezetők stb.). Emellett betekintést nyerünk abba is, hogy mely infrastruktúra-összetevők igényelnek vertikális skálázást.
Ez a cikk azokról a lépésekről szól, amelyeket megteszünk annak érdekében, hogy a legtöbbet kihozzuk a kezdeti konfigurációk leglassabb összetevőiből, és mérjük a Kafka-fürt teljesítményét. A rendkívül rugalmas konfigurációhoz legalább három futó bróker szükséges (min.insync.replicas=3), három különböző akadálymentesítési zónában van elosztva. A Kubernetes infrastruktúra konfigurálásához, méretezéséhez és figyeléséhez saját konténerkezelő platformunkat használjuk a hibrid felhők számára - . Támogatja a helyszíni (csupasz fém, VMware) és ötféle felhőt (Alibaba, AWS, Azure, Google, Oracle), valamint ezek bármilyen kombinációját.
Gondolatok a Kafka-fürt infrastruktúrájáról és konfigurációjáról
Az alábbi példákban az AWS-t választottuk felhőszolgáltatóként, az EKS-t pedig Kubernetes-terjesztésként. Hasonló konfiguráció valósítható meg a segítségével - Kubernetes disztribúció a Banzai Cloudtól, a CNCF által hitelesített.
korong
Az Amazon különféle ajánlatokat kínál . A magban gp2 и io1 Vannak azonban SSD-meghajtók, amelyek biztosítják a nagy átviteli sebességet gp2 felhalmozott krediteket fogyaszt (I/O kredit), ezért a típust részesítettük előnyben io1, amely állandóan nagy átviteli sebességet kínál.
Példánytípusok
A Kafka teljesítménye nagymértékben függ az operációs rendszer oldalgyorsítótárától, ezért olyan példányokra van szükségünk, amelyek elegendő memóriával rendelkeznek a közvetítők (JVM) és az oldalgyorsítótár számára. Példa c5.2xnagy - jó kezdet, hiszen 16 GB memóriával és . Hátránya, hogy 30 óránként legfeljebb 24 percig képes maximális teljesítményt nyújtani. Ha a munkaterhelés csúcsteljesítményt igényel hosszabb időn keresztül, érdemes lehet más példánytípusokat is megfontolni. Pontosan ezt tettük, megálltunk c5.4xnagy. Maximális áteresztőképességet biztosít 593,75 Mb/s. Egy EBS-kötet maximális áteresztőképessége io1 magasabb, mint a példány c5.4xnagy, így az infrastruktúra leglassabb eleme valószínűleg ennek a példánytípusnak az I/O átvitele lesz (amit terhelési tesztjeink is megerősítenek).
Hálózat
A hálózati átviteli sebességnek elég nagynak kell lennie a virtuálisgép-példány és a lemez teljesítményéhez képest, különben a hálózat szűk keresztmetszetté válik. Esetünkben a hálózati interfész c5.4xnagy akár 10 Gb/s sebességet is támogat, ami lényegesen magasabb, mint egy virtuálisgép-példány I/O átviteli sebessége.
Bróker telepítése
A közvetítőket (Kubernetesben ütemezve) dedikált csomópontokra kell telepíteni, hogy elkerüljék a versenyt más folyamatokkal a CPU-, memória-, hálózati és lemezerőforrásokért.
Java verzió
A logikus választás a Java 11, mivel kompatibilis a Dockerrel abban az értelemben, hogy a JVM helyesen határozza meg a tároló számára elérhető processzorokat és memóriát, amelyben a közvetítő fut. Tudva, hogy a CPU-korlátok fontosak, a JVM belsőleg és transzparensen beállítja a GC-szálak és a JIT-szálak számát. A Kafka-képet használtuk banzaicloud/kafka:2.13-2.4.0, amely tartalmazza a Kafka 2.4.0-s verzióját (Scala 2.13) Java 11-en.
Ha többet szeretne megtudni a Kubernetes Java/JVM-ről, tekintse meg a következő bejegyzéseinket:
- ;
- .
A bróker memória beállításai
A közvetítő memória konfigurálásának két kulcsfontosságú szempontja van: a JVM és a Kubernetes pod beállításai. A pod-ra beállított memóriakorlátnak nagyobbnak kell lennie a maximális kupacméretnél, hogy a JVM-nek legyen helye a saját memóriájában található Java metatérnek és a Kafka által aktívan használt operációs rendszer oldalgyorsítótárának. Tesztjeink során Kafka brókereket indítottunk el paraméterekkel -Xmx4G -Xms2G, és a pod memóriakorlátja ez volt 10 Gi. Kérjük, vegye figyelembe, hogy a JVM memóriabeállításai automatikusan lekérhetők a használatával -XX:MaxRAMPercentage и -X:MinRAMPercentage, a pod memóriakorlátja alapján.
A bróker processzor beállításai
Általánosságban elmondható, hogy a Kafka által használt szálak számának növelésével javíthatja a teljesítményt. Minél több processzor érhető el a Kafka számára, annál jobb. Tesztünkben 6 processzoros limittel indultunk, és fokozatosan (iterációkkal) 15-re emeltük a számukat. num.network.threads=12 a közvetítő beállításaiban, hogy növelje a hálózatról adatokat fogadó és elküldő szálak számát. Azonnal rájöttek, hogy a követő brókerek nem tudják elég gyorsan megkapni a replikákat, ezért emeltek num.replica.fetchers 4-re, hogy növelje a sebességet, amellyel a követő brókerek replikálják a vezetőktől érkező üzeneteket.
Load Generation Tool
Gondoskodnia kell arról, hogy a kiválasztott terhelésgenerátor kapacitása ne fogyjon ki, mielőtt a Kafka-fürt (amely benchmarking alatt áll) eléri a maximális terhelést. Más szóval, előzetesen fel kell mérni a terhelésgeneráló eszköz képességeit, és ki kell választani a megfelelő számú processzorral és memóriával rendelkező példánytípusokat. Ebben az esetben az eszközünk több terhelést termel, mint amennyit a Kafka-fürt elbír. Sok kísérlet után három példány mellett döntöttünk c5.4xnagy, amelyek mindegyikében működött egy generátor.
Benchmarking
A teljesítménymérés egy iteratív folyamat, amely a következő szakaszokat tartalmazza:
- infrastruktúra felállítása (EKS klaszter, Kafka klaszter, terhelésgeneráló eszköz, valamint Prometheus és Grafana);
- terhelés generálása egy bizonyos időszakra az összegyűjtött teljesítménymutatók véletlenszerű eltéréseinek szűrésére;
- a bróker infrastruktúrájának és konfigurációjának módosítása a megfigyelt teljesítménymutatók alapján;
- a folyamatot addig ismételjük, amíg el nem érjük a Kafka-klaszter átviteli sebességének szükséges szintjét. Ugyanakkor következetesen reprodukálhatónak kell lennie, és minimális eltéréseket kell mutatnia az átviteli sebességben.
A következő szakasz a tesztfürt-benchmarking folyamat során végrehajtott lépéseket ismerteti.
Tools
A következő eszközöket használták az alapkonfiguráció gyors üzembe helyezéséhez, a terhelések generálásához és a teljesítmény méréséhez:
- EKS klaszter megszervezéséért az Amazonból c (Kafka és infrastruktúra mérőszámok gyűjtésére) és (e mérőszámok megjelenítéséhez). Kihasználtuk integrált в szolgáltatások, amelyek egyesített felügyeletet, központosított naplógyűjtést, sebezhetőségi vizsgálatot, vész-helyreállítást, vállalati szintű biztonságot és még sok mást biztosítanak.
- — Kafka-klaszter terhelési tesztelésének eszköze.
- Grafana irányítópultok a Kafka-metrikák és infrastruktúra megjelenítéséhez: , .
- Supertubes CLI a Kafka-fürt létrehozásának legegyszerűbb módja a Kubernetes rendszeren. A Zookeeper, a Kafka operátor, az Envoy és sok más összetevő telepítve van, és megfelelően konfigurálva van a gyártásra kész Kafka-fürt futtatásához a Kubernetesen.
- Telepíteni supertubes CLI használja a mellékelt utasításokat .
EKS klaszter
Készítsen EKS-fürtöt dedikált dolgozói csomópontokkal c5.4xnagy különböző rendelkezésre állási zónákban a Kafka-brókerekkel ellátott podokhoz, valamint dedikált csomópontokhoz a terhelésgenerátorhoz és a felügyeleti infrastruktúrához.
banzai cluster create -f https://raw.githubusercontent.com/banzaicloud/kafka-operator/master/docs/benchmarks/infrastructure/cluster_eks_202001.jsonMiután az EKS-fürt üzembe helyezte és fut, engedélyezze az integrálását - Prometheust és Grafanát egy klaszterbe fogja telepíteni.
Kafka rendszerelemek
Telepítse a Kafka rendszerkomponenseket (Zookeeper, kafka-operator) az EKS-be a szupertubes CLI használatával:
supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>Kafka klaszter
Alapértelmezés szerint az EKS a típusú EBS-köteteket használja gp2, ezért külön tárolási osztályt kell létrehoznia a kötetek alapján io1 Kafka-klaszter esetében:
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
Állítsa be a paramétert a brókerekhez min.insync.replicas=3 és telepítse a bróker podokat három különböző rendelkezésre állási zóna csomópontjaira:
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émák
Három terhelésgenerátor példányt futtattunk párhuzamosan. Mindegyik a saját témájába ír, vagyis összesen három témára van szükségünk:
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
EOFAz egyes témaköröknél a replikációs tényező 3 – a minimális ajánlott érték magas rendelkezésre állású éles rendszerek esetén.
Load Generation Tool
A terhelésgenerátor három példányát indítottuk el (mindegyik külön témakörben írt). A terhelésgenerátor podoknál be kell állítania a csomópont-affinitást úgy, hogy azok csak a számukra kijelölt csomópontokon legyenek ütemezve:
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: 30Néhány megjegyzés:
- A betöltésgenerátor 512 bájt hosszúságú üzeneteket generál, és 500 üzenetből álló kötegekben teszi közzé Kafkának.
- Érv használatával
-required-acks=allA közzététel akkor tekinthető sikeresnek, ha az üzenet összes szinkronizált replikáját megkapják és a Kafka brókerek megerősítik. Ez azt jelenti, hogy a benchmarkban nem csak a vezetők üzenetfogadási sebességét mértük, hanem azt is, hogy követőik mennyire replikálják az üzeneteket. Ennek a tesztnek nem célja a fogyasztói olvasási sebesség értékelése (fogyasztók) a közelmúltban kapott üzenetek, amelyek még mindig az operációs rendszer oldal gyorsítótárában maradnak, és ennek összehasonlítása a lemezen tárolt üzenetek olvasási sebességével. - A terhelésgenerátor 20 dolgozót működtet párhuzamosan (
-workers=20). Minden dolgozó 5 termelőt tartalmaz, akik osztoznak a dolgozó kapcsolatában a Kafka-klaszterrel. Ennek eredményeként minden generátornak 100 gyártója van, és mindannyian üzenetet küldenek a Kafka-klaszternek.
A klaszter állapotának figyelése
A Kafka-fürt terhelési tesztelése során annak állapotát is felügyeltük, hogy biztosítsuk, ne legyenek pod újraindítások, ne legyenek szinkronizálatlan replikák, és a maximális átviteli sebesség minimális ingadozásokkal:
- A terhelésgenerátor szabványos statisztikákat ír a közzétett üzenetek számáról és a hibaarányról. A hibaaránynak változatlannak kell maradnia
0,00%. - A kafka-operator által telepített műszerfalat biztosít, ahol a fürt állapotát is figyelemmel kísérhetjük. A panel megtekintéséhez tegye a következőket:
supertubes cluster cruisecontrol show -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> - ISR szint (az „in-Sync” replikák száma) zsugorodása és tágulása 0.
Mérési eredmények
3 bróker, üzenet mérete - 512 bájt
A három bróker között egyenletesen elosztott partíciókkal teljesítményt tudtunk elérni ~500 Mb/s (kb. 990 ezer üzenet másodpercenként):
A JVM virtuális gép memóriafogyasztása nem haladta meg a 2 GB-ot:
A lemez átviteli sebessége elérte a maximális I/O csomópont átviteli sebességét mindhárom példányon, amelyen a közvetítők futottak:
A csomópontok memóriahasználati adataiból az következik, hogy a rendszer pufferelése és gyorsítótárazása ~10-15 GB-ot vett igénybe:
3 bróker, üzenet mérete - 100 bájt
Az üzenet méretének csökkenésével az átviteli sebesség körülbelül 15-20%-kal csökken: az egyes üzenetek feldolgozására fordított idő befolyásolja azt. Ráadásul a processzorterhelés majdnem megduplázódott.
Mivel a brókercsomópontoknak még mindig vannak használaton kívüli magjai, a teljesítmény a Kafka-konfiguráció módosításával javítható. Ez nem könnyű feladat, ezért az átviteli sebesség növelése érdekében jobb, ha nagyobb üzenetekkel dolgozunk.
4 bróker, üzenet mérete - 512 bájt
Könnyen növelheti a Kafka-fürt teljesítményét új brókerek hozzáadásával és a partíciók egyensúlyának fenntartásával (ez biztosítja, hogy a terhelés egyenletesen oszlik el a közvetítők között). Esetünkben egy bróker hozzáadása után a klaszter átviteli sebessége -ra nőtt ~580 Mb/s (~1,1 millió üzenet másodpercenként). A növekedés a vártnál kisebbnek bizonyult: ez elsősorban a partíciók kiegyensúlyozatlanságával magyarázható (nem minden bróker dolgozik a képességei csúcsán).
A JVM gép memóriafogyasztása 2 GB alatt maradt:
A meghajtókkal foglalkozó brókerek munkáját befolyásolta a partíciók kiegyensúlyozatlansága:
Álláspontja
A fent bemutatott iteratív megközelítés kiterjeszthető bonyolultabb, több száz fogyasztót érintő forgatókönyvekre, újraparticionálásra, gördülő frissítésekre, pod újraindításokra stb. Mindez lehetővé teszi, hogy felmérjük a Kafka-klaszter képességeinek korlátait különböző körülmények között, azonosítsuk működésének szűk keresztmetszeteit, és megoldásokat találjunk ezek leküzdésére.
A Supertubes-t úgy terveztük, hogy gyorsan és egyszerűen telepítsen egy fürtöt, konfigurálja azt, közvetítőket és témákat adjon hozzá/eltávolítson, válaszoljon a riasztásokra, és biztosítsa, hogy a Kafka általában megfelelően működjön a Kubernetes rendszeren. Célunk, hogy segítsünk a fő feladatra koncentrálni (Kafka üzenetek „generálása” és „felhasználása”), és a kemény munkát a Supertubesre és a Kafka operátorra bízzuk.
Ha érdeklik a Banzai Cloud technológiák és a nyílt forráskódú projektek, iratkozzon fel a cégre a címen , vagy .
PS a fordítótól
Olvassa el blogunkon is:
- «";
- «";
- «".
Forrás: will.com