Microservice design support system and microservice design support method

Abstract

To provide a microservice design support system capable of appropriately arranging microservices in a migration destination system.SOLUTION: The MS design support system 100 includes an MS division plan creation unit 112 that creates a microservice division plan in which a function provided by the control system is divided into a plurality of microservices, an MS dependency relationship creation unit 113 that creates a dependency relationship of the plurality of microservices based on the microservice division plan, and an MS arrangement plan creation unit 114 that creates a microservice arrangement plan in which the plurality of microservices are arranged in resources based on the configuration information and the dependency relationship.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to a microservice design support system and a microservice design support method. [Background technology]

[0002] Control systems used in various industrial fields have business requirements defined from the perspective of safety and cooperation between various devices. For example, one business requirement is for the control system to determine the impact of a user's control instruction (e.g., an instruction to stop a device) on related devices and execute control processing based on the control instruction within the desired time for the necessary devices. In order for the control system to meet the business requirements, the internal processing of the control server and controller is optimized with performance as the priority. For this reason, multiple devices configured in a control system often have modules with the same functions, and internal variables are often shared by multiple modules.

[0003] In response to this situation, advances in hardware, such as improved machine specifications, have increased the number of functions that can be installed in a single device, making it possible to reduce the number of devices used in a control system. When reducing the number of devices, optimization of software configuration is required from the perspective of device maintenance. One example of software configuration optimization is consolidating similar processes that are distributed across different devices into a single device. This also leads to consolidating similar processes that are distributed across different programs into a single program.

[0004] One way to optimize software configuration is to turn software into microservices. In the following explanation, microservices will be referred to as "MS," and microservices will be abbreviated as "MSization." Microservices include splitting a single function configured in a current system into multiple MSs, or aggregating identical or similar functions distributed across multiple devices into a single MS.

[0005] Additionally, the current control system that has not yet been converted to MS is called the "current system," and the new control system to which the current system will be migrated is called the "target system." Current systems include, for example, power facilities (substations, etc.) managed by railway companies and information control systems used for railway traffic management. The size and complexity of current systems are barriers to migrating them to MS.

[0006] Current systems include a large amount of software. Therefore, by converting software into MS, the current system will also be converted into MS. When software is converted into MS, internal processing becomes loosely coupled on a function basis that is easy to reuse. This has the advantage of improving the flexibility and scalability of the software and distributing the software load. However, it also makes it more difficult to achieve synchronization between MS. Therefore, the more software functions are subdivided and converted into MS, the more communication overhead occurs between multiple MS, which has the disadvantage of affecting the performance of the MS.

[0007] Patent Document 1 describes a technology that "provides splitting support information to assist in splitting a first microservice based on information about load pattern matching groups that are grouped based on the similarity of load patterns and data sharing groups that are grouped based on the data structure of data accessed by an API (Application Programming Interface) and splits the first microservice." [Prior art documents] [Patent documents]

[0008] [Patent Document 1] Patent Publication No. 2021-9589 Summary of the Invention [Problem to be solved by the invention]

[0009] That is, Patent Document 1 describes a technology for implementing MS, starting from an API that provides indivisible monolithic software, while taking into consideration the resources and performance used in the current system. However, in current systems, the same processing is often included in multiple devices. For this reason, Patent Document 1 does not disclose an optimal MS implementation or an optimal MS placement method in cases where the configuration of modules used in conventional software is changed, or the device that executes the software is changed, or the devices are consolidated.

[0010] In the past, since the processing capabilities required for each device were different, there was no problem even if the same processing was included in each device. In recent years, when consolidating devices by using MS, it has sometimes been better to consolidate the same processing included in each device. However, when the same processing included in each device is made into a common MS, the method disclosed in Patent Document 1 is not useful.

[0011] The present invention has been made in consideration of these circumstances, and aims to enable the appropriate placement of microservices in a destination system. [Means for solving the problem]

[0012] The microservice design support system of the present invention includes a microservice division plan creation unit that creates a microservice division plan that divides the functions provided by the control system into multiple microservices using analysis information about the program used in the current control system, configuration information including the resource configuration of a destination system to which the functions of the control system will be migrated, and business information including business requirements specified in the destination system; a microservice dependency creation unit that creates dependencies between the multiple microservices based on the microservice division plan; and a microservice deployment plan creation unit that creates a microservice deployment plan that deploys the multiple microservices on resources based on the configuration information and the dependencies. [Effects of the Invention]

[0013] According to the present invention, microservices can be appropriately deployed in a destination system. Problems, configurations, and effects other than those described above will become apparent from the following description of the embodiments. [Brief explanation of the drawings]

[0014] [Figure 1] 1 is a block diagram showing a configuration example of an MS design support system according to an embodiment of the present invention. [Figure 2] FIG. 3 is a diagram illustrating an example of information stored in a program information storage unit according to an embodiment of the present invention. [Figure 3] FIG. 4 is a diagram illustrating information stored in a resource information storage unit according to an embodiment of the present invention. [Figure 4] FIG. 2 is a diagram illustrating information stored in a business requirement storage unit according to an embodiment of the present invention. [Figure 5] FIG. 10 is a diagram illustrating information stored in a division requirement storage unit according to an embodiment of the present invention. [Figure 6] FIG. 4 is a diagram showing information stored in an evaluation information storage unit according to one embodiment of the present invention. [Figure 7] FIG. 10 is a diagram showing information stored in a distribution plan storage unit according to an embodiment of the present invention. [Figure 8] FIG. 10 is a diagram showing information stored in a placement plan storage unit according to an embodiment of the present invention. [Figure 9] FIG. 4 is a diagram showing information stored in an evaluation result storage unit according to one embodiment of the present invention. [Figure 10] 10 is a flowchart illustrating an example of a program analysis process according to an embodiment of the present invention. [Figure 11] 10 is a flowchart illustrating an example of an MS division plan creation process according to an embodiment of the present invention. [Figure 12] 10 is a flowchart showing an example of a first process according to an embodiment of the present invention. [Figure 13] 10 is a flowchart showing an example of a second process according to an embodiment of the present invention. [Figure 14]10 is a flowchart illustrating an example of a third process according to an embodiment of the present invention. [Figure 15] 1A and 1B are diagrams illustrating an example of a configuration of a simple current system, a call graph, and an MS division plan according to an embodiment of the present invention. [Figure 16] 10 is a flowchart illustrating an example of an MS dependency creation process according to an embodiment of the present invention. [Figure 17] 10 is a flowchart illustrating an example of an MS placement plan creation process according to an embodiment of the present invention. [Figure 18] 1 is a flowchart illustrating an example of an MS evaluation process according to an embodiment of the present invention. [Figure 19] FIG. 1 is a diagram illustrating a configuration of a current system according to an embodiment of the present invention. [Figure 20] FIG. 1 is a diagram illustrating an MS deployment plan for a destination system according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0015] Specific examples of an MS design support system and an MS design support method according to embodiments of the present invention will be described below with reference to the accompanying drawings. In this specification and drawings, components having substantially the same functions or configurations are designated by the same reference numerals, and redundant explanations will be omitted.

