Architecture de Lokad

La plateforme de Lokad est une solution SaaS multi-locataire hébergée sur le cloud. 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 chaîne d'approvisionnement technophile pourrait trouver cette information intéressante, car cette architecture reflète notre vision technologique pour l'optimisation prédictive des chaînes d'approvisionnement.

system architecture


   Vue d’ensemble de l'architecture
   Le front-end
       go.lokad.com
      Tableaux de bord
      Projets
      Code
      Fichiers
      Comptes
   La couche de persistance
      L'event store
      Magasin de contenu adressable
   La couche d'exécution
      Compiler
      Planificateur
      Thunks


Vue d’ensemble 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 la chaîne d'approvisionnement. Au cœur de cette plateforme 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 ce langage. Bien que l'utilisation d'Envision implique de la "programmation", Lokad est destiné aux "spécialistes de la chaîne d'approvisionnement", pas aux spécialistes de l'informatique ou aux ingénieurs logiciels.

La plateforme Lokad est multi-tenant : 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 fonctionnelle pure. En effet, le niveau de couplage entre ces services est relativement élevé. Ces services partagent le même dépôt de code Git, et ils sont fréquemment mis à niveau ensemble.

Notre base de code est implémentée en F#, C# et TypeScript avec peu de dépendances tierces au-delà de .NET, un framework open source développé par Microsoft. De plus, à l'exception de .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 diffère considérablement des architectures "habituelles" que l'on trouve dans les applications d'entreprise - et pour de bonnes raisons. Les applications d'entreprise courantes dépendent de dépendances "lourdes et étendues"; chaque dépendance pesant généralement plus d'un million de lignes de code. Cependant, Lokad ne dépend pas de tiers pour les domaines suivants:

  • Base de données relationnelle: nous utilisons à la place un event store ainsi qu'un magasin de contenu adressable.
  • Système de mise en cache: nous colocalisons le calcul et le stockage temporaire.
  • Gestionnaire de pipeline: nous avons notre propre ordonnanceur (détaillé ci-dessous).
  • Moteur d'analyse: notre DSL nommé Envision fournit des capacités d'analyse.
  • Boîte à outils d'apprentissage automatique: le DSL fournit également des capacités de ML.
  • Boîte à outils de visualisation de données: nous avons déployé notre propre outil de visualisation, avec une intégration DSL étroite.

