Traitement évolutif et économe pour les chaînes d'approvisionnement

Joannes Vermorel

Avec l’avènement du cloud computing, il y a un peu plus d’une décennie, il est devenu facile d’acquérir des ressources informatiques à la demande (stockage, calcul, réseau) à grande échelle, à condition d’être prêt à payer pour cela. Cependant, bien qu’il soit facile d’effectuer des calculs à grande échelle sur la plateforme de cloud computing de votre choix, cela ne signifie pas que cela en vaudra le coût.

Chez Lokad, nous ne facturons pas à nos clients en fonction du Go de stockage ou du CPU par heure. Au lieu de cela, le principal facteur déterminant notre tarification, lorsque vous optez pour nos services professionnels, est la complexité du défi de la chaîne d’approvisionnement à résoudre en premier lieu. Naturellement, nous prenons en compte les ressources informatiques dont nous avons besoin pour servir nos clients dans nos prix, mais en fin de compte, chaque euro que nous dépensons sur Microsoft Azure - en termes de dépenses, nous sommes devenus un client “véritablement” entreprise - est un euro que nous ne pouvons pas dépenser en R&D ou en Supply Chain Scientist qui s’occupe du compte.

Ainsi, la plateforme logicielle Lokad a été conçue selon le principe directeur selon lequel nous devrions être aussi économes que possible en termes de ressources informatiques¹. Le défi n’est pas de traiter 1 To de données - ce qui est facile - mais de traiter 1 To de données le moins cher possible. Cela nous a conduits à prendre une série de décisions quelque peu “inhabituelles” lors de la conception de Lokad.

Graphes d’exécution différentiels. Les Supply Chain Scientists - comme les autres data scientists - n’écrivent généralement pas des centaines de lignes de code d’un seul coup avant de tester leur code sur les données. Le processus est généralement hautement incrémental : ajouter quelques lignes, traiter les données, rincer et répéter. Ces itérations sont nécessaires car les résultats obtenus à partir des données guident fréquemment ce que le data scientist fera ensuite. Cependant, la plupart des outils de science des données (par exemple NumPy ou R) recalculent tout à partir de zéro chaque fois que le script est réexécuté. En revanche, Envision effectue une différence sur les graphes d’exécution successifs. Contrairement à une différence traditionnelle qui trouve les différences entre les fichiers, notre différence trouve les différences entre les graphes de calcul : la différence identifie les nouveaux nœuds de calcul - qui doivent encore être calculés. Pour tous les autres nœuds, les résultats ont déjà été calculés et sont “recyclés”. Pour le Supply Chain Scientist, la différence entre les graphes d’exécution ressemble à une exécution ultra-rapide où des téraoctets de données sont traités en quelques secondes (indice : Lokad n’a pas traité des téraoctets en quelques secondes, seulement les quelques centaines de mégaoctets qui différaient d’un script à l’autre).

Types de données axés sur le domaine. Les prévisions probabilistes sont une approche révolutionnaire pour la chaîne d’approvisionnement : considérons tous les futurs possibles, au lieu d’élire un futur comme s’il était garanti de se réaliser. Malheureusement, le traitement des distributions de probabilité nécessite une algèbre des distributions qui implique des calculs non triviaux. Ainsi, nous avons investi des efforts importants pour optimiser cette algèbre afin d’effectuer des opérations à grande échelle sur les variables aléatoires à un coût minimal en termes de CPU. En particulier, nous prenons en compte de manière agressive le fait que, dans la chaîne d’approvisionnement, la plupart des variables aléatoires représentent des probabilités en petites quantités, généralement pas plus d’une dizaine d’unités². Comparé aux approches génériques destinées, par exemple, au calcul scientifique, l’angle spécifique au domaine permet d’obtenir un gain de vitesse de calcul de deux ordres de grandeur.

Scalabilité défensive. La plupart des langages de programmation destinés au traitement de données à grande échelle (par exemple Scala ou Julia) offrent des capacités énormes pour distribuer les calculs sur de nombreux nœuds. Cependant, cela signifie que chaque ligne de code écrite a la possibilité de consommer une quantité arbitrairement importante de ressources informatiques. Il faut beaucoup de discipline en ingénierie pour contrer les besoins apparemment croissants de l’application à mesure que les modifications sont intégrées. En revanche, Envision adopte une approche défensive : le langage a été conçu pour dissuader les Supply Chain Scientists d’écrire du code qui serait extrêmement coûteux à mettre à l’échelle. C’est pourquoi Envision n’a pas de boucles, par exemple, car il est presque impossible d’offrir des performances prévisibles au moment de la compilation lorsque le langage contient des boucles arbitraires.

Stockage clé-valeur uniquement. Le stockage de blob³ est l’approche de stockage de données la plus économique offerte par le cloud, avec des prix pouvant descendre jusqu’à 20 $ par To par mois environ. Lokad fonctionne directement sur le stockage de blob (plus des disques locaux pour le cache), nous n’avons pas de bases de données relationnelles ou NoSQL - sauf celles que nous avons construites nous-mêmes sur le stockage de blob. En pratique, notre couche de stockage est profondément intégrée à Envision, le langage dédié à l’optimisation de la Supply Chain Quantitative au sein de Lokad. Cela nous permet d’éviter les couches de surcharge qui existent traditionnellement à l’intersection entre l’application et sa couche d’accès aux données. Au lieu de micro-optimiser les frictions aux frontières, nous avons supprimé ces frontières.

Bien que l’obtention d’un traitement de données évolutif et efficace pour votre chaîne d’approvisionnement puisse sembler être une “technicalité” pour les chaînes d’approvisionnement de taille importante, les coûts informatiques liés au traitement de téraoctets de données sont bien réels. Trop souvent, le système est soit trop cher, soit trop lent, et la friction finit par consommer une bonne partie des avantages escomptés générés par le système en premier lieu. Les coûts du cloud computing diminuent encore, mais ne vous attendez pas à plus de 20 % par an, donc laisser le progrès général du matériel informatique faire sa magie n’est plus vraiment une option à moins d’être prêt à retarder votre chaîne d’approvisionnement basée sur les données d’une autre décennie environ.

Vous pouvez également consulter l’épisode de Lokad TV que nous avons produit sur la scalabilité des téraoctets pour les chaînes d’approvisionnement.