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 temps quasi réel du parc fonctionnant au sol sont utiles pour les entreprises de plusieurs manières. Par exemple, les entreprises peuvent utiliser ces fonctionnalités pour:

  • surveiller les performances de leur parc et identifier les problèmes potentiels dès le début ;
  • Améliorez le service client en fournissant des heures d'arrivée prévues précises et des informations de suivi.
  • 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 ;
  • Optimisez les itinéraires et les horaires des chauffeurs pour une efficacité renforcée
  • Respectez la réglementation en suivant l'emplacement des véhicules et les horaires d'ouverture

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

Ce document concerne:

  • Architectes connaissant les services de mobilité de Google Maps Platform et l'un de ses composants principaux, "Fleet Engine". Si vous ne connaissez pas encore les "services de mobilité", nous vous recommandons de vous familiariser avec la solution Last Mile Fleet et/ou avec la solution On-demand Rides and Deliveries, selon vos besoins.
  • Architectes familiarisés avec Google Cloud. Pour les personnes qui débutent sur Google Cloud, la lecture préalable Créer des pipelines de flux de données sur Google Cloud est recommandée.
  • Si vous ciblez d'autres environnements ou piles logicielles, concentrez-vous sur la compréhension des points d'intégration de Fleet Engine et des considérations clés, qui doivent toujours s'appliquer.
  • Personnes qui souhaitent généralement découvrir comment générer et utiliser les événements provenant de flottes

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

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

La solution de référence pour les événements de parc est une solution Open Source qui permet aux clients et aux partenaires de mobilité de générer des événements clés sur les composants Fleet Engine et Google Cloud. Aujourd'hui, la solution de référence prend en charge les clients qui utilisent la solution Last Mile Fleet. Par la suite, elle prend en charge les trajets à la demande et la livraison.

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

  • Modification de l'heure d'arrivée prévue pour l'arrivée de la tâche
  • Modification de l'heure d'arrivée prévue relative à l'arrivée d'une tâche
  • Temps restant avant l'arrivée de la tâche
  • Distance restante avant 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é pour répondre aux besoins de votre entreprise.

Composants logiques

Diagramme : Le schéma suivant présente les principaux composants qui constituent la solution de référence sur les événements de parc

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

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

  • Source de l'événement: source du flux de l'événement d'origine. La solution Last Mile Fleet et la solution On-demand Rides and Deliveries s'intègrent à Cloud Logging et permet de transformer les journaux d'appels RPC Fleet Engine en flux d'événements mis à la disposition des développeurs. Il s'agit de la source principale à utiliser.
  • Traitement: les journaux d'appels RPC bruts sont convertis en événements de changement d'état dans ce bloc, qui effectue le calcul sur un flux d'événements de journaux. Pour détecter une telle modification, ce composant nécessite un magasin d'état afin que les nouveaux événements entrants puissent être comparés aux précédents en vue de détecter un changement. 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 aux backends si nécessaire.
    • Magasin d'état: certains frameworks de traitement fournissent eux-mêmes des données intermédiaires persistantes. Mais 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 par vous-même, puisqu'il doit être propre à un véhicule et à un type d'événement.
  • Récepteur (événements personnalisés): tout changement d'état détecté doit être mis à la disposition de tous les services ou applications qui peuvent en bénéficier. Il est donc naturel de publier cet événement personnalisé dans un système de diffusion d'événements pour une utilisation en aval.
  • Service en aval: code qui utilise les événements générés et effectue des actions propres à votre cas d'utilisation.

Choix du service

La mise en œuvre de la solution de référence pour Last Mile Fleet Solution ou On-demand Rides and Deliveries Solution (disponible fin 3e trimestre 2023) est simple. En revanche, l'option "Traitement" comporte un large éventail d'options. La solution de référence a choisi les services Google suivants.

Diagramme : Le schéma suivant présente le service Google Cloud pour mettre en œuvre la solution de référence.

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

Disposition du projet Cloud

Nous vous recommandons d'utiliser par défaut un déploiement multiprojet. Ainsi, les utilisations de Google Maps Platform et de Google Cloud peuvent être clairement séparées et liées au mode de facturation de votre choix.

Source de l'événement

"Last Mile Fleet Solution" et "On-demand Rides and Deliveries Solution" écrivent les charges utiles des requêtes et réponses API dans Cloud Logging. Cloud Logging fournit des 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.

Sink

Dans Google Cloud, Cloud Pub/Sub est le système de distribution de messages privilégié en temps quasi réel. Tout comme les événements de la source sont transmis à Pub/Sub, les événements personnalisés sont également publiés sur Pub/Sub pour une utilisation en aval.

Traitement

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

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

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 via des scripts de déploiement et sont documentés en détail dans les fichiers README du module Terraform correspondants.

*Remarque: Cette solution de référence prévoit de publier d'autres implémentations pouvant 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 et sécurisé du code source, Terraform est choisi comme outil d'automatisation. Terraform est un outil IaC (Infrastructure as Code) couramment utilisé et compatible avec Google Cloud.

Modules Terraform

Au lieu de créer un seul module monolithique de déploiement de solution de référence, 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. La plupart ont des valeurs par défaut pour vous permettre de démarrer rapidement, mais vous pouvez également 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 Fleet Engine: automatisez les configurations associées à Cloud Logging pour les utiliser avec Fleet Engine. Dans la solution de référence, il permet d'acheminer les journaux associés à Fleet Engine vers un sujet Pub/Sub spécifié.
  • Déploiement de la fonction cloud pour les événements de parc: contient l'exemple de déploiement de code de fonction et gère également l'automatisation des paramètres d'autorisation requis pour une intégration multiprojet sécurisée.
  • Déploiement de la solution de référence complète: appelle les deux modules précédents et encapsule l'intégralité 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. Reportez-vous aux articles suivants pour mieux comprendre les avantages de Google Cloud qui vous permettent de mieux contrôler la sécurité.

Actions suivantes

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

Annexe

Connaître vos besoins

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

Tout d'abord, expliquez en détail pourquoi vous êtes intéressé ou besoin d'utiliser des événements quasiment en temps réel. Voici quelques questions qui vous aideront à définir vos besoins.

  • Quelles sont les informations requises pour qu'un flux d'événements soit utile ?
    • Le résultat peut-il être dérivé uniquement de données capturées ou produites dans les services Google ? Ou bien l'enrichissement des données à l'aide de 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 sont les métriques que vous souhaitez mesurer en tant qu'entreprise ? Comment sont-elles définies ?
    • Si vous deviez calculer des métriques pour plusieurs événements, quel type d'agrégation utiliseriez-vous ? Essayez de mettre en page les étapes logiques. (par exemple, Comparez l'heure d'arrivée prévue/ATA aux SLO d'un sous-réseau du parc pendant les heures de pointe pour calculer les performances en fonction des contraintes liées aux ressources.)
  • Pourquoi êtes-vous intéressé par un modèle basé sur les événements ou plutôt par un modèle par lot ? Est-ce pour une latence plus faible (temps d'action) ou une intégration faiblement couplée (agilité) ?
    • Pour une faible latence, définissez la valeur "faible". Quelques minutes ? Des secondes ? En moins d'une seconde ? Et quelle latence ?
  • Avez-vous déjà investi en tant qu'équipe dans une pile technologique et des compétences connexes ? Si oui, de quoi s'agit-il et quels sont les points d'intégration qu'il offre ?
    • Existe-t-il des exigences auxquelles vos systèmes actuels ne peuvent pas répondre ou auxquels ils pourraient être confronté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 permet de prendre des décisions de conception cohérentes, en particulier lorsque vous avez le choix entre de nombreuses options.

  • Optez par défaut pour des options plus simples.
  • Valeur par défaut : délai de rentabilisation plus court. Moins de code, moins de phase d'apprentissage
  • Pour la latence et les performances, essayez d'atteindre le seuil que vous avez défini, et non une optimisation maximale. Évitez également toute optimisation extrême, car elle augmente souvent la complexité.
  • Il en va de même pour les coûts. Maintenir des coûts raisonnables. Il se peut que vous ne puissiez pas encore vous engager à utiliser des services à forte valeur ajoutée, mais relativement plus coûteux.
  • Dans la phase expérimentale, l'augmentation de la capacité peut être aussi importante que la réduction de la capacité. Prenons l'exemple d'une plate-forme offrant la flexibilité nécessaire pour effectuer un scaling à la hausse avec une limite et à la baisse (idéalement à zéro) afin de ne pas dépenser d'argent si vous ne faites rien. Vous pouvez envisager de hautes performances avec une infrastructure toujours activée plus tard dans la transition, lorsque vous êtes sûr de ses besoins.
  • Observez et mesurez afin de pouvoir identifier plus tard où travailler plus avant.
  • Maintenir les services faiblement couplés. Il est ainsi plus facile d'en permuter par la suite.
  • Enfin et surtout, la sécurité est un jeu d'enfant. En tant que service s'exécutant dans un environnement de cloud public, il ne peut y avoir aucune porte non sécurisée vers le système.

Concepts de streaming

Si vous débutez dans le domaine des événements ou des flux, 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, dans lequel vous avez généralement une bonne idée de la quantité de données à traiter par flux, vous ne pouvez pas le faire. Un embouteillage dans une ville peut générer soudainement de nombreux événements en provenance d'une zone spécifique, et vous devez toujours être en mesure de le traiter.
  • Fenêtrage : au lieu de traiter les événements un par un, vous souhaiterez souvent regrouper les événements sur une chronologie dans des fenêtres plus petites comme unité de calcul. Vous pouvez choisir parmi différentes stratégies de fenêtrage, telles que "fenêtres fixes (par exemple, tous les jours calendaires)", "fenêtres glissantes (5 dernières minutes)", "fenêtres de session (pendant ce trajet)". Plus la fenêtre est longue, plus les délais de production des résultats sont longs. Choisissez le modèle et la configuration adaptés à vos besoins.
  • Déclenchement : dans certains cas, vous n'avez pas d'autre choix que d'avoir des fenêtres relativement plus longues. Cependant, vous ne souhaitez pas attendre la fin de la fenêtre pour produire des événements, mais plutôt émettre des résultats intermédiaires entre les deux. Ce concept peut être mis en œuvre pour les cas d'utilisation où il est recommandé de renvoyer d'abord des résultats rapides, puis de les corriger par la suite. Imaginez qu'un état intermédiaire soit émis à 25%, 50 % ou 75% d'une livraison.
  • Classement : 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 des communications sur des réseaux mobiles qui ajoutent des retards et des chemins de routage complexes. Vous devez connaître la différence entre "heure de l'événement" (quand l'événement s'est réellement produit) et "heure du traitement" (lorsque l'événement a atteint le système), et gérer les événements en conséquence. En général, vous souhaitez traiter les événements en fonction de "l'heure de l'événement".
  • Distribution des messages (au moins une fois ou exactement une fois): leur prise en charge diffère selon les plates-formes d'événements. En fonction de votre cas d'utilisation, vous devez envisager des stratégies de nouvelle tentative ou de déduplication.
  • Exhaustivité : tout comme avec un changement d'ordre, des messages peuvent être 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, d'un dommage involontaire au téléphone, d'une perte de connectivité dans un tunnel ou d'un message reçu, mais seulement au-delà d'une fenêtre acceptable. Comment l'incompréhension affecterait-elle vos résultats ?

Ceci n'est pas une liste complète, mais une introduction. Voici quelques lectures fortement recommandées qui peuvent vous aider à approfondir votre compréhension de chacune d'elles.

Contributeurs

Google gère ce document. Ce commentaire a été écrit initialement par les contributeurs suivants.

Auteurs principaux: