WO2016198762A1 - Procédé et système de détermination d'une configuration de serveurs cible pour un déploiement d'une application logicielle - Google Patents

Procédé et système de détermination d'une configuration de serveurs cible pour un déploiement d'une application logicielle Download PDF

Info

Publication number
WO2016198762A1
WO2016198762A1 PCT/FR2016/051266 FR2016051266W WO2016198762A1 WO 2016198762 A1 WO2016198762 A1 WO 2016198762A1 FR 2016051266 W FR2016051266 W FR 2016051266W WO 2016198762 A1 WO2016198762 A1 WO 2016198762A1
Authority
WO
WIPO (PCT)
Prior art keywords
configuration
software application
load
server
target
Prior art date
Application number
PCT/FR2016/051266
Other languages
English (en)
Inventor
Wei Monin
Guy VACHET
Bruno DILLENSEGER
Xavier ETCHEVERS
Original Assignee
Orange
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange filed Critical Orange
Publication of WO2016198762A1 publication Critical patent/WO2016198762A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/505—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the load
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3051—Monitoring arrangements for monitoring the configuration of the computing system or of the computing system component, e.g. monitoring the presence of processing resources, peripherals, I/O links, software programs

Definitions

  • the invention relates to the general field of software applications.
  • the invention thus applies in a preferred but nonlimiting manner when software applications are deployed in a cloud computing system also more commonly known as "cloud” in English.
  • PaaS platform as a service
  • These systems aim to provide technical services that facilitate the construction, implementation and administration of software applications to refocus users' attention on their applications.
  • the purpose of a PaaS system is to hide the complexity of instantiating and exploiting applications.
  • the PaaS system offers technical bricks, accessible through high-level interfaces via a telecommunications network, to support a large panel of services related to the administration of applications, including dynamic adaptation to Load variations, dependability and safety.
  • the functional perimeter of these bricks generally corresponds to that filled by middleware (eg HTTP server, application server, database, script interpreters, various software frameworks, etc.), ie operations that can be shared over several applications.
  • middleware eg HTTP server, application server, database, script interpreters, various software frameworks, etc.
  • the purpose of managing the elasticity of software applications deployed in the cloud is to provide and adjust (ie adapt) the resources necessary for the proper functioning of these software applications, in particular in terms of volumetry, availability, response time and reliability, while satisfying the constraints specific to these software applications (eg cost, placement of virtual machines, right of use, etc.).
  • the elasticity management In order to optimize a quality / cost ratio, the elasticity management must thus:
  • Resource sizing techniques are therefore at the heart of elasticity management. They generally require a good knowledge of the software application, especially in terms of resource consumption by the application deployment instances (eg servers), but also user request profiles (eg distribution by service, data rates, queries, inter-arrival times between requests, etc.).
  • application deployment instances eg servers
  • user request profiles eg distribution by service, data rates, queries, inter-arrival times between requests, etc.
  • the invention makes it possible to remedy this drawback in particular by proposing a method for determining a so-called target server configuration for a deployment of a software application capable of offering at least one service, this method comprising:
  • a step of selecting a so-called initial configuration of servers for the deployment of the software application able to support a target load determined for the software application this selection step taking into account the average execution times obtained during said application. minus one unit test, the target load and a specified load determined for the reference configuration, and using a numerical model reflecting at least one deployment constraint of the software application imposed on the initial server configuration; and A step of determining, from the initial configuration, a target server configuration intended to be used for the deployment of the software application, said determining step comprising carrying out a plurality of load-bearing tests.
  • said determining step further comprising, as a function of the result of each load-holding test, an adjustment of at least one resource of the initial configuration so that the target configuration obtained at the result of said plurality of load-bearing tests is able to verify a maximum response time fixed for the application software and to support said target load.
  • the invention also aims at a system for determining a target configuration for a deployment of a software application, the system comprising:
  • a first test tool allowing the execution of at least one unit test on the software application when it is executed on a so-called reference server configuration
  • a obtaining module configured to control the execution of at least one unit test by the first test tool on said reference configuration and to obtain, for at least one service offered by the software application, a time of average execution of a request invoking this service for each server in the reference configuration;
  • a selection module configured to select an initial server configuration for the deployment of the software application capable of supporting a determined target load for the software application, said selection module being configured to take account of the average execution times obtained during said at least one unit test, the target load and a given load determined for the reference configuration, and to use a digital model reflecting at least one deployment constraint of the software application imposed on the server configuration initial ;
  • a second test tool for performing load-holding tests on said software application when it is executed on the initial server configuration selected by the selection module
  • a determination module configured to determine from the initial configuration a target server configuration to be used for the deployment of the software application, said determination module being configured to control the execution of a plurality of test cases; supported by the second test tool, said load-carrying tests being parameterized by the determination module according to a theoretical maximum load estimated for the initial configuration and the target load, and using at least one request profile invoking said at least one service offered by the software application, this profile being representative of a use of the software application during its deployment, said determining module being further configured to adjust, according to the result of each load-holding test, at least one resource of the initial configuration so that the target configuration obtained at the conclusion of said plurality of load-bearing tests is able to check a fixed maximum response time for the software application and to support said target load.
  • server here means any type of physical or virtual machine, able to execute all or part of an instance of the software application.
  • the software application is intended to be deployed on a configuration (ie an arrangement) of servers formed of one or more servers connected to each other and verifying imposed deployment constraints for the production of the software application (ex. multi-site deployment, use of specific machines, etc.).
  • the invention therefore proposes a method for sizing the resources required for the deployment of a software application in a production environment that relies on the structured execution of two types of tests, namely unit tests without concurrent access to resources and then load-bearing tests, judiciously parameterized. These different tests are performed on different server configurations, namely:
  • the invention thus makes it possible to simply and efficiently determine a target production configuration adapted in terms of resources to the deployment of the software application in a real execution environment and verifying the various contractual requirements that are imposed on it through the intermediary for example an SLA agreement as previously described.
  • This target configuration is obtained by iteratively adjusting the resources of the initial configuration at the end of each load-holding test so as to verify these requirements.
  • the adjustment of the resources of a server configuration comprises, within the meaning of the invention, the maintenance, the addition, and / or the withdrawal of resources for at least one server from the configuration, and / or the maintenance or the updating parameters of this configuration (such as the number of servers considered in this configuration).
  • This adjustment leads to an "optimal" production configuration, that is to say a minimum configuration of servers, to ensure compliance with the requirements set for the software application in terms of volumetry (ie target load), availability and end-to-end response time from the software application to user requests.
  • the reference server configuration used to perform the unit tests is generally chosen to be relatively small in complexity compared to the server configuration on which the software application is intended to be actually deployed.
  • This configuration of reference servers can typically be limited to a single machine (ie a single server), for example the machine on which the application is developed.
  • the unit tests carried out from this reference configuration aim to characterize, for each type of request identified as relevant to the services offered by the software application (eg subscription type requests, termination, multimedia object consultations, processing , etc.), the resources consumed by it on each server of the reference configuration to process this type of request when there is no concurrent access to these resources.
  • this is to quantify the use at each server of the reference configuration of the processors (or central processing units or CPU for "Central Processing Unit" in English), memory (ex. disk, RAM (Random Access Memory)) and / or network resources (eg network connectors) requested during the processing of requests.
  • Such unit tests are known per se and are conventionally implemented during the development and debugging of software applications. During these tests, it is ensured that there is no concurrent access to the resources whose consumption is to be quantified in order to process the requests sent to the software application.
  • the requests can be for example sent one by one to the software application executed by the reference configuration (a request being sent at the end of the processing of the previous one), or N requests (N integer) can be sent deterministically to the software application by ensuring that there is no concurrent access to the resources used for their processing.
  • the invention proposes to take advantage of these simple unit tests to be carried out to collect various resource consumption metrics related to the intrinsic processing of each request by each server of the reference configuration, and more particularly for each representative service offered by the application. software, to obtain the average execution time of a request invoking this service by each server of the reference configuration.
  • Other metrics can of course be obtained during these unit tests, such as for example the number of network connectors used simultaneously, the amount of RAM used on each server, the duration and volume of disk occupied, the time elapsing between the completion of the query on a server and the start of execution on the next server, etc.
  • the metrics thus harvested serve as inputs, according to the invention, to numerical models reflecting various requirements imposed in terms of architecture in particular or types of machines to the production configuration (that is to say various constraints of deployment of the software application) and are exploited to select an initial production configuration satisfying a target volume (load in terms of request rates) set for the software application.
  • the numerical models considered model, for example, the constraints (requirements) of deploying the software application from at least one queue or a network of queues.
  • the selection of the initial production configuration is based on unit test results conducted in an ideal runtime environment where queries are not competing for access to resources. Unit tests thus make it possible to determine only what are the needs of the software application in CPU, memory and / or network resources to intrinsically process each request.
  • the initial production configuration selected in accordance with the invention therefore only takes into account a volumetric to be respected and the intrinsic execution time of the queries resulting therefrom.
  • these assumptions are not representative of the actual conditions of use of the software application in which the requests of the users arrive generally non-deterministically, typically in bursts and with rates sometimes very different from the average throughput of the requests.
  • Unit tests therefore do not provide information on the actual response time of the software application in a production environment, so that a resource adjustment of the initial production configuration selected at the end of the unit tests is proposed by the invention to take into account the requirements imposed on the software application in terms in particular of maximum end-to-end response time.
  • a request profile invoking a service includes, for example, for at least a determined period of time of a software application activity cycle or a software application activity cycle:
  • the load-bearing tests take into account a realistic query profile representative of the use of the software application in a real execution environment (ie similar or at least close to the one at which one s 'waits when the software application goes into production).
  • the initial production configuration selected by the invention is not necessarily strictly in accordance with the server configuration that will be deployed later in production and tested in a real execution environment. She can In particular, it is of smaller complexity, but it is selected preferentially so as to be representative of the various functionalities and problems expected during the production of the software application.
  • the initial server configuration is preferably chosen so as to be representative of the software, technical and functional complexity of the production environment of the software application (eg the presence of a master node and several secondary nodes which communicate between them, modeling of inter-site communication, taking into account security problems, etc.). In this way, it is ensured that the sizing of the resources achieved by the invention is relevant and exploitable to facilitate the deployment of the application in production and limit large-scale tests.
  • the invention is thus distinguished from the current state of the art in that it offers a solution which makes it possible, before the software application is put into production, to preselect and to size, by means of numerical models, one or more several appropriate server configurations that serve as starting points for the actual deployment of the application.
  • the selection of the optimal configuration is not based solely on experimental tests carried out in production in a real execution environment and which may prove, as mentioned above, to be hazardous, expensive and time-consuming.
  • the invention offers the possibility of pre-provisioning the resources required to execute a software application, which makes it possible to perform such experimental tests only on a small number of configurations in order to select an optimal configuration. This gives the invention a substantial gain in complexity and time.
  • the invention thus makes it possible, compared to existing solutions based essentially on experimental observations, to ensure the control and efficiency of elasticity management, and to reduce investment costs for software applications and systems.
  • PaaS type
  • the software application can advantageously be considered as a "black box" offering one or more services in response to user requests verifying a certain profile, and distributed or instantiated on one or more servers.
  • the consumption metrics of resources from unit tests and which are then used to select an initial server configuration on which are performed load tests are all-component metrics measured on each server in the reference configuration.
  • the determination method further comprises a step of estimating a theoretical maximum load for the reference configuration and the allowable load determined for the reference configuration results from the product of a parameter was between 0 and 1 by the theoretical maximum load estimated for the reference configuration.
  • the theoretical maximum load for the reference configuration is estimated by applying a stability condition of the software application to at least one average execution time of a request of the derived software application for said at least one server of the reference configuration from the average execution times obtained for this server for the services offered by the software application.
  • Such a stability condition is verified in particular if for each server of the server configuration considered for executing the software application, the rate (flow) of arrival of the requests is strictly lower than the utilization rate of this server.
  • the response time of the server can be used to evaluate its utilization rate.
  • This stability condition makes it possible to easily evaluate a maximum theoretical load for the software application in the vicinity of which the software application is no longer able to process the requests. This theoretical maximum load is used to size the initial server configuration.
  • the inventors have observed that upstream of this maximum theoretical load, the average response time of a server as a function of the load of the software application generally follows a first linear regime in a gentle slope followed by a rise brutal defining a second linear regime approaching the saturation of the server.
  • the parameter between 0 and 1 used to define the allowable load of the initial configuration is preferably chosen so that the load considered is in a transition zone just before the second linear regime and in which the response time of end-to-end of the software application remains below a fixed maximum response time for the software application (typically in the SLA). In this "optimal" zone, the response time versus the load is contained and remains below the maximum response time allowed for the software application.
  • the value of the parameter a may depend on the distribution of the inter-arrival times of the requests, as detailed later. However, a value of 0.8 or 0.85 (or around these two values) is generally good enough to implement the invention.
  • the adjustment of at least one resource of the initial configuration after a load-holding test is performed according to a difference between a response time of the evaluated software application during the load withstand test and the maximum response time set for the software application.
  • the determining step comprises at least:
  • This protocol limits the load-bearing tests performed on the initial server configuration and quickly leads to a target server configuration derived from the initial configuration.
  • configuration derived from the initial configuration is meant in the sense of the invention that the configuration is the same as the initial configuration if it is considered correctly sized or it is obtained after adjusting resources of the initial configuration.
  • the determination step may furthermore comprise an estimate at the end of the second test, of a response time of the software application with the target load from a response time evaluated at the result of the first test performed with the first load on a tested configuration derived from the initial server configuration and a response time of the evaluated software application after the second test performed with the second load on said configuration tested, the resource adjustment being performed at the end of the second test based on a difference between the estimated response time for the target load and the maximum response time set for the software application.
  • the tested server configuration may be considered undersized if the estimated response time for the target load is greater than the maximum response time
  • the server configuration tested may be considered oversized if the estimated response time for the target load is less than the product of a predetermined real number ⁇ between 0 and 1 and the maximum response time, for example 0.9; and or
  • the tested server configuration can be considered correctly sized otherwise.
  • the resource adjustment is then carried out accordingly and the one or more previous load-holding tests are repeated on the adjusted configuration to validate this adjustment and / or to make a new adjustment, until the suitable target configuration is determined. to be deployed and meets the requirements for the release of the software application in terms of load and end-to-end response time.
  • the target configuration corresponds to a tested server configuration for which at the end of the third test, a response time of the evaluated software application for the target load on this tested server configuration is less than the maximum response time.
  • the determining method further comprises a step of validating the target configuration by means of an endurance test performed during a predetermined execution time of the software application.
  • this endurance test to test the software application and target server configuration determined unit tests and load-bearing tests over a sufficiently long period to take into account, for the sizing of resources, rare events whose probability of occurrence is relatively low.
  • the result of this endurance test makes it possible to readjust, if necessary, the resources of the target configuration with a view to deploying the software application.
  • the metrics and numerical models used in accordance with the invention to determine the target configuration are based on certain abstraction assumptions on the behavior of the software application, including independence of certain components or distribution of requests.
  • the endurance test is used to refine these models (and adjust the sizing of resources if necessary), and to a certain extent, highlight the differences between the reality and the numerical models used, to evaluate them and to judge their relevance.
  • the software application is characterized by an activity cycle comprising a plurality of intervals, each interval being associated with an average arrival rate of requests representative of this interval, and in which said steps of FIG. obtaining, selecting and determining are implemented for at least one interval of said plurality of intervals.
  • This embodiment makes it possible to adapt to the software applications for which there is a dynamic distribution of the requests, in other words for which the rate of the arrivals of service requests varies significantly over time intervals and this in a repetitive way on the cycle of activity.
  • the invention also aims at a method of elasticity management of a server configuration capable of executing a software application, this method comprising: a step of determining a target configuration of servers for the deployment of the software application comprising the execution of a determination method according to the invention;
  • a step of executing the software application on said server target configuration comprising:
  • the invention also aims at a resiliency management system of a server configuration capable of executing a software application comprising:
  • a system according to the invention for determining a target configuration of servers for the deployment of the software application comprising the execution of a determination method
  • a module for monitoring at least one supervision metric of this target configuration during the execution of the software application
  • An adjustment module configured to adjust the resources allocated to the target configuration according to the said at least one metric, this adjustment module being able to maintain the resources allocated or to dynamically add and / or remove resources to the configuration target.
  • the method and the elasticity management system benefit from the same advantages mentioned above as the method and the determination device according to the invention.
  • the various steps of the determination method and / or the elasticity management method are determined by computer program instructions.
  • the invention also relates to a computer program on one or more information medium (s), this program being capable of being implemented in a determination system or more generally in a computer, this program comprising instructions adapted to the implementation of the steps of a sizing process as described above.
  • the invention also relates to a computer program on one or more information medium (s), this program being capable of being implemented in an elasticity management system or more generally in a computer, this program comprising instructions adapted to the implementation of the steps of an elasticity management method as described above.
  • This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other form desirable shape.
  • the invention also relates to a computer-readable information medium, comprising instructions of a computer program as mentioned above.
  • the information carrier may be any entity or device capable of storing the program.
  • the medium may comprise a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording means, for example a floppy disk or a hard disk.
  • the information medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means.
  • the program according to the invention can be downloaded in particular on an Internet type network.
  • the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.
  • Figure 1 shows schematically a determination system according to the invention, in a particular embodiment
  • FIG. 2 represents a test tool for carrying out load-holding tests on a configuration of reference servers on which a software application is deployed and which can be used as a component of the determination system of FIG. 1;
  • FIGS. 3A and 3B illustrate, for two distinct services of a software application, a cycle of activity of this software application and the distribution of the number of arrivals of requests on this activity cycle;
  • FIG. 4 represents, in the form of a flow chart, the main steps of a determination method according to the invention in a particular embodiment in which it is implemented by the determination system of FIG. 1;
  • FIGS. 5A to 5D illustrate the evolution of the response time of a server as a function of the load of the software application, and for different request profiles
  • FIGS. 6A-6D illustrate several models of queuing systems that can be used to determine the initial configuration according to the invention
  • Figure 7 details, in flowchart form, the main steps implemented by the determination system of Figure 1 in a particular embodiment of the invention to determine the configuration of target servers from the initial configuration;
  • FIGS. 8A to 8D illustrate different cases leading to an adjustment of the resources of the initial configuration in accordance with the invention
  • FIG. 9 represents, in the form of a flow chart, the main steps of a method of managing the elasticity according to the invention, in a particular embodiment
  • FIG. 10 illustrates the processing implemented in a particular embodiment of the invention when the software application has a periodic activity cycle.
  • FIG. 1 represents, in its environment, a system 1 for determining a configuration of machines for the deployment of a software application APP, according to the invention, in a particular embodiment.
  • the system 1 proposes, through the configuration thus determined (designated by target configuration in the remainder of the description), a sizing of the resources necessary to put the APP software application into production, in other words to deploy it in a real execution environment.
  • APP software application can be an application allowing access to or the generation of multimedia content, the referencing of products, access to remote equipment, etc.
  • This APP software application is able to offer one or more services
  • UC1, UC2, ..., UCN N integer greater than or equal to 1 to users, on receipt of requests invoking these services sent by them via terminals (eg via a mobile terminal, a computer, etc.) .
  • the APP software application is intended to be deployed (ie put into production) in a cloud or cloud computing system (not shown), on a target configuration of virtual machines (servers) hosted by the cloud.
  • servers virtual machines
  • the management of the elasticity of the resources made available by the cloud for the execution of the software applications it hosts is very important: the cloud seeks to optimize the sharing of resources common to software applications that it hosts in order to reduce the cost of their deployment, while ensuring the quality of services offered by these applications to their users.
  • the shared resources can be of different natures: they can be in particular resources of the type processors or CPU of virtual and / or physical machines (servers), of memory resources (eg RAM, disk, etc.), or of network resources (eg network connectors, etc.).
  • the purpose of cloud resilience management is therefore to provide the various software applications with the aforementioned resources required for their execution and to guarantee their proper operation according to an agreed SLA.
  • Each SLA defines constraints specific to the software application to which it refers, particularly in terms of volumetry, availability, response time, reliability but also cost, placement of machines (virtual in the context of the cloud) on which are deployed the application, rights of use and subscriptions, etc.
  • each SLA associated with a software application defines a certain number of requirements that must be respected by the cloud.
  • the role of elasticity management is to determine the resources needed to deployment of the APP software application in the cloud to meet the requirements set by this SLA, while taking into account the resources committed to other software applications hosted by the cloud and running.
  • the management of the elasticity of the cloud hosting the APP software application relies on the determination system 1. More particularly, it allows efficient management of the elasticity of the cloud by offering the possibility of pre-provisioning the resources necessary to execute the APP application before it goes into production by determining a configuration suitable for deploying the APP application in a real execution environment (also designated by "target" configuration).
  • the determination system 1 is based on different test environments of the APP software application in which the application is deployed on different server configurations, and on different modules (software here) implementing programmed algorithms or calculation models exploiting the results obtained in these test environments.
  • the determination system 1 comprises:
  • An ENVI test software tool (or environment), built to perform unit tests on the APP software application when it is deployed on a first configuration of CONFIG1 servers referred to as reference, consisting of an NI number of connected servers; between them (where NI denotes an integer greater than or equal to 1);
  • An ENV2 test software tool built to carry out load-management tests of the APP software application when it is deployed on a second CONFIG2 server configuration called initial, consisting of a number N2 of servers interconnected (N2 designating an integer greater than or equal to 1), and taking into account the deployment constraints of the APP software application when it goes into production;
  • This configuration CONFIG2 is selected by the module 3 so as to support a target load determined targ.
  • the module 3 is configured to take into account the average execution times and maximum theoretical load maxl determined by the module 2, and to use a numerical model reflecting the deployment constraints of the application. software in real-world execution environment (eg types of machines used, multi-site deployment, required network connections, etc.).
  • the module 3 is also configured to determine a theoretical maximum load Xmax1 for the initial configuration CONFIG2 thus selected; and
  • This target configuration is determined by the module 4 by carrying out several load-bearing tests on the initial configuration CONFIG2 by means of the test tool ENV2: the module 4 readjusts if necessary at the end of each of the tests, according to the results obtained (in terms of the average response time, in particular of the software application on the tested configuration), the resources and the parameters of the servers from the initial configuration CONFIG2 until a configuration is determined which makes it possible to guarantee a maximum response time TRmax set for the APP software application and that supports targ target load.
  • Nl 1
  • the generalization of the invention to a more complex reference configuration comprising a plurality of servers interconnected and on which are deployed different deployment units of the APP software application is mentioned later.
  • the ENVI test tool is a test software environment similar to those conventionally built for debugging software applications and known to those skilled in the art. It is therefore not described in detail here.
  • This environment ENVI allows the module 2 to collect various metrics, for each type of requests identified as relevant for the services offered by the APP software application, each type of request considered being associated with a single service offered by the application.
  • the module 2 collects from the unit tests conducted in the ENVI test environment a metric representative of the average CPU consumption by the software application APP on the server SU of the reference configuration.
  • CONFIGl for the processing of a request of each type of retained queries, in other words for each service.
  • This metric is defined here as the average execution time of a request of the service envisaged by the server of the reference configuration CONFIG1 (in other words the average processing time of such a request by the server or the response time means of server to such a request).
  • the execution time of a request by a server is defined as the sum of the execution times of the processes of the APP software application (or even tasks or threads, more commonly referred to as "threads" in English) associated with the request after / before entries / exits.
  • the module 2 can collect a metric representative of an average rate of CPU usage on the server in question, the CPU utilization rate being defined as the percentage of time during which the processor (s) of the server is (are) active (s) in relation to the duration of observation during the processing of the request. This metric can also be evaluated from the average time of execution of a request by the server considered, as detailed later.
  • This resource is indeed the most critical and sensitive when considering a dynamic management of resources in a cloud-type system compared for example to memory.
  • a metric representative of the RAM consumption defined from the volume of RAM used for the processing of the request
  • a metric representative of a network consumption defined as the time elapsing between the completion of the request on a server and the start of execution of the request on the next server (which could be the same server);
  • the unit tests performed with the ENVI test tool are based on scenarios (that is, use cases of the application) of issuing each request after the receipt and processing of the previous request so that there is no concurrent access to resources (CPU here) whose consumption is to be quantified.
  • scenarios that is, use cases of the application
  • Each scenario follows sequential or parallel sequencing of the functions that make up the software application (also referred to as flow or execution graph or "workflow" in English).
  • these scenarios may consist of transmitting an integer K of requests in a deterministic or periodic manner if the processing time of a request is not significant, and without concurrent access to the CPU resources.
  • the queries considered in the scenarios implemented by the ENVI test tool correspond to queries considered as relevant to the services offered by APP software application.
  • the description of the services offered by the APP software application and the types of requests invoking these services is obtained for example from the administrator and / or the developer of the APP software application, as indicated in more detail later.
  • the unit tests carried out in the ENVI test environment thus make it possible to quantify a resource consumption at each server of the reference configuration considered for the processing of requests but without concurrent access to these resources: they therefore do not provide any information strictly speaking in terms of server response time in a real execution environment.
  • This response time information the knowledge of which is used here to size the resources of the production configuration of the APP software application to achieve a given targ target load (i.e. a volumetry imposed on the application APP software), are obtained in a second time thanks to the ENV2 test tool which makes it possible to carry out load tests on another server configuration (ie the initial configuration CONFIG2) built by the module 3 from the results. of unit tests obtained by module 2.
  • the configuration of initial servers CONFIG2 is chosen by the module 3 so as to be representative of the various constraints and functionalities expected during the production of the software application, and in particular of the software complexity, technical and functional of the actual execution environment of the software application (also called production environment).
  • the initial configuration of servers CONFIG2 must comprise a plurality of nodes materializing the "multi-site" component, a central node orchestrating the data conveyed by the plurality nodes, and model the communications between the different nodes on which the software application is based.
  • the initial server configuration may, however, include a reduced number of servers N2 compared to the number of sites on which it is planned to actually deploy the application in order to limit the cost, complexity and time of the tests to be performed.
  • N2 the number of servers on which it is planned to actually deploy the application in order to limit the cost, complexity and time of the tests to be performed.
  • this feature should be reflected in the initial configuration of servers.
  • the type of machines used eg mono or multiprocessor, maximum capacity of machines, etc.
  • the module 3 selects the initial configuration CONFIG2 using this numerical model MOD and taking into account, on the one hand, the results of the unit tests carried out on the reference configuration CONFIG1 (and notably the average execution times obtained for each server of the reference configuration for each type of request considered (ie for each service), and the theoretical maximum load) that serve as a reference for sizing the resources of the initial configuration CONFIG2, and secondly, the targ target load set for the software application APP (that is, the volumetry imposed on the APP software application).
  • the initial configuration CONFIG2 selected by the module 3 is therefore a reduced sample of the server configuration on which is intended to be put into production the software application APP.
  • This initial configuration CONFIG2 is used according to the invention as a starting point by the module 4 of the determination system 1 for sizing the resources required to execute the APP software application in a production environment.
  • the module 4 is configured to perform a resource adjustment of the initial configuration CONFIG2 based on load-holding test results made using the test tool ENV2 to determine a server configuration.
  • "Target" CONFIG_TARG to deploy the APP software application in a production environment.
  • the test tool ENV2 takes into account the deployment instances of the software application APP on the servers of the configuration CONFIG2, as well as of the topology connecting the instances, of the perimeter of the software application APP relative to to its environment (ie applications or third-party software products, terminals, etc.), communication protocols implemented, etc. It also takes into account the software and hardware characteristics of the CONFIG2 configuration, and in particular the configuration of physical machines and virtual machines (servers), storage spaces, network aspects, and parameterization of intermediate products (or "middleware"). English) as application servers, databases, buses and communication protocols, etc.
  • FIG. 2 schematically illustrates an example of such an ENV2ex test environment developed for testing a software application deployed on a server configuration comprising a presentation server 6, an application server 7 and a data server 8. An instance of the software application is installed on the application server 7.
  • HTTP HyperText Transfer Protocol
  • the servers 6, 7 and 8 are connected to a storage area 10, via the NFS (Network File System) protocol.
  • the APP software application interacts with third-party devices, such as for example a server of a shared exchange zone 11 and a rebound server 13, and various external systems 12 and 14 modeled using partner simulators.
  • the ENV2 test tool includes:
  • Load load modules or devices capable of generating and supplying the software application APP with different load levels generated by virtual users (each load level corresponding to a number of different virtual users), and measure average or median response times to requests made by these virtual users.
  • These load injection modules are here CLIF modules based on a fractal component model and described in particular in the document by B. Dillenseger entitled “CLIF, a framework based on Fractal for flexible, distributed load testing", Annals of Telecommunications, vol. 64, No. 1-2, February 2009; and
  • Probes making it possible to observe different metrics of resource consumption (CPU, memory, networks, etc.) by the software application on the servers of the tested configuration.
  • the test tool ENV2 is configured to inject, via its charge injection modules, automatically, over a fixed duration and according to a predetermined injection policy described in more detail later, different charge levels (ie different numbers increasing requests per unit of time) to the server configuration tested and supporting the APP software application.
  • the ENV2 test tool is programmed for this purpose to observe, after the injection of each load level, the behavior of the tested server configuration, and decide according to this behavior of the next level of charge to be injected. The process is reiterated until a predetermined criterion is reached.
  • the test tool ENV2 uses, in accordance with the invention, load injection scenarios. relying on user request profiles representative of the actual or at least expected use of the APP software application in a production environment (or as close as possible). Such profiles can be obtained for example from the developer and / or the administrator of the APP software application. They include information relating to the frequency of arrival of requests, and more particularly:
  • the queries injected by the ENV2 test tool are no longer systematically spaced deterministically (eg periodically) or sequentially as for the unit tests performed by the ENVI test tool, but "lumps" of queries can occur. produce and cause concurrent access to shared resources, which may cause a momentary collapse of the APP software application (ie the software application is full and no longer responding).
  • a bottleneck is formed on a server (corresponding to a peak request rate much higher than the average rate) and persists, the risk of collapse of the software application can become significant and the response time of it to degrade quickly.
  • the behaviors observed in terms of response time and resource consumption of the software application using this test tool ENV2 can therefore be very different from those that can be observed during unit tests performed at the same time. using the ENVI test tool.
  • the APP software application can experience reproducible variations of use over a time window, commonly called "activity cycle".
  • activity cycle a time window
  • the division into periods of time is preferably carried out so as to ensure that over a given period of time, the average throughput of the requests is representative of the actual values of observed flows. This division is then taken into account at the level of the ENV2 test tool.
  • FIGS. 3A and 3B illustrate, for two distinct services of a software application, the distribution of the number of arrival of requests over a 24h activity cycle.
  • two to five periods of time can be distinguished in which the average flows are fairly representative with respect to the actual values of observed flow rates (and very different from the overall average flow rate over the 24h activity cycle).
  • a division into two periods of time may consist of a first period of 8h to 8h approximately and a second period of 8h to 00h.
  • a division into four periods of time can be envisaged as consisting of a first period between Oh and 5:30, a second period between 5:30 and 10:00, a third period between 10:00 and 12:30 and a fourth period between 12:30 and 24:00.
  • the probes of the ENV2 test tool are configured to collect various metrics, and in particular here: The end-to-end response time of the user requests as a function of average arrival rates and the distribution of the inter-arrivals of user requests of the software application APP; and
  • the utilization rate of the processor or processors of this server or the execution time of the request by the server.
  • the module 4 of the determination system 1 is configured to adjust the resources and the parameters of the servers of the initial configuration CONFIG2 according to the results of load-bearing tests carried out using the tool ENV2 test.
  • This adjustment which is based here on several load-bearing tests suitably parameterized in terms of the load injected to limit the complexity of implementation of these tests, allows the module 4 to determine a configuration of "target" servers (configuration CONFIG_TARG) for deploying the APP software application in a production environment that checks the maximum response time TRmax set for the software application and supports targ target load.
  • the test environment ENV2 also makes it possible to carry out endurance or availability tests on the configuration of CONFIG_TARG servers after its determination by the module 4. These tests are intended to validate the dimensioning and the Parameterization of resources made from unit tests and load-bearing tests, the latter being supposed to correspond to a real deployment but on a reduced scale. It is, thanks to the tests of endurance, to test the software application and the configuration of target servers CONFIG_TARG over a sufficiently long duration (typically several days) in order to take into account rare events or whose probability of appearance is weak.
  • the test scenarios considered for these endurance tests consist of distributing the user requests according to the different types of services invoked, and to issue these requests according to a certain load estimated from the load-bearing tests for the target configuration CONFIG_TARG and according to inter-arrival distributions of predefined queries: deterministic, random, burst, etc.
  • the metrics collected after these tests are similar to those collected after load-bearing tests (end-to-end response time of the application, resource utilization rate (CPU, RAM, pool threads, etc.) of each server, etc.).
  • the ENVI and ENV2 test tools and the modules 2 to 4 of the determination system 1 are software modules defined using instructions of computer programs stored in memory of one or more several physical machines.
  • Each of these machines here has the hardware architecture of a computer and includes in particular a processor, a read only memory, a random access memory, a non-volatile memory and a communication module including other machines or computers.
  • the ROM of each machine is a recording medium according to the invention, readable by the processor of the machine and on which is recorded a computer program according to the invention comprising instructions for the execution of a or several steps of the sizing process according to the invention.
  • the service level agreement (SLA) defined for the software application APP is provided to the determination system 1.
  • this SLA defines the requirements in terms of the quality of the user services UC1,..., UCN offered by the software application APP, and in particular, in terms of volumetry (eg target targ load), availability and maximum expected response time TRmax from end to end.
  • volumetry eg target targ load
  • TRmax maximum expected response time
  • the services UC1,..., UCN are services considered as representative in terms of resource consumption, that is to say the consumption of resources for the provision of these services by the software application APP. is considered significant by the administrator or developer of the software application.
  • the services UC1, .., UCN depend, of course, on the software application in question.
  • the determination system 1 also has, as previously mentioned, profiles of the user requests representative of the actual or at least expected use of the APP software application in a production environment (or as close as possible). Via these profiles, the determination system 1 knows for each of the services UC1, ..., UCN, a percentage (i.e. proportion) of user requests invoking this service among the requests addressed to the APP software application.
  • These user requests may be of a different type (type) depending on the service they are invoking. They trigger the execution sequences of the software application and lead to consumption of software and hardware resources.
  • the invention makes it possible to establish a model of consumption of resources of the software application taking into account the user requirements for each of these services.
  • types of requests For example, one can have for example the following types of requests:
  • Each request profile associated with a service also includes, as mentioned above, information representative of the distribution of inter-arrival times of requests invoking this service. Such information particularly specifies whether the inter-arrival times of the requests for a given service follow a deterministic or burst-like distribution, such as for example a random or exponential distribution, by specifying the parameters of such a distribution for it corresponds to the average time associated with the service in question (eg "on" duration during which the application receives requests and "off” duration, etc.).
  • a deterministic or burst-like distribution such as for example a random or exponential distribution
  • the determination system 1 also has information on the deployment constraints imposed during the production of the APP software application. These constraints include the type of deployment architecture envisaged (presented for example in the form of a graph of nodes associated with the deployment units of the APP application). They can also relate to the characteristics of the servers (eg types of machines envisaged), for example on the capacity and the possibility of extension of CPU or RAM of a server, on the use of mono or multiprocessor servers or even a cluster of servers, the configuration type of deployment units of the APP application, and so on. This information may be provided in particular in the SLA.
  • the type of deployment architecture envisaged presented for example in the form of a graph of nodes associated with the deployment units of the APP application. They can also relate to the characteristics of the servers (eg types of machines envisaged), for example on the capacity and the possibility of extension of CPU or RAM of a server, on the use of mono or multiprocessor servers or even a cluster of servers, the configuration type of deployment units of the APP application, and so on. This information may be provided
  • the determination system 1 makes it possible to size the resources required to execute the APP software application on a server configuration, with a view to its deployment in a real execution environment, the configuration of servers. duly dimensioned being able to check the maximum overall response time TRmax and support targ target load.
  • the determination system 1 relies on unit tests performed on a "minimal" reference server configuration (namely the configuration CONFIG1) to obtain an estimate of the resource consumption of the software application APP.
  • This resource consumption is characterized here:
  • the choice of configuration CONFIG1 has already been detailed previously.
  • the determination system 1 therefore has, prior to the execution of the unit tests, a description of the configuration of servers CONFIG1 and the characteristics of the servers involved in this configuration (step E10).
  • the reference configuration CONFIG1 may include several servers connected to each other.
  • the determination system 1 via its test tool ENVI performs unit tests on the configuration of CONFIG1 servers from scenarios defined for each type of request identified as relevant for the services UC1, ..., UCN offered by the APP software application (step E20).
  • the module 2 of the determination system 1 harvest metrics quantifying the resource consumption by the software application on the SU server during the processing of the requests of the App.
  • the requests are sent to the software application in a deterministic manner so as not to have competing access to the resources (eg CPUs here) whose consumption is to be evaluated using metrics harvested.
  • the metrics obtained by the module 2 during the unit tests correspond for each type of request associated with a service UCi offered by the software application, to the CPU consumption denoted E (UCi, Sll) by the software application on the SU server to execute a request of this type.
  • Each metric E (UCi, Sll) is more precisely here a measure of the average execution time of a request associated with the service UCi on SU server (or equivalent, a measure of the average CPU utilization rate of the SU server to handle this request).
  • the module 2 evaluates from the average execution time E (S11), the utilization rate ⁇ (511) of the server SU.
  • the module 2 uses for this purpose the following relation:
  • the module 2 here estimates the theoretical maximum load Xmaxl for the CONFIGl reference configuration (step E40).
  • the invention is based on a so-called stability condition of the software application according to which, for the software application APP to be stable, it is necessary that the arrival rate ⁇ of the requests on a server (which defines here the load of the software application) is strictly lower than the utilization rate of this server.
  • a server which defines here the load of the software application
  • the module 2 uses the maximum theoretical load as the upper bound Xmax1:
  • the module 2 can take as the upper limit maxl of the maximum theoretical load a value - - e with e real number strictly positive.
  • the module 2 uses here as upper bound:
  • the upper bound Xmax1 thus determined by means of the equality (2) or (6) is subsequently used by the module 2, and more generally by the determination system 1, as an estimate of the theoretical maximum load of the software application in the CONFIGl reference configuration.
  • the maximum theoretical load maxl estimated by the module 2 gives an upper limit for the request rate values that can be supported by the software application APP in the configuration of reference servers CONFIG1.
  • the module 2 determines, from this upper bound, a value of flow (i.e. a load) ⁇ said admissible for the configuration CONFIG1 (step E50) according to:
  • FIGS. 5A to 5D illustrate the impact of the choice of the parameter a on the performances of the software application APP.
  • FIG. 5A schematically represents the general appearance of the average response time (expressed in milliseconds) of a software application APP deployed on a number NS of servers, NS> 1, as a function of the average bit rate of injected requests (expressed in number of queries per second).
  • Such a figure can be obtained by carrying out load-bearing tests, for example using the ENV2 test environment.
  • the zone ZI materializes an area where the servers of the considered configuration are underutilized (zone of underutilization of the resources);
  • the average response times of the software application APP follow a second linear regime in which they degrade more rapidly than the increase in the corresponding load.
  • saturation of the servers and the software application may occur, in other words, at least some of the servers of the tested configuration are overloaded;
  • the mean response times of the software application APP are in the vicinity of the change of speeds. They must of course be limited by the value TRmax of the maximum response time deemed acceptable for the software application. In this zone, the maximum capacity of some servers in the server configuration can be reached.
  • the end of the first linear regime (and therefore the zone ZI) is much easier to characterize than the load value marking the beginning of the overload of the servers of the software application (beginning of zone Z2) because this value is particularly unstable.
  • the inventors have found by experience that the "limit" load materializing the end of the zone optimal ZOpt can be considered as also materializing the beginning of the zone Z2, because beyond this limit load, the saturation of the servers and the software application becomes imminent.
  • This limit load can be considered as the load value corresponding to the maximum response time TRmax deemed acceptable for the software application APP. It can also be considered that the end of the zone Z2 corresponds to the maximum theoretical load max1 given by the upper bounds of the inequalities (2) and (5).
  • the parameter a is chosen so that the load ⁇ is in the zone ZOpt. This makes it possible to optimize the use of the servers on which the software application is deployed while respecting the maximum response time required.
  • FIGS. 5B-5D respectively represent the results of three series of load-bearing tests performed on a software application deployed on a server configuration, these results illustrating the average response times obtained as a function of the average request rates sent to the server.
  • software application and varying the inter-arrivals of the requests according to a deterministic distribution see FIG. 5B
  • an exponential distribution see FIG. 5C
  • a burst distribution see FIG. 5D.
  • the parameter a can be chosen equal to approximately 0.95 for deterministic inter-arrivals, 0.80 for exponential inter-arrivals and 0.50 or 0.60 for burst inter-arrivals.
  • the module 2 selects a value of the parameter a between 0.80 and 0.95. It thus obtains the value of admissible load ⁇ from equation (6) (step E50).
  • the module 2 selects a value of the parameter a taking into account the inter-arrival distributions of the requests specified in the request profiles associated with the different services UC1,..., UCN, for example based on the values above (0.95 for deterministic inter-arrivals, 0.80 for exponential inter-arrivals).
  • the different elements estimated by the module 2 from the reference configuration CONFIG1 and the unit tests are then used in accordance with the invention of reference data for any server sizing in the future.
  • production environment of the APP software application in which requirements in terms of server characteristics and volumetry are predefined by the SLA.
  • the sizing of the servers of this production environment of the software application APP is done in two stages by the determination system 1:
  • step E60 selection by the module 3 of an initial server configuration (namely the configuration CONFIG2) for the deployment of the software application including the determination of the number servers of this configuration and their parameters according to the volume required in the SLA (ie targ target load) (step E60), and the estimation of the theoretical maximum load for this configuration CONFIG2 (step E70); and
  • step E80 (2) adjustment by the module 4 of the number and parameters of the servers of the configuration CONFIG2 to satisfy the end-to-end maximum response time TRmax required in the SLA (step E80), and obtaining the target server configuration CONFIG_TARG (step E90).
  • each queuing system is a formalism composed of a queue and a server, and is mainly characterized by:
  • a policy for scheduling server requests eg FIFO (First In First Out), PS, RR, etc.
  • a processor (CPU) of the server is modeled by a server of a queue
  • the execution time of a request corresponds to the service time
  • FIG. 6A shows a modeling by a queue system of a software application running on a single-processor server
  • FIG. 6B represents a modeling by a queue system of a software application running on a multiprocessor server comprising m identical processors
  • FIG. 6C shows a modeling by a queue system of a software application running on a cluster of n identical multiprocessor servers.
  • deployment units of the software application can be distributed and deployed on servers or server clusters interconnected via a telecommunications network (NW), and then modeled by a network of queues, an example of which is shown in Figure 6D.
  • NW telecommunications network
  • Module 3 therefore associates a system or queue network model with the CONFIG2 configuration, depending on the constraints imposed for the deployment. It should be noted that this association can be performed upstream of the determination method according to the invention, for example since the deployment constraints of the APP software application are known.
  • the module 3 establishes a relation (that is to say a correspondence rule) between the average execution times of the servers or cluster (s) of servers CONFIG2 configuration with those of the or servers of CONFIGl configuration.
  • a relation that is to say a correspondence rule
  • the module 3 establishes for example the following relationships (MOD digital model in the sense of the invention) taking into account the targ target load and the estimated load ⁇ estimated by module 2 for the CONFIGl reference configuration:
  • step E60 For a software application running on a CONFIG2 configuration consisting of a single single-processor server S21 (see modeled in FIG. 6A), the server S21 must be chosen such that (step E60):
  • E (S21) designates the average execution time of a request of the software application APP on the server S21.
  • This means, for example, that if the target load targ 2 x ⁇ , it is necessary that the server S21 of the initial configuration CONFIG2 is twice as powerful in terms of CPU as the server SU of the reference configuration CONFIGl. Thus, the same request can be executed by the server S21 in half the time, leading to a utilization rate twice as high in terms of CPU.
  • the module 3 estimates a maximum theoretical load max1 for the configuration CONFIG2 which is such that (step E70):
  • step E60 For a software application running on a CONFIG2 configuration consisting of a multiprocessor S21 server having m identical processors (see modeled in FIG. 6B), the server S21 must be chosen such that (step E60):
  • E (S21) designates the average execution time of a request of the software application APP on the server S21 and E (S pmc ) denotes the execution time of the request by a processor.
  • the module 3 then estimates a maximum theoretical load max2 for the configuration CONFIG2 which is in this case such that (step E70):
  • step E60 For a software application running on a configuration CONFIG2 consisting of a cluster of n identical multiprocessor servers S 21 having identical processors (see modeled in FIG. 6C), the server cluster S21 must be chosen such that (step E60) :
  • E (cluster) designates the average execution time of a request of the software application APP on the server cluster S21 and ES proc J denotes the execution time of the request by a processor of a server S21, is :
  • the module 3 then estimates a maximum theoretical load max1 for the configuration CONFIG2 which is in this case such that (step E70):
  • the module 3 can determine the power and the number of servers and / or processors of the configuration CONFIG2 from unit test results made on a reference configuration CONFIG1 implementing three deployment units of the software application APP on three servers SU, S12 and S13 and depending on the target load Attarg. More precisely, the module 3 selects in this case the power and the number of servers for the initial configuration CONFIG2 such that (step E60):
  • the module 3 then estimates a theoretical maximum load for the configuration CONFIG2 which is in this case such that (step E70):
  • the configuration CONFIG1 comprises three servers SU, S12 and S13 implementing three deployment units of the software application APP.
  • the eligible and target loads being in this example determined by the unit tests on the servers for all the services of the APP software application.
  • the module 3 then estimates a maximum theoretical load max2 for the configuration CONFIG2 which is in this case such that (step E70):
  • the theoretical maximum load value max2 thus obtained in step E70 by the estimation module 3 for the initial configuration CONFIG2 selected in step E60, and which in particular increases the targ target load, is then used by the evaluation system. determination 1, and more particularly by module 4, to limit the load-bearing tests performed on the CONFIG2 initial server configuration using the ENV2 test tool.
  • the determination system 1 then carries out, through its test tool ENV2 and its module 4, load-bearing tests on the initial configuration of servers CONFIG2 (step E80).
  • the purpose of these tests is to evaluate the processing capacity (eg CPU utilization rate, response time, etc.) of the APP software application servers in the configuration of CONFIG2 servers with representative simulated user request flows. actual use of the software application.
  • the test environment ENV2 takes into account in these tests not only the requested request rate (and in particular the target load Astarg imposed by the SLA service level agreement), but also the variation of the times. which separate two consecutive query arrivals also called the inter-arrival times of the requests.
  • the CONFIG2 configuration selected by the module 3 is built from digital sizing models based solely on the average throughput of the requests sent to the APP software application and on unit test metrics for which the resources of the applications are accessed. servers without competition.
  • the variation in the times of inter-arrival of the requests has a significant impact on the end-to-end response time of the software application as mentioned above, and can be a source of congestion or even stop servers of the software application especially if clumps of requests are formed and persist over time during the execution of the software application.
  • the initial configuration CONFIG2 thus advantageously serves as a starting point for carrying out load-holding tests in the ENV2 environment by relying on injections of requests that are close to the behavior of the users of the software application APP in a production environment. It is the results of these tests that enable module 4, during step E80, to adjust and / or readjust the number and / or the parameters of the servers, the objective being to obtain a server configuration.
  • target CONFIG_TARG for production step E90).
  • the configuration CONFIG2 as selected by the module 3 to support the target load ⁇ targ was selected without taking into account variations in the inter-arrival times of the requests of the software application APP. There is therefore no guarantee that this target load is outside the congestion zone Z2 described above with reference to FIG. 5A.
  • the module 4 adjusts and / or readjusts the configuration of CONFIG2 servers during load tests, that is, sizing the resources of the configuration CONFIG2, so as to ensure that the target load Attarg is, for the adjusted configuration in the Zopt zone, ie outside the congestion zone Z2.
  • the upper limit in terms of the charges of this zone Zopt corresponds to the charge leading to the maximum response time TRmax fixed by the SLA agreement.
  • the module 4 of the determination system 1 implements a charge injection policy making it possible to minimize the number of tests carried out in the environment. ENV2.
  • the load withstand tests are performed by injecting the input of the software application and CONFIG2 configuration loads according to an algorithm detailed below. after. These charges are lower in any event than the maximum theoretical load max2 determined by the module 3, this load max2 being strictly greater than the target load Attarg. These charge injections are performed using the charge injection modules of the ENV2 test tool. The inter-arrival times of injected requests follow a distribution close to an actual use of the software application and as specified in the user request profiles. It should be noted that, advantageously, the invention does not require knowledge of the load distributions to be individually injected to each server of the CONFIG2 configuration. The invention is content with a global knowledge of the query profiles for the end-to-end software application.
  • FIG. 7 illustrates in more detail, in the form of a flow chart, the algorithm implemented by the module 4 for optimally performing during the step E80 the load-bearing tests and the adjustment of the resources of the CONFIG2 configuration.
  • the module 4 first chooses a request (load) rate Xtest1 such that (step E801):
  • the module 4 performs a first load-holding test on the initial configuration CONFIG2 from step E60 by injecting via the test environment ENV2 a load equal to Xtestl (step E802).
  • the module 4 compares the end-to-end response time TR (Xtest) of the software application APP obtained for this load Xtest1 with respect to the maximum expected response time TRmax (test step E803).
  • TR (Xtest ⁇ ) is greater than TRmax (yes answer to the test step E803), then it means that one or more servers of the configuration CONFIG2 are undersized and that it is necessary to proceed to an adjustment of the number of servers and / or their parameters and / or resources (step E804).
  • This adjustment is made by module 4 taking into account the individual consumption of each server of the tested configuration to reinforce the resources of those who are most loaded.
  • the value of exceeding the response time TR (Xtest) with respect to the maximum response time TRmax defines the ratio of this adjustment.
  • the module 4 applies an increase of the resources of the configuration CONFIG2 of the same order, either in adjusting the number of servers in the configuration, either by adjusting their parameters (eg processor power, number of processors, etc.).
  • the module 4 selects a new load value denoted Xtest1 such that Xtestl ⁇ Xtestl (step E805).
  • Xtest1 K1 x Xtest1 with K2 real predetermined constant less than 1.
  • K2 is for example taken here equal to 0.25.
  • the module 4 chooses a load Xtest1 determined as a function of the target load Xtarg, for example equal to 10% of the target load targ.
  • the module 4 performs a second load-holding test on the configuration CONFIG2, via the test environment ENV2, by injecting the load Xtestl to the software application APP (step E806). At the end of this test, it obtains the end-to-end response time TR (Xtestl) of the software application APP.
  • the module 4 determines, from the loads Xtest1 and Xtest1 and the response times of the software application APP TR (Xtest) and TR (Xtest1) obtained for these loads, an estimate of the response time of the software application for the server configuration tested for a load equal to the Xtarg target load (step E807). This estimate is denoted D (ltarg).
  • the module 4 takes as an estimate D (ltarg) the ordinate of the point A.
  • FIG. 8B illustrates this line on an example as well as the estimate D (Xtarg) obtained from this line.
  • K1 and K2 are chosen preferentially so as to obtain two points Al and A2 sufficiently distant to allow the construction of the line D.
  • the module 4 compares the value D (ltarg) with the maximum response time TRmax specified in the SLA (test step E808).
  • D (ltarg) is greater than TRmax (yes answer to the test step E808), then this means that one or more servers in the CONFIG2 configuration are undersized and that it is necessary to adjust the number of servers and / or their parameters and / or resources (step E809).
  • This adjustment is performed by the module 4, as in step E804, taking into account the individual consumption of each server of the tested configuration to reinforce the resources of those who are most loaded.
  • the value of exceeding the response time D (ltarg) with respect to the maximum response time TRmax defines the ratio of this adjustment.
  • FIG. 8B illustrates a case of D (ltarg) exceeding the maximum response time TRmax.
  • the module 4 applies an increase of the resources of the configuration CONFIG2 of the same order as (D (ltarg) - TRmax) / TRmax, either by adjusting the number of servers of the configuration, or by adjusting their parameters (ex. processor power, number of processors, etc.).
  • FIG. 8C illustrates an example where D (ltarg) is substantially less than TRmax according to the aforementioned criterion.
  • step E810 If such a case occurs (answer yes to the test step E810), it means that the CONFIG2 configuration tested (which corresponds to the configuration CONFIG2 possibly adjusted and / or readjusted) is oversized.
  • the module 4 thus proceeds to a (re) adjustment of the resources of the configuration CONFIG2 based as in step E809 on the difference (D (ltarg) - TRmax) / TRmax (step E811).
  • the module 4 selects a new load At test3 this time equal to the target load Itarg (step E812) and performs a new load-bearing test on the configuration CONFIG2 by injecting, via the ENV2 test environment, to the APP software application deployed on this configuration the Xtest3 load (step E813).
  • the module 4 compares the end-to-end response time TR (tTest3) of the software application APP obtained for this load Xtest3 with respect to the maximum expected response time TRmax (test step E814).
  • TR (ltest3) is greater than TRmax (yes answer to the test step E814) as illustrated for example in FIG. 8D, then this means that one or more servers of the configuration CONFIG2 are undersized and that it is appropriate to adjust the number of servers and / or their parameters and / or resources (step E815).
  • This adjustment is made by module 4 similarly to steps E804, E809, E811 taking into account the individual consumption of each server of the tested configuration to strengthen the resources of those who are most loaded.
  • the value of the exceeding of the response time TR (ttest3) with respect to the maximum response time TRmax defines the ratio of this adjustment, similar to that made to the adjustment steps E804, E809 and E811.
  • the configuration CONFIG2 is considered correctly sized for the deployment of the APP software application in a production environment (step E816).
  • the configuration thus adjusted constitutes the target configuration CONFIG_TARG obtained by the determination system 1 and considered for the production of the software application (step E90).
  • the algorithm implemented by the module 4 during the step E80 and represented in FIG. 7 makes it possible to compromise the number of load-holding tests carried out and the adjustment of the CONFIG2 configuration.
  • This algorithm advantageously makes it possible to validate as soon as possible the configuration of servers on which to deploy the software application APP while abstaining from carrying out too many load-holding tests because of a load increment between each test too much. low.
  • This algorithm converges very quickly to a production configuration thanks to the information acquired from modules 2 and 3 and taking advantage of the measured response time differences with respect to the maximum response time TRmax to quantify each adjustment of the server configuration tested.
  • the determination system 1 validates the configuration obtained by performing an endurance test on it (step E100). These endurance tests are carried out using the ENV2 test tool over a sufficiently long predetermined execution time (eg several days) to take into account rare events whose probability of occurrence is low.
  • User requests are divided according to UC1, ..., UCN services and issued with a certain allowable load and inter-arrival times following predefined distributions (eg deterministic, random, burst, etc.).
  • the metrics observed during this test are similar to those observed during the load handling tests (end-to-end response time of the user requests, average execution time on each server or utilization rate of the CPU, etc.). and make it possible to validate the configuration CONFIG_TARG and the dimensioning of its resources or to proceed if necessary to new adjustments in a similar way to what was done during the step E80 (step E110).
  • the sizing system 1 thus offers a configuration of CONFIG_TARG servers a / yo / 7 sized so as to check the constraints imposed by the SLA agreement, that is to say dimensioned for support, in a real production environment, the Itarg target load while respecting the maximum response time TRmax.
  • the pre-dimensioning technique proposed by the invention is based on taking into account realistic request profiles and close to the actual use of the software application.
  • any software system has a limited capacity from a hardware point of view, a collapse of the system can occur when the amount of processing momentarily exceeds the capacity of the server although the average rate is respected.
  • the target configuration obtained CONFIG_TARG at the end of step E1 is preferably considered as an initial deployment configuration making it possible to satisfy the requirements specified in the SLA, in an elasticity management method. according to the invention.
  • FIG. 9 represents, in the form of a flow chart, in a particular embodiment, the main steps of an elasticity management method according to the invention which uses as initial deployment configuration the target configuration CONFIG_TARG determined by the system determination 1 (step F10).
  • the initial target configuration CONFIG_TARG is then deployed in production and the software application APP is executed on the target configuration (step F20).
  • This execution is accompanied by mechanisms for monitoring the execution of the software application using known control metrics per se (step F30), and mechanisms for maintaining, adding or removing resources according to the metrics of the software application. supervision and predetermined rules (step F40), so as to absorb momentary bursts during the execution of the application and guarantee response times consistent with the SLA.
  • Such a mechanism is described, for example, in the document by L. Letondeur et al. entitled “Planning for automatic application elasticity management in the cloud,” ComPAS'2014, April 23-25, 2014.
  • Determination system 1 which determines a target configuration of servers for deploying the software application by executing the determination method according to the invention;
  • a module for monitoring at least one supervision metric of this target configuration during the execution of the software application
  • An adjustment module such as that described in the detailed document of L. Letondeur et al. and configured to adjust resources allocated to the target configuration based on said at least one metric, wherein said adjustment module is adapted to maintain allocated resources or dynamically add and / or remove resources from the target configuration.
  • the average arrival rate of the requests of the software application APP was representative of the actual flow values encountered during the execution of the software application.
  • the arrival rate of the service requests varies significantly over time and this, in a repetitive manner, thus defining cycles of activities of the software application.
  • the average rate of arrival of the requests of the software application on each activity cycle is rather insignificant compared to the actual flow values over the different periods making up the activity cycle.
  • N1 4 servers SU, S12, S13 and S14 are considered in the reference configuration CONFIG1, the three servers SU, S12, S13 being involved in the execution of the service UC1 and the two servers SU and S14 being involved in the execution of the UC2 service.
  • the Sli / Slj notation means that the equalities apply to both the Sli server and the Slj server;
  • the duration of the interval [T1] is less than a threshold, for example corresponding to the time of setting up a virtual server; and or

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Computing Systems (AREA)
  • Quality & Reliability (AREA)
  • Debugging And Monitoring (AREA)

