Architecture de la plateforme Lokad
La plateforme de Lokad est une solution SaaS hébergée dans le cloud, multi-locataire. Cette page présente l’architecture de haut niveau de la plateforme. Bien que la page soit destinée à un public informatique, un praticien de la supply chain averti en technologie pourrait trouver ces informations intéressantes, car cette architecture reflète notre vision technologique pour l’optimisation prédictive des supply chains.
Aperçu de l’architecture
Lokad se présente comme un environnement pour développer et exploiter des applications d’optimisation prédictive destinées aux problèmes de supply chain. À sa base se trouve un langage spécifique au domaine (DSL) appelé Envision, développé par Lokad. Envision est accessible aux utilisateurs finaux et la plupart des fonctionnalités sont fournies à travers lui. Bien qu’Envision implique de la programmation, Lokad est destiné aux spécialistes de la supply chain, et non aux spécialistes de l’informatique ou aux ingénieurs logiciels.
La plateforme Lokad est multi-locataire : la même application sert tous nos clients et elle comprend une courte série de services. La granularité de la division 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 division purement fonctionnelle. En effet, le niveau de couplage entre ces services est relativement élevé. Ces services partagent le même référentiel de code Git et sont fréquemment mis à jour ensemble.
Notre base de code est implémentée 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 considérablement des architectures “habituelles” que l’on trouve dans les applications d’entreprise - et pour de bonnes raisons. L’application d’entreprise classique dépend de dépendances lourdes et étendues ; chaque dépendance pesant généralement plus d’un million de lignes de code. Lokad, cependant, ne dépend pas de tiers dans les domaines suivants :
- Base de données relationnelle : À la place, nous utilisons un magasin d’événements avec un magasin adressable par contenu.
- Système de mise en cache : À la place, nous colocalisons le calcul et le stockage transitoire.
- Gestionnaire de pipeline : À la place, nous avons notre propre planificateur (détails ci-dessous).
- Moteur d’analyse : À la place, notre DSL nommé Envision fournit des capacités d’analyse.
- Boîte à outils d’apprentissage automatique : À la place, le DSL fournit également des capacités d’apprentissage automatique.
- Boîte à outils de visualisation des données : À la place, nous avons développé notre propre boîte à outils, intégrée étroitement au DSL.
Il convient de noter que, bien que nous internalisions largement le développement de notre plateforme, nous nous appuyons intentionnellement et exclusivement sur des composants tiers pour tous nos composants de sécurité, tels que les algorithmes cryptographiques.
Le 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 déplacer des données vers et depuis Lokad. La plupart de ces interactions se font via un navigateur web via HTTPS, bien que Lokad prenne également en charge les protocoles FTPS et SFTP pour le déplacement de fichiers.
go.lokad.com
Ce service héberge React, le framework front-end de l’application web de Lokad, implémenté sous la forme d’une application à page unique (SPA). Ce front-end dépend des APIs (interfaces de programmation d’application) fournies par les autres services.
Ce service sert exclusivement du contenu statique - principalement du JavaScript. Il n’y a pas de parties mobiles côté serveur et, notamment, aucune persistance des données. Cette conception est intentionnelle car la disponibilité est la plus grande priorité 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 des tableaux de bord, comme son nom l’indique, se charge du rendu des tableaux de bord analytiques 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 petites données, 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 seule requête HTTPS. Cette conception à requête unique vise à minimiser les surcharges de latence. L’emballage binaire et la compression minimisent la consommation de bande passante.
Côté serveur, les données associées à un tableau de bord donné sont emballées par le magasin de contenu. Encore une fois, l’emballage est essentiel pour maintenir le nombre total de requêtes réseau très faible, généralement inférieur à une demi-douzaine - indépendamment de la complexité du tableau de bord.
Les tableaux de bord interactifs donnent à l’utilisateur final la possibilité d’accéder à de grands ensembles de données, au-delà de ce qui serait possible de transférer et d’afficher dans un navigateur. Le passage d’une vue à l’autre nécessite au plus une seule requête côté client (et très peu de requêtes côté serveur).
Lokad vs mainstream
La conception de temps de rendu constant de Lokad diffère des outils de business intelligence (BI) classiques et d’autres outils analytiques. Les tableaux de bord que l’on trouve dans de tels 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 1 requête côté client par tuile, suivie d’un nombre non spécifié/non garanti de requêtes côté serveur. Malheureusement, cette conception entraîne 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 souvent plusieurs secondes.
Lokad résout ce problème en faisant en sorte que le compilateur Envision produise une stratégie d’emballage des données utilisées pour rendre le tableau de bord, garantissant ainsi à la fois un nombre de requêtes à un chiffre côté client et encore moins côté serveur. De notre point de vue, les performances des tableaux de bord commencent au moment de la compilation, avec les scripts à l’origine des tableaux de bord.
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, cette conception entraîne également des problèmes de performances 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 considérablement ce problème en précalculant les tableaux de bord. Notre conception minimise les ressources côté serveur nécessaires - sur demande de l’utilisateur final - pour servir un tableau de bord, laissant le magasin de contenu comme principal goulot d’étranglement (mais intentionnel) pour fournir les données du tableau de bord. Cette conception garantit qu’un grand nombre d’utilisateurs finaux peuvent être servis simultanément avec des tableaux de bord avec une dégradation minimale des performances.
Projets
Le service Projets gère les scripts et les travaux par lots (appelés séquences). Ce service propose une hiérarchie de projets. Les utilisateurs finaux, qui disposent des droits d’accès appropriés, peuvent consulter, modifier et exécuter des projets. Une application d’optimisation prédictive sur mesure implémentée par Lokad comprend généralement une liste de projets.
L’événement sourcing est utilisé pour persister les entrées utilisateur, en s’appuyant sur le magasin d’événements détaillé ici. Chaque commande ou interaction émise vers le service est enregistrée et transformée 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 modèle CQRS+ES. CQRS signifie Command and Query Responsibility Segregation, tandis que ES signifie Event Source.
Le modèle CQRS+ES fournit par conception une historisation complète de toutes les modifications introduites dans l’application. Dans le cas spécifique de Lokad, il fournit une versionnage similaire à Git de toutes les modifications jamais appliquées aux scripts Envision qui existent dans le compte.
Lokad par rapport à la norme
En termes d’interface utilisateur et d’expérience utilisateur, le service Projets suit l’approche courante. En revanche, sous le capot, le modèle CQRS+ES est utilisé comme une alternative au modèle CRUD (create, read, update, delete) utilisé pour la plupart des logiciels d’entreprise. Ce modèle remplace la base de données relationnelle par un magasin d’événements (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 auditabilité supérieure et, dans le cas de Lokad, des performances supérieures car elle nous permet de personnaliser largement la stratégie de persistance utilisée pour stocker et récupérer le code source Envision. En fait, la majeure partie des données à persister par le service Projets consiste en du code source Envision.
Code
Le service Code propose un environnement de développement intégré (IDE) dédié au langage Envision. Cet IDE basé sur le web dispose de toutes les fonctionnalités attendues d’un environnement de développement moderne, telles que la coloration du code, l’autocomplétion et une série d’actions sur le code (par exemple, le renommage de variables), rendues possibles grâce à l’analyse statique du code.
La complexité principale du service Code réside dans son backend de serveur de langage qui fournit des retours en temps réel : des indications 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 les retards seraient assez perceptibles compte tenu du rythme des interactions normales avec le clavier.
Fichiers
Chaque compte chez Lokad dispose de son propre espace de stockage de fichiers. Le service Fichiers propose un système de fichiers distribué et versionné utilisé pour gérer ses fichiers. Ce système de fichiers peut être accédé via une interface web et les protocoles SFTP et FTPS. Conceptuellement, ce système de fichiers est largement similaire à un référentiel Git, à l’exception qu’il est destiné aux fichiers plats de plusieurs gigaoctets.
La version des fichiers est assurée par le modèle 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 magasin adressable par contenu (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 de la supply chain déployées sur sa plateforme. Du point de vue de la supply chain, cette capacité est importante pour s’assurer que chaque résultat anormal généré par l’application de la supply chain peut être dépanné.
Lokad vs mainstream
Le service Fichiers est étroitement intégré au langage Envision (offrant des avantages en termes de correction), à l’IDE Envision (offrant des avantages en termes de productivité) et à l’exécution Envision (offrant des avantages en termes de performances). Ces avantages seraient difficiles à obtenir avec un système de fichiers généraliste, un logiciel qui est avant tout un compagnon du noyau.
De plus, bon nombre des avantages du service Fichiers sont obtenus en faisant moins qu’un système de fichiers généraliste. Par exemple, le service Fichiers n’autorise pas la mise à jour simultanée d’un fichier par plusieurs processus. De telles fonctionnalités, dans le contexte spécifique des applications de la supply chain, exposent uniquement les praticiens de la supply chain à des problèmes et des complexités centrés sur les technologies de l’information sans fournir de valeur en échange.
Comptes
La gestion de l’identité et de l’accès (IAM) du service Comptes est l’une des parties les plus courantes de Lokad. Il gère les comptes Lokad, les utilisateurs Lokad, l’authentification (idéalement, l’authentification déléguée) et la liste de contrôle d’accès (ACL) qui contrôle ce que les utilisateurs peuvent ou ne peuvent pas faire avec un compte Lokad.
Ce service utilise également le modèle CQRS+ES, qui offre des journaux d’audit complets de toutes les opérations IAM - des opérations qui sont toujours sensibles à la sécurité en raison de la nature même de l’IAM. L’utilisation de la source d’événements comme journal d’audit élimine également des classes entières de problèmes de sécurité, tels que la compromission du journal d’audit en ne sélectionnant pas les événements enregistré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 sur 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 les deux types de données grâce à Azure Blob Storage qui agit comme un magasin clé-valeur.
Magasin d’événements
Le magasin d’événements 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 de transition d’état de Lokad. Nous avons publié le code source de notre magasin d’événements en open source.
Ce composant est simple : il persiste et sert uniquement les événements de manière fiable, en utilisant un magasin clé-valeur distribué sous-jacent (Azure Blob Storage). Les événements sont censés être de petite taille - limités à 512 ko, mais généralement inférieurs à 1 ko.
Il n’y a pas de fonctionnalités “intelligentes”, telles que l’analyse en continu 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.
Magasin adressable par contenu
Le magasin adressable par contenu (CAS) persiste les fichiers, qu’ils soient téléchargés sur la plateforme Lokad ou générés par les scripts Envision. Nous avons publié le code source de notre magasin adressable par contenu en open source.
Le CAS est destiné à prendre en charge des fichiers volumineux, généralement de plusieurs Mo, avec une limite supérieure de 100 Go. Le CAS est utilisé pour stocker des fichiers, ou des fragments de fichiers, répartis selon une stratégie de stockage en colonnes. Le stockage en colonnes est aligné sur le modèle 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. Pour des raisons de concision, nous ne listerons ici que les plus remarquables. Le compilateur transforme les scripts Envision en instructions destinées à une machine virtuelle distribuée. Le planificateur est un service utilitaire pour déclencher, planifier et séquencer 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 en colonnes, produite et consommée par la machine virtuelle Envision.
Compilateur
Le compilateur transforme les scripts Envision en bytecode destiné à la machine virtuelle distribuée de la plateforme Lokad - nommée “Thunks” (voir ci-dessous). L’architecture de ce compilateur suit les pratiques de conception courantes : un pipeline de compilation qui commence par l’analyse syntaxique, suivi d’une série de transformations d’une représentation interne à la suivante, se terminant par la production de bytecode.
Le backend du serveur de langage, qui guide les interactions avec le code source Envision (voir le service Code ci-dessus), fait également partie du compilateur. Le serveur de langage est étatique afin de fournir des commentaires significatifs et des messages d’erreur au programmeur Envision, pendant la rédaction du code. Après la plupart des frappes de touches, le script n’est pas encore un script Envision valide, mais grâce à l’état du serveur de langage, des commentaires significatifs sont néanmoins fournis.
Planificateur
Le planificateur est un service utilitaire permettant d’exécuter des scripts Envision sans intervention manuelle. Le planificateur déclenche, planifie et séquence l’exécution des scripts Envision. Il offre également des capacités d’alerte si les exécutions dévient de leurs délais prévus. L’intégration étroite du planificateur avec le reste de la plateforme offre une série de fonctionnalités souhaitables, telles que des déclencheurs de modification de fichier (pour démarrer des scripts Envision à 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 se 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 vise pas une seule machine mais un cluster de machines. Cette fonctionnalité est essentielle pour traiter de grands ensembles de données en temps opportun. Le langage Envision a été spécialement conçu pour la parallélisation automatique (une fonctionnalité qui est autrement très difficile à réaliser avec un langage de programmation général). Incidemment, le cluster offre également une plus grande fiabilité de l’exécution des scripts si une machine devient non réactive.
Le cluster de machines dédiées à Thunks est regroupé, de manière multi-locataire, entre tous les comptes. Cette fonctionnalité est essentielle pour maîtriser les coûts de calcul. Le cas d’utilisation typique de la supply chain implique un lot d’exécution par jour, généralement d’une durée inférieure à 60 minutes. La mise en commun des ressources grâce à la multi-locataire atténue largement les frais généraux liés aux ressources de calcul - un coût qui serait autrement facturé par périodes de 24 heures, alors qu’une heure (voire moins) serait utilisée.
Pour une explication détaillée, nous vous suggérons la série en 4 parties de Victor Nicollet sur la conception de la machine virtuelle Envision, et pour des réponses aux questions les plus courantes sur les performances de Lokad, nous vous recommandons la section 8 de notre FAQ sur la sécurité.