Otimização de custos em escala: O impacto da compressão de tópicos Kafka no iFood

No ecossistema de tecnologia do iFood, o processamento de dados em tempo real é o pilar que sustenta desde a localização em tempo real de drivers até a detecção de fraudes em nosso marketplace. Com o crescimento exponencial do volume de dados, a eficiência operacional e a sustentabilidade financeira tornaram-se pilares estratégicos para nossa infraestrutura de streaming.

Recentemente, enfrentamos o desafio de otimizar os custos de Kafka sem comprometer a performance de nossas aplicações. Este artigo detalha como uma bateria de testes em grupos de controle, para falsear uma possibilidade, nos guiou para uma estratégia de compressão que já reduziu em 16% o custo efetivo de network do Kafka, e alcançou ROIs superiores a 11.000% em cenários específicos de produção.

O principal desafio: crescimento de dados vs. sustentabilidade financeira

O custo operacional no Kafka, que é uma plataforma de streaming de eventos distribuída, é diretamente impactado pelo throughput de dados. Sem uma estratégia de compressão otimizada, o aumento no volume de mensagens pressiona muito o custo de transferência de dados, o network, e armazenamento. Nosso objetivo foi encontrar o ponto ótimo entre o uso adicional de CPU, Unidade Central de Processamento (overhead computacional) e a economia gerada pela redução do volume de dados.

Parece óbvio, não é mesmo? Mas a realidade é que essa conclusão demorou para vir. Quando olhamos para um sistema complexo, como o gerenciamento de um Kafka em um ambiente de alto volume, não é trivial isolar variáveis e chegar a essa conclusão. Partimos de uma tentativa de falsear uma hipótese: para nós, a compressão não parecia algo que valesse o investimento de CPU. Ainda bem que estávamos errados, mas dispostos a testar. Para tal, elaboramos uma metodologia exclusiva desenvolvida para a execução do projeto.

Metodologia: A ciência por trás dos testes

Para garantir que nossas decisões fossem baseadas em evidências, estabelecemos uma metodologia rigorosa de testes utilizando grupos de controle. O time de data-store-stream, responsável por todas as plataformas de stream de dados do iFood, se dedicou por mais de 1 semana para chegar nos resultados apresentados tratando-se de um trabalho multidisciplinar com dedicação e alta qualidade técnica.

Detalhes sobre a configuração do ambiente

• Plataforma: Kubernetes (K8s) integrado à Confluent Cloud;
• Ferramentas de carga: Utilizamos o K6 para simular usuários virtuais (VUs) e payloads médios de 2KB;
• Monitoramento: Métricas em tempo real, via Datadog, para coletar dados de CPU, memória e latência.

Testamos as duas bibliotecas mais utilizadas internamente pelas nossas pessoas desenvolvedoras: Sarama, desenvolvida em GO, e o Confluent Kafka Client, desenvolvida em Java/JVM. O foco foi comparar o comportamento dos algoritmos LZ4 (Lempel-Ziv 4) e ZSTD (Zstandard).

Resultados dos grupos de controle: GO vs. Java

A análise inicial nos grupos de controle revelou disparidades interessantes entre as tecnologias. Por exemplo, as aplicações desenvolvidas em GO mostraram um potencial de otimização massivo. O algoritmo ZSTD destacou-se como o mais eficiente:

• Economia mensal: 81,5%;
• ROI: 6.683% ao mês;
• Overhead de CPU: Apenas 7% de aumento, comparado aos 41% do LZ4.

Já no cenário dos testes controlados, as aplicações Java apresentaram uma economia inicial de 7,6%. Embora parecesse modesto perto das aplicações desenvolvidas em GO, a estabilidade e a eficiência da JVM em lidar com a compressão sem grandes alterações no uso de CPU indicaram que o ganho em escala seria significativo.

Do laboratório para a produção: principais resultados obtidos

Costuma ser comum termos grandes diferenças entre um ambiente controlado e produção. Os resultados não apenas confirmaram nossas teses, mas superaram as projeções mais otimistas. Destacamos alguns casos:

Caso 1: Transição LZ4 para ZSTD em Java

Em um serviço de tracing, a troca do algoritmo LZ4 pelo ZSTD resultou em:

• Redução de custo operacional: 27,43%;
• Aumento de CPU: 5%;
• ROI em 12 meses: 742%.

Caso 2: O Poder do ZSTD onde não havia compressão

O resultado mais surpreendente veio de produtores Java que operavam sem compressão. Ao ligarmos o ZSTD, observamos:

• Redução de custo operacional: 74,5%;
• Aumento de CPU: Apenas 3,2%;
• ROI em 12 meses: Um incrível 11.085%.

Caso 3: Eficiência em GO

Em tópicos de busca, a migração para ZSTD confirmou a eficiência observada no laboratório:

• Redução de custo operacional: 67,9%;
• Aumento de CPU: 26,8%;
• ROI em 12 meses: 1.710%.

Aprendizados e recomendações técnicas

A jornada de implementação nos ensinou que a compressão não é uma “bala de prata”, mas uma ferramenta de precisão. Já o Trade-off de CPU compensa. O investimento em alguns cores adicionais no Kubernetes é largamente pago pela economia na Confluent Cloud. Em GO, cada $1 investido em CPU retornou $67,90 em economia.

ZSTD é o vencedor claro. Em quase todos os cenários, o ZSTD ofereceu a melhor taxa de compressão com um overhead de CPU mais eficiente que o LZ4. Atenção aos limites do K8s. Antes de ligar a compressão, certificamos de que os requests e limits de CPU das suas aplicações não estão muito justos. O aumento de processamento é real e o deployment precisa estar pronto para escalar.

Ciência aplicada em produção

A implementação da compressão de tópicos Kafka é uma vitória clara para nossa estratégia de FinOps. Ao reduzirmos em 16% o custo por request de rede, não apenas economizamos recursos, mas criamos uma infraestrutura mais sustentável para o crescimento do iFood.

O sucesso desta iniciativa reforça a importância dos grupos de controle: eles nos deram a confiança necessária para realizar mudanças estruturais em produção com riscos calculados e previsibilidade financeira.