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 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 le dimensioni iniziali 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:
Calcola la larghezza di banda di scrittura totale, inclusa la replica.
Total write bandwidth = produce rate * replicasQuesto valore include la larghezza di banda dal client al broker leader e dal leader ai broker di replica. Il numero predefinito di repliche è 3.
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 alcuna replica.Calcola la velocità di trasferimento dati equivalente in scrittura.
Come regola generale, la larghezza di banda di lettura è quattro 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)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, inizia con 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. L'utilizzo eccessivo di vCPU può causare latenze elevate ed errori.
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 funzionassero al 100% di utilizzo, 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 riportato qui. In questo caso, tieni conto della capacità di throughput ridotta o valuta la possibilità di inviare batch più grandi.
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 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%.
Total write bandwidth = 50 MBps * 3 replicas = 150 MBpsTotal read traffic = 100 MBps + 50 MBps * (3 - 1) = 200 MBpsWrite-equivalent rate = 150 MBps + (200 MBps / 4) = 200 MBpsTarget utilization = 0.5Number of vCPUs = ceiling (200 MBps / 20 MBps / 0.5) = 20 vCPUsMemory = 20 vCPUs * 4 GiB = 80 GiB
Limiti di replica della partizione
Esistono limiti al numero di repliche di partizioni per cluster e per broker che è importante considerare quando dimensiona il cluster.
Il limite per cluster è di 100.000 repliche di partizioni. Si tratta di un limite rigido e indipendente dal numero di broker in un cluster. Se il tuo workload 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 rigido. Se devi gestire un numero di repliche superiore, valuta la possibilità di aumentare le dimensioni del cluster per eseguire il provisioning di più broker. Per informazioni su come il servizio determina il numero di broker, consulta Provisioning dei 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.
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. Per maggiori informazioni, consulta Aggiornare un cluster Managed Service per Apache Kafka.
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.
Deve essere presente almeno 1 vCPU e 1 GiB di memoria per ogni broker esistente. Il numero di broker non diminuisce mai.
Se il cluster ha una configurazione del disco personalizzata, l'aggiornamento deve soddisfare i requisiti di configurazione del disco per l'archiviazione locale.
Se esegui l'upgrade, la vCPU e la memoria medie per broker non possono diminuire di più del 10% rispetto alle medie prima dell'aggiornamento. Ad esempio, se provi a eseguire l'upscaling di un cluster da 45 vCPU (3 broker) a 48 vCPU (4 broker), la vCPU media per broker diminuisce da 15 a 12, con una riduzione del 20%, superiore al limite del 10%.
Se devi ridurre il conteggio di vCPU di oltre il 10%, ti consigliamo di farlo 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 capacità sufficiente dopo l'aggiornamento, puoi disattivare questo controllo eseguendo il comando
gcloud managed-kafka clusters updatecon il flagallow_broker_downscale_on_cluster_upscale=true. Questo flag indica che accetti il potenziale rischio per il rendimento.
Operazioni di aggiornamento di esempio
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 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 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 un'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.
- 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 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 ha esito positivo perché la riduzione della vCPU media e della memoria per broker rientra nel limite del 10%.
Stima le dimensioni del disco richieste
Per impostazione predefinita, Managed Service per Apache Kafka alloca 100 GiB per vCPU a ogni broker. L'allocazione predefinita fornisce spazio di archiviazione locale sufficiente per la maggior parte dei workload, ma puoi configurare le dimensioni del disco del broker in base ai tuoi requisiti specifici. Questa sezione descrive come stimare la quantità di capacità del disco necessaria.
Quando un broker riceve un messaggio, lo scrive in un file di segmento locale.
Quando il file di segmento raggiunge una dimensione o un'età massima, viene chiuso (o "rollato") e spostato nello spazio di archiviazione remoto. Le dimensioni massime di un file di segmento sono specificate dall'impostazione log.roll.bytes, mentre l'età massima è specificata dall'impostazione log.segment.ms.
Quando viene eseguito il roll di un file di segmento, il broker apre un nuovo file di segmento. Il segmento viene mantenuto nello spazio di archiviazione locale mentre il broker lo copia nello spazio di archiviazione remoto. Pertanto, ogni partizione deve avere spazio sufficiente per archiviare un file di segmento sottoposto a roll over, più spazio per un nuovo file di segmento mentre il segmento sottoposto a roll over viene spostato nello spazio di archiviazione remoto.
Per impostazione predefinita, la dimensione massima di un file di segmento è 230 MiB. Per i cluster con un utilizzo moderato, puoi presupporre che siano necessari 250 MiB per partizione, per avere spazio buffer aggiuntivo durante lo spostamento di un segmento sottoposto a roll over. Utilizzando questo presupposto, la dimensione minima del disco per broker è:
250 MiB * partition count * replication factor / broker count
Tuttavia, le dimensioni richieste dipendono da fattori quali le dimensioni massime del file di segmento, il carico sul cluster, la velocità con cui vengono scritti nuovi dati e la latenza delle scritture nell'archiviazione a lungo termine.
È fondamentale mantenere una parte della capacità del disco inutilizzata su ogni broker. Il
comportamento di un broker senza capacità del disco non è prevedibile e può causare la perdita di dati e l'instabilità del cluster.
Monitora l'utilizzo del disco
(disk/used_bytes)
rispetto alle dimensioni totali del disco disponibili
(disk/limit).
Se l'utilizzo del disco supera l'80% delle dimensioni totali del disco disponibili, configura una dimensione del disco maggiore. Per saperne di più, consulta
Monitorare la capacità del cluster.
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
- Configura le dimensioni del disco del broker