Processing allocation device and processing allocation method

Abstract

The objective of the present disclosure is to provide a process allocation device that suppresses costs and enables derivation of an optimal method in terms of efficiency of dividing processes. A process allocation device according to the present disclosure comprises: a simulation execution unit for simulatively executing a cooperative operation between at least a cloud server and an edge device; a metrics extraction unit for extracting simulation environment metrics, which are indices for evaluating a non-functional requirement in a cooperative operation, from an execution log, which is an execution result from the simulation execution unit; and a process allocation unit for deriving an allocation of processes for executing the cooperative operation on the basis of the simulation environment metrics extracted by the metrics extraction unit.

Description

[Technical field]

[0001] The present disclosure relates to a process allocation device and a process allocation method for dividing a plurality of processes included in one function and allocating the divided processes to a plurality of devices. [Background technology]

[0002] Functions are being developed that provide new added value to customers by building IoT (Internet of Things) systems (hereafter simply referred to as "systems") that connect cloud servers (hereafter simply referred to as "clouds") to edge devices such as smartphones, and by performing processing and data sharing between the two.

[0003] When developing a collaborative function in a system, the processing required to realize the function must be appropriately distributed between the cloud and edge devices. When allocating the processing, it is necessary to consider the non-functional requirements for the cloud, edge devices, and the communication between the cloud and edge devices.

[0004] Non-functional requirements that must be considered include, for example, the load on the central processing unit (CPU) of the edge device, the amount of communication between the cloud and the edge device, charges incurred for using the cloud, etc. If the design of processing distribution fails, problems such as CPU resource pressure and excessive charges may arise, requiring a rework of the design.

[0005] Since non-functional requirements are multifaceted, it is difficult to build a system that takes all non-functional requirements into consideration. In addition, in order to confirm whether a system meets the non-functional requirements, it is necessary to build a system that applies the divided processes and analyze various metrics obtained by executing the processes in the system, which increases the verification cost.

[0006] Therefore, in order to build a system that satisfies non-functional requirements, it is useful to take measures to reduce the time and cost of system design by automating the manual work required for construction.For example, a method has been proposed in which the values ​​of metrics corresponding to non-functional requirements are automatically collected and the collected metrics are optimized to design a system (for example, see Patent Document 1 and Non-Patent Document 1).

[0007] Patent Document 1 proposes a method for allocating processing between a cloud and an edge server by connecting an allocation device to a network between the cloud and the edge server and determining the allocation of processing using a mixed integer programming problem using load information of both as input.

[0008] Non-Patent Document 1 proposes a method for allocating tasks using an NP-complete problem, with the network bandwidth and memory capacity between the cloud and edge servers as constraints. [Prior art documents] [Patent documents]

[0009] [Patent Document 1] International Publication No. 2020 / 004380 [Non-patent literature]

[0010] [Non-Patent Document 1] Boyang Peng, et al, "R-Storm: Resource-Aware Scheduling in Storm", Proceedings of the 16th Annual ACM Middleware Conference, Pages 149-161, Vancouver, BC, Canada, December 07-11, 2015. Summary of the Invention [Problem to be solved by the invention]

[0011] As described above, when installing a new function in a system, it is required to efficiently derive a design that satisfies non-functional requirements such as CPU utilization, network load, and cloud service charges by appropriately distributing processing among devices that make up the system. Therefore, a method has been proposed in which the partitioned processing is applied to devices in operation, resources such as the CPU utilization and memory usage of each device, as well as the amount of communication between devices, are collected from the system, and the results are analyzed to optimize the partitioning of processing.

[0012] However, with the conventional methods described above, it is necessary to build an operational system using a public cloud and actual devices, and this necessitates tasks such as deploying programs to the cloud and edge devices, coordinating the procurement of actual devices, and configuring cloud security, resulting in high costs for building the environment.

[0013] Patent Document 1 assumes dynamic allocation using the actual machine environment, and since it is necessary to build a system including the actual machine in order to obtain the optimal allocation method, the cost of building the environment to perform verification is high.

[0014] Non-Patent Document 1 proposes an algorithm for optimizing the method of allocating processing among a plurality of devices, but does not mention issues such as a method of building a system and a method of acquiring metric values.

