კაფკას კლასტერის შესაბამისი ზომის განსაზღვრა კუბერნეტში

Შენიშვნა. თარგმნა: ამ სტატიაში Banzai Cloud იზიარებს მაგალითს იმის შესახებ, თუ როგორ შეიძლება გამოყენებულ იქნას მისი მორგებული ხელსაწყოები, რათა კაფკას უფრო ადვილად გამოიყენოს Kubernetes-ში. შემდეგი ინსტრუქციები ასახავს, ​​თუ როგორ შეგიძლიათ განსაზღვროთ თქვენი ინფრასტრუქტურის ოპტიმალური ზომა და დააკონფიგურიროთ კაფკა საჭირო გამტარუნარიანობის მისაღწევად.

Apache Kafka არის განაწილებული სტრიმინგის პლატფორმა საიმედო, მასშტაბირებადი და მაღალი ხარისხის რეალურ დროში ნაკადის სისტემების შესაქმნელად. მისი შთამბეჭდავი შესაძლებლობები შეიძლება გაფართოვდეს Kubernetes-ის გამოყენებით. ამისათვის ჩვენ შევიმუშავეთ ღია კოდის კაფკას ოპერატორი და ინსტრუმენტი ე.წ სუპერმილები. ისინი საშუალებას გაძლევთ გაუშვათ Kafka Kubernetes-ზე და გამოიყენოთ მისი სხვადასხვა ფუნქციები, როგორიცაა ბროკერის კონფიგურაციის დაზუსტება, მეტრიკაზე დაფუძნებული სკალირება ხელახალი ბალანსით, თაროს ცნობადობა, „რბილი“ (მოხდენილი) განახლებების გავრცელება და ა.შ.

სცადეთ Supertubes თქვენს კლასტერში:

curl https://getsupertubes.sh | sh и supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>

ან დაუკავშირდით დოკუმენტაცია. ასევე შეგიძლიათ წაიკითხოთ კაფკას ზოგიერთი შესაძლებლობების შესახებ, რომელთანაც მუშაობა ავტომატიზირებულია Supertubes და Kafka ოპერატორის გამოყენებით. მათ შესახებ უკვე დავწერეთ ბლოგზე:

• Ო არა! კიდევ ერთი კაფკას ოპერატორი Kubernetes-ისთვის;
• დააკვირდით და მართეთ კაფკა პრომეთეს მეტრიკის საფუძველზე;
• კაფკას თაროს ცნობიერება Kubernetes-ზე;
• Apache Kafka-ს გაშვება ისტიოზე - საორიენტაციო ნიშანი;
• მომხმარებლის ავტორიზაცია და წვდომის კონტროლირებადი კლასტერები Kafka ოპერატორთან ერთად;
• კაფკას მოძრავი განახლება და დინამიური კონფიგურაცია Kubernetes-ზე;
• დესპანის პროტოკოლის ფილტრი კაფკასთვის, ქსელური.

როდესაც გადაწყვეტთ Kubernetes-ზე კაფკას კლასტერის განთავსებას, სავარაუდოდ, თქვენ წინაშე აღმოჩნდებით ძირითადი ინფრასტრუქტურის ოპტიმალური ზომის განსაზღვრის გამოწვევის წინაშე და თქვენი კაფკას კონფიგურაციის დაზუსტების აუცილებლობას გამტარუნარიანობის მოთხოვნების დასაკმაყოფილებლად. თითოეული ბროკერის მაქსიმალური შესრულება განისაზღვრება ძირითადი ინფრასტრუქტურის კომპონენტების მუშაობით, როგორიცაა მეხსიერება, პროცესორი, დისკის სიჩქარე, ქსელის გამტარობა და ა.შ.

იდეალურ შემთხვევაში, ბროკერის კონფიგურაცია უნდა იყოს ისეთი, რომ ყველა ინფრასტრუქტურის ელემენტი იყოს გამოყენებული მათი მაქსიმალური შესაძლებლობებით. თუმცა, რეალურ ცხოვრებაში ეს კონფიგურაცია საკმაოდ რთულია. უფრო სავარაუდოა, რომ მომხმარებლები დააკონფიგურირებენ ბროკერებს, რათა მაქსიმალურად გამოიყენონ ერთი ან ორი კომპონენტი (დისკი, მეხსიერება ან პროცესორი). ზოგადად რომ ვთქვათ, ბროკერი აჩვენებს მაქსიმალურ შესრულებას, როდესაც მისი კონფიგურაცია საშუალებას აძლევს ყველაზე ნელი კომპონენტის მაქსიმალურ გამოყენებას. ამ გზით ჩვენ შეგვიძლია მივიღოთ უხეში წარმოდგენა იმ დატვირთვის შესახებ, რომელსაც შეუძლია გაუმკლავდეს ერთ ბროკერს.

