SBB Cargo – Digital Twin Service

Le problème : le jumeau numérique 

Notre client avait besoin d’extraire les données les plus récentes provenant de nombreuses sources de données en temps réel. Ces données sont acquises en continu via un ensemble de pipelines de données (comme décrit dans cet article de blog). Le client souhaitait également que les données les plus récentes soient mises à disposition via une API HTTP REST. Le service ainsi créé a été baptisé « Digital Twin », car il collecte et expose les données les plus récentes pour un large éventail d’ensembles de données provenant d’objets physiques, en faisant une « représentation numérique » de l’état de ces objets. 

Défis techniques 

Les données présentent des structures et des formats variés, selon le service dont elles proviennent. Bon nombre de ces services fournissent des données en temps quasi réel, acquises à une fréquence variant de 15 minutes à 1 seconde. Ces données doivent être filtrées en temps réel, normalisées et stockées dans une base de données pouvant ensuite être interrogée par les utilisateurs de l’API. 

Une solution sans serveur basée sur AWS 

Nous voulions que la solution soit cohérente avec l’architecture des pipelines de données et avec la « philosophie de conception sans serveur » que nous avons adoptée avec succès en collaboration avec le client.  

Nous souhaitions également continuer à utiliser les outils et les services gérés fournis par AWS. Lors de la conception de l’architecture, nous avons veillé à faciliter la maintenance et les extensions incrémentielles. L’architecture qui en résulte est illustrée dans l’image suivante et a été décrite à l’aide de Terraform comme outil IaC. 

Le service Digital Twin tire pleinement parti de la modularité de l’architecture de streaming de données : il collecte les données en se connectant aux buffers Kinesis Streams/Firehose déployés dans chaque pipeline de données.

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

– AWS Kinesis Analytics en tant que service d’extraction de données

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

– AWS Lambda en tant qu’infrastructure informatique pour exécuter le microservice d’accès au stockage

– Amazon DynamoDB en tant que couche de persistance

– AWS API Gateway pour fournir des interfaces REST HTTPS

– Amazon Cognito pour fournir l’infrastructure OAuth2

– AWS KMS en tant que service de chiffrement

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

– AWS CloudWatch pour fournir l’infrastructure de journalisation et l’observabilité.

Voici la description de chaque composant.

Extracteur de données => AWS Kinesis Analytics :
Une fois les données récupérées par les workers de sourcing du pipeline, elles sont mises en mémoire tampon pendant une durée configurable dans Kinesis Stream, où elles sont disponibles pour une analyse en temps quasi réel, des transformations ETL ou une surveillance continue. En créant un Data Extractor en tant que consommateur Kinesis, nous avons pu tirer parti de la disponibilité quasi instantanée des données dans Kinesis et de l’architecture modulaire des services de streaming de données. Au lieu de mettre en œuvre un consommateur Kinesis à partir de zéro, nous avons choisi d’utiliser Kinesis Analytics et ses capacités SQL. Ainsi, l’extracteur de données est devenu une simple tâche Kinesis Analytics qui effectue trois opérations : le mappage des propriétés des données (« data templating »), l’extraction continue d’un sous-ensemble de celles-ci (« data pumping ») et la fourniture d’un flux normalisé envoyé vers le flux Kinesis de Digitaltwin (« data delivery »). En connectant un extracteur de données différent pour chaque pipeline de données avec une sortie cohérente, nous avons réussi à normaliser les données sur l’ensemble des pipelines. Tout cela a été réalisé simplement en définissant une ressource Terraform Kinesis Analytics et un ensemble d’instructions SQL enregistrées dans un seul fichier pour chaque extracteur.

Flux Digitaltwin => Flux AWS Kinesis :
Un flux de données avec une durée de vie courte est un bon choix pour mettre en mémoire tampon les données extraites en attendant qu’elles soient persistées (ou analysées plus en détail dans le cadre de futures améliorations de cette architecture). Sur AWS, il est judicieux d’utiliser Kinesis Stream.

Microservice d’accès au stockage => AWS Lambda :
Nous avons utilisé AWS Lambda comme infrastructure informatique pour créer un microservice sans serveur qui écrit et lit des données vers/depuis la couche de persistance. Lambda a été choisi en raison de son modèle d’invocation flexible : le code permettant d’accéder à la couche de persistance est le même quel que soit le service qui en a besoin, et il peut être déclenché par un événement Kinesis (données provenant des extracteurs) ou par un événement API Gateway (requête API REST émanant d’un service consommateur externe).

Couche de persistance => Amazon DynamoDB :
Nous devions stocker la valeur la plus récente pour une métrique de composant donnée. Ce modèle d’accès peut être géré efficacement par un magasin K-V, où la clé est Component.MetricName et la valeur est la métrique proprement dite (plus quelques métadonnées pour identifier sa provenance). DynamoDB est un magasin NoSQL sans serveur qui s’adapte parfaitement à ce scénario. Grâce à sa capacité d’écriture conditionnelle, il est facile de garantir qu’une tentative d’écriture ne réussit qu’avec les données les plus récentes. Grâce à ses capacités d’autoscaling, DynamoDB est également capable d’absorber n’importe quelle charge d’accès.

Interfaces REST HTTPS => AWS API Gateway :
Pour fournir un accès externe aux données du jumeau numérique, nous avons déployé une API Gateway qui a été intégrée au microservice Storage Access (qui récupère et fournit les données). Il s’agit d’une solution sans serveur, entièrement intégrée à AWS Lambda pour les besoins de calcul et à Amazon Cognito pour le contrôle d’accès basé sur les utilisateurs/services.

Infrastructure OAuth 2.0 => Amazon Cognito :
La mise en œuvre d’OAuth 2.0 côté serveur n’est pas une mince affaire. Cognito offre un ensemble d’outils et de ressources qui facilitent considérablement la mise en œuvre des flux OAuth 2.0, en fournissant des points de terminaison AUTH et des jetons JWT signés aux utilisateurs/clients de service autorisés. Il est également entièrement intégré à API Gateway pour des vérifications d’authentification JWT simples, tandis que des logiques d’autorisation plus complexes peuvent être mises en œuvre à l’aide d’un Lambda Authorizer dans API Gateway.

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 à l’aide d’autorisations restreintes, définies par des documents de politique IAM associés à un rôle spécifique attribué à la fonction Lambda.

Sécurité/3 => Rôle et politiques spécifiques à Kinesis Analytics :
L’exécution de Kinesis Analytics est liée à des autorisations restreintes, exprimées par des documents de politique IAM associés à un rôle spécifique attribué à Kinesis Analytics.

Journalisation et observabilité => CloudWatch :
Tous les journaux (exécution, accès, erreurs) sont collectés par CloudWatch. Les métriques opérationnelles sont représentées graphiquement dans un tableau de bord CloudWatch spécifique, offrant un moyen simple de définir des alarmes personnalisées pour tout type d’activités DevOps.

Tout dans cette implémentation est décrit à l’aide de l’IaC et soumis à un contrôle de version dans un dépôt Git. Un pipeline CICD est associé au dépôt, assurant la construction et le déploiement automatiques de l’infrastructure à chaque nouvelle validation.