System and method for optimizing a simulation tool

Abstract

The aim of the invention is to integrate a data simulation application programming interface into a dashboard delivered by a KibanaTM plug-in. This extra capability added to the ELK StackTM requires additional components: The Python simulation application programming interface (API) and the task queueing system (PythonTM, Node.JsTM, MongoDBTM) and the integration of a large amount of data in each simulation.

Description

TITLE OF THE INVENTION SYSTEM AND METHOD FOR OPTIMIZING A SIMULATION TOOL FIELD OF INVENTION

[0001] The present invention relates to the field of large-scale information processing and, in particular, to a system and method for optimizing a simulation tool. CONTEXT OF THE INVENTION

[0002] Elasticsearch MC Elasticsearch is a distributed, free, and open search and analytics engine for all types of data, including text, numeric, geospatial, structured, and unstructured data. MC is based on Apache Lucene MCand was first released in 2010 by Elasticsearch NV (now known as Elastic). Known for its REST APIs (API: "application programming interface"; REST: "Representational State Transfer," i.e., an architectural style characteristic of programs that rely on the inherent properties of hypermedia and the HTTP protocol to create and modify the state of an object accessed via a URL), its distributed nature, its speed, and its scalability, Elasticsearch MC is the central component of Elastic Stack MC , a set of free and open-source tools for data ingestion, enrichment, storage, analysis, and visualization. Commonly known as the ELK Stack MC (ELK: Elasticsearch) MC Logstash MC and Kibana MC ), Elastic Stack MC includes a collection of lightweight shipping agents known as Beats MCto send data to Elasticsearch MC .

[0003] Kibana MC is a free and open-source "front-end" application that sits on top of Elastic Stack MC providing search and data visualization capabilities for data indexed in Elasticsearch MC Kibana MC It also serves as a user interface for monitoring, managing, and securing an Elastic Stack cluster. MC as well as the centralized hub for integrated solutions developed on the Elastic Stack MC Kibana MC allows searching, displaying and visualizing indexed data in Elasticsearch MCand data analysis through the creation of bar charts, pie charts, tables, histograms, and maps. A dashboard view combines these visual elements and can then be shared via a browser to provide real-time analytical views in large volumes of data to support use cases such as enterprise risk and decision analysis.

[0004] R MC is a free software environment used for statistical computing and graphics. It compiles and runs on a wide variety of UNIX platforms. MC Windows MC and macOS MC R. MC provides a wide variety of statistical techniques (linear and non-linear modeling, classical statistical tests, time series analysis, classification, clustering, ...) and graphical techniques, and is highly extensible.

[0005] Plumber MCis an operating system that allows you to create a Web API by decorating R source code MC existing with roxygen2 type comments.

[0006] The ever-increasing size and complexity of modern scientific datasets constantly challenge the capabilities of existing statistical computing methods. High-performance parallel statistical computing (HPSC) is a promising solution to address these challenges. However, parallel statistical computing techniques introduce numerous implementation complexities, leading to a need for more efficient and streamlined processes. In response to this need, the use of parallel computing (pR) is known. MC , a lightweight and easy-to-use middleware for the R-Engine rich in statistics which also allows parallelization in statistical calculation.

[0007] Node.js MCis an open source, cross-platform, "back-end" JavaScript runtime environment that runs on an engine and executes JavaScript code outside of a web browser.

[0008] MongoDB MC MongoDB is a cross-platform, document-oriented database program available as source code. Classified as a NoSQL database program, MongoDB MC uses JSON type documents MC with optional diagrams.

[0009] Kubernetes Pods MC are the smallest and most basic deployable objects in Kubernetes MC A Pod represents a single instance of a process running in a cluster.

[0010] We know in the field the US patent US10803401 B2 (HAMMOND), as well as the patent applications US20210064346A1 (EXERTIER), US20180357047A1 (BROWN) and W02020136680A1 (SABHARWAL). OBJECTS OF THE INVENTION

[0011] According to preferred embodiments of the invention, the aim is to integrate a data simulation application interface into a dashboard delivered by a Kibana plugin. MC This additional capability was added to the ELK suite. MC requires additional components: The simulation application interface (API) in Python MC and the task queue system (Python) MC NodeJs MC MongoDB MC ) and the integration of a large amount of data into each simulation. For example, more than 8 million data points can be used to simulate a large company for 1 year, month by month.

