Control system and microservices processing method

Abstract

To provide a control system which removes a critical micro service (MS) from a target system, because failure generated in the critical MS affects other MSs when the critical MS exists in the control system configured by a plurality of MSs.SOLUTION: A control system 200 comprises: a failure impact degree calculation program 231 which calculates a failure impact degree for each micro service configuring a target system; and an MS division / integration program 232 which sets the micro service in which the failure impact degree is greater than a reference value as a critical micro service, and performs division integration processing which divides the critical micro service, or integrates the plurality of micro services until all of the critical micro services are exhausted, in accordance with a preset system requirement.SELECTED DRAWING: Figure 2

Description

[[Technical Field]]

[0001] The present invention relates to a control system and a microservice processing method. [[Background Art]]

[0002] Conventionally, control systems for controlling the operation of controlled objects have been required to be safe and have had a very large-scale configuration. Such a conventional control system is called a monolith. A monolith is configured by linking a large number of programs and databases to prevent inconsistencies in processing. However, when a failure occurs in a part of a control system configured as a monolith, it is difficult to isolate only the failed part from the control system. For this reason, after stopping the entire control system, repairing the failed location and checking the operation, the operation of the control system was resumed. Following such a procedure, it takes a long time to resume the control system.

[0003] Therefore, control systems that require stability adopt a dual configuration of primary and secondary. When a failure occurs in the primary control system, the operation is switched entirely to the secondary control system. However, the switching time required to switch from the primary control system to the secondary control system has been long. In addition, when updating a conventional control system, it is often necessary to stop the operation of the control system, so the update can only be performed during a time period that does not interfere with business operations.

[0004] In recent years, instead of the monolithic configuration, control systems configured by dividing functions into service units provided by the control system and connecting a plurality of MSs (MS: Micro Service) are being studied. When a failure occurs in a control system configured by MS, it is only necessary to switch the failed MS to another MS, so it has been thought that the switching time can be shortened and the impact of the system failure can be suppressed. It has also been thought that modernization can be achieved by individually updating only the MS that require updating.

[0005] Patent Document 1 states that "the service execution order definition information stored in the service configuration information management unit is searched, and it is determined whether the service execution order of the service indicated in the previous log and the service indicated in the input log matches the service execution order in the service execution order definition information stored in the service configuration information management unit, thereby detecting the occurrence of a service failure." [Prior art documents] [Patent Documents]

[0006] [Patent Document 1] Japanese Patent Publication No. 2013-3681 [Overview of the Initiative] [Problems that the invention aims to solve]

[0007] By configuring control systems using MS (Management Systems), it is possible to replace the functions of existing control systems (OT (Operational Technology) assets). Furthermore, by building general-purpose functions with MS, it is believed that control systems can be provided not only in Japan but also globally. For this reason, the development of support tools for configuring control systems with MS has been underway. In addition, in order to build control systems where real-time performance is important, the construction of control systems using multiple MS has been considered. Real-time performance is an indicator that represents the performance of the response to instructions input to the control system.

[0008] However, it was found that in control systems composed of multiple microservices (MSs), a failure in one MS easily propagates to several other MSs. MSs whose failure impact exceeds a certain threshold are called "critical microservices" (hereinafter abbreviated as "critical MS"). When a critical MS fails, it can significantly impact other MSs, expanding the scope of the failure. For example, other MSs sending messages to a critical MS may experience buffer overflows because the critical MS cannot receive the messages. Furthermore, MSs that receive messages from a critical MS may become idle because they cannot receive response messages.

[0009] Therefore, it has become clear that a microservices-based control system needs to be free of critical MSs, but conventionally, critical MSs have not been considered. Furthermore, the technology disclosed in Patent Document 1 merely detects the occurrence of a service failure, and therefore could not eliminate the impact on other MSs if the failed MS was a critical MS.

[0010] This invention was made in view of these circumstances and aims to remove critical MS from a microservices-based target system. [Means for solving the problem]

[0011] The control system according to the present invention comprises a calculation unit that calculates the failure impact for each microservice based on an index obtained from an index obtained from the switching time required to switch a failed microservice to another microservice among the microservices constituting the target system, an index obtained from the importance of the services provided by the microservice, and an index obtained from the average, multiplicative, maximum, or minimum value of communication index related to communication of the microservice; and a partitioning and integrating unit that designates a microservice whose failure impact is greater than a standard value as a critical microservice and performs partitioning and integrating processing to partition the critical microservice or to integrate multiple microservices until there are no critical microservices left, according to pre-set system requirements. Furthermore, the control system according to the present invention includes a calculation unit that calculates the failure impact for each microservice based on an index obtained from an index obtained from the switching time required to switch a failed microservice to another microservice among the microservices constituting the target system, an index obtained from the importance of the services provided by the microservice, and an index obtained from an average value, multiplicative value, maximum value, or minimum value obtained from communication index related to communication of the microservice; a partitioning and integration unit that designates microservices with a failure impact greater than a standard value as critical microservices and performs partitioning and integration processing to partition critical microservices or integrate multiple microservices in accordance with pre-set system requirements to eliminate them as much as possible; and a control unit that controls the operation of the microservices. The control unit designates any remaining critical microservices that the partitioning and integration unit could not partition as critical microservices that operate in the active system and the standby system. When the control unit detects that a failure has occurred in a critical microservice in the active system, it switches the critical microservice from the active system to the standby system to continue the service. When it detects that a failure has occurred in a microservice that is not operating in either the active system or the standby system, it starts a new microservice to supplement the function of the microservice. [Effects of the Invention]

[0012] According to the present invention, it is possible to remove critical microservices from a microservice-based target system by performing a split-and-integrate process that splits critical microservices or integrates multiple microservices until there are no critical microservices left. Other issues, configurations, and effects not mentioned above will be clarified by the following description of the embodiments. [Brief explanation of the drawing]

[0013] [Figure 1] This is a block diagram showing an example of the overall configuration of the target system and control system according to one embodiment of the present invention. [Figure 2] This block diagram shows a target system with a microservice configuration according to one embodiment of the present invention, and a detailed internal configuration example of the control system. [Figure 3] This is a schematic diagram showing the process flow for optimizing microservices after a large program according to one embodiment of the present invention has been converted into microservices. [Figure 4] This flowchart shows an example of MS division / integration processing related to one embodiment of the present invention. [Figure 5] It is a diagram showing a configuration example of system requirements according to an embodiment of the present invention. [Figure 6] It is a diagram showing the content of availability according to an embodiment of the present invention. [Figure 7] It is a diagram showing an example of a conversion table for switching time to degree according to an embodiment of the present invention. [Figure 8] It is a diagram showing an example of a conversion table for importance to degree according to an embodiment of the present invention. [Figure 9] It is a diagram showing an example of a conversion table for communication to degree according to an embodiment of the present invention. [Figure 10] It is an example of a conversion table showing the relationship between failure impact degree and the detection determination method for critical MS according to an embodiment of the present invention. [Figure 11] It is a flowchart showing an example of processing for eliminating critical MS according to an embodiment of the present invention. [Figure 12] It is a diagram showing an example of factors of critical MS in cases 1 to 3 according to an embodiment of the present invention. [Figure 13] It is a diagram showing an example of availability setting change in case 1 according to an embodiment of the present invention. [Figure 14] It is a diagram showing an example of service importance in case 2 according to an embodiment of the present invention. [Figure 15] It is a diagram showing an example of communication in case 3 according to an embodiment of the present invention. [Figure 16] It is a flowchart showing an example of trade-off determination processing according to an embodiment of the present invention. [Figure 17] It is a diagram showing an example of processing time and failure impact degree when the trade-off factor in case 4 is real-time performance according to an embodiment of the present invention. [Figure 18] It is a diagram showing an example of maintainability and failure impact degree when the trade-off factor in case 5 is maintainability (MS size) according to an embodiment of the present invention. [Figure 19] It is a diagram showing a display example of a screen on which a failure influence range is visualized according to an embodiment of the present invention. [Figure 20]This figure shows an example of a fault detection method using a checkpoint data transfer method according to one embodiment of the present invention. [Figure 21] This figure shows an example of a fault detection method using a dual-system transfer method according to one embodiment of the present invention. [Modes for carrying out the invention]

[0014] Hereinafter, embodiments for carrying out the present invention will be described with reference to the accompanying drawings. In this specification and drawings, components having substantially the same function or configuration are denoted by the same reference numerals, and redundant descriptions are omitted. Below, an example in which the present invention is applied to a control system that controls the configuration of multiple MSs when the target system to be controlled is composed of multiple MSs will be described.

[0015] [One embodiment] Figure 1 is a block diagram showing an example of the overall configuration of the target system 100 and control system 200 according to one embodiment of the present invention.

[0016] (Before pre-processing) The target system 100 is a conventional monolithic system and is an example of a system that will be pre-processed to be microservices by the system designer 10. The target system 100 could be a control system in various fields, such as railway control systems, operation management systems, power control systems, plant control systems, or IT platforms.

[0017] Prior to the microservices implementation, the conventional large program 111 and parameters 112 are stored in the memory management unit 110 of the target system 100. The large program 111 is composed of various programs intricately linked together. In addition, the memory management unit 110 contains parameters 112 that the large program 111 references during processing. The configuration of these parameters 112 is also large and complex.

[0018] (After pre-processing) Through pre-processing for microservices implementation, the large program 111 and its parameters 112 are converted into microservices. Each of the multiple microservices 121 (microservices MS_A to MS_F) has its own parameters 122. These microservices 121 (microservices MS_A to MS_F) are then stored in the memory management unit 120 of the target system 100.

[0019] The microservices 121 (microservices MS_A to MS_F) stored in the memory management unit 120 through preprocessing are not optimized, and there is a possibility that critical microservices exist. Therefore, the following processing is performed to split or merge the microservices 121 that become critical microservices. In addition, during the splitting or merging process of microservices 121, the parameters 122 of the microservices 121 are also appropriately split or merged. The target system 100, which consists of multiple microservices 121, will be described below.

[0020] The control system 200 performs the process of replacing the target system 100, which has a conventional monolithic configuration, with the microservice configuration according to this embodiment. For this purpose, the control system 200 has registered the microservices rules 224 set by the system designer 10. The microservices rules 224 include, for example, the rules used in the decision process of the flowchart in Figure 4, which will be described later, as well as system requirements 300, etc.

[0021] Furthermore, the control system 200 has registered an MS division / integration program 232 that divides one MS or integrates multiple MSs. The MS division / integration program 232 can divide the large program 111 into multiple microservices or integrate it into a single microservice according to the microservices rule 224.

[0022] <Example of internal configuration of the target system and control system> Figure 2 is a block diagram showing a detailed internal configuration example of the target system 100 and the control system 200, which are configured as microservices.

[0023] (Example of the target system configuration) The target system 100 comprises a memory management unit 120, an arithmetic unit 130, an input unit 140, an output unit 150, and a communication processing unit 160. In Figure 2, the memory management unit 110 is omitted from the description.

[0024] The memory management unit 120 stores and manages the multiple microservices 121 (microservices MS_A to MS_F) shown in Figure 1.

[0025] The arithmetic unit 130 is capable of executing the control program 131. The control program 131 performs calculations for the processing required by the target system 100, including reading and executing necessary microservices 121 from the memory management unit 120, and controlling the operation of the input unit 140, output unit 150, and communication processing unit 160. The arithmetic unit 130 is composed of, for example, a CPU (Central Processing Unit), ROM (Read Only Memory), and RAM (Random Access Memory). The CPU of the arithmetic unit 130 reads the program code of the software that realizes each function according to this embodiment from the ROM, loads it into the RAM, and executes it. Variables and parameters that occur during the CPU's calculation processing are temporarily written to the RAM of the arithmetic unit 130, and these variables and parameters are read out by the CPU as appropriate.

[0026] The input unit 140 can use, for example, a keyboard or mouse, allowing the user of the target system 100 to perform predetermined operations and give instructions. The output unit 150 is, for example, a liquid crystal display monitor, which displays the results of processing performed by the calculation unit 130 to the user of the target system 100. The communication processing unit 160 may use, for example, a NIC (Network Interface Card), and can send and receive various types of data to and from the control system 200 via a LAN (Local Area Network), dedicated line, etc., connected to the terminals of the NIC.

[0027] (Example of a control system configuration) The control system 200 comprises a memory management unit 220, an arithmetic unit 230, an input unit 240, an output unit 250, and a communication processing unit 260. The control system 200 may be a PC or server that the system designer 10 can operate, or it may be a cloud server built on the cloud.

[0028] The arithmetic unit 230 is capable of executing the failure impact calculation program 231, the MS division / integration program 232, and the control program 233. The arithmetic unit 230 is composed of, for example, a CPU, ROM, and RAM. The CPU of the arithmetic unit 230 reads the program code of the software that realizes each function according to this embodiment from ROM, loads it into RAM, and executes it. Variables and parameters that occur during the CPU's calculation process are temporarily written to the RAM of the arithmetic unit 230, and these variables and parameters are read out by the CPU as appropriate. Each program of the arithmetic unit 230 reads parameters 221, requirement data 222, failure impact data 223, and microservices rules 224 from the memory management unit 220 and performs microservices optimization processing according to this embodiment. This optimization processing is the process in which the arithmetic unit 230 performs microservice division and integration processing according to the system requirements 300, excluding critical MS.

[0029] The failure impact calculation program 231 (an example of the calculation unit) calculates the failure impact for each microservice that constitutes the target system 100. Failure impact is an indicator of how a failure in one microservice affects other microservices. Microservices with a failure impact greater than a baseline value are detected as critical microservices (MS). The failure impact calculation program 231 calculates the failure impact using, for example, three elements (switching time, service importance, and communication indicators). These three elements are, for example, the switching time required to switch a failed microservice to another microservice, the importance of the service provided by the microservice, and communication indicators related to the communication of the microservice. The failure impact calculation program 231 calculates the failure impact based on an indicator obtained from the switching time (switching time_degree), an indicator obtained from the service importance (service importance_degree), and an indicator obtained from the communication indicator using either the average value, multiplicative value, maximum value, or minimum value (communication_degree).

[0030] Switchover time is the time required to switch to another microservice in the event of a microservice failure. For example, switching over a microservice to a newly launched server or information processing device is called "switchover." The longer the switchover time, the greater the impact on the severity of the failure.

[0031] Service importance represents the importance of a service. For example, if a service has high service importance, a failure detected in the microservice providing that service will have a significant impact on the service. If the service importance is moderate, the service importance will vary depending on the actual processing content of the service. For example, if a service is started periodically, a service that occurs on the order of seconds will have higher service importance than a service that occurs on the order of minutes. In the target system 100, there are processes that do not occur periodically, i.e., processes that occur irregularly, and these processes are called events. A service that is started when an event occurs will have lower service importance than a service that occurs on the order of minutes. If the content of the service is a diagnostic process, the start of the process is either manually instructed or started while other services are stopped, so the impact on other services is small. For this reason, the service importance of a service that is a diagnostic process will be the lowest.

[0032] Communication metrics are elements used when one microservice communicates with other microservices, and are determined by factors such as communication range, communication mode, and communication frequency. Communication range is a value obtained by, for example, the number of communication MS / total number of MS, or the number of events, and represents the number of other microservices connected to a particular microservice. Communication mode is determined by whether it is synchronous or asynchronous. Synchronous communication has a greater impact on the service than asynchronous communication. Communication frequency is expressed, for example, as the number of communications per second, and a higher communication frequency has a greater impact on the service. In the following explanation, communication metrics may be referred to as "communication."

[0033] The impact of a failure occurring in a microservice is calculated as the failure impact (E) using the formula (switchover time_degree) * (service severity_degree) * (communication_degree). In the following explanation, the values ​​of the elements with "_degree" appended are normalized to a value in the range of 0 to 1. The failure impact calculated by the failure impact calculation program 231 is stored in the memory management unit 220 as failure impact data 223.

[0034] The MS partitioning / integration program 232 (an example of the partitioning / integration unit) performs partitioning / integration processing to partition critical MSs or integrate multiple microservices until there are no critical MSs, in accordance with the pre-configured system requirements 300 (see Figure 5 described later). For example, based on the microservices rules 224 read from the memory management unit 220, the MS partitioning / integration program 232 performs partitioning / integration processing to further partition the microservices 121 of the target system 100 shown in Figure 1, or to integrate multiple microservices 121 to create a single microservice. When the MS partitioning / integration program 232 integrates multiple microservices 121, the number of microservices can be reduced, and the maintainability of the microservices can be improved. For this reason, when the MS partitioning / integration program 232 detects a critical MS, it performs the following processing: (1) partitioning or integrating the critical MS (program partitioning), and (2) resetting parameters (configuration file).

[0035] (1) Processing of splitting or merging critical MS (referred to as "MS splitting / merging") • Splitting: A process to split the MS (Multi-Speaker) when it has a significant impact on communication. • Integration: If real-time performance is reduced due to the division of MS (Management System) which has a significant impact on real-time performance, the MS are integrated to restore real-time performance. (2) Parameter resetting process • Items of parameters to be reset Buffer size, timeout duration, number of retries Reading from an external disk ·others

[0036] Furthermore, the services that the target system 100 can provide are built by combining multiple microservices. Each microservice consists of multiple programs. Therefore, the MS's splitting / integration process is performed on a program-by-program basis, not on a service-by-service basis.

[0037] The control program 233 reads the necessary data from the memory management unit 220 to perform calculations required for the processing in the target system 100 and controls the operation of the microservices. The control program 233 also controls the operation of the input unit 240, the output unit 250, and the communication processing unit 260.

[0038] The memory management unit 220 stores and manages the parameters 221, requirements data 222, failure impact data 223, and microservices rules 224.

[0039] Parameter 221 includes the failure detection time, the retry time, and the number of retries.

[0040] Requirements data 222 includes availability data, RT (Real Time) data (hereinafter abbreviated as RT data), and maintainability data.

[0041] The input unit 240 can use, for example, a keyboard or mouse, allowing the system designer 10 to perform predetermined operations and give instructions. The output unit 250 is, for example, a liquid crystal display monitor, which displays the results of the processing performed by the calculation unit 230 to the system designer 10. The communication processing unit 260 may use, for example, a NIC, and can send and receive various types of data to and from the target system 100 via a LAN, dedicated line, etc., connected to the terminals of the NIC.

[0042] Figure 3 is a schematic diagram showing the process flow for optimizing microservices after the large program 111 has been converted into microservices. Arrows and numbers in the figure are used to explain the process flow.

[0043] (1) Pre-MS partitioning process The target system 100 undergoes a preliminary MS partitioning process before the MS partitioning / integration process according to this embodiment. During this process, the massive monolithic program 111 stored in the memory management unit 110 is divided into multiple microservices and stored in the memory management unit 120. This MS partitioning process is a process in which the system designer 10 roughly divides the massive program 111, and detailed requirements are not necessary.

[0044] (2) Setting system requirements Next, the system designer 10 sets the system requirements 300 in the memory management unit 220 as the microservices rule 224 shown in Figure 1. Examples of system requirements 300 include availability 310, MS real-time performance 320, and maintainability 330. Availability 310, MS real-time performance 320, and maintainability 330 are all requirements set for each microservice.

[0045] (3) Splitting / integrating MS The control system 200's failure impact calculation program 231 calculates the failure impact of the microservices. The MS partitioning / integration program 232 partitions or integrates the microservices 121 stored in the memory management unit 120 based on the microservices rules 224. The control system 200 can perform the microservices process automatically, but it may also be configured to allow the system designer 10 to interactively instruct the system to execute the process and to confirm the execution results.

[0046] (4) Receipt of the division result from the target system 100 to the control system 200 The MS partitioning / integration program 232 receives the partitioning results of the microservices 121 from the target system 100. The partitioning results include the microservices configuration and the requirements for the microservices.

[0047] (5) Confirmation of the division result received by the control system 200 The system designer 10 checks the division results received by the control system 200.

[0048] (6) Reconfiguring System Requirements 300 If the partitioning result indicates that an optimal solution exists, no further processing is required. An optimal solution exists if, as a result of the partitioning and integration process, critical MSs are eliminated and all microservices satisfy system requirement 300. Therefore, if the resulting microservice 121 satisfies system requirement 300, the system designer 10 terminates the process. On the other hand, if the partitioning result indicates that an optimal solution does not exist, the system designer 10 resets system requirement 300 and notifies the control program 233 that system requirement 300 has been reset.

[0049] (7) Reinstructions for the division / integration of MS The system designer 10 inputs an instruction to the control system 200 to perform MS division / integration again based on the reconfigured system requirements 300. Subsequently, processes (3) to (5) described above are executed again.

[0050] Here, we will explain the failure impact (E) calculated by the failure impact calculation program 231 in process (3). Failure impact (E) is an index that shows how a failure occurring in one microservice affects other microservices, and is defined by the switching time_degree E(to), service severity_degree E(pr), and communication_degree E(cm) shown in equation (1) below. If the failure impact is greater than the threshold value (C), it is determined to be a critical MS.

[0051] E = E(to) * E(pr) * E(cm) …(1)

[0052] The impact of a failure is determined using either multiplication or the maximum value. If any one of the following is important, the failure impact (E), transition time (E(to)), service severity (E(pr)), or communication severity (E(cm)), the failure impact (E) is considered high. 0 ≤ E ≤ 1 0 ≦ E(to), E(pr), E(cm) ≦ 1

[0053] Switching time_degrees E(to) The conversion is performed using the conversion table described later, so that 0 ≤ (switching time_degrees) ≤ 1. Switching time_degrees E(to) is determined by, for example, the failure detection time, message retransmission time, retry time, number of retries, or hard disk read time (shared data read). As the switching time increases, the scope of the failure's impact expands.

[0054] ·Importance_degreeE(pr) The conversion table is used to ensure that 0 ≤ (service importance) ≤ 1. Service importance is determined based on the role of the business. When a critical service fails, the scope of the failure expands.

[0055] Communication_degrees E(cm) The conversion is performed using a conversion table so that 0 ≤ (communication_degree) ≤ 1. The communication_degree is converted based on, for example, the number of received MS / total MS, the number of transmitted MS / total MS, the number of MS being communicated with / total MS, communication frequency, communication range, communication type (synchronous / asynchronous), or event type.

[0056] Figure 4 is a flowchart showing an example of MS partitioning / integration processing. The MS partitioning / integration processing shown in Figure 4 is an example of a microservices processing method performed during system design when partitioning the target system 100 into microservices.

[0057] First, the system designer 10 divides the massive monolithic program 111 into microservices before starting the main process (S1). Here, the system designer 10 divides the massive program 111 into microservices by desk calculations or by running a simple tool (S1A). Next, the failure impact calculation program 231 of the control system 200 calculates the failure impact (S2).

[0058] The processes described below can be broadly divided into two parts: process 400, which eliminates critical MS, and process 410, which determines the trade-off between real-time performance and maintainability (MS size). In process 400, the MS partitioning / integration program 232 determines whether it has detected a critical MS in the microservices partitioned in step S1 (S3). If it determines that a critical MS has been detected (YES in S3), the MS partitioning / integration program 232 partitions or integrates the critical MS (S4).

[0059] Furthermore, the MS splitting / integration program 232 sets parameters for the microservices split or integrated in step S4 according to the algorithm (S5). Then, returning to step S2, the failure impact calculation program 231 calculates the failure impact (S2) and repeats the process until no critical MSs are detected.

[0060] If the process in step S3 determines that no critical MS is detected (NO in S3), the MS partitioning / integration program 232 evaluates the real-time performance and MS size of the microservices (S6). Then, the MS partitioning / integration program 232 determines whether both the real-time performance and MS size of the microservices are OK or not (S7). In step S7, if either the real-time performance or the MS size is not OK, the microservice is evaluated as not being an optimal MS. Note that increasing real-time performance decreases maintainability, and decreasing real-time performance decreases maintainability. above It is a trade-off relationship.

