Architektur der Lokad-Plattform

Die Plattform von Lokad ist eine mandantenfähige Cloud-basierte SaaS-Lösung. Diese Seite stellt die Architektur der Plattform auf hoher Ebene vor. Obwohl die Seite für ein IT-Publikum gedacht ist, könnte auch ein technisch versierter Supply-Chain-Praktiker diese Informationen interessant finden, da diese Architektur unsere technologische Vision für die prädiktive Optimierung von Lieferketten widerspiegelt.

Architekturübersicht

Lokad präsentiert sich als Umgebung zur Entwicklung und Betrieb von prädiktiven Optimierungs-Apps für Probleme in der Lieferkette. Im Kern liegt eine domänenspezifische Sprache (DSL) namens Envision, die von Lokad entwickelt wurde. Envision ist für Endbenutzer zugänglich und die meisten Funktionen werden über sie bereitgestellt. Während Envision Programmierung impliziert, ist Lokad für Supply-Chain-Spezialisten gedacht, nicht für IT-Spezialisten oder Softwareentwickler.

Die Lokad-Plattform ist mandantenfähig: Die gleiche App bedient alle unsere Kunden und umfasst eine kurze Reihe von Diensten. Die Granularität der Aufteilung wird in erster Linie durch unterschiedliche Anforderungen an Zuverlässigkeit, Sicherheit und Leistung jedes Dienstes motiviert - nicht durch eine reine funktionale Aufteilung. Tatsächlich ist das Maß an Kopplung, das zwischen diesen Diensten besteht, relativ hoch. Diese Dienste teilen sich das gleiche Git-Code-Repository und werden auch häufig gemeinsam aktualisiert.

Unser Codebase ist in F#, C# und TypeScript implementiert und hat nur wenige Abhängigkeiten von Drittanbietern außer .NET, einem von Microsoft entwickelten Open-Source-Framework. Abgesehen von .NET selbst haben wir nur sehr wenige andere Abhängigkeiten (ungefähr eine Größenordnung weniger als der Durchschnitt).

Diese Architektur weicht stark von den “üblichen” Architekturen ab, die in Unternehmensanwendungen zu finden sind - und das aus gutem Grund. Die übliche Unternehmensanwendung hängt von umfangreichen und umfangreichen Abhängigkeiten ab; jede Abhängigkeit wiegt in der Regel mehr als 1 Million Zeilen Code. Lokad hingegen hat in den folgenden Bereichen keine Abhängigkeiten von Drittanbietern:

• Relationale Datenbank: Stattdessen verwenden wir ein Ereignisspeicher zusammen mit einem inhaltsadressierbaren Speicher.
• Caching-System: Stattdessen kollokalisieren wir Berechnungen und transienten Speicher.
• Pipeline-Manager: Stattdessen haben wir unseren eigenen Scheduler (unten detailliert beschrieben).
• Analyse-Engine: Stattdessen bietet unsere DSL namens Envision Analysefunktionen.
• Machine-Learning-Toolkit: Stattdessen bietet die DSL auch ML-Funktionen.
• Data-Visualisierungs-Toolkit: Stattdessen haben wir unser eigenes Toolkit mit enger DSL-Integration entwickelt.

Es sollte beachtet werden, dass wir zwar die Entwicklung unserer Plattform umfassend internalisieren, uns jedoch absichtlich und ausschließlich auf Komponenten von Drittanbietern für alle unsere Sicherheitskomponenten verlassen, wie kryptografische Algorithmen.

Das Front-End

Das Front-End bezieht sich auf die Elemente, die für Endbenutzer zugänglich sind, einschließlich automatisierter Agenten, die Daten zu und von Lokad verschieben. Die meisten dieser Interaktionen erfolgen über einen Webbrowser über HTTPS, obwohl Lokad auch die Protokolle FTPS und SFTP zum Verschieben von Dateien unterstützt.

go.lokad.com

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

