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 émis en temps quasi réel par les flottes 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 parc 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é" ("Last Mile Fleet Solution" (LMFS) ou "On-demand Rides and Deliveries Solution" (ODRD) de Google Maps Platform 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 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 la solution On-demand Rides and Deliveries, selon vos besoins.
  • Architectes qui connaissent 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, familiarisez-vous avec les points d'intégration et les considérations clés de Fleet Engine, qui doivent toujours s'appliquer.
  • Personnes intéressées par la manière dont les événements des flottes peuvent être générés et utilisés.

À 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 aide les clients qui utilisent la solution Last Mile Fleet, ainsi qu'une assistance pour On-demand Rides and Delivery.

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 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 prévue relative pour l'arrivée de la 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é en fonction des besoins de votre entreprise.

Composants logiques

Schéma : Le schéma suivant présente les principaux composants de la solution de référence "É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 d'événement 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.
    • Magasin d'état: certains frameworks de traitement fournissent des données intermédiaires persistantes de manière autonome. 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, l'option "Traitement" dispose d'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 définir par défaut un déploiement multiprojet. 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 la manière dont 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 utilisé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 hausse et à la baisse avec des commandes 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 la mise en œuvre
  • Cloud Firestore en tant que 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 temps quasi réel faiblement couplée

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 du module 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, contrôlable et sécurisé du code source, Terraform a été choisi comme outil d'automatisation. Terraform est un outil IaC (Infrastructure as Code) largement utilisé 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 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 des événements du parc: 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 plusieurs projets.
  • Déploiement complet 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'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é.

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

Rassembler vos besoins

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 sont les métriques que vous souhaitez 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 de la flotte 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 offre-t-il ?
    • Y a-t-il des exigences que vos systèmes actuels ne peuvent pas répondre ou qui pourraient être en difficulté 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 permet de prendre des décisions de conception cohérentes, en particulier lorsque vous avez le choix entre plusieurs options.

  • Utiliser par défaut des options plus simples.
  • Par défaut, le délai de retour sur investissement est plus court. Moins de code, moins de temps d'apprentissage.
  • 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. Faites en sorte que les coûts restent raisonnables. 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, le scaling à la baisse peut être aussi important que l'augmentation de la capacité. 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.
  • Maintenir 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 traitement par flux

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. Il existe 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)" et "Fenêtres de session (pendant ce trajet)", que vous devez choisir. Plus la fenêtre est longue, plus il faut attendre longtemps avant de produire des résultats. 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. Cependant, il ne faut 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 s'agit de l'intérêt de renvoyer des résultats rapides en premier, 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 une communication sur des réseaux mobiles qui ajoute des retards 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 général, vous souhaitez 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 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 au 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 une introduction. Voici quelques lectures vivement recommandées pour vous aider à mieux comprendre chacun d'eux.

Contributeurs

Google gère ce document. Ce message a été initialement rédigé par les contributeurs suivants.

Auteurs principaux: