System configuration derivation device, system configuration derivation method, and program

Abstract

This technology provides efficient methods for deriving configuration information for systems that handle large amounts of resources. [Solution] The system comprises a configuration concretization unit that acquires the abstract configuration and the resource allocation model input as requirement data and concretizes them step by step according to predetermined rules to generate a system configuration that satisfies the requirement data, and a resource allocation unit that acquires the resource allocation model as input and outputs the resource utilization status according to the resource allocation model.

Description

Technical Field

[0001] The present disclosure relates to a system configuration derivation device, a system configuration derivation method, and a program.

Background Art

[0002] When constructing an ICT (Information and Communication Technology) system for purposes such as service operation, etc., a design operation of the system configuration is necessary. In the design operation of the system configuration, the components of the system and their connection relationships (hereinafter, these are collectively referred to as the "system configuration") necessary to satisfy the requirements (hereinafter, referred to as "system requirements") required for the desired system must be constructed without shortage, and further, all the setting items necessary for the entire system to operate normally must be correctly set, which may be a very labor-intensive operation in some cases.

[0003] The technology that automates the above design process, that is, the process of concretizing from system requirements to system configuration, is an automatic design technology. As existing automatic design technologies, although many restrict problems to a specific domain of an ICT system, for example, the arrangement of network paths or computing resources, etc., and perform automatic design by solving certain optimization problems, etc. on that basis, research is also progressing on technologies for handling general-purpose requirement descriptions.

[0004] For example, Patent Document 1 and Non-Patent Document 1 describe a technology for automatically deriving a system configuration based on functional requirements described using a general-purpose system configuration information model in a graph-like format. According to the technology described in the document, by preparing the necessary models, automatic design with general-purpose and multifaceted requirements as input becomes possible.

[0005] The requirements that can be described by the general-purpose model described in Non-Patent Document 1 are those specified by a graph-like representation in which components such as functions and devices are represented as nodes, and the relationships between these nodes are represented by edges (oriented edges) (hereinafter referred to as the "abstract configuration"). For example, the requirement that "communication via TCP (Transmission Control Protocol) is possible between two servers" is represented as an abstract configuration in which nodes corresponding to each server are connected by edges representing "TCP communication possible". The method described in Non-Patent Document 1 is a mechanism that automatically derives a method for concretizing the abstract "TCP communication possible" edge included in the above abstract configuration. (Hereafter, nodes and edges will be collectively referred to as "entities".)

[0006] It should be noted that the automated design method described in Non-Patent Document 1 does not materialize the given requirements all at once. In the aforementioned automated design method, for model data representing related information for entity types (hereinafter referred to as "types"), peripheral configuration information necessary for entities with that type to function properly as system components (hereinafter referred to as "expected configuration") is stored as data, and this is applied sequentially to the abstract configuration representing the requirements, or the types of nodes and edges are replaced with more specific types to gradually transform it into a concrete abstract configuration.

[0007] Here, "applying the expected configuration" refers to an operation performed on an abstract node or edge included in the abstract configuration (hereinafter referred to as "unit requirement"), and means adding a structure equivalent to the expected configuration to the abstract configuration for a unit requirement that does not have an expected configuration.

[0008] In contrast to the "applying expected configuration" operation, the operation of replacing an entity's type with a more specific type is called "type refinement." The operations of applying an expected configuration to an entity or refining its type are collectively called "concretization" operations.

[0009] The automated design method described in Non-Patent Document 1 can be described as a method that obtains an abstract configuration in which all unit requirements included in the input functional requirements are resolved by repeatedly concretizing the input functional requirements. Furthermore, the abstract configuration obtained in this way can be considered a completely concretized system configuration that contains no abstract elements whatsoever.

[0010] As described above, automated design becomes possible through the step-by-step concretization of functional requirements expressed in an abstract structure.

[0011] The aforementioned system requirements may include information about the "resources" that can be used to build the system, in addition to information about the functions to be implemented as a service.

[0012] For example, by specifying a group of machines owned by the service operator as the information processing equipment to deploy the application that operates the service, it is possible to design a system configuration in which the application is deployed on the specified group of machines.

[0013] The examples mentioned above are specific examples of physical resources, but the resources dealt with in this invention also include virtual / logical resources.

[0014] For example, services that need to be exposed over a network require an address (IP address) for external access, but there are limitations on the IP addresses that can be specified. Therefore, by specifying a set of addresses available to the service operator as assignable IP addresses, it is possible to design a system configuration in which an appropriate address is selected from the available addresses for each service.

[0015] When handling requirements that include available resources within the automated design framework described in Non-Patent Document 1, there is a problem in that the computation time increases proportionally to the number of specified resources. In particular, in large-scale systems, it is not uncommon for hundreds of machines to be specified, and the number of available IP addresses can easily reach tens of thousands.

[0016] In the cases described above, if we consider treating each resource as a node in a graph-like structure and applying the automated design described in Non-Patent Document 1, the design efficiency becomes extremely poor due to the following two problems.

[0017] (1) If the data structure itself, which is treated as an abstract configuration in the design process, is large, the computation time for the entire search process, which generates many abstract configurations as candidate configurations, will become excessively long.

[0018] (2) If we were to generate a design candidate for every possible use of a large number of resources, the number of design candidates that would appear during the search process would become enormous.

[0019] These problems arise from treating each resource as an individual node, but since it is ultimately necessary to output the usage patterns of each individual resource as a system configuration, it is also inappropriate to simply treat resources as a single unit. [Prior art documents] [Patent Documents]

[0020] [Patent Document 1] Patent No. 6989014 [Non-patent literature]

[0021] [Non-Patent Document 1] Takayuki Kuroda, Takuya Kuwahara, Takashi Maruyama, Kozo Satoda, Hideyuki Shimonishi, Takao Osaki and Katsushi Matsuda, “Weaver: A Novel Configuration Designer for IT / NW Services in Heterogeneous Environments”, 2019 IEEE Global Communications Conference (GLOBECOM), 2019, pp. 1-6.

Summary of the Invention

Problems to be Solved by the Invention

[0022] If an entity that uses resources in a system configuration is called a “consumer”, in order to solve the above problems, while appropriately managing the information on the relationship between consumers and resources, it is necessary to devise a way to represent the set of resources not as a set of individual entities but by a more efficient data structure.

[0023] Therefore, the present disclosure provides a technique for solving the above problems and efficiently deriving configuration information of a system that handles a large amount of resources.

Means for Solving the Problems

[0024] According to one aspect of the present disclosure, the system configuration derivation device includes, when abstract configuration is system configuration information which may include an abstract configuration expressed as graph data connecting nodes and edges, resources are resources required for the normal operation of the system components, consumers are the components that request the resources, resource groups are objects corresponding to a collection of the resources, resource utilization status is data defining the resources used by the consumers and the resources included in the resource groups, and resource allocation model is data showing the correspondence between the consumers included in the abstract configuration and the resource groups to be allocated to those consumers, a configuration concretization unit that acquires the abstract configuration and the resource allocation model input as requirement data and concretizes them step by step according to predetermined rules to generate a system configuration that satisfies the requirement data, and a resource allocation unit that acquires the resource allocation model as input and outputs the resource utilization status according to the resource allocation model.

[0025] According to one aspect of this disclosure, an abstract configuration is system configuration information which may include an abstract configuration expressed as graph data connecting nodes and edges; a resource is a resource required for the normal operation of the system's components; a consumer is the component that requests the resource; a resource group is an object corresponding to a collection of the resources; resource utilization status is data that defines the resources used by the consumer and the resources included in the resource group; and a resource allocation model is data that shows the correspondence between the consumer included in the abstract configuration and the resource group to be allocated to that consumer. The computer then obtains the abstract configuration and the resource allocation model input as requirement data, and generates a system configuration that satisfies the requirement data by stepwise concretizing them according to predetermined rules, obtains the resource allocation model as input, and outputs the resource utilization status according to the resource allocation model.

[0026] According to one aspect of the present disclosure, an abstract configuration of a program may include configuration information of a system that can be represented as graph data connecting nodes and edges. A resource is a resource required for the normal operation of a component of the system. A consumer is a component that requests the resource. A resource group is an object corresponding to a set of the resources. A resource usage status is data that defines the resources used by the consumer and the resources included in the resource group. When a resource allocation model is data indicating a correspondence relationship between the consumer included in the abstract configuration and the resource group to be allocated to the consumer, the computer acquires the abstract configuration and the resource allocation model input as requirement data, and generates a system configuration that satisfies the requirement data by gradually concretizing according to a predetermined rule. The computer acquires the resource allocation model as an input, and executes a process of outputting the usage status of the resources according to the resource allocation model.

Advantages of the Invention

[0027] According to the present disclosure, it is possible to efficiently derive configuration information of a system that handles a large amount of resources.

Brief Description of the Drawings

[0028] [Figure 1] It is a block diagram showing a configuration example of a system configuration derivation device according to the first embodiment. [Figure 2] It is a block diagram showing a configuration example of a system configuration derivation device according to the second embodiment. [Figure 3] It is a flowchart for explaining the operation of a configuration concretization unit 101 of a system configuration derivation device according to the first embodiment. [Figure 4A] It is a first flowchart for explaining the operation of a resource allocation unit 102 of a system configuration derivation device according to the first embodiment. [Figure 4B]This is a second flowchart illustrating the operation of the resource allocation unit 102 of the system configuration derivation device according to the first embodiment. [Figure 5] This is an explanatory diagram showing an example of a configuration according to the first embodiment. [Figure 6] This is an explanatory diagram showing an example of the expected configuration defined in the component model according to the first embodiment. [Figure 7A] This is the first explanatory diagram showing an example of implementation based on the expected configuration according to the first embodiment. [Figure 7B] This is a second explanatory diagram showing an example of implementation based on the expected configuration according to the first embodiment. [Figure 7C] This is a third explanatory diagram showing an example of implementation based on the expected configuration according to the first embodiment. [Figure 8] This is an explanatory diagram showing a resource allocation model in which a group of proxy resources has been added by the resource allocation unit 102 of the first embodiment. [Figure 9] This is an explanatory diagram showing an example of an abstract configuration input to the system configuration derivation device 200 of the second embodiment. [Figure 10] This is an explanatory diagram showing a proposed configuration obtained as a result of transforming the abstract configuration 900 by the resource data extraction unit 201 of the second embodiment. [Figure 11] This is an explanatory diagram showing an example of an abstract configuration and resource utilization status input to the resource data reflection unit 202 of the second embodiment. [Figure 12] This is an explanatory diagram showing the abstract configuration obtained as a result of converting the configuration plan shown in Figure 11 by the resource data reflection unit 202 of the second embodiment. [Figure 13] This is a block diagram showing an example configuration of a system configuration derivation device according to the third embodiment. [Figure 14] This flowchart shows an example of the operation of the system configuration derivation device according to the third embodiment. [Figure 15] This figure shows an example of the hardware configuration of the system configuration derivation device according to each embodiment. [Modes for carrying out the invention]

[0029] The system configuration derivation devices according to each embodiment of this disclosure will be described below with reference to the drawings. In the drawings used in the following description, the configurations of parts not related to this disclosure may be omitted from the description and not shown. In all drawings, the same reference numerals are used for identical or equivalent components, and common descriptions may be omitted.

[0030] As described in the following embodiments, this disclosure proposes including a "resource allocation model" in the proposed configuration that treats a group of resources as a single "set" while simultaneously maintaining information about the correspondence between that group of resources and the consumers who use them.

[0031] In other words, as data representing the configuration proposal in the automated design described in Non-Patent Document 1, in addition to the abstract configuration, data representing the "resource utilization status (=correspondence with consumers)" (=resource allocation model) for entities corresponding to resources is included, thereby realizing a system configuration derivation process that balances conciseness as a data representation with expressive power to appropriately represent the form of resource utilization.

[0032] This disclosure provides a system configuration derivation device comprising a configuration concretization method that enables the stepwise concretization of a resource allocation model, similar to an abstract configuration, and a resource allocation method that outputs "resource allocation to each consumer" from the completed resource allocation model.

[0033] <First Embodiment> (composition) Figure 1 is a block diagram showing an example configuration of a first embodiment of the system configuration derivation device according to this disclosure. The system configuration derivation device 100 of the first embodiment includes a configuration concretization unit 101 that receives an abstract configuration, which is part of the system requirements, and a resource allocation model and component model necessary for concretizing the system requirements, which are also part of the system requirements, as inputs, and derives a system configuration by concretizing the input abstract configuration and resource allocation model step by step.

[0034] The system configuration derivation device 100 of the first embodiment includes a resource allocation unit 102 that receives a resource allocation model as input and clarifies the resource utilization status represented by the resource allocation model. If there is no valid resource allocation for the input resource allocation model, the resource allocation unit 102 notifies "unavailable" instead of returning a result.

[0035] The configuration concretization unit 101 obtains a configuration proposal that corresponds to a specific system configuration by progressively transforming data (hereinafter referred to as "configuration proposal") that associates an abstract configuration with a resource allocation model related to the abstract configuration.

[0036] The following describes the details of the abstract configuration and resource allocation model, which are data handled by the configuration concretization unit 101.

[0037] First, the resource allocation model in this invention will be explained. A resource allocation model is data composed of five types of information: a set of physical and logical resources that may be included in the system configuration (hereinafter referred to as "resource group"), the target that will use the resources (hereinafter referred to as "consumer"), the inclusion relationships between resource groups, the exclusivity relationships between resource groups, and the relationship between resource groups and consumers (hereinafter referred to as "consumption relationship"). It is data that expresses constraints on resource utilization.

[0038] In the following explanation, we will use the example where the resource is memory. However, in this embodiment, "resource" is not limited to so-called computer resources such as CPU and memory, but also includes system resources, addresses, ports, network bandwidth, licenses, etc., that system components need to occupy for their normal operation. For example, an "application" requires a "host machine" to run. In this case, the resources are the CPU, memory, HDD, etc., of the host machine. As another example, a "front-end application" requires a "port (to listen for access)" to run, and in this case, the port is a resource. "User access to a service (provided by a system)" requires "network bandwidth (corresponding to the service load)" to run, and in this case, the network bandwidth is a resource. "Windows®" OS requires a "purchased Windows® license" to run, and in this case, the purchased license is a resource.

[0039] In a resource allocation model, a set of resources is an object that corresponds to a collection of resources. A resource group may have detailed information about the specific resources it contains. Even if a resource group does not have detailed information about the specific resources it contains, it may only have information about the quantity of resources it contains (hereinafter referred to as "resource capacity").

[0040] Consumers in the resource allocation model are objects that have an identifier to distinguish them from each other and an attribute that specifies the "quantity of resources needed" (hereinafter referred to as "requested resource count"). Each consumer must be allocated resources equal to the number of requested resources, in order to satisfy the constraints expressed by the resource allocation model. However, the same resource cannot be allocated to two or more different consumers. Furthermore, the resource groups and consumers in the resource allocation model are assumed to have identifiers to refer to themselves.

[0041] The inclusion and exclusion relationships in resource allocation models are the usual inclusion and exclusion relationships for two sets of resources. In this specification, B⊆A indicates that resource group A includes resource group B, meaning all resources included in resource group B are also included in resource group A. Conversely, A≠B indicates that resource group A and resource group B are mutually exclusive, meaning that resource group A and resource group B do not share any resources as elements.

[0042] The consumption relationship in the resource allocation model is "consumer p must be allocated resources included in resource group A," which is denoted as p→A in this specification. This relationship only expresses that consumer p is allocated resources included in resource group A in quantities equal to the number of resources requested by p, and does not contain any information specifying the resources to be allocated.

[0043] The resource allocation model 501 in Figure 5 is a specific example of a resource allocation model. The resource allocation model shown in this example will be explained below.

[0044] The black, rounded rectangles represent consumers, and resource allocation model 501 contains only one consumer labeled "FE(Req:3)". This consumer has "FE" as its identifier and requests 3 resources.

[0045] The rectangles represent resource groups, and resource allocation model 501 contains three resource groups labeled "MachinePool_1 (Size: 800)", "MachinePool_2 (Size: 480)", and "MX_1 (size: 8)". These are resource groups with identifiers "MachinePool_1", "MachinePool_2", and "MX_1", respectively, and resource capacities of "800", "480", and "8", respectively. Furthermore, the resource groups "MachinePool_1" and "MachinePool_2" have separately defined sets of resources, namely "memory resources installed on physical machines X00, X01, ..., X99" and "memory resources installed on physical machines Y00, Y01, ..., Y29", respectively (not shown).

[0046] Arrows pointing from consumers to resource groups represent consumption relationships. Resource allocation model 501 includes an arrow pointing from consumer FE to resource group MX_1, indicating that the consumption relationship "FE→MX_1" is included in the resource allocation model.

[0047] The inclusion relationship is represented by showing that one resource group A is completely contained within another resource group. In resource allocation model 501, resource group MX_1 is contained within resource group MachinePool_1, which indicates that the inclusion relationship "MX_1⊆MachinePool_1" is included in the resource allocation model.

[0048] The double line connecting resource groups indicates mutual exclusion. In resource allocation model 501, resource group MachinePool_1 and resource group MachinePool_2 are connected by a double line, which indicates that the mutual exclusion relationship "MachinePool_1 ≠ MachinePool_2" is included in the resource allocation model.

[0049] The resource allocation model described in resource allocation model 501 means that MachinePool_1 and MachinePool_2 exist as available computing resources, and that the resources of server MX_1, which is included in MachinePool_1, will be consumed in order to run the application indicated by FE.

[0050] In this example, instead of using a set of machines as a resource to represent computing resources, we consider the total amount of memory (RAM, Random Access Memory) installed in the machines. In resource allocation models, one resource cannot be allocated to multiple consumers, so if we define a resource as "one machine," only one application can be hosted on one machine. By defining the memory installed in a machine as a resource, applications can be hosted on the same machine as long as the memory capacity is not exhausted. In reality, there are other resources that should be considered when deciding on a host server besides memory capacity, but here we have simplified it to memory usage for the sake of explaining the idea. The above is a description of the resource allocation model in the present invention.

[0051] The abstract configuration and its data structure in this embodiment will be described below. An abstract configuration refers to an abstract system configuration that includes parts that are not yet determined regarding the configuration and settings. The abstract configuration plays the role of defining the desired system without specifically mentioning the details of the system, by writing down only the information that is determined by the entity that desires the ICT system, that is, the information that represents "what requirements the system should meet and what functions it should have".

[0052] The abstract structure is based on a graph consisting of "nodes," which correspond to the functions and logical / physical components of a system, and "edges," which represent the relationship between two nodes by being drawn between them. The aforementioned edges have a direction, and for an edge that goes from node n1 to node n2, node n1 is called the "source" and node n2 is called the "destination." Furthermore, when nodes and edges are referred to without distinction below, they will be collectively called "entities."

[0053] An entity has data consisting of an "identifier" to uniquely identify the entity throughout the system, a "type" that expresses what concept the entity corresponds to, and a "satisfaction flag" that manages whether or not an expected configuration has been applied. The identity of an entity in two different abstract configurations is determined by its identifier. In other words, even if the types are different, if the identifiers are the same, they are treated as the "same entity".

[0054] Abstract configuration 500 in Figure 5 is an example of an abstract configuration. Nodes are represented by rectangles labeled "(identifier):(type name)", and edges are represented by arrows labeled "(identifier):(type name)". The label "(identifier):(type name)" represents "an entity whose type is (type name) and whose identifier is (identifier)". In addition, properties may be specified for entities using callouts.

[0055] The abstract configuration described in Abstract Configuration 500 includes four nodes: FE: FrontEnd, BE: BackEnd, MachinePool_1: MachineXPool, and MachinePool_2: MachineYPool, as well as two edges: Acc: Access and Hst: Host. Acc is the edge from FE to BE, and Hst is the edge from FE to MachinePool_1.

[0056] Nodes FE and BE correspond to the front-end application and back-end application, respectively. FE and BE have the properties "Required Memory: 3GB" and "Required Memory: 6GB" specified, respectively, where "Required Memory" represents the amount of memory required for normal operation.

[0057] The node MachineXPool and MachineYPool are types that represent sets of physical machine resources with model numbers "MachineX" and "MachineY," respectively. MachinePool_1 and MachinePool_2 represent sets of available physical machine resources with model numbers "MachineX" and "MachineY," respectively. MachinePool_1 and MachinePool_2 have the properties "Installed memory: 8GB, Number of units: 100" and "Installed memory: 16GB, Number of units: 30," respectively. "Installed memory" represents the amount of memory installed per unit, and "Number of units" represents the number of servers included in the resource set.

[0058] Edge Acc represents access from the frontend (FE) to the backend (BE). The Access type means that access between applications is possible, but it does not include information on how access is specifically enabled. Therefore, it needs to be concretized by supplementing the surrounding structure through the application of the expected configuration described later, or by representing it in the resource allocation model.

[0059] Edge Hst indicates that the frontend FE will use a machine included in MachinePool_1 as its host. The specific machine to be used is not included in the abstract configuration 500, but is represented by the associated resource allocation model. For example, if resource allocation model 501 is associated with abstract configuration 500, the machine corresponding to resource group MX_1 in resource allocation model 501 will be the host machine. The above is an explanation of Abstract Construction 500.

[0060] The following provides a more detailed explanation of entity "types". The type of an entity indicates what kind of entity it is. There are two types: "abstract types" and "concrete types." Abstract types, such as "Machine" or "HTTP-enabled," represent entities that do not intuitively correspond to concrete parts or connections that actually exist in reality, and require further concretization. On the other hand, concrete types represent entities that correspond to concrete parts or connections that actually exist in reality, such as "(specific machine model number)" or "wired LAN connection."

[0061] Furthermore, inheritance relationships can be defined between different types. When type Ta inherits type Tb, it means that entities of type Ta can also be considered entities of type Tb. For example, type MachineX, which corresponds to the model number of a specific machine, inherits type PhMachine, which represents "all physical machines". In addition, type PhMachine inherits type Machine, which represents "(all machines, whether physical or virtual)". Moreover, every abstract type is assumed to have one or more concrete types that inherit it, and no types are assumed to inherit concrete types.

[0062] Model data that defines information specific to each type is called the "component model" for that type. Various types of information can be defined in a component model, but in this disclosure, we assume that it includes "property" and "expected configuration" data.

[0063] The "properties" of a component model are a list of attribute information that can be set on an entity of that type.

[0064] The "expected configuration" of a component model is data that defines information about the peripheral configuration necessary for an entity of that type to function correctly in the system. The configuration concretization unit 101 gradually transforms the proposed configuration into a specific system configuration by repeatedly performing operations to supplement the components and relationships included in the expected configuration.

[0065] The expected configuration of a type includes graph data representing the peripheral configurations necessary for entities of that type to function correctly in the system, as well as rules for transforming the resource allocation model of the configurations to which the expected configuration applies.

[0066] The expected configuration will be explained in detail below using an example. For example, the fact that an "application" requires a "physical machine" to host it is expressed as an expected configuration of type App, which corresponds to the "application". The expected configuration 600 shown in Figure 6 is expected configuration data that expresses the aforementioned fact.

[0067] Abstract configuration 601 is a graph that represents the configuration in which an application equivalent to an App-type node is hosted on a machine, as a peripheral configuration necessary for the App-type node to function correctly. The App-type node SELF and the MachinePool-type node Ms, which represents a collection of resources consisting of machines, are connected by a Host-type edge H.

[0068] A Host-type edge H represents a relationship where "an App-type node SELF is hosted on the physical machine resources represented by node M."

[0069] Furthermore, "SELF" is a special identifier, and each expected configuration represents the structure necessary for the entity with identifier "SELF" to function correctly. In other words, there is exactly one entity with identifier SELF in every expected configuration. Hereafter, this "SELF" entity will be referred to as the target entity of the expected configuration.

[0070] The expected configuration has certain entities, including SELF nodes, designated as "prerequisite configurations." Prerequisite configurations are those that must be included in the abstract configuration to be applied when the expected configuration is applied (described later). In the diagrams of this specification, entities included in prerequisite configurations will be drawn with double lines.

[0071] For example, in the expected configuration 600 shown in Figure 6, the nodes SELF and Ms are drawn with double lines, indicating that the prerequisite configurations for these expected configurations are nodes SELF and Ms.

[0072] Transformation operation 602 is data that defines three modification operations (transformation operations 602-1, 2, and 3) that should be performed on the resource allocation model of the configuration to which the expected configuration is applied, in order to express various constraints on the resources consumed by the App-type node SELF.

[0073] Conversion operation 602-1 is an operation to create a new consumer "SELF" that consumes resources from the resource group "MXs". Since the consumer "SELF" corresponds to the App type node "SELF", the requested resource amount is set to a value equal to the requested memory amount set for the App type node "SELF".

[0074] Conversion operation 602-2 is an operation to extract a resource group equivalent to one machine from the resource group "MXs" as resource group "m". In this operation, (1) resource group "m" is selected from one already included in resource group "Ms", or (2) a new resource group "m" is created and the inclusion relationship "m⊆Ms" and the exclusion relationship "m≠m' (m' is all resource groups other than m such that m⊆MXs)" are added. Whether or not to add a new resource group is left to the user's discretion, and if a new resource group "m" is added, its resource capacity will be equal to the amount of installed memory set on the MachinePool type node Ms.

[0075] Conversion operation 602-3 adds a consumption relationship "SELF → m" between the consumer "SELF" and the resource group "m". The above is an explanation of the expected configuration 600.

[0076] An expected configuration can have more than one set for a single type. In that case, if any one of the multiple expected configurations is applied, it means that the entity of that type will function correctly.

[0077] Furthermore, some types have no expected configuration specified, meaning they do not require any dependent components and can function correctly as a standalone system component. The above is an explanation of the "expected configuration" of the type.

[0078] Next, we will explain the entity's "satisfaction flag". An entity of type T is associated with a set of flags whose keys are all ancestor types T(1), T(2), ..., T(m) of type T, and type T itself. These are called the satisfaction flags of the entity. Each flag is assigned a value of either TRUE or FALSE.

[0079] When all satisfaction flags are TRUE, the satisfaction flags are said to be satisfied, and when any are FALSE, the satisfaction flags are said to be lacking. In particular, when the flags relating to type T(i) are FALSE, the entity is said to be lacking with respect to type T(i). As will be explained later, an expected construction of type T(i) can be applied to an entity that is lacking with respect to type T(i), and the flags become TRUE at the same time as the application.

[0080] Furthermore, entities originally included in the abstract construction and entities newly generated by applying the expectation construction (described later) are assigned a satisfaction flag with itself and its ancestor type as keys. The initial value of each flag is FALSE if an expectation construction exists for the key type, and TRUE otherwise. The above explains the "satisfaction flag" of an entity.

[0081] Next, we will explain how to concretize the proposed structure. There are two ways to concretize a proposed structure: "applying the expected structure" and "further refining the type." In either case, one or more new proposed structures can be obtained as a result of the operation.

[0082] First, the "application of the expected configuration" to configuration D is carried out according to the following steps.

[0083] 1. Select entity e, which is included in the abstract structure of D and lacks a satisfaction flag.

[0084] 2. Select the missing type T for entity e.

[0085] 3. For each expected configuration EX of type T whose abstract configuration D includes a prerequisite configuration, the result of applying the following operation to the abstract configuration D is output as the result of the "Apply Expected Configuration" operation: "The abstract construction of the expected construction EX adds the necessary entities to the abstract construction of D so that entity e appears in a form that matches SELF, and the resource allocation model of D is rewritten according to the resource allocation model rewriting rules defined in the expected construction. Then, the satisfaction flag for type T of entity e is updated to TRUE."

[0086] The above is an explanation regarding the application of the expected configuration. However, there may be multiple ways to perform the transformation in Step 3 for a single expected configuration. The following sections will explain such cases using specific examples.

[0087] Figures 7A to 7C illustrate examples of how the proposed configuration described in Figure 5 can be realized in three different ways using the expected configuration shown in Figure 6.

[0088] In this example, it is assumed that the FrontEnd and BackEnd types inherit from the App type, and the MachineXPool and MachineYPool types inherit from the MachinePool type.

[0089] The three configuration options, 700, 701, and 702, are all configuration options obtained by applying the expected configuration 600 to the node BE within the abstract configuration 500, but each has a different host machine for the BE.

[0090] Configuration plan 700 in Figure 7A uses a machine with model number "MachineX" as the host for node BE, but it is a different machine from the host for node FE. Implementing configuration plan 700 is possible by selecting node MachinePool_1 from abstract configuration 500 as the node corresponding to node Ms in Figure 6, and then creating a new resource group "MX_2" as resource group "m" in conversion operation 602-2.

[0091] Configuration plan 701 in Figure 7B is a case where the host destination of node BE is a machine with the same model number "MachineX" as the host destination of node FE. Implementing configuration plan 701 is possible by selecting node MachinePool_1 from abstract configuration 500 as the node corresponding to node Ms in Figure 6, and then selecting the existing resource group "MX_1" as the resource group "m" in conversion operation 602-2.

[0092] Configuration plan 702 in Figure 7C is a case where the machine with model number "MachineY" is used as the host for node BE. Implementing configuration plan 702 is possible by selecting node MachinePool_2 from abstract configuration 500 as the node corresponding to node Ms in Figure 6, and then creating a new resource group "MY_1" as resource group "m" in conversion operation 602-2.

[0093] As mentioned above, if there are multiple ways to bring the abstract configuration of the expected configuration into the abstract configuration to be applied, or if there are branches in the operation of the resource allocation model, then multiple concrete implementations are possible from the application of a single expected configuration. The above is an explanation of the application of the expected configuration using a concrete example.

[0094] Secondly, the "type refinement" operation for configuration D is performed according to the following steps.

[0095] 1. Select entity e, which has an abstract type, that is included in the abstract structure of 1.D.

[0096] 2. For all types T' that inherit type T of entity e, the following operation is performed on the abstract construction of D, and the result is output as the "Type Refinement" operation: "Change the type of entity e to T', and add a flag with T' as the key to the satisfactoriness flag. However, the value of the flag for T' will be FALSE if there is one or more expected configurations in T', and TRUE if there are no such configurations." The above is an explanation of how the proposed structure will be concretized.

[0097] Next, we will explain the definition of a "specific structural plan" obtained by concretizing the structural plan. In this disclosure, a specific proposed structure refers to a proposed structure that includes a fully materialized abstract structure. Here, an abstract structure is considered "fully materialized" if it satisfies all of the following three materialized conditions: (Materialized Condition 1), (Materialized Condition 2), and (Materialized Condition 3).

[0098] (Confirmed condition 1) The abstract structure does not contain any nodes with an abstract type.

[0099] (Concretized condition 2) The abstract construction does not contain any edges that have an abstract type.

[0100] (Concretized condition 3) The abstract structure does not contain any entities that lack a satisfaction flag.

[0101] Based on the definition of specified conditions, an abstract configuration that does not include unit requirements can be said to represent a state in which there are no ambiguities whatsoever as an ICT system, and all the necessary components for operation (= expected configuration for each entity) are present.

[0102] Next, we will explain "resource utilization status," which is data that represents the specific form of resource allocation as expressed by the resource allocation model.

[0103] "(A reasonable resource utilization situation for a resource allocation model)" refers to dictionary data Rs that represents the allocation of a specific set of resources to all consumers or resource groups included in the resource allocation model, and that satisfies all of the following conditions (1) to (6).

[0104] (1) The quantity of resource Rs[c] allocated to consumer c is equal to the amount of resource requested by consumer c.

[0105] (2) The quantity of resources Rs[R] allocated to resource group R for which resource capacity is defined is equal to the resource capacity defined for resource group R.

[0106] (3) For any two different consumers c1 and c2, the allocated resources Rs[c1] and Rs[c2] do not overlap.

[0107] (4) For any two mutually exclusive resource groups R1 and R2 (R1≠R2), the allocated resources Rs[R1] and Rs[R2] do not overlap.

[0108] (5) For all two resource groups R1 and R2 that are in a containment relationship (R1⊆R2), the allocated resources satisfy the containment relationship Rs[R1]⊆Rs[R2].

[0109] (6) If consumer c and resource group R are in a consumption relationship c→R, then the allocated resources satisfy the inclusion relationship Rs[c]⊆Rs[R].

[0110] While the resource allocation model represents the constraints on the resources that consumers use, resource utilization represents the specific methods of allocating resources that satisfy those constraints.

[0111] The concretized abstract configuration and resource utilization correspond to the configuration and resource allocation of a fully functional system, respectively.

[0112] Therefore, the system configuration derivation device 100 outputs a set of a concrete abstract configuration and resource allocation as information representing the system configuration.

[0113] (operation) The system configuration derivation device 100 receives system requirements consisting of an abstract configuration and a resource allocation model as input, and outputs a concrete abstract configuration and resource utilization status that satisfy the system requirements.

[0114] The following describes in detail the processing of each part of the system configuration derivation device 100. First, the operation of the configuration implementation unit 101 of the first embodiment in which the configuration plan is implemented will be described.

[0115] The configuration concretization unit 101 of the first embodiment is basically the same as the configuration concretization procedure described in Patent Document 1, but differs in that it includes a step in which, in addition to the abstract configuration, it receives a resource allocation model as input, the resource allocation unit 102 verifies the resource allocation model in the process of concretization, and removes configuration proposals that require invalid resource allocation.

[0116] Figure 3 is a flowchart illustrating the procedure by which the configuration concretization unit 101 of the first embodiment derives the concretized abstract configuration and resource utilization status in relation to the system requirements.

[0117] The configuration concretization unit 101 receives a configuration proposal D_init corresponding to the system requirements as input from the input / output device (step S300). The configuration proposal D_init includes an abstract configuration and a resource allocation model related to the abstract configuration.

[0118] The configuration concretization unit 101 initializes the search candidate list T with an empty list (step S301).

[0119] The configuration concretization unit 101 initializes the searched configuration list V with an empty list (step S302).

[0120] The configuration concretization unit 101 adds D_init to T and V (step S303).

[0121] The configuration concretization unit 101 proceeds to step S305 if the search candidate list T contains a configuration proposal and T does not contain a specific configuration proposal; otherwise, it proceeds to step S314. (Step S304)

[0122] The configuration concretization unit 101 selects one of the configuration proposals D included in T (step S305).

[0123] The configuration concretization unit 101 generates configurations D_1, D_2, ..., D_N by concretizing the configuration D selected in step S305 (step S306).

[0124] The configuration concretization unit 101 executes the procedures from step S308 to step S311 for each configuration proposal D_i generated in the previous step (step S307).

[0125] The configuration concretization unit 101 returns to step S307 if D_i is included in the searched configuration list V, and proceeds to step S309 (step S308) if it is not included.

[0126] The configuration concretization unit 101 inputs the resource allocation model of D_i to the resource allocation unit 102 and verifies the output. If "allocation not possible" is notified, the process returns to step S307. If a resource allocation is output, the process proceeds to step S311 (step S310).

[0127] The configuration concretization unit 101 adds configuration plan D_i to T (step S311).

[0128] The configuration concretization unit 101 executes the procedures from steps S308 to S311 for all configuration proposals D_i generated in step S306, and then returns to step S304 (step S312).

[0129] The configuration concretization unit 101 inputs the resource allocation model of the specific configuration proposal D_out included in the search candidate list T to the resource allocation unit 102 and obtains the resource utilization status Rs as output. If the specific configuration proposal is not included in the search candidate list T, a search failure is notified (step S313).

[0130] The configuration concretization unit 101 outputs a pair of the abstract configuration of the specific configuration plan D_out and the resource utilization status Rs to the input / output device as the result of the system configuration derivation device 100 (step S314). The above is a description of the operation of the configuration implementation unit 101.

[0131] Next, the operation of the resource allocation unit 102 will be described. The resource allocation unit 102 of the first embodiment receives a resource allocation model as input and returns a reasonable resource utilization status.

[0132] The resource allocation unit 102 of this embodiment expresses the various relationships included in the resource allocation model as a linear constraint problem on integer variables, and determines the final resource utilization status by finding the allocation to variables that satisfy this problem. A linear constraint problem on integer variables is a problem in which a group of variables X[1], X[2], ..., X[n] to which integers can be allocated are defined, and linear constraints relating to them are defined, i.e., equalities or inequalities that do not involve multiplication of variables (for example, "X[1]==X[2]+X[4]", "5*X[1]≦3*X[3]+4", etc.), and the allocation of values ​​to variables that satisfy all constraints is the solution to this problem.

[0133] The operation of the resource allocation unit 102 in step S313 is described in detail below. Figures 4A and 4B are flowcharts showing the overall operation of the resource allocation unit 102.

[0134] The resource allocation unit 102 receives the resource allocation model RC as input (step S400).

[0135] The resource allocation unit 102 initializes the resource utilization status Rs with an empty dictionary. It also initializes the variable group Vs and the constraint group Cs with empty lists (step S401).

[0136] The resource allocation unit 102 adds a new resource group Proxy[c] to the resource allocation model RC for all consumers c included in the RC, and sets the resource capacity to the amount of resources requested by consumer c (step S402).

[0137] In the following explanation, Proxy[c] will be referred to as the "proxy resource group" for consumer c. The resource allocation unit 102 adds a new inclusion relationship Proxy[c]⊆R to all consumption relationships c→R included in the resource allocation model RC (step S403).

[0138] The resource allocation unit 102 adds the exclusive constraint Proxy[c1]≠Proxy[c2] to the RC for all pairs of two different proxy resource groups, Proxy[c1] and Proxy[c2] (step S404).

[0139] The resource allocation unit 102 determines a one-to-one correspondence ValueMap that associates all resources included in the resource allocation model RC with integer values ​​from 0, 1, ..., (total number of resources). At this time, the resource group R, whose set of included resources is fixed, is associated with a single interval. That is, when the set of all resources included in the resource group R is transformed by the ValueMap, the set {LB[R], LB[R]+1, ..., UB[R]-1, UB[R]} is obtained. The integers LB[R] and UB[R] are called the lower and upper bounds of the resource group R (step S405).

[0140] The resource allocation unit 102 executes the procedures from steps S407 to S411 for all resource groups R included in the resource allocation model RC (step S406).

[0141] The resource allocation unit 102 adds two integer variables, Lower[R] and Upper[R], to the variable group Vs (step S407).

[0142] The resource allocation unit 102 executes step S409 if the set of resources included in resource group R has been determined, and step S410 otherwise (step S408).

[0143] The resource allocation unit 102 adds the constraints "Lower[R]==LB[R]" and "Upper[R]==UB[R]" to the constraint group Cs and executes step S412 (step S409).

[0144] The resource allocation unit 102 executes step S411 if the resource capacity of resource group R has been determined, and step S412 otherwise (step S410).

[0145] The resource allocation unit 102 adds the constraint "Lower[R] + (resource capacity of R) - 1 == Upper[R]" to the constraint group Cs and executes step S412 (step S411).

[0146] The resource allocation unit 102 generates two constraints, "Lower[R2]≦Lower[R1]" and "Upper[R1]≦Upper[R2]", for all inclusion relationships R1⊆R2 included in the resource allocation model RC, and adds them to the constraint group Cs (step S413).

[0147] The resource allocation unit 102 generates the variable ORD[R1,R2] for all mutual exclusion relationships R1≠R2 included in the resource allocation model RC and adds it to the variable group Vs. Furthermore, it generates four constraints "0≦ORD[R1,R2]", "ORD[R1,R2]≦1", "Upper[R1]+1≦Lower[R2]+(total number of resources)×ORD[R1,R2]", and "Upper[R2]+1≦Lower[R1]+(total number of resources)×(1-ORD[R1,R2])" and adds them to the constraint group Cs (step S414).

[0148] The four constraints added in step S414 are essentially the same as "Upper[R1]+1≦Lower[R2] or Upper[R2]+1≦Lower[R1]". This takes the form of a disjunctive constraint (a constraint of the form that one of two constraints must be true) because it is unclear which of the mutually exclusive R1 and R2 contains the resource with the "lower" number.

[0149] Since disjunction constraints often take a long time to resolve, we may determine the order between the lower-numbered resource group (RL) and the lower-numbered resource group (RU) without loss of generality, only if we can identify which of the mutually exclusive R1 and R2 contains the lower-numbered resource, or make an assumption without loss of generality. In such cases, we may add a single constraint, "Upper[RL]+1≦Lower[RU]", instead of four constraints.

[0150] The resource allocation unit 102 seeks a solution, Assign, to the linear constraint problem defined by the constraint group Cs on the variable group Vs (Assign represents the correspondence between variables and integer values). However, if no solution exists, it notifies "Assignment not possible" and terminates (step S415).

[0151] The method for solving the linear constraint problem performed by the resource allocation unit 102 in step S415 is not particularly limited and may be a known method. Specifically, well-known methods include the branch-and-bound method, which obtains the solution to the original problem by repeatedly solving a simpler problem (relaxed problem) obtained by relaxing the variables from integers to real numbers; the cutting plane method, which obtains an integer solution by solving the relaxed problem and then solving a problem with added constraints so that the solution is an integer; and the branch-and-cut method, which achieves faster solving by combining the above two methods. These methods can be adopted as the solution method for the resource allocation unit 102.

[0152] The resource allocation unit 102 determines the allocation for all resource groups R as Rs[R]=(resources obtained by converting the numerical values ​​from Lower[R] to Upper[R] using a ValueMap) (step S416).

[0153] The resource allocation unit 102 determines the allocation for all consumers c as Rs[c]=(resources obtained by converting the numerical values ​​from Lower[Proxy[c]] to Upper[Proxy[c]] using a ValueMap) (step S417).

[0154] The resource allocation unit 102 outputs the obtained allocation Rs (step S418). The above describes the operation of the resource allocation unit 102 in this embodiment.

[0155] Next, a specific example of the operation of the resource allocation unit 102 will be described. First, we will explain the operation when the resource allocation model of configuration plan 700 in Figure 7A is input to the resource allocation unit 102.

[0156] The resource allocation model 800 in Figure 8 shows the resource allocation model for configuration 700, in which proxy resource groups and constraints related to the proxy resource groups have been added by steps S402 to S404.

[0157] The ValueMap calculated in step S405, which shows the correspondence between resources in the resource groups MachinePool_1 and MachinePool_2 and integers, associates the 800 resources in MachinePool_1 with integer values ​​0, 1, ..., 799, and the 480 resources in MachinePool_2 with integer values ​​800, 801, ..., 1279.

[0158] The upper limits for resource groups MachinePool_1 and MachinePool_2 are UB[MachinePool_1]=799 and UB[MachinePool_2]=1279, respectively, while the lower limits are LB[MachinePool_1]=0 and LB[MachinePool_2]=800, respectively.

[0159] In addition to the ValueMaps mentioned above, there are also ValueMaps for the resource groups MachinePool_1 and MachinePool_2 that map the 480 resources in MachinePool_2 to integer values ​​0, 1, ..., 479, and the 800 resources in MachinePool_1 to integer values ​​480, 481, ..., 1279.

[0160] Based on the resource allocation model 800, the linear constraints generated and added in steps S409, S411, S413, and S414 are as follows:

[0161] (Step S409) ·Upper[MachinePool_1]==UB[MachinePool_1] ·Upper[MachinePool_2]==UB[MachinePool_2] ·Lower[MachinePool_1]==LB[MachinePool_1] ·Lower[MachinePool_2]==LB[MachinePool_2]

[0162] (Step S411) Lower[MX_1]+7==Upper[MX_1] Lower[MX_2]+7==Upper[MX_2] ·Lower[Proxy[FE]]+2==Upper[Proxy[FE]] ·Lower[Proxy[BE]]+5==Upper[Proxy[BE]]

[0163] (Step S413) ·Lower[MachinePool_1]≦Lower[MX_1] ·Upper[MX_1]≦Upper[MachinePool_1] ·Lower[MachinePool_1]≦Lower[MX_2] ·Upper[MX_2]≦Upper[MachinePool_1] ·Lower[MX_1]≦Lower[Proxy[FE]] ·Upper[Proxy[FE]]≦Upper[MX_1] ·Lower[MX_2]≦Lower[Proxy[BE]] ·Upper[Proxy[BE]]≦Upper[MX_2]

[0164] (ステップS414) ·0≦ORD[MachinePool_1、MachinePool_2] ·ORD[MachinePool_1、MachinePool_2] ≦1 ·Upper[MachinePool_1]+1≦Lower[MachinePool_2]+1280×ORD[MachinePool_1、MachinePool_2] ·Upper[MachinePool_1]+1≦Lower[MachinePool_2]+1280×(1-ORD[MachinePool_1、MachinePool_2]) ·0≦ORD[MX_1,MX_2] ·ORD[MX_1,MX_2]≦1 ·Upper[MX_1]+1≦Lower[MX_2]+1280×ORD[MX_1,MX_2] ·Upper[MX_1]+1≦Lower[MX_2]+1280×(1-ORD[MX_1,MX_2]) ·0≦ORD[Proxy[FE],Proxy[BE]]·ORD[Proxy[FE],Proxy[BE]]≦1 ·Upper[Proxy[FE]]+1≦Lower[Proxy[BE]]+1280×ORD[Proxy[FE],Proxy[BE]] ·Upper[Proxy[FE]]+1≦Lower[Proxy[BE]]+1280×(1-ORD[Proxy[FE],Proxy[BE]])

[0165] Step S415 provides an example of a solution assignment for the linear constraint problem with the above constraints.

[0166] Assign: Lower[MachinePool_1]: 0 Upper[MachinePool_1]: 799 Lower[MachinePool_2]: 800 Upper[MachinePool_2]: 1279 Lower[MX_1]: 0 Upper[MX_1]: 7 Lower[MX_2]: 8 Upper[MX_2]: 15 Lower[Proxy[FE]]: 0 Upper[Proxy[FE]]: 2 Lower[Proxy[BE]]: 8 Upper[Proxy[BE]]: 13 ORD[MachinePool_1, MachinePool_2]: 0 ORD[MX_1, MX_2]: 0 ORD[Proxy[FE], Proxy[BE]]: 0

[0167] As a result, the resource utilization status obtained by inputting the configuration plan 700 into the resource allocation unit 102 is as follows. However, the allocated resources are indicated by their allocation numbers using ValueMap.

[0168] MachinePool_1:{0,1,... ,799} MachinePool_2:{800,801,... ,1279} MX_1:{0,1,2,3,4,5,6,7} MX_2:{8,9,10,11,12,13,14,15} FE:{0,1,2} BE:{8,9,10,11,12,13}

[0169] The above explains the operation when the resource allocation model of configuration plan 700 in Figure 7A is input to the resource allocation unit 102.

[0170] Next, we will explain the operation when the resource allocation model of configuration plan 701 in Figure 7B is input to the resource allocation unit 102.

[0171] The resource allocation model 801 in Figure 8 shows the resource allocation model for configuration 701, in which proxy resource groups and constraints related to the proxy resource groups have been added by steps S402 to S404.

[0172] The ValueMap and other elements are exactly the same as in case 700 of configuration plan, but when linear constraints are generated from the resource allocation model of configuration plan 701, the result includes the following constraints (1) to (11).

[0173] (1) Lower[MX_1] + 7 == Upper[MX_1] (2)Lower[Proxy[FE]]+2==Upper[Proxy[FE]] (3)Lower[Proxy[BE]]+5==Upper[Proxy[BE]] (4)Lower[MX_1]≦Lower[Proxy[FE]] (5)Lower[MX_1]≦Lower[Proxy[BE]] (6) Upper[Proxy[FE]]≦Upper[MX_1] (7) Upper[Proxy[BE]]≦Upper[MX_1] (8)0≦ORD[Proxy[FE], Proxy[BE]] (9)ORD[Proxy[FE],Proxy[BE]]≦1 (10)Upper[Proxy[FE]]+1≦Lower[Proxy[BE]]+1280×ORD[Proxy[FE],Proxy[BE]] (11)Upper[Proxy[FE]]+1≦Lower[Proxy[BE]]+1280×(1-ORD[Proxy[FE],Proxy[BE]])

[0174] In fact, it turns out that there is no variable assignment that satisfies all of these conditions. This will be explained below.

[0175] First, ORD[Proxy[FE], Proxy[BE]] can take the value of 0 or 1, but in either case, the reason why there is no assignment can be explained for the same reason, so below we consider the case where ORD[Proxy[FE],Proxy[BE]]=0.

[0176] In this case, constraint (11) holds for any allocation and can therefore be ignored. Also, constraint (10) indicates that Proxy[FE] contains resources with "lower" numbers than Proxy[BE].

[0177] Then, we find that "the value of Upper[Proxy[FE]] is exactly 2 greater than the value of Lower[Proxy[FE]] (from constraint (2))", "the value of Lower[Proxy[BE]] is 1 or more greater than the value of Upper[Proxy[FE]] (from constraint (11))", and "the value of Upper[Proxy[BE]] is exactly 5 greater than the value of Lower[Proxy[BE]] (from constraint (3))", so "the value of Upper[Proxy[BE]] is 8 or more greater than the value of Lower[Proxy[FE]]", and thus the size of the integer interval Lower[Proxy[FE]]~Upper[Proxy[BE]] must be 9 or greater.

[0178] However, constraints (4) and (7) show that the interval Lower[Proxy[FE]]~Upper[Proxy[BE]] is contained within the interval Lower[MX_1]~Upper[MX_1], and constraint (1) shows that the size of the latter interval is exactly 8. Therefore, it can be seen that there is no integer value assignment for the variable that satisfies both of these constraints simultaneously.

[0179] Based on the above, when the resource allocation model of configuration plan 701 in Figure 7B is input to the resource allocation unit 102, "allocation not possible" is notified in S415. The above is a description of a specific example of the operation of the resource allocation unit 102 in this embodiment.

[0180] As explained above, the proposed configuration 700 in Figure 7A has a reasonable resource utilization situation for the resource allocation model, while the proposed configuration 701 in Figure 7B does not. Therefore, if the configuration concretization unit 101 attempts to concretize Figure 5 during the search, in step S310, a resource utilization situation is found for the proposed configuration 700 and it is added to the candidate configuration T, while the proposed configuration 701 is notified as "unallocable" and is not added to the candidate configuration T.

[0181] (effect) The configuration implementation unit 101 of this embodiment can efficiently implement resources by treating a large number of resources as a single set rather than as individual nodes.

[0182] For example, in the example shown in Figures 7A to 7C, if the resource capacity of MachinePool_1 and MachinePool_2 increases 10,000 times, and if resources were represented individually as nodes without using a resource allocation model, both the data size and the number of branches would increase 10,000 times. On the other hand, by treating resources as a set using the configuration concretization unit 101 of this embodiment, the size of the data representing the configuration proposal does not change, and furthermore, the number of configuration proposals that appear as a result of concretization also does not change from three.

[0183] Furthermore, the resource allocation unit 102 of this embodiment can detail the specific usage status of resources from the resource allocation model. This makes it possible to concretize the connection between resources and consumers, which was partially abstracted when output from the configuration concretization unit 101 of this embodiment, and to supplement the information necessary for designing the system configuration.

[0184] Therefore, the system configuration derivation device 100 of this embodiment can efficiently find a system configuration that satisfies service requirements that specify a large amount of available resources, with a computation amount that is almost independent of the amount of resources.

[0185] <Second Embodiment> Next, a second embodiment of the present invention will be described. Figure 2 is a block diagram showing an example configuration of the system configuration derivation device of the second embodiment.

[0186] The system configuration derivation device 200 includes the same components as the system configuration derivation device 100 of the first embodiment, but a resource data extraction unit 201 is added as an input device, and a resource data reflection unit 202 is added as an output device.

[0187] The system configuration derivation device 200 includes a resource data extraction unit 201 that receives an abstract configuration as input and represents the group of resources contained therein using a resource allocation model, thereby dividing it into two parts: an abstract configuration in which the resource portion is abstracted, and the resource allocation model.

[0188] The system configuration derivation device 200 includes a resource data reflection unit 202 that receives a pair of abstract configuration and resource utilization status as input, and reflects the resource utilization status in the abstract configuration, thereby converting it into an abstract configuration in which "resources" and "resource utilization" are individually materialized as entities or properties.

[0189] Unlike the first embodiment, the system configuration derivation device 200 does not require the user to explicitly specify a resource allocation model. Therefore, it is necessary to define conversion rules in the type information for converting from "abstract configuration" to "configuration proposal including resource allocation model" (hereinafter referred to as "resource conversion rules") and for converting from "configuration proposal including resource allocation model" and "resource utilization status" to "abstract configuration" (hereinafter referred to as "configuration conversion rules").

