Größe Ihres Managed Service for Apache Kafka-Clusters planen

In diesem Dokument wird beschrieben, wie Sie die Kapazität schätzen, die Sie für einen Managed Service for Apache Kafka-Cluster benötigen, und wie Sie die Größe eines vorhandenen Clusters anpassen.

Wenn Sie einen Managed Service for Apache Kafka-Cluster erstellen, wählen Sie die folgenden Parameter für die Größe des Clusters aus:

vCPUs: Die Anzahl der vCPUs im Cluster. Die Mindestanzahl von vCPUs ist 3.
Arbeitsspeicher: Die Menge an Arbeitsspeicher pro vCPU. Sie müssen zwischen 1 GiB und 8 GiB pro vCPU bereitstellen.

Sie können diese Werte nach der Clustererstellung aktualisieren.

Anfängliche Clustergröße auswählen

Um die anfängliche Clustergröße auszuwählen, schätzen Sie zuerst die folgenden Werte basierend auf Ihrer jeweiligen Arbeitslast.

Schreibdurchsatz: Die Gesamtrate, mit der Producer Daten an den Cluster senden, in MBps.
Lesedurchsatz: Die Gesamtrate, mit der Consumer Daten aus dem Cluster lesen, in MBps.

So schätzen Sie die Größe eines Clusters, die für diesen Durchsatz erforderlich ist:

Berechnen Sie die gesamte Schreibbandbreite, einschließlich Replikation.

Total write bandwidth = produce rate * replicas

Dieser Wert umfasst die Bandbreite vom Client zum Leader-Broker und vom Leader zu den Replica-Brokern. Die Standardanzahl von Replikaten ist 3.
Berechnen Sie die gesamte Lesebandbreite, einschließlich der Replikation.

Total read bandwidth = consume rate + produce rate * ( replicas - 1)

Dieser Wert umfasst die Bandbreite für die Lesevorgänge des Clients (Verbrauchsrate) sowie die Bandbreite, die für die Synchronisierung der Replikate erforderlich ist. Replikate werden synchronisiert, indem Daten vom Partitions-Leader gelesen werden. Der Begriff (replicas - 1) wird verwendet, weil der Partitions-Leader nicht von Replikaten liest.
Berechnen Sie die datenäquivalente Schreibgeschwindigkeit.

Im Allgemeinen ist die Verarbeitung von Lesebandbreite viermal effizienter als die Verarbeitung von Schreibbandbreite. Um diesen Unterschied zu berücksichtigen, berechnen Sie die schreibäquivalente Datenrate so:

Write-equivalent rate = (total write bandwidth) + (total read bandwidth / 4)
Legen Sie die Ziel-vCPU-Auslastung fest. Dieser Wert gibt die durchschnittliche vCPU-Auslastung als Prozentsatz der vCPU-Kapazität an. Die tatsächliche Nutzung kann im Zeitverlauf ansteigen oder sinken.
- Beginnen Sie mit einem Zielwert für die Auslastung von 50%.
- Wenn Sie die erwarteten Traffic-Muster kennen, legen Sie das Auslastungsziel auf das Verhältnis der durchschnittlichen schreibäquivalenten Bandbreite zur Spitzenbandbreite fest, die Sie berücksichtigen müssen.
Im Allgemeinen senkt eine höhere Auslastung die Kosten Ihres Clusters, da die Größe reduziert wird. Das ist jedoch auch riskanter, wenn der Traffic die Schätzungen übersteigt. Eine übermäßige vCPU-Auslastung kann zu hohen Latenzen und Fehlern führen.
Berechnen Sie die Anzahl der vCPUs.

vCPU count = ceiling (write-equivalent rate / 20 MBps / utilization)

Die geschätzte Kapazität für eine einzelne vCPU in einer einzelnen Zone beträgt 20 MBps. Wenn die vCPUs also mit 100% iger Auslastung ausgeführt werden, benötigen Sie (write-equivalent rate / 20) vCPUs. Um die tatsächliche Anzahl zu erhalten, teilen Sie diesen Wert durch die Zielauslastung und runden Sie das Ergebnis auf.

Wenn Sie Nachrichten in Batches mit weniger als 10 KB senden, sinkt der Durchsatz pro CPU im Vergleich zum Benchmark. In diesem Fall müssen Sie entweder die reduzierte Durchsatzkapazität berücksichtigen oder größere Batches senden.
Schätzen Sie den erforderlichen Arbeitsspeicher. Wir empfehlen 4 GiB RAM pro vCPU.

Memory = vCPU count * 4 GiB

Testen Sie mit Ihrer tatsächlichen Arbeitslast, um die genaueste Dimensionierung zu erhalten. Überwachen Sie die Ressourcennutzung des Clusters und führen Sie bei Bedarf eine Aufwärtsskalierung durch.

Beispiel für die Größenberechnung

Angenommen, eine Arbeitslast hat eine Schreibrate von 50 MB/s und eine Leseraten von 100 MB/s, mit 3 Replikaten und einer Ziel-vCPU-Auslastung von 50%.

Total write bandwidth = 50 MBps * 3 replicas = 150 MBps
Total read traffic = 100 MBps + 50 MBps * (3 - 1) = 200 MBps
Write-equivalent rate = 150 MBps + (200 MBps / 4) = 200 MBps
Target utilization = 0.5
Number of vCPUs = ceiling (200 MBps / 20 MBps / 0.5) = 20 vCPUs
Memory = 20 vCPUs * 4 GiB = 80 GiB

Makler

