Multi-tenant service providing method and system

Abstract

To provide a technique that can reduce an increase in operation costs of multi-tenant service and ensure performance and punctuality.SOLUTION: A cloud system 101 includes: a plurality of common containers 301 each having microservices 311; a plurality of sidecar containers 302 paired with the plurality of common containers 301; and a plurality of individual containers 341 each having an orchestrator 342 that sequentially invokes and executes the microservices 311 for each of a plurality of tenants 201. Each of the plurality of sidecar containers 302 includes a request queue 332 that holds a request for execution of the microservices 311 from the orchestrator 342, and refers to the request queue 332 to perform load distribution to other sidecar containers 302.SELECTED DRAWING: Figure 6

Description

Technical Field

[0001] The present invention relates to a method and system for providing multi-tenant services.

Background Art

[0002] In order to efficiently provide power services such as prediction of power supply and demand and power market prices, aggregation and power generation planning, and power market transactions such as bidding processing, etc. to multi-tenants who are a plurality of operators with different scales, the operation of multi-tenant services in a cloud system has been studied. The multi-tenant service periodically and simultaneously performs power services for a plurality of operators (multi-tenants) each time a bid is placed in a power market transaction.

[0003] In such a cloud system, when implementing power services for multi-tenants by combining one or more microservices, if the number of tenants increases, the number of services increases, or customization of services for each tenant frequently occurs, the operation cost increases.

[0004] As a technique for suppressing an increase in the operation cost of a cloud system, Patent Document 1 proposes a technique of instantiating a pod including one or more containers and a sidecar container, temporarily stopping the execution of the sidecar container after the initialization of the execution of the sidecar container, and restarting the execution of the sidecar container in response to a determination that a container among the one or more containers requires additional computing resources, and providing an instruction to execute the computing task of the container to the sidecar container.

[0005] Also, as a technology for efficiently using server resources in a multi-tenant service, Patent Document 2 proposes a technique for an information processing apparatus that receives a request from a client and executes processing. The apparatus stores the received request in input storage means according to the source of the request, and after processing the request stored in the input storage means, performs processing on a request from a source different from that of the processed request.

Prior Art Documents

Patent Documents

[0006]

Patent Document 1

Patent Document 2

Summary of the Invention

Problems to be Solved by the Invention

[0007] In the technology disclosed in the above Patent Document 1, when continuously executing a service that requires performance and timeliness, even when resource securing is necessary for service processing execution due to processing delays of other services, an image of necessary processing including heavy main processing is loaded into the sidecar container. Therefore, it takes time until the processing is executed, leading to further delays and possibly even impairing timeliness.

[0008] Also, in the technology disclosed in the above Patent Document 2, resources are uniformly allocated to each tenant regardless of the number of requests from each tenant, but the time (processing time) for which each tenant occupies resources for its service is not necessarily uniform. For this reason, there are problems such as processing delays caused by an increase in data volume and the inability to know the processing time until execution.

[0009] Therefore, an object of the present invention is to provide a technology that can reduce an increase in the operation cost of a multi-tenant service and ensure performance and timeliness.

Means for Solving the Problem

[0010] In order to solve the above problems, one of the representative multi-tenant service providing methods of the present invention is a multi-tenant service providing method of a cloud system that provides services to a plurality of tenants. The cloud system includes a plurality of common containers each having a microservice, a plurality of sidecar containers paired with each of the plurality of common containers, and a plurality of individual containers each having an orchestrator for sequentially calling and executing microservices directed to each of the plurality of tenants. Each of the plurality of sidecar containers includes a request queue for holding a request for execution of a microservice from the orchestrator, and performs load distribution to other sidecar containers with reference to the request queue.

Advantages of the Invention

[0011] According to the present invention, it is possible to reduce an increase in the operation cost of the multi-tenant service and ensure performance and timeliness.

[0012] Problems, configurations, and effects other than those described above will be clarified by the description of the following embodiments.

Brief Description of the Drawings

[0013]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5A

Figure 5B

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10A

Figure 10B

Mode for Carrying Out the Invention

[0014] Hereinafter, examples will be described with reference to the drawings.

[0015] The cloud system of this embodiment is assumed to realize power services for multi-tenants through a combination of one or more microservices. Individual processing for each tenant is introduced into the sidecar container installed in the common microservice that does not depend on the tenant, and it is executed by switching for each tenant. Also, the sidecar container has a request queue, and adjusts the execution order for each tenant, requests proxy execution to other sidecar containers, or requests lending of resource occupancy rights.

[0016] FIG. 1 is a diagram showing an example of the configuration of a power service providing system to which the cloud system of this embodiment is applied.

[0017] The main components of the power service providing system of this embodiment are a cloud system 101, a client terminal 102, a power market server 103, and an EMS (Energy Management System) server 104.

[0018] The cloud system 101 provides power services to multiple tenants in cooperation with the power market server 103 and the EMS server 104. The client terminal 102 provides information presentation and the like to multiple tenants that receive power services from the cloud system 101.

[0019] The power market server 103 is a server that conducts power market transactions. The EMS server 104 is a server owned by consumers, power generation companies, etc. and manages the use of energy.

[0020] The cloud system 101, the client terminal 102, the power market server 103, and the EMS server 104 are interconnected via the Internet 105. However, the data provided from the EMS server 104 to the cloud system 101 is not only implemented by communication via the Internet 105, but also in some cases, data is stored in the cloud system 101 without going through the Internet 105, for example, manually.

[0021] The cloud system 101 includes one or more instances 111 to 115, a DB server 116, a control plane 121, a load balancer 122, a firewall 123, and a switch 132.

[0022] The instance 115, the control plane 121, the load balancer 122, and the firewall 123 are interconnected via the internal network 131. Also, the instances 111 to 114 and the DB server 116 are interconnected via the switch 132.

[0023] The instances 111 to 115 are virtual machines (VMs) running on a computer. In the instances 111 to 114, the microservices that make up the power service are executed. In the instance 115, an orchestrator that manages the flow execution of the microservices is executed. The cloud system 101 provides multi-tenant services through a combination of microservices.

[0024] The DB server 116 stores data accessed by the microservices executed by instances 111 to 114.

[0025] The control plane 121 manages resources within the cloud system 101, manages containers executed in the cloud system 101, manages communications, and so on.

[0026] The load balancer 122 distributes service requests from the orchestrator of instance 115 to instances 111 to 114. The load balancer 122 and instances 111 to 114 constitute a pooled environment for multi-tenants.

[0027] The firewall 123 restricts access from the Internet 105.

[0028] The cloud system 101 in FIG. 1 is realized by executing a program on a computer as shown in FIG. 2.

[0029] FIG. 2 is a block diagram showing an example of the hardware configuration of a computer that realizes the cloud system of this embodiment.

[0030] A computer 1000 for realizing the cloud system 101 is configured by interconnecting a CPU (Central Processing Unit) 1001, a memory 1002, a storage device 1003, a communication I / F 1004, an input device 1005, and a display device 1006 via a bus 1007.

[0031] The CPU 1001 is a central processing unit and implements necessary functions by executing a program held in the memory 1002 (or the storage device 1003).

[0032] The memory 1002 is a main memory device used when the CPU 1001 executes processing and is composed of volatile memory elements such as a RAM (Random Access Memory).

[0033] The memory device 1003 is an auxiliary storage device for storing input data provided to the CPU 1001 and output data output from the CPU 1001, and is composed of non-volatile memory elements such as an HDD (Hard Disk Drive) or an SSD (Solid State Drive).

[0034] The communication I / F 1004 is an interface used for the computer 1000 to communicate with an external device, and is composed of an NIC (Network Interface Card) or the like. The communication I / F 1004 is connected to a network (for example, the Internet) and communicates with an external device via the network.

[0035] The input device 1005 is an interface composed of a keyboard, a touch panel, a card reader, or a voice input device, etc., and receives input from a user.

[0036] The display device 1006 is an interface that presents information to a user by displaying the output data on a screen.

[0037] The bus 1007 is an internal communication path of the computer 1000.

