O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Planejar o tamanho do cluster do Serviço gerenciado para Apache Kafka

Este documento descreve como estimar a capacidade necessária para um cluster do Serviço Gerenciado para Apache Kafka e como ajustar o tamanho de um cluster atual.

Ao criar um cluster do Serviço Gerenciado para Apache Kafka, você escolhe os seguintes parâmetros para o tamanho do cluster:

vCPUs: o número de vCPUs no cluster. A contagem mínima de vCPUs é 3.
Memória: a quantidade de memória por vCPU. É necessário provisionar entre 1 GiB e 8 GiB por vCPU.

É possível atualizar esses valores depois que o cluster for criado.

Escolher o tamanho inicial do cluster

Para escolher o tamanho inicial do cluster, comece estimando os seguintes valores com base na sua carga de trabalho específica.

Capacidade de processamento de gravação: a taxa total em que os produtores enviam dados para o cluster, em MBps.
Capacidade de processamento de leitura: a taxa total em que os consumidores leem dados do cluster, em MBps.

Para estimar o tamanho de um cluster necessário para processar essa capacidade de processamento, siga estas etapas:

Calcule a largura de banda total de gravação, incluindo replicação.

Total write bandwidth = produce rate * replicas

Esse valor inclui a largura de banda do cliente para o broker líder e do líder para os brokers de réplica. O número padrão de réplicas é 3.
Calcule a largura de banda total de leitura, incluindo a replicação.

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

Esse valor inclui a largura de banda para as operações de leitura do cliente (taxa de consumo), além da largura de banda necessária para que as réplicas permaneçam sincronizadas. As réplicas são sincronizadas lendo dados do líder da partição. O termo (replicas - 1) é usado porque o líder da partição não lê de nenhuma réplica.
Calcule a taxa de dados equivalente à gravação.

Como regra geral, a largura de banda de leitura é quatro vezes mais eficiente para processar do que a largura de banda de gravação. Para considerar essa diferença, calcule a taxa de dados equivalente à gravação da seguinte maneira:

Write-equivalent rate = (total write bandwidth) + (total read bandwidth / 4)
Determine o uso de vCPU de destino. Esse valor representa o uso médio de vCPU como uma porcentagem da capacidade de vCPU. O uso real pode aumentar ou diminuir ao longo do tempo.
- Como linha de base, comece com uma meta de uso de 50%.
- Se você souber os padrões de tráfego esperados, defina a meta de uso igual à proporção da largura de banda equivalente à gravação média para a largura de banda de pico que você precisa acomodar.
Geralmente, o aumento do uso reduz o custo do cluster, diminuindo o tamanho dele, mas também é mais arriscado se o tráfego exceder as estimativas. O uso excessivo de vCPU pode causar latências e erros altos.
Calcule o número de vCPUs.

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

A capacidade estimada para uma única vCPU em uma única zona é de 20 MBps. Portanto, se as vCPUs fossem executadas com 100% de uso, você precisaria de (write-equivalent rate / 20) vCPUs. Para receber o número real, divida esse valor pelo uso de destino e arredonde para cima.

Além disso, o envio de mensagens em lotes menores que 10 kB reduz a capacidade de processamento por CPU, em relação ao benchmark aqui. Nesse caso, considere a capacidade de capacidade reduzida ou envie lotes maiores.
Estime a memória necessária. Recomendamos 4 GiB de RAM para cada vCPU.

Memory = vCPU count * 4 GiB

Teste com sua carga de trabalho real para ter o dimensionamento mais preciso. Monitore o uso de recursos do cluster e faça escalonar verticalmente, se necessário.

Exemplo de cálculo de tamanho

Suponha que uma carga de trabalho tenha uma taxa de gravação de 50 MBps e uma taxa de leitura de 100 MBps, com três réplicas e um uso de vCPU de destino de 50%.

Total write bandwidth = 50 MBps * 3 replicas = 150 MBps
Total read traffic = 100 MBps + 50 MBps * (3 - 1) = 200 MBps
Write-equivalent rate = 150 MBps + (200 MBps / 4) = 200 MBps
Target utilization = 0.5
Number of vCPUs = ceiling (200 MBps / 20 MBps / 0.5) = 20 vCPUs
Memory = 20 vCPUs * 4 GiB = 80 GiB

Agentes

Ao criar um cluster, o sistema provisiona pelo menos um broker em cada uma das três zonas. Os brokers são distribuídos da maneira mais uniforme possível entre as zonas, e todos têm o mesmo número de vCPUs. O número de brokers pode ser calculado com a seguinte fórmula:

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

Por exemplo, um cluster com 75 vCPUs começa com cinco brokers.

Se você mudar o número de vCPUs, elas serão distribuídas entre os brokers atuais, até um máximo de 15 vCPUs por broker. Se você aumentar o tamanho do cluster além de 15 vCPUs por broker, o sistema provisionará um novo broker. Depois que um novo broker é provisionado, ele pode ser reduzido para 1 vCPU, mas não pode ser excluído.

Limites de réplica de partição

Há limites para as contagens de réplicas de partição por cluster e por broker que são importantes considerar ao dimensionar o cluster.

O limite por cluster é de 100.000 réplicas de partição. Esse é um limite rígido e independente do número de brokers em um cluster. Se a carga de trabalho exigir mais de 100.000 réplicas de partição, considere dividi-la entre dois ou mais clusters.

O limite por broker é de 4.000 réplicas de partição. Esse não é um limite rígido. Se você precisar processar mais do que esse número de réplicas, considere provisionar mais brokers. É possível aumentar a contagem de brokers aumentando o tamanho da vCPU do cluster pelo tamanho máximo do broker. Depois de ter um número suficiente de brokers para processar suas partições, você poderá escalonar os tamanhos dos brokers para acomodar a capacidade.

Atualizar o tamanho do cluster

Depois de criar um cluster do Serviço Gerenciado para Apache Kafka, você pode ajustar a contagem de vCPUs e a memória para atender às suas necessidades. Ao atualizar um cluster atual, as seguintes regras se aplicam:

A proporção geral de vCPU para memória do cluster precisa sempre permanecer entre 1:1 e 1:8.
Se você fizer o escalonamento vertical, será necessário ter pelo menos 1 vCPU e 1 GiB de memória para cada broker atual. O número de brokers nunca diminui.
Se você fizer o escalonamento vertical e a mudança resultar na adição de novos brokers, a vCPU e a memória médias por broker não poderão diminuir em mais de 10% em comparação com as médias antes da atualização.

Por exemplo, se você tentar escalonar verticalmente um cluster de 45 vCPUs (3 brokers) para 48 vCPUs (4 brokers), a operação falhará. Isso ocorre porque a vCPU média por broker diminui de 15 para 12, o que é uma redução de 20%, excedendo o limite de 10%.

Se você precisar diminuir a contagem de CPUs em mais de 10%, recomendamos reduzir o número em várias etapas. Após cada atualização, monitore o uso de recursos e reequilibre as partições, se necessário.

No entanto, se você tiver certeza de que seus brokers terão capacidade suficiente após a atualização, poderá desativar essa verificação. Para desativar a verificação, defina a flag allow_broker_downscale_on_cluster_upscale como true no comando gcloud managed-kafka clusters update. Essa flag indica que você aceita o risco de desempenho potencial.

Para atualizar um cluster, consulte Atualizar um cluster do Serviço Gerenciado para Apache Kafka.

Exemplos de operações de atualização

Os exemplos a seguir começam com um cluster que tem 75 vCPUs, 130 GiB de RAM e 5 brokers.

Exemplo de uma operação de escalonamento vertical com falha

Escalone verticalmente o cluster para 80 vCPUs e 140 GiB de RAM.

O serviço determina se um novo broker é necessário.
- teto (80 vCPUs / 15) = 6 brokers
O cluster cresceria de 5 para 6 brokers, então a verificação de segurança de 10% é acionada.
As médias atuais por broker são:
- 75 vCPUs / 5 brokers = 15 vCPUs por broker
- 130 GiB / 5 brokers = 26 GiB por broker
Com 6 brokers, as novas médias são:
- 80 vCPUs / 6 brokers = 13,33 vCPUs por broker, uma redução de 11,1%
- 140 GiB / 6 brokers = 23,33 GiB por broker, uma redução de 10,2%
A operação falha porque essas médias excedem 10%.

Exemplo de uma operação de escalonamento vertical bem-sucedida

Escalone verticalmente o cluster para 85 vCPUs e 150 GiB de RAM.

O serviço determina se um novo broker é necessário.
- teto (85 vCPUs / 15) = 6 brokers
O cluster cresceria de 5 para 6 brokers, então a verificação de segurança de 10% é acionada.
As médias atuais por broker são:
- 75 vCPUs / 5 brokers = 15 vCPUs por broker
- 130 GiB / 5 brokers = 26 GiB por broker
Com 6 brokers, as novas médias são:
- 85 vCPUs / 6 brokers = 14,17 vCPUs por broker, uma redução de 5,5%
- 150 GiB / 6 brokers = 25 GiB por broker, uma redução de 3,8%

Essa operação é bem-sucedida porque a redução na vCPU média e na memória por broker está dentro do limite de 10%.

Planejar o tamanho do cluster do Serviço gerenciado para Apache Kafka Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.