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 regolare 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 tra 1 GiB e 8 GiB per vCPU.

Puoi aggiornare questi valori dopo la creazione del cluster.

Scegli la dimensione iniziale del cluster

Per scegliere la dimensione iniziale del cluster, inizia stimando i seguenti valori, in base al tuo workload specifico.

• Throughput di scrittura: la velocità totale con cui i produttori inviano dati al cluster, in MBps.
• Throughput 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), più la 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 nessuna replica.

3. Calcola la velocità di trasferimento dati equivalente in scrittura.

   Come regola 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 trasferimento dati equivalente in scrittura nel seguente modo:

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

4. Determina l'utilizzo 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 punto di partenza, imposta un target di utilizzo del 50%.
   • Se conosci i pattern di traffico previsti, imposta il target di utilizzo in modo che sia uguale al rapporto tra la larghezza di banda media equivalente in scrittura 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 delle 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 sono state eseguite al 100% di utilizzo, avrai 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 più piccoli di 10 KB riduce la velocità effettiva per CPU rispetto al benchmark riportato qui. In questo caso, tieni conto della capacità di throughput 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 il test con il tuo carico di lavoro reale per ottenere un dimensionamento più preciso. Monitora l'utilizzo delle risorse del cluster e aumenta le risorse se necessario.

Esempio di calcolo delle dimensioni

Supponiamo che un workload 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

Intermediari

Quando crei un cluster, il sistema esegue il provisioning di almeno un broker in ciascuna delle tre zone. I broker sono distribuiti in modo uniforme tra le zone e tutti 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 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.

Aggiorna la dimensione 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 tra vCPU e memoria del cluster deve sempre rimanere compreso tra 1:1 e 1:8.

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

• Se esegui l'upgrade e la modifica comporta l'aggiunta di nuovi broker, la vCPU media e la memoria per broker non possono diminuire di oltre il 10% rispetto alle medie prima dell'aggiornamento.

  Ad esempio, se provi ad aumentare le dimensioni di un cluster da 45 vCPU (3 broker) a 48 vCPU (4 broker), l'operazione non va a buon fine. Questo perché la vCPU media per broker diminuisce da 15 a 12, con una riduzione del 20%, che supera il limite del 10%.

Se devi ridurre il conteggio delle 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 ritieni 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 di rendimento.

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

Esempio di operazioni di aggiornamento

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

Esempio di un'operazione di upscaling non riuscita

Aumenta le dimensioni del cluster fino a 80 vCPU e 140 GiB di RAM.

• Il servizio determina se è necessario un nuovo broker.

  • limite massimo (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 intermediari, 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 upscaling riuscita

Aumenta le dimensioni del cluster a 85 vCPU e 150 GiB di RAM.

• Il servizio determina se è necessario un nuovo broker.

  • limite massimo (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 intermediari, 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 ha esito positivo perché la riduzione della vCPU e della memoria medie per broker rientra nel limite del 10%.

Passaggi successivi

• Crea un cluster Managed Service per Apache Kafka
• Monitorare un cluster Managed Service per Apache Kafka
• Aggiornare un cluster Managed Service per Apache Kafka