[0190] The following sections detail examples of "resource transformation rules" and "configuration transformation rules." The resource conversion rule "Convert-XResource," which replaces "MachineX" type nodes with "MachineXPool" type nodes and adds a resource allocation model, is defined by the following conversion steps (1) to (5).

[0191] (1) Add the resource group pool_mx to the resource allocation model. The resources included in pool_mx will be numerical values ​​1, 2, 3, ... (number of MachineX type nodes included in the abstract configuration × 8).

[0192] (2) For all "Host-type edges extended from App-type node a to MachineX-type node m" included in the abstract configuration, the operation to add consumer a and resource group m to the resource allocation model is performed (at this time, if resource group m already exists in the resource allocation model, the addition operation is skipped). The amount of resources requested by a is set to the amount of memory requested by node a, and the resource capacity of m is set to 8. Furthermore, the inclusion relationship m⊆pool_mx and the membership relationship a→m are added to the resource allocation model.

[0193] (3) Add an exclusive relationship m1≠m2 between two different resource groups m1 and m2 contained in pool_mx to the resource allocation model.

[0194] (4) Add a "MachineXPool" type node pool_mx to the abstract configuration and change the endpoint of all "Host type edges from App type nodes to MachineX type nodes" to pool_mx.

[0195] (5) Remove all MachineX type nodes from the abstraction configuration.

[0196] The resource conversion rule "Convert-XResource" converts the resource allocation model to an abstract configuration based on the added requirements, while the configuration conversion rule "Invert-XResource" reflects the resource utilization status Rs. This conversion rule is defined by the following conversion rules (1) and (2).

[0197] (1) Refer to the resource utilization status Rs[a] for consumer a included in the resource allocation model, and if there is a group of resources mx that is not pool_mx and includes the said resource, add a MachineX type node mx to the abstract configuration (skip if a node with the same name already exists). Then, change the endpoint of the Host type edge from node a included in the abstract configuration to node pool_mx to mx.

[0198] (2) Remove the node pool_mx from the abstract configuration. The above are specific examples of resource transformation rules and structure transformation rules.

[0199] It should be noted that the resource transformation rules and structure transformation rules used in the second embodiment of the present invention are not limited to those described above, and it is also possible to use multiple resource transformation rules / structure transformation rules.

[0200] (operation) The system configuration derivation device 200 takes the abstract configuration input from the user as input to the resource data extraction unit 201, and uses the output as input, performing the same operation as the system configuration derivation device 100 in the first embodiment. Subsequently, the abstract configuration obtained by inputting the set of abstract configuration and resource utilization status obtained as output to the resource data reflection unit 202 becomes the output of the system configuration derivation device 200.

[0201] The operation of the resource data extraction unit 201 will be explained using a specific example. In this embodiment, the resource data extraction unit 201 outputs an abstract configuration and a resource allocation model obtained by applying all applicable resource transformation rules to the input abstract configuration.

[0202] Figure 9 shows the requirements information before conversion. The requirements information before conversion is represented only by the abstract configuration 900.

[0203] Abstract configuration 900 includes seven App-type nodes app1, app2, ..., app7, with "required memory amount (GB)" of 6, 5, 4, 2, 1, 4, and 7 respectively. Abstract configuration 900 also includes 50 MachineX-type nodes m1, m2, ..., m50, and three Host-type edges: "edge from app1 to m1", "edge from app2 to m3", and "edge from app5 to m3".

[0204] Figure 10 shows a proposed configuration obtained by applying the resource conversion rule "Convert-XResource" to the abstract configuration 900 by the resource data extraction unit 201. The "proposed configuration" shown in Figure 10 consists of an abstract configuration 1000 and a resource allocation model 1001.

[0205] In resource allocation model 1001, the resource group pool_mx, which has resources 1, 2, ..., 400, has been added by step (1) of Convert-XResource.

[0206] In the resource allocation model 1001, consumers app1, app2, ..., app7 are added with requested resource amounts of 6, 5, 4, 2, 1, 4, and 7 respectively through step (2) of Convert-XResource, and resource groups m1 and m2 of size 8 are added. In addition, inclusion relationships m1⊆pool_mx, m2⊆pool_mx and membership relationships app1→m1, app2→m2, app5→m2 are added.

[0207] In resource allocation model 1001, the exclusive relationship m1≠m2 is added by step (3) of Convert-XResource.

[0208] In abstract configuration 1000, a MachineXPool type node pool_mx is added through step (4) of Convert-XResource, and the endpoints of all three Host type edges that were included in abstract configuration 900 have been changed to pool_mx.

[0209] In abstraction configuration 1000, all 50 MachineX type nodes that were included in abstraction configuration 900 have been removed by step (5) of Convert-XResource.

[0210] The above is a concrete example of how the resource data extraction unit 201 operates.

[0211] Next, the operation of the resource data reflection unit 202 will be explained using a specific example. The resource data reflection unit 202 receives a pair of an abstract configuration and resource usage status as input, and reflects the resource usage status in the abstract configuration to generate and output an abstract configuration in which the relationship between resources and consumers (or entities corresponding to them) is represented as concrete nodes and edges.

[0212] Figure 11 shows an example of an abstract configuration 1100 and resource utilization status 1101, which are inputs to the resource data reflection unit 202.

[0213] The abstract configuration 1200 in Figure 12 is a diagram showing the abstract configuration obtained by applying the structure transformation rule Invert-XResource by the resource data reflection unit 202 to the abstract configuration 1100 and reflecting the resource utilization status 1101.

[0214] In the abstract configuration 1200, MachineX type nodes m1, m2, m3, and m4 are added by step (1) of Invert-XResource. This is because, in resource usage status 1101, the resources allocated to app1 are included in m1, the resources allocated to app2, app4, and app5 are included in m2, the resources allocated to app3 and app6 are included in m3, and the resources allocated to app7 are included in m4, resulting in the creation of nodes corresponding to these.

[0215] In abstract configuration 1200, step (1) of Invert-XResource changes the endpoints of the Host-type edges to MachineX-type nodes m1, m2, m3, and m4.

[0216] In abstract configuration 1200, the MachineXPool type node pool_mx has been removed by step (2) of Invert-XResource.

[0217] (effect) Unlike the system configuration derivation device 100, the system configuration derivation device 200 of this embodiment completes data exchange with the user using an abstract configuration.

[0218] The resource data extraction unit 201 of this embodiment can determine, on behalf of the user, which parts of the requirements information provided by the user can be efficiently handled as resources.

[0219] Therefore, according to the system configuration derivation device 200 of this embodiment, resources included in the abstract configuration can be automatically converted into a resource allocation model, and then a design process using the resource allocation model can be executed. As a result, it becomes possible to automatically design the system configuration at high speed without requiring the user to explicitly specify the existence of resources.

[0220] <Third Embodiment> Figure 13 is a block diagram showing an example of the configuration of a system configuration derivation device according to the third embodiment. If an abstract configuration is defined as system configuration information that may include an abstract configuration expressed as graph data connecting nodes and edges, a resource is defined as various resources such as system resources, addresses, ports, bandwidth, and licenses required for the normal operation of the system's components, a consumer is defined as the component requesting the resources, a resource group is defined as an object corresponding to a collection of the resources, resource utilization status is defined as data that defines the resources used by the consumer and the resources included in the resource group, and a resource allocation model is defined as data showing the correspondence between the consumer included in the abstract configuration and the resource group to be allocated to that consumer, then the system configuration derivation device 80 comprises: an embodiment means 81 that generates a system configuration that satisfies the requirement data by stepwise concretizing the abstract configuration and the resource allocation model input as requirement data according to predetermined rules, and an allocation means 82 that takes the resource allocation model as input and outputs the resource utilization status according to the resource allocation model.

[0221] Figure 14 is a flowchart showing an example of the operation of the system configuration derivation device according to the third embodiment. The concretization means 81 generates a system configuration that satisfies the requirement data by stepwise concretizing the abstract configuration and the resource allocation model input as requirement data according to predetermined rules (step S801). Next, the allocation means 82 takes the resource allocation model as input and outputs the resource utilization status according to the resource allocation model (step S802).

[0222] Figure 15 shows an example of the hardware configuration of the system configuration derivation device according to each embodiment. The computer 90 comprises a CPU 91, main memory 92, auxiliary memory 93, input / output interface 94, and communication interface 95. The system configuration derivation devices 100, 200, and 80 described above are implemented in the computer 90. The functions described above are stored in the auxiliary memory 93 in the form of programs. The CPU 91 reads the program from the auxiliary memory 93, expands it into the main memory 92, and executes the above processing according to the program. The CPU 91 also allocates memory space in the main memory 92 according to the program. The CPU 91 also allocates memory space in the auxiliary memory 93 to store data being processed according to the program.