[0015] The present disclosure has been made to solve such problems, and has an object to provide a process allocation device that is capable of suppressing costs and efficiently deriving an optimal process division method. [Means for solving the problem]

[0016] In order to solve the above problems, a processing allocation device according to the present disclosure includes a simulation execution unit that simulates a collaborative operation between at least a cloud server and an edge device, a metrics extraction unit that extracts simulated environment metrics that are indices for evaluating non-functional requirements in the collaborative operation from an execution log that is the execution result of the simulation execution unit, and a processing allocation unit that derives allocation of processing for executing the collaborative operation based on the simulated environment metrics extracted by the metrics extraction unit. The execution log includes at least a monitoring log of resource usage in each of the cloud server and the edge device, and the metrics extraction unit extracts from the monitoring log transitions of resource usage in at least the cloud server and the edge device, and includes the transitions in the simulated environment metrics. . Effect of the Invention

[0017] According to the present disclosure, it is possible to suppress costs and efficiently derive an optimal process division method.

[0018] The objects, features, aspects, and advantages of the present disclosure will become more apparent from the following detailed description and the accompanying drawings. [Brief description of the drawings]

[0019] [Figure 1] 1 is a block diagram showing an example of a configuration of a processing allocation device according to a first embodiment. [Diagram 2] 4 is a flowchart showing an example of the operation of the processing allocation device according to the first embodiment. [Diagram 3] FIG. 11 is a diagram showing an example of non-functional requirement metrics before conversion of each device according to the first embodiment. [Figure 4] FIG. 2 is a diagram showing an example of non-functional requirement metrics before conversion of a network according to the first embodiment. [Diagram 5] FIG. 2 is a diagram showing an example of system specification information including specification information of each device according to the first embodiment. [Figure 6] FIG. 2 is a diagram showing an example of system specification information related to a usage fee of a public cloud according to the first embodiment. [Figure 7] FIG. 11 is a diagram showing an example of non-functional requirement metrics after conversion of each device according to the first embodiment. [Figure 8]FIG. 11 is a diagram showing an example of non-functional requirement metrics after conversion of the network according to the first embodiment. [Figure 9] FIG. 2 is a diagram showing an example of system specification information related to a network in accordance with the first embodiment. [Figure 10] FIG. 11 is a diagram showing an example of display of a processing allocation result according to the first embodiment. [Figure 11] FIG. 11 is a block diagram showing an example of a configuration of a processing allocation device according to a second embodiment. [Figure 12] FIG. 11 is a diagram showing an example of display of a processing allocation result according to the second embodiment. [Figure 13] FIG. 11 is a diagram showing an example of display of a processing allocation result according to the second embodiment. [Figure 14] FIG. 11 is a diagram showing an example of a network configuration according to a third embodiment. [Figure 15] FIG. 11 is a diagram showing an example of a network configuration according to a third embodiment. [Figure 16] FIG. 11 is a diagram illustrating an example of setting network constraints according to the third embodiment. [Figure 17] FIG. 13 is a diagram showing an example of a screen display for comparing optimization results for each network configuration according to the third embodiment. [Figure 18] FIG. 2 is a diagram illustrating an example of a hardware configuration of a process allocation device according to the first to third embodiments. [Figure 19] FIG. 2 is a diagram illustrating an example of a hardware configuration of a process allocation device according to the first to third embodiments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0020] <Embodiment 1> FIG. 1 is a block diagram showing an example of a configuration of a processing allocation device according to the first embodiment.

[0021] The processing allocation device includes a simulation execution unit 10, a metrics extraction unit 21, a metrics conversion unit 22, a processing allocation optimization unit 23, a simulation execution control unit 24, and an output unit 25. The simulation execution unit 10 includes a cloud server simulation execution unit 11, a gateway simulation execution unit 12, an edge device simulation execution unit 13, a network simulation execution unit 14, and a distribution processing execution unit 15.

[0022] The processing allocation device also holds a simulation execution log 31, system specification information 32, non-functional requirement metrics before conversion 33, non-functional requirement metrics after conversion 34, evaluation weight values ​​35, and processing allocation information 36. Each piece of information may be stored in separate storage units (not shown), or may be stored together in a single storage unit (not shown). The storage unit may be provided outside the processing allocation device.

