CFF Cargo – Le lac de données

Le défi

Le problème des silos

Dans les entreprises modernes, les données sont omniprésentes et proviennent d’un large éventail de sources différentes, telles que :

– Site(s) web de l’entreprise

– Applications de l’entreprise

– Les appareils IoT

– Les CRM

– Réseaux sociaux

– Outils de gestion des stocks et de logistique (comme SAP)

– Entrepôts de données

– Rapports internes

– Canaux de vente

– Etc.

Le principal problème d’un tel scénario est que chacune de ces données est stockée dans ce qu’on appelle des « silos verticaux », et ces silos ne sont pas conçus pour permettre le partage de données entre eux.

Ce problème fondamental engendre de nombreuses autres difficultés :

– tenter d’analyser ces données à l’aide d’outils d’agrégation et de manière transversale entre les silos nécessite un travail manuel fastidieux et source d’erreurs, impliquant l’exportation de données, l’extraction de données et des « bidouillages » dans des tableurs : en quelques années, les entreprises se retrouvent avec un ensemble d’outils artisanaux.

– Ces outils artisanaux sont assez fragiles et dépendent fortement de la personne qui les a initialement mis en place, ce qui rend leur maintenance cauchemardesque.

– En matière de données, il est difficile de déterminer quelle est la « source unique de vérité ».

– L’emplacement des données est encore plus difficile à déterminer, en particulier dans les moyennes et grandes entreprises.

– Les données brutes (non modifiées) font souvent défaut.

Le lac de données 

Une façon de résoudre le problème des « silos verticaux » consiste à créer un lac de données. Il s’agit d’un espace où les données, provenant de différentes sources, peuvent être stockées et consultées de manière cohérente. Les données sont stockées dans leur format naturel/brut, ce qui permet leur manipulation ultérieure. Parfois, des données transformées sont également stockées dans le lac de données ; elles sont nécessaires pour des tâches telles que le reporting, la visualisation, l’analyse avancée et l’apprentissage automatique.

En général, la « traçabilité » des données (d’où elles proviennent, quand elles ont été acquises et manipulées, et par qui ou quoi) est enregistrée avec les ensembles de données (sous forme de métadonnées ou via un système de recherche simple).

Qu’est-ce qu’un pipeline de données ? 

Pour « alimenter » un lac de données, il faut mettre en place des « workers » qui acquièrent les données à partir de sources (silos). Chaque agent est dédié à une source de données et est relié à des services permettant une analyse des données en temps quasi réel. Cet ensemble de fonctionnalités (agent + services) est communément appelé « pipeline de données ». À l’instar des pompes à eau et des canalisations, les données sont extraites (« pompées ») des sources et « circulent » à travers les services jusqu’à ce qu’elles aboutissent dans des lacs de données ou des solutions de stockage/bases de données spécifiques.

La création d’un lac de données et l’alimentation des pipelines de données peuvent être réalisées à l’aide :

a) des services sur site
b) des services autogérés basés sur le cloud
c) des services cloud entièrement gérés
d) d’une infrastructure sans serveur basée sur le cloud

Le niveau d’engagement requis pour exploiter les architectures précédentes diminue considérablement de a) à d).

Dans le cas a), l’ensemble des opérations incombe à l’équipe informatique, y compris la gestion du matériel.
Dans le cas d), les seules tâches sur lesquelles l’équipe informatique doit se concentrer sont :

– le développement de la logique applicative (logique des workers) ;

– l’utilisation des outils adaptés à la tâche et de leurs API, en respectant les meilleures pratiques en matière de sécurité.

Étant donné que les lacs de données impliquent de nombreux éléments mobiles et différentes technologies, le passage à une architecture entièrement sans serveur est une option qui mérite d’être envisagée pour réduire la complexité opérationnelle.

Les services utilisés dans cette implémentation sont :

AWS Lambda en tant qu’infrastructure informatique pour exécuter les workers de collecte et de transformation des données