თეორიულად, ჩვენ ასევე შეგვიძლია შევაფასოთ ბროკერების რაოდენობა, რომლებიც საჭიროა მოცემული დატვირთვის გასატარებლად. თუმცა, პრაქტიკაში იმდენი კონფიგურაციის ვარიანტია სხვადასხვა დონეზე, რომ ძალიან რთულია (თუ არა შეუძლებელი) კონკრეტული კონფიგურაციის პოტენციური შესრულების შეფასება. სხვა სიტყვებით რომ ვთქვათ, ძალიან რთულია კონფიგურაციის დაგეგმვა რომელიმე მოცემულ შესრულებაზე დაყრდნობით.

Supertubes-ის მომხმარებლებისთვის ჩვენ ჩვეულებრივ მივმართავთ შემდეგ მიდგომას: ვიწყებთ გარკვეული კონფიგურაციით (ინფრასტრუქტურა + პარამეტრები), შემდეგ გავზომავთ მის შესრულებას, ვასწორებთ ბროკერის პარამეტრებს და ვიმეორებთ პროცესს ხელახლა. ეს ხდება მანამ, სანამ ინფრასტრუქტურის ყველაზე ნელი კომპონენტი სრულად არ იქნება გამოყენებული.

ამ გზით, ჩვენ უფრო მკაფიო წარმოდგენას ვიღებთ იმის შესახებ, თუ რამდენი ბროკერი სჭირდება კლასტერს გარკვეული დატვირთვის გასატარებლად (ბროკერების რაოდენობა ასევე დამოკიდებულია სხვა ფაქტორებზე, როგორიცაა შეტყობინებების რეპლიკების მინიმალური რაოდენობა მდგრადობის უზრუნველსაყოფად, დანაყოფის რაოდენობა. ლიდერები და ა.შ.). გარდა ამისა, ჩვენ ვიღებთ ინფორმაციას იმის შესახებ, თუ რომელი ინფრასტრუქტურის კომპონენტები საჭიროებენ ვერტიკალურ მასშტაბირებას.

ამ სტატიაში ვისაუბრებთ იმ ნაბიჯებზე, რომლებსაც ჩვენ გადავდგამთ, რათა მაქსიმალურად ვისარგებლოთ ყველაზე ნელი კომპონენტებიდან საწყის კონფიგურაციებში და გავზომოთ კაფკას კლასტერის გამტარუნარიანობა. უაღრესად მდგრადი კონფიგურაციისთვის საჭიროა მინიმუმ სამი გაშვებული ბროკერი (min.insync.replicas=3), განაწილებულია სამ სხვადასხვა ხელმისაწვდომობის ზონაში. Kubernetes ინფრასტრუქტურის კონფიგურაციისთვის, მასშტაბის და მონიტორინგისთვის, ჩვენ ვიყენებთ კონტეინერის მართვის საკუთარ პლატფორმას ჰიბრიდული ღრუბლებისთვის - მილსადენის. იგი მხარს უჭერს შიდა (შიშველი მეტალი, VMware) და ხუთი ტიპის ღრუბლებს (Alibaba, AWS, Azure, Google, Oracle), ისევე როგორც მათ ნებისმიერ კომბინაციას.

აზრები კაფკას კასეტური ინფრასტრუქტურისა და კონფიგურაციის შესახებ

ქვემოთ მოყვანილი მაგალითებისთვის, ჩვენ ავირჩიეთ AWS, როგორც ღრუბლოვანი პროვაიდერი და EKS, როგორც Kubernetes დისტრიბუცია. მსგავსი კონფიგურაციის განხორციელება შესაძლებელია გამოყენებით პ.კ.ე. - Kubernetes დისტრიბუცია Banzai Cloud-დან, დამოწმებული CNCF-ის მიერ.

დისკზე

Amazon გთავაზობთ სხვადასხვა EBS მოცულობის ტიპები. ბირთვში gp2 и io1 თუმცა არის SSD დისკები მაღალი გამტარუნარიანობის უზრუნველსაყოფად gp2 მოიხმარს დაგროვილ კრედიტებს (I/O კრედიტები), ამიტომ ჩვენ ვამჯობინეთ ტიპი io1, რომელიც გთავაზობთ თანმიმდევრულ მაღალ გამტარუნარიანობას.

