Computer system and method for calculating metrics

Abstract

To calculate a matrix for controlling the scaling of a system in which an application, which executes event-driven parallel distributed processing, operates.SOLUTION: A computer system connects with: an execution environment system, which provides an instance for executing an application; and an auto-scaling system, which controls the scaling of the instance. At least one application, which executes event-driven parallel distributed processing, operates on the execution environment system. The computer system acquires, as an application matrix, information regarding the number of retained events and the processing time of the events in the application, from the execution environment system, and the auto-scaling system calculates a determination matrix used for determining whether instance scaling needs to be executed on the basis of the application matrix.SELECTED DRAWING: Figure 6

Description

Technical Field

[0001] The present invention relates to an auto-scaling technique for a system in which an application that performs event-driven parallel and distributed processing operates.

Background Art

[0002] As containerization, which implements an application as a container, becomes widespread, container orchestration tools such as Kubernetes (k8s) and container orchestration services such as Amazon ECS (Elastic Container Service) have become widespread in order to reduce the operation load of containers arranged on a plurality of servers.

[0003] For example, k8s manages a node corresponding to a physical / virtual machine, a pod corresponding to a logical host, and a container executed on the pod as components, and an application is executed on the container. At this time, a group of node machines for executing a containerized application is called a cluster.

[0004] By utilizing container orchestration, automation of container management and operation such as container life and death monitoring, automatic recovery in case of failure, and auto-scaling becomes possible. In auto-scaling, when a value (metric) indicating the load status of a starting container exceeds a threshold, container orchestration can dynamically add (scale out) pods / nodes for executing the required number of containers to reduce the load. Also, in auto-scaling, when the metric falls below the threshold, container orchestration can dynamically stop (scale in) pods / nodes according to the number of containers required to maintain performance. As a result, the system can be stably operated using minimal resources.

[0005] Furthermore, managed container services, which utilize external instances instead of requiring companies to prepare their own instances (physical / virtual machines) for container implementation, are also becoming popular. With managed container services, containers can be created and applications run on instances managed by the cloud provider, and management of instance security measures, OS (Operating System) and various package version upgrades is unnecessary. However, a disadvantage of managed container services is that they are billed on a pay-as-you-go basis, so the cost increases if the number of containers used and the usage time are high.

[0006] To reduce both operational and financial costs, there is a growing trend to combine container orchestration services with managed container services.

[0007] For example, in the case of Kubernetes (k8s), scaling using a Horizontal Pod Autoscaler (HPA) and a metrics server deployed in the container is well known. Specifically, the metrics server acquires metrics such as CPU usage and memory usage from the pods, sends them to the HPA, and the HPA compares the metrics with thresholds to calculate the number of pods required to run the container and performs horizontal scaling. This makes it possible to reduce monetary costs while maintaining performance.

[0008] CPU usage and memory usage are known as standard metrics. Standard metrics are effective for controlling scaling in cases where the container itself can be executed in parallel and CPU usage and memory usage increase linearly.

[0009] On the other hand, when implementing business logic into an application, a single request may trigger multiple different internal processes, resulting in event-driven parallel and distributed processing. This can involve complex parallel and distributed processing, such as a process responding to one event waiting for another to complete, or generating another event. In applications with complex, internally branching parallel and distributed processing, standard metrics obtained from pods cannot accurately estimate the application's load, making appropriate scaling impossible. For example, if CPU usage is low but a large number of processes are accumulating while waiting for event processing, pod scaling is necessary, but this cannot be addressed using standard metrics.

[0010] Patent documents 1 and 2 are known as techniques for scaling applications that perform parallel and distributed processing by capturing load fluctuations.

[0011] Patent Document 1 states that "an information processing device includes a receiving unit that receives a notification from a terminal device indicating a predetermined operational timing prior to using a service on the terminal device, and a scaler that performs service scaling based on the notification."

[0012] Patent Document 2 describes that "the number of messages to be processed that are pending in the message queue is obtained, and if the number of messages exceeds the first scale-out threshold and the number of messages increases by more than a predetermined number, or if the number of messages exceeds the second scale-out threshold, a scale-out is performed. Also, if the number of messages falls below the first scale-in threshold and the number of messages decreases by more than a predetermined number, or if the number of messages falls below the second scale-in threshold, a scale-in is performed." [Prior art documents] [Patent Documents]

[0013] [Patent Document 1] Japanese Patent Publication No. 2018-128866 [Patent Document 2] Japanese Patent Publication No. 2017-162059 [Overview of the project] [Problems that the invention aims to solve]

[0014] Patent Document 1 discloses a system that obtains notifications from the routing table storage unit of a load balancer indicating predetermined operation timings in the preceding stage in order to capture sudden fluctuations in load, and determines whether or not to scale out or scale in. However, it does not disclose scaling that determines the load status including the processing time corresponding to each event for parallel distributed processing for each event.

[0015] Patent Document 2 discloses a system for scaling parallel message processing using the number of messages in a message queue as a determining factor. However, it does not disclose scaling when there are multiple types of messages (events) and there is variation in the processing time corresponding to each message.

[0016] Furthermore, Patent Documents 1 and 2, among others, do not mention methods for scaling parallel distributed processing applications in conjunction with external auto-scaling services.

[0017] The object of the present invention is to provide a system and method for calculating a determination metric that takes into account the processing load of an application, which is used to control the autoscaling of a system running an event-driven, parallel, and distributed processing application. [Means for solving the problem]

[0018] A typical example of the invention disclosed in this application is as follows. That is, a computer system including at least one computer, which is connected to an execution environment system that provides an instance for executing an application and an auto-scaling system that controls the scaling of the instance of the execution environment system. On the execution environment system, When a single request calls different processes, multiple events occur. At least one application that performs event-driven parallel and distributed processing is running. The at least one computer obtains, from the execution environment system, information regarding the number of event backlogs and the event processing time in the application as application metrics, For each type of event and calculates determination metrics used by the auto-scaling system to determine whether to perform scaling of the instance based on the application metrics, and transmits the determination metrics to the auto-scaling system. Recorded as history, and included in multiple such histories

Advantages of the Invention

[0019] According to the present disclosure, determination metrics considering the processing load of an application can be calculated. Problems, configurations, and effects other than those described above will be clarified by the description of the following embodiments.

Brief Description of the Drawings

[0020] [Figure 1] It is a diagram showing a configuration example of the IT system of Example 1. [Figure 2] It is a diagram showing an example of the configuration of a computer that realizes the server of Example 1. [Figure 3] It is a diagram showing an example of the functional configuration of the application execution server of Example 1. [Figure 4] It is a diagram showing an example of the functional configuration of the determination metric calculation server of Example 1. [Figure 5A] It is a diagram showing an example of the event history information included in the history DB of Example 1. [Figure 5B] ​It is a diagram showing an example of scaling history information included in the history DB of Example 1. [Figure 5C] It is a diagram showing an example of container number history information included in the history DB of Example 1. [Figure 5D] It is a diagram showing an example of determination metric history information included in the history DB of Example 1. [Figure 6] It is a diagram showing an example of cooperation between servers in the IT system of Example 1. [Figure 7] It is a diagram showing the processing flow in the IT system of Example 1. [Figure 8] It is a flowchart for explaining an example of determination metric generation processing executed by the determination metric calculation unit of Example 1. [Figure 9] It is a diagram showing an example of a screen displayed by the metric visualization unit of Example 1. [Figure 10] It is a diagram showing an example of the functional configuration of the determination metric calculation server of Example 2. [Figure 11] It is a diagram showing an example of cooperation between servers in the IT system of Example 2.

Embodiments for Carrying Out the Invention

[0021] Hereinafter, embodiments of the present invention will be described with reference to the drawings. However, the present invention is not to be construed as being limited to the description of the embodiments shown below. Those skilled in the art can easily understand that the specific configuration can be changed without departing from the spirit or gist of the present invention.

[0022] In the configuration of the invention described below, the same or similar configurations or functions are denoted by the same reference numerals, and duplicate descriptions are omitted.

[0023] Expressions such as "first", "second", "third", etc. in this specification and the like are attached to identify components and do not necessarily limit numbers or order.

