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 para agentes Express
Este tópico descreve algumas práticas recomendadas a seguir ao usar agentes Express. Os agentes Express vêm pré-configurados para proporcionar alta disponibilidade e durabilidade. Seus dados estão distribuídos em três zonas de disponibilidade por padrão, a replicação está sempre definida como 3 e a réplica mínima em sincronização está sempre definida como 2. No entanto, ainda há alguns fatores a considerar para otimizar a confiabilidade e o desempenho do seu cluster.
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 nas recomendações de melhores práticas para clientes do Apache Kafka.
Execute testes de desempenho para verificar se as configurações do seu cliente permitem que você atinja seus objetivos de desempenho mesmo quando reiniciarmos os agentes com carga máxima. Você pode reinicializar os agentes em seu cluster a partir do console do MSK ou usando o MSK. APIs
Considerações do lado do servidor
Tópicos
Dimensione seu cluster adequadamente: número de agentes por cluster
É fácil escolher o número de agentes para seu cluster baseado no Express. Cada agente Express vem com uma capacidade de throughput definida para entrada e saída. Use essa capacidade de throughput como o principal meio para dimensionar o cluster (e depois considerar outros fatores, como partição e contagem de conexões, discutidos abaixo).
Por exemplo, se seu aplicativo de streaming precisar MBps de 45% de capacidade de entrada (gravação) e 90 de saída de MBps dados (leitura), você pode simplesmente usar 3 corretores express.m7g.large para atender às suas necessidades de taxa de transferência. Cada corretora express.m7g.large lidará com 15% MBps das entradas e 30% das saídas. MBps Consulte a tabela a seguir para ver nossos limites de throughput recomendados para cada tamanho de agente Express. Se o throughput exceder os limites recomendados, poderá ocorrer a degradação do desempenho e você deverá reduzir o tráfego ou escalar o cluster. Se seu throughput exceder os limites recomendados e atingir a cota por agente, o MSK limitará o tráfego do seu cliente para evitar mais sobrecarga.
Você também pode usar nossa planilha de Dimensionamento e preços do MSK
A tabela a seguir apresenta o throughput máximo recomendado por agente para cada tamanho de instância.
| Tamanho da instância | Entrada () MBps | Saída () MBps |
|---|---|---|
|
|
15,6 | 31.2 |
|
|
31.2 | 62.5 |
|
|
62.5 | 125,0 |
|
|
124,9 | 249,8 |
|
|
250,0 | 500,0 |
|
|
375,0 | 750,0 |
|
|
500,0 | 1000,0 |
Monitorar uso da CPU
Recomendamos veementemente que você mantenha a utilização total da CPU de seus agentes (definida como CPU do usuário + CPU do sistema) 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. Isso pode ser necessário devido a eventos planejados ou não planejados. Um exemplo de evento planejado é um upgrade da versão do cluster durante o qual o MSK atualiza os agentes em um cluster, reiniciando-os um por vez. Um exemplo de evento não planejado é uma falha de hardware em um agente ou, na pior das hipóteses, uma falha de AZ em que todos os agentes de uma AZ são afetados. Quando os agentes com réplicas de liderança das partições 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 o uso de expressões matemáticas com CloudWatch métricas no Guia CloudWatch do usuário da Amazon para criar uma métrica composta que é Usuário da CPU + Sistema da CPU. 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: atualize o tamanho do agente para o próximo tamanho maior. 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.
Opção 2: expanda seu cluster adicionando agentes e, em seguida, reatribua as partições existentes usando a ferramenta
kafka-reassign-partitions.shde reatribuição de partições.
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, 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 atributo Prometheus, é recomendável 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.
Dimensione seu cluster adequadamente: número de partições por agente Express
Se houver 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
-
Associe um AWS Secrets Manager segredo a um cluster que tenha SASL/SCRAM autenticação
Um cluster sobrecarregado com um grande número de partições também pode resultar na falta de métricas do Kafka na coleta de dados do CloudWatch Prometheus.
Para obter orientações sobre como escolher o número de partições, consulte Apache Kafka Supports 200K Partitions Per Cluster
Para saber mais sobre o número recomendado de partições (incluindo partições líderes e seguidoras) para cada agente Express, consulte Cota de partição do agente Express. 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.
Monitorar o número de conexões
As conexões do cliente aos seus agentes consomem recursos do sistema, como memória e CPU. Dependendo do mecanismo de autenticação, você deve monitorar para garantir que está dentro dos limites aplicáveis. Para processar novas tentativas em conexões com falha, você pode definir o parâmetro de configuração reconnect.backoff.ms no lado do cliente. Por exemplo, se você quiser que um cliente tente novamente as conexões após 1 segundo, defina reconnect.backoff.ms como 1000. Para obter mais informações sobre novas tentativas de configuração, consulte a documentação do Apache Kafka.
| Dimensão | Quota |
|---|---|
|
Máximo de conexões TCP por agente (Controle de acesso IAM) |
3000 |
|
Máximo de conexões TCP por agente (IAM) |
100 por segundo |
|
Máximo de conexões TCP por agente (não IAM) |
O MSK não impõe limites de conexão para autenticação que não seja do IAM. No entanto, você deve monitorar outras métricas, como uso de CPU e memória, para garantir que seu cluster não fique sobrecarregado devido ao excesso de conexões. |
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 20 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
