Gerar eventos quase em tempo real com o Fleet Engine e a solução de referência de eventos de frota

Os indicadores quase em tempo real da frota em operação são úteis para as empresas de várias maneiras. Por exemplo, as empresas podem usar esses dados para:

  • Monitorar o desempenho da frota e identificar possíveis problemas com antecedência
  • Melhorar o atendimento ao cliente fornecendo ETAs precisos e informações de rastreamento
  • Reduza os custos identificando e corrigindo ineficiências
  • Melhorar a segurança monitorando o comportamento do motorista e identificando possíveis riscos
  • Otimizar rotas e horários dos motoristas para melhorar a eficiência
  • Obedeça às regulamentações rastreando a localização do veículo e as horas de serviço

Este documento ilustra como os desenvolvedores podem transformar indicadores dos "Serviços de mobilidade" da Plataforma Google Maps (Solução de frota de última milha (LMFS) ou Solução de entregas e viagens sob demanda (ODRD)) em eventos personalizados acionáveis. Os principais conceitos e decisões de design da Solução de referência de eventos da frota disponível no GitHub também são abordados.

Este documento é relevante para:

  • Arquitetos familiarizados com os serviços de mobilidade da Plataforma Google Maps e um dos principais componentes dela, o Fleet Engine. Para quem não conhece os "Serviços de mobilidade", recomendamos que se familiarize com a Solução de frota do last mile e/ou a Solução de transporte e entregas sob demanda, dependendo das suas necessidades.
  • Arquitetos familiarizados com o Google Cloud. Para quem não conhece o Google Cloud, recomendamos ler Como criar pipelines de dados de streaming no Google Cloud.
  • Se você estiver segmentando outros ambientes ou stacks de software, concentre-se em entender os pontos de integração e as principais considerações do Fleet Engine, que ainda serão aplicáveis.
  • Pessoas com interesse geral em saber como os eventos de frotas podem ser gerados e utilizados.

Ao final deste documento, você terá um entendimento básico dos principais elementos e considerações de um sistema de streaming, além dos blocos de construção da Plataforma Google Maps e do Google Cloud que compõem a Solução de referência de eventos da frota.

Visão geral da solução de referência de eventos da frota

A solução de referência de eventos de frota é de código aberto e permite que clientes e parceiros de mobilidade gerem eventos principais com base no Fleet Engine e em componentes do Google Cloud. Hoje, a solução de referência oferece suporte a clientes que usam a Last Mile Fleet Solution com suporte para viagens e entregas sob demanda em breve.

A solução gera eventos automaticamente com base em mudanças em dados específicos associados a tarefas ou viagens. É possível usar esses eventos para enviar notificações, como as seguintes, aos stakeholders ou acionar outras ações para sua frota.

  • Mudança na HEC para a chegada da tarefa
  • Mudança relativa no HEC para a chegada da tarefa
  • Tempo restante até a chegada da tarefa
  • Distância restante até a chegada da tarefa
  • Mudança no status de TaskOutcome

Cada componente da solução de referência pode ser personalizado para atender às necessidades da sua empresa.

Elementos básicos lógicos

Diagrama : o diagrama a seguir mostra blocos de construção de alto nível que compõem a solução de referência de eventos da frota.

Visão geral e blocos de construção lógicos dos eventos da frota

A solução de referência contém os seguintes componentes:

  • Origem do evento: de onde vem o fluxo de eventos original. A solução de frota do Last Mile e a solução de viagens e entregas sob demanda têm integração com o Cloud Logging, que ajuda a transformar registros de chamadas RPC do Fleet Engine em fluxos de eventos disponíveis para desenvolvedores. Essa é a principal fonte a ser consumida.
  • Processamento: os registros de chamadas RPC brutas são convertidos em eventos de mudança de estado neste bloco que computa um fluxo de eventos de registro. Para detectar essa mudança, esse componente exige um repositório de estado para que novos eventos recebidos possam ser comparados com os anteriores e detectar mudanças. Os eventos nem sempre incluem todas as informações de interesse. Nesses casos, esse bloco pode fazer chamadas de pesquisa para back-ends conforme necessário.
    • Armazenamento de estado: alguns frameworks de processamento fornecem dados intermediários persistentes por conta própria. Caso contrário, para armazenar o estado por conta própria, já que eles precisam ser exclusivos para um veículo e um tipo de evento, um serviço de persistência de dados do tipo K-V é uma boa opção.
  • Coletor (eventos personalizados): a mudança de estado detectada precisa ser disponibilizada para qualquer aplicativo ou serviço que possa se beneficiar dela. Portanto, é uma escolha natural publicar esse evento personalizado em um sistema de entrega de eventos para consumo downstream.
  • Serviço downstream: código que consome os eventos gerados e realiza ações exclusivas para seu caso de uso.

Seleção de serviço