[0038] In one or more computers 1000 having a hardware configuration as illustrated in FIG. 2, the CPU 1001 of the cloud system 101 implements necessary functions by executing a program held in the memory 1002 (or the memory device 1003).

[0039] FIG. 3 is a diagram showing a module configuration of the cloud system of this embodiment.

[0040] A plurality of common containers 301 are introduced into the instances 111 to 114 in the cloud system 101, and one microservice 311 is executed on each common container 301.

[0041] In addition, for instances 111 to 114, a sidecar container 302 corresponding to each common container 301 is introduced, and various processes are executed on the sidecar container 302.

[0042] The DB server 116 stores application data 333 accessed by the microservice 311.

[0043] For instance 115, a tenant-specific individual container 341 is introduced, and an orchestrator 342 is executed on the individual container 341. The orchestrator 342 calls one or more microservices according to a workflow for service execution for each tenant and sequentially executes them.

[0044] In the control plane 121, a control middleware 351 for managing resources, containers, communications, etc. for providing multi-tenant services is introduced.

[0045] The main components of the control middleware 351 are a resource management unit 352, a container management unit 353, and a communication management unit 354.

[0046] The resource management unit 352 manages instances 111 to 115, the DB server 116, the load balancer 122, etc. within the cloud system 101. The container management unit 353 arranges and manages containers for instances 111 to 115. The communication management unit 354 manages communications within the cloud system 101.

[0047] The main components of the sidecar container 302 are an individual process storage unit 321, a process mediation unit 322, a request queue management unit 323, a service execution management unit 324, a request to other containers unit 325, a communication processing unit 326, and an interface unit 327.

[0048] The individual process storage unit 321 stores individual processes for each tenant.

[0049] The processing mediation unit 322 refers to the individual processing correspondence table 331 during the execution of microservices and assigns individual processing for each tenant.

[0050] The request queue management unit 323 manages a request queue 332 for storing service requests.

[0051] The service execution management unit 324 refers to the request queue 332 and manages the execution of individual processing for each tenant of the microservice 311 and the individual processing storage unit 321.

[0052] The other container request unit 325 creates a proxy execution request for a microservice or a resource occupancy right lending request for another sidecar container.

[0053] The communication processing unit 326 performs communication with other sidecar containers, the instance 115, the control plane 121, etc.

[0054] The interface unit 327 provides an interface to the common container 301 and the microservice 311.

[0055] FIG. 4 is a diagram for explaining a multi-tenant service providing method of the cloud system of this embodiment.

[0056] In the instance 115, individual containers 341a and 341b are introduced for each of the tenants 201a and 201b, and the orchestrators 342a and 342b are respectively executed on the individual containers 341a and 341b.

[0057] In the instances 111 to 114, the microservices 311a to 311d are executed. The microservices 311a to 311d perform, for example, explanatory variable generation, model construction, predicted value calculation, etc.

[0058] Orchestrators 342a and 342b sequentially call and execute the microservices 311a to 311d required for the power service according to the power service workflow for each tenant in order to provide a power service by a microservice combination for tenants 201a and 201b. The workflow defines the order of executing the microservices for providing the power service for each tenant and is held by each orchestrator 342a and 342b.

[0059] In each common container 301 including the microservices 311a to 311d which are common products independent of each tenant, a sidecar container 302 is installed in a paired form.

[0060] Each sidecar container 302 includes a processing mediation unit 322, an individual processing correspondence table 331, and a request queue 332.

[0061] The processing mediation unit 322 assigns individual processing for each tenant by referring to the individual processing correspondence table 331 when executing the microservice.

[0062] The individual processing correspondence table 331 introduces the individual processing for each tenant required for executing the microservices 311a to 311d as functions or libraries. When the microservices 311a to 311d are executed, the necessary individual processing is selected and executed by referring to the individual processing correspondence table 331.