[0024] The positions, sizes, shapes, and ranges of each component shown in the drawings, etc., may not represent the actual positions, sizes, shapes, and ranges, etc., in order to facilitate understanding of the invention. Therefore, the present invention is not limited to the positions, sizes, shapes, and ranges, etc., disclosed in the drawings, etc. [Examples]

[0025] Figure 1 shows an example of the configuration of the IT system in Example 1. Figure 2 shows an example of the configuration of the computer that implements the server in Example 1.

[0026] The IT system includes a decision metrics calculation server 100, an auto-scaling server 101, a load balancer 103, multiple application execution servers 104, and a database server 105. Each server is connected to the others via a network 106. The network 106 can be a LAN (Local Area Network), a WAN (Wide Area Network), the Internet, etc. The network connection method can be either wired or wireless. Furthermore, the network 106 can be a private network or a public network.

[0027] The application execution server 104 is a server that provides an instance for running application 311 (see Figure 3). The execution environment system 110 is composed of multiple application execution servers 104.

[0028] The load balancer 103 distributes requests to application 311. Application 311, running on application execution server 104, performs event-driven parallel distributed processing according to the received requests. Application execution server 104 accesses database server 105 as needed.

[0029] The auto-scaling server 101 is a server that implements an auto-scaling service that increases or decreases the number of application execution servers 104 based on the comparison results of the determination metrics and thresholds described later. For example, it is intended to utilize the horizontal scaling function of orchestration services such as Amazon EKS (Elastic Kubernetes Service). In this embodiment, the execution environment system 110 is the target of scaling by the auto-scaling server 101.

[0030] The judgment metric calculation server 100 calculates the judgment metrics used by the auto-scaling server 101.

[0031] The server of the IT system is implemented using, for example, a computer 200 as shown in Figure 2. The computer 200 has a processor 201, main memory 202, secondary memory 203, and a network interface 204. Each hardware element is connected to the others via a bus. The computer 200 may also have an input device that accepts input from the user and an output device that outputs data visible to the user. The input device is, for example, a keyboard, mouse, and touch panel, and the output device is, for example, a display and printer.

[0032] The processor 201 executes the program stored in the main memory 202. By executing processing according to the program, the processor 201 operates as a functional unit (module) that realizes a specific function. In the following description, when the processing is described with a functional unit as the subject, it indicates that the processor 201 is executing the program that realizes that functional unit.

[0033] Alternatively, an FPGA (Field Programmable Gate Array) or ASIC (Application Specific Integrated Circuit) may be used instead of processor 201. Furthermore, processor 201 may be used in combination with an FPGA or ASIC.

[0034] The main memory 202 is a high-speed storage device such as DRAM (Dynamic Random Access Memory) and stores the program executed by the processor 201 and the data used during program execution. The main memory 202 is also used as a work area. The computer 200 may also have ROM (Read Only Memory) to store the BIOS, etc.

[0035] The secondary storage device 203 is a high-capacity storage device such as an HDD (Hard Disk Drive) or SSD (Solid State Drive) that permanently stores data. The programs and data stored in the main memory 202 may also be stored in the secondary storage device 203. In this case, the processor 201 reads the programs and data from the secondary storage device 203 and loads them into the main memory 202.

[0036] The network interface 204 communicates with other devices over the network according to a predetermined protocol.

[0037] The server may be implemented using a virtual machine. Alternatively, the server may be implemented using a cloud service or a managed container service.

[0038] Figure 3 shows an example of the functional configuration of the application execution server 104 in Example 1.

[0039] The application execution server 104 can run multiple containers 300. In Figure 3, container 300-1 running application 311 and container 300-2 running event information collection agent 312 are running.

[0040] Application 311 runs on the parallel distributed processing infrastructure 310. Application 311 can communicate with other applications 311 via the parallel distributed processing infrastructure 310.

[0041] The parallel distributed processing infrastructure 310 stores pre-processing events and completed processing events in queues on the main memory 202 in order to distribute processing destinations, wait for processing, and record processing status before and after the execution of multiple event-responding processes that constitute the application 311. In addition, the parallel distributed processing infrastructure 310 can also use the event storage database 600 (see Figure 6) of the database server 105 to avoid event loss and accommodate a large number of events.