Wenn Sie einen Cluster erstellen, stellt das System mindestens einen Broker in jeder von drei Zonen bereit. Die Broker werden so gleichmäßig wie möglich auf die Zonen verteilt und alle Broker haben dieselbe Anzahl von vCPUs. Die Anzahl der Vermittler kann mit der folgenden Formel berechnet werden:

number of brokers = max(3, ceiling(vCPUs / 15))

Ein Cluster mit 75 vCPUs beginnt beispielsweise mit 5 Brokern.

Wenn Sie die Anzahl der vCPUs ändern, werden sie auf die vorhandenen Broker verteilt, bis zu maximal 15 vCPUs pro Broker. Wenn Sie die Clustergröße auf mehr als 15 vCPUs pro Broker erhöhen, wird ein neuer Broker bereitgestellt. Sobald ein neuer Broker bereitgestellt wurde, kann er auf 1 vCPU herunterskaliert, aber nicht gelöscht werden.

Clustergröße aktualisieren

Nachdem Sie einen Managed Service for Apache Kafka-Cluster erstellt haben, können Sie die Anzahl der vCPUs und den Arbeitsspeicher an Ihre Anforderungen anpassen. Wenn Sie einen vorhandenen Cluster aktualisieren, gelten die folgenden Regeln:

Das allgemeine Verhältnis von vCPU zu Arbeitsspeicher des Clusters muss immer zwischen 1:1 und 1:8 liegen.
Wenn Sie die Ressourcen herunterskalieren, muss für jeden vorhandenen Broker mindestens 1 vCPU und 1 GiB Arbeitsspeicher vorhanden sein. Die Anzahl der Broker nimmt nie ab.
Wenn Sie die Anzahl der Broker erhöhen, darf die durchschnittliche Anzahl von vCPUs und der durchschnittliche Arbeitsspeicher pro Broker im Vergleich zu den Durchschnittswerten vor der Änderung um nicht mehr als 10% sinken.

Wenn Sie beispielsweise versuchen, einen Cluster von 45 vCPUs (3 Brokern) auf 48 vCPUs (4 Broker) hochzuskalieren, schlägt der Vorgang fehl. Das liegt daran, dass die durchschnittliche vCPU pro Broker von 15 auf 12 sinkt, was einer Reduzierung um 20% entspricht und damit das Limit von 10 % überschreitet.

Wenn Sie die Anzahl der CPUs um mehr als 10 % verringern müssen, empfehlen wir, die Anzahl in mehreren Schritten zu reduzieren. Überwachen Sie nach jeder Aktualisierung die Ressourcennutzung und gleichen Sie die Partitionen bei Bedarf neu aus.

Wenn Sie jedoch sicher sind, dass Ihre Broker nach dem Update über genügend Kapazität verfügen, können Sie diese Prüfung deaktivieren. Um die Prüfung zu deaktivieren, setzen Sie das Flag allow_broker_downscale_on_cluster_upscale im Befehl gcloud managed-kafka clusters update auf true. Dieses Flag signalisiert, dass Sie das potenzielle Leistungsrisiko akzeptieren.

Informationen zum Aktualisieren eines Clusters finden Sie unter Managed Service for Apache Kafka-Cluster aktualisieren.

Beispiel für Aktualisierungsvorgänge

Die folgenden Beispiele beginnen mit einem Cluster mit 75 vCPUs, 130 GiB RAM und 5 Brokern.

Beispiel für einen fehlgeschlagenen Upscaling-Vorgang

Skalieren Sie den Cluster auf 80 vCPUs und 140 GiB RAM hoch.

Der Dienst ermittelt, ob ein neuer Broker erforderlich ist.
- obere Gaußklammer (80 vCPUs / 15) = 6 Broker
Das Cluster würde von 5 auf 6 Broker anwachsen, sodass die Sicherheitsprüfung von 10% ausgelöst wird.
Die aktuellen Durchschnittswerte pro Broker sind:
- 75 vCPUs / 5 Broker = 15 vCPUs pro Broker
- 130 GiB / 5 Brokern = 26 GiB pro Broker
Bei 6 Brokern ergeben sich folgende neue Durchschnittswerte:
- 80 vCPUs / 6 Broker = 13,33 vCPUs pro Broker, eine Reduzierung um 11,1 %
- 140 GiB / 6 Brokers = 23,33 GiB pro Broker, eine Reduzierung um 10,2 %
Der Vorgang schlägt fehl, weil diese Durchschnittswerte 10 % überschreiten.

Beispiel für einen erfolgreichen Upscale-Vorgang

Skalieren Sie den Cluster auf 85 vCPUs und 150 GiB RAM hoch.

Der Dienst bestimmt, ob ein neuer Broker erforderlich ist.
- Obergrenze (85 vCPUs / 15) = 6 Broker
Das Cluster würde von 5 auf 6 Broker anwachsen, sodass die Sicherheitsprüfung von 10% ausgelöst wird.
Die aktuellen Durchschnittswerte pro Broker sind:
- 75 vCPUs / 5 Broker = 15 vCPUs pro Broker
- 130 GiB / 5 Brokern = 26 GiB pro Broker
Bei 6 Brokern ergeben sich folgende neue Durchschnittswerte:
- 85 vCPUs / 6 Broker = 14,17 vCPUs pro Broker, eine Reduzierung um 5,5 %
- 150 GiB / 6 Broker = 25 GiB pro Broker, eine Reduzierung um 3,8 %

Dieser Vorgang ist erfolgreich, da die Reduzierung der durchschnittlichen vCPU und des durchschnittlichen Arbeitsspeichers pro Broker innerhalb des 10‑%‑Limits liegt.

Größe Ihres Managed Service for Apache Kafka-Clusters planen Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.