Program, Information Processing Method, and Information Processing Apparatus

Abstract

To use an appropriate communication method in an environment where a plurality of different types of proxy containers coexist.SOLUTION: A container group 20 includes a proxy container 22 of type X. A container group 40 includes a proxy container 42 of type Y. A processing unit 12 acquires a reference delay time when transmitting a request from the proxy container 22 to a destination. The processing unit 12 calculates a delay time on the basis of the number of the requests for the case where a request of the container group 20 reaches the container group 40 via a container group 50 that relays communication between different types of proxy. The processing unit 12 sets up for transmitting a request to the container group 50 via the proxy container 22 when the delay time is smaller than the reference delay time, and adds a proxy container 23 of type Y to the container group 20 and sets up for transmitting a request to the container group 40 via the proxy container 23 when the delay time is greater than or equal to the reference delay time.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present invention relates to a program, an information processing method, and an information processing apparatus.

Background Art

[0002] One of the virtualization technologies in a computer is a technology called container virtualization. In container virtualization, a container that bundles resources such as libraries used for starting an application is defined as a software execution environment. For example, a node realized by a computer can form a container on the node by executing a container engine. The node may be a physical machine having resources such as a CPU (Central Processing Unit) and a RAM (Random Access Memory), or a virtual machine operating on a physical machine.

[0003] Containers may be used for the execution of applications developed by a method called microservices. In microservices, an application is developed by dividing it into services for each function. The node operates a plurality of services with a plurality of containers, and executes the application by the cooperation between the services. The network infrastructure used for the cooperation between the services is called a service mesh. A proxy arranged for each service is used in the service mesh. The proxy is also realized by a container. The node controls the communication between the services by transmitting the data of a certain service to another service via the proxy. For example, a container group that is a group of containers including a service container and a proxy container functioning as a proxy may be used as a single unit of deployment to the node.

[0004] Note that a method for determining a communication path by an overlay node belonging to an overlay network has been proposed. In this communication path determination method, the overlay node measures the communication quality from its own node to the destination node, and on the other hand, obtains the communication quality measurement result from the relay candidate node to the destination node from the relay candidate node. The overlay node compares the communication quality of both, and if the former is better, the path that directly transfers to the destination node without using the relay node is set as the communication path from its own node to the destination node. When the latter is better, the overlay node sets the communication path using the relay candidate node that provides the highest quality as the relay node.

[0005] In addition, a method that considers a plurality of QoS (Quality of Service) such as delay time and packet loss rate as the communication quality acquired by the overlay node has also been proposed.

Prior Art Documents

Patent Documents

[0006]

Patent Document 1

Patent Document 2

Summary of the Invention

Problems to be Solved by the Invention

[0007] There are multiple types of proxy containers. The type of proxy container used for a certain service is selected according to, for example, the development framework used in the development of the service.

[0008] Therefore, the types of proxy containers used may differ between one container group and another. If the types of proxy containers are different, the protocols used for communication will be different, and communication between the two container groups will become impossible. Thus, in order to implement a service mesh in a system where multiple types of proxy containers coexist, for example, the following methods can be considered.

[0009] The first method is to separately provide a container group that functions as a gateway. The gateway relays communication between different types of proxy containers by converting the protocol used by one type of proxy container into the protocol used by the other type of proxy container.

[0010] The second method is to coexist multiple types of proxy containers in a container group that includes service containers. In this case, the container group of the request source selectively uses multiple types of proxy containers it has according to the type of proxy container used in the destination container group.

[0011] However, in the first method, although the amount of consumed resources can be suppressed compared to the second method, there is a problem that the communication delay may increase due to the relay processing at the gateway. On the other hand, in the second method, since there is no gateway, the communication delay is suppressed compared to the first method, but the consumed resources per container group increase, and the amount of consumed resources may become excessive as the number of deployed container groups increases.

[0012] In one aspect, the present invention aims to enable the use of an appropriate communication method in an environment where multiple types of proxy containers coexist.

Means for Solving the Problem

[0013] In one aspect, a program is provided. This program is for an information processing system that executes a plurality of container groups including a container group to which a plurality of containers including a proxy container used for communication with other container groups belong, the plurality of container groups including a first container group having a first type of proxy container and a second container group having a first proxy container of a second type. The program causes a computer to execute a process of obtaining a first delay time, which is a reference delay time when a request is transmitted from the first container group to a destination container group by the first type of proxy container, calculating a second delay time when a request from the first container group reaches the second container group via a third container group that relays communication between proxy containers of different types, setting to transmit a request from the first container group to the second container group to the third container group via the first type of proxy container when the second delay time is less than the first delay time, adding a second proxy container of the second type to the first container group when the second delay time is greater than or equal to the first delay time, and setting to transmit a request from the first container group to the second container group to the second container group via the second proxy container.

[0014] Also, in one aspect, an information processing method is provided. Also, in one aspect, an information processing apparatus having a storage unit and a processing unit is provided.

Advantages of the Invention

[0015] In one aspect, an appropriate communication method can be used in an environment where multiple types of proxy containers coexist.

Brief Description of the Drawings

[0016]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18

Figure 19

Figure 20

Figure 21

Figure 22

Figure 23

Figure 24

Figure 25

Embodiments for Carrying Out the Invention

[0017] Hereinafter, the present embodiment will be described with reference to the drawings. [First Embodiment] The first embodiment will be described.

[0018] FIG. 1 is a diagram for explaining an information processing apparatus according to the first embodiment. The information processing apparatus 10 manages communication between container groups executed in the information processing system 1. The information processing apparatus 10 includes a storage unit 11 and a processing unit 12. The storage unit 11 may be a volatile storage device such as a RAM, or a non-volatile storage device such as an HDD (Hard Disk Drive) or a flash memory. The processing unit 12 may include a CPU, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), etc. The processing unit 12 may be a processor that executes a program. The "processor" may be a set of multiple processors (multi-processor). The information processing apparatus 10 may be included in the information processing system 1.

[0019] The information processing system 1 executes an application developed by the microservices approach. The information processing system 1 has one or more nodes and operates a plurality of containers on one or more nodes. Nodes are omitted in FIG. 1. A node may be a physical machine or a virtual machine operating on a physical machine. The information processing system 1 executes a plurality of services by a plurality of containers. The information processing system 1 executes an application by coordinating a plurality of services via a proxy container. The unit of service deployment to a node in the information processing system 1 is a container group including a container that executes a service and a proxy container.

[0020] Here, in the information processing system 1, a container orchestration tool for performing integrated management of containers is used. The container orchestration tool is software that performs scheduling such as creation and deletion of containers, cluster management of containers, and determination of container deployment destination nodes. An example of the container orchestration tool is Kubernetes (registered trademark). Kubernetes is abbreviated as K8s. For example, in K8s, a container group called a pod is a deployment unit to a node. However, the information processing system 1 may use something other than K8s as the container orchestration tool. Also, the proxy container may be called a sidecar container or simply a sidecar. The information processing system 1 executes container groups 20, 30, and 40.

[0021] The container group 20 has a container 21 and a proxy container 22. The container 21 executes the first service. The type of the proxy container 22 is X. The container group 30 has a container 31 and a proxy container 32. The container 31 executes the second service. The type of the proxy container 32 is X.

[0022] The container group 40 has a container 41 and a proxy container 42. The container 41 executes a third service. The type of the proxy container 42 is Y. In this way, in the information processing system 1, multiple types of proxy containers coexist. For example, multiple types of proxy containers on K8s include an Istio Envoy sidecar, a Linkerd sidecar, and a Dapr sidecar.

[0023] Two proxy containers can communicate directly if they are of the same type. Two proxy containers cannot communicate directly if they are of different types. This is because the protocols such as encryption used for communication are different. In the case of the above example, the proxy containers 22 and 32 are both of type X. Therefore, the proxy containers 22 and 32 can communicate directly.

[0024] On the other hand, the proxy container 22 is of type X, while the proxy container 42 is of type Y, and their types are different. Therefore, the proxy containers 22 and 42 cannot communicate directly. To realize the cooperation between the container groups 20 and 40, the processing unit 12 can use the following method.

[0025] The first method is to provide the information processing system 1 with a container group 50 that functions as a gateway. The container group 50 has proxy containers 51 and 52. The type of the proxy container 51 is X. The type of the proxy container 52 is Y. The container group 50 receives a request from the proxy container 22 by the proxy container 51. The container group 50 transfers the request from the proxy container 52 to the proxy container 42.

[0026] The second method is to provide the container group 20 with a proxy container 23 of type Y and coexist it with the proxy container 22 of type X. The container group 20 can communicate directly with the proxy container 42 of the container group 40 by the proxy container 23.

[0027] In the first method, the amount of consumed resources can be suppressed compared to the second method, but communication may be delayed due to the relay process by the gateway. On the other hand, in the second method, the delay of communication is reduced compared to the first method, but the resources consumed per container group increase, and the amount of consumed resources may become excessive according to the increase in the number of deployed container groups.

[0028] Therefore, the processing unit 12 selectively uses the first method and the second method as follows. The processing unit 12 performs the following processing at the timing when the container group 20 or another container group is newly deployed or at a predetermined cycle. When the container group 20 is newly deployed, in the information processing system 1, a container group that executes the same service as the container group 20 may already be executed. In this case, a part of the load of the executed container group is allocated to the newly deployed container group 20. Also, when another container group that executes the same service as the existing container group 20 is newly deployed, a part of the load of the executed container group 20 is allocated to the newly deployed other container group.

[0029] The processing unit 12 acquires a first delay time, which is a reference delay time when transmitting a request from the container group 20 to the destination container group using the proxy container 22. The processing unit 12 stores the first delay time in the storage unit 11.

