Architektur der Lokad-Plattform

Lokads Plattform ist eine mandantenfähige, cloudbasierte SaaS-Lösung. Diese Seite präsentiert die Architektur der Plattform auf hoher Ebene. Obwohl die Seite für ein IT-Publikum gedacht ist, könnte ein technisch versierter supply chain Praktiker diese Informationen interessant finden, da diese Architektur unsere technologische Vision für die prädiktive Optimierung von supply chains widerspiegelt.

Architekturübersicht

Lokad präsentiert sich als eine Umgebung zur Entwicklung und zum Betrieb von prädiktiven Optimierungsanwendungen, die auf supply chain Probleme ausgerichtet sind. Im Kern liegt eine domänenspezifische Sprache (DSL) namens Envision, entwickelt von Lokad. Envision ist für Endnutzer zugänglich und die meisten Funktionen werden über sie bereitgestellt. Während Envision Programmierung impliziert, richtet sich Lokad an supply chain specialists, nicht an IT-Spezialisten oder Softwareingenieure.

Die Lokad-Plattform ist mandantenfähig: dieselbe Anwendung bedient all unsere Kunden und umfasst eine kurze Reihe von Diensten. Die Granularität der Aufteilung wird hauptsächlich durch unterschiedliche Anforderungen an Zuverlässigkeit, Sicherheit und Leistung jedes Dienstes motiviert – und nicht durch eine reine funktionale Trennung. Tatsächlich ist der Kopplungsgrad zwischen diesen Diensten relativ hoch. Diese Dienste teilen sich dasselbe Git-Code-Repository und werden häufig gemeinsam aktualisiert.

Unser Code wird in F#, C# und TypeScript implementiert und hat abgesehen von .NET, einem von Microsoft entwickelten Open-Source-Framework, nur wenige Abhängigkeiten von Drittanbietern. Außerdem haben wir, abgesehen von .NET selbst, sehr wenig weitere Abhängigkeiten (etwa eine Größenordnung weniger als üblich).

Diese Architektur weicht erheblich von den „üblichen“ Architekturen ab, die in Unternehmensanwendungen zu finden sind – und das aus guten Gründen. Die gängige Unternehmensanwendung ist abhängig von schweren und umfangreichen Abhängigkeiten; jede Abhängigkeit wiegt typischerweise mehr als 1 Million Codezeilen. Lokad hingegen verzichtet auf Drittanbieterabhängigkeiten in den folgenden Bereichen:

• Relationale Datenbank: Stattdessen verwenden wir einen Event-Store zusammen mit einem Content Addressable Store.
• Caching-System: Stattdessen kombinieren wir Rechenleistung und temporären Speicher.
• Pipeline-Manager: Stattdessen verwenden wir unseren eigenen Scheduler (im Folgenden detailliert).
• Analytics-Engine: Stattdessen bietet unsere DSL namens Envision Analysefunktionen.
• Machine-Learning-Toolkit: Stattdessen bietet die DSL auch ML-Funktionen.
• Datenvisualisierungs-Toolkit: Stattdessen haben wir ein eigenes entwickelt, das eng in die DSL integriert ist.

Es sei darauf hingewiesen, dass wir, obwohl wir die Entwicklung unserer Plattform weitgehend intern vornehmen, absichtlich und ausschließlich auf Drittanbieterkomponenten für alle unsere Sicherheitskomponenten, wie kryptografische Algorithmen, setzen.

Das Frontend

Das Frontend bezieht sich auf die Elemente, die für Endnutzer zugänglich sind, einschließlich automatisierter Agenten, die verwendet werden, um Daten zu Lokad zu übertragen und von dort zu empfangen. Die meisten dieser Interaktionen erfolgen über einen Webbrowser mittels HTTPS, obwohl Lokad auch FTPS- und SFTP-Protokolle zur Übertragung von Dateien unterstützt.

go.lokad.com

Dieser Service hostet React, das Frontend-Framework der Lokad-Webapp, das als Single-Page Application (SPA) implementiert ist. Dieses Frontend hängt von den von den anderen Diensten bereitgestellten APIs (Application Programming Interfaces) ab.