[0023] In Fig. 1, the simulation execution unit 10 includes one each of a cloud server simulation execution unit 11, a gateway simulation execution unit 12, and an edge device simulation execution unit 13, but the configuration does not necessarily have to be as shown in Fig. 1. For example, if there are multiple edge devices in the system to be simulated, there may be as many edge device simulation execution units 13 as there are edge devices. Also, in the case of a system in which there is no gateway and the cloud and the edge devices are directly connected, the configuration may exclude the gateway simulation execution unit 12. Furthermore, if the processing on the cloud side is realized by multiple instances, there may be multiple cloud server simulation execution units 11.

[0024] Regarding the allocation information for dividing the newly developed function and allocating it to each device (cloud, edge device, gateway), the final optimized result is stored in the storage unit as processing allocation information 36.

[0025] Here, a method for deriving the processing allocation information 36 will be described with reference to the flowchart of FIG.

[0026] The process allocation information 36 is derived by performing an initialization process (step S1), a simulation (step S2), metrics extraction (step S3), metrics conversion (step S4), and optimization calculation (step S5). Each step will be described in detail below.

[0027] In the initialization process (step S1), the processing allocation device initializes data before executing the optimization process. First, simulation execution conditions are set for the simulation execution unit 10 and the cloud server simulation execution unit 11, gateway simulation execution unit 12, edge device simulation execution unit 13, and network simulation execution unit 14 that constitute the simulation execution unit 10. Examples of the execution conditions to be set include model settings and control parameters of the edge device to be simulated. In addition, an initial allocation of processing to each device is determined with respect to the processing allocation information 36. There are no particular restrictions on the method of determining the initial allocation, and the user may freely determine it.

[0028] In the simulation execution (step S2), the simulation execution control unit 24 starts the simulation execution unit 10 and controls it to simulate the behavior in the simulated environment of the cloud, the gateway, the edge device, and the network between each device. At that time, the distribution processing execution unit 15 distributes the processing divided according to the contents of the processing allocation information 36 to each of the cloud server simulation execution unit 11, the gateway simulation execution unit 12, and the edge device simulation execution unit 13. There are several possible ways to realize the cooperation between the distribution processing execution unit 15 and the cloud server simulation execution unit 11, the gateway simulation execution unit 12, and the edge device simulation execution unit 13. For example, there is a method of defining an API (Application Programming Interface) that can execute the processing assigned to each device from outside, and calling the API at any timing in each of the cloud server simulation execution unit 11, the gateway simulation execution unit 12, and the edge device simulation execution unit 13 to execute the target processing. The execution result of the simulation is stored in the storage unit as a simulation execution log 31.

[0029] In metrics extraction (step S3), the metrics extraction unit 21 extracts metrics from a simulation execution log 31. The simulation execution log 31 is data output from commands provided by the OS (Operating System) and data output from measurement processes added to a program, and the like. Metrics extraction is performed by analyzing the simulation execution log 31.

[0030] The extracted metrics are mainly indices for evaluating the non-functional requirements of the system, and are used to derive converted non-functional requirement metrics 34 to be used in the optimization calculation execution (step S5) described below. Specifically, the metrics extraction unit 21 executes a process of extracting transition data of CPU usage from the CPU resource monitoring log, and a process of extracting the size of the payload used in communication from the communication log. The extracted metrics are stored in the storage unit as pre-conversion non-functional requirement metrics 33.

[0031] Fig. 3 shows an example of items of non-functional requirement metrics 33 before conversion stored by the process of metrics extraction (step S3). As shown in Fig. 3, the metrics items for each device include CPU usage time (average CPU usage time, maximum CPU usage time) due to the execution of the process, memory usage, and disk usage. Fig. 4 shows an example of metrics items for communication between devices. As shown in Fig. 4, the metrics items include communication volume indicating the amount of communication data, and number of requests indicating the number of requests. Note that the items shown in Figs. 3 and 4 are only examples, and types of metrics to be extracted may be added or deleted in order to improve the content and accuracy of optimization.

[0032] In metrics conversion (step S4), the metrics conversion unit 22 uses the system specification information 32 and the pre-conversion non-functional requirement metrics 33 to convert the metrics values ​​corresponding to the simulated environment into metrics values ​​expected during operation in the real environment, and stores them in the memory unit as converted non-functional requirement metrics 34.

