Architecture de la plateforme de Lokad

La plateforme de Lokad est une solution SaaS multi-tenant hébergée dans le cloud. Cette page présente l’architecture globale de la plateforme. Bien que la page s’adresse à un public IT, un praticien supply chain averti pourrait trouver ces informations intéressantes, puisque cette architecture reflète notre vision technologique pour l’optimisation prédictive de la supply chain.

Aperçu de l’architecture

Lokad se présente comme un environnement permettant de développer et d’exploiter des applications d’optimisation prédictive destinées aux problèmes de supply chain. Au cœur de celle-ci se trouve un langage spécifique au domaine (DSL) nommé Envision, conçu par Lokad. Envision est accessible aux utilisateurs finaux et la plupart des fonctionnalités y sont délivrées. Bien qu’Envision implique de la programmation, Lokad est destiné aux spécialistes supply chain, et non aux spécialistes IT ou aux ingénieurs logiciels.

La plateforme de Lokad est multi-tenant : la même application sert tous nos clients et elle comprend une courte série de services. La granularité de cette répartition est principalement motivée par des exigences divergentes en termes de fiabilité, de sécurité et de performance de chaque service – plutôt que par une répartition purement fonctionnelle. En effet, le degré de couplage existant entre ces services est relativement élevé. Ces services partagent le même dépôt de code Git, et ils sont fréquemment mis à jour simultanément.

Notre code est implémenté en F#, C# et TypeScript avec peu de dépendances tierces en dehors de .NET, un framework open source développé par Microsoft. De plus, à part .NET lui-même, nous avons très peu d’autres dépendances (environ un ordre de grandeur de moins que la norme).

Cette architecture diverge largement des architectures “usuelles” que l’on trouve dans les applications d’entreprise – et pour de bonnes raisons. L’application d’entreprise typique dépend de dépendances lourdes et étendues ; chaque dépendance pesant généralement plus d’un million de lignes de code. Lokad, en revanche, n’a pas de dépendances tierces dans les domaines suivants:

• Base de données relationnelle: À la place, nous utilisons un event store ainsi qu’un content addressable store.
• Système de mise en cache: À la place, nous colocalisons le calcul et le stockage transitoire.
• Gestionnaire de pipeline: À la place, nous disposons de notre propre scheduler (décrit ci-dessous)
• Moteur d’analyse: À la place, notre DSL nommé Envision fournit des capacités d’analyse.
• Boîte à outils de machine learning: À la place, le DSL fournit également des capacités ML.
• Outils de visualisation de données: À la place, nous avons développé le nôtre, avec une intégration étroite du DSL.

Il convient de noter que, bien que nous internalisions largement le développement de notre plateforme, nous nous appuyons de manière intentionnelle et exclusive sur des composants tiers pour tous nos composants de sécurité, tels que les algorithmes cryptographiques.

The front-end

Le front-end fait référence aux éléments accessibles aux utilisateurs finaux, y compris les agents automatisés utilisés pour transférer des données vers et depuis Lokad. La plupart de ces interactions se déroulent via un navigateur web en HTTPS, bien que Lokad supporte également les protocoles FTPS et SFTP pour transférer des fichiers.

go.lokad.com

Ce service héberge React, le framework front-end de l’application web de Lokad, implémenté en tant qu’application monopage (SPA). Ce front-end dépend des API (interfaces de programmation d’application) fournies par les autres services.

Ce service ne fournit exclusivement que du contenu statique - principalement du JavaScript. Il n’y a aucune partie dynamique côté serveur, et, notamment, aucune persistance de données. Ce design est intentionnel car la disponibilité est la priorité absolue pour ce service ; peu importe le service auquel on accède via le web, le service go.lokad.com doit être disponible.

Tableaux de bord

Le service de tableaux de bord, comme son nom l’indique, s’occupe de rendre les tableaux de bord analytiques web fournis par Lokad.

Chaque tableau de bord est le résultat d’un script Envision exécuté. Les tableaux de bord sont largement pré-calculés, bien que certaines fonctionnalités interactives soient également proposées. La conception d’Envision elle-même garantit que les interactions côté client restent des problèmes de small data, quelle que soit la taille de l’ensemble de données d’origine.

Côté client, toutes les données nécessaires pour le premier rendu du tableau de bord sont obtenues via une unique requête HTTPS. Ce design à requête unique permet de minimiser la latence. Le packaging binaire et la compression réduisent la consommation de bande passante.