[0223] A program to implement all or part of the functions of the system configuration derivation devices 100, 200, and 80 may be recorded on a computer-readable recording medium, and the program recorded on this recording medium may be loaded into a computer system and executed to perform processing by each functional unit. Here, "computer system" includes hardware such as the OS and peripheral devices. Furthermore, if a WWW system is used, "computer system" also includes the homepage provisioning environment (or display environment). Furthermore, "computer-readable recording medium" refers to portable media such as CDs, DVDs, USBs, and storage devices such as hard disks built into the computer system. Furthermore, if this program is distributed to computer 90 via a communication line, computer 90 that receives the distribution may load the program into main memory 92 and execute the above processing. Furthermore, the above program may be for implementing only a part of the functions described above, and may also be able to implement the above functions in combination with programs already recorded in the computer system.

[0224] Although one embodiment of this disclosure has been described in detail above with reference to the drawings, the specific configuration is not limited to that described above, and various design changes can be made without departing from the spirit of this invention. Furthermore, one aspect of this disclosure can be modified in various ways within the scope of the claims, and embodiments obtained by appropriately combining the technical means disclosed in different embodiments are also included in the technical scope of this disclosure. In addition, configurations in which elements described in each of the above embodiments and modifications that produce similar effects are substituted for each other are also included. Moreover, each embodiment can be appropriately combined with other embodiments.

[0225] Some or all of the above embodiments may be described as follows, but are not limited to the following:

[0226] (Note 1) A system configuration derivation device comprising: an abstract configuration unit that generates a system configuration that satisfies the requirement data by acquiring the abstract configuration and the resource allocation model input as requirement data and progressively concretizing them according to predetermined rules; and a resource allocation unit that acquires the resource allocation model as input and outputs the resource utilization status according to the resource allocation model.

[0227] (Note 2) The system configuration derivation device according to Appendix 1 further comprises a resource data extraction unit that takes the abstract configuration as input and performs a transformation operation to extract the portion that can be efficiently handled as a resource, thereby outputting the abstract configuration in which the portion corresponding to the resource has been abstracted, and the resource allocation model that represents the extracted portion corresponding to the resource.

[0228] (Note 3) The system configuration derivation device according to Appendix 1 or Appendix 2 further comprises a resource data reflection unit that acquires the abstract configuration and the resource utilization status as inputs, and reflects the resource utilization status information in the abstract configuration to generate the abstract configuration in which the resources requested by the consumer included in the abstract configuration are materialized.

[0229] (Note 4) The resource allocation unit calculates the resource utilization status by converting the input resource allocation model into a constraint problem for integer variables and finding its solution, as described in Appendices 1 to 3.

[0230] (Note 5) The system configuration derivation device described in Appendix 4, which in the aforementioned constraint problem, restricts the following: the quantity of resources allocated to the consumer is equal to the quantity of resources requested by the consumer; the quantity of resources allocated to the resource group in which the capacity of the resources is defined is equal to the resource capacity defined in the resource group; resources allocated to different consumers do not overlap; resources allocated to different resource groups that are mutually exclusive do not overlap; resources allocated to resource groups that are in an inclusion relationship satisfy the inclusion relationship; and if the consumer and the resource group are in a relationship in which the consumer consumes the resource group, then the resources allocated to the consumer are included in the resource group.

[0231] (Note 6) A system configuration derivation method wherein, when an abstract configuration is system configuration information that may include an abstract configuration expressed as graph data connecting nodes and edges, a resource is a resource required for the normal operation of the system's components, a consumer is the component that requests the resource, a resource group is an object corresponding to a collection of the resources, resource utilization status is data that defines the resources used by the consumer and the resources included in the resource group, and a resource allocation model is data that shows the correspondence between the consumer included in the abstract configuration and the resource group to be allocated to that consumer, the computer acquires the abstract configuration and the resource allocation model input as requirement data, generates a system configuration that satisfies the requirement data by stepwise concretizing them according to predetermined rules, acquires the resource allocation model as input, and outputs the resource utilization status according to the resource allocation model.

[0232] (Note 7) Assuming that an abstract configuration is system configuration information that may include an abstract configuration expressed as graph data connecting nodes and edges, a resource is a resource required for the normal operation of the system's components, a consumer is the component that requests the resource, a resource group is an object corresponding to a collection of the resources, resource utilization status is data that defines the resources used by the consumer and the resources included in the resource group, and a resource allocation model is data that shows the correspondence between the consumer included in the abstract configuration and the resource group to be allocated to that consumer, a program that causes a computer to execute a process that acquires the abstract configuration and the resource allocation model input as requirement data, generates a system configuration that satisfies the requirement data by stepwise concretizing them according to predetermined rules, acquires the resource allocation model as input, and outputs the resource utilization status according to the resource allocation model. [Explanation of Symbols]

[0233] 100, 200, 80... System configuration derivation device 101...Concretization Department 102...Resource allocation section 201...Resource Data Extraction Unit 202...Resource Data Reflection Section 81...Means of embodiment 82. Allocation means 90... Computer 91···CPU 92...Main memory 93...Auxiliary storage device 94. Input / Output Interface 95. Communication Interface

Claims

1. An abstract configuration is system configuration information that may include an abstract configuration represented as graph data connecting nodes and edges. A resource is a resource required for the normal operation of the components of the aforementioned system, A consumer is the component that requests the aforementioned resources, A resource group is an object that corresponds to a collection of the aforementioned resources, Resource utilization status refers to data that defines the resources used by the consumer and the resources included in the resource group, If the resource allocation model is defined as data showing the correspondence between the consumers included in the abstract configuration and the group of resources to be allocated to those consumers, A configuration concretization unit acquires the abstract configuration and resource allocation model input as requirement data, and concretizes them step by step according to predetermined rules to generate a system configuration that satisfies the requirement data, A resource allocation unit that takes the resource allocation model as input and outputs the resource utilization status according to the resource allocation model, A system configuration derivation device equipped with [the following features].

2. A resource data extraction unit takes the abstract structure as input and performs a transformation operation to extract the portion that can be efficiently handled as a resource, thereby outputting the abstract structure in which the portion corresponding to the resource has been abstracted, and the resource allocation model that represents the extracted portion corresponding to the resource. The system configuration derivation device according to claim 1, further comprising the following:

3. A resource data reflection unit acquires the abstract configuration and the resource utilization status as inputs, and reflects the resource utilization status information in the abstract configuration to generate the abstract configuration in which the resources requested by the consumer included in the abstract configuration are materialized. The system configuration derivation device according to claim 1 or claim 2, further comprising the above.

4. The resource allocation unit converts the input resource allocation model into a constraint problem for integer variables and calculates the resource utilization status by finding its solution. A system configuration derivation device according to claim 1 or claim 2.

5. In the aforementioned constraint problem, The quantity of resources allocated to the consumer is equal to the quantity of resources requested by the consumer. The quantity of the resource allocated to the resource group, whose capacity is defined, is equal to the resource capacity defined in the resource group. The resources allocated to different consumers do not overlap. The resources allocated to different resource groups that are mutually exclusive do not overlap. The resources allocated to the resource group that is in a subordination relationship satisfy the subordination relationship. If the consumer and the resource group are in a relationship where the consumer consumes the resource group, then the resources allocated to the consumer are included in the resource group. A system configuration derivation device according to claim 4, which restricts the following.

6. An abstract configuration is system configuration information that may include an abstract configuration represented as graph data connecting nodes and edges. A resource is a resource required for the normal operation of the components of the aforementioned system, A consumer is the component that requests the aforementioned resources, A resource group is an object that corresponds to a collection of the aforementioned resources, Resource utilization status refers to data that defines the resources used by the consumer and the resources included in the resource group, If the resource allocation model is defined as data showing the correspondence between the consumers included in the abstract configuration and the group of resources to be allocated to those consumers, Computers The abstract configuration and resource allocation model input as requirement data are obtained, and a system configuration that satisfies the requirement data is generated by gradually concretizing them according to predetermined rules. The system takes the resource allocation model as input and outputs the resource utilization status according to the resource allocation model. Method for deriving the system configuration.

7. An abstract configuration is system configuration information that may include an abstract configuration represented as graph data connecting nodes and edges. A resource is a resource required for the normal operation of the components of the aforementioned system, A consumer is the component that requests the aforementioned resources, A resource group is an object that corresponds to a collection of the aforementioned resources, Resource utilization status refers to data that defines the resources used by the consumer and the resources included in the resource group, If the resource allocation model is defined as data showing the correspondence between the consumers included in the abstract configuration and the group of resources to be allocated to those consumers, On the computer, The abstract configuration and resource allocation model input as requirement data are obtained, and a system configuration that satisfies the requirement data is generated by gradually concretizing them according to predetermined rules. A process that takes the resource allocation model as input and outputs the resource utilization status according to the resource allocation model. A program that executes the command.

Images