සටහන. පරිවර්තනය.: මෙම ලිපියේ, Banzai Cloud විසින් Kubernetes තුළ Kafka භාවිතා කිරීම පහසු කිරීමට එහි අභිරුචි මෙවලම් භාවිතා කළ හැකි ආකාරය පිළිබඳ උදාහරණයක් බෙදා ගනී. පහත උපදෙස් මඟින් ඔබට ඔබේ යටිතල ව්යුහයේ ප්රශස්ත ප්රමාණය තීරණය කළ හැකි ආකාරය සහ අවශ්ය ප්රතිදානය සාක්ෂාත් කර ගැනීම සඳහා Kafka වින්යාස කළ හැකි ආකාරය නිරූපණය කරයි.
Apache Kafka යනු විශ්වසනීය, පරිමාණය කළ හැකි සහ ඉහළ කාර්යසාධනයක් සහිත තත්ය කාලීන ප්රවාහ පද්ධති නිර්මාණය කිරීම සඳහා බෙදා හරින ලද ප්රවාහ වේදිකාවකි. එහි ආකර්ෂණීය හැකියාවන් Kubernetes භාවිතයෙන් දීර්ඝ කළ හැක. මේ සඳහා අපි සංවර්ධනය කර ඇත
ඔබේ පොකුරේ Supertubes උත්සාහ කරන්න:
curl https://getsupertubes.sh | sh и supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>
නැතිනම් සම්බන්ධ කරගන්න
ලියකියවිලි . සුපර් ටියුබ් සහ කෆ්කා ක්රියාකරු භාවිතයෙන් ස්වයංක්රීයව ක්රියාත්මක වන කෆ්කාගේ සමහර හැකියාවන් ගැන ඔබට කියවිය හැකිය. අපි ඔවුන් ගැන දැනටමත් බ්ලොග් අඩවියේ ලියා ඇත:
අපොයි නෑ! Kubernetes සඳහා තවත් කෆ්කා ක්රියාකරුවෙක් ;ප්රොමිතියස් ප්රමිතික මත පදනම්ව කෆ්කා අධීක්ෂණය සහ ක්රියාත්මක කරන්න ;Kubernetes පිළිබඳ Kafka රාක්ක දැනුවත් කිරීම ;Apache Kafka Istio හරහා ධාවනය කිරීම - මිණුම් ලකුණ ;කෆ්කා ක්රියාකරු සමඟ පරිශීලක සත්යාපනය කර පාලිත පොකුරු වෙත ප්රවේශ වීම ;Kubernetes මත Kafka rolling upgrade සහ dynamic configuration ;කෆ්කා සඳහා එන්වෝයි ප්රොටෝකෝල පෙරහන, දැල් කර ඇත .
ඔබ Kubernetes මත Kafka පොකුරක් යෙදවීමට තීරණය කරන විට, ඔබට යටින් පවතින යටිතල ව්යුහයේ ප්රශස්ත ප්රමාණය තීරණය කිරීමේ අභියෝගයට මුහුණ දීමට සිදුවනු ඇත. මතකය, ප්රොසෙසරය, තැටි වේගය, ජාල කලාප පළල යනාදී යටිතල පහසුකම් සංරචකවල ක්රියාකාරීත්වය අනුව එක් එක් තැරැව්කරුගේ උපරිම ක්රියාකාරිත්වය තීරණය වේ.
ඉතා මැනවින්, තැරැව්කාර වින්යාසය සියලු යටිතල පහසුකම් මූලද්රව්ය ඒවායේ උපරිම හැකියාවන් සඳහා භාවිතා කළ යුතුය. කෙසේ වෙතත්, සැබෑ ජීවිතයේ දී මෙම සැකසුම තරමක් සංකීර්ණ වේ. සංරචක එකක් හෝ දෙකක් (තැටිය, මතකය හෝ ප්රොසෙසරය) උපරිම ලෙස භාවිතා කිරීම සඳහා පරිශීලකයින් තැරැව්කරුවන් වින්යාස කිරීමට ඉඩ ඇත. සාමාන්යයෙන් කථා කරන විට, එහි වින්යාසය මන්දගාමී සංරචකය එහි උපරිම ප්රමාණයට භාවිතා කිරීමට ඉඩ දෙන විට තැරැව්කරුවෙකු උපරිම කාර්ය සාධනය පෙන්වයි. මේ ආකාරයෙන් අපට එක් තැරැව්කරුවෙකුට හැසිරවිය හැකි බර පිළිබඳ දළ අදහසක් ලබා ගත හැකිය.
න්යායාත්මකව, දී ඇති බරක් හැසිරවීමට අවශ්ය තැරැව්කරුවන් සංඛ්යාව ද අපට තක්සේරු කළ හැකිය. කෙසේ වෙතත්, ප්රායෝගිකව විවිධ මට්ටම්වල බොහෝ වින්යාස විකල්ප ඇති අතර, විශේෂිත වින්යාසයක විභව කාර්ය සාධනය තක්සේරු කිරීම ඉතා අපහසුය (නොහැකි නම්). වෙනත් වචන වලින් කිවහොත්, යම් කාර්ය සාධනයක් මත පදනම්ව වින්යාසයක් සැලසුම් කිරීම ඉතා අපහසුය.
Supertubes භාවිතා කරන්නන් සඳහා, අපි සාමාන්යයෙන් පහත ප්රවේශය ගනිමු: අපි යම් වින්යාසයකින් (යටිතල පහසුකම් + සිටුවම්) පටන් ගනිමු, ඉන්පසු එහි ක්රියාකාරිත්වය මැනීම, තැරැව්කාර සැකසුම් සකස් කර නැවත ක්රියාවලිය නැවත කරන්න. යටිතල ව්යුහයේ මන්දගාමීම සංරචකය සම්පූර්ණයෙන්ම භාවිතා කරන තෙක් මෙය සිදු වේ.
මේ ආකාරයට, පොකුරකට යම් බරක් හැසිරවීමට කොපමණ තැරැව්කරුවන් අවශ්යද යන්න පිළිබඳ පැහැදිලි අදහසක් අපට ලැබේ (තැරැව්කරුවන් සංඛ්යාව ද ඔරොත්තු දීමේ හැකියාව සහතික කිරීම සඳහා අවම පණිවිඩ අනුරූ ගණන, කොටස් ගණන වැනි වෙනත් සාධක මත රඳා පවතී. නායකයන්, ආදිය). ඊට අමතරව, සිරස් පරිමාණය අවශ්ය යටිතල පහසුකම් සංරචක පිළිබඳව අපි අවබෝධයක් ලබා ගනිමු.
මූලික වින්යාසයන්හි ඇති මන්දගාමී සංරචකවලින් උපරිම ප්රයෝජන ගැනීමට සහ කෆ්කා පොකුරක ප්රතිදානය මැනීමට අප ගන්නා පියවර ගැන මෙම ලිපියෙන් කතා කෙරේ. ඉතා ඔරොත්තු දෙන වින්යාසයකට අවම වශයෙන් ධාවන තැරැව්කරුවන් තිදෙනෙකුවත් අවශ්ය වේ (min.insync.replicas=3
), විවිධ ප්රවේශ්යතා කලාප තුනක් හරහා බෙදා හරිනු ලැබේ. Kubernetes යටිතල පහසුකම් වින්යාස කිරීම, පරිමාණය කිරීම සහ අධීක්ෂණය කිරීම සඳහා, අපි දෙමුහුන් වලාකුළු සඳහා අපගේම බහාලුම් කළමනාකරණ වේදිකාවක් භාවිතා කරමු -
කෆ්කා පොකුරු යටිතල පහසුකම් සහ වින්යාසය පිළිබඳ සිතුවිලි
පහත උදාහරණ සඳහා, අපි ක්ලවුඩ් සපයන්නා ලෙස AWS සහ Kubernetes බෙදාහැරීම ලෙස EKS තෝරා ගත්තෙමු. සමාන වින්යාසයක් භාවිතයෙන් ක්රියාත්මක කළ හැක
තැටිය
Amazon විවිධ ඉදිරිපත් කරයි
අවස්ථා වර්ග
කෆ්කාගේ ක්රියාකාරිත්වය මෙහෙයුම් පද්ධතියේ පිටු හැඹිලිය මත බෙහෙවින් රඳා පවතී, එබැවින් අපට තැරැව්කරුවන් (JVM) සහ පිටු හැඹිලි සඳහා ප්රමාණවත් මතකයක් සහිත අවස්ථා අවශ්ය වේ. උදාහරණය c5.2x විශාලයි - හොඳ ආරම්භයක්, එය 16 GB මතකයක් ඇති නිසා සහ
ජාලය
VM නිදසුනෙහි සහ තැටියේ ක්රියාකාරීත්වයට සාපේක්ෂව ජාල ප්රතිදානය ප්රමාණවත් තරම් විශාල විය යුතුය, එසේ නොමැතිනම් ජාලය බාධාවක් බවට පත්වේ. අපගේ නඩුවේදී, ජාල අතුරු මුහුණත c5.4x විශාලයි 10 Gb/s දක්වා වේගය සඳහා සහය දක්වයි, එය VM නිදසුනක I/O ප්රතිදානයට වඩා සැලකිය යුතු ලෙස වැඩි වේ.
තැරැව්කරු යෙදවීම
CPU, මතකය, ජාල සහ තැටි සම්පත් සඳහා වෙනත් ක්රියාවලීන් සමඟ තරඟ කිරීම වැළැක්වීම සඳහා කැපවූ නෝඩ් වෙත තැරැව්කරුවන් යෙදවිය යුතුය (Kubernetes හි කාලසටහන්ගත කර ඇත).
ජාවා අනුවාදය
තාර්කික තේරීම ජාවා 11 වන අතර එය ඩොකර් සමඟ අනුකූල වන බැවින් තැරැව්කරු ක්රියාත්මක වන බහාලුමට ඇති ප්රොසෙසර සහ මතකය JVM නිවැරදිව තීරණය කරයි. CPU සීමාවන් වැදගත් බව දැනගෙන, JVM අභ්යන්තරව සහ විනිවිද පෙනෙන ලෙස GC නූල් සහ JIT නූල් ගණන සකසයි. අපි කෆ්කා රූපය භාවිතා කළා banzaicloud/kafka:2.13-2.4.0
, Java 2.4.0 මත Kafka අනුවාදය 2.13 (Scala 11) ඇතුළත් වේ.
ඔබ Kubernetes හි Java/JVM ගැන වැඩිදුර දැන ගැනීමට කැමති නම්, අපගේ පහත පළ කිරීම් බලන්න:
තැරැව්කාර මතක සැකසුම්
තැරැව්කාර මතකය වින්යාස කිරීම සඳහා ප්රධාන අංශ දෙකක් තිබේ: JVM සඳහා සහ Kubernetes පොඩ් සඳහා සැකසුම්. පොඩ් එකක් සඳහා සකසන ලද මතක සීමාව උපරිම ගොඩ ප්රමාණයට වඩා වැඩි විය යුතුය, එවිට JVM හට තමන්ගේම මතකයේ පවතින ජාවා මෙටාස්පේස් සහ කෆ්කා සක්රියව භාවිතා කරන මෙහෙයුම් පද්ධති පිටු හැඹිලිය සඳහා ඉඩ ඇත. අපගේ පරීක්ෂණ වලදී අපි පරාමිති සහිත කෆ්කා තැරැව්කරුවන් දියත් කළෙමු -Xmx4G -Xms2G
, සහ පොඩ් සඳහා මතක සීමාව විය 10 Gi
. JVM සඳහා මතක සැකසුම් ස්වයංක්රීයව භාවිතයෙන් ලබා ගත හැකි බව කරුණාවෙන් සලකන්න -XX:MaxRAMPercentage
и -X:MinRAMPercentage
, පෝඩ් සඳහා මතක සීමාව මත පදනම්ව.
තැරැව්කාර ප්රොසෙසර සැකසුම්
සාමාන්යයෙන් කිවහොත්, Kafka විසින් භාවිතා කරන නූල් ගණන වැඩි කිරීමෙන් සමාන්තරකරණය වැඩි කිරීමෙන් ඔබට කාර්ය සාධනය වැඩි දියුණු කළ හැකිය. Kafka සඳහා ප්රොසෙසර වැඩි වන තරමට වඩා හොඳය. අපගේ පරීක්ෂණයේදී, අපි ප්රොසෙසර 6ක සීමාවකින් ආරම්භ කළ අතර ක්රමයෙන් (පුනරාවර්තන හරහා) ඒවායේ සංඛ්යාව 15 දක්වා ඉහළ නැංවෙමු. ඊට අමතරව, අපි සකස් කළෙමු. num.network.threads=12
තැරැව්කාර සැකසුම් තුළ ජාලයෙන් දත්ත ලබා ගන්නා නූල් ගණන වැඩි කර යැවීමට. අනුගාමික තැරැව්කරුවන්ට ප්රමාණවත් තරම් ඉක්මනින් අනුරූ ලබා ගත නොහැකි බව වහාම සොයා ගත් ඔවුන් මතු කළහ num.replica.fetchers
අනුගාමික තැරැව්කරුවන් නායකයින්ගෙන් පණිවිඩ අනුකරණය කරන වේගය වැඩි කිරීමට 4 දක්වා.
පැටවීමේ උත්පාදන මෙවලම
කෆ්කා පොකුරේ (මිණුම් සලකුණු කර ඇති) එහි උපරිම බරට පැමිණීමට පෙර තෝරාගත් බර උත්පාදකයේ ධාරිතාව අවසන් නොවන බවට ඔබ සහතික විය යුතුය. වෙනත් වචන වලින් කිවහොත්, බර උත්පාදන මෙවලමෙහි හැකියාවන් පිළිබඳ මූලික තක්සේරුවක් සිදු කිරීම අවශ්ය වන අතර ප්රමාණවත් ප්රොසෙසර සංඛ්යාවක් සහ මතකයක් සමඟ ඒ සඳහා අවස්ථා වර්ග ද තෝරා ගත යුතුය. මෙම අවස්ථාවේදී, අපගේ මෙවලම Kafka පොකුරට හැසිරවිය හැකි ප්රමාණයට වඩා වැඩි බරක් නිපදවනු ඇත. බොහෝ අත්හදා බැලීම්වලින් පසුව, අපි පිටපත් තුනක් මත පදිංචි විය c5.4x විශාලයි, ඒ හැම එකකම ජෙනරේටරයක් ක්රියාත්මක විය.
මිණුම් සලකුණු කිරීම
කාර්ය සාධනය මැනීම යනු පහත සඳහන් අදියරයන් ඇතුළත් පුනරාවර්තන ක්රියාවලියකි:
- යටිතල පහසුකම් පිහිටුවීම (EKS පොකුර, කෆ්කා පොකුර, පැටවුම් උත්පාදන මෙවලම, මෙන්ම Prometheus සහ Grafana);
- එකතු කරන ලද කාර්ය සාධන දර්ශකවල අහඹු අපගමනය පෙරීම සඳහා යම් කාලයක් සඳහා බරක් උත්පාදනය කිරීම;
- නිරීක්ෂිත කාර්ය සාධන දර්ශක මත පදනම්ව තැරැව්කරුගේ යටිතල පහසුකම් සහ වින්යාසය සකස් කිරීම;
- කෆ්කා පොකුරු ප්රතිදානයේ අවශ්ය මට්ටම ලබා ගන්නා තෙක් ක්රියාවලිය නැවත සිදු කිරීම. ඒ සමගම, එය අඛණ්ඩව ප්රතිනිෂ්පාදනය කළ හැකි අතර ප්රතිදානයේ අවම වෙනස්කම් පෙන්නුම් කළ යුතුය.
පරීක්ෂණ පොකුරු මිණුම් සලකුණු කිරීමේ ක්රියාවලියේදී සිදු කරන ලද පියවර ඊළඟ කොටස විස්තර කරයි.
මෙවලම්
මූලික වින්යාසයක් ඉක්මනින් යෙදවීමට, බර උත්පාදනය කිරීමට සහ කාර්ය සාධනය මැනීමට පහත මෙවලම් භාවිතා කරන ලදී:
-
බන්සායි වලාකුළු නල මාර්ගය Amazon c වෙතින් EKS පොකුරක් සංවිධානය කිරීම සඳහාPrometheus (කෆ්කා සහ යටිතල පහසුකම් ප්රමිතික එකතු කිරීමට) සහග්රැෆනා (මෙම මිතික දෘශ්යමාන කිරීමට). අපි ප්රයෝජන ගත්තා ඒකාබද්ධ вනල මාර්ගය ෆෙඩරේටඩ් අධීක්ෂණය, මධ්යගත ලොග් එකතු කිරීම, අවදානම් ස්කෑන් කිරීම, ආපදා ප්රතිසාධනය, ව්යවසාය-ශ්රේණියේ ආරක්ෂාව සහ තවත් බොහෝ දේ සපයන සේවාවන්. -
සංග්රෙනෙල් - කෆ්කා පොකුරක් බර පරීක්ෂා කිරීම සඳහා මෙවලමක්. - කෆ්කා ප්රමිතික සහ යටිතල පහසුකම් දෘශ්යමාන කිරීම සඳහා Grafana උපකරණ පුවරු:
කුබර්නෙටස් කෆ්කා ,නෝඩ් අපනයනකරු . - Kubernetes මත Kafka පොකුරක් පිහිටුවීමට පහසුම මාර්ගය සඳහා Supertubes CLI. Zookeeper, Kafka operator, Envoy සහ තවත් බොහෝ සංරචක ස්ථාපනය කර ඇති අතර Kubernetes හි නිෂ්පාදනයට සූදානම් Kafka පොකුරක් ධාවනය කිරීමට නිසි ලෙස වින්යාස කර ඇත.
- ස්ථාපනය කිරීමට supertubes CLI ලබා දී ඇති උපදෙස් භාවිතා කරන්න
මෙහි .
- ස්ථාපනය කිරීමට supertubes CLI ලබා දී ඇති උපදෙස් භාවිතා කරන්න
EKS පොකුර
කැපවූ සේවක නෝඩ් සහිත EKS පොකුරක් සකස් කරන්න c5.4x විශාලයි Kafka තැරැව්කරුවන් සමඟ කරල් සඳහා විවිධ ලබා ගත හැකි කලාපවල, මෙන්ම පැටවුම් උත්පාදක සහ අධීක්ෂණ යටිතල පහසුකම් සඳහා කැප වූ නෝඩ්.
banzai cluster create -f https://raw.githubusercontent.com/banzaicloud/kafka-operator/master/docs/benchmarks/infrastructure/cluster_eks_202001.json
EKS පොකුර ක්රියාත්මක වූ පසු, එහි ඒකාබද්ධ කිරීම සක්රීය කරන්න
කෆ්කා පද්ධති සංරචක
සුපර් ටියුබ් CLI භාවිතයෙන් EKS හි Kafka පද්ධති සංරචක (Zookeeper, kafka-operator) ස්ථාපනය කරන්න:
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 ක කාණ්ඩ වශයෙන් Kafka වෙත ප්රකාශයට පත් කරයි.
- තර්කයක් භාවිතා කිරීම
-required-acks=all
කෆ්කා තැරැව්කරුවන් විසින් පණිවිඩයේ සියලුම සමමුහුර්ත අනුරූ ලැබී සහ තහවුරු කළ විට ප්රකාශනය සාර්ථක යැයි සැලකේ. මෙයින් අදහස් කරන්නේ මිණුම් ලකුණෙන් අපි නායකයින් පණිවිඩ ලබා ගන්නා වේගය පමණක් නොව, ඔවුන්ගේ අනුගාමිකයින් පණිවිඩ ප්රතිනිර්මාණය කරන බව ද මැන බැලූ බවයි. මෙම පරීක්ෂණයේ අරමුණ පාරිභෝගික කියවීමේ වේගය ඇගයීම නොවේ (පාරිභෝගිකයින්) OS පිටු හැඹිලියේ තවමත් පවතින මෑතදී ලැබුණු පණිවිඩ සහ එය තැටියේ ගබඩා කර ඇති පණිවිඩ කියවීමේ වේගය සමඟ සැසඳීම. - බර උත්පාදක යන්ත්රය කම්කරුවන් 20 ක් සමාන්තරව ධාවනය කරයි (
-workers=20
) සෑම සේවකයෙකුටම කෆ්කා පොකුරට සේවකයාගේ සම්බන්ධතාවය බෙදා ගන්නා නිෂ්පාදකයින් 5 දෙනෙකු අඩංගු වේ. එහි ප්රතිඵලයක් වශයෙන්, සෑම උත්පාදක යන්ත්රයකටම නිෂ්පාදකයින් 100 ක් සිටින අතර, ඔවුන් සියල්ලෝම Kafka පොකුරට පණිවිඩ යවයි.
පොකුරේ සෞඛ්යය නිරීක්ෂණය කිරීම
කෆ්කා පොකුරේ බර පරීක්ෂා කිරීමේදී, පොඩ් නැවත ආරම්භ කිරීම්, සමමුහුර්ත නොවන අනුරූ සහ අවම උච්චාවචනයන් සහිත උපරිම ප්රතිදානයක් නොමැති බව සහතික කිරීමට අපි එහි සෞඛ්යය ද නිරීක්ෂණය කළෙමු:
- පැටවුම් උත්පාදක යන්ත්රය ප්රකාශයට පත් කරන ලද පණිවිඩ සංඛ්යාව සහ දෝෂ අනුපාතය පිළිබඳ සම්මත සංඛ්යා ලේඛන ලියයි. දෝෂ අනුපාතය එලෙසම පැවතිය යුතුය
0,00%
. -
ක ru ස් පාලනය , kafka-operator විසින් යොදවා ඇති අතර, අපට පොකුරු තත්ත්වය නිරීක්ෂණය කළ හැකි උපකරණ පුවරුවක් සපයයි. මෙම පැනලය බැලීම සඳහා:supertubes cluster cruisecontrol show -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file>
- ISR මට්ටම (“සමමුහුර්තකරණය තුළ” අනුරූ ගණන) හැකිලීම සහ ප්රසාරණය 0 ට සමාන වේ.
මිනුම් ප්රතිඵල
තැරැව්කරුවන් 3ක්, පණිවිඩ ප්රමාණය - බයිට් 512ක්
තැරැව්කරුවන් තිදෙනෙකු හරහා ඒකාකාරව බෙදා හරින ලද කොටස් සමඟ, අපට කාර්ය සාධනය ලබා ගැනීමට හැකි විය ~500 Mb/s (තත්පරයට ආසන්න වශයෙන් පණිවිඩ 990 දහසක්):
JVM අතථ්ය යන්ත්රයේ මතක පරිභෝජනය 2 GB නොඉක්මවිය:
තැරැව්කරුවන් ක්රියාත්මක වූ අවස්ථා තුනෙහිම තැටි ප්රතිදානය උපරිම I/O නෝඩ් ප්රතිදානය කරා ළඟා විය:
නෝඩ් මගින් මතක භාවිතය පිළිබඳ දත්ත අනුව, පද්ධති බෆරින් සහ හැඹිලි ~10-15 GB පමණ ගත වේ:
තැරැව්කරුවන් 3ක්, පණිවිඩ ප්රමාණය - බයිට් 100ක්
පණිවිඩයේ ප්රමාණය අඩු වන විට, ප්රතිදානය දළ වශයෙන් 15-20% කින් පහත වැටේ: එක් එක් පණිවිඩය සැකසීමට ගත කරන කාලය එයට බලපායි. ඊට අමතරව, ප්රොසෙසරයේ බර දෙගුණයක් පමණ වැඩි වී ඇත.
තැරැව්කාර නෝඩ් වල තවමත් භාවිතයට නොගත් හරයන් ඇති බැවින්, කෆ්කා වින්යාසය වෙනස් කිරීමෙන් කාර්ය සාධනය වැඩි දියුණු කළ හැක. මෙය පහසු කාර්යයක් නොවේ, එබැවින් ප්රතිදානය වැඩි කිරීම සඳහා විශාල පණිවිඩ සමඟ වැඩ කිරීම වඩා හොඳය.
තැරැව්කරුවන් 4ක්, පණිවිඩ ප්රමාණය - බයිට් 512ක්
නව තැරැව්කරුවන් එකතු කිරීමෙන් සහ කොටස්වල ශේෂයක් පවත්වා ගැනීමෙන් ඔබට පහසුවෙන් කෆ්කා පොකුරේ කාර්ය සාධනය වැඩි කළ හැකිය (මෙය තැරැව්කරුවන් අතර බර ඒකාකාරව බෙදා හැරීම සහතික කරයි). අපගේ නඩුවේදී, තැරැව්කරුවෙකු එකතු කිරීමෙන් පසු, පොකුරු ප්රතිදානය වැඩි විය ~580 Mb/s (තත්පරයට පණිවිඩ මිලියන 1,1). වර්ධනය බලාපොරොත්තු වූවාට වඩා අඩු විය: මෙය ප්රධාන වශයෙන් කොටස්වල අසමතුලිතතාවය නිසා (සියලු තැරැව්කරුවන් ඔවුන්ගේ හැකියාවන් උපරිමයෙන් වැඩ නොකරයි).
JVM යන්ත්රයේ මතක පරිභෝජනය 2 GB ට වඩා අඩු විය:
ධාවක සහිත තැරැව්කරුවන්ගේ කාර්යය කොටස්වල අසමතුලිතතාවයට බලපෑවේය:
සොයා ගැනීම්
ඉහත ඉදිරිපත් කර ඇති පුනරාවර්තන ප්රවේශය සිය ගණනක් පාරිභෝගිකයින්, නැවත කොටස් කිරීම, පෙරළීමේ යාවත්කාලීන කිරීම්, පොඩ් නැවත ආරම්භ කිරීම් යනාදිය සම්බන්ධ වඩාත් සංකීර්ණ අවස්ථා ආවරණය කිරීමට පුළුල් කළ හැකිය. මේ සියල්ල අපට විවිධ තත්වයන් යටතේ කෆ්කා පොකුරේ හැකියාවන්ගේ සීමාවන් තක්සේරු කිරීමට, එහි ක්රියාකාරිත්වයේ ඇති බාධක හඳුනා ගැනීමට සහ ඒවාට එරෙහිව සටන් කිරීමට ක්රම සොයා ගැනීමට අපට ඉඩ සලසයි.
පොකුරක් ඉක්මනින් සහ පහසුවෙන් යෙදවීමට, එය වින්යාස කිරීමට, තැරැව්කරුවන් සහ මාතෘකා එක් කිරීමට/ඉවත් කිරීමට, ඇඟවීම්වලට ප්රතිචාර දැක්වීමට, සහ සාමාන්යයෙන් Kafka Kubernetes මත නිසි ලෙස ක්රියා කරන බව සහතික කිරීමට අපි Supertubes නිර්මාණය කළෙමු. අපගේ ඉලක්කය වන්නේ ඔබට ප්රධාන කාර්යය ("ජනනය" සහ "පරිභෝජනය" Kafka පණිවිඩ) වෙත අවධානය යොමු කිරීමට උපකාර කිරීම සහ සියලු වෙහෙස මහන්සි වී වැඩ කිරීම Supertubes සහ Kafka ක්රියාකරු වෙත පැවරීමයි.
ඔබ Banzai Cloud තාක්ෂණයන් සහ විවෘත මූලාශ්ර ව්යාපෘති ගැන උනන්දුවක් දක්වන්නේ නම්, සමාගමට දායක වන්න
පරිවර්තකගෙන් PS
අපගේ බ්ලොග් අඩවියේ ද කියවන්න:
- «
K8s හි Redis ක්රියාකරු සමඟ එක් කථාවක් සහ මෙම දත්ත සමුදායෙන් දත්ත විශ්ලේෂණය කිරීම සඳහා උපයෝගිතා පිළිබඳ කුඩා සමාලෝචනයක් »; - «
RabbitMQ හි Kubernetes වෙත බාධාවකින් තොරව සංක්රමණය වීම »; - «
CoreOS වෙතින් zetcd: ZooKeeper වෙනුවට...etcd ගබඩාව ".
මූලාශ්රය: www.habr.com