KR102339747B1 - Simulator, simulation device, and simulation method - Google Patents

Abstract

The availability of a service system composed of multiple services is estimated before system construction. At least one of the processing content of the service and the request transmission destination depending on the service in which the problem occurred is changed. In order to realize such a change in the simulation, the system configuration describing the dependency relationship between the respective services, the request transmission policy for other services describing the processing change according to the processing status related to the dependent service, and the request describing the request transmission rate A creation policy is entered. The simulator executes a service system behavior simulation when a request arrives based on the request generation policy, based on the system configuration and other service request transmission policies.

Description

Simulator, simulation device, and simulation method

FIELD OF THE INVENTION The present invention relates generally to the simulation of designed systems.

As a technique related to simulation of a designed system, the technique disclosed in Patent Document 1 is known. The simulator disclosed in Patent Document 1 outputs a system behavior when a disturbance such as an input load and a hardware failure constituting the system is applied to the designed system.

Japanese Patent Laid-Open No. 2005-196601

Hereinafter, "system development" includes design and construction of a system. That is, in system development, system development is completed through processes such as system design, construction of a designed system, and verification of the constructed system.

In recent years, with the spread of cloud computing, system development based on a microservice architecture has become common. In system development based on a microservice architecture, a service system is often built by combining a plurality of services such as a service developed by a developer, a service developed by another vendor, and a service provided by a cloud computing provider. many. These services are often deployed distributedly on a distributed environment (eg, a distributed computer system composed of a plurality of calculators (eg, general-purpose calculators)). An API (Application Programming Interface) is prepared for each service, and the services mutually transmit a processing request via a network, and the processing of the service system (for example, one or more tasks) is realized. do. By developing such a system, it is possible to construct a system quickly by reusing services and to improve the scaling performance by securing resources quickly, so advantages are expected from both development and operation.

However, a drawback of system development based on the microservice architecture is that it is difficult to find out the cause when the response time of the service system fluctuates, or to design a response to service failure.

In monolithic system development, that is, system development of a service system deployed on a single server, it is relatively easy to find out the cause of the case where the response time of the service system fluctuates. This is because it is easy to follow the flow of processing in the service system, and monitoring of resource consumption and the like at the time of execution is completed with a single server. Therefore, it is easy to guess in advance the location which may become an obstacle, and it is comparatively easy to coordinate the correspondence design.

On the other hand, in the microservice architecture, small-scale independent processing is executed in a computer system as a distributed environment, and processing related to one request to the service system spans between servers in which a plurality of services constituting the computer system are distributed. It becomes difficult to understand the flow of processing at development time and execution time. In addition, since the processing for one request is executed at a plurality of places (servers), a large number of communications occur between the servers. Therefore, there is a possibility that the bottleneck of processing exists in a network or message queue that has hitherto been difficult to exist. In addition, since there are cases in which at least some services in the same service system are services developed by different development organizations, a person (for example, a developer or a designer ) is less.

In general system development, in order to verify the availability of the designed system, after the designed system is experimentally built (that is, after the test system is built as a test environment equivalent to the actual environment), load test or response time measurement and repeating the design review based on the test results. However, this method requires a lot of time and cost because a test environment is required for the test.

Therefore, it is conceivable to use the same simulation technology as in Patent Document 1 and to estimate the availability of the service system before construction of the service system.

However, unlike the service system, the system to be simulated in Patent Document 1 is a system composed of a plurality of servers (for example, a three-tier Web system). That is, in Patent Document 1, a component of a system to be simulated is a server, and the system is maintained by so-called auto-scaling.

On the other hand, a computer system (a plurality of servers) in which a service system (typically, a service system designed in system development based on a microservice architecture) is deployed is generally a system development side (eg, providing a service system) It is a calculator system (eg, a calculator system under the control of an enterprise providing cloud computing) that is not under the control of an enterprise that provides cloud computing.

Therefore, on the system development side, the method of controlling the auto-scaling method in the computer system in order to maintain the availability of the service system cannot be taken. That is, the technique disclosed in Patent Document 1 cannot be applied to a simulation for verifying availability of a service system.

Even if a problem occurs in either service (for example, if a problem such as a failure or a change in response time occurs in some services), the expected behavior of the service system as a whole (for example, for end users In order to ensure that a certain response is returned), at least one of the processing content of the service depending on the service in which the problem occurred and the request transmission destination is changed. For example, when a request is sent from a certain service to a dependent service of the certain service, but no response is returned from the dependent service to the certain service after a certain period of time, the certain service executes any of the following it is thought to do

- The certain service generates an error notification and returns the error notification to the dependent source (or end user) of the service (an example of changing the processing content of the certain service).

- The certain service changes the request transmission destination from the service of the dependent destination to the warning notification service or alternative service (example of change of the request transmission destination of the certain service).

- The given service transmits most of the requests transmitted at a certain frequency to the request destination after the change, but sends some requests to the service of the dependent destination because the problem of the service of the dependent destination may be solved ( An example of changing the processing contents of the given service and the destination of the request).

In order to realize (reproduce) changing at least one of the processing content and the request transmission destination in the service system in this way in the simulation, the following information (a1), (a2) and (a3) is input to the simulator.

(a1) A system configuration describing the dependency relationship between services in a service system comprising a plurality of services and in which the plurality of services cooperate to perform processing according to a request from an end user by sending and receiving requests between the services.

(a2) Another service request transmission policy described below for each of at least one service among the plurality of services.

- Condition regarding the processing status that is at least one of the presence or absence of a failure in the service to which the request is sent because it is a dependent destination of the service and the processing speed.

・A change in processing that is at least one of the processing contents after the change of the service and the destination of the request after the change when it is said that the conditions are satisfied.

(a3) A request generation policy that describes the contents of a request to be transmitted to the service system as an end user and a transmission rate of the request.

The simulator executes, based on the system configuration and other service request transmission policies, a simulation of a system behavior that is a service system behavior when a request based on the request generation policy arrives at a transmission rate based on the request generation policy; Simulation result information, which is information indicating the system behavior as the execution result of the simulation, is output.

In a service system composed of a plurality of services, in particular, in a service system designed based on a microservice architecture and deployed in a distributed environment, changing at least one of the request destination and processing contents can be realized (reproduced) in simulation. Therefore, it is possible to simulate and output the system behavior when the change is made. For this reason, the availability of a service system can be estimated.

The details of at least one embodiment of the subject matter disclosed in this specification are set forth in the accompanying drawings and the description below. Other features, aspects and effects of the disclosed subject matter will be revealed by the following disclosure, drawings, and claims.

BRIEF DESCRIPTION OF THE DRAWINGS Fig. 1 is a diagram illustrating input/output of a microservice simulator.
Fig. 2 is a diagram illustrating a flow of use of a microservice simulator;
Fig. 3 is a diagram showing the internal configuration of an apparatus used for execution of a simulation input data creation tool and a microservice simulator;
It is a figure which exemplifies the system configuration creation support screen displayed by the simulation input data creation tool.
Fig. 5 is a diagram showing an example of another service request transmission policy;
Fig. 6 is a diagram showing an example of a request generation policy;
Fig. 7 is a diagram illustrating a system configuration of a microservice simulator;
Fig. 8 is a diagram illustrating a processing sequence at the time of constructing a simulation environment;
Fig. 9 is a diagram illustrating a processing sequence of policy change during simulation;
Fig. 10 is a diagram illustrating a processing sequence for a request to the system;
Fig. 11 is a diagram illustrating a processing sequence at the time of disturbance setting for a microservice simulator;
Fig. 12 is a diagram showing an example of a disturbance occurrence scenario;

In the following description, the "interface device unit" may be one or more interface devices. The one or more interface devices may be any of the following.

· An I/O interface device to at least one of an I/O (Input/Output) device and a remote display calculator. The I/O interface device for the display calculator may be a communication interface device. The at least one I/O device may be any of a user interface device, for example, an input device such as a keyboard and pointing device, and an output device such as a display device.

· One or more communication interface devices. The one or more communication interface devices may be one or more communication interface devices of the same type (eg, one or more NICs (Network Interface Cards)), and two or more different types of communication interface devices (eg, NICs and Host Bus Adapters (HBAs)). )) may be

In addition, in the following description, the "memory part" is one or more memories, and typically a main memory device may be sufficient. At least one memory in the memory unit may be a volatile memory or a nonvolatile memory.

In addition, in the following description, the "PDEV unit" is one or more PDEVs, and may typically be an auxiliary storage device. "PDEV" means a physical storage device (Physical storage DEVice), and is typically a nonvolatile storage device, for example, HDD (Hard Disk Drive) or SSD (Solid State Drive).

In addition, in the following description, the "storage unit" is at least one of a memory unit and a PDEV unit (typically at least a memory unit).

In addition, in the following description, a "processor part" is one or more processors. The at least one processor is typically a microprocessor such as a CPU (Central Processing Unit), but may be a different type of processor such as a GPU (Graphics Processing Unit). At least one processor may be single-core or multi-core. The at least one processor may be a processor in a broad sense such as a hardware circuit (eg, Field-Programmable Gate Array (FPGA) or Application Specific Integrated Circuit (ASIC)) that performs a part or all of processing.

In addition, in the following description, although a function may be demonstrated with the expression of "kkk part" (interface device part, a memory|storage part, and a processor part excluded), a function is realized when one or more computer programs are executed by a processor part. may be used, or may be realized by one or more hardware circuits. When the function is realized by executing the program by the processor unit, the function may be at least a part of the processor unit, since predetermined processing is performed while appropriately using the storage unit and/or the communication interface device unit or the like. The processing described with the function as the subject may be processing performed by the processor unit or an apparatus having the processor unit. The program may be installed as a program source. The program source may be, for example, a program distribution calculator or a computer-readable recording medium (eg, a non-transitory recording medium). The description of each function is an example, and a plurality of functions may be combined into one function, or one function may be divided into a plurality of functions.

In addition, in the following description, a "data set" is one logical chunk of electronic data viewed from the program, and for example, any of a record, a file, a key value pair, and a tuple may be used.

In addition, in the following description, the expression "xxx data set" describes a data set (information) from which an output is obtained with respect to an input in some cases. It may be a learning model, such as a neural network that is generated. In the following description, the configuration of each data set is an example, and one data set may be divided into two or more data sets, and all or part of the two or more data sets may be one data set.

Note that, in the following description, the term "displaying information for display" by an apparatus may mean displaying information for display on a display device included in the apparatus, and does not mean that the apparatus transmits information for display to a calculator for display. (in the latter case, the display information is displayed by the display calculator). An example of the information for display is simulation result information, which is information indicating the system behavior.

Hereinafter, a preferred embodiment of the present invention will be described with reference to the drawings.

The simulator according to the present embodiment relates to a simulator for estimating availability of a service system designed based on a microservice architecture. So, hereafter, this simulator is called "microservice simulator". In addition, overload conditions and prolonged response times that are intentionally generated for a virtual service (virtual service corresponding to a service) in a virtual system (virtual service system) to be described later built in the microservice simulator are “ It is called 'disruption'.

Fig. 1 shows an example of input/output of a microservice simulator.

Inputs to the microservice simulator 0112 are the system configuration 0106, the request creation policy 0108, and the other service request transmission policy 0107. These input data are saved in the input data storage 0105 .

The system configuration 0106 is a data set indicating the services constituting the service system and the dependency relationship between the services. The details of the system configuration 0106 will be described later based on FIG. 4 .

The other service request transmission policy 0107 is, for each of one or more services among the plurality of services, (1) processing that is at least one of the presence or absence of failure and the processing speed in the service to which the request is sent because it is a dependent destination of the service It is a data set describing the conditions related to the situation and (2) the processing change that is at least one of the processing contents after the change of the service concerned and the request transmission destination after the change in the case that the conditions are satisfied. Other service request transmission policy 0107 is, for example, a data set indicating a policy when each service sends a request to another service it depends on. In the other service request transmission policy 0107, it is possible to describe that the request transmission destination is changed according to the service status of the dependent destination. In addition, it is also possible to describe changes in the processing contents of one's own service. For example, when the response time of a certain service exceeds a certain threshold in the service of the dependent destination, the request is not transmitted to the service of the dependent destination, but to the service of the request source that sent the request to the own service. You can describe sending an error message.

The request generation policy 0108 is a policy used when creating a message pseudo-transmitted to the virtual system built in the microservice simulator 0112 during simulation. In the request generation policy 0108, the contents of the generated message, the service of the transmission destination, and the transmission rate within a certain period of time can be specified. It also makes it possible to specify the protocol used for transmission. By specifying the protocol, characteristics such as transmission speed, retransmission control, synchronous communication, or asynchronous communication peculiar to the protocol can be reproduced in simulation. In the request generation policy 0108, the number of requests to be generated can also be specified. By specifying an infinite number of requests, it is possible to run the simulation permanently. In this case, the simulation ends when the user (for example, a system designer) of the microservice simulator 0112 instructs the microservice simulator 0112 to end the simulation.

Hereinafter, the system configuration 0106, the request generation policy 0108, and the other service request transmission policy 0107 are collectively referred to as "input data". In addition, all users described after this shall point to the user of the microservice simulator 0112. In addition, the "end user" shall indicate the user of the service system, and is, for example, the issuer of the request with respect to a service system.

Outside of the microservice simulator 0112 , a simulation input data creation tool 0103 , a disturbance input console 0110 , and a policy input console 0113 exist. Any of these elements 0103, 0110 and 0113 may be a computer program or a physical device. For example, in a cloud-based (a calculator system having a plurality of computational resources), at least one of a microservice simulator 0112, a simulation input data creation tool 0103, a disturbance input console 0110, and a policy input console 0113 One may run.

The input data can be created by the user using the simulation input data creation tool 0103 . The simulation input data creation tool 0103 includes one or more UIs (Users) that receive input of information elements included in at least one of a system configuration 0106, another service request transmission policy 0107, and a request generation policy 0108. interface) is displayed. The one or more UIs may be included in one or a plurality of GUIs (Graphical User Interfaces). The information element input via the one or more UIs is included in at least one of the system configuration (0106), the other service request transmission policy (0107), and the request creation policy (0108). It is expected to efficiently prepare input data using one or more UIs provided by the simulation input data creation tool 0103 . For example, the simulation input data creation tool 0103 can import a message template from a request template DB 0101 that is a DB (database) that stores a template of a request message input to the virtual system during simulation. In addition, it is possible to import a service template from the service template DB 0102 that stores the service template constituting the service system. In addition, it is possible to save the created input file in the input data repository 0104 and import it when creating it next time. In addition, input data makes it possible for a user to create with an arbitrary editor.

As an example of the output of system behavior information, the microservice simulator 0112 outputs (displays) information indicating the transition of the response time, which is the request processing time of each service, and the amount of resources consumed by each service at a certain time. can An example of the output of these information is the output of the system behavior output screen (eg GUI) 0111 which is an example of UI which displays a system behavior. With the system behavior output screen 0111, it is possible to graph and output the output result. That is, in order to confirm that the service system (which may be referred to as an IT system) designed based on the microservice architecture has desired availability, the microservice simulator 0112 is a request assumed for the designed service system on the system development side. It is possible to estimate the system behavior (for example, the transition of response time of each service or the amount of resource used) when is input, and visualize the system behavior. In addition, it is possible to save as a log in the simulation log DB (0113).

In order to measure the availability of a service system, it is desirable to check availability at the time of disturbance by intentionally generating a disturbance in a specific service during the simulation. Thus, the user can intentionally generate a disturbance (eg, prolonged response time due to failure or overload) for a specific service during execution of the simulation, using the disturbance input console 0110 . have. Also, the disturbance input by the user on the disturbance input console 0110 can be stored as the disturbance occurrence scenario 0109 in the input data storage 0105 . The disturbance occurrence scenario 0109 is data describing at least one service ID included in the service system and disturbance (intentional processing stop, processing speed improvement, or processing speed decrease) at a specified time for the at least one service. is a set The disturbance occurrence scenario 0109 is input to the microservice simulator 0112 before the start of the simulation (or during the execution of the simulation), and after the start of the simulation, the microservice simulator 0112 follows the disturbance scenario 0109 to the virtual system It may cause a disturbance in the virtual service within.

In order to measure the availability of the service system, in the middle of the simulation (for example, based on the response time displayed by the system behavior output screen 0111 or the transition of the consumed resource amount), the content or transmission of a request issued as an end user It is preferable to change the rate, at least one service processing content, or a request transmission destination. Therefore, the user uses the policy input console 0113 to change at least one of the other service request transmission policy 0107 and the request creation policy 0108 during the execution of the simulation, and the microservice simulator 0112, The policy after the change is accepted during simulation execution, the policy after the change is reflected without stopping the simulation, and the simulation is continued according to the policy after the reflection. Thereby, it is possible to expect an efficient process of repeating the output of the estimated system behavior and the policy change based on the output without stopping the simulation. Further, the policy input by the user into the policy input console 0113 can be stored in the input data storage 0105 as either of the other service request transmission policy 0107 and the request creation policy 0108 .

According to the present embodiment, the microservice simulator 0112 inputs the above-described system configuration 0106, other service request creation policy 0107, and request creation policy 0108, and based on the request creation policy 0108 A simulation of system behavior when a request to be made arrives at a transmission rate based on the policy (0108) is performed based on the system configuration (0106) and other service request transmission policies (0107), and the system behavior is Display information. Thereby, in a service system designed based on a microservice architecture and deployed in a distributed environment, changing at least one of a request transmission destination and processing content can be realized (reproduced) in simulation, and In this case, the system behavior can be simulated and output. For this reason, the availability of a service system can be estimated.

Specifically, for example, during execution of the simulation, the microservice simulator 0112, for each of one or more services included in the service system, based on the other service request transmission policy 0107, the destination of the service dependent. Changes the processing status of the service of , and changes at least one of the processing content of the service and the request transmission destination accordingly, and simulates the system behavior after the change. The microservice simulator 0112 displays information including information indicating the system behavior before and after the change of the processing status of the dependent service for each of the one or more services. Thereby, the user can compare the system behavior before and after the change of the processing status of the dependent destination service (change of at least one of the processing content of a dependent service and a request sending destination).

In addition, at least one of the input data storage (0105), the request template DB (0101), the service template DB (0102), the input data repository (0104), and the simulation log DB (0113) is stored in a storage unit of one or more calculators. is realized by

Fig. 2 shows a flow chart when a user uses the microservice simulator 0112.

When the user's use is started (0201), first, the user creates input data using the simulation input data creation tool 0103 (0202). Even if input data is created using a template stored in the request template DB (0101) or service template DB (0102), past input data is imported from the input data repository (0104) and created with or without modification. also be After that, the user saves the created input data in the input data storage 0105 (0203).

Next, the user instructs the microservice simulator 0112 to load the input data stored in the input data storage 0105 (0204). When loading is finished, the user instructs the microservice simulator 0112 to start the simulation (0205).

After the simulation is initiated, the user can use the disturbance input console 0110 to instruct 0206 to simulate the disturbance for one or more services. If it is not necessary to confirm the effect of disturbance by simulation, this step may not be performed.

In addition, the user can change the other service request transmission policy 0107 while the simulation is running (0207). In order to change the other service request transmission policy during simulation, for example, the user first prepares the changed other service request transmission policy 0107 in the input data storage 0105, and sends it to the microservice simulator 0112 in the microservice simulator 0112 after the change. Instructs to import the service request transmission policy (0107). If it is not necessary to modify the other service request transmission policy 0107 during simulation, this step does not need to be performed.

Also, the user can change the request creation policy 0108 (0208) while the simulation is running. When changing the request generation policy 0108, for example, similarly to the change of the other service request transmission policy 0107, the user first prepares the changed request generation policy 0108 in the input data storage 0105, Instructs the microservice simulator (0112) to import the request creation policy (0108) after the change. If it is not necessary to modify the request generation policy 0108 during simulation, this step may not be performed.

Any conditions may be sufficient as the completion|finish condition of a simulation. For example, the termination condition is that a request to the virtual system is inputted to the virtual system as many times as the number of times of message generation described in the request creation policy 0108, processing according to the request is completed, or the user It sends a simulation end command to the microservice simulator 0112. When any of the above conditions is satisfied, the simulation is finished (0209), and the user's use is ended (0210).

3 shows the internal configuration of an apparatus used for execution of the simulation input data creation tool 0103 and the microservice simulator 0112. As shown in FIG. This apparatus is an example of a simulation apparatus, and a computer may be sufficient as it. Hereinafter, the device illustrated in FIG. 3 is referred to as a “simulation device” for convenience. Further, in the present embodiment, the simulation input data creation tool 0103 and the microservice simulator 0112 are executed in the device, but the simulation input data creation tool 0103 and the microservice simulator 0112 are two or more different from each other. It may be run on a calculator.

The simulation apparatus 0301 is composed of a processor unit 0302, an I/O interface device unit 0303, a storage unit 0304, and a communication interface device unit 0305, which are connected to each other by an internal bus. The I/O interface device section 0303 and the communication interface device section 0305 are interface device sections. To the I/O interface device portion 0303, one or more user interface devices such as an input device such as a keyboard or an output device such as a liquid crystal display are connected. One or more external devices 0306 are connected to the communication interface device unit 0305 via a network such as the Internet, for example. However, the data stored in the storage unit 0304 is different for each device, and in the storage unit 0304 of each device, a program for realizing the function of the device and an event log or event log after processing is performed. A storage area for storing data may exist. The simulation input data creation tool 0103 and the microservice simulator 0112 are loaded from the storage unit 0304 and executed by the processor unit 0302 .

4 : shows the system configuration creation support screen displayed by the simulation input data creation tool 0103.

A system configuration creation support screen 0401 is a plurality of UIs: a service template screen 0404 (an example of a first UI), a system configuration design screen 0405 (an example of a second UI), and a service detail screen 0406 ) (an example of the third UI). One or more information elements included in the system configuration 0106 are information elements input via the system configuration creation support screen 0401 .

The service template screen 0404 is a UI for receiving, from the user, selection of one or more desired service templates among one or a plurality of service templates stored in the service template DB 0102 . On the screen 0404, for example, four template objects 0407 to 0410 respectively corresponding to the four service templates are displayed.

The system configuration design screen 0405 displays one or more service objects respectively corresponding to one or more service templates (template objects) selected from the service template screen 0404, and allows the user to specify a dependency relationship of the one or more service objects. This is the receiving UI. In the example of FIG. 4 , five service objects 0411 to 0415 respectively corresponding to the five services are displayed. The at least one service object may be a service object corresponding to the service template selected from the service template screen 0404 . Note that, on the service template screen 0404, a service object corresponding to a service created without using any service template may be displayed. In the system configuration design screen 0405, the dependency relationship between services can be expressed by arrows (edges) between service objects (nodes), but other types of expressions may be employed. In two service objects connected by an arrow, the service object at the starting point (circle) of the arrow is an object corresponding to the service of the dependent source, and the service object at the end point (destination) of the arrow corresponds to the service of the dependent source is one object.

The service detail screen 0406 shows one or more service templates corresponding to the selected service object (for example, the service C object 0413) among the one or more service objects deployed (displayed) on the system configuration design screen 0405. It is a UI that accepts input of values.

At least one of the plurality of services constituting the service system is a service based on a service template in which one or more values input through the service detail screen 0406 are set. By using the service template, it is possible to efficiently design the service system. The at least one service template may be a service itself created in the past.

Using the system configuration creation support screen 0401 illustrated in FIG. 4 , the user can design a service system as follows, for example. In addition, the display in response to a user operation on the screen 0401 is controlled by the simulation input data creation tool 0103 .

The user describes the system configuration 0106 on the system configuration design screen 0405 . In the system configuration 0106, all of the services used in the system and the dependency relationship between the services are expressed. Arrows connecting services indicate that one service sends a request to another service. For example, since service A depends on service B and service C, service A transmits a request to service B and service C.

When the user selects a service in the system configuration design screen 0405 , details of the selected service are displayed on the service detail screen 0406 . As a detailed example of the service, the amount of resources the service consumes in processing for each request is displayed. As a UI corresponding to an item for setting the amount of resources to be consumed, a UI for input of the number of CPUs (0416) and a UI (0417) for input of the amount of memory, and at the same time, when a large number of requests arrive, the amount of resources is dynamically increased A UI 0418 for setting whether or not auto-scale is supported is displayed. These values allow the user to be set as input data of the microservice simulator 0112. If autoscale is not supported, the amount of resources allocated to each service can also be set. In the UI 0419 of the response time change item of the service detail screen 0406, the user can set the response time of the service. In the UI 0420 of the processing synchronization item of the service detail screen 0406, when the service receives a request, the user can select whether to make the request source wait in a response waiting state or perform processing asynchronously without waiting. can be set.

The items of request processing load, response time variation, and processing synchronization on the service detail screen 0406 can also be individually written for each request content processed by the service.

In the service template screen 0404, all or part of the service templates of the services included in the system configuration design screen 0405 are displayed as a list. When a user pastes a service template on the system configuration design screen 0405, the pasted service template is recognized as a service. In the service created by the service template, a value is set on the service detail screen 0406, and the user corrects the value of a certain item if necessary. Thereby, the time required for the user to create the system configuration 0106 is shortened.

When the design of the system configuration is completed, when the user clicks or taps the save button 0403, the system configuration 0106 indicating the designed system configuration is saved in the input data repository 0104 and the input data storage 0105. Also, by clicking the import button 0402, the system configuration 0106 saved in the input data repository 0104 can be imported into the system configuration design screen 0405.

As illustrated in FIG. 4 , the user can design a service system by repeating selection (creation) of a service and establishment of a dependency relationship between services. At least one service among the designed service systems may be a service developed by an organization different from the user side (system development side). A user designs a service system for realizing one or a plurality of tasks by cooperating with a plurality of services having a dependency relationship between the respective services.

In addition, in the simulation input data creation tool 0103, there may be a screen in which the user sets the other service request transmission policy 0107 for each service and the request generation policy 0108 to the system.

5 shows an example of another service request transmission policy 0107. The other service request transmission policy 0107 in Fig. 5 conforms to the JSON (JavaScript (registered trademark) Object Notation) format, but the format does not have to be JSON.

The description in line 0503 specifies the service to which the policy described in lines 0502 to 0528 is applied. The description in the 0504th line is an identifier of the service for which the service specified in the 0503th line is waiting for a request. A location surrounded by "{" and "}" represents a variable. The user can describe, for each variable value, the processing and transfer destination of a request that has reached the service. The description on the 0505th line indicates a port number. The description in line 0507 indicates the method of a request to the service. For example, when waiting for a request by HTTP, any of GET, PUT, PUSH, and DELETE is specified. The description on the 0509th and 0510th lines designates the value of the location designated as the variable of the 0504th line of the character string. An asterisk here represents an arbitrary character string. It does not need to be an asterisk in particular, and any character or character string that is not valid as an endpoint description is sufficient. The descriptions in lines 0511 to 0526 indicate processing and transfer destinations for requests whose endpoints are specified by the combination of descriptions in lines 0504, 0509, and 0510.

The description in the 0512th to the 0524th line shows the processing in the case where a failure occurs, such as a response not returning to the request destination service and the destination service for a long time. The description in the 0513th line indicates the request transmission destination service. Line 0514 shows the request method. The description in line 0515 indicates the end point of the request transmission destination. The descriptions on the 0517th and 0524th lines indicate indicators and standards for considering that a failure has occurred in the service of the sender. In the example of FIG. 5 , as a criterion for the service C to consider that a failure has occurred in the service D, the response time of the service D is set to be 50 ms or more. As another failure determination criterion, it is also possible to specify failure determination standards, such as when the number of requests for which service C has sent to service D and has not yet returned a response exceeds a certain number, it is regarded as a failure. The description in line 0518 specifies processing when it is considered that a failure has occurred in the service of the request destination. In the example of Fig. 5, assuming that a failure has occurred in the service D, the next request to be transmitted to the service D is not transmitted to the service D, but a response indicating an error is returned to the service that transmitted the request to the service C . This operation prevents the overall system response time from being prolonged due to the failure of the service D.

The user can designate a service to which a request is to be sent when a failure occurs in the request transmission destination at a location corresponding to lines 0517 to 0523. For example, when a warning message is transmitted to a system monitoring service, the user designates a system monitoring service.

The description in line 0522 shows the standard for judging that the service of the request transmission destination has recovered from the failure. In the example of Fig. 5, it is set as time, and by the description of line 0523, when the time has elapsed by 1 second, it is intended to consider that the service D has recovered from the failure.

When the service specified in line 0503 sends a request to a plurality of services, the user enumerates the descriptions in lines 0512 to 0525 in an array format. In addition, when the service designated in line 0503 accepts a plurality of request methods, the user enumerates the descriptions in lines 0507 to 0528 in an associative array using the method as a key. In addition, the user enumerates the descriptions of lines 0502 to 0530 in an array form for all services included in the system configuration 0106 .

According to the example of Fig. 5, the other service request transmission policy 0107 is, for each of one or more services, one service as an example (“target service” in the description of Fig. 5), at least one of the following:

· ID of the target service;

· ID of the service on which the target service depends (eg, the service for which the target service is waiting for a request);

・Processing details of requests that have reached the target service in the normal time (“normal time” means other than when there is a problem with the client service);

・Condition that there is a problem with the requester service (eg, response time threshold);

・At least one of the processing contents and the request destination in the case of a problem when the conditions are satisfied

includes

6 shows an example of a request generation policy 0108. Although the request generation policy 0108 in Fig. 6 conforms to the JSON (JavaScript (registered trademark) Object Notation) format, the format does not have to be JSON.

The request creation policy 0108 is a policy for generating a request to the system during simulation. The description of line 0603 shows the protocol of the request. The description on line 0604 indicates an endpoint that is a request destination for the system. The description on the 0605th line indicates the port number of the endpoint. The description in line 0606 indicates the number of requests transmitted to the system during simulation. As shown in line 0617, when a character other than a numeric value is entered in the number of requests, requests are continuously sent to the system permanently. The description in the 0607th to the 0611th line indicates the transmission rate of the request to the system. In the example of lines 0607 to 0611 in Fig. 6, the average is 100 requests per unit time, and the requests are transmitted with a probability that the variance follows a normal distribution of 10.

When sending multiple types of requests to the system or sending requests to multiple services, a plurality of descriptions equivalent to those in lines 0602 to 0612 are described. In the example of FIG. 6 , during the simulation, requests arrive at port 80 of service A by the HTTP protocol at a transmission rate according to a normal distribution with an average of 100 pieces per unit time and a variance of 10, and 18181 of service B On port No. 1, with the Thrift protocol, 100 requests per unit time arrive at a fixed rate.

7 shows the system configuration of the microservice simulator 0112.

The microservice simulator 0112 includes a plurality of modules (functions) such as a simulation control unit 0706 , an input file load unit 0703 , a virtual system construction unit 0704 , and a request generation unit 0707 .

The simulation control unit 0706 constructs the simulation environment, starts the simulation, pauses the simulation, ends the simulation, and inputs disturbance to a specific service according to a command from the user. In addition, the command from the user may be received via at least one of the disturbance input console 0110, the policy input console 0113, and other input consoles not shown.

The input file load unit 0703 reads an input file (an example of an input data set) existing in the input data storage 0105 according to an instruction from the simulation control unit 0706 , and sends it to the virtual system construction unit 0704 . send.

The virtual system building unit 0704 virtually builds a service system to be simulated in the microservice simulator 0112 based on the input file received from the input file loading unit 0703 . At that time, the virtual system building unit 0704 creates an instance of each service included in the service system based on the system configuration. That is, the virtual system building unit 0704 constructs a virtual system 0700 that is a virtual service system composed of a plurality of virtual services 0708 respectively corresponding to the plurality of services. Accordingly, in the virtual system 0700, the dependency relationship between the respective virtual services is the same as the dependency relationship between the respective services in the service system. Each virtual service 0708 is a service in which the corresponding service is virtualized, and specifically, corresponds to an instance of the corresponding service, for example.

The simulation control unit 0706 accepts control of the simulation from the user. The control received by the simulation control unit 0706 is any one of the establishment of the virtual system 0700 in the simulation, the start of the simulation, the pause of the simulation, the end of the simulation, and the intentional disturbance to a specific service. will be.

The request generation unit 0707 generates a request input to the virtual system 0700 during simulation. The virtual service 0708 generated by the virtual system building unit 0704 includes a service control receiving unit 0709 , a service processing unit 0710 , and another service request unit 0711 . Hereinafter, one virtual service 0708 is taken as an example ("target virtual service 0708" in the description of FIG. 7).

The service control receiving unit 0709 receives control of the target virtual service 0708 from the simulation control unit 0706 . For example, when the user temporarily stops the simulation, the user instructs the simulation control unit 0706 to pause, and the simulation control unit 0706 sends the service control receiving unit 0709 of each virtual service 0708 to the Send a pause command. The service processing unit 0710 continues to consume the amount of resources required for the processing of the target virtual service 0708 while the target virtual service 0708 is processing. The processing time of the target virtual service 0708 and the amount of resources consumed during processing are based on values specified in the system configuration 0106 . The other service request unit 0711 transmits a request to the other virtual service 0708 after processing in the service processing unit 0710 is completed. The request transmission destination complies with the rule specified by the other service request transmission policy (0107). That is, the request destination is, in principle, the virtual service 0708 of the dependent destination of the target virtual service 0708, but when a problem occurs in the virtual service 0708 of the dependent destination, it is different from the virtual service 0708 of the dependent destination. virtual service 0708 . In other words, in the target virtual service 0708, the normal request transmission destination is the virtual service 0708 of the dependent destination according to the dependency relationship indicated by the service configuration 0106, but there is a problem with the virtual service 0708 of the dependent destination. In the case of occurrence, the request transmission destination is a virtual service 0708 conforming to the other service request transmission policy 0107.

Each service is typically an application, and has an API (Application Programming Interface) as an example of an input interface that accepts a request, and an API as an example of an output interface that sends a request to an input API of another service. In the target virtual service 0708 , the service processing unit 0710 is a part corresponding to the input API of the service corresponding to the target virtual service 0708 , and a part realized by setting a value based on the service configuration 0106 . to be. In the target virtual service 0708, the other service request unit 0711 is a part corresponding to the output API of the service corresponding to the target virtual service 0708, and a value based on the other service request transmission policy 0107 is It is a part that has been realized by setting it up.

As described above, in each virtual service 0708, the output interface included in the virtual service 0708 is a module as an output interface set based on the other service request transmission policy 0107, the other service request unit 0711 to be. Thereby, when a problem arises in the service of the dependent destination, it is possible in simulation to switch the request transmission destination to another service. In addition, in the virtual service 0708 in which the virtual service 0708 of a dependent destination does not exist, the other service request part 0711 does not need to be provided.

Further, each virtual service 0708 receives a request as an input interface and, in addition to the service processing unit 0710 that executes processing according to the request, a service processing unit 0710 in the virtual service 0708 (and It has a service control receiving unit 0709 that controls the other service request unit 0711). Accordingly, it is possible to control the service processing unit 0710 (and the other service request unit 0711) without making special settings in the service processing unit 0710 (and other service requesting unit 0711) itself. Specifically, for example, during simulation execution, after the virtual system 0700 is built, the simulation control unit 0706 outside the virtual system 0700 sets the policy 0107 after changing the other service request transmission policy 0107 ) is accepted (in the present embodiment, the user can change at least one of the other service request transmission policy 0107 and the request generation policy 0108 as appropriate by looking at the system behavior displayed during the simulation). In this case, a virtual service 0708 (for example, a virtual service 0708 corresponding to the service specified by the change policy 0107) having the change target other service request unit 0711 conforming to the change policy 0107. )), to the service control receiving unit 0709, an instruction for setting according to the changed policy 0107 is transmitted. Upon receiving the instruction, the service control receiving unit 0709 temporarily suspends the service processing unit 0710 in the virtual service 0708 having the service control receiving unit 0709, and during the temporary suspension, other users in the virtual service 0708 are suspended. The service request unit 0711 is set according to the instruction. In this way, the changed policy 0107 can be reflected without stopping the simulation.

In addition, in the present embodiment, the service processing unit 0710 does not actively execute the prescribed processing and appropriately instructs the other service requesting unit 0711 to transmit the request, but performs the processing in response to receiving the request from the outside. is to be executed. Specifically, outside the virtual system 0700, a request generating unit 0707 that transmits a request as an end user is provided. The request generation unit 0707 transmits a request with content conforming to the request generation policy 0108 to the virtual system 0700 as an end user at a transmission rate conforming to the policy 0108 . While the simulation is being executed, after the virtual system 0700 is built, the request generating unit 0707 outside the virtual system 0700 sends the request generation policy 0108 to the policy 0108 after the change via the simulation control unit 0706 . ) is received. In this case, the request generation unit 0707 transmits a request for contents conforming to the post-change policy 0108 to the virtual system 0700 as an end user at a transmission rate conforming to the post-change policy 0108 .

Fig. 8 shows a processing sequence of building a simulation environment.

Construction of the simulation environment is performed before starting the simulation. When the user instructs the simulation control unit 0706 to build a simulation environment (0801), the simulation control unit 0706 transmits an input file load command to the input file load unit 0703 (0802). In response to the command, the input file loading unit 0703 refers to the input data storage 0105 (0803), and acquires (0804) an input file (input data) and receives (0805).

Thereafter, the input file load unit 0703 transmits the system configuration 0106 and other service request transmission policy 0107 to the virtual system construction unit 0704 (0806). The virtual system building unit 0704 builds the virtual system 0700 according to the system configuration 0106 and other service request transmission policy 0107, for example, an instance of a service included in the system configuration 0106. Create in the simulation environment (0807). Further, the input file loading unit 0703 transmits the request generation policy 0108 to the request generation unit 0707 (0808). The request generation unit 0707, according to the request generation policy 0108, includes the contents of the request input to the service system (virtual system 0700), and the service (virtual service 0708 corresponding to the service) that is the destination of the request. ) and a request transmission rate is set (0809).

As described above, the request generation policy 0108 and other service request transmission policy 0107 can be changed even during simulation without stopping the simulation.

Fig. 9 shows a processing sequence of policy change during simulation.

After the simulation is started (0901), the user prepares a new request creation policy (0108) or another service request transmission policy (0107) in the input data storage (0105).

When the user instructs the simulation control unit 0706 to reload the request generation policy 0108 (0902), the simulation control unit 0706 sends the input file loading unit 0703 to the new request generation policy 0108. An acquisition is ordered (0903). Then, the input file load unit 0703 refers to the request creation policy 0108 to the input data storage 0105 (0904). The input data storage 0105 acquires the corresponding request creation policy 0108 (0905), and transmits the policy 0108 to the input file load unit 0703 (0906). The input file load unit 0703 transmits the request generation policy 0108 to the request generation unit 0707 (0907). The request generation unit 0707 reflects the acquired new request generation policy (0908), and transmits a request to the service system (virtual system 0700) based on the new request generation policy 0108.

Further, when the user instructs the simulation control unit 0706 to reload the other service request transmission policy 0107 (0909), the simulation control unit 0706 sends a new other service request to the input file loading unit 0703 The acquisition of the policy (0107) is commanded (0910). Thereafter, the input file load unit 0703 refers to the other service request transmission policy 0107 to the input data storage 0105 (0911). The input data storage 0105 acquires the corresponding other service request transmission policy 0107 (0912), and transmits the policy 0107 to the input file load unit 0703 (0913). The input file loading unit 0703 sends a new service request transmission policy 0107 (or an external part thereof) to the service control receiving unit 0709 of the virtual service 0708 that needs to be modified according to the other service request transmission policy 0107. ) is transmitted (0914). The service control receiving unit 0709 transmits a new other service request transmission policy 0107 to the other service request unit 0711 in its own service (0915). Thereafter, the other service request unit 0711 reflects the received other service request transmission policy 0107 as its own request transmission policy (0916). In step 0914, the transmission destination of the new other service request transmission policy 0107 is set to the other service request unit 0711, so that the service control receiving unit 0709 does not have to relay the other service request transmission policy.

Fig. 10 shows a processing sequence for a request to the system during simulation execution.

When the user instructs the simulation control unit 0706 to start the simulation (1001), the simulation control unit 0706 instructs the request generation unit 0707 to generate a request (1002). The request generation unit 0707 generates a request according to the request generation policy 0108 (1003), and transmits the request to the service processing unit 0710 in the virtual service 0708 (1004).

When a request arrives at the service processing unit 0710, the service processing unit 0710 increases the amount of resources consumed by the service by the amount of resources required to process the service for one request (1005), and the time required for the processing Waits for processing as much as (1006). In addition, "amount of resources required for service processing for one request" and "time required for processing" are defined in the service configuration 0106 (or other input data sets) and set in the service processing unit 0710 make it become When the time required for processing has elapsed, the service processing unit 0710 reduces the amount of resources required for service processing for one request (1007). When the virtual service 0708 sends a request to another virtual service 0708, the service processing unit 0710 transmits the request to the other service request unit 0711 (1008). The other service request unit 0711 is configured according to whether another virtual service 0708 (typically, a virtual service 0708 of a dependent destination) meets a prescribed problem condition (eg, response time, failure situation, Alternatively, the virtual service 0708 of the request transmission destination is determined (1009) according to whether a situation such as the number of transmission completion requests for which no response is returned satisfies the condition prescribed in the other service request transmission policy 0107). That is, it is determined whether the request transmission destination will remain as the dependent destination virtual service 0708 or a different virtual service 0708 . Then, the other service request unit 0711 transmits the request to the service processing unit 0710 of the determined request transmission destination virtual service 0708 (1010).

When receiving a response from another virtual service 0708 (1011), the other service request unit 0711 stores the response time of the other virtual service 0708 (1012). The stored response time of the other virtual service 0708 can be referred to from the service processing unit 0710 as well. By storing the response time of the other virtual service 0708, the service processing unit 0710 can change the processing content of the virtual service 0708 according to the response time of the virtual service 0708 of the request transmission destination. In addition, the other service request unit 0711 can change the virtual service 0708 of the transmission destination according to the output log. The response is returned to the service processing unit 0710 of the own virtual service 0708 (1013). Thereafter, the service processing unit 0710 outputs the response time in the request to the other virtual service 0708 as a log (1014). Thereafter, the service processing unit 0710 returns a response to the request generation unit 0707 (1015).

11 shows a processing sequence when a user inputs disturbance to the microservice simulator 0112 during simulation. In the simulation, the problem of the virtual service 0708 of the dependent destination will occur according to at least one of the other service request transmission policy 0107 and the disturbance occurrence scenario 0109.

A user inputs ( 1101 ) a disturbance (disturbance occurrence scenario 0109 ) using the disturbance input console 0110 during the simulation. In step 1101, the user designates a service causing disturbance and contents of the disturbance. As an example of the content of disturbance, it is possible to designate the suspension of the service or the increase of the response time of the service. The disturbance input console 0110 sends an instruction to the simulation control unit 0706 to generate a disturbance input by the user in the simulation ( 1102 ). The simulation control unit 0706 confirms that the virtual service 0708 corresponding to the service designated by the user is operating during the simulation, and transmits an instruction to generate a disturbance to the service control receiving unit 0709 of the virtual service 0708 ( 1103). When the service control receiving unit 0709 receives an instruction to generate a disturbance, the service control receiving unit 0709 instructs the service processing unit 0710 to change the process according to the content of the disturbance specified by the user (1104). For example, when the user designates to stop the service, the service processing unit 0710 does not accept a request from another service, and the processing during execution does not return a response to the request source of the processing. quit In addition, when the user designates an increase in the response time of the service, the service processing unit 0710 increases the response time set in the service processing unit 0710 by the amount specified by the user.

12 shows an example of a disturbance occurrence scenario 0109.

The descriptions in lines 1202 to 1209 indicate a single disturbance event for a single service. When multiple disturbances are set, all disturbances are listed in an array format as in lines 1210 to 1218.

The description in line 1203 indicates the time or time from the start of the simulation until the disturbance occurs. The description in line 1204 indicates the time at which the event of the disturbance ends or the duration of the disturbance. The description in line 1205 shows a service in which disturbance occurs. The description in line 1206 shows the contents of the disturbance. Line 1206 of Fig. 12 shows, for example, that the service has been stopped, and line 1214 shows that the response time of the service has been lengthened. The descriptions from lines 1207 to 1208 indicate supplementary information on the disturbance that has occurred. For example, in the 1215th to the 1217th lines, it is shown that the response time is tripled normally.

The disturbance occurrence scenario 0109 is input to the microservice simulator 0112 before the start of the simulation, and after the simulation starts, the microservice simulator 0112 follows the disturbance scenario 0109 to generate a disturbance in the service in the system. . A user may create a disturbance occurrence scenario using a disturbance input console, a simulation input data creation tool, or any text editor.

In the above, one embodiment of the present invention has been described, but these are examples for the description of the present invention, and it is not intended to limit the scope of the present invention only to this embodiment. The present invention can also be implemented in other various forms.

0112: Microservices Simulator
0105: input data storage
0106: System Configuration
0107: Other service request transmission policy
0108: Request creation policy
0109: Disturbance Occurrence Scenario
0103: Simulation input data creation tool
0110: disturbance input console
0706: Simulation Control
0703: Load input file
0113: Policy input console

Claims (12)