Dieser Service liefert ausschließlich statische Inhalte – hauptsächlich JavaScript. Es gibt keine serverseitigen beweglichen Teile und, insbesondere, keine Datenspeicherung. Dieses Design ist absichtlich gewählt, da Uptime die höchste Priorität für diesen Service hat; egal, welcher Service über das Web aufgerufen wird, der Dienst go.lokad.com muss verfügbar sein.

Dashboards

Der Dashboards-Service, wie der Name schon sagt, ist für die Darstellung der webbasierten Analyse-Dashboards von Lokad verantwortlich.

Jedes Dashboard ist das Ergebnis eines ausgeführten Envision-Skripts. Dashboards werden umfangreich vorkomputiert, obwohl auch einige interaktive Funktionen angeboten werden. Das Design von Envision selbst stellt sicher, dass clientseitige Interaktionen unabhängig von der Größe des ursprünglichen Datensatzes als small data-Probleme bleiben.

Auf der Clientseite werden alle Daten, die für die erste Darstellung des Dashboards benötigt werden, durch eine einzige HTTPS-Anfrage abgerufen. Dieses Design mit einer Einzelanfrage dient der Minimierung von Latenzzeiten. Binäres Packen und Kompression reduzieren den Bandbreitenverbrauch.

Auf der Serverseite werden die Daten, die einem bestimmten Dashboard zugeordnet sind, vom Content Store gepackt. Auch hier ist das Packen entscheidend, um die Gesamtzahl der Netzwerk-Anfragen sehr niedrig zu halten, normalerweise unter ein halbes Dutzend – unabhängig von der Komplexität des Dashboards.

Interaktive Dashboards bieten dem Endnutzer die Möglichkeit, auf große Datensätze zuzugreifen, die über das hinausgehen, was in einen Browser übertragen und dargestellt werden könnte. Der Wechsel von einer Ansicht zur nächsten erfordert höchstens eine einzelne clientseitige Anfrage (und sehr wenige serverseitige).

Lokad vs mainstream

Das Design mit konstanter Renderzeit von Lokad unterscheidet sich von den gängigen Business-Intelligence-(BI)-Systemen und anderen analytischen Werkzeugen. Die Dashboards in solchen Tools bestehen in der Regel aus einer Liste von Kacheln, die manchmal auch als Blöcke oder Widgets bezeichnet werden. Der Standardansatz zur Handhabung dieser Kacheln sieht pro Kachel eine clientseitige Anfrage vor, gefolgt von einer unbestimmten/unguaranteten Anzahl von serverseitigen Anfragen. Leider führt dieses Design zu trägen Dashboards mit einer merklichen Verzögerung pro Kachel. Darüber hinaus dauert die vollständige Darstellung aller Kacheln des Dashboards häufig mehrere Sekunden.

Lokad behebt dieses Problem, indem der Envision-Compiler eine Pack-Strategie für die zur Darstellung des Dashboards verwendeten Daten erzeugt, was sowohl auf der Clientseite für einstellige Anfragen als auch noch weniger auf der Serverseite sorgt. Aus unserer Sicht beginnt die Performance der Dashboard-Darstellung bereits zur Kompilierzeit, mit den den Dashboards zugrunde liegenden Skripten.

Darüber hinaus verschieben die meisten analytischen Werkzeuge einen großen Teil der Berechnung, bis ein Dashboard (manchmal auch Bericht genannt) angefordert wird. Leider führt dieses Design ebenfalls zwangsläufig zu Performanceproblemen, wenn die Anzahl der gleichzeitigen Endnutzer steigt, da es einen unvermeidlichen Konflikt um die serverseitigen Rechenressourcen gibt, die gemeinsam zur Bedienung aller Endnutzer verwendet werden.

Lokad mildert dieses Problem umfassend, indem Dashboards vorkomputiert werden. Unser Design minimiert die serverseitigen Ressourcen, die – auf Endnutzeranforderung – zur Bereitstellung eines Dashboards benötigt werden, wobei der Content Store als primärer (aber beabsichtigter) Engpass für die Bereitstellung der Dashboard-Daten fungiert. Dieses Design stellt sicher, dass eine große Anzahl von Endnutzern gleichzeitig Dashboards mit minimalem Leistungsverlust erhalten kann.

Projekte

