Computer system, method for generating a deployment plan, and deployment control system

Abstract

To plan a deployment plan for an application in consideration of the activation method for serverless instances.SOLUTION: A computer system is coupled to a plurality of infrastructure systems configured to implement an environment for providing resources to instances forming an application. The computer system is configured to: receive a deployment plan generation request for the application which includes at least a serverless instance for which, as an activation method, either one of a warm start and a cold start is selectable; generate, based on a resource amount required for each instance, an allocation pattern which is a combination of environments of a deployment destination of each instance; generate an activation pattern which is a combination of the activation methods for each instance; plan an activation timing of the serverless instance for the activation pattern; and generate a deployment plan by combining the allocation pattern, the activation pattern, and the activation timing.SELECTED DRAWING: Figure 18

Description

Technical Field

[0001] The present invention relates to a technology for formulating a deployment plan for an application composed of a plurality of instances.

Background Art

[0002] In order to perform data analysis and the like, the introduction of multi-cloud, which constructs an environment by combining a plurality of cloud systems, is progressing. Also, serverless technology has been attracting attention. In serverless, for example, functions and triggers are registered in a cloud system, and when a trigger is detected, resources necessary for function execution are allocated, and the function is executed using the resources. Patent Document 1 is known as a technology for formulating a deployment plan for data, functions, tasks, etc. in multi-cloud.

[0003] Patent Document 1 describes inputting data related to a plurality of tasks included in a serverless workflow into a machine learning model to determine the timing for task execution and the cloud service provider that executes the task.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] Serverless instances usually have a low response because resources are allocated and startup is performed when a trigger is detected. In the following description, allocating resources and starting up when a trigger is detected is described as a cold start. Also, allocating resources constantly and starting up at the time of deployment is described as a warm start.

[0006] The response speed and cost of serverless instances differ depending on whether they are started using a warm start or a cold start. Therefore, the method of starting serverless instances is an important factor in planning the deployment of an application consisting of multiple instances. Conventional technologies do not take into account the method of starting serverless tasks when planning deployments.

[0007] This invention provides a technology for planning the deployment of applications (workflows) composed of regular and serverless instances, taking into account the method of launching serverless instances. [Means for solving the problem]

[0008] A typical example of the invention disclosed in this application is as follows: A computer system comprising at least one computer having a processor, a storage device connected to the processor, and a network interface connected to the processor, and connected to a plurality of infrastructure systems that realize an environment that provides resources to each of a plurality of instances constituting an application that executes processing, wherein the processor receives a request to generate a deployment plan for an application which includes at least one serverless instance that can select either a warm start, in which resources are allocated and the instance is started when it is deployed, or a cold start, in which resources are allocated and the instance is started when an execution trigger is detected, as a startup method, generates a placement pattern which is a combination of the deployment environment for each of the plurality of instances based on the amount of resources required for each of the plurality of instances, generates a startup pattern which is a combination of the startup method for each of the plurality of instances, plans the startup timing for at least one of the serverless instances for the startup pattern, generates a plurality of deployment plans by combining the placement pattern, the startup pattern, and the startup timing, and generates display information for displaying the plurality of deployment plans. [Effects of the Invention]

[0009] According to the present invention, a computer system can formulate and present an application deployment plan that takes into account the method of starting serverless instances. Other issues, configurations, and effects will be clarified by the following description of the embodiments. [Brief explanation of the drawing]

[0010] [Figure 1] This figure shows an example of the system configuration of Example 1. [Figure 2] This figure shows an example of the computer configuration in Example 1. [Figure 3] This diagram illustrates an example of the operational management information for the base system in Example 1. [Figure 4] This diagram illustrates an example of instance operation management information for Example 1. [Figure 5] This figure illustrates an example of startup time management information in Example 1. [Figure 6] This figure illustrates an example of resource quantity prediction model information for Example 1. [Figure 7] This figure illustrates an example of startup time prediction model information for Example 1. [Figure 8A] This diagram illustrates an example of a deployment plan database in Example 1. [Figure 8B] This diagram illustrates an example of a deployment plan database in Example 1. [Figure 8C] This diagram illustrates an example of a deployment plan database in Example 1. [Figure 8D] This diagram illustrates an example of a deployment plan database in Example 1. [Figure 8E] This diagram illustrates an example of a deployment plan database in Example 1. [Figure 9] This flowchart illustrates an example of the process for updating the underlying system operation management information performed by the deployment plan generation system in Example 1. [Figure 10] This flowchart illustrates an example of the instance operation management information update process performed by the deployment plan generation system in Example 1. [Figure 11] It is a flowchart for explaining an example of the update process of startup time management information executed by the deployment plan generation system of Example 1. [Figure 12] It is a flowchart for explaining an example of the update process of resource amount prediction model information executed by the deployment plan generation system of Example 1. [Figure 13] It is a flowchart for explaining an example of the update process of startup time prediction model information executed by the deployment plan generation system of Example 1. [Figure 14A] It is a sequence diagram for explaining the flow of the application deployment process in the system of Example 1. [Figure 14B] It is a sequence diagram for explaining the flow of the application deployment process in the system of Example 1. [Figure 15] It is a diagram showing an example of the screen displayed on the client PC of Example 1. [Figure 16] It is a diagram showing an example of the screen displayed on the client PC of Example 1. [Figure 17] It is a diagram showing an example of the screen displayed on the client PC of Example 1. [Figure 18] It is a flowchart for explaining an example of the deployment plan generation process executed by the deployment plan generation system of Example 1. [Figure 19] It is a flowchart for explaining an example of the deployment process executed by the deployment control system of Example 1. [Figure 20] It is a diagram showing an example of the startup management information transmitted by the deployment control system of Example 1. [Figure 21] It is a flowchart for explaining an example of the application call process by the base system of Example 1. [Figure 22] It is a diagram showing an example of the configuration of the system of Example 2. [Figure 23] It is a diagram showing an example of the application operation management information of Example 2. [Figure 24] It is a diagram showing an example of the screen displayed on the client PC of Example 2. [Modes for carrying out the invention]

[0011] The embodiments of the present invention will be described below with reference to the drawings. However, the present invention is not to be construed as being limited to the embodiments described below. It will be readily apparent to those skilled in the art that the specific configuration can be modified without departing from the spirit or intent of the present invention.

[0012] In the configuration of the invention described below, identical or similar components or functions are denoted by the same reference numerals, and redundant descriptions are omitted.

[0013] The designations "First," "Second," "Third," etc., used in this specification are for the purpose of identifying constituent elements and do not necessarily limit their number or order. [Examples]

[0014] Figure 1 shows an example of the system configuration of Example 1. Figure 2 shows an example of the computer configuration of Example 1.

[0015] The system of Example 1 consists of a deployment plan generation system 100, a client PC 101, an application catalog management system 102, a deployment control system 103, and multiple infrastructure systems (cloud systems) 104. The deployment plan generation system 100, client PC 101, application catalog management system 102, deployment control system 103, and multiple infrastructure systems 104 are connected to each other via a network such as a LAN (Local Area Network) and a WAN (Wide Area Network). The network connection method may be either wired or wireless.

[0016] Client PC 101 is a terminal operated by a user who utilizes an application that provides a specified service.

[0017] The base system 104 is a computing system that provides an environment for running instances that constitute applications that realize predetermined services.

[0018] The application catalog management system 102 manages application catalogs, which are information about applications.

[0019] The deployment plan generation system 100 generates a deployment plan for deploying instances that make up an application. Instances include, for example, functions, containers, and virtual machines.

[0020] The deployment control system 103 deploys instances to the environment based on a deployment plan formulated by the deployment plan generation system 100 and selected by the user.

[0021] Each of the deployment plan generation system 100, application catalog management system 102, deployment control system 103, and base system 104 consists of, for example, a computer 200 as shown in Figure 2.

[0022] Computer 200 includes a CPU 201, main memory 202, secondary memory 203, and a network interface 204. Each hardware element is connected to the others via a bus. Computer 200 may also have input devices such as a keyboard, mouse, and touch panel, and may also have output devices such as a display.

[0023] The CPU 201 executes the program stored in the main memory 202. The CPU 201 functions as a functional unit (module) by executing processing according to the program. In the following explanation, when the processing is described with the functional unit as the subject, it indicates that the CPU 201 is executing the program that realizes the functional unit.

[0024] The main memory 202 is a memory unit that stores the program executed by the CPU 201 and the information used by that program. The main memory 202 also includes a work area that the program uses temporarily.

[0025] The secondary storage device 203 is an HDD (Hard Disk Drive) or SSD (Solid State Drive), etc., and permanently stores a large amount of data. Programs and information stored in the main memory 202 may also be stored in the secondary storage device 203. In this case, the CPU 201 reads the programs and information from the secondary storage device 203 and loads them into the main memory 202.

[0026] The network interface 204 communicates with external devices via the network.

[0027] The deployment plan generation system 100 includes an environment candidate search unit 110, an information collection unit 111, and a prediction unit 112. The deployment plan generation system 100 also holds infrastructure system operation management information 120, instance operation management information 121, startup time management information 122, resource quantity prediction model information 123, startup time prediction model information 124, and a deployment plan DB 125.

[0028] The infrastructure system operation management information 120 is information for managing the operating status of the infrastructure system 104. The instance operation management information 121 is information for managing the operating status of instances. The startup time management information 122 is information for managing the startup time of instances. The resource quantity prediction model information 123 is information for managing a model for predicting the amount of resources required to deploy instances. The startup time prediction model information 124 is information for managing a model for predicting the startup time of instances. The deployment plan DB 125 is a database that stores information related to the deployment plan, including combinations of environments in which instances will be deployed.

[0029] The information gathering unit 111 collects various types of information. The prediction unit 112 uses resource quantity prediction model information 123 to predict the amount of resources required to deploy the instance, and uses startup time prediction model information 124 to predict the startup time of the instance. The environment candidate search unit 110 searches for combinations of environments to which the instance will be deployed and generates a deployment plan.

[0030] Furthermore, regarding the functional units of the deployment plan generation system 100, multiple functional units may be combined into one functional unit, or one functional unit may be divided into multiple functional units for each function. For example, the prediction unit 112 may be divided into a functional unit that predicts resource quantities and a functional unit that predicts startup time.

[0031] Figure 3 illustrates an example of the base system operation management information 120 in Example 1.

[0032] The infrastructure system operation management information 120 stores an entry that includes the infrastructure system ID 301, cluster ID 302, CPU information 303, memory information 304, and timestamp 305. There is one entry for each environment. 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.

[0033] The base system ID 301 is a field that stores the ID of the base system 104. The cluster ID 302 is a field that stores the ID of the cluster that makes up the environment. The base system 104 is configured with one or more clusters, and one environment is realized using one cluster.

[0034] CPU information 303 is a set of fields that store information about the CPUs owned by the cluster. CPU information 303 includes fields such as specifications, total quantity, and unallocated amount. Memory information 304 is a set of fields that store information about the memory owned by the cluster. Memory information 304 includes fields such as specifications, total amount, and unallocated amount. Note that entries may also include fields related to network bandwidth, etc.

[0035] The timestamp 305 is a field that stores the date and time the information corresponding to the entry was obtained.

[0036] Figure 4 is a diagram illustrating an example of instance operation management information 121 in Example 1.

[0037] The instance operation management information 121 stores an entry containing the application ID 401, instance ID 402, instance type 403, CPU information 404, memory information 405, and timestamp 406. There is one entry for each instance. 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.

[0038] Application ID 401 is a field that stores the application's ID. Instance ID 402 is a field that stores the ID of the instance that makes up the application. Instance Type 403 is a field that stores the type of instance. For example, functions, containers, and virtual machines are stored here.

[0039] In this embodiment, the startup method is determined according to the type of instance. For serverless instances such as functions, either a cold start or a warm start can be selected. A warm start means that resources are allocated and the instance is started at the time of deployment. A cold start means that the instance is not started at the time of deployment, but resources are allocated to the instance and it is started when a request is received.

[0040] CPU information 404 is a set of fields that store information about the instance's CPU usage. CPU information 404 includes fields such as allocation value, minimum usage, maximum usage, and average usage. Memory information 405 is a set of fields that store information about the instance's memory usage. Memory information 405 includes fields such as allocation amount, minimum usage, maximum usage, and average usage. Note that entries may also include fields related to network bandwidth, etc.

[0041] The timestamp 406 is a field that stores the date and time the information corresponding to the entry was obtained.

[0042] Figure 5 is a diagram illustrating an example of the startup time management information 122 in Example 1.

[0043] The startup time management information 122 stores an entry containing the application ID 501, instance ID 502, instance type 503, environment 504, resource 505, startup type 506, startup time 507, and timestamp 508. There is one entry for each instance. 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.

[0044] Application ID 501, Instance ID 502, and Instance Type 503 are the same fields as Application ID 401, Instance ID 402, and Instance Type 403.

[0045] Environment 504 is a field that stores the IDs of the underlying system 104 and cluster to which the instance is deployed. Resource 505 is a group of fields that store information about the resources allocated to the instance. Resource 505 includes fields such as CPU and memory.

[0046] The Startup Type 506 field stores the startup type of the instance. It can store either a warm start or a cold start. The Startup Time 507 field stores the time (startup time) from when the request is received until the instance is ready to process.

[0047] The timestamp 508 is a field that stores the date and time when the startup time was measured.

[0048] Figure 6 illustrates an example of resource quantity prediction model information 123 in Example 1.

[0049] The resource quantity prediction model information 123 stores an entry containing the application ID 601, instance ID 602, instance type 603, model 604, and timestamp 605. There is one entry for each instance. 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.

[0050] Application ID 601, Instance ID 602, and Instance Type 603 are the same fields as Application ID 401, Instance ID 402, and Instance Type 403.

[0051] Model 604 is a set of fields that store models for predicting the resource amount of each resource. Model 604 includes fields that store models for predicting the resource amounts of CPU, memory, etc.

[0052] The timestamp 605 is a field that stores the date and time the model was registered.

[0053] Figure 7 illustrates an example of the startup time prediction model information 124 in Example 1.

[0054] The startup time prediction model information 124 stores an entry containing the application ID 701, instance ID 702, instance type 703, model 704, and timestamp 705. There is one entry for each instance. 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.

[0055] Application ID 701, Instance ID 702, and Instance Type 703 are the same fields as Application ID 401, Instance ID 402, and Instance Type 403.

[0056] Model 704 is a set of fields that stores models for predicting instance startup times for each type of instance startup. Model 704 stores models for predicting cold start startup times and models for predicting warm start startup times.

[0057] The timestamp 705 is a field that stores the date and time the model was registered.

[0058] Figures 8A, 8B, 8C, 8D, and 8E illustrate an example of the deployment plan DB125 in Example 1.

[0059] The deployment plan DB125 includes predicted resource amount information 800, placement pattern information 810, startup pattern information 820, startup timing information 830, and deployment plan management information 840.

[0060] The predicted resource quantity information 800 shown in Figure 8A is information for managing the predicted amount of resources required for an instance. The predicted resource quantity information 800 stores an entry that includes the instance ID 801, instance type 802, and resource quantity 803. There is one entry for each instance. 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.

[0061] Instance ID 801 and instance type 802 are the same fields as instance ID 402 and instance type 403.

[0062] Resource Amount 803 is a field that stores the estimated amount of resources required for the instance. Resource Amount 803 stores the estimated amount of resources such as CPU and memory.

[0063] The deployment pattern information 810 shown in Figure 8B is information for managing deployment patterns that indicate the combination of environments to which each instance constituting the application is deployed. The deployment pattern information 810 stores entries that include the deployment pattern ID 811 and instance 812. There is one entry for each deployment pattern. Note that the fields included in an entry are not limited to those described above. It may not include any of the fields described above, or it may include other fields.

[0064] Deployment pattern ID 811 is a field that stores the ID of the deployment pattern. Instance 812 is a group of fields that store information about the environment to which each instance that makes up the application is deployed. Instance 812 has as many fields as there are instances that make up the application. The field stores a combination of the ID of the underlying system 104 and the cluster ID.

[0065] The startup pattern information 820 shown in Figure 8C is information for managing startup patterns that indicate combinations of startup types for each instance that makes up the application. The startup pattern information 820 stores entries that include startup pattern ID 821 and instance 822. There is one entry for each startup pattern. Note that the fields included in an entry are not limited to those described above. It may not include any of the fields described above, or it may include other fields.

[0066] The startup pattern ID 821 is a field that stores the startup pattern ID. Instance 822 is a group of fields that store the startup type of each instance that makes up the application. Instance 822 has as many fields as there are instances that make up the application. The field stores either a warm start or a cold start.

[0067] The startup timing information 830 shown in Figure 8D is information for managing the startup timing of instances for each startup pattern. The startup timing information 830 stores entries that include the startup timing ID 831, startup pattern ID 832, and startup timing 833. There is one entry for each startup timing. Note that the fields included in an entry are not limited to those described above. It may not include any of the fields described above, or it may include other fields.

[0068] The startup timing ID 831 is a field that stores the ID of the startup timing. The startup pattern ID 832 is a field that stores the ID of the startup pattern to which the startup timing is set. The startup timing 833 is a field that stores the startup timing of the instance for the startup pattern.

[0069] The deployment plan management information 840 shown in Figure 8E is information for managing the deployment plan for deploying instances that make up the application. The deployment plan management information 840 stores entries that include the deployment pattern ID 841, the startup pattern ID 842, the startup timing 843, the predicted processing time 844, the predicted startup time 845, the predicted cost 846, and the predicted power consumption 847. There is one entry for each deployment plan. 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.

[0070] In Example 1, the deployment plan is defined by a combination of deployment pattern, launch pattern, and launch timing.

[0071] The placement pattern ID 841, activation pattern ID 842, and activation timing 843 are the same fields as the placement pattern ID 811, activation pattern ID 821, and activation timing ID 831.

[0072] The predicted processing time 844 is a field that stores the predicted processing time of the application when an instance is deployed according to the deployment plan. The predicted startup time 845 is a field that stores the predicted startup time of a cold-start instance when an instance is deployed according to the deployment plan. The predicted cost 846 is a field that stores the predicted cost required to operate the application when an instance is deployed according to the deployment plan. The predicted power consumption 847 is a field that stores the predicted power consumption due to the operation of the application when an instance is deployed according to the deployment plan.

[0073] The predicted processing time (844), predicted startup time (845), predicted cost (846), and predicted power consumption (847) are performance indicators of the deployment plan.

[0074] Figure 9 is a flowchart illustrating an example of the update process for the underlying system operation management information 120 performed by the deployment plan generation system 100 of Example 1.

[0075] The information gathering unit 111 acquires operational information of the base system 104 from the base system 104 (step S101). For example, the information gathering unit 111 acquires operational information of the base system 104 from the base system 104 by sending an acquisition request. Alternatively, the base system 104 may periodically transmit operational information of the base system 104.

[0076] The operational information for the infrastructure system 104 includes the ID of the infrastructure system 104, the cluster ID, and resource information, among other things.

[0077] The information collection unit 111 updates the infrastructure system operation management information 120 based on the acquired operation information of the infrastructure system 104 (step S102). If there is no entry for the infrastructure system 104 from which the operation information was acquired in the infrastructure system operation management information 120, the information collection unit 111 adds an entry to the infrastructure system operation management information 120 and sets the value included in the operation information to the added entry. If there is an entry for the infrastructure system 104 from which the operation information was acquired in the infrastructure system operation management information 120, the information collection unit 111 overwrites the value included in the operation information to that entry.

[0078] Figure 10 is a flowchart illustrating an example of the update process for instance operation management information 121 performed by the deployment plan generation system 100 of Example 1.

[0079] The information gathering unit 111 obtains instance operation information from the base system 104 (step S201). For example, the information gathering unit 111 obtains operation information of instances deployed in the environment provided by the base system 104 by sending an acquisition request. The base system 104 may periodically send instance operation information. Alternatively, the base system 104 may send operation information when processing is performed by an instance.

[0080] Instance operational information includes the ID of the underlying system 104, the cluster ID, the application ID, the instance ID and type, and information regarding resource usage.

[0081] The information collection unit 111 updates the instance operation management information 121 based on the acquired instance operation information (step S202). If there is no entry for the instance from which operation information has been acquired in the instance operation management information 121, the information collection unit 111 adds an entry to the instance operation management information 121 and sets the value included in the operation information to the added entry. If there is an entry for the instance from which operation information has been acquired in the instance operation management information 121, the information collection unit 111 overwrites the value included in the operation information to that entry.

[0082] Figure 11 is a flowchart illustrating an example of the startup time management information 122 update process performed by the deployment plan generation system 100 of Example 1.

[0083] The information gathering unit 111 obtains instance startup process information from the base system 104 (step S301). For example, if the base system 104 executes the instance startup process, it transmits the instance startup process information.

[0084] The startup process information includes the application ID, instance ID and type, base system 104 ID, environment ID, amount of resources allocated to the instance, startup type, and startup time.

[0085] The information gathering unit 111 updates the startup time management information 122 based on the startup process information of the acquired instance (step S302). If there is no entry for the instance from which startup process information has been acquired in the startup time management information 122, the information gathering unit 111 adds an entry to the startup time management information 122 and sets the value included in the startup process information to the added entry. If there is an entry for the instance from which startup process information has been acquired in the startup time management information 122, the information gathering unit 111 overwrites the value included in the startup process information to that entry.

[0086] Figure 12 is a flowchart illustrating an example of the update process for resource quantity prediction model information 123 performed by the deployment plan generation system 100 of Example 1.

[0087] The prediction unit 112 refers to the instance operation management information 121 (step S401) and generates a resource quantity prediction model for each resource using information on the allocation amount of the instance's resources (step S402). For example, the model is generated using multivariate analysis, machine learning, etc. The present invention is not limited to the model generation method.

[0088] The prediction unit 112 updates the resource quantity prediction model information 123 based on the generation result of the resource quantity prediction model (step S403). If there is no instance entry in the resource quantity prediction model information 123, the prediction unit 112 adds an entry to the resource quantity prediction model information 123 and sets the ID and resource quantity prediction model, etc., for the entry. If there is an instance entry in the resource quantity prediction model information 123, the prediction unit 112 overwrites the model 604 of the entry with the generated resource quantity prediction model.

[0089] Figure 13 is a flowchart illustrating an example of the update process for startup time prediction model information 124 performed by the deployment plan generation system 100 of Example 1.

[0090] The prediction unit 112 refers to the startup time management information 122 (step S501) and generates an instance startup time prediction model using information about the instance startup time (step S502). For example, the model is generated using multivariate analysis, machine learning, etc. The present invention is not limited to the model generation method.

[0091] The prediction unit 112 updates the startup time prediction model information 124 based on the generation result of the startup time prediction model (step S503). If there is no instance entry in the startup time prediction model information 124, the prediction unit 112 adds an entry to the startup time prediction model information 124 and sets the ID and startup time prediction model, etc., for the entry. If there is an instance entry in the startup time prediction model information 124, the prediction unit 112 overwrites the model 704 of the entry with the generated startup time prediction model.

[0092] Figures 14A and 14B are sequence diagrams illustrating the application deployment process in the system of Example 1. Figures 15, 16, and 17 show examples of screens displayed on the client PC 101 of Example 1.

[0093] The client PC 101 operated by the user sends a request to the application catalog management system 102 to retrieve the list of applications (step S601).

[0094] When the application catalog management system 102 receives a request to retrieve an application list, it sends the application list to the client PC 101 (step S602). The application list contains information about the applications managed by the application catalog management system 102.

[0095] The user operating the client PC 101 refers to the application list and selects the application to use. The client PC 101 operated by the user sends an application retrieval request to the application catalog management system 102 to retrieve the application selected by the user (step S603).

[0096] When the application catalog management system 102 receives an application acquisition request, it sends the application to the client PC 101 (step S604).

[0097] The user's client PC 101 sends a deployment plan generation request to the deployment plan generation system 100 (step S605). The deployment plan generation request includes information about the application. It may also include information used to refine the deployment plan, such as KPIs.

[0098] The client PC 101 sends a deployment plan generation request via a screen 1500, for example, as shown in Figure 15. Screen 1500 includes an input box 1501, settings fields 1502, 1503, 1504, an execute button 1505, and a cancel button 1506.

[0099] Input box 1501 is a box for inputting files and other elements that constitute the application itself.

[0100] Setting fields 1502 and 1503 are fields for setting KPIs, which are evaluation metrics for the deployment plan. In this embodiment, at least one performance metric is selected as the KPI. The user enters information into either setting field 1502 or setting field 1503 by operating the radio buttons.

[0101] The settings section 1502 includes input boxes 1511 and 1512, and an add button 1513. Input box 1511 is for entering the type of KPI. Input box 1512 is for entering the target value of the KPI. The add button 1513 is for adding input boxes 1511 and 1512.

[0102] The settings section 1503 includes an input box 1514. Input box 1514 is for entering the phase. The phase represents the phase in which the application is deployed, such as the test phase and the production phase. For example, the user sets KPIs for each phase in advance using screen 1600, as shown in Figure 16.

[0103] Screen 1600 includes input boxes 1601, 1602, and 1603, an add button 1604, a register button 1605, and a cancel button 1606.

[0104] Input box 1601 is for entering the phase name. Input boxes 1602 and 1603 are the same as input boxes 1511 and 1512. Add button 1604 is the same as add button 1513.

[0105] The registration button 1605 is used to register the KPI settings for a phase. The cancel button 1606 is used to undo an operation.

[0106] Returning to the explanation of Figure 15, setting field 1504 is for setting constraints on the startup pattern. The user can specify one of the following startup patterns: a warm start only startup pattern, a cold start only startup pattern, or a startup pattern that mixes warm and cold starts. Setting field 1504 may also include a box for setting the number of instances to start in parallel (threshold).

[0107] The Execute button 1505 is an operation button for sending a deployment plan generation request. The Cancel button 1506 is a button for canceling the operation.

[0108] When the deployment plan generation system 100 receives a deployment plan generation request, it executes the deployment plan generation process (step S606). Details of the deployment plan generation process will be described later.

[0109] The deployment plan generation system 100 sends deployment plan display information to the client PC 101 as a result of the deployment plan generation process (step S607).

[0110] When client PC 101 receives deployment plan display information, it displays screen 1700 as shown in Figure 17. Screen 1700 includes table 1701, a deploy button 1702, and a cancel button 1703.

[0111] Table 1701 is a table that displays deployment plans. Table 1701 stores entries that include selection 1711, deployment pattern 1712, launch pattern 1713, launch timing 1714, predicted processing time 1715, predicted launch time 1716, predicted cost 1717, and predicted power consumption 1718. There is one entry for each deployment plan. Note that the fields included in an entry are not limited to those mentioned above. It may not include any of the fields mentioned above, or it may include other fields.

[0112] Selection 1711 is a field that stores boxes for selecting the deployment plan to adopt. Deployment Pattern 1712 is a field that stores combinations of environments to which the instances will be deployed. Launch Pattern 1713 is a field that stores combinations of launch types for the instances. Launch Timing 1714 is a field that stores information about the launch timing of the instances.

[0113] The predicted processing time 1715, predicted startup time 1716, predicted cost 1717, and predicted power consumption 1718 are the same fields as the predicted processing time 844, predicted startup time 845, predicted cost 846, and predicted power consumption 847.

[0114] The deploy button 1702 is used to submit an application deployment request. The cancel button 1703 is used to cancel an operation.

[0115] The user refers to table 1701, selects the deployment plan to adopt, and operates the deploy button 1702. The client PC 101 sends a deployment request to the deployment plan generation system 100, including the identification information and application of the selected deployment plan (step S610).

[0116] When the deployment plan generation system 100 receives a deployment request, it sends a deployment request to the deployment control system 103, which includes information about the selected deployment plan and the application (step S611). The deployment plan generation system 100 also deletes information about the unselected deployment plans from the deployment plan DB 125.

[0117] When the deployment control system 103 receives a deployment request, it deploys the instance to the environment of the underlying system 104 (step S612).

[0118] When the deployment control system 103 has completed the deployment of the instance to the base system 104, it sends a deployment completion notification to the client PC 101 (step S613).

[0119] After receiving the deployment completion notification, client PC 101 uses the application at a predetermined time (step S614).

[0120] Figure 18 is a flowchart illustrating an example of the deployment plan generation process performed by the deployment plan generation system 100 of Example 1.

[0121] First, the prediction unit 112 calculates the predicted resource amount for the instance using information about the application and resource amount prediction model information 123 (step S701). Based on the calculation results, the prediction unit 112 generates predicted resource amount information 800.

[0122] Next, the environment candidate search unit 110 generates instance placement patterns based on the predicted resource amount of the instances and the underlying system operation management information 120 (step S702). Specifically, the following processes are executed.

[0123] (S702-1) The environment candidate search unit 110 selects one instance.

[0124] (S702-2) The environment candidate search unit 110 refers to the base system operation management information 120 and identifies environments (base system 104 and clusters) to which the predicted resource amount of the selected instance can be allocated. The environment candidate search unit 110 stores data associating the instance with the identified environment in the work area.

[0125] (S702-3) The environment candidate search unit 110 determines whether processing has been completed for all instances. If processing has not been completed for all instances, the environment candidate search unit 110 returns to S702-1.

[0126] (S702-4) When processing is complete for all instances, the environment candidate search unit 110 generates a deployment pattern by combining the environments of each instance. Based on the generated results, the environment candidate search unit 110 generates deployment pattern information 810.

[0127] The above is a description of the process in step S702.

[0128] Next, the environment candidate search unit 110 generates an instance startup pattern (step S703). Specifically, the following processes are executed.

[0129] (S703-1) The environment candidate search unit 110 selects one instance.

[0130] (S703-2) The environment candidate search unit 110 identifies the startup type based on the type of the selected instance. For example, if the instance is a function, warm start and cold start are identified. The environment candidate search unit 110 stores data associating the instance with the identified startup type in the work area.

[0131] (S703-3) The environment candidate search unit 110 determines whether processing has been completed for all instances. If processing has not been completed for all instances, the environment candidate search unit 110 returns to S703-1.

[0132] (S703-4) When processing is complete for all instances, the environment candidate search unit 110 generates a startup pattern by combining the startup types of each instance. The environment candidate search unit 110 generates startup pattern information 820 based on the generation results. At this time, the environment candidate search unit 110 controls the startup pattern to be generated based on the information in the setting field 1504.

[0133] The above is a description of the process in step S703.

[0134] Next, the environment candidate search unit 110 starts loop processing of startup patterns (step S704). Specifically, the environment candidate search unit 110 selects one entry from the startup pattern information 820.

[0135] Next, the environment candidate search unit 110 plans the startup timing for the startup pattern (step S705).

[0136] For example, the environment candidate search unit 110 plans the startup timing so that the number of instances to be started in parallel is maximized. Also, if the number of instances to be started in parallel (threshold) is specified, the environment candidate search unit 110 plans the startup timing so that the number of instances to be started in parallel is greater than the threshold. For example, if the startup pattern includes three cold-start instances and the threshold is "1", a startup timing will be planned to start three or two instances in parallel. This reduces the number of startup timings that are planned. Therefore, the processing load can be reduced.

[0137] The environment candidate search unit 110 registers a combination of a startup pattern and a single startup timing in the startup timing information 830.

[0138] Next, the environment candidate search unit 110 generates a deployment plan by combining the placement pattern, startup pattern, and startup timing (step S706). The environment candidate search unit 110 registers the deployment plan in the deployment plan management information 840. At this point, the predicted processing time 844, predicted startup time 845, predicted cost 846, and predicted power consumption 847 are blank.

[0139] The environment candidate search unit 110 determines whether processing has been completed for all startup patterns (step S707).

[0140] If processing has not been completed for all startup patterns, the environment candidate search unit 110 returns to step S704.

[0141] Once processing is complete for all startup patterns, the environment candidate search unit 110 narrows down the deployment plan (step S708). Specifically, the following processes are executed.

[0142] (S708-1) The environment candidate search unit 110 instructs the prediction unit 112 to calculate predicted values ​​for performance indicators for each of the deployment plans.

[0143] (S708-2) The prediction unit 112 selects a deployment plan.

[0144] (S708-3) The prediction unit 112 uses the instance information and the startup time prediction model information 124 to calculate the predicted startup time for each instance included in the deployment plan. The prediction unit 112 also calculates the predicted processing time, predicted cost, and predicted power consumption based on the deployment plan. The predicted processing time can be calculated, for example, based on the application execution history. The predicted cost and predicted power consumption can be calculated based on the environment and resource amount of the deployment target. The prediction unit 112 sets the calculation results for the predicted processing time 844, predicted startup time 845, predicted cost 846, and predicted power consumption 847 of the entry corresponding to the deployment plan, and notifies the environment candidate search unit 110 of the completion of processing.

[0145] (S708-4) The environment candidate search unit 110 deletes deployment plans that do not meet the KPI from the deployment plan management information 840. For example, if processing time is specified as the KPI, the environment candidate search unit 110 determines whether the KPI is met based on the result of comparing the sum of the predicted processing time and predicted startup time with the target value of the KPI.

[0146] The above is a description of the process in step S708.

[0147] Next, the environment candidate search unit 110 generates deployment plan display information based on the deployment plan management information 840 (step S709).

[0148] Note that if the application does not include serverless instances, steps S703 through S707 will not be executed. In this case, the deployment pattern will be output as the deployment plan.

[0149] The environment candidate search unit 110 may sort the deployment plans based on the KPI values. In this case, if there is no difference in the KPIs for deployment plans with the same deployment pattern and startup pattern but different startup timings (number of parallel processes), the environment candidate search unit 110 may prioritize displaying the deployment plan with the smallest number of parallel processes.

[0150] The environment candidate search unit 110 in Example 1 not only plans combinations of environments to which instances will be deployed, but can also simultaneously plan the instance startup patterns and startup timings within those environments. This makes it possible to present a deployment plan that takes into account how serverless instances will be started.

[0151] Figure 19 is a flowchart illustrating an example of the deployment process performed by the deployment control system 103 of Example 1. Figure 20 is a diagram showing an example of the startup management information 2000 transmitted by the deployment control system 103 of Example 1.

[0152] The deployment control system 103 selects one instance to deploy based on the deployment plan (step S801).

[0153] The deployment control system 103 deploys the instance to the environment of a predetermined base system 104 based on the deployment plan (step S802).

[0154] The deployment control system 103 registers the startup management information 2000 with the underlying system 104 where the instance is deployed (step S803).

[0155] The startup management information 2000 is generated based on the startup pattern and startup timing included in the deployment plan. The startup management information 2000 stores entries including the application ID 2001, instance ID 2002, and startup timing 2003. Each entry corresponds to one instance.

[0156] Application ID 2001 and Instance ID 2002 are the same fields as Application ID 401 and Instance ID 402. Startup Timing 2003 is a field that stores information about the instance's startup timing. Note that Startup Timing 2003 is left blank for instances using a warm start.

[0157] The deployment control system 103 may also register information defining the instance execution flow along with the startup management information 2000.

[0158] The deployment control system 103 determines whether the deployment of all instances is complete (step S804). If the deployment of all instances is not complete, the deployment control system 103 returns to step S801.

[0159] Once all instances have been deployed, the deployment control system 103 terminates the deployment process.

[0160] Furthermore, the startup management information 2000 may be registered only in the underlying system 104 where the instance related to the startup timing is deployed.

[0161] Figure 21 is a flowchart illustrating an example of application call processing by the base system 104 of Example 1.

[0162] When the base system 104 receives a request for an instance (step S901), it refers to the startup management information 2000 to determine whether or not it is necessary to start other instances (step S902). In other words, it determines whether or not there are instances that need to be started when a request for an instance is received.

[0163] If it is not necessary to start any other instances, the underlying system 104 proceeds to step S904.

[0164] If it is necessary to start other instances, the infrastructure system 104 starts other instances based on the startup management information 2000 (step S903). After that, the infrastructure system 104 proceeds to step S904. For example, if other instances are deployed in the environment of its own infrastructure system 104, the infrastructure system 104 allocates resources to the other instances and starts them. If other instances are deployed in the environment of another infrastructure system 104, the infrastructure system 104 instructs the other infrastructure system 104 to start the instances.

[0165] In step S904, the underlying system 104 instructs the instance to execute processing for the received request (step S904).

[0166] By registering startup management information 2000 with the underlying system 104 when deploying an instance, the startup of the instance can be automated.

[0167] As described above, the deployment plan generation system 100 of Example 1 can formulate and present a deployment plan that takes into account the method of starting serverless instances. [Examples]

[0168] Example 2 describes a system for redeploying instances. Below, we will describe Example 2, focusing on the differences from Example 1.

[0169] Figure 22 shows an example of the system configuration of Example 2.

[0170] The system configuration of Example 2 is the same as that of Example 1. In Example 2, the configuration of the deployment plan generation system 100 is slightly different. The deployment plan generation system 100 in Example 2 holds application operation management information 126.

[0171] Figure 23 shows an example of application operation management information 126 in Example 2.

[0172] Application operation management information 126 is information for managing the operating status of an application. Application operation management information 126 stores entries that include application ID 2301, deployment pattern 2302, startup pattern 2303, startup timing 2304, processing time 2305, cost 2306, and power consumption 2307. There is one entry for each application. 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.

[0173] Application ID 2301 has the same fields as Application ID 401.

[0174] Deployment pattern 2302 is a field that stores the instance's deployment pattern. Launch pattern 2303 is a field that stores the instance's launch pattern. Launch timing 2304 is a field that stores information about the instance's launch timing.

[0175] Processing time 2305 is a field that stores the processing time of the application. Cost 2306 is a field that stores the cost required to operate the application. Power consumption 2307 is a field that stores the power consumption due to the operation of the application.

[0176] The information update process performed by the deployment plan generation system 100 in Example 2 (infrastructure system operation management information 120, instance operation management information 121, startup time management information 122, resource amount prediction model information 123, and startup time prediction model information 124) is the same as in Example 1. The application deployment process flow in Example 2 is the same as in Example 1. However, in Example 2, when the deployment plan generation system 100 receives a deployment request from the client PC 101 (step S610), it adds an entry to the application operation management information 126. Based on the selected deployment plan, the deployment plan generation system 100 sets values ​​for the application ID 2310, deployment pattern 2302, startup pattern 2303, and startup timing 2304 of the added entry.

[0177] The deployment plan generation process performed by the deployment plan generation system 100 in Example 2 is the same as in Example 1. The deployment process performed by the deployment control system 103 in Example 2 is the same as in Example 1. The application call process performed by the base system 104 in Example 2 is the same as in Example 1.

[0178] In Example 2, the information gathering unit 111 of the deployment plan generation system 100 acquires application operation information from the base system 104 and updates the application operation management information 126 based on the acquired information.

[0179] In Example 2, the client PC 101 sends a redeployment request to the deployment plan generation system 100 at any time. In this case, the deployment plan generation system 100 displays a screen on the client PC 101 as shown in Figure 24.

[0180] Screen 2400 includes an input box 2401, a display button 2402, a display field 2403, a settings field 2404, a settings field 2405, a settings field 2406, an execute button 2407, and a cancel button 2408.

[0181] Settings fields 2404, 2405, 2406, execute button 2407, and cancel button 2408 are identical to settings fields 1502, 1503, 1504, execute button 1505, and cancel button 1506.

[0182] Input box 2401 is a box for entering the application ID, etc. Display button 2402 is a button for displaying the application's operating status. Display field 2403 is a field for displaying the application's operating information.

[0183] When the display button 2402 is pressed, the deployment plan generation system 100 obtains the operation information of the specified application from the application operation management information 126 and sends it to the client PC 101. The client PC 101 displays the received application operation information in the display field 2403.

[0184] When the execute button 2407 is pressed, the deployment plan generation system 100 executes the deployment plan generation process. At this time, the previously adopted deployment plan is excluded from the display.

[0185] According to Example 2, the user can revise the deployment plan if the application's operational status deviates significantly from the prediction.

[0186] 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.

[0187] 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.

[0188] 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).

[0189] 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.

[0190] 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]

[0191] 100 Deployment Plan Generation System 101 Client PCs 102 Application Catalog Management System 103 Deployment Control System 104 Infrastructure Systems 110 Environmental Candidate Search Unit 111 Information Gathering Department 112 Prediction Section 120 Infrastructure System Operation Management Information 121 Instance Operation Management Information 122 Startup time management information 123 Resource Quantity Prediction Model Information 124 Startup Time Prediction Model Information 125 Deployment Plan DB 126 Application Operation Management Information 200 calculator 201 CPU 202 Main storage 203 Secondary storage device 204 Network Interfaces 800 Predicted Resource Volume Information 810 Placement Pattern Information 820 Startup Pattern Information 830 Startup timing information 2000 Boot management information 1500, 1600, 1700, 2400 screens

Claims

1. A computer system, A computer comprising at least one processor, a storage device connected to the processor, and a network interface connected to the processor, Connecting to multiple infrastructure systems that provide resources to each of the multiple instances that make up the application that executes the processing, The aforementioned processor, The system receives a request to generate a deployment plan for an application that includes at least one serverless instance capable of either a warm start (where resources are allocated and the instance is started at deployment time) or a cold start (where resources are allocated and the instance is started when an execution trigger is detected). Based on the amount of resources required for each of the multiple instances, a deployment pattern is generated which is a combination of the deployment environment for each of the multiple instances. A startup pattern is generated, which is a combination of the startup methods for each of the multiple instances. For the aforementioned startup pattern, the startup timing of at least one of the serverless instances is determined. Multiple deployment plans are generated by combining the aforementioned placement pattern, the aforementioned activation pattern, and the aforementioned activation timing. A computer system characterized by generating display information for displaying the aforementioned multiple deployment plans.

2. A computer system according to claim 1, The deployment plan generation request includes information regarding the constraints of the launch pattern, The computer system is characterized in that the processor generates the startup pattern based on information regarding the constraints of the startup pattern.

3. A computer system according to claim 2, The aforementioned application includes a plurality of the serverless instances, The deployment plan generation request includes a threshold for the number of parallel processes for starting the serverless instance that employs the cold start method. The computer system is characterized in that the processor devises a startup timing such that the number of parallel startup processes for the serverless instance employing the cold start becomes greater than the threshold.

4. A computer system according to claim 1, The deployment plan generation request includes target values ​​for evaluation metrics used to evaluate the deployment plan. The aforementioned processor, The value of the evaluation indicator for each of the multiple deployment plans is calculated, A computer system characterized by selecting a deployment plan to present based on the result of comparing the value of the evaluation indicator for each of the plurality of deployment plans with the target value.

5. A method for generating a deployment plan for multiple instances that constitute an application that performs processing, which is executed by a computer system, The aforementioned computer system, A computer comprising at least one processor, a storage device connected to the processor, and a network interface connected to the processor, Connects to multiple infrastructure systems that realize an environment that provides resources to each of the aforementioned multiple instances, The method for generating the aforementioned deployment plan is: The first step is that the computer receives a request to generate a deployment plan for the application, which includes at least one serverless instance that can select either a warm start, in which resources are allocated and the instance is started at deployment time, or a cold start, in which resources are allocated and the instance is started when an execution trigger is detected. The second step is for the computer to generate a deployment pattern, which is a combination of the deployment environments for each of the multiple instances, based on the amount of resources required for each of the multiple instances. A third step in which the computer generates a startup pattern which is a combination of the startup methods for each of the plurality of instances, The computer performs a fourth step of determining the startup timing of at least one serverless instance for the startup pattern, A fifth step in which the computer generates a plurality of deployment plans by combining the placement pattern, the startup pattern, and the startup timing, A method for generating a deployment plan, characterized in that the computer generates display information for displaying the plurality of deployment plans.

6. A method for generating a deployment plan according to claim 5, The deployment plan generation request includes information regarding the constraints of the launch pattern, A method for generating a deployment plan, characterized in that the third step includes the step of the computer generating the startup pattern based on information regarding the constraints of the startup pattern.

7. A method for generating a deployment plan according to claim 6, The aforementioned application includes a plurality of the serverless instances, The deployment plan generation request includes a threshold for the number of parallel processes for starting the serverless instance that employs the cold start method. The fifth step of the method for generating a deployment plan is characterized by including a step in which the computer devises a startup timing such that the number of parallel startup processes for the serverless instance employing the cold start becomes greater than the threshold.

8. A method for generating a deployment plan according to claim 5, The deployment plan generation request includes target values ​​for evaluation metrics used to evaluate the deployment plan. The sixth step described above is: The steps include: the computer calculating the value of the evaluation indicator for each of the plurality of deployment plans; A method for generating a deployment plan, characterized in that the computer selects a deployment plan to present based on the result of comparing the value of the evaluation indicator for each of the plurality of deployment plans with the target value.

Images