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.
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.
Tamanho do corretor | Número recomendado de partições (incluindo partições líderes e seguidoras) por agente |
---|---|
kafka.t3.small |
300 |
kafka.m5.large ou kafka.m5.xlarge |
1000 |
kafka.m5.2xlarge |
2000 |
kafka.m5.4xlarge , kafka.m5.8xlarge , kafka.m5.12xlarge , kafka.m5.16xlarge ou kafka.m5.24xlarge |
4000 |
kafka.m7g.large ou kafka.m7g.xlarge |
1000 |
kafka.m7g.2xlarge |
2000 |
kafka.m7g.4xlarge ,kafka.m7g.8xlarge ,kafka.m7g.12xlarge , ou kafka.m7g.16xlarge |
4000 |
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:
-
Atualizar a configuração do cluster
-
Atualize o cluster para um tamanho de agente menor
-
Associe um AWS Secrets Manager segredo a um cluster que tenha SCRAM autenticaçãoSASL/
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 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
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
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.
Importante
Não aumente num.network.threads sem antes aumentar num.io.threads, pois isso pode causar congestionamento relacionado à saturação da fila.
Configurações recomendadas | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
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 --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.
-
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 o mínimo de réplicas sincronizadas (minISR) para no máximo RF - 1. Um mínimo ISR igual à RF pode impedir a produção no cluster durante uma atualização contínua. Um mínimo ISR de 2 permite que tópicos replicados em três vias estejam disponíveis quando uma réplica estiver off-line.
-
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 Obtendo os corretores de bootstrap para um cluster da Amazon MSK.
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:
-
Opção 1 (recomendada): atualize o tamanho do seu corretor para o próximo tamanho maior. Por exemplo, se o tamanho atual for
kafka.m5.large
, atualize o cluster a ser usadokafka.m5.xlarge
. Lembre-se de que, quando você atualiza o tamanho do broker no cluster, a Amazon MSK coloca os corretores off-line de forma contínua e transfere temporariamente a liderança da partição para outros corretores. 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 --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 CPU carga exceder significativamente 60%, pois essa forma de escalonamento normalmente não resulta em aumento de carga nos corretores existentes. -
Opção 3: expanda seu cluster adicionando agentes e, em seguida, reatribua as partições existentes usando a ferramenta de reatribuição de partições chamada
kafka-reassign-partitions.sh
. 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, a Amazon MSK não recomenda usar essa opção quando a CPU utilização está acima de 70%, pois a replicação causa CPU carga e tráfego de rede adicionais. A Amazon MSK só recomenda usar essa opção se as duas opções anteriores não forem viáveis.
Outras recomendações:
-
Monitore CPU a utilização total por corretor como proxy para distribuição de carga. Se os corretores tiverem uma CPU utilização consistentemente desigual, pode ser um sinal de que a carga não está distribuída uniformemente no cluster. MSKA Amazon recomenda 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 de produção e consumo pode aumentar linearmente com CPU a utilização.
-
JMXintervalo de raspagem: se você habilitar o monitoramento aberto com o recurso Prometheus, é recomendável usar um intervalo de raspagem de 60 segundos ou mais (scrape_interval: 60s) para a configuração do host Prometheus (prometheus.yml). Reduzir o intervalo de coleta pode levar a um alto CPU uso do 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:
-
Usar Escalabilidade automática. Você também pode aumentar manualmente o armazenamento do agente, conforme descrito em Escalabilidade manual.
-
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 MSK métricas da Amazon, consulteMonitorando 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 ter mais informações, consulte Configurações personalizadas do 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-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 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 Criptografia 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 Expandindo um MSK cluster da Amazon. 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