[0063] Individual processing includes preprocessing when the input data varies for each tenant and postprocessing when the output format such as the predicted value varies for each tenant. Since the input data and output format may have different specifications for each tenant, a method of microservicing the necessary preprocessing and postprocessing separately when executing microservices can be considered. However, in this method, the number of microservice containers increases as the number of tenants increases. In this embodiment, by aggregating individual processing as the individual processing correspondence table 331 in the sidecar container 302, an increase in infrastructure costs due to an increase in the number of containers is suppressed.

[0064] The request queue 332 manages the service execution deadline, service execution status, processing standard time, etc. for each tenant.

[0065] The service execution management unit 324 refers to the information managed by the request queue 332 and, when the microservice for each tenant cannot be executed within the deadline, performs a rearrangement of the execution order so as to advance the execution order of the microservice.

[0066] In addition, when the service execution management unit 324 determines that it is difficult to execute the microservice 311a to be started next within the deadline due to processing delay, high load, etc. in the power service for a certain tenant, the other container request unit 325, first, requests the sidecar container 302 of the same type of microservice 311d operating in the other instance 112 to execute the processing of the microservice 311a as an alternative.

[0067] Since the same type of microservice 311d and its sidecar container 302 in the other instance 112 that has received the request are already in an executable state, if proxy execution of the processing is possible, the processing can be executed without waiting time.

[0068] If proxy execution is not possible with the same type of microservice 311d, the other container request section 325, secondly, requests the sidecar containers 302 of the heterogeneous microservices 311b and 311c in the same instance 111 to lend the resource occupancy right. If the sidecar containers 302 of the heterogeneous microservices 311b and 311c in the received instance 111 are able to lend the resource occupancy right, they will stop once.

[0069] In response to this, the sidecar container 302 of the requesting microservice 311a replicates the microservice 311a by itself and executes the processing of the corresponding microservice. Here, it is assumed that the resource occupancy right is the right to use the CPU resource in a state where the container can be preferentially executed within the instance. By lending the resource occupancy right between containers, processing can be executed within the limit of the CPU resources in the instance.

[0070] FIG. 5A is a diagram showing an example of the configuration of the individual processing correspondence table 331.

[0071] The individual processing correspondence table 331 stores information regarding the association of individual processing for each tenant with respect to the microservice, which is managed by the sidecar container 302.

[0072] The main components of the individual processing correspondence table 331 are individual processing identification information 411, tenant identification information 412, processing type 413, function call identification information 414, input source 415, output destination 416, and update date and time 417.

[0073] The individual processing identification information 411 stores information for identifying the individual processing for each tenant with respect to the microservice.

[0074] The tenant identification information 412 stores information for identifying the tenant to which the individual processing specified by the individual processing identification information 411 applies.

[0075] For processing type 413, information regarding the processing type of the individual processing specified by the individual processing identification information 411 is stored. For example, "pre - processing", "post - processing", etc. are stored.

[0076] For function call identification information 414, information for identifying the function or library to be called within the side - car container 302 to execute the individual processing specified by the individual processing identification information 411 is stored.

[0077] For input source 415, information regarding the input source of the individual processing specified by the individual processing identification information 411 is stored. For example, information such as reception from the outside, the micro - service, etc. is stored.

[0078] For output destination 416, information regarding the output destination of the individual processing specified by the individual processing identification information 411 is stored. For example, information such as the micro - service, transmission to the outside, etc. is stored. For update date and time 417, the date and time when the records of 411 - 416 were last updated is stored.

[0079] Figure 5B is a diagram showing an example of the configuration of the request queue 332.

[0080] The request queue 332 stores service requests for the micro - service. The request queue 332 is utilized for the execution order control of the micro - service by the service execution management unit 324.

[0081] The main components of the request queue 332 are order 421, request identification information 422, requesting tenant identification information 423, processing guideline time 424, execution deadline 425, execution availability 426, execution status 427, and update date and time 428.

[0082] For order 421, information regarding the execution order of the service requests stored in the request queue 332 is stored.

[0083] The request identification information 422 stores information for identifying the service request stored in the request queue 332.

[0084] The requesting tenant identification information 423 stores information for identifying the tenant of the service requester that is the basis of the service request specified by the request identification information 422.

[0085] The processing standard time 424 stores information regarding the standard time required for the execution of microservices and individual processes in the service request specified by the request identification information 422.

