JP6984087B2 - Service development system, resource prediction method and service development program - Google Patents

Description

The present disclosure relates to a technique for predicting the amount of resources required to be satisfied by a service element or a network function and allocating resources to the service element or the network function in a service development system for developing a service on a virtual or physical server.

With server virtualization technology and the like, technologies such as NFV (Network Virtualization) that can easily build network services on the cloud, which could not be developed without physical equipment, have been developed and standardized.

Further, a microservice architecture has been proposed as a software development method (see, for example, Non-Patent Document 1). FIG. 1 shows a microservice architecture. Microservices architecture is a software design method that builds a single application as a combination of small independent service elements, which clarifies the demarcation point of service responsibility and improves scalability compared to monolithic applications. In recent years, service elements such as Node red have already been created as tools for easily creating microservices, and software for easily creating services by combining them has also been proposed (see, for example, Non-Patent Document 2). .).

FIG. 2 is a configuration diagram illustrating a component combination type service development system 300 such as a conventional Node Red. The service development system 300 creates one application by connecting and combining necessary service elements from the service element list 11 by using the interface 12 when the developer develops an application. Then, the developer allocates the resources of the network function and the computational resource based on each service element by using the resource allocation unit 21.

FIG. 4 is a diagram illustrating an operation of generating a service configuration of an application by using the service development system 300. In the service development system 300, service elements that can be selected in advance are registered in the service list of the system, and the developer selects a necessary service element from the service list and connects the service elements with a line (interface). A service (application) is generated by creating a service configuration (step S01) and allocating resources to the service configuration (step S02).

With such technology, it is possible to build a service that meets various service requirements by developing a service as an element and selecting and combining it, instead of creating software from scratch.

"Microservices", https: // Martinfowler. com / artles / microservices. html (searched on September 13, 2017) "Node-red", https: // nodered. org / (Searched on September 13, 2017)

There is a problem that detailed knowledge of the network is required for the application developer to design the optimum service for the application by combining the network functions in consideration of the scalability (extensibility) of the service.

In addition, since the service element is an independent service, it is common to construct it in different computer resources (the computer resources defined here include bare metal, virtual machines, containers, etc.), such as VNF (Virtualized network function). It is necessary to allocate the amount of resources (CPU, memory, HDD) to each VNF in the network function of the above, and there is also a problem that it is difficult to determine how many resources need to be allocated to which VNF.

Therefore, in order to solve the above problems, the present invention is a service development system and a resource prediction method that can predict the amount of computational resources and the amount of resources of network functions required when creating an application without detailed knowledge of the network. And to provide service development programs.

In order to achieve the above object, the service development system and the resource prediction method according to the present invention are required when creating one application by combining a plurality of service elements to form a service configuration by using a microservice architecture. It was decided to describe the service requirements required for the application in a table, map the amount of computational resources to be calculated and the amount of resources of the network function to the service configuration to which they are applied, and operate the application virtually to understand it.

Specifically, the service development system according to the present invention is
A service development system that creates one or more applications by combining two or more service elements to form a service configuration.
A service requirement input unit that describes the entered one or more service requirements required for the application in the service requirement table, and
A service requirement application unit that converts each service requirement described in the service table into network setting information and maps it to the service configuration.
A resource prediction unit that virtually operates the service configuration to which service requirements are mapped and predicts the amount of computational resources and network function resources that meet each service requirement.
To prepare for.

Further, the resource prediction method according to the present invention is a resource prediction method for predicting the amount of resources required when creating a service configuration by combining two or more service elements to create one or more applications. ,
A service requirement input procedure that describes the entered one or more service requirements required for the application in the service requirement table, and
A service requirement application procedure that converts each service requirement described in the service table into network setting information and maps it to the service configuration, and
Based on the data that operated the service configuration to which the service requirements are mapped, a resource prediction procedure that predicts the amount of computational resources and network function resources that meet each service requirement, and a resource prediction procedure.
It is characterized by doing.

According to the present invention, service requirements can be aggregated when resources are shared by inputting network functions required for an application into a table as service requirements, and the amount of resources required by operating the application virtually can be predicted. Can be done. Therefore, the present invention can provide a service development system and a resource prediction method that can predict the amount of computational resources and the amount of resources of network functions required when creating an application without detailed knowledge of the network.