ინსტანციის ტიპები

კაფკას შესრულება დიდად არის დამოკიდებული ოპერაციული სისტემის გვერდის ქეშზე, ამიტომ ჩვენ გვჭირდება ინსტანციები საკმარისი მეხსიერებით ბროკერებისთვის (JVM) და გვერდის ქეშისთვის. მაგალითად c5.2x დიდი - კარგი დასაწყისია, რადგან მას აქვს 16 GB მეხსიერება და ოპტიმიზირებულია EBS-თან მუშაობისთვის. მისი მინუსი ის არის, რომ მას შეუძლია უზრუნველყოს მაქსიმალური შესრულება მხოლოდ 30 წუთის განმავლობაში ყოველ 24 საათში. თუ თქვენი დატვირთვა მოითხოვს მაქსიმალურ შესრულებას უფრო ხანგრძლივი პერიოდის განმავლობაში, შეგიძლიათ განიხილოთ ინსტანციის სხვა ტიპები. სწორედ ეს გავაკეთეთ, ამაზე შევჩერდით c5.4x დიდი. ის უზრუნველყოფს მაქსიმალურ გამტარუნარიანობას 593,75 მბ/წმ. EBS მოცულობის მაქსიმალური გამტარუნარიანობა io1 უფრო მაღალი ვიდრე მაგალითი c5.4x დიდიასე რომ, ინფრასტრუქტურის ყველაზე ნელი ელემენტი, სავარაუდოდ, იქნება ამ ტიპის I/O გამტარუნარიანობა (რაც უნდა დაადასტუროს ჩვენმა დატვირთვის ტესტებმაც).

ქსელი

ქსელის გამტარუნარიანობა საკმარისად დიდი უნდა იყოს VM ინსტანციისა და დისკის შესრულებასთან შედარებით, წინააღმდეგ შემთხვევაში ქსელი ხდება ბოთლი. ჩვენს შემთხვევაში, ქსელის ინტერფეისი c5.4x დიდი მხარს უჭერს 10 გბ/წმ-მდე სიჩქარეს, რაც მნიშვნელოვნად აღემატება VM ინსტანციის I/O გამტარუნარიანობას.

ბროკერის განლაგება

ბროკერები უნდა განთავსდნენ (დაგეგმილი Kubernetes-ში) სპეციალურ კვანძებში, რათა თავიდან აიცილონ კონკურენცია CPU-ს, მეხსიერების, ქსელისა და დისკის რესურსების სხვა პროცესებთან.

ჯავის ვერსია

ლოგიკური არჩევანია Java 11, რადგან ის თავსებადია Docker-თან იმ გაგებით, რომ JVM სწორად განსაზღვრავს პროცესორებს და მეხსიერებას, რომელიც ხელმისაწვდომია კონტეინერისთვის, რომელშიც ბროკერი მუშაობს. იცის, რომ პროცესორის ლიმიტები მნიშვნელოვანია, JVM შინაგანად და გამჭვირვალედ ადგენს GC ძაფებისა და JIT ძაფების რაოდენობას. ჩვენ გამოვიყენეთ კაფკას გამოსახულება banzaicloud/kafka:2.13-2.4.0, რომელიც მოიცავს კაფკას ვერსიას 2.4.0 (Scala 2.13) Java 11-ზე.

თუ გსურთ გაიგოთ მეტი Java/JVM-ის შესახებ Kubernetes-ზე, შეამოწმეთ ჩვენი შემდეგი პოსტები:

• რატომ არის ჩემი Java აპლიკაცია OOMKilled;
• როგორ სწორად გავზომოთ კონტეინერები Java 10 აპლიკაციებისთვის.

ბროკერის მეხსიერების პარამეტრები

