Plateforme de traitement de données pour un important constructeur européen de bus

Par Oussem ALOUI / Julien GREAU, 21 Janvier 2025

Pays: France

Le client

Notre client est un fabriquant de véhicules de transport en commun, et a pour enjeu l’exploitation des données d’exploitation des véhicules pour des besoins d’analyse d’activité et de maintenance prédictive.

Le défi

Akkodis a mis en place depuis 2018 3 chaines de traitement collectant les données de 9000 bus en exploitation dans toute l’Europe ; le défi a été de migrer ces chaines de traitement & les solutions de stockage associées vers un environnement AWS / Databricks

La solution

Environnement de travail

Nous accédons à Databricks via une connexion SSO déjà mise en place, sans intervention de notre part.

Composants cloud AWS

Nous utilisons S3 pour le stockage des données, CloudWatch pour surveiller ce stockage, EC2 pour exécuter les machines virtuelles associées aux jobs Databricks, et Databricks pour les traitements en Python et SQL.

Détails de mise en œuvre garantissant que la solution reste à jour avec les nouvelles menaces de sécurité

La gestion des menaces de sécurité n’est pas directement prise en charge par notre équipe. Nous veillons uniquement à maintenir les runtimes Databricks à jour pour bénéficier des dernières améliorations et correctifs.

Surveillance des performances & alertes

La surveillance des performances est réalisée via un job Databricks qui suit plusieurs métriques:

1. Utilisation des clusters (en minutes) pour traiter les événements collectés.
2. Nombre de fichiers rejetés par jour.
3. Nombre de VINs uniques.
4. Dates hors norme sur les deux dernières semaines.
5. Retards d’événements sur les 120 derniers jours.
6. Événements PCM et Intellibus par jour.
7. VINs inconnus par date et VINs inconnus distincts.

Diagramme d’architecture

KPI identifiés et monitorés

Les KPI actuellement suivis incluent:

1. Coûts de chaque cluster en fonction du temps de traitement.
2. Utilisation des clusters en minutes, selon les types de machines utilisées.
3. Comparaison des coûts entre les différents types de clusters pour optimiser les ressources.

Cahier d’exécution/notes du client lors de la surveillance des alertes sur les problèmes

Les incidents sont discutés lors des réunions de sprint review ou par échange de mails. Si nécessaire, un ticket est créé et suivi dans Azure DevOps, pour traitement par les équipes Akkodis

Liste de contrôle de déploiement lors de la mise à jour

Avant chaque mise à jour, nous vérifions :

1. La configuration correcte du cluster Databricks.
2. La disponibilité des instances EC2 associées.
3. Que les notebooks sont bien versionnés et poussés correctement sur GitLab.

Pratiques de sécurité réseau utilisées – par exemple, des sous-réseaux séparés, des groupes de sécurité

La gestion de la sécurité réseau n’est pas directement de notre ressort et est prise en charge par une équipe coté client.

• Comment les données en vol sont-elles cryptées, et où, avec quels certificats, comment les certificats sont-ils gérés/rafraîchis, protocoles TLS, etc. La gestion du chiffrement des données en vol et des certificats n’est pas de notre ressort et est prise en charge par une équipe coté client.

Modèle de déploiement

Le déploiement des jobs est principalement géré par Databricks, qui fournit les outils nécessaires pour les planifier et les exécuter. Nous avons également intégré GitLab pour versionner les notebooks et permettre de déclencher automatiquement les jobs depuis ce dernier. Cependant, cette configuration n’est pas un pipeline CI/CD classique, car elle ne comprend pas de phases automatisées comme les tests ou la validation avant le déploiement.

Quel est le RTO et le RPO

Les RTO et RPO ne sont pas formellement définis dans notre environnement actuel et sont pris en charge par les configurations standard de Databricks et AWS.

Quelle est la résilience de la charge de travail: multi-AZ? Multi-région?

Notre architecture est déployée dans une seule région AWS. Nous n’avons pas de visibilité sur l’utilisation ou la configuration éventuelle de Multi-AZ.

Analyse/modélisation du TCO

L’analyse du TCO se concentre sur les coûts liés :

1. Au stockage des données dans S3, en fonction du volume et de la fréquence d’accès.
2. À l’exécution des clusters Databricks, incluant le temps d’utilisation et la taille des instances configurées.

Le résultat

• Les chaines de données sont fonctionnelles. Nous en assurons la maintenance et le fonctionnement.

Rétex projet

1. Maitrise du périmètre.
2. Maitrise de chaines data dans un environnement AWS.
3. Maitrise de des processus de migration.