Ao implementar a solução de referência para Last Mile Fleet Solution ou On-demand Rides and Deliveries Solution (disponível no final do terceiro trimestre de 2023), a seleção de tecnologia para "Origem" e "Destino" é simples. Por outro lado, "Processamento" tem uma ampla variedade de opções. A solução de referência escolheu os seguintes Serviços do Google.

Diagrama : o diagrama a seguir mostra o serviço do Google Cloud para implementar a solução de referência.

Blocos de construção da solução de referência de eventos da frota

Layout do projeto do Cloud

Recomendamos que você use uma implantação de vários projetos por padrão. Assim, os consumos da Plataforma Google Maps e do Google Cloud podem ser separados de forma clara e vinculados ao contrato de faturamento escolhido.

Fonte do evento

A Solução de frota do last mile e a Solução de viagens e entregas sob demanda gravam payloads de solicitação e resposta da API no Cloud Logging. O Cloud Logging entrega registros a um ou mais serviços de sua escolha. O roteamento para o Cloud Pub/Sub é uma ótima opção aqui e permite converter registros em um fluxo de eventos sem programação.

Coletor

No Google Cloud, o Cloud Pub/Sub é o sistema de entrega de mensagens quase em tempo real preferido. Assim como os eventos da origem foram entregues ao Pub/Sub, os eventos personalizados também são publicados no Pub/Sub para consumo downstream.

Processando

Os componentes a seguir têm um papel no processamento de eventos. Assim como os outros blocos de construção, os componentes de processamento são totalmente sem servidor e escalonam bem para cima e para baixo.

  • Cloud Functions como plataforma de computação para a versão inicial (*)
    • Sem servidor, escalonamento vertical e horizontal com controles para gerenciar custos
    • Java como linguagem de programação devido à disponibilidade de bibliotecas de cliente para APIs relacionadas ao Fleet Engine, o que contribui para a facilidade de implementação.
  • Cloud Firestore como um repositório de estado
    • Repositório de chave-valor sem servidor
  • Cloud Pub/Sub como ponto de integração com componentes upstream e downstream
    • Integração quase em tempo real com acoplamento fraco

As funções podem ser usadas como estão com as configurações padrão, mas também podem ser reconfiguradas. Os parâmetros de configuração são definidos por scripts de implantação e estão documentados em detalhes nos arquivos README dos módulos correspondentes do Terraform.

*Observação: esta solução de referência planeja lançar implementações alternativas que podem ajudar a atender a diferentes requisitos.

Implantação

Para tornar o processo de implantação da solução de referência repetível, personalizável, controlável e seguro, o Terraform foi escolhido como ferramenta de automação. O Terraform é uma ferramenta de IaC (infraestrutura como código) amplamente adotada com suporte completo para o Google Cloud.

Módulos do Terraform

Em vez de criar um grande módulo monolítico de implantação de solução de referência, blocos reutilizáveis de automação são implementados como módulos do Terraform que podem ser usados de forma independente. Os módulos oferecem uma ampla variedade de variáveis configuráveis, a maioria com valores padrão para que você possa começar rapidamente, mas também tenha a flexibilidade de personalizar com base nas suas necessidades e preferências.

Módulos incluídos na solução de referência:

  • Configuração de geração de registros do Fleet Engine: automatize as configurações relacionadas ao Cloud Logging para uso com o Fleet Engine. Na solução de referência, ele é usado para encaminhar registros relacionados ao Fleet Engine para um tópico específico do Pub/Sub.
  • Implantação da função do Cloud para eventos da frota: contém a implantação do código de amostra da função e também processa a automação das configurações de permissão necessárias para uma integração segura entre projetos.
  • Implantação da solução de referência completa: chama os dois módulos anteriores e encapsula toda a solução.

Segurança

O IAM é adotado para aplicar os princípios de privilégio mínimo, além das práticas recomendadas de segurança do Google Cloud, como a representação de contas de serviço. Consulte os artigos a seguir para entender melhor o que o Google Cloud oferece para dar mais controle sobre a segurança.

Próximas ações

Agora você pode acessar e conhecer melhor a Solução de referência de eventos da frota. Acesse o GitHub para começar.

Apêndice

Reúna os requisitos

Recomendamos que você reúna seus requisitos no início do processo.

Primeiro, capture os detalhes sobre por que você tem interesse ou precisa usar eventos quase em tempo real. Confira algumas perguntas para ajudar você a definir suas necessidades.

  • Quais informações são necessárias para que um fluxo de eventos seja útil?
    • O resultado pode ser derivado apenas de dados capturados ou produzidos nos Serviços do Google? Ou o enriquecimento de dados com sistemas externos integrados é necessário? Se sim, quais são esses sistemas e quais interfaces de integração eles oferecem?
    • Quais métricas você gostaria de medir como empresa? Como eles são definidos?
    • Se você precisar calcular métricas em vários eventos, que tipo de agregação será necessário? Tente descrever as etapas lógicas. Por exemplo: Compare a ETA/ATA com os SLOs em um subconjunto da frota durante os horários de pico para calcular a performance em condições de restrição de recursos.
  • Por que você tem interesse em um modelo baseado em eventos em vez de em lote? Isso é para menor latência (tempo até a ação) ou para uma integração pouco acoplada (agilidade)?
    • Se for para baixa latência, defina como "low". Minutos? Segundos? Subsegundo? E qual é a latência?
  • Você já investiu em uma tecnologia e habilidades relacionadas como uma equipe? Se sim, qual é e quais pontos de integração ele oferece?
    • Há requisitos que seus sistemas atuais não atendem ou que podem ter dificuldades ao processar eventos da sua frota?