[0061] If it is determined that neither real-time performance nor MS size is acceptable (NG in S7), the MS partitioning / integration program 232 partitions or integrates the microservices (S8). The MS partitioning / integration program 232 also sets parameters for the partitioned or integrated microservices (S9). Then, the process returns to step S2, where the failure impact calculation program 231 calculates the failure impact (S2), and the process is repeated.

[0062] If, despite performing the process in step S7 a predetermined number of times, it is determined that neither real-time performance nor MS size is satisfactory, then the optimal MS has not been found. Therefore, the MS splitting / integration program 232 notifies the system designer 10 of a warning (S10). Upon receiving the warning, the system designer 10 manually resets the system requirements 300 (see Figure 3) and runs the process again (S11). For example, if the system designer 10 wants to prioritize real-time performance even if it means a larger MS size, they might choose to relax the MS size requirement.

[0063] If the processing in step S7 determines that both real-time performance and MS size are OK (OK in S7), the MS splitting / integration program 232 terminates this process.

[0064] <System Requirements Description> Next, we will explain the details of System Requirement 300.

[0065] Figure 5 shows an example configuration of system requirement 300. System Requirements 300 consists of the following items: performance classification, performance item, value, and content. As shown in Figure 3, the performance classification of system requirement 300 is divided into availability 310, real-time performance 320, and maintainability 330. The MS splitting / integration program 232 performs splitting and integration processing to satisfy system requirement 300 in the order of real-time performance, availability, and maintainability.

[0066] In Availability 310, the performance item is "Switchover Time," and the value for Switchover Time is, for example, 5 seconds. The content of Availability 310 is "MS Switchover Time." In other words, Availability 310 defines the switchover time from when a failed MS is replaced by a healthy MS.

[0067] In Real-Time Performance 320, the performance item is "execution time," and the execution time value is, for example, 12 milliseconds. The content of Real-Time Performance 320 is "execution time of mission-critical services." In other words, MS that require real-time performance are required to complete processing within the execution time range.

[0068] In Maintainability 330, the performance item is "MS size," the value of which is, for example, 5kstep, and the content of Maintainability 330 is "MS size." In other words, as the MS size increases, maintainability decreases, so it is required to divide or merge the MS until the MS size is less than 5kstep.

[0069] As described above, if the failure impact (E), calculated using availability 310, real-time performance 320, and maintainability 330, is greater than the baseline value C, it indicates that the microservice is a critical MS. Therefore, the MS partitioning / integration program 232 can eliminate critical MS by repeatedly performing partitioning and integration processes to reduce the failure impact value.

[0070] Figure 6 shows the contents of Availability 310. Availability 310 consists of performance classification, parameters, and values.

[0071] The parameters for Availability 310 include the alive message, retry time, and number of retries. The alive message is a message issued at regular intervals to check if other microservices are functioning correctly.

[0072] A retry is the process of attempting to execute the same process again if a microservice terminates abnormally. For example, if a microservice fails to send an alive message, a process will be executed to attempt to send the alive message again after a certain period of time. The retry time is, for example, the time it takes for a microservice to decide whether or not to send an alive message. If a response to an alive message sent to another microservice is not received within the retry time, a retry is performed. The number of retries is the number of times a microservice attempts to retry an action. For example, the `alive` message might have a 3-second timeframe, a 2-second retry timeframe, and a 2-retry count. Based on the values ​​shown in Figure 6, the fault detection time is calculated to be 3 seconds + 2 seconds × 2 times = 7 seconds.

[0073] <Explanation of the elements of failure impact and the failure impact conversion table> Next, the elements of the failure impact and the failure impact conversion table will be explained with reference to Figures 7 to 9.

[0074] Figure 7 shows an example of a conversion table for switching time in degrees. The conversion table for the transition time_degree consists of the following items: microservice (MS), transition time, and transition time_degree. As mentioned above, the transition time_degree is set for each microservice within the range of 0 ≤ (transition time_degree) ≤ 1.

[0075] For example, if the failover time for microservice MS_A is 1 second or less, the failover time score is "0.9". Also, if the failover time for microservice MS_B is between 1 second and 3 seconds, the failover time score is "0.7".

[0076] Figure 8 shows an example of a conversion table for importance levels. The importance conversion table consists of the following items: service, service importance, and microservice. As mentioned above, the importance is set for each microservice within the range of 0 ≤ (service importance) ≤ 1.

[0077] The service items will contain services A through D. The service importance item stores the service importance for each service from Service A to Service D. In the microservices section, the microservices that make up Service_A to Service_D are represented by circles.

[0078] For example, Service A has a service importance of 0.9 and consists of microservices MS_A, MS_B, and MS_F. Service B has a service importance of 0.9 and consists of microservices MS_B and MS_C. Service C has a service importance of 0.5 and consists of microservices MS_A, MS_C, MS_D, and MS_F.

[0079] Then, by using the importance-to-importance conversion table, the average microservice importance can be calculated from the service importance. For example, the importance of microservice MS_A is calculated as (0.9 + 0.5) / 2 = 0.7, and the importance of microservice MS_B is calculated as (0.9 + 0.9) / 2 = 0.9. Similarly, the importance of microservices MS_C to MS_F can be calculated.

[0080] Figure 9 shows an example of a communication degree conversion table. The communication degree conversion table consists of the following items: communication range (Com_R), communication frequency (Com_F), communication type (Com_T), and average communication degree. As mentioned above, the communication degree is set within the range of 0 ≤ (communication degree) ≤ 1.

[0081] The communication range (Com_R) is expressed as the number of communication MSs divided by the total number of MSs. For example, if the communication range is 0-1%, it is calculated as "0.2", and if it is 1-20%, it is calculated as "0.4". The communication frequency (Com_F) is calculated as the number of transmissions and receptions per second. For example, the communication frequency is calculated as "0.2" if it is 0 to 1 time or less, and as "0.4" if it is 1 to 30 times or less. The communication mode (Com_T) is expressed as either synchronous or asynchronous. For example, it is calculated as "0.3" for synchronous communication and "0.7" for asynchronous communication.

[0082] The average communication frequency is calculated using the formula {(Com_R)+(Com_F)+(Com_T)} / 3. For example, if the communication range (Com_R) is 0-1% or less, the communication frequency (Com_F) is 0-1 or less, and the communication type (Com_T) is synchronous, the average communication frequency is calculated to be "0.23".

[0083] Figure 10 is an example of a conversion table showing the relationship between the degree of failure impact and the detection and determination method for critical MS. This table consists of the following items: MS, failure impact, critical MS detection / determination, availability, severity, and communication items.

[0084] The MS field stores the values ​​for microservices MS_A through MS_F. Therefore, the value for each field is determined for each microservice. The "Failure Impact" section stores the values ​​for failure impact (E), failover time E(to), service severity E(pr), and communication E(cm), calculated for each microservice.

[0085] The Critical MS Detection Criteria section stores the results of the Critical MS detection. A microservice is determined to be a Critical MS if its failure impact (E) is greater than the threshold value (C). Microservices determined to be Critical MS are marked with a circle, while microservices determined not to be Critical MS are marked with an X. For example, microservices MS_A through MS_C are determined to be Critical MS.

[0086] In the Availability, Severity, and Communication fields, an "X" mark is stored for microservices that have been determined to be critical MS and do not meet the requirements. In Figure 10, MS_A through MS_C are determined to be critical MS, and microservice MS_A does not meet the availability requirements. Microservice MS_B does not meet the service severity requirements. Also, microservice MS_C does not meet the communication requirements.

[0087] On the other hand, microservices MS_D to MS_F are not critical microservices. However, microservices MS_D and MS_E are assumed to not satisfy real-time requirements, as explained in Case 4 in Figure 16 below. Also, considering service 4, MS_F is assumed to not satisfy maintainability requirements due to its large microservice size, as explained in Case 5 in Figure 16 below. Note that real-time requirements are determined by the type of service, not the microservice itself. Therefore, even if one microservice satisfies real-time requirements, a service composed of multiple microservices may not.

[0088] The right side of the communication degree conversion table shown in Figure 9 stores the average values ​​of the communication range (Com_R), communication frequency (Com_F), and communication type (Com_T). The failure impact in the conversion table shown in Figure 10 stores the product of the switching time degree E(to), service severity degree E(pr), and communication degree E(cm). However, these values ​​may be calculated using various formulas other than taking the average, such as taking the maximum or minimum value.

[0089] Next, we will explain the processing performed by the calculation unit 230 of the control system 200 shown in Figure 2. Figure 11 is a flowchart showing an example of the process for eliminating critical MS. Here, the process of eliminating critical MS is performed based on the result of the failure impact calculation program 231 calculating the failure impact (E) of the critical MS.

[0090] Prior to the processing shown in Figure 11, it is assumed that the large program 111 has been divided into six microservices (MS_A, MS_B, MS_C, MS_D, MS_E, MS_F) by step S1 shown in Figure 4.

[0091] Next, in step S2 shown in Figure 4, the failure impact calculation program 231 calculates the failure impact of the six microservices (MS_A, MS_B, MS_C, MS_D, MS_E, MS_F), and in step S3 shown in Figure 4, it is determined that microservices MS_A, MS_B, and MS_C are critical MS. The process shown in Figure 11 is performed after step S3 shown in Figure 4 has detected that multiple microservices have critical MS.

[0092] In this process, the failure impact calculation program 231 determines the cause of the critical microservice failure (MS). For example, the failure impact calculation program 231 determines whether the cause of the critical MS is the failover time (S21). If the cause of the critical MS is the failover time, the criteria for determination are, for example, the timeout, retry interval, and number of retries if it is a parameter, and the MS size and read time if it is checkpoint data. Checkpoint data is data necessary to take over to another microservice when a failure occurs in one microservice.

[0093] Even if microservices are split or merged, the parameters (timeout, retry interval, number of retries) remain unchanged. On the other hand, when microservices are split, the size of the checkpoint data decreases, so the time it takes to read the checkpoint data also decreases. Conversely, when multiple microservices are merged, the size of the checkpoint data increases, so the time it takes to read the checkpoint data increases.

[0094] If the critical MS factor is the failover time, which is one of the availability assessment criteria (YES in S21: Case 1), the failure impact calculation program 231 resets the parameters of microservice MS_A (S22).

[0095] Next, the failure impact calculation program 231 calculates the failure impact (S23) and determines whether the failure impact meets the standard value, that is, whether the failure impact (E) is greater than the standard value (C) (S24). If the failure impact does not meet the standard value (NO in S24), the failure impact calculation program 231 returns to step S21 and repeats the process. If the failure impact meets the standard value (YES in S24), the failure impact calculation program 231 terminates this process.

[0096] In step S21, if the cause of the critical MS is not the switching time (NO in S21), the failure impact calculation program 231 determines whether the cause of the critical MS is communication or not (S25). The criteria for determining whether the cause of the critical MS is communication or not are, for example, the communication range (number of communication MS / total number of MS), the communication frequency (number of communications per second), or the communication type (synchronous, asynchronous).

[0097] If the critical MS factor is communication (YES in S25: Case 3), the MS partitioning / integration program 232 partitions the microservice. At this time, the MS partitioning / integration program 232 performs partitioning / integration processing based on communication indicators, at least the communication range, communication frequency, and communication type.

[0098] Next, the failure impact calculation program 231 calculates the failure impact (S23) by considering the communication between the transmitting microservice and the receiving microservice (S26). For example, the MS splitting / integration program 232 splits the critical MS, microservice MS_C, into microservices MS_C1 and MS_C2. Next, the failure impact calculation program 231 calculates the failure impact of microservices MS-C1 and MS-C2 and determines whether the failure impact (E) of each is below the threshold value (C) and whether the threshold value is met (S24).

[0099] In step S25, if the cause of the critical MS is not communication (S25 NO: Case 2), the failure impact calculation program 231 notifies the system designer 10 that "the cause of the critical MS is service importance" (S27), and terminates this process.

[0100] Service importance is a fixed value and cannot be changed. Microservices with high service importance generally have short switching times and wide communication ranges. Therefore, when a microservice has high service importance, it is desirable to perform splitting and merging processing while considering switching time and communication range. If service importance can be changed, the system designer 10 may reset the importance of microservice MS-B.

[0101] The process shown in Figure 11 is repeatedly executed until the critical MS is eliminated. Once the critical MS is eliminated, the trade-off determination process 410 shown in Figure 4 is performed. However, as will be described later, there are cases where the critical MS cannot be completely eliminated and the core portion of the critical MS remains. In this case, the control program 233 treats the core portion of the critical MS as equivalent to the critical MS and implements redundancy or other measures to ensure that service can continue even when the critical MS fails.

[0102] <Impact of failure by case> Figure 12 shows examples of factors contributing to critical MS in cases 1-3. This figure consists of the case, the formula for calculating the impact of the failure, the processing details, and each item of the relevant MS.

[0103] The case items will contain cases 1 to 3 shown in Figure 11. Cases 1 to 3 are examples of critical MSs. A critical MS is defined as one in which the failure impact (E) is greater than the baseline value (C) of "0.2". To eliminate critical MSs, it is necessary to improve the highest of the following indicators: switching time, severity, and communication.

[0104] The fields in the failure impact calculation formula store the calculated failure impact (E), transition time_degree E(to), service severity_degree E(pr), or communication_degree E(cm).

[0105] The processing details field stores the processing details for each case (1-3). The corresponding MS item will contain MS_A for Case 1, MS_B for Case 2, and MS_C for Case 3.

[0106] In Case 1, the failure impact is improved by resetting parameter 122 to a failover time of 0.9 for the microservice MS_A. Therefore, the processing content item for Case 1 will contain "Parameter reset" as shown in step S22 of Figure 11.

[0107] In Case 2, the severity level (0.9) of the microservice MS_B is notified to the system designer 10, and the failure impact is improved by resetting parameter 122. Therefore, the processing content items for Case 2 include "Notify system designer 10" and "Reset parameter 122," as shown in step S27 of Figure 11.

[0108] In Case 3, the MS partitioning / integration program 232 improves the impact of failures by partitioning the microservice MS_C so that the communication degree (0.8) is lower. For this reason, the processing content item for Case 3 stores "partitioning of microservices" as shown in step S26 of Figure 11.

[0109] <Settings for Case 1> In Case 1, the failure impact (E) of microservice MS_A is greater than the threshold value (C), so microservice MS_A is determined to be a critical MS. The parameters for microservice MS_A are reset by querying the system designer 10. The parameters are then reset by changing the retry time and the number of retries. After that, the failure impact (E) of microservice MS_A with the reset parameters is recalculated.

[0110] Figure 13 shows an example of changing the availability settings in Case 1. The table shown in Figure 13 consists of the following items: pre-configuration or reconfiguration type of parameter 122 (indicated as "pre-configuration / reconfiguration"), parameter, and failure impact.

[0111] The parameter section includes configurable items (failure detection time, retry time, number of retries) and their values. The "Fault Impact" item stores the calculated fault impact (E), switching time_degree E(to), service severity_degree E(pr), or communication_degree E(cm), similar to the items in the fault impact calculation formula shown in Figure 12.

[0112] If the pre-configured parameters 122 have a fault detection time of 1 second, a retry time of 1 second, and 0 retries, the calculated fault impact (E) is "0.315". If the threshold value (C) for determining a critical MS is "0.2", then fault impact (E) > threshold value (C), and the microservice will be split.

[0113] On the other hand, if the reset parameters have a failure detection time of 1 second, a retry time of 2 seconds, and 2 retries, the calculated failure impact (E) is "0.175". Since the failure impact (E) < baseline value (C), no further microservice splitting will be performed.

[0114] <Settings for Case 2> In Case 2, the failure impact (E) of microservice MS_B is greater than the threshold value (C), so microservice MS_B is determined to be a critical MS. The parameters for microservice MS_B are reset by querying system designer 10. At this time, system designer 10 is asked if the importance can be reduced. If the importance requested in the query is a service importance, system designer 10 reconsiders the service importance. For example, system designer 10 reviews the service importance of service_A and service_B, which are related to microservice MS_B, and resets the service importance. Then, system designer 10 determines the importance of microservice MS_B based on the reset service importance values.

