Eventos em tempo real do Fleet Engine

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

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

Este documento mostra como os desenvolvedores podem transformar indicadores dos serviços de mobilidade da Plataforma Google Maps (Solução para frotas de última etapa [LMFS, na sigla em inglês] ou Solução para viagens e entregas sob demanda [ODRD, na sigla em inglês]) em eventos personalizados acionáveis. Os principais conceitos e decisões de design da solução de referência de eventos de 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, o Fleet Engine. Se você não conhece os serviços de mobilidade, recomendamos que se familiarize com a solução de frota de última etapa e/ou a solução de viagens e entregas sob demanda, dependendo das suas necessidades.
  • Arquitetos que conhecem o Google Cloud. Para quem está começando a usar o Google Cloud, recomendamos a leitura de Como criar pipelines de dados de streaming no Google Cloud.
  • Se você estiver segmentando outros ambientes ou pilhas de software, concentre-se em entender os pontos de integração e as principais considerações do Fleet Engine, que ainda devem ser aplicáveis.
  • Pessoas com interesse geral em descobrir como os eventos de frotas podem ser gerados e utilizados.

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

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

A solução de referência de eventos de frota é uma solução de código aberto que permite que clientes e parceiros de mobilidade gerem eventos principais com base no Fleet Engine e nos componentes do Google Cloud. Atualmente, a solução de referência é compatível com clientes que usam a Solução de Frota de Last Mile, com suporte para viagens e entregas sob demanda em seguida.

A solução gera eventos automaticamente com base em mudanças em dados específicos associados a tarefas ou viagens. Use esses eventos para enviar notificações como as seguintes para as partes interessadas ou acionar outras ações para sua frota.

  • Mudança no HEC para 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 à tarefa
  • Mudança de status do 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 os elementos básicos de alto nível que compõem a solução de referência do Fleet Events.

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

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

  • Origem do evento: de onde vem o fluxo de eventos original. As soluções Last Mile Fleet Solution e On-demand Rides and Deliveries Solution têm integração com o Cloud Logging, que ajuda a transformar os 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 brutos de chamadas RPC são convertidos em eventos de mudança de estado nesse bloco que calcula um fluxo de eventos de registro. Para detectar essa mudança, esse componente requer um armazenamento de estado para que os novos eventos recebidos possam ser comparados com os anteriores para 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 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

Quando se trata de implementar a solução de referência para a Solução de frota de última etapa ou a Solução de viagens e entregas on demand (disponível no final do terceiro trimestre de 2023), a seleção de tecnologia para "Origem" e "Coletor" é 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.

Componentes da solução de referência do Fleet Events

Layout do projeto na nuvem

Recomendamos que você use uma implantação de vários projetos como padrão. Isso é feito para que o consumo da Plataforma Google Maps e do Google Cloud possa ser separado de forma clara e vinculado ao seu contrato de faturamento preferido.

Fonte do evento

A Solução de frota de última etapa 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 para um ou mais serviços de sua escolha. O roteamento para o Cloud Pub/Sub é uma escolha perfeita 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 desempenham um papel no processamento de eventos. Assim como os outros elementos básicos, os componentes de processamento são totalmente sem servidor e escalonam bem para cima e para baixo.

  • Cloud Functions como uma plataforma de computação para a versão inicial (*)
    • Sem servidor, escalonamento vertical e horizontal com controles de escalonamento para gerenciar custos
    • Java como linguagem de programação, devido à disponibilidade de bibliotecas de cliente para APIs relacionadas ao Fleet Engine, o que facilita a implementação.
  • Cloud Firestore como um armazenamento 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 flexível

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 documentados em detalhes nos READMEs do módulo do Terraform correspondente.

*Observação: essa 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 por código-fonte e seguro, o Terraform é escolhido como a ferramenta de automação. O Terraform é uma ferramenta de IaC (infraestrutura como código) amplamente adotada com suporte avançado para o Google Cloud.

Módulos do Terraform

Em vez de criar um grande módulo de implantação de solução de referência monolítica, 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 dos eventos de frota: contém a implantação do código de função de amostra e também lida com a automação das configurações de permissão necessárias para a integração segura entre projetos.
  • Implantação de toda a solução de referência: chama os dois módulos anteriores e engloba toda a solução.

Segurança

O IAM é adotado para aplicar princípios de privilégio mínimo com as práticas recomendadas de segurança do Google Cloud, como a identidade temporária de conta de serviço. Consulte os artigos a seguir para entender melhor o que o Google Cloud oferece para dar a você mais controle sobre a segurança.