Der Projekte-Service verwaltet Skripte und Batch-Jobs (genannt Sequenzen). Dieser Service zeichnet sich durch eine Hierarchie von Projekten aus. Endnutzer, die über die entsprechenden Zugriffsrechte verfügen, können Projekte ansehen, bearbeiten und ausführen. Eine maßgeschneiderte prädiktive Optimierungsanwendung, die von Lokad implementiert wurde, beinhaltet typischerweise eine Liste von Projekten.

Beim Event Sourcing werden Benutzereingaben persistiert, wobei der hier detailliert beschriebene Event Store genutzt wird. Jeder einzelne Befehl oder jede Interaktion, die an den Service gesendet wird, wird protokolliert und in ein daraus resultierendes Ereignis umgewandelt. Die Benutzeroberfläche zeigt den Zustand an, der durch Zusammenführen aller Ereignisse ermittelt wurde. Dieser Ansatz ist als CQRS+ES-Muster bekannt. CQRS steht für Command and Query Responsibility Segregation, während ES für Event Source steht.

Das CQRS+ES-Muster ermöglicht per Design eine vollständige Historisierung aller in der Anwendung vorgenommenen Änderungen. Im spezifischen Fall von Lokad bietet es eine Git-ähnliche Versionsverwaltung aller jemals an den Envision-Skripten vorgenommenen Änderungen, die im Konto existieren.

Lokad vs mainstream

Bezüglich UI und UX folgt der Projekte-Service dem klassischen Ansatz. Im Hintergrund wird jedoch das CQRS+ES-Muster als Alternative zum CRUD (Create, Read, Update, Delete)-Ansatz verwendet, der bei den meisten Unternehmensanwendungen zum Einsatz kommt. Dieses Muster ersetzt die relationale Datenbank durch einen Event Store (unten näher erläutert).

Der CQRS+ES-Ansatz bietet viele Vorteile gegenüber dem CRUD-Muster. Zum Beispiel bietet er überlegene Semantik, bessere Nachvollziehbarkeit und – im Fall von Lokad – eine überlegene Performance, da er uns erlaubt, die Persistenzstrategie zur Speicherung und zum Abruf des Envision-Quellcodes umfassend anzupassen. Tatsächlich besteht der Großteil der vom Projekte-Service zu persistierenden Daten aus Envision-Quellcode.

Code

Der Code-Service bietet eine IDE (Integrated Development Environment), die der Envision-Sprache gewidmet ist. Diese webbasierte IDE verfügt über alle Funktionen und Features, die man von einer modernen Entwicklungsumgebung erwartet, wie z.B. Syntax-Hervorhebung, Autovervollständigung und eine Reihe von Code-Aktionen (z.B. Umbenennung von Variablen), die durch statische Code-Analyse ermöglicht werden.

Der Großteil der Komplexität des Code-Services liegt in seinem Language Server-Backend, das Echtzeit-Feedback bietet: Hinweise für Autovervollständigungen, Fehler oder Code-Aktionen bei jedem Tastendruck. Insbesondere besteht eine der wesentlichen technischen Herausforderungen darin, eine niedrige Latenz für diese Funktion sicherzustellen, da Verzögerungen bei der normalen Tasteninteraktion ziemlich auffallen würden.

Dateien

Jeder Account bei Lokad hat seinen eigenen Speicherplatz zur Ablage von Dateien. Der Dateien-Service verfügt über ein verteiltes, versioniertes Dateisystem, das zur Verwaltung der Dateien verwendet wird. Auf dieses Dateisystem kann über eine Weboberfläche sowie die SFTP- und FTPS-Protokolle zugegriffen werden. Konzeptionell ähnelt dieses Dateisystem weitgehend einem Git-Repository, mit dem Unterschied, dass es für gigabyte-große flat files vorgesehen ist.

Die Dateiversionierung wird durch das CQRS+ES-Muster gewährleistet, welches die Darstellung einer Folge von „Commits“, die die Entwicklung des Dateisystems widerspiegeln, ergänzt. Die Persistenz des Datei-Inhalts wird durch einen Content Addressable Store sichergestellt (unten näher erläutert).

Durch die Versionierung sowohl des Codes (Envision-Skripte) als auch der Daten bietet Lokad eine vollständige Reproduzierbarkeit vergangener Abläufe für die supply chain Apps, die auf seiner Plattform eingesetzt werden. Aus supply chain Sicht ist diese Fähigkeit wichtig, um sicherzustellen, dass jedes anomale Ergebnis, das von der supply chain App erzeugt wird, analysiert werden kann.