[0033] The specifications of the devices that make up the simulated environment and the network performance between the devices are different from those of the real environment. For example, the CPU specifications of each device are different in the real environment, and a relatively low-performance microcomputer may be used in an edge device. On the other hand, in the simulated environment, devices basically run on a general-purpose PC (Personal Computer) with the same specifications. Also, while various methods such as Ethernet (registered trademark) or Wi-Fi (registered trademark) can be used for communication between devices in the real environment, communication in the simulated environment is communication within the general-purpose PC. In the metrics conversion (step S4), a correction calculation is performed that takes into account the difference in performance due to such an execution environment, and an expected value in the real environment is derived.

[0034] An embodiment of the correction calculation in the process of the metrics conversion (step S4) will be described. FIG. 5 is a diagram showing an example of the system specification information 32. The specification information included in the system specification information 32 targets a simulated environment in which a simulation is performed and a device operating in a real environment. Items of the specification information include a CPU frequency, the number of CPU cores, and the amount of memory installed. In addition, in the case of a cloud, the type of virtual machine operating (for example, a t3.xlarge instance in EC2 of AWS (Amazon Web Service)) may also be described. Note that the items shown in FIG. 5 are merely examples, and items may be added or deleted to improve the content and accuracy of optimization.

[0035] Cloud charges can also be included as an evaluation item for processing allocation. The fee structure of the target public cloud may be input to be included in the system specification information 32. In this case, the usage unit price for the public cloud service as shown in Fig. 6 can be used to derive the expected charge amount from the acquired non-functional requirement metrics 33 before conversion.

[0036] In the metrics conversion (step S4), the metrics conversion unit 22 converts the metrics values ​​by performing a correction operation on the non-functional requirement metrics 33 before conversion based on the values ​​defined in the system specification information 32. FIGS. 7 and 8 show an example of the values ​​of the non-functional requirement metrics 34 after conversion. For example, the expected value of the average CPU usage rate in the edge device 1 can be calculated by two correction processes. First, the average CPU usage time in the simulated environment is input, and the average CPU usage time in the edge device 1 expected during operation in the actual environment is derived by multiplying the average CPU usage time by the ratio of the CPU specifications. Next, the average CPU usage rate converted from the derived average CPU usage time is added to the average CPU usage rate by processes other than the distribution target (processes other than non-functional requirements) to derive the average CPU usage rate in the edge device 1. If the original average CPU usage rate in the edge device 1 is 15%, the expected value of the average CPU usage rate of the edge device 1 after the distributed processes are integrated can be calculated as shown in the following formula (1). (2.9×10÷1000)+0.15=0.03+0.15=0.18=18% (1)

[0037] In performing optimization calculations (step S5), processing allocation optimization unit 23 evaluates the validity of the current processing allocation using pre-conversion non-functional requirement metrics 33, converted non-functional requirement metrics 34, and evaluation weight values ​​35 as inputs, and stores the optimal processing allocation result derived by calculation in a storage unit as processing allocation information 36. Although processing allocation optimization unit 23 performs optimization calculations to derive the allocation result, it is not necessary to use a specific optimization algorithm, and any algorithm may be adopted depending on the number of types of metrics and the characteristics of the evaluation method.

[0038] The evaluation weight value 35 is set by the user according to the importance of the evaluation item. For example, if the importance of the processing load is high, the weight value of a metric such as CPU usage rate is set high. In this case, instead of specifying the weight as an immediate value, a method may be adopted in which a set of weight values ​​according to the evaluation contents is defined as a category in advance and the user selects the category.

[0039] For example, when detecting and evaluating that a non-functional requirement is below a required value (a non-functional requirement does not satisfy the required value), a method can be considered in which a penalty term is added to the evaluation function when the metric value is worse than the required value, and this is fed back to the optimization algorithm. For example, the following formula (2) can be considered as a simple evaluation function that gives a penalty when the value of any evaluation metric exceeds a threshold value. Here, x n is a flag variable that outputs 1 when the metric value becomes worse than the threshold, and m n is a weighting coefficient that represents the penalty value when the value of the nth metric deteriorates. F(x) = m1x1 + m2x2 + + m n x n (2)

[0040] For example, by calculating the communication volume per unit time using the converted non-functional requirement metrics 34 and raising a flag if the value exceeds the upper limit of the network throughput in the actual environment as shown in Figure 9, the network throughput can be included in the assessment of the validity of the allocation.

[0041] Note that the above evaluation function is just one example. Instead of determining the variable value discretely based on a threshold value, the difference from the target value may be treated as a continuous variable, and an evaluation index that combines the values ​​of multiple metrics may be introduced to define the evaluation variable.

[0042] In step S6, the processing allocation optimization unit 23 determines whether the processing allocation information 36 has converged in the optimization calculation. If the optimization calculation of the processing allocation has not converged, the processing allocation information 36 derived by the processing allocation optimization unit 23 is used as a new allocation, and the simulation is executed again by the simulation execution unit 10 (simulation execution in step 2). At this time, the processing allocation information 36 is input to the distribution processing execution unit 15, and the cloud server simulation execution unit 11, gateway simulation execution unit 12, edge device simulation execution unit 13, and network simulation execution unit 14 in the simulation execution unit 10 execute processing under the control of the simulation execution control unit 24.

[0043] After that, the same process as described above is performed to evaluate the validity of the new allocation. By repeatedly performing such a process, an optimal processing allocation is derived through optimization calculation.

[0044] When the optimization calculation by the processing allocation optimization unit 23 is completed in step S6, the execution result is output (step S7).

[0045] In outputting the execution results (step S7), the output unit 25 notifies the user of the contents of the processing allocation information 36 derived as the optimization result. The output unit 25 graphically displays the optimal processing allocation result on a monitor, for example.

[0046] For example, the output unit 25 may display the process allocation results as a graph structure as shown in Fig. 10, and present the interface of process distribution to the user by dividing the areas of processes allocated to the cloud, gateway, and edge device. Note that the method of notifying the user may be any method other than display on the monitor, such as output to a file.

[0047] From the above, according to the first embodiment, when a newly developed function is applied to a system, an optimal method for distributing the processing for realizing the newly developed function to each device constituting the system can be derived without constructing an actual operating system. This makes it possible to suppress costs and efficiently derive an optimal processing division method.

[0048] <Embodiment 2> The optimization of processing allocation explained in the first embodiment basically uses a single evaluation function and evaluation weight value to derive a single optimal allocation information. However, depending on the use case, instead of adopting the optimization result by a single evaluation method as it is, it may be possible to adopt a method in which multiple evaluation methods are set to perform optimization and an appropriate distribution method is selected from each optimization result.

[0049] For example, when considering cloud billing, there are two possible viewpoints: deriving allocations using an evaluation method that minimizes billing amounts, and deriving allocations using an evaluation method that prioritizes performance while allowing some increase in billing. With the above methods, users can check the allocation results from both viewpoints and decide whether they can tolerate an increase in billing amounts before adopting one of them.

[0050] A simple method for implementing the above-mentioned use cases is to multiplex the processing allocation optimization unit 23 so as to correspond to each evaluation function, and execute optimization calculations and simulations for each evaluation function. This method can be implemented with a simple configuration because optimization calculations for each evaluation function can be performed independently, but it has the drawback of increasing the calculation time.

[0051] In order to reduce the calculation time of the optimization calculation, it is necessary to devise a method for reducing redundant calculation by sharing some of the processes executed in the optimization calculation. For example, as shown in FIG. 11, when it becomes necessary to execute a simulation under the same conditions for each evaluation function in the process of executing the optimization calculation, the non-functional requirement metrics 33 before conversion and the non-functional requirement metrics 34 after conversion corresponding to the results of the previously executed simulation are stored so as to be mapped (associated) with the processing allocation history 40, and the processing allocation optimization unit 23 refers to these contents, thereby reducing the execution of duplicated simulations and speeding up the optimization calculation. Note that the configuration other than that shown in FIG. 11 is the same as that of the processing allocation device shown in FIG. 1.

[0052] As a result of executing the optimization calculation according to the second embodiment, the processing allocation result for each evaluation function is stored in the storage unit as processing allocation information 36. The output unit 25 notifies the user of the optimization result for each evaluation function included in the processing allocation information 36. For example, the output unit 25 may graphically display the allocation results on a monitor by dividing them by evaluation content, as shown in Figs. 12 and 13. Note that the method of notifying the user is not limited to the above method, and any method, such as output to a file, may be adopted.

