CA3188740C - Systeme et procede d'optimisation d'un outil de simulation - Google Patents

Description

I
TITRE DE L'INVENTION
SYSTEME ET PROCEDE D'OPTIMISATION D'UN OUTIL DE SIMULATION
DOMAINE DE L'INVENTION
[0001]La presente invention concerne le domaine du traitement d'informations a grande echelle et, en particulier, a un systeme et un procede d'optimisation d'un outil de simulation.
CONTEXTE DE L'INVENTION

[0002]Elasticsearchmc est un moteur de recherche et d'analyse distribue, gratuit et ouvert pour tous les types de donnees, y compris textuelles, numeriques, geospatiales, structurees et non structurees. Elasticsearchmc est base sur Apache Lucenemc et a ete publie pour la premiere fois en 2010 par Elasticsearch N.V. (maintenant connu sous le nom d'Elastic). Connu pour ses API REST (API : application programming interface )> ou interface de programmation applicative; REST: Representational State Transfer )> i.e. un style d'architecture caracteristique des programmes qui s'appuient sur les proprietes inherentes des hypermedias et du protocole HTTP pour creer et modifier l'etat d'un objet accessible via une URL), sa nature distribuee, sa vitesse et son evolutivite, Elasticsearchmc est le composant central de Elastic Stackmc, un ensemble d'outils gratuits et ouverts pour l'ingestion, l'enrichissement, le stockage, l'analyse et la visualisation des donnees.
Communement appelee ELK Stackmc (ELK: Elasticsearchmc, Logstashmc et Kibanamc), Elastic Stackmc comprend une collection d'agents d'expedition legers connus sous le nom de Beatsmc pour envoyer des donnees a Elasticsearchmc.

[0003]Kibanamc est une application front-end gratuite et ouverte qui se trouve au-dessus de Elastic Stackmc, offrant des capacites de recherche et de visualisation des donnees pour les donnees indexees dans Elasticsearchmc.
Kibanamc sert egalement d'interface utilisateur pour la surveillance, la gestion et la securisation d'un cluster Elastic Stackmc, ainsi que le hub centralise pour les solutions integrees developpees sur la Elastic Stackmc. Kibanamc permet la recherche, l'affichage et la visualisation des donnees indexees dans Date Recue/Date Received 2023-02-06 Elasticsearchmc et l'analyse des donnees via la creation de graphiques a barres, de camemberts, de tableaux, d'histogrammes et de cartes. Une vue de tableau de bord combine ces elements visuels pour ensuite etre partages via un navigateur pour fournir des vues analytiques en temps reel dans de grands volumes de donnees a l'appui de cas d'utilisation tels que le risque d'entreprise et l'analyse decisionnelle.

[0004]Rmc est un environnement logiciel libre utilise pour le calcul statistique et les graphiques. II compile et s'execute sur une grande variete de plates-formes UNIXmc, Windowsmc et Mac0Smc. Rmc fournit une grande variete de techniques statistiques (modelisation lineaire et non lineaire, tests statistiques classiques, analyse de series chronologiques, classification, clustering, ...) et graphiques, et est hautement extensible.

[0005]Plumbermc est un systeme d'operation qui permet de creer une API Web en decorant un code source Rmc existant avec des commentaires de type roxygen2.

[0006]La taille et la complexite sans cesse croissantes des ensembles de donnees scientifiques modernes defient constamment les capacites des methodes de calcul statistique existantes. Le calcul parallele statistique haute performance est une solution prometteuse pour relever ces defis. Cependant, les techniques de calcul statistique parallele introduisent de nombreuses complexites de mise en ceuvre, entrainant un besoin de processus plus efficaces et rationalises. En reponse a ce besoin, il est connu d'utiliser pIRmc, un middleware leger et facile a utiliser pour le R-Engine riche en statistiques qui permet en outre la parallelisation dans le calcul statistique.

[0007]Node.Jsmc est un environnement d'execution JavaScript open source, multiplateforme et back-end qui s'execute sur un moteur et execute du code JavaScript en dehors d'un navigateur Web.

[0008]MongoDBmc est un programme de base de donnees multiplateforme dente document disponible en source. Classe comme programme de base de donnees NoSQL, MongoDBmc utilise des documents de type JSONmc avec des schemas facultatifs.
Date Recue/Date Received 2023-02-06

[0009]Les Pods Kubemetes MC sont les objets deployables les plus petits et les plus basiques de Kubemetesmc. Un Pod represente une instance unique d'un processus en cours d'execution dans un cluster.

[0010]On connait dans le domaine le brevet US10803401B2 (HAMMOND), de meme que les demandes de brevets US20210064346A1 (EXERTIER), US20180357047A1 (BROWN) et W02020136680A1 (SABHARWAL).
OBJETS DE L'INVENTION
[0011 ]Selon des realisations preferentielles de l'invention, on vise a integrer une interface applicative de simulation de donnees dans un tableau de bord delivre par un plugin Kibanamc. Cette capacite supplementaire ajoutee a la suite ELKIvIc necessite des composantes additionnelles : L'interface applicative (API) de simulation en Pythonmc et le systeme de file d'attente des taches (Pythonmc, NodeJsmc, MongoDBmc) et !Integration d'un nombre important de donnees a cheque simulation. Par exemple, on peut utiliser plus de 8 millions de donnees pour simuler une grande entreprise pendant 11 ans cheque mois.
[0012]Selon une realisation preferentielle de l'invention, Kibana Servermc, Node.Jsmc et R-Enginemc ou Pythonmc sont dans un meme Pod Kubemetesmc.
Du fait des specificites du R-Enginemc [1], on fait face a une complexite dans la communication (par ligne de commande dynamique) et dans les retours d'erreur entre l'API Kibanamc et R-Enginemc. De plus pour certains environnements cibles, lorsque R-Engine et Kibana-Server sont dans le meme Pod kubernetes, cela introduit une vulnerabilite.
[0013] Selon une realisation preferentielle, on propose un procede de simulation comprenant des &tapes de:
reception d'une premiere demande de simulation d'un agent par une interface applicative (API) et creation d'une tache de simulation;
verification par un premier service si la demande de simulation est une tache principale, si oui, le premier service cree des sous taches par entites pour effectuer la simulation en simultanee et un calcul de la simulation;
sinon, si la tache est une sous tache, on calcule une simulation pour une entite correspondante;
Date Recue/Date Received 2023-02-06 indexation de la simulation dans un deuxieme service;
mise a jour du statut de la simulation par le premier service;
compilation d'un resultat de generation de langage naturel dans le premier service;
interrogation du resultat de la simulation de l'agent par l'interface applicative (API) a intervalle regulier jusqu'a ce que la simulation soit completee;
requete du resultat de la simulation au deuxieme service; et transmission du resultat de simulation a l'interface applicative.
[0014]SeIon des realisations preferentielles, le premier service et deuxieme service sont installes dans un cluster Kubemetesmc. L'interface applicative (API) peut etre un plugin Kibanamc qui est installe sur un Pod d'un cluster Kubemetesmc. Le premier service peut comprendre Pythonmc et la librairie cliente MongoDBmc dans un Pod scalable sur un cluster Kubemetesmc. Le deuxieme service (28) peut comprendre Elasticsearchmc installe sur un cluster de machine virtuelle ou un cluster Kubernetesmc.
[0015]SeIon une realisation preferentielle, on propose egalement un systeme de simulation comprenant :
une interface applicative (API) configuree pour recevoir une premiere demande de simulation d'un utilisateur via un agent;
une file d'attente de travail installee dans un Pod d'un cluster Kubemetesmc pour recevoir la premiere demande de simulation de l'utilisateur pour repartir une charge de travail sur differentes instance d'un premier service;
et un engin analytique installe dans le Pod du cluster Kubemetesmc pour recevoir des resultats de la simulation et le transmettre a l'interface applicative (API).
[0016]D'autres objets, avantages et fonctions de la presente invention deviendront plus apparentes lors de la description suivante de modes de realisations possibles, donnes a titre d'exemples seulement, en relation aux figures suivantes.
Date Recue/Date Received 2023-02-06 BREVE DESCRIPTION DES FIGURES
[0017]La Figure 1 est un diagramme schematique d'un systeme representant un premier prototype, selon une realisation preferentielle de la presente invention.
[0018]La Figure 2 est un diagramme schematique montrant un procede d'operation du premier prototype, selon une realisation preferentielle de la presente invention.
[0019]La Figure 3 est un diagramme schematique d'un systeme representant un deuxieme prototype, selon une realisation preferentielle de la presente invention [0020]La Figure 4 est un diagramme schematique montrant un systeme, selon une realisation preferentielle de la presente invention.
[0021]La Figure 5 est un diagramme schematique montrant un procede d'operation, selon une realisation preferentielle de la presente invention.
[0022]La Figure 6 est un diagramme schematique montrant un systeme, selon une realisation preferentielle de la presente invention.
DESCRIPTION DES MODES DE REALISATIONS DE L'INVENTION
[0023]La presente invention est illustree plus en detail par les exemples non limitatifs suivants.
[0024]Comme l'appreciera la personne du métier a la lecture de la description suivante, divers aspects decrits ici peuvent etre mis en ceuvre sous la forme d'un dispositif, d'un procede ou d'un produit de programme informatique (par exemple, un support ou memoire lisible par ordinateur non transitoire ayant des instructions executables par ordinateur qui, une fois executees, executent les operations ou &tapes). Ainsi, ces aspects peuvent prendre la forme d'un mode de realisation entierement materiel, d'un mode de realisation entierement logiciel ou d'un mode de realisation combinant des aspects logiciels et materiels.
[0025]En outre, de tels aspects peuvent prendre la forme d'un produit de programme informatique stocke par un ou plusieurs supports de stockage Date Recue/Date Received 2023-02-06 lisibles par ordinateur ayant un code de programme lisible par ordinateur, ou des instructions, incorpores dans ou sur les supports de stockage. Tout support de stockage lisible par ordinateur approprie peut etre utilise, y compris les disques durs, les CD-ROM, les dispositifs de stockage optiques, les dispositifs de stockage magnetiques et/ou toute combinaison de ceux-ci.
[0026]SeIon une realisation preferentielle de l'invention, Kibana Servermc, Node.Jsmc et R-Enginemc ou Pythonmc et tous autres engins analytiques sont dans un meme Pod Kubemetesmc. Du fait des specificites du R-Enginemc [1], les inventeurs ont fait face a une complexite dans la communication (par ligne de commande dynamique) et dans les retours d'erreur entre l'API Kibanamc et R-Enginemc. De plus pour certains environnements cibles, lorsque R-Enginemc et Kibana-Servermc sont dans un meme Pod Kubemetesmc, cela introduit une vulnerabilite.
[0027]Selon une autre realisation preferentielle de l'invention, on fait resider R-Enginemc separement et on invoque ce demier par API REST. Dans ce sens, l'infrastructure Backend comprend : Kibanamc pour la visualisation;
ElasticSearchmc pour la persistance; et un mecanisme ou moyens (PLUMBERmc) pour transformer les fonctions R en API REST et construire le serveur http.
[0028]Le PLUMBERmc identifie et achemine les requetes http pour invoquer les services du R-Enginemc. Dans le serveur Kibanamc, un service invoque l'API
REST et avec le retour, met a jour ElasticSearch et construit la reponse retournee par l'API "Kibanamc serveur" au client pour actualiser son tableau de bord avec le scenario demande. Contrairement au cas standard, les clients d'un tableau de bord ne font pas que le visualiser, ils influent sur sa visualisation via la simulation de scenario.
[0029]II faut prendre en consideration que plusieurs clients d'un meme tableau de bord invoquent concurremment les services R-Enginemc. D'apres une realisation preferentielle de l'invention, on doit donc lancer plusieurs threads (un par simulation), ce qui nativement est compromis d'une part par le Threading collaboratif de R-Enginemc et d'autre part, par le cdte single thread http du Date Recue/Date Received 2023-02-06 serveur construit par PLUMBERmc. Or ce dernier ne peut pas interpreter plus d'une requete http a la fois.
[0030]Ces limites technologiques rendent incertaines la disponibilite et la consistance des visualisations, consequence d'un double risque de traitement sequentiel des scenarios par R-Enginemc et PLUMBERmc. Le traitement sequentiel occasionne des expirations de delai (time out) et une inconsistance des tableaux de bord qui ne refleteront plus le scenario de l'utilisateur pour cause d'interpretations erronees.
[0031 plus precisement, si les scenarios sont loges en memoire par R-ENGINEmc, tout traitement sur ces scenarios sera atom ique : R-ENGINEmc ne redonnera pas la main aux processus concurrents tant que le scenario ne sera pas construit. Cela est particulierement dommageable pour les scenarios tres courts, qui restent dans l'attente inutilement de scenarios plus longs. Le fait que PLUMBERmc soit entrelace dans les scripts de Rmc, fait que les deux limites technologiques "single http" de PLUMBERmc et "single threaded" du R-ENGINEmc ne peuvent pas etre abordees separement.
[0032]Dans ce sens, traiter la problematique "single http" de PLUMBERmc laisse une forte incertitude effective pour les scenarios CPU intensive, alors que lancer plusieurs instances du R-Enginemc necessite de gerer le goulot d'etranglement pose par le cdte single http de PLUMBERmc. Une autre problematique s'ajoute alors : la limite de la capacite de traitement des instances de Rmc, suite aux appels http. II faut donc parvenir a determiner une composante de balancement pour garantir un taux d'utilisation acceptable (>90 %) de chaque instance du R-Enginemc.
[0033]La parallelisation des processus en Machine Learning, et dans notre cas en simulation, fait actuellement l'objet d'etudes de R&D sur differents aspects comme nous pouvons le constater dans la litterature [2]. Nous avons du par consequent developper une nouvelle methode de parallelisation afin de tenter de repondre a nos contraintes.
[0034]Nous pouvons voir dans la litterature que la parallelisation des traitements d'indexation et bulk ElasticSearch [3][4] est un sujet traite via des plateformes de repartiteur de charges (Load Balancer) generiques. Ceux-ci Date Recue/Date Received 2023-02-06 demandent une integration lourde en termes d'infrastructure ainsi que de coat de licence et maintenance, ce qui amene une complexite avec un surdimensionnement qui n'est pas utile dans plusieurs cas d'utilisation.
[0035]Les solutions existantes ne reglent qu'un seul des deux obstacles a surmonter. Leur application independante dans notre contexte s'expose a un mauvais taux d'utilisation des instances du R-ENGINEmc.
[0036]D'apres des realisations preferentielles de l'invention, on fait collaborer des scripts R-ENGINEmc avec un moteur d'indexation ElasticSearchmc. Ceci permet a un utilisateur de simuler et d'integrer des scenarios pour realiser une analyse des resultats sur plusieurs annees.
[0037]Au lieu d'utiliser un process realisant plusieurs traitements, une realisation preferentielle de la presente invention utilise plusieurs process traitant en parallele. Pour faire face a la chute du taux d'utilisation, nous avons enrichi notre hypothese afin que chaque simulation dans le pool devienne un consommateur independant des autres. Ainsi la structure se transforme en une liste FIFO (First In First Out), chaque simulation dans le pool qui finit va chercher une requete http de la liste FIFO. Dans cette implementation, la consommation des simulations se fait par appel recursif. L'analyse des logs pour un banc d'essai de plusieurs lots de 500 requetes http, de duree aleatoire, avec 2,8,16 et 32 instances du R-ENGINEmc, montrait qu'en tout temps le nombre de taches asynchrones en cours etait egal au nombre d'instances de R-ENGINEmc.
[0038]Pour optimiser ceci, il nous a fallu decomposer le code des simulations en elements de base assez petits pour obtenir des appels en parallele sans la presence d'un gros element qui aurait genere de l'attente, tout en gardant un niveau de granularite assez eleve pour que le temps ne soit pas exclusivement pris en appel de procedure entre NodeJSmc, PLUMBERmc et Rmc.
[0039]L'invocation des services Rmc par API REST s'est trouvee compromise par le caractere single http du serveur qui prend en charge les API. Ni le multiplexage par fonction ou par port n'ont permis de lever cet obstacle, s'etant traduit respectivement soit par un refus de connexion ou un traitement sequentiel des API. Quant a l'obstacle pose par le threading collaboratif, nos Date Recue/Date Received 2023-02-06 taches etant CPU intensive, et de surcroit, !ogees en memoire, devenaient des operations atomiques : ce qui est redhibitoire pour de courtes simulations.
[0040]Le lancement de plusieurs instances resultait en un taux d'utilisation des instances imprevisibles et des techniques d'affectation ne pouvant s'appliquer qu'a deux instances. Nous avons realise un avancement technologique, un repartiteur de charge (Load Balancer) specialement adapte aux cas Ca l'on peut mettre une relation d'un pour un entre l'instance de serveur http et l'instance de service invoquee en les faisant toumer dans le meme process.
[0041]Cet avancement s'appuie sur la notion de pool de promesses, une notion inexistante dans Node.Jsmc que nous avons du developper. Ce pool prend la forme d'un tableau de promesses qui recursivement, en exploitant la capacite de chainage de promesses, va chercher dans une file FIFO la prochaine requete a executer.
[0042]Cet avancement est reproductible et pourra s'appliquer pour tout Framework construisant les API REST directement a partir du script via des decorateurs. Comme experimente, de tels serveurs sont incapables d'ecouter plusieurs requetes http : ce qui amene un goulot d'etranglement et nuit a la concurrence. Sans cet avancement, nous n'aurions pas pu implementer notre scenario de simulations multiples.
[0043]Cette solution nous permet d'obtenir un resultat en 5 minutes, ce qui est acceptable mais qui n'atteint pas un objectif de 3 minutes qui serait souhaitable.
Afin d'ameliorer les temps d'indexation de donnees, on peut utiliser Pythonmc pour realiser les bulks d'indexation des 8 millions de lignes. En passant les scripts de R-Enginemc a Pythonmc il est possible de garantir une meilleure integration technique globale.
[0044]Afin de rendre dynamiques les visualisations de Kibana via la simulation de scenarios, selon une realisation preferentielle, on rassemble Kibanamc, Node.jsmc et R-Enginemc sur le meme cluster Kubemetesmc dans l'architecture.
La communication par ligne de commande s'est revelee non generique, avec une gestion d'erreurs peu robuste entre Kibana et R-Engine. II est donc preferable de faire resider le R-ENGINEmc dans un Pod Kubemetesmc different et d'invoquer ses services par appel http REST. Pour construire l'infrastructure Date Recue/Date Received 2023-02-06 REST, PLUMBERmc construit le serveur qui ecoute les appels REST et invoque les fonctions d'un script, via les decorations dans le script Rmc. Cependant, la nature CPU intensive des scenarios est incompatible avec l'aspect single threaded de R-Enginemc.
[0045]Nous avons donc realise une premiere etude preliminaire et construit un banc de test de plusieurs usagers (robots) langant concurremment via Kibanamc les scenarios usuels avec differentes tailles et complexites. Nous avons ainsi mesure la duree de completion des scenarios.
[0046]En reference a la Figure 2, un premier prototype implique plusieurs processus : Kibanamc, ElasticSearchmc, PLUMBERmc pour construire le serveur adosse au R-Enginemc. Dans ce procede, quand un utilisateur 10 demande une simulation 12 via un agent 14, l'appel REST est soumis a Kibanamc, soit une simulation API 16, qui loge un second appel http, soit un POST simulation 18, vers le serveur 20 genere par PLUMBERmc. Ce dernier serveur 20 invoque, via une demande de calcul de simulation 22, les fonctions 24 du R-Enginemc pour effectuer la simulation et retoume les donnees de simulation, soit l'indexation de la simulation 26, qui serviront a la mise a jour ElasticSearchmc dans Elasticmc et a l'API Kibanamc pour les relayer a l'utilisateur 30, 32.
[0047]Nos essais ont cependant montre que tant qu'une des URL vers la fonction est en cours, invoquer la meme fonction avec la seconde URL generait une erreur de connexion.
[0048]Nous avons donc du travailler a !Integration d'un repartiteur de charge ( load balancer ) et realiser de nouveaux travaux de prototypage. II existe une limitation entre PLUMBERmc et Rmc : si une simulation est en cours, alors aucune nouvelle demande ne peut passer. A ce stade il etait impossible de determiner si le probleme venait de PLUMBERmc n'etant pas capable d'ecouter plus qu'une connexion http.
[0049]Nous avons par la suite initie la construction de deux serveurs PLUMBERmc sur deux ports differents. Les essais ont valide le concept, le lancement simultane des deux requetes etait accept& Cependant l'examen des logs d'execution montrait qu'une des simulations devait attendre que l'autre finisse avant de debuter, ce qui etait redhibitoire.
Date Recue/Date Received 2023-02-06

11 [0050] En effet notre plateforme multi-utilisateur et multi-client permet d'obtenir des temps optimaux sans demultiplier l'infrastructure, ce qui reduit les coats de location et de maintenance. De ce fait nous ne pouvons accepter une solution ou un utilisateur/client attendrait que la simulation d'un autre client soit terminee avant que la sienne commence.
[0051 ] Une analyse approfondie de nos resultats nous a conduits a identifier le risque de deux obstacles imbriques : l'aspect single thread http de PLUMBERmc (que nous venions de resoudre par repartition de charge ou load balancing ) et le caractere single threaded )> du R-ENGINEmc. Plus precisement, les donnees de simulation sont chargees entierement en memoire par R-ENGINEmc. Les operations en memoire &tent atomiques, leur traitement ne peut pas etre interrompu : ce qui bloque les autres traitements concurrents.
Les courtes simulations sont alors penalisees car elles attendent la fin des plus longues.
[0052]Nous avons revu nos hypotheses en consequence, pour que les instances de serveur PLUMBERmc (par port) s'executent sur des processus separes. Cette hypothese part du principe que le script Rmc s'execute sur le meme process que le serveur PLUMBERmc qui l'a invoque. Donc indirectement, il y aura autant d'instances du R-ENGINEmc que de serveurs PLUMBERmc. Les process s'executent soit en parallele sur des processeurs separes et/ou en multithreading avec une isolation memoire, ce qui garantit la concurrence.
[0053]Pour atteindre nos objectifs, nous avons de nouveau revu notre approche afin que la construction des serveurs PLUMBERmc/port s'effectue dans des processus differents. Nous avons construit un nouveau banc de test, avec deux instances langant deux serveurs PLUMBERmc, ecoutant sur la meme adresse IP et sur deux ports differents.
[0054] Notre test consistait a lancer en meme temps deux simulations de duree 30s et 15s et evaluer si le temps d'execution etait inferieur a leur somme (45s).
Les simulations se sont terminees en 32s, ce qui montrait que nous etions parvenus a depasser l'obstacle du single http de PLUMBERmc et du single threaded du R-ENGINEmc.
Date Recue/Date Received 2023-02-06

12 [0055]Grace a ce test, nous pouvons confirmer que les taches se lancent bien en parallele et que les resultats obtenus donnent des acces paralleles.
[0056]En reference aux Figures 3 a 6, un deuxieme prototype implique plusieurs processus : Kibanamc, ElasticSearchmc, MongoDBmc pour construire les Pod Kubemetesmc 11 adosse au R-Enginemc avec Pythonmc Le diagramme represente les interactions entre les differents acteurs (clients, services ou persistance de donnees) ainsi la sequence chronologique des differents evenements.
[0057]Le client ou utilisateur 10 via l'agent 14 demarre une nouvelle simulation 12, une nouvelle tache 34 est creee par l'Api de simulation 16. Le service Pythonmc 38 va prendre la prochaine tache non traitee 35 et l'executer. Le service Pythonmc verifie en effectuant une requete 40 aupres du service MongoDBmc 36 s'il y a une nouvelle tache. Cette verification fait partie d'un processus qui est repete dans le bloc 37.
[0058]Le service Python 38 verifie dans le bloc 39 le type de la tache 40 :
s'il s'agit d'un type de tache principale 42, le service Python 38 distribue le traitement de la tache en creant une sous tache 44 par entite (une entite est un ensemble de donnees sur lesquels une simulation peut etre appliquee de fa9on coherente), sinon le service effectue le calcul de la simulation 46 pour l'entite.
Une simulation peut etre executee en parallele en fonction du nombre d'instances du service Pythonmc et du nombre d'entites. Des qu'une sous tache 44 est completee, le resultat de la simulation est indexe 48 dans Elasticmc 28. Lorsque toutes les sous taches d'une simulation sont completees : le statut de la tache principale est mis a jour 50 et le resultat de generation de langage nature! ou Natural Laguage Generation: NLG 52 de chaque entite est compile afin un resultat agrege sur l'ensemble des entites traitees.
[0059]Pendant ce temps, l'agent 14 requete le resultat de la simulation 54 a l'API de simulation 16 a intervalle regulier jusqu'a ce que la simulation soit completee. L'API de simulation 16 requete le resultat de la simulation 56 au deuxieme service 28, soit a Elasticmc. Le deuxieme service 28 transmet ensuite le resultat de la simulation 58 a l'API de simulation 16.
Date Recue/Date Received 2023-02-06

13 [0060]Dans ce procede, quand un utilisateur 10 demande une simulation 12 via un agent 14, l'appel REST est soumis a Kibanamc, soit une simulation API 16, qui loge un second appel http, soit une nouvelle tache de simulation 34, vers le serveur 36 genere par MongoDBmc.
[0061]Classiquement, ce cas de figure est adresse par l'ajout de la requete http dans une file que les serveurs PLUMBERmc consomment. Chaque requete dans ce sens a un hash construit a partir de: ID Simulation, ID Tableau de bord et ID client. Ce hash evite de refaire une simulation. De plus, combine avec la notion de favori, il permet d'anticiper pour generer a l'avance les simulations pendant les periodes creuses. Notre problematique reside ici au niveau de l'utilisateur : comment assigner chaque requete a un serveur PLUMBERmc tout en garantissant un taux d'utilisation des instances du R-ENGINEmc superieur a 80%.
[0062]Selon des realisations preferentielles de l'invention, le deuxieme prototype s'adressant a des entreprises de grande taille, l'utilisation des instances doit etre proche de 100%. Non seulement pour pouvoir scaler ou etendre a plus de deux instances sans perte de taux d'utilisation, mais aussi pour eviter les problemes de timeout lies a l'utilisation d'ecoute sur des ports http, qui est naturellement limitee en temps.
[0063]En effet, pour une simulation, les tests se decomposent sur le lancement de plusieurs processus en parallele. II faut attendre que chacun des processus ait repondu pour obtenir une reponse globale. Donc lorsqu'un processus met beaucoup plus de temps que les autres pour repondre, nous observons une attente de tous les autres processus avant de terminer globalement. Ceci diminue drastiquement le taux d'utilisation dans notre cas, car il n'est pas possible d'identifier a l'avance les processus les plus longs et donc de les repartir sur les differentes instances Pythonmc.
[0064]La parallelisation des processus en apprentissage automatique ou Machine Learning , et dans notre cas en simulation en simultanee, fait actuellement l'objet d'etudes de R&D (Recherche et Developpement) sur differents aspects, comme nous pouvons le constater dans la litterature. Nous avons par consequent developpe une methode de parallelisation afin de tenter Date Recue/Date Received 2023-02-06

14 de repondre a nos contraintes. La parallelisation doit permettre d'effectuer plusieurs taches de Machine Learning )> en meme temps, en prenant en compte la prediction du temps requis pour chaque tache de Machine Learning afin de repartir ces taches sur plusieurs processus Python 38. Le but etant de repartir le plus possible l'utilisation de tous les POD Kubemetes Pythonmc 24 selon un critere de temps de simulation prevue et non pas selon un nombre de simulation, afin que le temps de la simulation globale soit le plus court possible.
[0065] Les revendications ne doivent pas etre limitees dans leur portee par les realisations preferentielles illustrees dans les exemples, mais doivent recevoir l'interpretation la plus large qui soit conforme a la description dans son ensemble.
REFERENCES
[1] SHAH, Neil, KORA, Guruprasad, BREIMYER, Paul, et al. pR: Enabling Automatic Parallelization of Data-Parallel Tasks and Interfacing Parallel Computing Libraries in R with Application to Fusion Reaction Simulations. The, 2010. http://nshah.net/publications/pR applications.useR.2010.pdf [2] Memeti, S., Pllana, S., Binotto, A. et al. Using meta-heuristics and machine learning for software optimization of parallel computing systems: a systematic literature review. Computing 101, 893-936 (2019).
https://doi.orq/10.1007/s00607-018-0614-9 [3] Li, Y.; Jiang, Y.; Gu, J.; Lu, M.; Yu, M.; Armstrong, E.M.; Huang, T.;
Moroni, D.; McGibbney, L.J.; Frank, G.; Yang, C. A Cloud-Based Framework for Large-Scale Log Mining through Apache Spark and Elasticsearch. Appl.
Sci. 2019,9, 1114. https://doi.ord/10.3390/app9061114 [4] Kumar P., Kumar P., Zaidi N., Rathore V.S. (2018) Analysis and Comparative Exploration of Elastic Search, MongoDB and Hadoop Big Data Processing. In: Pant M., Ray K., Sharma T., Rawat S., Bandyopadhyay A. (eds) Soft Computing: Theories and Applications. Advances in Intelligent Systems and Computing, vol 584. Springer, Singapore. https://doi.ord/10.1007/978-981-Date Recue/Date Received 2023-02-06

Claims (11)

REVENDICATIONS

1. Procédé de simulation comprenant des étapes de:
reception d'une première demande de simulation (12) d'un agent (14) par une interface applicative (16) et creation d'une tâche de simulation (34);
verification par un premier service (38) si la demande de simulation (12) est une tâche principale (42), si oui, le premier service (38) crée des sous tâches (44) par entités pour effectuer la simulation en simultanée et un calcul de la simulation;
sinon, si la tâche (34) est une sous tâche, on calcule (46) la simulation pour une entité correspondante;
indexation (48) de la simulation dans un deuxième service (28);
mise a jour (50) du statut de la simulation par le premier service (38);
compilation d'un résultat de generation de langage nature! (52) dans le premier service (38);
interrogation (54) du résultat de la simulation de l'agent (14) par l'interface applicative (16) a intervalle régulier jusqu'a ce que la simulation soit complétée;
requête (56) du résultat de la simulation au deuxième service (28);
et transmission (58) du résultat de simulation a l'interface applicative (16).

2. Le procédé selon la revendication 1, dans lequel le premier service (38) et deuxième service (28) sont installés dans un cluster Kubernetes (11).

3. Le procédé selon la revendication 1, dans lequel !Interface applicative (16) est un plugin Kibana, Kibana étant installé sur un Pod d'un cluster Kubemetes (11).
Date Recue/Date Received 2023-02-06

4. Le procédé selon la revendication 1, dans lequel le premier service (38) comprend Python et la librairie cliente MongoDB dans un Pod scalable sur un cluster Kubernetes (11).

5. Le procédé selon la revendication 1, dans lequel le deuxième service (28) comprend Elasticsearch installé sur un cluster de machine virtuelle ou un cluster Kubernetes (11).

6. Un système de simulation comprenant :
une interface applicative (16) configurée pour recevoir une première demande de simulation (12) d'un utilisateur via un agent (14);
une file d'attente de travail installée dans un Pod d'un cluster Kubemetes (11) pour recevoir la première demande de simulation (12) de l'utilisateur pour répartir une charge de travail sur différentes instances d'un premier service (38); et un engin analytique installé dans le Pod du cluster Kubernetes (11) pour recevoir des résultats de la simulation et le transmettre (58) a l'interface applicative (16).

7. Le système selon la revendication 6, dans lequel l'interface applicative (16) est un plugin Kibana et utilise Kibana comme serveur applicatif.

8. Le système selon la revendication 6, dans lequel l'engin analytique est configure pour :
recevoir d'une première demande de simulation (12) d'un agent (14) par une interface applicative (16) et creation d'une tâche de simulation (34);
verifier par le premier service (38) si la demande de simulation (12) est une tâche principale (42), si oui, le premier service (38) crée des sous tâches (44) par entités pour effectuer la simulation en simultanée et un calcul de la simulation;
sinon, si la tâche (34) est une sous tâche, on calcule (46) la simulation pour une entité correspondante;
Date Recue/Date Received 2023-02-06 indexer (48) la simulation dans un deuxième service (28);
mettre a jour (50) du statut de la simulation par le premier service (38);
compiler un résultat de generation de !engage nature! (52) dans le premier service (38);
interroger (54) un résultat de la simulation de l'agent (14) par l'interface applicative (16) a intervene régulier jusqu'a ce que la simulation soit complétée;
requérir (56) le résultat de la simulation au deuxième service (28);
et transmettre (58) du résultat de simulation a l'interface applicative (16).

9. Le système selon la revendication 8, dans lequel le premier service (38) comprend Python et MongoDB installés dans des Pods du cluster Kubemetes (11)

10.Le système selon la revendication 8, dans lequel le deuxième service (28) comprend Elasticsearch installé dans des Pods du cluster Kubemetes.

11. Mémoire lisible par ordinateur stockant des instructions executables par ordinateur qui, une fois exécutées, exécutent des operations de :
reception d'une première demande de simulation (12) d'un agent (14) par une interface applicative (16) et creation d'une tâche de simulation (34);
verification par un premier service (38) si la demande de simulation (12) est une tâche principale (42), si oui, le premier service (38) crée des sous tâches (44) par entités pour effectuer la simulation en simultanée et un calcul de la simulation;
sinon, si la tâche (34) est une sous tâche, on calcule une simulation (46) pour une entité correspondante;
indexation (48) de la simulation dans un deuxième service (28);
Date Recue/Date Received 2023-02-06 mise a jour (50) du statut de la simulation par le premier service (38);
compilation d'un résultat de generation de langage nature! (52) dans le premier service (38);
interrogation (54) du résultat de la simulation de l'agent (14) par l'interface applicative (16) a intervalle régulier jusqu'a ce que la simulation soit complétée;
requête (56) du résultat de la simulation au deuxième service (28);
et transmission (58) du résultat de simulation a l'interface applicative (16).
Date Recue/Date Received 2023-02-06