[0012] According to a preferred embodiment of the invention, Kibana Server MC Node.js MC and R-Engine MC or Python MC are in the same Kubernetes Pod MC Due to the specific characteristics of the R-Engine MC[1], we face a complexity in communication (via dynamic command line) and in error feedback between the Kibana API MC and R-Engine MC Furthermore, for some target environments, when R-Engine and Kibana-Server are in the same Kubernetes Pod, this introduces a vulnerability.

[0013] According to a preferred embodiment, a simulation process is proposed comprising the following steps: receiving a first simulation request from an agent via an application interface (API) and creating a simulation task; checking by a first service whether the simulation request is a main task, if so, the first service creates subtasks per entity to perform the simulation simultaneously and calculates the simulation; otherwise, if the task is a subtask, a simulation is calculated for a corresponding entity; indexing the simulation in a second service; updating the simulation status by the first service; compiling a natural language generation result in the first service; querying the agent simulation result by the application interface (API) at regular intervals until the simulation is completed; requesting the simulation result from the second service; and transmitting the simulation result to the application interface.

[0014] According to preferred implementations, the first and second services are installed in a Kubernetes cluster. MC The application interface (API) can be a Kibana plugin. MC which is installed on a Pod of a Kubernetes cluster MC The first service can understand Python. MC and the MongoDB client library MC in a scalable Pod on a Kubernetes cluster MC The second service (28) may include ElasticsearchMC installed on a virtual machine cluster or a Kubernetes cluster MC .

[0015] In a preferred implementation, a simulation system is also proposed, comprising: an application interface (API) configured to receive an initial simulation request from a user via an agent; and a work queue installed in a Pod of a Kubernetes cluster. MC to receive the user's first simulation request to distribute a workload across different instances of an initial service; and an analytics engine installed in the Kubernetes cluster Pod MC to receive simulation results and transmit them to the application interface (API).

[0016] Other objects, advantages and functions of the present invention will become more apparent from the following description of possible embodiments, given by way of example only, in relation to the following figures. BRIEF DESCRIPTION OF THE FIGURES

[0017] Figure 1 is a schematic diagram of a system representing a first prototype, according to a preferred embodiment of the present invention.

[0018] Figure 2 is a schematic diagram showing a method of operating the first prototype, according to a preferred embodiment of the present invention.

[0019] Figure 3 is a schematic diagram of a system representing a second prototype, according to a preferred embodiment of the present invention.

[0020] Figure 4 is a schematic diagram showing a system, according to a preferred embodiment of the present invention.

[0021] Figure 5 is a schematic diagram showing an operating method, according to a preferred embodiment of the present invention.

[0022] Figure 6 is a schematic diagram showing a system, according to a preferred embodiment of the present invention. DESCRIPTION OF THE METHODS OF IMPLEMENTING THE INVENTION

[0023] The present invention is illustrated in more detail by the following non-limiting examples.

[0024] As a person skilled in the art will appreciate upon reading the following description, various aspects described herein can be implemented in the form of a device, a method, or a computer program product (for example, a non-transient computer-readable medium or memory having computer-executable instructions that, once executed, carry out the operations or steps). Thus, these aspects can take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects.

[0025] Furthermore, such aspects can take the form of a computer program product stored on one or more storage media. Computer-readable media having computer-readable program code, or instructions, embedded in or on the storage media. Any suitable computer-readable storage media may be used, including hard drives, CD-ROMs, optical storage devices, magnetic storage devices, and / or any combination thereof.

[0026] According to a preferred embodiment of the invention, Kibana Server MC Node.js MC and R-Engine MC or Python MC and all other analytical tools are in the same Kubernetes Pod MC Due to the specific characteristics of the R-Engine MC [1], the inventors faced complexity in communication (via dynamic command line) and in error feedback between the Kibana API MC and R-Engine MC Furthermore, for certain target environments, when R-Engine MC and Kibana-Server MCare in the same Kubernetes Pod MC This introduces a vulnerability.

