O blog da AWS
Como iFood se beneficiou da arquitetura orientada a eventos para modernizar seu middleware financeiro
Figura 1 – Arquitetura monolítica com forte acoplamento
Solução proposta
Para endereçar os problemas acima, o iFood contou com o apoio de um time da AWS chamado Professional Services, que fazendo um trabalho de working backwards pode entender as reais necessidades do time de finanças e direcionar qual deveria ser o caminho a seguir. O working backwards é um método de trabalho AWS, que visa entender as reais necessidades do cliente e desenhar uma solução que atenda especificamente suas necessidades.
Após esse trabalho, iFood e AWS entenderam que para poder endereçar os problemas da plataforma seria necessário uma mudança de paradigma, saindo da arquitetura monolítca para uma arquitetura de microsserviços orientada a eventos, também conhecida como Event Driven Architecture.
A primeira etapa foi a execução de workshops imersivos e Event Stormings, para juntos os times de engenharia e produtos construirem o DDD (Domain Driven Design) da plataforma. O objetivo era alinhar todos os stakeholders garantindo um fluxo de comunicação único través de uma linguagem ubíqua. Mergulhando fundo foi possivel descobrir a essência de cada domínio de negócio e com isso definir precisos Bounded Contexts. Durante esses workshops também foi possível identificar processos de negócios críticos, entidades, agregações e mapear todo fluxo de eventos para melhorar a comunicação e colaboração entre os times.
Com os insights descobertos nas sessões de Event Storm, foi possivel identificar três domínios de negócios principais dentro do monólito existente. Uma vez esses domínios identificados, foi tomada a decisão de decompor o monólito em três microsserviços distintos:
- Gerenciamento de Dados Mestre
- Provisão
- Requisição
Cada serviço com a responsabilidade única sobre seu domínio de negócio, comunicando-se entre si através de uma arquitetura orientada a eventos.
Além dos microsserviços acima, foi levantada a necessidade da criação de uma camada adicional na arquitetura, um BFF (Bakend for Frontend), que ficou responsável por fazer a interface com o mundo legado, agregando dados de multiplos microsserviços para apresentar de forma unificada para os consumidores das APIs, além de transformar as requisições síncronas em assíncronas.
Para hablitar essa nova forma de comunição entre o BFF e os microsserviços adotamos o Amazon EventBridge como barramento de eventos. Com sua simplificidade, escalabilidade, alta disponibilidade e resiliência se tornou a peça principal na estrutura de comunicação. Conectando os microsserviços no EventBridge nós podemos criar uma coreografia entre os microsserviços de forma simples, enviando eventos de um domínio para outro, abstraindo produtores de consumidores e dando autonomia para os domínios.
Para assegurar completa autonomia e escalabilidade para cada microsserviço, também decidiu-se por decompor o banco de dados, dessa forma cada microsserviço terá seu próprio banco de dados. Essa abordagem, além de evitar que ocorram gargalos quando muitos serviços acessam um mesmo banco de dados, também garante com que cada microsserviço possa escalar de forma independente e possa ser gerido e evoluído por um time de forma autônoma.
A transição de uma arquitetura monolítica para uma uma arquitetura de microsserviços orientada a eventos traz inúmeras vantagens, diminuir o acoplamento dinâmico, consequentemente aumentando a resiliência, aumenta de performance com uso de comunicação assíncrona, cada microsserviço pode escalar independentemente de acordo com sua capacidade, em caso de falha os outros serviços não são impactados e também melhora manutenibilidade permitindo que cada microsserviço seja evoluido e implantando de forma independente e mais rápido.
Figura 2 – Nova arquitetura DBY orientada a eventos
Amazon EventBridge como principal barramento de eventos
Vamos separar um momento para explorar os benefícios do Amazon EventBrigde e entender o motivo pelo qual foi escolhido para ser o principal barramento de eventos do DBY.
Primeiro e principal ponto, precisávamos de um barramento de eventos que fosse capaz de filtrar e rotear eventos de forma performática, além disso, o EventBridge é um serviço serverless regionalizado com alta disponibilidade nativa, escalável e que consegue atender a alto número de requisições por segundo à uma latência muito baixa.
Segundo, seu modelo de cobrança é pay-as-you-go, ou seja, você paga apenas pelos eventos enviados, o que permite optmizar os custos uma vez que não é necessário pagar por recursos inativos
O EventBridge possui as features abaixo que agregam ainda mais valor:
Rules and Targets: EventBridge permite que você defina regras baseados em padrões, essas regras podem ser aplicadas a qualquer campo do evento de forma que cada evento é filtrado e direcionado para diferentes destinos de forma individual, desacoplando os produtores dos consumidores.
CloudWatch Integration: Possibilita que todos os eventos sejam logados de forma integral, hablitando monitoramento ativo e um throubleshooting eficiente.
EventBridge Pipes: Com Pipes você pode consumir eventos diretamente de serviços como SQS, DynamoDB, Kinesis e Kafka, de forma No-Code. Também permite que você filtre e transforme os eventos antes de entrega-los ao destino.
Archive e Replay: Com Archive você pode transformar o EventBridge em um Event Store, armazenando todos os eventos que passarem pelo barramento, ou criando filtros para armazenar um determinado padrão de evento. Com o replay, você consegue reprocessar todos os eventos que foram armazenados, com regras específicas de replay, permitindo com que você possa reprocessar eventos em casos de falhas, incidentes ou até mesmo uma necessidade pontual de negócio.
Um exemplo de uso do EventBridge na nova plataforma do DBY é o caso de uso onde o frontend faz uma consulta de uma lista de materiais para o microsserviço de provisões. Veja a sequência de execução transformando uma requisição síncrona em assíncrona e depois retornando a requisição inicial de forma síncrona:
- O frontend faz faz um resquest síncrono para o BFF
- O BFF envia um evento assíncrono para o EventBridge:
{"eventType": "MaterialListRequested","companyCode": "12","functionalArea": "34} - O EventBridge roteia o evento para o backend responsável de acordo com o campo eventType
- O bakcend processa a requisição de forma assíncrona
- O BFF faz polling no backend para obter a resposta atualizada
- O BFF retorna a requisicao síncrona inicial para o frontend
Importante relembrar que a nova plataforma do DBY precisava manter a compatibilidade com outros sistemas legados, por isso foi feita a inclusão da camada de BFF para fazer a troca de requisições síncronas para assíncronas e vice versa.
Figura 3 – Digrama de sequência do fluxo de requisião para o microsserviço de provisão
Estratégia de migração e implantação
Para se evitar downtime e perda de integridade nos dados, optou-se por fazer uma migração de dados do monólito para a nova plataforma do DBY de uma vez só durante uma janela de migração onde a plataforma não está em uso. Para se decidir sobre a forma de migração foram considerados fatores como horários de utilizaçao da plataforma, quantidade de dados a serem migrados e tecnologia do banco de dados antes e depois da migração.
No caso da plataforma DBY, existia uma janela de manutenção onde a plataforma não era acessada e a quantidade de dados a ser migrada caberia dentro dessa janela. Outro fator importante é que a tecnologia de banco de dados utilizada pelo monólito e pela nova plataforma era a mesma, em ambas estava sendo utlizado Postgres, sendo assim não foi necessário fazer uma conversão de esquemas, apenas a divisão dos dados de um único banco de dados, em alguns bancos de dados separados por microsserviço.
Para estratégia de implantação foi escolhia a Canary. Essa estratégia permite que seja liberada a nova versão da plataforma para uma pequena porcentagem de usuários, de forma que podemos acompanhar e identificar rapaidamente caso algum problema ocorra, possibilitando também uma rápida ação de rollback. Após um determinado periodo de tempo não havendo qualquer incidente, completamos a implantação levando 100% da nova versão para o ambiente produtivo. Importante frisar que para se ter uma estratégia de implantação Canary, é necessário haver um processo de CI/CD bem estruturado e automatizado, onde se estabeleça métricas para medir o sucesso da implantação bem como, ações automatizadas para conclusão ou rollback.
Com as estratégias de migração de dados e de implantação com Canary, pudemos garantir uma segura troca de versão da plataforma, saindo do monólito para a arquitetura em microsserviços orientada a eventos.
Benefícios obtidos pelo iFood
A modernização da plataforma decompondo o monólito em microsserviços usando uma arquitetura orientada a eventos entregrou benefícios significativos ao time da finanças do iFood. Anteriormente eles possuiam dificuldades para disponibilizar novas funcionalidades rapidamente, prejudicando o time-to-market. Após a migração, o tempo de desenvolvimento de novas funcionalidades caiu de 1 mês para 1 semana. Com a distribuição dos microsserviços por domínios, os times tiveram mais autonomia e velocidade, podendo desenvolver seu microsserviço sem ter a preocupação com outras partes da plataforma.
A transição para requisições assíncronas permitiu aos times melhorar a experiencia do usuario final. Com a eliminação de muitas chamadas síncronas que aumentavam o acoplamento dinâmico entre os componentes, precebeu-se uma melhora significativa na performance e na resiliência. Falhas em um determinado serviços não impactam mais os outros serviços, permitindo uma experiencia inenterrupta para o cliente final. Adicionalmente, a adoção do EventBridge permitiu a inclusão de novas capacidades facilmente, como uso de DLQs (Dead Letter Queue) e políticas de retentativa garantindo que nenhum evento seja perdido caso algum microsserviço esteja inoperante.
Importante lembrar que o uso do domain driven design teve grande contribuição para se identificar de forma eficiente quais são os domínios de negócio, dando a eles autonomia. Com limites entre domínios bem definidos os times podem agora trabalhar de forma independente, focando nas suas áreas de conhecimento específicas.
Baseado em dados obtidos após a implementação da nova arquitetura, percebeu-se um aumento na disponibilidade da paltaforma em 30%, redução no MTTR (mean time to recover) de 90% e diminuição no tempo de entrega de novas funcionalidades de 50%.
Conclusão
A jornada de modernização é uma jornada contínua e os times do iFood contam com o poder dos serviços da AWS, bem como uso de boas práticas para continuar a otimizar duas aplicações. Abraçando a inovação e adotando modernas abordagens de arquitetura estarão bem equipados para atender a crescente demanda e se adaptarem às futuras necessidades de negócio. A modernização da plataforma DBY é um exemplo da importancia de se abrir a mudanças se beneficiando de serviços que facilitam e aceleram a implementação de soluções modernas e robustas.
Sobre os autores
Ricardo Marques é Senior Solutions Architect na AWS, com mais de 15 anos de experiência em desenvolvimento de software, arquiteturas de soluções escaláveis, cloud native, orientação a eventos e. Ele trabalha apoiando clientes nativos digitais, ajudando-os em sua jornada para a nuvem. Também é professor em MBA de arquiteturas cloud.
https://www.linkedin.com/in/ricardo-marques-45846425
Abbas Zahid é um arquiteto sênior de aplicações na AWS, com mais de 11 anos de experiência na indústria de cloud. Ao longo de sua carreira, ele se concentrou no desenvolvimento e na arquitetura de aplicações nativas da cloud em diferentes plataformas de cloud, entregando produtos seguros, escaláveis e resilientes. Atualmente ajuda clientes a modernizar suas aplicações usando vários estilos arquitetônicos e aproveitando os benefícios de cloud disponíveis na AWS.