Bom pessoal, boa noite. Eu me chamo Ronaldo Lanheiras e nessa aula eu vou falar um pouco para vocês sobre quais são as melhores práticas para calcular o tamanho ideal do cluster em produção. É difícil dar uma receita de bolo e dizer exatamente o tamanho que você tem que ter, quantos nós e espaço em disco, CPU e memória tá? isso é um cálculo que se alguém falar pra você é um número exato com certeza não é verdade porque não existe esse número exato cada caso é um caso o que eu posso dar pra vocês aqui são algumas informações pra que vocês consigam calcular por si só esse valor e também baseado em algumas experiências que eu tive, quais valores eu já usei. Então eu vou primeiro passar nesses pontos aqui e aí eu preciso abrir a calculadora só para gente fazer alguns cálculos aqui. Mais alguns pontos importantes é sempre use Linux. Produção é Linux. Não tem discussão. Por conta de algumas técnicas. Que o Kafka usa. Que ele precisa de Linux. Para performance etc. Por exemplo. Ele usa. PageCast do sistema operacional. Então o Linux vai ajudar nisso. Para aumentar a performance. Porque ele faz. P paginação do disco, desculpa, ele faz cache do disco, usando o mecanismo de page cache, e aí não precisa ficar indo no disco toda hora para ler informação. Então o Linux vai ajudar muito nisso, não só nisso, isso é só um exemplo. O número de nós, geralmente a gente recomenda 3. O mínimo é 3. Você não vai errar a produção com 2 ou 1 nó. Mas aí você, dependendo do seu caso, pode ter 5 ou 7 ou etc. Mas aqui o número recomendado para você começar são 3 nós. Como o Kafka usa um algoritmo de consenso, etc. O ideal é que você tenha um número ímpar Para que você não tenha nenhum problema De consenso na hora de eleger um guia Para o seu cluster Então o 3NOS funciona Na grande maioria dos casos Em 90% dos casos vai atender muito bem Tempo de retenção O que é o tempo de retenção? O tempo de retenção, se vocês voltarem lá no início das primeiras aulas, é o tempo que a mensagem vai ficar gravada no Kafka, que é retention.ms, que por padrão são sete dias e você pode mudar esse tempo. Isso é muito importante porque isso vai dizer pra você qual é o tamanho do disco que você precisa. E aí o cálculo é muito simples. Vou abrir a calculadora aqui. O cálculo é tão simples quanto. Então vamos imaginar que você por dia tem 1024 MB de dados, que vai dar 1 GB de informação. E aí, por dia, se eu multiplicar por 7, eu vou ter aqui aproximadamente 7 GB em 7 dias. Se você reter o dado por um dia, você só precisa de 1,5 GB para storage. Se você vai reter por 7 dias, você vai ter que ter 7,5 GB. Claro, você não vai botar exatamente 7 GB, você vai ter uma gordura aí para configurações etc, mas eu quero dizer que o tempo de retenção é muito importante para saber qual que é o máximo que você pode reter, e não só o tempo de retenção, o tamanho da mensagem, o máximo. Então vamos fazer um cálculo aqui. Vamos imaginar, e aqui sempre você vai pelo pior caso, vamos imaginar que a gente tem um produtor que ele produz a 50 TPS, então são 50 mensagens por segundo. E esse produtor, são 50 mensagens por segundo multiplicado por, vamos dizer que são 1K, então é 1024 bytes. Vamos colocar 1 só para... vamos pensar em KB tá? Então a gente tem 50 KB por segundo deixa eu abrir o Notepad, Notep mensagem, então eu tenho 50k por segundo. Então a cada segundo eu estou trafegando 50kbyte de mensagem. Cálculo bem simples. Quanto eu estou trafegando aqui por minuto. Vou multiplicar aqui por 60. Então 300 Kb por minuto. KB por hora, certo? E por dia. Por dia. E aí vamos fazer uma conversão, tá? Isso aqui é em KB, né? Então eu vou pegar isso aqui e dividir por 1024. Que vai me dar isso aqui em Mega certo? Vamos converter para Giga, 1024, vamos colocar 4 gigas, tá? 4 gigas por giga. Então vou repassar aqui, tá? Eu peguei 50 kbytes Beleza Comecei lá nos 50TPS 50TPS eu multipliquei por 1k Porque cada mensagem tem 1k Aqui no meu exemplo E aí então eu sei que eu tenho 50k por segundo Aí eu multipliquei por 60 Para Converter de segundo para minuto Porque o minuto tem 60 segundos. E aí depois eu multipliquei por mais 60 para converter de minuto para hora. E aí depois eu multipliquei por 24, porque o dia tem 24 horas, para converter de hora para dia. E aí eu sei que no dia eu tenho aproximadamente, eu vou até arredondar para cima aqui, aproximadamente 5 gigas de dado por dia se eu manter aí vamos supor que o meu TTL que é a minha retenção é 7 dias o que isso vai me dar? vai dar 5 vezes 7, 35 gigas 35 gigas então essa é a minha retenção 35 gigas então essa é a minha retenção pensando em um produtor estou falando de um produtor durante 7 dias 35 gigas e aí você tem que fazer o cálculo do seguinte quantos produtores desse eu vou ter, quantos tópicos desse eu vou ter ah, putz, eu vou ter 100 desse cara aqui então multiplica por 100 que vai me dar esse valor aqui que dá 3 teras, né se dividir por 24 3.5 teras vou colocar aqui 4 teras, né vamos arredondar 4 terabytes em 7 dias se eu multiplicar por 100 produtores nessa velocidade aqui, produtores de 50 TPS então esse é um cálculo que você tem que fazer para poder entender quanto de storage você precisa mas storage é um ponto muito importante obviamente, para você saber quanto você precisa e falando em experiências minhas aqui, eu já trabalhei com histórias de 10 teras, 20 teras, etc. Não é uma coisa tão absurda você ter histórias de 1 tera no Kafka, porque você vai ter muito dado trafegando, dependendo do seu caso. Mas quando você está falando de muita informação, é legal você fazer esse cálculo para você não colocar um tera quando você precisa só de 5 gigas de data. Principalmente se a sua retenção for muito baixa. A gente está falando de um dia de retenção aqui. Cara, eu diminui de 35 gigas aqui para 5 por dia. E aqui vai diminuir de 4 tera para 500 gigas aqui para 5 por dia. E aqui vai diminuir de 4 tera para 500 gigas. Então é uma diferença gigante quando você fala de retenção. E essa retenção é legal falar que assim, você consegue configurar no Kafka a retenção de todos os tópicos. Então quando o tópico é criado ele já vem com aquela retenção padrão. Beleza. Só que esse cálculo me ajuda em um outro ponto também. A definir a capacidade da rede. O que é a capacidade da rede? Quando você fala de cloud, ou mesmo rede on-premises, você tem um limite da sua rede que pode ser, por exemplo, 10 gigabits. 10 gigabits, alguma coisa assim. Dada essa capacidade você sabe quanto você consegue trafegar por segundo. E você tem que olhar para sua capacidade de rede, por exemplo, se você está em uma rede de 100 megabits e baseado nisso você pode olhar para quanto você vai trafegar por segundo. Nesse caso aqui é pouco, só 50k por segundo. Todas as redes que eu conheço vão suportar super bem, mas quando a gente começa a falar de 1000 TPS, cada mensagem tendo 10k, você começa a mudar o assunto. mensagem tendo 10k você começa a mudar o assunto né e começa a falar de 1 gigabit 2 gigabit etc então você tem que ver se o local que você está colocando aquele cluster vai suportar todo aquele tráfego tá então assim essa capacidade que é da rede, você tem que calcular também baseada no seu TPS e no tamanho da sua mensagem. Então, TPS e tamanho de mensagem. Aí, vamos lembrar de uma configuração que eu falei nas aulas iniciais, que é o tamanho máximo da mensagem. Por padrão, o Kafka tem um padrão de tamanho de mensagem. Por padrão, o Kafka tem um padrão de tamanho de mensagem. E aí, imagina que chega alguém e fala para você, putz, eu tenho uma mensagem aqui que é 10 megas. Você tem que pensar muito bem se você vai aceitar aquele tamanho de mensagem ou não, porque isso vai afetar principalmente na sua capacidade de rede. É até por isso que o Kafka tem um padrão de tamanho máximo de mensagem. E aí o que a gente faz? Lá no server properties do Kafka a gente define, cara, meu tamanho máximo é 10K. E não interessa o que aconteça se você mandar 11K, vai ser rejeitado. Porque eu já faço esse cálculo aqui baseado no meu pior caso. Então, por exemplo, vamos supor que esse meu pior caso aqui é 1k. Eu defino no meu server.property esse 1k byte e eu sei que o meu pior caso vai me dar 50k por segundo de uso de rede. Eu não vou ter mais do que isso, porque eu estou definindo o tamanho máximo de mensagem. Se eu não sei esse tamanho, eu posso ter um gargalo na minha rede, pacotes sendo dropados, entrar em hold, etc. Então esse cálculo de tamanho máximo da mensagem é muito importante para você conseguir definir a sua capacidade de rede e sua retenção também. Obviamente, se você sabe o tamanho máximo, você sabe quanto você vai precisar de disco para gravar. Bom, muita informação, mas realmente para você colocar um cluster no tamanho ideal, você tem que fazer todos esses cálculos. Outro ponto é o replica factor. O replica factor que é aquela configuração que diz para quantos blocos você vai replicar sua mensagem. E aí se você tem 3 blocos, você vai replicar sua mensagem. E aí se você tem três blocos, você vai replicar para três. Obviamente que esse cálculo aqui de 5 gigas está aplicado para um nó só. Você vai ter que pensar também que se você replicar para todo mundo, esse disco tem que ser igual em todos os nós, obviamente, etc. Então, só pensa que também a banda, a capacidade de rede é afetada, porque aquele dado vai ser replicado do broker A para o B para o C e assim por diante. Você vai ter a mesma taxa de transferência e etc. Uma coisa que eu sempre recomendo muito, a técnica de compressão. Você até pode dar uma pesquisada depois na internet, em alguns benchmarks, mas você vai ver reduções drásticas de uso de rede quando você usa compressão. O que é compressão? Quando você está produzindo uma mensagem, e aí eu vou voltar aqui, essa mensagem tem um K. Sem compressão. Quando você aplica uma técnica de compressão, isso aqui pode cair 40%, 30%, 50%. E isso significa automaticamente uma redução do seu uso de rede. Praticamente. Então, você continua calculando pelo pior caso, sem compressão, etc. Mas no final das contas, se os seus produtores estão usando compressão, você não vai usar 50K, você vai usar 10, 15K. Então você vai ter uma folga para a sua rede se você usar a técnica de compressão. Super recomendo, use sempre. E para fechar, eu não falei de memória e CPU porque são coisas muito subjetivas. Eu posso falar alguns números para vocês aqui, por exemplo. Tem empresas que já trabalhei, já vi funcionando, mais de 300 mil TPS, com 3 brokers, cada broker com 32 GB de RAM e com 8 vCPU. cada broker com 32 GB de RAM e com 8V CPU, funcionando tranquilamente, sem problema, sem pressão em memória, sem memory pressure, sem CPU pressure, então, de novo, 3 brokers, 32 GB de RAM cada um, com 8V CPU. Talvez se você está vendo esse vídeo e, cara, você tem 5 TPS, você vai perceber que é muita coisa 32 GB de RAM e realmente é, eu estou falando de um caso de 300 mil TPS, coisa pra caramba então tenta pensar direitinho, eu estou dando um exemplo e de novo não tem receita de boa se realmente 32 GB de RAM 8GB CPU é muito ou pouco para você. Mas o que eu faria antes de só subir uma máquina com 32GB de RAM é usar uma ferramenta de performance. O Kafka, quando você baixa ele, dentro do diretório de BIM, etc., ele tem dois SH que fazem esse teste para você, que é o producer path e o consumer path. Ele roda o teste de performance e você consegue avaliar quanto de memória o CPU está utilizando. Existem outras ferramentas que fazem isso, como KC, Jbit, etc. Mas o recado que eu quero deixar aqui é que vocês precisam primeiro fazer o cálculo que eu quero deixar aqui que vocês precisam primeiro fazer o cálculo que eu acabei de falar de tamanho máximo de mensagem TPS e rodar o teste de performance seja com a própria ferramenta do Kafka ou seja com K6 ou com o Gmitter ou qualquer outra ferramenta de teste porque só rodando o teste de performance vocês vão saber exatamente quanto de CPU vai usar, quanto de memória, se a máquina vai aguentar, se a rede vai aguentar. E não ficar só na teoria fazendo os cálculos, e sim fazer o cálculo, subir a máquina e rodar o teste real. Beleza pessoal? Espero que vocês tenham gostado e até a próxima.