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á.
Melhores práticas para agentes Standard
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 da sua aplicação 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 agentes ficarão offline em eventos planejados e não planejados, como, por exemplo, atualizações, aplicação de patches, 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 em Práticas recomendadas para clientes 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 adequadamente: número de partições por agente Standard
A tabela a seguir mostra o número recomendado de partições (incluindo partições líderes e seguidoras) por agente Standard. 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 para 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 as 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ê tiver casos de uso de partição alta e throughput baixo com um número maior de partições, mas que não está enviando tráfego para todas as partições, você poderá empacotar mais partições por agente se tiver realizado testes normais e de desempenho suficientes para validar se o cluster permanecerá íntegro com o aumento no número de partições. Se o número de partições por agente exceder o máximo permitido e seu cluster ficar sobrecarregado, você poderá ser impedido de realizar as seguintes operações:
-
Atualizar a configuração do cluster
-
Atualizar o cluster para um tamanho de agente menor
-
Associar um segredo do AWS Secrets Manager 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 no CloudWatch e na extração de dados do Prometheus.
Para obter orientações sobre como escolher o número de partições, consulte Apache Kafka Supports 200K Partitions Per Cluster
Dimensione seu cluster adequadamente: número de agentes Standard por cluster
Para determinar o número certo de agentes Standard correto para seu cluster do MSK e entender os custos, consulte a planilha Preço e dimensionamento do MSK
Para entender como a infraestrutura subjacente afeta o desempenho do Apache Kafka, consulte Práticas recomendadas para dimensionar corretamente seus clusters do Apache Kafka a fim de otimizar o desempenho e custo
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 o throughput do cluster do MSK Provisioned ajustando as configurações num.io.threads e num.network.threads.
Num.io.threads é o número de threads que um agente Standard 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 agente Standard usa para receber todas as solicitações que entraram e para 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.
A tabela a seguir descreve as configurações recomendadas para cada tamanho de instância.
| 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 |
Usar o Kafka AdminClient mais recente 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 versão do Kafka AdminClient inferior à 2.8.0 com o sinalizador --zookeeper para aumentar ou reatribuir partições de tópicos para um cluster do MSK Provisioned 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
Aplique as recomendações a seguir para que os clusters do MSK Provisioned permaneçam altamente disponíveis durante uma atualização (p. ex., quando você estiver atualizando o tamanho do agente ou a versão do Apache Kafka) 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 da CPU de seus agentes (definida como CPU User + CPU System) abaixo de 60%. Isso garante que seu cluster retenha espaço suficiente na CPU para lidar com eventos operacionais, como falhas de agentes, patches e atualizações contínuas.
O Apache Kafka poderá redistribuir a carga da CPU entre os agentes no cluster quando necessário. Por exemplo, quando o Amazon MSK detecta e se recupera de uma falha do agente, ele executa a manutenção automática, como a aplicação de patches. De forma similar, quando um usuário solicita uma alteração do tamanho do agente ou um upgrade de versão, o Amazon MSK inicia a implantação de 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ê garante disponibilidade suficiente da CPU para tolerar esses eventos operacionais.
nota
Ao monitorar a utilização da CPU, esteja ciente de que o uso total da CPU inclui mais do que CPU User e CPU System. Outras categorias, comoiowait, irq, softirq e steal, também contribuem para a atividade geral da CPU. Consequentemente, uma CPU ociosa nem sempre é igual a 100% - CPU User - CPU System.
Você pode usar a Amazon CloudWatch Metric Math para criar uma métrica composta (CPU User + CPU System) e definir um alarme a ser acionado quando o uso médio exceder 60%. Quando esse alarme for acionado, considere escalar 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 do MSK Provisioned adicionando agentes e, em seguida, reatribua as partições existentes usando a ferramenta
kafka-reassign-partitions.shde reatribuição de partições. 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, 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 ficar sem espaço em disco para mensagens, crie um alarme do CloudWatch que observe a métrica KafkaDataLogsDiskUsed. 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 agentes Standard.
-
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 Usar alarmes do Amazon CloudWatch. Para obter uma lista completa das métricas do Amazon MSK, consulte Monitorar um cluster do Amazon MSK Provisioned.
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 alarme do CloudWatch que seja acionado 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 do MSK Provisioned baseados no ZooKeeper, se você usar comandos do Apache ZooKeeper para adicionar agentes, esses agentes não serão adicionados ao cluster do MSK Provisioned, e o Apache ZooKeeper conterá informações incorretas sobre o cluster. Isso pode resultar em perda de dados. Para acessar as operações compatíveis do cluster do MSK Provisioned, 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 agentes diferentes no mesmo cluster do MSK Provisioned, é possível usar a ferramenta kafka-reassign-partitions.sh de reatribuição de partições. Recomendamos que você não reatribua mais de 10 partições em uma única chamada kafka-reassign-partitions para garantir a segurança das operações. 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 do MSK Provisioned, consulte Expandir o número de agentes em um cluster do Amazon MSK. Para obter informações sobre como remover agentes de um cluster do MSK Provisioned, 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