[0016] [One embodiment] 1 is a block diagram showing an example of the configuration of an MS design support system 100. To the MS design support system 100, an input device 140 and an output device 150 are connected.

[0017] The MS design support system 100 converts the functions of the current system into MSs in order to migrate them to the destination system, and supports a series of MS design steps for allocating the MSs to the resources of the destination system.

[0018] The MS design support system 100 is a physical computing system, but may also be a logical computing system (for example, a virtual computer in a cloud environment) constructed based on a physical computing system. Therefore, the MS design support system 100 may be in the form of either a cloud server or an on-premise server.

[0019] The input device 140 and output device 150 are input / output consoles of the MS design support system 100. The input / output console may be configured in a client environment when the MS design support system 100 is used as a server. The MS design support system 100 creates an MS design proposal and an MS placement proposal. The MS design proposal also includes an MS division proposal in which one MS is divided into multiple MSs and the placement of the MSs is designed. In the following explanation, the MS division proposal will be used for explanation.

[0020] The input device 140 inputs data stored in each storage unit of the storage device 120. This data may be read from a data management device such as a portable storage medium or a remote storage system and input to the storage device 120.

[0021] The output device 150 is a display device such as a liquid crystal display device, and is an example of an output unit. The output device 150 displays the MS division plan and its arrangement information from the MS design support system 100.

[0022] The MS design support system 100 includes a processor 110, a storage device 120, and an input / output interface 130. The MS design support system 100 (computer) configures each functional unit by executing a program, and the functional units cooperate to execute a series of processes (MS design support method) shown in Figures 10 to 13, which will be described later. The storage device 120 and the input / output interface 130 are connected to the processor 110.

[0023] The processor 110 reads out program code of software that realizes each function according to an embodiment from the storage device 120, and realizes each functional unit. For example, a CPU (Central Processing Unit), an MPU (Micro Processing Unit), or a GPU (Graphics Processing Unit) is used as the processor 110. The processor 110 includes a program analysis unit 111, an MS division plan creation unit 112, an MS dependency creation unit 113, an MS placement plan creation unit 114, an evaluation unit 115, and a result output unit 116.

[0024] A program to be analyzed is input to the program analysis unit 111. The program analysis unit 111 outputs the results of analyzing the program as program information, and stores the program information in the program information storage unit 121.

[0025] The microservice division plan creation unit 112 (hereinafter referred to as the MS division plan creation unit 112) creates an MS division plan 710 (see FIG. 7 described later) in which functions provided by the control system are divided among multiple MSs, using analysis information of the program used in the current control system, configuration information including the resource configuration of a destination system to which functions of the control system will be migrated, and business information including business requirements specified in the destination system. To this end, the MS division plan creation unit 112 receives as input program information, resource information, business requirements, division requirements, and evaluation information (only the amount of code).

[0026] The MS division plan creation unit 112 reads program information from the program information storage unit 121, and reads resource information from the resource information storage unit 122. The MS division plan creation unit 112 also reads business requirements from the business requirement storage unit 123, reads division requirements from the division requirement storage unit 124, and reads evaluation information from the evaluation information storage unit 125. The evaluation information read and input by the MS division plan creation unit 112 is only the code amount of the program. The MS division plan creation unit 112 creates an MS division plan based on this input information. Thereafter, the MS division plan creation unit 112 outputs the created MS division plan and stores it in the division plan storage unit 126.

[0027] The microservice dependency creation unit 113 (hereinafter referred to as the MS dependency creation unit 113) creates dependency relationships between multiple MSs based on the MS division plan 710. To this end, the business requirements and the MS division plan are input to the MS dependency creation unit 113. The MS dependency creation unit 113 reads the business requirements from the business requirement storage unit 123 and reads the MS division plan from the division plan storage unit 126. The MS dependency creation unit 113 creates MS dependency relationships (the relationship between a calling MS and a called MS) based on this input information. Thereafter, the MS dependency creation unit 113 outputs the MS dependency relationships and stores them in the division plan storage unit 126.

[0028] The microservice placement plan creation unit 114 (hereinafter referred to as the MS placement plan creation unit 114) creates an MS placement plan in which multiple MSs are placed on resources based on configuration information and dependency relationships. To this end, the MS placement plan creation unit 114 receives as input the evaluation information read from the evaluation information storage unit 125, and creates an MS placement plan in which the MSs divided according to the MS division plan are placed in each layer and device of the destination system (see FIG. 20, which will be described later). Thereafter, the MS placement plan creation unit 114 stores the MS placement plan in the placement plan storage unit 127. Below, it will be explained how the current system is converted into an MS when it is migrated to the destination system.

[0029] The evaluation unit 115 evaluates whether or not an MS placement plan 810 (see FIG. 8 described later) satisfies business requirements based on the MS division plan, MS dependency relationships, and MS placement plan. The evaluation unit 115 reads the MS division plan and MS dependency relationships from the division plan storage unit 126, and reads the MS placement plan from the placement plan storage unit 127. The evaluation result of the MS placement plan by the evaluation unit 115 is expressed as, for example, OK or NG.

[0030] The result output unit 116 outputs the MS allocation plan shown in Fig. 20 (described later) together with the evaluation result to the output device 150 via the input / output interface 130. Note that the result output unit 116 may output the MS allocation plan before evaluation by the evaluation unit 115 to the output device 150. The result output unit 116 can also display the current system configuration shown in Fig. 19 (described later) and the MS allocation plan shown in Fig. 20. This display allows the user to confirm how the functions, features, etc. used in the current system configuration have been converted into MSs and how the MSs have been allocated to each device.

[0031] The storage device 120 is, for example, a nonvolatile storage such as a hard disk drive (HDD), a solid state drive (SSD), an optical disk, a magneto-optical disk, a magnetic tape, or a nonvolatile memory. The storage device 120 stores an operating system (OS) and various parameters, as well as programs for operating the MS design support system 100, various tables, data, and the like. For this reason, the storage device 120 is used as an example of a computer-readable non-transitory storage medium that stores programs executed by the MS design support system 100.

[0032] The storage device 120 includes a program information storage unit 121, a resource information storage unit 122, a business requirement storage unit 123, a division requirement storage unit 124, an evaluation information storage unit 125, a division plan storage unit 126, an allocation plan storage unit 127, and an evaluation result storage unit 128.