AWS Kinesis Stream / Firehose en tant que fournisseur de services de flux de données

Amazon S3 comme système de stockage du lac de données

AWS KMS comme service de chiffrement

AWS System Manager Parameter Store comme référentiel pour les secrets

AWS IAM pour la définition des politiques et des rôles

Passons brièvement en revue chaque composant afin d’analyser la logique qui sous-tend ces choix architecturaux.

Worker de collecte de données => AWS Lambda :

Ce worker doit se connecter au silo/service et en extraire des données. Selon le type de données et leur utilisation, ce worker peut s’exécuter plusieurs fois par jour ou en continu. Dans un environnement sans serveur sur AWS, les options sont les suivantes :

Lambda (exécution planifiée)

Un conteneur déployé sur ECS utilisant Fargate comme infrastructure de calcul (exécution continue)

Nous avons opté pour Lambda car le client souhaitait disposer d’une architecture de pipeline de données capable de gérer différentes fréquences de données ; pour des flux de données quasi continus, un faible taux d’invocation associé à de petits ensembles de données par exécution offre une bonne solution pour utiliser une simple fonction Lambda plutôt qu’un worker conteneurisé plus complexe, tout en conservant la cohérence architecturale avec des flux de données discrets.

Worker de transformation => AWS Lambda :

Ce worker transforme les données selon des critères spécifiques, qui dépendent de la source de données réelle. Lambda est la solution recommandée à utiliser avec AWS Kinesis Firehose. Un événement d’entrée est généré par Kinesis avec des données brutes provenant de la source, Lambda traite et transforme les données selon la logique implémentée par le code, puis les données transformées sont renvoyées vers Kinesis Firehose afin d’être persistées.

Service de flux => Kinesis Stream / Firehose :

Les flux sont particulièrement utiles pour l’ingestion de données, car ils mettent en mémoire tampon les données d’entrée pendant une période configurable et permettent à une architecture modulable de consommer, d’analyser et de traiter les données, par lots et/ou en temps quasi réel. Kinesis Firehose est un service de flux de données géré sans serveur, dont l’objectif est de transférer en continu des données vers un type de destination spécifique. Dans ce cas précis, la cible est un compartiment S3. À l’instar de Kinesis Stream, Firehose peut générer des événements associés aux données qui y transitent. Ces événements peuvent être utilisés pour exécuter du code via Lambda ou pour déclencher des tâches complexes à l’aide d’AWS Step-Functions ou d’autres services AWS.

Lac de données => Amazon S3 :

Une capacité de stockage illimitée, des politiques de cycle de vie configurables et des métadonnées personnalisées sont idéales pour créer un lac de données. Amazon S3 offre tout cela, ainsi qu’une API puissante et une intégration transparente avec d’autres services AWS, comme Firehose. Le lac de données peut se composer d’un seul compartiment ou de plusieurs (données brutes, données transformées, données agrégées…)

Sécurité 1 => KMS :

Les données en transit et au repos sont chiffrées à l’aide de KMS avec des CMK (clés principales client) à portée limitée

Sécurité 2 => Rôle et politiques spécifiques à Lambda :

Les fonctions Lambda s’exécutent avec des autorisations restreintes, définies par des documents de politique IAM associés à un rôle spécifique attribué à la fonction Lambda.

Sécurité 3 => Secrets :

Pour stocker les secrets et les paramètres à l’échelle du service, on utilise Parameter Store. Les secrets sont enregistrés sous forme de chaînes sécurisées et chiffrés avec KMS à l’aide d’une CMK dédiée

AWS est une plateforme qui offre de nombreuses possibilités, il existe donc des services permettant de construire chacune des architectures mentionnées précédemment. Les clients peuvent passer d’une infrastructure entièrement sur site (location de machines bare metal) à une infrastructure entièrement sans serveur et pilotée par les événements. Et même dans un scénario sans serveur, plusieurs options s’offrent à eux.