Ao longo dos anos, o McDonald’s passou por uma transformação digital significativa para aprimorar a experiência do cliente, fortalecer sua marca e otimizar suas operações.
No centro dessa transformação está uma infraestrutura tecnológica robusta que unifica processos em diversos canais e pontos de contato em suas operações globais.
A necessidade de um processamento de eventos unificado surgiu do extenso ecossistema digital do McDonald’s, onde os eventos são utilizados em toda a stack tecnológica.
Havia três tipos principais de processamento:
- Operações assíncronas
- Processamento transacional
- Manipulação de dados analíticos
Os eventos foram utilizados em casos como o acompanhamento do progresso de pedidos via aplicativo mobile e o envio de comunicações de marketing (ofertas e promoções) aos clientes.
Dado o alcance global das operações do McDonald’s, o sistema precisava de uma arquitetura capaz de lidar com:
- Requisitos de implantação global
- Processamento de eventos em tempo real
- Integração entre canais
- Processamento de transações em alto volume
Objetivos de Design da Plataforma
A plataforma orientada a eventos do McDonald’s foi construída com princípios fundamentais específicos para dar suporte às suas operações globais e serviços voltados ao cliente.
Cada objetivo de design foi cuidadosamente considerado para garantir a robustez e a eficiência da plataforma.
Vamos detalhar esses objetivos.
Escalabilidade
A plataforma precisava ser capaz de escalar automaticamente para acomodar a demanda. Para isso, ela foi projetada para lidar com volumes crescentes de eventos por meio de fragmentação baseada em domínio em vários clusters MSK. Essa abordagem permite a escalabilidade horizontal e o uso eficiente de recursos à medida que o volume de transações aumenta.
Alta Disponibilidade
A plataforma tinha que ser capaz de resistir a falhas em componentes. A resiliência do sistema é garantida por meio de componentes redundantes e mecanismos de failover. A arquitetura inclui um armazenamento de eventos em espera que mantém a continuidade operacional quando o serviço MSK primário enfrenta problemas.
Desempenho
O objetivo era entregar eventos em tempo real com a capacidade de lidar com cargas de trabalho altamente concorrentes. A entrega em tempo real de eventos é facilitada por caminhos de processamento otimizados e mecanismos de cache. O sistema mantém baixa latência enquanto lida com cenários de alta demanda em diferentes regiões geográficas.
Segurança
Os dados precisavam aderir a diretrizes de segurança de dados. A plataforma implementa medidas abrangentes de segurança, incluindo:
- camadas de autenticação para integrações com parceiros externos;
- gateways de eventos seguros;
- conformidade com protocolos rigorosos de segurança de dados.
Confiabilidade
A plataforma deve ser confiável e ter controles para evitar a perda de eventos. A prevenção de perda de eventos é garantida por meio de:
- gestão de tópicos de mensagens com falhas (dead-letter);
- mecanismos robustos de tratamento de erros;
- garantias de entrega confiáveis;
- procedimentos automáticos de recuperação.
Consistência
A plataforma deve manter consistência em padrões importantes relacionados ao tratamento de erros, resiliência, evolução de esquemas e monitoramento. A padronização é mantida com:
- SDKs personalizados para diferentes linguagens de programação;
- padrões de implementação unificados;
- registro centralizado de esquemas;
- gestão consistente de contratos de eventos.
Simplicidade
A plataforma deve reduzir a complexidade operacional para que as equipes possam construir sobre ela com facilidade. A complexidade operacional é minimizada com:
- gerenciamento automatizado de clusters;
- ferramentas de desenvolvedor simplificadas;
- interfaces administrativas simplificadas;
- padrões de implementação claros.
Componentes Principais da Arquitetura
O diagrama abaixo mostra a arquitetura de alto nível orientada a eventos do McDonald’s.
Os principais componentes da arquitetura são os seguintes:
Broker de Eventos
O componente central da plataforma é o AWS Managed Streaming for Kafka (MSK), que gerencia:
- A comunicação entre produtores e consumidores;
- A organização e gestão dos tópicos;
- A distribuição de eventos em toda a plataforma.
Registro de Esquemas
O registro de esquemas é um componente crítico que mantém a qualidade dos dados ao armazenar todos os esquemas de eventos.
Isso permite a validação de esquemas tanto para os produtores quanto para os consumidores. Também possibilita que os consumidores determinem qual esquema seguir para o processamento das mensagens.
Armazenamento de Eventos em Espera
Este componente ajuda a evitar a perda de mensagens caso o MSK fique indisponível.
Ele realiza as seguintes funções:
- Atua como um mecanismo de fallback quando o Kafka está indisponível.
- Armazena temporariamente eventos que não puderam ser publicados no Kafka.
- Trabalha com a função AWS Lambda para tentar republicar eventos no Kafka assim que ele estiver disponível.
SDKs Personalizados
A equipe de engenharia do McDonald’s desenvolveu bibliotecas específicas para cada linguagem, voltadas para produtores e consumidores.
Aqui estão os recursos suportados por esses SDKs:
- Interfaces padronizadas para produtores e consumidores;
- Capacidades integradas de validação de esquemas;
- Mecanismos automatizados de tratamento de erros e tentativas de reenvio;
- Abstração de operações complexas da plataforma.
Gateway de Eventos
A arquitetura baseada em eventos do McDonald’s precisa dar suporte a eventos gerados internamente e a eventos produzidos por aplicações de parceiros externos.
O gateway de eventos atua como uma interface para integrações externas ao:
- Fornecer endpoints HTTP para parceiros externos;
- Converter solicitações HTTP em eventos Kafka;
- Implementar camadas de autenticação e autorização.
Utilitários de Suporte
São ferramentas administrativas que oferecem funcionalidades como:
- Gerenciamento de tópicos de mensagens com falhas (dead-letter);
- Tratamento de erros para eventos com falhas;
- Interfaces administrativas para monitoramento de eventos;
- Capacidades de gerenciamento de clusters.
Fluxo de Processamento de Eventos
O sistema de processamento de eventos do McDonald’s segue um fluxo sofisticado que garante a integridade dos dados e o processamento eficiente.
O diagrama abaixo mostra o fluxo geral de processamento.
Vamos analisar em mais detalhes, dividindo o fluxo em dois temas principais: criação e recepção de eventos.
Criação e Compartilhamento de Eventos
- O primeiro passo é criar um modelo (esquema) para cada tipo de evento e armazená-lo em uma biblioteca central, conhecida como registro de esquemas;
- Os aplicativos que desejam criar eventos usam uma ferramenta especial (SDK de produtor) para isso;
- Quando um aplicativo é iniciado, ele salva uma cópia do modelo de evento para acesso rápido;
- A ferramenta verifica se o evento corresponde ao modelo antes de enviá-lo;
- Se tudo estiver correto, o evento é enviado para o quadro de mensagens principal, que é o tópico primário;
- Se houver um problema com o evento ou um erro corrigível, ele é enviado para uma área separada (tópico de mensagens com falhas) para aquele aplicativo;
- Se o sistema de mensagens (MSK) estiver fora do ar, o evento é salvo em um banco de dados de backup (DynamoDB).
Recepção de Eventos
- Os aplicativos que desejam receber eventos usam o SDK de consumidor. Este SDK também verifica se os eventos recebidos correspondem aos seus modelos;
- Quando um evento é recebido com sucesso, o aplicativo o marca como “lido” e passa para o próximo.
- Os eventos na área de problema (tópico de mensagens com falhas) podem ser corrigidos posteriormente e enviados de volta ao quadro de mensagens principal.
- Eventos de empresas parceiras (“Eventos Externos”) entram pelo gateway de eventos, conforme mencionado anteriormente.
Técnicas para Desafios Importantes
A equipe de engenharia do McDonald’s também utilizou algumas técnicas interessantes para resolver desafios comuns associados à configuração. Vamos analisar algumas importantes:
Governança de Dados
Garantir a precisão dos dados é crucial quando diferentes sistemas compartilham informações. Se os dados forem confiáveis, o design e a construção desses sistemas se tornam muito mais simples.
O MSK e o Registro de Esquemas ajudam a manter a integridade dos dados ao impor “contratos de dados” entre os sistemas.
Um esquema funciona como um modelo que define quais informações devem estar presentes em cada mensagem e em que formato. Ele especifica os campos de dados obrigatórios e opcionais e seus tipos (por exemplo, texto, número, data). Cada mensagem é verificada em tempo real com base nesse modelo. Se uma mensagem não corresponder ao esquema, ela é enviada para uma área separada para ser corrigida.
Veja como os esquemas funcionam:
- Quando um sistema é iniciado, ele salva uma lista de esquemas conhecidos para referência rápida;
- Os esquemas podem ser atualizados para incluir mais campos ou alterar tipos de dados;
- Quando um sistema envia uma mensagem, ele inclui um número de versão para indicar qual esquema foi utilizado;
- O sistema receptor usa esse número de versão para processar a mensagem com o esquema correto;
- Essa abordagem lida com mensagens com diferentes esquemas sem interrupção e permite atualizações e reverter alterações com facilidade.
Veja o diagrama abaixo como referência:
Utilizar um registro de esquemas para validar contratos de dados garante que as informações que fluem entre os sistemas sejam precisas e consistentes. Isso economiza tempo e esforço no design e na operação dos sistemas que dependem desses dados, especialmente para fins de análise.
Autoescalonamento de Clusters
O MSK é um sistema de mensagens que ajuda diferentes partes de uma aplicação a se comunicarem. Ele utiliza brokers para armazenar e gerenciar as mensagens.
À medida que a quantidade de dados cresce, o MSK aumenta automaticamente o espaço de armazenamento para cada broker. No entanto, era necessário um método para adicionar mais brokers ao sistema quando os existentes ficavam sobrecarregados.
Para resolver esse problema, eles criaram uma função de Autoescalonador.
Veja o diagrama abaixo:
Pense nessa função como um cão de guarda que monitora o quão sobrecarregado cada broker está. Quando a carga de trabalho de um broker (medida pela utilização da CPU) ultrapassa um determinado nível, a função de Autoescalonador entra em ação e faz duas coisas:
- Adiciona um novo broker ao sistema MSK para ajudar a lidar com a carga de trabalho aumentada.
- Aciona uma função Lambda para redistribuir os dados de forma uniforme entre todos os brokers, incluindo o novo.
Dessa forma, o sistema MSK pode se adaptar automaticamente para lidar com mais dados e tráfego sem a necessidade de adicionar brokers ou mover dados manualmente.
Fragmentação Baseada em Domínio
Para garantir que o sistema de mensagens possa lidar com uma grande quantidade de dados e minimizar o risco de falhas, os eventos são divididos em grupos separados com base em seu domínio.
Cada grupo tem seu próprio cluster MSK dedicado. Isso é como ter salas de correio separadas para diferentes departamentos em uma grande empresa. O domínio de um evento determina a qual cluster e tópico ele pertence. Por exemplo, eventos relacionados a perfis de usuários podem ir para um cluster, enquanto eventos relacionados a pedidos de produtos podem ir para outro.
Os aplicativos que precisam receber eventos podem optar por obtê-los de qualquer um desses tópicos baseados em domínio. Isso melhora a flexibilidade e ajuda a distribuir a carga de trabalho por todo o sistema.
Para garantir que a plataforma esteja sempre disponível e possa atender usuários globalmente, ela é configurada para operar em várias regiões. Em cada região, há uma configuração de alta disponibilidade. Isso significa que, se uma parte do sistema falhar, outra parte pode assumir automaticamente, garantindo um serviço contínuo.
Conclusão
A arquitetura orientada a eventos do McDonald’s demonstra uma implementação bem-sucedida de uma plataforma de processamento de eventos em grande escala e em nível global. O sistema lida de forma eficaz com casos de uso variados, desde o rastreamento de pedidos móveis até comunicações de marketing, mantendo alta confiabilidade e desempenho.
Os fatores-chave para o sucesso incluem a implementação robusta do AWS MSK, a gestão eficaz de esquemas e mecanismos abrangentes de tratamento de erros. A abordagem de fragmentação baseada em domínio e as capacidades de autoescalonamento da arquitetura provaram ser cruciais para lidar com volumes crescentes de eventos.
Algumas das melhores práticas estabelecidas com essa implementação incluem:
- Uso padronizado de SDKs em diferentes linguagens de programação;
- Gestão centralizada de esquemas;
- Tratamento robusto de erros com tópicos de mensagens com falhas;
- Otimização de desempenho por meio de cache de esquemas.
Olhando para o futuro, a plataforma do McDonald’s está posicionada para evoluir com aprimoramentos planejados, incluindo:
- Suporte formal para especificação de eventos;
- Transição para MSK sem servidor;
- Implementação de autoescalonamento de partições;
- Melhoria nas ferramentas e na experiência do desenvolvedor.
Essas melhorias fortalecerão ainda mais as capacidades da plataforma, mantendo seus princípios fundamentais de escalabilidade, confiabilidade e simplicidade.
Aviso Legal: As informações neste post foram derivadas do Blog Técnico do McDonald’s. Todo o crédito pelos detalhes técnicos vai para a equipe de engenharia do McDonald’s. Os links para os artigos originais estão presentes na seção de referências ao final do post. Analisamos os detalhes e fornecemos nossa opinião sobre eles. Se encontrar imprecisões ou omissões, por favor, deixe um comentário, e faremos o possível para corrigir.
