Architecture de la plateforme Lokad
La plateforme de Lokad est une solution SaaS multi-locataire hébergée dans le cloud. Cette page présente l’architecture de haut niveau de la plateforme. Bien que cette page soit destinée à un public IT, un praticien de supply chain averti sur le plan technologique pourrait trouver ces informations intéressantes, car cette architecture reflète notre vision technologique pour l’optimization prédictive de la supply chain.
Aperçu de l’architecture
Lokad se présente comme un environnement pour développer et exploiter des applications d’optimization prédictive destinées aux problèmes de supply chain. Au cœur se trouve un langage spécifique (DSL) nommé Envision, conçu par Lokad. Envision est accessible aux utilisateurs finaux et la majorité des fonctionnalités lui est délivrée. Alors qu’Envision implique de la programmation, Lokad est destiné aux spécialistes de la supply chain, et non aux spécialistes IT ou aux ingénieurs logiciels.
La plateforme de Lokad est multi-locataire : la même application dessert tous nos clients et 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 division purement fonctionnelle. En effet, le niveau de couplage existant entre ces services est relativement élevé. Ces services partagent le même dépôt Git, et ils sont fréquemment mis à jour ensemble.
Notre base de code est implémentée en F#, C# et TypeScript avec très 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 “usual” que l’on retrouve dans les applications d’entreprise – et ce pour de bonnes raisons. L’application d’entreprise classique dépend de dépendances lourdes et étendues ; chaque dépendance pèse 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 cache: À la place, nous colocalisons le calcul et le stockage transitoire.
- Gestionnaire de pipeline: À la place, nous avons notre propre scheduler (détaillé ci-dessous)
- Moteur analytique: À la place, notre DSL nommé Envision offre des fonctionnalités analytiques.
- Machine learning toolkit: À la place, le DSL fournit également des capacités de ML.
- Data visualization toolkit: À la place, nous avons déployé le nôtre, avec une intégration étroite au 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 l’ensemble de nos composants de sécurité, comme les algorithmes cryptographiques.
Le front-end
Le front-end désigne les é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 s’effectuent via un navigateur web en HTTPS, bien que Lokad supporte également les protocoles FTPS et SFTP pour le transfert de fichiers.
go.lokad.com
Ce service héberge React, le framework front-end de l’application web de Lokad, implémenté sous forme d’application monopage (SPA). Ce front-end dépend des API (interfaces de programmation d’applications) fournies par les autres services.
Ce service ne sert exclusivement que du contenu statique – principalement du JavaScript. Il n’existe aucune partie mobile côté serveur, et, notamment, aucune persistance des données. Ce design est intentionnel, car le uptime constitue la priorité absolue pour ce service; quel que soit le service accessible 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 de l’affichage des 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 même d’Envision garantit que les interactions côté client demeurent des problèmes de small data, quelle que soit la taille du jeu de données d’origine.
Côté client, toutes les données nécessaires au premier rendu du tableau de bord sont obtenues via une seule requête HTTPS. Ce design à requête unique permet de minimiser la latence. L’emballage 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. Encore une fois, cet empaquetage 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 offrent à l’utilisateur final la possibilité d’accéder à de grands ensembles de données, au-delà de ce qui serait envisageable à transférer vers – et afficher via – un navigateur. Le passage d’une vue à l’autre nécessite au maximum une seule 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 de business intelligence (BI) mainstream et autres outils analytiques. Les tableaux de bord que l’on trouve dans ces outils se composent invariablement d’une liste de tuiles, parfois appelées blocs ou widgets. La méthode standard pour traiter ces tuiles implique une requête côté client par tuile, suivie d’un nombre non spécifié de requêtes côté serveur. Malheureusement, ce design aboutit à des tableaux de bord lents avec un délai perceptible pour chaque tuile. Par ailleurs, 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, garantissant ainsi un nombre de requêtes côté client à un chiffre et encore moins côté serveur. De notre point de vue, la performance des tableaux de bord commence dès la compilation, grâce aux scripts qui les soutiennent.
De plus, la plupart des outils analytiques repoussent une grande partie du calcul jusqu’à ce qu’un tableau de bord (parfois appelé rapport) soit sollicité. Malheureusement, ce design conduit également invariablement à des problèmes de performance lorsque le nombre d’utilisateurs finaux simultanés augmente, en raison d’un conflit inévitable pour les ressources de calcul côté serveur, mutualisées pour servir tous les utilisateurs.
Lokad atténue largement ce problème en précalculant les tableaux de bord. Notre conception 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 goulot d’étranglement (mais prévu) pour fournir les données des dashboards. Cette conception assure qu’un grand nombre d’utilisateurs finaux peuvent être servis simultanément avec une dégradation minimale des performances.
Projets
Le service des projets gère les scripts et les travaux par lots (appelés séquences). Ce service dispose d’une hiérarchie de projets. Les utilisateurs finaux, disposant des droits d’accès appropriés, peuvent consulter, modifier et exécuter des projets. Une application d’optimization 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 s’appuyant sur l’event store détaillé ici. Chaque commande ou interaction adressée au service est consignée et transformée en un événement résultant. L’interface utilisateur présente l’état obtenu en rassemblant 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 versionnage à la manière de Git de toutes les modifications jamais apportées aux scripts Envision présents dans le compte.
Lokad vs mainstream
En termes d’UI et d’UX, le service des projets suit l’approche mainstream. En coulisses, cependant, le pattern CQRS+ES est utilisé en alternative au CRUD (create, read, update, delete) employé par la plupart des logiciels d’entreprise. Ce pattern remplace la base de données relationnelle par un event store (voir ci-dessous).
L’approche CQRS+ES offre de nombreux avantages par rapport au pattern CRUD. Par exemple, elle propose une sémantique supérieure, une auditabilité améliorée et, dans le cas de Lokad, des performances supérieures puisqu’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, l’essentiel des données à persister par le service des projets constitue le code source Envision.
Code
Le service code propose un IDE (integrated development environment) dédié au langage Envision. Cet IDE basé sur le web intègre 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: renommage de variables), rendues possibles par l’analyse statique du code.
L’essentiel de la complexité du service code réside dans son backend language server qui fournit un retour en temps réel : suggestions pour l’autocomplétion, erreurs ou 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 particulièrement perceptibles compte tenu du rythme normal des interactions au clavier.
Fichiers
Chaque compte chez Lokad dispose de son propre espace de stockage de fichiers. Le service des fichiers propose un système de fichiers distribué et versionné qui est utilisé pour gérer ces fichiers. Ce système peut être accédé via une interface web ainsi que par les protocoles SFTP et FTPS. Conceptuellement, ce système ressemble beaucoup à un dépôt Git, à la différence qu’il est destiné aux fichiers plats de taille gigaoctet.
La gestion des versions des fichiers est assurée grâce au 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 (les scripts Envision) et les données, Lokad offre une reproductibilité complète des comportements passés pour les supply chain apps 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 supply chain puisse être diagnostiqué.
Lokad vs mainstream
Le service des fichiers est étroitement intégré au langage Envision (offrant des bénéfices en termes de justesse), à l’IDE Envision (apportant des bénéfices en termes de productivité) et au runtime Envision (fournissant des bénéfices en termes de performance). Ces avantages seraient difficiles à atteindre avec un système de fichiers à usage général, un logiciel qui se veut avant tout un compagnon du noyau.
De plus, bon nombre des avantages du service des fichiers découlent du fait d’en faire moins qu’un système de fichiers à usage général. Par exemple, le service des fichiers n’autorise pas qu’un fichier soit mis à jour simultanément par plusieurs processus. De telles fonctionnalités, dans le contexte spécifique des applications de supply chain, n’exposent les praticiens de supply chain qu’à des problématiques IT et à des complexités, sans apporter de réelle 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 l’ACL (Access Control List) qui détermine 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 – opérations toujours sensibles sur le plan de la sécurité en raison de la nature même de l’IAM. L’utilisation de l’event source en tant que journal d’audit élimine également des catégories entières de problèmes de sécurité, tels que le risque de compromission du journal d’audit par l’absence d’enregistrement de certains événements.
La couche de persistance
La couche de persistance, comme son nom l’indique, assure la pérennité de toutes les données gérées par Lokad. Ces données se présentent sous deux formes distinctes : d’une part, les fichiers – soit téléchargés par les clients vers Lokad, soit générés par des scripts Envision ; d’autre part, les événements résultant des opérations des utilisateurs (y compris les agents automatisés, comme un script de téléchargement de fichiers). Lokad persiste ces deux types de données via Azure Blob Storage, qui agit comme un magasin de clés-valeurs.
Event Store
L’event store persiste les événements générés par l’ensemble des services de la plateforme Lokad. Ce store 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 se contente de persister et de servir les événements, de manière fiable, en s’appuyant sur un magasin de clés-valeurs distribué sous-jacent (Azure Blob Storage). Les événements sont censés être de petite taille – limités à 512kB, mais typiquement inférieurs à 1kB.
Il n’existe pas de fonctionnalités “smart”, telles que l’analytics en streaming ou la gestion des projections. Encore une fois, en faisant moins, Lokad élimine des catégories entières de problèmes, comme les attaques par injection SQL, qui découlent des capacités de la couche de persistance.
Content Addressable Store
Le content addressable store (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 content addressable storage en open source.
Le CAS est conçu pour supporter de gros fichiers, typiquement de plusieurs mégaoctets, avec une limite supérieure de 100GB. Il est utilisé pour stocker des fichiers, ou des fragments de fichiers, répartis selon une stratégie de stockage en colonnes. Ce stockage en colonnes est en phase avec le schéma 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 faire court, nous listerons ici uniquement les plus notables. Le compiler transforme les scripts Envision en instructions destinées à une machine virtuelle distribuée. Le scheduler 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 désigne la stratégie de stockage en 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 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, suivi d’une série de transformations d’une représentation interne à l’autre, pour aboutir à la production de bytecode.
Le backend du serveur de langage, qui guide les interactions avec le code source d’Envision (voir le service Code, ci-dessus), fait également partie du compilateur. Le serveur de langage est doté d’un état afin de fournir des retours significatifs et des messages d’erreur pertinents au programmeur Envision, pendant que le codage est en cours. Après la plupart des frappes, le script n’est pas encore un script Envision valide, mais, grâce à l’état du serveur de langage, des retours significatifs sont néanmoins fournis.
Ordonnanceur
L’ordonnanceur est un service utilitaire permettant d’exécuter des scripts Envision sans interventions manuelles. L’ordonnanceur 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 platforme offre une série de fonctionnalités désirables, telles que des déclencheurs liés aux changements de fichiers (pour démarrer des 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 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 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 voulu. Le langage Envision a été spécialement conçu pour la parallélisation automatique (une fonctionnalité qui est par ailleurs très difficile à réaliser avec un langage de programmation général). Incidemment, le cluster offre également une fiabilité supérieure lors de l’exécution des scripts si une machine devient non réactive.
Le cluster de machines dédié à Thunks est mutualisé, de manière multi-tenant, entre l’ensemble des comptes. Cette fonctionnalité est essentielle pour contenir les coûts informatiques. Le cas d’utilisation typique supply chain implique un traitement par lots par jour, d’une durée généralement inférieure à 60 minutes. La mutualisation des ressources grâce au multi-tenancy atténue largement le surcoût associé 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 effectivement utilisée.
Pour une explication approfondie, nous vous suggérons la série en 4 parties de Victor Nicollet sur la conception de la Envision Virtual Machine, et pour obtenir des réponses aux questions Lokad les plus courantes concernant les performances, nous recommandons la section 8 de notre Security FAQ.