The service development system and the resource prediction method according to the present invention confirm the existence of service requirements that can be shared with other applications, and if there are service requirements that can be shared and the service requirements are the same, the above-mentioned other services. It is characterized by accommodating network functions in an application. The amount of resources can be predicted in consideration of other applications.

The service development system and the resource prediction method according to the present invention confirm the presence or absence of an interaction between service elements or between a service element and a network function at the time of resource prediction, and if there is an interaction, the amount of resources due to the interaction. Is reflected in the predicted amount of resources. It is possible to handle the case where the computational resources are not virtualized.

The service development program according to the present invention is a program for making a computer function as the service development system. The service development system of the present invention can also be realized by a computer and a program, and the program can be recorded on a recording medium or provided through a network.

The present invention can provide a service development system, a resource prediction method, and a service development program that can predict the amount of computational resources and the amount of resources of network functions required when creating an application without detailed knowledge of the network. ..

It is a figure explaining the microservice architecture. It is a block diagram explaining the component combination type service development system such as Node Red. It is a block diagram explaining the service development system which concerns on this invention. It is a figure explaining the work of generating the service configuration of an application using a service development system. It is a figure explaining the work of generating the service configuration of an application using the service development system which concerns on this invention. It is a figure explaining the service requirement table. This is an example of an event list that describes the order in which service requirements are set. It is a flowchart explaining the operation of the service requirement application part of the service development system which concerns on this invention. It is a figure explaining the effect by the service requirement application part of the service development system which concerns on this invention. It is a flowchart explaining the operation which the resource prediction part of the service development system which concerns on this invention estimates the amount of resources. It is a flowchart explaining the operation which the resource prediction part of the service development system which concerns on this invention estimates the resource amount when the computational resource is not virtualized. It is a flowchart explaining the operation when the resource prediction part of the service development system which concerns on this invention changes a resource amount.

An embodiment of the present invention will be described with reference to the accompanying drawings. The embodiments described below are examples of the present invention, and the present invention is not limited to the following embodiments. In addition, the components having the same reference numerals in the present specification and the drawings shall indicate the same components.

FIG. 3 is a configuration diagram illustrating the service development system 301 of the present embodiment. The service development system 301 is a service development system using a microservice architecture that combines two or more service elements to form a service configuration and creates one or more applications.
In addition to the service element list 11 and interface 12,
The service requirement input unit 13 that describes the input one or more service requirements required for the application in the service requirement table, and
A service requirement application unit 14 that converts each service requirement described in the service table into network setting information and maps it to the service configuration.
A resource prediction unit 15 that virtually operates the service configuration to which service requirements are mapped and predicts the amount of computational resources and network function resources that satisfy each service requirement.
To prepare for.

The application developer uses the service development system 301 to input service requirements into the service requirement table, and based on the service requirement table, predicts the required resource amount in consideration of allocation and aggregation of network functions, etc., and estimates the resources. assign. The service development system 301 enables efficient resource allocation to network functions and service elements.

FIG. 5 is a diagram illustrating an operation of generating a service configuration of an application by using the service development system 301. In the service development system 301, the following steps are added to the work described with reference to FIG.
Step S11: The developer inputs a service requirement that abstracts the service requirement into the service requirement table via the service requirement input unit 13.
Step S12: When the service requirement is input to the service requirement table, the service requirement application unit 14 generates a network structure of the service element and aggregates the service requirement for each place where the service requirement is applied. Furthermore, it is determined whether the service requirements can be aggregated with other services provided by the developer or services provided by the other developers.
Step S13: The resource prediction unit 15 allocates computational resources and network functions according to the service requirement application destination of the service requirement application unit 14. The resource prediction unit 15 constructs a computational resource and a network structure on a temporary system and operates them, and measures the usage amount of the computational resource per unit time. The resource prediction unit 15 predicts the resources of each service element in applying the service requirement from the measurement result, calculates the required computational resource amount, and allocates the resource to each service element.

Each component of the service development system 301 will be specifically described.

