Προσδιορίστε το κατάλληλο μέγεθος για ένα σύμπλεγμα Κάφκα στο Kubernetes

Σημείωση. μετάφρ.: Σε αυτό το άρθρο, το Banzai Cloud μοιράζεται ένα παράδειγμα για το πώς μπορούν να χρησιμοποιηθούν τα προσαρμοσμένα βοηθητικά προγράμματα του για να κάνουν το Kafka πιο εύκολο στη χρήση στο Kubernetes. Οι παρακάτω οδηγίες δείχνουν πώς μπορείτε να προσδιορίσετε το βέλτιστο μέγεθος της υποδομής σας και να διαμορφώσετε τον ίδιο τον Kafka για να επιτύχετε την απαιτούμενη απόδοση.

Το Apache Kafka είναι μια κατανεμημένη πλατφόρμα ροής για τη δημιουργία αξιόπιστων, επεκτάσιμων και υψηλής απόδοσης συστημάτων ροής σε πραγματικό χρόνο. Οι εντυπωσιακές δυνατότητές του μπορούν να επεκταθούν χρησιμοποιώντας το Kubernetes. Για αυτό έχουμε αναπτύξει Χειριστής ανοιχτού κώδικα Kafka και ένα εργαλείο που ονομάζεται Υπερσωλήνες. Σας επιτρέπουν να εκτελέσετε το Kafka στο Kubernetes και να χρησιμοποιήσετε τις διάφορες δυνατότητες του, όπως λεπτή ρύθμιση της διαμόρφωσης του μεσίτη, κλιμάκωση βάσει μετρήσεων με επαναστάθμιση, επίγνωση rack, "soft" (χαριτωμένος) κυκλοφορία ενημερώσεων κ.λπ.

Δοκιμάστε τα Supertubes στο σύμπλεγμα σας:

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

Ή επικοινωνήστε τεκμηρίωση. Μπορείτε επίσης να διαβάσετε για ορισμένες από τις δυνατότητες του Kafka, η εργασία με την οποία είναι αυτοματοποιημένη χρησιμοποιώντας Supertubes και Kafka operator. Έχουμε ήδη γράψει για αυτούς στο blog:

• Ωχ όχι! Ένας ακόμη χειριστής Kafka για την Kubernetes;
• Παρακολούθηση και λειτουργία του Κάφκα με βάση τις μετρήσεις του Προμηθέα;
• Συνειδητοποίηση rack Kafka στο Kubernetes;
• Τρέχοντας τον Απάτσι Κάφκα πάνω από το Ιστιο - σημείο αναφοράς;
• Έλεγχος ταυτότητας χρήστη και ελεγχόμενη πρόσβαση σε συμπλέγματα με τον τελεστή Kafka;
• Κυλιόμενη αναβάθμιση Kafka και δυναμική διαμόρφωση στο Kubernetes;
• Φίλτρο πρωτοκόλλου Envoy για τον Kafka, δικτυωτό.

Όταν αποφασίσετε να αναπτύξετε ένα σύμπλεγμα Kafka στο Kubernetes, πιθανότατα θα αντιμετωπίσετε την πρόκληση του προσδιορισμού του βέλτιστου μεγέθους της υποκείμενης υποδομής και της ανάγκης να τελειοποιήσετε τη διαμόρφωση του Kafka ώστε να ανταποκρίνεται στις απαιτήσεις απόδοσης. Η μέγιστη απόδοση κάθε μεσίτη καθορίζεται από την απόδοση των υποκείμενων στοιχείων υποδομής, όπως μνήμη, επεξεργαστής, ταχύτητα δίσκου, εύρος ζώνης δικτύου κ.λπ.

Στην ιδανική περίπτωση, η διαμόρφωση του μεσίτη θα πρέπει να είναι τέτοια ώστε όλα τα στοιχεία υποδομής να χρησιμοποιούνται στο μέγιστο των δυνατοτήτων τους. Ωστόσο, στην πραγματική ζωή αυτή η ρύθμιση είναι αρκετά περίπλοκη. Είναι πιο πιθανό οι χρήστες να διαμορφώσουν τους μεσίτες για να μεγιστοποιήσουν τη χρήση ενός ή δύο στοιχείων (δίσκος, μνήμη ή επεξεργαστής). Σε γενικές γραμμές, ένας μεσίτης δείχνει τη μέγιστη απόδοση όταν η διαμόρφωσή του επιτρέπει στο πιο αργό στοιχείο να χρησιμοποιηθεί στο μέγιστο βαθμό. Με αυτόν τον τρόπο μπορούμε να πάρουμε μια γενική ιδέα για το φορτίο που μπορεί να χειριστεί ένας μεσίτης.

