Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Bewährte Methoden für Express-Broker
In diesem Thema werden einige bewährte Methoden beschrieben, die Sie bei der Verwendung von Express-Brokern beachten sollten. Express-Broker sind für hohe Verfügbarkeit und Haltbarkeit vorkonfiguriert. Ihre Daten sind standardmäßig auf drei Availability Zones verteilt, die Replikation ist immer auf 3 festgelegt und die Mindestanzahl an synchronisierten Replikaten ist immer auf 2 festgelegt. Es müssen jedoch noch einige Faktoren berücksichtigt werden, um die Zuverlässigkeit und Leistung Ihres Clusters zu optimieren.
Überlegungen auf Kundenseite
Die Verfügbarkeit und Leistung Ihrer Anwendung hängt nicht nur von den serverseitigen Einstellungen, sondern auch von den Client-Einstellungen ab.
Konfigurieren Sie Ihre Clients für hohe Verfügbarkeit. In einem verteilten System wie Apache Kafka ist die Sicherstellung einer hohen Verfügbarkeit entscheidend für die Aufrechterhaltung einer zuverlässigen und fehlertoleranten Messaging-Infrastruktur. Makler werden sowohl bei geplanten als auch bei ungeplanten Ereignissen wie Upgrades, Patches, Hardwareausfällen und Netzwerkproblemen offline gehen. Ein Kafka-Cluster ist tolerant gegenüber Offline-Brokern, daher müssen Kafka-Clients auch Broker-Failover ordnungsgemäß handhaben. Vollständige Informationen finden Sie in den Best-Practice-Empfehlungen für Apache Kafka-Kunden.
Führen Sie Leistungstests durch, um zu überprüfen, ob Ihre Client-Konfigurationen es Ihnen ermöglichen, Ihre Leistungsziele auch dann zu erreichen, wenn wir Broker bei Spitzenlast neu starten. Sie können Broker in Ihrem Cluster von der MSK Konsole aus oder mit dem neu starten MSKAPIs.
Serverseitige Überlegungen
Die Größe Ihres Clusters anpassen: Anzahl der Broker pro Cluster
Die Auswahl der Anzahl der Broker für Ihren Express-basierten Cluster ist einfach. Jeder Express-Broker verfügt über eine definierte Durchsatzkapazität für ein- und ausgehenden Datenverkehr. Sie sollten diese Durchsatzkapazität als primäres Mittel für die Dimensionierung Ihres Clusters verwenden (und dann andere Faktoren wie Partitionen und Verbindungsanzahl berücksichtigen, die weiter unten erörtert werden).
Wenn Ihre Streaming-Anwendung beispielsweise 45% MBps Dateneingangs- (Schreib-) und 90% MBps Datenausgangskapazität (Lesen) benötigt, können Sie einfach 3 express.m7g.large Broker verwenden, um Ihren Durchsatzbedarf zu decken. Jeder express.m7g.large Broker verarbeitet 15% eingehenden und 30 ausgehenden Datenverkehr. MBps MBps In der folgenden Tabelle finden Sie unsere empfohlenen Durchsatzgrenzen für jede Express-Broker-Größe. Wenn Ihr Durchsatz die empfohlenen Grenzwerte überschreitet, kann es zu Leistungseinbußen kommen und Sie sollten Ihren Datenverkehr reduzieren oder Ihren Cluster skalieren. Wenn Ihr Durchsatz die empfohlenen Grenzwerte überschreitet und das Kontingent pro Broker erreicht, MSK wird Ihr Client-Verkehr gedrosselt, um eine weitere Überlastung zu verhindern.
Sie können auch unsere Tabelle „MSKGröße und Preise
| Instance-Größe | Eingang () MBps | Ausgang () MBps |
|---|---|---|
|
|
15.6 | 31,2 |
|
|
124,9 | 249,8 |
|
|
500,0 | 1000,0 |
Nutzung überwachen CPU
Wir empfehlen Ihnen, die CPU Gesamtauslastung Ihrer Broker (definiert als CPU Benutzer und CPU System) unter 60% zu halten. Wenn mindestens 40% der Gesamtkapazität Ihres Clusters CPU verfügbar sind, kann Apache Kafka die CPU Last bei Bedarf auf die Broker im Cluster verteilen. Dies kann aufgrund von geplanten oder ungeplanten Ereignissen erforderlich sein. Ein Beispiel für ein geplantes Ereignis ist ein Upgrade der Cluster-Version, bei dem die Broker in einem Cluster MSK aktualisiert werden, indem sie nacheinander neu gestartet werden. Ein Beispiel für ein ungeplantes Ereignis ist ein Hardwarefehler in einem Broker oder, im schlimmsten Fall, ein AZ-Ausfall, bei dem alle Broker in einer AZ betroffen sind. Wenn Broker mit Partitionsleitreplikaten offline gehen, weist Apache Kafka die Partitionsleitung neu zu, um die Arbeit auf andere Broker im Cluster umzuverteilen. Wenn Sie diese bewährte Methode befolgen, können Sie sicherstellen, dass Ihr Cluster über genügend CPU Spielraum verfügt, um betriebliche Ereignisse wie diese zu tolerieren.
Sie können die Verwendung von mathematischen Ausdrücken mit CloudWatch Metriken im CloudWatch Amazon-Benutzerhandbuch verwenden, um eine zusammengesetzte Metrik zu erstellen, die CPU Benutzer + CPU System lautet. Stellen Sie einen Alarm ein, der ausgelöst wird, wenn die zusammengesetzte Metrik eine durchschnittliche CPU Auslastung von 60% erreicht. Wenn dieser Alarm ausgelöst wird, skalieren Sie den Cluster mit einer der folgenden Optionen:
Option 1: Aktualisieren Sie Ihre Broker-Größe auf die nächstgrößere Größe. Denken Sie daran, dass Amazon, wenn Sie die Broker-Größe im Cluster aktualisieren, die Broker fortlaufend offline MSK nimmt und die Partitionsleitung vorübergehend anderen Brokern zuweist.
Option 2: Erweitern Sie Ihren Cluster, indem Sie Broker hinzufügen und anschließend vorhandene Partitionen mithilfe des Tools zur Neuzuweisung von Partitionen mit dem Namen neu zuweisen.
kafka-reassign-partitions.sh
Andere Empfehlungen
Überwachen Sie die CPU Gesamtauslastung pro Broker als Proxy für die Lastverteilung. Wenn Broker durchweg ungleichmäßig CPU ausgelastet sind, kann dies ein Zeichen dafür sein, dass die Last innerhalb des Clusters nicht gleichmäßig verteilt ist. Wir empfehlen die Verwendung von Cruise Control, um die Lastverteilung mithilfe von Partitionszuweisungen kontinuierlich zu verwalten.
Überwachen Sie die Latenz bei Produktion und Verbrauch. Die Latenz bei Produktion und Verbrauch kann linear mit CPU der Auslastung zunehmen.
JMXScrape-Intervall: Wenn Sie die offene Überwachung mit der Prometheus-Funktion aktivieren, wird empfohlen, für Ihre Prometheus-Host-Konfiguration () ein Scrape-Intervall von 60 Sekunden oder höher (
scrape_interval: 60s) zu verwenden.prometheus.ymlEine Verkürzung des Scrape-Intervalls kann zu einer hohen Auslastung Ihres Clusters führen. CPU
Passen Sie die Größe Ihres Clusters an: Anzahl der Partitionen pro Express-Broker
Die folgende Tabelle zeigt die empfohlene Anzahl von Partitionen (einschließlich Leader- und Follower-Replikaten) pro Express-Broker. Die empfohlene Anzahl von Partitionen wird nicht durchgesetzt und ist eine bewährte Methode für Szenarien, in denen Sie Datenverkehr über alle bereitgestellten Themenpartitionen senden.
| Größe des Brokers | Empfohlene maximale Anzahl von Partitionen (einschließlich Leader- und Follower-Replikate) pro Broker | Maximale Anzahl von Partitionen, die Aktualisierungsvorgänge unterstützen |
|---|---|---|
|
|
1000 | 1500 |
|
|
4000 | 6 000 |
Wenn Sie Anwendungsfälle mit hoher Partition und geringem Durchsatz haben, bei denen Sie zwar eine höhere Partitionsanzahl haben, aber keinen Datenverkehr über alle Partitionen senden, können Sie mehr Partitionen pro Broker packen, sofern Sie ausreichend Tests und Leistungstests durchgeführt haben, um zu überprüfen, ob Ihr Cluster auch bei der höheren Partitionszahl fehlerfrei bleibt. Wenn die Anzahl der Partitionen pro Broker den maximal zulässigen Wert überschreitet und Ihr Cluster überlastet ist, können Sie die folgenden Vorgänge nicht ausführen:
-
Die Cluster-Konfiguration aktualisieren
-
Aktualisieren Sie den Cluster auf eine kleinere Broker-Größe
-
Ordnen Sie einem Cluster mit SASL SCRAM /-Authentifizierung ein AWS Secrets Manager Geheimnis zu
Ein mit einer hohen Anzahl von Partitionen überlasteter Cluster kann auch dazu führen, dass Kafka-Metriken beim CloudWatch und beim Prometheus-Scraping fehlen.
Eine Anleitung zur Auswahl der Anzahl der Partitionen finden Sie unter Apache Kafka unterstützt 200K Partitionen pro Cluster
Überwachen Sie die Anzahl der Verbindungen
Die Client-Verbindungen zu Ihren Brokern verbrauchen Systemressourcen wie Speicher undCPU. Abhängig von Ihrem Authentifizierungsmechanismus sollten Sie überwachen, ob Sie die geltenden Grenzwerte einhalten. Um Wiederholungsversuche bei fehlgeschlagenen Verbindungen zu verarbeiten, können Sie den Konfigurationsparameter reconnect.backoff.ms auf der Client-Seite festlegen. Wenn Sie beispielsweise möchten, dass ein Client nach 1 Sekunde erneut versucht, Verbindungen herzustellen, stellen Sie reconnect.backoff.ms auf 1000 ein. Weitere Informationen zur Konfiguration von Wiederholungsversuchen finden Sie in der Apache Kafka-Dokumentation.
| Dimension | Kontingent |
|---|---|
|
Maximale Anzahl an TCP Verbindungen pro Broker (IAMZugriffskontrolle) |
3000 |
|
Maximale Anzahl TCP Verbindungen pro Broker (IAM) |
100 pro Sekunde |
|
Maximale Anzahl TCP Verbindungen pro Broker (nicht-IAM) |
MSKerzwingt keine Verbindungslimits bei IAM Nichtauthentifizierung. Sie sollten jedoch andere Messwerte wie die CPU Speicherauslastung überwachen, um sicherzustellen, dass Sie Ihren Cluster nicht aufgrund übermäßiger Verbindungen überlasten. |