(1) Service requirement input unit The service requirement input unit 13 inputs the service requirement that abstracts the service requirement into the service requirement table. FIG. 6 is an input example of the service requirement table. In the past, service requirements were entered individually as parameters for each service element, network functions were selected, and so on. By inputting the service requirements in the table format, the service requirement input unit 13 facilitates the aggregation of policies, which will be described later. In this example, the policy name (requirement name), application location, application condition, and operation are shown as service requirement fields, but the field is not limited to these.

The service element provider who provides the service element may input the service requirement in the service requirement table in advance, or the service provider who creates the application by combining the service elements may input the service element. Further, the service element provider and the service provider may apply a plurality of service requirements to one application place.

The requirement name represents the service requirement to be applied (eg, Scaling rule, security rule).
The place of application represents a place in the combination of service elements to which the service requirement is applied (eg, service element 1: input 1).
The applicable condition represents a condition that reflects the service requirement (example: when the number of users exceeds 100 or when the service is started).
The operation represents the operation according to the service requirement (example: redundancy using resources up to twice the resources).

When service requirements are aggregated into one resource, the system needs to have a table that describes the setting order because there is a dependency of the setting order. FIG. 7 is an example of an event list showing the setting order.
The event name represents the service requirement and the command required for operation (example: instantiate, scaleout add).
The execution priority represents the setting order of the settings. Those with the same execution priority indicate that there is no problem even if the order is reversed.

(2) Service requirement application unit The service requirement application unit 14 applies resources based on the combination of service elements and service requirements. FIG. 8 is a flow for explaining the operation of the service requirement application unit 14. FIG. 9 is a diagram illustrating the effect of the service requirement application unit 14.

Step S21: Confirm that the service requirement is input to the service requirement table.
Step S22: Map service requirements to the service configuration, sort by application location, and search for service requirements set in the same application location.
Step S23: When there are a plurality of service requirements in the same application location, it is a condition that satisfies a set of a plurality of service requirements. For example, when both the scaling rule and the security rule are service element 1: input 1, if the set satisfying the scaling rule is N {scaling rule} and the set satisfying the security rule is N {surrity rule}, both are satisfied. Since it is a set, it becomes N {security rule} ∪ N {security rule}.
Step S24: Check whether the service requirements can be shared with other applications (which may be other applications of the same service provider or other service providers).
Step S25: If the setting cannot be shared with other applications, a setting template for arranging service requirements on the service configuration is generated (see FIG. 9B).
Step S29: In the case of a setting that can be shared with other applications, it is determined whether or not the other applications have the same service requirements and can be accommodated. If it is not possible, generate a setting template to be applied to its own service configuration (step S25).
Step S30: If possible, predict the amount of resources in another application. Step S31: Generate a setting template including the addition of resources, and accommodate the network function in another application.
Step S26: Service elements are connected by an interface to assemble a service configuration, and a service requirement setting template is added to a predetermined application location of the service configuration (see FIG. 9 (c)).
Step S27: The service configuration is divided according to the service requirements, and for example, in the case of scale-out or the like, the service elements need to be duplicated, so the service elements are duplicated according to the needs of the service requirements (see FIG. 9D).
Step S28: The resource allocation unit 21 allocates the resource amount based on the service configuration formed as shown in FIG. 9D. Here, when the resource amount is determined for each service requirement, the resource allocation unit 21 allocates the resource amount by using the resource amount. On the other hand, when the resource amount is not determined for each service requirement, the resource prediction unit 15 estimates the resource amount, and the resource allocation unit 21 allocates the resource based on the estimated resource amount.

(3) Resource prediction unit The resource prediction unit 15 predicts the amount of resources. FIG. 10 is a diagram illustrating an example of a flow in which the resource prediction unit 15 estimates the amount of resources.
Step S41: Allocate computational resources to the host. For example, allocate resources based on the network structure so that the number of hops is minimized. In this example, the number of hops is set to the minimum, but other conditions may be used.
Step S42: Predict the amount of resources. There are several prediction methods, but an example is shown below.
Before building the service, start the computational resource, the computational resource related to the service, or the computational resource that starts up on the same host (virtualize the computational resource) on the simulation host, and start, operate, and stop the computational resource. And so on. Then, the resource amount (memory, network, disk IO, processing time of service elements, processing speed, etc.) per unit time of computational resources is measured. At the same time, the processes with a large increase in the amount of resources per unit time are extracted from the computational resources. Here, the total amount of resources after a certain period of time (one day, one week, one month, etc.) is predicted from the amount of change in the amount of resources. Also, for processes with a large increase in the amount of resources, the amount of resources after a certain period of time is predicted from the amount of change in the amount of resources.
If the estimated resource amount exceeds the threshold to be satisfied, resource expansion and resource reallocation of computational resources are performed. The threshold value is determined, for example, as follows. As a service requirement, it is assumed that there is a condition that the response speed of the service is within 1 s. From the result of measuring the number of connections of the service element or the processing time, the processing time that the service element must satisfy is obtained. From there, the processing time when the threshold value of the resource of the service element changes is obtained from the empirical rule and the past history to obtain the threshold value that the service element must satisfy. The above data may be acquired in advance, and when the service is started, the resource amount may be predicted based on the above data instead of actually allocating. The prediction method is not limited to this method, and other methods may be used.

Step S43: In the allocation of computational resources, first, it is determined whether or not it can be allocated to its own host, and if it cannot be allocated, it is allocated to another host. The allocation decision is whether the amount of resources allocated to the host meets the amount of resources used by its own computational resources, or the resources used by its own computational resources when other service elements assigned to the host increase. Determine if it meets. At this time, the CPU and memory can be completely separated for each computational resource as virtual resources, but the network IO and disk IO cannot be completely separated, so the effect of allocation is determined.
The allocation to computational resources may be evenly allocated, or the allocation ratio of the resource amount may be changed according to the processing content of the service element. For example, since reliability is required for monitoring such as heartbeat, it is conceivable to preferentially allocate network IO. At this time, this allocation ratio is used to determine whether the service requirement can be satisfied when the computational resource is allocated to the host, and if the service requirement can be satisfied, the computational resource is allocated to the host that meets the service requirement. The above service requirements are, for example, reliability, response time, and the like. It calculates the reliability of the entire network system, finds a host that can meet the conditions, and searches for a host that can meet the delay.
For example, when α and β are the reliability of the module, the reliability of the entire system can be obtained by the following equation.
Series connection R1 = α × β
Parallel connection R2 = 1- (1-α) × (1-β)
At this time, the reliability of the entire system in which the modules are combined is given by R = (γR1, δR2). (Γ and δ are optional)
The reliability R at this time is given as follows when the service request level is C.
R = εC (ε is arbitrary)
The reliability of the entire system is calculated as described above, the optimum host is found, and resources are allocated (step S44).

Step S45: If the service requirement cannot be satisfied, the host that meets the service requirement (for example, the reliability is 90%, the response speed is 1 s or less, etc.) is searched and the computational resources are reassigned. For example, again, allocate computational resources to the host so that the number of hops is minimized. This makes it possible to allocate computational resources to the host. This method is an example, and other methods may be used. After allocating the host, switch the route to the host to which the computational resource is allocated.

FIG. 11 is a diagram illustrating another example of a flow in which the resource prediction unit 15 estimates the amount of resources. This example is an example when the computational resource is not virtualized.
Step S51: Acquire how much resource amount is required from the characteristics of each service element. This may be based on the data measured in advance, or may be actually measured as in step S42.
Step S52: It is determined whether there is a combination of a plurality of service elements in the same resource and each service element may interact with each other. If they are completely logically separated, there is almost no effect, but if they communicate with each other or if there is a wait to get the same resource, an interaction occurs.
Step S53: When the service elements interact with each other, the required resource amount generated by the interaction is acquired from the past data and the like. For example, the process in which communication between service elements occurs, the amount of communication at that time, the resources to be shared and the degree of influence are stored as advance data, and the amount of resources required for interaction based on the data when the service element is executed. Predict.
Step S54: It is determined whether the same resource has a combination of service elements and network functions, and each service element may interact with each other. This is the same as step S52.
Step S55: When the service element and the network function interact with each other, the required resource amount generated by the interaction is acquired from the past data or the like. This is the same as step S53.
Step S55: When the service element and the network function interact with each other, the required resource amount generated by the interaction is acquired from the past data or the like.

