Criando uma camada RESTFul para integração entre microserviços com Apache Kafka

O Apache Kafka é uma das principais opções atualmente no mercado quando há a necessidade de trafegar dados (informações) na forma de eventos entre sistemas com escalabilidade e organização. A Via Varejo, um dos maiores Varejistas do Brasil, com mais de 1000 lojas físicas e o segundo maior em vendas de comércio eletrônico, com as bandeiras Ponto Frio, Extra e Casas Bahia, na última Black Friday (2018) trafegou mais de 50 milhões de mensagens pelo Apache Kafka em apenas 2 dias com uma média de 25 mil mensagens por segundo. O ecossistema é formado por centenas de sistemas com milhares de sub sistemas, que trafegam dados e informações por toda a cadeia de atendimento.

Este artigo, detalha alguns aspectos de nossa experiência adquirida na criação de uma camada de abstração similar ao REST Proxy da Confluent utilizando a versão Open Source do Apache Kafka onde tínhamos as seguintes motivações:

• Criar um serviço totalmente gerenciável no ambiente on-premise;
• Ser um facilitador de integração - como a maioria dos desenvolvedores sabe trabalhar com o padrão HTTP, o mensageria torna-se um acelerador, já que os desenvolvedores não precisam de conhecimento prévio com o Apache Kafka para começar a trabalhar;
• Gerenciar as falhas, fazendo o reenvio de mensagens, além do histórico, que retemos por 7 dias, tendo uma visão de como todos os eventos estão sendo processados, com sucesso ou falhas, ou seja, ter uma rastreabilidade mais apurada;
• Como temos times multidisciplinares, os conectores(drivers) de diferentes linguagens nem sempre suportam a mesma versão do Apache Kafka, tornando mais difícil a evolução dos nossos clusters de Kafka, com a nossa abstração, esse processo se torna transparente para os desenvolvedores e facilita a vida do time de operações na manutenção do cluster da ferramenta;
• Redução do tempo necessário para que desenvolvedores, em um universo de alta rotatividade e de pouco conhecimento técnico com relação ou uso do Apache Kafka, estejam engajados e produzindo em pouco tempo.

Motivação

Nossa estratégia foi a criação de uma camada de abstração que utiliza RESTful como padrão de comunicação e que é de maior conhecimento para desenvolvedores com pouca ou nenhuma experiência com o uso do Apache Kafka deixando a gestão e configuração da estrutura robusta do Apache Kafka por conta de nossos SMEs(Subject Matter Experts). Com esta estratégia, a utilização do Apache Kafka pela empresa foi absorvida de forma transparente e assim conseguimos escalar o crescimento de nossos clusters a medida que realmente necessitamos escalar. Centralizamos o uso da solução corporativa para nossos especialistas e conseguimos abstrair de forma convencional o uso da solução.

O mensageria é um serviço totalmente gerenciável que abstrai o Apache Kafka como um mecanismo de mensagens distribuídas, escalável e de alta vazão, permitindo que microsserviços sejam conectados entre si e com sistemas externos.

Problemas comuns enfrentados

• Distribuir eventos de forma simples e ágil;
• Integrações sem um gerenciador de mensagens possuem muitos problemas, muitas vezes param de funcionar sem fornecer informações suficientes para o diagnóstico do problema;
• Com o mensageria temos uma visibilidade desde o momento que o sistema produtor gera a mensagem, até o momento que o sistema consumidor a consome, dependendo menos de implementações de desenvolvedores para gerar diagnóstico adequado, evitamos também o problema do jogo da batata quente, onde um time ficava jogando a batata do problema da integração para o outro;
• Redução dos problemas de integrações pois criamos um trace das integrações por meio de Correlation IDs, com serviços de retentativas e gestão de retentativas através das APIs do mensageria, reenvio por consumidor, data de início e fim para o reenvio;
• Grande número de desenvolvedores e empresas terceiras prestando serviços, mais de 400 desenvolvedores atuantes. Falta de conhecimento no uso eficiente do Apache Kafka por parte da grande maioria dos desenvolvedores terceiros;
• Dificuldade com a gestão dos conectores utilizados pelos times de desenvolvimento multidisciplinares:

• A versões dos drivers disponíveis nas mais diversas linguagens podem divergir de acordo com a versão do Apache Kafka que será utilizado, dificultando assim a implementação igualitária em sistemas com linguagens distintas
• Como começamos com o Apache Kafka v0.8 não havia mecanismos de segurança. Os mesmos foram adicionados somente a partir da v0.9

• Alto índice de acionamento dos SMEs da Via Varejo o que acarretava inferência de profissionais altamente qualificados apenas para ajustar o código desenvolvido. Redução de configuração e manutenção do cluster Kafka.;
• Direcionamento do foco no desenvolvimento das aplicações somente e consequente redução do tempo para entrega das soluções;
• Paralelismo. Alto número de microsserviços interessados em um mesmo tópico;

Por que não utilizar o REST proxy e o Schema Registry da Confluent

Há três anos atrás, quando iniciamos o desenvolvimento do mensageria, fazíamos uso do Apache Kafka versão 0.8, que não possuia muitas funcionalidades além do envio eficiênte de eventos entre sistemas. No mensageria temos um payload dividido em "header" e "body". O header concentra uma série de informações de controle, como timestamp, o correlation id entre outros. Não temos o problema de controlar o versionamento de eventos/mensagens porque o "body" é dinâmico. Em nossa arquitetura, o mensageria é "schemaless", ou seja, o tratamento do schema fica a cargo do destinatário que recebe a mensagem.

Além disso, devido ao uso da versão open source, também não fazemos o uso do Schema Registry da Confluent pois entendemos que o Schema Registry viola, em partes, a nossa filosofia de smart endpoints e dumb pipes, para não gerar lock-in com vendors.

Webhook vs Stream

Nosso cenário requer um índice elevado de alta disponibilidade e grande vazão na comunicação entre os sistemas. Partindo dessas premissas, tratar a comunicação utilizando o Apache Kafka em conjunto com técnicas de processamento de stream seria a solução mais natural. Contudo, devido a diversidade de background dos desenvolvedores contratados, detectamos que essa não seria a solução ideal, por conta do overhead de acionamentos gerados ao time de sustentação e aos SMEs devido à falta de conhecimento em técnicas de processamento de stream.

Nesse cenário a utilização de webhooks se mostrou uma alternativa atraente e que gera possibilidade de entrega de mensagens sem mudança de mindset por parte, por exemplo, das equipes de sistemas legados.

A opção pelo conceito de webhook traz vantagens com relação à menor modificação em sistemas legados e facilidade de criação de novas integrações, porém traz junto algumas desvantagens com relação a vazão de dados e introdução de novos pontos de falha na comunicação.

A tomada de decisão não levou em consideração apenas aspectos técnicos mas também considerou aspectos organizacionais como capacidade técnica dos times e diversidade de tecnologias - muitos drivers com versionamento diferente com a necessidade de se conectar ao cluster Kafka.

InfluxDB

O InfluxDB é um banco de dados orientado a série temporal, ele é utilizado no Mensageria para armazenar todo e qualquer evento de métricas dos producers, agents e os consumers a fim de subsidiar dados para análises.

MongoDB

O MongoDB na estrutura do Mensageria é responsável por armazenar dados com relação a configurações como por exemplo origem e destino, regras de segurança, sistemas cadastrados como producers e sistemas cadastrados como consumers.

ZooKepper

O ZooKepper atua nas informações sensíveis de configuração dos agents e do próprio Kafka, que são efêmeros e com isso garante a distribuição correta das mensagens entre origem e destino, ele é um dos principais componentes do mensageria pois armazena dados sensíveis para o funcionamento da estrutura. A única chave de configuração efêmera é a que contém o id da sessão para identificar se um determinado agente está ou não ativo. As demais configurações são persistentes.

Message Dispatcher

Os consumers foram construídos sobre o padrão Message Dispatcher com o objetivo de garantir a correta escalabilidade de uso do mensageria. É importante destacar que antes desta implementação não possuíamos nenhuma estrutura capaz de suportar a demanda de requisições que enfrentávamos na companhia e que integrar diretamente com o Apache Kafka para alguns desenvolvedores não era uma tarefa fácil e trivial.

Principais ganhos alcançados

• Criação de uma camada de abstração baseada em RESTful. Mais comum ao mercado, trazendo maior produtividade e menor chance de falhas;
• Visibilidade quase em tempo real dos status das integrações. (Near real time);
• Integrações gerenciáveis - com a possibilidade de recebimento das mensagens fazendo a retenção das mesmas no Apache Kafka. Com o mensageria conseguimos parar o serviço de webhooks se necessário, fazendo que os dados sejam retidos e posteriormente enviados ao ligar novamente o agente de webhooks. Os agentes de webhooks são gerenciáveis por grupo de consumidores;
• Reprocessamento de mensagens por período;
• TRACE das integrações (Log com Correlation ID);
• Simples de usar, pois os desenvolvedores conhecem o protocolo HTTP, compatível com qualquer linguagem, sem haver necessidade de conhecimento do Apache Kafka;
• Taxa de engajamento reduzida para novos desenvolvedores, principalmente juniores e plenos;
• Alta escalabilidade da mensageria gerenciada em um único ponto;
• Monitoramento centralizado dos clusters;
• Qualquer tecnologia que suporte o protocolo HTTP pode utilizar o mensageria;
• Log eficiente pois é possível identificar o tempo de envio/entrega e o status da mensagem através de mecanismos Correlation ID. O Correlation ID possibilita o rastreio de todas as mensagens trafegadas no mensageria.

Volumetria de mensagens durante a Black Friday 2018

Conclusão

Nós começamos a construir este gerenciador de mensagens há 3 anos, quando ainda não havia uma solução no mercado, ou da Confluent, que pudesse atender às nossas necessidades. Em um comparativo entre a solução arquitetural desenvolvida e a existente comercialmente, identificamos os seguintes pontos:

Devido à complexidade envolvida somado a alta quantidade de sistemas que atualmente fazem uso do mensageria, outras funcionalidades estão em nosso roadmap para desenvolvimento no decorrer de 2019. Temos planos para implementação de escalonamento horizontal por meio de containers deixando a estrutura mais flexível à medida que mais recursos (hardware principalmente) são necessários para garantir a escalabilidade e assim reduzindo ainda mais as intervenções dos times de suporte e sustentação (plataforma).

Sobre os autores