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 an 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 Erstellung des Clusters 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 MB/s.
  • Lesedurchsatz: Die Gesamtrate, mit der Consumer Daten aus dem Cluster lesen, in MB/s.

So schätzen Sie die Größe eines Clusters, der diesen Durchsatz verarbeiten kann:

  1. Berechnen Sie die gesamte Schreibbandbreite einschließlich der Replikation.

    Total write bandwidth = produce rate * replicas

    Dieser Wert umfasst die Bandbreite vom Client zum Leader-Broker und vom Leader zu den Replikat-Brokern. Die Standardanzahl der Replikate ist 3.

  2. 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 Partition Leader gelesen werden. Der (replicas - 1) Ausdruck wird verwendet, weil der Partition Leader keine Daten von Replikaten liest.

  3. Berechnen Sie die datenäquivalente Schreibgeschwindigkeit.

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

    Write-equivalent rate = (total write bandwidth) + (total read bandwidth / 4)

  4. Bestimmen Sie die Ziel-vCPU-Auslastung. Dieser Wert stellt die durchschnittliche vCPU-Auslastung als Prozentsatz der vCPU-Kapazität dar. Die tatsächliche Auslastung kann im Laufe der Zeit steigen oder sinken.

    • Beginnen Sie mit einer Zielauslastung von 50%.
    • Wenn Sie die erwarteten Trafficmuster kennen, legen Sie die Zielauslastung auf das Verhältnis der durchschnittlichen datenäquivalenten Schreibbandbreite 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. Sie ist jedoch auch riskanter, wenn der Traffic die Schätzungen übersteigt. Eine übermäßige vCPU-Auslastung kann zu hohen Latenzen und Fehlern führen.

  5. 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 MB/s. Wenn die vCPUs also zu 100% ausgelastet wären, würden Sie (write-equivalent rate / 20) vCPUs benötigen. Um die tatsächliche Anzahl zu erhalten, teilen Sie diesen Wert durch die Zielauslastung und runden Sie ihn auf.

    Außerdem reduziert das Senden von Nachrichten in Batches mit weniger als 10 KB den Durchsatz pro CPU im Vergleich zum Benchmark hier. In diesem Fall müssen Sie entweder die reduzierte Durchsatzkapazität berücksichtigen oder größere Batches senden.

  6. 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 Größe zu erhalten. Überwachen Sie die Ressourcennutzung des Clusters und skalieren Sie ihn bei Bedarf nach oben.

Beispiel für die Größenberechnung

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

  1. Total write bandwidth = 50 MBps * 3 replicas = 150 MBps
  2. Total read traffic = 100 MBps + 50 MBps * (3 - 1) = 200 MBps
  3. Write-equivalent rate = 150 MBps + (200 MBps / 4) = 200 MBps
  4. Target utilization = 0.5
  5. Number of vCPUs = ceiling (200 MBps / 20 MBps / 0.5) = 20 vCPUs
  6. 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. Broker werden so gleichmäßig wie möglich auf die Zonen verteilt und alle Broker haben die gleiche Anzahl an vCPUs. Die Anzahl der Broker 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 über 15 vCPUs pro Broker hinaus erhöhen, stellt das System einen neuen Broker bereit. Sobald ein neuer Broker bereitgestellt wurde, kann er auf 1 vCPU herunterskaliert werden, aber er kann nicht gelöscht werden.

Limits für Partition Replikat

Es gibt Limits für die Anzahl der Partition Replikate pro Cluster und pro Broker, die bei der Größenanpassung Ihres Clusters berücksichtigt werden müssen.

Das Limit pro Cluster beträgt 100.000 Partition Replikate. Dies ist ein festes Limit und unabhängig von der Anzahl der Broker in einem Cluster. Wenn Ihre Arbeitslast mehr als 100.000 Partition Replikate erfordert, sollten Sie sie auf zwei oder mehr Cluster aufteilen.

Das Limit pro Broker beträgt 4.000 Partition Replikate. Dies ist kein festes Limit. Wenn Sie mehr als diese Anzahl von Replikaten verarbeiten müssen, sollten Sie mehr Broker bereitstellen. Sie können die Anzahl der Broker erhöhen, indem Sie die vCPU-Größe des Clusters um die maximale Brokergrößeerhöhen. Sobald Sie eine ausreichende Anzahl von Brokern haben, um Ihre Partitionen zu verarbeiten, können Sie die Brokergrößen an den Durchsatz anpassen.

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 Verhältnis von vCPU zu Arbeitsspeicher des Clusters muss immer zwischen 1:1 und 1:8 liegen.

  • Wenn Sie herunterskalieren, muss für jeden vorhandenen Broker mindestens 1 vCPU und 1 GiB Arbeitsspeicher vorhanden sein. Die Anzahl der Broker wird nie reduziert.

  • Wenn Sie nach oben skalieren und die Änderung dazu führt, dass neue Broker hinzugefügt werden, darf die durchschnittliche Anzahl an vCPUs und der durchschnittliche Arbeitsspeicher pro Broker im Vergleich zu den Durchschnittswerten vor der Aktualisierung um nicht mehr als 10% sinken.

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

Wenn Sie die Anzahl der CPUs um mehr als 10 % reduzieren 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 der Aktualisierung genügend Kapazität haben, können Sie diese Prüfung deaktivieren. Setzen Sie dazu im Befehl gcloud managed-kafka clusters update das Flag allow_broker_downscale_on_cluster_upscale 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 Skalierungsvorgang

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

  • Der Dienst ermittelt, ob ein neuer Broker erforderlich ist.

    • Aufrunden (80 vCPUs / 15) = 6 Broker

    Der Cluster würde von 5 auf 6 Broker anwachsen, daher wird die 10-%-Sicherheitsprüfung ausgelöst.

  • Die aktuellen Durchschnittswerte pro Broker sind:

    • 75 vCPUs / 5 Broker = 15 vCPUs pro Broker

    • 130 GiB / 5 Broker = 26 GiB pro Broker

  • Mit 6 Brokern sind die neuen Durchschnittswerte:

    • 80 vCPUs / 6 Broker = 13,33 vCPUs pro Broker, eine Reduzierung um 11,1 %

    • 140 GiB / 6 Broker = 23,33 GiB pro Broker, eine Reduzierung um 10,2 %

    Der Vorgang schlägt fehl, da diese Durchschnittswerte 10 % übersteigen.

Beispiel für einen erfolgreichen Skalierungsvorgang

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

  • Der Dienst ermittelt, ob ein neuer Broker erforderlich ist.

    • Aufrunden (85 vCPUs / 15) = 6 Broker

    Der Cluster würde von 5 auf 6 Broker anwachsen, daher wird die 10-%-Sicherheitsprüfung ausgelöst.

  • Die aktuellen Durchschnittswerte pro Broker sind:

    • 75 vCPUs / 5 Broker = 15 vCPUs pro Broker

    • 130 GiB / 5 Broker = 26 GiB pro Broker

  • Mit 6 Brokern sind die neuen 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 Anzahl an vCPUs und des durchschnittlichen Arbeitsspeichers pro Broker innerhalb des Limits von 10% liegt.

Nächste Schritte