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 en quasi-temps réel de la flotte opérant au sol 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 à un stade précoce ;
  • 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éliorer la sécurité en surveillant le comportement des conducteurs et en identifiant les dangers potentiels
  • Optimiser les itinéraires et les plannings des conducteurs pour améliorer l'efficacité
  • Respecter les réglementations en suivant la position des véhicules et les heures de service

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 les 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'adresse aux personnes suivantes :

À la fin de ce document, vous devriez avoir une compréhension de base des éléments et des considérations clés d'un système de streaming, ainsi que des blocs de construction de Google Maps Platform et Google Cloud qui composent 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 Fleet Events est une solution Open Source qui permet aux clients et partenaires Mobility de générer des événements clés en plus des composants Fleet Engine et Google Cloud. Aujourd'hui, la solution de référence aide les clients qui utilisent la solution du parc du dernier kilomètre, et prendra en charge les courses et les livraisons à la demande par la suite.

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 (comme celles ci-dessous) aux parties prenantes ou déclencher d'autres actions pour votre parc.

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

Chaque composant de la solution de référence peut être personnalisé pour répondre aux besoins de votre entreprise.

Éléments de base logiques

Diagramme : le diagramme suivant présente les blocs de construction de haut niveau qui composent la solution de référence Événements de parc automobile.

Présentation des événements de parc et des blocs de construction logiques

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

  • Source de l'événement : origine du flux d'événements. Les solutions Last Mile Fleet et On-demand Rides and Deliveries s'intègrent à Cloud Logging, ce qui permet de transformer les journaux d'appels RPC 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 effectue des calculs sur un flux d'événements de journal. Pour détecter un tel 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 les changements. Il est possible que les événements n'incluent pas toujours toutes les informations qui vous intéressent. Dans ce cas, ce bloc peut effectuer des appels de recherche vers les backends si nécessaire.
    • Magasin d'état : certains frameworks de traitement fournissent des données intermédiaires persistantes par elles-mêmes. Si ce n'est pas le cas, un service de persistance des données de type K-V est un bon choix pour stocker l'état vous-même, car ces données doivent être uniques à 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 distribution d'événements pour une 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 des services

Lors de l'implémentation de la solution de référence pour Last Mile Fleet Solution ou On-demand Rides and Deliveries Solution (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 permettant d'implémenter la solution de référence.

Composants de base pour la création de solutions de référence pour les événements de parc

Mise en page du projet Cloud

Nous vous recommandons de choisir par défaut un déploiement multiprojets. Cela permet de séparer clairement les consommations Google Maps Platform et Google Cloud, et de les associer à l'accord de facturation de votre choix.

Source de l'événement

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

Récepteur

Dans Google Cloud, Cloud Pub/Sub est le système de diffusion de messages en temps quasi réel de référence. Tout comme les événements de la source ont été transmis à 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 fois à la hausse et à la baisse.

  • Cloud Functions comme plate-forme de calcul pour la version initiale (*)
    • Sans serveur, avec des contrôles de scaling pour gérer les coûts
    • Java comme langage de programmation, étant donné la disponibilité des bibliothèques clientes pour les API liées à Fleet Engine, ce qui facilite l'implémentation
  • Cloud Firestore en tant que magasin d'état
    • Serveur de stockage clé-valeur
  • Cloud Pub/Sub comme point d'intégration avec les composants en amont et en aval
    • Intégration en quasi-temps réel faiblement couplée

Les fonctions peuvent être utilisées telles quelles avec les paramètres par défaut, mais peuvent également être reconfigurées. Les paramètres de configuration sont définis par le biais de scripts de déploiement et sont décrits 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 qui peuvent vous aider à répondre à différentes exigences.

Déploiement

Pour rendre le processus de déploiement de la solution de référence reproductible, personnalisable, contrôlable au niveau du code source et sécurisé, Terraform a été choisi comme outil d'automatisation. Terraform est un outil IaC (Infrastructure as Code) largement adopté et 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 qui peuvent être utilisés indépendamment. Les modules fournissent un large éventail de variables configurables, dont la plupart ont des valeurs par défaut. Vous pouvez ainsi vous lancer rapidement, mais aussi personnaliser votre configuration en fonction de vos besoins et préférences.

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

  • Configuration de la journalisation Fleet Engine : automatisez les configurations Cloud Logging à 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 le déploiement de l'exemple de code de fonction et gère également l'automatisation des paramètres d'autorisation requis pour une intégration sécurisée entre projets.
  • Déploiement de l'ensemble de la solution de référence : 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'emprunt 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é.

Actions 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

Consignez vos exigences

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

Commencez par indiquer pourquoi vous souhaitez ou devez utiliser des événements quasi en temps réel. Voici quelques questions pour vous aider à définir vos besoins.

  • Quelles informations sont nécessaires pour qu'un flux d'événements soit utile ?
    • Le résultat peut-il être obtenu uniquement à partir des données capturées ou produites dans les services Google ? Ou bien, 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 sur plusieurs événements, quel type d'agrégation cela nécessitera-t-il ? Essayez de définir les étapes logiques. (par exemple, Comparez l'ETA/ATA aux SLO pour un sous-ensemble de la flotte pendant les heures de pointe afin de calculer les performances en cas de contraintes de ressources.)
  • Pourquoi êtes-vous intéressé par un modèle basé sur les événements plutôt que par un modèle par lots ? Est-ce pour une latence plus faible (délai d'action) ou pour une intégration faiblement couplée (agilité) ?
    • Si vous souhaitez une faible latence, définissez la valeur sur "low". Minutes ? Secondes ? Sous-seconde ? Et quelle latence ?
  • Votre équipe a-t-elle déjà investi dans une pile technologique et les compétences associées ? Si oui, de quoi s'agit-il et quels points d'intégration fournit-il ?
    • Existe-t-il des exigences auxquelles vos systèmes actuels ne peuvent pas répondre ou qui peuvent leur poser des difficultés lors du traitement des événements provenant de votre parc ?

Principes de conception

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

  • Privilégiez les options les plus simples.
  • Par défaut, le retour sur investissement est plus rapide. Moins de code, courbe d'apprentissage plus faible.
  • Pour la latence et les performances, essayez d'atteindre le seuil que vous avez défini, et non l'optimisation maximale. Évitez également l'optimisation extrême, car elle ajoute souvent de la complexité.
  • Il en va de même pour les coûts. Maintenez les coûts à un niveau raisonnable. Vous n'êtes peut-être pas encore en mesure de vous engager à utiliser des services à forte valeur ajoutée, mais relativement plus coûteux.
  • Lors d'une phase expérimentale, la réduction de la taille peut être aussi importante que son augmentation. Choisissez une plate-forme qui vous permet de faire évoluer votre capacité à la hausse (avec un plafond) et à la baisse (idéalement jusqu'à zéro) afin de ne pas dépenser lorsque vous ne faites rien. Vous pourrez envisager de passer à une infrastructure toujours active et à hautes performances plus tard, lorsque vous aurez une meilleure idée de vos besoins.
  • Observer et mesurer pour identifier les points à améliorer
  • Maintenez un couplage faible entre les services. Cela vous permettra de les échanger plus facilement par la suite.
  • Enfin, la sécurité ne doit pas être négligée. En tant que service exécuté dans un environnement de cloud public, le système ne doit comporter aucune porte non sécurisée.

Concepts de streaming

Si vous êtes relativement nouveau dans le domaine des événements ou du streaming, il existe des concepts clés à connaître, 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, ce n'est pas le cas dans le traitement par flux. Un embouteillage dans une ville peut générer soudainement de nombreux événements dans une zone spécifique, et vous devez toujours être en mesure de les traiter.
  • Fenêtrage : au lieu de traiter les événements un par un, il est souvent préférable de regrouper les événements sur une chronologie dans des "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)" ou "fenêtres de session (pendant ce trajet)". Plus la fenêtre est longue, plus les résultats sont longs à produire. 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 fenêtres relativement longues. Toutefois, vous ne souhaitez pas attendre la toute fin de la fenêtre pour générer des événements, mais plutôt émettre des résultats intermédiaires entre-temps. Ce concept peut être mis en œuvre dans les cas d'utilisation où il est utile de renvoyer d'abord des résultats rapides, puis de les corriger ultérieurement. Imaginez que vous émettez un état intermédiaire à 25 %, 50 % et 75 % de l'avancement d'une livraison.
  • Ordre : les événements n'atteignent pas nécessairement le système dans l'ordre dans lequel ils ont été générés. Cela est particulièrement utile pour les cas d'utilisation impliquant des communications sur des réseaux mobiles, qui ajoutent des délais et des chemins de routage complexes. Vous devez connaître la différence entre le "temps de l'événement" (le moment où l'événement s'est réellement produit) et le "temps de traitement" (le moment où l'événement a atteint le système), et gérer les événements en conséquence. En général, vous devez traiter les événements en fonction de leur heure.
  • Distribution des messages : au moins une fois ou exactement une fois : les différentes plates-formes d'événements ne prennent pas toutes en charge 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, à des dommages involontaires causés au téléphone, à une perte de connectivité dans un tunnel ou à un message reçu, mais uniquement en dehors d'une fenêtre acceptable. Quel serait l'impact de l'incomplétude sur vos résultats ?

Cette liste n'est pas exhaustive, mais elle vous donne une idée des types de contenus qui peuvent être considérés comme du contenu généré par IA. Voici quelques lectures fortement recommandées qui peuvent vous aider à mieux comprendre chacun d'eux.

Contributeurs

Google gère ce document. Les contributeurs suivants en sont les auteurs originaux.

Auteurs principaux :