[0033] An input device 140 and an output device 150 are connected to the input / output interface 130. The input device 140 may be, for example, a keyboard or a mouse. A user can use the input device 140 to input predetermined operations and give instructions. The output device 150 is, for example, a liquid crystal display monitor. The output device 150 displays to the user the evaluation results by the evaluation unit 115 as the results of the processing performed in the MS design support system 100. The output device 150 also displays a configuration diagram of the current system shown in FIG. 19 (described later) and a configuration diagram of the proposed MS placement of the migration target system shown in FIG. 20.

[0034] The input / output interface 130 accepts data input from the input device 140 and inputs the data to the processor 110. The input / output interface 130 also outputs data output from the processor 110 (for example, the output result of the program analysis unit 111, and screen data shown in FIGS. 19 and 20 described later) to the output device 150.

[0035] Next, an example of the configuration of each storage unit stored in the storage device 120 will be described. FIG. 2 is a diagram showing an example of information stored in the program information storage unit 121. As shown in FIG. The program analysis unit 111 stores the results of analyzing the current program as program information in the program information storage unit 121. The current program is a program for realizing the functions of software used in the current system.

[0036] The program information storage unit 121 includes a function information list 210, a variable information list 220, a function-function dependency relationship 230, and a function-variable dependency relationship 240. The function information list 210 is a table that stores an ID 211 for identifying a function used in a program, a function 212 that represents the function, a file name 213 of the file in which the function is recorded, a code amount 214 of the function, and a type 215.

[0037] Nothing is stored in type 215 at the time when program analysis unit 111 outputs the analysis result to output device 150. When the user inputs information regarding the analysis result of program analysis unit 111, this information is stored in type 215. For example, in type 215, for the analysis result output to output device 150, if the processing content of the function relates to control processing, "control processing", if it relates to screen processing, "screen processing", or if it relates to other processing, information such as "other" is stored.

[0038] The variable information list 220 is a table that stores an ID 221 for identifying a variable, a variable name 222, a file name 223 of the file in which the variable is defined, a variable type 224, and a data amount 225 of data stored in the variable. The variable name 222 indicates that the variable is a global variable, and the file name 223 stores the file name of the file in which the variable is stored.

[0039] The type 224 indicates one of a system definition variable, a function variable, an inter-function common variable, an inter-task connection variable, and an existing platform (PF: Platform) connection variable (hereinafter referred to as an existing PF connection variable) depending on the access condition of the variable. The type 224 may store a type edited by the user based on the analysis result of the program analysis unit 111. In the drawing, the existing platform is also abbreviated as "existing PF".

[0040] Here, each variable stored in the type 224 will be explained. System-defined variables are read-only data that are used when the control system is started and that functions can only read. A functional variable is data used within a functional unit of the current system. Because a functional variable is data used by each functional unit, it cannot be accessed by other functional units. A cross-function variable is data that is read or written by multiple functional units in the current system. Therefore, a cross-function variable can be accessed by multiple different functional units. An inter-task connection variable is data that is shared between tasks that occur within a functional unit in the current system.

[0041] The existing PF connection variables are data shared between functional units that are to be MS-ized and functional units that are not to be MS-ized. When migrating the current system to the target system, it is common that not all functions of the existing control system are MS-ized, but rather some functions are MS-ized in stages. For this reason, a database or data set for data exchange between MS-ized functions and non-MS-ized functions is used as the existing PF.

[0042] Data such as variables exchanged between functional units in the current system are stored in a database or dataset in file format. The database or dataset may be replaced with a global variable that can be referenced and rewritten by multiple programs.

[0043] Function-function dependency 230 is a table that stores an ID 231 for identifying the dependency between two functions, a caller function 232, and a callee function 233. For example, Function_A, which is a caller function, calls Function_B, which is a callee function, to cause Function_B to execute processing and obtain a return value from Function_B.

[0044] The function-variable dependency relationship 240 is a table that stores an ID 241, a caller function 242, a variable name 243, and an R / W 244. The R / W 244 indicates an operation (Read / Write) on the variable by the caller function. A variable with "R" stored in R / W 244 can only be read by the calling function. A variable with "WR" or "W" stored in R / W 244 can be called and rewritten by the calling function. Here, it is shown that the calling function, Function_A, can read the global variable with the variable name GLB_A, and can read and rewrite the global variable with the variable name GLB_B.

[0045] FIG. 3 is a diagram illustrating an example of information stored in the resource information storage unit 122. As shown in FIG. The resource information storage unit 122 stores the configuration of the destination system and information on resources used in the destination system. The configuration of the destination system includes the hardware and software of the MS-based control system. This resource information storage unit 122 has destination system information 310 stored by the user via the input device 140, and resource information 320 indicating resources required for the execution of each function used in the destination system.

[0046] The destination system information 310 is a table that stores an ID 311 for identifying a device configured in the destination system, a device name 312 of the device in the destination system, a storage capacity 313 of the storage that the device has, a memory capacity 314 of the memory that the device has, an upper layer device ID 315, a same layer device ID 316, and a lower layer device ID 317. Using the device identified by ID 311 as a reference, a device ID that matches the layer of another device to which this device is connected is stored in either upper layer device ID 315, same layer device ID 316, or lower layer device ID 317.

[0047] Here, the devices of the destination system are configured with multiple layers (layers of the controller, control server, and screen device shown in FIG. 20, which will be described later). Therefore, the layers of the devices that make up the destination system are identified as either a lower layer, the same layer, or an upper layer when viewed from the devices of the current system. When a device of the current system is migrated to a device of the same layer in the destination system, the device ID of the device of the destination system is stored in the same layer device ID 316, and the upper layer device ID 315 and lower layer device ID 317 are left blank.

[0048] When a device in the current system is migrated to a device in a higher layer, the device ID of the device in the migration destination system is stored in the higher layer device ID 315, and the same layer device ID 316 and lower layer device ID 317 are left blank. When a device in the current system is migrated to a device in a lower layer, the device ID of the device in the migration destination system is stored in the lower layer device ID 317, and the upper layer device ID 315 and the same layer device ID 316 are left blank. Therefore, even if the migration destination system is configured with two or three layers, a device ID matching the layer of the migration destination system is stored in one of the device IDs 315 to 317 of the migration destination system information 310.

[0049] The resource information 320 indicates resources required by the functions of the software used in the current system in the migration destination system. The resource information 320 is a table that stores IDs 321, functions 322, loads 323, and memory usage amounts 324.

