View a markdown version of this page

Bewährte Methoden für Standard-Broker - Amazon Managed Streaming für Apache Kafka
Client-side ÜberlegungenServer-side Überlegungen

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 bei der Verwendung von Amazon MSK zu beachten sind. Informationen zu den bewährten Methoden von Amazon MSK Replicator finden Sie unter. Best Practices

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. Die vollständigen Informationen finden Sie unter. Bewährte Methoden für Apache Kafka-Clients

  • 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 sicherzustellen, dass Ihre Client-Konfigurationen es Ihnen ermöglichen, Ihre Leistungsziele zu erreichen.

Server-side Überlegungen

Right-size Ihr Cluster: Anzahl der Partitionen pro Standard-Broker

Die folgende Tabelle zeigt die empfohlene Anzahl von Partitionen (einschließlich Leader- und Follower-Repliken) 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 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 geheimes Passwort zu

Eine hohe Anzahl von Partitionen kann auch dazu führen, dass Kafka-Metriken auf CloudWatch und auf Prometheus-Scraping fehlen. Dieser Effekt wird durch eine hohe Anzahl von Verbrauchergruppen 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. Wir empfehlen Ihnen außerdem, Ihre eigenen Tests durchzuführen, um die richtige Größe für Ihre Makler zu ermitteln. Weitere Informationen zu den verschiedenen Brokergrößen finden Sie unterAmazon-MSK-Brokertypen.

Right-size Ihr Cluster: Anzahl der Standard-Broker pro Cluster

Informationen zur Bestimmung der richtigen Anzahl von Standard-Brokern für Ihren von MSK bereitgestellten Cluster und zum Verständnis der Kosten finden Sie in der Tabelle zur Dimensionierung und Preisgestaltung von MSK. Diese Tabelle enthält eine Schätzung für die Größe eines von MSK bereitgestellten Clusters und die damit verbundenen Kosten von Amazon MSK im Vergleich zu einem ähnlichen, selbstverwalteten Apache Kafka-Cluster. EC2-based Weitere Informationen zu den Eingabeparametern in der Tabelle erhalten Sie, wenn Sie den Mauszeiger über die Parameterbeschreibungen bewegen. Die Schätzungen in diesem Blatt sind konservativ und bieten einen Ausgangspunkt für einen neuen Cluster mit MSK Provisioning. Leistung, Größe und Kosten des Clusters hängen von Ihrem Anwendungsfall ab. Wir empfehlen Ihnen, diese Werte anhand von Tests zu überprüfen.

Weitere Informationen dazu, 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. AWS Der Blogbeitrag enthält Informationen darüber, wie Sie Ihre Cluster so dimensionieren können, dass sie Ihren Durchsatz-, Verfügbarkeits- und Latenzanforderungen entsprechen. Außerdem erhalten Sie Antworten auf Fragen, z. B. wann Sie eine Hochskalierung oder eine horizontale Skalierung vornehmen sollten, sowie Anleitungen zur kontinuierlichen Überprüfung der Größe Ihrer Produktionscluster. Informationen zu auf Tiered Storage basierenden Clustern finden Sie unter Bewährte Methoden für die Ausführung von Produktions-Workloads mit Amazon MSK Tiered Storage.

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 von MSK Provisioned bereitgestellten 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 CPU-Kerne, die für die Instance-Größe unterstützt werden, kann zur Verbesserung des Cluster-Durchsatzes beitragen.

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 gesetzt 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.

In der folgenden Tabelle werden die empfohlenen Einstellungen für jede Instanzgröße beschrieben.

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 AdminClient , um zu vermeiden, dass die Themen-ID nicht übereinstimmt

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 --zookeeper zum Erhöhen oder Neuzuweisen der Themenpartitionen für einen von MSK bereitgestellten Cluster verwenden, 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 Brokergröß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, dass Sie die CPU-Auslastung Ihrer Broker (definiert als) unter 60% halten. CPU User + CPU System Dadurch wird sichergestellt, dass Ihr Cluster über ausreichend CPU-Speicherplatz verfügt, um Betriebsereignisse wie Brokerausfälle, Patches und fortlaufende Upgrades zu bewältigen.

Apache Kafka kann die CPU-Last bei Bedarf auf die Broker im Cluster umverteilen. Wenn Amazon MSK beispielsweise einen Brokerfehler erkennt und ihn behebt, führt es automatische Wartungsarbeiten durch, z. B. Patches. Wenn ein Benutzer eine Änderung der Brokergröße oder ein Versions-Upgrade anfordert, initiiert Amazon MSK ebenfalls fortlaufende Workflows, bei denen jeweils ein Broker offline ist. 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, stellen Sie sicher, dass genügend CPU-Spielraum vorhanden ist, um diese Betriebsereignisse 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, und irq softirqsteal, tragen ebenfalls zur CPU-Gesamtaktivität bei. Folglich ist CPU-Leerlauf 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 einrichten, der ausgelöst wird, wenn die durchschnittliche Auslastung 60% übersteigt. Wenn der Cluster ausgelöst wird, sollten Sie erwägen, den Cluster mithilfe einer der folgenden Optionen zu skalieren:

  • Option 1 (empfohlen): Aktualisieren Sie Ihre Brokergröße auf die nächstgrößere Größe. Wenn die aktuelle Größe beispielsweise gleich istkafka.m5.large, aktualisieren Sie den zu verwendenden Clusterkafka.m5.xlarge. Beachten Sie, 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. 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 von MSK bereitgestellten 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 Wenn 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, 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 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 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:

Informationen zur Einrichtung und Verwendung von Alarmen finden Sie unter CloudWatch Amazon-Alarme 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-name TopicName --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-name TopicName --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, dass Sie einen CloudWatch Alarm einrichten, 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.

Keine Nicht-MSK-Broker hinzufügen

Wenn Sie bei von ZooKeeper-based MSK bereitgestellten Clustern ZooKeeper Apache-Befehle zum Hinzufügen von Brokern verwenden, werden diese Broker nicht zu Ihrem MSK Provisioned-Cluster hinzugefügt, und Ihr Apache ZooKeeper enthält falsche Informationen über den Cluster. Dies kann zu Datenverlust führen. Informationen zu unterstützten Clustervorgängen von 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 während der Übertragung.

Neuzuweisung von Partitionen

Um Partitionen auf verschiedene Broker auf demselben MSK Provisioned-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 10 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 in der Apache Kafka-Dokumentation.