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 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 von Replikaten 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.

    In der Regel ist die Lesebandbreite viermal effizienter als die Schreibbandbreite. Um diesen Unterschied zu berücksichtigen, berechnen Sie die schreibäquivalente Datenrate 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 schreibäquivalenten Bandbreite zur Spitzenbandbreite fest, die Sie berücksichtigen müssen.

    Im Allgemeinen senkt eine höhere Auslastung die Kosten Ihres Clusters, da seine 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 mit 100% Auslastung laufen, 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 ihn auf.

    Außerdem reduziert das Senden von Nachrichten in Batches, die kleiner als 10 KB sind, 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.

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

Limits für Partition-Replikate

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 die Größe des Clusters erhöhen, um mehr Broker bereitzustellen. Informationen dazu, wie der Dienst die Anzahl der Broker bestimmt, finden Sie unter Broker bereitstellen.

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. Weitere Informationen finden Sie unter Managed Service for Apache Kafka-Cluster aktualisieren.

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.

  • Für jeden vorhandenen Broker müssen mindestens 1 vCPU und 1 GiB Arbeitsspeicher vorhanden sein. Die Anzahl der Broker nimmt nie ab.

  • Wenn der Cluster eine benutzerdefinierte Laufwerkskonfiguration, hat, muss die Aktualisierung die Anforderungen an die Laufwerkskonfiguration für den lokalen Speicher erfüllen.

  • Wenn Sie die Größe erhöhen, darf die durchschnittliche Anzahl von 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 erhöhen, sinkt die durchschnittliche Anzahl von vCPUs pro Broker von 15 auf 12, was einer Reduzierung von 20% entspricht und das Limit von 10% überschreitet.

    Wenn Sie die Anzahl der vCPUs um mehr als 10 % reduzieren müssen, empfehlen wir, sie 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, indem Sie den gcloud managed-kafka clusters update Befehl mit dem allow_broker_downscale_on_cluster_upscale=true Flag ausführen. Dieses Flag signalisiert, dass Sie das potenzielle Leistungsrisiko akzeptieren.

Beispiele 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 Upscale-Vorgang

Erhöhen Sie die Größe des Clusters 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 Upscale-Vorgang

Erhöhen Sie die Größe des Clusters 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 von vCPUs und des durchschnittlichen Arbeitsspeichers pro Broker innerhalb des Limits von 10% liegt.

Erforderliche Laufwerksgröße schätzen

Standardmäßig weist Managed Service for Apache Kafka jedem Broker 100 GiB pro vCPU zu. Die Standardzuweisung bietet genügend lokalen Speicher für die meisten Arbeitslasten. Sie können die Laufwerksgröße des Brokers jedoch an Ihre spezifischen Anforderungen anpassen. In diesem Abschnitt wird beschrieben, wie Sie die benötigte Laufwerkskapazität schätzen.

Wenn ein Broker eine Nachricht empfängt, schreibt er sie in eine lokale Segmentdatei. Wenn die Segmentdatei eine maximale Größe oder ein maximales Alter erreicht, wird sie geschlossen (oder „gerollt“) und in den Remote-Speicher verschoben. Die maximale Größe einer Segmentdatei wird durch die Einstellung log.roll.bytes und das maximale Alter durch die Einstellung log.segment.ms festgelegt.

Wenn eine Segmentdatei gerollt wird, öffnet der Broker eine neue Segmentdatei. Das gerollte Segment verbleibt im lokalen Speicher, während der Broker es in den Remote-Speicher kopiert. Daher benötigt jede Partition genügend Speicherplatz, um eine gerollte Segmentdatei zu speichern, sowie Speicherplatz für eine neue Segmentdatei, während das gerollte Segment in den Remote-Speicher verschoben wird.

Standardmäßig beträgt die maximale Größe einer Segmentdatei 230 MiB. Bei Clustern mit moderater Auslastung können Sie davon ausgehen, dass pro Partition 250 MiB erforderlich sind, um zusätzlichen Pufferplatz zu schaffen, während ein gerolltes Segment verschoben wird. Unter dieser Annahme beträgt die Mindestlaufwerksgröße pro Broker:

250 MiB * partition count * replication factor / broker count

Die erforderliche Größe hängt jedoch von Faktoren wie der maximalen Größe der Segmentdatei, der Last auf dem Cluster, der Rate, mit der neue Daten geschrieben werden, und der Latenz von Schreibvorgängen in den Langzeitspeicher ab.

Um sicherzustellen, dass Sie genügend Laufwerkskapazität haben, überwachen Sie die Laufwerksgröße Ihrer Partitionen mit dem managedkafka/byte_size Messwert.

Nächste Schritte