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 lidar com essa capacidade de processamento, siga estas etapas:

  1. 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 agente líder e do líder para os agentes 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), 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.

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

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

    • Como 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 equivalente à gravação média para a largura de banda de pico que você precisa acomodar.

    Geralmente, o aumento da utilização reduz o custo do cluster, diminuindo o tamanho dele, mas também é mais arriscado se o tráfego exceder as estimativas. A utilização excessiva da vCPU 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 receber o número real, divida esse valor pela utilização 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 processamento 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 3 réplicas e uma utilização de vCPU de destino 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

Limites de réplica de partição

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

O limite por cluster é de 100.000 réplicas de partição. Esse é um limite fixo e independente do número de agentes 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 agente é de 4.000 réplicas de partição. Esse não é um limite fixo. Se você precisar processar mais do que esse número de réplicas, considere aumentar o tamanho do cluster para provisionar mais agentes. Para mais informações sobre como o serviço determina o número de agentes, consulte Provisionamento de agentes.

Depois de ter um número suficiente de agentes para processar as partições, você poderá escalonar os tamanhos dos agentes para acomodar a capacidade de processamento.

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. Para mais informações, consulte Atualizar um cluster do Serviço Gerenciado para Apache Kafka.

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.

  • É necessário ter pelo menos 1 vCPU e 1 GiB de memória para cada agente atual. O número de agentes nunca diminui.

  • Se o cluster tiver uma configuração de disco personalizada, a atualização precisará atender aos requisitos de configuração de disco para armazenamento local.

  • Se você fizer o escalonamento vertical, a vCPU média e a memória por agente 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 um cluster de 45 vCPUs (3 agentes) para 48 vCPUs (4 agentes), a vCPU média por agente diminuirá de 15 para 12, o que é uma redução de 20%, excedendo o limite de 10%.

    Se você precisar diminuir a contagem de vCPUs em mais de 10%, recomendamos reduzir 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 agentes terão capacidade suficiente após a atualização, poderá desativar essa verificação executando o gcloud managed-kafka clusters update comando com a allow_broker_downscale_on_cluster_upscale=true flag. Essa flag indica que você aceita o risco de desempenho potencial.

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 agentes.

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

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

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

    • teto (80 vCPUs / 15) = 6 agentes

    O cluster aumentaria de 5 para 6 agentes, então a verificação de segurança de 10% é acionada.

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

    • 75 vCPUs / 5 agentes = 15 vCPUs por agente

    • 130 GiB / 5 agentes = 26 GiB por agente

  • Com 6 agentes, as novas médias são:

    • 80 vCPUs / 6 agentes = 13,33 vCPUs por agente, uma redução de 11,1%

    • 140 GiB / 6 agentes = 23,33 GiB por agente, 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 o cluster para 85 vCPUs e 150 GiB de RAM.

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

    • teto (85 vCPUs / 15) = 6 agentes

    O cluster aumentaria de 5 para 6 agentes, então a verificação de segurança de 10% é acionada.

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

    • 75 vCPUs / 5 agentes = 15 vCPUs por agente

    • 130 GiB / 5 agentes = 26 GiB por agente

  • Com 6 agentes, as novas médias são:

    • 85 vCPUs / 6 agentes = 14,17 vCPUs por agente, uma redução de 5,5%

    • 150 GiB / 6 agentes = 25 GiB por agente, uma redução de 3,8%

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

Estimar o tamanho do disco necessário

Por padrão, o Serviço Gerenciado para Apache Kafka aloca 100 GiB por vCPU para cada agente. A alocação padrão fornece armazenamento local suficiente para a maioria das cargas de trabalho, mas você pode configurar o tamanho do disco do agente para seus requisitos específicos. Esta seção descreve como estimar a quantidade de capacidade de disco necessária.

Quando um agente recebe uma mensagem, ele a grava em um arquivo de segmento local. Quando o arquivo de segmento atinge um tamanho ou idade máxima, ele é fechado (ou "rolado") e movido para o armazenamento remoto. O tamanho máximo de um arquivo de segmento é especificado pela configuração log.roll.bytes, e a idade máxima é especificada pela configuração log.segment.ms.

Quando um arquivo de segmento é rolado, o agente abre um novo arquivo de segmento. O segmento rolado permanece no armazenamento local enquanto o agente o copia para o armazenamento remoto. Portanto, cada partição precisa de espaço suficiente para armazenar um arquivo de segmento rolado, além de espaço para um novo arquivo de segmento enquanto o segmento rolado está sendo movido para o armazenamento remoto.

Por padrão, o tamanho máximo de um arquivo de segmento é de 230 MiB. Para clusters com utilização moderada, é possível presumir que 250 MiB são necessários por partição, para fornecer espaço de buffer adicional enquanto um segmento rolado está sendo movido. Usando essa suposição, o tamanho mínimo do disco por agente é:

250 MiB * partition count * replication factor / broker count

No entanto, o tamanho necessário depende de fatores como o tamanho máximo do arquivo de segmento, a carga no cluster, a taxa em que novos dados são gravados e a latência de gravações no armazenamento de longo prazo.

É fundamental manter alguma capacidade de disco não utilizada em cada agente. O comportamento de um agente sem capacidade de disco não é previsível e pode resultar em perda de dados e instabilidade do cluster. Monitore o uso do disco (disk/used_bytes) em relação ao tamanho total do disco disponível (disk/limit). Se o uso do disco for superior a 80% do tamanho total do disco disponível, configure um tamanho de disco maior. Para mais informações, consulte Monitorar a capacidade do cluster.

A seguir