Model management system, method, and program

Abstract

To efficiently manage a prediction model for evaluating the processing performance of software forming an application.SOLUTION: The present invention is directed to a model management system for managing a prediction model for predicting the processing performance of software forming an application at a deployment destination. The system has a model management table for storing a first common model which is a prediction model capable of being commonly used in prediction of processing performance of a software of the same kind, a data management table for storing first configuration information used for learning upon generation of the first common model and indicating configuration of the deployment destination of the software, a configuration comparison unit for extracting difference between a second configuration information indicating configuration of a deployment destination of target software to be predicted and the first configuration information, and a model generating unit for generating a prediction model by subjecting the first configuration information to learning using configuration information added with the difference to set the prediction model as a second common model as a new common model.SELECTED DRAWING: Figure 4

Description

[Technical Field]

[0001] The present disclosure relates to a technique for managing predictive models applied to software that constitutes an application. [Background technology]

[0002] Multi-cloud or hybrid cloud is a method of providing IT infrastructure that is realized by applications. In a multi-cloud or hybrid cloud, multiple environmental sites, including cloud environments, are combined and used. An application is made up of one or more pieces of software, and the application or each piece of software is deployed at the appropriate site. In this case, different types of sites, such as public cloud, private cloud, and on-premise, may be combined.

[0003] For example, a search application may consist of software that implements a web server and software that implements an SQL server that manages a database, and the application or each piece of software may be deployed on-premise or on a public cloud.Furthermore, a data collection application that collects IoT data to be stored in a database may be deployed on the edge.

[0004] In order for an application to meet its required processing performance (hereinafter also referred to as "required processing performance"), each piece of software must also meet its respective required processing performance. Processing performance is expressed, for example, in terms of execution time and throughput. Processing performance varies depending on the environment in which the application is deployed. An administrator who maintains and manages the information processing infrastructure including the application (hereinafter also referred to as "IT infrastructure administrator") deploys each piece of software for the application to a site with an appropriate environment that meets the required processing performance for each piece of software. For example, a container with an appropriate amount of resources is prepared for each piece of software, and each piece of software is deployed to that container. The amount of resources referred to here is, for example, the number of CPU cores or the amount of memory.

[0005] The processing performance obtained by a container varies depending on the amount of resources allocated to the container. Therefore, an IT infrastructure administrator predicts the processing performance that a container will exhibit using the amount of resources as a parameter, and determines where to deploy the software and the amount of resources for the container. The IT infrastructure administrator creates a prediction model (hereinafter simply referred to as a "model") that calculates a predicted value of processing performance using the amount of resources as an input parameter, and uses this prediction. The prediction model may be obtained, for example, by machine learning or deep learning, or may be a regression equation. The model is created individually for each application deployment destination and type of application based on configuration information that indicates the configuration of resources available at each site and operation information that indicates the operating status of resources when software was previously executed at that site.

[0006] Patent Document 1 discloses a technology that determines whether a query is data that can be used in public cloud resources or in private cloud resources, and selects whether to use the public cloud model or the private cloud model to process the query depending on the determination result. [Prior art documents] [Patent documents]

[0007] [Patent Document 1] US Patent Publication US2019 / 0377897 Summary of the Invention [Problem to be solved by the invention]

[0008] Over time, changes occur in the site environment, which can cause the model's prediction accuracy to decline. Therefore, in order to manage the model so that it maintains high prediction accuracy, it is necessary to update the model as needed. Updating a model requires preparing or collecting new metric information and learning data, which requires time and cost.

[0009] As the number of applications and the scale of each application increase, the number of software components that make up the applications also increases, and the number of models applied to the software also increases. As the number of models increases, the labor and cost required to update those models also increases.

[0010] One object of the present disclosure is to provide a technology that enables efficient management of a prediction model for evaluating the processing performance of software that constitutes an application. [Means for solving the problem]

[0011] A model management system according to one aspect of the present disclosure is a model management system that manages predictive models that predict the processing performance of software that constitutes an application at a deployment destination, and includes: a model management table that stores a first common model, which is a predictive model that can be commonly used to predict the processing performance of software of the same type; a data management table that stores first configuration information that indicates the configuration of the deployment destination of the software that was used for learning when the first common model was created; second configuration information that indicates the configuration of the deployment destination of the target software that is the subject of prediction; a configuration comparison unit that extracts the difference from the first configuration information; and a model creation unit that creates a predictive model by learning using configuration information that takes the difference into account with the first configuration information, and designates the predictive model as a new common model, a second common model. [Effects of the Invention]

[0012] According to one aspect of the present disclosure, it is possible to efficiently manage a prediction model for evaluating the processing performance of software that constitutes an application. [Brief explanation of the drawings]

[0013] [Figure 1] FIG. 1 is a block diagram illustrating an example of the configuration of a hybrid cloud according to a first embodiment. [Figure 2] 1 is a block diagram showing an example of the internal configuration of an on-premise system according to a first embodiment; [Figure 3] 1 is a block diagram showing an example of the internal configuration of a pub club system according to a first embodiment; [Figure 4] 1 is a block diagram showing an example of the internal configuration of a management system according to a first embodiment; [Figure 5] FIG. 2 is a diagram illustrating an example of a configuration of an operational configuration information management table according to the first embodiment. [Figure 6] FIG. 3 is a diagram illustrating an example of a configuration of an application catalog management table according to the first embodiment. [Figure 7] FIG. 3 is a diagram illustrating an example of a configuration of a model management table according to the first embodiment. [Figure 8] FIG. 3 is a diagram illustrating an example of a configuration of a data management table according to the first embodiment. [Figure 9] FIG. 4 is a diagram illustrating an example of a configuration of a model update table according to the first exemplary embodiment. [Figure 10] FIG. 10 is a diagram illustrating an example of a configuration of a common model creation history management table according to the first exemplary embodiment. [Figure 11] FIG. 2 is a diagram showing an example of a screen configuration of an operation portal according to the first embodiment. [Figure 12] FIG. 2 is a diagram for explaining an outline of a prediction model assumed in the first embodiment. [Figure 13] FIG. 2 is a diagram for explaining an outline of an application assumed in the first embodiment. [Figure 14] FIG. 2 is a diagram for explaining an outline of a process relating to standardization of a prediction model according to the first embodiment. [Figure 15] 10 is a flowchart illustrating a series of processing steps related to standardization of a prediction model according to the first embodiment. [Figure 16] 10 is a flowchart illustrating an initial registration process of a common model according to the first embodiment. [Figure 17] 10 is a flowchart illustrating a model creation process to be applied to an application according to the first embodiment. [Figure 18] FIG. 10 is a diagram for explaining an outline of model standardization processing according to the second embodiment. [Figure 19] FIG. 10 is a diagram illustrating an example of a configuration of a model management table according to the second embodiment. [Figure 20] FIG. 10 is a diagram showing an example of a screen configuration of an operation portal according to the second embodiment. [Figure 21] 10 is a flowchart illustrating a series of steps in a process for standardizing a prediction model according to the second embodiment. [Figure 22] 10 is a flowchart illustrating a model registration process according to the second embodiment. [Figure 23]10 is a flowchart illustrating a model integration and elimination process according to the second embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0014] Hereinafter, an embodiment of the present invention will be described with reference to the drawings.

[0015] (First embodiment)

[0016] FIG. 1 is a block diagram illustrating an example of the configuration of a hybrid cloud according to the first embodiment.

[0017] 1, the hybrid cloud environment 110 includes an edge system 101, an on-premise system 102, a public cloud system 103, and a management system 104. Hereinafter, the on-premise system 102 may be referred to as the on-premise system 102, and the public cloud system 103 may be referred to as the pub-kura system 103.

[0018] The hybrid cloud environment 110 is a computing environment that combines computer systems at sites in multiple environments, including a cloud environment. In this embodiment, an edge system 101, an on-premise system 102, and a pubclub system 103 are combined. The edge system 101 is a computer system located near a user or device. The on-premise system 102 is a computer system that is managed by the user. The pubclub system 103 is a computer system provided on a public cloud.

[0019] Edge system 101, on-premise system 102, and pubg-club system 103 share a common basic configuration including a communication device 105, a LAN (Local Area Network) 106, a physical server 107, a SAN (Storage Area Network) 108, and a storage device 109. Communication device 105 is a device that enables physical server 107 to communicate with the outside world via WAN (Wide Area Network) 100. Physical server 107 is connected to communication device 105 via LAN 106. Physical server 107 is also connected to storage device 109 via SAN 108. Physical server 107 is a computer that executes software processing, and records data in and retrieves data from storage device 109 as the processing progresses.

[0020] The management system 104 is a computer system that manages the hybrid cloud environment 110, the applications implemented therein, and the software that makes up each application. An application is made up of one or more pieces of software. The management system 104 may be implemented in any environment.

[0021] Although a configuration is shown here in which there is one edge system 101, one on-premise system 102, and one pub club system 103, there may be multiple of any of them.

[0022] FIG. 2 is a block diagram showing an example of the internal configuration of the on-premise system 102 according to the first embodiment.

[0023] 2, in the on-premise system 102, the physical server 107 includes a central processing unit (CPU) 200, a chipset 201, a physical network interface card (NIC) 202, a host bus adapter (HBA) 203, and memory 204. An operating system (OS) 206 arranged in the memory 204 provides a container 205 in which an application 207 is deployed.

[0024] The CPU 200 is a processor that reads an application 207 (hereinafter also referred to as "app 207") from the memory 204 and executes the processing. The chipset 201 is a bridge circuit that interconnects the devices in the physical server 107. The physical NIC 202 is an interface card that enables a physical connection to the LAN 106. The HBA 203 is an interface card that provides a physical connection to realize communication with the storage device 109 via the SAN 108.

[0025] The storage device 109 has a storage controller 208 and a physical volume 209. The physical volume 209 is a physical storage area provided by a storage device such as a hard disk. The storage device 109 is equipped with multiple storage devices, and the storage controller 208 integrates the physical storage areas of these multiple storage devices and provides them as a logical storage area.

[0026] The edge system 101 also has an internal configuration similar to that of the on-premise system 102 shown in Figure 2. The edge system 101 is mainly used for purposes such as acquiring and storing IoT data from factories and the like.

[0027] FIG. 3 is a block diagram showing an example of the internal configuration of the pubclub system 103 according to the first embodiment.

[0028] 3, the pubclub system 103 differs from the on-premise system 102 in that a managed service 301 is placed on the OS 206. The managed service 301 is software that realizes a specific service provided by a cloud service provider in a public cloud environment.

[0029] A user can use this managed service 301 in his / her own application or as part of it.

[0030] FIG. 4 is a block diagram showing an example of the internal configuration of the management system 104 according to the first embodiment.

[0031] 4, the management system 104 includes, as software that runs on the OS 206, an operation portal 401, an information acquisition unit 402, an application deployment unit 404, a model update unit 406, and a model management unit 408. The information acquisition unit 402 includes an operational configuration information management table 403. The application deployment unit 404 includes an application catalog management table 405. The model update unit 406 includes a model update table 407. The model management unit 408 includes, as internal software, a model creation unit 409 and a configuration comparison unit 410, and includes a model management table 411, a data management table 412, and a common model creation history management table 413.

[0032] The operation portal 401 provides an operation screen for creating and updating a common model of the software that constitutes the application.

[0033] The information acquisition unit 402 acquires configuration information indicating the amount of physical or logical computer resources provided to software at each site (on-premise, public cloud, edge) in the hybrid cloud environment, and operation information indicating the operation of the computer, and registers the information in the operation configuration information management table 403. Sites in a hybrid cloud environment include on-premise systems, public cloud systems, edge systems, etc.

[0034] The operational configuration information management table 403 is a table in which configuration information indicating the amount of resources allocated to the application software running at each site, operational information such as CPU utilization rate due to software execution, and processing performance including application processing time and billing information are registered.

[0035] Configuration information is information that indicates the configuration of resources allocated to software, and can be obtained from deployment configuration information set in a manifest file or the like used when deploying software to a site. Operational information is information that indicates the degree of operation of resources allocated to software, and can be obtained, for example, using an OSS (Open Source Software) tool. Processing time is information that indicates the time required to execute a specified process. Processing time may be calculated by hooking communication between containers, or by measuring the time it takes for a result to be returned from an input. Billing information is information that indicates the amount charged for resource usage. The amount may be calculated from the amount of resources used and the fee structure, by obtaining a fee structure in advance that indicates the price for each resource amount.

[0036] The application deployment unit 404 deploys the application 207 or software to each site. When deploying the application or software on a container, a manifest file that serves as configuration information for the deployment may be created, and the deployment may be performed automatically using, for example, a general-purpose tool. Note that the destination to which the application 207 or software is deployed is not limited to a container, and may also be a virtual machine or a server (including a physical server and a server provided as a managed service).

[0037] The application catalog management table 405 is a table for registering a manifest file, a deployment tool, and an image storage destination. The application catalog management table 405 may be updated by creating a template in advance and determining the result of prediction using a prediction model.

[0038] The model update unit 406 updates the common model as necessary. For example, it acquires the operation information and configuration information used to learn the common model registered by the model creation unit 409, as well as the operation information and configuration information at each site, and checks whether any of the information has changed. If any of the information has changed, the model update unit 406 updates the common model by re-learning based on the operation information and configuration information at each site, and registers the new common model in the model update table 407.

[0039] The model update table 407 is a table that stores various information related to prediction models, including common models. For example, the model update table 407 registers the input information, output information, operation information used for learning, and configuration information of the prediction model for each software. The model update table 407 also allows the user to check whether a model is common using a commonization flag. A commonization flag of 1 indicates a common model that has been commonized through re-learning. A commonization flag of 0 indicates a newly registered prediction model that has not been applied anywhere.

[0040] The model management unit 408 creates, applies, and manages a common model to be applied to the application 207 .

[0041] Based on the results of the configuration comparison unit 410, the model creation unit 409 re-learns and creates a common model to be applied to the software that constitutes the application 207, and registers the created common model in the model management table 411. The model creation unit 409 also registers the re-learned content in the common model creation history management table 413. In the re-learning of the common model, if the difference resulting from the processing by the configuration comparison unit 410 is related to a resource, the model creation unit 409 responds by acquiring information (learning data) used for learning when the common model was created and narrowing down the learning data. Narrowing down the learning data is control based on the results of the processing by the configuration comparison unit 410 described above. Furthermore, if the difference resulting from the processing by the configuration comparison unit 410 is related to the managed service 301, the model creation unit 409 responds based on the common model in the on-premise system 102 and the creation history of that common model.

[0042] The configuration comparison unit 410 compares the configuration information of the site (on-premise system 102, public cloud system 103, edge system 101) where the application 207 is deployed with the configuration information of the site used when the common model was created, and extracts the differences in the configuration information.

[0043] The model management table 411 is a table for registering and managing the input information, output information, operation information used for learning, and configuration information of a prediction model for each of one or more pieces of software in a used application. Furthermore, in the model management table 411, a commonization flag indicates whether a prediction model is commonized. If the commonization flag is 1, a commonized model created by re-learning has been registered, and if the commonization flag is 0, it indicates that a newly registered prediction model (a model that is not applied anywhere) has been registered.

[0044] The data management table 412 is a table for registering and managing configuration information and operation information used when learning the common model.

[0045] The common model creation history management table 413 is a table for registering and managing the history of re-learning, new creation, update, etc. of the common model according to the deployment destination of the software.

[0046] The configuration of each table and the processing of each unit will be explained in detail below.

[0047] 5 is a diagram showing an example of the configuration of the operational configuration information management table 403 according to the first embodiment. The operational configuration information management table 403 records information about the configuration and operational status of each software of each application 207 deployed at each site. The configuration is information that was determined when the software was deployed. The operational status is information that may change, and the latest value is stored.

[0048] 5, the operational configuration information management table 403 records an acquisition date and time 500, a target site name 501, an application name in use 502, a software name in use 503, configuration information 504, operational information 509, and processing performance 514 in association with each other.

[0049] Acquisition date and time 500 indicates the date and time when the information was acquired. Target site name 501 indicates the name of the target site. Used application name 502 indicates the name of the application 207 deployed on the site. Used software name 503 indicates the name of each piece of software that makes up the application 207. Configuration information 504 is information indicating the configuration of the container in which the software is deployed, and includes the container ID 505, number of CPU cores 506, memory capacity 507, and data capacity 508 of the container. Operation information 509 is information indicating the operating status of the software in the container, and includes CPU usage rate 510, memory usage rate 511, data usage rate 512, and IO busy rate 513. Processing performance 514 is information indicating the processing performance of the software in the container, and includes average processing time 515 and charge (cost) 516.

[0050] 6 is a diagram showing an example of the configuration of the application catalog management table 405 according to the first embodiment. In the application catalog management table 405, catalog information for introducing each software of each application 207 into a site is registered.

[0051] Referring to FIG. 6, the application catalog management table 405 records, for each application 207, an application ID 600, a name of the application used 601, a name of the software used 602, a name of the installation site 603, a name of the deployment tool 604, a manifest ID 605, an image file ID 606, and an image storage location 607, all of which are associated with one another.

[0052] The application ID 600 is identification information for the application 207. The application name used 601 indicates the name of the application 207. The software name used 602 indicates the name of the software. The installation site name 603 indicates the name of the site where the software is installed. The deployment tool name 604 indicates the name of the deployment tool for deploying the software to the site. The manifest ID 605 is identification information for the software and the manifest file when deploying it to the site. The image file ID 606 is identification information for the image file used when the software is deployed to the site. The image storage location 607 indicates the storage location of the image file used when the software is deployed to the site.

[0053] 7 is a diagram showing an example of the configuration of the model management table 411 according to the first exemplary embodiment. In the model management table 411, information about each prediction model including the common model is recorded.

[0054] Referring to FIG. 7, the model management table 411 records a registration date and time 700, a model name 701, a common flag 702, an application name used 703, a software name used 704, input information 705, output information 709, and a model creation data ID 712 in association with each other.

[0055] The registration date and time 700 indicates the date and time when the prediction model was registered. The model name 701 indicates the name of the prediction model. The common flag 702 is a flag indicating whether the prediction model is a common model. The application name 703 indicates the name of the application 207 to which the prediction model is applied. The software name 704 indicates the name of the software to which the prediction model is applied. The input information 705 is information input as explanatory variables to the prediction model, and includes the number of CPU cores 706, memory capacity 707, and application-specific parameters 708. The application-specific parameters represent input information such as the number of input data items for the application 207, and multiple pieces of input information are assumed. The output information 709 is information output as a target variable from the prediction model, and includes processing time 710 and cost (fee) 711. The model creation data ID 712 is identification information for the data used when the prediction model was created, and includes operation information 713 and configuration information 714.

[0056] 8 is a diagram showing an example of the configuration of the data management table 412 according to the first embodiment. The data management table 412 records management information relating to the configuration information and operation information of each piece of software deployed at each site.

[0057] Referring to FIG. 8, the data management table 412 stores an acquisition date and time 800, a target site name 801, an application name 802, a software name 803, configuration information 804, and operation information 808 in association with each other.

[0058] Acquisition date and time 800 indicates the date and time when the information was acquired. Target site name 801, used application name 802, and used software name 803 indicate the names of the site, application 207, and software that are the subject of the information, respectively. Configuration information 804 is management information related to the configuration information, and includes data storage destination 805, data ID 806, and data name 807. Operation information 808 is management information related to the operation information, and includes data storage destination 809, data ID 810, and data name 811.

[0059] 9 is a diagram showing an example of the configuration of model update table 407 according to the first embodiment. Information about each updated prediction model is recorded in model update table 407. Referring to FIG. 9, the configuration of model update table 407 is the same as that of model management table 411 shown in FIG. 7.

[0060] 10 is a diagram showing an example of the configuration of the common model creation history management table 413 according to the first embodiment. In the common model creation history management table 413, information on each created common model is registered.

[0061] Referring to FIG. 10, the common model creation history management table 413 records, for each common model, the application name used 1000, software name used 1001, registration date and time 1002, deployment destination 1003, model name 1004, creation / update content ID 1005, detailed information 1006, and model creation data ID 1007.

[0062] The application name 1000 indicates the name of the application 207 to which the common model is applied. The software name 1001 indicates the name of the software to which the common model is applied. The registration date and time 1002 indicates the date and time when the common model was registered. The deployment destination 1003 indicates the site to which the software to which the common model is applied is deployed. The model name 1004 indicates the name of the common model. The creation / update content ID 1005 is information regarding the creation or update of the common model. For example, 0 indicates "new model creation," 1 indicates "model re-learned after resource changes," and 2 indicates "model re-learning (updated)." Detailed information 1006 is detailed information regarding the creation / update content of the common model. The model creation data ID 1007 is identification information for the data used when the prediction model was created, and includes identification information for each of the operation information 1008 and configuration information 1009.

[0063] FIG. 11 is a diagram showing an example of the screen configuration of the operation portal 401 according to the first embodiment. The management system 104 provides various user interfaces to the operator (IT infrastructure administrator) who operates the terminal 111 through the operation portal 401. A screen 1100 shown in FIG. 11 is an example. The screen 1100 is a screen on which the operator deploys a desired application to a desired site. The screen 1100 displays a list of selectable applications, a list of selectable sites, an Execute button, and a Cancel button. When an application and a site are selected and the Execute button is clicked, a message screen regarding the deployment is displayed as a pop-up. When the operator clicks the Yes button in response to the message screen, the deployment is actually executed.

[0064] In addition to the above, the operation portal 401 may display various screens in accordance with various processes. For example, the operation portal 401 may receive an instruction to execute a prediction of software processing performance using a prediction model and display a screen presenting the results.

[0065] Fig. 12 is a diagram for explaining an outline of the prediction model assumed in the first embodiment. Fig. 12 shows a graph showing the relationship between the number of CPU cores and the response time when the memory amount is fixed, and a graph showing the relationship between the memory amount and the response time when the number of CPU cores is fixed.

[0066] In this embodiment, it is assumed that there is a linear correlation between the amount of resources, such as the number of CPU cores and memory amount, allocated to the container to which software is deployed, and processing performance, such as the response time of software processing. Therefore, as shown in Figure 12, if the amount of memory is set to a fixed value, the relationship between the number of CPU cores and response time can be approximated by a straight line, and if the number of CPU cores is set to a fixed value, the relationship between the amount of memory and response time can also be approximated by a straight line. A prediction model is generated by determining, through learning, a linear regression equation in which configuration information, including resource amounts, is used as an explanatory variable and processing performance is used as a target variable.

[0067] FIG. 13 is a diagram for explaining an outline of the application 207 assumed in the first embodiment.

[0068] In this embodiment, the application 207 is assumed to be a search application as an example, and the search application is assumed to be configured with Web Server software and SQL Server software. As a deployment configuration for such an application 207, both the Web Server and the SQL Server can be deployed in a container built in the on-premise system 102. It is also possible to deploy the Web Server software in a container provided by the public cloud system 103, and use the managed service 301 provided by the public cloud provider as the SQL Server software.

[0069] When deciding what deployment configuration to adopt, a predictive model can be used to predict the software's processing performance and determine the appropriate environment (site) and amount of resources.

[0070] Fig. 14 is a diagram for explaining an overview of the process related to the standardization of prediction models according to the first embodiment. In conceptual diagram 1400 of Fig. 14, when a search application APP#3 is to be deployed to pubclub system 103, a prediction model that was created when search application APP#2, which has already been deployed to on-premise system 102, was deployed and that was registered as a common model is used to predict the processing performance of pubclub system 103, which is a candidate deployment destination for search application APP#3, and an appropriate amount of resources is determined based on the prediction results, followed by actual deployment. The conceptual diagram 1400 of Fig. 14 conceptually shows, with (1) to (7), the flow of a series of processes from the deployment of search application APP#3 to pubclub system 103. (1) The configuration comparison unit 410 acquires information on the applications 207 that have already been deployed and the applications 207 that are about to be deployed. (2) The configuration comparison unit 410 acquires information about a common model applied to an already deployed application 207 of the same type as the application 207 that is about to be deployed. (3) The configuration comparison unit 410 extracts the difference in configuration information between the application 207 to be deployed and an application 207 of the same type that has already been deployed. (4) The model creation unit 409 creates a common model for the pubclub system 103 by learning data that takes into account differences in configuration information. (5) The model creation unit 409 registers the created common model in the model management table 411. (6) The application deployment unit 404 uses the common model to predict the processing performance of the search application APP#3 on the pubclub system 103. (7) The application deployer 404 calculates the required resource amount based on the prediction result, and deploys each piece of software for APP#3 to a container that has secured that amount of resource.

[0071] This series of processes will be explained in more detail below.

[0072] FIG. 15 is a flowchart illustrating a series of processing steps related to the standardization of a prediction model according to the first exemplary embodiment.

[0073] In step 1500 , the information acquisition unit 402 periodically acquires the operational information and configuration information of each site, and updates the operational configuration information management table 403 .

[0074] When there is an instruction to execute deployment of the application 207 to be newly used (Yes in step 1051), in step 1502, the model management unit 408 determines whether the software that constitutes the application 207 has already been registered in the model management table 411. If the software that constitutes the application 207 has not already been registered in the model management table 411, the management system 104 executes an initial registration process for the common model in step 1503. The initial registration process for the common model is a process for initially registering a new common model. Details of the initial registration process for the common model will be described later using FIG. 16.

[0075] Next, in step 1504, the application deployment unit 404 obtains the common model of the application 207 from the model management unit 408, calculates the amount of resources to be allocated to the application 207 by applying the common model to the application 207, updates the amount of resources in a manifest file (hereinafter also referred to as deployment configuration information) that serves as setting information for the deployment configuration, deploys the application 207, and ends the process. The deployment configuration information may include configuration information for the application, information indicating to which site the software of the application is deployed, and which prediction model is applied to the software.

[0076] If, in step 1502, the software that constitutes the application 207 has already been registered in the model management table 411, then, in step 1505, the model management unit 408 acquires deployment configuration information tailored to the deployment destination of the application 207 to be used from the application deployment unit 404. The deployment configuration information tailored to the deployment destination of the application 207 to be used is deployment configuration information that sets the deployment destination to a site where the application 207 to be used is planned to be deployed. This deployment configuration information includes configuration information of the application 207 that is about to be deployed.

[0077] Next, in step 1506, the model management unit 408 acquires, from the model management table 411, the configuration information used when creating the common model of the application 207 to be used.

[0078] Furthermore, in step 1507, the model management unit 408 uses the configuration comparison unit 410 to extract the difference between the configuration information of the common model obtained in step 1506 and the configuration information included in the deployment configuration information obtained in step 1504, and in step 1508 determines whether there is a difference between the configuration information.

[0079] If there is a difference between the configuration information (Yes in step 1508), the model management unit 408 executes a model creation process to be applied to the application 207 in step 1509. The model creation process to be applied to the application 207 is a process to create a prediction model used to predict the processing performance of the software that constitutes the application 207. Details of the model creation process to be applied to the application 207 will be described later with reference to FIG.

[0080] If there is no difference between the two pieces of configuration information in step 1508 (No in step 1508) or when the processing of step 1509 is completed, the application deployment unit 404 obtains a common model of the application 207 to be used from the model management unit 408 in step 1510, calculates the amount of resources to be allocated to the application 207 by applying the common model to the application 207 to be used, and updates the resource amount in the deployment configuration information.

[0081] Furthermore, the application deploy unit 404 deploys the application 207 to be used, and then ends the process.

[0082] 16 is a flowchart for explaining the initial registration process of a common model according to the first embodiment, which shows in detail the process of step 1603 in FIG.

[0083] In step 1600 , the application deployment unit 404 deploys the application 207 to be initially registered to the on-premises system 102 .

[0084] The site where the application 207 is to be deployed is the Pubkura system 103, but at this stage it is first deployed to the on-premise system 102.

[0085] Next, in step 1601, the model creation unit 409 executes, as a test, the application 207 to be initially registered on the on-premise system 102, and stores data indicating the test execution results obtained from the test execution in a predetermined location. Management information for that data is registered in the data management table 412. The test execution involves measuring processing performance, such as processing time, while changing resource amounts, such as the number of CPU cores and memory amount.

[0086] Next, in step 1602, the model creation unit 409 performs learning using the test execution results as learning data, creates a common model for the application 207 to be initially registered, and registers the common model in the model management table 411. An example of the common model here is a regression equation. Furthermore, in step 1603, the model creation unit 409 registers the contents of the created common model in the common model creation history management table 413.

[0087] 17 is a flowchart for explaining the model creation process applied to the application 207 according to the first embodiment. This shows the process of step 1509 in FIG. 15 in detail.

[0088] In step 1700, the model creation unit 409 acquires, from the model management table 412, a common model that is applied to the software that constitutes the application 207. Next, in step 1701, the model creation unit 409 acquires, from the data management table 412, information that was used when the acquired common model was learned.

[0089] Next, in step 1702, the model creation unit 409 determines whether the application 207 to be deployed uses the managed service 301 in the pubclub system 103. Whether or not to use the managed service 301 may be determined by, for example, obtaining input of the decision from the operator via the operation portal 401. If it is determined that the managed service 301 will not be used (No in step 1702), in step 1703, the model creation unit 409 creates a prediction model by learning using the configuration information that takes into account the difference in the configuration information extracted in step 1507, and sets the prediction model as a common model.

[0090] Learning using configuration information that takes into account differences in the configuration information is not particularly limited, but may involve reflecting differences in resource amounts included in the configuration information in processing performance using a predetermined conversion formula. For example, conversion may be performed based on the assumption that doubling the number of CPU cores reduces processing time by half. Furthermore, for example, when creating a common model for predicting processing performance when software is deployed to the on-premise system 102 using the managed service 301 of the pubclub system 103, the resource amounts in the on-premise system 102 and the managed service 301 of the pubclub system 103 may be converted using a predetermined conversion formula and used for learning.

[0091] Furthermore, if the range of resource amounts in the configuration information used for learning when the existing common model was created is wider than the range of possible resource amounts in the deployment destination of the software to which the new common model is applied, the configuration information used for learning may be limited to the range of possible resource amounts in the deployment destination of the software to which the new common model is applied. The configuration information used for creating the existing common model may be narrowed down to only configuration information whose resource amount values ​​fall within the range of possible resource amounts in the deployment destination of the new software, and the narrowed down configuration information may be used for learning. Here, the model creation unit 409 narrows down the information used for learning by taking into account the difference in resource amounts corresponding to the difference in configuration information extracted in step 1507, performs re-learning using the narrowed down information, and the created prediction model is used as the common model.

[0092] If it is determined in step 1702 that the managed service 301 is to be used (Yes in step 1702), in step 1704, the model creation unit 409 obtains the common model associated with the software that constitutes the application 207 from the model management table 411.

[0093] Next, in step 1705 , the model creation unit 409 refers to the creation history of the common model in the common model creation history management table 413 , and calculates the usage frequency of the common model extracted in step 1704 .

[0094] Next, in step 1706, the model creation unit 409 selects one of the common models extracted in step 1704 based on its usage frequency, acquires information about the selected common model, and creates a prediction model by relearning the acquired information. The created prediction model is then used to create a common model for the managed service 301 in the application 207 to be deployed. Note that the reason for selecting a common model based on usage frequency is that, since a common model applicable to the software using the managed service 301 does not yet exist, a common model with a high usage frequency is used from among common models applied to software deployed in other environments (on-premises system 102). The usage frequency of a common model may also be weighted based on, for example, where the software to which the common model is applied is deployed or whether it was used to respond to changes in resource amounts. A common model for the managed service 301 is a prediction model for predicting the processing performance of the managed service 301, and is considered a common model.

[0095] After executing the processing of step 1703 or after executing the processing of step 1706, in step 1707, the model creation unit 409 registers the created common model in the model management table 411, and registers information used for relearning in the data management table 412. Furthermore, in step 1708, the model creation unit 409 registers the contents of the created common model in the common model creation history management table 413.

[0096] (Second embodiment)

[0097] The second embodiment differs from the first embodiment in that the management system 104 consolidates and updates the common model. The hybrid cloud configuration in the second embodiment is the same as that in the first embodiment shown in FIG. 1. The edge system 101, on-premise system 102, and pubg-club system 103 in the second embodiment are the same as those shown in FIG. 2 or FIG. 3. Furthermore, the management system 104 in the second embodiment has a basic configuration similar to that in the first embodiment shown in FIG. 4, but the processing it executes is different. Below, the differences between the first embodiment and the second embodiment will be mainly described.

[0098] Fig. 18 is a diagram for explaining an outline of the model standardization process according to the second embodiment. A conceptual diagram 1900 of Fig. 18 conceptually shows, with (1) to (9), a series of process flows including a consolidation process for consolidating multiple common models into one common model and an update process for learning and updating each common model with new information, for the common models applied to search applications APP#2 to APP#4 deployed in on-premise system 102 and pubg-club system 103. (1) The information acquisition unit 402 collects operation information and configuration information of the application 207 installed at each site. (2) The model management unit 408 acquires application information (operation information and configuration information) of each site from the information acquisition unit 402. (3) If an application 207 introduced to another site is newly registered, the model management unit 408 extracts its operation information and configuration information. Furthermore, if an existing common model can be applied to the software of the application, the model management unit 408 applies the existing common model. For example, if an existing common model has been applied to software of the same type, the existing common model can be applied to the new software. If an existing common model cannot be applied to the new software, the model management unit 408 performs new learning to generate a prediction model, and after confirming that the prediction model can provide sufficient prediction results, uses the new common model. (4) The model update unit 406 also acquires application information for each site. (5) The model update unit 406 receives a standardization instruction through an operation input to the operation portal. (6) The model update unit 406 acquires model information of each prediction model, including the existing common model, from the model management unit 408. The model information includes information on the software to which the prediction model is applied. (7) Based on the model information, the model update unit 406 extracts prediction models that can be applied to the target software and consolidates them into a common model. Consolidation into a common model means applying a common model to software to which a certain prediction model was originally applied, and abolishing the original prediction model. Furthermore, based on the model information, the model update unit 406 extracts software of the application 207 whose operation information or configuration information has changed, and updates the prediction model applied to that software. (8) The model update unit 406 notifies the model management unit 408 that the common model has been updated. (9) The model management unit 408 registers the updated common model based on the notification.

[0099] This series of processes will be explained in more detail below.

[0100] FIG. 19 is a diagram illustrating an example of the configuration of a model management table 411 according to the second embodiment. Referring to FIG. 19, the model management table 411 according to the second embodiment differs from the model management table 411 according to the first embodiment illustrated in FIG. 7 in that a policy 2000 is registered for each prediction model. The policy 2000 is a policy regarding the standardization of prediction models and is information specifying software and environments to which a prediction model can be applied. The policy 2000 includes a similar application 2001, performance information 2002, and configuration information match 2003. The similar application 2001 is information indicating whether software constituting the same type of application as the associated application is required for the prediction model to be applicable. The performance information 2002 is information indicating the extent to which the performance information of the associated application must differ in order for the prediction model to be applicable. The configuration information match 2003 is information indicating whether the configuration of the associated application must match in order for the prediction model to be applicable.

[0101] FIG. 20 is a diagram illustrating an example of a screen configuration of the operation portal 401 according to the second embodiment. A screen 2100 of the operation portal is a screen for accepting an operation to execute a common processing of a prediction model. The screen 2100 includes a display of a list of prediction models, a display of a list of applications 207, an execute button, a register button, and a message display area. From the display of the list of prediction models, it is possible to individually select prediction models to be subjected to the common processing. From the display of the list of applications 207, it is possible to collectively select prediction models that meet the conditions related to the application 207 and software to be applied as prediction models to be subjected to the common processing. Clicking the execute button executes the common processing of the prediction model. Clicking the register button registers the results of the common processing of the prediction model. In the message display area, messages to the operator are displayed in response to the acceptance of an operation, the execution of a process, etc.

[0102] FIG. 21 is a flowchart illustrating a series of steps in the process of standardizing a prediction model according to the second embodiment.

[0103] The management system 104 periodically repeats the processes of steps 2200 to 2204 until an operation instructing the execution of standardization is received at the operation portal 401. In step 2200, the information acquisition unit 402 periodically acquires operation information and configuration information for each site and updates the operation configuration information management table 403 based on the acquired information. In step 2201, the information acquisition unit 402 transmits the updated operation configuration information management table 403 to the model management unit 408. In step 2202, the model management unit 408 receives the operation configuration information management table 403 from the information acquisition unit 402 and extracts information about the applications 207 of each site from the operation configuration information management table 403. In step 2203, the model management unit 408 extracts applications 207 newly installed at another site, and if there are any applications 207 newly installed at another site, performs model registration processing for those applications 207. The model registration processing is processing for registering a predictive model to be applied to software for which a predictive model to be applied is not registered. The model registration process will be described in detail later with reference to FIG.

[0104] In step 2204, the management system 104 determines whether or not an instruction to execute the common processing of the prediction model has been accepted by the operation portal 401. If the instruction has not been accepted (No in step 2204), the management system 104 returns to step 2200 and repeats the processing.

[0105] When an instruction to execute the common processing of the predictive model is received at the operation portal 401 (Yes in step 2204), in step 2205, the model update unit 406 acquires the model management table 411 and the data management table 412 from the model management unit 408, and acquires the operational configuration information management table 403 from the information acquisition unit 402.

[0106] Next, in step 2206, the model update unit 406 performs model integration processing based on each model information registered in the model management table 411. The model integration processing is a processing for integrating into one common model applied to multiple software programs to which different prediction models are applied but to which the same common model can be applied, when there are multiple software programs to which different prediction models are applied. Details of the model integration processing will be described later with reference to FIG. 23.

[0107] Next, in step 2207, the model update unit 406 registers the results of the model consolidation processing in the model update table 407, and notifies the model management unit 408 and the operation portal 401. A screen presenting the results of the model consolidation processing to the operator is displayed in the operation portal 401. Also, in step 2208, the model management unit 408 updates the model management table 411 based on the results of the model consolidation processing notified by the model update unit 406, and ends the series of processes.

[0108] 22 is a flowchart for explaining the model registration process according to the second embodiment. This process is a detailed description of the process in step 2203 in FIG.

[0109] Step 2301 is processing corresponding to steps 2201 and 2202 in Fig. 21. In step 2301, the model management unit 408 extracts information about the applications 207 of each site from the operational configuration information management table 403 received from the information acquisition unit 402, and extracts applications 207 installed at other sites.

[0110] In step 2302, the model management unit 408 checks whether the information on the extracted application 207 is registered in the model management table 411, and in step 2303, determines whether the information on the application 207 is registered in the model management table 411. If the extracted application 207 is registered in the model management table 411, the model registration process ends.

[0111] If it is determined in step 2303 that the information of the application 207 is not registered in the model management table 411, then in step 2304, the model management unit 408 extracts information about the software (hereinafter also referred to as "used software") that constitutes the application (hereinafter also referred to as "used application") that is not registered from the operational configuration information management table 403.

[0112] Furthermore, in step 2305, the model management unit 408 checks whether a prediction model to be applied to software of the same type as the software to be used that constitutes the unregistered application to be used (hereinafter also referred to as "same type software") is registered in the model management table 411, and in step 2306, determines whether a prediction model to be applied to the same type of software is registered in the model management table 411. Note that although an example in which a prediction model to be applied to the same type of software is targeted has been shown here, as another example, a prediction model to be applied to software that satisfies policy 2000 may be targeted.

[0113] If the predictive model to be applied to the same type of software is registered in the model management table 411, the model management unit 408, in step 2307, obtains the operation information and configuration information of the software being used from the data management table 412. Furthermore, in step 2308, the model management unit 408 obtains from the model management table 411 the model creation data ID 712 indicating the information when the predictive model to be applied to the same type of software was created, and obtains from the data management table 412 the operation information and configuration information corresponding to that ID.

[0114] Next, in step 2309, the model management unit 408 combines the operation information and configuration information acquired in steps 2307 and 2308, respectively, and performs re-learning to create a new prediction model. The new prediction model created here can be applied to both the software being used and software of the same type. Therefore, the model management unit 408 confirms that by applying the new prediction model, desired information can be obtained for both the software being used and software of the same type. The desired information is an appropriate prediction result of processing performance using the prediction model. For example, the desired information is an appropriate predicted value for the amount of resources required.

[0115] In step 2310, the model management unit 408 determines whether or not the software in use and similar software and common models can be consolidated. If the desired information about the software in use and similar software can be obtained using the prediction model created in step 2309, it is determined that consolidation is possible. If the desired information about either the software in use or similar software or both cannot be obtained using the prediction model, it is determined that consolidation is not possible.

[0116] If it is determined that consolidation is possible (Yes in step 2310), the model management unit 408 registers in the model management table 411 in step 2312 that a new common model that is the same as the homogeneous model will be applied to the software in use. On the other hand, if it is determined that consolidation is not possible (No in step 2310), the model management unit 408 creates a new prediction model for the software in use and registers it in the model management table 411 in step 2311.

[0117] 23 is a flowchart for explaining the model consolidation processing according to the second embodiment. The model consolidation processing is processing for consolidating common models in response to instructions received by the operation portal 401. This processing is a detailed description of the processing of step 2206 in FIG. 21.

[0118] In step 2401 , the model update unit 406 extracts the model name 701 , the application name in use 703 , the software name in use 704 , and the common flag 702 from the model management table 411 acquired in step 2205 .

[0119] In step 2402, the model update unit 406 searches for software of the same type based on the information extracted in step 2401, and checks whether a common model is applied to the software of the same type that is found. In step 2403, the model update unit 406 determines whether a common model is applied to the software of the same type.

[0120] If a common model is not applied to the same type of software (No in step 2403), in step 2404, the model update unit 406 obtains from the model management table 411 the model creation data ID 712 used when creating the predictive model to be applied to each of the same type of software, and obtains from the data management table 412 the configuration information 804 and operation information 808 that match each of the IDs and integrates them.

[0121] Next, in step 2405, the model update unit 406 creates a prediction model that can be applied to the software by learning the configuration information 804 and operation information 808 integrated in step 2404. Furthermore, the created prediction model is applied to the software to confirm that appropriate prediction results are obtained. For example, an appropriate prediction result is an appropriate predicted value for the required resource amount.

[0122] Then, in step 2406, the model update unit 406 determines whether or not consolidation of prediction models is possible. If the prediction models created in step 2405 can obtain appropriate prediction results for software of the same type, it determines that consolidation is possible. If the prediction models cannot obtain appropriate prediction results for any of the software of the same type, it determines that consolidation is not possible. If it is determined that consolidation of prediction models is not possible (No in step 2406), the model update unit 406 ends the process without consolidating or consolidating the prediction models applied to the software of the same type.

[0123] In step 2403, if a common model is applied to software of the same type (Yes in step 2403), the model update unit 406 registers in the model update table 407 in step 2407 the common model applied to software of the same type to the software not registered in the model update table 407.

[0124] In step 2408, the model update unit 406 acquires the configuration information of each of the software of the same type from the operational configuration information management table 403.

[0125] In step 2409, the model update unit 406 extracts software that is of the same type and has a similar configuration but has different predictive models applied to it, and checks whether the predictive models applied to those software are common models by referring to the common flag 702 in the model management table 411.

[0126] In step 2410, the model update unit 406 determines whether or not it is possible to consolidate or eliminate predictive models. In step 2409, if the same common model is not applied to software of the same type and with similar configurations, it determines that it is possible to consolidate or eliminate predictive models applied to that software. In that case, it is possible to consolidate or eliminate predictive models by applying a common model applied to one of the software to that software. On the other hand, if the same common model has already been applied to software of the same type and with similar configurations, it determines that it is not possible to consolidate or eliminate predictive models applied to that software. If it is determined that it is not possible to consolidate or eliminate predictive models (No in step 2410), the model update unit 406 ends the process without consolidating or eliminating the predictive models applied to that software.

[0127] If it is determined in step 2406 that prediction models can be consolidated (Yes in step 2406), or if it is determined in step 2410 that prediction models can be consolidated (Yes in step 2410), the model update unit 406 registers the results of the consolidation of prediction models in the model update table 407 in step 2411, and notifies the model management unit 408 that new information has been registered in the model update table 407. In step 2412, the model management unit 408 updates the model management table 411 based on the model update table 407.

[0128] The above-described embodiment includes the following features, but the features included in the above-described embodiment are not limited to those described below.

[0129] (Item 1) A model management system that manages a prediction model that predicts processing performance at a deployment destination of software that constitutes an application, a model management table that stores a first common model, which is a prediction model that can be commonly used to predict the processing performance of software of the same type; a data management table that stores first configuration information that indicates a configuration of a target to which software is to be deployed and that was used for learning when the first common model was created; a configuration comparison unit that extracts a difference between second configuration information indicating a configuration of a deployment destination of target software that is a target of prediction and the first configuration information; a model creation unit that creates a prediction model by learning using configuration information that takes the difference into account with respect to the first configuration information, and sets the prediction model as a second common model that is a new common model; A model management system having

[0130] In this way, a common model that can be commonly used to predict the processing performance of similar software is prepared in advance, and a new common model is created taking into account the difference in configuration between the deployment destination when the common model was created and the deployment destination of the target software. Therefore, by standardizing the prediction model and appropriate learning that takes into account the difference, it is possible to efficiently manage the prediction model for evaluating the processing performance of software.

[0131] (Item 2) Item 1. The model management system according to item 1, The software whose processing performance was predicted by the first common model when the first common model was created is deployed on an on-premise computer; The target software is deployed to a computer in a public cloud.

[0132] (Item 3) Item 2. The model management system according to item 2, The prediction model is a regression equation that calculates a response variable that represents the processing performance of the arithmetic processing based on an explanatory variable related to the amount of resources provided for the arithmetic processing.

[0133] This allows the prediction of processing performance using a regression equation, so the basis for the prediction results is clear, and it is also possible to make predictions in areas where there is insufficient training data.

[0134] (Item 4) Item 3. The model management system according to item 3, the configuration comparison unit, when a range of resource amounts included in the first configuration information is wider than a possible range of resource amounts included in the second configuration information, limits the first configuration information to the range of resource amounts included in the second configuration information, and extracts a difference between the second configuration information and the limited first configuration information; The model creation unit creates the second common model based on the restricted first configuration information and a difference extracted by restricting the first configuration information.

[0135] According to this, by narrowing down the learning data to a required range and performing learning, it is possible to create a common model that can obtain high prediction accuracy within the required range.

[0136] (Item 5) Item 2. The model management system according to item 2, The public cloud computer provides a unique service, which is a unique computing service that is not provided by the on-premise computer, and when the target software is deployed on the public cloud using the unique service, The model creation unit creates a second common model that can be used to predict the processing performance of the target software on a public cloud computer using the specific service, based on a first common model that can be used to predict the processing performance of software of the same type as the target software on an on-premises computer.

[0137] This means that even when deploying target software using specific services of a public cloud, the common model can be created based on the on-premises common model.

[0138] (Item 6) Item 1. The model management system according to item 1, a model management unit that manages a prediction model including the common model created by the model creation unit in association with software whose processing performance is predicted by the prediction model; a model updating unit that, if a plurality of different prediction models are used to predict the processing performance of a plurality of software programs of the same type among the models managed by the model management unit, creates a new prediction model by relearning data used when the plurality of prediction models were created, and, if the new prediction model correctly predicts the processing performance of the plurality of software programs, sets the new prediction model as a common model for the plurality of software programs; It further has:

[0139] This makes it easier to manage prediction models by integrating and eliminating common models.

[0140] (Item 7) Item 6. The model management system according to item 6, If different common models are used to predict the processing performance of multiple pieces of software that are the same type and have the same deployment configuration and are managed by the model management unit, the model update unit selects one of the common models as the common model for the multiple pieces of software.

[0141] This makes it easier to manage prediction models by integrating and eliminating common models.

[0142] (Item 8) Item 1. The model management system according to item 1, When the common model is created, the software whose processing performance is predicted by the common model is deployed on a public cloud computer; The target software is deployed on an on-premise computer. The above-described embodiments of the present invention are merely illustrative examples of the present invention, and are not intended to limit the scope of the present invention to these embodiments alone. Those skilled in the art can implement the present invention in various other forms without departing from the scope of the present invention. [Explanation of symbols]

[0143] 101...Edge system, 102...On-premise system, 103...Public cloud system, 104...Management system, 105...Communication equipment, 106...LAN, 107...Physical server, 108...SAN, 109...Storage equipment, 110...Hybrid cloud environment, 200...CPU, 201...Chipset, 202...Physical NIC, 203...HBA, 204...Memory, 205...Container, 206...OS, 207...Application, 208...Storage controller, 209...Physical volume, 301...Managed service, 401...Operation portal, 402...Information acquisition unit, 403...Operation configuration information management table, 404...Application deployment unit, 405...Application catalog management table, 406...Model update unit, 407...Model update table, 408...Model management unit, 409...Model creation unit, 410...Configuration comparison unit, 411...Model management table, 412...Data management table, 413...Common model creation history management table, 500...Acquisition date and time, 501...Target site name, 502...Used application name, 503...Used software name, 504...Configuration information, 505...Container ID, 506...Number of CPU cores, 507...Memory capacity, 50 8...Data capacity, 509...Operation information, 510...CPU usage rate, 511...Memory usage rate, 512...Data usage rate, 513...IO busy rate, 514...Processing performance, 515...Average processing time, 516...Charge, 600...Application ID, 601...Application name used, 602...Software name used, 603...Installation site name, 604...Deployment tool name, 605...Manifest ID, 606...Image file ID, 607...Image storage location, 700...Registration date and time, 701...Model name, 702...Common flag, 703...Application name used, 704...Software name used, 705...Input information, 706... Number of CPU cores, 707...Memory capacity, 708...Application-specific parameters, 709...Output information, 710...Processing time, 712...Model creation data ID, 713...Operation information, 714...Configuration information, 800...Acquisition date and time, 801...Target site name, 802...Application name used, 803...Software name used, 804...Configuration information, 805...Data storage destination, 806...Data ID, 807...Data name, 808...Operation information, 809...Data storage destination, 810...Data ID, 811...Data name, 1000...Application name used, 1001...Software name used, 1002...Registration date and time, 1003...Deployment destination,1004...Model name, 1005...Creation / update content ID, 1006...Detailed information, 1007...Model creation data ID, 1008...Operation information, 1009...Configuration information, 1100...Screen, 1400...Conceptual diagram, 1900...Conceptual diagram, 2000...Policy, 2001...Similar applications, 2002...Operational information, 2003...Configuration information match, 2100...Screen,

Claims

1. A model management system that manages a prediction model that predicts processing performance at a deployment destination of software that constitutes an application, a model management table that stores a first common model that is a prediction model that can be commonly used to predict the processing performance of software of the same type; a data management table that stores first configuration information indicating a configuration of a target to which software is to be deployed, the first configuration information being used for learning when the first common model is created; a configuration comparison unit that extracts a difference between second configuration information indicating a configuration of a target software to be predicted and the first configuration information; a model creation unit that creates a prediction model by learning using configuration information in which the difference is added to the first configuration information, and sets the prediction model as a second common model that is a new common model; A model management system having

2. The software, the processing performance of which was predicted by the first common model when the first common model was created, is deployed on an on-premise computer; The target software is deployed on a public cloud computer; The model management system of claim 1 .

3. The prediction model is a regression equation for calculating a response variable representing a processing performance of the arithmetic processing based on an explanatory variable related to a resource amount of a resource provided for the arithmetic processing. The model management system according to claim 2 .

4. the configuration comparison unit, when a range of resource amounts included in the first configuration information is wider than a possible range of resource amounts included in the second configuration information, limits the first configuration information to the range of resource amounts included in the second configuration information, and extracts a difference between the second configuration information and the limited first configuration information; The model management system according to claim 3 , wherein the model creation unit creates the second common model based on the restricted first configuration information and a difference extracted by restricting the first configuration information.

5. The public cloud computer provides a unique service that is a unique computing service that is not provided by the on-premise computer, and when the target software is deployed on the public cloud using the unique service, The model creation unit creates a second common model that can be used to predict the processing performance of the target software using the specific service on a public cloud computer based on a first common model that can be used to predict the processing performance of software of the same type as the target software on an on-premise computer. The model management system according to claim 2 .

6. a model management unit that manages a prediction model including the common model created by the model creation unit in association with software whose processing performance is predicted by the prediction model; a model updating unit that, if different prediction models are used to predict the processing performance of multiple software programs of the same type among those managed by the model management unit, creates a new prediction model by re-learning data at the time when the multiple prediction models were created, and, if the new prediction model correctly predicts the processing performance of the multiple software programs, sets the new prediction model as a common model for the multiple software programs; Further comprising The model management system of claim 1 .

7. the model update unit, when different common models are used to predict the processing performance of a plurality of software programs that are the same type and have the same configuration as the deployed software programs managed by the model management unit, sets any one of the common models as the common model for the plurality of software programs; The model management system according to claim 6.

8. The software whose processing performance was predicted by the common model when the common model was created is deployed to a computer in a public cloud, The target software is deployed on an on-premise computer; The model management system of claim 1 .

9. A model management method for managing a prediction model that predicts processing performance of a target device for deploying software constituting an application, comprising: storing a first common model which is a prediction model that can be commonly used to predict the processing performance of software of the same type; storing first configuration information indicating a configuration of a target to which software is to be deployed, the first configuration information being used for learning when the first common model was created; extracting a difference between second configuration information indicating a configuration of a target software to be predicted and the first configuration information; creating a prediction model by learning using configuration information in which the difference is added to the first configuration information, and designating the prediction model as a second common model that is a new common model; This is a model management method that is implemented by a computer.

10. A model management program for managing a prediction model that predicts processing performance at a deployment destination of software constituting an application, storing a first common model which is a prediction model that can be commonly used to predict the processing performance of software of the same type; storing first configuration information indicating a configuration of a target to which software is to be deployed, the first configuration information being used for learning when the first common model was created; extracting a difference between second configuration information indicating a configuration of a target software to be predicted and the first configuration information; creating a prediction model by learning using configuration information in which the difference is added to the first configuration information, and designating the prediction model as a second common model that is a new common model; A model management program that allows a computer to carry out these tasks.

Images