[0050] The function 322 indicates a function name for identifying a function of the software used in the current system. The load 323 indicates the utilization rate of the processor configured in the destination system when the function is used in the destination system. The memory usage 324 indicates the maximum memory usage required by a function stored in the function 322 when the function uses memory configured in the migration destination system.

[0051] FIG. 4 is a diagram showing an example of information stored in the business requirement storage unit 123. As shown in FIG. The business requirement storage unit 123 stores business names, target APIs, performance requirements, execution paths of target businesses (e.g., function flows), etc. Business requirement information 410 is information that a user stores in the business requirement storage unit 123 via the input device 140. The business requirement information 410 is a table that stores business IDs 411, business names 412, target APIs 413, performance requirements 414, and function flows 415.

[0052] The business ID 411 is an ID for identifying business information including business requirements defined in the migration destination system. The business name 412 indicates the business name when the user starts the system by operating the system's GUI (Graphical User Interface), for example. The target API 413 is the name of the API that is the starting point for the action on the screen operated by the business. An interface that is made public so that the MS functions can be called from outside the MS is called an API. An MS can have multiple APIs.

[0053] The performance requirement 414 is the time from the start to the end of the task, that is, the time from when the user starts GUI operation until the task is completed. In this example, the performance requirement stored is that the time from when the target API function Function_A, which was started at the start of the task, ends within A milliseconds [msec].

[0054] The function flow 415 is an example of function flow information configured as a list of function IDs called from the start to the end of a task. The function flow 415 is also called the execution path of the target task. The function flow 415 may include response information of the function that receives the task end. One or more function IDs are stored in the function flow 415.

[0055] FIG. 5 is a diagram showing an example of information stored in the division requirement storage unit 124. As shown in FIG. The division requirement storage unit 124 stores an ID 511 for identifying a division requirement, destination system information 512, resources 513, and a code amount per MS 514. The migration destination system information 512 is information that references, for example, the migration destination system information 310 shown in FIG.

[0056] Resource 513 is information that refers to, for example, resource information 320 shown in Fig. 3. Code amount per MS 514 indicates the code amount calculated for each MS. An upper limit on the amount of code in an MS is determined, and if the amount of code exceeds the upper limit, the MS is divided into smaller MSs.

[0057] FIG. 6 is a diagram showing an example of information stored in the evaluation information storage unit 125. As shown in FIG. The evaluation information storage unit 125 stores inter-MS evaluation information 610 and inter-device evaluation information 620 stored by a user via the input device 140. The quality of an MS requires that communication be completed within a predetermined time. Therefore, the inter-MS evaluation information 610 and inter-device evaluation information 620 store the overhead of communication between MSs and between devices as communication time.

[0058] Inter-MS evaluation information 610 is static information regarding the communication time between MSs and between devices expected in the target system. In an MS-based control system, the communication time for data transmitted and received between multiple MSs configured in the same device must meet certain requirements, and the communication time is used as evaluation information. Inter-MS evaluation information 610 is a table that stores ID 611 for identifying inter-MS evaluation information, device ID 612, source MS 613, destination MS 614, and inter-MS communication time 615.

[0059] The device ID 612 indicates a device ID for identifying a device that stores a plurality of MSs that transmit and receive communication data to and from each other. The source MS 613 indicates an MSID for identifying the MS that is the source of the communication data. For example, the source MS of the communication data is assumed to be MS_A. The destination MS 614 indicates an MSID for identifying the MS to which the communication data is to be sent. For example, the destination MS of the communication data is assumed to be MS_B. The inter-MS communication time 615 indicates the communication time of communication data from the source MS to the destination MS. This communication time represents the overhead in communication between MSs. For example, the communication time between MSs is assumed to be MS_AB milliseconds [msec].

[0060] The inter-device evaluation information 620 is a table that stores an ID 621 for identifying inter-device evaluation information, a source device ID 622, a destination device ID 623, and an inter-device communication time 624. The source device ID 622 indicates the ID of the device that is the source of the communication data. For example, the source device of the communication data is assumed to be Device_A.

[0061] The destination device ID 623 indicates the ID of the device to which the communication data is to be sent. For example, the destination device of the communication data is assumed to be Device_B. The inter-device communication time 624 indicates the communication time of communication data from the source device to the destination device. This communication time represents the overhead in communication between devices. For example, the communication time between devices is assumed to be Device_AB milliseconds [msec].

[0062] FIG. 7 is a diagram showing an example of information stored in the distribution plan storage unit 126. As shown in FIG. The division plan storage unit 126 stores information on the minimum unit initial division plan and MS dependency relationships. The division plan storage unit 126 has an MS division plan 710 output by the MS division plan creation unit 112 and an MS dependency relationship 720 output by the MS dependency relationship creation unit 113.

[0063] The MS division plan 710 is composed of MSIDs 711 arranged in the row direction and function IDs and variable IDs 712 arranged in the column direction. The MS division plan 710 is a table in which check marks indicating the affiliation of functions and variables are entered in the corresponding function ID and variable ID fields to represent the functions and variables belonging to the MS. In other words, the divided MS has functions or variables with check marks entered.

[0064] For example, the function Function_A belongs to the microservice MS_A. The microservice MS_A has a screen processing function using the function Function_A. The function Function_B and the global variable GLB_A belong to the microservice MS_B. The microservice MS_B has a control processing function using the function Function_B and the global variable GLB_A.

[0065] The MS dependency 720 is a table having a business ID 721 and an MS flow 722 . The business ID 721 stores the same value as the business ID 411 included in the business requirement information 410. The MS flow 722 is information in which the function ID described in the function flow 415 included in the business requirement information 410 is replaced with an MSID for identifying the MS. Because the function ID of the function flow 415 is a list, the MSID in which multiple function IDs are replaced with MSs is stored in the MS flow 722.

[0066] The microservices MS_A and MS_B are stored in the MS flow 722 indicated by the business ID 721 of the MS dependency relationship 720. Therefore, the MS dependency relationship 720 indicates that the business that has been converted into an MS has a screen processing function and a control processing function.

[0067] FIG. 8 is a diagram showing an example of information stored in the placement plan storage unit 127. As shown in FIG. The placement plan storage unit 127 stores an MS placement plan. The placement plan storage unit 127 stores an MS placement plan 810 output by the MS placement plan creation unit 114.

[0068] The MS placement plan 810 is a table configured with device IDs 811 indicating devices in the destination system in the row direction and MSIDs 812 indicating MSs belonging to the devices in the destination system in the column direction. A different MS is placed in each device indicated by the device ID 811. Examples of devices on which an MS is placed include a cloud server, an on-premise server, etc.

