SBB Cargo 

Das Problem: Digital Twin

Unser Kunde musste die  aktuellsten Datenpunkte aus einer Vielzahl von Live-Datenanbietern extrahieren. Diese Daten werden kontinuierlich über eine Reihe von Datenpipelines erfasst (wie in diesem Blog-Artikel beschrieben). Zudem wünschte sich der Kunde, dass die aktuellsten Datenpunkte über eine HTTP-REST-API verfügbar gemacht werden. Der daraus resultierende Dienst wurde „Digital Twin“ genannt, da er die aktuellsten Daten für eine Vielzahl von Datensätzen sammelt und bereitstellt, die von physischen Objekten stammen, und sie so zu einer „digitalen Darstellung“ des Zustands dieser Objekte macht.

Technische Herausforderungen

Die Daten weisen je nach dem Dienst, von dem sie stammen, unterschiedliche Strukturen und Formate auf. Viele dieser Dienste liefern Daten nahezu in Echtzeit, die mit einer Rate von 15 Minuten bis 1 Sekunde erfasst werden. Diese Daten müssen in Echtzeit gefiltert, normalisiert und in einer Datenbank gespeichert werden, die anschliessend von den API-Nutzern abgefragt werden kann.

Eine serverlose Lösung auf Basis von AWS 

Wir wollten, dass die Lösung mit der Architektur der Datenpipelines und mit der „serverlosen Designphilosophie“ im Einklang steht, die wir gemeinsam mit dem Kunden erfolgreich umgesetzt haben.  

Ausserdem wollten wir weiterhin die von AWS bereitgestellten Tools und Managed Services nutzen. Bei der Architekturplanung haben wir darauf geachtet, eine einfache Wartung und schrittweise Erweiterungen zu ermöglichen. Die daraus resultierende Architektur ist in der folgenden Abbildung dargestellt und wurde unter Verwendung von Terraform als IaC-Tool beschrieben. 

Der Digital-Twin-Dienst nutzt die Pluggability der Daten-Streaming-Architektur voll aus: Er sammelt Daten, indem er sich an die Kinesis Streams/Firehose-Puffer anbindet, die in jeder Datenpipeline bereitgestellt werden.

Die in dieser Implementierung verwendeten Dienste sind:

– AWS Kinesis Analytics als Datenextraktionsdienst

– AWS Kinesis Stream als Datenstrom-Dienstanbieter

– AWS Lambda als Recheninfrastruktur zur Ausführung des Mikroservices für den Speicherzugriff

– Amazon DynamoDB als Persistenzschicht

– AWS API Gateway zur Bereitstellung von HTTPS-REST-Schnittstellen

– Amazon Cognito zur Bereitstellung der OAuth2-Infrastruktur

– AWS KMS als Verschlüsselungsdienst

– AWS IAM zur Definition von Richtlinien und Rollen

– AWS CloudWatch zur Bereitstellung der Protokollierungsinfrastruktur und Observability.

– Im Folgenden finden Sie eine Beschreibung der einzelnen Komponenten.

Datenextraktor => AWS Kinesis Analytics:
Sobald die Daten von den Sourcing-Workern der Pipeline abgerufen wurden, werden sie für einen konfigurierbaren Zeitraum in Kinesis Stream gepuffert und stehen so für Analysen in nahezu Echtzeit, ETL-Transformationen oder kontinuierliche Überwachung zur Verfügung. Durch die Erstellung eines Data Extractors als Kinesis-Consumer konnten wir die nahezu sofortige Datenverfügbarkeit in Kinesis und die modulare Architektur der Daten-Streaming-Dienste nutzen. Anstatt einen Kinesis-Consumer von Grund auf neu zu implementieren, haben wir uns für die Verwendung von Kinesis Analytics und dessen SQL-Funktionen entschieden. So wurde der Data Extractor zu einem einfachen Kinesis-Analytics-Job, der drei Aufgaben erfüllt: das Zuordnen von Dateneigenschaften („Data Templating“), das kontinuierliche Extrahieren einer Teilmenge davon („Data Pumping“) und die Bereitstellung einer normalisierten Ausgabe, die an den Digitaltwin-Kinesis-Stream gesendet wird („Data Delivery“). Indem wir für jede Datenpipeline einen eigenen Datenextraktor mit konsistentem Output einbinden, haben wir eine Datennormalisierung über alle Datenpipelines hinweg erreicht. All dies wurde erreicht, indem lediglich eine Kinesis Analytics Terraform-Ressource und eine Reihe von SQL-Anweisungen definiert wurden, die für jeden Extraktor in einer einzigen Datei gespeichert sind.

