Olá pessoal, me chamo Ronaldo Lanelas e nessa aula eu vou falar um pouco para vocês aqui sobre como é que a gente faz para configurar um Kafka Broker em produção, que tipo de preocupação a gente precisa ter. Na aula passada eu falei sobre cálculo de TPS, tamanho de disco, memória, CPU, teste de performance, etc. E se tem algumas propriedades que você precisa tomar cuidado quando vai configurar o seu Kafka. Independente se você está rodando bad metal, um sistema de Linux, etc, ou via Kubernetes, etc, você precisa ficar de olho em algumas propriedades que eu coloquei aqui que são muito baseadas na última aula. Então, uma das coisas que, isso é uma opinião pessoal minha, mas você pode optar por escolher ou não, que é não permitir a autocrisão de tópicos. E por que eu não permito a autocrisação de tópicos? Geralmente quando você coloca a propriedade true e entra alguma aplicação nova, automaticamente aquele tópico vai ser criado. Se por exemplo a aplicação colocar o nome do tópico errado, ele vai criar aquele nome do tópico errado. Então o que eu geralmente faço é eu tenho um tipo de governança em cima desses tópicos onde eu faço a criação desse tópico, seja de forma manual ou seja via pipeline etc. E aí eu disponibilizo esse tópico para quem vai utilizar para o produtor e o consumidor então eu não permito que o produtor e o consumidor criem por si só então a gente mantém uma governança em cima do Kafka e mantém as coisas muito mais organizadas etc você não toma susto de abrir o Kafka no outro dia e ver milhares de tópicos que não fazem sentido nenhum e você evita erros também o capa no outro dia e ver milhares de tópicos que não fazem sentido nenhum. E você evita erros também. Então, vai que o produtor está num loop infinito, criando milhares de tópicos e vai, de alguma forma, afetar o seu broker. Então, para todos os efeitos, produção, eu deixo essa propriedade como falsa. Eu falei também na passada sobre compressão. Na aula passada sobre compressão. Existem duas formas de você fazer compressão. Você deixa o produtor escolher como é que vai ser a compressão. E, por experiência, quando você está em uma empresa muito grande, a maioria não sabe que essa propriedade existe, acaba não usando, acaba não comprimindo nada. Então, eu colocando o LZ4, que vem do benchmarks, etc., é uma das melhores compressões que existem, você está forçando que toda a mensagem seja comprimida. Então, independente se o produtor configurou ou não, ela vai obedecer esse padrão LZ4 aqui. Então, é uma propriedade meio que enforcement aqui para você garantir a compressão. Bom, eu falei também na aula passada sobre a parte de retenção, e aqui eu estou jogando a propriedade que eu geralmente uso, que é o Retention Hours, que aqui no padrão é sete dias, mas, de novo, não tem margem, você tem que definir o quanto você precisa reter. Se você... Sete dias é coisa pra caramba, pra ser sincero. Quando você está trabalhando com Kafka pra transmitir eventos de A pra B, geralmente três ou dois dias é mais suficiente, porque se a sua aplicação está parada por 3, 4 dias, então o problema é outro, né? Acho que você precisa trabalhar em monitoria, alertas etc, tá? Mas é uma coisa que não dá para tomar uma decisão cada um, cada caso é um caso. Bom, o tamanho máximo de mensagem, se você olhar, o Kafka tem um padrão mega, que eu pessoalmente acho muito. Se você olhar o mega, o mega é um ebook de, não sei, chutar 50, 70 páginas, é muita coisa. Então, se você tem um payload de um mega, você está fazendo muito dado. tem um payload de 1Mbps que está trafegando muito dado. Eu geralmente coloco 10K o máximo, isso aqui dá 10K aproximadamente, e aí a gente não permite passar desse tamanho máximo. Por que? De novo para pensar naquele cálculo de tamanho de banda e etc. Então se tem alguém com payload maior que 10K, a gente tem que repensar se realmente esse payload faz sentido, se deveria ser trafegado via Kafka, se a gente não deveria trafegar só um ID, depois consultando uma base, em vez de ficar trafegando pelo de completo. Lembrando que eu estou falando aqui caso de alta performance. Se você tem um broker de produção com baixíssimo TPS que não vai usar quase nada de storage, sendo bem sincero, você não precisa se preocupar com isso aqui. Mas se a gente está falando de brokers de alta volumetria que vão precisar de muita performance, cada propriedade dessa aqui é muito importante você dar uma olhada. O Binsync réplica, na aula passada eu falei sobre o Réplica Factor, que aquela mensagem vai ser replicada para vários nós. O Binsync, você diz qual é o mínimo antes de ele retornar para o produtor ok. Então, imagina que o produtor mandou uma mensagem, tem três brokers, lembra que eu falei que a produção padrão é três brokers? Eu mandei essa mensagem, o ACK do produtor é all, então ele vai esperar a réplica. Só que aqui no meu broker, estou dizendo que ele já retorna Se replicar pelo menos para dois Não vai precisar replicar para todo mundo Então isso aqui Ele aumenta a performance Porque o produtor Não precisa esperar replicar para todo mundo Mas também tem que pensar Obviamente que você tem Uma mínima chance de perda de mensagem Caso, por exemplo O broker 1 e 2 caia e o 3 não recebeu a mensagem ainda depois que o produtor já deu o ato. Então, é só tomar cuidado aí. Se for talvez uma mensagem que você de forma alguma pode perder e o Kafka é sua fonte da verdade, tem que repensar e talvez colocar 3 nesse min5 replica. Mas em 90% dos casos, o 2 atende muito bem. Então isso aqui é só para vocês verem que propriedade é muito importante quando você vai configurar o broker de produção. Para ser sincero com vocês, quando você vai configurar o broker de produção, é muito parecido com o que a gente fez aqui nas aulas, usando aquelas variáveis com broker ID, etc, isso não muda mas você tem que ter muito cuidado com essas propriedades a mais aqui também na hora que você vai configurar, tá? E as outras eu já falei na aula passada sobre capacidade de rede etc, tá? Espero que vocês tenham gostado e até a próxima.