ბროკერის მეხსიერების კონფიგურაციის ორი ძირითადი ასპექტია: პარამეტრები JVM-სთვის და Kubernetes pod-ისთვის. პოდისთვის დაყენებული მეხსიერების ლიმიტი უნდა აღემატებოდეს გროვის მაქსიმალურ ზომას, რათა JVM-ს ჰქონდეს ადგილი Java-ის მეტასივრცისთვის, რომელიც მდებარეობს მის მეხსიერებაში და ოპერაციული სისტემის გვერდის ქეშისთვის, რომელსაც კაფკა აქტიურად იყენებს. ჩვენს ტესტებში ჩვენ გავუშვით კაფკას ბროკერები პარამეტრებით -Xmx4G -Xms2Gდა მეხსიერების ლიმიტი იყო 10 Gi. გთხოვთ გაითვალისწინოთ, რომ JVM-ის მეხსიერების პარამეტრების მიღება შესაძლებელია ავტომატურად გამოყენებით -XX:MaxRAMPercentage и -X:MinRAMPercentage, მეხსიერების ლიმიტის საფუძველზე pod.

ბროკერის პროცესორის პარამეტრები

ზოგადად, თქვენ შეგიძლიათ გააუმჯობესოთ შესრულება პარალელურობის გაზრდით, კაფკას მიერ გამოყენებული ძაფების რაოდენობის გაზრდით. რაც უფრო მეტი პროცესორია ხელმისაწვდომი კაფკასთვის, მით უკეთესი. ჩვენს ტესტში დავიწყეთ 6 პროცესორის ლიმიტით და თანდათან (იტერაციების მეშვეობით) გავზარდეთ მათი რიცხვი 15-მდე. გარდა ამისა, დავაყენეთ num.network.threads=12 ბროკერის პარამეტრებში გაზარდოს ძაფების რაოდენობა, რომლებიც იღებენ მონაცემებს ქსელიდან და აგზავნიან მას. მაშინვე აღმოაჩინეს, რომ მიმდევარი ბროკერები ვერ მიიღებდნენ რეპლიკებს საკმარისად სწრაფად, მათ წამოაყენეს num.replica.fetchers 4-მდე გაზარდოს სიჩქარე, რომლითაც მიმდევარი ბროკერები იმეორებდნენ ლიდერების შეტყობინებებს.

ჩატვირთვის გენერაციის ინსტრუმენტი

თქვენ უნდა დარწმუნდეთ, რომ არჩეული დატვირთვის გენერატორი არ ამოიწურება სიმძლავრემდე, სანამ კაფკას კლასტერი (რომელიც ბენჩმარკშია) მიაღწევს მაქსიმალურ დატვირთვას. სხვა სიტყვებით რომ ვთქვათ, აუცილებელია ჩატარდეს დატვირთვის გენერირების ხელსაწყოს შესაძლებლობების წინასწარი შეფასება და ასევე შეარჩიოს მაგალითების ტიპები საკმარისი რაოდენობის პროცესორებითა და მეხსიერებით. ამ შემთხვევაში, ჩვენი ინსტრუმენტი გამოიმუშავებს იმაზე მეტ დატვირთვას, ვიდრე კაფკას კლასტერს შეუძლია. მრავალი ექსპერიმენტის შემდეგ ჩვენ სამ ეგზემპლარზე დავრჩით c5.4x დიდი, რომელთაგან თითოეულს ჰქონდა გენერატორი გაშვებული.

Benchmarking

შესრულების გაზომვა არის განმეორებითი პროცესი, რომელიც მოიცავს შემდეგ ეტაპებს:

• ინფრასტრუქტურის მოწყობა (EKS კლასტერი, კაფკას კლასტერი, დატვირთვის გენერირების ინსტრუმენტი, ასევე პრომეთე და გრაფანა);
• გარკვეული პერიოდის განმავლობაში დატვირთვის გენერირება შეგროვებული შესრულების ინდიკატორებში შემთხვევითი გადახრების გასაფილტრად;
• საბროკერო ინფრასტრუქტურისა და კონფიგურაციის მორგება დაკვირვებული შესრულების ინდიკატორებზე დაყრდნობით;
• პროცესის გამეორება მანამ, სანამ არ მიიღწევა კაფკას კასეტური გამტარუნარიანობის საჭირო დონე. ამავე დროს, ის უნდა იყოს თანმიმდევრულად გამეორებადი და აჩვენოს გამტარუნარიანობის მინიმალური ცვალებადობა.

შემდეგი ნაწილი აღწერს საფეხურებს, რომლებიც განხორციელდა სატესტო კლასტერული ბენჩმარკინგის პროცესში.

ინსტრუმენტები

შემდეგი ინსტრუმენტები გამოიყენებოდა საბაზისო კონფიგურაციის სწრაფად დასაყენებლად, დატვირთვების გენერირებისთვის და შესრულების გასაზომად:

• Banzai Cloud Pipeline ამაზონიდან EKS კლასტერის ორგანიზებისთვის გ პრომეთე (კაფკას და ინფრასტრუქტურის მეტრიკის შეგროვება) და გრაფანა (ამ მეტრიკის ვიზუალიზაციისთვის). ჩვენ ვისარგებლეთ ინტეგრირებული в მილსადენის სერვისები, რომლებიც უზრუნველყოფენ ფედერაციულ მონიტორინგს, ჟურნალების ცენტრალიზებულ შეგროვებას, დაუცველობის სკანირებას, კატასტროფის აღდგენას, საწარმოს დონის უსაფრთხოებას და მრავალი სხვა.
• სანგრენელი - ინსტრუმენტი კაფკას კლასტერის დატვირთვის შესამოწმებლად.
• გრაფანას დაფები კაფკას მეტრიკისა და ინფრასტრუქტურის ვიზუალიზაციისთვის: კუბერნეტეს კაფკა, კვანძის ექსპორტიორი.
• Supertubes CLI უმარტივესი გზით Kubernetes-ზე კაფკას კლასტერის დასაყენებლად. Zookeeper, Kafka ოპერატორი, Envoy და მრავალი სხვა კომპონენტი დაინსტალირებული და სათანადოდ არის კონფიგურირებული Kubernetes-ზე წარმოებისთვის მზა კაფკას კლასტერის გასაშვებად.
  • დაყენება სუპერმილები 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 პუბლიკაცია წარმატებულად ითვლება, როდესაც შეტყობინების ყველა სინქრონიზებული ასლი მიიღება და დადასტურდება კაფკას ბროკერების მიერ. ეს ნიშნავს, რომ ეტალონში ჩვენ გავზომეთ არა მხოლოდ ლიდერების სიჩქარე, რომლებიც იღებენ შეტყობინებებს, არამედ მათი მიმდევრები ამეორებენ მესიჯებს. ამ ტესტის მიზანი არ არის მომხმარებლის კითხვის სიჩქარის შეფასება (მომხმარებლები) ცოტა ხნის წინ მიღებული შეტყობინებები, რომლებიც ჯერ კიდევ რჩება OS გვერდის ქეშში და მისი შედარება დისკზე შენახული შეტყობინებების წაკითხვის სიჩქარესთან.
• დატვირთვის გენერატორი მუშაობს 20 მუშაკს პარალელურად (-workers=20). თითოეული მუშაკი შეიცავს 5 მწარმოებელს, რომლებიც იზიარებენ მუშაკის კავშირს კაფკას კლასტერთან. შედეგად, თითოეულ გენერატორს ჰყავს 100 პროდიუსერი და ისინი ყველა გზავნის შეტყობინებებს კაფკას კლასტერში.

კლასტერის ჯანმრთელობის მონიტორინგი

კაფკას კლასტერის დატვირთვის ტესტირების დროს, ჩვენ ასევე ვაკვირდებოდით მის ჯანმრთელობას, რათა დავრწმუნდეთ, რომ არ არსებობდა pod გადატვირთვა, არ იყო სინქრონული ასლები და მაქსიმალური გამტარუნარიანობა მინიმალური რყევებით:

• დატვირთვის გენერატორი წერს სტანდარტულ სტატისტიკას გამოქვეყნებული შეტყობინებების რაოდენობისა და შეცდომის სიხშირის შესახებ. შეცდომის მაჩვენებელი იგივე უნდა დარჩეს 0,00%.
• საკრუიზო კონტროლი, განლაგებული kafka-ოპერატორის მიერ, გთავაზობთ დაფას, სადაც ჩვენ ასევე შეგვიძლია დავაკვირდეთ კლასტერის მდგომარეობას. ამ პანელის სანახავად გააკეთეთ:

  supertubes cluster cruisecontrol show -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file>

• ISR დონე ("in-სინქრონული" ასლების რაოდენობა) შეკუმშვა და გაფართოება 0-ის ტოლია.

გაზომვის შედეგები

3 ბროკერი, შეტყობინების ზომა - 512 ბაიტი

სამ ბროკერზე თანაბრად გადანაწილებული ტიხრები, ჩვენ შევძელით შესრულების მიღწევა ~500 Mb/s (დაახლოებით 990 ათასი შეტყობინება წამში):

JVM ვირტუალური მანქანის მეხსიერების მოხმარება არ აღემატებოდა 2 გბ-ს:

დისკის გამტარუნარიანობა მიაღწია I/O კვანძის მაქსიმალურ გამტარუნარიანობას სამივე ინსტანციაზე, რომლებზეც ბროკერები მუშაობდნენ:

კვანძების მიერ მეხსიერების გამოყენების მონაცემებიდან გამომდინარეობს, რომ სისტემის ბუფერირებას და ქეშირებას დასჭირდა ~ 10-15 GB:

3 ბროკერი, შეტყობინების ზომა - 100 ბაიტი

შეტყობინების ზომის შემცირებით, გამტარუნარიანობა მცირდება დაახლოებით 15-20%-ით: თითოეული შეტყობინების დამუშავებაზე დახარჯული დრო გავლენას ახდენს მასზე. გარდა ამისა, პროცესორის დატვირთვა თითქმის გაორმაგდა.

ვინაიდან საბროკერო კვანძებს ჯერ კიდევ აქვთ გამოუყენებელი ბირთვები, შესრულება შეიძლება გაუმჯობესდეს კაფკას კონფიგურაციის შეცვლით. ეს არ არის ადვილი ამოცანა, ამიტომ გამტარუნარიანობის გასაზრდელად უმჯობესია იმუშაოთ უფრო დიდ შეტყობინებებთან.

4 ბროკერი, შეტყობინების ზომა - 512 ბაიტი

თქვენ შეგიძლიათ მარტივად გაზარდოთ კაფკას კლასტერის შესრულება, უბრალოდ ახალი ბროკერების დამატებით და დანაყოფების ბალანსის შენარჩუნებით (ეს უზრუნველყოფს ბროკერებს შორის დატვირთვის თანაბრად განაწილებას). ჩვენს შემთხვევაში, ბროკერის დამატების შემდეგ, კლასტერის გამტარუნარიანობა გაიზარდა ~580 Mb/s (~1,1 მილიონი შეტყობინება წამში). ზრდა მოსალოდნელზე ნაკლები აღმოჩნდა: ეს ძირითადად აიხსნება დანაყოფების დისბალანსით (ყველა ბროკერი არ მუშაობს თავისი შესაძლებლობების პიკზე).

JVM აპარატის მეხსიერების მოხმარება დარჩა 2 გბ-ზე ქვემოთ:

დისკებით ბროკერების მუშაობაზე გავლენა იქონია დანაყოფების დისბალანსმა:

დასკვნები

ზემოთ წარმოდგენილი განმეორებითი მიდგომა შეიძლება გაფართოვდეს უფრო რთული სცენარების დასაფარად, რომლებიც მოიცავს ასობით მომხმარებელს, ხელახალი დაყოფა, მოძრავი განახლებები, პოდ გადატვირთვა და ა.შ. ეს ყველაფერი საშუალებას გვაძლევს შევაფასოთ კაფკას კლასტერის შესაძლებლობების საზღვრები სხვადასხვა პირობებში, დავადგინოთ მის ფუნქციონირებაში არსებული შეფერხებები და ვიპოვოთ მათთან ბრძოლის გზები.

ჩვენ შევქმენით Supertubes, რათა სწრაფად და მარტივად განათავსონ კლასტერი, დააკონფიგურიროთ იგი, დავამატოთ/ამოშალოთ ბროკერები და თემები, უპასუხოთ გაფრთხილებებს და უზრუნველვყოთ, რომ ზოგადად კაფკა მუშაობს სწორად Kubernetes-ზე. ჩვენი მიზანია დაგეხმაროთ კონცენტრირება მოახდინოთ მთავარ ამოცანაზე (კაფკას შეტყობინებების „გენერირება“ და „მოხმარება“) და მთელი შრომა დაუტოვოთ Supertubes-ს და Kafka ოპერატორს.

თუ გაინტერესებთ Banzai Cloud ტექნოლოგიები და ღია კოდის პროექტები, გამოიწერეთ კომპანია მისამართზე GitHub, LinkedIn ან Twitter.

PS მთარგმნელისგან

ასევე წაიკითხეთ ჩვენს ბლოგზე:

• «ერთი ამბავი Redis ოპერატორთან K8s-ში და კომუნალური პროგრამების მინი-მიმოხილვა ამ მონაცემთა ბაზის მონაცემების გასაანალიზებლად";
• «RabbitMQ-ის უწყვეტი მიგრაცია Kubernetes-ში";
• «zetcd CoreOS-დან: ZooKeeper-ის ჩანაცვლება...etcd მეხსიერებით".

წყარო: www.habr.com