[0027] According to another preferred embodiment of the invention, R-Engine is located MC separately, and the latter is invoked via REST API. In this sense, the "Backend" infrastructure includes: Kibana MC for visualization; ElasticSearch MC for persistence; and a mechanism or means (PLUMBER) MC ) to transform R functions into a REST API and build the http server.

[0028] The PLUMBER MC Identifies and routes HTTP requests to invoke R-Engine services MC On the Kibana server MC A service invokes the REST API and, with the response, updates ElasticSearch and constructs the response returned by the "Kibana" API. MCThe server sends a request to the client to update their dashboard with the requested scenario. Unlike the standard case, dashboard clients do not simply view it; they influence its display through scenario simulation.

[0029] It must be taken into account that several clients on the same dashboard may concurrently invoke R-Engine services. MC According to a preferred embodiment of the invention, several threads must therefore be launched (one per simulation), which is inherently compromised by the collaborative threading of R-Engine. MC and on the other hand, by the single-threaded HTTP side of the server built by PLUMBER MC However, the latter cannot interpret more than one HTTP request at a time.

[0030] These technological limitations make the availability and consistency of visualizations uncertain, a consequence of the double risk of sequential scenario processing by R-Engine. MC and PLUMBER MC Sequential processing causes timeouts and inconsistencies in dashboards that will no longer reflect the user's scenario due to erroneous interpretations.

[0031] More specifically, if the scenarios are stored in memory by R-ENGINE MC Any processing of these scenarios will be atomic: R-ENGINE MC will not return control to concurrent processes until the scenario is built. This is particularly detrimental to very short scenarios, which remain unnecessarily waiting for longer scenarios. The fact that PLUMBER MC either interwoven in R's scripts MC , which means that the two technological limitations of PLUMBER are "single http". MCand “single threaded” of R-ENGINE MC cannot be addressed separately.

[0032] In this sense, address the "single http" issue of PLUMBER MC leaves a high degree of uncertainty for CPU-intensive scenarios, whereas launching multiple instances of the R-Engine MC requires managing the bottleneck posed by the single HTTP side of PLUMBER MC Another problem then arises: the limited processing capacity of R instances. MC , following HTTP calls. It is therefore necessary to determine a balancing component to guarantee an acceptable utilization rate (>90%) of each R-Engine instance. MC .

[0033] The parallelization of processes in Machine Learning, and in our case in simulation, is currently the subject of R&D studies on different aspects as we can see in the literature [2]. We therefore had to develop a new parallelization method in order to try to meet our constraints.

[0034] We can see in the literature that the parallelization of indexing and bulk ElasticSearch processing [3][4] is a topic addressed via generic load balancer platforms. These require heavy integration in terms of infrastructure as well as licensing and maintenance costs, which leads to complexity with over-provisioning that is not useful in several use cases.

[0035] Existing solutions only address one of the two obstacles to overcome. Their independent application in our context risks poor utilization of R-ENGINE instances. MC .

[0036] According to preferred embodiments of the invention, R-ENGINE scripts are made to collaborate MC with an ElasticSearch indexing engine MC This allows a user to simulate and integrate scenarios to perform an analysis of results over several years.

[0037] Instead of using a single process performing multiple operations, a preferred embodiment of the present invention uses several processes operating in parallel. To address the potential drop in utilization, we have enhanced our assumption so that each simulation in the pool becomes an independent consumer. Thus, the structure transforms into a FIFO (First In First Out) list; each simulation in the pool that finishes retrieves an HTTP request from the FIFO list. In this implementation, simulation consumption occurs via recursive calls. Log analysis was conducted for a test bench of several batches of 500 HTTP requests of random duration, using 2, 8, 16, and 32 instances of R-ENGINE. MC , showed that at any given time the number of asynchronous tasks in progress was equal to the number of R-ENGINE instances MC .

[0038] To optimize this, we needed to decompose the simulation code into fairly small basic elements to allow for parallel calls without a large element that would have generated waiting time, while maintaining a high enough level of granularity so that the time wasn't exclusively consumed by procedure calls between NodeJS. MC PLUMBER MC and R MC .

