Como posso solucionar problemas de alto uso da CPU em um ou mais agentes em um cluster do Amazon MSK?

7 minuto de leitura
0

Preciso solucionar problemas de alto uso da CPU em um ou mais agentes no meu cluster do Amazon Managed Streaming for Apache Kafka (Amazon MSK).

Resolução

A utilização total da CPU para um cluster do Amazon MSK é calculada como a soma do seguinte:

  • Porcentagem de CPU no espaço do usuário definida pela métrica CpuUser
  • Porcentagem de CPU no espaço do kernel que é definido pelo CpuSystem

É uma prática recomendada manter a utilização total da CPU em menos de 60% para que 40% da CPU do seu cluster esteja disponível. O Apache Kafka pode redistribuir a carga da CPU entre os agentes no cluster, conforme necessário. Por exemplo, quando o Amazon MSK se recupera de uma falha do agente, a CPU disponível pode ser usada para realizar manutenção automática, como a aplicação de patches.

A seguir estão algumas das causas mais comuns de alto uso da CPU no seu cluster do Amazon MSK:

  • O tráfego de entrada ou saída é alto.
  • O número de partições por agente foi excedido, sobrecarregando o cluster.
  • Você está usando uma instância do tipo T.

O tráfego de entrada ou saída é alto

Você pode monitorar o tráfego de entrada e saída para o cluster usando as métricas BytesInPerSec e BytesOutPerSec do Amazon CloudWatch. Se essas métricas de um agente tiverem valores altos ou estiverem distorcidas, o agente pode estar passando por alto uso da CPU. A seguir estão algumas das causas do alto tráfego de entrada e saída:

  • A contagem de partições para o tópico que recebe alto tráfego não é distribuída uniformemente entre os agentes. Ou o produtor não está enviando dados uniformemente para todas as partições. Certifique-se de verificar sua chave de particionamento do produtor e atualizar a configuração do cluster adequadamente. Certifique-se de configurar a chave de partição de forma que uma partição não receba mais dados do que as demais.
  • O grupo de consumidores está confirmando offsets com muita frequência. O tráfego das confirmações de offsets afeta o agente. Nesses casos, você vê um valor significativamente alto de MessagesInPerSec para o agente que é líder na partição de tópico _consumer_offset. Essa é a partição à qual o grupo de consumidores offset é confirmado. Para resolver esse problema, reduza o número de grupos de consumidores ou atualize o tamanho da sua instância.

O número de partições por agente foi excedido

Se o número de partições por agente exceder o valor recomendado, seu cluster ficará sobrecarregado. Nesse caso, talvez você não consiga fazer o seguinte:

  • Atualizar a configuração do cluster.
  • Atualizar a versão do Apache Kafka para o cluster.
  • Atualizar o cluster para um tipo de agente menor.
  • Associar um segredo do AWS Secrets Manager a um cluster que tenha autenticação SASL/SCRAM.

Ter muitas partições causa degradação da performance devido ao alto uso da CPU. Isso significa que cada partição usa uma certa quantidade de recursos do agente, mesmo quando há pouco tráfego. Para resolver esse problema, tente o seguinte:

  • Exclua tópicos obsoletos ou não utilizados para colocar a contagem de partições dentro do limite recomendado.
  • Amplie o tipo de instância do agente para o tipo que possa acomodar o número de partições de que você precisa. Além disso, tente adicionar mais agentes e reatribuir partições.

Observe que partições não são reatribuídas automaticamente quando você adiciona agentes. É necessário executar o comando kafka-reassign-partitions. Para mais informações, consulte Reatribuir partições depois de alterar o tamanho do cluster.

Você está usando uma instância de tipo T

Observe que as instâncias de tipo T têm performance básica com alguns recursos intermitentes. Essas instâncias permitem uma performance básica de 20% de utilização da CPU. Se você exceder esse valor, o tipo de instância começará a usar os créditos de CPU. Quando a utilização é inferior a 20%, os créditos de CPU são acumulados.

Certifique-se de monitorar a métrica do saldo de crédito da CPU no Amazon CloudWatch. Os créditos são acumulados no saldo de créditos após terem sido ganhos e são removidos do saldo de créditos quando são gastos. O saldo de crédito tem um limite máximo, determinado pelo tamanho da instância. Depois que esse limite for atingido, todos os novos créditos ganhos serão descartados. Para o tipo de instância T2 Standard, os créditos de execução não contam para o limite.

Os créditos de CPU indicados pela métrica CPUCreditBalance estão disponíveis para a instância gastar até ultrapassar sua utilização básica da CPU. Quando uma instância está em execução, os créditos em CPUCreditBalance não expiram. Quando uma instância T4g, T3a ou T3 é interrompida, o valor de CPUCreditBalance persiste por sete dias. Depois de sete dias, você perderá todos os créditos acumulados. Quando uma instância T2 é interrompida, o valor de CPUCreditBalance não persiste, e você perde todos os créditos acumulados. As métricas de crédito da CPU estão disponíveis em uma frequência de cinco minutos.

Certifique-se de monitorar o uso básico da CPU e o saldo de crédito de qualquer cluster executado em instâncias de tipo T. Se o uso da CPU for maior do que a linha de base e não houver mais créditos para gastar, o cluster terá problemas de performance.

Outras causas

  • O número de conexões com o cliente é alto: Um aumento em qualquer uma das seguintes métricas do CloudWatch pode fazer com que o uso da CPU do agente aumente. Para solucionar esse problema, monitore essas métricas no CloudWatch. Em seguida, reduza a contagem de conexões conforme necessário ou aumente a escala verticalmente para o tipo de agente.
    • ConnectionCount
    • ConnectionCreationRate
    • ConnectionCloseRate
  • O número de grupos de consumidores é alto: Se o número de grupos de consumidores for alto (por exemplo, mais de 1000), o uso da CPU pelo agente poderá aumentar. O alto uso da CPU também pode ocorrer quando um grupo de consumidores está confirmando offsets com muita frequência. Para resolver esse problema, reduza o número de grupos de consumidores ou atualize o tamanho da sua instância.
  • O Amazon MSK detecta e se recupera de uma falha do agente: Nesse caso, o Amazon MSK executa uma operação de manutenção automática, como a aplicação de patches, resultando em um aumento no uso da CPU.
  • Um usuário solicita uma alteração de tipo de agente ou atualização de versão: Nesse caso, o Amazon MSK implanta fluxos de trabalho contínuos que colocam um agente offline por vez. Quando agentes com partições líderes ficam offline, o Apache Kafka reatribui a liderança da partição para redistribuir o trabalho a outros agentes no cluster. Monitore o uso da CPU para esses agentes e certifique-se de que você tenha espaço livre de CPU suficiente em seu cluster para tolerar eventos operacionais.
  • O uso da CPU para um ou mais agentes é alto devido à distribuição distorcida de dados: Por exemplo, se dois agentes em cada seis forem contratados e consumidos mais, haverá maior uso da CPU. Para resolver esse problema, certifique-se de usar a técnica de circularidade para que as partições no cluster sejam bem distribuídas. Execute o comando topic describe para ver como as partições são distribuídas pelo cluster. A saída pode ser semelhante à seguinte:
bin/kafka-topics.sh -bootstrap-server $MYBROKERS --describe --topic my-topic
    Topic:my-topic    PartitionCount:7 ReplicationFactor:3 Configs:
    Topic: my-topic    Partition: 0 Leader: 1 Replicas: 1,3,2 Isr: 1,3,2
    Topic: my-topic    Partition: 1 Leader: 2 Replicas: 2,1,3 Isr: 2,1,3
    Topic: my-topic    Partition: 2 Leader: 3 Replicas: 3,2,1 Isr: 3,2,1
    Topic: my-topic    Partition: 3 Leader: 1 Replicas: 1,2,3 Isr: 1,2,3
    Topic: my-topic    Partition: 4 Leader: 2 Replicas: 2,3,1 Isr: 2,3,1
    Topic: my-topic    Partition: 5 Leader: 3 Replicas: 3,1,2 Isr: 3,1,2
  • Você ativou o monitoramento aberto: Se você ativou o monitoramento aberto com o Prometheus e o intervalo de exploração for baixo, isso poderá gerar um grande número de métricas emitidas. Isso leva a um aumento no uso da CPU. Para resolver esse problema, aumente o intervalo de exploração.
AWS OFICIAL
AWS OFICIALAtualizada há um ano