[0086] The execution deadline 425 stores information regarding the execution deadline by which the microservices and individual processes in the service request specified by the request identification information 422 should be completed.

[0087] The executability 426 stores information regarding the executability of the microservices and individual processes in the service request specified by the request identification information 422.

[0088] The execution status 427 stores information regarding the execution status of the microservices and individual processes in the service request specified by the request identification information 422. For example, information such as "executing", "waiting", "delayed", etc. is stored.

[0089] The update date and time 428 stores the date and time when the records of 421 to 427 were last updated.

[0090] Each piece of information stored in the request identification information 422, the requesting tenant identification information 423, the processing standard time 424, and the execution deadline 425 is included in the service request from the orchestrator 342.

[0091] Note that the service request priority may be associated with the request identification information 422, and the service execution management unit 324 may change the execution order so as to preferentially execute the service request with a higher priority.

[0092] FIG. 6 is a flowchart showing an example of processing in the sidecar container.

[0093] First, the sidecar container 302 determines whether it has received a message (S500). If the sidecar container 302 has not received a message in S500, the process proceeds to S504.

[0094] If the sidecar container 302 has received a message in S500, it determines the type of the received message (S501).

[0095] If the type of the message received in S501 is a service request from the orchestrator 342, information regarding the service request is stored in the request queue 332 (S502), and the process proceeds to S504.

[0096] If the type of the message received in S501 is a request message for micro-service proxy execution or resource occupancy right lending from another sidecar container, the request reception process described later with reference to FIG. 9 is executed to receive the request message (S503), and the process proceeds to S504.

[0097] In S504, the sidecar container 302 refers to the request queue 332.

[0098] Next, based on the request queue 332 referred to in S504, it is determined whether there is a micro-service scheduled for execution (S505). If there is no micro-service scheduled for execution in S505, the process returns to S500.

[0099] If there is a microservice scheduled to be executed in S505, check the execution status of the common container 301 of the microservice connected to the sidecar container 302 (S506).

[0100] Next, based on the execution status of the common container 301 of the microservice checked in S506, determine whether the microservice scheduled to be executed by the common container 301 of the microservice can be executed by the execution deadline (S507).

[0101] If the common container 301 of the microservice can execute the microservice scheduled to be executed by the execution deadline in S507, execute the service execution process shown in FIG. 7 described later (S508).

[0102] If the common container 301 of the microservice cannot execute the microservice scheduled to be executed by the execution deadline in S507, execute the request process shown in FIG. 8 described later, and request the sidecar container 302 of another microservice to execute the microservice on behalf or lend the resource occupancy right (S509).

[0103] FIG. 7 is a flowchart showing an example of the service execution process of S508 in FIG. 6.

[0104] First, in the sidecar container 302, refer to the individual processing correspondence table 331 (S601).

[0105] Next, based on the individual processing correspondence table 331 referred to in S601, determine whether there is preprocessing for the microservice connected to the sidecar container of the requesting tenant (S602).

[0106] If there is preprocessing for the microservice connected to the sidecar container of the requesting tenant in S602, extract the corresponding preprocessing function / library from the individual processing correspondence table 331, execute the preprocessing (S603), and proceed to S604.

[0107] If there is no pre - processing for the microservice to which the side - car container of the requesting tenant is to be connected in S602, proceed to S604.

[0108] In S604, execute the microservice to which the side - car container is to be connected.

[0109] Next, based on the individual - processing correspondence table 331 referred to in S601, determine whether there is post - processing for the microservice to which the side - car container of the requesting tenant is to be connected (S605).

[0110] If there is post - processing for the microservice to which the side - car container of the requesting tenant is to be connected in S605, extract the corresponding function / library of the post - processing from the individual - processing correspondence table 331, execute the post - processing (S606), and proceed to S607.

[0111] If there is no post - processing for the microservice to which the side - car container of the requesting tenant is to be connected in S605, proceed to S607.

[0112] In S607, output the processing result up to S606 to the output destination stored in the individual - processing correspondence table 331, and end this processing.