[0039] The invocation of R services MC REST API access was compromised by the single HTTP nature of the server supporting the APIs. Neither function-based nor port-based multiplexing overcame this obstacle, resulting respectively in either a connection refusal or sequential API processing. As for the obstacle posed by collaborative threading, our tasks being CPU intensive, and moreover, housed in memory, became atomic operations: which is prohibitive for short simulations.

[0040] Launching multiple instances resulted in unpredictable instance utilization rates, and allocation techniques could only be applied to two instances. We implemented a technological advancement: a load balancer specifically designed for situations where a one-to-one relationship can be established between the HTTP server instance and the invoked service instance by running them in the same process.

[0041] This advancement relies on the concept of a promise pool, a concept that does not exist in Node.js. MC that we had to develop. This pool takes the form of an array of promises which recursively, by exploiting the promise chaining capability, will look in a FIFO queue for the next request to execute.

[0042] This improvement is reproducible and can be applied to any framework that builds REST APIs directly from the script using decorators. As we have seen, such servers are unable to listen for multiple HTTP requests, which creates a bottleneck and harms concurrency. Without this improvement, we would not have been able to implement our multiple simulation scenario.

[0043] This solution allows us to obtain a result in 5 minutes, which is acceptable but falls short of the desired target of 3 minutes. To improve data indexing times, we can use Python. MC to perform the bulk indexing of the 8 million rows. By running the R-Engine scripts MC to Python MC It is possible to guarantee better overall technical integration.

[0044] In order to make Kibana visualizations dynamic through scenario simulation, according to a preferred implementation, Kibana is brought together MC Node.js MC and R-Engine MC on the same Kubernetes cluster MC in the architecture. Command-line communication proved to be non-generic, with unrobust error handling between Kibana and R-Engine. It is therefore preferable to have R-ENGINE reside within the architecture. MC in a Kubernetes Pod MC different and to invoke its services via REST HTTP calls. To build the infrastructure REST, PLUMBER MC builds the server that listens for REST calls and invokes functions from a script, via decorations in the R script MC However, the CPU-intensive nature of the scenarios is incompatible with the single-threaded aspect of R-Engine. MC .

[0045] We therefore conducted an initial preliminary study and built a test bench for several users (bots) launching concurrently via Kibana MC We tested typical scenarios of varying sizes and complexities, and measured the completion time of each scenario.

[0046] Referring to Figure 2, a first prototype involves several processes: Kibana MC ElasticSearch MC PLUMBER MC to build the server backed by the R-Engine MC In this process, when a user 10 requests a simulation 12 via an agent 14, the REST call is submitted to Kibana MC , either an API simulation 16, which logs a second HTTP call, or a POST simulation 18, to the server 20 generated by PLUMBER MC This last server 20 invokes, via a simulation calculation request 22, the functions 24 of the R-Engine MCto perform the simulation and returns the simulation data, namely the simulation index 26, which will be used for the ElasticSearch update MC in Elastic MC and the Kibana API MC to relay them to user 30, 32.

[0047] Our tests have shown, however, that as long as one of the URLs to the function is in progress, invoking the same function with the second URL generates a connection error.

[0048] We therefore had to work on integrating a load balancer and carry out new prototyping work. There is a limitation between PLUMBER MC and R MC If a simulation is running, then no new requests can be processed. At this stage, it was impossible to determine if the problem originated with Plumber. MC not being able to listen to more than one HTTP connection.

[0049] We subsequently initiated the construction of two PLUMBER servers MC on two different ports. The tests validated the concept; the simultaneous launch of the two requests was accepted. However, examination of the execution logs showed that one of the simulations had to wait for the other to finish before starting, which was a deal-breaker.

[0050] Indeed, our multi-user and multi-client platform allows us to achieve optimal turnaround times without duplicating infrastructure, thus reducing rental and maintenance costs. Therefore, we cannot accept a solution where a user / client would have to wait for another client's simulation to finish before their own could begin.

[0051] A thorough analysis of our results led us to identify the risk of two interlocking obstacles: the single-thread HTTP aspect of PLUMBER MC(which we had just solved by load balancing) and the single-threaded nature of the R-ENGINE MC More specifically, the simulation data is loaded entirely into memory by R-ENGINE. MC Since memory operations are atomic, their processing cannot be interrupted, which blocks other concurrent processes. Short simulations are therefore penalized because they have to wait for longer ones to finish.