Θεωρητικά, μπορούμε επίσης να υπολογίσουμε τον αριθμό των μεσιτών που απαιτούνται για να χειριστούν ένα δεδομένο φορτίο. Ωστόσο, στην πράξη υπάρχουν τόσες πολλές επιλογές διαμόρφωσης σε διαφορετικά επίπεδα που είναι πολύ δύσκολο (αν όχι αδύνατο) να αξιολογηθεί η πιθανή απόδοση μιας συγκεκριμένης διαμόρφωσης. Με άλλα λόγια, είναι πολύ δύσκολο να σχεδιάσετε μια διαμόρφωση με βάση κάποια δεδομένη απόδοση.

Για τους χρήστες του Supertubes, ακολουθούμε συνήθως την ακόλουθη προσέγγιση: ξεκινάμε με κάποια διαμόρφωση (υποδομή + ρυθμίσεις), μετά μετράμε την απόδοσή του, προσαρμόζουμε τις ρυθμίσεις του μεσίτη και επαναλαμβάνουμε τη διαδικασία ξανά. Αυτό συμβαίνει μέχρι να χρησιμοποιηθεί πλήρως το πιο αργό στοιχείο της υποδομής.

Με αυτόν τον τρόπο, έχουμε μια σαφέστερη ιδέα για το πόσους μεσίτες χρειάζεται ένα σύμπλεγμα για να χειριστεί ένα συγκεκριμένο φορτίο (ο αριθμός των μεσιτών εξαρτάται επίσης από άλλους παράγοντες, όπως ο ελάχιστος αριθμός αντιγράφων μηνυμάτων για να διασφαλιστεί η ανθεκτικότητα, ο αριθμός των διαμερισμάτων ηγέτες κ.λπ.). Επιπλέον, αποκτούμε μια εικόνα για το ποια στοιχεία υποδομής απαιτούν κατακόρυφη κλιμάκωση.

Αυτό το άρθρο θα μιλήσει για τα βήματα που κάνουμε για να αξιοποιήσουμε στο έπακρο τα πιο αργά στοιχεία στις αρχικές διαμορφώσεις και να μετρήσουμε την απόδοση ενός συμπλέγματος Kafka. Μια εξαιρετικά ανθεκτική διαμόρφωση απαιτεί τουλάχιστον τρεις μεσίτες που τρέχουν (min.insync.replicas=3), κατανεμημένη σε τρεις διαφορετικές ζώνες προσβασιμότητας. Για τη διαμόρφωση, την κλιμάκωση και την παρακολούθηση της υποδομής Kubernetes, χρησιμοποιούμε τη δική μας πλατφόρμα διαχείρισης εμπορευματοκιβωτίων για υβριδικά σύννεφα - Pipeline. Υποστηρίζει on-premise (γυμνό μέταλλο, VMware) και πέντε τύπους cloud (Alibaba, AWS, Azure, Google, Oracle), καθώς και οποιονδήποτε συνδυασμό αυτών.

Σκέψεις για την υποδομή και τη διαμόρφωση του συμπλέγματος Kafka

Για τα παρακάτω παραδείγματα, επιλέξαμε το AWS ως πάροχο cloud και το EKS ως διανομή Kubernetes. Μια παρόμοια διαμόρφωση μπορεί να υλοποιηθεί χρησιμοποιώντας ΠΚΕ - Διανομή Kubernetes από το Banzai Cloud, με πιστοποίηση CNCF.

δίσκος

Η Amazon προσφέρει διάφορα Τύποι όγκου EBS. Στον πυρήνα gp2 и io1 Ωστόσο, υπάρχουν μονάδες SSD για την εξασφάλιση υψηλής απόδοσης gp2 καταναλώνει συσσωρευμένες πιστώσεις (Μονάδες εισόδου/εξόδου), οπότε προτιμήσαμε τον τύπο io1, το οποίο προσφέρει σταθερή υψηλή απόδοση.

Τύποι περιπτώσεων