[0115] Figure 14 shows an example of service severity in Case 2. The table in Figure 14 consists of the following items: type of pre-configuration or reconfiguration of parameter 122 (indicated as "pre-configuration / reconfiguration"), parameter, and failure impact.

[0116] The parameter fields include configurable items (service, MS) and their values. The "Fault Impact" field stores the calculated fault impact level (E), failover time level (E) (to), service severity level (E) (pr), or communication level (E) (cm).

[0117] In the pre-configured parameter 122, the value of service_A is "0.9", the value of service_B is "0.9", and the value of microservice MS_B, which is used in both service_A and service_B, is "0.9". In this case, the calculated fault impact (E) is "0.225". If the threshold value (C) for determining a critical MS is "0.2", then fault impact (E) > threshold value (C), and parameter 122 is reset.

[0118] On the other hand, with the reconfigured parameter 122, the value of service_A is "0.7", the value of service_B is "0.7", and the value of microservice MS_B, which is used in both service_A and service_B, is "0.7". In this case, the calculated failure impact (E) is "0.175". Since failure impact (E) < baseline value (C), no further microservice division will be performed.

[0119] <Settings for Case 3> In Case 3, the failure impact (E) of microservice MS_C is greater than the threshold value (C), so microservice MS_C is determined to be a critical MS. Therefore, the MS splitting / integration program 232 splits MS microservice MS_C into microservice MS_C1 and MS_C2.

[0120] Figure 15 shows an example of communication in Case 3. The table shown in Figure 15 consists of the following items: pre-configuration or reconfiguration type of parameter 122 (indicated as "pre-configuration / reconfiguration"), MS, parameter, and fault impact.

[0121] The MS field stores the pre-configured microservice MS_C and the reconfigured microservices MS_C1 and MS_C2. The parameter section includes configurable items (communication MS / total MS, communication frequency, communication type) and their values. The "Fault Impact" field stores the calculated fault impact (E), failover time (E(to)), service severity (E(pr)), or communication severity (E(cm)).

[0122] In the pre-configured parameters, microservice MS_C has a communication MS / total MS ratio of 40%, a communication frequency of 60 times, and an asynchronous communication mode. In this case, the calculated failure impact (E) is "0.266". If the threshold value (C) for determining a critical MS is "0.2", then failure impact (E) > threshold value (C), and the microservice will be split.

[0123] <Trade-off determination process> Next, the trade-off determination process will be explained with reference to Figures 16 to 19. Figure 16 is a flowchart illustrating an example of a trade-off determination process. Here, the real-time performance and maintainability of six microservices (MA-A, MA-B, MS-C1, MS-C2, MS-D, MS-E, MS-F) are evaluated. The evaluation priority in this process is real-time performance, availability, and maintainability, in that order. Furthermore, if any of the evaluation items do not meet the criteria, a warning is issued.

[0124] First, the MS partitioning / integration program 232 determines whether the trade-off factor is real-time performance (S31). Partitioning a critical MS reduces the MS size and thus the impact of failures. Also, since the processing for each partitioned microservice becomes lighter, the response to requests made to the microservices becomes faster, improving real-time performance. Therefore, the real-time performance of the partitioned microservices is evaluated first. Real-time performance is evaluated based on whether the execution time of the microservices is within a predetermined time. If the execution time of the microservices is within the predetermined time, it is determined that there is no problem with real-time performance. On the other hand, if the execution time of the microservices exceeds the predetermined time, it is determined that there is a problem with real-time performance.

[0125] In step S31, if the trade-off factor is real-time performance (YES in S31: Case 4), the failure impact calculation program 231 evaluates it as OK if the microservice satisfies real-time requirements. On the other hand, the MS splitting / integration program 232 evaluates it as NG if the microservice does not satisfy real-time requirements and optimizes the microservice parameters 122 to satisfy real-time requirements. For example, if the relevant part of the critical MS that affects real-time performance has been split, the MS splitting / integration program 232 integrates the split microservices, changes the parameters, returns them to the critical MS, and calculates the real-time time (S32).

[0126] The MS partitioning / integration program 232 prioritizes real-time performance over availability when it integrates partitioned microservices and returns them to a critical MS. The return to a critical MS is notified to the system designer 10 as a warning. Furthermore, if the MS size of the critical MS exceeds a certain threshold as a result of the integration, the system designer 10 is also notified as a warning. Note that integrating multiple microservices into a critical MS can increase processing load and slow response times, thus reducing real-time performance. However, increasing the size of the microservices reduces the number of programs, making program maintenance easier and improving maintainability.

[0127] Next, the failure impact calculation program 231 calculates the failure impact (E) of the integrated microservices (S33) and determines whether the failure impact (E) meets the threshold value (C), that is, whether the failure impact (E) is less than or equal to the threshold value (C) (S34). If the failure impact (E) does not meet the threshold value (C) (NO in S34), the process returns to step S31 and the trade-off determination process is repeated. On the other hand, if the failure impact (E) meets the standard value (C) (YES in S34), the failure impact calculation program 231 terminates this process.

[0128] In Case 4, for example, suppose the trade-off factor between microservices MS_D and MS_E was real-time performance. If the relevant parts (transactions) affecting real-time performance are split and microservices MS_D and MS_E are created, the MS splitting / integration program 232 integrates microservices MS_D and MS_E and calculates the execution time of the integrated microservice. Subsequently, the failure impact calculation program 231 determines whether the execution time of the integrated microservice is within a predetermined time. The failure impact calculation program 231 also calculates the failure impact of the integrated microservice and determines whether the failure impact meets the threshold value.

[0129] In step S31, if the trade-off factor is not real-time performance (NO in S31), the maintainability of the microservice is evaluated. The maintainability of the microservice is determined by evaluating the size of the microservice and checking whether it is below a predetermined value. If the MS size is below the predetermined value, it is determined that there is no problem with maintainability. On the other hand, if the MS size is larger than the predetermined value, it is determined that there is a problem with maintainability.

[0130] Therefore, the failure impact calculation program 231 determines whether the trade-off factor is the MS size (S35). If the trade-off factor is the MS size (YES in S35: Case 5), the failure impact calculation program 231 determines whether the MS size is below a certain value.

[0131] The failure impact calculation program 231 evaluates the process as OK if it determines that the MS size of the microservice is below a certain value, and terminates processing. On the other hand, if the failure impact calculation program 231 determines that the MS size of the microservice is above a certain value, it evaluates it as NG and notifies the system designer 10 of a warning. In this case, the failure impact calculation program 231 prioritizes real-time performance and availability at the expense of MS maintainability (S36). After that, the failure impact calculation program 231 terminates processing. Thus, real-time performance is prioritized first in step S31, then in step S35, if the MS size related to maintainability is a trade-off factor, real-time performance and availability are prioritized. Finally, maintainability is prioritized.

[0132] In Case 5, for example, suppose the trade-off factor for microservice MS_F is maintainability. In this case, the MS partitioning / integration program 232 partitions the microservice MS_F, which is the factor causing the trade-off. However, as in Case 4, if partitioning the microservice MS_F would affect real-time performance, it is not partitioned. Subsequently, the failure impact calculation program 231 calculates the failure impact of the partitioned microservice MS_F and determines whether the failure impact meets the threshold value. After that, a warning is notified to the system designer 10.

[0133] In step S35, if the trade-off factor is not MS size (S35 NO: Case 6), then there is no trade-off factor, and the failure impact calculation program 231 terminates the process without taking any action.

[0134] Figure 17 shows an example of processing time and failure impact when the trade-off factor in Case 4 is real-time performance. Here, we will explain assuming that a YES determination was made in step S31 of Figure 16 (Case 4).

[0135] The left side of this table consists of the MS (Management System) and real-time performance items, while the right side consists of the failure impact and the MS items. The target values ​​shown on the left side of the table are used to determine real-time performance and are expressed as the sum of the execution time and latency of the microservices. In this example, the target value is set to a total time of 12 milliseconds.

[0136] Real-time performance is calculated based on the pre-processing time and the reconfiguration processing time. The pre-processing time represents the execution time, waiting time, and total time of the processes performed by microservices MS_D and MS_E, respectively. Since the total time shown in the pre-processing time is 15ms, it exceeds the target value of 12ms.

[0137] Furthermore, the failure impact shown on the right side of the table stores the calculated values ​​for microservice MS_D and MS_E, respectively. For example, the failure impact (E) for microservice MS_D is "0.084" and the failure impact (E) for microservice MS_E is "0.075", which is smaller than the aforementioned baseline value (C) of "0.2", thus meeting the baseline.

[0138] As shown in Figure 8, Service D consists of two separate microservices, MS_D and MS_E, neither of which are critical microservices. However, latency occurs between MS_D and MS_E, causing the total time to exceed the target value and failing to meet real-time requirements. Therefore, a process is performed to integrate MS_D and MS_E. When integrating microservices, the larger of the following values ​​is adopted: switching time, importance, and communication.

[0139] The reconfiguration processing time is calculated for the microservice MS_DE, which is formed by integrating microservices MS_D and MS_E. Because microservices MS_D and MS_E are integrated, the waiting time becomes 0 seconds. The total execution time and waiting time for microservice MS_DE is 10ms, which is within the target value of 12ms, thus meeting the real-time requirement. Furthermore, the failure impact (E) of microservice MS_DE is "0.14," which is lower than the baseline value (C) of "0.2," thus meeting the baseline.

[0140] Figure 18 shows an example of maintainability and failure impact when the trade-off factor in Case 5 is maintainability (MS size). Here, we will explain assuming that a YES decision was made in step S35 of Figure 16 (Case 5).

[0141] The table shown at the top of Figure 18 consists of the following items: MS, maintainability, and failure impact. The target value for maintainability is an MS size of 10K steps. The initial MS size for microservice MS_F is 15K steps, which exceeds the target value. Furthermore, the failure impact (E) of microservice MS_F is "0.175", which is smaller than the aforementioned threshold value (C) of "0.2", thus meeting the threshold.

[0142] Therefore, microservice MS_F whose MS size is larger than the target value is split into microservice MS_F1 and MS_F2, and its maintainability and failure impact are assessed again. The reset MS sizes are 8k steps for microservice MS_F1 and 8k steps for microservice MS_F2, both of which are below the maintainability target. Furthermore, the failure impact (E) is 0.081 for both microservice MS_F1 and 0.081 for microservice MS_F2, both of which are below the threshold value (C), thus meeting the threshold.

[0143] The table shown at the bottom of Figure 18 stores the communication items (communication range (Com_R), communication frequency (Com_F), communication type (Com_T)) and the average communication frequency for the microservice MS_F before splitting. The values ​​for each communication item (communication range (Com_R), communication frequency (Com_F), communication type (Com_T)) are stored using the communication frequency conversion table shown in Figure 9.

[0144] The communication range (Com_R) of microservice MS_F is "0.2", the communication frequency (Com_F) is "0.2", the communication type (Com_T) is "0.3", and the average communication frequency is "0.23". On the other hand, since microservices MS_F1 and MS_F2 communicate with each other, the values ​​of each communication-related item become larger. For example, the communication range (Com_R) of microservices MS_F1 and MS_F2 is "0.6", the communication frequency (Com_F) is "0.6", the communication type (Com_T) is "0.3", and the average communication frequency is "0.5".

[0145] Even if the critical MS is divided, if stringent system requirements 300 are set, the core portion may remain. If the core portion remains, it may not meet the system performance requirements (availability, real-time performance, maintainability). In this case, the system designer 10 is notified that there is a core portion that does not meet the system performance requirements. For example, it may not be possible to satisfy both real-time performance and maintainability simultaneously. In this case, the control system 200 proposes a message to the system designer 10 encouraging them to prioritize real-time performance and accept that maintainability will not be met. The system designer 10 then readjusts the system requirements 300 (availability, real-time performance, maintainability) according to the proposal. The control system 200 then divides / integrates microservices and readjusts parameters according to the readjusted system requirements 300.

[0146] <Visualized scope of impact of the failure> Next, we will explain an example of visualizing the scope of the impact of a failure. Figure 19 shows an example of the display of screen 50, which visualizes the scope of the failure impact. This screen 50 is output by the output unit 250 shown in Figure 2, for example, after the processing of step S7 in Figure 4, and can be confirmed by the system designer 10.

[0147] Screen 50 has a command input field 51 that allows the system requirements 300 to be reset, an execution result display field 52, and a display field 53 that shows the scope of the failure, including critical MS.

[0148] The command input field 51 includes input fields for availability, real-time performance, and MS size as examples of commands. When the system designer 10 specifies availability, real-time performance, and MS size as commands in the command input field 51 and presses the execute button 51a, the microservices processing by the arithmetic unit 230 shown in Figure 2 is automatically executed.

[0149] After the system requirements 300 are reconfigured via the command input field 51, the execution result of the split-integration process is output. For example, the result of the microservices implementation process being automatically executed according to the reconfigured system requirements 300 is displayed in the execution result display field 52. If the execution result is not OK, a warning is notified to the system designer 10. The warning is notified, for example, by displaying a warning message in the display field 52 or by displaying a critical MS in the display field 53.

[0150] Furthermore, once the microservices implementation process is automatically executed, the microservices are visualized and displayed in the microservices implementation results display area 53. Here, the failure impact (E) of microservices MS_A to MS_F and the relationships between failures in each microservice are visualized and shown. For example, a failure in microservice MS_A affects microservice MS_D. Also, a failure in microservice MS_B affects microservices MS_D and MS_F.

[0151] Here, the failure impact (E) of microservice MS_D is "0.3", which is greater than the baseline value (C) of "0.2". Therefore, microservice MS_D is highlighted as a critical MS. System designer 10 can specify whether to further subdivide microservice MS_D, which is a critical MS.

[0152] <Explanation of recovery procedure> Next, we will explain the recovery procedures to be followed when a microservice fails. (1) Failure When a failure occurs in a microservice, the following recovery procedure is initiated. (2) Fault detection Next, failures occurring in microservices are detected.

[0153] (3) Recovery from disability Next, the process of recovering from the failure takes place. Here, two methods are used depending on whether the microservice is critical or not (usually).

[0154] (3-1) Important Microservices If a critical MS is critical, the control program 233 operates both the active and standby MS. As mentioned above, critical MS are processed to eliminate them as much as possible, but sometimes critical MS remain. In this case, the critical MS is divided, and the remaining core portion (the part equivalent to the critical MS) is operated in redundancy in both the active and standby systems as a critical MS. Then, when the control program 233 detects a failure in the critical MS, it switches the critical MS operating in both the active and standby systems from the active system to the standby system to continue service. An example of this service switchover will be described later.

[0155] (3-2) Typical microservices In a typical microservice, the MS is not redundant, and the standby MS is not operating. Therefore, when the control program 233 detects a failure in a typical microservice that is not operating in either the active or standby system, it starts a new microservice to compensate for the function of the microservice that detected the failure.

[0156] <Fault detection method> Next, we will explain how to detect failures in important microservices, referring to Figures 20 and 21. As described above, if a critical MS remains in the target system 100, the critical MS is configured in a redundant configuration. For example, a redundant configuration can consist of an active system and a standby system. When a failure is detected in the active system's critical MS, the system switches to the standby system's critical MS using either a checkpoint data transfer method or a dual-system transfer method, and service continues.

[0157] (Checkpoint data transfer method) Figure 20 shows an example of a fault detection method using a checkpoint data transfer scheme. For example, microservice MS_A communicates with the critical MS of the active system. The fault detection method using the checkpoint data transfer scheme is explained with numbers indicating the processing order in the diagram.

[0158] (1) The active critical MS periodically transfers checkpoint data to the standby critical MS. As mentioned above, checkpoint data is necessary to take over processing to the standby critical MS in the event of a failure in, for example, microservice MS_A. The standby critical MS takes over communication processing with microservice MS_A from the active critical MS upon receiving the checkpoint data. In addition, the active and standby critical MS confirm their operational status by sending each other Alive messages.

[0159] (2) A malfunction occurs in the critical MS of the current system. (3) When a failure occurs, the active critical MS will be unable to communicate with microservice MS_A. As a result, the standby critical MS will not be able to receive checkpoint data from the active critical MS. Furthermore, the standby critical MS will not be able to receive Alive messages from the active critical MS, nor will it be able to send Alive messages to the active critical MS. As a result, the standby critical MS will be able to detect that a failure has occurred in the active critical MS and execute recovery procedures.