Côté serveur, les données associées à un tableau de bord donné sont empaquetées par le content store. Là encore, l’empaquetage est essentiel pour maintenir un nombre total de requêtes réseau très faible, généralement inférieur à une demi-douzaine – quelle que soit la complexité du tableau de bord.

Les tableaux de bord interactifs offrent à l’utilisateur final la possibilité d’accéder à de grands ensembles de données, au-delà de ce qu’il serait possible de transférer et d’afficher dans un navigateur. Passer d’une vue à l’autre nécessite au maximum une requête côté client (et très peu côté serveur).

Lokad vs mainstream

Le design à temps de rendu constant de Lokad diffère des outils d’intelligence d’affaires (BI) mainstream et d’autres outils analytiques. Les tableaux de bord que l’on trouve dans ces outils sont invariablement constitués d’une liste de tuiles, parfois appelées blocs ou widgets. La méthode standard pour gérer ces tuiles implique une requête côté client par tuile, suivie d’un nombre non spécifié/non garanti de requêtes côté serveur. Malheureusement, ce design conduit à des tableaux de bord lents avec un délai perceptible pour chaque tuile. De plus, l’affichage complet de toutes les tuiles du tableau de bord prend fréquemment plusieurs secondes.

Lokad élimine ce problème en faisant en sorte que le compilateur Envision produise une stratégie d’empaquetage des données utilisées pour rendre le tableau de bord, assurant ainsi un nombre de requêtes à un chiffre du côté client, et encore moins du côté serveur. De notre point de vue, la performance des tableaux de bord commence à la compilation, avec les scripts qui les supportent.

De plus, la plupart des outils analytiques reportent une grande partie du calcul jusqu’à ce qu’un tableau de bord (parfois appelé rapport) soit demandé. Malheureusement, ce design conduit également invariablement à des problèmes de performance lorsque le nombre d’utilisateurs finaux simultanés augmente, car il y a un conflit inévitable pour les ressources de calcul côté serveur qui sont mutualisées pour servir tous les utilisateurs finaux.

Lokad atténue largement ce problème en pré-calculant les tableaux de bord. Notre design minimise les ressources côté serveur nécessaires – à la demande de l’utilisateur final – pour servir un tableau de bord, laissant le content store comme principal (mais prévu) goulot d’étranglement pour fournir les données des tableaux de bord. Ce design garantit qu’un grand nombre d’utilisateurs finaux peut être servi simultanément par les tableaux de bord avec une dégradation minimale des performances.

Projets

Le service des projets gère les scripts et les tâches par lots (appelées séquences). Ce service présente une hiérarchie de projets. Les utilisateurs finaux, ayant les droits d’accès appropriés, peuvent visualiser, éditer et exécuter des projets. Une application d’optimisation prédictive sur mesure implémentée par Lokad inclut généralement une liste de projets.

L’event sourcing est utilisé pour persister les entrées des utilisateurs, en tirant parti de l’event store détaillé ici. Chaque commande ou interaction envoyée au service est enregistrée et convertie en un événement résultant. L’interface utilisateur présente l’état obtenu en regroupant tous les événements. Cette approche est connue sous le nom de pattern CQRS+ES. CQRS signifie Command and Query Responsibility Segregation, tandis que ES signifie Event Source.

Le pattern CQRS+ES offre par conception une historisation complète de tous les changements introduits dans l’application. Dans le cas spécifique de Lokad, il fournit un versioning à la manière de Git de toutes les modifications jamais appliquées aux scripts Envision présents dans le compte.

Lokad vs mainstream

En termes d’interface utilisateur (UI) et d’expérience utilisateur (UX), le service des projets suit l’approche mainstream. En interne, cependant, le pattern CQRS+ES est utilisé comme alternative au modèle CRUD (create, read, update, delete) utilisé pour la plupart des logiciels d’entreprise. Ce pattern remplace la base de données relationnelle par un event store (discuté ci-dessous).

L’approche CQRS+ES offre de nombreux avantages par rapport au modèle CRUD. Par exemple, elle offre une sémantique supérieure, une meilleure traçabilité et, dans le cas de Lokad, des performances supérieures, car elle nous permet de personnaliser de manière extensive la stratégie de persistance utilisée pour stocker et récupérer le code source Envision. En fait, l’essentiel des données à persister par le service des projets consiste en code source Envision.