[0030] For example, the processing unit 12 may acquire the first delay time by accepting an input of the first delay time by the user. Also, the delay time of communication by the proxy container changes in proportion to the number of requests transmitted by the proxy container per unit time. Therefore, the processing unit 12 may calculate the first delay time based on the delay time T with respect to a predetermined number of requests A transmitted per unit time, which is publicly available for the proxy container of type X.

[0031] More specifically, first, the processing unit 12 acquires the total number of requests B sent by the proxy container 22 per unit time. The processing unit 12 may calculate the total number of requests B based on the number of requests in a recent predetermined period sent by the container group 20. Note that the processing unit 12 can acquire the number of requests sent from each proxy container to the destination proxy container using existing distributed tracing technologies. For example, tools that provide distributed tracing include Jaeger and Zipkin.

[0032] Also, when the processing unit 12 newly deploys another container group that executes the same service as the container group 20, the processing unit 12 calculates the total number of requests B considering that a part of the number of requests of the container group 20 will be allocated to other container groups. In one example, the processing unit 12 can calculate the total number of requests B by proportionally dividing the number of requests in a recent predetermined period in the container group 20 between the container group 20 and another container group to be newly deployed. Also, when newly deploying the container group 20, the processing unit 12 may calculate the total number of requests B based on the number of requests in a recent predetermined period sent by the proxy container belonging to an existing container group that executes the same service as the container group 20.

[0033] Based on the total number of requests B, the processing unit 12 calculates the delay time τ when directly sending a request from the proxy container 22 to the proxy container of type X as τ = (B / A)*T. The processing unit 12 may use the delay time τ as the first delay time. Alternatively, the processing unit 12 may use a value obtained by multiplying the delay time τ by a predetermined coefficient α as the first delay time. For example, the coefficient α may be a value greater than 1.

[0034] Next, when a request from the proxy container 22 reaches the container group 40 via the container group 50, the processing unit 12 calculates a second delay time based on the number of requests from the container group 20 to the container group 40. As described above, the delay time corresponding to a predetermined number of requests per unit time in the proxy container of type X and the delay time corresponding to a predetermined number of requests per unit time in the proxy container of type Y are publicly available. Therefore, the processing unit 12 calculates the delay time generated in each of the proxy containers 22, 51, and 52 based on the number of requests from the container group 20 to the container group 40 and the publicly available delay times for the proxy containers 22, 51, and 52. The processing unit 12 sets the sum of the delay times generated in each of the proxy containers 22, 51, and 52 as the second delay time. By calculating the delay time based on the number of requests, the processing unit 12 can appropriately obtain the delay time even when it is difficult to directly measure the delay time corresponding to the processing within each proxy container.

[0035] Then, the processing unit 12 compares the first delay time and the second delay time, and selects whether to use the first method or the second method according to the result of the comparison. Specifically, when the second delay time is smaller than the first delay time, the processing unit 12 sets the information processing system 1 to send requests from the container group 20 to the container group 40 to the container group 50 via the proxy container 22.

[0036] That is, when the second delay time is smaller than the first delay time, the processing unit 12 selects a first method of transmitting a request from the container group 20 to the container group 40 via the gateway, and performs a routing setting for using the first method. In one example, the processing unit 12 adds a rule that sets the transfer destination of a request destined for the container group 40 to the proxy container 51 to a predetermined table that the proxy container 22 has and that holds transfer destination information. As a result, a request from the container group 20 to the container group 40 reaches the container group 40 via the container group 50.

[0037] Note that the proxy container 23 may already exist in the container group 20. In this case, the processing unit 12 deletes the proxy container 23 from the container group 20. That is, the processing unit 12 redeploys the container group 20 after deleting the proxy container 23. Also, when the container group 50 used as the gateway is not deployed, the processing unit 12 newly deploys the container group 50.

[0038] On the other hand, when the second delay time is equal to or greater than the first delay time, the processing unit 12 adds the proxy container 23 to the container group 20. Specifically, the processing unit 12 redeploys the container group 20 after adding the proxy container 23. Then, the processing unit 12 sets the information processing system 1 to transmit a request from the container group 20 to the container group 40 to the container group 40 via the proxy container 23.

[0039] That is, when the second delay time is equal to or greater than the first delay time, the processing unit 12 selects a second method of directly transmitting a request from the container group 20 to the container group 40 using the proxy container 23 of type Y. Then, the processing unit 12 performs a routing setting for using the second method. In one example, the processing unit 12 adds a rule that sets the transfer destination of a request destined for the container group 40 to the proxy container 42 to a predetermined table that the proxy container 23 has and holds transfer destination information. Further, the processing unit 12 adds a rule that sets the transfer destination of a request destined for the container group 40 from the container 21 to the proxy container 23 to routing setting information such as iptables that the container group 20 has. As a result, a request from the container group 20 to the container group 40 reaches the container group 40 directly without passing through the container group 50.

[0040] According to the information processing apparatus 10, for the information processing system 1, a first delay time, which is a reference delay time when sending a request from the first container group to the destination container group using a first type of proxy container, is acquired. The first delay time is stored in the storage unit 11. A second delay time when the request from the first container group reaches the second container group via the third container group is calculated based on the number of requests from the first container group to the second container group. The third container group functions as a gateway for relaying communication between proxy containers of different types. When the second delay time is smaller than the first delay time, a setting is made to send a request from the first container group to the second container group via the third container group through the first type of proxy container. When the second delay time is greater than or equal to the first delay time, a second proxy container of a second type is added to the first container group. Further, a setting is made to send a request from the first container group to the second container group via the second proxy container. Note that the container group 20 is an example of the first container group. The container group 40 is an example of the second container group. The container group 50 is an example of the third container group.

[0041] Thereby, the information processing apparatus 10 can use an appropriate communication method in an environment where multiple types of proxy containers coexist. Specifically, it is as follows. When the second delay time is smaller than the first delay time serving as a reference, even if communication is performed via the gateway, the communication quality expected for the information processing system 1 will be satisfied. Therefore, in this case, the processing unit 12 can suppress the amount of consumed resources by setting the request from the container group 20 to the container group 40 to pass through the gateway, that is, via the container group 50.

[0042] On the other hand, when the second delay time is equal to or longer than the reference first delay time, the communication quality expected of the information processing system 1 will not be met in communication via the gateway. Therefore, in this case, the processing unit 12 can suppress the delay time by directly transmitting the request from the container group 20 to the container group 40 without going through the gateway, that is, the container group 50.

[0043] In this way, by comparing the first delay time and the second delay time, the processing unit 12 can select whether to route the request to a different proxy container via the gateway or to transmit it directly, thereby achieving both suppression of the delay time and suppression of the amount of consumed resources.

[0044] Hereinafter, a more specific example will be used to explain the functions of the information processing apparatus 10 in more detail. [Second Embodiment] Next, a second embodiment will be described.

[0045] FIG. 2 is a diagram showing a hardware example of the information processing system according to the second embodiment. The information processing system 2 executes an application developed using the microservices approach. The information processing system 2 executes a plurality of containers that realize a plurality of services in the application. For example, the information processing system 2 executes K8s as a container orchestration tool. The information processing system 2 may use other container orchestration tools such as Apache Mesos (Apache is a registered trademark).

[0046] The information processing system 2 includes a management server 100, a master node 200, and worker nodes 300, 400, and 500. The management server 100, the master node 200, and the worker nodes 300, 400, and 500 are connected to a network 60. The network 60 is, for example, a LAN (Local Area Network). For example, the network 60 may be connected to an external network such as a WAN (Wide Area Network) or the Internet. The information processing system 2 may make an application executed by the information processing system 2 available to a client computer (not shown) via the external network.

[0047] The management server 100 is a server computer that manages a communication method between pods having different sidecars operating on each worker node. The sidecar is an example of a proxy container. A pod is a unit of container deployment for a worker node and is an example of a container group. Note that the service of an application realized by a container on an individual pod may be called a "microservice". The management server 100 is an example of the information processing apparatus 10 in the first embodiment.

[0048] The master node 200 is a server computer that performs cluster management of containers, provides an API (Application Programming Interface) for cooperation with each worker node, schedules container deployment to each worker node, and manages a DB (DataBase).

[0049] The worker nodes 300, 400, and 500 are server computers that execute containers. The worker nodes 300, 400, and 500 communicate with the master node 200 and control the containers.

[0050] FIG. 3 is a diagram showing a hardware example of the management server. The management server 100 includes a CPU 101, a RAM 102, an HDD 103, a GPU (Graphics Processing Unit) 104, an input interface 105, a media reader 106, and a NIC (Network Interface Card) 107. Note that the CPU 101 is an example of the processing unit 12 in the first embodiment. The RAM 102 or the HDD 103 is an example of the storage unit 11 in the first embodiment.

[0051] The CPU 101 is a processor that executes program instructions. The CPU 101 loads at least a part of the programs and data stored in the HDD 103 into the RAM 102 and executes the programs. Note that the CPU 101 may include a plurality of processor cores. Also, the management server 100 may have a plurality of processors. The processes described below may be executed in parallel using a plurality of processors or processor cores. Also, a collection of a plurality of processors may be referred to as a "multiprocessor" or simply a "processor".

[0052] The RAM 102 is a volatile semiconductor memory that temporarily stores programs executed by the CPU 101 and data used by the CPU 101 for calculations. Note that the management server 100 may include other types of memory than RAM, or may include a plurality of memories.

[0053] The HDD 103 is a non-volatile storage device that stores software programs such as an OS (Operating System), middleware, and application software, as well as data. Note that the management server 100 may include other types of storage devices such as flash memory and SSD (Solid State Drive), or may include a plurality of non-volatile storage devices.

[0054] The GPU 104 outputs an image to the display 61 connected to the management server 100 according to the instructions from the CPU 101. As the display 61, any type of display such as a CRT (Cathode Ray Tube) display, a liquid crystal display (LCD), a plasma display, or an organic EL (OEL: Organic Electro-Luminescence) display can be used.

[0055] The input interface 105 acquires an input signal from the input device 62 connected to the management server 100 and outputs it to the CPU 101. As the input device 62, a pointing device such as a mouse, a touch panel, a touch pad, or a trackball, a keyboard, a remote controller, a button switch, etc. can be used. Also, a plurality of types of input devices may be connected to the management server 100.

[0056] The media reader 106 is a reading device that reads programs and data recorded on the recording medium 63. As the recording medium 63, for example, a magnetic disk, an optical disk, a magneto-optical disk (MO), a semiconductor memory, etc. can be used. The magnetic disk includes a flexible disk (FD) and an HDD. The optical disk includes a CD (Compact Disc) and a DVD (Digital Versatile Disc).

[0057] The media reader 106, for example, copies the programs and data read from the recording medium 63 to other recording media such as the RAM 102 and the HDD 103. The read program is executed, for example, by the CPU 101. Note that the recording medium 63 may be a portable recording medium and may be used for the distribution of programs and data. Also, the recording medium 63 and the HDD 103 may be referred to as computer-readable recording media.

[0058] NIC107 is an interface that is connected to network 60 and communicates with other computers via network 60. NIC107 is connected by cable to a communication device such as a switch or router, for example.

[0059] Master node 200 and worker nodes 300, 400, 500 are also realized by the same hardware as management server 100. However, management server 100, master node 200, and worker nodes 300, 400, 500 may be realized by a plurality of virtual machines operating on one or more physical machines having a CPU and RAM.

[0060] Figure 4 is a diagram showing an example of control of worker nodes by a master node. Master node 200 has a management data storage unit 210 and a service control unit 220. For the management data storage unit 210, a storage area such as the RAM or HDD of master node 200 is used. The service control unit 220 is realized by the CPU of master node 200 executing a program stored in the RAM of master node 200.

[0061] Worker node 300 has an agent 310 and a pod 600. Agent 310 and pod 600 are realized by the CPU of worker node 300 executing a program stored in the RAM of worker node 300.

[0062] Worker node 400 has an agent 410 and a pod 700. Agent 410 and pod 700 are realized by the CPU of worker node 400 executing a program stored in the RAM of worker node 400.

[0063] Agents 310, 410 start pods on their own nodes according to the instructions of master node 200. Also, agents 310, 410 monitor the status of their own nodes and notify master node 200. Agents 310, 410 are called kubelet.

[0064] Although illustration is omitted, the worker node 500 also executes an agent and pods, similar to the worker nodes 300 and 400. Each of the worker nodes 300, 400, and 500 can execute a plurality of pods.

[0065] The service control unit 220 communicates with the agent 310 and instructs the deployment and startup of the pod 600 on the worker node 300. Also, the service control unit 220 may communicate with the agent 310 and instruct the stop or deletion of the pod 600 operating on the worker node 300. Note that the deployment of a pod to a worker node is sometimes referred to as deployment. Also, the deletion of a pod from a worker node is sometimes referred to as undeployment.

[0066] The service control unit 220 communicates with the agent 410 and instructs the deployment and startup of the pod 700 on the worker node 400. Also, the service control unit 220 may communicate with the agent 410 and instruct the stop or deletion of the pod 700 operating on the worker node 400.

[0067] Here, the pod 600 has a container 610 and a sidecar 620. The pod 700 has a container 710 and a sidecar 720. The containers 610 and 710 are components that bundle together application programs, libraries, etc. Each of the containers 610 and 710 realizes one service.

[0068] The sidecar 620 is a component that functions as a proxy for communicating the pod 600 with other pods. The sidecar 620 is also realized as a container. The sidecar 720 also functions as a proxy for communicating with other pods, similar to the sidecar 620.

[0069] In addition, the service control unit 220 uses existing distributed tracing technology to obtain the average value of the number of requests per unit time sent from each sidecar to the destination sidecar, and stores it in the management data storage unit 210. Examples of distributed tracing tools executed in the information processing system 2 include Jaeger and Zipkin.

[0070] The management server 100 inputs commands to the master node 200 to instruct the deployment and startup of pods in the worker nodes 300, 400, and 500, or to obtain the information held in the management data storage unit 210. For example, the management data storage unit 210 holds information such as the measured values of the number of requests between sidecars obtained by the service control unit 220 from each worker node. For example, a kubectl command is used as the command input from the management server 100 to the master node.

[0071] FIG. 5 is a diagram showing an example of communication between pods. For example, the pod 600 communicates with the pod 600x using the sidecar 620. The pod 600x has the container 610x and the sidecar 620x. For example, when a request is sent from the container 610 to the container 610x, the container 610 transfers the request to the sidecar 620. The sidecar 620 identifies the destination of the request, that is, the IP (Internet Protocol) address of the sidecar 620x, and based on the IP address, sends the request to the sidecar 620x. The sidecar 620x transfers the received request to the container 610x.

[0072] The transfer destination information (e.g., the IP address of the transfer destination) according to the destination of the request by the sidecars 620 and 620x is provided from the control plane 70 to the sidecars 620 and 620x. The control plane 70 is realized by a container and operates in each of the worker nodes 300, 400, and 500.

[0073] For the control plane 70, the layer of the sidecars 620, 620x is called the data plane 71. The control plane 70 and the data plane 71 realize a service mesh. The service mesh performs communication control between services, such as encryption by mTLS (mutual-TLS), load balancing, and distributed tracing.

[0074] Software that provides a service mesh on K8s includes, for example, Istio, Linkerd, and Dapr. Cloud services that provide a service mesh on K8s include AWS (registered trademark) App Mesh and GCP Anthos (registered trademark). GCP is an abbreviation for Google Cloud Platform. Google is a registered trademark.

[0075] The type of service mesh, that is, the type of sidecar used, is selected according to the development framework used for service development. For this reason, in the information processing system 2, different types of sidecars can coexist.

[0076] FIG. 6 is a diagram showing an example of communication availability according to the type of sidecar. For example, let the service name of the container 610 be App1. Assume that the sidecar 620 is an Istio sidecar, that is, an Envoy sidecar. Also, let the service name of the container 710 be App2. Assume that the sidecar 720 is a Dapr sidecar. In this case, the control plane 70 for the sidecar 620 is the Istio control plane. For the Dapr sidecar 720, the Dapr control plane is executed on each node.

[0077] Also, the pod 800 operating in the information processing system 2 has a container 810 and a sidecar 820. Let the service name of the container 810 be App3. The sidecar 820 is an Istio sidecar.

[0078] Sidecars of the same type can communicate directly. For example, sidecars 620 and 820 are both Istio sidecars and are sidecars of the same type. Therefore, sidecars 620 and 820 can communicate directly.

[0079] On the other hand, sidecars of different types cannot communicate directly because the protocols for communication such as encryption are different. For example, sidecar 620 is an Istio sidecar, while sidecar 720 is a Dapr sidecar. That is, sidecars 620 and 720 are sidecars of different types. Therefore, sidecars 620 and 720 cannot communicate directly.

[0080] To enable cooperation between pods that cannot communicate directly, the following two communication methods can be considered. The first method is to provide a pod that functions as a gateway (GW: Gateway) to relay communication between sidecars of different types and perform communication between sidecars of different types via the GW. The second method is to coexist a sidecar of a different type from the original sidecar in the pod that is the source of the request and use it to send requests to sidecars of different types.

[0081] Figure 7 is a diagram showing an example of communication via the GW. The gateway 900 relays the communication of pods 600 and 700. The gateway 900 has sidecars 910 and 920. The sidecar 910 is an Istio sidecar. The sidecar 920 is a Dapr sidecar. The gateway 900 converts the communication protocol of the Istio sidecar to the communication protocol of the Dapr sidecar by sending the request received by the sidecar 910 from the sidecar 920. Alternatively, the gateway 900 converts the communication protocol of the Dapr sidecar to the communication protocol of the Istio sidecar by sending the request received by the sidecar 920 from the sidecar 910. The information about the destination of the request transfer (e.g., the IP address of the destination) according to the destination of the request is provided to the gateway 900 by the control plane of the worker node that operates the gateway 900. The gateway 900 may further have a container that performs the process of converting the communication protocol of the Dapr sidecar to the communication protocol of the Istio sidecar.

[0082] The sidecar 620 can communicate with the pod 700 without providing a Dapr sidecar to the pod 600 by sending a request to the pod 700 to the gateway 900. Note that the sidecar 620 directly sends a request to the pod 800 to the sidecar 820.

[0083] FIG. 8 is a diagram showing an example of communication due to the coexistence of different types of sidecars. For example, in addition to the container 610 and the sidecar 620, a sidecar 630 is provided to the pod 600. The sidecar 630 is a Dapr sidecar. Therefore, the sidecars 630 and 720 can communicate directly. In this case, the container 610 can send a request to the pod 700 by transferring a request to the pod 700 to the sidecar 630. For a request to the pod 800, the container 610 can send the request to the pod 800 by transferring it to the sidecar 620.

[0084] In this way, it is conceivable to enable communication between pods having different types of sidecars by the above two communication methods. However, in the communication method via the GW, although the amount of consumed resources can be suppressed compared to the communication method that allows heterogeneous sidecars to coexist, there is a possibility that communication may be delayed due to the relay processing by the gateway 900. On the other hand, in the communication method that allows heterogeneous sidecars to coexist, the communication delay is reduced compared to the communication method via the GW, but the resources consumed per container group increase, and the amount of consumed resources may become excessive as the number of deployed container groups increases. Also, the control plane 70 also increases the amount of consumed resources according to the number of sidecars to be controlled. For example, the amount of resources consumed by the control plane 70 for the execution of 1000 services and 2000 sidecars is about 1 CPU and 1.5 GB of memory. Note that the CPU assigned to each pod or the control plane 70 may be a virtual CPU (vCPU: virtual CPU).

[0085] Therefore, the management server 100 provides a function of selectively using the communication method via the GW and the communication method that allows heterogeneous sidecars to coexist. FIG. 9 is a diagram showing a functional example of the management server.

[0086] The management server 100 includes a storage unit 110, a reference delay time calculation unit 120, a delay time calculation unit 130, and a setting change processing unit 140. For the storage unit 110, the storage areas of the RAM 102 and the HDD 103 are used. The reference delay time calculation unit 120, the delay time calculation unit 130, and the setting change processing unit 140 are realized by the CPU 101 executing the programs stored in the RAM 102.

[0087] The memory unit 110 stores performance information published by the provider of the respective sidecar regarding the delay time due to the processing of various sidecars. The performance information includes, for each of the various sidecars, information on the delay time corresponding to a predetermined number of requests per unit time. The performance information can be obtained, for example, from the web page of the provider vendor of the corresponding sidecar. In this example, the unit time is set to 1 second. The memory unit 110 stores the information on the reference delay time calculated by the reference delay time calculation unit 120 based on the performance information. Further, the memory unit 110 stores the information on the delay time calculated for each sidecar with respect to the current number of requests.

[0088] The reference delay time calculation unit 120 calculates the reference delay time related to the request transmission of each pod based on the information on the delay time corresponding to a predetermined number of requests per second included in the performance information. Note that the number of requests per second indicates the number of requests per second. The delay time due to communication by the sidecar increases in proportion to the number of requests per second to be transmitted. The reference delay time calculation unit 120 calculates, for a certain pod, the delay time when transmitting at the current number of requests per second using the original single sidecar as the reference delay time for the pod.

[0089] The delay time calculation unit 130 calculates the delay time when transmitting the request via the GW based on the number of requests per second that each pod transmits to different sidecars. When transmitting the request via the GW, the delay time calculation unit 130 calculates the delay time in the case of transmission via the GW by adding the delay time in the sidecar of the pod that is the request transmission source and the delay times in the sidecars 910 and 920 of the gateway 900 respectively.

[0090] The setting change processing unit 140 compares, for each pod, the reference delay time calculated by the reference delay time calculation unit 120 with the delay time calculated by the delay time calculation unit 130, and selects a communication method to be used for transmitting a request to a different type of sidecar from the corresponding pod. When the delay time in the case of passing through the GW is smaller than the reference delay time, the setting change processing unit 140 selects the communication method via the GW. On the other hand, when the delay time in the case of passing through the GW is equal to or greater than the reference delay time, the setting change processing unit 140 selects a communication method that allows different types of sidecars to coexist. The setting change processing unit 140 instructs the master node 200 to change the configuration of the pod according to the selected communication method. As will be described later, changing the configuration of the pod involves adding a new sidecar or deleting an existing sidecar. For example, the setting change processing unit 140 changes the image data corresponding to the pod 600 held by the master node 200 according to the addition of a new sidecar or the deletion of an existing sidecar for the pod 600. The image data is used by the master node 200 for deploying the pod 600.

[0091] Also, when selecting to pass through the GW for transmitting a request from the pod 600 to the pod 700, the setting change processing unit 140 performs routing setting for transmitting the request to the gateway 900 in the pod 600. As will be described later, the setting change processing unit 140 may separately provide an Istio sidecar for transmitting a request via the GW in the pod 600, separately from the sidecar 620.

[0092] Also, when selecting coexistence of different types of sidecars for transmitting a request from the pod 600 to the pod 700, the setting change processing unit 140 adds the sidecar 630 to the pod 600. Then, the setting change processing unit 140 performs routing setting for transmitting a request from the pod 600 to the pod 700 using the sidecar 630 in the pod 600.

[0093] For example, when a new pod is added to a worker node or at a predetermined period, the setting change processing unit 140 performs setting of the communication method used by the new pod or re - setting of the communication method used by the existing pod. The predetermined period is, for example, one hour or one day. By re - setting the communication method, for the existing pod, it may be changed from the communication method via the GW to the communication method that co - exists with heterogeneous sidecars, or conversely, from the communication method that co - exists with heterogeneous sidecars to the communication method via the GW.

[0094] In addition, when changing the communication method according to the selection of communication via the GW and co - existence of heterogeneous sidecars, it involves configuration changes such as adding a sidecar to a pod or deleting a sidecar from a pod. In this case, the setting change processing unit 140 instructs the master node 200 to perform procedures such as re - deployment of the pod, that is, undeployment of the pod and deployment of the pod after configuration change. For example, when there are multiple pods that execute the same service, the setting change processing unit 140 may perform rolling update or blue - green deployment to re - deploy the pod without stopping the service.

[0095] FIG. 10 is a diagram showing an example of a sidecar information table. The sidecar information table 111 is stored in advance in the storage unit 110. The sidecar information table 111 is performance information published by the providers of various sidecars. The sidecar information table 111 includes items of sidecar type, item name, and value. In the item of sidecar type, the type of sidecar is registered. In the item of item name, the item name of performance is registered. In the item of value, the performance value is registered.

[0096] For example, the sidecar information table 111 has a record with sidecar type "Istio", item name "resource usage at 1000 req / s", and value "CPU: 0.35, memory: 40MB". This record indicates that in the Istio sidecar, when the number of requests sent per second is 1000, 0.35 CPUs and 40MB (Mega Bytes) of memory are used.

[0097] Also, the sidecar information table 111 has a record with sidecar type "Istio", item name "latency at 1000 req / s", and value "2.65ms". This record indicates that in the Istio sidecar, when the number of requests sent per second is 1000, a latency of 2.65ms (milliseconds) occurs.

[0098] Also, the sidecar information table 111 has a record with sidecar type "Dapr", item name "resource usage at 1000 req / s", and value "CPU: 0.48, memory: 23MB". This record indicates that in the Dapr sidecar, when the number of requests sent per second is 1000, 0.48 CPUs and 23MB of memory are used.

[0099] Also, the sidecar information table 111 has a record with sidecar type "Dapr", item name "latency at 1000 req / s", and value "1.40ms". This record indicates that in the Dapr sidecar, when the number of requests sent per second is 1000, a latency of 1.40ms occurs.

[0100] For sidecars of types other than Istio and Dapr, information on resource usage and latency time publicly disclosed by the sidecar provider can also be registered in the sidecar information table 111.

[0101] Figure 11 is a diagram showing an example of a request number table. The request count table 112 is information in which the average value of the number of requests per unit time (requests per second) sent from the source service to the destination service is recorded. The information in the request count table 112 is acquired from the master node 200 by the reference delay time calculation unit 120 and stored in the storage unit 110.

[0102] The request count table 112 includes items for the source, destination, and requests per second. In the item for the source, the identification name of the service in the source pod is registered as the identification information of the source pod. In the item for the destination, the identification name of the service in the destination pod is registered. In the item for requests per second, the average value of the number of requests sent per second from the source to the destination is registered. The average value is obtained, for example, based on the number of requests sent from the source to the destination in a recent predetermined period.

[0103] For example, the request count table 112 has a record with the source "App1", the destination "App2", and requests per second "300". This record indicates that 300 requests are sent per second from pod 600 to pod 700.

[0104] Also, the request count table 112 has a record with the source "App1", the destination "App3", and requests per second "700". This record indicates that 700 requests are sent per second from pod 600 to pod 800.

[0105] In the request count table 112, the requests per second can also be registered for other combinations of the source and the destination. FIG. 12 is a diagram showing an example of the reference delay time table.

[0106] The reference delay time table 113 is generated by the reference delay time calculation unit 120 based on the request number table 112 and stored in the storage unit 110. The reference delay time table 113 includes items of source, type, and reference delay time. In the item of the source, the identification name of the service in the source pod is registered. In the item of the type, the type of the sidecar operating in the pod is registered. In the item of the reference delay time, the reference delay time when a request is sent from the pod to the destination pod is registered.

[0107] For example, the reference delay time table 113 has a record with a source of "App1", a type of "Istio", and a reference delay time of "2.65 ms". This record indicates that the type of the sidecar in pod 600 is "Istio" and the reference delay time is 2.65 ms.

[0108] Here, the reference delay time calculation unit 120 calculates the reference delay time for pod 600 as follows based on the request number table 112. First, the reference delay time calculation unit 120 calculates the total number of requests sent by pod 600 per unit time based on the request number table 112. Specifically, the reference delay time calculation unit 120 calculates that the total number of requests sent by pod 600 / s = 300 + 700 = 1000 requests / s.

[0109] Then, based on the sidecar information table 111, the reference delay time calculation unit 120 calculates, as the reference delay time, the delay time when transmitting at the total number of requests / s using the single sidecar 620 originally possessed by the pod 600. Specifically, the delay time of the sidecar increases in proportion to the number of requests / s to be transmitted. The type of the sidecar 620 is Istio. According to the sidecar information table 111, the "delay time at 1000 req / s" of the Istio sidecar is 2.65 ms. Here, let "1000 req / s" in the "delay time at 1000 req / s" of the sidecar information table 111 be denoted as A, and the total number of requests / s calculated by the reference delay time calculation unit 120 for the pod 600 be denoted as B. The reference delay time calculation unit 120 calculates the reference delay time for the pod 600 as (B / A)*2.65 = (1000 / 1000)*2.65 = 2.65 ms.

[0110] In the reference delay time table 113, reference delay times can also be registered for other pods. FIG. 13 is a diagram showing an example of the service mesh type table.

[0111] The service mesh type table 114 is acquired from the master node 200 by the reference delay time calculation unit 120 and stored in the storage unit 110. The service mesh type table 114 includes items for pods and types. In the pod item, the identification name of the service in the pod is registered. In the type item, the service mesh type used in the pod, that is, the type of the sidecar used in the service mesh, is registered.

[0112] For example, the service mesh type table 114 has a record of pod "App1" and type "Istio". This record indicates that the type of the sidecar of the pod 600 is "Istio".

[0113] In the service mesh type table 114, records indicating that the type of the sidecar of pod 700 is "Dapr" and records indicating that the type of the sidecar of pod 800 is "Istio" are also registered.

[0114] FIG. 14 is a diagram showing an example of a request number table by service mesh type. The request number table 115 by service mesh type is generated by the delay time calculation unit 130 based on the request number table 112 and the service mesh type table 114, and is stored in the storage unit 110. The request number table 115 by service mesh type includes items of source, source type, destination type, and request number / s.

[0115] In the item of the source, the identification name of the service in the source pod is registered. In the item of the source type, the type of the sidecar in the source pod is registered. In the item of the destination type, the type of the sidecar in the destination pod is registered. In the item of the request number / s, the number of requests per second transmitted from the source pod to the destination pod is registered.

[0116] For example, the request number table 115 by service mesh type has a record of source "App1", source type "Istio", destination type "Dapr", and request number / s "300". This record indicates that 300 requests per second are transmitted from pod 600 to pod 700 having a sidecar of destination type Dapr.

[0117] Also, the request number table 115 by service mesh type has a record of source "App1", source type "Istio", destination type "Istio", and request number / s "700". This record indicates that 700 requests per second are transmitted from pod 600 to pod 800 having a sidecar of destination type Istio.

[0118] In the request number table 115 by service mesh type, for other pods of the source, the request number per unit time can be registered for each destination type. FIG. 15 is a diagram showing an example of a GW transit delay time table.

[0119] The GW transit delay time table 116 is generated by the delay time calculation unit 130 based on the request number table 115 by service mesh type and stored in the storage unit 110. The GW transit delay time table 116 includes items of pod, source type, destination type, and delay time.

[0120] In the item of pod, the identification name of the service in the source pod is registered. In the item of source type, the type of sidecar in the source pod is registered. In the item of destination type, the type of sidecar in the destination pod is registered. In the item of delay time, the delay time when a request is sent from the source pod to the destination pod via the gateway 900 is registered.

[0121] For example, the GW transit delay time table 116 has a record of pod "App1", source type "Istio", destination type "Dapr", and delay time "2.01 ms". This record indicates that the delay time when a request from pod 600 to pod 700 is sent via the gateway 900 is 2.01 ms.

[0122] Here, the delay time calculation unit 130 calculates the delay time when a request is sent from pod 600 to pod 700 via the GW as follows. First, based on the request count table 115 for each service mesh type, the delay time calculation unit 130 identifies that for the sidecar type "Istio" of the pod 600, the destination sidecar type "Dapr" exists. Therefore, the delay time calculation unit 130 identifies that for requests sent via the GW, they pass through a gateway with Istio sidecar and Dapr sidecar. Also, based on the request count table 115 for each service mesh type, the delay time calculation unit 130 identifies that the number of requests from the pod 600 to the Dapr sidecar is 300 requests per second.

[0123] In this case, requests sent from the pod 600 to a pod with a Dapr sidecar reach the destination pod via the Istio sidecar of the pod 600, the Istio sidecar of the gateway, and the Dapr sidecar of the gateway. Therefore, based on the sidecar information table 111, the delay time calculation unit 130 calculates (300 / 1000)*2.65+(300 / 1000)*2.65+(300 / 1000)*1.40 = 2.01 ms as the delay time via the GW.

[0124] Note that in the above calculation example, it shows the case where one gateway relays requests from one source pod. However, one gateway can relay requests from multiple source pods. When one gateway relays requests from multiple source pods, in the above calculation formula, for the term of the delay time related to the sidecar of the gateway, the total number of requests relayed by the gateway is used.

[0125] In the GW via delay time table 116, for other pods, the delay time via the GW when sending requests to a destination pod with different types of sidecars can be registered. FIG. 16 is a diagram showing an example of an IP address table.

[0126] The IP address table 117 is information indicating the IP addresses of each pod. The IP address table 117 is generated by the setting change processing unit 140. The setting change processing unit 140 acquires the IP addresses of each pod from the master node 200 and registers them in the IP address table 117. The IP address table 117 includes items for pods and IP addresses. In the item for pods, the identification name of the service in the pod is registered. In the item for IP addresses, the IP address is registered.

[0127] For example, the IP address table 117 has a record of pod "App1" and IP address "10.0.0.2". This record indicates that the IP address of pod 600 is 10.0.0.2. The IP address table 117 also has records indicating that the IP address of pod 700 is 10.0.0.3 and that the IP address of pod 800 is 10.0.0.4.

[0128] Figure 17 is a diagram showing an example of the communication method management table. The communication method management table 118 is information used for managing the communication method when sending a request from a certain pod to a destination pod. The communication method management table 118 includes items for pods, destination types, and communication methods.

[0129] In the item for pods, the identification name of the service in the pod is registered. In the item for destination types, the type of sidecar of the destination pod is registered. In the item for communication methods, the communication method used for sending a request from the corresponding pod to the destination pod is registered. The communication methods are "GW" and "direct". "GW" indicates that the request is sent via the GW. "Direct" indicates that the request is sent directly from the sidecar of the source pod to the sidecar of the destination pod without going through the GW.

[0130] For example, the communication method management table 118 has a record for pod "App1", destination type "Dapr", and communication method "GW". This record indicates that requests from pod 600 to pod 700 with a Dapr sidecar are sent via the GW.

[0131] Also, the communication method management table 118 has a record for pod "App1", destination type "Istio", and communication method "direct". This record indicates that requests from pod 600 to pod 800 with an Istio sidecar are sent directly.

[0132] Note that when a Dapr sidecar 630 is provided in pod 600 and used to communicate directly with pod 700, the communication method corresponding to pod "App1" and destination type "Dapr" becomes "direct".

[0133] For other pods in the communication method management table 118, communication methods for each destination type can be registered. FIG. 18 is a diagram showing examples of communication paths for each of communication via the GW and sidecar coexistence.

[0134] For example, when pod 600 and pod 700 communicate via the GW, the gateway 900 relays between pods 600 and 700. Direct communication is possible between pods 600 and 800 via the same type of sidecars 620 and 820.

[0135] Also, in the case of sidecar coexistence where a different type of sidecar 630 is added to pod 600 separately from sidecar 620 and used for communication with pod 700, direct communication is possible between pods 600 and 700 via the same type of sidecars 630 and 720. Also, direct communication is possible between pods 600 and 800 via the same type of sidecars 620 and 820.

[0136] The setting change processing unit 140 selects whether to perform the communication between pods 600 and 700 via the GW or by the coexistence of different types of sidecars according to the comparison between the delay time in the case of via-GW corresponding to the number of requests per unit time from pod 600 to pod 700 and the reference delay time. In the container 610, libraries for cooperating with multiple types of sidecars, logic for API calls, etc. are pre-installed.

[0137] Note that when using the GW route, the setting change processing unit 140 provides a sidecar 620a for sending requests to the gateway 900 to pod 700 separately from the sidecar 620 in pod 600. The sidecar 620a is an Istio sidecar. As described above, the sidecar 620 directly sends requests to the pod 800 to the sidecar 820. In this way, by separately providing the sidecar 620a for sending requests to the gateway 900, the communication delay time can be reduced compared to transferring requests only using the sidecar 620. In particular, the setting change processing unit 140 can suppress the deviation between the delay time calculated in advance as the case of via-GW during the operation in sidecar coexistence and the actual delay time when actually using the GW route by separately providing the sidecar 620a from the sidecar 620.

[0138] Here, the resource consumption amount of the sidecar increases as the number of requests processed per unit time increases. Even if the sidecar 620a is provided separately from the sidecar 620, the requests will be shared by the sidecars 620 and 620a respectively. For this reason, the resource consumption amount of the pod 600 for operating both the sidecars 620 and 620a is suppressed to increase slightly compared to the case of only the sidecar 620, and is less than the resource amount in the case of coexisting the sidecar 620 and a different type of sidecar 630.

[0139] Note that it is also conceivable to determine the transfer destinations of requests to the GW and the pod 800 using only the sidecar 620 without providing the sidecar 620a for the GW in the pod 600. In this case, for example, the reference delay time calculation unit 120 determines, as the reference delay time for the corresponding pod, a value obtained by multiplying the reference delay time calculated by the method described with reference to FIG. 12 (for example, a value of 2.65 ms) by a coefficient greater than 1. Further, when calculating the delay time in the case of passing through the GW, the delay time calculation unit 130 calculates the delay time due to the sidecar 620 using the total number of requests transmitted by the pod 600, and obtains the delay time in the case of passing through the GW by adding the delay time at the gateway 900. In this way, the management server 100 can also be configured not to provide the sidecar 620a. Further, in the pod 600, when switching the direct communication between the GW and the pod 800 using only the sidecar 620, the setting change processing unit 140 may set the information on the transfer destination of the request according to the destination of the request in the sidecar 620 via the Istio control plane.

[0140] The setting change processing unit 140 can also change from the method of passing through the GW to the method of sidecar coexistence, or from the method of sidecar coexistence to the method of passing through the GW. For example, when changing from the method of passing through the GW to the method of sidecar coexistence, the setting change processing unit 140 may set the information on the transfer destination of the request to the pod 700 in the sidecar 630 added to the pod 600 via the Dapr control plane. Further, when changing from the method of sidecar coexistence to the method of passing through the GW, the setting change processing unit 140 may set the information on the transfer destination of the request to the pod 700 in the sidecar 620a added to the pod 600 via the Istio control plane. Furthermore, when changing from the method of sidecar coexistence to the method of passing through the GW, the setting change processing unit 140 may set the information on the transfer destination of the request to the pod 700 in the sidecar 920 via the Dapr control plane.

[0141] Next, the routing settings within the pod 600 by the setting change processing unit 140 will be described. First, the routing settings when sending a request to the pod 700 via the GW through the sidecar 620a will be described.

[0142] FIG. 19 is a diagram showing an example of routing settings when passing through the GW. The setting change processing unit 140 registers information indicating the sidecar of the transfer destination for each destination IP in the transfer destination table 640 held by the pod 600. The transfer destination table 640 is used to determine the transfer destination of the request by the container 610. The transfer destination table 640 includes items for the destination IP and the transfer destination.

[0143] In the item for the destination IP, the IP address of the pod that is the destination of the request is registered. In the item for the transfer destination, information indicating the sidecar of the transfer destination corresponding to the destination is registered. Here, the information indicating the sidecar of the transfer destination is a combination of the local host address "127.0.0.1" and the port number. That is, the sidecars 620, 620a existing within the pod 600 are distinguished from the container 610 by the port number. In one example, the port number corresponding to the sidecar 620a is "9000". The port number corresponding to the sidecar 620 is "9001".

[0144] For example, the setting change processing unit 140 acquires the IP address "10.0.0.3" of the pod 700 with the Dapr sidecar based on the IP address table 117. Then, the setting change processing unit 140 sets "10.0.0.3" in the item for the destination IP of the transfer destination table 640, and sets "127.0.0.1:9000" in the item for the transfer destination corresponding to the destination IP. The sidecar 620a sends the request transferred from the container 610 to the gateway 900 under the control of the control plane 70. For example, the setting change processing unit 140 may set rule information for setting the transfer destination of the request from the container 610 to the gateway 900 in the sidecar 620a via the control plane 70.

[0145] Further, the setting change processing unit 140 sets the default route "0.0.0.0" in the destination IP item of the transfer destination table 640, and sets "127.0.0.1:9001" in the transfer destination item for the default route. Thereby, requests with a destination IP address other than "10.0.0.3" are transferred from the container 610 to the sidecar 620.

[0146] Next, the routing setting when directly sending a request to the pod 700 via the sidecar 630 will be described. FIG. 20 is a diagram showing an example of routing setting when different types of sidecars coexist.

[0147] In this example, the port number corresponding to the sidecar 630 is "9002". In this case, the setting change processing unit 140 sets the transfer destination "127.0.0.1:9002" for the destination IP "10.0.0.3" of the transfer destination table 640. The sidecar 630 sends the request transferred from the container 610 to the pod 700 under the control of the Dapr control plane. For example, the setting change processing unit 140 may set rule information for setting the transfer destination of the request from the container 610 to the pod 700 in the sidecar 630 via the Dapr control plane. The setting change processing unit 140 sets the transfer destination "127.0.0.1:9001" for the default route "0.0.0.0" in the same manner as in FIG. 19.

[0148] In this way, the setting change processing unit 140 can control the request transmission route of the container 610 by changing the setting of the transfer destination table 640 according to whether to go via the GW or to directly send by coexistence of different types of sidecars.

[0149] Note that the setting change processing unit 140 can perform the setting change for the pod 600 illustrated in FIGS. 19 and 20 via the master node 200. Next, the processing procedure of the management server 100 will be described.

[0150] FIG. 21 is a flowchart showing a processing example of the management server. (S10) The reference delay time calculation unit 120 receives a service mesh configuration design request. The service mesh configuration design request is input to the management server 100 either when a new pod is deployed to any worker node or at a predetermined cycle.

[0151] (S11) The reference delay time calculation unit 120 selects one pod to be processed. The selection candidates of the pod to be processed include the pods that are already operating. When a new pod is deployed, the selection candidates of the pod to be processed include the new pod. The pod to be processed selected in step S11 is referred to as the corresponding pod in the following steps.

[0152] (S12) The reference delay time calculation unit 120 acquires the number of requests per second for each destination sent by the corresponding pod from the master node 200 and registers it in the request number table 112. The reference delay time calculation unit 120 calculates the total number of requests per second obtained by summing up the number of transmitted requests per second for each destination of the corresponding pod.

[0153] Note that when the corresponding pod is a new pod, the reference delay time calculation unit 120 may obtain the number of requests per second for each destination sent by the new pod so as to allocate a part of the request number of the existing pod that executes the same service as the new pod to the new pod. For example, there may be m existing pods that execute a certain service, and the addition of a new pod may increase the number of pods that execute the same service to m + 1. In this case, the reference delay time calculation unit 120 may divide the sum of the number of requests per second for each destination of each existing pod by (m + 1) to obtain the number of requests per second for each destination of the existing pod and the new pod respectively. Thereby, the reference delay time calculation unit 120 can obtain the number of requests per second for each destination after the addition of the new pod for each of the new pod and the existing pods.

[0154] Also, when the corresponding pod is a new pod and there is no existing pod that executes the same service as the new pod, the reference delay time calculation unit 120 may set the number of requests / s for each destination of the corresponding pod to 0.

[0155] (S13) The reference delay time calculation unit 120 calculates the reference delay time via the sidecar in the corresponding pod based on the total number of requests / s calculated in step S12 and the sidecar information table 111. The sidecar for which the reference delay time is calculated is the type of sidecar originally used by the corresponding pod (default type of sidecar). The reference delay time calculation unit 120 registers the calculated reference delay time in the reference delay time table 113. In step S13, the reference delay time calculation unit 120 acquires the types of sidecars of the corresponding pod and the destination pod from the master node 200 and registers them in the service mesh type table 114. The reference delay time calculation unit 120 can identify the default type of sidecar of the corresponding pod from the service mesh type table 114.

[0156] (S14) The delay time calculation unit 130 acquires the service mesh type of the destination pod, that is, the type of sidecar of the destination pod, based on the service mesh type table 114. The delay time calculation unit 130 calculates the number of requests for each type of sidecar of the destination pod with respect to the corresponding pod based on the request number table 112 and registers it in the service mesh type - specific request number table 115.

[0157] (S15) The delay time calculation unit 130 selects one destination pod for the corresponding pod from the service mesh type - specific request number table 115 and determines whether the type of sidecar of the destination pod is the same as that of the corresponding pod. If they are the same, the delay time calculation unit 130 proceeds to step S16. If they are not the same, the delay time calculation unit 130 proceeds to step S19 in FIG. 22. Note that the service mesh type of the destination pod corresponds to the destination type in the service mesh type - specific request number table 115.

[0158] (S16) The setting change processing unit 140 sets the destination of the default route by the container that executes the service to its own service mesh sidecar in the forwarding destination table in the iptables of the corresponding pod. Its own service mesh sidecar corresponds to the default type of sidecar in the corresponding pod.

[0159] (S17) The setting change processing unit 140 determines, for all service mesh types of the destination of the corresponding pod, whether the configuration design, that is, the processing after step S15 has been completed. If there is an unprocessed service mesh type, the setting change processing unit 140 proceeds to step S15 for the processing. When the configuration design has been completed for all service mesh types of the destination of the corresponding pod, the setting change processing unit 140 proceeds to step S18 for the processing.

[0160] (S18) The setting change processing unit 140 determines whether the processing of the configuration design has been completed for all pods that are candidates for processing. When the processing of the configuration design has been completed for all pods, the setting change processing unit 140 ends the processing. If there are unprocessed pods, the setting change processing unit 140 proceeds to step S11 for the processing.

[0161] Figure 22 is a flowchart showing a subsequent processing example of the management server. (S19) The delay time calculation unit 130 calculates the delay time in the case of passing through the GW from the corresponding pod to the destination pod based on the sidecar information table 111 and the request number table 115 by service mesh type. The delay time calculation unit 130 registers the calculated delay time in the GW transit delay time table 116.

[0162] (S20) The setting change processing unit 140 determines, based on the reference delay time table 113 and the GW via delay time table 116, whether the delay time in the case of GW via from the corresponding pod to the destination pod is smaller than the reference delay time of the corresponding pod. If the delay time in the case of GW via is smaller than the reference delay time of the corresponding pod, the setting change processing unit 140 proceeds to step S27 in FIG. 23. If the delay time in the case of GW via is equal to or greater than the reference delay time of the corresponding pod, the setting change processing unit 140 proceeds to step S21.

[0163] (S21) The setting change processing unit 140 determines whether a sidecar for the service mesh type of the destination pod already exists in the corresponding pod. If a sidecar for the service mesh type of the destination pod already exists in the corresponding pod, the setting change processing unit 140 proceeds to step S25. If a sidecar for the service mesh type of the destination pod does not exist in the corresponding pod, the setting change processing unit 140 proceeds to step S22.

[0164] Note that the setting change processing unit 140 can obtain information indicating the sidecar existing in the corresponding pod and the type of the sidecar by querying the master node 200. Also, when a record of the corresponding pod is registered in the communication method management table 118, the setting change processing unit 140 may obtain the sidecar existing in the corresponding pod and the type of the sidecar based on the record.

[0165] (S22) The setting change processing unit 140 determines whether a GW destination sidecar already exists in the corresponding pod. If a GW destination sidecar already exists in the corresponding pod, the setting change processing unit 140 proceeds to step S23. If a GW destination sidecar does not exist in the corresponding pod, the setting change processing unit 140 proceeds to step S24.

[0166] (S23) The setting change processing unit 140 creates a sidecar for the service mesh type of the destination pod and deletes the sidecar for GW for the corresponding pod. That is, the setting change processing unit 140 instructs the master node 200 to undeploy the corresponding pod, and then instructs the master node 200 to deploy the corresponding pod after creating the sidecar for the service mesh type of the destination pod and deleting the sidecar for GW. As a result, the corresponding pod is redeployed to one of the worker nodes and the corresponding pod is started. Then, the setting change processing unit 140 proceeds to step S25 for processing.

[0167] (S24) The setting change processing unit 140 creates a sidecar for the service mesh type of the destination pod for the corresponding pod. That is, the setting change processing unit 140 instructs the master node 200 to undeploy the corresponding pod, and then instructs the master node 200 to deploy the corresponding pod after creating the sidecar for the service mesh type of the destination pod. As a result, the corresponding pod is redeployed to one of the worker nodes and the corresponding pod is started. Then, the setting change processing unit 140 proceeds to step S25 for processing.

[0168] (S25) The setting change processing unit 140 obtains the IP address of the destination pod corresponding to the corresponding pod from the master node 200 and registers it in the IP address table 117. (S26) Based on the IP address table 117, the setting change processing unit 140 sets the transfer destination of the IP address of the destination pod to the sidecar for the service mesh type of the destination pod. That is, the setting change processing unit 140 sets in the iptables of the corresponding pod the setting to transfer a request from the container executing the service of the corresponding pod to the IP address of the destination pod to the sidecar for the service mesh type of the destination pod. Also, the setting change processing unit 140 registers a record of the communication method of the corresponding pod in the communication method management table 118. Then, the setting change processing unit 140 proceeds to step S17 in FIG. 21 for processing.

[0169] FIG. 23 is a flowchart showing a subsequent processing example of the management server. (S27) The setting change processing unit 140 determines whether a gateway (GW) that relays a request from the corresponding pod to the service mesh type of the destination pod already exists. If the gateway already exists, the setting change processing unit 140 proceeds to step S29. If the gateway does not exist, the setting change processing unit 140 proceeds to step S28.

[0170] (S28) The setting change processing unit 140 creates a gateway. Specifically, the setting change processing unit 140 instructs the master node 200 to deploy a pod that functions as a gateway for relaying requests from the service mesh type of the corresponding pod to the service mesh type of the destination pod. As a result, a gateway pod is deployed and started on one of the worker nodes.

[0171] (S29) The setting change processing unit 140 acquires the IP address of the destination pod from the master node 200 and registers it in the IP address table 117. (S30) The setting change processing unit 140 determines whether a sidecar for GW already exists in the corresponding pod. If a sidecar for GW already exists in the corresponding pod, the setting change processing unit 140 proceeds to step S34. If a sidecar for GW does not exist in the corresponding pod, the setting change processing unit 140 proceeds to step S31.

[0172] (S31) The setting change processing unit 140 determines whether a sidecar for the service mesh type of the destination pod already exists in the corresponding pod. If a sidecar for the service mesh type of the destination pod already exists in the corresponding pod, the setting change processing unit 140 proceeds to step S32. If a sidecar for the service mesh type of the destination pod does not exist in the corresponding pod, the setting change processing unit 140 proceeds to step S33.

[0173] (S32) The setting change processing unit 140 creates a sidecar for the GW destination for the corresponding pod and deletes the sidecar for the service mesh type of the destination pod. That is, the setting change processing unit 140 instructs the master node 200 to undeploy the corresponding pod, and then instructs the master node 200 to deploy the corresponding pod after creating the sidecar for the GW destination and deleting the sidecar for the service mesh type of the destination pod. As a result, the corresponding pod is redeployed to one of the worker nodes and the corresponding pod is started. Then, the setting change processing unit 140 proceeds to step S34 for processing.

[0174] (S33) The setting change processing unit 140 creates a sidecar for the GW destination for the corresponding pod. That is, the setting change processing unit 140 instructs the master node 200 to undeploy the corresponding pod, and then instructs the master node 200 to deploy the corresponding pod after creating the sidecar for the GW destination. As a result, the corresponding pod is redeployed to one of the worker nodes and the corresponding pod is started. Then, the setting change processing unit 140 proceeds to step S34 for processing.

[0175] (S34) The setting change processing unit 140 sets the transfer destination of the IP address of the destination pod to the GW destination sidecar based on the IP address table 117. That is, the setting change processing unit 140 sets in the iptables of the corresponding pod a setting to transfer a request from the container executing the service of the corresponding pod to the IP address of the destination pod to the GW destination sidecar. In addition, the setting change processing unit 140 registers a record of the communication method of the corresponding pod in the communication method management table 118. Then, the setting change processing unit 140 proceeds to step S17 in FIG. 21 for processing.

[0176] In addition, as a result of performing the above procedure, for example, the gateway 900 may no longer be used for relaying any requests. In this case, the setting change processing unit 140 may instruct the master node 200 to undeploy the gateway 900 and cause the gateway 900 to be undeployed. Further, when redeploying the corresponding pods in steps S23, S24, S32, and S33, the setting change processing unit 140 controls so that the iptables setting information of the corresponding pods is retained before and after the redeployment.

[0177] Also, the setting change processing unit 140 may repeatedly perform the processing from step S15 to step S17 including the procedures in FIGS. 22 and 23 for one pod. In this case, the setting change processing unit 140 does not perform pod redeployment during the repetition, and after all the repetitions are completed, that is, immediately after step S17 is YES, the pod may be redeployed once to reflect all the configuration changes related to the sidecar in the corresponding pod. Then, thereafter, the setting change processing unit 140 may set the sidecar of the transfer destination for each IP address of the destination pod in the iptables of the corresponding pod.

[0178] In this way, the management server 100 selectively uses a method of transmitting a request from a certain pod to another pod having different types of sidecars via the GW and a method of directly transmitting the request using a sidecar of the same type as the destination provided in the source pod. The management server 100 can achieve both suppression of the delay time and suppression of the amount of consumed resources by selecting whether to route a request to a different type of proxy container via the GW or to transmit it directly based on a comparison between the reference delay time and the delay time when transmitting via the GW from the corresponding pod.

[0179] Note that for each pod, a maximum allocable resource amount allowed for the pod may be predetermined. In this case, the setting change processing unit 140 may determine whether to transmit via the GW based on the maximum allocable resource amount of each pod.

[0180] FIG. 24 is a diagram showing an example of a maximum allocated resource amount table. The maximum allocated resource amount table 119 is pre-stored in the storage unit 110. The maximum allocated resource amount table 119 includes items for pods, CPUs, and memories. In the item for the pod, the identification name of the service in the corresponding pod is registered. In the item for the CPU, the maximum allocation amount of the CPU for the corresponding pod is registered. In the item for the memory, the maximum allocation amount of the memory for the corresponding pod is registered.

[0181] For example, the maximum allocated resource amount table 119 has a record of pod "App1", CPU "3", and memory "200MB". This record indicates that the maximum allocated resource amount for pod 600 is 3 CPUs and 200MB of memory. The maximum allocated resource amounts for other pods may also be registered in the maximum allocated resource amount table 119.

[0182] FIG. 25 is a diagram showing an example of selection of a communication method according to the maximum allocated resource amount. Even when the delay time in the case of via-GW is smaller than the reference delay time, the setting change processing unit 140 coexists a heterogeneous sidecar in pod 600 if the total allocated resource amount of pod 600 when the heterogeneous sidecar coexists in pod 600 is less than or equal to the maximum allocated resource amount.

[0183] For example, the resource consumption amount of the container 610 in pod 600 is 2 CPUs and 100MB of memory. Also, the resource consumption amount of the sidecar 620 is 0.35 CPUs and 40MB of memory. Further, the resource consumption amount of the sidecar 630 is 0.48 CPUs and 23MB of memory. Therefore, the total allocated resource amount of pod 600 is the sum of these, which is 2.83 CPUs and 163MB of memory.

[0184] The setting change processing unit 140 compares the maximum allocable resource amount of the pod 600 in the maximum allocable resource amount table 119 with the total allocable resource amount for each of the CPU and memory. Then, for both the CPU and memory, when the total allocable resource amount is less than or equal to the maximum allocable resource amount, the setting change processing unit 140 selects direct transmission by sidecar coexistence instead of via the GW. When the total allocable resource amount is greater than the maximum allocable resource amount for at least one of the CPU and memory, the setting change processing unit 140 selects whether to use the GW or direct transmission by sidecar coexistence according to the comparison between the delay time in the case of using the GW and the reference delay time.

[0185] When the setting change processing unit 140 performs the process of FIG. 25, immediately before step S19, it compares the total allocable resource amount and the maximum allocable resource amount for the corresponding pod. Then, when the total allocable resource amount is less than or equal to the maximum allocable resource amount, the setting change processing unit 140 proceeds to step S21. Also, when the total allocable resource amount is greater than the maximum allocable resource amount, the setting change processing unit 140 proceeds to step S20. Note that when the delay time in the case of using the GW is greater than or equal to the reference delay time, the setting change processing unit 140 will coexist a sidecar in the corresponding pod. In that case, it allows the total allocable resource amount of the corresponding pod to exceed the maximum allocable resource amount.

[0186] In this way, when there is a margin in the allocable resource amount allowed for the corresponding pod, the management server 100 may reduce the delay time of communication between pods by selecting request transmission by sidecar coexistence instead of via the GW.

[0187] As described above, the management server 100 executes, for example, the following process. The information processing system 2 executes a plurality of container groups including a first container group having a first type of proxy container and a second container group having a first proxy container of a second type. One container group includes a plurality of containers including a service container and a proxy container used for communication between the service container and other container groups. The reference delay time calculation unit 120 acquires a first delay time which is a reference delay time when a request is transmitted from the first container group to a destination container group by the first type of proxy container. The delay time calculation unit 130 calculates a second delay time based on the number of requests from the first container group to the second container group. The second delay time is the delay time when a request from the first container group reaches the second container group via a third container group that relays communication between different types of proxy containers. When the second delay time is less than the first delay time, the setting change processing unit 140 makes a setting to transmit a request from the first container group to the second container group to the third container group via the first type of proxy container. When the second delay time is greater than or equal to the first delay time, the setting change processing unit 140 adds a second proxy container of the second type to the first container group. Further, the setting change processing unit 140 makes a setting to transmit a request from the first container group to the second container group to the second container group via the second proxy container.

[0188] Thereby, the management server 100 can use an appropriate communication method in an environment where a plurality of types of proxy containers are mixed. Further, the reference delay time calculation unit 120 and the delay time calculation unit 130 can appropriately obtain the delay time even when it is difficult to measure the delay time according to the processing in each proxy container by calculating the delay time based on the number of requests.

[0189] When the second delay time is smaller than the first delay time, even if communication is via the GW, the communication quality expected for the information processing system 2 will be satisfied. Therefore, in this case, the setting change processing unit 140 can suppress the amount of consumed resources by making a request from the first container group to the second container group via the gateway, that is, via the third container group.

[0190] On the other hand, when the second delay time is greater than or equal to the first delay time, in communication via the GW, the communication quality expected for the information processing system 2 will not be satisfied. Therefore, in this case, the setting change processing unit 140 can suppress the delay time by directly transmitting a request from the first container group to the second container group without going through the gateway, that is, the third container group.

[0191] In this way, the management server 100 can achieve both suppression of the delay time and suppression of the amount of consumed resources by selecting whether to send a request to a different proxy container via the gateway or to send it directly based on the comparison between the first delay time and the second delay time.

[0192] Note that the pod 600 is an example of the first container group. The pod 700 is an example of the second container group. The gateway 900 is an example of the third container group. The sidecars 620, 620a are examples of the first type of proxy container. The sidecar 720 is an example of the first proxy container of the second type. The sidecar 630 is an example of the second proxy container of the second type.

[0193] For example, when the second delay time is smaller than the first delay time and the second proxy container exists in the first container group, the setting change processing unit 140 deletes the second proxy container from the first container group.

[0194] As a result, the management server 100 can delete unnecessary proxy containers from the first container group, and can reduce the amount of resources consumed by the first container group. In addition, when the second delay time is smaller than the first delay time, the setting change processing unit 140 adds a first type of proxy container that sends requests to the third container group to the first container group. Then, when the second delay time is equal to or greater than the first delay time and the added first type of proxy container exists in the first container group, the setting change processing unit 140 deletes the added first type of proxy container from the first container group.

[0195] As a result, the management server 100 can reduce the delay time of request transmission via the third container group from the first container group. In addition, the management server 100 can delete unnecessary proxy containers from the first container group, and can reduce the amount of resources consumed by the first container group. Note that the sidecar 620a is an example of a proxy container added as a first type of proxy container that sends requests to the third container group.

[0196] In obtaining the first delay time, the reference delay time calculation unit 120 calculates the first delay time based on the number of all requests transmitted per unit time from the first container group. For example, the reference delay time calculation unit 120 may calculate, as the first delay time, the delay time that occurs in the first type of proxy container when all the requests are transmitted without passing through the third container group using the first type of proxy container.

[0197] As a result, the management server 100 can control communication between container groups so as to be smaller than the delay time that occurs when requests are directly transmitted using the first type of proxy container alone. The management server 100 can obtain, for example, the delay time that occurs in the first type of proxy container from the delay time corresponding to the predetermined number of requests per unit time, which is published by the provider of the proxy container.

[0198] In addition, the third container group has a first type of proxy container and a second type of proxy container. The third container group receives requests from the first container group using the first type of proxy container belonging to the third container group. The third container group transfers the requests to the second container group using the second type of proxy container belonging to the third container group.

[0199] Thereby, the management server 100 can easily create a third container group that functions as a gateway using various proxy containers and add it to the information processing system 2.

[0200] In calculating the second delay time, the delay time calculation unit 130 calculates the second delay time based on the number of requests transmitted per unit time from the first container group to the second container group. That is, the delay time calculation unit 130 calculates the delay times generated by the first type of proxy container belonging to the first container group, the first type of proxy container belonging to the third container group, and the second type of proxy container belonging to the third container group, respectively. The delay time calculation unit 130 sets the sum of the calculated delay times as the second delay time.

[0201] Thereby, the management server 100 can appropriately calculate the delay time when passing through the third container group that functions as a gateway. The management server 100 can obtain, for example, the delay time generated in each proxy container from the delay time corresponding to the predetermined number of requests per unit time published by the provider of the corresponding proxy container.

[0202] Further, the setting change processing unit 140 compares the total allocated resource amount and the maximum allocated resource amount of the first container group when adding a second type of second proxy container to the first container group based on the information indicating the maximum allocated resource amount for the first container group. When the total allocated resource amount is less than or equal to the maximum allocated resource amount, the setting change processing unit 140 adds the second proxy container to the first container group even if the second delay time is smaller than the first delay time. Then, the setting change processing unit 140 sets to send a request from the first container group to the second container group to the second container group via the second proxy container.

[0203] Thereby, when there is a margin in the resource amount allocable to the first container group, the management server 100 can further reduce the delay time. Note that the maximum allocated resource amount table 119 is an example of information indicating the maximum allocated resource amount for the first container group.

[0204] Also, when the second delay time is smaller than the first delay time and the third container group is not in the information processing system 2, the setting change processing unit 140 adds the third container group to the information processing system 2.

[0205] Thereby, the management server 100 can appropriately provide the information processing system 2 with a communication path using the third container group that functions as a gateway. Here, the information processing of the first embodiment can be realized by causing the processing unit 12 to execute a program. Also, the information processing of the second embodiment can be realized by causing the CPU 101 to execute a program. The program can be recorded on a computer-readable recording medium 63.

[0206] For example, the program can be distributed by distributing the recording medium 63 on which the program is recorded. Also, the program may be stored in another computer and distributed via a network. The computer may store (install) the program recorded on the recording medium 63 or the program received from another computer in a storage device such as the RAM 102 or the HDD 103, and read and execute the program from the storage device.

Explanation of Signs

[0207] 1 Information Processing System 10 Information Processing Device 11 Storage Unit 12 Processing Unit 20, 30, 40, 50 Container Group 21, 31, 41 Container 22, 32, 42, 51, 52 Proxy Container

Claims

1. An information processing system that executes a plurality of container groups including a proxy container used for communication with other container groups, the plurality of container groups including a first container group having a first type of proxy container and a second container group having a second type of first proxy container. Obtain a first delay time, which is a reference delay time when a request is transmitted from the first container group to a destination container group by the first type of proxy container, Calculate a second delay time when the request from the first container group reaches the second container group via a third container group that relays communication between proxy containers of different types, based on the number of requests from the first container group to the second container group, When the second delay time is smaller than the first delay time, set to transmit the request from the first container group to the second container group to the third container group via the first type of proxy container. When the second delay time is greater than or equal to the first delay time, add the second type of second proxy container to the first container group and set to transmit the request from the first container group to the second container group via the second proxy container. A program for causing a computer to execute the processing.

2. When the second delay time is smaller than the first delay time and the second proxy container exists in the first container group, delete the second proxy container from the first container group. The program according to claim 1, further causing the computer to execute the processing.

3. When the second delay time is smaller than the first delay time, add the first type of proxy container for transmitting the request to the third container group to the first container group. When the second delay time is greater than or equal to the first delay time and the added first - type proxy container exists in the first container group, delete the added first - type proxy container from the first container group. The program according to claim 1, further causing the computer to execute the process.

4. In the acquisition of the first delay time, based on the number of all requests transmitted per unit time from the first container group, when all the requests are transmitted without passing through the third container group using the first - type proxy container, calculate the delay time occurring in the first - type proxy container as the first delay time. The program according to claim 1, causing the computer to execute the process.

5. The third container group has the first - type proxy container and the second - type proxy container, receives the request from the first container group using the first - type proxy container belonging to the third container group, and transfers the request to the second container group using the second - type proxy container belonging to the third container group. The program according to claim 1.

6. In the calculation of the second delay time, based on the number of the requests transmitted per unit time from the first container group to the second container group, calculate the delay time occurring in each of the first - type proxy container belonging to the first container group, the first - type proxy container belonging to the third container group, and the second - type proxy container belonging to the third container group, and set the sum of the calculated delay times as the second delay time. The program according to claim 5, causing the computer to execute the process.

7. Based on the information indicating the maximum amount of resources allocated to the first container group, compare the total amount of resources allocated to the first container group when the second proxy container is added to the first container group with the maximum amount of resources allocated, When the total amount of resources allocated is less than or equal to the maximum amount of resources allocated, even if the second delay time is less than the first delay time, add the second proxy container to the first container group, and set to send the request from the first container group to the second container group via the second proxy container. The program according to claim 1, further causing the computer to execute the process.

8. When the second delay time is less than the first delay time and the third container group does not exist in the information processing system, add the third container group to the information processing system. The program according to claim 1, further causing the computer to execute the process.

9. A computer, For an information processing system that executes a plurality of container groups including a container group to which a plurality of containers including a proxy container used for communication with other container groups belong, and includes a first container group having a first type of proxy container and a second container group having a second type of first proxy container, obtain a first delay time that is a reference delay time when sending a request from the first container group to a destination container group by the first type of proxy container, Calculate a second delay time when the request from the first container group reaches the second container group via a third container group that relays communication between proxy containers of different types, based on the number of requests from the first container group to the second container group. When the second delay time is smaller than the first delay time, set to send the request from the first container group to the second container group to the third container group via the first type of proxy container. When the second delay time is equal to or greater than the first delay time, add the second type of second proxy container to the first container group and set to send the request from the first container group to the second container group to the second container group via the second proxy container. Information processing method.

10. A container group to which a plurality of containers including a proxy container used for communication with other container groups belong, the container group including a first container group having a first type of proxy container and a second container group having a first proxy container of a second type. For an information processing system that executes a plurality of container groups, a storage unit that stores a first delay time, which is a reference delay time when a request is sent from the first container group to a destination container group by the first type of proxy container; Calculate a second delay time when the request from the first container group reaches the second container group via a third container group that relays communication between proxy containers of different types, based on the number of requests from the first container group to the second container group. When the second delay time is smaller than the first delay time, set to send the request from the first container group to the second container group to the third container group via the first type of proxy container. When the second delay time is equal to or greater than the first delay time, add the second type of second proxy container to the first container group and set to send the request from the first container group to the second container group to the second container group via the second proxy container. A processing unit; An information processing apparatus having the above.

Images