Il convient de noter que, bien que nous internalisions considérablement 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 les 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 déplacer les 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 à page unique (SPA). Ce front-end dépend des API (interfaces de programmation d'application) fournies par les autres services.

Ce service ne sert exclusivement que du contenu statique - principalement du JavaScript. Il n'y a pas de parties mobiles côté serveur et, surtout, aucune persistance de données. Cette conception est intentionnelle car la "disponibilité" est la plus grande priorité pour ce service; quel que soit le service qui est accessible 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 du rendu 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 capacités interactives soient également offertes. La conception d'Envision lui-même garantit que les interactions côté client restent des problèmes de "petites données", quelles que soient 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 grâce à une seule demande HTTPS. Cette conception de demande unique sert à minimiser la surcharge de latence. Le paquetage 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 content store. Encore une fois, l'emballage est essentiel pour maintenir le nombre total de requêtes réseau très faible, normalement en dessous d'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 réalisable pour transférer - et afficher à travers - un navigateur. Passer d'une vue à l'autre nécessite au plus une seule demande côté client (et très peu de demandes côté serveur).

Lokad vs mainstream

La conception de Lokad, basée sur un temps de rendu constant, diffère de celle des outils d'intelligence d'affaires (BI) et autres outils analytiques courants. Les tableaux de bord que l'on trouve dans ces outils sont généralement constitués d'une liste de tuiles, également appelées blocs ou widgets. Pour gérer ces tuiles, la méthode standard implique une demande côté client par tuile, suivie d'un nombre non spécifié/ non garanti de demandes 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 fréquemment plusieurs secondes.

Lokad résout ce problème en demandant au compilateur Envision de produire une stratégie d'emballage des données utilisées pour rendre le tableau de bord, assurant ainsi un nombre de demandes limité à un chiffre côté client, et encore moins côté serveur. Pour nous, la performance du tableau de bord commence au moment de la compilation, avec les scripts utilisés pour créer les tableaux de bord.

De plus, la plupart des outils analytiques repoussent une grande partie du calcul jusqu'à ce qu'un tableau de bord (parfois appelé un rapport) soit demandé. Malheureusement, cette conception entraîne inévitablement des problèmes de performance lorsque le nombre d'utilisateurs finaux concurrents augmente, car il y a un conflit pour les ressources informatiques côté serveur qui sont mutualisées pour servir tous les utilisateurs finaux.

Lokad résout largement ce problème en "précalculant" les tableaux de bord. Notre conception minimise les ressources côté serveur nécessaires pour servir un tableau de bord sur demande des utilisateurs finaux, en laissant le content store comme principal goulot d'étranglement pour servir les données de tableau de bord. Cette conception garantit qu'un grand nombre d'utilisateurs finaux peuvent être simultanément servis des tableaux de bord avec une dégradation minimale des performances.

Projets

Le service projets gère les scripts et les tâches par lots (appelées séquences). Ce service dispose d'une hiérarchie de projets. Les utilisateurs finaux, disposant des droits d'accès appropriés, peuvent afficher, modifier et exécuter des projets. Une application de prédiction d'optimisation personnalisée implémentée par Lokad comprend généralement une liste de projets.

La persistance des entrées utilisateur est assurée par l'Event Sourcing, en exploitant l'event store 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 recoupant tous les événements. Cette approche est connue sous le nom de modèle CQRS+ES. CQRS signifie Command Query Responsibility Segregation, tandis que ES signifie Event Source.

Le modèle CQRS+ES offre par conception une historisation complète de toutes les modifications apportées à l'application. Dans le cas spécifique de Lokad, il fournit une version comparable à Git de toutes les modifications jamais appliquées aux scripts Envision qui existent dans le compte.

Lokad vs mainstream

En termes d'interface utilisateur (UI) et d'expérience utilisateur (UX), le service projets suit l'approche courante. Sous le capot, cependant, le modèle CQRS+ES est utilisé en 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 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 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 dispose d'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 et fonctionnalités attendues d'un environnement de développement moderne, telles que la coloration du code, l'auto-complétion et une série d'actions de 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 commentaires en temps réel : des indications pour l'autocomplétion, des erreurs ou des actions de code à chaque frappe. En particulier, l'un des principaux défis techniques consiste à maintenir une latence faible pour cette fonction, car les retards seraient assez perceptibles compte tenu du rythme des interactions normales du clavier.

Fichiers

Chaque compte chez Lokad dispose de son propre espace de stockage de fichiers. Le service files présente un système de fichiers distribué et versionné qui est utilisé pour gérer ces fichiers. Ce système de fichiers peut être accessible via une interface web ainsi que via les protocoles SFTP et FTPS. Conceptuellement, ce système de fichiers est similaire à un dépôt Git, à l'exception qu'il est conçu pour les fichiers plats de 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 de contenu adressable (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 chaîne d'approvisionnement déployées sur sa plateforme. Du point de vue de la chaîne d'approvisionnement, cette capacité est importante pour s'assurer que chaque résultat anormal généré par l'application de la chaîne d'approvisionnement puisse être dépanné.

Lokad vs mainstream

Le service files est étroitement intégré avec le langage Envision (fournissant des avantages de correction), l'IDE Envision (fournissant des avantages de productivité) et le runtime Envision (fournissant des avantages de performance). Ces avantages seraient difficiles à atteindre avec un système de fichiers généraliste, un logiciel qui est avant tout un compagnon du noyau.

De plus, de nombreux avantages du service files sont obtenus en faisant moins qu'un système de fichiers généraliste. Par exemple, le service files 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 chaîne d'approvisionnement, exposent uniquement les praticiens de la chaîne d'approvisionnement à des problèmes et complexités liés à l'informatique 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. Elle gère les comptes Lokad, les utilisateurs Lokad, l'authentification (idéalement, une 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 le compromis 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, téléchargés par les clients sur Lokad ou générés par des scripts Envision; ensuite, les événements résultant des opérations utilisateur (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 key-value store.

L'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 de transition d'état de Lokad. Nous avons publié le code source de notre event store en tant que logiciel libre.

Ce composant est simple: il persiste et sert les événements de manière fiable, en s'appuyant sur un key-value store distribué sous-jacent (Azure Blob Storage). Les événements sont censés être petits - 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 de projections. Encore une fois, en faisant "moins", Lokad élimine des classes entières de problèmes, tels que les attaques d'injection SQL, qui se produisent en raison des capacités de la couche de persistance.

Magasin de contenu adressable

Le magasin adressable de contenu (CAS) persiste les fichiers téléchargés sur la plateforme Lokad ou générés par les scripts Envision. Nous avons publié la source de notre stockage de contenu adressable en tant que logiciel libre.

Le CAS est destiné à prendre en charge les 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, fragmentés 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 brièveté, nous ne citerons 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 ordonner l'exécution des scripts Envision. Les "Thunks" sont 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.

Compiler

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 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 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 pour fournir des commentaires et des messages d'erreur significatifs au programmeur Envision pendant la rédaction du code. Après la plupart des frappes de clavier, 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 pour l'exécution de scripts Envision sans intervention manuelle. Le planificateur déclenche, planifie et séquence l'exécution de scripts Envision. Il fournit également des capacités d'alerte si les exécutions dévient de leurs délais attendus. 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 lors de la réception de fichiers, par exemple) ou la détection précoce de 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. Dans 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é 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 inopérante.

Le cluster de machines dédiées à Thunks est regroupé, de manière multi-locataire, dans tous les comptes. Cette fonctionnalité est essentielle pour maîtriser les coûts de calcul. Le cas d'utilisation typique de la chaîne d'approvisionnement implique un lot d'exécution par jour, généralement d'une durée de moins de 60 minutes. Le regroupement des ressources via une solution multi-locataire atténue largement les frais généraux associés aux ressources informatiques - 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 suggérons la série en quatre 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, on recommande la section 8 de notre FAQ Sécurité.