Générez des événements en quasi-temps réel avec Fleet Engine et la solution de référence pour les événements de parc

Les signaux quasi en temps réel de la flotte opérant sur le terrain sont utiles aux entreprises de plusieurs façons. Par exemple, les entreprises peuvent les utiliser pour:

  • Surveiller les performances de leur flotte et identifier les problèmes potentiels dès le début
  • Améliorer le service client en fournissant des heures d'arrivée prévues et des informations de suivi précises
  • Réduire les coûts en identifiant et en corrigeant les inefficacités
  • Améliorez la sécurité en surveillant le comportement des conducteurs et en identifiant les dangers potentiels
  • Optimiser les itinéraires et les horaires des chauffeurs pour améliorer l'efficacité
  • Respecter la réglementation en suivant l'emplacement et les horaires de service des véhicules

Ce document explique comment les développeurs peuvent transformer les signaux des services de mobilité de Google Maps Platform ("Last Mile Fleet Solution" (LMFS) ou "On-demand Rides and Deliveries Solution" (ODRD)) en événements personnalisés exploitables. Les principaux concepts et décisions de conception de la solution de référence pour les événements de flotte disponible sur GitHub sont également abordés.

Ce document s'applique aux éléments suivants:

  • Architectes familiarisés avec les services de mobilité de Google Maps Platform et avec l'un de ses principaux composants, "Fleet Engine". Si vous ne connaissez pas les "services de mobilité", nous vous recommandons de vous familiariser avec la solution du parc du dernier kilomètre et/ou la solution de courses et de livraisons à la demande, en fonction de vos besoins.
  • Architectes familiarisés avec Google Cloud Pour les nouveaux utilisateurs de Google Cloud, nous vous recommandons de lire Créer des pipelines de données en streaming sur Google Cloud.
  • Si vous ciblez d'autres environnements ou piles logicielles, concentrez-vous sur la compréhension des points d'intégration et des considérations clés de Fleet Engine, qui devraient toujours s'appliquer.
  • Les personnes qui souhaitent découvrir comment générer et utiliser les événements des flottes

À la fin de ce document, vous devriez avoir une compréhension de base des principaux éléments et considérations d'un système de streaming, ainsi que des blocs de construction de Google Maps Platform et de Google Cloud qui constituent la solution de référence pour les événements de flotte.

Présentation de la solution de référence pour les événements de parc

La solution de référence sur les événements de flotte est une solution Open Source qui permet aux clients et partenaires de Mobility de générer des événements clés sur Fleet Engine et les composants Google Cloud. Aujourd'hui, la solution de référence est compatible avec les clients qui utilisent la solution du parc du dernier kilomètre, et sera bientôt compatible avec les courses et livraisons à la demande.

La solution génère automatiquement des événements en fonction des modifications apportées à des données spécifiques associées à des tâches ou à des trajets. Vous pouvez utiliser ces événements pour envoyer des notifications aux personnes concernées (par exemple, les suivantes) ou déclencher d'autres actions pour votre parc.

  • Modification de l'heure d'arrivée prévue de la tâche
  • Modification de l'heure d'arrivée estimée relative
  • Temps restant avant l'arrivée de la tâche
  • Distance restante jusqu'à l'arrivée de la tâche
  • Modification de l'état de TaskOutcome

Chaque composant de la solution de référence peut être personnalisé en fonction des besoins de votre entreprise.

Composants logiques

Schéma : le schéma suivant montre les composants de haut niveau qui constituent la solution de référence Fleet Events.

Présentation des événements de parc et composants logiques