FIG. 12 is a diagram illustrating a flow in which the resource prediction unit 15 changes the resource amount.
Step S61: The resource prediction unit 15 acquires the amount of computational resources or resources of the network function. For this acquisition, the resource amount (memory, network, disk IO, processing time of service elements, processing speed, etc.) per unit time of computational resources is periodically measured.
Step S62: Predict the amount of computational resources or network function resources. Forecasting is based on service requirements and predicts the amount of resources so that the conditions are met. For example, in the case of the example of the method of step S42 in FIG. 10, the time series data of the process of the service element actually executed by the computational resource is acquired, and the amount of resources used after a certain period of time is predicted from the execution frequency of the process. ..
Step S63: It is determined whether the resource amount is insufficient in consideration of the service requirement.
If there is no shortage, continue the service.
Step S64: If the resource is insufficient, check whether the service is affected when the resource amount is changed. For example, if it is scaled up or down, the effect on the service is small. If the host is switched, the service will be affected.
Step S65: If there is no influence of the service, the resource amount is predicted and the resource is changed to the resource amount.
Step S66: If the service is affected, the service element is generated in the resource of another host and the state is inherited. Step S67: Switching is performed instantly by switching the line connected to the service element at a timing when the influence on the service is small.
Step S68: If the service can be migrated normally, the original service element is deleted.
Step S69: Continue the service. Repeat this.

[Additional Notes]
The differences between the present embodiment (FIG. 3) and the prior art (FIG. 2) for solving the above problems of the present invention are as follows.
-Providing a service requirement table-Applying service elements and service requirements to the service configuration-Prediction of resource amount The effects of the above differences are as follows.
-The network function can be integrated into one computational resource.-In the past, the network function was set one by one, and the network function could not be integrated into one computational resource. The reasons for this are as follows.
-By inputting the network function as a service requirement, the service requirement can be aggregated, and by predicting the required resource amount, the allocated resource can be determined, so that it can be aggregated into one computational resource.

11: Service element list 12: Interface 13: Service requirement input unit 14: Service requirement application unit 15: Resource prediction unit 21: Resource allocation unit 300, 301: Service development system

Claims (7)

A service development system that creates one or more applications by combining two or more service elements to form a service configuration.
One or more service requirements in which the input operation required for the application including the network function and the application condition of the operation and the service element to which the operation and the application condition are imposed are described are described in the service requirement table. Service requirements input department and
Assembles the service configured by connecting the service elements described in each of the service requirements described in the service requirement table, for each of the service requirements, configuration template representing the service requirements as an element of the service configuration Is generated, and the generated setting template is associated with the service element described in the setting template, and the service requirement application unit is added to the assembled service configuration.
A resource prediction unit that virtually operates the service configuration and predicts the amount of computational resources and network function resources that meet each service requirement.
Equipped with
A service development system characterized by assembling the service configuration using the resource amount predicted by the resource prediction unit. The service development system according to claim 1, wherein the operation is to make a redundancy by using resources up to twice the resources, or to block communication from other than a service element. The network function included in the service requirement is a virtual network function that can be executed using computational resources.
The service development system according to claim 1 or 2, wherein the service requirement application unit aggregates the service requirements for each service element described in the service requirements to assemble the service configuration. A resource prediction method executed by a service development system that predicts the amount of resources required when creating a service configuration by combining two or more service elements to create one or more applications.
The service development system
One or more service requirements in which the input operation required for the application including the network function and the application condition of the operation and the service element to which the operation and the application condition are imposed are described are described in the service requirement table. Service requirement input procedure and
The service element described in each service requirement described in the service requirement table is connected to assemble the service configuration, and a setting template representing the service requirement as an element of the service configuration is provided for each service requirement. The service requirement application procedure to be added to the assembled service configuration by associating the generated and generated setting template with the service element described in the setting template, and
A resource prediction procedure that virtually operates the service configuration and predicts the amount of computational resources and network function resources that meet each service requirement, and
And
A resource prediction method characterized by assembling the service configuration using the resource amount predicted by the resource prediction procedure. The resource prediction method according to claim 4, wherein the operation is to make a redundancy by using resources up to twice the resources, or to block communication from other than a service element. The network function included in the service requirement is a virtual network function that can be executed using computational resources.
The resource prediction method according to claim 4 or 5, wherein in the service requirement application procedure, the service requirements are aggregated for each service element described in the service requirements to assemble the service configuration. A service development program for operating a computer as the service development system according to any one of claims 1 to 3.

Images