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 Standard-Broker
In diesem Thema werden einige bewährte Methoden beschrieben, die Sie bei der Verwendung von Amazon beachten solltenMSK. Informationen zu den Best Practices von Amazon MSK Replicator finden Sie unterBewährte Methoden für die Verwendung von MSK Replicator.
Ü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. Die vollständigen Informationen finden Sie unter. Bewährte Methoden für Apache Kafka-Kunden
-
Stellen Sie sicher, dass die Client-Verbindungszeichenfolgen mindestens einen Broker aus jeder Availability Zone enthalten. Die Verwendung mehrerer Broker in der Verbindungszeichenfolge eines Clients ermöglicht ein Failover, wenn ein bestimmter Broker für ein Update offline ist. Weitere Informationen zum Abrufen einer Verbindungszeichenfolge mit mehreren Brokern finden Sie unter Holen Sie sich die Bootstrap-Broker für einen Amazon-Cluster MSK.
-
Führen Sie Leistungstests durch, um zu überprüfen, ob Ihre Client-Konfigurationen es Ihnen ermöglichen, Ihre Leistungsziele zu erreichen.
Serverseitige Überlegungen
Passen Sie die Größe Ihres Clusters an: Anzahl der Partitionen pro Standard-Broker
Die folgende Tabelle zeigt die empfohlene Anzahl von Partitionen (einschließlich Leader- und Follower-Replikaten) pro Standard-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 |
|---|---|---|
kafka.t3.small |
300 | 300 |
kafka.m5.large oder kafka.m5.xlarge |
1000 | 1500 |
kafka.m5.2xlarge |
2000 | 3000 |
kafka.m5.4xlarge, kafka.m5.8xlarge, kafka.m5.12xlarge, kafka.m5.16xlarge oder kafka.m5.24xlarge |
4000 | 6 000 |
kafka.m7g.large oder kafka.m7g.xlarge |
1000 | 1500 |
kafka.m7g.2xlarge |
2000 | 3000 |
kafka.m7g.4xlarge, kafka.m7g.8xlargekafka.m7g.12xlarge, oder kafka.m7g.16xlarge |
4000 | 6 000 |
Wenn Sie Anwendungsfälle mit hoher Partition und geringem Durchsatz haben, bei denen Sie zwar mehr Partitionen 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 sicherzustellen, dass Ihr Cluster auch bei der höheren Partitionszahl fehlerfrei bleibt. Wenn die Anzahl der Partitionen pro Broker den zulässigen Höchstwert ü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
Eine hohe Anzahl von Partitionen 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
Passen Sie die Größe Ihres Clusters an: Anzahl der Standard-Broker pro Cluster
Informationen zur Bestimmung der richtigen Anzahl von Standard-Brokern für Ihren MSK bereitgestellten Cluster und zu den Kosten finden Sie in der Tabelle MSKGröße und Preisgestaltung
Informationen darüber, wie sich die zugrunde liegende Infrastruktur auf die Leistung von Apache Kafka auswirkt, finden Sie im Big Data-Blog unter Bewährte Methoden für die richtige Dimensionierung Ihrer Apache Kafka-Cluster zur Optimierung von Leistung und Kosten
Optimieren Sie den Cluster-Durchsatz für m5.4xl-, m7g.4xl- oder größere Instances
Wenn Sie m5.4xl-, m7g.4xl- oder größere Instances verwenden, können Sie den Durchsatz des bereitgestellten Clusters optimieren, indem Sie die Konfigurationen num.io.threads und num.network.threads optimieren. MSK
num.io.Threads ist die Anzahl der Threads, die ein Standardbroker für die Verarbeitung von Anfragen verwendet. Durch das Hinzufügen weiterer Threads bis zur Anzahl der für die Instanzgröße unterstützten CPU Kerne kann der Clusterdurchsatz verbessert werden.
num.network.Threads ist die Anzahl der Threads, die der Standard-Broker für den Empfang aller eingehenden Anfragen und die Rückgabe von Antworten verwendet. Netzwerk-Threads platzieren eingehende Anfragen in einer Anforderungswarteschlange zur Verarbeitung durch io.threads. Wenn num.network.threads auf die Hälfte der Anzahl der für die Instanzgröße unterstützten CPU Kerne festgelegt wird, kann die neue Instanzgröße voll genutzt werden.
Wichtig
Erhöhen Sie num.network.threads nicht, ohne zuerst num.io.threads zu erhöhen, da dies zu einer Überlastung der Warteschlange führen kann.
| Instance-Größe | Empfohlener Wert für num.io.threads | Empfohlener Wert für num.network.threads |
|---|---|---|
|
m5.4xl |
16 |
8 |
|
m5.8xl |
32 |
16 |
|
m5.12xl |
48 |
24 |
|
m5.16xl |
64 |
32 |
|
m5.24xl |
96 |
48 |
|
m7g.4xlarge |
16 |
8 |
|
m7g.8xlarge |
32 |
16 |
|
m7g.12xlarge |
48 |
24 |
|
m7g.16xlarge |
64 |
32 |
Verwenden Sie die neueste Version von Kafka, um Probleme mit nicht übereinstimmenden AdminClient Themen-IDs zu vermeiden
Die ID eines Themas geht verloren (Fehler: stimmt nicht mit der Themen-ID für die Partition überein), wenn Sie eine AdminClient Kafka-Version unter 2.8.0 mit der Markierung verwenden, --zookeeper um Themenpartitionen für einen MSK bereitgestellten Cluster mit Kafka-Version 2.8.0 oder höher zu erhöhen oder neu zuzuweisen. Beachten Sie, dass das Flag --zookeeper in Kafka 2.5 veraltet ist und ab Kafka 3.0 entfernt wird. Siehe Aktualisieren von einer beliebigen Version 0.8.x bis 2.4.x auf 2.5.0
Um eine Nichtübereinstimmung der Themen-IDs zu vermeiden, verwenden Sie einen Kafka-Client der Version 2.8.0 oder höher für Kafka-Admin-Vorgänge. Alternativ können Clients 2.5 und höher das Flag --bootstrap-servers anstelle des Flags --zookeeper verwenden.
Erstellen hochverfügbarer Cluster
Verwenden Sie die folgenden Empfehlungen, damit Ihre MSK bereitgestellten Cluster während eines Updates (z. B. wenn Sie die Broker-Größe oder die Apache Kafka-Version aktualisieren) oder wenn Amazon MSK einen Broker ersetzt, hochverfügbar sind.
-
Richten Sie einen Drei-AZ-Cluster ein.
-
Stellen Sie sicher, dass der Replikationsfaktor (RF) mindestens 3 beträgt. Beachten Sie, dass ein RF von 1 während eines fortlaufenden Updates zu Offline-Partitionen führen kann und ein RF von 2 zu Datenverlust führen kann.
-
Stellen Sie die Mindestanzahl synchronisierter Replikate (min.ISR) auf höchstens RF — 1 ein. Ein MindestwertISR, der der RF entspricht, kann verhindern, dass während eines fortlaufenden Updates eine Produktion für den Cluster erfolgt. Bei einem ISR Mindestwert von 2 sind dreifach replizierte Themen verfügbar, wenn ein Replikat offline ist.
CPUÜberwachen Sie die Nutzung
Amazon empfiehlt MSK dringend, die CPU Gesamtauslastung Ihrer Makler (definiert alsCPU User + 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. Ein Beispiel dafür, wann dies erforderlich ist, ist, wenn Amazon einen Brokerfehler MSK erkennt und diesen behebt. In diesem Fall MSK führt Amazon automatische Wartungsarbeiten wie Patches durch. Ein anderes Beispiel ist, wenn ein Benutzer eine Änderung der Brokergröße oder ein Versionsupgrade anfordert. In diesen beiden Fällen MSK stellt Amazon fortlaufende Workflows bereit, bei denen jeweils ein Broker offline geschaltet wird. Wenn Broker mit Lead-Partitionen 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 Amazon CloudWatch Metric Math verwenden, um eine zusammengesetzte Metrik zu erstellen, die CPU User + CPU System 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 (empfohlen): Aktualisieren Sie Ihre Broker-Größe auf die nächsthöhere Größe. Wenn die aktuelle Größe beispielsweise lautet
kafka.m5.large, aktualisieren Sie den zu verwendenden Clusterkafka.m5.xlarge. Denken Sie daran, dass Amazon, wenn Sie die Broker-Größe im Cluster aktualisieren, die Broker fortlaufend offline MSK nimmt und vorübergehend die Partitionsführung anderen Brokern zuweist. Eine Größenaktualisierung dauert in der Regel 10–15 Minuten pro Broker. -
Option 2: Wenn es Themen gibt, in denen alle Nachrichten von Produzenten aufgenommen wurden, die Round-Robin-Schreibvorgänge verwenden (mit anderen Worten, Nachrichten sind nicht verschlüsselt und die Reihenfolge ist für Verbraucher nicht wichtig), erweitern Sie Ihren Cluster, indem Sie Broker hinzufügen. Fügen Sie außerdem Partitionen zu vorhandenen Themen mit dem höchsten Durchsatz hinzu. Verwenden Sie als Nächstes
kafka-topics.sh --describe, um sicherzustellen, dass neu hinzugefügte Partitionen den neuen Brokern zugewiesen werden. Der Hauptvorteil dieser Option im Vergleich zur vorherigen Option besteht darin, dass Sie Ressourcen und Kosten detaillierter verwalten können. Darüber hinaus können Sie diese Option verwenden, wenn die CPU Auslastung deutlich über 60% liegt, da diese Form der Skalierung in der Regel nicht zu einer erhöhten Belastung vorhandener Broker führt. -
Option 3: Erweitern Sie Ihren MSK bereitgestellten Cluster, indem Sie Broker hinzufügen, und weisen Sie dann vorhandene Partitionen mithilfe des Tools zur Neuzuweisung von Partitionen neu zu.
kafka-reassign-partitions.shWenn Sie diese Option verwenden, muss der Cluster jedoch Ressourcen aufwenden, um Daten von Broker zu Broker zu replizieren, nachdem Partitionen neu zugewiesen wurden. Im Vergleich zu den beiden vorherigen Optionen kann dies die Belastung des Clusters zunächst erheblich erhöhen. Aus diesem Grund empfiehlt Amazon, diese Option MSK nicht zu verwenden, wenn die CPU Auslastung über 70% liegt, da die Replikation zusätzliche CPU Last und zusätzlichen Netzwerkverkehr verursacht. Amazon empfiehlt, diese Option MSK nur zu verwenden, wenn die beiden vorherigen Optionen nicht durchführbar sind.
Weitere 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 über die Partitionszuweisung 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 (prometheus.yml) ein Scrape-Intervall von 60 Sekunden oder höher (scrape_interval: 60 s) zu verwenden. Eine Verkürzung des Scrape-Intervalls kann zu einer hohen Auslastung Ihres Clusters führen. CPU
Überwachen der Festplattenkapazität
Um zu verhindern, dass der Speicherplatz für Nachrichten knapp wird, erstellen Sie einen CloudWatch Alarm, der die KafkaDataLogsDiskUsed Metrik überwacht. Wenn der Wert dieser Metrik 85 % erreicht oder überschreitet, führen Sie eine oder mehrere der folgenden Aktionen aus:
-
Verwenden Sie Automatische Skalierung für MSK Amazon-Cluster. Sie können den Broker-Speicher auch manuell erhöhen, wie unter Manuelle Skalierung für Standard-Broker beschrieben.
-
Verringern Sie den Aufbewahrungszeitraum für Nachrichten oder die Protokollgröße. Weitere Informationen hierzu finden Sie unter Anpassen der Datenaufbewahrungsparameter.
-
Löschen Sie nicht verwendete Themen.
Informationen zur Einrichtung und Verwendung von Alarmen finden Sie unter Amazon CloudWatch Alarms verwenden. Eine vollständige Liste der MSK Amazon-Metriken finden Sie unterÜberwachen Sie einen von Amazon MSK bereitgestellten Cluster.
Anpassen der Datenaufbewahrungsparameter
Durch die Verwendung von Nachrichten werden diese nicht aus dem Protokoll entfernt. Um regelmäßig Speicherplatz freizugeben, können Sie explizit einen Aufbewahrungszeitraum angeben, d. h., wie lange Nachrichten im Protokoll verbleiben. Sie können auch eine Größe für das Aufbewahrungsprotokoll angeben. Wenn entweder der Aufbewahrungszeitraum oder die Größe des Aufbewahrungsprotokolls erreicht ist, beginnt Apache Kafka, inaktive Segmente aus dem Protokoll zu entfernen.
Zum Angeben einer Aufbewahrungsrichtlinie auf Clusterebene legen Sie einen oder mehrere der folgenden Parameter fest: log.retention.hours, log.retention.minutes, log.retention.ms oder log.retention.bytes. Weitere Informationen finden Sie unter Benutzerdefinierte MSK Amazon-Konfigurationen.
Sie können Aufbewahrungsparameter auch auf Themenebene angeben:
-
Verwenden Sie den folgenden Befehl, um einen Aufbewahrungszeitraum pro Thema anzugeben.
kafka-configs.sh --bootstrap-server $bs --alter --entity-type topics --entity-nameTopicName--add-config retention.ms=DesiredRetentionTimePeriod -
Verwenden Sie den folgenden Befehl, um eine Aufbewahrungsprotokollgröße pro Thema anzugeben.
kafka-configs.sh --bootstrap-server $bs --alter --entity-type topics --entity-nameTopicName--add-config retention.bytes=DesiredRetentionLogSize
Die auf Themenebene angegebenen Aufbewahrungsparameter haben Vorrang vor Parametern auf Clusterebene.
Beschleunigung der Protokollwiederherstellung nach einem unsauberen Herunterfahren
Nach einem unsauberen Herunterfahren kann es eine Weile dauern, bis ein Broker neu gestartet wird, da er die Protokollwiederherstellung durchführt. Standardmäßig verwendet Kafka nur einen einzigen Thread pro Protokollverzeichnis, um diese Wiederherstellung durchzuführen. Wenn Sie beispielsweise Tausende von Partitionen haben, kann die Protokollwiederherstellung Stunden dauern. Um die Protokollwiederherstellung zu beschleunigen, wird empfohlen, die Anzahl der Threads mithilfe der Konfigurationseigenschaft num.recovery.threads.per.data.dir zu erhöhen. Sie können es auf die Anzahl der CPU Kerne einstellen.
Apache-Kafka-Arbeitsspeicher überwachen
Wir empfehlen, dass Sie den Arbeitsspeicher überwachen, den Apache Kafka verwendet. Andernfalls ist der Cluster möglicherweise nicht mehr verfügbar.
Um festzustellen, wie viel Arbeitsspeicher Apache Kafka verwendet, können Sie die HeapMemoryAfterGC-Metrik überwachen. HeapMemoryAfterGC ist der Prozentsatz des gesamten Heap-Speichers, der nach der Garbage Collection verwendet wird. Wir empfehlen Ihnen, einen CloudWatch Alarm zu erstellen, der aktiv wird, wenn der HeapMemoryAfterGC Anstieg über 60% liegt.
Die Maßnahmen, die Sie ergreifen können, um die Speichernutzung zu verringern, sind unterschiedlich. Sie hängen davon ab, wie Sie Apache Kafka konfigurieren. Wenn Sie beispielsweise die transaktionale Nachrichtenzustellung verwenden, können Sie den transactional.id.expiration.ms-Wert in Ihrer Apache-Kafka-Konfiguration von 604800000 ms auf 86400000 ms (von 7 Tagen auf 1 Tag) verringern. Dadurch wird der Speicherbedarf jeder Transaktion verringert.
Fügen Sie keine MSK Nicht-Makler hinzu
Wenn Sie bei ZooKeeper basierten, MSK bereitgestellten Clustern ZooKeeper Apache-Befehle zum Hinzufügen von Brokern verwenden, ZooKeeper werden diese Broker nicht zu Ihrem MSK bereitgestellten Cluster hinzugefügt, und Ihr Apache enthält falsche Informationen über den Cluster. Dies kann zu Datenverlust führen. Informationen zu unterstützten MSK Provisioned Cluster-Vorgängen finden Sie unter. Die MSK wichtigsten Funktionen und Konzepte von Amazon
Aktivieren der Verschlüsselung während der Übertragung
Informationen zur Verschlüsselung während der Übertragung und zum Aktivieren dieser Verschlüsselung finden Sie unter MSKAmazon-Verschlüsselung bei der Übertragung.
Neuzuweisung von Partitionen
Um Partitionen auf verschiedene Broker auf demselben MSK bereitgestellten Cluster zu verschieben, können Sie das Tool zur Neuzuweisung von Partitionen mit dem Namen verwenden. kafka-reassign-partitions.sh Nachdem Sie beispielsweise neue Broker hinzugefügt haben, um einen Cluster zu erweitern oder Partitionen zu verschieben, um Broker zu entfernen, können Sie diesen Cluster neu verteilen, indem Sie den neuen Brokern Partitionen neu zuweisen. Informationen zum Hinzufügen von Brokern zu einem MSK bereitgestellten Cluster finden Sie unter. Erhöhen Sie die Anzahl der Broker in einem MSK Amazon-Cluster Informationen zum Entfernen von Brokern aus einem MSK bereitgestellten Cluster finden Sie unter. Einen Broker aus einem MSK Amazon-Cluster entfernen Informationen zum Tool zur Neuzuweisung von Partitionen finden Sie unter Expanding your cluster
