As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Práticas recomendadas

Este tópico descreve algumas das melhores práticas a serem seguidas ao usar a AmazonMSK. Para obter informações sobre as melhores práticas do Amazon MSK Replicator, consultePráticas recomendadas para usar o MSK Replicator.

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.

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:

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 MSK corretores da Amazon.

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 o desempenho e o 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.

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.

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:

Outras recomendações:

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:

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, consulteMonitore 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 obter mais informações, consulte MSKConfigurações personalizadas da Amazon.

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

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 MSKCriptografia da Amazon 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 Expanda o número de corretores em um cluster da Amazon MSK. 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.