WO2021192268A1 - リソース管理装置、リソース管理方法、および、リソース管理プログラム - Google Patents

リソース管理装置、リソース管理方法、および、リソース管理プログラム Download PDF

Info

Publication number
WO2021192268A1
WO2021192268A1 PCT/JP2020/014210 JP2020014210W WO2021192268A1 WO 2021192268 A1 WO2021192268 A1 WO 2021192268A1 JP 2020014210 W JP2020014210 W JP 2020014210W WO 2021192268 A1 WO2021192268 A1 WO 2021192268A1
Authority
WO
WIPO (PCT)
Prior art keywords
design
resource management
resource
resources
application
Prior art date
Application number
PCT/JP2020/014210
Other languages
English (en)
French (fr)
Inventor
青木　大輔
克幸 長谷部
誠 神崎
優介 日下部
Original Assignee
日本電信電話株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日本電信電話株式会社 filed Critical 日本電信電話株式会社
Priority to PCT/JP2020/014210 priority Critical patent/WO2021192268A1/ja
Priority to BR112022018999A priority patent/BR112022018999A2/pt
Priority to EP20926535.4A priority patent/EP4130980A4/en
Priority to CA3176911A priority patent/CA3176911A1/en
Priority to AU2020437977A priority patent/AU2020437977A1/en
Priority to JP2022510367A priority patent/JP7405242B2/ja
Priority to US17/914,823 priority patent/US20230133543A1/en
Publication of WO2021192268A1 publication Critical patent/WO2021192268A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5038—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the execution order of a plurality of tasks, e.g. taking priority or time dependency constraints into consideration
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/20—Software design
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5055—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering software capabilities, i.e. software resources associated or available to the machine
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5077—Logical partitioning of resources; Management or configuration of virtualized resources
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/508—Monitor

Definitions

  • the present invention relates to a resource management device, a resource management method, and a resource management program.
  • Patent Document 1 states, "One different communication service published in the communication service API for each wholesale service provider in response to an order request for using the communication service from a terminal that provides communication to the user. It is a collective service construction device between business operators that collectively provides one or more of the above, and holds a catalog that describes the specifications of the wholesale service of communication and a cooperation rule that defines the cooperation of various communication services. When there is an order request for the use of a plurality of communication services from the terminal, the communication service API corresponding to the plurality of communication services requested for the order is collectively linked based on the retained catalog and the cooperation rule. Disclosed is a "business-to-business batch service construction device, which is characterized by having a batch construction function unit for constructing a cooperation service and providing the constructed cooperation service to the terminal".
  • multi-service A combination of multi-service, multi-domain, and multi-layer may be referred to as "triple multi" below.
  • the requirements that trigger the design of the system may be abstract, and there is no guarantee that the designed system is actually optimal. Also, due to changes in the external environment, there is no guarantee that a system designed for optimization will remain optimal. In addition, various findings may be obtained when the designed system is operated, and it may be found that there is room for optimization. Therefore, it is required to change the design of the system, but in the past, it was not easy to change the design of the system because it required a lot of labor and time.
  • the resource management device of the present invention has a determination unit that determines whether or not to change the design of the system that provides the service based on external information, and if the change is made, each of the multilayers.
  • a selection unit that selects a plurality of resources that can exchange data according to a data model that clearly shows the relationships between resources arranged in layers, and a selection unit for changing the design of the system using the selected resources. It is characterized by including a design unit for generating a blueprint and an orchestrator unit for executing orchestration according to the generated blueprint for a system whose design has been changed.
  • the multilayer is composed of a physical layer, a virtual layer, and an application layer.
  • the virtual layer exists above the physical layer, and the application layer exists above the virtual layer.
  • Resources for providing a plurality of types of services can be allocated to each of the physical layer, the virtual layer, and the application layer.
  • Resources placed in the application layer are sometimes called "applications".
  • the application may be abbreviated as "app”.
  • resources arranged in the physical layer may be referred to as "physical resources”.
  • Resources placed in a virtual layer may be called “virtual resources”. Physical resources and virtual resources may be collectively referred to as "infrastructure”.
  • the resource management device of the present embodiment is a device that manages resources for providing a plurality of types of services.
  • the resource management device 1 of the present embodiment includes an acquisition unit 11, an application selection unit 12, an infrastructure selection unit 13, a design unit 14, an orchestrator unit 15, and a determination unit 16. I have.
  • the resource management device 1 stores the catalog group d1, the data model group d2, the blueprint group d3, and the best practice group d4.
  • Various information including the catalog group d1, the data model group d2, the blueprint group d3, and the best practice group d4 are stored in a storage unit (not shown) included in the resource management device 1.
  • the acquisition unit 11 acquires a request from an external device.
  • the external device is, for example, a device such as an information terminal used by a user who uses a service and a console used by an operator who manages a network, but is not limited thereto. Requirements are, for example, those that require, build, or modify a system, and express, for example, business demands, but are not limited to.
  • the format of the request can be, for example, text, voice, or command, but is not limited to these.
  • the external device can be used as an external information source, and the acquisition unit 11 can acquire external information from the external information source.
  • External information includes, for example, alerts generated on the network by monitoring the system, system logs on the network, information posted on SNS (Social Networking Service), and information on weather and traffic, but is limited to these. Not done.
  • the request and the external information may be equated as a trigger of the process performed in the present embodiment, and the present embodiment does not distinguish between the request and the external information unless there are special circumstances.
  • the application selection unit 12 selects an application for satisfying the request acquired by the acquisition unit 11.
  • the application selection unit 12 can select an application by analyzing the request and extracting a predetermined catalog from the catalog group d1 based on the analysis result.
  • the technique itself for analyzing requirements is well known, and detailed description thereof will be omitted.
  • the catalog is a model of the process for providing the service, and one or more applications necessary for providing the service are specified.
  • the catalog itself is well known, and detailed description is omitted.
  • the application selection unit 12 can set the data pipeline used by the selected application.
  • a data pipeline is a data path from a data source (eg, infrastructure) to a data destination (eg, infrastructure).
  • the application selection unit 12 can set a data pipeline by a well-known pipeline process.
  • the data pipeline can be made to have a predetermined order in the data processing order by a software pipeline which is one of the pipeline processing, but the data pipeline is not limited to this.
  • the application selection unit 12 can select a best practice application.
  • the application selection unit 12 can select an application by selecting a best practice including an application for satisfying a request from the best practice group d4.
  • Best practices are a group of resources that have been confirmed to be optimized for performance above a given value with respect to the provision of a given service. Details of best practices will be described later.
  • the application selected by the application selection unit 12 may be a best practice application or a non-best practice application, but the application selection unit 12 preferentially selects the best practice infrastructure.
  • the infrastructure selection unit 13 selects the infrastructure for the application selected by the application selection unit 12.
  • the infrastructure selection unit 13 can refer to the data model group d2 and select an infrastructure having a relationship with the selected application according to a specific data model. Details of the data model will be described later.
  • the infrastructure selection unit 13 can select the best practice infrastructure.
  • the infrastructure selection unit 13 refers to the best practice group d4 and is capable of exchanging data with the application selected by the application selection unit 12, or an infrastructure capable of exchanging data with the infrastructure selected by the infrastructure selection unit 13. Can be selected.
  • the infrastructure selected by the infrastructure selection unit 13 may be a best-practice infrastructure or a non-best-practice infrastructure, but the infrastructure selection unit 13 preferentially selects the best-practice infrastructure.
  • the design unit 14 designs a system using the application selected by the application selection unit 12 and the infrastructure selected by the infrastructure selection unit 13. Specifically, the design unit 14 generates a blueprint.
  • a blueprint is system design information consisting of a group of resources that meet the requirements. The blueprint itself is well known and its detailed description will be omitted.
  • the design unit 14 can set parameters for generating a blueprint. The parameters include, but are not limited to, for example, the number of users who use the service, the IP address of the physical machine arranged in the physical layer, and the IP address of the virtual machine arranged in the virtual layer. The parameters themselves are well known and detailed description will be omitted.
  • the design unit 14 can change the design of the system in operation according to the determination result of the determination unit 16. Specifically, the system using the application reselected by the application selection unit 12 and the infrastructure reselected by the infrastructure selection unit 13 is designed. In addition, the design unit 14 generates a blueprint for changing the design of the system.
  • the orchestrator unit 15 executes orchestration on the system designed by the design unit 14 according to the blueprint generated by the design unit 14. Orchestration is the automatic control of service deployment, configuration, and management. The orchestration enables the provision of services. In addition, the orchestrator unit 15 can execute a system test.
  • the orchestrator unit 15 can execute the orchestration on the system whose design has been changed by the design unit 14 according to the blueprint generated by the design unit 14. In addition, the orchestrator unit 15 can execute a test of the redesigned system.
  • the determination unit 16 determines whether or not to change the system design based on external information.
  • the system to be judged can be a system that has completed orchestration and testing and has started operation, but is not limited to this. For example, it may be a system after design and before operation. In the present embodiment, the system to be determined will be described as a system that has started operation.
  • Catalog group d1 is a collection of catalogs.
  • the data model group d2 is a collection of data models.
  • the blueprint group d3 is an aggregate of blueprints. The blueprints generated by the design unit 14 are accumulated in the blueprint group d3.
  • the best practice group d4 is a collection of best practices.
  • the data model in this embodiment clearly shows the relationship between resources that exchange predetermined data.
  • the data model is represented by a relationship and a pair of two resources with that relationship.
  • the original data model explicitly determines the structure of data or structured data.
  • the present invention specifically uses the data model.
  • the data model is defined as showing the individual resources provided by services and the relationships between them, and can be used as a reference for the design of complex systems that combine multiple services. Therefore, a group of resources required to provide a plurality of services is specified.
  • the resources are classified into an application arranged in the application layer, a virtual resource arranged in the virtual layer, and a physical resource arranged in the physical layer. Therefore, as shown in FIG. 2, as a data model, there are a data model in which a relation is formed between the application r1 and the virtual resource r2, and a data model in which a relation is formed between the virtual resource r3 and the physical resource r4. These two data models are examples in which relationships are formed between resources placed between adjacent layers. Further, as shown in FIG. 2, as a data model, there are a data model in which a relation is formed with virtual resources r5 and r6 and a data model in which a relation is formed with physical resources r7 and r8. These two data models are examples of relationships formed between resources placed on the same layer. In addition, as a data model, there may be one in which a relation is formed between two applications.
  • the data model stipulates that predetermined data can be exchanged between the two specified resources, that is, a data flow is formed. Therefore, when the application selection unit 12 selects an application, the infrastructure selection unit 13 can select a virtual resource having a relationship with the selected application according to the data model, and data is exchanged. Further, the infrastructure selection unit 13 can select a physical resource or another virtual resource having a relationship with the selected virtual resource according to the data model, and data is exchanged. In addition, the infrastructure selection unit 13 can select other physical resources or virtual resources that have a relationship with the selected physical resource according to the data model, and data is exchanged.
  • the version of the application or virtual resource is appropriately upgraded according to, for example, a change in the type of resource used to provide a predetermined service, a change in the usage of the resource (user usage mode), and the like.
  • physical resources are provided, for example, as devices that follow new standards as appropriate.
  • the particle size of the management unit such as switching from server management to the processing devices that make up the server and memory management, has been reduced, and used equipment has been replaced with new equipment with enhanced performance. It will be replaced with a device whose data structure has been changed. In this way, resources are dynamically changing. Therefore, the data model also changes (updates) dynamically. Along with such a change, the data model group d2 is updated as appropriate.
  • the data model is prepared as a data model in which two resources have a relationship, but there are a plurality of data models in which one of the two resources having a relationship is common and the other is different. It may exist. In this case, depending on the data model, there may be a plurality of infrastructures having a relationship with the application selected by the application selection unit 12.
  • the infrastructure selection unit 13 can select one infrastructure using a predetermined priority (eg, SLA (Service Level Agreement), link cost, and other policies).
  • the resource management device 1 can manage a resource by associating the resource with the owner of the resource. Further, for each of the resources managed by the resource management device 1, a user who has the authority to use the resource is determined. The resource management device 1 can manage a resource by associating the resource with a user who has the authority to use the resource.
  • a tenant is prepared as a virtual network unit provided to a specific user group (example: 1 customer, 1 company).
  • One tenant can be prepared for one or more types of services. Therefore, one tenant can be assigned to a plurality of resources according to a predetermined rule.
  • the resource management device 1 can manage the resource by associating the resource with the tenant to which the resource belongs.
  • the infrastructure selection unit 13 can select an infrastructure group capable of exchanging data (data flow) only by referring to the relation between resources (apps, infrastructures).
  • the infrastructure group can be selected for the selected application regardless of which layer of the multi-layer the resource in charge of data flow belongs to.
  • the infrastructure group can be selected for the selected application regardless of which of the multi-service services the resource in charge of the data flow is for providing.
  • the domain in the design of the system that can support triple multi is related to the resource owner and tenant mentioned above.
  • the owner of the resource in the domain can be identified, and a tenant that can be identified with the domain can be prepared.
  • the infrastructure group for a specific application is selected by using the data model, it was selected regardless of which domain of the multi-domain the resource responsible for the data flow belongs to. You can select the infrastructure group for the app.
  • the data model can take a general-purpose data structure by abstracting the differences between domains, the differences between layers, and the differences between services, and the resources selected for the request. It is a useful means for optimizing.
  • best practices are a group of resources that have been confirmed to be optimized to perform above a predetermined level with respect to the provision of a predetermined service.
  • Performance above a predetermined value can be defined as, for example, that the throughput of exchanging data between resources constituting the best practice is equal to or higher than a predetermined value, but is not limited thereto.
  • the resource group that constitutes the best practice includes a resource group that includes resources that are arranged in different layers. That is, one that includes an application and a virtual resource, one that includes a virtual resource and a physical resource, and one that includes an application and a virtual resource and a physical resource.
  • the resource group that constitutes the best practice includes a resource group that includes resources that are arranged in the same layer. That is, one containing two or more applications, one containing two or more virtual resources, and one containing two or more physical resources.
  • the resource group that constitutes the best practice may be a resource group that has a relationship based on the data model, a resource group that does not have a relationship based on the data model, or a resource group group that has a relationship based on the data model. It may be a resource group including a resource subgroup having no relation by the data model. Based on past knowledge (actual results), regardless of whether or not there is a relationship between the resources that make up the best practice, the performance of data exchange between the resources that make up the best practice may exceed the specified level. It has been confirmed.
  • Best practices can be a subset of the resources that make up the entire system to provide a given service. That is, best practices can provide partial (local) optimal solutions for the entire system. Therefore, it is possible to design the entire system so that the entire system is optimized by collecting a plurality of best practices so that the data flow is continuous. That is, a best practice is a set of multiple partial best practices that provide a partial optimal solution for the entire system, and selections (12, 13) are multiple partial best practices for the entire system.
  • the design unit 14 generates a blueprint for designing the entire system using the selected resources of the plurality of partial best practices.
  • the parameters set by the design unit 14 may have already been set for the resources.
  • the parameter setting by the design unit 14 may be omitted. In this embodiment, the description will be continued as omitted. However, the design unit 14 may reset different parameters. Further, when the parameter is not set in the resource constituting the best practice, the design unit 14 can set the parameter in the resource.
  • the determination unit 16 can analyze the external information acquired by the acquisition unit 11 and derive one or more design change proposals. For example, when an abnormal value exceeding a specified range is detected by system monitoring, the determination unit 16 can derive a design change proposal, but the present invention is not limited to this case.
  • the determination unit 16 can derive a design change proposal by referring to the best practices accumulated in the best practice group d4, for example. That is, since the design change proposal is derived in light of the past results, the reliability of the design change proposal can be improved.
  • the determination unit 16 can evaluate the derived design change proposal by, for example, well-known scoring using the performance value of the system as an index. As a result, the determination unit 16 can determine the design change proposal having the maximum score. The determination unit 16 can use the determined design change proposal as a request for changing the design of the system.
  • the resource management device 1 has already executed the design process for the system before the design change.
  • the design process is executed in the following procedure. That is, first, the acquisition unit 11 acquires the request from the external device. Next, the application selection unit 12 analyzes the acquired request and selects an application for satisfying the request. Next, the infrastructure selection unit 13 selects an infrastructure having a relationship with the selected application or an infrastructure having a relationship with the selected infrastructure according to the data model. Next, the design unit 14 sets parameters for the application selected by the application selection unit 12 and the infrastructure selected by the infrastructure selection unit 13. Next, the design unit 14 generates a blueprint for designing the system using the application selected by the application selection unit 12, the infrastructure selected by the infrastructure selection unit 13, and the set parameters. Finally, the orchestrator unit 15 performs orchestration on the system according to the generated blueprint.
  • the orchestrator unit 15 may execute a test of the designed system. Depending on the selected app and infrastructure, it may be possible to generate a blueprint without setting parameters, and parameters are not required. Therefore, the parameter setting is arbitrary. Further, in the design process, the application and the infrastructure may be selected with reference to the best practice group d4.
  • the design unit 14 can accumulate the generated blueprints in the blueprint group d3.
  • the design unit 14 can form a new relationship with the application and infrastructure used in the designed system, and can generate a new data model.
  • the design unit 14 can store the newly generated data model in the data model group d2.
  • the design unit 14 can determine new best practices using the apps and infrastructure used in the designed system.
  • the design unit 14 can accumulate the newly determined best practice in the best practice group d4.
  • the resource management device 1 executes the design change process of FIG. 3 for the system whose orchestration and test are completed by the above design process and has started operation.
  • the acquisition unit 11 acquires external information from the external device (step S1).
  • the determination unit 16 analyzes the external information and derives one or a plurality of design change proposals (step S2).
  • the determination unit 16 determines whether or not to change the design of the system based on the external information (step S3). Specifically, the determination unit 16 determines whether or not to adopt the design change proposal having the highest score among the derived design change proposals. For example, if the maximum score is equal to or higher than a predetermined value, it may be adopted, but the present invention is not limited to this.
  • step S3 the design change process is terminated.
  • the application selection unit 12 analyzes the request indicated by the adopted design change proposal and selects an application for satisfying the request (step S4).
  • the infrastructure selection unit 13 selects an infrastructure having a relationship with the selected application or an infrastructure having a relationship with the selected infrastructure according to the data model (step S5).
  • the design unit 14 sets parameters for the application selected by the application selection unit 12 and the infrastructure selected by the infrastructure selection unit 13 (step S6).
  • step S6 the design unit 14 generates a blueprint for designing and changing the system using the application selected by the application selection unit 12, the infrastructure selected by the infrastructure selection unit 13, and the set parameters ().
  • Step S7 the orchestrator unit 15 executes orchestration on the redesigned system according to the generated blueprint (step S8). This completes the design change process.
  • the orchestrator unit 15 may execute a test of the redesigned system. Depending on the selected app and infrastructure, it may be possible to generate a blueprint without setting parameters, and parameters are not required. Therefore, the parameter setting is arbitrary. Further, in the design process, the application and the infrastructure may be selected with reference to the best practice group d4. Further, the order of the application selection (step S4) by the application selection unit 12 and the infrastructure selection (step S5) by the infrastructure selection unit 13 can be appropriately changed according to the determined design change proposal. That is, a particular infrastructure may be selected before the app is selected.
  • the design unit 14 can accumulate the blueprint generated in step S7 in the blueprint group d3.
  • the design unit 14 can form a new relationship with the application and the infrastructure used in the redesigned system, and can generate a new data model.
  • the design unit 14 can store the newly generated data model in the data model group d2.
  • the design unit 14 can determine new best practices by using the application and infrastructure used in the redesigned system.
  • the design unit 14 can accumulate the newly determined best practice in the best practice group d4.
  • the design change process of FIG. 3 can be executed repeatedly. That is, by continuing to collect external information, system design changes can be made automatically without human intervention. As a result, it can self-evolve to converge on the optimal system.
  • a data pipeline is set in which the surveillance camera p1 is the data transmission source and the storage v1 is the data transmission destination (thick line with an arrow).
  • the setting of the data pipeline can be, for example, the processing of the application selection unit 12, but is not limited to this.
  • the setting of the data pipeline may be, for example, a process of the design unit 14.
  • one data pipeline can be set according to the selection of the infrastructure by the infrastructure selection unit 13.
  • the system of FIG. 4 can design a system in which the surveillance camera p1 can photograph a suspicious person and realize a service satisfying the demand.
  • the system that started operation can check various situations by monitoring it.
  • performance conditions include slow processing, non-compliance with application operating requirements, and over-engineering.
  • cost situation there are high costs and unexpected costs.
  • usage tendency the service usage rate is low, the data source is biased, the service usage time zone is biased, and the like.
  • the system may not be connected or the system may shut down.
  • the system can be monitored by the resource management device 1.
  • the monitoring of the system is performed by a plurality of monitoring devices (computers) different from the resource management device 1.
  • the monitoring results of the plurality of monitoring devices can be aggregated in the resource management device 1.
  • Each of the plurality of monitoring devices can be prepared, for example, for each service, each area, and each tenant, but is not limited thereto.
  • Situation A Does not meet the operating requirements of the video analysis application (high latency).
  • Situation B performance aspect: GW traffic is large (resource usage is high).
  • Situation C cost aspect: The cost of DC GW for cloud services is enormous.
  • Situation D usage tendency: The data source is biased to a specific area.
  • the acquisition unit 11 can acquire the above situations A to D as external information. It is assumed that the determination unit 16 analyzes the situations A to D and derives the following design change proposals: options (1) to (3).
  • Option (1) Expand GW resources.
  • Option (2) Decrease the bit rate of the video.
  • Option (3) Move the video analysis application closer to the data source.
  • the method of deriving the option from the situation is as follows. That is, the resource management device 1 holds in advance a response (option) to the situation as a rule. Further, the resource management device 1 assigns a score to the rules to be held. When the status is confirmed, the resource management device 1 extracts the rule corresponding to the confirmed status. Further, the resource management device 1 finally determines which rule to select based on the score attached to the extracted rule.
  • the above method is an example, and the method of deriving the option from the situation is not limited to this. For example, a dedicated AI model may be introduced.
  • the determination unit 16 evaluates options (1) to (3).
  • option (1) increases the cost of GW, gives a negative evaluation to situation C, and has a low score.
  • option (2) cannot meet the operating requirements of the video analysis application, resulting in an extremely negative evaluation for situation A, and the score is extremely low.
  • option (3) can improve all of situations A to D and gives a positive evaluation, and the score is high.
  • the determination unit 16 adopts the option (3) and changes the system design in response to the option (3).
  • the method of evaluating a plurality of options and adopting one option is not limited to the above, and can be realized by using, for example, a predetermined algorithm.
  • the infrastructure selection unit 13 selects edge p4 as a physical resource to be arranged in the physical layer of the data source: area e1.
  • the infrastructure selection unit 13 considers the usage status, usage range, usage, usage authority, and the like of the physical resource.
  • the edge p4 is, for example, a multipurpose / versatile shared edge that is provisioned at the time of use and released after the use.
  • the application selection unit 12 selects an application to be used for the area e1 (see step S4 in FIG. 3). Specifically, the application selection unit 12 moves the video analysis a2 arranged in the domain of the data center p3 to the application layer of the domain of the edge p4 of the area e1. In addition, the application selection unit 12 newly arranges the data input a4 and the data transmission a5 in the application layer of the domain of the edge p4.
  • the application since the environment for providing the service using the surveillance camera p1 is switched from the single domain to the distributed environment, it is preferable that the application is selected so that the configuration pattern of the application is maintained before and after the switching.
  • the data input a4 and the data transmission a5 are generally the same as the data reception a1 and the data storage a3 in terms of data transmission / reception specifications.
  • the application selection unit 12 uses a data pipeline (arrow) used by the selected application (data input a4, video analysis a2, data transmission a5, data reception a1 and data storage a3). Thick line with) is set.
  • the application selection unit 12 sets a data pipeline from the surveillance camera p1 to the storage v1 via the selected application (data input a4, video analysis a2, data transmission a5, data reception a1 and data storage a3). be able to.
  • the infrastructure selection unit 13 selects the infrastructure to be used for the area e1 (see step S5 in FIG. 3).
  • the infrastructure selection unit 13 can select the already selected edge p4, virtual network v7, GWv8, VMv9 to v11 according to the data pipeline and the data model.
  • the virtual networks v7, GWv8, and VMv9 to v11 are resources arranged in the virtual layer.
  • a data pipeline is set up via the selected infrastructure (thick line with arrow).
  • the infrastructure selection unit 13 may satisfy the operating conditions. It is preferable to select an infrastructure that can be used.
  • the “predetermined operating condition” can be, for example, that the amount of resources of the infrastructure is sufficient (resource check), but the present invention is not limited to this.
  • the resource management device 1 can notify the owner of the infrastructure that the amount of resources is insufficient.
  • a resource that has a relationship with an application according to option (3) and a data model can be said to be a resource that can satisfy the operating conditions of the application.
  • the design unit 14 accumulates the best practices of the resource group consisting of the infrastructure and the application in the best practice group d4.
  • the design unit 14 sets the parameters and generates a blueprint (see steps S6 to S7 in FIG. 3), and the orchestrator unit 15 executes the orchestration (see step S8 in FIG. 3). Therefore, it is possible to redesign the system in which the surveillance camera p1 can shoot a suspicious person and eliminate all the situations A to D confirmed by the monitoring.
  • the function of the resource management device 1 according to the above embodiment can be executed by a computer by a program.
  • the same effect as that of the above embodiment can be obtained by executing the program by the computer.
  • the same processing as that of the above-described embodiment may be realized by recording the program on a computer-readable recording medium, reading the program recorded on the recording medium into the computer, and executing the program.
  • An example of a computer that executes a resource management program that realizes the same functions as the resource management device 1 will be described below.
  • FIG. 9 is a diagram showing a computer that executes a resource management program.
  • the computer 1000 has, for example, a memory 1010, a CPU 1020, a hard disk drive interface 1030, a disk drive interface 1040, a serial port interface 1050, a video adapter 1060, and a network interface 1070. Each of these parts is connected by a bus 1080.
  • the memory 1010 includes a ROM (Read Only Memory) 1011 and a RAM (Random Access Memory) 1012.
  • the ROM 1011 stores, for example, a boot program such as a BIOS (Basic Input Output System).
  • BIOS Basic Input Output System
  • the hard disk drive interface 1030 is connected to the hard disk drive 1090.
  • the disk drive interface 1040 is connected to the disk drive 1100.
  • a removable storage medium such as a magnetic disk or an optical disk is inserted into the disk drive 1100.
  • a mouse 1110 and a keyboard 1120 are connected to the serial port interface 1050.
  • a display 1130 is connected to the video adapter 1060, for example.
  • the memory 1010, the hard disk drive 1090, the disk drive 1100, and the storage medium inserted into the disk drive 1100 are specific hardware resources of the storage unit included in the resource management device 1.
  • the hard disk drive 1090 stores, for example, the OS 1091, the application program 1092, the program module 1093, and the program data 1094.
  • Each table described in the above embodiment is stored in, for example, a hard disk drive 1090 or a memory 1010.
  • the resource management program is stored in the hard disk drive 1090 as, for example, a program module in which a command executed by the computer 1000 is described. Specifically, a program module in which each process executed by the resource management device 1 described in the above embodiment is described is stored in the hard disk drive 1090.
  • the data used for information processing by the resource management program is stored as program data in, for example, the hard disk drive 1090.
  • the CPU 1020 reads the program module 1093 and the program data 1094 stored in the hard disk drive 1090 into the RAM 1012 as needed, and executes each of the above-described procedures.
  • the program module 1093 and program data 1094 related to the resource management program are not limited to the case where they are stored in the hard disk drive 1090. For example, they are stored in a removable storage medium and read by the CPU 1020 via the disk drive 1100 or the like. It may be issued. Alternatively, the program module 1093 and the program data 1094 related to the resource management program are stored in another computer connected via a network such as LAN (Local Area Network) or WAN (Wide Area Network), and are stored via the network interface 1070. It may be read by the CPU 1020.
  • LAN Local Area Network
  • WAN Wide Area Network
  • the present embodiment has a determination unit 16 that determines whether or not to change the design of the system that provides the service based on external information, and if the change is made, data is exchanged according to the data model.
  • a selection unit (app selection unit 12, infrastructure selection unit 13) that selects a plurality of possible resources, and a design unit 14 that uses the selected resources to generate a blueprint for changing the design of the system.
  • the resource management device 1 is provided with an orchestrator unit 15 that executes orchestration according to the generated blueprint for the system whose design has been changed.
  • the resource management device 1 determines whether or not to change the design of the system that provides the service based on the external information, and if the change is made, data exchange is performed according to the data model.
  • the plurality of resources are characterized by including an application for satisfying a request derived from the external information and an infrastructure having a relationship with the application.
  • the resource is characterized by including a best practice resource.
  • the determination unit 16 analyzes the external information acquired by monitoring the system to derive one or a plurality of design change proposals, and uses a predetermined algorithm to obtain one of the derived design change proposals. It is characterized by being adopted.
  • performance values eg, throughput
  • the determination unit 16 can combine two or more of the derived design change proposals into one new design change proposal. When the score of the new design change plan is the maximum, the determination unit 16 can adopt the new design change plan and realize the design change process by the resource management device 1.
  • the design change of the system of the present invention includes a design change that does not involve addition or deletion of resources, that is, a design change in which the resource groups constituting the system remain the same.
  • a design change can be executed based on, for example, internal information of the system instead of the external information described above, but is not limited thereto. For example, in a smart city where a suspicious person is monitored by a surveillance camera, when a suspicious person is detected, the coding rate of the video of the surveillance camera (infrastructure) is autonomously increased, or the network bandwidth is autonomously increased. By doing so, it is possible to autonomously improve the image of the surveillance camera in high definition.
  • D Various techniques described in this embodiment can be combined as appropriate.
  • Resource management device 11 Acquisition unit 12 Application selection unit (selection unit) 13 Infrastructure selection section (selection section) 14 Design Department 15 Orchestrator Department 16 Judgment Department d1 Catalog Group d2 Data Model Group d3 Blueprint Group d4 Best Practice Group

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Stored Programmes (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本発明のリソース管理装置（１）は、外部情報に基づいて、サービスを提供するシステムの設計を変更するか否かを判定する判定部（１６）と、変更する場合、マルチレイヤの各レイヤに配置されるリソース間のリレーションを明示したデータモデルに従い、データのやり取りが可能な複数のリソースを選択する選択部（１２，１３）と、前記選択されたリソースを用いて、前記システムの設計を変更するためのブループリントを生成する設計部（１４）と、前記設計を変更したシステムに対して、前記生成したブループリントに従い、オーケストレーションを実行するオーケストレータ部（１５）と、を備えることを特徴とする。

Description

リソース管理装置、リソース管理方法、および、リソース管理プログラム
　本発明は、リソース管理装置、リソース管理方法、および、リソース管理プログラムに関する。
　近年、クラウドサービス等のサービス事業者がサービスをエンドユーザに提供するための技術開発が盛んに行われている。例えば、特許文献１には、「ユーザに通信を提供する端末機からの通信サービス利用のためのオーダ要求に応じて、卸サービス事業者毎に通信サービスＡＰＩで公開される各々異なる１つの通信サービスを１又は複数一括して提供する事業者間一括サービス構築装置であって、通信の卸サービスの仕様が記述されたカタログと、各種の通信サービスの連携を定めた連携ルールとを保持し、前記端末機から複数の通信サービス利用のオーダ要求があった場合に、前記保持された前記カタログ及び前記連携ルールに基づき、当該オーダ要求された複数の通信サービスに対応する前記通信サービスＡＰＩを一括に連携させて連携サービスを構築し、この構築された連携サービスを前記端末機へ提供する一括構築機能部を備えることを特徴とする事業者間一括サービス構築装置」について開示されている。
特開２０１８－３２８９７号公報（請求項１）
　また、近年では、ＰａａＳ（Platform as a Service）やＩａａＳ（Infrastructure as a Service）などの、インターネット経由で利用したり提供したりすることが可能なサービスが数多く存在し、そのような複数種類のサービスを提供するシステムの技術開発が盛んに行われている。複数種類のサービスの各々を扱うベンダは固有のドメインを用意している（マルチドメイン）。つまり、複数種類のドメインが存在しており、ドメイン間で連携可能となるようにシステムの設計が行われる。また、複数種類のサービスの提供のために仮想化技術が用いられている。よって、各ドメイン内のリソースは多層化されており、物理レイヤ、仮想レイヤ、アプリケーションレイヤなどに属している（マルチレイヤ）。リソースは、ＩＣＴ（Information and Communication Technology）リソースとも呼ばれる。そして、複数種類のサービスが連携可能となるようにシステムの設計が行われ、異なるサービスを利用するユーザ同士のやり取りを実現する（マルチサービス）。なお、マルチサービス、マルチドメイン、マルチレイヤをまとめたものを以下「トリプルマルチ」と呼ぶ場合がある。
　しかし、一般的には、各リソースの所有者が異なるため、各リソースはドメインごと、レイヤごとで個別に管理される。このため、通常は、あるリソース群から構成されるシステムの運用ノウハウを他のリソース群に適用することはできない。その結果、従来では、トリプルマルチにおけるリソースの制御は極めて複雑であり、トリプルマルチに対応可能なシステムの設計は容易でなかった。
　また、システムの設計の契機となる要求が抽象的である場合があり、設計したシステムが実際に最適である保証がない。また、外部環境が変化したために、最適を目指して設計したシステムが最適のままである保証がない。また、設計したシステムを運用した場合にさまざまな知見が得られ、最適化の余地が残されていることがわかる場合がある。よって、システムの設計の変更が求められるが、従来では、システムの設計変更は、多大な労力と時間を要するため容易でなかった。
　このような事情を鑑みて、本発明は、複数種類のサービスを提供するシステムの設計変更を容易にすることを課題とする。
　前記した課題を解決するため、本発明のリソース管理装置は、外部情報に基づいて、サービスを提供するシステムの設計を変更するか否かを判定する判定部と、変更する場合、マルチレイヤの各レイヤに配置されるリソース間のリレーションを明示したデータモデルに従い、データのやり取りが可能な複数のリソースを選択する選択部と、前記選択されたリソースを用いて、前記システムの設計を変更するためのブループリントを生成する設計部と、前記設計を変更したシステムに対して、前記生成したブループリントに従い、オーケストレーションを実行するオーケストレータ部と、を備えることを特徴とする。
　本発明によれば、複数種類のサービスを提供するシステムの設計変更を容易にすることができる。
本実施形態におけるリソース管理装置の機能構成図である。 データモデルの例の説明図である。 設計変更処理のフローチャートである。 システム設計変更の具体例（１／５）である。 システム設計変更の具体例（２／５）である。 システム設計変更の具体例（３／５）である。 システム設計変更の具体例（４／５）である。 システム設計変更の具体例（５／５）である。 本実施形態における処理のプログラムを実行するコンピュータを示す図である。
　以下、図面を参照して本発明を実施するための形態（以下、「本実施形態」という）について説明する。本実施形態では、トリプルマルチに対応可能なシステムの設計について説明する。マルチレイヤは、物理レイヤ、仮想レイヤ、アプリケーションレイヤから構成されているとする。物理レイヤの上に仮想レイヤが存在し、仮想レイヤの上にアプリケーションレイヤが存在する。物理レイヤ、仮想レイヤ、アプリケーションレイヤの各々には、複数種類のサービスを提供するためのリソースを配置することができる。アプリケーションレイヤに配置されるリソースを「アプリケーション」と呼ぶ場合がある。説明の便宜上、アプリケーションは、「アプリ」と略記する場合がある。また、物理レイヤに配置されるリソースを「物理リソース」と呼ぶ場合がある。仮想レイヤに配置されるリソースを「仮想リソース」と呼ぶ場合がある。物理リソースおよび仮想リソースを「インフラ」と総称する場合がある。
［構成］
　本実施形態のリソース管理装置は、複数種類のサービスを提供するためのリソースを管理する装置である。図１に示すように、本実施形態のリソース管理装置１は、取得部１１と、アプリ選択部１２と、インフラ選択部１３と、設計部１４と、オーケストレータ部１５と、判定部１６とを備えている。また、リソース管理装置１は、カタログ群ｄ１と、データモデル群ｄ２と、ブループリント群ｄ３と、ベストプラクティス群ｄ４とを記憶する。カタログ群ｄ１、データモデル群ｄ２、ブループリント群ｄ３、および、ベストプラクティス群ｄ４を含む各種情報は、リソース管理装置１が備える記憶部（図示略）に記憶される。
　取得部１１は、外部装置からの要求を取得する。外部装置は、例えば、サービスを利用するユーザが用いる情報端末、ネットワークを管理するオペレータが用いるコンソールなどの装置であるが、これらに限定されない。要求は、例えば、システムの設計、構築、変更を必要とするものであり、例えば、ビジネス上の要望を表現するものであるが、これに限定されない。要求の形式は、例えば、テキスト、音声、または、コマンドとすることができるが、これらに限定されない。また、外部装置は、外部情報源とすることもでき、取得部１１は、外部情報源からの外部情報を取得することができる。外部情報とは、例えば、システムをモニタリングすることによりネットワーク上に発生したアラート、ネットワーク上のシステムのログ、ＳＮＳ（Social Networking Service）に投稿された情報、天候や交通に関する情報があるがこれらに限定されない。要求および外部情報は本実施形態で行う処理のトリガとして同一視できる場合があり、本実施形態では特段の事情がない限り、要求と外部情報との区別をしない。
　アプリ選択部１２は、取得部１１が取得した要求を満たすためのアプリを選択する。アプリ選択部１２は、要求を解析し、その解析結果に基づいて、カタログ群ｄ１から所定のカタログを抽出することで、アプリを選択することができる。要求を解析する技術自体は周知であり、詳細な説明は省略する。カタログは、サービスの提供に供する工程のひな型であり、当該サービスの提供に必要な１または複数のアプリが指定されている。カタログ自体は周知であり、詳細な説明は省略する。
　また、アプリ選択部１２は、選択したアプリが利用するデータパイプラインを設定することができる。データパイプラインは、データの送信元（例えば、インフラ）からデータの送信先（例えば、インフラ）までのデータの経路である。アプリ選択部１２は、周知のパイプライン処理によってデータパイプラインを設定することができる。例えば、データパイプラインは、パイプライン処理の１つであるソフトウェアパイプラインによって、データの処理順番に所定の順序性を持たせたものとすることができるが、これに限定されない。
　特に、アプリ選択部１２は、ベストプラクティスのアプリを選択することができる。アプリ選択部１２は、要求を満たすためのアプリを含むベストプラクティスをベストプラクティス群ｄ４から選択することで、アプリを選択することができる。ベストプラクティスは、所定のサービスの提供に関して所定以上の性能が発揮されるように最適化されていることが確認済みのリソース群である。ベストプラクティスの詳細は後記する。アプリ選択部１２が選択したアプリは、ベストプラクティスのアプリでもよいし、ベストプラクティスでないアプリであってもよいが、アプリ選択部１２は、ベストプラクティスのインフラを優先的に選択する。
　インフラ選択部１３は、アプリ選択部１２が選択したアプリに対してインフラを選択する。インフラ選択部１３は、データモデル群ｄ２を参照して、特定のデータモデルにより、選択されたアプリとリレーションを持つインフラを選択することができる。データモデルの詳細は後記する。
　特に、インフラ選択部１３は、ベストプラクティスのインフラを選択することができる。インフラ選択部１３は、ベストプラクティス群ｄ４を参照して、アプリ選択部１２が選択したアプリとデータのやり取りが可能なインフラ、または、インフラ選択部１３が選択したインフラとデータのやり取りが可能なインフラを選択することができる。インフラ選択部１３が選択したインフラは、ベストプラクティスのインフラでも良いし、ベストプラクティスでないインフラであってもよいが、インフラ選択部１３は、ベストプラクティスのインフラを優先的に選択する。
　設計部１４は、アプリ選択部１２が選択したアプリ、および、インフラ選択部１３が選択したインフラを用いたシステムを設計する。具体的には、設計部１４は、ブループリントを生成する。ブループリントは、要求を満たすリソース群からなるシステムの設計情報である。ブループリント自体は周知であり、その詳細な説明は省略する。また、設計部１４は、ブループリントを生成するためのパラメータを設定することができる。パラメータは、例えば、サービスを利用するユーザの数、物理レイヤに配置される物理マシンのＩＰアドレス、仮想レイヤに配置される仮想マシンのＩＰアドレスなどがあるが、これらに限定されない。パラメータ自体は周知であり、詳細な説明は省略する。
　また、設計部１４は、判定部１６の判定結果に従い、運用中のシステムの設計を変更することができる。具体的には、アプリ選択部１２が再選択したアプリ、および、インフラ選択部１３が再選択したインフラを用いたシステムを設計する。また、設計部１４は、システムを設計変更するためのブループリントを生成する。
　オーケストレータ部１５は、設計部１４が設計したシステムに対して、設計部１４が生成したブループリントに従い、オーケストレーションを実行する。オーケストレーションは、サービスの配備、設定、管理の自動制御である。オーケストレーションによって、サービスの提供が実現する。また、オーケストレータ部１５は、システムのテストを実行することができる。
　また、オーケストレータ部１５は、設計部１４が設計変更したシステムに対して、設計部１４が生成したブループリントに従い、オーケストレーションを実行することができる。また、オーケストレータ部１５は、設計変更したシステムのテストを実行することができる。
　判定部１６は、外部情報に基づいて、システムの設計を変更するか否かを判定する。判定対象のシステムは、オーケストレーションおよびテストが完了し、運用を開始したシステムとすることができるが、これに限定されない。例えば、設計後運用前のシステムであってもよい。本実施形態では、判定対象のシステムを、運用を開始したシステムとして説明を続ける。
　カタログ群ｄ１は、カタログの集合体である。データモデル群ｄ２は、データモデルの集合体である。ブループリント群ｄ３は、ブループリントの集合体である。設計部１４が生成したブループリントは、ブループリント群ｄ３に蓄積される。ベストプラクティス群ｄ４は、ベストプラクティスの集合体である。
＜データモデルの詳細＞
　本実施形態におけるデータモデルは、所定のデータをやり取りするリソース間のリレーションを明示したものである。データモデルは、リレーションと、当該リレーションを持つ２つのリソースとの組で表現される。なお、本来のデータモデルは、データまたは構造化データの構造を明示的に決めるものである。しかし、本発明では、データモデルを特異的に使用している。つまり、サービス等で提供される個々のリソースとその間のリレーションを示すものとしてデータモデルを定義し、複数のサービスを組み合わせた複雑系の設計のリファレンスとして活用できるようにしている。よって、複数のサービスの提供に必要なリソース群が特定される。
　本実施形態では、リソースは、アプリレイヤに配置されるアプリ、仮想レイヤに配置される仮想リソース、および物理レイヤに配置される物理リソースに分類される。よって、図２に示すように、データモデルとして、アプリｒ１と仮想リソースｒ２との間にリレーションが形成されたもの、仮想リソースｒ３と物理リソースｒ４との間にリレーションが形成されたものがある。これら２つのデータモデルは、隣接するレイヤ同士に配置されるリソース間にリレーションが形成された例である。また、図２に示すように、データモデルとして、仮想リソースｒ５，ｒ６との間にリレーションが形成されたもの、物理リソースｒ７，ｒ８との間にリレーションが形成されたものがある。これら２つのデータモデルは、同じレイヤに配置されるリソース間にリレーションが形成された例である。なお、データモデルとして、２つのアプリ間にリレーションが形成されたものがあってもよい。
　データモデルによって、特定された２つリソースの間で所定のデータをやり取りすることが可能になり、つまり、データフローが形成されることが規定されている。よって、アプリ選択部１２がアプリを選択した場合、インフラ選択部１３は、データモデルに従って、選択されたアプリとの間にリレーションを持つ仮想リソースを選択することができ、データのやり取りがなされる。また、インフラ選択部１３は、データモデルに従って、選択された仮想リソースとの間にリレーションを持つ物理リソースや他の仮想リソースを選択することができ、データのやり取りがなされる。また、インフラ選択部１３は、データモデルに従って、選択された物理リソースとの間にリレーションを持つ他の物理リソースや仮想リソースを選択することができ、データのやり取りがなされる。
　アプリや仮想リソースは、例えば、所定のサービスを提供するために利用されるリソースの種別の変化や、当該リソースの使い方（ユーザの利用態様）の変化などに応じて適宜バージョンアップがなされる。また、物理リソースは、例えば、適宜新しい規格へ追随した機器として提供される。具体的には、サーバによる管理からサーバを構成する処理装置やメモリによる管理への切替のような管理単位の粒度の小規模化、使い古した機器からより性能が強化された新しい機器への交換、データ構造を変更した機器への交換、などがなされる。このように、リソースは、動的に変化するものである。よって、データモデルも動的に変化する（更新する）。このような変化に伴い、データモデル群ｄ２は適宜更新される。
　なお、図２に示すように、データモデルは、２つのリソースがリレーションを持つデータモデルとして用意されるが、リレーションを持つ２つのリソースのうちの片方が共通し、もう片方が異なるデータモデルが複数存在していてもよい。この場合、データモデルにより、アプリ選択部１２が選択したアプリとリレーションを持つインフラは複数存在する場合がある。インフラ選択部１３は、所定の優先順位（例：ＳＬＡ（Service Level Agreement）、リンクコスト、その他ポリシー）を用いて１つのインフラを選択することができる。
　また、リソースの各々に対して、当該リソースを保有する所有者が存在する。リソース管理装置１は、リソースと、当該リソースの所有者とを関連付けてリソースを管理することができる。また、リソース管理装置１が管理するリソースの各々に対して、当該リソースの利用権限を有するユーザが決められている。リソース管理装置１は、リソースと、当該リソースの利用権限を有するユーザとを関連付けてリソースを管理することができる。
　また、サービスが提供されるネットワークに関しては、特定のユーザ群（例：１顧客、１企業）に提供される仮想ネットワーク単位としてテナントが用意されている。１つのテナントは、１または複数種類のサービスごとに用意することができる。よって、所定のルールに従った複数のリソースに対して１つのテナントを割り当てることができる。結果的には、リソース管理装置１は、リソースと、当該リソースが属するテナントとを関連付けてリソースを管理することができる。
　データモデルを用いることにより、インフラ選択部１３は、リソース（アプリ、インフラ）間のリレーションを参照するのみで、データのやり取り（データフロー）が可能なインフラ群を選択することができる。つまり、データフローを担当するリソースがマルチレイヤのいずれのレイヤに属しているかを問わずに、選択されたアプリに対してインフラ群を選択することができる。また、データフローを担当するリソースがマルチサービスのいずれのサービスを提供するためのリソースであるかを問わずに、選択されたアプリに対してインフラ群を選択することができる。
　また、トリプルマルチに対応可能なシステムの設計におけるドメインは、上述した、リソースの所有者およびテナントに関係している。つまり、ドメインに従って、ドメイン内のリソースの所有者が特定されたり、ドメインと同一視可能なテナントを用意したりすることができる。しかし、上述したように、データモデルを用いることで特定のアプリに対するインフラ群が選択されるので、データフローを担当するリソースがマルチドメインのいずれのドメインに属しているかを問わずに、選択されたアプリに対してインフラ群を選択することができる。
　このように、データモデルは、各ドメイン間の差異、各レイヤ間の差異、各サービス間の差異、を抽象化して、汎用的なデータ構造をとることができ、要求に対して選択されるリソースを最適化する上で有用な手段である。
＜ベストプラクティスの詳細＞
　先述した通り、ベストプラクティスは、所定のサービスの提供に関して所定以上の性能が発揮されるように最適化されていることが確認済みのリソース群である。所定以上の性能とは、例えば、ベストプラクティスを構成するリソース間でのデータのやり取りのスループットが所定値以上であるとすることができるが、これに限定されない。
　ベストプラクティスを構成するリソース群には、異なるレイヤに配置されるリソースを含むリソース群がある。つまり、アプリと仮想リソースを含むもの、仮想リソースと物理リソースを含むもの、アプリと仮想リソースと物理リソースを含むものである。また、ベストプラクティスを構成するリソース群には、同じレイヤに配置されるリソースを含むリソース群がある。つまり、２以上のアプリを含むもの、２以上の仮想リソースを含むもの、２以上の物理リソースを含むものである。
　ベストプラクティスを構成するリソース群は、データモデルによるリレーションを持つリソース群であってもよいし、データモデルによるリレーションを持たないリソース群であってもよいし、データモデルによるリレーションを持つリソース部分群とデータモデルによるリレーションを持たないリソース部分群とを合わせたリソース群であってもよい。ベストプラクティスを構成するリソース群の間のリレーションの有無に関わらず、過去の知見（実績）により、ベストプラクティスを構成するリソース間でのデータのやり取りについては、所定以上の性能が発揮されることが確認済みである。
　ベストプラクティスは、所定のサービスを提供するためのシステム全体を構成するリソース群の部分集合となり得る。つまり、ベストプラクティスは、システム全体に対して部分的な（局所的な）最適解を提供することができる。よって、データフローが連続するように複数のベストプラクティスを寄せ集めることで、システム全体が最適化されるようにシステム全体を設計することができる。つまり、ベストプラクティスは、システム全体に対して部分的な最適解を提供する複数の部分的なベストプラクティスの集合であり、選択部（１２，１３）は、システム全体に対する複数の部分的なベストプラクティスのリソースを選択し、設計部１４は、選択された複数の部分的なベストプラクティスのリソースを用いてシステム全体を設計するためのブループリントを生成する。
　ベストプラクティスを構成するリソースは、すでにサービスの提供のために運用済みであるため、当該リソースに対して、設計部１４が設定するパラメータが設定済みである場合がある。この場合、アプリ選択部１２またはインフラ選択部１３が当該リソースを選択した場合、設計部１４によるパラメータ設定は省略してもよい。本実施形態では省略することとして説明を続ける。ただし、設計部１４が異なるパラメータを設定し直してもよい。また、ベストプラクティスを構成するリソースにパラメータが設定されていない場合、設計部１４が当該リソースにパラメータを設定することができる。
＜システムの設計変更の詳細＞
　例えば、判定部１６は、取得部１１が取得した外部情報を解析して、１または複数の設計変更案を導出することができる。例えば、システムのモニタリングにより、規定範囲を超える異常値が検出された場合に、判定部１６は設計変更案を導出することができるが、この場合に限定されない。判定部１６は、例えば、ベストプラクティス群ｄ４に蓄積されているベストプラクティスを参照して、設計変更案を導出することができる。つまり、過去の実績に照らし合わせて設計変更案が導出されるため、設計変更案の信頼性を向上させることができる。
　また、判定部１６は、例えば、システムの性能値を指標とした周知のスコアリングによって、導出した設計変更案を評価することができる。その結果、判定部１６は、スコアが最大の設計変更案を決定することができる。判定部１６は、決定した設計変更案を、システムの設計を変更するための要求とすることができる。
［処理］
　リソース管理装置１が複数種類のサービスを提供するシステムを設計変更するための設計変更処理を、図３を参照して説明する。
＜設計処理＞
　前段階として、リソース管理装置１は、設計変更前のシステムに対して、設計処理を実行済みである。設計処理は、以下の手順で実行される。すなわち、まず、取得部１１が外部装置から要求を取得する。次に、アプリ選択部１２が、取得した要求を解析し、要求を満たすためのアプリを選択する。次に、インフラ選択部１３が、データモデルに従い、選択されたアプリとリレーションを持つインフラや、選択したインフラとリレーションを持つインフラを選択する。次に、設計部１４が、アプリ選択部１２が選択したアプリ、および、インフラ選択部１３が選択したインフラに対して、パラメータを設定する。次に、設計部１４が、アプリ選択部１２が選択したアプリ、および、インフラ選択部１３が選択したインフラ、および、設定したパラメータを用いて、システムを設計するためのブループリントを生成する。最後に、オーケストレータ部１５が、システムに対して、生成されたブループリントに従い、オーケストレーションを実行する。
　上記設計処理によれば、設計したシステムによるサービスの提供を実現することができる。なお、オーケストレータ部１５は、設計したシステムのテストを実行してもよい。
　なお、選択されたアプリやインフラ次第では、パラメータの設定なしでブループリントを生成することができる場合があり、パラメータは必須ではない。よって、パラメータの設定は任意である。また、設計処理において、ベストプラクティス群ｄ４を参照して、アプリおよびインフラを選択してもよい。
　また、設計部１４は、生成されたブループリントを、ブループリント群ｄ３に蓄積することができる。また、設計部１４は、設計したシステムに用いられたアプリおよびインフラに対しては、新たなリレーションを形成することができ、新たなデータモデルを生成することができる。設計部１４は、新たに生成されたデータモデルを、データモデル群ｄ２に蓄積することができる。また、設計部１４は、設計したシステムに用いられたアプリおよびインフラを用いて新たなベストプラクティスを決定することができる。設計部１４は、新たに決定したベストプラクティスをベストプラクティス群ｄ４に蓄積することができる。
＜設計変更処理＞
　リソース管理装置１は、上記設計処理によってオーケストレーションおよびテストが完了し、運用を開始したシステムに対して図３の設計変更処理を実行する。まず、取得部１１が外部装置から外部情報を取得する（ステップＳ１）。次に、判定部１６が、外部情報を解析して、１または複数の設計変更案を導出する（ステップＳ２）。次に、判定部１６が、外部情報に基づいて、システムを設計変更するか否かを判定する（ステップＳ３）。具体的には、判定部１６は、導出した設計変更案のうち最大のスコアとなる設計変更案を採用するか否か判定する。例えば、最大のスコアが所定値以上であれば採用するとしてもよいが、これに限定されない。
　設計変更しない場合（ステップＳ３でＮｏ）、設計変更処理を終了する。一方、設計変更する場合（ステップＳ３でＹｅｓ）、アプリ選択部１２が、採用した設計変更案が示す要求を解析し、要求を満たすためのアプリを選択する（ステップＳ４）。次に、インフラ選択部１３が、データモデルに従い、選択されたアプリとリレーションを持つインフラや、選択したインフラとリレーションを持つインフラを選択する（ステップＳ５）。次に、設計部１４が、アプリ選択部１２が選択したアプリ、および、インフラ選択部１３が選択したインフラに対して、パラメータを設定する（ステップＳ６）。次に、設計部１４が、アプリ選択部１２が選択したアプリ、および、インフラ選択部１３が選択したインフラ、および、設定したパラメータを用いて、システムを設計変更するためのブループリントを生成する（ステップＳ７）。最後に、オーケストレータ部１５が、設計変更したシステムに対して、生成されたブループリントに従い、オーケストレーションを実行する（ステップＳ８）。以上で、設計変更処理を終了する。
　図３の設計変更処理によれば、設計変更したシステムによるサービスの提供を実現することができる。なお、オーケストレータ部１５は、設計変更したシステムのテストを実行してもよい。
　なお、選択されたアプリやインフラ次第では、パラメータの設定なしでブループリントを生成することができる場合があり、パラメータは必須ではない。よって、パラメータの設定は任意である。また、設計処理において、ベストプラクティス群ｄ４を参照して、アプリおよびインフラを選択してもよい。
　また、決定した設計変更案に応じて、アプリ選択部１２によるアプリの選択（ステップＳ４）およびインフラ選択部１３によるインフラの選択（ステップＳ５）の順序は適宜変更することができる。つまり、アプリの選択の前に特定のインフラが選択される場合があってもよい。
　また、設計部１４は、ステップＳ７で生成されたブループリントを、ブループリント群ｄ３に蓄積することができる。また、設計部１４は、設計変更したシステムに用いられたアプリおよびインフラに対しては、新たなリレーションを形成することができ、新たなデータモデルを生成することができる。設計部１４は、新たに生成されたデータモデルを、データモデル群ｄ２に蓄積することができる。また、設計部１４は、設計変更したシステムに用いられたアプリおよびインフラを用いて新たなベストプラクティスを決定することができる。設計部１４は、新たに決定したベストプラクティスをベストプラクティス群ｄ４に蓄積することができる。
　図３の設計変更処理は繰り返し実行可能である。つまり、外部情報の収集を継続することにより、システムの設計変更は、人手を介さずに自動的に行うことができる。その結果、最適なシステムに収束するように自己進化させることができる。
［具体例］
　具体例として、「インターネット経由で入力される映像から不審者を検知したい」という要求に対して設計されたシステムの設計変更について説明する。運用を開始したシステムを構成するリソース群は、図４に示す通りであったとする。図４に示すように、データ受信ａ１、映像解析ａ２、および、データ保存ａ３がアプリレイヤに配置されている。また、ストレージｖ１、仮想ネットワークｖ２、ＧＷ（GateWay）ｖ３、および、ＶＭ（Virtual Machine）ｖ４～ｖ６が仮想レイヤに配置されている。また、監視カメラｐ１、インターネットｐ２、および、データセンタ（ＤＣ）ｐ３が物理レイヤに配置されている。
　また、図４に示すように、監視カメラｐ１をデータの送信元としストレージｖ１をデータの送信先とするデータパイプラインが設定されている（矢印付き太線）。データパイプラインは、アプリ選択部１２が選択したアプリに依存するため、データパイプラインの設定は、例えば、アプリ選択部１２の処理とすることができるが、これに限定されない。例えば、データパイプラインの設定は、例えば、設計部１４の処理としてもよい。なお、選択したアプリに対して複数種類のデータパイプラインが設定可能である場合、インフラ選択部１３によるインフラの選択に応じて１つのデータパイプラインを設定することができる。データパイプラインを設定する場合、アプリ間のベストプラクティスを保持することが好ましい。図４のシステムは、監視カメラｐ１が不審者を撮影可能なシステムを設計し、要求を満たすサービスを実現することができる。
　運用を開始したシステムは、モニタリングすることで様々な状況を確認することができる。例えば、性能面の状況としては、処理が遅い、アプリの動作要件を満たさない、オーバースペックなどがある。また、例えば、コスト面の状況としては、高い、想定外の費用が発生しているなどがある。また、例えば、利用傾向面の状況としては、サービスの利用率が低い、データソースに偏りがある、サービスの利用時間帯に偏りがあるなどがある。また、例えば、不具合と判定される状況として、システムにつながらない、システムが落ちるなどがある。
　なお、システムのモニタリングは、リソース管理装置１が行うことができる。しかし、複数種類のサービスが提供されるシステムが大規模であることに鑑みて、システムのモニタリングは、リソース管理装置１とは異なる複数の監視装置（計算機）が行うようにすることが好ましい。この場合、複数の監視装置のモニタリングの結果をリソース管理装置１に集約させることができる。複数の監視装置の各々は、例えば、サービスごと、エリアごと、テナントごとに用意することができるが、これらに限定されない。
　運用を開始したシステムのモニタリングにより、例えば、以下の状況Ａ～Ｄが確認されたとする。
状況Ａ（性能面）：映像解析のアプリの動作要件を満たしていない（レイテンシ高）。
状況Ｂ（性能面）：ＧＷのトラヒック量が多い（リソース使用量高）。
状況Ｃ（コスト面）：クラウドサービス用のＤＣのＧＷにかかるコストが莫大。
状況Ｄ（利用傾向面）：データソースが特定のエリアに偏っている。
　取得部１１は、上記状況Ａ～Ｄを外部情報として取得することができる。判定部１６は、状況Ａ～Ｄを解析して、以下の設計変更案：オプション（１）～（３）を導出したとする。
オプション（１）：ＧＷのリソースを拡張する。
オプション（２）：映像のビットレートを落とす。
オプション（３）：映像解析のアプリをデータソース近くに移動する。
　なお、状況からオプションを導出する方法は以下の通りである。つまり、リソース管理装置１は、状況に対する対応（オプション）をルールとして予め保持している。また、リソース管理装置１は、保持するルールに対してスコアを付しておく。状況が確認された場合、リソース管理装置１は、確認された状況に対応するルールを抽出する。また、リソース管理装置１は、抽出したルールに付したスコアに基づいて最終的にどのルールを選択するかを決定する。ただし、上記方法は一例であり、状況からオプションを導出する方法はこれに限定されない。例えば、専用のＡＩモデルを導入してもよい。
　判定部１６は、オプション（１）～（３）を評価する。その結果、オプション（１）は、ＧＷのコストが増大することになり、状況Ｃに対してマイナス評価となってしまい、スコアは低い。また、オプション（２）は、映像解析のアプリの動作要件を満たすことができず、状況Ａに対して極めてマイナス評価となってしまい、スコアは極めて低い。一方、オプション（３）は、状況Ａ～Ｄのすべてを改善することができプラス評価となり、スコアは高い。以上から、判定部１６は、オプション（３）を採用し、オプション（３）を要求としてシステムの設計を変更する。なお、複数のオプションを評価して１つのオプションを採用する方法は、上記に限られず、例えば、所定のアルゴリズムを用いて実現することができる。
　まず、図５に示すように、インフラ選択部１３は、データソース：エリアｅ１の物理レイヤに配置される物理リソースとしてエッジｐ４を選択する。インフラ選択部１３は、物理リソースの選択の際、当該物理リソースの利用状況、利用範囲、用途、利用権限などを考慮する。エッジｐ４は、例えば、多目的・多用途の共用エッジであり、使用時にプロビジョニングし、使用後に解放される。
　次に、図６に示すように、アプリ選択部１２は、エリアｅ１に用いるアプリを選択する（図３のステップＳ４参照）。具体的には、アプリ選択部１２は、データセンタｐ３のドメインに配置されていた映像解析ａ２を、エリアｅ１のエッジｐ４のドメインのアプリレイヤに移動する。また、アプリ選択部１２は、エッジｐ４のドメインのアプリレイヤにデータ入力ａ４およびデータ送信ａ５を新たに配置する。本具体例では、監視カメラｐ１を用いるサービスを提供する環境がシングルドメインから分散環境に切り替わるため、切り替え前後でアプリの構成パターンが保持されるようにアプリの選択がなされることが好ましい。データ入力ａ４およびデータ送信ａ５は、データ送受信の仕様に関して、データ受信ａ１およびデータ保存ａ３と概ね共通する。
　次に、図７に示すように、アプリ選択部１２は、選択したアプリ（データ入力ａ４、映像解析ａ２、データ送信ａ５、データ受信ａ１、および、データ保存ａ３）が利用するデータパイプライン（矢印付き太線）を設定する。アプリ選択部１２は、選択したアプリ（データ入力ａ４、映像解析ａ２、データ送信ａ５、データ受信ａ１、および、データ保存ａ３）を経由した、監視カメラｐ１からストレージｖ１までのデータパイプラインを設定することができる。なお、データパイプラインを設定する場合、アプリ間のベストプラクティスを保持することが好ましい。
　次に、図８に示すように、インフラ選択部１３がエリアｅ１に用いるインフラを選択する（図３のステップＳ５参照）。インフラ選択部１３は、データパイプラインおよびデータモデルに従い、すでに選択したエッジｐ４、仮想ネットワークｖ７、ＧＷｖ８、ＶＭｖ９～ｖ１１を選択することができる。仮想ネットワークｖ７、ＧＷｖ８、ＶＭｖ９～ｖ１１は、仮想レイヤに配置されるリソースである。結果的に、図８に示すように、選択したインフラを経由するデータパイプラインが設定される（矢印付き太線）。
　選択したアプリ（データ入力ａ４、映像解析ａ２、データ送信ａ５、データ受信ａ１、および、データ保存ａ３）に所定の稼働条件が存在する場合、インフラ選択部１３は、当該稼働条件を充足することができるインフラを選択することが好ましい。「所定の稼働条件」は、例えば、インフラのリソース量が十分足りていることとすることができる（リソースチェック）が、これに限定されない。リソース量が不足するインフラが存在する場合、リソース管理装置１は、当該インフラの所有者にリソース量が不足する旨を通知することができる。オプション（３）およびデータモデルによりアプリとリレーションを持つリソースは当該アプリの稼働条件を充足することができるリソースといえる。インフラを選択した場合、インフラおよびアプリからなるリソース群のベストプラクティスをベストプラクティス群ｄ４に設計部１４が蓄積することが好ましい。
　その後、設計部１４がパラメータの設定、ブループリントの生成をし（図３のステップＳ６～ステップＳ７参照）、オーケストレータ部１５がオーケストレーションの実行をする（図３のステップＳ８参照）。よって、監視カメラｐ１が不審者を撮影可能なシステムを設計変更し、モニタリングにより確認された状況Ａ～Ｄをすべて解消することができる。
（プログラム）
　また、上記実施形態に係るリソース管理装置１の機能をプログラムにより、コンピュータに実行させることができる。この場合、コンピュータがプログラムを実行することにより、上記実施形態と同様の効果を得ることができる。さらに、かかるプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータに読み込ませて実行することにより上記実施形態と同様の処理を実現してもよい。以下に、リソース管理装置１と同様の機能を実現するリソース管理プログラムを実行するコンピュータの一例を説明する。
　図９は、リソース管理プログラムを実行するコンピュータを示す図である。図９に示すように、コンピュータ１０００は、例えば、メモリ１０１０と、ＣＰＵ１０２０と、ハードディスクドライブインタフェース１０３０と、ディスクドライブインタフェース１０４０と、シリアルポートインタフェース１０５０と、ビデオアダプタ１０６０と、ネットワークインタフェース１０７０とを有する。これらの各部は、バス１０８０によって接続される。
　メモリ１０１０は、ＲＯＭ（Read　Only　Memory）１０１１およびＲＡＭ（Random　Access　Memory）１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic　Input　Output　System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、ハードディスクドライブ１０９０に接続される。ディスクドライブインタフェース１０４０は、ディスクドライブ１１００に接続される。ディスクドライブ１１００には、例えば、磁気ディスクや光ディスク等の着脱可能な記憶媒体が挿入される。シリアルポートインタフェース１０５０には、例えば、マウス１１１０およびキーボード１１２０が接続される。ビデオアダプタ１０６０には、例えば、ディスプレイ１１３０が接続される。メモリ１０１０、ハードディスクドライブ１０９０、ディスクドライブ１１００、および、ディスクドライブ１１００に挿入される記憶媒体は、リソース管理装置１が備える記憶部の具体的なハードウェア資源となる。
　ここで、図９に示すように、ハードディスクドライブ１０９０は、例えば、ＯＳ１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３およびプログラムデータ１０９４を記憶する。上記実施形態で説明した各テーブルは、例えばハードディスクドライブ１０９０やメモリ１０１０に記憶される。
　また、リソース管理プログラムは、例えば、コンピュータ１０００によって実行される指令が記述されたプログラムモジュールとして、ハードディスクドライブ１０９０に記憶される。具体的には、上記実施形態で説明したリソース管理装置１が実行する各処理が記述されたプログラムモジュールが、ハードディスクドライブ１０９０に記憶される。
　また、リソース管理プログラムによる情報処理に用いられるデータは、プログラムデータとして、例えば、ハードディスクドライブ１０９０に記憶される。そして、ＣＰＵ１０２０が、ハードディスクドライブ１０９０に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出して、上述した各手順を実行する。
　なお、リソース管理プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０９０に記憶される場合に限られず、例えば、着脱可能な記憶媒体に記憶されて、ディスクドライブ１１００等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、リソース管理プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ＬＡＮ（Local　Area　Network）やＷＡＮ（Wide　Area　Network）等のネットワークを介して接続された他のコンピュータに記憶され、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。
［効果］
　上述してきたように、本実施形態は、外部情報に基づいて、サービスを提供するシステムの設計を変更するか否かを判定する判定部１６と、変更する場合、データモデルに従い、データのやり取りが可能な複数のリソースを選択する選択部（アプリ選択部１２、インフラ選択部１３）と、前記選択されたリソースを用いて、前記システムの設計を変更するためのブループリントを生成する設計部１４と、前記設計を変更したシステムに対して、前記生成したブループリントに従い、オーケストレーションを実行するオーケストレータ部１５と、を備えることを特徴とするリソース管理装置１である。
　また、本実施形態は、リソース管理装置１が、外部情報に基づいて、サービスを提供するシステムの設計を変更するか否かを判定するステップと、変更する場合、データモデルに従い、データのやり取りが可能な複数のリソースを選択するステップと、前記選択されたリソースを用いて、前記システムの設計を変更するためのブループリントを生成するステップと、前記設計を変更したシステムに対して、前記生成したブループリントに従い、オーケストレーションを実行するステップと、を実行することを特徴とするリソース管理方法である。
　これらにより、複数種類のサービスを提供するためのデータパイプラインを再設定することができる。したがって、複数種類のサービスを提供するシステムの設計変更を容易にすることができる。また、外部情報の収集を継続することにより、システムの設計変更は、人手を介さずに自動的に行うことができる。その結果、最適なシステムに収束するように自己進化させることができる。
　また、前記複数のリソースは、前記外部情報から導出される要求を満たすためのアプリ、および、前記アプリとの間にリレーションを持つインフラを含むことを特徴とする。
　これにより、要求に応じて選択したアプリに起因するデータパイプラインを再設定することができる。
　また、前記リソースは、ベストプラクティスのリソースを含むことを特徴とする。
　これにより、複数種類のサービスを提供するシステムの設計変更をより容易にすることができる。
　また、判定部１６は、前記システムのモニタリングにより取得された前記外部情報を解析して１または複数の設計変更案を導出し、所定のアルゴリズムを用いて、前記導出した設計変更案の１つを採用することを特徴とする。
　これにより、システムのモニタリングを継続することにより、システムの設計変更は、人手を介さずに自動的に行うことができる。その結果、最適なシステムに収束するように自己進化させることができる。
［変形例］
（ａ）：要求と、要求を満たすために選択されたベストプラクティスと、ベストプラクティスからなるシステムの性能値（例：スループット）の組み合わせを機械学習させたＡＩモデルを構築することができる。未知の要求を当該ＡＩモデルに入力することで、システムの性能値が所望の値となるベストプラクティスを出力として得ることができる。また、出力したベストプラクティスに対して、要求と、当該ベストプラクティスと、当該ベストプラクティスからなるシステムの性能値の組み合わせを前記ＡＩモデルに機械学習させることができ、本実施形態の設計変更処理に応用することができる。
（ｂ）：判定部１６は、複数の設計変更案（オプション）を導出した場合、導出した設計変更案の２つ以上の組み合わせを１つの新たな設計変更案とすることができる。当該新たな設計変更案のスコアが最大であった場合、判定部１６が当該新たな設計変更案を採用し、リソース管理装置１による設計変更処理を実現することができる。
（ｃ）：本発明のシステムの設計変更は、リソースの追加、削除を伴わない設計変更、つまり、システムを構成するリソース群が同じままの設計変更を含む。このような設計変更は、例えば、先述した外部情報ではなく、システムの内部情報に基づいて実行することができるが、これに限定されない。例えば、監視カメラで不審者を監視するスマートシティにおいて、不審者が検知された際、自律的に監視カメラ（インフラ）の映像の符号化レートを高めたり、自律的にネットワークの帯域を増大させたりすることで、自律的に監視カメラの映像を高精細にすることができる。
（ｄ）：本実施形態で説明した各種技術を適宜組み合わせることができる。
　１　　　リソース管理装置
　１１　　取得部
　１２　　アプリ選択部（選択部）
　１３　　インフラ選択部（選択部）
　１４　　設計部
　１５　　オーケストレータ部
　１６　　判定部
　ｄ１　　カタログ群
　ｄ２　　データモデル群
　ｄ３　　ブループリント群
　ｄ４　　ベストプラクティス群

Claims (9)

  1. 　外部情報に基づいて、サービスを提供するシステムの設計を変更するか否かを判定する判定部と、
    　変更する場合、マルチレイヤの各レイヤに配置されるリソース間のリレーションを明示したデータモデルに従い、データのやり取りが可能な複数のリソースを選択する選択部と、
    　前記選択されたリソースを用いて、前記システムの設計を変更するためのブループリントを生成する設計部と、
    　前記設計を変更したシステムに対して、前記生成したブループリントに従い、オーケストレーションを実行するオーケストレータ部と、を備えることを特徴とするリソース管理装置。
  2. 　前記複数のリソースは、前記外部情報から導出される要求を満たすためのアプリ、および、前記アプリとの間にリレーションを持つインフラを含むことを特徴とする請求項１に記載のリソース管理装置。
  3. 　前記リソースは、ベストプラクティスのリソースを含むことを特徴とする請求項１または請求項２に記載のリソース管理装置。
  4. 　前記判定部は、前記システムのモニタリングにより取得された前記外部情報を解析して１または複数の設計変更案を導出し、所定のアルゴリズムを用いて、前記導出した設計変更案の１つを採用することを特徴とする請求項１から請求項３の何れか１項に記載のリソース管理装置。
  5. 　リソース管理装置が、
    　外部情報に基づいて、サービスを提供するシステムの設計を変更するか否かを判定するステップと、
    　変更する場合、マルチレイヤの各レイヤに配置されるリソース間のリレーションを明示したデータモデルに従い、データのやり取りが可能な複数のリソースを選択するステップと、
    　前記選択されたリソースを用いて、前記システムの設計を変更するためのブループリントを生成するステップと、
    　前記設計を変更したシステムに対して、前記生成したブループリントに従い、オーケストレーションを実行するステップと、を実行することを特徴とするリソース管理方法。
  6. 　前記複数のリソースは、前記外部情報から導出される要求を満たすためのアプリ、および、前記アプリとの間にリレーションを持つインフラを含むことを特徴とする請求項５に記載のリソース管理方法。
  7. 　前記リソースは、ベストプラクティスのリソースを含むことを特徴とする請求項５または請求項６に記載のリソース管理方法。
  8. 　前記リソース管理装置が、
    　前記判定するステップにおいて、前記システムのモニタリングにより取得された前記外部情報を解析して１または複数の設計変更案を導出し、所定のアルゴリズムを用いて、導出した設計変更案の１つを採用することを特徴とする請求項５から請求項７の何れか１項に記載のリソース管理方法。
  9. 　コンピュータに、請求項５から請求項８の何れか１項に記載のリソース管理方法を実行させるためのリソース管理プログラム。
PCT/JP2020/014210 2020-03-27 2020-03-27 リソース管理装置、リソース管理方法、および、リソース管理プログラム WO2021192268A1 (ja)

Priority Applications (7)

Application Number Priority Date Filing Date Title
PCT/JP2020/014210 WO2021192268A1 (ja) 2020-03-27 2020-03-27 リソース管理装置、リソース管理方法、および、リソース管理プログラム
BR112022018999A BR112022018999A2 (pt) 2020-03-27 2020-03-27 Dispositivo de gerenciamento de recursos, método de gerenciamento de recursos, e programa de gerenciamento de recursos
EP20926535.4A EP4130980A4 (en) 2020-03-27 2020-03-27 RESOURCE MANAGEMENT APPARATUS, RESOURCE MANAGEMENT METHOD AND RESOURCE MANAGEMENT PROGRAM
CA3176911A CA3176911A1 (en) 2020-03-27 2020-03-27 Resource management device, resource management method, and resource management program
AU2020437977A AU2020437977A1 (en) 2020-03-27 2020-03-27 Resource management device, resource management method, and resource management program
JP2022510367A JP7405242B2 (ja) 2020-03-27 2020-03-27 リソース管理装置、リソース管理方法、および、リソース管理プログラム
US17/914,823 US20230133543A1 (en) 2020-03-27 2020-03-27 Resource management device, resource management method, and resource management program

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2020/014210 WO2021192268A1 (ja) 2020-03-27 2020-03-27 リソース管理装置、リソース管理方法、および、リソース管理プログラム

Publications (1)

Publication Number Publication Date
WO2021192268A1 true WO2021192268A1 (ja) 2021-09-30

Family

ID=77891130

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2020/014210 WO2021192268A1 (ja) 2020-03-27 2020-03-27 リソース管理装置、リソース管理方法、および、リソース管理プログラム

Country Status (7)

Country Link
US (1) US20230133543A1 (ja)
EP (1) EP4130980A4 (ja)
JP (1) JP7405242B2 (ja)
AU (1) AU2020437977A1 (ja)
BR (1) BR112022018999A2 (ja)
CA (1) CA3176911A1 (ja)
WO (1) WO2021192268A1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016018269A (ja) * 2014-07-04 2016-02-01 キヤノン株式会社 情報処理装置、情報処理方法及びプログラム
JP2017536608A (ja) * 2014-09-30 2017-12-07 ヒューレット パッカード エンタープライズ デベロップメント エル ピーＨｅｗｌｅｔｔ Ｐａｃｋａｒｄ Ｅｎｔｅｒｐｒｉｓｅ Ｄｅｖｅｌｏｐｍｅｎｔ ＬＰ ステージ及びバージョンポリシーを用いるトポロジーベースの管理
JP2018032897A (ja) 2016-08-22 2018-03-01 日本電信電話株式会社 事業者間一括サービス構築装置及び事業者間一括サービス構築方法

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8069242B2 (en) * 2008-11-14 2011-11-29 Cisco Technology, Inc. System, method, and software for integrating cloud computing systems
US8843633B2 (en) * 2011-03-23 2014-09-23 Bmc Software, Inc. Cloud-based resource identification and allocation
US9052961B2 (en) * 2012-03-02 2015-06-09 Vmware, Inc. System to generate a deployment plan for a cloud infrastructure according to logical, multi-tier application blueprint
WO2016138242A1 (en) * 2015-02-25 2016-09-01 Abb Technology Ag Robotic additive manufacturing apparatuses, systems and methods
US9888098B2 (en) * 2015-06-15 2018-02-06 International Business Machines Corporation Orchestrating resources in a multilayer computing environment by sending an orchestration message between layers
US11061737B2 (en) * 2018-07-27 2021-07-13 Vmware, Inc. Methods, systems and apparatus for governance of virtual computing infrastructure resources

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016018269A (ja) * 2014-07-04 2016-02-01 キヤノン株式会社 情報処理装置、情報処理方法及びプログラム
JP2017536608A (ja) * 2014-09-30 2017-12-07 ヒューレット パッカード エンタープライズ デベロップメント エル ピーＨｅｗｌｅｔｔ Ｐａｃｋａｒｄ Ｅｎｔｅｒｐｒｉｓｅ Ｄｅｖｅｌｏｐｍｅｎｔ ＬＰ ステージ及びバージョンポリシーを用いるトポロジーベースの管理
JP2018032897A (ja) 2016-08-22 2018-03-01 日本電信電話株式会社 事業者間一括サービス構築装置及び事業者間一括サービス構築方法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
HIROSHI YOSHIDA, RIICHIRO TAKE, MITSUHIRO KISHIMOTO, MASANOBU HIBI: "Service Oriented Platform", FUJITSU NO. 2010-5, vol. 61, no. 3, 10 May 2010 (2010-05-10), JP , pages 283 - 290, XP009540263, ISSN: 0016-2515 *
See also references of EP4130980A4

Also Published As

Publication number Publication date
US20230133543A1 (en) 2023-05-04
CA3176911A1 (en) 2021-09-30
EP4130980A4 (en) 2023-12-06
JP7405242B2 (ja) 2023-12-26
AU2020437977A1 (en) 2022-10-20
JPWO2021192268A1 (ja) 2021-09-30
EP4130980A1 (en) 2023-02-08
BR112022018999A2 (pt) 2022-11-01

Similar Documents

Publication Publication Date Title
US9635101B2 (en) Proposed storage system solution selection for service level objective management
US7861247B1 (en) Assigning resources to an application component by taking into account an objective function with hard and soft constraints
US9185006B2 (en) Exchange of server health and client information through headers for request management
CN105989523B (zh) 用于分析的基于策略的数据收集处理及协商的方法与***
US20190306236A1 (en) Insight for cloud migration and optimization
US8620921B1 (en) Modeler for predicting storage metrics
US9122739B1 (en) Evaluating proposed storage solutions
US10992585B1 (en) Unified network traffic controllers for multi-service environments
US20060235664A1 (en) Model-based capacity planning
US10164908B2 (en) Filtration of network traffic using virtually-extended ternary content-addressable memory (TCAM)
US20210037072A1 (en) Managed distribution of data stream contents
TWI787562B (zh) Ict資源管理裝置、ict資源管理方法以及ict資源管理程式
WO2021192268A1 (ja) リソース管理装置、リソース管理方法、および、リソース管理プログラム
WO2021192267A1 (ja) リソース管理装置、リソース管理方法、および、リソース管理プログラム
US11336518B2 (en) Staging configuration changes with deployment freeze options
Burakowski et al. Traffic Management for Cloud Federation.
WO2021192266A1 (ja) リソース管理装置、リソース管理方法、および、リソース管理プログラム
US20220215319A1 (en) Dynamic generation on enterprise architectures using capacity-based provisions
Han et al. Graph abstraction based Virtual Network management framework for SDN
JPWO2020116222A1 (ja) Ｉｃｔ資源管理装置、ｉｃｔ資源管理方法、および、ｉｃｔ資源管理プログラム
KR102543689B1 (ko) 하이브리드 클라우드 운영 시스템 및 그 제어방법과, 그 하이브리드 클라우드 운영 시스템에 포함되는 노드 배치 장치 및 그 제어방법
US20150207757A1 (en) Shared resource allocation control
JP2023024385A (ja) ユーザインターフェーススクリーンショットを自動的にキャプチャする方法、システム、及びコンピュータプログラム（ソフトウェア製品ドキュメンテーションのためのユーザインターフェーススクリーンショットの自動キャプチャ）
JP2023138908A (ja) コンピュータ実施方法、システム及びコンピュータプログラム（予測のための安定な局所的に解釈可能なモデル）

Legal Events

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

Ref document number: 20926535

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2022510367

Country of ref document: JP

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 3176911

Country of ref document: CA

REG Reference to national code

Ref country code: BR

Ref legal event code: B01A

Ref document number: 112022018999

Country of ref document: BR

ENP Entry into the national phase

Ref document number: 2020437977

Country of ref document: AU

Date of ref document: 20200327

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 2020926535

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2020926535

Country of ref document: EP

Effective date: 20221027

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 112022018999

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20220922