Dieser Dienst dient ausschließlich statischem Inhalt - hauptsächlich JavaScript. Es gibt keine serverseitigen beweglichen Teile und insbesondere keine Datenpersistenz. Dieses Design ist beabsichtigt, da Verfügbarkeit die größte Priorität für diesen Dienst ist; unabhängig davon, auf welchen Dienst über das Web zugegriffen wird, muss der Dienst go.lokad.com verfügbar sein.

Dashboards

Der Dashboards-Dienst kümmert sich, wie der Name schon sagt, um die Darstellung der von Lokad bereitgestellten webbasierten Analyse-Dashboards.

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

Clientseitig werden alle für das erste Rendern des Dashboards benötigten Daten über eine einzelne HTTPS-Anfrage abgerufen. Dieses Design mit einer einzelnen Anfrage dient dazu, die Latenzzeiten zu minimieren. Die binäre Verpackung und Komprimierung minimieren den Bandbreitenverbrauch.

Serverseitig wird die mit einem bestimmten Dashboard verbundene Daten von dem Content Store verpackt. Auch hier ist die Verpackung entscheidend, um die Gesamtzahl der Netzwerkanfragen sehr niedrig zu halten, normalerweise unter einem halben Dutzend - unabhängig von der Komplexität des Dashboards.

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

Lokad vs Mainstream

Das Design der konstanten Renderzeit von Lokad unterscheidet sich von Mainstream-Business-Intelligence (BI) und anderen Analysetools. Die Dashboards, die man in solchen Tools findet, bestehen in der Regel aus einer Liste von Kacheln, manchmal auch Blöcke oder Widgets genannt. Der Standardweg, um mit diesen Kacheln umzugehen, beinhaltet 1 clientseitige Anfrage pro Kachel, gefolgt von einer nicht spezifizierten/ungarantierten Anzahl von serverseitigen Anfragen. Leider führt dieses Design zu träge reagierenden Dashboards mit einer spürbaren Verzögerung für jede Kachel. Darüber hinaus dauert die vollständige Anzeige aller Kacheln des Dashboards häufig mehrere Sekunden.

Lokad löst dieses Problem, indem der Envision-Compiler eine Verpackungsstrategie der Daten erstellt, die zur Darstellung des Dashboards verwendet werden, und somit sowohl eine einstellige Anzahl von Anfragen auf der Clientseite als auch noch weniger auf der Serverseite gewährleistet. Aus unserer Sicht beginnt die Leistung der Dashboards bereits zur Kompilierungszeit mit den Skripten, die den Dashboards zugrunde liegen.

Darüber hinaus verschieben die meisten Analysetools einen großen Teil der Berechnung, bis ein Dashboard (manchmal auch Bericht genannt) angefordert wird. Leider führt das Design auch unweigerlich zu Leistungsproblemen, wenn die Anzahl der gleichzeitigen Endbenutzer zunimmt, da es einen unvermeidlichen Konflikt um die serverseitigen Rechenressourcen gibt, die gemeinsam genutzt werden, um alle Endbenutzer zu bedienen.

Lokad mildert dieses Problem umfassend, indem Dashboards vorab berechnet werden. Unser Design minimiert die serverseitigen Ressourcen, die - auf Nachfrage des Endbenutzers - benötigt werden, um ein Dashboard zu bedienen, und lässt den Content Store als primären (aber beabsichtigten) Engpass zur Bereitstellung der Dashboard-Daten. Dieses Design stellt sicher, dass eine große Anzahl von Endbenutzern gleichzeitig Dashboards mit minimaler Leistungseinbuße bedient werden können.

Projekte

Der Projektdienst verwaltet Skripte und Stapeljobs (sogenannte Sequenzen). Dieser Dienst verfügt über eine Hierarchie von Projekten. Endbenutzer, die über die entsprechenden Zugriffsrechte verfügen, können Projekte anzeigen, bearbeiten und ausführen. Eine maßgeschneiderte prädiktive Optimierungs-App, die von Lokad implementiert wird, enthält in der Regel eine Liste von Projekten.

Event Sourcing wird verwendet, um Benutzereingaben dauerhaft zu speichern und dabei den hier detaillierten Event Store zu nutzen. Jeder einzelne Befehl oder jede Interaktion, die an den Dienst gesendet wird, wird protokolliert und in ein resultierendes Ereignis umgewandelt. Die Benutzeroberfläche stellt den Zustand dar, der durch Zusammenfassen aller Ereignisse erhalten wird. Dieser Ansatz wird als CQRS+ES-Muster bezeichnet. CQRS steht für Command and Query Responsibility Segregation, während ES für Event Source steht.

Das CQRS+ES-Muster bietet von Design her eine vollständige Historisierung aller Änderungen, die in der Anwendung vorgenommen wurden. Im speziellen Fall von Lokad bietet es eine Git-ähnliche Versionierung aller jemals auf die Envision-Skripte angewendeten Änderungen, die im Konto vorhanden sind.

Lokad vs Mainstream

In Bezug auf UI und UX folgt der Projektdienst dem Mainstream-Ansatz. Unter der Oberfläche wird jedoch das CQRS+ES-Muster als Alternative zum CRUD (Create, Read, Update, Delete) verwendet, das für die meisten Unternehmenssoftwarelösungen verwendet wird. Dieses Muster ersetzt die relationale Datenbank durch einen Event Store (unten diskutiert).

Der CQRS+ES-Ansatz bietet viele Vorteile gegenüber dem CRUD-Muster. Zum Beispiel bietet er überlegene Semantik, überlegene Nachvollziehbarkeit und im Fall von Lokad eine überlegene Leistung, da er uns ermöglicht, die Persistenzstrategie zur Speicherung und Abfrage von Envision-Quellcode umfassend anzupassen. Tatsächlich besteht der Großteil der zu speichernden Daten des Projektdienstes aus Envision-Quellcode.

Code

Der Code-Dienst verfügt über eine integrierte Entwicklungsumgebung (IDE) für die Envision-Sprache. Diese webbasierte IDE bietet alle Funktionen und Funktionalitäten, die von einer modernen Entwicklungsumgebung erwartet werden, wie z.B. Code-Färbung, Autovervollständigung und eine Reihe von Code-Aktionen (z.B. Variablenumbenennung), die durch statische Code-Analyse ermöglicht werden.

Der Großteil der Komplexität des Code-Dienstes liegt in seinem Backend des Language Servers, der Echtzeit-Feedback bietet: Hinweise für Autovervollständigungen, Fehler oder Code-Aktionen bei jedem Tastendruck. Insbesondere besteht eine der wichtigsten technischen Herausforderungen darin, eine geringe Latenz für diese Funktion aufrechtzuerhalten, da Verzögerungen bei der Betrachtung des normalen Tastaturinteraktionsrhythmus recht bemerkbar wären.

Dateien

Jedes Konto bei Lokad hat seinen eigenen Speicherplatz für Dateien. Der Dateidienst verfügt über ein verteiltes, versioniertes Dateisystem, das zur Verwaltung seiner Dateien verwendet wird. Auf dieses Dateisystem kann über eine Web-Benutzeroberfläche sowie über die SFTP- und FTPS-Protokolle zugegriffen werden. Konzeptionell ähnelt dieses Dateisystem weitgehend einem Git-Repository, mit der Ausnahme, dass es für gigabytegroße Flachdateien vorgesehen ist.

Die Versionierung der Dateien wird durch das CQRS+ES-Muster sichergestellt, das die Darstellung einer Sequenz von “Commits” ergänzt, die die Entwicklung des Dateisystems selbst widerspiegeln. Die Persistenz des Dateiinhalts wird durch einen inhaltsadressierbaren Speicher sichergestellt (unten diskutiert).

Durch die Versionierung sowohl des Codes (Envision-Skripte) als auch der Daten bietet Lokad eine vollständige Reproduzierbarkeit vergangener Verhaltensweisen für die auf seiner Plattform bereitgestellten Supply Chain-Anwendungen. Aus Sicht der Supply Chain ist diese Fähigkeit wichtig, um sicherzustellen, dass jedes anomale Ergebnis, das von der Supply Chain-Anwendung generiert wird, behoben werden kann.

Lokad vs Mainstream

Der Datei-Dienst ist eng mit der Envision-Sprache (die Vorteile in Bezug auf Korrektheit bietet), der Envision-IDE (die Vorteile in Bezug auf Produktivität bietet) und der Envision-Laufzeit (die Vorteile in Bezug auf Leistung bietet) integriert. Diese Vorteile wären schwer zu erreichen mit einem allgemeinen Dateisystem, das in erster Linie ein Begleiter des Kernels ist.

Darüber hinaus werden viele der Vorteile des Datei-Dienstes durch das Vermeiden von Funktionen eines allgemeinen Dateisystems erzielt. Zum Beispiel erlaubt der Datei-Dienst nicht, dass eine Datei gleichzeitig von mehreren Prozessen aktualisiert wird. Solche Funktionen würden im spezifischen Kontext von Supply Chain-Anwendungen nur Supply Chain-Praktikern IT-zentrische Probleme und Komplexitäten aussetzen, ohne einen Mehrwert zu bieten.

Konten

Das Identity and Access Management (IAM) des Konto-Dienstes ist einer der Mainstream-Teile von Lokad. Es verwaltet die Lokad-Konten, die Lokad-Benutzer, die Authentifizierung (idealerweise delegierte Authentifizierung) und die ACL (Access Control List), die steuert, was Benutzer mit einem Lokad-Konto tun können oder nicht.

Dieser Dienst nutzt auch das CQRS+ES-Muster, das vollständige Audit-Logs aller IAM-Operationen bietet - Operationen, die aufgrund der Natur von IAM immer sicherheitssensitiv sind. Die Verwendung der Ereignisquelle als Audit-Log entfernt auch ganze Klassen von Sicherheitsproblemen, wie z.B. das Kompromittieren des Audit-Logs durch das Nichtaufzeichnen ausgewählter Ereignisse.

Die Persistenzschicht

Die Persistenzschicht stellt, wie der Name schon sagt, die Persistenz aller von Lokad verwalteten Daten sicher. Diese Daten kommen in zwei verschiedenen Varianten vor: erstens die Dateien - entweder von Kunden auf Lokad hochgeladen oder durch Envision-Skripte generiert; zweitens die Ereignisse, die aus Benutzeroperationen resultieren (einschließlich automatisierter Agenten wie einem Datei-Upload-Skript). Lokad persistiert beide Datenvarianten über Azure Blob Storage, das als Key-Value-Store fungiert.

Ereignisspeicher

Der Ereignisspeicher speichert die Ereignisse, die von allen Diensten der Lokad-Plattform generiert werden. Dieser Speicher repräsentiert die Zustandsübergangsdatenbank von Lokad. Wir haben den Quellcode unseres Ereignisspeichers als Open Source veröffentlicht.

Diese Komponente ist einfach: Sie speichert und liefert Ereignisse auf zuverlässige Weise und nutzt dabei einen verteilten Key-Value-Store (Azure Blob Storage). Die Ereignisse sollen klein sein - auf 512 kB begrenzt, aber in der Regel weniger als 1 kB.

Es gibt keine “intelligenten” Funktionen wie Streaming-Analytics oder Projections-Management. Auch hier entfernt Lokad durch das Vermeiden von Funktionen ganze Klassen von Problemen, wie z.B. SQL-Injection-Angriffe, die aufgrund der Fähigkeiten der Persistenzschicht entstehen.

Inhaltsadressierbarer Speicher

Der inhaltsadressierbare Speicher (CAS) speichert die Dateien, die entweder auf die Lokad-Plattform hochgeladen oder durch die Envision-Skripte generiert werden. Wir haben den Quellcode unseres inhaltsadressierbaren Speichers als Open Source veröffentlicht.