Abstract

Le procédé comprend: l'obtention (E20) pour au moins un service offert par l'application, via au moins un test unitaire réalisé sur une configuration de serveurs de référence, d'un temps d'exécution moyen d'une requête invoquant ce service pour chaque serveur; la sélection (E60) d'une configuration de serveurs initiale supportant une charge cible, en tenant compte des temps obtenus, de la charge cible et d'une charge admissible de la configuration de référence, et en utilisant un modèle numérique reflétant au moins une contrainte de déploiement de l'application sur la configuration initiale; et la détermination (E90) à partir de la configuration initiale d'une configuration cible via des tests de tenue en charge (E80) paramétrés en fonction d'une charge maximale de la configuration initiale et de la charge cible, et en utilisant un profil de requêtes invoquant ledit au moins un service représentatif d'une utilisation de l'application en déploiement, la détermination comprenant, en fonction du résultat de chaque test, un ajustement de ressource(s) de la configuration initiale pour obtenir à l'issue des tests une configuration cible vérifiant un temps de réponse maximal et la charge cible.

Description

PROCÉDÉ ET SYSTÈME DE DÉTERMINATION D'UNE CONFIGURATION DE SERVEURS CIBLE POUR UN DÉPLOIEMENT D'UNE APPLICATION LOGICIELLE
Arrière-plan de rinvention
L'invention se rapporte au domaine général des applications logicielles.
Elle concerne plus particulièrement le dimensionnement des ressources permettant l'exécution de telles applications.
L'invention s'applique ainsi de façon privilégiée mais non limitative lorsque des applications logicielles sont déployées dans un système informatique en nuage aussi plus communément appelé « cloud » en anglais.
La gestion de l'élasticité des applications logicielles déployées en cloud est une problématique importante, notamment dans les systèmes de type « PaaS » (« Platform as a Service » en anglais ou Plateforme en tant que service). Ces systèmes, principalement destinés aux entreprises, visent à proposer des services techniques qui facilitent la construction, la mise en œuvre et l'administration des applications logicielles afin de recentrer l'attention des utilisateurs sur leurs applications. La finalité d'un système PaaS est de masquer la complexité liée à l'instanciation et à l'exploitation des applications. Pour cela, le système PaaS propose des briques techniques, accessibles au travers d'interfaces de haut niveau via un réseau de télécommunications, permettant de prendre en charge un panel important des services liés à l'administration des applications, notamment l'adaptation dynamique aux variations de charge, la sûreté de fonctionnement et la sécurité. Le périmètre fonctionnel de ces briques correspond généralement à celui rempli par un intergiciel (e.g. serveur HTTP, serveur d'application, base de données, interpréteurs de script, canevas logiciels divers...), à savoir des opérations qui peuvent être mutualisées entre plusieurs applications.
Dans ce contexte, la gestion de l'élasticité des applications logicielles déployées en cloud a pour but de fournir et d'ajuster (i.e. adapter) les ressources nécessaires au bon fonctionnement de ces applications logicielles, en termes notamment de volumétrie, de disponibilité, de temps de réponse et de fiabilité, tout en satisfaisant les contraintes spécifiques à ces applications logicielles (ex. coût, placement des machines virtuelles, droit d'utilisation, etc.). En vue d'optimiser un rapport qualité/coût, la gestion de l'élasticité doit ainsi :
— permettre de déterminer (i.e. dimensionner) les ressources nécessaires au déploiement d'une application logicielle ainsi que la configuration optimale de ces ressources, en fonction notamment d'exigences contractualisées (par exemple sous la forme d'accord de niveau de service ou encore SLA pour « Service Level Agreement » en anglais) et des ressources engagées pour d'autres applications logicielles en cours d'exécution ; et
— être capable d'ajouter ou de supprimer dynamiquement des ressources durant l'exécution de l'application logicielle, afin notamment d'absorber des « rafales » ponctuelles (instantanées) de requêtes dues à des pics d'utilisation de l'application logicielle ou au partage de l'environnement d'exécution avec d'autres applications logicielles, et de respecter ainsi les exigences contractualisées dans les SLA (ex. en termes de temps de réponse de l'application logicielle). Pour ce faire, la gestion de l'élasticité doit être en mesure de déterminer rapidement la nouvelle configuration de ressources et préciser quand doit intervenir l'opération de reconfiguration.
Les techniques de dimensionnement des ressources sont donc au cœur de la gestion de l'élasticité. Elles nécessitent généralement une bonne connaissance de l'application logicielle, notamment en termes de consommation de ressources par les instances de déploiement de l'application (ex. serveurs), mais également de profils de requêtes utilisateurs (ex. répartition par service, débits des requêtes, temps d'inter-arrivées entre les requêtes, etc.).
Dans l'état actuel de la technique, il n'existe pas de procédé structuré connu permettant de déterminer facilement les ressources nécessaires (ainsi que la configuration de ces ressources) pour le déploiement ou l'exécution d'une application logicielle. En effet, aujourd'hui, on dimensionne et on ajuste uniquement de façon expérimentale avec des outils de tests et/ou de supervision les ressources nécessaires à l'exécution d'une application logicielle à partir d'une étude de pré-métrologie. Cette façon de procéder implique un investissement très important en termes de coût et de temps : de nombreuses configurations doivent être testées avant de trouver une configuration optimale, nécessitant la mise en place d'équipements physiques et de logiciels, l'exécution de nombreux tests, etc. Une telle approche n'est donc pas toujours envisageable en pratique du fait de contraintes de temps imposées au déploiement de l'application logicielle par exemple ou de contraintes imposées en termes de retour sur investissement.
Objet et résumé de l'invention
L'invention permet de remédier notamment à cet inconvénient en proposant un procédé de détermination d'une configuration de serveurs dite cible pour un déploiement d'une application logicielle apte à offrir au moins un service, ce procédé comprenant :
— une étape d'obtention, pour au moins un service offert par l'application logicielle, au moyen d'au moins un test unitaire réalisé sur une configuration de serveurs dite de référence apte à exécuter l'application logicielle, d'un temps d'exécution moyen d'une requête invoquant ce service pour chaque serveur de la configuration de référence ;
— une étape de sélection d'une configuration de serveurs dite initiale pour le déploiement de l'application logicielle apte à supporter une charge cible déterminée pour l'application logicielle, cette étape de sélection tenant compte des temps d'exécution moyens obtenus lors dudit au moins un test unitaire, de la charge cible et d'une charge admissible déterminée pour la configuration de référence, et utilisant un modèle numérique reflétant au moins une contrainte de déploiement de l'application logicielle imposée à la configuration de serveurs initiale ; et — une étape de détermination, à partir de la configuration initiale, d'une configuration de serveurs cible destinée à être utilisée pour le déploiement de l'application logicielle, ladite étape de détermination comprenant la réalisation d'une pluralité de tests de tenue en charge paramétrés en fonction d'une charge maximale théorique estimée pour la configuration initiale et de la charge cible, et utilisant au moins un profil de requêtes invoquant ledit au moins un service offert par l'application logicielle, ce profil étant représentatif d'une utilisation de l'application logicielle lors de son déploiement, ladite étape de détermination comprenant en outre, en fonction du résultat de chaque test de tenue en charge, un ajustement d'au moins une ressource de la configuration initiale de sorte que la configuration cible obtenue à l'issue de ladite pluralité de tests de tenue en charge soit apte à vérifier un temps de réponse maximal fixé pour l'application logicielle et à supporter ladite charge cible.
Corrélativement, l'invention vise aussi un système de détermination d'une configuration cible pour un déploiement d'une application logicielle, le système comprenant :
— un premier outil de test permettant l'exécution d'au moins un test unitaire sur l'application logicielle lorsque celle-ci est exécutée sur une configuration de serveurs dite de référence ;
— un module d'obtention, configuré pour commander l'exécution d'au moins un test unitaire par le premier outil de test sur ladite configuration de référence et pour obtenir, pour au moins un service offert par l'application logicielle, un temps d'exécution moyen d'une requête invoquant ce service pour chaque serveur de la configuration de référence ;
— un module de sélection, configuré pour sélectionner une configuration de serveurs initiale pour le déploiement de l'application logicielle apte à supporter une charge cible déterminée pour l'application logicielle, ledit module de sélection étant configuré pour tenir compte des temps d'exécution moyens obtenus lors dudit au moins un test unitaire, de la charge cible et d'une charge admissible déterminée pour la configuration de référence, et pour utiliser un modèle numérique reflétant au moins une contrainte de déploiement de l'application logicielle imposée à la configuration de serveurs initiale ;
— un second outil de test permettant l'exécution de tests de tenue en charge sur ladite application logicielle lorsque celle-ci est exécutée sur la configuration de serveurs initiale sélectionnée par le module de sélection ; et
— un module de détermination configuré pour déterminer à partir de la configuration initiale une configuration de serveurs cible destinée à être utilisée pour le déploiement de l'application logicielle, ledit module de détermination étant configuré pour commander l'exécution d'une pluralité de tests de tenue en charge par le second outil de test, lesdits tests de tenue en charge étant paramétrés par le module de détermination en fonction d'une charge maximale théorique estimée pour la configuration initiale et de la charge cible, et utilisant au moins un profil de requêtes invoquant ledit au moins un service offert par l'application logicielle, ce profil étant représentatif d'une utilisation de l'application logicielle lors de son déploiement, ledit module de détermination étant en outre configuré pour ajuster, en fonction du résultat de chaque test de tenue en charge, au moins une ressource de la configuration initiale de sorte que la configuration cible obtenue à l'issue de ladite pluralité de tests de tenue en charge soit apte à vérifier un temps de réponse maximal fixé pour l'application logicielle et à supporter ladite charge cible.
Par serveur, on entend ici tout type de machine physique ou virtuelle, apte à exécuter tout ou partie d'une instance de l'application logicielle. L'application logicielle est destinée à être déployée sur une configuration (i.e. un agencement) de serveurs formée d'un ou de plusieurs serveurs reliés entre eux et vérifiant des contraintes de déploiement imposées pour la mise en production de l'application logicielle (ex. déploiement multi-sites, utilisation de machines spécifiques, etc.).
L'invention propose donc un procédé de dimensionnement des ressources nécessaires au déploiement d'une application logicielle dans un environnement de production qui s'appuie sur l'exécution structurée de deux types de tests, à savoir des tests unitaires sans accès concurrent aux ressources puis des tests de tenue en charge, judicieusement paramétrés. Ces différents tests sont réalisés sur des configurations de serveurs différentes, à savoir :
— pour les tests unitaires, sur une configuration de serveurs dite de référence, prédéterminée et relativement simple, ce qui permet d'obtenir des résultats en termes de consommation de ressources ; et
— pour les tests de tenue en charge, sur une configuration de serveurs de production dite initiale dont l'architecture reflète les contraintes imposées par le déploiement de l'application logicielle en environnement de production, et sélectionnée grâce à l'exploitation des résultats des tests unitaires réalisés sur la configuration de référence combinée à un modèle numérique permettant de mettre en correspondance les ressources des deux configurations de serveurs.
L'invention permet ainsi de déterminer de façon simple et efficace une configuration de production cible adaptée en termes de ressources au déploiement de l'application logicielle dans un environnement réel d'exécution et vérifiant les différentes exigences contractuelles qui lui sont imposées par l'intermédiaire par exemple d'un accord SLA tel que précédemment décrit. Cette configuration cible est obtenue en ajustant de façon itérative à l'issue de chaque test de tenue en charge les ressources de la configuration initiale de sorte à vérifier ces exigences.
L'ajustement des ressources d'une configuration de serveurs comprend, au sens de l'invention, le maintien, l'ajout, et/ou le retrait de ressources pour au moins un serveur de la configuration, et/ou le maintien ou la mise à jour de paramètres de cette configuration (comme par exemple le nombre de serveurs considérés dans cette configuration). Cet ajustement conduit à une configuration de production « optimale », c'est-à-dire à une configuration minimale de serveurs, permettant de garantir le respect des exigences fixées pour l'application logicielle en termes de volumétrie (i.e. de charge cible), de disponibilité et de temps de réponse de bout en bout de l'application logicielle aux requêtes des utilisateurs. Comme mentionné précédemment, la configuration de serveurs de référence utilisée pour réaliser les tests unitaires est choisie généralement de complexité relativement réduite par rapport à la configuration de serveurs sur laquelle est destinée à être effectivement déployée l'application logicielle. Cette configuration de serveurs de référence peut typiquement se limiter à une seule machine (i.e. un serveur unique), par exemple la machine sur laquelle est développée l'application. Les tests unitaires réalisés à partir de cette configuration de référence visent à caractériser, pour chaque type de requête identifié comme pertinent au regard des services offerts par l'application logicielle (ex. requêtes de type souscription, résiliation, consultations d'objets multimédia, traitement, etc.), les ressources consommées par celle-ci sur chaque serveur de la configuration de référence pour traiter ce type de requête quand il n'y a pas d'accès concurrent à ces ressources. Autrement dit, il s'agit là de quantifier l'utilisation au niveau de chaque serveur de la configuration de référence des processeurs (ou unités de traitement centrales ou encore CPU pour « Central Processing Unit » en anglais), de la mémoire (ex. disque, RAM (Random Access Memory)) et/ou encore des ressources réseaux (ex. connecteurs réseaux) sollicitées lors du traitement des requêtes.
De tels tests unitaires sont connus en soi et sont classiquement mis en œuvre lors du développement et du débogage des applications logicielles. Durant ces tests, on s'assure qu'il n'y a pas d'accès concurrent aux ressources dont on cherche à quantifier la consommation pour traiter les requêtes envoyées à l'application logicielle. A cet effet, les requêtes peuvent être par exemple envoyées une par une à l'application logicielle exécutée par la configuration de référence (une requête étant envoyée à l'issue du traitement de la précédente), ou N requêtes (N nombre entier) peuvent être envoyées de façon déterministe à l'application logicielle en s'assurant qu'il n'y ait pas d'accès concurrent aux ressources utilisées pour leur traitement.
L'invention propose de tirer profit de ces tests unitaires simples à réaliser pour récolter diverses métriques de consommation de ressources liées au traitement intrinsèque de chaque requête par chaque serveur de la configuration de référence, et plus particulièrement pour chaque service représentatif offert par l'application logicielle, pour obtenir le temps d'exécution moyen d'une requête invoquant ce service par chaque serveur de la configuration de référence. D'autres métriques peuvent bien entendu être obtenues lors de ces tests unitaires, comme par exemple le nombre de connecteurs réseau utilisés simultanément, le volume de RAM utilisé sur chaque serveur, la durée et le volume de disque occupé, la durée s'écoulant entre la fin d'exécution de la requête sur un serveur et le début d'exécution sur le serveur suivant, etc. Les métriques ainsi récoltées servent d'entrées, conformément à l'invention, à des modèles numériques reflétant diverses exigences imposées en termes d'architecture notamment ou de types de machines à la configuration de production (c'est-à-dire diverses contraintes de déploiement de l'application logicielle) et sont exploitées pour sélectionner une configuration de production initiale satisfaisant une volumétrie (charge en termes de débit de requêtes) cible fixée pour l'application logicielle. Les modèles numériques considérés modélisent par exemple les contraintes (exigences) de déploiement de l'application logicielle à partir d'au moins une file d'attente ou d'un réseau de files d'attente.
Il convient de noter que la sélection de la configuration de production initiale se fait sur la base de résultats de tests unitaires conduits dans un environnement d'exécution idéal où les requêtes ne subissent aucune concurrence pour l'accès aux ressources. Les tests unitaires permettent donc de déterminer uniquement quels sont les besoins de l'application logicielle en ressources CPU, mémoire, et/ou réseau pour traiter intrinsèquement chaque requête. La configuration de production initiale sélectionnée conformément à l'invention ne tient donc compte que d'une volumétrie à respecter et du temps d'exécution intrinsèque des requêtes en découlant. Toutefois ces hypothèses ne sont pas représentatives des conditions réelles d'utilisation de l'application logicielle dans lesquelles les requêtes des utilisateurs arrivent généralement de façon non déterministe, typiquement par rafales et avec des débits parfois très différents du débit moyen des requêtes. Les tests unitaires ne fournissent donc aucune information sur le temps de réponse à proprement parler de l'application logicielle dans un environnement de production, de sorte qu'un ajustement des ressources de la configuration de production initiale sélectionnée à l'issue des tests unitaires est proposé par l'invention pour tenir compte des exigences imposées à l'application logicielle en termes notamment de temps de réponse maximal de bout en bout.
Ces ajustements sont encadrés par des tests de tenue en charge dûment paramétrés et qui permettent de dimensionner les ressources nécessaires à la mise en production de l'application logicielle. Ces tests de tenue en charge prennent en effet en compte non seulement les contraintes en termes de volumétrie de l'application logicielle, mais également le profil des requêtes invoquant les services offerts par celle-ci et en particulier la nature des temps d'inter- arrivées des requêtes (i.e. la distribution d'arrivée de ces requêtes au niveau de l'application logicielle). Ainsi, un profil de requêtes invoquant un service comprend par exemple, pour au moins une période de temps déterminée d'un cycle d'activité de l'application logicielle ou d'un cycle d'activité de l'application logicielle :
— un débit moyen des requêtes invoquant ce service sur ladite période de temps ;
— une proportion de requêtes invoquant ce service parmi les requêtes invoquant des services offerts par l'application logicielle ; et
— une distribution des durées d'inter-arrivées entre deux requêtes invoquant ce service sur ladite période de temps.
En d'autres mots, les tests de tenue en charge prennent en compte un profil de requêtes réaliste représentatif de l'utilisation de l'application logicielle dans un environnement réel d'exécution (i.e. similaire ou tout du moins proche de celui auquel on s'attend lors de la mise en production de l'application logicielle).
Il convient de noter que la configuration de production initiale sélectionnée par l'invention n'est pas nécessairement strictement conforme à la configuration de serveurs qui sera déployée ultérieurement en production et testée dans un environnement réel d'exécution. Elle peut être notamment de complexité plus réduite, mais elle est sélectionnée préférentiellement de sorte à être représentative des différentes fonctionnalités et problématiques attendues lors de la mise en production de l'application logicielle. Ainsi, la configuration de serveurs initiale est choisie préférentiellement de sorte à être représentative de la complexité logicielle, technique et fonctionnelle de l'environnement de production de l'application logicielle (ex. présence d'un nœud maître et de plusieurs nœuds secondaires qui communiquent entre eux, modélisation de la communication inter-sites, prise en compte des problèmes de sécurité, etc.). De cette sorte, on s'assure que le dimensionnement des ressources réalisé par l'invention est pertinent et exploitable pour faciliter le déploiement en production de l'application et limiter les tests réalisés à grande échelle.
Plusieurs configurations de serveurs cibles peuvent être identifiées à partir de l'invention. La sélection de l'une de ces configurations peut ensuite être réalisée à partir de tests expérimentaux réalisés dans l'environnement de production. Toutefois le nombre de configurations de serveurs à tester est considérablement réduit par rapport à l'état de la technique.
L'invention se distingue donc de l'état actuel de la technique en ce qu'elle offre une solution qui permet, avant la mise en production de l'application logicielle, de présélectionner et de dimensionner, au moyen de modèles numériques, une ou plusieurs configurations de serveurs appropriées qui servent de points de départ pour le déploiement réel de l'application. Ainsi, contrairement à l'état de la technique, la sélection de la configuration optimale ne s'appuie pas uniquement sur des tests expérimentaux réalisés en production dans un environnement réel d'exécution et qui peuvent s'avérer, comme mentionné précédemment, hasardeux, coûteux et chronophages. L'invention offre au contraire une possibilité de pré-provisionner les ressources nécessaires à l'exécution d'une application logicielle, ce qui permet d'effectuer de tels tests expérimentaux uniquement sur un nombre réduit de configurations en vue de sélectionner une configuration optimale. On obtient ainsi grâce à l'invention un gain substantiel en complexité et en temps.
L'invention permet donc, par rapport aux solutions existantes basées essentiellement sur des observations expérimentales, d'assurer la maîtrise et l'efficacité de la gestion de l'élasticité, et de réduire les coûts d'investissement pour des applications logicielles et des systèmes de type PaaS.
Il convient de noter par ailleurs que de façon avantageuse, la mise en œuvre de l'invention ne requiert pas de connaissance détaillée des composants logiciels constituant l'application logicielle ni de l'enchaînement d'exécution de ces composants. L'application logicielle peut avantageusement être considérée comme une « boîte noire » offrant un ou plusieurs services en réponse à des requêtes d'utilisateur vérifiant un certain profil, et répartie ou instanciée sur un ou plusieurs serveurs. Les métriques de consommation des ressources issues des tests unitaires et qui sont ensuite utilisées pour sélectionner une configuration de serveurs initiale sur laquelle sont effectués les tests de tenues en charge sont des métriques tous composants confondus mesurées sur chaque serveur de la configuration de référence.
Dans un mode particulier de réalisation de l'invention, le procédé de détermination comprend en outre une étape d'estimation d'une charge maximale théorique pour la configuration de référence et la charge admissible déterminée pour la configuration de référence résulte du produit d'un paramètre a compris entre 0 et 1 par la charge maximale théorique estimée pour la configuration de référence.
Par exemple, la charge maximale théorique pour la configuration de référence est estimée en appliquant une condition de stabilité de l'application logicielle à au moins un temps d'exécution moyen d'une requête de l'application logicielle dérivé pour ledit au moins un serveur de la configuration de référence à partir des temps d'exécution moyens obtenus pour ce serveur pour les services offerts par l'application logicielle.
Une telle condition de stabilité est vérifiée notamment si pour chaque serveur de la configuration de serveurs considérée pour exécuter l'application logicielle, le taux (débit) d'arrivée des requêtes est strictement inférieur au taux d'utilisation de ce serveur. Le temps de réponse du serveur peut être utilisé pour évaluer son taux d'utilisation. Cette condition de stabilité permet d'évaluer facilement une charge théorique maximale pour l'application logicielle aux alentours de laquelle l'application logicielle n'est plus capable de traiter les requêtes. Cette charge théorique maximale est utilisée pour dimensionner la configuration de serveurs initiale.
Par ailleurs, les inventeurs ont observé qu'en amont de cette charge théorique maximale, le temps de réponse moyen d'un serveur en fonction de la charge de l'application logicielle suit généralement un premier régime linéaire en pente douce suivi d'une montée brutale définissant un deuxième régime linéaire à l'approche de la saturation du serveur. Le paramètre a compris entre 0 et 1 utilisé pour définir la charge admissible de la configuration initiale est choisi préférentiellement pour que la charge admissible considérée se situe dans une zone de transition se trouvant juste avant le deuxième régime linéaire et dans laquelle le temps de réponse de bout en bout de l'application logicielle reste inférieur à un temps de réponse maximal fixé pour l'application logicielle (typiquement dans l'accord SLA). Dans cette zone « optimale », le temps de réponse versus la charge est contenu et reste inférieur au temps de réponse maximal autorisé pour l'application logicielle. On note que la valeur du paramètre a peut dépendre de la distribution des temps d'inter-arrivées des requêtes, comme détaillé ultérieurement. Toutefois une valeur de 0.8 ou 0.85 (ou aux alentours de ces deux valeurs) convient généralement assez bien pour mettre en œuvre l'invention.
Dans un mode particulier de réalisation, au cours de l'étape de détermination, l'ajustement d'au moins une ressource de la configuration initiale à l'issue d'un test de tenue en charge est réalisé en fonction d'une différence entre un temps de réponse de l'application logicielle évalué lors du test de tenue en charge et le temps de réponse maximal fixé pour l'application logicielle. Cette façon d'ajuster les ressources en tenant compte du temps de réponse maximal fixé pour l'application logicielle et le temps de réponse obtenu de bout en bout avec la configuration de serveurs en cours de test permet de converger rapidement vers un dimensionnement approprié des ressources.
Dans un mode de réalisation, l'étape de détermination comprend au moins :
— un premier test de tenue en charge réalisé avec une première charge inférieure à une valeur minimum entre une moitié de la charge maximale théorique estimée pour la configuration initiale et le produit de la charge cible par un nombre réel prédéterminé inférieur ou égal à 1 ;
— un deuxième test de tenue en charge réalisé avec une deuxième charge inférieure à la première charge ; et
— un troisième test de tenue en charge réalisé avec une troisième charge égale à la charge cible.
Ce protocole permet de limiter les tests de tenue en charge réalisés sur la configuration de serveurs initiale et d'aboutir rapidement à une configuration de serveurs cible dérivée de la configuration initiale. Par configuration dérivée de la configuration initiale on entend au sens de l'invention que la configuration est la même que la configuration initiale si celle-ci est considérée comme correctement dimensionnée ou qu'elle est obtenue après avoir ajusté des ressources de la configuration initiale.
Dans ce mode de réalisation, l'étape de détermination peut comprendre en outre une estimation à l'issue du deuxième test, d'un temps de réponse de l'application logicielle avec la charge cible à partir d'un temps de réponse évalué à l'issue du premier test réalisé avec la première charge sur une configuration testée dérivée de la configuration de serveur initiale et d'un temps de réponse de l'application logicielle évalué à l'issue du deuxième test réalisé avec la deuxième charge sur ladite configuration testée, l'ajustement de ressources étant réalisé à l'issue du deuxième test en fonction d'une différence entre le temps de réponse estimé pour la charge cible et le temps de réponse maximal fixé pour l'application logicielle.
Typiquement, à l'issue du deuxième test :
— la configuration de serveurs testée peut être considérée comme sous-dimensionnée si le temps de réponse estimé pour la charge cible est supérieur au temps de réponse maximal ; et/ou
— la configuration de serveurs testée peut être considérée comme surdimensionnée si le temps de réponse estimé pour la charge cible est inférieur au produit d'un nombre réel prédéterminé γ compris entre 0 et 1 et du temps de réponse maximal, par exemple 0.9 ; et/ou
— la configuration de serveurs testée peut être considérée comme correctement dimensionnée sinon.
L'ajustement des ressources est ensuite réalisé en conséquence et le ou les tests de tenue en charge précédents sont réitérés sur la configuration ajustée pour valider cet ajustement et/ou procéder à un nouvel ajustement, et ce, jusqu'à déterminer la configuration cible apte à être déployée et qui répond aux exigences fixées pour la mise en production de l'application logicielle en termes de charge et de temps de réponse de bout en bout. Typiquement, la configuration cible correspond à une configuration de serveurs testée pour laquelle à l'issue du troisième test, un temps de réponse de l'application logicielle évalué pour la charge cible sur cette configuration de serveurs testée est inférieur au temps de réponse maximal.
Dans un mode de réalisation particulier de l'invention, le procédé de détermination comprend en outre une étape de validation de la configuration cible au moyen d'un test d'endurance réalisé pendant une durée d'exécution prédéterminée de l'application logicielle.
Il s'agit par ce test d'endurance de tester l'application logicielle et la configuration de serveurs cible déterminée aux tests unitaires et aux tests de tenue en charge sur une durée suffisamment longue afin de prendre en compte, pour le dimensionnement des ressources, des événements rares dont la probabilité d'apparition est relativement faible. Le résultat de ce test d'endurance permet de réajuster le cas échéant les ressources de la configuration cible en vue du déploiement de l'application logicielle. En effet, les métriques et les modèles numériques utilisés conformément à l'invention pour déterminer la configuration cible reposent sur certaines hypothèses d'abstraction sur le comportement de l'application logicielle, et notamment d'indépendance de certains composants ou de distribution des requêtes. Le test d'endurance permet d'affiner ces modèles (et d'ajuster si besoin le dimensionnement des ressources), et dans une certaine mesure, de mettre en évidence les écarts entre la réalité et les modèles numériques utilisés établis, de les évaluer et de juger de leurs pertinences.
Dans un mode particulier de réalisation, l'application logicielle est caractérisée par un cycle d'activité comprenant une pluralité d'intervalles, chaque intervalle étant associé à un débit moyen d'arrivée des requêtes représentatif sur cet intervalle, et dans lequel lesdites étapes d'obtention, de sélection et de détermination sont mises en œuvre pour au moins un intervalle de ladite pluralité d'intervalles.
Ce mode de réalisation permet de s'adapter aux applications logicielles pour lesquelles on a une distribution dynamique des requêtes, autrement dit pour lesquelles le débit des arrivées de requêtes de services varie de manière significative sur des intervalles de temps et ce de façon répétitive sur le cycle d'activité.
Selon un autre aspect, l'invention vise également un procédé de gestion d'élasticité d'une configuration de serveurs apte à exécuter une application logicielle, ce procédé comprenant : — une étape de détermination d'une configuration cible de serveurs pour le déploiement de l'application logicielle comprenant l'exécution d'un procédé de détermination selon l'invention ; et
— une étape d'exécution de l'application logicielle sur ladite configuration cible de serveurs comprenant :
o une surveillance d'au moins une métrique de supervision de cette configuration cible ; et o en fonction de ladite au moins une métrique, un ajustement des ressources de la configuration cible, cet ajustement comprenant un maintien et/ou un ajout et/ou un retrait dynamique de ressources à la configuration cible.
L'invention vise aussi un système de gestion d'élasticité d'une configuration de serveurs apte à exécuter une application logicielle comprenant :
— un système selon l'invention de détermination d'une configuration cible de serveurs pour le déploiement de l'application logicielle comprenant l'exécution d'un procédé de détermination ;
— un module de déclenchement d'une exécution de l'application logicielle sur la configuration cible de serveurs ;
— un module de surveillance d'au moins une métrique de supervision de cette configuration cible lors de l'exécution de l'application logicielle ; et
— un module d'ajustement configuré pour ajuster les ressources allouées à la configuration cible en fonction de ladite au moins une métrique, ce module d'ajustement étant apte à maintenir les ressources allouées ou à ajouter et/ou retirer dynamiquement des ressources à la configuration cible.
Le procédé et le système de gestion d'élasticité bénéficient des mêmes avantages cités précédemment que le procédé et le dispositif de détermination selon l'invention.
Dans un mode particulier de réalisation, les différentes étapes du procédé de détermination et/ou du procédé de gestion d'élasticité sont déterminées par des instructions de programmes d'ordinateurs.
En conséquence, l'invention vise aussi un programme d'ordinateur sur un ou plusieurs support(s) d'informations, ce programme étant susceptible d'être mis en œuvre dans un système de détermination ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d'un procédé de dimensionnement tel que décrit ci-dessus.
L'invention vise également un programme d'ordinateur sur un ou plusieurs support(s) d'informations, ce programme étant susceptible d'être mis en œuvre dans un système de gestion d'élasticité ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d'un procédé de gestion d'élasticité tel que décrit ci- dessus.
Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus.
Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy dise) ou un disque dur.
D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
On peut également envisager, dans d'autres modes de réalisation, que le procédé de détermination, le procédé de gestion d'élasticité, le système de détermination et le système de gestion d'élasticité selon l'invention présentent en combinaison tout ou partie des caractéristiques précitées. Brève description des dessins
D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures :
la figure 1 représente, de façon schématique, un système de détermination conforme à l'invention, dans un mode particulier de réalisation ;
la figure 2 représente un outil de test permettant la réalisation de tests de tenue en charge sur une configuration de serveurs de référence sur laquelle est déployée une application logicielle et pouvant être utilisé comme composant du système de détermination de la figure 1 ;
les figures 3A et 3B illustrent, pour deux services distincts d'une application logicielle, un cycle d'activité de cette application logicielle et la répartition des nombres d'arrivées de requêtes sur ce cycle d'activité ;
la figure 4 représente, sous forme d'ordinogramme, les principales étapes d'un procédé de détermination conforme à l'invention dans un mode particulier de réalisation dans lequel il est mis en œuvre par le système de détermination de la figure 1 ;
- les figures 5A à 5D illustrent l'évolution du temps de réponse d'un serveur en fonction de la charge de l'application logicielle, et pour différents profils de requêtes ;
les figures 6A à 6D illustrent plusieurs modèles de systèmes de files d'attente pouvant être utilisés pour déterminer la configuration initiale selon l'invention ;
la figure 7 détaille, sous forme d'ordinogramme, les principales étapes mises en œuvre par le système de détermination de la figure 1 dans un mode particulier de l'invention pour déterminer la configuration de serveurs cible à partir de la configuration initiale ;
les figures 8A à 8D illustrent différents cas de figure conduisant à un ajustement des ressources de la configuration initiale conformément à l'invention ; la figure 9 représente, sous forme d'ordinogramme, les principales étapes d'un procédé de gestion de l'élasticité conforme à l'invention, dans un mode particulier de réalisation ; et la figure 10 illustre le traitement mis en œuvre dans un mode particulier de réalisation de l'invention lorsque l'application logicielle présente un cycle d'activité périodique.
Description détaillée de l'invention
La figure 1 représente, dans son environnement, un système 1 de détermination d'une configuration de machines pour le déploiement d'une application logicielle APP, conforme à l'invention, dans un mode particulier de réalisation. Le système 1 propose, par le biais de la configuration ainsi déterminée (désignée par configuration cible dans la suite de la description), un dimensionnement des ressources nécessaire à la mise en production de l'application logicielle APP, autrement dit à son déploiement dans un environnement réel d'exécution.
Aucune limitation n'est attachée à la nature de l'application logicielle APP. Il peut s'agir d'une application permettant l'accès à ou la génération de contenus multimédia, le référencement de produits, l'accès à des équipements distants, etc.
Cette application logicielle APP est apte à offrir un ou plusieurs services
UC1,UC2,...,UCN (N entier supérieur ou égal à 1) à des utilisateurs, sur réception de requêtes invoquant ces services émises par ces derniers via des terminaux (ex. via un terminal mobile, un ordinateur, etc.).
Dans l'exemple envisagé ici, l'application logicielle APP est destinée à être déployée (i.e. mise en production) dans un système informatique en nuage ou cloud (non représenté), sur une configuration cible de machines (serveurs) virtuelles hébergées par le cloud. Dans un tel contexte, la gestion de l'élasticité des ressources mises à disposition par le cloud pour l'exécution des applications logicielles qu'il héberge est très importante : le cloud cherche en effet à optimiser le partage des ressources communes aux applications logicielles qu'il héberge en vue de réduire notamment le coût de leur déploiement, tout en garantissant la qualité des services offerts par ces applications à leurs utilisateurs. Les ressources partagées peuvent être de différentes natures : il peut s'agir notamment de ressources de type processeurs ou CPU de machines (serveurs) virtuelles et/ou physiques, de ressources mémoires (ex. RAM, disque, etc.), ou encore de ressources réseaux (ex. connecteurs réseaux, etc.).
La gestion de l'élasticité dans le cloud a donc pour fonction de fournir aux différentes applications logicielles les ressources précitées nécessaires à leur exécution et de garantir leur bon fonctionnement selon un accord de niveau de service (ou SLA) convenu au préalable. Chaque SLA définit des contraintes spécifiques à l'application logicielle auquel il se rapporte, notamment en termes de volumétrie, de disponibilité, de temps de réponse, de fiabilité mais également de coût, de placement des machines (virtuelles dans le contexte du cloud) sur lesquelles sont déployées l'application, de droits d'utilisation et d'abonnements, etc. Autrement dit, chaque SLA associé à une application logicielle définit un certain nombre d'exigences qui se doivent d'être respectées par le cloud. La gestion de l'élasticité a pour rôle de déterminer les ressources nécessaires au déploiement de l'application logicielle APP dans le cloud afin de répondre aux exigences fixées par ce SLA et ce, tout en prenant en compte les ressources engagées pour d'autres applications logicielles hébergées par le cloud et en cours d'exécution.
Dans l'exemple envisagé ici, la gestion de l'élasticité du cloud hébergeant l'application logicielle APP s'appuie sur le système de détermination 1. Plus particulièrement, celui-ci permet une gestion efficace de l'élasticité du cloud en offrant la possibilité de procéder à un pré- provisionnement des ressources nécessaires à l'exécution de l'application APP avant sa mise en production via la détermination d'une configuration adaptée au déploiement de l'application APP dans un environnement réel d'exécution (aussi désignée par configuration « cible »).
A cet effet, conformément à l'invention, le système de détermination 1 s'appuie sur différents environnements de tests de l'application logicielle APP dans lesquels l'application est déployée sur différentes configurations de serveurs, et sur différents modules (logiciels ici) mettant en œuvre des algorithmes ou des modèles de calcul programmés exploitant les résultats obtenus dans ces environnements de tests.
Plus précisément, dans le mode de réalisation décrit ici, le système de détermination 1 comprend :
— un outil logiciel (ou environnement) de test ENVI, construit pour réaliser des tests unitaires sur l'application logicielle APP lorsque celle-ci est déployée sur une première configuration de serveurs CONFIG1 dite de référence, constituée d'un nombre NI de serveurs reliés entre eux (NI désignant un entier supérieur ou égal à 1) ;
— un outil logiciel (environnement) de test ENV2, construit pour réaliser des tests de tenue en charge de l'application logicielle APP lorsque celle-ci est déployée sur une deuxième configuration de serveurs CONFIG2 dite initiale, constituée d'un nombre N2 de serveurs reliés entre eux (N2 désignant un entier supérieur ou égal à 1), et tenant compte de contraintes de déploiement de l'application logicielle APP lors de sa mise en production ;
— un module 2 de récolte de diverses métriques lors des tests unitaires réalisés dans l'environnement de test ENVI, apte à évaluer à partir de ces métriques une consommation des ressources par les serveurs de la configuration CONFIG1 pour le traitement de requêtes invoquant des services offerts par l'application logicielle APP. Plus précisément, le module 2 est apte à obtenir ici, à partir des métriques récoltées, un temps d'exécution moyen d'une requête invoquant un service offert par l'application logicielle APP pour chaque serveur de la configuration de référence CONFIG1 et pour chaque service offert par l'application logicielle APP. Il est également configuré pour estimer à partir des temps d'exécution moyens obtenus, une charge théorique maximale maxl pouvant être supportée par la configuration de référence CONFIG1 ;
— un module 3 de sélection de la configuration de serveurs initiale CONFIG2 sur laquelle sont réalisés les tests de tenue en charge via l'environnement de test ENV2 et qui sert de point de départ au dimensionnement des ressources nécessaires pour la mise en production de l'application logicielle APP. Cette configuration CONFIG2 est sélectionnée par le module 3 de sorte à supporter une charge cible déterminée targ. Pour déterminer la configuration CONFIG2, le module 3 est configuré de sorte à tenir compte des temps d'exécution moyens et de la charge théorique maximale maxl déterminés par le module 2, et à utiliser un modèle numérique reflétant les contraintes de déploiement de l'application logicielle en environnement réel d'exécution (ex. types de machines utilisées, déploiement multi-sites, connexions réseau requises, etc.). Le module 3 est également configuré pour déterminer une charge maximale théorique Xmaxl pour la configuration initiale CONFIG2 ainsi sélectionnée ; et
— un module 4 d'ajustement des ressources et des paramètres des serveurs de la configuration CONFIG2, configuré pour déterminer à partir de la configuration initiale CONFIG2 une configuration de serveurs cible désignée par CONFIG_TARG pour la mise en production de l'application logicielle APP. Cette configuration cible est déterminée par le module 4 en réalisant plusieurs tests en tenue de charge sur la configuration initiale CONFIG2 grâce à l'outil de test ENV2 : le module 4 réajuste le cas échéant à l'issue de chacun des tests, en fonction des résultats obtenus (en terme de temps de réponse moyen notamment de l'application logicielle sur la configuration testée), les ressources et les paramètres des serveurs de la configuration initiale CONFIG2 jusqu'à déterminer une configuration qui permette de garantir un temps de réponse maximal TRmax fixé pour l'application logicielle APP et qui supporte la charge cible targ.
Dans le mode de réalisation décrit ici, par souci de simplification, la configuration de référence CONFIGl est constituée d'un serveur unique (i.e. Nl=l), par exemple, le serveur SU sur lequel a été déployée l'application APP. La généralisation de l'invention à une configuration de référence plus complexe comprenant une pluralité de serveurs reliés entre eux et sur lesquels sont déployées différentes unités de déploiement de l'application logicielle APP est évoquée ultérieurement.
L'outil de test ENVI est un environnement logiciel de test similaire à ceux construits classiquement pour le débogage des applications logicielles et connus de l'homme du métier. Il n'est par conséquent pas décrit en détail ici.
Cet environnement ENVI permet au module 2 de récolter diverses métriques, pour chaque type de requêtes identifié comme pertinent pour les services offerts par l'application logicielle APP, chaque type de requête considéré étant associé à un unique service offert par l'application. Ainsi, dans l'exemple envisagé ici, le module 2 récolte à partir des tests unitaires menés dans l'environnement de test ENVI une métrique représentative de la consommation moyenne de CPU par l'application logicielle APP sur le serveur SU de la configuration de référence CONFIGl pour le traitement d'une requête de chaque type de requêtes retenu, autrement dit pour chaque service. Cette métrique est définie ici comme le temps d'exécution moyen d'une requête du service envisagé par le serveur de la configuration de référence CONFIGl (autrement dit le temps de traitement moyen d'une telle requête par le serveur ou encore le temps de réponse moyen du serveur à une telle requête). Le temps d'exécution d'une requête par un serveur est défini comme la somme des durées d'exécution des processus de l'application logicielle APP (ou encore des tâches ou fils, plus communément désignés par « threads » en anglais) associés à la requête après/avant des entrées/sorties.
En variante, le module 2 peut récolter une métrique représentative d'un taux moyen d'utilisation de CPU sur le serveur considéré, le taux d'utilisation de CPU étant défini comme le pourcentage de temps où le ou les processeurs (CPU) du serveur est (sont) actif(s) par rapport à la durée d'observation lors du traitement de la requête. Cette métrique peut également être évaluée à partir du temps moyen d'exécution d'une requête par le serveur considéré, comme détaillé ultérieurement.
Dans le mode de réalisation décrit ici, on se limite à des métriques relatives à l'utilisation du ou des processeurs (CPU) des serveurs et au dimensionnement de ces processeurs pour déterminer la configuration cible CONFIG_TARG. Cette ressource est en effet la plus critique et la plus sensible lorsque l'on envisage une gestion dynamique des ressources dans un système de type cloud comparativement par exemple à la mémoire.
Toutefois, cette hypothèse n'est pas limitative et le dimensionnement d'autres ressources peut être envisagé grâce à l'invention, comme notamment le dimensionnement de ressources mémoire (ex. disque, RAM) et/ou réseaux. A cet effet, d'autres métriques peuvent être obtenues lors des tests unitaires réalisés dans l'outil de test ENVI comme notamment :
— une métrique représentative de la consommation de RAM, définie à partir du volume de RAM utilisé pour le traitement de la requête ;
— des métriques représentatives d'une consommation de disque, définies à partir de la durée et du volume de disque occupé lors du traitement de la requête ;
— une métrique représentative d'une consommation réseau définie comme la durée s'écoulant entre la fin d'exécution de la requête sur un serveur et le début d'exécution de la requête sur le serveur suivant (qui pourrait être le même serveur) ;
— etc.
Les tests unitaires réalisés avec l'outil de test ENVI s'appuient sur des scénarios (c'est- à-dire des cas d'utilisation de l'application) consistant à émettre chaque requête après la réception et le traitement de la requête précédente de sorte à ce qu'il n'y ait pas d'accès concurrent aux ressources (CPU ici) dont on cherche à quantifier la consommation. Chaque scénario s'ensuit du déroulement séquentiel ou en parallèle des fonctions composant l'application logicielle (aussi désigné par flot ou graphe d'exécution ou encore « workflow » en anglais).
En variante, ces scénarios peuvent consister à émettre un nombre entier K de requêtes de façon déterministe ou périodique si le temps de traitement d'une requête n'est pas significatif, et sans accès concurrent aux ressources CPU.
Les requêtes considérées dans les scénarios mis en œuvre par l'outil de test ENVI correspondent à des requêtes considérées comme pertinentes au regard des services offerts par l'application logicielle APP. La description des services offerts par l'application logicielle APP et des types de requêtes invoquant ces services est obtenue par exemple de l'administrateur et/ou le développeur de l'application logicielle APP, comme indiqué plus en détail ultérieurement.
Les tests unitaires déroulés dans l'environnement de test ENVI permettent donc de quantifier une consommation de ressources au niveau de chaque serveur de la configuration de référence considérée pour le traitement des requêtes mais sans accès concurrent à ces ressources : ils ne fournissent par conséquent aucune information pertinente à proprement parler en termes de temps de réponse des serveurs dans un environnement réel d'exécution. Ces informations de temps de réponse, dont la connaissance est utilisée ici pour dimensionner les ressources de la configuration de production de l'application logicielle APP pour atteindre une charge cible targ donnée (c'est-à-dire une volumétrie imposée à l'application logicielle APP), sont obtenues dans un second temps grâce à l'outil de test ENV2 qui permet de réaliser des tests de tenue en charge sur une autre configuration de serveurs (i.e. la configuration initiale CONFIG2) construite par le module 3 à partir des résultats de tests unitaires obtenus par le module 2.
Dans le mode de réalisation décrit ici, la configuration de serveurs initiale CONFIG2 est choisie par le module 3 de sorte à être représentative des différentes contraintes et fonctionnalités attendues lors de la mise en production de l'application logicielle, et notamment de la complexité logicielle, technique et fonctionnelle de l'environnement d'exécution réel de l'application logicielle (aussi appelé environnement de production). Ainsi notamment, si l'on envisage un déploiement multi-sites de l'application logicielle, la configuration de serveurs initiale CONFIG2 doit comprendre une pluralité de nœuds matérialisant la composante « multi-sites », un nœud central orchestrant les données véhiculées par la pluralité de nœuds, et modéliser les communications entre les différents nœuds sur lesquels s'appuie l'application logicielle. La configuration de serveurs initiale peut toutefois comprendre un nombre N2 de serveurs réduit par rapport au nombre de sites sur lesquels on envisage de déployer réellement l'application en vue de limiter notamment le coût, la complexité et le temps des tests à réaliser. De façon similaire, si lors de la mise en production de l'application logicielle on envisage une fonctionnalité de type pare-feu, cette fonctionnalité doit être reflétée au niveau de la configuration de serveurs initiale. Le type de machines utilisées (ex. mono ou multiprocesseurs, capacités maximales des machines, etc.) peut également être une contrainte imposée par l'environnement de production et qui doit être reflétée dans la configuration initiale.
Ces différentes contraintes imposées par l'environnement de production sont matérialisées conformément à l'invention par un modèle numérique MOD, qui s'appuie ici sur le formalisme des files d'attentes ou des réseaux de files d'attente. Différents exemples de modèles numériques sont illustrés ultérieurement. Le module 3 sélectionne alors la configuration initiale CONFIG2 en utilisant ce modèle numérique MOD et en tenant compte d'une part, des résultats des tests unitaires réalisés sur la configuration de référence CONFIG1 (et notamment des temps d'exécution moyens obtenus pour chaque serveur de la configuration de référence pour chaque type de requête considéré (i.e. pour chaque service), et de la charge maximale théorique) qui servent de référence pour dimensionner les ressources de la configuration initiale CONFIG2, et d'autre part, de la charge cible targ fixée pour l'application logicielle APP (c'est-à-dire de la volumétrie imposée à l'application logicielle APP).
La configuration initiale CONFIG2 sélectionnée par le module 3 est donc un échantillon réduit de la configuration de serveurs sur laquelle est destinée à être mise en production l'application logicielle APP. Cette configuration initiale CONFIG2 est utilisée conformément à l'invention comme point de départ par le module 4 du système de détermination 1 pour le dimensionnement des ressources nécessaires à l'exécution de l'application logicielle APP en environnement de production.
Plus précisément, le module 4 est configuré pour procéder à un ajustement des ressources de la configuration initiale CONFIG2 en fonction de résultats de tests de tenue en charge réalisés à l'aide de l'outil de test ENV2 en vue de déterminer une configuration de serveurs « cible » CONFIG_TARG pour déployer l'application logicielle APP dans un environnement de production. Ces tests permettent d'évaluer la capacité de traitements (ex. taux d'utilisation des CPU ou de la mémoire, temps de réponse, etc.) des serveurs de la configuration CONFIG2 sur laquelle est déployée l'application logicielle APP, pour différentes valeurs de débit de requêtes (i.e. différentes charges de l'application logicielle) avec des flux de requêtes utilisateurs simulés représentatifs d'une utilisation réelle de l'application.
A cet effet, l'outil de test ENV2 tient compte des instances de déploiement de l'application logicielle APP sur les serveurs de la configuration CONFIG2, de même que de la topologie reliant les instances, du périmètre de l'application logicielle APP par rapport à son environnement (i.e. applications ou produits logiciels tiers, terminaux, etc.), des protocoles de communication mis en œuvre, etc. Il tient compte également des caractéristiques logicielles et matérielles de la configuration CONFIG2, et notamment du paramétrage des machines physiques et des machines (serveurs) virtuelles, des espaces de stockage, des aspects réseaux, et du paramétrage des produits intermédiaires (ou « middleware » en anglais) comme les serveurs d'application, les bases de données, les bus et les protocoles de communication, etc.
La figure 2 illustre schématiquement un exemple d'un tel environnement de test ENV2ex élaboré pour tester une application logicielle déployée sur une configuration de serveurs comprenant un serveur de présentation 6, un serveur d'application 7 et un serveur de données 8. Une instance de l'application logicielle est installée sur le serveur d'application 7.
Dans l'exemple illustré à la figure 2, des requêtes HTTP (HyperText Transfer Protocol) sont envoyées par un dispositif d'injection de charge 9 à l'application logicielle APP pour traitement. Les serveurs 6, 7 et 8 sont reliés à une zone de stockage 10, via le protocole NFS (Network File System). L'application logicielle APP interagit avec des dispositifs tiers, tels que par exemple un serveur d'une zone d'échange mutualisée 11 et un serveur rebond 13, et différents systèmes externes 12 et 14 modélisés à l'aide de simulateurs partenaires. De manière générale, pour réaliser des tests en tenue de charge de l'application logicielle APP, l'outil de test ENV2 comprend notamment :
— des modules ou dispositifs d'injection de charge, aptes à générer et à fournir à l'application logicielle APP différents niveaux de charge générés par des utilisateurs virtuels (chaque niveau de charge correspondant à un nombre d'utilisateurs virtuels différents), et à mesurer des temps de réponse moyens ou médians aux requêtes émises par ces utilisateurs virtuels. Ces modules d'injection de charge sont ici des modules CLIF s'appuyant sur un modèle de composante fractale et décrits notamment dans le document de B. Dillenseger intitulé « CLIF, a framework based on Fractal for flexible, distributed load testing », Annales des Télécommunications, vol. 64, n°l-2, février 2009 ; et
— des sondes permettant d'observer différentes métriques de consommation de ressources (CPU, mémoire, réseaux, etc.) par l'application logicielle sur les serveurs de la configuration testée.
L'outil de test ENV2 est configuré pour injecter, via ses modules d'injection de charge, de façon automatique, sur une durée fixe et selon une politique d'injection prédéterminée décrite plus en détail ultérieurement, différents niveaux de charge (i.e. différents nombres de requêtes par unité de temps croissants) à la configuration de serveurs testée et supportant l'application logicielle APP. L'outil de test ENV2 est programmé à cet effet pour observer, après injection de chaque niveau de charge, le comportement de la configuration de serveurs testée, et décider en fonction de ce comportement du prochain niveau de charge à injecter. Le processus est réitéré jusqu'à l'atteinte d'un critère prédéterminé.
L'homme du métier est invité à se référer au document de N. Salmi et al. intitulé « Model-based performance anticipation in multi-tiers autonomie Systems : methodology and experiments », International Journal on Advances in Networks and Services, vol 3 no 3 & 4, 2010 (http://www.iariajournals.org/networks_and_services/tocv3n34.html), section III, pour plus de détails sur l'automatisation du processus d'injection de charge mis en œuvre par l'outil de test ENV2.
Il convient toutefois de noter qu'à l'instar du mode de fonctionnement décrit dans le document de N. Salmi et al., l'outil de test ENV2 utilise, conformément à l'invention, des scénarios d'injection de charge s'appuyant sur des profils de requêtes utilisateurs représentatifs de l'utilisation réelle ou tout du moins attendue de l'application logicielle APP en environnement de production (ou s'en approchant le plus possible). De tels profils peuvent être obtenus par exemple du développeur et/ou de l'administrateur de l'application logicielle APP. Ils comprennent notamment des informations relatives à la fréquence d'arrivée des requêtes, et plus particulièrement :
— à la répartition des différents types de requêtes (i.e. proportion de chaque type de requêtes) ;
— aux débits moyens d'arrivée des différents types de requêtes associés aux services offerts par l'application logicielle APP ; et — aux distributions des durées (temps) d'inter-arrivées entre ces requêtes (ex. distributions déterministes ou de type rafales telles que par exemple une distribution aléatoire ou exponentielle).
Des informations relatives aux débits minimum et maximum peuvent également être contenues dans ces profils.
Ainsi, les requêtes injectées par l'outil de test ENV2 ne sont plus systématiquement espacées de façon déterministe (ex. périodique) ou successives comme pour les tests unitaires réalisés par l'outil de test ENVI, mais des « grumeaux » de requêtes peuvent se produire et entraîner des concurrences d'accès à des ressources partagées, ce qui peut provoquer un effondrement momentané de l'application logicielle APP (i.e. l'application logicielle est saturée et ne répond plus). En particulier, si un goulot d'étranglement se forme sur un serveur (correspondant à un débit crête de requêtes très supérieur au débit moyen) et persiste, le risque d'écroulement de l'application logicielle peut devenir non négligeable et le temps de réponse de celle-ci se dégrader rapidement. Les comportements observés en termes de temps de réponse et de consommation de ressources de l'application logicielle à l'aide de cet outil de test ENV2 peuvent donc être très différents de ceux que l'on peut observer lors des tests unitaires réalisés à l'aide de l'outil de test ENVI.
On note que l'application logicielle APP peut connaître des variations d'utilisation reproductibles sur une fenêtre temporelle, communément appelée « cycle d'activité ». Dans ce cas, une connaissance détaillée des informations de débits et de distributions des temps d'inter-arrivées des requêtes sur différentes périodes de temps identifiées sur le cycle d'activité pour chaque service offert par l'application logicielle peut être envisagée. Le découpage en périodes de temps est réalisé préférentiellement de sorte à garantir que sur une période de temps donnée, le débit moyen des requêtes soit représentatif des valeurs réelles de débits observées. Ce découpage est alors pris en compte au niveau de l'outil de tests ENV2.
A titre d'exemple, les figures 3A et 3B illustrent, pour deux services distincts d'une application logicielle, la répartition des nombres d'arrivées de requêtes sur un cycle d'activité de 24h.
Sur la figure 3A, on peut distinguer 2 à 5 périodes de temps sur lesquelles les débits moyens sont assez représentatifs par rapport aux valeurs réelles de débits observées (et très différents du débit moyen global sur le cycle d'activité de 24h). Par exemple un découpage en deux périodes de temps peut consister en une première période de OOh à 8h environ et une seconde période de 8h à OOh.
Sur la figure 3B, un découpage en 4 périodes de temps peut être envisagé comme consistant en une première période entre Oh et 5h30, une deuxième période entre 5h30 et lOh, une troisième période entre lOh et 12h30 et une quatrième période entre 12h30 et 24h.
Les sondes de l'outil de test ENV2 sont configurées pour récolter diverses métriques, et notamment ici : — le temps de réponse de bout en bout des requêtes utilisateur en fonction de débits d'arrivée moyens et de la distribution des inter-arrivées de requêtes utilisateur de l'application logicielle APP ; et
— pour chaque serveur de la configuration CONFIG2, le taux d'utilisation du ou des processeurs de ce serveur, ou le temps d'exécution de la requête par le serveur.
En variante, d'autres métriques peuvent être récoltées dans cet environnement de test et notamment pour chaque serveur, la distribution du nombre de connecteurs réseau utilisés, la distribution du volume de RAM utilisé, le taux d'occupation de RAM et/ou de pool de « threads » d'entrée/sortie de chaque serveur, etc.
Comme mentionné précédemment, le module 4 du système de détermination 1 est configuré pour procéder à un ajustement des ressources et des paramètres des serveurs de la configuration initiale CONFIG2 en fonction de résultats de tests de tenue en charge réalisés à l'aide de l'outil de test ENV2. Cet ajustement qui est réalisé en s'appuyant ici sur plusieurs tests de tenue en charge judicieusement paramétrés en termes de charge injectée pour limiter la complexité d'implémentation de ces tests, permet au module 4 de déterminer une configuration de serveurs « cible » (configuration CONFIG_TARG) pour le déploiement de l'application logicielle APP dans un environnement de production qui vérifie le temps de réponse maximal TRmax fixé pour l'application logicielle et supporte la charge cible targ.
Dans le mode de réalisation décrit ici, l'environnement de test ENV2 permet également de réaliser des tests d'endurance ou de disponibilité sur la configuration de serveurs CONFIG_TARG après sa détermination par le module 4. Ces tests sont destinés à valider le dimensionnement et le paramétrage des ressources réalisés à partir des tests unitaires et des tests de tenue en charge, ces derniers étant supposés correspondre à un déploiement réel mais à échelle réduite. Il s'agit, grâce aux tests d'endurance, de tester l'application logicielle et la configuration de serveurs cible CONFIG_TARG sur une durée suffisamment longue (typiquement plusieurs jours) afin de prendre en compte des événements rares ou dont la probabilité d'apparition est faible.
Les scénarios de tests considérés pour ces tests d'endurance consistent à répartir les requêtes utilisateur suivant les différents types de services invoqués, et à émettre ces requêtes selon une certaine charge estimée à partir des tests de tenue en charge pour la configuration cible CONFIG_TARG et selon des distributions d'inter-arrivées des requêtes prédéfinies : déterministe, aléatoire, en rafales, etc. Les métriques récoltées à l'issue de ces tests sont similaires à celles récoltées à l'issue des tests en tenue de charge (temps de réponse de bout en bout de l'application, taux d'utilisation de ressources (CPU, RAM, pool de threads, etc.) de chaque serveur, etc.).
Dans le mode de réalisation décrit ici, les outils de test ENVI et ENV2 et les modules 2 à 4 du système de détermination 1 sont des modules logiciels définis à l'aide d'instructions de programmes d'ordinateur stockés en mémoire d'une ou de plusieurs machines physiques. Chacune de ces machines a ici l'architecture matérielle d'un ordinateur et comprend notamment un processeur, une mémoire morte, une mémoire vive, une mémoire non volatile et un module de communication avec notamment d'autres machines ou ordinateurs. La mémoire morte de chaque machine constitue un support d'enregistrement conforme à l'invention, lisible par le processeur de la machine et sur lequel est enregistré un programme d'ordinateur conforme à l'invention comportant des instructions pour l'exécution d'une ou de plusieurs étapes du procédé de dimensionnement selon l'invention.
Nous allons maintenant décrire, en référence à la figure 4, les principales étapes d'un procédé de détermination selon l'invention, tel qu'il est mis en œuvre dans un mode particulier de réalisation par le système de détermination 1 illustré à la figure 1.
On suppose en préliminaire de la mise en œuvre de ce procédé qu'un certain nombre d'informations relatives à l'application logicielle APP et à son déploiement dans un environnement de production sont fournies au système de détermination 1, par exemple par l'administrateur ou le développeur de l'application logicielle. Ces informations sont stockées par exemple dans une mémoire non volatile du système de détermination 1.
Ainsi, notamment, est fourni au système de détermination 1 l'accord de niveau de service (SLA) défini pour l'application logicielle APP. Comme mentionné précédemment, ce SLA définit les exigences en termes de qualité des services utilisateurs UC1,...,UCN offerts par l'application logicielle APP, et en particulier, en termes de volumétrie (ex. charge cible targ), de disponibilité et de temps de réponse maximal TRmax attendu de bout en bout. On suppose ici que les services UC1,...,UCN sont des services considérés comme représentatifs en matière de consommation de ressources, c'est-à-dire dont la consommation de ressources pour la fourniture de ces services par l'application logicielle APP est considérée comme significative par l'administrateur ou développeur de l'application logicielle. Les services UC1,..,UCN dépendent bien entendu de l'application logicielle considérée.
Le système de détermination 1 dispose également comme mentionné précédemment, des profils des requêtes utilisateurs représentatifs de l'utilisation réelle ou tout du moins attendue de l'application logicielle APP en environnement de production (ou s'en approchant le plus possible). Via ces profils, le système de détermination 1 connaît pour chacun des services UC1,...,UCN, un pourcentage (i.e. proportion) de requêtes utilisateurs invoquant ce service parmi les requêtes adressées à l'application logicielle APP. On note p_i, le pourcentage des requêtes utilisateurs destinées à l'application logicielle APP et associées au service UCi avec∑!liP_i = l.
Ces requêtes utilisateurs peuvent être de nature (type) différente selon le service qu'elles invoquent. Elles déclenchent des séquences d'exécution de l'application logicielle et entraînent des consommations de ressources logicielles et matérielles. En associant chaque requête à un service, l'invention permet d'établir un modèle de consommation de ressources de l'application logicielle en tenant compte des exigences utilisateur pour chacun de ces services. A titre illustratif, on peut avoir par exemple les types de requêtes suivants :
— pour le service UC1 : commandes/souscriptions ;
— pour le service UC2 : résiliations ;
— pour le service UC3 : consultations passant en commandes ;
— pour le service UC4 : traitements différés dans la nuit ;
— etc.
Si on désigne par λ le débit moyen des requêtes associées aux services principaux de l'application logicielle, le système de détermination 1 déduit de la connaissance de λ et de la répartition des requêtes par service, le débit moyen λί des requêtes associées au service UCi, i= 1, N, en utilisant la relation :
λί = p_i x λ
Les informations sur la répartition des requêtes sur les N services UC1,...,UCN, et sur les débits moyens λ; sont données par les profils des requêtes utilisateurs de l'application logicielle APP stockés au niveau du système de détermination 1.
Chaque profil de requêtes associé à un service comprend également, comme évoqué précédemment, une information représentative de la distribution des temps d'inter-arrivées des requêtes invoquant ce service. Une telle information précise notamment si les temps d'inter- arrivées des requêtes pour un service donné suivent une distribution déterministe ou au contraire de type rafales, telle que par exemple une distribution aléatoire ou exponentielle, en spécifiant les paramètres d'une telle distribution pour qu'elle corresponde au délai moyen associé au service considéré (ex. durée « on » pendant laquelle l'application reçoit des requêtes et durée « off », etc.). Ces profils de requêtes sont utilisés dans les scénarios de test implémentés par les outils de tests ENVI et ENV2.
Le système de détermination 1 dispose également d'informations sur les contraintes de déploiement imposées lors de la mise en production de l'application logicielle APP. Ces contraintes comprennent notamment le type d'architecture de déploiement envisagée (présentée par exemple sous forme d'un graphe de nœuds associés aux unités de déploiement de l'application APP). Elles peuvent porter également sur des caractéristiques des serveurs (ex. types de machines envisagées), par exemple sur la capacité et la possibilité d'extension de CPU ou de RAM d'un serveur, sur l'utilisation de serveurs mono ou multiprocesseurs ou encore d'un cluster de serveurs, sur le type de configuration des unités de déploiements de l'application APP, etc. Ces informations peuvent être notamment fournies dans l'accord SLA.
D'autres contraintes et/ou informations peuvent être fournies au système de détermination 1 comme par exemple des contraintes en matière de placement des serveurs, etc. Toutefois par souci de simplification ici, nous ne considérerons pas de telles contraintes additionnelles. Conformément à l'invention, le système de détermination 1 permet de dimensionner les ressources nécessaires à l'exécution de l'application logicielle APP sur une configuration de serveurs, en vue de son déploiement dans un environnement réel d'exécution, la configuration de serveurs dûment dimensionnée étant apte à vérifier le temps de réponse global maximal TRmax et à supporter la charge cible targ.
A cet effet, le système de détermination 1 s'appuie sur des tests unitaires réalisés sur une configuration de serveurs « minimale » de référence (à savoir la configuration CONFIG1) pour obtenir une estimation de la consommation de ressources de l'application logicielle APP. Cette consommation de ressources est caractérisée ici :
— d'une part, par les temps d'exécution moyens d'une requête de l'application logicielle sur chacun des serveurs 511, ... ,51N1 de la configuration CONFIG1 sur lesquels sont déployées les unités de déploiement de l'application logicielle APP. Ces temps d'exécution moyens sont désignés dans la suite de la description par £(5lj), j = 1, ... , N1 ; et
— d'autre part, par la charge maximale maxl pouvant être supportée par l'application logicielle APP1 dans la configuration de serveurs CONFIG1 (autrement dit le débit maximum de l'application logicielle APP dans la configuration de serveurs CONFIG1).
Le choix de la configuration CONFIG1 a déjà été détaillé précédemment. Le système de détermination 1 dispose donc, en préalable de l'exécution des tests unitaires, d'une description de la configuration de serveurs CONFIG1 et des caractéristiques des serveurs impliqués dans cette configuration (étape E10). Comme mentionné précédemment, à titre illustratif, on choisit ici une configuration CONFIG1 minimale constituée d'un unique serveur mono-processeur désigné par SU (Nl=l). Toutefois cette hypothèse n'est en aucun cas limitative, la configuration de référence CONFIG1 pouvant comprendre plusieurs serveurs reliés entre eux.
Conformément à l'invention, le système de détermination 1 via son outil de test ENVI réalise des tests unitaires sur la configuration de serveurs CONFIG1 à partir de scénarios définis pour chaque type de requête identifié comme pertinent pour les services UC1,...,UCN offerts par l'application logicielle APP (étape E20). Comme mentionné précédemment, à l'issue de ces tests unitaires, le module 2 du système de détermination 1 récolte des métriques quantifiant la consommation de ressources par l'application logicielle sur le serveur SU lors du traitement des requêtes de l'App. Dans les scénarios de test mis en œuvre, les requêtes sont envoyées à l'application logicielle de façon déterministe de sorte à ne pas avoir d'accès concurrents aux ressources (ex. CPU ici) dont on cherche à évaluer la consommation à l'aide des métriques récoltées.
Dans l'exemple envisagé ici, les métriques obtenues par le module 2 durant les tests unitaires correspondent pour chaque type de requête associé à un service UCi offert par l'application logicielle, à la consommation de CPU notée E(UCi,Sll) par l'application logicielle sur le serveur SU pour exécuter une requête de ce type. Chaque métrique E(UCi,Sll) est plus précisément ici une mesure du temps d'exécution moyen d'une requête associée au service UCi sur le serveur SU (ou de façon équivalente, une mesure du taux d'utilisation moyen du CPU du serveur SU pour traiter cette requête).
Le module 2 évalue ensuite (étape E30), à partir des métriques E(UCi,Sll), i= l,...,N, récoltées pour chaque type de requête (autrement dit pour chaque service), un temps d'exécution moyen E(S11) d'une requête par l'application logicielle APP sur le serveur SU (i.e. tous services confondus) suivant la relation :
E(S11) = ^ p_i x E(UCi, SU)
Puis le module 2 évalue à partir du temps d'exécution moyen E(S11), le taux d'utilisation μ(511) du serveur SU. Pour un serveur SU monoprocesseur exécutant une unique instance de l'application APP, le module 2 utilise à cet effet la relation suivante :
1
μ(511)
£■(511)
On note que lorsque la configuration CONFIGl comprend plusieurs serveurs distincts
Slj, j=l,...,Nl avec N1>1 (autrement dit, l'application logicielle APP est composée de plusieurs unités de déploiement distribuées sur différents serveurs), un temps d'exécution moyen E(Slj) d'une requête par l'application logicielle APP est évalué par le module 2 pour chaque serveur Slj, j= l,...,Nl de la configuration CONFIGl à partir des métriques récoltées lors des tests unitaires menés dans l'environnement de test ENVI. De même, un taux d'utilisation (ou taux de service) moyen μ(5ΐ;) est dérivé pour chaque serveur Slj, j= l,...,Nl à partir de ce temps d'exécution moyen de façon similaire à celle décrite précédemment.
A partir de ces taux d'utilisation du (ou des serveurs) de la configuration CONFIGl, le module 2 estime ici la charge maximale théorique Xmaxl pour la configuration de référence CONFIGl (étape E40). A cet effet, l'invention s'appuie sur une condition dite de stabilité de l'application logicielle selon laquelle pour que l'application logicielle APP soit stable, il faut que le taux d'arrivée λ des requêtes sur un serveur (qui définit ici la charge de l'application logicielle) soit strictement inférieur au taux d'utilisation de ce serveur. Autrement dit dans l'exemple du serveur unique SU de la configuration CONFIGl :
- μΑ(5Ί1) < 1 ° λ <— E(S—11) (1) J
Cette hypothèse de stabilité de l'application logicielle APP et la relation (1) qui en découle permettent d'estimer une borne supérieure Xmaxl de la charge théorique maximale de l'application logicielle dans la configuration de référence CONFIGl à partir des taux d'utilisation des serveurs de la configuration CONFIGl.
Dans le mode de réalisation décrit ici, par souci de simplification, le module 2 utilise comme borne supérieure Xmaxl de la charge théorique maximale :
Xmaxl =— -— (2) Toutefois, cette hypothèse n'est pas limitative et dans un autre mode de réalisation, le module 2 peut prendre comme borne supérieure maxl de la charge théorique maximale une valeur— - e avec e nombre réel strictement positif.
De manière générale, si la configuration CONFIGl comprend NI serveurs SU, SN1, en appliquant l'hypothèse de stabilité de l'application logicielle APP, on obtient : g¾ < l, pour tout j =1, ... , N1 (3) où À(Slj) représente le taux d'arrivée (charge) de requêtes de l'application logicielle APP sur le serveur Slj , et μ(5ΐ;) représente le taux d'utilisation du serveur Slj, j= 1, NI. Ces taux (Slj) et μ(5ΐ;) peuvent être obtenus par le module 2 en utilisant les équations suivantes :
Figure imgf000028_0001
avec Pij = 1 si une requête du service UCi entraîne l'exécution d'un programme sur le serveur Slj, sinon = 0, et E- Slj) désigne le temps d'exécution moyen d'une requête du service UCi sur le serveur Slj.
L'inégalité (3) et les relations (4) permettent alors au module 2 d'estimer la borne supérieure Xmaxl de la charge maximale théorique à partir de l'inégalité suivante : λ≤ " m~ (5)
max {(∑?=1/¾ x p_i) x E(Sl;)} .=i
Comme mentionné précédemment pour la configuration comprenant un unique serveur, par souci de simplification, le module 2 utilise ici comme borne supérieure :
Xmaxl = jv5~ (6)
max {(∑il1 ^yxp-i)xE(Sl )}J.=1
ou en variante :
1
Xmaxl = e
max {(∑?=1/¾ x pj) x E(Sl;)} .=i
avec e nombre réel strictement positif.
La borne supérieure Xmaxl ainsi déterminée à l'aide de l'égalité (2) ou (6) est utilisée par la suite par le module 2, et plus généralement par le système de détermination 1, comme estimation de la charge théorique maximale de l'application logicielle dans la configuration de référence CONFIGl.
On note que l'inégalité (5) ci-dessus met en évidence l'influence de la puissance et du nombre de serveurs dans la configuration de serveurs CONFIGl sur la charge maximale admissible par l'application logicielle. Ainsi, au regard de cette inégalité, il convient, pour utiliser les serveurs Slj, j=l,...,Nl de la configuration CONFIGl le plus équitablement possible, de s'assurer que les charges de ces serveurs Slj qui sont égales à (Σϋι β^ x pj) x E(5l;'), j=l,...,Nl soient les plus proches possibles les unes des autres. De cette sorte, on peut optimiser le coût des serveurs dans le déploiement de l'application logicielle APP y compris sur la configuration de serveurs de référence CONFIG1.
La charge maximale théorique maxl estimée par le module 2 donne une borne supérieure pour les valeurs de débits de requêtes pouvant être supportées par l'application logicielle APP dans la configuration de serveurs de référence CONFIG1. Dans le mode de réalisation décrit ici, le module 2 détermine alors, à partir de cette borne supérieure, une valeur de débit (i.e. une charge) λ dite admissible pour la configuration CONFIG1 (étape E50) selon :
=ax maxl (6)
avec a nombre réel tel que 0<a<l.
Les figures 5A à 5D illustrent l'impact du choix du paramètre a sur les performances de l'application logicielle APP.
La figure 5A représente schématiquement l'allure générale du temps de réponse moyen (exprimé en millisecondes) d'une application logicielle APP déployée sur un nombre NS de serveurs, NS> 1, en fonction du débit moyen de requêtes injectées (exprimé en nombre de requêtes par seconde). Une telle figure peut être obtenue en réalisant des tests de tenue en charge par exemple à l'aide de l'environnement de test ENV2.
Sur cette figure, on peut identifier trois zones principales, notées respectivement ZI, ZOpt et Z2, et telles que :
— lorsque les valeurs de charge se situent dans la zone ZI, les temps de réponse moyens de l'application logicielle APP suivent un premier régime linéaire dans lequel tous les serveurs de la configuration considérée se comportent normalement et ont la possibilité de traiter davantage de requêtes. Autrement dit, la zone ZI matérialise une zone où les serveurs de la configuration considérée sont sous-utilisés (zone de sous-utilisation des ressources) ;
— lorsque les valeurs de charge se situent dans la zone Z2, les temps de réponse moyens de l'application logicielle APP suivent un second régime linéaire dans lequel ils se dégradent plus rapidement que l'accroissement de la charge correspondant. Dans cette zone dite de congestion, une saturation des serveurs et de l'application logicielle peut se produire, autrement dit, certains au moins des serveurs de la configuration testée sont surchargés ; — lorsque les valeurs de charge se situent dans la zone ZOpt, les temps de réponse moyens de l'application logicielle APP se trouvent au voisinage du changement de régimes. Ils doivent bien entendu restés bornés par la valeur TRmax du temps de réponse maximal jugé acceptable pour l'application logicielle. Dans cette zone, la capacité maximum de certains serveurs de la configuration de serveurs peut être atteinte.
II convient de noter que la fin du premier régime linéaire (et donc la zone ZI) est beaucoup plus facile à caractériser que la valeur de charge marquant le début de la surcharge des serveurs de l'application logicielle (début de la zone Z2) car cette valeur est particulièrement instable. Les inventeurs ont constaté par expérience que la charge « limite » matérialisant la fin de la zone optimale ZOpt peut être considérée comme matérialisant également le début de la zone Z2, du fait qu'au-delà de cette charge limite, la saturation des serveurs et de l'application logicielle devient imminente. Cette charge limite peut être considérée comme la valeur de charge correspondant au temps de réponse maximal TRmax jugé acceptable pour l'application logicielle APP. On peut par ailleurs considérer que la fin de la zone Z2 correspond à la charge théorique maximale maxl donnée par les bornes supérieures des inégalités (2) et (5).
On suppose ici que le paramètre a est choisi pour que la charge λ se trouve dans la zone ZOpt. Ceci permet d'optimiser l'utilisation des serveurs sur lesquelles est déployée l'application logicielle tout en respectant le temps de réponse maximal exigé.
Comme l'illustrent les figures 5B à 5D, on note que la distribution des temps d'inter- arrivées des requêtes a une influence sur la position du point d'intersection des régimes linéaires des zones ZI et Z2. Les figures 5B à 5D représentent respectivement des résultats de trois séries de tests de tenue en charge réalisés sur une application logicielle déployée sur une configuration de serveurs, ces résultats illustrant les temps de réponse moyens obtenus en fonction des débits de requêtes moyens envoyés à l'application logicielle et en faisant varier les inter-arrivées des requêtes suivant une distribution déterministe (cf. figure 5B), une distribution exponentielle (figure 5C) ou une distribution en rafale (figure 5D). On peut constater sur ces figures que moins le trafic de requêtes est régulier (autrement dit, plus il s'éloigne d'une distribution déterministe), plus le changement de régimes apparaît tôt en terme de charge. Sur cet exemple, on observe que, le paramètre a peut être choisi égal à environ 0.95 pour des inter-arrivées déterministes, à 0.80 pour des inter-arrivées exponentielles et à 0.50 ou 0.60 pour des inter-arrivées en rafale.
Au vu de ces constats, on suppose ici que le module 2 sélectionne une valeur du paramètre a comprise entre 0.80 et 0.95. Il obtient ainsi la valeur de charge admissible λ à partir de l'équation (6) (étape E50).
En variante, le module 2 sélectionne une valeur du paramètre a en tenant compte des distributions d'inter-arrivées des requêtes spécifiées dans les profils de requêtes associés aux différents services UC1,...,UCN, par exemple en se basant sur les valeurs précitées (0.95 pour des inter-arrivées déterministes, 0.80 pour des inter-arrivées exponentielles).
Les différents éléments estimés par le module 2 à partir de la configuration de référence CONFIG1 et des tests unitaires (i.e. charge maximale, charge admissible, etc.) servent alors conformément à l'invention de données de référence pour tout dimensionnement de serveurs dans un futur environnement de production de l'application logicielle APP dans lequel des exigences en termes de caractéristiques des serveurs et de volumétrie sont prédéfinies par le SLA. Le dimensionnement des serveurs de cet environnement de production de l'application logicielle APP se fait en deux temps par le système de détermination 1 :
(1) sélection par le module 3 d'une configuration de serveurs initiale (à savoir la configuration CONFIG2) pour le déploiement de l'application logicielle comprenant la détermination du nombre de serveurs de cette configuration et de leurs paramètres en fonction de la volumétrie exigée dans le SLA (i.e. de la charge cible targ) (étape E60), et l'estimation de la charge théorique maximale pour cette configuration CONFIG2 (étape E70) ; et
(2) ajustement par le module 4 du nombre et des paramètres des serveurs de la configuration CONFIG2 pour satisfaire le temps de réponse maximal TRmax de bout en bout exigé dans le SLA (étape E80), et obtention de la configuration de serveurs cible CONFIG_TARG (étape E90).
Nous allons maintenant détailler davantage les étapes E60-E90 mises en œuvre par les modules 3 et 4 conduisant à l'obtention de la configuration de serveurs cible CONFIG_TARG.
Pour sélectionner la configuration initiale CONFIG2 (étape E60), le module 3 tient compte de la charge (volumétrie) cible targ et des caractéristiques des serveurs imposées par les contraintes de déploiement de l'application logicielle APP. Plus précisément, il s'appuie sur la charge maximale maxl et la charge admissible λ évaluées par le module 2 à partir des résultats des tests unitaires conduits sur la configuration de serveurs CONFIG1 et sur des règles de correspondance établies entre les paramètres des serveurs de la configuration CONFIG1 et les paramètres des serveurs de la configuration CONFIG2, pour le choix du nombre et des paramètres des serveurs à considérer dans la configuration CONFIG2. Ces règles de correspondance sont établies ici en s'appuyant sur la théorie des files d'attente (ou des réseaux de files d'attente). Elles permettent au module 3 de déterminer la puissance et le nombre de serveurs ou clusters de serveurs S2j, j=l,...,N2 à considérer dans la configuration initiale CONFIG2 en tenant compte de leurs caractéristiques (monoprocesseur, multiprocesseurs, etc.).
De façon connue, selon la théorie des files d'attente, chaque système de file d'attente est un formalisme composé d'une file d'attente et d'un serveur, et est caractérisé principalement par :
— un processus aléatoire d'arrivées de requêtes, défini par un débit d'arrivée des requêtes et une distribution des temps d'inter-arrivées des requêtes ;
— un processus de service défini par une distribution statistique du temps de service ;
— une politique d'ordonnancement des requêtes du serveur (ex. FIFO (First In First Out), PS, RR, etc.) ;
— un nombre de serveurs ; et
— une capacité (taille) de la file d'attente.
Dans le mode de réalisation décrit ici, on adopte cette modélisation par file d'attente en faisant les hypothèses suivantes pour l'application logicielle APP :
— un processeur (CPU) du serveur est modélisé par un serveur d'une file d'attente ;
— la durée d'exécution d'une requête correspond au temps de service ;
— le stockage/mémoire du serveur est modélisé par la file d'attente ; et
— les arrivées des requêtes sont modélisées par le processus d'arrivées. Ces hypothèses permettent une modélisation simple d'une application logicielle s'exécutant sur un ou plusieurs serveurs monoprocesseur, multi-fils ou multiprocesseurs. Ainsi, à titre illustratif :
— la figure 6A représente une modélisation par un système de file d'attente d'une application logicielle s'exécutant sur un serveur monoprocesseur ;
— la figure 6B représente une modélisation par un système de file d'attente d'une application logicielle s'exécutant sur un serveur multiprocesseur comprenant m processeurs identiques ; et
— la figure 6C représente une modélisation par un système de file d'attente d'une application logicielle s'exécutant sur un cluster de n serveurs multiprocesseur identiques.
D'autres configurations peuvent bien entendu être envisagées. Notamment, les unités de déploiement de l'application logicielle peuvent être distribuées et déployées sur des serveurs ou clusters de serveurs reliés entre eux via un réseau de télécommunications (NW), et être modélisées alors par un réseau de files d'attente dont un exemple est illustré à la figure 6D.
Le module 3 associe donc un modèle de système ou de réseau de files d'attente à la configuration CONFIG2, en fonction des contraintes imposées pour le déploiement. Il convient de noter que cette association peut être réalisée en amont du procédé de détermination selon l'invention, par exemple dès lors que les contraintes de déploiement de l'application logicielle APP sont connues.
Puis, à partir de ce modèle, le module 3 établit une relation (c'est-à-dire une règle de correspondance) entre les temps d'exécution moyens des serveurs ou cluster(s) de serveurs de la configuration CONFIG2 avec ceux du ou des serveurs de la configuration CONFIGl. Pour les exemples de modèles envisagés sur les figures 6A à 6C et pour une configuration de référence CONFIGl comprenant un unique serveur SU, le module 3 établit par exemple les relations suivantes (modèle numérique MOD au sens de l'invention) en tenant compte de la charge cible targ et de la charge admissible λ estimée par le module 2 pour la configuration de référence CONFIGl :
— Pour une application logicielle s'exécutant sur une configuration CONFIG2 constituée d'un unique serveur S21 monoprocesseur (cf. modélisé sur la figure 6A), le serveur S21 doit être choisi tel que (étape E60) :
E(S21) = ^ x £(5ll)
où E(S21) désigne le temps d'exécution moyen d'une requête de l'application logicielle APP sur le serveur S21. Cela signifie par exemple, que si la charge cible targ = 2 x λ, il faut que le serveur S21 de la configuration initiale CONFIG2 soit deux fois plus puissant en termes de CPU que le serveur SU de la configuration de référence CONFIGl. Ainsi, la même requête pourra être exécutée par le serveur S21 en deux fois moins de temps, conduisant à un taux d'utilisation deux fois supérieur en termes de CPU. A partir de cette relation et en faisant une hypothèse de stabilité de l'application logicielle APP telle qu'évoquée précédemment, le module 3 estime une charge maximale théorique maxl pour la configuration CONFIG2 qui est telle que (étape E70) :
Àtarg < max2
avec
1
max2 =
£■(521)
Pour une application logicielle s'exécutant sur une configuration CONFIG2 constituée d'un serveur S21 multiprocesseur ayant m processeurs identiques (cf. modélisé sur la figure 6B), le serveur S21 doit être choisi tel que (étape E60) :
E(S21) ' = £ÎW m ≤—targ x £(511) J
où E(S21) désigne le temps d'exécution moyen d'une requête de l'application logicielle APP sur le serveur S21 et E(Spmc) désigne le temps d'exécution de la requête par un processeur.
Comme dans l'exemple ci-dessus, le module 3 estime alors une charge maximale théorique max2 pour la configuration CONFIG2 qui est dans ce cas telle que (étape E70) :
Àtarg < max2
avec
Xmax2 =— -— = 7-—
E S21) E(Sproc)
Pour une application logicielle s'exécutant sur une configuration CONFIG2 constituée d'un cluster de n serveurs S21 multiprocesseur identiques ayant m processeurs identiques (cf. modélisé sur la figure 6C), le cluster de serveurs S21 doit être choisi tel que (étape E60) :
E(cluster)= ? ™ù.≤ — x £(511)
nm targ
où E(cluster) désigne le temps d'exécution moyen d'une requête de l'application logicielle APP sur le cluster de serveurs S21 et E SprocJ désigne le temps d'exécution de la requête par un processeur d'un serveur S21, soit :
Figure imgf000033_0001
Comme dans les deux exemples ci-dessus, le module 3 estime alors une charge maximale théorique maxl pour la configuration CONFIG2 qui est dans ce cas telle que (étape E70) :
Àtarg < max2
avec
„ 1 nm
Amax2 = =
E(cluster ) E(Sproc)
D'autres modèles plus complexes peuvent bien entendu être envisagés pour modéliser la configuration de serveurs CONFIG2 en fonction des contraintes de déploiement imposées, à partir desquels sont dérivées des relations entre la charge cible Àtarg , les temps d'exécution des serveurs de la configuration CONFIG1 et les temps d'exécution des serveurs de la configuration CONFIG2.
Ainsi, par exemple, on considère une application logicielle APP offrant un service unique destinée à s'exécuter sur une configuration CONFIG2 constituée de plusieurs serveurs distribués S21, S22 et d'un cluster de serveurs comprenant n serveurs identiques S23, le serveur S21 étant un serveur multiprocesseur comprenant m processeurs identiques Sproc. Dans ce cas, le module 3 peut déterminer la puissance et le nombre de serveurs et/ou de processeurs de la configuration CONFIG2 à partir de résultats de tests unitaires réalisés sur une configuration de référence CONFIG1 implémentant trois unités de déploiement de l'application logicielle APP sur trois serveurs SU, S12 et S13 et en fonction de de la charge cible Àtarg. Plus précisément, le module 3 choisit dans ce cas la puissance et le nombre de serveurs pour la configuration initiale CONFIG2 tels que (étape E60) :
f £(521) = g( proc = _^-_ x £ ii)
m Àtarg
λ
£■(522) = X £(512)
Àtarg
£(523) λ
E(cluster 523) = — = X £(513)
n Àtarg Les mêmes notations qu'introduites précédemment sont utilisées.
Comme dans les trois exemples ci-dessus, le module 3 estime alors une charge maximale théorique pour la configuration CONFIG2 qui est dans ce cas telle que (étape E70) :
Àtarg < max2
avec
Figure imgf000034_0001
Selon un autre exemple encore, on considère une application logicielle APP offrant une pluralité de services UC1,...,UCN, chaque service correspondant à un pourcentage de requêtes p_i, i=l,...,N, l'application logicielle étant destinée à s'exécuter sur une configuration CONFIG2 comprenant des serveurs ou clusters de serveurs distribués S21, S22 et S23, chacun de ces serveurs comprenant respectivement ml, m2 et m3 processeurs identiques notés Sproc2l, Sproc22 et Sproc23. La configuration CONFIG1 comprend trois serveurs SU, S12 et S13 implémentant trois unités de déploiement de l'application logicielle APP. Le module 3 choisit alors dans ce cas la puissance et le nombre de serveurs pour la configuration initiale CONFIG2 tels que (étape E60) : = E{sproc2l) ≤ yN _ x (511)
£■(522) = E(SProc22^ < V N pJ x x £.(512)
m2 ^—>i=i A,targj m3 i—ii=i Atargj
Les mêmes notations qu'introduites précédemment sont utilisées, les charges admissibles et cibles étant dans cet exemple déterminées par les tests unitaires sur les serveurs pour l'ensemble des services de l'application logicielle APP.
Comme dans les exemples ci-dessus, le module 3 estime alors une charge maximale théorique max2 pour la configuration CONFIG2 qui est dans ce cas telle que (étape E70) :
Àtarg < Àmax2
avec
Àmax2 = min
E(sproc2l) E(sproc22) E(sproc2 Bien entendu, ces modèles ne sont donnés qu'à titre illustratif et ne sont en aucun cas exhaustifs.
La valeur de charge maximale théorique max2 ainsi obtenue à l'étape E70 par le module d'estimation 3 pour la configuration initiale CONFIG2 sélectionnée à l'étape E60, et qui majore en particulier la charge cible targ, est ensuite utilisée par le système de détermination 1, et plus particulièrement par le module 4, pour borner les tests de tenue en charge réalisés sur la configuration de serveurs initiale CONFIG2 à l'aide de l'outil de test ENV2.
Plus précisément, comme mentionné précédemment, le système de détermination 1 réalise ensuite, par l'intermédiaire de son outil de test ENV2 et de son module 4, des tests de tenue en charge sur la configuration de serveurs initiale CONFIG2 (étape E80). Ces tests ont pour objectif d'évaluer la capacité de traitements (ex. taux d'utilisation CPU, temps de réponse, etc.) des serveurs de l'application logicielle APP dans la configuration de serveurs CONFIG2 avec des flux de requêtes utilisateurs simulés représentatifs d'une utilisation réelle de l'application logicielle. Autrement dit, l'environnement de test ENV2 tient compte lors de ces tests non seulement du débit de requêtes demandé (et en particulier de la charge cible Àtarg imposée par l'accord de niveau de service SLA), mais également de la variation des temps qui séparent deux arrivées de requêtes consécutives aussi appelé temps d'inter-arrivées des requêtes.
En effet, la configuration CONFIG2 sélectionnée par le module 3 est construite à partir de modèles numériques de dimensionnement basés uniquement sur le débit moyen des requêtes envoyées à l'application logicielle APP et sur des métriques de tests unitaires pour lesquelles il est accédé aux ressources des serveurs sans concurrence.
Or la variation des temps d'inter-arrivées des requêtes impacte de façon importante le temps de réponse de bout en bout de l'application logicielle comme mentionné précédemment, et peut être source d'engorgement, voire d'arrêt de serveurs de l'application logicielle notamment si des grumeaux de requêtes se forment et persistent dans le temps lors de l'exécution de l'application logicielle.
Conformément à l'invention, la configuration initiale CONFIG2 sert donc avantageusement de point départ pour effectuer des tests de tenue en charge dans l'environnement ENV2 en s'appuyant sur des injections de requêtes proches du comportement des utilisateurs de l'application logicielle APP dans un environnement de production. Ce sont les résultats de ces tests qui permettent au module 4, au cours de l'étape E80, d'ajuster et/ou de réajuster le nombre et/ou les paramètres des serveurs, l'objectif étant d'obtenir une configuration de serveurs cible CONFIG_TARG destinée à la production (étape E90).
Autrement dit, durant ces tests de tenue en charge, contrairement aux tests unitaires précédemment réalisés sur la configuration de serveurs CONFIG1, les temps d'inter-arrivées des requêtes ne sont plus déterministes mais ils sont proches des distributions réellement rencontrées lors de l'utilisation de l'application logicielle dans un environnement réel d'exécution. Ces distributions ont été définies préalablement par l'administrateur de l'application logicielle et sont stockées comme mentionné précédemment en mémoire du système de détermination 1, dans des profils de requêtes utilisateurs définis pour chaque service UC1,...,UCN. Ainsi, en considérant de telles distributions réalistes, des grumeaux de requêtes peuvent se produire et entraîner des accès concurrents à des ressources partagées de la configuration CONFIG2, ce qui peut provoquer un effondrement momentané de l'application logicielle ou dégrader fortement son temps de réponse. Les comportements en termes de consommation de ressources de l'application logicielle APP sur les serveurs de la configuration CONFIG2 peuvent donc être très différents de ceux estimés précédemment par le module 3.
En particulier, la configuration CONFIG2 telle que sélectionnée par le module 3 pour supporter la charge cible Àtarg a été sélectionnée sans tenir compte des variations des temps d'inter-arrivées des requêtes de l'application logicielle APP. Rien ne garantit donc que cette charge cible se trouve en dehors de la zone de congestion Z2 décrite précédemment en référence à la figure 5A. Le module 4 ajuste et/ou réajuste la configuration de serveurs CONFIG2 au fil des tests de tenues en charge, autrement dit dimensionne les ressources de la configuration CONFIG2, de sorte à s'assurer que la charge cible Àtarg se trouve, pour la configuration ajustée, dans la zone Zopt, i.e. en dehors de la zone de congestion Z2. La limite supérieure en termes de charges de cette zone Zopt correspond à la charge conduisant au temps de réponse maximal TRmax fixé par l'accord SLA.
Dans le mode de réalisation décrit ici, pour réaliser ces ajustements au cours de l'étape E80, le module 4 du système de détermination 1 met en œuvre une politique d'injection de charges permettant de minimiser le nombre de tests réalisés dans l'environnement ENV2.
Plus précisément, les tests de tenue en charge sont réalisés en injectant en entrée de l'application logicielle et de la configuration CONFIG2 des charges selon un algorithme détaillé ci- après. Ces charges sont inférieures en tout état de cause à la charge théorique maximale max2 déterminée par le module 3, cette charge max2 étant strictement supérieure à la charge cible Àtarg. Ces injections de charge sont réalisées à l'aide des modules d'injection de charge de l'outil de test ENV2. Les temps d'inter-arrivées de requêtes injectées suivent une distribution proche d'une utilisation réelle de l'application logicielle et telle que spécifiée dans les profils de requêtes utilisateurs. Il convient de noter qu'avantageusement, l'invention ne requiert pas la connaissance des distributions de charge devant être injectées individuellement à chaque serveur de la configuration CONFIG2. L'invention se contente d'une connaissance globale des profils de requêtes pour l'application logicielle de bout en bout.
Pour chaque valeur de charge injectée lors de ces tests de tenue en charge, le module
4 obtient ici les métriques suivantes :
— temps de réponse de bout en bout de l'application logicielle APP ; et
— consommation des ressources (ex. CPU, RAM, pool, etc.) pour chacun des serveurs S2j ,j =
1, ... ,N2 de la configuration de serveurs testée (CONFIG2 ou CONFIG2 ajustée).
La figure 7 illustre plus en détail, sous forme d'ordinogramme, l'algorithme mis en œuvre par le module 4 pour réaliser de manière optimisée au cours de l'étape E80 les tests de tenue en charge et l'ajustement des ressources de la configuration CONFIG2.
Conformément à cet algorithme, le module 4 choisit tout d'abord un débit de requêtes (charge) Xtestl tel que (étape E801) :
max2 \
Xtestl = min (— -— ,K1 x Àtarg )
où Kl désigne une constante réelle prédéterminée inférieure ou égale à 1. Par exemple Kl =0.8.
Puis le module 4 réalise un premier test de tenue en charge sur la configuration initiale CONFIG2 issue de l'étape E60 en injectant via l'environnement de test ENV2 une charge égale à Xtestl (étape E802).
Le module 4 compare alors le temps de réponse TR(Xtestï) de bout en bout de l'application logicielle APP obtenu pour cette charge Xtestl par rapport au temps de réponse maximal attendu TRmax (étape test E803).
Si TR(Xtestï) est supérieur à TRmax (réponse oui à l'étape test E803), alors cela signifie qu'un ou plusieurs serveurs de la configuration CONFIG2 sont sous-dimensionnés et qu'il convient de procéder à un ajustement du nombre de serveurs et/ou de leurs paramètres et/ou ressources (étape E804). Cet ajustement est réalisé par le module 4 en tenant compte des consommations individuelles de chaque serveur de la configuration testée pour renforcer les ressources de ceux qui sont le plus chargés. La valeur du dépassement du temps de réponse TR(Xtestï) par rapport au temps de réponse maximal TRmax définit le ratio de cet ajustement.
A titre d'exemple, la figure 8A illustre un cas de dépassement de 25% du temps de réponse maximal TRmax, i.e.(TR( ltestl)) - TRmax ) /TRmax) = 25%. Dans ce cas, le module 4 applique une augmentation des ressources de la configuration CONFIG2 du même ordre, soit en ajustant le nombre de serveurs de la configuration, soit en ajustant leurs paramètres (ex. puissance des processeurs, nombre de processeurs, etc.).
Lorsque le redimensionnement de la configuration CONFIG2 est terminé, les étapes précédentes sont réitérées sur la configuration ajustée (toujours notée CONFIG2 par souci de simplification), autrement dit, le module 4 reprend l'étape E802 et l'applique à la configuration ajustée.
Si TR(Xtestï) est inférieur ou égal à TRmax (réponse non à l'étape test E803), alors le module 4 sélectionne une nouvelle valeur de charge notée Xtestl telle que Xtestl < Xtestl (étape E805). Par exemple, le module 4 choisit ici une charge Xtestl = Kl x Xtestl avec K2 constante réelle prédéterminée inférieure à 1. K2 est par exemple prise ici égale à 0.25. En variante, le module 4 choisit une charge Xtestl déterminée en fonction de la charge cible Xtarg, par exemple égale à 10% de la charge cible targ.
Puis le module 4 réalise un deuxième test de tenue en charge sur la configuration CONFIG2, via l'environnement de test ENV2, en injectant la charge Xtestl à l'application logicielle APP (étape E806). Il obtient à l'issue de ce test le temps de réponse TR(Xtestl) de bout en bout de l'application logicielle APP.
Le module 4 détermine ensuite, à partir des charges Xtestl et Xtestl et des temps de réponse de l'application logicielle APP TR(Xtestï) et TR(Xtestl) obtenus pour ces charges, une estimation du temps de réponse de l'application logicielle pour la configuration de serveurs testée pour une charge égale à la charge cible Xtarg (étape E807). Cette estimation est notée D( ltarg).
Dans le mode de réalisation décrit ici, cette estimation est obtenue par le module 4 en considérant la droite D passant par les points Al et A2 de coordonnées respectives Al=(Xtestl,TR(Xtestl)) et A2=(Xtest2,TR(Xtest2)), et le point A de la droite D d'abscisse Xtarg. Le module 4 prend comme estimation D( ltarg) l'ordonnée du point A. La figure 8B illustre cette droite sur un exemple ainsi que l'estimation D(Xtarg) obtenue à partir de cette droite.
Il convient de noter que les constantes Kl et K2 sont choisies préférentiellement de sorte à obtenir deux points Al et A2 suffisamment éloignés pour permettre la construction de la droite D. Les valeurs considérées dans l'exemple décrit ici, à savoir Kl=0.8 et K2=0.25 permettent avantageusement d'obtenir un tel tracé, toutefois d'autres valeurs peuvent être envisagées en variante.
Puis le module 4 compare la valeur D( ltarg) au temps de réponse maximal TRmax spécifié dans l'accord SLA (étape test E808).
Si D( ltarg) est supérieur à TRmax (réponse oui à l'étape test E808), alors cela signifie qu'un ou plusieurs serveurs de la configuration CONFIG2 sont sous-dimensionnés et qu'il convient de procéder à un ajustement du nombre de serveurs et/ou de leurs paramètres et/ou ressources (étape E809). Cet ajustement est réalisé par le module 4, comme à l'étape E804, en tenant compte des consommations individuelles de chaque serveur de la configuration testée pour renforcer les ressources de ceux qui sont le plus chargés. La valeur du dépassement du temps de réponse D( ltarg) par rapport au temps de réponse maximal TRmax définit le ratio de cet ajustement.
A titre d'exemple, la figure 8B illustre un cas de dépassement par D( ltarg) du temps de réponse maximal TRmax. Dans ce cas, le module 4 applique une augmentation des ressources de la configuration CONFIG2 du même ordre que (D( ltarg) - TRmax) /TRmax, soit en ajustant le nombre de serveurs de la configuration, soit en ajustant leurs paramètres (ex. puissance des processeurs, nombre de processeurs, etc.).
Lorsque le redimensionnement de la configuration CONFIG2 est terminé, les étapes précédentes sont réitérées sur la configuration ajustée (toujours notée CONFIG2 par souci de simplification), autrement dit, le module 4 reprend l'étape E802 et l'applique à la configuration ajustée.
Si au contraire D( ltarg) est inférieur ou égal à TRmax (réponse non à l'étape test E808), alors le module 4 examine si D( ltarg) est sensiblement inférieur à TRmax (étape test E810). Dans le mode de réalisation décrit ici, par sensiblement inférieur, on entend que D( ltarg) est inférieur à γ = 90% de la valeur de TRmax. Bien entendu, cette valeur γ prise égale à 90% ou de manière équivalente à 0.9 est paramétrable et n'est donné qu'à titre illustratif.
La figure 8C illustre un exemple où D( ltarg) est sensiblement inférieur à TRmax selon le critère précité.
Si un tel cas de figure se présente (réponse oui à l'étape test E810), cela signifie que la configuration CONFIG2 testée (qui correspond à la configuration CONFIG2 éventuellement ajustée et/ou réajustée) est surdimensionnée. Le module 4 procède donc à un (ré)ajustement des ressources de la configuration CONFIG2 en se basant comme à l'étape E809 sur la différence (D( ltarg) - TRmax ) /TRmax (étape E811).
Puis lorsque le redimensionnement de la configuration CONFIG2 est terminé, les étapes précédentes sont réitérées sur la configuration ajustée (toujours notée CONFIG2 par souci de simplification), autrement dit, le module 4 reprend l'étape E802 et l'applique à la configuration ajustée.
Sinon (réponse non à l'étape test E810), le module 4 sélectionne une nouvelle charge Àtest3 égale cette fois-ci à la charge cible Itarg (étape E812) et réalise un nouveau test de tenue en charge sur la configuration CONFIG2 en injectant, via l'environnement de test ENV2, à l'application logicielle APP déployée sur cette configuration la charge Xtest3 (étape E813).
Le module 4 compare ensuite le temps de réponse TR(Àtest3) de bout en bout de l'application logicielle APP obtenu pour cette charge Xtest3 par rapport au temps de réponse maximal attendu TRmax (étape test E814).
Si TR( ltest3) est supérieur à TRmax (réponse oui à l'étape test E814) comme illustré par exemple à la figure 8D, alors cela signifie qu'un ou plusieurs serveurs de la configuration CONFIG2 sont sous-dimensionnés et qu'il convient de procéder à un ajustement du nombre de serveurs et/ou de leurs paramètres et/ou ressources (étape E815). Cet ajustement est réalisé par le module 4 de façon similaire aux étapes E804, E809, E811 en tenant compte des consommations individuelles de chaque serveur de la configuration testée pour renforcer les ressources de ceux qui sont le plus chargés. La valeur du dépassement du temps de réponse TR(Àtest3) par rapport au temps de réponse maximal TRmax définit le ratio de cet ajustement, de façon similaire à ce qui est fait aux étapes d'ajustement E804, E809 et E811.
Puis lorsque le redimensionnement de la configuration CONFIG2 est terminé, les étapes précédentes sont réitérées sur la configuration ajustée (toujours notée CONFIG2 par souci de simplification), autrement dit, le module 4 reprend l'étape E802 et l'applique à la configuration ajustée.
Sinon (réponse non à l'étape test E814), la configuration CONFIG2 est considérée comme correctement dimensionnée pour le déploiement de l'application logicielle APP dans un environnement de production (étape E816). La configuration ainsi ajustée constitue la configuration cible CONFIG_TARG obtenue par le système de détermination 1 et considérée pour la mise en production de l'application logicielle (étape E90).
L'algorithme mis en œuvre par le module 4 au cours de l'étape E80 et représenté à la figure 7 permet de réaliser un compromis entre le nombre de tests de tenue en charge effectués et l'ajustement de la configuration CONFIG2. Cet algorithme permet avantageusement de valider au plus tôt la configuration de serveurs sur laquelle déployer l'application logicielle APP tout en s'abstenant de réaliser un trop grand nombre de tests de tenue en charge du fait d'un incrément de charge entre chaque test trop faible. Cet algorithme converge très rapidement vers une configuration de production grâce aux informations acquises des modules 2 et 3 et en tirant parti des écarts de temps de réponse mesurés par rapport au temps maximal de réponse TRmax pour quantifier chaque ajustement de la configuration de serveurs testée.
Dans le mode de réalisation décrit ici, à la suite du dimensionnement (potentiellement itératif) des serveurs de la configuration CONFIG2 par le module 4 résultant en l'obtention de la configuration de serveurs cible CONFIG_TARG pour la mise en production de l'application logicielle, le système de détermination 1 valide la configuration obtenue en réalisant un test d'endurance sur celle-ci (étape E100). Ces tests d'endurance sont réalisés à l'aide de l'outil de test ENV2 sur une durée d'exécution prédéterminée suffisamment longue (ex. plusieurs jours) afin de prendre en compte des événements rares dont la probabilité d'apparition est faible. Les requêtes utilisateur sont réparties suivant les services UC1,...,UCN et émises avec une certaine charge admissible et des temps d'inter-arrivées suivant des distributions prédéfinies (ex. déterministe, aléatoire, en rafale, etc.).
Les métriques observées durant ce test sont similaires à celles observées durant les tests en tenue de charge (temps de réponse de bout en bout des requêtes utilisateur, temps d'exécution moyen sur chaque serveur ou taux d'utilisation du CPU, etc.), et permettent de valider la configuration CONFIG_TARG et le dimensionnement de ses ressources ou de procéder si besoin à de nouveaux ajustements de façon similaire à ce qui a été fait durant l'étape E80 (étape E110). A l'issue de l'étape E110, le système de dimensionnement 1 offre donc une configuration de serveurs CONFIG_TARG a /yo/7 dimensionnée de sorte à vérifier les contraintes imposées par l'accord SLA, c'est-à-dire dimensionnée pour supporter, dans un environnement réel de production, la charge cible Itarg tout en respectant le temps de réponse maximal TRmax.
II convient de noter que la technique de pré-dimensionnement proposée par l'invention s'appuie sur la prise en compte de profils de requêtes réalistes et proches de l'utilisation réelle de l'application logicielle. Or, il est parfois difficile de disposer d'informations précises sur ces distributions pour des applications logicielles réparties dans des environnements de type cloud. En effet, les délais qui séparent deux arrivées consécutives de requêtes à l'entrée d'un serveur sont perturbés par des délais de réseaux traversés dans le cloud et de traitements d'autres serveurs, et subissent des gigues aléatoires. Des accumulations de requêtes en attente de traitement à l'entrée d'un serveur peuvent se produire et impacter significativement le temps de réponse. Par ailleurs, comme tout système logiciel a une capacité limitée d'un point de vue matériel, un écroulement du système peut se produire lorsque la quantité de traitements dépasse momentanément la capacité du serveur bien que le débit moyen soit respecté.
Par conséquent, dans un tel contexte, la configuration cible obtenue CONFIG_TARG à l'issue de l'étape El 10 est préférentiellement considérée comme une configuration de déploiement initial permettant de satisfaire les exigences spécifiées dans le SLA, dans un procédé de gestion d'élasticité selon l'invention.
La figure 9 représente, sous forme d'ordinogramme, dans un mode particulier de réalisation, les principales étapes d'un procédé de gestion d'élasticité selon l'invention qui utilise comme configuration de déploiement initiale, la configuration cible CONFIG_TARG déterminée par le système de détermination 1 (étape F10).
La configuration cible initiale CONFIG_TARG est ensuite déployée en production et l'application logicielle APP est exécutée sur la configuration cible (étape F20). Cette exécution est accompagnée de mécanismes de surveillance de l'exécution de l'application logicielle à l'aide de métriques de supervision connues en soi (étape F30), et de mécanismes de maintien, ajout ou de retrait de ressources en fonction des métriques de supervision et de règles prédéterminées (étape F40), de sorte à absorber des rafales momentanées durant l'exécution de l'application et garantir des temps de réponse conformes au SLA. Un tel mécanisme est décrit par exemple dans le document de L. Letondeur et al. intitulé « Planification pour la gestion automatique de l'élasticité d'applications dans le cloud », ComPAS'2014, 23-25 avril 2014.
Ce procédé de gestion d'élasticité peut ainsi être aisément mis en œuvre par un système de gestion d'élasticité conforme à l'invention (non représenté sur les figures) comprenant :
— le système 1 de détermination, qui détermine une configuration cible de serveurs pour le déploiement de l'application logicielle via l'exécution du procédé de détermination selon l'invention ; — un module de déclenchement d'une exécution de l'application logicielle sur la configuration cible de serveurs ;
— un module de surveillance d'au moins une métrique de supervision de cette configuration cible lors de l'exécution de l'application logicielle ; et
— un module d'ajustement tel que celui décrit dans le document précidé de L. Letondeur et al. et configuré pour ajuster les ressources allouées à la configuration cible en fonction de ladite au moins une métrique, ce module d'ajustement étant apte à maintenir les ressources allouées ou à ajouter et/ou retirer dynamiquement des ressources à la configuration cible. Dans le mode de réalisation et les exemples décrits précédemment, on a considéré que le débit moyen d'arrivée des requêtes de l'application logicielle APP était représentatif des valeurs de débit réellement rencontrées lors de l'exécution de l'application logicielle. Toutefois, comme déjà évoqué précédemment et illustré aux figures 3A et 3B, il se peut que pour certaines applications logicielles, le débit d'arrivée des requêtes de services varie significativement au cours du temps et ce de façon répétitive, définissant ainsi des cycles d'activités de l'application logicielle. Dans un tel contexte, le débit moyen d'arrivée des requêtes de l'application logicielle sur chaque cycle d'activité est assez peu significatif par rapport aux valeurs de débits réelles sur les différentes périodes composant le cycle d'activité.
Pour gérer une telle situation, dans un mode particulier de réalisation de l'invention, le cycle d'activité de durée T de l'application logicielle APP est préalablement découpé pour chaque service UCi, i= l,...,N en une pluralité Li d'intervalles de temps [Tj]_i, j= l,...,Li tels que les débits moyens correspondants, notés λ(ΙΙΟ, [Tj]_i), soient suffisamment représentatifs des valeurs réelles de débit rencontrées sur les intervalles de temps [Tj]_i (c'est-à-dire typiquement tels que l'écart-type des débits moyens sur chaque intervalle soient faible, par exemple inférieur à un seuil prédéfini). Par ailleurs, les intervalles de temps [Tj]_i, j= l,...,Li sont définis ici pour chaque service i= l,...,N tels que :
T = [Tl]_i U [T2]_i U ... U [TLi]_i
Le nombre d'intervalles Li considéré pour le découpage d'un cycle d'activité peut varier d'un service à l'autre ou être identique pour tout ou partie des services UCi, i= l,...,N considérés.
Pour mieux illustrer le traitement effectué par le système de détermination 1 dans ce mode de réalisation, on considère ci-après, en référence à la figure 10, un exemple simple d'une application logicielle offrant deux services principaux UCl et UC2 définis dans un accord SLA et caractérisés, sur un cycle d'activité de durée T, par le profil de requêtes suivant :
— pour le service UCl : les arrivées des requêtes relatives au service UCl sont réparties sur Ll=3 intervalles de temps [Tl]_l, [T2]_l et [T3]_l tels que T = [Tl]_l u [T2]_l u [T3]_l et avec des débits moyens respectifs sur chacun de ces intervalles notés ii= (UCi, [Tl]_l), λΐ2 = λ(υα, [T2]_l) et λ13=λ(υα, [T3]_l) ; — pour le service UC2 : les arrivées des requêtes relatives au service UC2 sont réparties sur L2=4 intervalles de temps [Tl]_2, [T2]_2, [T3]_2 et [T4]_2 tels que T = [Tl]_2 u [T2]_2 u [T3]_2 u [T4]_2, et avec des débits moyens respectifs sur ces intervalles notés λ21=λ(ΙΙ02, [Tl]_2), λ22 = λ(Ι 2, [T2]_2), λ23=λ(ΙΙ02, [T3]_2) et λ24=λ(1 , [T4]_2).
On considère par ailleurs dans cet exemple Nl=4 serveurs SU, S12, S13 et S14 dans la configuration de référence CONFIGl, les trois serveurs SU, S12, S13 étant impliqués dans l'exécution du service UC1 et les deux serveurs SU et S14 étant impliqués dans l'exécution du service UC2.
Au regard de ces hypothèses, le cycle d'activité de l'application logicielle APP peut être décomposé, selon un nouveau découpage commun aux deux services UC1 et UC2 dérivé du découpage pour chacun des services, en L=6 intervalles de temps [Tl], [T2], [T3], [T4], [T5] et [T6] comme illustré à la figure 10, sur lesquels les débits λ[Τί], i=l,...,6 d'arrivée de requêtes de l'application logicielle APP sont représentatifs et donnés par les relations (7) suivantes :
λ[Τ1]= λ11+λ21
λ[Τ2]= λ11+λ22
λ[Τ3]= λ12+λ22
λ[Τ4]= λ12+λ23
λ[Τ5]= λ13+λ24
λ[Τ6]= λ13+λ24
Pour chaque intervalle de temps [Ti], i=l,...,6, la répartition des requêtes de l'application logicielle entre les deux services peut être déduite comme suit :
Figure imgf000043_0001
P2 ([Tl]) = λ[Γ1]
p2 ([Ti]) = , i = 2 et 3
p, ([Ti]) = — , i = 4 et 5
λ24
2 ([Γ6]) = λ[Τ6]
Ainsi on peut en déduire, pour chaque intervalle de temps [Tl], le taux des arrivées de requêtes de l'App :
λ(1ΐα, [Tl])=Pi([Tl])x λ[ΤΙ ] pour i=l,...,N et 1=1,...,L
Les étapes du procédé de détermination telles que décrites précédemment sont ensuite appliquées par le système de détermination sur chacun des six intervalles [T1],...,[TL], avec L=6. Autrement dit, pour chaque intervalle de temps [Tl], l= l,...,L, le système de détermination 1 effectue les étapes suivantes :
— tests unitaires via l'environnement de test ENVI et détermination par le module 2, pour chaque serveur Slj, j= l...,Nl=4 de la configuration de référence CONFIGl, du débit d'arrivée moyen des requêtes (sij) [TÏ] de l'application logicielle APP et du temps d'exécution moyen d'une requête E(Slj)[Tl] sur le serveur 51; sur l'intervalle de temps [Tl], tous services confondus. Dans l'exemple envisagé ici, on obtient en particulier, à partir des relations (7) indiquées ci- dessus appliquées individuellement pour chaque serveur de la configuration de référence CONFIGl, et en fonction de l'implication de chaque serveur de la configuration de référence dans l'exécution des services UC1 et UC2 :
• pour le serveur SU impliqué dans l'exécution des deux services UC1 et UC2 :
λ(511)[Τ1] = λΐΐ + λ21
λ(511)[Τ2]= λΐΐ + λ22
λ(511)[Τ3]= λ12 + λ22
λ(511)[Τ4]= λ12 + λ23
λ(511)[Τ5]= λ13 + λ23
λ(511)[Τ6]= λ13 + λ24
et
E(S11)[TI]= pl([TI])xE(UCl,Sll)+ p2([TI])xE(UC2,Sll), 1=1,2,3,4,5,6.
• pour les serveurs S12 et S13 impliqués dans l'exécution du service UC1 seulement :
λ(512/513)[Τ1]= λΐ1(512/513)
λ(512/513)[Τ2] = λΐ1(512/513)
λ(512/513)[Τ3] = λΐ2(512/513)
λ(512/513)[Τ4] = λΐ2(512/513)
λ(512/513)[Τ5] = λΐ3(512/513)
λ(512/513)[Τ6] = λΐ3(512/513)
et
E(S12/S13)[TI]= pl([TI])xE(UCl,S12/S13), 1=1,2,3,4,5,6.
la notation Sli/Slj signifiant que les égalités s'appliquent aussi bien au serveur Sli qu'au serveur Slj ; et
• pour le serveur S14 impliqué dans l'exécution du service UC2 seulement :
(S14)[T1]= λ21
λ(514)[Τ2]= λ22 λ(514)[Τ3]= λ22
λ(514)[Τ4]= λ23
λ(514)[Τ5]= λ23
λ(514)[Τ6]= λ24
et
E(S14)[TI]= p2([TI])xE(UC2,S14), 1=1,2,3,4,5,6.
— détermination par le module 2, en appliquant la condition de stabilité de l'application logicielle APP, d'une estimation Àlmax[Tl] de la charge maximale théorique telle que :
1
λΐ max[Tl] = —
max {(∑f=1/¾ x pi([Tl])) x E(S1;)[77]} .=1
Il convient de noter que certaines intervalles peuvent être fusionnés avec leurs intervalles voisins notamment lorsque :
— la durée de l'intervalle [Tl] est inférieure à un seuil, par exemple correspondant au temps de mise en place d'un serveur virtuel ; et/ou
— les débits et les temps d'exécution moyens sur deux intervalles consécutifs ont des valeurs proches.
Suite aux estimations réalisées par le module 2, et à cette phase de révision des intervalles Tl le cas échéant, les étapes E60 à El 10 décrites précédemment sont mises en œuvre par les modules 3 et 4 individuellement pour chacun des intervalles de temps (éventuellement révisés)
On note que l'invention a été décrite dans un contexte de type cloud pour le dimensionnement de machines virtuelles permettant de supporter une application logicielle. Toutefois, l'invention s'applique à d'autres types d'environnement et au dimensionnement de machines matérielles et/ou virtuelles.

Claims

REVENDICATIONS
1. Procédé de détermination d'une configuration de serveurs dite cible pour un déploiement d'une application logicielle (APP) apte à offrir au moins un service, le procédé comprenant :
— une étape d'obtention (E20), pour au moins un service offert par l'application logicielle, au moyen d'au moins un test unitaire réalisé sur une configuration de serveurs dite de référence (CONFIG1) apte à exécuter l'application logicielle (APP), d'un temps d'exécution moyen d'une requête invoquant ce service pour chaque serveur (Slj) de la configuration de référence ; — une étape de sélection (E60) d'une configuration de serveurs dite initiale (CONFIG2) pour le déploiement de l'application logicielle apte à supporter une charge cible ( targ) déterminée pour l'application logicielle, cette étape de sélection tenant compte des temps d'exécution moyens obtenus lors dudit au moins un test unitaire, de la charge cible et d'une charge admissible déterminée (λ) pour la configuration de référence, et utilisant un modèle numérique reflétant au moins une contrainte de déploiement de l'application logicielle imposée à la configuration de serveurs initiale ; et
— une étape de détermination (E90), à partir de la configuration initiale, d'une configuration de serveurs cible (CONFIG_TARG) destinée à être utilisée pour le déploiement de l'application logicielle, ladite étape de détermination comprenant la réalisation (E80) d'une pluralité de tests de tenue en charge paramétrés en fonction d'une charge maximale théorique ( max ) estimée pour la configuration initiale et de la charge cible, et utilisant au moins un profil de requêtes invoquant ledit au moins un service offert par l'application logicielle, ce profil étant représentatif d'une utilisation de l'application logicielle lors de son déploiement, ladite étape de détermination comprenant en outre, en fonction du résultat de chaque test de tenue en charge, un ajustement (E80) d'au moins une ressource de la configuration initiale de sorte que la configuration cible obtenue à l'issue de ladite pluralité de tests de tenue en charge soit apte à vérifier un temps de réponse maximal fixé pour l'application logicielle et à supporter ladite charge cible.
2. Procédé selon la revendication 1 comprenant en outre une étape d'estimation
(E40) d'une charge maximale théorique ( maxl) pour la configuration de référence et dans lequel la charge admissible (λ) déterminée pour la configuration de référence résulte du produit d'un paramètre a compris entre 0 et 1 par la charge maximale théorique estimée pour la configuration de référence.
3. Procédé selon la revendication 2 dans lequel la charge maximale théorique ( maxl) pour la configuration de référence est estimée en appliquant une condition de stabilité de l'application logicielle à au moins un temps d'exécution moyen d'une requête de l'application logicielle dérivé pour ledit au moins un serveur de la configuration de référence à partir des temps d'exécution moyens obtenus pour ce serveur pour les services offerts par l'application logicielle.
4. Procédé selon l'une quelconque des revendications 1 à 3 dans lequel au cours de l'étape de détermination, l'ajustement (E804,E809,E811,E815) d'au moins une ressource de la configuration initiale à l'issue d'un test de tenue en charge est réalisé en fonction d'une différence entre un temps de réponse de l'application logicielle évalué lors du test de tenue en charge et le temps de réponse maximal (TRmax) fixé pour l'application logicielle.
5. Procédé selon l'une quelconque des revendications 1 à 4 dans lequel l'étape de détermination comprend au moins :
— un premier test de tenue en charge (E802) réalisé avec une première charge inférieure à une valeur minimum entre une moitié de la charge maximale théorique estimée pour la configuration initiale et le produit de la charge cible par un nombre réel prédéterminé inférieur ou égal à 1 ;
— un deuxième test de tenue en charge (E806) réalisé avec une deuxième charge inférieure à la première charge ; et
— un troisième test de tenue en charge (E813) réalisé avec une troisième charge égale à la charge cible.
6. Procédé selon la revendication 5 dans lequel l'étape de détermination comprend en outre une estimation (E807) à l'issue du deuxième test, d'un temps de réponse de l'application logicielle avec la charge cible à partir d'un temps de réponse évalué à l'issue du premier test réalisé avec la première charge sur une configuration testée dérivée de la configuration de serveur initiale et d'un temps de réponse de l'application logicielle évalué à l'issue du deuxième test réalisé avec la deuxième charge sur ladite configuration testée, l'ajustement de ressources étant réalisé à l'issue du deuxième test en fonction d'une différence entre le temps de réponse estimé pour la charge cible et le temps de réponse maximal fixé pour l'application logicielle.
7. Procédé selon la revendication 6 dans lequel, à l'issue du deuxième test :
— la configuration de serveurs testée est considérée comme sous-dimensionnée si le temps de réponse estimé pour la charge cible est supérieur au temps de réponse maximal ; et/ou
— la configuration de serveurs testée est considérée comme surdimensionnée si le temps de réponse estimé pour la charge cible est inférieur au produit d'un nombre réel prédéterminé γ compris entre 0 et 1 et du temps de réponse maximal ; et/ou
— la configuration de serveurs testée est considérée comme correctement dimensionnée sinon.
8. Procédé selon la revendication 7 dans lequel γ est pris égal à 0.9.
9. Procédé selon l'une quelconque des revendications 5 à 8 dans lequel la configuration cible correspond à une configuration de serveurs testée pour laquelle à l'issue du troisième test, un temps de réponse de l'application logicielle évalué pour la charge cible sur cette configuration de serveurs testée est inférieur au temps de réponse maximal.
10. Procédé selon l'une quelconque des revendications 1 à 9 comprenant en outre une étape de validation (E100) de la configuration cible au moyen d'un test d'endurance réalisé pendant une durée d'exécution prédéterminée de l'application logicielle.
11. Procédé selon l'une quelconque des revendications 1 à 10 dans lequel le modèle numérique modélise ladite au moins une contrainte de déploiement de l'application logicielle à partir d'au moins une file d'attente ou d'un réseau de files d'attente.
12. Procédé selon l'une quelconque des revendications 1 à 11 dans lequel au moins un profil de requêtes comprend, pour au moins une période de temps déterminée d'un cycle d'activité de l'application logicielle :
— un débit moyen des requêtes invoquant ce service sur ladite période de temps ;
— une proportion de requêtes invoquant ce service parmi les requêtes invoquant des services offerts par l'application logicielle ; et
— une distribution des durées d'inter-arrivées entre deux requêtes invoquant ce service sur ladite période de temps.
13. Procédé selon la revendication 1 à 12 dans lequel ladite application logicielle est caractérisée par un cycle d'activité comprenant une pluralité d'intervalles, chaque intervalle étant associé à un débit moyen d'arrivée des requêtes représentatif sur cet intervalle, et dans lequel lesdites étapes d'obtention, de sélection et de détermination sont mises en œuvre pour au moins un intervalle de ladite pluralité d'intervalles.
14. Procédé de gestion d'élasticité d'une configuration de serveurs apte à exécuter une application logicielle, ce procédé comprenant :
— une étape de détermination (F10) d'une configuration cible de serveurs pour le déploiement de l'application logicielle comprenant l'exécution d'un procédé de détermination selon l'une quelconque des revendications 1 à 13 ; et
— une étape d'exécution (F20) de l'application logicielle sur ladite configuration cible de serveurs comprenant : o une surveillance (F30) d'au moins une métrique de supervision de cette configuration cible ; et
o en fonction de ladite au moins une métrique, un ajustement (F40) des ressources de la configuration cible, cet ajustement comprenant un maintien et/ou un ajout et/ou un retrait dynamique de ressources à la configuration cible.
15. Système de détermination (1) d'une configuration cible pour un déploiement une application logicielle, le système comprenant :
- un premier outil de test (ENVI) permettant l'exécution d'au moins un test unitaire sur l'application logicielle lorsque celle-ci est exécutée sur une configuration de serveurs dite de référence ;
- un module d'obtention (2), configuré pour commander l'exécution d'au moins un test unitaire par le premier outil de test sur ladite configuration de référence et pour obtenir, pour au moins un service offert par l'application logicielle, un temps d'exécution moyen d'une requête invoquant ce service pour chaque serveur (Slj) de la configuration de référence ;
- un module de sélection (3), configuré pour sélectionner une configuration de serveurs initiale (CONFIG2) pour le déploiement de l'application logicielle apte à supporter une charge cible déterminée pour l'application logicielle, ledit module de sélection étant configuré pour tenir compte des temps d'exécution moyens obtenus lors dudit au moins un test unitaire, de la charge cible et d'une charge admissible déterminée pour la configuration de référence, et pour utiliser un modèle numérique reflétant au moins une contrainte de déploiement de l'application logicielle imposée à la configuration de serveurs initiale ;
- un second outil de test (ENV2) permettant l'exécution de tests de tenue en charge sur ladite application logicielle lorsque celle-ci est exécutée sur la configuration de serveurs initiale sélectionnée par le module de sélection ; et
- un module de détermination (4) configuré pour déterminer à partir de la configuration initiale une configuration de serveurs cible destinée à être utilisée pour le déploiement de l'application logicielle, ledit module de détermination étant configuré pour commander l'exécution d'une pluralité de tests de tenue en charge par le second outil de test, lesdits tests de tenue en charge étant paramétrés par le module de détermination en fonction d'une charge maximale théorique estimée pour la configuration initiale et de la charge cible, et utilisant au moins un profil de requêtes invoquant ledit au moins un service offert par l'application logicielle, ce profil étant représentatif d'une utilisation de l'application logicielle lors de son déploiement, ledit module de détermination étant en outre configuré pour ajuster, en fonction du résultat de chaque test de tenue en charge, au moins une ressource de la configuration initiale de sorte que la configuration cible obtenue à l'issue de ladite pluralité de tests de tenue en charge soit apte à vérifier un temps de réponse maximal fixé pour l'application logicielle et à supporter ladite charge cible.
PCT/FR2016/051266 2015-06-09 2016-05-27 Procédé et système de détermination d'une configuration de serveurs cible pour un déploiement d'une application logicielle WO2016198762A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1555267 2015-06-09
FR1555267A FR3037417A1 (fr) 2015-06-09 2015-06-09 Procede et systeme de determination d'une configuration de serveurs cible pour un deploiement d'une application logicielle

Publications (1)

Publication Number Publication Date
WO2016198762A1 true WO2016198762A1 (fr) 2016-12-15

Family

ID=54356436

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2016/051266 WO2016198762A1 (fr) 2015-06-09 2016-05-27 Procédé et système de détermination d'une configuration de serveurs cible pour un déploiement d'une application logicielle

Country Status (2)

Country Link
FR (1) FR3037417A1 (fr)
WO (1) WO2016198762A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109976773A (zh) * 2019-04-04 2019-07-05 网易（杭州）网络有限公司 游戏测试环境的部署方法和装置
CN112162891A (zh) * 2020-10-14 2021-01-01 腾讯科技（深圳）有限公司 服务器集群中的性能测试方法及相关设备

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10248400B1 (en) 2016-11-15 2019-04-02 VCE IP Holding Company LLC Computer implemented system and method, and a computer program product, for automatically determining a configuration of a computing system upon which a software application will be deployed
CN109739649B (zh) * 2018-12-28 2023-07-18 深圳前海微众银行股份有限公司 资源管理方法、装置、设备及计算机可读存储介质

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080155074A1 (en) * 2006-12-22 2008-06-26 Business Objects, S.A. Apparatus and method for automating server optimization

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080155074A1 (en) * 2006-12-22 2008-06-26 Business Objects, S.A. Apparatus and method for automating server optimization

Non-Patent Citations (6)

* Cited by examiner, † Cited by third party
Title
B. DILLENSEGER: "CLIF, a framework based on Fractal for flexible, distributed load testing", ANNALES DES TÉLÉCOMMUNICATIONS, vol. 64, no. L-2, February 2009 (2009-02-01)
L. LETONDEUR ET AL.: "Planification pour la gestion automatique de l'élasticité d'applications dans le cloud", COMPAS'2014, 23 April 2014 (2014-04-23)
LOÏC LETONDEUR ET AL: "Planification pour la gestion autonomique de l'élasticité d'applications dans le cloud", ACTES DE LA CONFERENCE COMPAS'14, 23-25 AVRIL 2014,NEUCHÂTEL, SUISSE, 23 April 2014 (2014-04-23), pages 1 - 12, XP055257355 *
N. SALMI ET AL.: "Model-based performance anticipation in multi-tiers autonomie systems : methodology and experiments", INTERNATIONAL JOURNAL ON ADVANCES IN NETWORKS AND SERVICES, vol. 3, no. 3, 4, 2010, Retrieved from the Internet <URL:http://www.iariajournals.org/networks_and_services/tocv3n34.html>
SUN YU ET AL: "A Model-Based System to Automate Cloud Resource Allocation and Optimization", 28 September 2014, CORRECT SYSTEM DESIGN; [LECTURE NOTES IN COMPUTER SCIENCE; LECT.NOTES COMPUTER], SPRINGER INTERNATIONAL PUBLISHING, CHAM, PAGE(S) 18 - 34, ISBN: 978-3-642-28871-5, ISSN: 0302-9743, pages: 18 - 34, XP047299834 *
YATAGHENE LYDIA ET AL: "A Queuing Model for Business Processes Elasticity Evaluation", 2014 INTERNATIONAL WORKSHOP ON ADVANCED INFORMATION SYSTEMS FOR ENTERPRISES, IEEE, 10 November 2014 (2014-11-10), pages 22 - 28, XP032699589, DOI: 10.1109/IWAISE.2014.12 *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109976773A (zh) * 2019-04-04 2019-07-05 网易（杭州）网络有限公司 游戏测试环境的部署方法和装置
CN109976773B (zh) * 2019-04-04 2023-01-10 网易（杭州）网络有限公司 游戏测试环境的部署方法和装置
CN112162891A (zh) * 2020-10-14 2021-01-01 腾讯科技（深圳）有限公司 服务器集群中的性能测试方法及相关设备
CN112162891B (zh) * 2020-10-14 2024-05-03 腾讯科技（深圳）有限公司 服务器集群中的性能测试方法及相关设备

Also Published As

Publication number Publication date
FR3037417A1 (fr) 2016-12-16

Similar Documents

Publication Publication Date Title
US20180254998A1 (en) Resource allocation in a cloud environment
US11171845B2 (en) QoS-optimized selection of a cloud microservices provider
EP3479285B1 (fr) Procédé et dispositif de surveillance de la sécurité d&#39;un système d&#39;information
EP2559196B1 (fr) Outil de gestion de ressources et d&#39;infrastructures informatiques et réseaux
US10581756B2 (en) Nonintrusive dynamically-scalable network load generation
US9825869B2 (en) Traffic shaping based on request resource usage
WO2016198762A1 (fr) Procédé et système de détermination d&#39;une configuration de serveurs cible pour un déploiement d&#39;une application logicielle
Prachitmutita et al. Auto-scaling microservices on IaaS under SLA with cost-effective framework
EP2559224B1 (fr) Outil de gestion de ressources et d&#39;infrastructures informatiques et de réseaux
EP2894872B1 (fr) Procédé d&#39;ordonnancement de tâches dans un réseau à courants porteurs en ligne
WO2010034920A1 (fr) Determination et gestion de reseaux virtuels
WO2011128595A1 (fr) Outil pour la gestion de ressources et d&#39;infrastructures informatiques et de reseaux
WO2014072628A1 (fr) Procédé, dispositif et programme d&#39;ordinateur de placement de tâches dans un système multi-coeurs
BE1028995A1 (fr) Interface d&#39;application dynamique basée sur une intention ascendante
WO2021260312A1 (fr) Procédé d&#39;ordonnancement de tâches dans un système de traitement, dispositif d&#39;ordonnancement associé
US20150277892A1 (en) Multi-phase software delivery
FR3096156A1 (fr) Plafonnement du rythme de transactions entrantes dans des échanges avec état entrants établis dans un environnement informatique distribué
EP3991356A1 (fr) Procede d&#39;allocation de ressources d&#39;une infrastructure de reseau
FR2995424A1 (fr) Procede et dispositif de decompte du temps deporte pour unite de traitement dans un systeme de traitement de l&#39;information
EP3051416B1 (fr) Procédé de commande de déploiement d&#39;un programme a exécuter dans un parc de machines
Souidi et al. An adaptive real time mechanism for IaaS cloud provider selection based on QoE aspects
EP3881515B1 (fr) Système de supervision formelle de communications
FR3060791A1 (fr) Procede et dispositif de mise a jour
FR3103664A1 (fr) Système de stockage distribué pour stocker des données contextuelles
Mireslami Cost and Performance Optimization for Cloud-Based Web Applications Deployment.

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16733639

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16733639

Country of ref document: EP

Kind code of ref document: A1