[0053] From the above, according to the second embodiment, when it becomes necessary to execute a simulation under the same conditions for each evaluation function, it becomes possible to reduce redundant calculations by making some of the processes executed in the optimization calculation common. In addition, it is possible to notify the user of the process allocation results for each evaluation function.

[0054] <Embodiment 3> In the first embodiment, the network simulation execution unit 14 has a responsibility to simulate communication executed between any of the cloud server simulation execution unit 11, the gateway simulation execution unit 12, and the edge device simulation execution unit 13. The communication executed via the network simulation execution unit 14 is monitored by the metrics extraction unit 21, and the communication volume and the like are measured.

[0055] There are various possible connection methods between devices, as shown in Figs. 14 and 15. For example, when wireless communication is assumed, BLE (Bluetooth Low Energy) can be adopted for its power saving properties. When high-speed wired communication is assumed, a configuration in which a switch is inserted between the gateway and edge device and connected via Ethernet (registered trademark) can be considered. In a configuration in which a switch is inserted between the gateway and edge device, communication performance will deteriorate if the communication being sent and received exceeds the processing capacity of the switch, and in such a case, the configuration must be reconsidered.

[0056] Additionally, communication volume varies depending on the communication protocol selected. Even when communicating the same data, the total communication volume changes depending on the data size of the header section added by the selected communication protocol. For example, the header size of HTTP (Hypertext Transfer Protocol), which is used for communication with the web, starts at 50 bytes, whereas the header size of MQTT (Message Queue Telemetry Transport) starts at 2 bytes, so sending data with MQTT results in less total communication volume.

[0057] In the simulation of the first embodiment, the network simulation execution unit 14 can perform simulation in consideration of the communication protocol and connection configuration for communication occurring between any of the target cloud servers, gateways, and edge devices. To realize such simulation, the network simulation execution unit 14 defines the configuration assumed by the network. Specifically, as shown in FIG. 16, the arrangement of communication devices such as switches used in the target network and the connections between the devices are defined. In addition, performance values ​​such as the switch capacity and transfer rate of the communication devices and the communication protocol are defined as settings related to the behavior of the network.

[0058] 16 shows an example of setting the network configuration graphically on a GUI (Graphical User Interface), but it is not necessary to use a GUI for the setting. For example, the network configuration may be defined in any manner, such as by describing it in a structured document such as XML (Extensible Markup Language) or YAML (YAML Ain't Markup Language).

[0059] As described above, by setting the communication protocol and device specifications of the target network, it is possible to derive performance constraints such as throughput and communication speed in the network. In addition, by adding the constraints to the evaluation function, the processing allocation optimization unit 23 can derive processing allocation that takes into account constraints due to the assumed network configuration.

[0060] It is also expected that the trend of communication traffic will change depending on the difference in network configuration. As shown in FIG. 17, the output unit 25 can compare and display the contents of the non-functional requirement metrics 33 before conversion, the non-functional requirement metrics 34 after conversion, and the processing allocation information 36 for a plurality of network configurations. In this way, by comparing the behavior trends of the IoT system and the optimal function allocation results, the developer is supported to select an appropriate network configuration. Note that FIG. 17 is an output example when the comparison results are displayed on the screen, and does not limit the contents of the output items or the adoption of other output formats such as file output.

[0061] The definition of the network configuration described in the third embodiment is not essential, and a method of simply describing network constraints as shown in FIG. 9 in the first embodiment may be adopted.

[0062] <Hardware configuration> The functions of the cloud server simulation execution unit 11, gateway simulation execution unit 12, edge device simulation execution unit 13, network simulation execution unit 14, distributed processing execution unit 15, metrics extraction unit 21, metrics conversion unit 22, processing allocation optimization unit 23, simulation execution control unit 24, and output unit 25 in the processing allocation device described in embodiment 1 are realized by processing circuits. That is, the processing allocation device includes a processing circuit for simulating the operation of a cloud, simulating the operation of a gateway, simulating the operation of an edge device, and simulating the operation of a network, distributing the processing divided in accordance with the contents of processing allocation information 36 to each of the cloud server simulation execution unit 11, the gateway simulation execution unit 12, and the edge device simulation execution unit 13, extracting pre-conversion non-functional requirement metrics 33 from the simulation execution log 31, converting the pre-conversion non-functional requirement metrics 33 into post-conversion non-functional requirement metrics 34, evaluating the validity of the current processing allocation based on the pre-conversion non-functional requirement metrics 33 and the post-conversion non-functional requirement metrics 34, controlling the execution of the simulation in the simulation execution unit 10, and outputting the processing allocation information. The processing circuit may be dedicated hardware, or may be a processor (also called a CPU, central processing unit, processing unit, arithmetic unit, microprocessor, microcomputer, or DSP (Digital Signal Processor)) that executes a program stored in a memory.

[0063] When the processing circuit is a dedicated hardware, the processing circuit 50 may be, for example, a single circuit, a composite circuit, a programmed processor, a parallel programmed processor, an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or a combination of these, as shown in Fig. 18. Each function of the cloud server simulation execution unit 11, the gateway simulation execution unit 12, the edge device simulation execution unit 13, the network simulation execution unit 14, the distribution processing execution unit 15, the metrics extraction unit 21, the metrics conversion unit 22, the processing allocation optimization unit 23, the simulation execution control unit 24, and the output unit 25 may be realized by the processing circuit 50, or each function may be realized by a single processing circuit 50.

[0064] 19, each function of the cloud server simulation execution unit 11, the gateway simulation execution unit 12, the edge device simulation execution unit 13, the network simulation execution unit 14, the distribution processing execution unit 15, the metrics extraction unit 21, the metrics conversion unit 22, the processing allocation optimization unit 23, the simulation execution control unit 24, and the output unit 25 is realized by software, firmware, or a combination of software and firmware. The software or firmware is written as a program and stored in the memory 52. ​​The processor 51 realizes each function by reading and executing the program recorded in the memory 52. That is, the processing allocation device includes a memory 52 for storing a program that results in the execution of the steps of simulating cloud operation, simulating gateway operation, simulating edge device operation, simulating network operation, distributing processing divided in accordance with the contents of processing allocation information 36 to each of the cloud server simulation execution unit 11, the gateway simulation execution unit 12, and the edge device simulation execution unit 13, extracting pre-conversion non-functional requirement metrics 33 from the simulation execution log 31, converting the pre-conversion non-functional requirement metrics 33 into converted non-functional requirement metrics 34, evaluating the validity of the current processing allocation based on the pre-conversion non-functional requirement metrics 33 and the converted non-functional requirement metrics 34, controlling the execution of the simulation in the simulation execution unit 10, and outputting the processing allocation information. In addition, these programs can also be said to cause a computer to execute the procedures or methods of the cloud server simulation execution unit 11, gateway simulation execution unit 12, edge device simulation execution unit 13, network simulation execution unit 14, distribution processing execution unit 15, metrics extraction unit 21, metrics conversion unit 22, processing allocation optimization unit 23, simulation execution control unit 24, and output unit 25.Here, the memory may be, for example, a non-volatile or volatile semiconductor memory such as RAM (Random Access Memory), ROM (Read Only Memory), flash memory, EPROM (Erasable Programmable Read Only Memory), EEPROM (Electrically Erasable Programmable Read Only Memory), a magnetic disk, a flexible disk, an optical disk, a compact disk, a DVD (Digital Versatile Disc), or any storage medium that will be used in the future.

[0065] In addition, with regard to each function of the cloud server simulation execution unit 11, gateway simulation execution unit 12, edge device simulation execution unit 13, network simulation execution unit 14, distribution processing execution unit 15, metrics extraction unit 21, metrics conversion unit 22, processing allocation optimization unit 23, simulation execution control unit 24, and output unit 25, some functions may be realized by dedicated hardware and other functions may be realized by software or firmware.

[0066] Thus, the processing circuitry may implement the functions described above through hardware, software, firmware, or a combination of these.

[0067] Although the hardware configuration of the process allocation device described in the first embodiment has been described above, the hardware configuration of the process allocation device described in the second and third embodiments is similar.

[0068] Within the scope of the present disclosure, the embodiments can be freely combined, and each embodiment can be modified or omitted as appropriate.

[0069] Although the present disclosure has been described in detail, the above description is illustrative in all respects and is not restrictive. It is understood that countless variations not illustrated can be envisioned. [Explanation of symbols]

[0070] 10 Simulation execution unit, 11 Cloud server simulation execution unit, 12 Gateway simulation execution unit, 13 Edge device simulation execution unit, 14 Network simulation execution unit, 15 Distribution processing execution unit, 21 Metrics extraction unit, 22 Metrics conversion unit, 23 Processing allocation optimization unit, 24 Simulation execution control unit, 25 Output unit, 31 Simulation execution log, 32 System specification information, 33 Non-functional requirement metrics, 34 Non-functional requirement metrics, 35 Evaluation weight value, 36 Processing allocation information, 40 Processing allocation history, 50 Processing circuit, 51 Processor, 52 Memory.

Claims

1. a simulation execution unit that simulates a cooperative operation between at least a cloud server and an edge device; a metrics extraction unit that extracts simulated environment metrics, which are indices for evaluating non-functional requirements in the collaboration operation, from an execution log that is an execution result of the simulation execution unit; a process allocation unit that derives allocation of processes for executing the collaborative operation based on the simulated environment metrics extracted by the metrics extraction unit; Equipped with the execution log includes at least a monitoring log of resource usage in each of the cloud server and the edge device; The metrics extraction unit extracts from the monitoring log trends of the resource usage at least in each of the cloud server and the edge device, and includes these trends in the simulated environment metrics.

2. the simulation execution unit includes a cloud server simulation execution unit that simulates an operation of the cloud server, an edge device simulation execution unit that simulates an operation of the edge device, a gateway simulation execution unit that simulates an operation of a gateway, and a network simulation execution unit that simulates an operation of a network, The processing allocation device according to claim 1 , wherein at least two of the cloud server simulation execution unit, the edge device simulation execution unit, the gateway simulation execution unit, and the network simulation execution unit simulate the cooperative operation.

3. The processing allocation device according to claim 1 or 2, further comprising a metrics conversion unit that converts the simulated environment metrics extracted by the metrics extraction unit into real environment metrics assumed when the collaborative operation is actually executed based on system specification information including specification information of a simulation device that executes the simulation execution unit, the cloud server, and the edge device.

4. 3. The processing allocation device according to claim 1, wherein the processing allocation section derives the allocation based on the simulated environment metrics extracted by the metrics extraction section and evaluation weight values ​​for the non-functional requirements.

5. The processing allocation device according to claim 1 , wherein the processing allocation section derives the allocation for each of a plurality of evaluation functions.

6. The processing allocation device according to claim 3 , wherein the processing allocation section derives the allocation for each of a plurality of evaluation functions.

7. The processing allocation device described in claim 6, wherein when a common condition exists in each of the evaluation functions, the processing allocation unit derives the allocation for the current execution result based on a processing allocation history that associates the simulated environment metrics and the real environment metrics for past execution results with the allocation at that time.

8. The processing allocation device according to claim 1 , further comprising an output section that outputs the allocation derived by the processing allocation section.

9. The processing allocation unit derives a plurality of the allocations; The processing allocation device according to claim 8 , wherein the output unit outputs each of the allocations derived by the processing allocation unit.

10. an output unit that outputs the allocation derived by the processing allocation unit; The processing allocation device according to claim 5 , wherein the output unit outputs the allocation for each of the evaluation functions.

11. 3. The processing allocation device according to claim 2, wherein the metrics extraction unit derives constraints for a network targeted by the network simulation execution unit based on at least one predefined network configuration.

12. The processing allocation device according to claim 11 , wherein the processing allocation unit derives the allocation based on a constraint condition of the network.

13. an output unit that outputs the allocation derived by the processing allocation unit; 13. The processing allocation device according to claim 11, wherein the output unit outputs at least the simulated environment metrics and the allocation for a plurality of the network configurations in a comparable manner.

14. Simulating a cooperative operation between at least a cloud server and an edge device; extracting simulated environment metrics, which are indices for evaluating non-functional requirements in the collaborative operation, from an execution log that is a result of the execution; deriving an allocation of processes for executing the collaborative operations based on the extracted simulated environment metrics; the execution log includes at least a monitoring log of resource usage in each of the cloud server and the edge device; The processing allocation method, wherein the simulated environment metrics include transitions in the resource usage at least in the cloud server and the edge device extracted from the monitoring log.

Images