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](msk-replicator-best-practices.md).
## 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](bestpractices-kafka-client.md).
+ 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](msk-get-bootstrap-brokers.md).
+ 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 corretor | Número recomendado de partições (incluindo partições líderes e seguidoras) por agente | Número máximo de partições compatíveis com 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
+ 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](https://blogs.apache.org/kafka/entry/apache-kafka-supports-more-partitions). Também recomendamos que você execute seu próprio teste para determinar o tipo certo para os agentes. Para obter mais informações sobre os diferentes tamanhos de agentes, consulte [Tipos de agentes do Amazon MSK](broker-instance-types.md).
### 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](https://view.officeapps.live.com/op/view.aspx?src=https%3A%2F%2Fdy7oqpxkwhskb.cloudfront.net%2FMSK_Sizing_Pricing.xlsx&wdOrigin=BROWSELINK). Essa planilha fornece uma estimativa para dimensionar um cluster do MSK Provisioned e os custos associados do Amazon MSK em relação a um cluster do Apache Kafka semelhante, autogerenciado e baseado no EC2. 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 do MSK Provisioned. 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](https://aws.amazon.com/blogs/big-data/best-practices-for-right-sizing-your-apache-kafka-clusters-to-optimize-performance-and-cost/) 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. Também respondem perguntas como quando você deve aumentar a escala *verticalmente* ou *horizontalmente*, além de fornecer orientações sobre como verificar continuamente o tamanho dos seus clusters de produção. Para obter informações sobre clusters baseados em armazenamento hierárquico, consulte [Melhores práticas para executar workloads de produção usando o armazenamento em camadas do Amazon MSK](https://aws.amazon.com/blogs/big-data/best-practices-for-running-production-workloads-using-amazon-msk-tiered-storage/).
### 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 |
### 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](https://kafka.apache.org/documentation.html#upgrade_2_5_0).
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, como`iowait`, `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 [matemática CloudWatch métrica da Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html) para criar uma métrica composta (`CPU User + CPU System`) e definir um alarme para 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](https://docs.aws.amazon.com//msk/latest/developerguide/msk-update-broker-type.html) para o tamanho maior seguinte. Por exemplo, se o tamanho atual for `kafka.m5.large`, atualize o cluster para usar `kafka.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](https://docs.aws.amazon.com//msk/latest/developerguide/msk-update-broker-count.html) 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 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.sh` de 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](https://docs.aws.amazon.com//msk/latest/developerguide/cruise-control.html) 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](https://docs.aws.amazon.com/msk/latest/developerguide/open-monitoring.html), recomenda-se usar um intervalo de extração de 60 segundos ou mais (scrape\$1interval: 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](msk-autoexpand.md). Você também pode aumentar manualmente o armazenamento do agente, conforme descrito em [Dimensionamento manual para agentes Standard](manually-expand-storage.md).
+ 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](#bestpractices-retention-period).
+ Exclua tópicos não utilizados.
Para obter informações sobre como configurar e usar alarmes, consulte [Usando alarmes da Amazon CloudWatch ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html). Para obter uma lista completa das métricas do Amazon MSK, consulte [Monitorar um cluster do Amazon MSK Provisioned](monitoring.md).
### 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](msk-configuration-properties.md).
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 [https://docs.aws.amazon.com/msk/latest/developerguide/msk-configuration-properties.html](https://docs.aws.amazon.com/msk/latest/developerguide/msk-configuration-properties.html). É 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 acessar as operações compatíveis do cluster do MSK Provisioned, consulte. [Principais recursos e conceitos do Amazon MSK](operations.md)
### 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](msk-encryption.md#msk-encryption-in-transit).
### 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](msk-update-broker-count.md). Para obter informações sobre como remover agentes de um cluster do MSK Provisioned, consulte [Remover um agente de um cluster do Amazon MSK](msk-remove-broker.md). Para obter informações sobre a ferramenta de reatribuição de partições, consulte [Expanding your cluster](https://kafka.apache.org/documentation/#basic_ops_cluster_expansion) na documentação do Apache Kafka.