[0160] (Dual-system transfer method) Figure 21 shows an example of a fault detection method using a dual-system forwarding system. For example, microservice MS_A communicates with both the active critical MS and the standby critical MS. The fault detection method using a dual-system forwarding system is explained with numbers indicating the processing order in the diagram.

[0161] (1) Microservice MS_A sends messages to the active critical MS and the standby critical MS. In the dual-system forwarding method, the active critical MS does not need to send checkpoint data to the standby critical MS. The active and standby critical MS confirm each other's operation by sending Alive messages.

[0162] (2) A malfunction occurs in the critical MS of the current system. (3) When a failure occurs, the active critical MS will be unable to communicate with microservice MS_A. The standby critical MS will not receive an Alive message from the active critical MS, nor will it be able to send an Alive message to the active critical MS. Therefore, the standby critical MS can detect that a failure has occurred in the active critical MS and perform recovery procedures.

[0163] In the control system 200 according to the embodiment described above, the system designer 10 performs preprocessing to convert the large program 111 into microservices. Subsequently, the control system 200 detects critical MS during system design by determining the requirements for each microservice according to the microservices rule 224. At this time, the control system 200 uses an algorithm to divide or merge microservices so that critical MS are eliminated from the microservices of the target system 100. As a result, critical MS are removed during the process of automatically optimizing the numerous microservices that make up the target system 100, making the system design of the microservices easier. Furthermore, by converting the existing target system 100 into microservices, the modernization of each microservice (the process of updating old programs) is made easier. In addition, by converting the existing target system 100 into microservices, it becomes easier to deploy the microservices to other environments.

[0164] In the control system 200, the impact of a failure is calculated, and by comparing the impact with a baseline value, it is determined whether a microservice is a critical microservice (MS). Microservices determined to be critical are expected to be eliminated through splitting or merging. When a critical MS is eliminated, even if a failure occurs in one microservice, the impact on other microservices is less likely to spread. Therefore, it becomes easier to replace only the failed microservice, and the spread of failures to the entire microservice ecosystem can be suppressed. In addition, by minimizing the connections between the failed microservice and other microservices, the time required to recover the failed microservice can be shortened.

[0165] Furthermore, the system requirements 300 for microservices are prioritized in the following order: real-time performance, availability, and maintainability. Microservices are divided or merged according to this priority, thus guaranteeing their performance.

[0166] Furthermore, microservices whose real-time time exceeds a certain value are integrated with other microservices, reducing their real-time time to below that value and thus meeting the real-time requirements. For this reason, the microservice division or integration process by the control system 200 is particularly useful for microservice implementation in the target system 100 where real-time performance is required.

[0167] Furthermore, considering the trade-off between real-time performance and MS size, microservices are divided or merged. As a result, microservices are generated such that real-time performance is less than a certain time and MS size is less than a certain value. Consequently, the target system 100 is composed of microservices that meet the requirements pre-set by the system designer 10.

[0168] Furthermore, when a critical MS is detected, information about the critical MS is visualized and displayed on screen 50. The system designer 10 can change the settings of system requirements 300, including availability, real-time performance, or MS size, while checking screen 50. The results of the microservice splitting or integration process performed again based on the changed system requirements 300 are then displayed on screen 50. This makes it easy for the system designer 10 to verify whether the changed system requirements 300 were appropriate.

[0169] It should be noted that the present invention is not limited to the embodiments described above, and various other applications and modifications can be taken as long as they do not depart from the gist of the present invention as described in the claims. For example, the embodiments described above are detailed and specific explanations of the configuration of the control system 200 in order to clearly illustrate the present invention, and are not necessarily limited to having all the configurations described. Furthermore, it is possible to replace some of the configurations of the embodiments described here with the configurations of other embodiments, and it is also possible to add the configurations of other embodiments to the configuration of one embodiment. In addition, it is possible to add, delete, or replace some of the configurations of each embodiment with other configurations. Furthermore, the control lines and information lines shown are those deemed necessary for explanatory purposes, and not all control lines and information lines are necessarily shown in the actual product. In reality, it can be assumed that almost all components are interconnected. [Explanation of Symbols]

[0170] 10...System designer, 50...Screen, 100...Target system, 120...Memory management unit, 121...Microservices, 122...Parameters, 200...Control system, 220...Memory management unit, 221...Parameters, 222...Requirements data, 223...Failure impact data, 224...Microservices implementation rules, 230...Calculation unit, 231...Failure impact calculation program, 232...MS splitting / integration program, 233...Control program

Claims

1. A calculation unit calculates the impact of a failure for each microservice, based on an index obtained from the switching time required to switch a failed microservice to another microservice among the microservices constituting the target system, an index obtained from the importance of the services provided by the microservice, and an index obtained from the average, multiplicative, maximum, or minimum value of communication indicators related to the communication of the microservice. The system includes a splitting and integrating unit that designates a microservice whose failure impact is greater than a threshold value as a critical microservice, and performs a splitting and integrating process to split the critical microservice or integrate multiple microservices until the critical microservice is eliminated, according to pre-set system requirements. Control system.

2. The aforementioned system requirements include real-time performance, availability, and maintainability. The division and integration unit performs the division and integration process in such a way that it satisfies the system requirements in the order of real-time performance, availability, and maintainability. The control system according to claim 1.

3. The aforementioned real-time performance and maintainability are in a trade-off relationship, where increasing real-time performance decreases maintainability, and decreasing real-time performance increases maintainability. The control system according to claim 2.

4. The division and integration unit performs the division and integration process based on at least the communication range, communication frequency, and communication type as communication indicators. The control system according to claim 2.

5. The division and integration unit optimizes the parameters of the microservices to satisfy the real-time requirement if the microservices do not satisfy the real-time requirement. The control system according to claim 2.

6. A screen is displayed that has a display field showing the scope of the failure, including the critical microservices, and an input field that allows the system requirements to be reconfigured. After the system requirements have been reset and entered into the input field, the execution result of the division and integration process is output. The control system according to claim 2.

7. A calculation unit that calculates the failure impact for each microservice among the microservices constituting the target system, based on an index obtained from an index obtained from the switching time required to switch a failed microservice to another microservice, an index obtained from the importance of the services provided by the microservice, and an index obtained from the average value, multiplicative value, maximum value, or minimum value of communication indicators related to the communication of the microservice, A microservice whose failure impact is greater than a threshold value is designated as a critical microservice, and a splitting and integrating unit performs a splitting and integrating process to divide the critical microservice in order to eliminate it as much as possible, or to integrate multiple microservices, according to pre-set system requirements. The system comprises a control unit that controls the operation of the microservices, The control unit makes the critical microservices that the division and integration unit could not divide into remaining critical microservices that operate on both the active and standby systems. When it detects a failure in the critical microservice operating on the active system, it switches the critical microservice from the active system to the standby system to continue the service. When it detects a failure in a microservice that is not operating on either the active or standby system, it starts a new microservice to supplement the functionality of the microservice. Control system.

8. If the target system is unable to be completely partitioned by the partitioning and integrating unit and some critical microservices remain, these remaining critical microservices are configured in multiplexing between the active and standby systems. When a failure in the critical microservices on the active system is detected, the system switches to the critical microservices on the standby system using either a checkpoint data transfer method or a dual-system transfer method to continue service. The control system according to claim 7.

9. A microservices processing method performed by a control system comprising a calculation unit and a partitioning and integrating unit, The calculation unit calculates the failure impact for each microservice based on an index obtained from the switching time required to switch a failed microservice to another microservice among the microservices constituting the target system, an index obtained from the importance of the services provided by the microservice, and an index obtained from the average, multiplicative, maximum, or minimum value of the communication index related to the communication of the microservice. The division and integration unit includes the step of designating the microservice whose failure impact is greater than a threshold value as a critical microservice, and performing a division and integration process to divide the critical microservice or integrate multiple microservices until the critical microservice is eliminated, according to pre-set system requirements. Microservices processing method.

Images