[0042] The event information collection agent 312 periodically obtains event-related information from the parallel distributed processing infrastructure 212, such as the number of events queuing (event retention) and event processing time, using an API (Application Program Interface) or CLI (Command Line Interface). Note that the event processing time does not necessarily have to be included in the information obtained from the parallel distributed processing infrastructure 212. In this case, the information includes a timestamp related to the event. The event processing time can be calculated using the aforementioned timestamp.

[0043] Figure 4 shows an example of the functional configuration of the judgment metric calculation server 100 in Example 1.

[0044] The judgment metrics calculation server 100 includes an interface unit 401, an event information acquisition unit 402, a container information acquisition unit 403, a judgment metrics calculation unit 404, a judgment metrics transmission unit 405, and a history management unit 406. The judgment metrics calculation server 100 also maintains a history DB 407.

[0045] History DB 407 is a database for managing various histories, and stores event history information 440, scaling history information 441, container count history information 442, and judgment metric history information 443.

[0046] Event history information 440 is information for managing the history of information related to events. Scaling history information 441 is information for managing the execution history of scaling by the auto-scaling server 101. Container count history information 442 is information for managing the history of the number of containers in the execution environment system 110. Judgment metric history information 443 is information for managing the history of judgment metrics.

[0047] The interface unit 401, event information acquisition unit 402, container information acquisition unit 403, judgment metric calculation unit 404, judgment metric transmission unit 405, and history management unit 406 are functional units that are realized by the processor 201 executing a program.

[0048] The interface unit 401 provides various interfaces. The interface unit 401 includes a metrics visualization unit 410 and an API 411 for acquiring data presented by the metrics visualization unit 410.

[0049] The event information acquisition unit 402 acquires information about events, including event processing time, and stores it in the event history information 440 of the history DB 407. The event information acquisition unit 402 includes an agent adapter 420 and a database adapter 421. The agent adapter 420 is an adapter for accessing the event information collection agent 312. The database adapter 421 is an adapter for accessing the database server 105.

[0050] The container information acquisition unit 403 acquires control logs from the auto-scaling server 101 and stores them in the scaling history information 441 in order to grasp information such as the number and execution status of containers 300 currently running in the execution environment system 110. It also executes status confirmation commands for containers 300 and stores the obtained information in the container count history information 442.

[0051] The judgment metric calculation unit 404 calculates the judgment metric using the current number of events pending, the event processing time, and the history DB 407, and registers it in the judgment metric history information 443 of the history DB 407. The judgment metric calculation unit 404 also instructs the judgment metric transmission unit 405 to transmit the judgment metric. The judgment metric calculation unit 404 implements the algorithm 430 for calculating the judgment metric.

[0052] The judgment metrics transmission unit 405 transmits judgment metrics to the auto-scaling server 101. The history management unit 406 controls access to the history DB 407 for each functional unit.

[0053] Furthermore, if necessary, a group of adapters used to acquire information may be added to the event information acquisition unit 402, or the adapters may be modified. Additionally, new information may be added to the history DB 407. The history DB 407 may be managed using an external database service such as the database server 105.

[0054] Figure 5A shows an example of event history information 440 included in the history DB 407 of Example 1.

[0055] Event history information 440 stores data 500 in JSON (JavaScript Object Notation) format, for example.

[0056] In data 500, "timestamp" represents the timestamp, "container ID" represents the container's identification information, "no. total events" represents the total number of events, "no. run events" represents the number of events currently running, and "no. unprocessed events" represents the number of unprocessed events.

[0057] Data 500 also includes information about pre-processing and post-processing. Specifically, "event type" represents the type of event, "no. total events" represents the total number of events, "no. run events" represents the number of events currently running, "no. unprocessed events" represents the number of unprocessed events, and "avg. proc. time (ms)" represents the average processing time (a statistical value of processing time).

[0058] Figure 5B shows an example of scaling history information 441 included in the history DB 407 of Example 1.

[0059] Scaling history information 441 stores an entry that includes sequence ID 511, container ID 512, operation type 513, request time 514, start time 515, end time 516, and number of unprocessed events 517. There is one entry for each control log. Note that the fields included in the entry are not limited to those described above. It may not include any of the fields described above, or it may include other fields.

[0060] Sequence ID 511 is a field that stores the identification information of the autoscaling task. Container ID 512 is a field that stores the identification information of the container 300 that will be autoscaled. Operation type 513 is a field that stores the type of autoscaling operation.

[0061] Request time 514 is a field that stores the time required for starting / stopping due to autoscaling. Start time 515 is a field that stores the start time of autoscaling. End time 516 is a field that stores the end time of autoscaling.

[0062] The number of unprocessed events, 517, is a field that stores the number of unprocessed events in the container 300 targeted for scaling in. This value is used to calculate the time required to process the unprocessed events in the container 300 targeted for scaling in, as well as the container downtime. When the container information acquisition unit 403 adds information to the scaling history information 441, it refers to the event history information 440 and reflects the total number of events in the data 500 with the timestamp closest to the current time in the number of unprocessed events, 517.

[0063] Figure 5C shows an example of container count history information 442 included in the history DB 407 of Example 1.

[0064] The container count history information 442 stores entries that include the timestamp 521, the total number of containers 522, the number of running containers 523, and the number of started containers 524. There is one entry for each log. Note that the fields included in the entry are not limited to those mentioned above. It may not include any of the fields mentioned above, or it may include other fields.

[0065] The timestamp field 521 stores the timestamp when the log was retrieved. The total number of containers field 522 stores the total number of containers 300 at the time the log was retrieved. The number of running containers field 523 stores the number of running containers 300. The number of running containers field 524 stores the number of running containers 300.

[0066] Figure 5D shows an example of the determination metric history information 443 included in the history DB 407 of Example 1.

[0067] The judgment metric history information 443 stores entries containing a timestamp 531 and judgment metric 532. There is one entry for each log. Note that the fields included in the entry are not limited to those mentioned above. It may not include any of the fields mentioned above, or it may include other fields.

[0068] The timestamp 531 is a field that stores the timestamp when the log was acquired. The judgment metric 532 is a field that stores the judgment metric calculated by the judgment metric calculation unit 404.

[0069] Furthermore, there are no limitations on the format of the data stored in the history DB407. For example, it could be in JSON format, CSV (Comma Separated Value) format, table format, or time-series database format.

[0070] Figure 6 shows an example of server-to-server communication in the IT system of Example 1. Figure 7 shows the processing flow in the IT system of Example 1.

[0071] The event information acquisition unit 402 of the judgment metrics calculation server 100 acquires data 500 containing information such as the number of events remaining and event processing time via the agent adapter 420 or the database adapter 421 (step S701) and stores it in the event history information 440 (step S702). The event information acquisition unit 402 acquires the number of events remaining and event processing time from the data 500 as application metrics.

[0072] The event information acquisition unit 402 sends an execution request to the determination metric calculation unit 404 that includes application metrics (number of events remaining and event processing time) as arguments (step S703).

[0073] The judgment metric calculation unit 404 performs the judgment metric calculation process using the application metrics and history DB 407 included in the execution request (step S704). Details of the judgment metric calculation process will be explained with reference to Figure 8.

[0074] The determination metric calculation unit 404 sends an execution request to the determination metric transmission unit 405 that includes the calculated determination metric as an argument (step S705).

[0075] The judgment metric transmission unit 405 transmits the judgment metrics to the auto-scaling server 101 (step S706).

[0076] The auto-scaling server 101 determines whether or not to perform scaling of the container 300 based on the determination metrics received from the determination metrics calculation server 100. If scaling is required, the auto-scaling server 101 performs scaling by starting or stopping the container 300.

[0077] The container information acquisition unit 403 of the judgment metrics calculation server 100 acquires the control log of the auto-scaling server 101 and stores it in the scaling history information 441. The container information acquisition unit 403 also acquires information regarding the number of containers 300 and their startup times in the execution environment system 110 and stores it in the container count history information 442.

[0078] The interface unit 401 of the judgment metric calculation server 100 displays a screen showing the relationships between application metrics, judgment metrics, and the number of containers, based on the history DB 407.

[0079] Figure 8 is a flowchart illustrating an example of the judgment metric generation process performed by the judgment metric calculation unit 404 of Example 1.

[0080] The judgment metrics calculation unit 404 obtains the application metrics included in the execution request (step S801). Subsequently, the judgment metrics calculation unit 404 executes processing according to algorithm 430. Algorithm 430 can be changed and updated as needed.

[0081] The judgment metric calculation unit 404 refers to the scaling history information 441 and calculates the average startup time of the container 300 (step S802). This calculation uses the control logs of the containers 300 that were started within a predetermined time from the current time.

[0082] The judgment metric calculation unit 404 calculates the predicted time N based on the average startup time of the container 300 (step S803). For example, the average startup time of the container 300 may be used directly as the predicted time N, or it may be calculated by multiplying the average startup time of the container 300 by a coefficient, or it may be calculated by adding a fixed value to the average startup time of the container 300.

[0083] The predicted time N is a value calculated from the time required to start container 300, and is used to predict the processing load of the application after container 300 has started.

[0084] In this way, the timing of the prediction can be dynamically changed by taking into account the execution status of the container 300 in the execution environment system 110. Therefore, it is possible to calculate judgment metrics that accurately estimate the processing load of application 311.

[0085] The judgment metric calculation unit 404 calculates the predicted number of containers 300 N seconds after the current time (step S804).

[0086] Specifically, the judgment metric calculation unit 404 calculates the value of the total number of containers, 522, in the latest log of the container count history information 442 as the predicted number of containers, 300, after N seconds.

[0087] The judgment metric calculation unit 404 uses the application metrics and the predicted number of containers 300 to calculate metrics for estimating the processing load of application 311 N seconds from the current time, as judgment metrics (step S805).

[0088] For example, the judgment metric calculation unit 404 calculates the ratio of the number of unprocessed events (event processing saturation) to the upper limit of the number of events processed in each container 300 after N seconds, based on the increase in the number of various event processing operations and the change in event processing time. In this case, the event processing saturation becomes the judgment metric. Note that the event processing saturation may be calculated as the sum of all containers, or it may be calculated using the value of the container with the most critical processing saturation.

[0089] As another example, the judgment metric calculation unit 404 can also consider event processing to be saturated if the increase in event processing time approaches or exceeds a predetermined threshold, and can apply further bias to the judgment metric or generate additional judgment metrics. In this way, the judgment metric calculation unit 404 performs calculations to generate one or more judgment metrics based on the information obtained.

[0090] Figure 9 shows an example of a screen displayed by the metrics visualization unit 410 of Example 1.

[0091] The metrics visualization unit 410 displays screen 900, including display fields 901 and 902, based on the history database 407.

[0092] Display area 901 shows the container 300 on which application 311 is running, the number of pending events for application 311 on each container 300, the average processing time for each event type, etc. Display area 901 may also show information on containers 300 that are running and stopped.

[0093] Display area 902 shows time-series graphs of the total number of events, average processing time for each event type, number of containers, and judgment metrics.

[0094] When you hover your cursor over a change in a time-series graph, detailed information about that change will be displayed. For example, if you hover your cursor over a change in the number of containers in a time-series graph, the number of containers added and the reason for scaling out will be displayed.

[0095] The time-series graph of the decision metrics displays both the decision metrics when scaling is not performed and when scaling is performed.

[0096] The data displayed in display fields 901 and 902 is updated manually or automatically. Display fields 901 and 902 may include selection fields for setting the update method, update frequency, etc.

[0097] According to Example 1, the judgment metric calculation server 100 can calculate judgment metrics that take into account the application's processing load based on event information such as the number of events remaining and the event processing time, and send them to the auto-scaling server 101. [Examples]

[0098] In Example 2, the difference from Example 1 is that the judgment metric calculation server 100 changes the control parameters of the auto-scaling server 101. Below, Example 2 will be described focusing on the differences from Example 1.

[0099] The configuration of the IT system in Example 2 is the same as that of Example 1. The functional configuration of the application execution server 104 in Example 2 is the same as that of Example 1.

[0100] Figure 10 shows an example of the functional configuration of the judgment metric calculation server 100 in Example 2. Figure 11 shows an example of server-to-server cooperation in the IT system of Example 2.

[0101] The judgment metric calculation server 100 includes a parameter generation unit 1000 and a parameter transmission unit 1001 as new functional units. In addition, the history DB 407 includes parameter history information 1010.

[0102] The parameter generation unit 1000 calculates the values ​​of the control parameters for the auto-scaling server 101. Here, the control parameters include the threshold of the judgment metric, the judgment period, and the time from scale-out to scale-in re-evaluation. For example, when the judgment metric calculation unit 404 uses the saturation level of event processing as the judgment metric, when the rate of increase in the saturation level of event processing over time increases, it sends an instruction to the parameter generation unit 1000 to shorten the scale-out re-evaluation time, and the parameter generation unit 1000 generates specific parameter values ​​to dynamically change the scale-in and scale-out behavior of the auto-scaling server 101.

[0103] The parameter generation unit 1000 registers the calculated control parameter values ​​in the parameter history information 1010. The parameter transmission unit 1001 transmits the calculated control parameter values ​​to the auto-scaling server 101.

[0104] In Figure 11, the execution environment system 110 and the database server 105 are omitted due to space limitations in the drawing. The judgment metric calculation unit 404 calculates the judgment metrics and then reads the parameter generation unit 1000. The parameter generation unit 1000 calculates the value of the control parameter (initial value or updated value). The parameter transmission unit 1001 transmits the calculated control parameter value to the auto-scaling server 101.

[0105] The metrics visualization unit 410 can display the values ​​of the control parameters by accessing the history DB 407.

[0106] It should be noted that the present invention is not limited to the embodiments described above, and various modifications are included. Furthermore, for example, the embodiments described above are detailed explanations of the configuration in order to clearly illustrate the present invention, and are not necessarily limited to those having all the configurations described. In addition, some of the configurations in each embodiment can be added to, deleted from, or replaced with other configurations.

[0107] Furthermore, each of the above-mentioned configurations, functions, processing units, processing means, etc., may be implemented in hardware, in whole or in part, for example, by designing them as integrated circuits. The present invention can also be implemented by software program code that realizes the functions of the embodiment. In this case, a storage medium on which the program code is recorded is provided to a computer, and the processor of that computer reads the program code stored in the storage medium. In this case, the program code read from the storage medium itself realizes the functions of the embodiment described above, and the program code itself and the storage medium on which it is stored constitute the present invention. Examples of storage media used to supply such program code include flexible disks, CD-ROMs, DVD-ROMs, hard disks, SSDs (Solid State Drives), optical disks, magneto-optical disks, CD-Rs, magnetic tapes, non-volatile memory cards, ROMs, and the like.

[0108] Furthermore, the program code that implements the functions described in this embodiment can be implemented in a wide range of programming or scripting languages, such as assembler, C / C++, Perl, Shell, PHP, Python, and Java (registered trademark).

[0109] Furthermore, the program code for the software that implements the functions of the embodiment may be distributed via a network and stored in a storage means such as a computer's hard disk or memory, or in a storage medium such as a CD-RW or CD-R, and the computer's processor may read and execute the program code stored in the storage means or storage medium.

[0110] In the above-described embodiment, the control lines and information lines shown are those deemed necessary for explanation and do not necessarily represent all control lines and information lines in the actual product. All components may be interconnected. [Explanation of symbols]

[0111] 100 Metrics calculation server for judgment 101 Auto-scaling servers 103 Load Balancer 104 Application Execution Server 105 Database Server 106 Network 110 Execution Environment System 200 calculator 201 Processor 202 Main storage 203 Secondary storage device 204 Network Interfaces 212 Parallel Distributed Processing Infrastructure 300 containers 310 Parallel Distributed Processing Infrastructure 311 Applications 312 Event Information Gathering Agent 401 Interface section 402 Event Information Acquisition Department 403 Container Information Acquisition Unit 404 Metrics calculation unit for judgment 405 Judgment Metric Transmission Unit 406 History Management Department 407 History DB 410 Metrics Visualization Department 411 API 420 Agent Adapter 421 Database Adapter 430 Algorithms 440 Event History Information 441 Scaling History Information 442 Container count history information 443 Metrics History Information for Judgment 500 data 600 Event Storage Databases 900 screens 1000 Parameter generation unit 1001 Parameter transmission unit 1010 Parameter History Information

Claims

1. A computer system comprising at least one computer, It connects to an execution environment system that provides instances for running an application, and an auto-scaling system that controls the scaling of the instances of the execution environment system, On the aforementioned execution environment system, multiple events occur that call different processes in response to a single request, and at least one application runs that performs event-driven parallel distributed processing. The aforementioned at least one computer is From the aforementioned execution environment system, information regarding the number of events lingering for each event type and the processing time of events in the application is obtained as application metrics and recorded as history. Based on the application metrics included in the multiple history records, the auto-scaling system calculates a determination metric to be used to determine whether or not scaling of the instance is necessary. A computing system characterized by transmitting the determination metrics to the auto-scaling system.

2. A computer system according to claim 1, The aforementioned at least one computer is Information regarding the startup of the instance of the execution environment system is obtained, and the average startup time of the instance is calculated. Based on the average startup time, the estimated time for estimating the number of instances is calculated. A computer system characterized by calculating a metric for evaluating the load of the application from the present time to the predicted target time, based on the number of instances on the execution environment system from the present time to the predicted target time, and the application metrics included in a plurality of histories, as the determination metric.

3. A computer system according to claim 1, The aforementioned at least one computer is After calculating the aforementioned determination metrics, the control parameters used by the auto-scaling system are calculated. A computer system characterized by transmitting data to the auto-scaling system.

4. A computer system according to claim 1, The aforementioned at least one computer is The control log of scaling by the auto-scaling system is obtained, Obtain the calculation log of the aforementioned judgment metric, A computer system characterized by generating and outputting display information for displaying the time progression of the aforementioned determination metrics and the number of instances.

5. A method for calculating metrics performed by a computer system including at least one computer, The aforementioned computer system is connected to an execution environment system that provides instances for running applications, and an auto-scaling system that controls the scaling of the instances of the execution environment system. On the aforementioned execution environment system, multiple events occur that call different processes in response to a single request, and at least one application runs that performs event-driven parallel distributed processing. The method for calculating the aforementioned metrics is: The first step involves at least one computer acquiring information from the execution environment system regarding the number of events remaining for each event type in the application and the processing time of the events, as application metrics, and recording this information as history. A second step in which at least one computer calculates a determination metric that the auto-scaling system uses to determine whether or not to perform scaling of the instance, based on the application metrics included in a plurality of histories, A method for calculating metrics, characterized by comprising a third step in which at least one computer transmits the determination metrics to the auto-scaling system.

6. A method for calculating metrics according to claim 5, The second step described above is: The steps include: the at least one computer obtaining information regarding the startup of the instance of the execution environment system and calculating the average startup time of the instance; The steps include: the at least one computer calculating a predicted time for estimating the number of instances based on the average startup time; A method for calculating metrics, characterized in that at least one computer calculates a metric for evaluating the load of the application from the present time to the predicted target time, based on the number of instances on the execution environment system from the present time to the predicted target time, and the application metrics included in a plurality of histories, as the determination metric.

7. A method for calculating metrics according to claim 5, The steps include: the at least one computer calculating the determination metrics, and then calculating the control parameters used by the auto-scaling system; A method for calculating metrics, characterized by comprising the step of transmitting data from at least one computer to the auto-scaling system.

8. A method for calculating metrics according to claim 5, The steps include: the at least one computer acquiring a control log of the scaling by the auto-scaling system; The steps include: the at least one computer obtaining a calculation log of the determination metric, A method for calculating metrics, characterized in that at least one computer generates and outputs display information for displaying the time progression of the determination metrics and the number of instances.

Images