[0052] We have revised our assumptions accordingly, so that the PLUMBER server instances MC (per port) run on separate processes. This assumption is based on the premise that the R script MC runs on the same process as the PLUMBER server MC who invoked it. So indirectly, there will be as many instances of the R-ENGINE MC than PLUMBER servers MCThe processes run either in parallel on separate processors and / or in multithreading with memory isolation, which guarantees concurrency.

[0053] To achieve our goals, we have once again reviewed our approach so that the construction of the PLUMBER servers MC / port is handled in different processes. We built a new test bench, with two instances launching two PLUMBER servers MC listening on the same IP address and on two different ports.

[0054] Our test consisted of simultaneously running two simulations of 30 seconds and 15 seconds in length and evaluating whether the execution time was less than their sum (45 seconds). The simulations completed in 32 seconds, demonstrating that we had successfully overcome the single HTTP obstruction of Plumber. MC and the “single threaded” of R-ENGINE MC .

[0055] Thanks to this test, we can confirm that the tasks are launched in parallel and that the results obtained provide parallel access.

[0056] With reference to Figures 3 to 6, a second prototype involves several processes: Kibana MC ElasticSearch MC MongoDB MC to build the Kubernetes Pods MC 11 backed by the R-Engine MC with Python MC The diagram represents the interactions between the different actors (customers, services or data persistence) as well as the chronological sequence of the different events.

[0057] The client or user 10, via the agent 14, starts a new simulation 12; a new task 34 is created by the simulation API 16. The Python service MC 38 will take the next unprocessed task 35 and execute it. The Python service MC verifies by making a 40 request to the MongoDB service MC36 if there is a new task. This check is part of a process that is repeated in block 37.

[0058] The Python service 38 checks the type of task 40 in block 39: if it is a main task type 42, the Python service 38 distributes the task processing by creating a subtask 44 for each entity (an entity is a set of data on which a simulation can be consistently applied); otherwise, the service performs the simulation calculation 46 for the entity. A simulation can be run in parallel depending on the number of instances of the Python service. MC and the number of entities. As soon as a subtask 44 is completed, the simulation result is indexed 48 in Elastic MC28. When all subtasks of a simulation are completed: the status of the main task is updated 50 and the result of Natural Language Generation or "NLG" 52 of each entity is compiled into an aggregated result on all entities processed.

[0059] Meanwhile, agent 14 requests the result of simulation 54 from the simulation API 16 at regular intervals until the simulation is complete. The simulation API 16 then requests the result of simulation 56 from the second service 28, namely Elastic MC The second service 28 then transmits the result of the simulation 58 to the simulation API 16.

[0060] In this process, when a user 10 requests a simulation 12 via an agent 14, the REST call is submitted to Kibana MC , either an API simulation 16, which logs a second HTTP call, or a new simulation task 34, to the server 36 generated by MongoDBMC .

[0061] Typically, this scenario is addressed by adding the HTTP request to a queue that the PLUMBER servers MC consume. Each request in this direction has a hash constructed from: Simulation ID, Dashboard ID, and Client ID. This hash prevents the simulation from being repeated. Furthermore, combined with the concept of favorites, it allows for anticipating and generating simulations in advance during off-peak periods. Our challenge here lies at the user level: how to assign each request to a Plumber server. MC while guaranteeing a utilization rate of R-ENGINE instances MC greater than 80%.

[0062] According to preferred embodiments of the invention, the second prototype, intended for large companies, requires instance utilization to be close to 100%. This is not only to allow scaling or expansion to more than two instances without loss of utilization rate, but also to avoid timeout problems related to listening on HTTP ports, which is inherently time-limited.

[0063] Indeed, for a simulation, the tests are broken down into launching several processes in parallel. We must wait for each process to respond before obtaining a global response. Therefore, when one process takes significantly longer than the others to respond, we observe all the other processes waiting before the overall result is achieved. This drastically reduces the utilization rate in our case, because it is not possible to identify the slowest processes in advance and thus distribute them across the different Python instances. MC .