Princípios de design

É sempre útil ter um processo de pensamento a seguir. Isso ajuda a tomar decisões de design consistentes, principalmente quando há várias opções disponíveis.

  • Use opções mais simples.
  • O padrão é um tempo de retorno do investimento mais curto. Menos código, menor curva de aprendizado.
  • Para latência e desempenho, tente atingir a meta definida, não a otimização máxima. Evite otimizações extremas, porque elas geralmente aumentam a complexidade.
  • O mesmo vale para o custo. Mantenha o custo razoável. Talvez você ainda não esteja em um estado em que possa se comprometer a usar serviços de alto valor, mas relativamente mais caros.
  • Em uma fase experimental, a redução de escalonamento pode ser tão importante quanto o aumento. Considere uma plataforma que ofereça flexibilidade para aumentar a escala com limite e também reduzir a escala (idealmente para zero) para que você não gaste quando não estiver fazendo nada. O alto desempenho com infraestrutura sempre ativa pode ser considerado mais tarde na jornada, quando você tiver certeza das necessidades.
  • Observe e meça para identificar depois onde trabalhar mais.
  • Mantenha os serviços acoplados com flexibilidade. Isso facilita a troca de peça por peça mais tarde.
  • Por último, mas não menos importante, a segurança não pode ser negligenciada. Como um serviço executado em um ambiente de nuvem pública, não pode haver portas sem segurança para o sistema.

Conceitos de streaming

Se você não tem muita experiência com eventos ou streaming, é importante conhecer alguns conceitos básicos, alguns deles bem diferentes do processamento em lote.

  • Escala : ao contrário do processamento em lote, em que geralmente se tem uma boa ideia da quantidade de dados a serem processados, no streaming isso não é possível. Um congestionamento em uma cidade pode gerar muitos eventos de repente em uma área específica, e você ainda precisa processar isso.
  • Janelas : em vez de processar eventos um a um, muitas vezes é melhor agrupar eventos em uma linha do tempo em "janelas" menores como uma unidade para computação. Há várias estratégias de janelamento, como "janelas fixas (por exemplo, todos os dias do calendário)", "janelas deslizantes (últimos 5 minutos)" e "janelas de sessão (durante esta viagem)", que você pode escolher. Quanto maior a janela, mais longos serão os atrasos na produção de resultados. Escolha o modelo e a configuração certos para atender aos seus requisitos.
  • Acionamento : há casos em que não há outra opção a não ser ter janelas relativamente mais longas. No entanto, você não quer esperar até o final da janela para gerar eventos. Em vez disso, emita resultados intermediários. Esse conceito pode ser implementado em casos de uso em que é valioso retornar resultados rápidos primeiro e corrigi-los depois. Imagine emitir um status intermediário em 25%, 50% e 75% da conclusão de uma entrega.
  • Ordenação : os eventos não chegam necessariamente ao sistema na ordem em que foram gerados. Principalmente para casos de uso que envolvem comunicação em redes móveis, o que adiciona atraso e caminhos de roteamento complexos. É preciso estar ciente da diferença entre "horário do evento" (quando o evento realmente aconteceu) e "horário de processamento" (quando o evento chegou ao sistema) e processar os eventos de acordo com isso. Em geral, você quer processar eventos com base em "event time".
  • Entrega de mensagens: pelo menos uma vez x exatamente uma vez: diferentes plataformas de eventos têm suporte diferente para essas opções. Dependendo do caso de uso, é necessário considerar estratégias de nova tentativa ou remoção de duplicidade.
  • Integridade : assim como na mudança de ordenação, há uma chance de mensagens serem perdidas. Isso pode acontecer devido ao desligamento do aplicativo e do dispositivo por causa da duração da bateria, danos não intencionais ao smartphone, perda de conectividade em um túnel ou uma mensagem recebida fora de um período aceitável. Como a incompletude afetaria seus resultados?

Esta não é uma lista completa, mas uma introdução. Confira algumas leituras altamente recomendadas que podem ajudar você a entender melhor cada um deles.

Colaboradores

O Google mantém este documento. Os colaboradores a seguir escreveram o texto original.

Principais autores:

  • Mary Pishny | Gerente de produtos da Plataforma Google Maps
  • Ethel Bao| Engenheira de software, Plataforma Google Maps
  • Mohanad Almiski | Engenheiro de software, plataforma Google Maps
  • Naoya Moritani | Engenheiro de soluções da Plataforma Google Maps