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 Langlebigkeit vorkonfiguriert. Ihre Daten sind standardmäßig auf drei Availability Zones verteilt. Die Replikation ist immer auf 3 und die Mindestanzahl der synchronisierten Replikate 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.
Client-side Überlegungen
Die Verfügbarkeit und Leistung Ihrer Anwendung hängt nicht nur von den serverseitigen Einstellungen ab, sondern auch von den Client-Einstellungen.
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. Broker gehen sowohl bei geplanten als auch bei ungeplanten Ereignissen wie Upgrades, Patches, Hardwareausfällen und Netzwerkproblemen offline. Ein Kafka-Cluster ist tolerant gegenüber einem Offline-Broker, daher müssen Kafka-Clients auch das Broker-Failover ordnungsgemäß handhaben. Alle Einzelheiten 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 zu erreichen, auch wenn wir Broker bei Spitzenauslastung neu starten. Sie können Broker in Ihrem Cluster über die MSK-Konsole oder mithilfe der MSK-APIs neu starten.
Server-side Überlegungen
Themen
Right-size Ihr Cluster: Anzahl der Broker pro Cluster
Die Auswahl der Anzahl der Broker für Ihren Express-based Cluster ist einfach. Jeder Express-Broker verfügt über eine definierte Durchsatzkapazität für den Ein- und Ausgang. Sie sollten diese Durchsatzkapazität als primäres Mittel für die Dimensionierung Ihres Clusters verwenden (und dann andere Faktoren wie die Anzahl der Partitionen und Verbindungen berücksichtigen, die unten beschrieben werden).
Wenn Ihre Streaming-Anwendung beispielsweise 45 MBit/s Dateneingangskapazität (Schreiben) und 90 MBit/s Datenausgangskapazität (Lesen) benötigt, können Sie einfach 3 express.m7g.large Broker verwenden, um Ihre Durchsatzanforderungen zu erfüllen. Jeder express.m7g.large-Broker verarbeitet 15 MBit/s eingehenden und 30 MBit/s ausgehenden Datenverkehr. In der folgenden Tabelle finden Sie unsere empfohlenen Durchsatzlimits für jede Express-Brokergröße. Wenn Ihr Durchsatz die empfohlenen Grenzwerte überschreitet, kann es zu Leistungseinbußen kommen. Sie sollten Ihren Datenverkehr reduzieren oder Ihren Cluster skalieren. Wenn Ihr Durchsatz die empfohlenen Grenzwerte überschreitet und das Kontingent pro Broker erreicht, drosselt MSK Ihren Client-Verkehr, um eine weitere Überlastung zu verhindern.
Sie können auch unsere Tabelle zur Größenbestimmung und Preisgestaltung von
In der folgenden Tabelle ist der empfohlene maximale Durchsatz pro Broker für jede Instance-Größe aufgeführt.
| Instance-Größe | Eingang (MBit/s) | Ausgang (MBit/s) |
|---|---|---|
|
|
15,6 | 31.2 |
|
|
31,2 | 62,5 |
|
|
62,5 | 125,0 |
|
|
124,9 | 249,8 |
|
|
250,0 | 500,0 |
|
|
375,0 | 750,0 |
|
|
500,0 | 1000,0 |
CPU-Auslastung überwachen
Wir empfehlen, dass Sie die gesamte CPU-Auslastung für Ihre Broker (definiert als CPU-Benutzer und CPU-System) unter 60% halten. Wenn mindestens 40 % der gesamten CPU Ihres Clusters verfügbar sind, kann Apache Kafka die CPU-Last bei Bedarf auf die Broker im Cluster verteilen. Dies kann aufgrund geplanter oder ungeplanter Ereignisse erforderlich sein. Ein Beispiel für ein geplantes Ereignis ist ein Cluster-Versions-Upgrade, bei dem MSK die Broker in einem Cluster aktualisiert, 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 einem AZ betroffen sind. Wenn Broker mit Partitions-Lead-Replikaten offline gehen, weist Apache Kafka die Partitionsleitung neu zu, um die Arbeit an andere Broker im Cluster weiterzuverteilen. Wenn Sie sich an diese bewährte Methode halten, können Sie sicherstellen, dass Ihr Cluster über genügend CPU-Reserven verfügt, um Betriebsereignisse wie diese zu tolerieren.
Im CloudWatch Amazon-Benutzerhandbuch können Sie mithilfe von mathematischen Ausdrücken mit CloudWatch Metriken eine zusammengesetzte Metrik erstellen, die CPU-Benutzer und 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 Brokergröße auf die nächstgrößere Größe. Denken Sie daran, dass Amazon MSK bei der Aktualisierung der Brokergröße im Cluster die Broker fortlaufend offline nimmt und vorübergehend anderen Brokern die Führung der Partition zuweist.
Option 2: Erweitern Sie Ihren Cluster, indem Sie Broker hinzufügen, und weisen Sie dann vorhandene Partitionen mithilfe des oben genannten Tools zur Partitionsneuzuweisung neu zu.
kafka-reassign-partitions.sh
Weitere Empfehlungen
Überwachen Sie die gesamte CPU-Auslastung pro Broker als Proxy für die Lastverteilung. Wenn Broker eine durchweg ungleichmäßige CPU-Auslastung haben, kann dies ein Zeichen dafür sein, dass die Last innerhalb des Clusters nicht gleichmäßig verteilt ist. Wir empfehlen, Cruise Control zu verwenden, um die Lastverteilung über die Partitionszuweisung kontinuierlich zu verwalten.
Überwachen Sie die Latenz bei Produktion und Verbrauch. Die Latenz bei Produktion und Verbrauch kann linear mit der CPU-Auslastung zunehmen.
JMX-Scrape-Intervall: Wenn Sie Open Monitoring mit der Prometheus-Funktion aktivieren, wird empfohlen, für Ihre Prometheus-Host-Konfiguration () ein Scrape-Intervall von 60 Sekunden oder mehr (
scrape_interval: 60s) zu verwenden.prometheus.ymlEine Verkürzung des Scrape-Intervalls kann zu einer hohen CPU-Auslastung in Ihrem Cluster führen.
Right-size Ihr Cluster: Anzahl der Partitionen pro Express-Broker
Wenn Sie Anwendungsfälle mit hoher Partition und niedrigem Durchsatz haben, in denen Sie eine höhere Partitionsanzahl haben, aber nicht den Datenverkehr über alle Partitionen senden, können Sie mehr Partitionen pro Broker packen, sofern Sie ausreichend Tests und Leistungstests durchgeführt haben, um sicherzustellen, dass Ihr Cluster auch bei der höheren Partitionsanzahl fehlerfrei bleibt. Wenn die Anzahl der Partitionen pro Broker den maximal zulässigen Wert überschreitet und Ihr Cluster überlastet wird, können Sie die folgenden Vorgänge nicht ausführen:
-
Die Cluster-Konfiguration aktualisieren
-
Aktualisieren Sie den Cluster auf eine kleinere Brokergröße
-
Ordnen Sie einem Cluster, der über eine SASL/SCRAM Authentifizierung verfügt, ein AWS Secrets Manager Geheimnis zu
Ein Cluster, der mit einer hohen Anzahl von Partitionen überlastet ist, kann auch dazu führen, dass Kafka-Metriken auf CloudWatch und bei Prometheus-Scraping fehlen. Dieser Effekt wird durch eine hohe Anzahl von Nutzergruppen verstärkt, da jede Kombination aus Verbrauchergruppe, Thema und Partition zu einem nachverfolgten Offset-Eintrag führt. Leere Verbrauchergruppen (Gruppen ohne aktive Verbraucher) tragen ebenfalls zu diesem Overhead bei. Apache Kafka behält die Offsets für diese Gruppen bei, bis der durch definierte Aufbewahrungszeitraum offsets.retention.minutes abläuft oder bis Sie die Gruppe explizit löschen. Um dem entgegenzuwirken, sollten Sie die Gesamtzahl Ihrer Verbrauchergruppen überwachen und ungenutzte Verbrauchergruppen löschen.
Eine Anleitung zur Auswahl der Anzahl der Partitionen finden Sie unter Apache Kafka unterstützt 200K Partitionen pro Cluster
Hinweise zur empfohlenen Anzahl von Partitionen (einschließlich Leader- und Follower-Replikaten) für jeden Express-Broker finden Sie unter. Partitionskontingent für 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.
Überwachen Sie die Anzahl der Verbindungen
Die Client-Verbindungen zu Ihren Brokern verbrauchen Systemressourcen wie Speicher und CPU. 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 einer Sekunde erneut versucht, Verbindungen herzustellen, setzen Sie den Wert reconnect.backoff.ms auf1000. Weitere Informationen zur Konfiguration von Wiederholungsversuchen finden Sie in der Apache Kafka-Dokumentation.
| Dimension | Kontingent |
|---|---|
|
Maximale TCP-Verbindungen pro Broker (IAM Access Control) |
3000 |
|
Maximale TCP-Verbindungen pro Broker (IAM) |
100 pro Sekunde |
|
Maximale TCP-Verbindungen pro Broker (ohne IAM) |
MSK erzwingt keine Verbindungslimits für Nicht-IAM-Authentifizierung. Sie sollten jedoch andere Messwerte wie die CPU- und Speicherauslastung überwachen, um sicherzustellen, dass Sie Ihren Cluster nicht aufgrund übermäßiger Verbindungen überlasten. |
Neuzuweisung von Partitionen
Um Partitionen auf verschiedene Broker auf demselben von MSK Provisioned bereitgestellten Cluster zu verschieben, können Sie das Tool für die Neuzuweisung von Partitionen mit dem Namen verwenden. kafka-reassign-partitions.sh Wir empfehlen, nicht mehr als 20 Partitionen in einem einzigen kafka-reassign-partitions Aufruf neu zuzuweisen, um einen sicheren Betrieb zu gewährleisten. Nachdem Sie beispielsweise neue Broker hinzugefügt haben, um einen Cluster zu erweitern oder Partitionen zu verschieben, um Broker zu entfernen, können Sie den Cluster neu verteilen, indem Sie den neuen Brokern Partitionen neu zuweisen. Informationen zum Hinzufügen von Brokern zu einem von MSK bereitgestellten Cluster finden Sie unter. Erweitern Sie die Anzahl der Broker in einem Amazon MSK-Cluster Informationen zum Entfernen von Brokern aus einem von MSK bereitgestellten Cluster finden Sie unter. Einen Broker aus einem Amazon-MSK-Cluster entfernen Informationen zum Tool zur Neuzuweisung von Partitionen finden Sie unter Expanding your cluster
