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á.
Este tópico descreve algumas práticas recomendadas para seguir ao usar o Amazon MSK. Para obter informações sobre as práticas recomendadas do Replicador do Amazon MSK, consulte Práticas recomendadas para usar o replicador do MSK.
Considerações do lado do cliente
A disponibilidade e o desempenho do seu aplicativo dependem não apenas das configurações do lado do servidor, mas também das configurações do cliente.
-
Configure seus clientes para alta disponibilidade. Em um sistema distribuído como o Apache Kafka, garantir a alta disponibilidade é crucial para manter uma infraestrutura de mensagens confiável e tolerante a falhas. Os corretores ficarão off-line para eventos planejados e não planejados, por exemplo, atualizações, correções, falhas de hardware e problemas de rede. Um cluster do Kafka é tolerante a um agente offline, portanto, os clientes Kafka também devem lidar perfeitamente com o failover do agente. Veja os detalhes completos emMelhores práticas para clientes do Apache Kafka.
-
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 Obter os agentes de bootstrap para um cluster do Amazon MSK.
-
Execute testes de desempenho para verificar se as configurações do seu cliente permitem que você atinja seus objetivos de desempenho.
Considerações do lado do servidor
Dimensione seu cluster corretamente: número de partições por broker padrão
A tabela a seguir mostra o número recomendado de partições (incluindo réplicas líder e seguidora) por agente padrão. O número recomendado de partições não é imposto e é uma prática recomendada para cenários em que você está enviando tráfego por todas as partições de tópicos provisionadas.
| Tamanho do agente | Número recomendado de partições (incluindo partições líderes e seguidoras) por agente | Número máximo de partições que suportam operações de atualização |
|---|---|---|
kafka.t3.small |
300 | 300 |
kafka.m5.large ou kafka.m5.xlarge |
1000 | 1500 |
kafka.m5.2xlarge |
2000 | 3000 |
kafka.m5.4xlarge, kafka.m5.8xlarge, kafka.m5.12xlarge, kafka.m5.16xlarge ou kafka.m5.24xlarge |
4000 | 6000 |
kafka.m7g.large ou kafka.m7g.xlarge |
1000 | 1500 |
kafka.m7g.2xlarge |
2000 | 3000 |
kafka.m7g.4xlarge, kafka.m7g.8xlarge, kafka.m7g.12xlarge ou kafka.m7g.16xlarge |
4000 | 6000 |
Se você tem casos de uso de partição alta e baixa taxa de transferência em que tem um número maior de partições, mas não está enviando tráfego para todas as partições, você pode empacotar mais partições por agente, desde que tenha realizado testes e testes de desempenho suficientes para validar se o cluster permanece íntegro com o maior número de partições. Se o número de partições por agente exceder o valor máximo permitido e seu cluster ficar sobrecarregado, você será impedido de realizar as seguintes operações:
-
Atualizar a configuração do cluster
-
Atualizar o cluster para um tamanho de agente menor
-
Associe um AWS Secrets Manager segredo a um cluster que tenha autenticação SASL/SCRAM
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
Dimensione seu cluster corretamente: número de corretores padrão por cluster
Para determinar o número certo de corretores padrão para seu cluster provisionado pelo MSK e entender os custos, consulte a planilha de dimensionamento e preços do MSK
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
Otimizar o throughput 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 provisionado MSK ajustando as configurações num.io.threads e num.network.threads.
Num.io.threads é o número de threads que um agente padrão usa para processar solicitações. Adicionar mais threads, até o número de núcleos de CPU compatível com o tamanho da instância, pode ajudar a melhorar o throughput do cluster.
Num.network.threads é o número de threads que o corretor padrão 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 para a metade do número de núcleos de CPU compatível com o tamanho da instância permite o uso total do novo tamanho de 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.
| 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 para aumentar ou reatribuir partições de tópico --zookeeper para um cluster provisionado pelo MSK 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 seus clusters provisionados pelo MSK possam estar altamente disponíveis durante uma atualização (como quando você está atualizando o tamanho do agente ou a versão do Apache Kafka, por exemplo) ou quando o 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 réplicas mínimas em sincronização (minISR) para, no máximo, RF - 1. Uma minISR igual ao RF pode impedir a produção no cluster durante uma atualização sem interrupção. Uma minISR de 2 permite que tópicos replicados de três vias estejam disponíveis quando uma réplica estiver offline.
Monitorar uso da CPU
O Amazon MSK recomenda veementemente que você mantenha a utilização total da CPU de seus agentes (definida como CPU User + CPU System) abaixo de 60%. Quando você tiver ao menos 40% da CPU total do seu cluster disponível, o Apache Kafka poderá redistribuir a carga da CPU entre os agentes no cluster quando necessário. Por exemplo, isso é necessário quando o Amazon MSK detecta e se recupera de uma falha do agente. Nesse caso, o Amazon MSK realiza a manutenção automática, como a aplicação de patches. Outro exemplo é quando um usuário solicita uma alteração do tamanho do agente ou um upgrade de versão. Nesses dois casos, o Amazon MSK implanta fluxos de trabalho contínuos que colocam um agente offline 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 a disponibilidade suficiente de CPU 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 utilização média de 60% da CPU. Quando esse alarme for acionado, escale o cluster usando uma das seguintes opções:
-
Opção 1 (recomendada): atualize o tamanho do agente para o tamanho maior seguinte. Por exemplo, se o tamanho atual for
kafka.m5.large, atualize o cluster para usarkafka.m5.xlarge. Lembre-se de que, ao atualizar o tamanho do agente no cluster, o Amazon MSK coloca os agentes offline de forma contínua e reatribui temporariamente a liderança da partição para outros agentes. 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 --describepara 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 carga da CPU exceder significativamente 60%, pois essa forma de escalabilidade normalmente não resulta em aumento de carga nos agentes existentes. -
Opção 3: expanda seu cluster provisionado pelo MSK adicionando agentes e, em seguida, reatribua as partições existentes usando a ferramenta de reatribuição de partições chamada.
kafka-reassign-partitions.shNo 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, o Amazon MSK não recomenda usar essa opção quando a utilização da CPU estiver acima de 70%, pois a replicação causará carga adicional da CPU e tráfego de rede. O Amazon MSK recomenda usar essa opção somente se as duas opções anteriores não forem viáveis.
Outras recomendações:
-
Monitore a utilização total da CPU por agente como um indicador da distribuição de carga. Se os agentes tiverem uma utilização consistentemente desigual da CPU, isso pode ser um sinal de que a carga não está sendo distribuída uniformemente no cluster. Recomendamos 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 da produção e do consumo pode aumentar linearmente com a utilização da CPU.
-
Intervalo de extração do JMX: se você habilitar o monitoramento aberto com o recurso Prometheus, recomenda-se usar um intervalo de extração de 60 segundos ou mais (scrape_interval: 60s) para a configuração do host do Prometheus (prometheus.yml). A redução do intervalo de coleta pode levar a um alto uso da CPU em 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:
-
Use Escalabilidade automática para clusters do Amazon MSK. Você também pode aumentar manualmente o armazenamento do agente, conforme descrito em Dimensionamento manual para corretores padrão.
-
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 métricas do Amazon MSK, consulte Monitore um cluster provisionado do Amazon MSK.
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 Configurações personalizadas do Amazon 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-nameTopicName--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-nameTopicName--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. É possível defini-la com o número de núcleos de CPU.
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 adicionar agentes que não são do MSK
Para clusters provisionados pelo MSK ZooKeeper baseados, se você usar ZooKeeper comandos do Apache para adicionar agentes, esses agentes não serão adicionados ao seu cluster provisionado pelo MSK e seu Apache conterá informações incorretas sobre o cluster. ZooKeeper Isso pode resultar em perda de dados. Para obter as operações de cluster provisionadas do MSK suportadas, consulte. Principais recursos e conceitos do Amazon MSK
Ativar a criptografia em trânsito
Para obter informações sobre a criptografia em trânsito e como ativá-la, consulte Criptografia do Amazon MSK em trânsito.
Reatribuir partições
Para mover partições para diferentes agentes no mesmo cluster provisionado pelo MSK, você pode usar a ferramenta de reatribuição de partições chamada. kafka-reassign-partitions.sh Recomendamos que você não reatribua mais de 10 partições em uma única kafka-reassign-partitions chamada para operações seguras. Por exemplo, após adicionar novos agentes para expandir um cluster, ou mover partições a fim de remover agentes, você pode rebalancear esse cluster reatribuindo partições aos novos agentes. Para obter informações sobre como adicionar agentes a um cluster provisionado pelo MSK, consulte. Expandir o número de agentes em um cluster do Amazon MSK Para obter informações sobre como remover agentes de um cluster provisionado pelo MSK, consulte. Remover um agente de um cluster do Amazon MSK Para obter informações sobre a ferramenta de reatribuição de partições, consulte Expanding your cluster