[0113] Figure 8 is a flowchart showing an example of the request - processing of S509 in Figure 6.

[0114] First, the side - car container 302 extracts information regarding the microservice to which the side - car container 302 it manages is to be connected (S701).

[0115] Next, using the information extracted in S701, create a request message for requesting proxy execution of the microservice to the side - car container of the same - type microservice (S702).

[0116] Next, the request message for micro-service proxy execution created at S702 is sent to the sidecar container of the same type of micro-service (S703).

[0117] Next, it is determined whether a response message indicating that micro-service proxy execution is possible is received from the sidecar container for the request message for micro-service proxy execution sent to the sidecar container of the same type of micro-service at S703 (S704).

[0118] If a response message indicating that micro-service proxy execution is possible is received at S704, this process ends.

[0119] If a response message indicating that micro-service proxy execution is possible is not received at S704, proceed to S705.

[0120] At S705, using the information extracted at S701, a request message for requesting the lending of resource occupancy rights is created to the sidecar container of the heterogeneous micro-service.

[0121] Next, the request message for lending resource occupancy rights created at S705 is sent to the sidecar container of the heterogeneous micro-service (S706).

[0122] Next, it is determined whether a response message indicating that lending of resource occupancy rights is possible is received from the sidecar container for the request message for lending resource occupancy rights sent to the sidecar container of the heterogeneous micro-service at S706 (S707).

[0123] If a response message indicating that lending of resource occupancy rights is possible is received at S707, this process ends.

[0124] If a response message indicating that resource occupancy right lending is possible is not received at S707, the service request is placed at the front of the request queue 332 (S708), and this process ends. As a result, the service request can be executed preferentially.

[0125] Note that when a response message indicating that resource occupancy right lending is possible is not received at S707, instead of the process of S708, this process may end as an error. In this case, the tenant may be notified that the service request cannot be executed by the execution deadline.

[0126] Also, the priority of the service request is associated with the request identification information 422 of the request queue 332 in FIG. 5B. The service request with a higher priority is placed at the front of the request queue 332 and executed preferentially. When a response message indicating that resource occupancy right lending is not possible is not received for the service request with a lower priority, it may be regarded as an error.

[0127] FIG. 9 is a flowchart showing an example of the request reception process of S503 in FIG. 6.

[0128] When the sidecar container 302 receives a request message from another sidecar container, it refers to the individual processing correspondence table 331, the request queue 332, etc., and checks the execution status of the microservice connected to the sidecar container 302 (S801).

[0129] Next, the sidecar container 302 determines the request type based on the request type information of the received request message (S802).

[0130] If the request type is a proxy execution request for a microservice at S802, it is determined whether proxy execution of the microservice is possible based on the execution status of the microservice confirmed at S801 (S803).

[0131] When it is possible to proxy-execute the microservice at S803, a response message indicating that microservice proxy execution is possible is sent to the sidecar container 302 of the requester (S806).

[0132] Next, the proxy execution of the requested microservice is added to the request queue 332, and the request queue 332 is updated (S807).

[0133] Next, the proxy execution of the corresponding microservice is started (S808), and this process ends.

[0134] When it is not possible to proxy-execute the microservice at S803, a response message indicating that microservice proxy execution is not possible is sent to the sidecar container 302 of the requester (S805), and this process ends.

[0135] When the request type at S802 is a resource occupancy right lending request, it is determined whether resource occupancy right lending is possible based on the execution state of the microservice confirmed at S801 (S804).

[0136] When resource occupancy right lending is possible at S804, the sidecar container 302 temporarily stops the common container 301 in which the microservice connected to the sidecar container 302 operates (S809).

[0137] Next, the execution state of the service request stopped at S809 is changed from "executing" to "waiting", and the request queue 332 is updated (S810).

[0138] Next, a response message indicating that resource occupancy right lending is possible is sent to the sidecar container 302 of the requester (S811), and this process ends.

[0139] When resource occupancy right lending is not possible at S804, a response message indicating that resource occupancy right lending is not possible is sent to the sidecar container 302 of the requester (S805), and this process ends.

[0140] FIG. 10A is a diagram showing an example of the configuration of a request message transmitted by the sidecar container 302 in the request process of FIG. 8.

[0141] The request message 901 is a message transmitted to other sidecar containers when the sidecar container 302 requests the proxy execution of a microservice or the lending of resource occupancy rights.

[0142] The main components of the request message 901 are communication header information 911, source information 912, request type information 913, message type information 914, and request information 915.

[0143] The communication header information 911 stores information necessary for the transmission and reception of the request message 901.

[0144] The source information 912 stores information about the sidecar container that is the source of the request message 901.

[0145] The request type information 913 stores information about the type of request by the request message 901. Here, either "proxy execution request" or "resource occupancy right lending request" is stored.

[0146] The message type information 914 stores information about the type of the message. Here, "request" is stored.

[0147] The request information 915 stores information about the content of the request of the type specified by the request type information 913. The main components of the request information 915 are request identification information 931, microservice information to be executed 932, start time of execution 933, estimated processing time 934, and tenant information 935.

[0148] The request identification information 931 stores information for identifying the request from the sidecar container 302.

[0149] The execution microservice information 932 stores information about the microservice to be executed for the request specified by the request identification information 931.

[0150] The execution start time 933 stores information about the scheduled start time of the execution of the microservice specified by the execution microservice information 932.

[0151] The expected processing time 934 stores information about the expected time required for the processing of the microservice specified by the execution microservice information 932.

[0152] The tenant information 935 stores information about the tenant of the service requester that is the basis of the request specified by the request identification information 931.

[0153] FIG. 10B is a diagram showing an example of the configuration of the response message transmitted by the sidecar container 302 in the request reception process of FIG. 9.

[0154] The response message 902 is a message transmitted to the sidecar container of the request source when the sidecar container 302 responds to the request message 901 received from the sidecar container of the request source.

[0155] The main components of the response message 902 are communication header information 921, source information 922, request type information 923, message type information 924, and response information 925.

[0156] The communication header information 921 stores information necessary for the transmission and reception of the message.

[0157] The source information 922 stores information about the sidecar container that is the source of the message.

[0158] The request type information 923 stores information about the type of the request that is the source of the response by the message. Here, either "proxy execution request" or "resource occupancy right lending request" is stored.

[0159] The message type information 924 stores information regarding the type of the message. Here, "response" is stored.

[0160] The response information 925 stores information regarding the content of the response to the request of the type specified by the request type information 923. The main components of the response information 925 are the request identification information 941, the feasibility of execution 942, and the execution start time 943.

[0161] The request identification information 941 stores information for identifying the request that serves as the basis for the response by the message.

[0162] The feasibility of execution 942 stores information regarding the response as to whether the request specified by the request identification information 941 is feasible.

[0163] The execution start time 943 stores information regarding the execution start time of the request process when the request specified by the request identification information 941 is feasible.

[0164] According to this embodiment, it is possible to reduce the cost of constructing and operating multi-tenant services in the cloud and ensure performance and timeliness.

[0165] For example, in a multi-tenant environment, when executing services by a microservice combination for each tenant, even if a processing delay of the microservice may occur due to an increase in the amount of input data or the like, by distributing the processing load to resources within a predetermined range, it is possible to prevent the influence from spreading to services for other tenants.

[0166] In addition, by introducing tenant-specific processing into the sidecar container, even when the number of tenants increases and the types of individual processing can increase, the number of containers required for execution can be reduced, and an increase in the cloud usage cost can be suppressed. By increasing common parts, it becomes easier to aggregate components, and the amount of resources at the time of scaling out can be optimized.

[0167] Note that the present invention is not limited to the above-described embodiments, and includes various modifications. For example, the above-described embodiments have been described in detail for easy understanding of the present invention, and are not necessarily limited to those having all the configurations described.

Explanation of Signs

[0168] 101 Cloud system 111~115 Instances 301 Common container 302 Sidecar container 311 Microservice 331 Individual processing correspondence table 332 Request queue 341 Individual container 342 Orchestrator

Claims