Próximas ações

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

Apêndice

Reúna os requisitos

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

Primeiro, capture os detalhes sobre o motivo do seu interesse ou da necessidade de usar eventos quase em tempo real. Aqui estão 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 puramente de dados capturados ou produzidos nos Serviços do Google? Ou é necessário o aprimoramento de dados com sistemas externos integrados? 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 seria necessária? Tente organizar as etapas lógicas. Por exemplo: Compare o ETA/ATA com os SLOs em um subconjunto da frota durante os horários de pico para calcular o desempenho sob restrições de recursos.
  • Por que você tem interesse em um modelo baseado em eventos em vez de em lote? É para menor latência (tempo de ação) ou para uma integração de acoplamento flexível (agilidade)?
    • Se for para baixa latência, defina "baixa". Minutos? Segundos? Subsegundo? E qual é a latência?
  • Você já investiu em uma pilha de tecnologia e habilidades relacionadas como equipe? Se sim, qual é o sistema e quais pontos de integração ele oferece?
    • Seus sistemas atuais têm algum requisito que não conseguem atender ou que pode causar problemas ao processar eventos da frota?

Princípios de design

É sempre útil ter um processo de pensamento para seguir. Isso ajuda a tomar decisões de design consistentes, especialmente quando há uma variedade de opções para escolher.

  • Use opções mais simples como padrão.
  • O padrão é um tempo de retorno do investimento mais curto. Menos código, curva de aprendizado menor.
  • Para latência e desempenho, tente atingir o limite definido, não a otimização máxima. Além disso, evite a otimização extrema, porque ela costuma adicionar complexidade.
  • O mesmo vale para o custo. Mantenha o custo razoável. Talvez você ainda não esteja no estado em que pode se comprometer a usar serviços de alto valor, mas relativamente mais caros.
  • Em uma fase experimental, reduzir a escala vertical pode ser tão importante quanto aumentá-la. Considere uma plataforma que ofereça flexibilidade para escalonamento vertical com limite e também redução de escala vertical (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 confiança nas necessidades dela.
  • Observe e meça para identificar onde é preciso trabalhar mais.
  • Manter os serviços acoplados com flexibilidade. Isso facilita a troca de peças mais tarde.
  • Por último, mas não menos importante, a segurança não pode ser negligenciada. Como um serviço em execução em um ambiente de nuvem pública, não pode haver portas não seguras para o sistema.

Conceitos de streaming

Se você não tem muita experiência com streaming ou processamento baseado em eventos, é importante conhecer alguns conceitos-chave, que podem ser bem diferentes do processamento em lote.

  • Escala : ao contrário do processamento em lote, em que você geralmente 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 ser capaz de processá-los.
  • Janelas : em vez de processar eventos um por um, é comum agrupar eventos em uma linha do tempo em "janelas" menores como uma unidade de 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)", "janelas de sessão (durante esta viagem)", que você deve escolher. Quanto maior a janela, maiores 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. Ainda assim, você não quer esperar até o final da janela para produzir eventos, mas sim emitir resultados intermediários entre eles. Esse conceito pode ser implementado para casos de uso em que é importante retornar resultados rápidos primeiro e corrigi-los depois. Imagine emitir um status intermediário em 25%, 50% e 75% de conclusão de uma entrega.
  • Ordenação : os eventos não chegam necessariamente ao sistema na ordem em que foram gerados. Especialmente para casos de uso que envolvem comunicação em redes móveis, o que adiciona atrasos e caminhos de roteamento complexos. É preciso estar ciente da diferença entre "horário do evento" (quando o evento realmente aconteceu) e "horário do processo" (quando o evento chegou ao sistema) e processar os eventos de acordo. Em geral, você quer processar eventos com base no "horário do evento".
  • Entrega de mensagens: pelo menos uma vez x exatamente uma vez: plataformas de eventos diferentes têm suporte diferente para essas opções. Dependendo do caso de uso, é preciso considerar estratégias de repetição ou eliminação de duplicação.
  • Integridade : assim como na mudança de ordenação, há uma chance de perda de mensagens. Isso pode ocorrer devido ao desligamento do aplicativo e do dispositivo devido à duração da bateria do dispositivo, danos não intencionais ao smartphone, perda de conectividade em um túnel ou uma mensagem recebida, mas apenas fora de uma janela aceitável. Como a incompletude afetaria seus resultados?

Esta não é uma lista completa, mas uma introdução. Aqui estão 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 conteúdo original.

Autores principais:

  • Mary Pishny | Gerente de produtos, 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, Plataforma Google Maps