Lokad vs mainstream

Der Dateien-Service ist eng in die Envision-Sprache integriert (was Korrektheitsvorteile bietet), in die Envision-IDE (die Produktivitätsvorteile bietet) und in die Envision-Laufzeitumgebung (die Performancevorteile bietet). Diese Vorteile wären mit einem allgemeinen Dateisystem, einer Software, die in erster Linie als Begleiter des Kernels dient, nur schwer zu erreichen.

Darüber hinaus werden viele der Vorteile des Dateien-Service dadurch erreicht, dass er weniger leistet als ein allgemeines Dateisystem. Beispielsweise erlaubt der Dateien-Service nicht, dass eine Datei gleichzeitig von mehreren Prozessen aktualisiert wird. Solche Funktionen führen im spezifischen Kontext von supply chain Apps dazu, dass supply chain Praktiker IT-zentrierten Problemen und Komplexitäten ausgesetzt werden, ohne dass hierfür ein Mehrwert entsteht.

Accounts

Das Identity and Access Management (IAM) des Accounts-Service ist einer der gängigsten Teile von Lokad. Es verwaltet die Lokad-Accounts, die Lokad-Nutzer, die Authentifizierung (idealerweise delegated authentication) und die ACL (Access Control List), die steuert, was Nutzer mit einem Lokad-Account tun dürfen oder nicht.

Dieser Service nutzt ebenfalls das CQRS+ES-Muster, das vollständige Audit-Logs aller IAM-Operationen bietet – Operationen, die aufgrund der Natur von IAM immer sicherheitsrelevant sind. Die Verwendung der Event Source als Audit-Log beseitigt zudem ganze Klassen von Sicherheitsproblemen, wie z.B. das Kompromittieren des Audit-Logs, weil bestimmte Ereignisse nicht aufgezeichnet wurden.

Die Persistenzschicht

Die Persistenzschicht stellt, wie der Name vermuten lässt, die Speicherung aller von Lokad verwalteten Daten sicher. Diese Daten kommen in zwei verschiedenen Formen: zum einen die Dateien – entweder von Kunden zu Lokad hochgeladen oder durch Envision-Skripte generiert; zum anderen die Ereignisse, die aus Benutzeroperationen resultieren (einschließlich automatisierter Agenten, wie einem Datei-Upload-Skript). Lokad speichert beide Datenformen über Azure Blob Storage, das als Key-Value-Store fungiert.

Event Store

Der Event Store speichert die von allen Lokad-Plattformdiensten erzeugten Ereignisse. Dieser Store repräsentiert die Zustandsübergangs-Datenbank von Lokad. Wir haben den Quellcode unseres Event Store als Open Source veröffentlicht.

Diese Komponente ist einfach: Sie speichert und liefert nur Ereignisse, und zwar zuverlässig, indem sie einen zugrunde liegenden verteilten Key-Value-Store (Azure Blob Storage) nutzt. Die Ereignisse sollen klein sein – begrenzt auf 512kB, typischerweise jedoch weniger als 1kB.

Es gibt keine „intelligenten“ Funktionen wie Streaming-Analytics oder Management von Projektionen. Wiederum entfernt Lokad, indem weniger getan wird, ganze Klassen von Problemen, wie z.B. SQL-Injection-Angriffe, die sich aus den Möglichkeiten der Persistenzschicht ergeben.

Content Addressable Store

Der Content Addressable Store (CAS) speichert die Dateien, die entweder zur Lokad-Plattform hochgeladen oder durch Envision-Skripte generiert wurden. Wir haben den Quellcode unseres Content Addressable Storage als Open Source veröffentlicht.

Der CAS ist dafür ausgelegt, große Dateien zu unterstützen, typischerweise von mehreren MB, mit einem oberen Limit von 100GB. Der CAS wird genutzt, um Dateien oder Dateifragmenten zu speichern, die nach einer spaltenorientierten Speicherstrategie zerlegt werden. Die spaltenorientierte Speicherung ist an das Zugriffsmuster der Ausführungsschicht angepasst.

Die Ausführungsschicht