1. In a method for providing a multi-tenant service in a cloud system that provides services to a plurality of tenants, the cloud system includes: a plurality of common containers each having a microservice; a plurality of sidecar containers paired with each of the plurality of common containers; and a plurality of individual containers each having an orchestrator that sequentially calls and executes the microservices directed to each of the plurality of tenants. Each of the plurality of sidecar containers includes a request queue that holds a request for execution of the microservice from the orchestrator, and a method for providing a multi-tenant service that performs load distribution to other sidecar containers by referring to the request queue.

2. In the method for providing a multi-tenant service according to Claim 1, each of the plurality of sidecar containers further includes individual processing correspondence information directed to each of the plurality of tenants, and a method for providing a multi-tenant service that executes individual processing directed to a tenant by referring to the individual processing correspondence information when executing the microservice directed to the tenant.

3. In the method for providing a multi-tenant service according to Claim 2, the request queue has information on the execution order, execution deadline, execution status, and processing standard time of the microservice, and each of the plurality of sidecar containers changes the execution order of the microservice when it cannot execute the microservice by the execution deadline by referring to the request queue.

4. In the method for providing a multi-tenant service according to Claim 3, each of the plurality of sidecar containers transmits a request for proxy execution or a request for lending resource occupancy rights of the microservice to other sidecar containers when it cannot execute the microservice by the execution deadline by referring to the request queue.

5. In the method for providing a multi-tenant service according to Claim 4, each of the plurality of sidecar containers executes the microservice as a proxy by referring to the request queue and the individual processing correspondence information when receiving the request for proxy execution from other sidecar containers.

6. In the multi-tenant service providing method according to claim 4, In the multi-tenant service providing method, when each of the plurality of sidecar containers receives a resource occupancy right lending request from another of the sidecar containers, the common container paired with the sidecar container is stopped, and the microservice that is the source of the resource occupancy right lending request is replicated and executed.

7. In the multi-tenant service providing method according to claim 3, The request queue further has information on the priority of the microservice, In the multi-tenant service providing method, each of the plurality of sidecar containers changes the execution order with reference to the priority.

8. In a multi-tenant service providing system that provides services to a plurality of tenants, a plurality of common containers each having a microservice, a plurality of sidecar containers paired with each of the plurality of common containers, and a plurality of individual containers each having an orchestrator that sequentially calls and executes the microservices for each of the plurality of tenants, each of the plurality of sidecar containers, comprises a request queue for holding a request for execution of the microservice from the orchestrator, A multi-tenant service providing system that performs load distribution to other sidecar containers with reference to the request queue.

9. In the multi-tenant service providing system according to claim 8, each of the plurality of sidecar containers, further comprises individual processing correspondence information for each of the plurality of tenants, A multi-tenant service providing system that executes individual processing for a tenant with reference to the individual processing correspondence information when executing the microservice for the tenant.

10. In the multi-tenant service providing system according to claim 9, the request queue has information on the execution order, execution deadline, execution status, and processing standard time of the microservice, In the multi-tenant service providing system, when each of the plurality of sidecar containers cannot execute the microservice by the execution deadline with reference to the request queue, the execution order of the microservice is changed.

11. In the multi-tenant service providing system according to claim 10, In the multi-tenant service providing system, each of the plurality of sidecar containers refers to the request queue and, when it cannot execute the microservice by the execution deadline, sends a request for proxy execution of the microservice or a request for lending the resource occupancy right to another one of the sidecar containers.

12. In the multi-tenant service providing system according to Claim 11, each of the plurality of sidecar containers refers to the request queue and the individual processing correspondence information and proxy-executes the microservice when it receives the proxy execution request from another one of the sidecar containers.

13. In the multi-tenant service providing system according to Claim 11, each of the plurality of sidecar containers stops the common container paired with the sidecar container when it receives the resource occupancy right lending request from another one of the sidecar containers, and replicates and executes the microservice that is the source of the resource occupancy right lending request.

14. In the multi-tenant service providing system according to Claim 10, the request queue further has information on the priority of the microservice, and each of the plurality of sidecar containers changes the execution order with reference to the priority.

Images