[0069] A check mark indicating the affiliation of the MS is entered in a field corresponding to the MS to be placed in a device of the destination system. If a check mark is entered, the MS has a function or a variable. The device of the destination system has an MS with a check mark entered. For example, the MS placement plan 810 indicates that microservice MS_A is placed in device Device_A, and microservice MS_B is placed in device Device_B.

[0070] FIG. 9 is a diagram showing an example of information stored in the evaluation result storage unit 128. As shown in FIG. The evaluation result storage unit 128 stores evaluation results 910 of the MS placement plan 810 by the evaluation unit 115. The evaluation results 910 are a table configured with evaluation results 911 indicating evaluation results in the row direction and placement plan IDs 912 of the MS placement plans to be evaluated in the column direction.

[0071] The MS placement plan evaluated by the evaluation unit 115 is, for example, the MS placement plan shown in FIG. 20, which will be described later. The evaluation result may be a binary evaluation result of OK or NG, or the results of an ABC evaluation or a score evaluation may be stored. The evaluation result storage unit 128 stores placement plans and evaluation results that have been created in the past. Therefore, the user can check how the MSs were placed on resources and how they were evaluated by looking at the past placement plans that the result output unit 116 reads from the evaluation result storage unit 128 and outputs to the output device 150.

[0072] Next, examples of processing by each unit in processor 110 shown in FIG. 1 will be described with reference to FIGS. 10 is a flowchart showing an example of a program analysis process. This process is performed by the program analysis unit 111.

[0073] First, the program analysis unit 111 inputs a program to be analyzed (S101). The program is input through the input device 140 operated by the user. Alternatively, the program may be input from a storage device or a cloud connected to the MS design support system 100.

[0074] Next, the program analysis unit 111 analyzes the program (S102). The program analysis unit 111 acquires each piece of information shown in FIG. 2 as program information through the program analysis.

[0075] Then, the program analysis unit 111 stores the program information in the program information storage unit 121 (S103). Each piece of information stored in the program information storage unit 121 is read out and used in subsequent processing.

[0076] 11 is a flowchart showing an example of the MS division plan creation process. This process is performed by the MS division plan creation unit 112. In the MS division plan creation process, the MS division plan creation unit 112 adds to the MS a process corresponding to the type of variable used in the program indicated in the program analysis information. Then, the MS division plan creation unit 112 assigns to the MS a system-defined variable that can be read by a program function, and updates the MS division plan 710.

[0077] First, the MS distribution plan creation unit 112 acquires the variable information list 220, the function-function dependency relationships 230, and the function-variable dependency relationships 240 from the program information storage unit 121 (S201).

[0078] Next, the MS division plan creation unit 112 acquires the type of variable stored in the type 224 from the acquired variable information list 220 (S202). Then, the MS division plan creation unit 112 selects one of the subsequent first processing (S210) to third processing (S230) according to the acquired type of variable, and executes the processing.

[0079] 12 is a flowchart showing an example of the first process, in which an MS for inter-function common variables that can be accessed by each function of the MS is created. If the type of the variable acquired in step S202 is an inter-function common variable, the MS division plan creation unit 112 creates an independent MS for inter-function common variables. Then, the MS division plan creation unit 112 enables the MS for inter-function common variables to return values ​​in response to requests from inter-function common variables used in other MSs. Therefore, the MS division plan creation unit 112 proceeds to the first process (S210).

[0080] In the first process, when the type of a variable is an inter-function common variable that can be read or written by multiple functional units of the current system, the MS division plan creation unit 112 creates an MS that manages the inter-function common variable and assigns the inter-function common variable to the MS. For example, the MS division plan creation unit 112 first creates one MS for the inter-function common variable (S211). Next, the MS division plan creating unit 112 assigns all inter-function common variables to the inter-function common variable MS created in step S211 (S212).

[0081] Next, the MS division plan creating unit 112 adds the data access management process to the MS for inter-function common variables created in step S211 (S213), and returns to step S240 in FIG. The data access management process added to the MS for common variables is a process that uses APIs to allow various MSs in the destination system to access common variables. This process enables the MS for common variables to perform data access management.

[0082] 13 is a flowchart showing an example of the second process. In the second process, an existing PF connecting MS that allows data access between the outside and the inside of the MS is created. If the type of the acquired variable is an existing PF connection variable, the MS division plan creation unit 112 proceeds to a second process (S220) to enable access from outside the MS to inside the MS, or from inside the MS to outside the MS.

[0083] In the second process, when the type of variable is an existing PF connection variable that allows data to be shared between a functional unit that is a target of MS conversion and a functional unit that is not a target of MS conversion, the MS division plan creation unit 112 creates an MS that manages the existing PF connection variable. Then, the MS division plan creation unit 112 assigns an interface that allows the functional unit that is not a target of MS conversion to access the functional unit that is a target of MS conversion to the MS for existing PF connection. For example, the MS division plan creation unit 112 first creates one existing PF connection MS for managing existing PF connection variables (S221). Here, an existing PF connection MS is created for access by an MS in the migration destination system and a functional unit that is not targeted for MS conversion.

[0084] Next, the MS division plan creation unit 112 assigns an interface that allows access from outside the MS to the inside of the MS to the MS connected to an existing PF (S222). At this time, the existing PF connection variables are assigned to the MS connected to an existing PF created in step S221.

[0085] Next, the MS division plan creation unit 112 adds a data access management process to the MS for connecting to an existing PF created in step S221 (S223), and returns to step S240 in Figure 11. The data access management process added to the MS for connecting to an existing PF is a process that uses an API to enable an external MS to access variables for connecting to an existing PF. This process enables the external MS to access the inside of the MS.

[0086] 14 is a flowchart showing an example of the third process. In the third process, a minimized MS that combines a plurality of functions is created. That is, if the type of the acquired variable is a functional variable, the MS division plan creation unit 112 designs a call graph of the MS starting from the API. Furthermore, the MS division plan creation unit 112 designs the call graph layer by layer so that the MSs of the destination system can be placed within the upper resource limit, starting from the upper device configured in the destination system. The upper resource limit is set, for example, for the amount of code of the program and the amount of memory in the scale. Therefore, the MS division plan creation unit 112 proceeds to the third process (S230).

[0087] In the third process, when the type of variable is a functional variable used within a functional unit of the current system, the MS division plan creation unit 112 first creates a call graph of the MS starting from the API. For example, the MS division plan creation unit 112 creates a call graph using the function-function dependency relationships 230 and the function-variable dependency relationships 240 (S231). Leaf functions of the call graph are extracted (S232). The call graph is created by internal processing of the MS division plan creation unit 112 and is not shown to the user.

[0088] Here, an example of the configuration of a call graph will be described. 15 is a diagram showing an example of a configuration of a simple current system, a call graph, and an MS division plan. The current system configuration diagram (1) in Figure 15 shows that Function 1 accesses DB1 to retrieve data. The configuration diagram (1) also shows that Function 1 calls Function 2, and Function 2 calls Function 3.

[0089] Function 3 accesses DB2, retrieves data, performs a specified process, writes the data to DB2, and passes the processing results to Function 2. Function 2 performs a specified process based on the result received from Function 3, and passes the result to Function 1. Function 1 performs a specified process based on the data retrieved from DB1 and the result received from Function 2, and writes the data to DB1.

[0090] In conventional microservice design, the problem was how to separate functions and data to convert them into MS. For example, converting each function into an MS would result in many small MSs, making it difficult to handle them in a large-scale destination system. Therefore, in this embodiment, we reconsidered the smallest unit of MS so that the function responsible for the data would be placed at a higher level.

[0091] The call graph configuration diagram (2) in Figure 15 shows an example of a call graph in which the functions and DBs shown in the current system configuration diagram (1) have been MSized. MS1 is the MSization of function 1 and DB1. MS2 is the MSization of function 2 and DB2. Function 3, which is called by function 2, is configured to be included in function 2. In addition, MS1 has an API that allows external programs to call the functions of MS1.

[0092] The configuration diagram (3) of the MS division plan 710 in Figure 15 is created based on the call graph. Here, a check mark indicates that MS1 includes function 1, and a check mark indicates that MS2 includes function 2 and function 3. By using the call graph in this way, the functions and DBs that have been converted into MSs become clear.

[0093] Returning to the explanation of FIG. After step S232, the MS division plan creation unit 112 traces the call graph back from the leaf function in the call graph. Then, the MS division plan creation unit 112 traces the call graph back until it finds a function that writes a value to the variable, and assigns the variable to which the value has been written to one MS. For example, the MS division plan creation unit 112 traces the call graph back to the leaf function extracted in step S232, searching for a function that writes a value to the variable. When the MS division plan creation unit 112 finds a function that writes a value to the variable, the MS division plan creation unit 112 assigns the function traced back up to that point and the variable to which the value has been written as one MS (S233).

[0094] The MS distribution plan creation unit 112 repeats the process of searching for functions that have written values ​​to variables, and assigning the variables with values ​​written to MSs, excluding the functions assigned to MSs in step S233. The MS distribution plan creation unit 112 assigns all functions to one of the MSs through this repeated process, and then returns to step S240 in FIG.

[0095] Returning to the explanation of FIG. After performing any one of the first process (S210) to the third process (S230), the MS distribution plan creation unit 112 copies and assigns the system-defined variables to each MS for the result of any one of steps S213, S223, and S233 (S240). For example, the MS distribution plan creation unit 112 assigns the corresponding system-defined variable to the MS to which the function accessing the system-defined variable belongs. The MS to which the system-defined variable is assigned is used when the migration destination system is started up.

[0096] Finally, the MS division plan creation unit 112 checks the types of functions included in the MS and updates the MS division plan 710 (S241). If the MS includes a screen processing function, the MS division plan creation unit 112 sets the screen information as the MS type. If the MS includes a control processing function, the MS division plan creation unit 112 sets the control processing as the MS type. If the MS does not include any function type, the MS division plan creation unit 112 sets the other as the MS type.

[0097] 16 is a flowchart showing an example of the MS dependency creating process, which is performed by the MS dependency creating unit 113. 16, the MS dependency creation unit 113 acquires business requirement information 410 that defines the business requirements of the migration destination system, and an MS division plan 710. Then, based on the function flow information that is included in the business requirement information 410 and that corresponds to the API that is the starting point of the action on the screen operated by the business, the MS dependency creation unit 113 performs processing to replace the function information included in the function flow information with the MS information included in the MS flow that indicates the configuration of multiple MSs.

[0098] First, the MS dependency relationship creation unit 113 acquires the business requirement information 410 from the business requirement storage unit 123 (S301). Next, the MS dependency relationship creation unit 113 acquires the MS division plan 710 from the division plan storage unit 126 (S302).

[0099] Next, the MS dependency relationship creation unit 113 acquires flow information of the functions included in each target API 413 from the function flow 415 of the business requirement information 410 acquired in step S301 (S303). At this time, the MS dependency relationship creation unit 113 acquires a function list as flow information of the functions for each business ID 411. The function list includes flow information of the functions.

[0100] Next, based on the flow information of the function acquired in step S303, the MS dependency relationship creation unit 113 repeats the process of extracting the MSID of the MS to which the function belongs from the MS division plan 710. Then, the MS dependency relationship creation unit 113 replaces the function included in the flow information of the function flow 415 with the MSID of the MS flow 722 (S304). Then, the MS dependency creating unit 113 registers the information of the business ID 721 and the MS flow 722 in the MS dependency 720 (S305).

[0101] 17 is a flowchart showing an example of the MS placement plan creation process. This process is performed by the MS placement plan creation unit 114. First, the MS deployment plan creator 114 acquires the inter-MS evaluation information 610, the migration destination system information 310, the MS division plan 710, and the MS dependency relationship 720 (S401).

[0102] Next, the MS placement plan creating unit 114 creates a system configuration between devices used in the destination system based on the destination system information 310 (S402). Then, the MS placement plan creating unit 114 performs a tentative placement of MSs in devices of the migration destination system for each service ID (S403).

[0103] Based on the MS flow 722 described in the MS dependency relationship 720 and the MS division plan 710, the MS placement plan creation unit 114 provisionally places the MS in the device with the most available resources among the devices in the top layer (for example, the layer of screen-related devices in FIG. 20) whose type 215 shown in FIG. 2 is screen processing. Furthermore, the MS placement plan creator 114 tentatively places the MS in the device with the most spare resources among the devices in the lowest layer whose type 215 is control processing (for example, the controller layer in FIG. 20).

[0104] If the destination system is configured with three layers, the MS placement plan creation unit 114 provisionally places devices whose type 215 is "other" in the middle layer (for example, the control server layer in FIG. 20). If the destination system is configured with two layers, the MS placement plan creation unit 114 provisionally places devices whose type 215 is "other" in devices in the upper layer. Furthermore, with regard to placement within the same layer, it is not necessary to use all devices as long as they are within the range of the storage capacity and memory capacity of the destination device.

[0105] Next, the evaluation unit 115 performs an MS evaluation process for evaluating the performance of the MS using the temporary placement information (S404). Here, the MS evaluation process performed by the evaluation unit 115 will be described with reference to FIG.

[0106] 18 is a flowchart showing an example of the MS evaluation process. This process is performed by the evaluation unit 115.

[0107] First, the evaluation unit 115 determines whether the resources allocated to the MSs have been leveled based on the result of the temporary allocation of the MSs (S501). If the resources allocated to the MSs have been leveled (YES in S501), the process proceeds to step S502.

[0108] Next, the evaluation unit 115 calculates the inter-MS communication time based on the result of the tentative MS allocation and the information on the source MS 613 and the destination MS 614 in the inter-MS evaluation information 610 (S502). The inter-MS communication time is written to the inter-MS communication time 615 in the inter-MS evaluation information 610 in FIG. 6.

[0109] Next, the evaluation unit 115 checks the performance requirement 414 in the business requirement information 410 shown in Fig. 4 (S503). If the inter-MS communication time satisfies the performance requirement 414 in step S503 (OK in S503), the evaluation unit 115 assigns a label indicating that the performance requirement is OK to the result of the tentative placement (S504), and the process returns to the MS placement plan creation process in Fig. 17.

[0110] In step S503, if the communication time does not satisfy the performance requirement 414 (NG in S503), or if the resources are not leveled in step S501 (NO in S501), the evaluation unit 115 assigns a label indicating that the performance requirement is NG to the result of the provisional placement (S505), and the process returns to the MS placement plan creation process of FIG. 17.

[0111] Returning to the explanation of FIG. After step S404, the MS placement plan creation unit 114 refers to the label attached to the result of tentative placement and determines whether the performance requirements are OK (positive) (S405). In step S405, if the label attached to the result of tentative placement does not meet the performance requirements (NO in S405), the performance requirements are NG. In this way, if the evaluation result is negative, the MS placement plan creation unit 114 recreates an MS placement plan, and the evaluation unit 115 evaluates the recreated MS placement plan again. Therefore, the MS placement plan creation unit 114 provisionally places the MSs again (S406).

[0112] For example, the MS placement plan creation unit 114 performs a tentative placement by selecting and combining only one pair of dependent MSs based on the dependency relationships of other MSs present in the same device. After this tentative placement reduces the communication time between the MSs, the MS placement plan creation unit 114 performs the MS evaluation process again in step S404. The MS placement plan creation unit 114 repeats the processes from step S404 onwards until the requirements are met.

[0113] In step S405, if the label attached to the result of the tentative placement meets the performance requirements (YES in S405), the MS placement plan creation unit 114 allocates other MSs that do not belong to the business that is the evaluation target of the performance requirements 414 to resources (S407). At this time, the MS placement plan creation unit 114 allocates other MSs to resources so that the resources used are leveled among the devices to which MSs have already been allocated.

[0114] Next, the MS placement plan creation unit 114 determines whether the usage of the other MSs allocated in S407 exceeds the resources (S408). If the usage of the other MSs allocated in step S408 does not exceed the resources (NO in S408), the MS placement plan creation unit 114 ends this process.

[0115] On the other hand, if the usage of the other allocated MSs exceeds the resources in step S408 (YES in S408), the MS placement plan generator 114 determines whether there are any resources to which no MSs are allocated (S409).

[0116] In step S409, if there are resources to which no MS has been allocated (YES in S409), the MS placement plan creating unit 114 allocates other MSs to the resources to which no MS has been allocated (S410), and ends this process.

[0117] On the other hand, if there are no resources to which MSs have not been allocated in step S409 (NO in S409), the MS placement plan creation unit 114 issues an alert to the user (S411) and ends this process. The alert may, for example, notify the user of a resource shortage or that resources to which MSs are allocated are not leveled. If there is a device to which no MS has been allocated, information about that device may be notified to the user as an alert.

[0118] Next, we will explain an example of the current system configuration and the MS placement plan for the migration target system. 19 is a diagram showing the configuration of the current system. The current system is composed of three layers: a controller, a control server, and a screen device. The configuration example of the current system shown in FIG. 19 is displayed on the output device 150.

[0119] The layer of the screen-related device includes one screen-related device_a. The UI-related functions of the screen-related device_a can execute processes A to F.

[0120] The control server layer has three control servers _b1 to _b3 connected to the screen system device _a via a bus. Control function 1 of control server _b1 can execute processes 1 to 3 and D to F. Control function 2 of control server _b2 can execute processes 2, 3, 5, A, E, and F. Control function 3 of control server _b3 can execute processes 4 to 6 and E to G.

[0121] The controller layer includes three controllers _c1 to _c3 connected to control servers _b1 to _b3 via buses, respectively. Each of the controllers _c1 to _c3 is capable of executing control input / output (I / O) processing.

[0122] 19, the screen device _a and the control servers _b1 to _b3 are all capable of executing the same processes E and F. In addition, the control servers _b1 and _b2 are all capable of executing the same processes 2 and 3.

[0123] Fig. 20 is a diagram showing an example of the configuration of a destination system. The destination system also consists of three layers: a controller, a control server, and a screen system device. The example of the configuration of the destination system shown in Fig. 20 is displayed on the output device 150. In addition, "OK" is displayed on the output device 150, indicating that the evaluation result of the destination system is positive.

[0124] One screen-related device _A is provided in the layer of the screen-related device. MS1 of the screen-related device _A can execute processes B to D. The empty space to the right of MS1 indicates that the screen-related device _A has spare resources. For example, it is possible to add and place three more processes in MS1.

[0125] The control server layer has two control servers _B1 and _B2 connected to screen system device _A via a bus. Control server _B1 has MS2 and MS3. MS2 includes processes 1 to 3, and MS3 includes processes E and F. Control server _B2 has MS4, MS5, and MS6. MS4 includes processes 2, 3, and process A, MS5 includes process 5, and MS6 includes process D.

[0126] The controller layer includes two controllers C1 and C2 connected to control servers B1 and B2 via buses, respectively. Both controllers C1 and C2 are capable of executing control input / output (I / O) processing.

[0127] In the current system, processes E and F, which were distributed across various devices, are consolidated into MS3 in the migration target system. MS3 was created as an MS for inter-function common variables as explained in Fig. 12, and when an MS other than MS3 executes processes E and F, it accesses MS3 to obtain the execution results of processes E and F.

[0128] Simply combining common processes included in multiple devices may result in large communication overhead, which may cause delays in overall processing. Therefore, it is possible to configure MSs so that the same processes remain in multiple devices. For example, in the current configuration shown in Figure 19, processes 2 and 3 are shared by control servers b1 and b2, but in the target system, processes D, E, and F are placed in an MS other than MS2.