Wie der Name schon sagt, stellt die Ausführungsschicht die Ausführung von Envision-Skripten innerhalb der Lokad-Plattform sicher und umfasst eine Reihe von Komponenten. Der Einfachheit halber listen wir hier nur die bemerkenswertesten auf. Der Compiler wandelt Envision-Skripte in Anweisungen um, die für eine verteilte virtuelle Maschine bestimmt sind. Der Scheduler ist ein Dienst, der dazu dient, Envision-Skripte auszulösen, zu planen und zu sequenzieren. Thunks ist der Codename für die Envision-Virtual Machine. Schließlich ist Ionic der Name der spaltenorientierten Speicherstrategie, die von der Envision-Virtual Machine erzeugt und genutzt wird.

Compiler

Der Compiler wandelt Envision-Skripte in Bytecode um, der für die verteilte virtuelle Maschine der Lokad-Plattform – genannt „Thunks“ (siehe unten) – bestimmt ist. Die Architektur dieses Compilers folgt gängigen Design-Praktiken: einer Kompilierungspipeline, die mit dem Parsen beginnt, gefolgt von einer Reihe von Transformationen von einer internen Repräsentation zur nächsten, und schließlich in der Erzeugung von Bytecode mündet.

Das Backend des Sprachservers, das die Interaktionen mit dem Envision-Quellcode (siehe the Code service, above) leitet, ist ebenfalls Teil des Compilers. Der Sprachserver ist zustandsbehaftet, um dem Envision-Programmierer während des Codierens sinnvolles Feedback und Fehlermeldungen zu liefern. Nach den meisten Tastaturanschlägen ist das Skript (noch) kein gültiges Envision-Skript, aber dank des Zustands des Sprachservers wird dennoch sinnvolles Feedback bereitgestellt.

Scheduler

Der Scheduler ist ein Hilfsdienst zur Ausführung von Envision-Skripten ohne manuelle Eingriffe. Der Scheduler löst die Ausführung von Envision-Skripten aus, plant sie und ordnet sie in einer Reihenfolge an. Er bietet zudem Alarmierungsfunktionen, falls die Ausführungen von den erwarteten Zeitplänen abweichen. Die enge Integration des Schedulers mit dem Rest der Plattform bietet eine Reihe von wünschenswerten Funktionen, wie z. B. Dateiänderungstrigger (um Envision-Skripte beim Eintreffen von Dateien zu starten) oder die frühzeitige Erkennung eines drohenden Ausfalls (falls eines der Envision-Skripte innerhalb einer Sequenz nicht kompiliert).

Thunks

Thunks ist der Codename für Lokads verteilte virtuelle Maschine. Tatsächlich profitieren Envision-Skripte von Haus aus von einer verteilten Ausführung. In diesem Sinne zielt der Envision-Compiler nicht auf eine einzelne Maschine, sondern auf einen Cluster von ihnen ab. Diese Funktion ist entscheidend für die zeitgerechte Verarbeitung großer Datensätze. Die Envision-Sprache wurde speziell für die automatische Parallelisierung entwickelt (eine Funktion, die mit einer allgemeinen Programmiersprache sehr schwer zu erreichen ist). Nebenbei bietet der Cluster auch eine höhere Zuverlässigkeit bei der Ausführung von Skripten, falls eine Maschine nicht reagiert.

Der Maschinencluster, der Thunks zugeordnet ist, wird in Multi-Mandanten-Nutzung über alle Konten hinweg gemeinsam genutzt. Diese Funktion ist wesentlich, um die Rechenkosten unter Kontrolle zu halten. Der typische supply chain-Anwendungsfall umfasst einen Ausführungsdurchlauf pro Tag, der in der Regel weniger als 60 Minuten dauert. Durch die Zusammenlegung der Ressourcen mittels Multi-Mandantenbetrieb wird der mit Rechenressourcen verbundene Overhead weitgehend ausgeglichen – ein Kostenfaktor, der ansonsten in 24-Stunden-Zeiträumen berechnet würde, während tatsächlich nur eine Stunde (möglicherweise weniger) genutzt wird.

Für eine umfassende Erklärung empfehlen wir die 4-teilige Serie von Victor Nicollet über das Design der Envision Virtual Machine, und für Antworten auf die häufigsten leistungsbezogenen Fragen zu Lokad empfehlen wir Abschnitt 8 unserer Security FAQ.