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 Managed Service para Apache Kafka, você escolhe os seguintes parâmetros para o tamanho do cluster:

  • vCPUs: o número de vCPUs no cluster. O número mínimo 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 gravação: a taxa total em que os produtores enviam dados para o cluster, em MBps.
  • Taxa de transferência 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 taxa de transferência, siga estas etapas:

  1. Calcule a largura de banda total de gravação, incluindo a 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.

  2. 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) e a 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.

  3. 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 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)

  4. Determine a utilização de vCPU desejada. Esse valor representa a utilização média de vCPU como uma porcentagem da capacidade de vCPU. A utilização real pode aumentar ou diminuir com o tempo.

    • Como uma linha de base, comece com uma meta de utilização de 50%.
    • Se você conhece os padrões de tráfego esperados, defina a meta de utilização igual à proporção da largura de banda média equivalente de gravação pela largura de banda máxima que você precisa acomodar.

    Em geral, aumentar a utilização 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 vCPUs pode causar latências e erros altos.

  5. 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 utilização, você precisaria de (write-equivalent rate / 20) vCPUs. Para saber o número real, divida esse valor pela utilização desejada e arredonde para cima.

    Além disso, o envio de mensagens em lotes menores que 10 KB reduz a capacidade por CPU em relação ao comparativo de mercado. Nesse caso, considere a capacidade de capacidade reduzida ou envie lotes maiores.

  6. 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 uma utilização de vCPU de 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

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 corretores 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 vai provisionar um novo broker. Depois que um novo broker é provisionado, ele pode ser reduzido para 1 vCPU, mas não pode ser excluído.

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 existente, as seguintes regras se aplicam:

  • A proporção geral de vCPU para memória do cluster precisa sempre estar entre 1:1 e 1:8.

  • Se você reduzir a escala, cada broker precisará ter pelo menos uma vCPU e 1 GiB de memória. O número de brokers nunca diminui.

  • Se você fizer um upgrade e a mudança resultar na adição de novos brokers, a vCPU média e a memória 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 fazer o escalonamento vertical de um cluster de 45 vCPUs (3 brokers) para 48 vCPUs (4 brokers), a operação vai falhar. Isso acontece porque a vCPU média por corretor diminui de 15 para 12, 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 a utilização 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, desative 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 possível risco de performance.

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 ampliação com falha

Aumente a escala do cluster para 80 vCPUs e 140 GiB de RAM.

  • O serviço determina se um novo corretor é necessário.

    • teto (80 vCPUs / 15) = 6 agentes

    O cluster cresceria de 5 para 6 brokers, então a verificação de segurança de 10% seria acionada.

  • As médias atuais por corretor são:

    • 75 vCPUs / 5 agentes = 15 vCPUs por agente

    • 130 GiB / 5 brokers = 26 GiB por broker

  • Com seis corretoras, as novas médias são:

    • 80 vCPUs / 6 agentes = 13,33 vCPUs por agente, 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 ampliação bem-sucedida

Aumente a escala do cluster para 85 vCPUs e 150 GiB de RAM.

  • O serviço determina se um novo corretor é necessário.

    • teto (85 vCPUs / 15) = 6 agentes

    O cluster cresceria de 5 para 6 brokers, então a verificação de segurança de 10% seria acionada.

  • As médias atuais por corretor são:

    • 75 vCPUs / 5 agentes = 15 vCPUs por agente

    • 130 GiB / 5 brokers = 26 GiB por broker

  • Com seis corretoras, as novas médias são:

    • 85 vCPUs / 6 agentes = 14,17 vCPUs por agente, 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%.

A seguir