[0064] The parallelization of processes in machine learning, and in our case in simultaneous simulation, is currently the subject of R&D studies on various aspects, as can be seen in the literature. We have therefore developed a parallelization method in order to attempt to meet our constraints. Parallelization must allow us to perform several machine learning tasks simultaneously, taking into account the predicted time required for each task in order to distribute these tasks across multiple Python processes. The goal is to distribute the use of all the Kubernetes Python PODs as much as possible. MC 24 according to a criterion of planned simulation time and not according to a number of simulations, so that the overall simulation time is as short as possible.

[0065] The claims should not be limited in scope by the preferential realizations illustrated in the examples, but should receive the broadest interpretation that is consistent with the description as a whole. 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.org / 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.org / 10.1007 / 978-981- 10-5699-4 57

Claims

CLAIMS Simulation method comprising the steps of: receiving a first simulation request (12) from an agent (14) via an application interface (16) and creating a simulation task (34); checking by a first service (38) whether the simulation request (12) is a main task (42), if so, the first service (38) creates subtasks (44) per entity to perform the simulation simultaneously and a simulation calculation; otherwise, if the task (34) is a subtask, the simulation is calculated (46) for a corresponding entity; indexing (48) the simulation in a second service (28); updating (50) the status of the simulation by the first service (38); compiling a natural language generation result (52) in the first service (38); querying (54) the result of the simulation of the agent (14) by the application interface (16) at regular intervals until the simulation is completed;request (56) of the simulation result to the second service (28); and transmission (58) of the simulation result to the application interface (16). The method according to claim 1, wherein the first service (38) and second service (28) are installed in a Kubernetes cluster (11). The method according to claim 1, wherein the application interface (16) is a Kibana plugin, Kibana being installed on a Pod of a Kubernetes cluster (11). The method according to claim 1, wherein the first service (38) comprises Python and the MongoDB client library in a scalable Pod on a Kubernetes cluster (11). The method according to claim 1, wherein the second service (28) comprises Elasticsearch installed on a virtual machine cluster or a Kubernetes cluster (11). A simulation system comprising: an application interface (16) configured to receive an initial simulation request (12) from a user via an agent (14); a worker queue installed in a Pod of a Kubernetes cluster (11) to receive the user's initial simulation request (12) to distribute a workload across different instances of a first service (38); and an analytics engine installed in the Pod of the Kubernetes cluster. (11) to receive simulation results and transmit them (58) to the application interface (16). The system according to claim 6, wherein the application interface (16) is a Kibana plugin and uses Kibana as the application server. The system according to claim 6, wherein the analytical engine is configured to: receive a first simulation request (12) from an agent (14) via an application interface (16) and create a simulation task (34); verify by the first service (38) whether the simulation request (12) is a main task (42), if so, the first service (38) creates subtasks (44) by entity to perform the simulation simultaneously and a simulation calculation; otherwise, if task (34) is a subtask, the simulation is calculated (46) for a corresponding entity; index (48) the simulation in a second service (28); update (50) the simulation status by the first service (38); compile a natural language generation result (52) in the first service (38); query (54) a simulation result from the agent (14) by the application interface (16) at regular intervals until the simulation is complete; request (56) the simulation result from the second service (28); and transmit (58) the simulation result to the application interface (16). The system according to claim 8, wherein the first service (38) comprises Python and MongoDB installed in Pods of the Kubernetes cluster (11). The system according to claim 8, wherein the second service (28) comprises Elasticsearch installed in Pods of the Kubernetes cluster.Computer-readable memory storing computer-executable instructions which, once executed, perform the following operations: receiving a first simulation request (12) from an agent (14) via an application interface (16) and creating a simulation task (34); checking by a first service (38) whether the simulation request (12) is a main task (42), if so, the first service (38) creates subtasks (44) by entity to perform the simulation simultaneously and a simulation calculation; otherwise, if the task (34) is a subtask, a simulation (46) is calculated for a corresponding entity; indexing (48) of the simulation in a second service (28);. update (50) of the simulation status by the first service (38); compilation of a natural language generation result (52) in the first service (38); querying (54) the simulation result of the agent (14) by the application interface (16) at regular intervals until the simulation is completed; querying (56) the simulation result to the second service (28); and transmitting (58) the simulation result to the application interface (16).

Images