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 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 workload 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 di destinazione. 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 tuo workload 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 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

Limiti delle repliche di partizione

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

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

Il limite per broker è di 4000 repliche di partizione. Questo non è un limite fisso. Se devi gestire un numero di repliche superiore a questo, 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.

Aggiornare le dimensioni del cluster

Dopo aver creato un cluster Managed Service per Apache Kafka, puoi regolare il numero di vCPU e la memoria in base alle tue esigenze. Per saperne di più, consulta Aggiornare un cluster Managed Service per Apache Kafka.

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.

  • Per ogni broker esistente devono essere presenti almeno 1 vCPU e 1 GiB di memoria. 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 lo spazio di archiviazione locale.

  • Se esegui l'upscaling, 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 l'upscaling di un cluster da 45 vCPU (3 broker) a 48 vCPU (4 broker), 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 vCPU di oltre il 10%, ti consigliamo di ridurlo 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 eseguendo il gcloud managed-kafka clusters update comando con il allow_broker_downscale_on_cluster_upscale=true flag. Questo flag indica che accetti il potenziale rischio per il rendimento.

Esempi di operazioni di aggiornamento

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

Esempio di operazione di upscale non riuscita

Esegui l'upscale 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 upscale riuscita

Esegui l'upscale 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%.

Stimare 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. La dimensione massima di un file di segmento è specificata dall'impostazione log.roll.bytes, mentre l'età massima è specificata dall'impostazione log.segment.ms.

Quando un file di segmento viene rollato, il broker apre un nuovo file di segmento. Il segmento rollato rimane nello spazio di archiviazione locale mentre il broker lo copia nello spazio di archiviazione remoto. Pertanto, ogni partizione ha bisogno di spazio sufficiente per archiviare un file di segmento rollato, oltre allo spazio per un nuovo file di segmento mentre il segmento rollato viene spostato nello spazio di archiviazione remoto.

Per impostazione predefinita, la dimensione massima di un file di segmento è di 230 MiB. Per i cluster con un utilizzo moderato, puoi presupporre che siano necessari 250 MiB per partizione, per fornire spazio buffer aggiuntivo durante lo spostamento di un segmento rollato. Utilizzando questo presupposto, la dimensione minima del disco per broker è:

250 MiB * partition count * replication factor / broker count

Tuttavia, la dimensione richiesta dipende da fattori quali la dimensione massima del file di segmento, il carico sul cluster, la velocità con cui vengono scritti i nuovi dati e la latenza delle scritture nello spazio di archiviazione a lungo termine.

È fondamentale mantenere una certa capacità del disco inutilizzata su ogni broker. Il comportamento di un broker senza capacità del disco non è prevedibile e può comportare la perdita di dati e l'instabilità del cluster. Monitora l'utilizzo del disco (disk/used_bytes) rispetto alla dimensione totale del disco disponibile (disk/limit). Se l'utilizzo del disco supera l'80% della dimensione totale del disco disponibile, configura una dimensione del disco maggiore. Per saperne di più, consulta Monitorare la capacità del cluster.

Passaggi successivi