Digitaltwin-Stream => AWS Kinesis-Stream:
Ein Datenstrom mit kurzer Datenverfallszeit ist eine gute Wahl, um extrahierte Daten zwischenzuspeichern, während sie darauf warten, dauerhaft gespeichert (oder in zukünftigen Verbesserungen dieser Architektur weiter analysiert) zu werden. Eine gute Wahl auf AWS ist die Verwendung von Kinesis Stream.

Mikroservice für Speicherzugriff => AWS Lambda:
Wir haben AWS Lambda als Recheninfrastruktur genutzt, um einen serverlosen Microservice zu erstellen, der Daten in die Persistenzschicht schreibt und aus dieser liest. Lambda wurde aufgrund seines flexiblen Aufrufmodells ausgewählt: Der Code für den Zugriff auf die Persistenzschicht ist derselbe, unabhängig davon, welcher Dienst ihn benötigt, und er kann durch ein Kinesis-Ereignis (Daten von Extraktoren) oder durch ein API-Gateway-Ereignis (REST-API-Anfrage eines externen Verbraucherdienstes) ausgelöst werden.

Persistenzschicht => Amazon DynamoDB:
Wir mussten den aktuellsten Wert für eine bestimmte Komponentenmetrik speichern. Dieses Zugriffsmuster lässt sich effizient durch einen K-V-Speicher abdecken, wobei der Schlüssel „Component.MetricName“ lautet und der Wert die eigentliche Metrik ist (zuzüglich einiger Metadaten zur Identifizierung ihrer Herkunft). DynamoDB ist ein serverloser NoSQL-Speicher, der perfekt in dieses Szenario passt. Dank der Fähigkeit zum bedingten Schreiben lässt sich einfach sicherstellen, dass ein Schreibversuch nur mit den aktuellsten Daten erfolgreich ist. Durch seine Autoscaling-Fähigkeiten ist DynamoDB zudem in der Lage, jede beliebige Zugriffslast zu bewältigen.

HTTPs-REST-Schnittstellen => AWS API Gateway:
Um externen Zugriff auf Digital-Twin-Daten zu ermöglichen, haben wir ein API Gateway bereitgestellt, das in den Storage-Access-Mikroservice (der Daten abruft und bereitstellt) integriert wurde. Es handelt sich um eine serverlose Lösung, die vollständig in AWS Lambda für Rechenanforderungen und Amazon Cognito für die benutzer- und dienstbasierte Zugriffskontrolle integriert ist.

OAuth 2.0-Infrastruktur => Amazon Cognito:
Die serverseitige Implementierung von OAuth 2.0 ist nicht trivial. Cognito bietet eine Reihe von Tools und Ressourcen, die die Implementierung von OAuth-2.0-Abläufen erheblich vereinfachen und autorisierten Benutzern/Dienstkunden AUTH-Endpunkte sowie signierte JWT-Token bereitstellen. Es ist zudem vollständig in API Gateway integriert, was einfache JWT-Authentifizierungsprüfungen ermöglicht, während komplexere Autorisierungslogiken mithilfe eines Lambda-Authorizers in API Gateway implementiert werden können.

Sicherheit/1 => KMS:
Daten während der Übertragung und im Ruhezustand werden mithilfe von KMS mit CMKs (Customer Master Keys) mit begrenztem Geltungsbereich verschlüsselt

Sicherheit/2 => Lambda-spezifische Rolle und Richtlinien:
Lambda-Funktionen werden mit eingeschränkten Berechtigungen ausgeführt, die durch IAM-Richtliniendokumente festgelegt sind, die einer bestimmten Rolle zugeordnet sind, welche wiederum der Lambda-Funktion zugewiesen ist.

Sicherheit/3 => Kinesis Analytics-spezifische Rolle und Richtlinien:
Die Ausführung von Kinesis Analytics ist an eingeschränkte Berechtigungen gebunden, die durch IAM-Richtliniendokumente ausgedrückt werden, die einer bestimmten Rolle zugeordnet sind, welche wiederum Kinesis Analytics zugewiesen ist.

Protokollierung und Überwachbarkeit => CloudWatch:
Alle Protokolle (Ausführung, Zugriff, Fehler) werden von CloudWatch erfasst. Betriebsmetriken werden in einem spezifischen CloudWatch-Dashboard dargestellt, was eine einfache Möglichkeit bietet, benutzerdefinierte Alarme für jede Art von DevOps-Aktivitäten einzurichten.

Alles in dieser Implementierung wird mithilfe von IaC beschrieben und unterliegt der Versionskontrolle in einem Git-Repository. Eine CICD-Pipeline ist mit dem Repository verknüpft und sorgt bei jedem neuen Commit für den automatischen Aufbau und die Bereitstellung der Infrastruktur.