Pianifica le dimensioni del cluster Managed Service per Apache Kafka

Questo documento descrive come stimare la capacità necessaria per un cluster Managed Service per Apache Kafka e come modificare le dimensioni di un cluster esistente.

Quando crei un cluster Managed Service per Apache Kafka, scegli i seguenti parametri per le dimensioni del cluster:

  • vCPUs: il numero di vCPU nel cluster. Il numero minimo di vCPU è 3.

  • Memoria: la quantità di memoria per vCPU. Devi eseguire il provisioning di una quantità compresa tra 1 GiB e 8 GiB per vCPU.

Puoi aggiornare questi valori dopo la creazione del cluster.

Scegliere le dimensioni iniziali del cluster

Per scegliere le dimensioni iniziali del cluster, inizia stimando i seguenti valori in base al tuo carico di lavoro specifico.

  • Velocità effettiva di scrittura: la velocità totale con cui i produttori inviano dati al cluster, in MBps.
  • Velocità effettiva di lettura: la velocità totale con cui i consumer leggono i dati dal cluster, in MBps.

Per stimare le dimensioni di un cluster necessarie per gestire questa velocità effettiva, segui questi passaggi:

  1. Calcola la larghezza di banda di scrittura totale, inclusa la replica.

    Total write bandwidth = produce rate * replicas

    Questo valore include la larghezza di banda dal client al broker leader e dal leader ai broker di replica. Il numero predefinito di repliche è 3.

  2. Calcola la larghezza di banda di lettura totale, inclusa la replica.

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

    Questo valore include la larghezza di banda per le operazioni di lettura del client (velocità di consumo), oltre alla larghezza di banda necessaria per mantenere sincronizzate le repliche. Le repliche si sincronizzano leggendo i dati dal leader della partizione. Il termine (replicas - 1) viene utilizzato perché il leader della partizione non legge da alcuna replica.

  3. Calcola la velocità di dati equivalente alla scrittura.

    In generale, la larghezza di banda di lettura è 4 volte più efficiente da elaborare rispetto alla larghezza di banda di scrittura. Per tenere conto di questa differenza, calcola la velocità di dati equivalente alla scrittura come segue:

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

  4. Determina l'utilizzo della vCPU target. Questo valore rappresenta l'utilizzo medio della vCPU come percentuale della capacità della vCPU. L'utilizzo effettivo potrebbe aumentare o diminuire nel tempo.

    • Come base, inizia con un target di utilizzo del 50%.
    • Se conosci i pattern di traffico previsti, imposta il target di utilizzo uguale al rapporto tra la larghezza di banda equivalente alla scrittura media e la larghezza di banda di picco che devi gestire.

    In genere, l'aumento dell'utilizzo riduce il costo del cluster riducendone le dimensioni, ma è anche più rischioso se il traffico supera le stime. Un utilizzo eccessivo della vCPU può causare latenze elevate ed errori.

  5. Calcola il numero di vCPU.

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

    La capacità stimata per una singola vCPU in una singola zona è di 20 MBps. Pertanto, se le vCPU venissero eseguite con un utilizzo del 100%, avresti bisogno di (write-equivalent rate / 20) vCPU. Per ottenere il numero effettivo, dividi questo valore per l'utilizzo target e arrotonda per eccesso.

    Inoltre, l'invio di messaggi in batch inferiori a 10 KB riduce la velocità effettiva per CPU rispetto al benchmark qui. In questo caso, tieni conto della capacità di velocità effettiva ridotta o valuta la possibilità di inviare batch più grandi.

  6. Stima la memoria richiesta. Consigliamo 4 GiB di RAM per ogni vCPU.

    Memory = vCPU count * 4 GiB

Esegui test con il carico di lavoro reale per ottenere le dimensioni più accurate. Monitora l'utilizzo delle risorse del cluster ed esegui lo scale up, se necessario.

Esempio di calcolo delle dimensioni

Supponiamo che un carico di lavoro abbia una velocità di scrittura di 50 MBps e una velocità di lettura di 100 MBps, con 3 repliche e un utilizzo della vCPU target del 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

Broker

Quando crei un cluster, il sistema esegue il provisioning di almeno un broker in ognuna delle tre zone. I broker sono distribuiti il più uniformemente possibile tra le zone e tutti i broker hanno lo stesso numero di vCPU. Il numero di broker può essere calcolato con la seguente formula:

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

Ad esempio, un cluster con 75 vCPU inizia con 5 broker.

Se modifichi il numero di vCPU, queste vengono distribuite tra i broker esistenti, fino a un massimo di 15 vCPU per broker. Se aumenti le dimensioni del cluster oltre le 15 vCPU per broker, il sistema esegue il provisioning di un nuovo broker. Una volta eseguito il provisioning di un nuovo broker, è possibile ridimensionarlo a 1 vCPU, ma non può essere eliminato.

Limiti delle repliche delle partizioni

Esistono limiti al numero di repliche delle partizioni per cluster e per broker che è importante considerare quando si dimensiona il cluster.

Il limite per cluster è di 100.000 repliche di partizioni. Questo è un limite fisso ed è indipendente dal numero di broker in un cluster. Se il tuo carico di lavoro richiede più di 100.000 repliche di partizioni, valuta la possibilità di suddividerlo tra due o più cluster.

Il limite per broker è di 4000 repliche di partizioni. Questo non è un limite fisso. Se devi gestire un numero di repliche superiore a questo, valuta la possibilità di eseguire il provisioning di più broker. Puoi aumentare il numero di broker aumentando le dimensioni della vCPU del cluster in base a le dimensioni massime del broker. Una volta che hai un numero sufficiente di broker per gestire le partizioni, puoi scalare le dimensioni dei broker per adattarle alla velocità effettiva.

Aggiornare le dimensioni del cluster

Dopo aver creato un cluster Managed Service per Apache Kafka, puoi modificare il numero di vCPU e la memoria in base alle tue esigenze. Quando aggiorni un cluster esistente, si applicano le seguenti regole:

  • Il rapporto complessivo vCPU-memoria del cluster deve sempre rimanere compreso tra 1:1 e 1:8.

  • Se esegui lo scale down, deve essere presente almeno 1 vCPU e 1 GiB di memoria per ogni broker esistente. Il numero di broker non diminuisce mai.

  • Se esegui lo scale up e la modifica comporta l'aggiunta di nuovi broker, la media di vCPU e memoria per broker non può diminuire di oltre il 10% rispetto alle medie precedenti all'aggiornamento.

    Ad esempio, se provi a eseguire lo scale up di un cluster da 45 vCPU (3 broker) a 48 vCPU (4 broker), l'operazione non riesce. Questo perché la media di vCPU per broker diminuisce da 15 a 12, ovvero una riduzione del 20%, che supera il limite del 10%.

Se devi ridurre il numero di CPU di oltre il 10%, ti consigliamo di ridurre il numero in più fasi. Dopo ogni aggiornamento, monitora l'utilizzo delle risorse e ribilancia le partizioni, se necessario.

Tuttavia, se sei certo che i tuoi broker avranno una capacità sufficiente dopo l'aggiornamento, puoi disattivare questo controllo. Per disattivare il controllo, imposta il flag allow_broker_downscale_on_cluster_upscale su true nel comando gcloud managed-kafka clusters update. Questo flag indica che accetti il potenziale rischio per il rendimento.

Per aggiornare un cluster, consulta Aggiornare un cluster Managed Service per Apache Kafka.

Esempi di operazioni di aggiornamento

I seguenti esempi iniziano con un cluster con 75 vCPU, 130 GiB di RAM e 5 broker.

Esempio di operazione di scale up non riuscita

Esegui lo scale up del cluster a 80 vCPU e 140 GiB di RAM.

  • Il servizio determina se è necessario un nuovo broker.

    • ceiling (80 vCPU / 15) = 6 broker

    Il cluster aumenterebbe da 5 a 6 broker, quindi viene attivato il controllo di sicurezza del 10%.

  • Le medie attuali per broker sono:

    • 75 vCPU / 5 broker = 15 vCPU per broker

    • 130 GiB / 5 broker = 26 GiB per broker

  • Con 6 broker, le nuove medie sono:

    • 80 vCPU / 6 broker = 13,33 vCPU per broker, una riduzione dell'11,1%

    • 140 GiB / 6 broker = 23,33 GiB per broker, una riduzione del 10,2%

    L'operazione non riesce perché queste medie superano il 10%.

Esempio di operazione di scale up riuscita

Esegui lo scale up del cluster a 85 vCPU e 150 GiB di RAM.

  • Il servizio determina se è necessario un nuovo broker.

    • ceiling (85 vCPU / 15) = 6 broker

    Il cluster aumenterebbe da 5 a 6 broker, quindi viene attivato il controllo di sicurezza del 10%.

  • Le medie attuali per broker sono:

    • 75 vCPU / 5 broker = 15 vCPU per broker

    • 130 GiB / 5 broker = 26 GiB per broker

  • Con 6 broker, le nuove medie sono:

    • 85 vCPU / 6 broker = 14,17 vCPU per broker, una riduzione del 5,5%

    • 150 GiB / 6 broker = 25 GiB per broker, una riduzione del 3,8%

Questa operazione riesce perché la riduzione della media di vCPU e memoria per broker rientra nel limite del 10%.

Passaggi successivi