Η απόδοση του Kafka εξαρτάται σε μεγάλο βαθμό από την προσωρινή μνήμη σελίδων του λειτουργικού συστήματος, επομένως χρειαζόμαστε παρουσίες με αρκετή μνήμη για τους μεσίτες (JVM) και την προσωρινή μνήμη σελίδων. Παράδειγμα c5.2χρόνος - καλή αρχή, αφού διαθέτει 16 GB μνήμης και βελτιστοποιημένο για εργασία με EBS. Το μειονέκτημά του είναι ότι μπορεί να παρέχει μέγιστη απόδοση μόνο για 30 λεπτά κάθε 24 ώρες. Εάν ο φόρτος εργασίας σας απαιτεί κορυφαία απόδοση για μεγαλύτερο χρονικό διάστημα, ίσως θελήσετε να εξετάσετε άλλους τύπους παρουσιών. Αυτό ακριβώς κάναμε, σταματώντας σε αυτό c5.4χρόνος. Παρέχει μέγιστη απόδοση 593,75 Mb/s. Μέγιστη απόδοση όγκου EBS io1 υψηλότερο από το παράδειγμα c5.4χρόνος, επομένως το πιο αργό στοιχείο της υποδομής είναι πιθανό να είναι η απόδοση εισόδου/εξόδου αυτού του τύπου παρουσίας (κάτι που θα πρέπει επίσης να επιβεβαιώσουν οι δοκιμές φορτίου μας).

Δικτύου

Η απόδοση του δικτύου πρέπει να είναι αρκετά μεγάλη σε σύγκριση με την απόδοση του στιγμιότυπου και του δίσκου VM, διαφορετικά το δίκτυο γίνεται εμπόδιο. Στην περίπτωσή μας, η διεπαφή δικτύου c5.4χρόνος υποστηρίζει ταχύτητες έως και 10 Gb/s, που είναι σημαντικά υψηλότερες από την απόδοση I/O μιας παρουσίας VM.

Ανάπτυξη μεσίτη

