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 Standardbroker
In diesem Thema werden einige bewährte Methoden beschrieben, die bei der Verwendung von Amazon MSK zu beachten sind. Weitere Informationen zu bewährten Methoden für Amazon MSK Replicator finden Sie unter. Bewährte Methoden für die Verwendung von MSK-Replikator
Clientseitige Überlegungen
Die Verfügbarkeit und Leistung Ihrer Anwendung hängt nicht nur von den serverseitigen Einstellungen, sondern auch von den Client-Einstellungen ab.
-
Konfigurieren Ihrer 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 MSK-Cluster.
-
Führen Sie Leistungstests durch, um zu überprüfen, ob Ihre Client-Konfigurationen es Ihnen ermöglichen, Ihre Leistungsziele zu erreichen.
Serverseitige Überlegungen
Die Größe Ihres Clusters anpassen: Anzahl der Partitionen pro Standard-Broker
Die folgende Tabelle zeigt die empfohlene Anzahl von Partitionen (einschließlich Leader- und Follower-Replikate) 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.
| Broker-Größe | 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 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 sicherzustellen, dass 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
-
Den Cluster auf eine kleinere Broker-Größe aktualisieren
-
Einem Cluster mit SASL/SCRAM-Authentifizierung ein AWS Secrets Manager -Secret zuordnen
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
Die Größe Ihres Clusters anpassen: Anzahl der Standard-Broker pro Cluster
Informationen zur Ermittlung der richtigen Anzahl von Standard-Brokern für Ihren von MSK bereitgestellten Cluster und zum Verständnis der Kosten finden Sie in der Tabelle MSK: Dimensionierung und Preise
Informationen darüber, wie sich die zugrunde liegende Infrastruktur auf die Leistung von Apache Kafka auswirkt, finden Sie im AWS Big Data Blog unter Bewährte Methoden für die richtige Dimensionierung Ihrer Apache-Kafka-Cluster zur Optimierung von Leistung und Kosten
Optimieren des Cluster-Durchsatzes 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 MSK Provisioned Cluster-Durchsatz optimieren, indem Sie die Konfigurationen num.io.threads und num.network.threads optimieren.
num.io.threads ist die Anzahl der Threads, die ein Standard-Broker für die Verarbeitung von Anfragen verwendet. Das Hinzufügen weiterer Threads bis zur Anzahl der für die Instance-Größe unterstützten CPU-Kerne kann den Cluster-Durchsatz verbessern.
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 Instance-Größe unterstützten CPU-Kerne festgelegt wird, kann die neue Instance-Größe vollständig 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 das neueste Kafka-Verfahren AdminClient , um Probleme mit nicht übereinstimmenden 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 dem Flag verwenden, um Themenpartitionen für einen MSK bereitgestellten Cluster --zookeeper zu vergrößern oder neu zuzuweisen, der Kafka Version 2.8.0 oder höher verwendet. 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 von 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.
-
Legen Sie minimale In-Sync-Replikate (minISR) auf höchstens RF - 1 fest. Ein minISR, das dem RF entspricht, kann verhindern, dass das Erzeugen im Cluster während einer fortlaufenden Aktualisierung erfolgt. Mit einem minISR von 2 können dreiseitige replizierte Themen verfügbar sein, wenn ein Replikat offline ist.
CPU-Auslastung überwachen
Amazon MSK empfiehlt dringend, die CPU-Auslastung für Ihre Broker (definiert alsCPU User + CPU System) unter 60% zu halten. Dadurch wird sichergestellt, dass Ihr Cluster über ausreichend CPU-Spielraum verfügt, um betriebliche Ereignisse wie Brokerausfälle, Patches und fortlaufende Upgrades zu bewältigen.
Apache Kafka kann die CPU-Last bei Bedarf auf die Broker im Cluster verteilen. Wenn Amazon MSK beispielsweise einen Broker-Fehler erkennt und diesen behebt, führt es automatische Wartungsarbeiten wie Patches durch. Wenn ein Benutzer eine Änderung der Broker-Größe oder ein Versionsupgrade anfordert, initiiert Amazon MSK fortlaufende Workflows, die jeweils einen Broker offline schalten. 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 sich an diese bewährte Methode halten, stellen Sie sicher, dass genügend CPU-Ressourcen vorhanden sind, um diese betrieblichen Ereignisse zu tolerieren.
Anmerkung
Beachten Sie bei der Überwachung der CPU-Auslastung, dass die gesamte CPU-Auslastung mehr als CPU User und CPU System umfasst. Andere Kategorien wie, iowait irq softirqsteal, und tragen ebenfalls zur gesamten CPU-Aktivität bei. Folglich ist CPU Idle nicht immer gleich100% - CPU User - CPU System.
Sie können Amazon CloudWatch Metric Math verwenden, um eine zusammengesetzte Metrik (CPU User + CPU System) zu erstellen und einen Alarm einzustellen, der ausgelöst wird, wenn die durchschnittliche Nutzung 60% übersteigt. Wenn dies ausgelöst wird, sollten Sie den Cluster mit Hilfe einer der folgenden Optionen skalieren:
-
Option 1 (empfohlen): Aktualisieren Sie Ihre Broker-Größe auf die nächstgrößere 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 MSK bei der Aktualisierung der Broker-Größe im Cluster die Broker fortlaufend offline nimmt und die Partitionsleitung vorübergehend 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 Provisioned Cluster, indem Sie Broker hinzufügen, und weisen Sie dann vorhandene Partitionen neu zu mithilfe des Tools zur Neuzuweisung von Partitionen mit dem Namen.
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 MSK, diese Option nicht zu verwenden, wenn die CPU-Auslastung über 70 % liegt, da die Replikation zu zusätzlicher CPU-Last und Netzwerk-Datenverkehr führt. Amazon MSK empfiehlt, diese Option nur zu verwenden, wenn die beiden vorherigen Optionen nicht durchführbar sind.
Weitere Empfehlungen:
-
Überwachen Sie die gesamte CPU-Auslastung pro Broker als Proxy für die Lastverteilung. Wenn Broker eine durchweg ungleichmäßige CPU-Auslastung aufweisen, 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 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 die offene Überwachung mit der Prometheus-Feature aktivieren, wird empfohlen, für Ihre Prometheus-Host-Konfiguration (prometheus.yml) ein Scrape-Intervall von 60 Sekunden oder höher (scrape_interval: 60s) zu verwenden. Eine Verkürzung des Scrape-Intervalls kann zu einer hohen CPU-Auslastung in Ihrem Cluster führen.
Überwachen der Festplattenkapazität
Um sicherzustellen, dass genügend Speicherplatz für Nachrichten vorhanden ist, 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 Amazon MSK-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 Amazon-MSK-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 Amazon MSK-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. Es wird empfohlen, dass Sie einen CloudWatch Alarm erstellen, der bei einem HeapMemoryAfterGC Anstieg von über 60% reagiert.
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.
Keine Nicht-MSK-Broker hinzufügen
Wenn Sie ZooKeeper Apache-Befehle verwenden, um Broker hinzuzufügen, werden diese Broker nicht zu Ihrem MSK Provisioned Cluster hinzugefügt, und Ihr Apache ZooKeeper enthält falsche Informationen über den Cluster. ZooKeeper Dies kann zu Datenverlust führen. Informationen zu unterstützten Clustervorgängen mit MSK Provisioned finden Sie unter. Die wichtigsten Funktionen und Konzepte von Amazon MSK
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 Amazon MSK-Verschlüsselung bei der Übertragung.
Neuzuweisung von Partitionen
Um Partitionen auf verschiedene Broker auf demselben von MSK bereitgestellten Cluster zu verschieben, können Sie das Tool zur Neuzuweisung von Partitionen mit dem Namen verwenden. kafka-reassign-partitions.sh Wir empfehlen, aus Sicherheitsgründen nicht mehr als 10 Partitionen in einem einzigen kafka-reassign-partitions Aufruf neu zuzuweisen. Wenn 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. Weitere Informationen zum Hinzufügen von Brokern zu einem von MSK bereitgestellten Cluster finden Sie unter. Erhöhen Sie die Anzahl der Broker in einem Amazon MSK-Cluster Weitere 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