(A) Input the information of (a1), (a2) and (a3) below,
(a1) A system configuration describing the dependency relationship between each service in a service system comprising a plurality of services and in which the plurality of services cooperate to perform processing according to a request from an end user by sending and receiving requests between the services;
(a2) another service request transmission policy in which the following (a21) and (a22) are described for each of at least one service among the plurality of services;
(a21) a condition regarding the processing status that is at least one of the presence or absence of a failure in the service to which the request is sent because it is a dependent destination of the service and the processing speed;
(a22) A change in processing that is at least one of the processing contents after the change of the service and the destination of the request after the change, when it is said that the conditions are satisfied;
(a3) a request generation policy in which the contents of a request to be transmitted to the service system as the end user and a transmission rate of the request are described;
(B) A simulation of a system behavior that is a behavior of the service system when a request based on the request generation policy arrives at a transmission rate based on the request generation policy is performed in the system configuration and the other service request transmission policy run on the basis of
(C) outputting simulation result information, which is information indicating the system behavior as a result of executing the simulation
run it on your computer,
During the execution of the simulation in (B),
Receive a policy after changing at least one of the other service request transmission policy and the request creation policy;
The policy after the change is reflected without stopping the simulation,
According to the policy after the reflection, the simulation continues.
A simulator stored in a computer-readable recording medium, characterized in that the computer is executed. (A) Input the information of (a1), (a2) and (a3) below,
(a1) A system configuration describing the dependency relationship between each service in a service system comprising a plurality of services and in which the plurality of services cooperate to perform processing according to a request from an end user by sending and receiving requests between the services;
(a2) another service request transmission policy in which the following (a21) and (a22) are described for each of at least one service among the plurality of services;
(a21) a condition regarding the processing status that is at least one of the presence or absence of a failure in the service to which the request is sent because it is a dependent destination of the service and the processing speed;
(a22) A change in processing that is at least one of the processing contents after the change of the service and the destination of the request after the change, when it is said that the conditions are satisfied;
(a3) a request generation policy in which the contents of a request to be transmitted to the service system as the end user and a transmission rate of the request are described;
(B) A simulation of system behavior, which is the behavior of the service system when a request based on the request generation policy arrives at a transmission rate based on the request generation policy, is performed in the system configuration and the other service request transmission policy run on the basis of
(C) outputting simulation result information, which is information indicating the system behavior as a result of executing the simulation
run it on your computer,
During the execution of the simulation of (B), for each of the one or more services included in the service system, the processing status of the service dependent on the service is changed based on the other service request transmission policy, and accompanying it to change at least one of the processing contents of the service and the request transmission destination;
In (C), as the simulation result information, information including information indicating a system behavior before and after a change in the processing status of a dependent service for each of the one or more services is output.
A simulator stored in a computer-readable recording medium, characterized in that the computer is executed. (A) Input the information of (a1), (a2) and (a3) below,
(a1) A system configuration describing the dependency relationship between each service in a service system comprising a plurality of services and in which the plurality of services cooperate to perform processing according to a request from an end user by sending and receiving requests between the services;
(a2) another service request transmission policy in which the following (a21) and (a22) are described for each of at least one service among the plurality of services;
(a21) a condition regarding the processing status that is at least one of the presence or absence of a failure in the service to which the request is sent because it is a dependent destination of the service and the processing speed;
(a22) A change in processing that is at least one of the processing contents after the change of the service and the destination of the request after the change, when it is said that the conditions are satisfied;
(a3) a request generation policy in which the contents of a request to be transmitted to the service system as the end user and a transmission rate of the request are described;
(B) A simulation of system behavior, which is the behavior of the service system when a request based on the request generation policy arrives at a transmission rate based on the request generation policy, is performed in the system configuration and the other service request transmission policy run on the basis of
(C) outputting simulation result information, which is information indicating the system behavior as a result of executing the simulation
run it on your computer,
At least one service ID included in the service system before or during the execution of the simulation of (B), and the disturbance of the at least one service that is intentional processing stop, processing speed improvement, or processing speed decrease at a specified time point Enter the disturbance scenario, which is information describing
In the simulation of (B), according to the disturbance occurrence scenario, a disturbance is generated for the at least one service,
In (C), as the simulation result information, information including information indicating the system behavior before and after the occurrence of disturbance for the at least one service is output.
A simulator stored in a computer-readable recording medium, characterized in that the computer is executed. (A) Input the information of (a1), (a2) and (a3) below,
(a1) A system configuration describing the dependency relationship between each service in a service system comprising a plurality of services and in which the plurality of services cooperate to perform processing according to a request from an end user by sending and receiving requests between the services;
(a2) another service request transmission policy in which the following (a21) and (a22) are described for each of at least one service among the plurality of services;
(a21) a condition regarding the processing status that is at least one of the presence or absence of a failure in the service to which the request is sent because it is a dependent destination of the service and the processing speed;
(a22) A change in processing that is at least one of the processing contents after the change of the service and the destination of the request after the change, when it is said that the conditions are satisfied;
(a3) a request generation policy in which the contents of a request to be transmitted to the service system as the end user and a transmission rate of the request are described;
(B) A simulation of a system behavior that is a behavior of the service system when a request based on the request generation policy arrives at a transmission rate based on the request generation policy is performed in the system configuration and the other service request transmission policy run on the basis of
(C) outputting simulation result information, which is information indicating the system behavior as a result of executing the simulation
run it on your computer,
The information element included in at least one of the system configuration, the other service request transmission policy, and the request creation policy is an information element included in at least one of the system configuration, the other service request transmission policy, and the request creation policy Information elements input through one or more UI (User Interface) that receive input of
The simulator stored in a computer-readable recording medium, characterized in that. delete (A) Input the information of (a1), (a2) and (a3) below,
(a1) A system configuration describing the dependency relationship between each service in a service system comprising a plurality of services and in which the plurality of services cooperate to perform processing according to a request from an end user by sending and receiving requests between the services;
(a2) another service request transmission policy in which the following (a21) and (a22) are described for each of at least one service among the plurality of services;
(a21) a condition regarding the processing status that is at least one of the presence or absence of a failure in the service to which the request is sent because it is a dependent destination of the service and the processing speed;
(a22) A change in processing that is at least one of the processing contents after the change of the service and the destination of the request after the change, when it is said that the conditions are satisfied;
(a3) a request generation policy in which the contents of a request to be transmitted to the service system as the end user and a transmission rate of the request are described;
(B) A simulation of a system behavior that is a behavior of the service system when a request based on the request generation policy arrives at a transmission rate based on the request generation policy is performed in the system configuration and the other service request transmission policy run on the basis of
(C) outputting simulation result information, which is information indicating the system behavior as a result of executing the simulation
run it on your computer,
The simulation of (B) includes building a virtual system in which the service system is a virtualized system based on the system configuration and the other service request transmission policy,
The virtual system consists of a plurality of virtual services, wherein the plurality of services are virtualized services,
each of the one or more services has an output interface;
Among the plurality of virtual services, for each of one or more virtual services corresponding to the one or more services, the output interface of the virtual service is a module as an output interface set based on the other service request transmission policy. Other service request department
The simulator stored in a computer-readable recording medium, characterized in that. 7. The method of claim 6,
each of the one or more services has an input interface;
Each of the one or more virtual services respectively corresponding to the one or more services,
a service processing unit which is a module that receives a request as an input interface and executes processing according to the request;
A service control receiving unit, which is a module for controlling the service processing unit and the other service request unit in the virtual service
A simulator stored in a computer-readable recording medium, characterized in that it further has a. 8. The method of claim 7,
(B) During the execution of the simulation, and after the construction of the virtual system,
Receive the policy after the change of the other service request transmission policy;
sending a setting instruction according to the post-change policy to a service control receiving unit in a virtual service having another service request unit to be changed according to the post-change policy
run on the computer,
The service control receiving unit receiving the instruction,
Temporarily stop the service processing unit in the virtual service having the service control receiving unit;
During the temporary suspension, setting according to the instruction is performed for other service request units in the virtual service.
The simulator stored in a computer-readable recording medium, characterized in that. (A) Input the information of (a1), (a2) and (a3) below,
(a1) A system configuration describing the dependency relationship between each service in a service system comprising a plurality of services and in which the plurality of services cooperate to perform processing according to a request from an end user by sending and receiving requests between the services;
(a2) another service request transmission policy in which the following (a21) and (a22) are described for each of at least one service among the plurality of services;
(a21) a condition regarding the processing status that is at least one of the presence or absence of a failure in the service to which the request is sent because it is a dependent destination of the service and the processing speed;
(a22) A change in processing that is at least one of the processing contents after the change of the service and the destination of the request after the change, when it is said that the conditions are satisfied;
(a3) a request generation policy in which the contents of a request to be transmitted to the service system as the end user and a transmission rate of the request are described;
(B) A simulation of a system behavior that is a behavior of the service system when a request based on the request generation policy arrives at a transmission rate based on the request generation policy is performed in the system configuration and the other service request transmission policy run on the basis of
(C) outputting simulation result information, which is information indicating the system behavior as a result of executing the simulation
run it on your computer,
In the simulation of (B),
building a virtual system in which the service system is a virtualized system based on the system configuration and the other service request transmission policy;
sending a request of content conforming to the request generating policy to the virtual system as the end user at a transmission rate conforming to the request generating policy;
(B) During the execution of the simulation, and after the construction of the virtual system,
Accept the policy after the change of the request generation policy,
sending a request for content conforming to the policy after the change to the virtual system as the end user at a transmission rate conforming to the policy after the change;
A simulator stored in a computer-readable recording medium, characterized in that the computer is executed. (A) Input the information of (a1), (a2) and (a3) below,
(a1) A system configuration describing the dependency relationship between each service in a service system comprising a plurality of services and in which the plurality of services cooperate to perform processing according to a request from an end user by sending and receiving requests between the services;
(a2) another service request transmission policy in which the following (a21) and (a22) are described for each of at least one service among the plurality of services;
(a21) a condition regarding the processing status that is at least one of the presence or absence of a failure in the service to which the request is sent because it is a dependent destination of the service and the processing speed;
(a22) A change in processing that is at least one of the processing contents after the change of the service and the destination of the request after the change, when it is said that the conditions are satisfied;
(a3) a request generation policy in which the contents of a request to be transmitted to the service system as the end user and a transmission rate of the request are described;
(B) A simulation of system behavior, which is the behavior of the service system when a request based on the request generation policy arrives at a transmission rate based on the request generation policy, is performed in the system configuration and the other service request transmission policy run on the basis of
(C) outputting simulation result information, which is information indicating the system behavior as a result of executing the simulation
run it on your computer,
The one or more information elements included in the system configuration are information elements input via one or more UI (User Interface) for receiving input of information elements included in the system configuration,
The one or more UIs,
A first UI for receiving selection of one or more service templates from one or a plurality of service templates;
a second UI that displays one or more objects respectively corresponding to one or more service templates selected from the first UI and accepts designation of a dependency relationship of the one or more objects;
A third UI for receiving input of one or more values for a service template corresponding to the selected object among the one or more objects
including,
At least one of the plurality of services is a service based on a service template in which one or more values input through the third UI are set.
The simulator stored in a computer-readable recording medium, characterized in that. Information of (a1), (a2) and (a3) below;
(a1) A system configuration describing the dependency relationship between each service in a service system comprising a plurality of services and in which the plurality of services cooperate to perform processing according to a request from an end user by sending and receiving requests between the services;
(a2) another service request transmission policy in which the following (a21) and (a22) are described for each of at least one service among the plurality of services;
(a21) a condition regarding the processing status that is at least one of the presence or absence of a failure in the service to which the request is sent because it is a dependent destination of the service and the processing speed;
(a22) A change in processing that is at least one of the processing contents after the change of the service and the destination of the request after the change, when it is said that the conditions are satisfied;
(a3) Request generation policy describing the contents of a request to be transmitted to the service system as the end user and the transmission rate of the request
a memory unit storing
(A) input the system configuration, the other service request transmission policy, and the request creation policy;
(B) A simulation of a system behavior that is a behavior of the service system when a request based on the request generation policy arrives at a transmission rate based on the request generation policy is performed in the system configuration and the other service request transmission policy run on the basis of
(C) outputting simulation result information, which is information indicating the system behavior as a result of executing the simulation
Simulation unit that executes processing
to provide
During the execution of the simulation of the simulation unit (B),
Receive a policy after changing at least one of the other service request transmission policy and the request creation policy;
The policy after the change is reflected without stopping the simulation,
According to the policy after the reflection, the simulation continues.
simulation device. (A) Input the information of (a1), (a2) and (a3) below,
(a1) A system configuration describing the dependency relationship between each service in a service system comprising a plurality of services and in which the plurality of services cooperate to perform processing according to a request from an end user by sending and receiving requests between the services;
(a2) another service request transmission policy in which the following (a21) and (a22) are described for each of at least one service among the plurality of services;
(a21) a condition regarding the processing status that is at least one of the presence or absence of a failure in the service to which the request is sent because it is a dependent destination of the service and the processing speed;
(a22) A change in processing that is at least one of the processing contents after the change of the service and the destination of the request after the change, when it is said that the conditions are satisfied;
(a3) a request generation policy in which the contents of a request to be transmitted to the service system as the end user and a transmission rate of the request are described;
(B) A simulation of a system behavior that is a behavior of the service system when a request based on the request generation policy arrives at a transmission rate based on the request generation policy is performed in the system configuration and the other service request transmission policy run on the basis of
(C) outputting simulation result information that is information indicating the system behavior as a result of executing the simulation;
During the execution of the simulation in (B),
Receive a policy after changing at least one of the other service request transmission policy and the request creation policy;
The policy after the change is reflected without stopping the simulation,
According to the policy after the reflection, the simulation continues.
simulation method.

Images