La solution de référence comprend les composants suivants:

  • Source de l'événement: origine du flux d'événements d'origine. Last Mile Fleet Solution et On-demand Rides and Deliveries Solution sont tous deux intégrés à Cloud Logging, ce qui permet de transformer les journaux d'appels RPC de Fleet Engine en flux d'événements disponibles pour les développeurs. Il s'agit de la source principale à consommer.
  • Traitement: les journaux d'appels RPC bruts sont convertis en événements de changement d'état dans ce bloc qui calcule sur un flux d'événements de journal. Pour détecter ce changement, ce composant nécessite un magasin d'état afin que les nouveaux événements entrants puissent être comparés aux précédents pour détecter le changement. Les événements ne contiennent pas toujours toutes les informations qui vous intéressent. Dans ce cas, ce bloc peut effectuer des appels de recherche aux backends si nécessaire.
    • Stockage d'état: certains frameworks de traitement fournissent des données intermédiaires persistantes. Toutefois, si ce n'est pas le cas, un service de persistance des données de type K-V est adapté pour stocker l'état vous-même, car il doit être propre à un véhicule et à un type d'événement.
  • Récepteur (événements personnalisés): le changement d'état détecté doit être mis à la disposition de toute application ou de tout service pouvant en bénéficier. Il est donc naturel de publier cet événement personnalisé dans un système de diffusion d'événements pour la consommation en aval.
  • Service en aval: code qui consomme les événements générés et effectue des actions propres à votre cas d'utilisation.

Sélection de services

Pour implémenter la solution de référence pour la solution du parc du dernier kilomètre ou la solution de transport et de livraison à la demande (disponible fin du troisième trimestre 2023), la sélection de la technologie pour "Source" et "Sink" est simple. En revanche, "Traitement" propose un large éventail d'options. La solution de référence a choisi les services Google suivants.

Diagramme : le diagramme suivant montre le service Google Cloud pour implémenter la solution de référence.

Éléments de base de la solution de référence sur les événements de parc

Structure du projet Cloud

Nous vous recommandons de choisir un déploiement multiprojet par défaut. Cela permet de séparer clairement la consommation Google Maps Platform et Google Cloud, et de l'associer au mode de facturation de votre choix.

Source de l'événement

La solution Last Mile Fleet et la solution Courses et livraisons à la demande écrivent les charges utiles de requête et de réponse de l'API dans Cloud Logging. Cloud Logging envoie des journaux à un ou plusieurs services de votre choix. Le routage vers Cloud Pub/Sub est un choix parfait ici et permet de convertir les journaux en flux d'événements sans codage.

Sink

Dans Google Cloud, Cloud Pub/Sub est le système de diffusion de messages en quasi-temps réel de choix. Tout comme les événements de la source ont été envoyés à Pub/Sub, les événements personnalisés sont également publiés dans Pub/Sub pour être consommés en aval.

Traitement

Les composants suivants jouent un rôle dans le traitement des événements. Comme les autres blocs de construction, les composants de traitement sont entièrement sans serveur et s'adaptent bien à la hausse et à la baisse.

  • Cloud Functions en tant que plate-forme de calcul pour la version initiale (*)
    • Sans serveur, évolutif à la demande et avec des commandes de scaling pour gérer les coûts
    • Java comme langage de programmation, compte tenu de la disponibilité de bibliothèques clientes pour les API liées à Fleet Engine, qui facilitent l'implémentation
  • Cloud Firestore en tant que store d'état
    • Stockage clé-valeur sans serveur
  • Cloud Pub/Sub comme point d'intégration avec les composants en amont et en aval
    • Intégration en quasi-temps réel avec couplage lâche

Les fonctions peuvent être utilisées telles quelles avec les paramètres par défaut, mais elles peuvent également être reconfigurées. Les paramètres de configuration sont définis via des scripts de déploiement et sont documentés en détail dans les fichiers README des modules Terraform correspondants.

*Remarque: Cette solution de référence prévoit de publier d'autres implémentations pouvant aider à répondre à différentes exigences.

Déploiement

Pour rendre le processus de déploiement de la solution de référence reproductible, personnalisable, avec un code source contrôlé et sécurisé, Terraform est choisi comme outil d'automatisation. Terraform est un outil IaC (Infrastructure as Code) largement adopté, qui offre une compatibilité étendue avec Google Cloud.

Modules Terraform

Au lieu de créer un grand module de déploiement de solution de référence monolithique, des blocs d'automatisation réutilisables sont implémentés en tant que modules Terraform pouvant être utilisés indépendamment. Les modules fournissent un large éventail de variables configurables, dont la plupart sont associées à des valeurs par défaut pour vous permettre de démarrer rapidement, mais aussi de les personnaliser en fonction de vos besoins et de vos préférences.

Modules inclus dans la solution de référence:

  • Configuration de la journalisation de Fleet Engine: automatisez les configurations liées à Cloud Logging pour les utiliser avec Fleet Engine. Dans la solution de référence, il est utilisé pour acheminer les journaux liés à Fleet Engine vers un sujet Pub/Sub spécifié.
  • Déploiement de la fonction cloud Fleet Events: contient l'exemple de déploiement du code de fonction et gère également l'automatisation des paramètres d'autorisation requis pour une intégration sécurisée entre les projets.
  • Déploiement de la solution de référence complète: appelle les deux modules précédents et encapsule l'ensemble de la solution.

Sécurité

IAM est adopté pour appliquer les principes du moindre privilège, ainsi que les bonnes pratiques de sécurité de Google Cloud, telles que l'usurpation d'identité de compte de service. Consultez les articles suivants pour mieux comprendre ce que Google Cloud propose pour vous donner plus de contrôle sur la sécurité.

Étapes suivantes

Vous êtes maintenant prêt à accéder à la solution de référence sur les événements de parc et à l'explorer plus en détail. Pour commencer, accédez à GitHub.

Annexe

Recueillir vos exigences

Nous vous recommandons de recueillir vos exigences plus tôt dans le processus.

Commencez par identifier les raisons pour lesquelles vous souhaitez ou devez utiliser des événements quasi en temps réel. Voici quelques questions qui vous aideront à clarifier vos besoins.

  • Quelles informations sont requises pour qu'un flux d'événements soit utile ?
    • Le résultat peut-il être dérivé uniquement des données capturées ou produites dans les services Google ? Ou l'enrichissement des données avec des systèmes externes intégrés est-il nécessaire ? Si oui, quels sont ces systèmes et quelles interfaces d'intégration proposent-ils ?
    • Quelles métriques souhaitez-vous mesurer en tant qu'entreprise ? Comment sont-ils définis ?
    • Si vous devez calculer des métriques pour plusieurs événements, quel type d'agrégation cela nécessite-t-il ? Essayez de mettre en forme les étapes logiques. (par exemple, Comparez l'heure d'arrivée estimée/l'heure d'arrivée réelle aux SLO d'une sous-section du parc aux heures de pointe pour calculer les performances en cas de contraintes de ressources.)
  • Pourquoi vous intéressez-vous à un modèle basé sur les événements plutôt qu'à un modèle par lot ? S'agit-il d'une latence plus faible (temps de réponse) ou d'une intégration faiblement couplée (agilité) ?
    • Si vous souhaitez une latence faible, définissez la valeur "low". Minutes ? Secondes ? En moins d'une seconde ? Et quelle latence ?
  • Avez-vous déjà investi dans une pile technologique et les compétences associées en équipe ? Si oui, de quoi s'agit-il et quels points d'intégration propose-t-il ?
    • Y a-t-il des exigences que vos systèmes actuels ne peuvent pas respecter ou qui peuvent poser problème lors du traitement des événements provenant de votre parc ?

Principes de conception