Code

Le service de code propose un IDE (environnement de développement intégré) dédié au langage Envision. Cet IDE basé sur le web offre toutes les fonctionnalités attendues d’un environnement de développement moderne, telles que la coloration syntaxique, l’autocomplétion et une série d’actions sur le code (ex: le renommage de variables), rendues possibles grâce à l’analyse statique du code.

L’essentiel de la complexité du service de code réside dans son backend de language server qui fournit un retour en temps réel : des suggestions pour l’autocomplétion, des erreurs ou des actions sur le code à chaque frappe. En particulier, l’un des principaux défis techniques consiste à maintenir une faible latence pour cette fonction, car des retards seraient assez perceptibles compte tenu du rythme normal des interactions au clavier.

Fichiers

Chaque compte chez Lokad dispose de son propre espace pour stocker des fichiers. Le service de fichiers propose un système de fichiers versionné distribué qui est utilisé pour gérer ces fichiers. Ce système de fichiers peut être accédé via une interface web ainsi que par les protocoles SFTP et FTPS. Conceptuellement, ce système de fichiers est largement similaire à un dépôt Git, sauf qu’il est destiné à des fichiers plats de taille gigaoctets.

La gestion des versions des fichiers est assurée par le pattern CQRS+ES, qui complète la présentation d’une séquence de “commits”, reflétant l’évolution du système de fichiers lui-même. La persistance du contenu des fichiers est assurée par un content addressable store (discuté ci-dessous).

En versionnant à la fois le code (scripts Envision) et les données, Lokad offre une reproductibilité complète des comportements passés pour les applications supply chain déployées sur sa plateforme. D’un point de vue supply chain, cette capacité est importante pour s’assurer que chaque résultat anormal généré par l’application supply chain puisse être diagnostiqué.

Lokad vs mainstream

Le service fichiers est étroitement intégré avec le langage Envision (offrant des avantages en termes de correction), l’IDE Envision (offrant des avantages en termes de productivité) et le runtime Envision (offrant des avantages en termes de performance). Ces avantages seraient difficiles à obtenir avec un système de fichiers à usage général, un logiciel qui est avant tout un compagnon du noyau.

De plus, bon nombre des avantages du service fichiers sont obtenus en faisant moins que ce qu’un système de fichiers à usage général permet. Par exemple, le service fichiers n’autorise pas la mise à jour concurrente d’un fichier par plusieurs processus. De telles fonctionnalités, dans le contexte spécifique des applications supply chain, n’exposent les praticiens supply chain qu’à des problèmes et des complexités centrés sur l’IT sans offrir de valeur en retour.

Comptes

La gestion des identités et des accès (IAM) du service comptes est l’une des parties les plus mainstream de Lokad. Elle gère les comptes Lokad, les utilisateurs de Lokad, l’authentification (idéalement, authentification déléguée), et la ACL (Access Control List) qui contrôle ce que les utilisateurs peuvent ou ne peuvent pas faire avec un compte Lokad.

Ce service exploite également le pattern CQRS+ES, qui offre des journaux d’audit complets de toutes les opérations IAM - des opérations toujours sensibles en matière de sécurité en raison de la nature même de l’IAM. Utiliser l’event source comme journal d’audit permet également d’éliminer des classes entières de problèmes de sécurité, tels que le risque de compromettre le journal d’audit en n’y enregistrant pas certains événements sélectionnés.

La couche de persistance

La couche de persistance, comme son nom l’indique, assure la persistance de toutes les données gérées par Lokad. Ces données se présentent sous deux formes distinctes : d’abord, les fichiers - soit téléchargés par les clients vers Lokad, soit générés par des scripts Envision ; ensuite, les événements résultant des opérations des utilisateurs (y compris les agents automatisés, tels qu’un script de téléchargement de fichiers). Lokad persiste ces deux types de données via Azure Blob Storage agissant comme un magasin clé-valeur.

Event Store

L’event store persiste les événements générés par tous les services de la plateforme Lokad. Ce magasin représente la base de données des transitions d’état de Lokad. Nous avons publié le code source de notre event store en open source.

Ce composant est simple : il ne persiste et ne sert que des événements, de manière fiable, en tirant parti d’un magasin clé-valeur distribué sous-jacent (Azure Blob Storage). Les événements sont censés être petits - limités à 512kB, mais généralement de moins de 1kB.

Il n’y a pas de fonctionnalités “intelligentes”, telles que l’analytics en streaming ou la gestion des projections. Encore une fois, en faisant moins, Lokad élimine des classes entières de problèmes, tels que les attaques par injection SQL, qui surviennent en raison des capacités de la couche de persistance.

Content Addressable Store

Le content addressable store (CAS) persiste les fichiers, soit téléchargés sur la plateforme Lokad, soit générés par les scripts Envision. Nous avons publié le code source de notre content addressable storage en open source.

Le CAS est destiné à supporter de gros fichiers, typiquement de plusieurs MB, avec une limite supérieure de 100GB. Le CAS est utilisé pour stocker des fichiers, ou des fragments de fichiers, partitionnés selon une stratégie de stockage par colonnes. Le stockage par colonnes est aligné avec le mode d’accès de la couche d’exécution.

La couche d’exécution

Comme son nom l’indique, la couche d’exécution assure l’exécution des scripts Envision au sein de la plateforme Lokad, et elle comprend une série de composants. Par souci de concision, nous ne listerons ici que les plus notables. Le compiler transforme les scripts Envision en instructions destinées à une machine virtuelle distribuée. Le scheduler est un service utilitaire permettant de déclencher, planifier et ordonner les scripts Envision. Thunks est le nom de code de la machine virtuelle Envision. Enfin, Ionic est le nom de la stratégie de stockage par colonnes, produite et consommée par la machine virtuelle Envision.

Compiler

Le compiler transforme les scripts Envision en bytecode destiné à la machine virtuelle distribuée de la plateforme de Lokad – nommée “Thunks” (voir ci-dessous). L’architecture de ce compiler suit les pratiques de conception mainstream : un pipeline de compilation qui commence par l’analyse syntaxique, suivie d’une série de transformations d’une représentation interne à l’autre, se terminant par la production de bytecode.

Le backend du serveur de langue, qui guide les interactions avec le code source Envision (voir le service Code, ci-dessus), fait également partie du compilateur. Le serveur de langue est doté d’un état afin de fournir des retours pertinents et des messages d’erreur au programmeur Envision pendant le codage. Après la plupart des frappes, le script n’est pas (encore) un script Envision valide, mais grâce à l’état du serveur de langue, des retours pertinents sont néanmoins fournis.

Ordonnanceur

L’ordonnanceur est un service utilitaire permettant d’exécuter des scripts Envision sans intervention manuelle. Il déclenche, planifie et séquence l’exécution des scripts Envision. Il offre également des capacités d’alerte si les exécutions s’écartent des délais prévus. L’intégration étroite de l’ordonnanceur avec le reste de la plateforme offre une série de fonctionnalités recherchées, telles que les déclencheurs à la modification de fichier (pour démarrer les scripts Envision dès la réception de fichiers, par exemple), ou la détection précoce d’une défaillance imminente (si l’un des scripts Envision d’une séquence ne compile pas).

Thunks

Thunks est le nom de code de la machine virtuelle distribuée de Lokad. En fait, les scripts Envision bénéficient nativement d’une exécution distribuée. En ce sens, le compilateur Envision ne cible pas une seule machine mais un cluster d’entre elles.. Cette fonctionnalité est cruciale pour traiter de grands ensembles de données en temps utile. Le langage Envision a été spécialement conçu pour la parallélisation automatique (une fonctionnalité par ailleurs très difficile à obtenir avec un langage de programmation général). Incidemment, le cluster offre également une plus grande fiabilité d’exécution des scripts si une machine devient non réactive.

Le cluster de machines dédié à Thunks est mutualisé, de manière multi-locataire, entre tous les comptes. Cette fonctionnalité est essentielle pour maîtriser les coûts informatiques. Le cas d’usage typique de la supply chain implique un lot d’exécution par jour, durant généralement moins de 60 minutes. La mutualisation des ressources via la multi-location atténue largement les frais généraux associés aux ressources informatiques – un coût qui, autrement, serait facturé sur des périodes de 24 heures, alors qu’une seule heure (voire moins) serait utilisée.

Pour une explication détaillée, nous vous suggérons la série en 4 volets de Victor Nicollet sur la conception de la Envision Virtual Machine, et pour obtenir des réponses aux questions de performance les plus courantes chez Lokad, nous recommandons la section 8 de notre Security FAQ.