[0129] Therefore, if the communication overhead between processes 2 and 3 and processes D, E, and F becomes large, it will have an impact on the processing of the entire destination system, such as delays. For this reason, processes 2 and 3 are distributed to MS2 and MS4. This makes it possible to distribute access concentrated on the MS that owns processes 2 and 3.

[0130] In the MS design support system 100 according to the embodiment described above, when an existing control system is migrated to a migration destination system and converted to MS, functions to be MS-targeted are automatically selected, and an MS placement plan is created in which the MSs are automatically assigned to devices so that the tasks run by the MSs satisfy the performance requirements. By checking the MS placement plan, a user can learn at an early stage how the MSs will be placed on the resources of the migration destination system. Furthermore, an experienced user can determine the suitability of the MS placement plan simply by looking at it, since they can identify areas where communication bottlenecks and areas where resources are not being used effectively are identified.

[0131] Furthermore, an evaluation process is performed on the MS placement plan in the MS design support system 100. If the evaluation process reveals that an MS does not satisfy the performance requirement for communication time, for example, the MS design support system 100 automatically rearranges the MS and can also perform an evaluation process on the rearranged MS placement plan. The MS design support system 100 can automatically relocate MSs and repeat the evaluation process of the relocated MS placement plan until the MS placement plan satisfies the performance requirements. In this way, because the MS placement and evaluation process are performed automatically, the user can significantly reduce the time and effort required to design the MS in the migration destination system.

[0132] Furthermore, the MS division plan creation unit 112 focuses on the function that writes to the variable, and combines this function and the variable into which the value is written into a single MS. The MS divided by the MS division plan creation unit 112 can clearly identify the function that writes a value to the variable, compared to conventional MSs that are divided based on differences in data input timing.

[0133] Note that, when it is determined that the MS placement plan does not satisfy the performance requirements, information indicating that the MS placement plan does not satisfy the performance requirements may be displayed from the output device 150. The user can confirm what kind of MS placement plan does not satisfy the performance requirements from the content displayed on the output device 150. Thereafter, the user may instruct the MS design support system 100 to rearrange the MSs, and may also instruct it to perform an evaluation process for the rearranged MS placement plan.

[0134] Furthermore, by dividing the current system into microservices in the target system, it is possible to stop only specific microservices during maintenance, without having to stop the entire target system, which improves the maintainability of the target system.

[0135] The present invention is not limited to the above-described embodiment, and it goes without saying that various other applications and modifications are possible without departing from the gist of the present invention as set forth in the claims. For example, the above-described embodiment has described in detail and specifically the configuration of the MS design support system in order to clearly explain the present invention, and is not necessarily limited to a system including all of the described configurations. Furthermore, it is also possible to add, delete, or replace part of the configuration of this embodiment with other configurations. In addition, the control lines and information lines shown are those that are considered necessary for the explanation, and do not necessarily show all the control lines and information lines in the product. In reality, it can be assumed that almost all components are interconnected. [Explanation of symbols]

[0136] 100... MS design support system, 110... processor, 111... program analysis unit, 112... MS division plan creation unit, 113... MS dependency creation unit, 114... MS placement plan creation unit, 115... evaluation unit, 116... result output unit, 120... storage device, 121... program information storage unit, 122... resource information storage unit, 123... business requirement storage unit, 124... partition requirement storage unit, 125... evaluation information storage unit, 126... division plan storage unit, 127... placement plan storage unit, 128... evaluation result storage unit, 130... input / output interface, 140... input device, 150... output device

Claims

1. a microservice division plan creation unit that creates a microservice division plan in which functions provided by the control system are divided into multiple microservices using analysis information of a program used in the current control system, configuration information including a resource configuration of a migration destination system to which functions of the control system are migrated, and business information including business requirements specified in the migration destination system; and a microservice dependency creation unit that creates dependencies between the plurality of microservices based on the microservice division plan; a microservice deployment plan creation unit that creates a microservice deployment plan in which the plurality of microservices are deployed on the resources based on the configuration information and the dependency relationships. Microservice design support system.

2. The microservice division plan creation unit adds, to the microservice, processing according to the type of variable used in the program indicated in the analysis information of the program, and assigns, to the microservice, system-defined variables that are used when the control system is started and that can be read by functions of the program, thereby updating the microservice division plan. The microservice design support system according to claim 1 .

3. When the type of the variable is a functional variable used in a functional unit of the control system, the microservice division plan creation unit creates a call graph of the microservice starting from an API, traces the call graph from a terminal function of the call graph back, and assigns the other functions traced back in the call graph until the function that writes a value to the variable and the variable into which the value has been written to one of the microservices. The microservice design support system according to claim 2.

4. When the type of the variable is an inter-function common variable that can be read or written by a plurality of functional units of the control system, the microservice division plan creation unit creates the microservice that manages the inter-function common variable and assigns the inter-function common variable to the microservice. The microservice design support system according to claim 3 .

5. When the type of the variable is an existing platform connection variable that allows data to be shared between a function unit that is a target for microservices and a function unit that is not a target for microservices, the microservice division plan creation unit creates the microservice that manages the existing platform connection variable, and assigns an interface that allows the function unit that is not a target for microservices to access the function unit that is a target for microservices to the microservice for existing platform connection. The microservice design support system according to claim 4.

6. The microservice dependency creation unit acquires business requirement information that defines the business requirements of the destination system and the microservice division plan, and, based on function flow information that is included in the business requirement information and that corresponds to the API that is the starting point of an action on a screen operated by the business, replaces information about the function included in the function flow information with information about the microservice included in a microservice flow that indicates the configuration of multiple microservices. The microservice design support system according to claim 5.

7. An evaluation unit that evaluates whether the microservice deployment plan satisfies the business requirements; an output unit that outputs the evaluation result by the evaluation unit; The microservice design support system according to claim 6.

8. The microservice deployment plan creation unit recreates the microservice deployment plan when the evaluation result is negative; The evaluation unit evaluates the recreated microservice deployment plan again. The microservice design support system according to claim 7.

9. If the evaluation result is positive, the microservice placement plan creation unit sets the microservice that does not include a screen processing or control processing type as an other microservice, and if the usage amount of the other microservice allocated to a resource exceeds the resource, allocates the other microservice to another resource to which the microservice is not allocated, and if there is no other resource, issues an alert. The microservice design support system according to claim 8.

10. A step of creating a microservice division plan in which functions provided by the control system are divided into multiple microservices using analysis information of a program used in the current control system, configuration information including a resource configuration of a destination system to which functions of the control system will be migrated, and business information including business requirements specified in the destination system; Creating dependencies between the microservices based on the microservice division plan; and creating a microservice deployment plan in which the plurality of microservices are deployed on the resources based on the configuration information and the dependencies. Microservice design support method.

Images