Οι μεσίτες θα πρέπει να αναπτυχθούν (προγραμματισμένοι στο 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, ρίξτε μια ματιά στις παρακάτω αναρτήσεις μας:

• Γιατί η εφαρμογή Java μου είναι OOMKilled;
• Πώς να κάνετε σωστά το μέγεθος των κοντέινερ για εφαρμογές Java 10.

Ρυθμίσεις μνήμης μεσίτη

Υπάρχουν δύο βασικές πτυχές για τη διαμόρφωση της μνήμης μεσίτη: ρυθμίσεις για το JVM και για το pod Kubernetes. Το όριο μνήμης που έχει οριστεί για ένα pod πρέπει να είναι μεγαλύτερο από το μέγιστο μέγεθος σωρού, έτσι ώστε το JVM να έχει χώρο για τον μετα-χώρο Java που βρίσκεται στη δική του μνήμη και για τη μνήμη cache σελίδας του λειτουργικού συστήματος που χρησιμοποιεί ενεργά ο Kafka. Στις δοκιμές μας λανσάραμε τους μεσίτες Kafka με παραμέτρους -Xmx4G -Xms2G, και το όριο μνήμης για το pod ήταν 10 Gi. Λάβετε υπόψη ότι οι ρυθμίσεις μνήμης για το JVM μπορούν να ληφθούν αυτόματα χρησιμοποιώντας -XX:MaxRAMPercentage и -X:MinRAMPercentage, με βάση το όριο μνήμης για το pod.

Ρυθμίσεις επεξεργαστή μεσίτη

Σε γενικές γραμμές, μπορείτε να βελτιώσετε την απόδοση αυξάνοντας τον παραλληλισμό αυξάνοντας τον αριθμό των νημάτων που χρησιμοποιεί ο Κάφκα. Όσο περισσότεροι επεξεργαστές είναι διαθέσιμοι για τον Kafka, τόσο το καλύτερο. Στη δοκιμή μας, ξεκινήσαμε με όριο τους 6 επεξεργαστές και σταδιακά (μέσω επαναλήψεων) αυξήσαμε τον αριθμό τους στους 15. Επιπλέον, ορίσαμε num.network.threads=12 στις ρυθμίσεις μεσίτη για να αυξήσετε τον αριθμό των νημάτων που λαμβάνουν δεδομένα από το δίκτυο και τα στέλνουν. Ανακαλύπτοντας αμέσως ότι οι followers brokers δεν μπορούσαν να λάβουν αντίγραφα αρκετά γρήγορα, έθεσαν num.replica.fetchers σε 4 για να αυξηθεί η ταχύτητα με την οποία οι μεσίτες ακολούθων αναπαράγουν μηνύματα από ηγέτες.

Εργαλείο δημιουργίας φορτίου

Θα πρέπει να βεβαιωθείτε ότι η επιλεγμένη γεννήτρια φορτίου δεν εξαντληθεί από τη χωρητικότητα πριν το σύμπλεγμα Kafka (το οποίο συγκρίνεται) φτάσει στο μέγιστο φορτίο του. Με άλλα λόγια, είναι απαραίτητο να πραγματοποιηθεί μια προκαταρκτική αξιολόγηση των δυνατοτήτων του εργαλείου παραγωγής φορτίου και επίσης να επιλεγούν τύποι παρουσιών για αυτό με επαρκή αριθμό επεξεργαστών και μνήμης. Σε αυτήν την περίπτωση, το εργαλείο μας θα παράγει περισσότερο φορτίο από αυτό που μπορεί να αντέξει το σύμπλεγμα Kafka. Μετά από πολλά πειράματα, καταλήξαμε σε τρία αντίγραφα c5.4χρόνος, καθένα από τα οποία είχε μια γεννήτρια σε λειτουργία.

Συγκριτική αξιολόγηση

Η μέτρηση της απόδοσης είναι μια επαναληπτική διαδικασία που περιλαμβάνει τα ακόλουθα στάδια:

• δημιουργία υποδομής (σύμπλεγμα EKS, σύμπλεγμα Kafka, εργαλείο παραγωγής φορτίου, καθώς και Prometheus και Grafana).
• δημιουργία φορτίου για μια ορισμένη περίοδο για φιλτράρισμα τυχαίων αποκλίσεων στους δείκτες απόδοσης που συλλέγονται·
• προσαρμογή της υποδομής και της διαμόρφωσης του μεσίτη με βάση δείκτες απόδοσης που παρατηρούνται.
• επαναλαμβάνοντας τη διαδικασία μέχρι να επιτευχθεί το απαιτούμενο επίπεδο απόδοσης του συμπλέγματος Kafka. Ταυτόχρονα, πρέπει να είναι σταθερά αναπαραγώγιμη και να παρουσιάζει ελάχιστες διακυμάνσεις στην απόδοση.

Η επόμενη ενότητα περιγράφει τα βήματα που πραγματοποιήθηκαν κατά τη διαδικασία συγκριτικής αξιολόγησης συμπλέγματος δοκιμών.

Εργαλεία

Τα ακόλουθα εργαλεία χρησιμοποιήθηκαν για τη γρήγορη ανάπτυξη μιας βασικής διαμόρφωσης, τη δημιουργία φορτίων και τη μέτρηση της απόδοσης:

• Banzai Cloud Pipeline για την οργάνωση ενός συμπλέγματος EKS από την Amazon γ Προμηθέας (για τη συλλογή μετρήσεων Kafka και υποδομής) και Γκράφανα (για να οπτικοποιήσετε αυτές τις μετρήσεις). Εκμεταλλευτήκαμε ολοκληρωμένο в Pipeline υπηρεσίες που παρέχουν ενοποιημένη παρακολούθηση, κεντρική συλλογή αρχείων καταγραφής, σάρωση ευπάθειας, ανάκτηση καταστροφών, ασφάλεια εταιρικού επιπέδου και πολλά άλλα.
• Sangrenel — ένα εργαλείο για τη δοκιμή φορτίου ενός συμπλέγματος Kafka.
• Πίνακες εργαλείων Grafana για οπτικοποίηση μετρήσεων και υποδομής Kafka: Kubernetes Kafka, Εξαγωγέας κόμβων.
• Supertubes CLI για τον ευκολότερο τρόπο δημιουργίας ενός συμπλέγματος Kafka στο Kubernetes. Το Zookeeper, ο χειριστής Kafka, ο Envoy και πολλά άλλα εξαρτήματα είναι εγκατεστημένα και ρυθμισμένα κατάλληλα για να εκτελούν ένα σύμπλεγμα Kafka έτοιμο για παραγωγή στο Kubernetes.
  • Για εγκατάσταση υπερσωλήνες CLI χρησιμοποιήστε τις οδηγίες που παρέχονται εδώ.

Σύμπλεγμα EKS

Προετοιμάστε ένα σύμπλεγμα EKS με αποκλειστικούς κόμβους εργαζομένων c5.4χρόνος σε διαφορετικές ζώνες διαθεσιμότητας για pods με μεσίτες Kafka, καθώς και αποκλειστικούς κόμβους για τη γεννήτρια φορτίου και την υποδομή παρακολούθησης.

banzai cluster create -f https://raw.githubusercontent.com/banzaicloud/kafka-operator/master/docs/benchmarks/infrastructure/cluster_eks_202001.json

Μόλις το σύμπλεγμα EKS είναι σε λειτουργία και λειτουργεί, ενεργοποιήστε την ενσωμάτωσή του υπηρεσία παρακολούθησης — θα αναπτύξει τον Προμηθέα και τη Γραφάνα σε ένα σύμπλεγμα.

Στοιχεία συστήματος Kafka

Εγκαταστήστε εξαρτήματα συστήματος Kafka (Zookeeper, kafka-operator) στο EKS χρησιμοποιώντας supertubes 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 byte και τα δημοσιεύει στον Κάφκα σε παρτίδες των 500 μηνυμάτων.
• Χρησιμοποιώντας ένα όρισμα -required-acks=all Η δημοσίευση θεωρείται επιτυχής όταν όλα τα συγχρονισμένα αντίγραφα του μηνύματος ληφθούν και επιβεβαιωθούν από τους μεσίτες Kafka. Αυτό σημαίνει ότι στο σημείο αναφοράς μετρήσαμε όχι μόνο την ταχύτητα των ηγετών που λαμβάνουν μηνύματα, αλλά και των οπαδών τους που αναπαράγουν μηνύματα. Ο σκοπός αυτής της δοκιμής δεν είναι να αξιολογήσει την ταχύτητα ανάγνωσης των καταναλωτών (Καταναλωτές) πρόσφατα ληφθέντα μηνύματα που εξακολουθούν να παραμένουν στην προσωρινή μνήμη των σελίδων του λειτουργικού συστήματος και η σύγκρισή του με την ταχύτητα ανάγνωσης των μηνυμάτων που είναι αποθηκευμένα στο δίσκο.
• Η γεννήτρια φορτίου λειτουργεί 20 εργαζόμενους παράλληλα (-workers=20). Κάθε εργαζόμενος περιέχει 5 παραγωγούς που μοιράζονται τη σύνδεση του εργάτη με το σύμπλεγμα Κάφκα. Ως αποτέλεσμα, κάθε γεννήτρια έχει 100 παραγωγούς και όλοι στέλνουν μηνύματα στο σύμπλεγμα Κάφκα.

Παρακολούθηση της υγείας του συμπλέγματος

Κατά τη διάρκεια της δοκιμής φόρτωσης του συμπλέγματος Kafka, παρακολουθήσαμε επίσης την υγεία του για να διασφαλίσουμε ότι δεν υπήρχαν επανεκκινήσεις στο pod, δεν υπήρχαν μη συγχρονισμένα αντίγραφα και μέγιστη απόδοση με ελάχιστες διακυμάνσεις:

• Η γεννήτρια φορτίου γράφει τυπικά στατιστικά στοιχεία σχετικά με τον αριθμό των μηνυμάτων που δημοσιεύονται και το ποσοστό σφάλματος. Το ποσοστό σφάλματος πρέπει να παραμείνει το ίδιο 0,00%.
• Αυτόματη ταχύτητα ταξιδιού, που αναπτύσσεται από το kafka-operator, παρέχει έναν πίνακα εργαλείων όπου μπορούμε επίσης να παρακολουθούμε την κατάσταση του συμπλέγματος. Για να δείτε αυτό το πλαίσιο κάντε:

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

• Επίπεδο ISR (αριθμός αντιγράφων "σε συγχρονισμό") η συρρίκνωση και η διαστολή είναι ίσες με 0.

Αποτελέσματα μετρήσεων

3 μεσίτες, μέγεθος μηνύματος - 512 byte

Με τα διαμερίσματα ομοιόμορφα κατανεμημένα σε τρεις μεσίτες, μπορέσαμε να επιτύχουμε απόδοση ~500 Mb/s (περίπου 990 χιλιάδες μηνύματα ανά δευτερόλεπτο):

Η κατανάλωση μνήμης της εικονικής μηχανής JVM δεν ξεπέρασε τα 2 GB:

Η διεκπεραίωση του δίσκου έφτασε τη μέγιστη απόδοση κόμβου I/O και στις τρεις περιπτώσεις στις οποίες λειτουργούσαν οι μεσίτες:

Από τα δεδομένα σχετικά με τη χρήση της μνήμης από τους κόμβους, προκύπτει ότι η προσωρινή αποθήκευση και η προσωρινή αποθήκευση του συστήματος χρειάστηκαν ~10-15 GB:

3 μεσίτες, μέγεθος μηνύματος - 100 byte

Καθώς το μέγεθος του μηνύματος μειώνεται, η απόδοση μειώνεται κατά περίπου 15-20%: ο χρόνος που δαπανάται για την επεξεργασία κάθε μηνύματος το επηρεάζει. Επιπλέον, το φορτίο του επεξεργαστή έχει σχεδόν διπλασιαστεί.

Εφόσον οι κόμβοι μεσίτη εξακολουθούν να έχουν αχρησιμοποίητους πυρήνες, η απόδοση μπορεί να βελτιωθεί αλλάζοντας τη διαμόρφωση του Kafka. Αυτό δεν είναι εύκολο έργο, επομένως για να αυξήσετε την απόδοση είναι καλύτερο να εργαστείτε με μεγαλύτερα μηνύματα.

4 μεσίτες, μέγεθος μηνύματος - 512 byte

Μπορείτε εύκολα να αυξήσετε την απόδοση ενός συμπλέγματος Kafka προσθέτοντας απλώς νέους μεσίτες και διατηρώντας μια ισορροπία των κατατμήσεων (αυτό διασφαλίζει ότι το φορτίο κατανέμεται ομοιόμορφα μεταξύ των μεσιτών). Στην περίπτωσή μας, μετά την προσθήκη ενός μεσίτη, η απόδοση του συμπλέγματος αυξήθηκε σε ~580 Mb/s (~1,1 εκατομμύρια μηνύματα ανά δευτερόλεπτο). Η ανάπτυξη αποδείχθηκε μικρότερη από την αναμενόμενη: αυτό εξηγείται κυρίως από την ανισορροπία των κατατμήσεων (δεν εργάζονται όλοι οι μεσίτες στο αποκορύφωμα των δυνατοτήτων τους).

Η κατανάλωση μνήμης του μηχανήματος JVM παρέμεινε κάτω από 2 GB:

Η εργασία των μεσιτών με μονάδες δίσκου επηρεάστηκε από την ανισορροπία των κατατμήσεων:

Ευρήματα

Η επαναληπτική προσέγγιση που παρουσιάζεται παραπάνω μπορεί να επεκταθεί για να καλύψει πιο περίπλοκα σενάρια που περιλαμβάνουν εκατοντάδες καταναλωτές, επαναδιαμερισμό, κυλιόμενες ενημερώσεις, επανεκκινήσεις pod κ.λπ. Όλα αυτά μας επιτρέπουν να αξιολογήσουμε τα όρια των δυνατοτήτων του συμπλέγματος Κάφκα σε διάφορες συνθήκες, να εντοπίσουμε τα σημεία συμφόρησης στη λειτουργία του και να βρούμε τρόπους για την καταπολέμησή τους.

Σχεδιάσαμε το Supertubes για να αναπτύσσει γρήγορα και εύκολα ένα σύμπλεγμα, να το διαμορφώνει, να προσθέτει/αφαιρεί μεσίτες και θέματα, να ανταποκρίνεται σε ειδοποιήσεις και να διασφαλίζει ότι ο Kafka γενικά λειτουργεί σωστά στο Kubernetes. Στόχος μας είναι να σας βοηθήσουμε να συγκεντρωθείτε στην κύρια εργασία ("δημιουργία" και "κατανάλωση" μηνυμάτων Kafka) και να αφήσετε όλη τη σκληρή δουλειά στη Supertubes και στον χειριστή του Kafka.

Εάν ενδιαφέρεστε για τεχνολογίες Banzai Cloud και έργα ανοιχτού κώδικα, εγγραφείτε στην εταιρεία στο GitHub, LinkedIn ή Twitter.

ΥΓ από τον μεταφραστή

Διαβάστε επίσης στο blog μας:

• «Μια ιστορία με τον χειριστή Redis στα K8s και μια μίνι ανασκόπηση των βοηθητικών προγραμμάτων για την ανάλυση δεδομένων από αυτήν τη βάση δεδομένων"?
• «Ομαλή μετανάστευση του RabbitMQ στο Kubernetes"?
• «zetcd από το CoreOS: Αντικατάσταση του ZooKeeper με χώρο αποθήκευσης...etcd».

Πηγή: www.habr.com