Il est toujours utile de suivre un processus de réflexion. Cela vous aide à prendre des décisions de conception cohérentes, en particulier lorsque vous avez le choix entre plusieurs options.

  • Utiliser des options plus simples par défaut
  • Par défaut, le retour sur investissement est plus rapide. Moins de code, pente d'apprentissage plus faible.
  • Pour la latence et les performances, visez à atteindre la barre que vous avez définie, et non l'optimisation maximale. Évitez également une optimisation extrême, car elle entraîne souvent une complexité supplémentaire.
  • Il en va de même pour les coûts. Maintenez un coût raisonnable. Vous n'êtes peut-être pas encore prêt à vous engager à utiliser des services à forte valeur ajoutée, mais relativement plus coûteux.
  • Lors d'une phase expérimentale, la réduction de l'échelle peut être aussi importante que l'augmentation. Choisissez une plate-forme qui vous permet de faire évoluer votre infrastructure à la hausse avec un plafond et à la baisse (idéalement à zéro) afin de ne pas dépenser d'argent lorsque vous ne faites rien. Les performances élevées avec une infrastructure toujours active peuvent être envisagées plus tard dans le processus, lorsque vous êtes sûr de ses besoins.
  • Observez et mesurez pour pouvoir identifier plus tard les points à améliorer.
  • Maintenez les services faiblement couplés. Cela permet de remplacer plus facilement les pièces par la suite.
  • Enfin, la sécurité ne doit pas être laxiste. En tant que service exécuté dans un environnement cloud public, le système ne doit pas comporter de portes non sécurisées.

Concepts de streaming

Si vous débutez avec le traitement basé sur les événements ou le streaming, il est important de connaître certains concepts clés, dont certains peuvent être très différents du traitement par lot.

  • Échelle : contrairement au traitement par lot, où vous avez généralement une bonne idée de la quantité de données à traiter, vous ne pouvez pas le faire avec le streaming. Un embouteillage dans une ville peut générer soudainement de nombreux événements dans la zone concernée, et vous devez quand même pouvoir les traiter.
  • Fenêtrage : au lieu de traiter les événements un par un, vous souhaitez souvent regrouper les événements sur une chronologie en "fenêtres" plus petites en tant qu'unité de calcul. Vous pouvez choisir parmi différentes stratégies de fenêtrage, telles que "fenêtres fixes (par exemple, chaque jour calendaire)", "fenêtres glissantes (5 dernières minutes)" et "fenêtres de session (pendant ce trajet)". Plus la période est longue, plus les délais de génération des résultats sont longs. Choisissez le modèle et la configuration qui répondent à vos besoins.
  • Déclenchement : dans certains cas, vous n'avez pas d'autre choix que d'avoir des périodes relativement plus longues. Toutefois, vous ne souhaitez pas attendre la fin de la période pour générer des événements, mais plutôt émettre des résultats intermédiaires entre-temps. Ce concept peut être implémenté pour les cas d'utilisation où il est utile de renvoyer d'abord des résultats rapides, puis de les corriger ultérieurement. Imaginez d'émettre un état intermédiaire à 25%, 50 % et 75% de l'avancement d'une diffusion.
  • Ordre : les événements n'atteignent pas nécessairement le système dans l'ordre dans lequel ils ont été générés. En particulier pour les cas d'utilisation impliquant la communication sur des réseaux mobiles, ce qui ajoute des délais et des chemins de routage complexes. Vous devez connaître la différence entre "heure de l'événement" (lorsque l'événement s'est réellement produit) et "temps de traitement" (lorsque l'événement a atteint le système) et gérer les événements en conséquence. En règle générale, vous devez traiter les événements en fonction de l'heure de l'événement.
  • Distribution des messages : "au moins une fois" ou "exactement une fois" : les différentes plates-formes d'événements ne sont pas toutes compatibles avec ces options. Selon votre cas d'utilisation, vous devez envisager des stratégies de nouvelle tentative ou de déduplication.
  • Exhaustivité : tout comme pour le changement d'ordre, il est possible que des messages soient perdus. Cela peut être dû à l'arrêt de l'application et de l'appareil en raison de l'autonomie de la batterie de l'appareil, de dommages accidentels sur le téléphone, de la perte de connectivité dans un tunnel ou d'un message reçu, mais uniquement en dehors d'une période acceptable. En quoi l'incomplétude affectera-t-elle vos résultats ?

Cette liste n'est pas exhaustive, mais elle vous donne un aperçu des possibilités. Voici quelques lectures vivement recommandées pour vous aider à mieux comprendre chacun d'eux.

Contributeurs

Google gère ce document. Les contributeurs suivants l'ont initialement rédigé.

Auteurs principaux: