Événements en temps réel Fleet Engine

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

  • Surveiller les performances de leur parc et identifier les problèmes potentiels à un stade précoce
  • Améliorez le service client en fournissant des heures d'arrivée prévues et des informations de suivi précises.
  • Réduisez 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.
  • Optimisez les itinéraires et les plannings des conducteurs pour améliorer l'efficacité
  • Respectez 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 concepts clés et les décisions de conception de la solution de référence Fleet Events disponible sur GitHub sont également abordés.

Ce document s'applique aux produits suivants :

  • Architectes familiarisés avec les services de mobilité de Google Maps Platform et l'un de ses composants principaux, 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 trajets et de livraisons à la demande, en fonction de vos besoins.
  • Architectes familiarisés avec Google Cloud. Si vous débutez avec Google Cloud, nous vous recommandons de lire Créer des pipelines de flux de données 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 points clés de Fleet Engine, qui devraient toujours s'appliquer.
  • Toute personne souhaitant découvrir comment générer et utiliser des événements à partir de parcs.

À la fin de ce document, vous devriez avoir une compréhension de base des éléments clés et des considérations d'un système de streaming, ainsi que des composants de Google Maps Platform et de Google Cloud qui constituent la solution de référence Fleet Events.

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 est compatible avec les clients qui utilisent la solution du parc du dernier kilomètre, et la compatibilité avec les courses et livraisons à la demande sera bientôt disponible.

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 telles que les suivantes aux parties prenantes ou 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
  • Évolution de l'heure d'arrivée prévue relative pour l'arrivée de la tâche
  • Temps restant avant l'arrivée à la tâche
  • Distance restante jusqu'à l'arrivée de la tâche
  • Changement d'état de TaskOutcome

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

Composants de base logiques

Diagramme : le diagramme suivant présente les composants de base de haut niveau qui constituent la solution de référence Fleet Events.

Présentation de Fleet Events et des composants logiques

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

  • Source d'événement : origine du flux d'événements d'origine. Les solutions Last Mile Fleet Solution et On-demand Rides and Deliveries Solution sont toutes deux intégrées à 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 à utiliser.
  • 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 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 le changement. Les événements n'incluent pas toujours toutes les informations d'intérêt. 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. Sinon, pour stocker l'état vous-même, étant donné qu'il doit être unique pour un véhicule et un type d'événement, un service de persistance des données de type clé-valeur est une bonne solution.
  • 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 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

Lorsqu'il s'agit d'implémenter la solution de référence pour la solution du parc du dernier kilomètre ou la solution de trajets et de livraisons à la demande (disponible fin du troisième trimestre 2023), la sélection de la technologie pour la "source" et le "récepteur" 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 la solution de référence Fleet Events

Mise en page d'un projet sur le cloud

Nous vous recommandons d'utiliser par défaut un déploiement multiprojet. Cela permet de séparer clairement les consommations de Google Maps Platform et de Google Cloud, et de les associer à l'accord 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 des réponses d'API dans Cloud Logging. Cloud Logging transmet les journaux à un ou plusieurs services de votre choix. Le routage vers Cloud Pub/Sub est un choix idéal ici, car il 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 distribution de messages en temps quasi réel de choix. 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 une consommation en aval.

Traitement…

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

  • Cloud Functions comme plate-forme de calcul pour la version initiale (*)
    • Sans serveur, scaling à la hausse et à la baisse 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 la mise en œuvre
  • Cloud Firestore comme magasin d'état
    • Magasin de clés/valeurs 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 à 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 que le processus de déploiement de la solution de référence soit reproductible, personnalisable, contrôlable par le code source 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 seul 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 ont des valeurs par défaut. Vous pouvez ainsi démarrer rapidement, tout en ayant la possibilité 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 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 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é d'un 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 pour 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 rassembler vos exigences plus tôt dans le processus.

Tout d'abord, indiquez pourquoi vous souhaitez ou devez utiliser des événements en temps quasi réel. Voici quelques questions pour vous aider à définir 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 sur plusieurs événements, de quel type d'agrégation auriez-vous besoin ? Essayez de présenter les étapes logiques. (par exemple, Comparez l'heure d'arrivée prévue/réelle aux SLO sur un sous-ensemble du parc pendant les heures pleines 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'au traitement par lot ? Est-ce pour une latence plus faible (temps d'action) ou pour une intégration faiblement couplée (agilité) ?
    • Si vous souhaitez une faible latence, définissez "low". Minutes ? Des secondes ? Moins d'une seconde ? Et quelle latence ?
  • Avez-vous déjà investi dans une pile technologique et des compétences associées en tant qu'équipe ? Si oui, de quoi s'agit-il et quels points d'intégration fournit-il ?
    • Existe-t-il des exigences que vos systèmes actuels ne peuvent pas satisfaire ou qui peuvent poser problème 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.

  • Utilisez par défaut des options plus simples.
  • Par défaut, le délai de rentabilisation est plus court. Moins de code, courbe d'apprentissage plus courte.
  • Pour la latence et les performances, essayez d'atteindre l'objectif que vous avez défini, et non l'optimisation maximale. Évitez également l'optimisation extrême, car elle entraîne souvent une complexité accrue.
  • Il en va de même pour le coût. Maintenez un coût raisonnable. Vous n'êtes peut-être pas encore en mesure de vous engager à utiliser des services de grande valeur, mais relativement plus coûteux.
  • Lors d'une phase expérimentale, la réduction de la capacité peut être aussi importante que l'augmentation de la capacité. Envisagez une plate-forme qui offre la flexibilité nécessaire pour effectuer un scaling à la hausse avec un plafond, mais aussi un scaling à la baisse (idéalement jusqu'à zéro) afin de ne pas dépenser d'argent lorsque vous n'utilisez pas la plate-forme. Vous pourrez envisager des performances élevées avec une infrastructure toujours active plus tard, lorsque vous serez sûr de vos besoins.
  • Observez et mesurez pour pouvoir identifier ultérieurement les points à améliorer.
  • Maintenez les services faiblement couplés. Il est ainsi plus facile de remplacer les pièces une par une par la suite.
  • Enfin, la sécurité ne doit pas être négligée. En tant que service s'exécutant dans un environnement 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 traitement par flux ou basé sur des événements, 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 savoir dans le traitement par flux. Un embouteillage dans une ville peut générer soudainement un grand nombre d'événements dans une zone particulière, 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 les regrouper sur une chronologie en "fenêtres" plus petites en tant qu'unité de calcul. Il existe différentes stratégies de fenêtrage, telles que les "fenêtres fixes (par exemple, chaque jour calendaire)", les "fenêtres glissantes (les cinq dernières minutes)" et les "fenêtres de session (pendant ce trajet)", parmi lesquelles vous devez choisir. Plus la fenêtre est longue, plus les résultats mettent du temps à être générés. 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 plus longues. Cependant, vous ne voulez pas attendre la fin de la fenêtre pour produire des événements, mais plutôt émettre des résultats intermédiaires entre-temps. Ce concept peut être mis en œuvre pour 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 émettiez un état intermédiaire à 25%, 50 % et 75% de l'achèvement 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. C'est particulièrement vrai 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 l'heure de l'événement (le moment où l'événement s'est réellement produit) et l'heure 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 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 : les différentes plates-formes d'événements sont 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, à 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 constitue une introduction. Voici quelques lectures vivement recommandées qui peuvent vous aider à approfondir votre compréhension de chacune d'entre elles.

Contributeurs

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

Auteurs principaux :