Práticas recomendadas

Este tópico descreve algumas das melhores práticas a serem seguidas ao usar a AmazonMSK.

Dimensione seu cluster adequadamente: número de partições por agente

A tabela a seguir mostra o número recomendado de partições (incluindo partições líderes e seguidoras) por agente.

Tamanho do corretor	Número recomendado de partições (incluindo partições líderes e seguidoras) por agente
kafka.t3.small	300
kafka.m5.large ou kafka.m5.xlarge	1000
kafka.m5.2xlarge	2000
kafka.m5.4xlarge, kafka.m5.8xlarge, kafka.m5.12xlarge, kafka.m5.16xlarge ou kafka.m5.24xlarge	4000
kafka.m7g.large ou kafka.m7g.xlarge	1000
kafka.m7g.2xlarge	2000
kafka.m7g.4xlarge,kafka.m7g.8xlarge,kafka.m7g.12xlarge, ou kafka.m7g.16xlarge	4000

Se o número de partições por agente exceder o valor recomendado e seu cluster ficar sobrecarregado, você poderá ser impedido de realizar as seguintes operações:

• Atualizar a configuração do cluster

• Atualize o cluster para um tamanho de agente menor

• Associe um AWS Secrets Manager segredo a um cluster que tenha SCRAM autenticaçãoSASL/

Um grande número de partições também pode resultar na falta de métricas do Kafka na coleta de dados do Prometheus. CloudWatch

Para obter orientações sobre como escolher o número de partições, consulte Apache Kafka Supports 200K Partitions Per Cluster. Também recomendamos que você realize seus próprios testes para determinar o tamanho certo para seus corretores. Para obter mais informações sobre os diferentes tamanhos de corretores, consulteTamanhos de corretores.

Dimensione seu cluster adequadamente: número de agentes por cluster

Para determinar o número certo de corretores para seu MSK cluster e entender os custos, consulte a planilha de MSKdimensionamento e preços. Essa planilha fornece uma estimativa do tamanho de um MSK cluster e dos custos associados da Amazon MSK em comparação com um cluster similar, autogerenciado e EC2 baseado no Apache Kafka. Para obter mais informações sobre os parâmetros de entrada na planilha, passe o mouse sobre as descrições dos parâmetros. As estimativas fornecidas por essa planilha são conservadoras e fornecem um ponto de partida para um novo cluster. O desempenho, o tamanho e os custos do cluster dependerão do seu caso de uso e recomendamos que você os verifique com testes reais.

Para entender como a infraestrutura subjacente afeta o desempenho do Apache Kafka, consulte Melhores práticas para dimensionar corretamente seus clusters do Apache Kafka para otimizar desempenho e custo no blog de Big Data. AWS A postagem do blog fornece informações sobre como dimensionar seus clusters para atender aos requisitos de throughput, disponibilidade e latência. Ela também fornece respostas para perguntas como quando você deve aumentar a escala verticalmente ou horizontalmente, além de orientações sobre como verificar continuamente o tamanho dos seus clusters de produção.

Otimize a taxa de transferência do cluster para instâncias m5.4xl, m7g.4xl ou maiores

Ao usar instâncias m5.4xl, m7g.4xl ou maiores, você pode otimizar a taxa de transferência do cluster ajustando as configurações num.io.threads e num.network.threads.

Num.io.threads é o número de threads que um agente usa para processar solicitações. Adicionar mais threads, até o número de CPU núcleos compatíveis com o tamanho da instância, pode ajudar a melhorar a taxa de transferência do cluster.

Num.network.threads é o número de threads que o agente usa para receber todas as solicitações recebidas e retornar respostas. Os threads de rede colocam as solicitações recebidas em uma fila de solicitações para processamento por io.threads. Definir num.network.threads como metade do número de CPU núcleos suportados para o tamanho da instância permite o uso total do novo tamanho da instância.

Importante

Não aumente num.network.threads sem antes aumentar num.io.threads, pois isso pode causar congestionamento relacionado à saturação da fila.

Configurações recomendadas
Tamanho da instância	Valor recomendado para num.io.threads	Valor recomendado para num.network.threads
m5.4xl	16	8
m5.8xl	32	16
m5.12xl	48	24
m5.16xl	64	32
m5.24xl	96	48
m7g.4xlarge	16	8
m7g.8xlarge	32	16
m7g.12xlarge	48	24
m7g.16xlarge	64	32

Use o Kafka mais recente AdminClient para evitar problemas de incompatibilidade de ID de tópico

O ID de um tópico é perdido (Erro: não corresponde ao ID do tópico para partição) quando você usa uma AdminClient versão do Kafka inferior à 2.8.0 com o sinalizador --zookeeper para aumentar ou reatribuir partições de tópico para um cluster usando a versão 2.8.0 ou superior do Kafka. Observe que o sinalizador --zookeeper ficou obsoleto no Kafka 2.5 e foi removido desde o Kafka 3.0. Consulte Atualização para a versão 2.5.0 de qualquer versão entre 0.8.x e 2.4.x.

Para evitar incompatibilidade de ID de tópico, use um cliente do Kafka versão 2.8.0 ou superior para operações administrativas do Kafka. Como alternativa, clientes 2.5 e superiores podem usar o sinalizador --bootstrap-servers em vez do sinalizador --zookeeper.

Criar clusters altamente disponíveis

Use as recomendações a seguir para que seu MSK cluster possa estar altamente disponível durante uma atualização (como quando você estiver atualizando o tamanho do broker ou a versão do Apache Kafka, por exemplo) ou quando a Amazon MSK estiver substituindo um agente.

• Configure um cluster com três zonas de disponibilidade.

• Certifique-se de que o Replication factor (RF – Fator de replicação) seja pelo menos 3. Observe que um RF de 1 pode resultar em partições offline durante uma atualização contínua; e um RF de 2 pode resultar em perda de dados.

• Defina o mínimo de réplicas sincronizadas (minISR) para no máximo RF - 1. Um mínimo ISR igual à RF pode impedir a produção no cluster durante uma atualização contínua. Um mínimo ISR de 2 permite que tópicos replicados em três vias estejam disponíveis quando uma réplica estiver off-line.

• Certifique-se de que as strings de conexão do cliente incluam pelo menos um agente de cada zona de disponibilidade. Ter vários agentes na string de conexão de um cliente possibilita o failover quando um agente específico estiver offline para uma atualização. Para obter informações sobre como obter uma string de conexão com vários agentes, consulte Obtendo os corretores de bootstrap para um cluster da Amazon MSK.

Monitore CPU o uso

A Amazon recomenda MSK fortemente que você mantenha a CPU utilização total de seus corretores (definida comoCPU User + CPU System) abaixo de 60%. Quando você tem pelo menos 40% do total do seu cluster CPU disponível, o Apache Kafka pode redistribuir a CPU carga entre os corretores no cluster quando necessário. Um exemplo de quando isso é necessário é quando a Amazon MSK detecta e se recupera de uma falha do corretor; nesse caso, a Amazon MSK realiza manutenção automática, como a aplicação de patches. Outro exemplo é quando um usuário solicita uma alteração no tamanho do corretor ou um upgrade de versão; nesses dois casos, a Amazon MSK implanta fluxos de trabalho contínuos que colocam um corretor off-line por vez. Quando os agentes com partições principais ficam offline, o Apache Kafka reatribui a liderança da partição para redistribuir o trabalho para outros agentes no cluster. Ao seguir essa prática recomendada, você pode garantir que tenha CPU espaço suficiente em seu cluster para tolerar eventos operacionais como esses.

Você pode usar a matemática CloudWatch métrica da Amazon para criar uma métrica composta que sejaCPU User + CPU System. Defina um alarme que seja acionado quando a métrica composta atingir uma CPU utilização média de 60%. Quando esse alarme for acionado, escale o cluster usando uma das seguintes opções:

• Opção 1 (recomendada): atualize o tamanho do seu corretor para o próximo tamanho maior. Por exemplo, se o tamanho atual forkafka.m5.large, atualize o cluster a ser usadokafka.m5.xlarge. Lembre-se de que, quando você atualiza o tamanho do broker no cluster, a Amazon MSK coloca os corretores off-line de forma contínua e transfere temporariamente a liderança da partição para outros corretores. Normalmente uma atualização de tamanho leva de 10 a 15 minutos por agente.

• Opção 2: se houver tópicos com todas as mensagens ingeridas de produtores que usam gravações de ida e volta (em outras palavras, as mensagens não recebem chaves e a ordenação não é importante para os consumidores), expanda seu cluster adicionando agentes. Também adicione partições aos tópicos existentes com o maior throughput. Em seguida, use kafka-topics.sh --describe para garantir que as partições recém-adicionadas sejam atribuídas aos novos agentes. O principal benefício dessa opção em comparação com a anterior é que você pode gerenciar recursos e custos de modo mais granular. Além disso, você pode usar essa opção se a CPU carga exceder significativamente 60%, pois essa forma de escalonamento normalmente não resulta em aumento de carga nos corretores existentes.

• Opção 3: expanda seu cluster adicionando agentes e, em seguida, reatribua as partições existentes usando a ferramenta de reatribuição de partições chamada kafka-reassign-partitions.sh. No entanto, se você usar essa opção, o cluster precisará gastar recursos para replicar dados de um agente para outro após a reatribuição das partições. Em comparação com as duas opções anteriores, inicialmente isso pode aumentar significativamente a carga no cluster. Como resultado, a Amazon MSK não recomenda usar essa opção quando a CPU utilização está acima de 70%, pois a replicação causa CPU carga e tráfego de rede adicionais. A Amazon MSK só recomenda usar essa opção se as duas opções anteriores não forem viáveis.

Outras recomendações:

• Monitore CPU a utilização total por corretor como proxy para distribuição de carga. Se os corretores tiverem uma CPU utilização consistentemente desigual, pode ser um sinal de que a carga não está distribuída uniformemente no cluster. MSKA Amazon recomenda o uso do Cruise Control para gerenciar continuamente a distribuição de carga por meio da atribuição de partições.

• Monitore a latência da produção e do consumo. A latência de produção e consumo pode aumentar linearmente com CPU a utilização.

• JMXintervalo de raspagem: se você habilitar o monitoramento aberto com o recurso Prometheus, é recomendável usar um intervalo de raspagem de 60 segundos ou mais (scrape_interval: 60s) para a configuração do host Prometheus (prometheus.yml). Reduzir o intervalo de coleta pode levar a um alto CPU uso do seu cluster.

Monitorar o espaço em disco

Para evitar a falta de espaço em disco para mensagens, crie um CloudWatch alarme que observe a KafkaDataLogsDiskUsed métrica. Quando o valor dessa métrica atingir ou exceder 85%, execute uma ou mais das seguintes ações:

• Usar Escalabilidade automática. Você também pode aumentar manualmente o armazenamento do agente, conforme descrito em Escalabilidade manual.

• Reduza o período de retenção de mensagens ou o tamanho do log. Para obter informações sobre como fazer isso, consulte Ajustar os parâmetros de retenção de dados.

• Exclua tópicos não utilizados.

Para obter informações sobre como configurar e usar alarmes, consulte Usando alarmes da Amazon CloudWatch . Para obter uma lista completa das MSK métricas da Amazon, consulteMonitorando um MSK cluster da Amazon.

Ajustar os parâmetros de retenção de dados

Consumir mensagens não as remove do log. Para liberar espaço em disco regularmente, é possível especificar explicitamente um período de retenção, ou seja, por quanto tempo as mensagens permanecem no log. Também é possível especificar um tamanho do log de retenção. Quando o período de retenção ou o tamanho do log de retenção são atingidos, o Apache Kafka começa a remover segmentos inativos do log.

Para especificar uma política de retenção no nível do cluster, defina um ou mais dos seguintes parâmetros: log.retention.hours, log.retention.minutes, log.retention.ms ou log.retention.bytes. Para ter mais informações, consulte Configurações personalizadas do MSK.

Também é possível especificar parâmetros de retenção no nível do tópico:

• Para especificar um período de retenção por tópico, use o comando a seguir.

  kafka-configs.sh --bootstrap-server $bs --alter --entity-type topics --entity-name TopicName --add-config retention.ms=DesiredRetentionTimePeriod

• Para especificar um tamanho de log de retenção por tópico, use o comando a seguir.

  kafka-configs.sh --bootstrap-server $bs --alter --entity-type topics --entity-name TopicName --add-config retention.bytes=DesiredRetentionLogSize

Os parâmetros de retenção especificados no nível do tópico têm precedência sobre os parâmetros no nível do cluster.

Como acelerar a recuperação de logs após um desligamento inadequado

Após um desligamento inadequado, um agente pode demorar um pouco para reiniciar, pois registra a recuperação em log. Por padrão, o Kafka usa apenas um thread por diretório de log para realizar essa recuperação. Por exemplo, se você tiver milhares de partições, a conclusão da recuperação do log pode levar horas. Para acelerar a recuperação do log, recomenda-se aumentar o número de threads usando a propriedade de configuração num.recovery.threads.per.data.dir. Você pode configurá-lo para o número de CPU núcleos.

Monitorar a memória do Apache Kafka

Recomendamos que você monitore a memória que o Apache Kafka usa. Caso contrário, o cluster pode ficar indisponível.

Para determinar quanta memória o Apache Kafka usa, você pode monitorar a métrica HeapMemoryAfterGC. HeapMemoryAfterGC é o percentual da memória total da pilha que está em uso após a coleta de resíduos. Recomendamos que você crie um CloudWatch alarme que atue quando HeapMemoryAfterGC aumentar acima de 60%.

As etapas que você pode seguir para diminuir o uso da memória variam. Elas dependem da forma como você configura o Apache Kafka. Por exemplo, se você usar a entrega de mensagens transacionais, poderá diminuir o valor transactional.id.expiration.ms na configuração do Apache Kafka de 604800000 ms para 86400000 ms (de 7 dias para 1 dia). Isso diminui o espaço ocupado na memória de cada transação.

Não adicione não MSK corretores

Para clusters ZooKeeper baseados, se você usar ZooKeeper comandos do Apache para adicionar agentes, esses agentes não serão adicionados ao seu MSK cluster e seu Apache ZooKeeper conterá informações incorretas sobre o cluster. Isso pode resultar em perda de dados. Para consultar as operações de cluster compatíveis, consulte AmazonMSK: Como funciona.

Ativar a criptografia em trânsito

Para obter informações sobre a criptografia em trânsito e como ativá-la, consulte Criptografia em trânsito.

Reatribuir partições

Para mover partições para agentes diferentes no mesmo cluster, é possível usar a ferramenta de reatribuição de partições, chamada kafka-reassign-partitions.sh. Por exemplo, depois de adicionar novos agentes para expandir um cluster ou mover partições para remover agentes, você pode reequilibrar esse cluster reatribuindo partições aos novos corretores. Para obter informações sobre como adicionar agentes a um cluster, consulte Expandindo um MSK cluster da Amazon. Para obter informações sobre como remover agentes de um cluster, consulteRemover um agente de um MSK cluster da Amazon. Para obter informações sobre a ferramenta de reatribuição de partições, consulte Expanding your cluster na documentação do Apache Kafka.