SBB Cargo – Digital Twin Service

Il problema: Digital Twin

Il nostro cliente aveva bisogno di estrarre i dati più recenti da una vasta gamma di fornitori di dati in tempo reale. Questi dati vengono acquisiti continuamente attraverso una serie di pipeline di dati (come descritto in questo articolo del blog). Inoltre, il cliente desiderava che i dati più recenti fossero resi disponibili tramite un’API HTTP REST. Il servizio risultante è stato denominato «Digital Twin», poiché raccoglie ed espone i dati più recenti per un’ampia gamma di set di dati provenienti da oggetti fisici, rendendoli una «rappresentazione digitale» degli stati degli oggetti.

Sfide tecniche

I dati hanno strutture e formati diversi, a seconda del servizio da cui provengono. Molti di questi servizi forniscono dati quasi in tempo reale, acquisiti con una frequenza che varia da 15 minuti a 1 secondo. Questi dati devono essere filtrati in tempo reale, normalizzati e memorizzati in un database che possa essere successivamente interrogato dagli utenti dell’API.

Una soluzione serverless basata su AWS 

Volevamo che la soluzione fosse coerente con l’architettura delle pipeline di dati e con la «filosofia di progettazione serverless» che abbiamo adottato con successo insieme al cliente.

Volevamo inoltre continuare a utilizzare gli strumenti e i servizi gestiti forniti da AWS. Durante la progettazione architettonica, abbiamo prestato attenzione a consentire una facile manutenzione ed estensioni incrementali. L’architettura risultante è illustrata nella figura seguente ed è stata descritta utilizzando Terraform come strumento IaC.

Il servizio Digital Twin sfrutta appieno la pluggability dell’architettura di streaming dei dati: raccoglie i dati collegandosi ai buffer Kinesis Streams/Firehose che sono distribuiti in ogni pipeline di dati.

I servizi utilizzati in questa implementazione sono:

– AWS Kinesis Analytics come servizio di estrazione dati

– AWS Kinesis Stream come fornitore di servizi di streaming dati

– AWS Lambda come infrastruttura di calcolo per l’esecuzione del microservizio di accesso allo storage

– Amazon DynamoDB come livello di persistenza

– AWS API Gateway per fornire interfacce REST HTTPs

– Amazon Cognito per fornire l’infrastruttura OAuth2

– AWS KMS come servizio di crittografia

– AWS IAM per la definizione di policy e ruoli

– AWS CloudWatch per fornire l’infrastruttura di registrazione e l’osservabilità.

Di seguito è riportata la descrizione di ciascun componente.

Data Extractor => AWS Kinesis Analytics:
Una volta che i dati vengono recuperati dai worker di sourcing della pipeline, vengono bufferizzati per un periodo di tempo configurabile in Kinesis Stream, rendendoli disponibili per analisi quasi in tempo reale, trasformazioni ETL o monitoraggio continuo. Creando un Data Extractor come consumatore Kinesis, siamo stati in grado di sfruttare la disponibilità quasi istantanea dei dati in Kinesis e l’architettura modulare dei servizi di streaming dei dati. Invece di implementare un consumatore Kinesis da zero, abbiamo optato per l’utilizzo di Kinesis Analytics e delle sue funzionalità SQL. Pertanto, l’estrattore di dati è diventato un semplice processo di Kinesis Analytics che svolge 3 funzioni: mappare le proprietà dei dati («data templating»), estrarne continuamente un sottoinsieme («data pumping») e fornire un output normalizzato che viene inviato al Kinesis Stream di Digitaltwin («data delivery»). Collegando un estrattore di dati diverso per ogni pipeline di dati con un output coerente, abbiamo ottenuto la normalizzazione dei dati in tutte le pipeline. Tutto questo è stato fatto semplicemente definendo una risorsa Terraform di Kinesis Analytics e una serie di istruzioni SQL salvate in un unico file per ogni estrattore.

Digitaltwin stream => AWS Kinesis Stream:
Un flusso di dati con scadenza breve è una buona scelta per mettere in buffer i dati estratti in attesa di essere persistiti (o ulteriormente analizzati in futuri miglioramenti di questa architettura). Una buona scelta su AWS è utilizzare Kinesis Stream.

Microservizio di accesso allo storage => AWS Lambda:
Abbiamo utilizzato AWS Lambda come infrastruttura di calcolo per creare un microservizio serverless che scrive e legge i dati da/verso il livello di persistenza. Lambda è stato scelto come ” ” per via del suo modello di invocazione flessibile: il codice per accedere al livello di persistenza è lo stesso indipendentemente dal servizio che ne ha bisogno e può essere attivato da un evento Kinesis (dati provenienti dagli estrattori) o da un evento API Gateway (richiesta API REST da parte di un servizio consumer esterno).

Livello di persistenza => Amazon DynamoDB:
Avevamo bisogno di memorizzare il valore più recente per una data metrica del componente. Questo modello di accesso può essere gestito in modo efficiente da un archivio K-V, dove la chiave è Component.MetricName e il valore è la metrica effettiva (più alcuni metadati per identificarne la provenienza). DynamoDB è un archivio NoSQL serverless che si adatta perfettamente a questo scenario. Grazie alla funzionalità di scrittura condizionale, è semplice garantire che un tentativo di scrittura abbia esito positivo solo con i dati più recenti. Grazie alle funzionalità di autoscaling, DynamoDB è anche in grado di assorbire qualsiasi carico di accesso.

Interfacce REST HTTPs => AWS API Gateway:
Per fornire accesso esterno ai dati del Digital Twin, abbiamo implementato un API Gateway integrato con il microservizio Storage Access (che recupera e fornisce i dati). Si tratta di una soluzione serverless, completamente integrata con AWS Lambda per le esigenze di elaborazione e Amazon Cognito per il controllo degli accessi basato su utente/servizio.

Infrastruttura OAuth 2.0 => Amazon Cognito:
L’implementazione di OAuth 2.0 sul lato server non è banale. Cognito offre una serie di strumenti e risorse che rendono molto più semplice l’implementazione dei flussi OAuth 2.0, fornendo endpoint AUTH e token JWT firmati agli utenti/clienti del servizio autorizzati. È inoltre completamente integrato con API Gateway per semplici controlli di autenticazione JWT, mentre logiche di autorizzazione più complesse possono essere implementate utilizzando un Lambda Authorizer in API Gateway.

Sicurezza/1 => KMS:
I dati in transito e inattivi vengono crittografati utilizzando KMS con CMK (Customer Master Keys) a ambito limitato

Sicurezza/2 => Ruolo e politiche specifici per Lambda:
Le funzioni Lambda vengono eseguite utilizzando autorizzazioni con ambito ridotto, espresse tramite documenti di policy IAM associati a un ruolo specifico assegnato alla funzione Lambda.

Sicurezza/3 => Ruolo e politiche specifici di Kinesis Analytics:
L’esecuzione di Kinesis Analytics è collegata a permessi con ambito ridotto, espressi tramite documenti di policy IAM associati a un ruolo specifico assegnato a Kinesis Analytics.

Registrazione e osservabilità => CloudWatch:
Tutti i log (esecuzione, accesso, errori) vengono raccolti da CloudWatch. Le metriche operative vengono tracciate in una dashboard CloudWatch specifica, fornendo un modo semplice per impostare allarmi personalizzati per qualsiasi tipo di attività DevOps.

Tutto in questa implementazione è descritto utilizzando IaC ed è sotto controllo di versione in un repository git. Una pipeline CICD è collegata al repository, fornendo la creazione e la distribuzione automatica dell’infrastruttura ad ogni nuovo commit.