Traitement lean scalable pour supply chain

Joannes Vermorel

Avec l’avènement de cloud computing, il y a un peu plus d’une décennie, il est devenu simple d’acquérir des ressources informatiques à la demande (stockage, calcul, réseau) à pratiquement n’importe quelle échelle du moment que l’on est prêt à payer. Pourtant, bien qu’il soit aisé d’effectuer des calculs à grande échelle sur la plateforme cloud computing de votre choix, cela n’implique pas pour autant que cela en vaille le coût.

Chez Lokad, nous ne facturons pas nos clients par GB de stockage ni par CPU par heure. Au lieu de cela, le principal moteur de notre tarification, lorsqu’il s’agit de nos services professionnels, est la complexité du défi de la supply chain à relever en premier lieu. Naturellement, nous intégrons dans nos prix les ressources informatiques dont nous avons besoin pour servir nos clients, mais en fin de compte, chaque euro que nous dépensons sur Microsoft Azure – en termes de dépenses, nous sommes devenus un véritable client entreprise – est un euro que nous ne pouvons pas investir en R&D ou dans le Supply Chain Scientist qui gère le compte.

Ainsi, la plateforme logicielle de Lokad a été conçue selon le principe directeur que nous devrions être aussi lean 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 aussi économiquement que possible. Cela nous a conduits à une série de décisions quelque peu inhabituelles lors de la conception de Lokad.

Diff execution graphs. 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 très itératif : ajouter quelques lignes, analyser les données, rincer et répéter. Ces itérations sont nécessaires car les résultats obtenus à partir des données orientent fréquemment la suite des actions du data scientist. Pourtant, la plupart des outils de data science (eg. NumPy ou R) recalculent tout à partir de zéro chaque fois que le script est réexécuté. En revanche, Envision effectue un diff sur les graphes d’exécution successifs. Contrairement au diff traditionnel qui détecte les différences entre des fichiers, notre diff identifie les différences entre des graphes de calcul : il repère les nouveaux nœuds de calcul – qui doivent encore être traités. Pour tous les autres nœuds, les résultats ont déjà été calculés et sont recyclés à la place. Pour le Supply Chain Scientist, comparer 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 quelques centaines de mégaoctets qui différaient d’un script à l’autre).

Domain-driven datatypes. Probabilistic forecasting est une approche révolutionnaire pour supply chain : considérons tous les futurs possibles, au lieu de choisir 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 impliquant des calculs non triviaux. Ainsi, nous avons investi des efforts considérables pour optimiser cette algèbre afin d’exécuter des opérations à grande échelle sur des variables aléatoires tout en minimisant les coûts CPU. En particulier, nous prenons en compte de manière agressive le fait que, dans supply chain, la plupart des variables aléatoires représentent des probabilités en quantités réduites, typiquement pas plus que quelques dizaines d’unités². Comparé aux approches génériques destinées, par exemple, au calcul scientifique, cet angle spécifique au domaine offre deux ordres de grandeur d’accélération de calcul.

Defensive scalability. La plupart des langages de programmation destinés au traitement de données à grande échelle (e.g. Scala ou Julia) offrent des capacités remarquables pour distribuer les calculs sur de nombreux nœuds. Cependant, cela signifie que chaque ligne de code écrite peut potentiellement consommer une quantité arbitrairement grande de ressources informatiques. Il faut beaucoup de rigueur en ingénierie pour contrer les besoins apparemment toujours croissants de l’application au fur et à mesure que des modifications y sont apportées. En revanche, Envision adopte une posture 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. Cela explique pourquoi Envision ne comporte aucune boucle, par exemple, car il est pratiquement impossible d’offrir des performances prévisibles à la compilation lorsqu’un langage contient des boucles arbitraires.

Key-value storage only. Blob storage³ est l’approche de stockage de données clé-valeur la plus rentable au niveau du coût sur le cloud, avec des prix pouvant descendre jusqu’à environ 20 $ par To par mois. Lokad opère directement sur Blob Storage (avec des disques locaux pour le cache), nous ne disposons d’aucune base de données relationnelle ni de NoSQL – à l’exception de celles que nous avons construits nous-mêmes au-dessus du Blob Storage. 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. Plutôt que de micro-optimiser la friction aux limites, nous avons supprimé ces dernières complètement.

Bien que parvenir à un traitement de données lean et scalable pour votre supply chain puisse sembler n’être qu’une simple formalité pour des supply chains de grande envergure, le surcoût informatique lié au traitement de téraoctets de données est bien réel. Trop souvent, le système est soit trop coûteux, soit trop lent, et la friction finit par engloutir une bonne partie des bénéfices escomptés générés dès le départ par le système. Les coûts du cloud computing continuent de baisser, mais ne comptez pas sur une diminution de plus de 20 % par an, ainsi, 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 supply chain pilotée par les données d’une décennie ou plus.

Vous pouvez également consulter l’épisode de Lokad TV que nous avons réalisé sur la scalabilité en téraoctets pour supply chain.