Der CAS ist für große Dateien vorgesehen, typischerweise mehrere MB groß, mit einer Obergrenze von 100 GB. Der CAS wird verwendet, um Dateien oder Dateifragmente zu speichern, die nach einer spaltenorientierten Speicherstrategie geschardet sind. Der spaltenorientierte Speicher ist auf das Zugriffsmuster der Ausführungsschicht abgestimmt.

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. Um die Kürze willen werden wir hier nur die bemerkenswertesten auflisten. Der Compiler wandelt Envision-Skripte in Anweisungen um, die für eine verteilte virtuelle Maschine bestimmt sind. Der Scheduler ist ein Hilfsdienst zum Auslösen, Planen und Sequenzieren von Envision-Skripten. Thunks ist der Codename für die Envision-Virtual Machine. Schließlich ist Ionic der Name für die spaltenorientierte Speicherstrategie, die von der Envision-Virtual Machine erzeugt und verwendet wird.

Compiler

Der Compiler wandelt Envision-Skripte in Bytecode um, der für die verteilte virtuelle Maschine der Lokad-Plattform - namens “Thunks” (siehe unten) - bestimmt ist. Die Architektur dieses Compilers folgt gängigen Designpraktiken: eine Kompilationspipeline, die mit dem Parsen beginnt, gefolgt von einer Reihe von Transformationen von einer internen Repräsentation zur nächsten, endend mit der Erzeugung von Bytecode.

Der Language Server Backend, der die Interaktionen mit dem Envision-Quellcode (siehe oben den Code-Service) steuert, ist ebenfalls Teil des Compilers. Der Language Server ist zustandsbehaftet, um dem Envision-Programmierer während des Codierens sinnvolles Feedback und Fehlermeldungen zu liefern. Nach den meisten Tastenanschlägen ist das Skript noch kein gültiges Envision-Skript, aber dank des Zustands des Language Servers wird dennoch sinnvolles Feedback bereitgestellt.

Scheduler

Der Scheduler ist ein Hilfsdienst zum Ausführen von Envision-Skripten ohne manuelle Eingriffe. Der Scheduler löst, plant und sequenziert die Ausführung von Envision-Skripten aus. Er bietet auch Alarmierungsfunktionen, wenn die Ausführungen von ihren erwarteten Zeitplänen abweichen. Die enge Integration des Schedulers mit dem Rest der Plattform bietet eine Reihe von wünschenswerten Funktionen, wie z.B. Trigger für Dateiänderungen (um Envision-Skripte beim Empfang von Dateien zu starten) oder die frühzeitige Erkennung von anstehenden Fehlern (wenn eines der Envision-Skripte in einer Sequenz nicht kompiliert).

Thunks

Thunks ist der Codename der verteilten virtuellen Maschine von Lokad. Tatsächlich profitieren Envision-Skripte nativ von einer verteilten Ausführung. In diesem Sinne zielt der Envision-Compiler nicht auf eine einzige Maschine, sondern auf einen Cluster von Maschinen ab. Diese Funktion ist entscheidend für die Verarbeitung großer Datensätze in angemessener Zeit. Die Envision-Sprache wurde speziell für die automatische Parallelisierung entwickelt (eine Funktion, die mit einer allgemeinen Programmiersprache sonst sehr schwer zu erreichen ist). Übrigens bietet der Cluster auch eine höhere Zuverlässigkeit der Skriptausführung, wenn eine Maschine nicht reagiert.

Der Cluster von Maschinen, der Thunks gewidmet ist, wird in einer mandantenfähigen Art und Weise über alle Konten hinweg gepoolt. Diese Funktion ist entscheidend, um die Rechenkosten unter Kontrolle zu halten. Der typische Anwendungsfall für die Supply Chain umfasst eine Ausführungscharge pro Tag, die in der Regel weniger als 60 Minuten dauert. Durch das Pooling der Ressourcen über Mandantenfähigkeit wird der mit den Rechenressourcen verbundene Overhead weitgehend gemildert - ein Kostenfaktor, der sonst in 24-Stunden-Perioden berechnet würde, während nur eine Stunde (möglicherweise weniger) genutzt wird.

Für eine ausführliche Erklärung empfehlen wir Victor Nicollets 4-teilige Serie zum Design der Envision Virtual Machine und für Antworten auf die häufigsten leistungsbezogenen Lokad-Fragen empfehlen wir Abschnitt 8 unserer Sicherheits-FAQ.