JP2024173034A - Information processing method and server system - Google Patents

Abstract

[Problem] To improve the availability of a server system that performs inter-process communication. [Solution] An information processing method for a server system that performs inter-process communication from a first server to at least a second server, the server system includes a resolution server that executes processing related to identifying an inter-process communication destination in the inter-process communication, the first server receives first information for identifying the second server from the resolution server, and transmits second information for requesting processing of the inter-process communication to the second server based on the first information, and the second server receives the second information from the first server and executes the first processing based on the second information. [Selected Figure] Figure 1-1

Description

This disclosure relates to information processing methods, server systems, etc.

To realize distributed application processing in cloud computing and the like, message communication is required as a mechanism for cooperative operation between multiple applications. For example, Patent Document 1 discloses a system that realizes message communication by controlling a message queue.

JP 2005-004356 A

According to a first aspect of the present invention, there is provided an information processing method for a server system performing inter-process communication from a first server to at least a second server, the server system including a resolution server that performs processing related to identifying an inter-process communication destination in the inter-process communication, the first server receives first information for identifying the second server from the resolution server and transmits second information to the second server based on the first information for requesting processing of the inter-process communication, and the second server receives the second information from the first server and performs the first processing based on the second information.
According to a second aspect of the present invention, there is provided a server system that performs inter-process communication from a first server to at least a second server, the server system including a resolution server that performs processing related to identifying an inter-process communication destination in the inter-process communication, the first server having a communication unit that receives first information for identifying the second server from the resolution server and transmits second information to the second server based on the first information for requesting processing of the inter-process communication, and the second server having a communication unit that receives the second information from the first server and a control unit that performs first processing based on the second information.

FIG. 1 is a diagram showing an example of a system configuration of a communication system according to a first embodiment. FIG. 4 is a diagram showing an example of functions realized by a control unit of the component server according to the first embodiment; FIG. 4 is a diagram showing an example of information stored in a storage unit of the component server according to the first embodiment; FIG. 4 is a diagram showing an example of functions realized by a control unit of the call destination resolution server according to the first embodiment; FIG. 4 is a diagram showing an example of information stored in a storage unit of a call destination resolution server according to the first embodiment; FIG. 4 is a diagram showing an example of call destination management data according to the first embodiment. FIG. 2 is a diagram showing an example of functions realized by a control unit of the mass calling server according to the first embodiment; FIG. 4 is a diagram showing an example of information stored in a storage unit of the mass calling server according to the first embodiment; 4 is a flowchart showing an example of a flow of a process executed by each device according to the first embodiment. FIG. 2 is a block diagram showing an example of the processing flow of each software module according to the first embodiment. 4 is a flowchart showing an example of a flow of a process executed by each device according to the first embodiment. FIG. 11 is a block diagram showing an example of a flow of processes executed by each device according to the second embodiment. FIG. 11 is a block diagram showing an example of a flow of processes executed by each device according to a second modified example.

<Compliance with legal matters>
It should be noted that the disclosures described herein are subject to compliance with the laws of the country of implementation, such as communications secrecy, as necessary for the implementation of the disclosure.

<Embodiment>
In this specification, for ease of understanding, there are some places where the phrase "by way of example and not by way of limitation" is used, but please note that not only these places but also the entire embodiment described below are not limited to the contents of the description.

An embodiment for implementing the program etc. related to this disclosure will be described with reference to the drawings.

The production of a terminal of the claimed invention (terminal of the claimed invention) may include, by way of example and not limitation, the concept of a terminal owned (possessed) by a user receiving (or receiving and storing in the terminal) a program (by way of example and not limitation) described in this specification (an application program) and the like, thereby creating a state in which the functions of the claimed invention are realizable in the terminal (creating a state in which the claimed invention is executable).

Furthermore, the production of the system of the invention claimed in the present application (the system of the invention of the present application) may include, by way of example and not limitation, the concept of creating a state in which the functions of the invention of the system claimed in the present application can be realized (a state in which the invention claimed in the present application can be executed) by receiving, at a terminal included in the system of the present application, a program described in this specification (by way of example and not limitation, an application program) transmitted from a server included in the system of the present application (or by storing the received program in the terminal).

In addition, in this specification, a system may be, for example and not by way of limitation, configured to include a plurality of devices.
The multiple devices may be a combination of devices of the same type, a combination of devices of different types, or a combination of devices of the same type and devices of different types.
Note that a system can be considered, for example and not by way of limitation, as a plurality of devices working together to perform some kind of processing.

Furthermore, a system relating to a client (client device) and a server can be considered to be, by way of example and not limitation, at least one of the following:
(1) Terminal & Server (2) Server (3) Terminal

(1) is, by way of example and not limitation, a system that includes at least one terminal and at least one server. One example of this is a client-server system.

The server is, by way of example and not limitation, composed of the following devices, which may be a single device or a combination of multiple devices:

Specifically, the server is configured to have at least one processor (for example and not limitation, a CPU: Central Processing Unit, a GPU: Graphics Processing Unit, an APU: Accelerated Processing Unit, a DSP: Digital Signal Processor (for example and not limitation, an ASIC: Application Specific Integrated Circuit, an FPGA: Field Programmable Gate Array), etc.), a computer device (processor + memory), a control device, an arithmetic device, a processing device, etc., and may be a configuration having multiple of the same type of any one device (for example and not limitation, a CPU + CPU, a homogeneous multi-core processor, etc.), or a configuration having multiple different types of any one device (for example and not limitation, a CPU + DSP, a heterogeneous multi-core processor, etc.), or may be a combination of multiple devices (for example and not limitation, a processor + computer device, a processor + arithmetic device, a heterogeneous combination of multiple devices, etc.).
The processor may be a virtual processor.

Furthermore, when a server executes some processing, if the server is configured with a single device, the processing described in the embodiment is executed by the single device. If the server is configured with multiple devices, the server may be configured to execute some processing by one device and execute other processing by the other device. As a non-limiting example, if the server is configured with a processor and an arithmetic device, the server may be configured to execute a first processing by the processor and execute a second processing by the arithmetic device.
Furthermore, when a configuration is made up of a plurality of devices, the devices may be arranged in locations physically separated from one another.

Furthermore, the server functions may be provided in the form of PaaS, IaaS, or SaaS in cloud computing, for example and without limitation.

The control unit of the system can be at least one of the control unit of the terminal and the control unit of the server. In other words, by way of example and not limitation, the control unit of the system can be any of the following: (1A) only the control unit of the terminal, (1B) only the control unit of the server, or (1C) both the control unit of the terminal and the control unit of the server.

In addition, the control and processing (hereinafter collectively referred to as "control, etc.") performed by the control unit of the system may be (1A) performed only by the control unit of the terminal, (1B) performed only by the control unit of the server, or (1C) performed by both the control unit of the terminal and the control unit of the server.
In addition, in (1C), as an example and not a limitation, some of the controls performed by the control unit of the system may be performed by the control unit of the terminal, and the remaining controls may be performed by the control unit of the server. In this case, the allocation (allocation) of the controls may be equal or may be allocated in different proportions.

Furthermore, when referring to a communication unit of a server, if the server is configured with a single device, it may be the communication unit itself that the single device has, or, if the server is configured with multiple devices, the communication unit of the server may be configured to include each communication unit that each device has.
As an example and not by way of limitation, if a server comprises a first device and a second device, the first device having a first communication unit and the second device having a second communication unit, the communication unit of the server may be conceptualized as including the first communication unit and the second communication unit.

(2) As an example and not a limitation, the system may be a system made up of multiple servers (hereinafter referred to as a "server system"). In this case, the configuration of each server may be the same as that described above.

The control etc. performed by the server system may be performed by only one of the multiple servers (2A), by only the other servers (2B), or by both the one server and the other servers (2C).
In addition, in (2C), as an example and not a limitation, one server may perform part of the control etc. performed by the server system, and another server may perform the remaining control etc. In this case, the allocation (allocation) of the control etc. may be equal or may be allocated in different proportions.

(3) By way of example and not limitation, the system may be comprised of multiple terminals.
The system may be, by way of example and not limitation, a system such as the following:
A system that provides server functions to terminals (distributed system). This can be realized, for example and without limitation, by using blockchain technology.
A system in which terminals communicate wirelessly with each other. This can be realized, for example and without limitation, by communicating in a peer-to-peer (P2P) manner using short-range wireless communication technology such as Bluetooth (registered trademark).

The above is not limited to the control unit, but also applies to each functional unit, such as the input/output unit, communication unit, memory unit, clock unit, etc., which may be components of the system.

In the following embodiment, a system including a terminal and a server (a client-server system) is illustrated as an example and not as a limitation.
Incidentally, the server system described above in (2) can also be applied as the server.

Also, instead of a system including a terminal and a server, a system not including a server, such as the above-mentioned system (3) as an example and not a limitation, may be applied.
In this case, the embodiment can be configured based on the above-mentioned blockchain technology. Specifically, by way of example and not limitation, data stored and managed in a server described in the following embodiment is stored on the blockchain. Then, the terminal generates a transaction to the blockchain, and when the transaction is approved on the blockchain, the data stored on the blockchain can be updated.

It should be noted that even when the term "terminal" is used, this is not limited to the meaning of a terminal as a client device in a client server.
That is, a terminal may include the concept of a device other than in a client-server context.

In addition, the expression "through a communication I/F" is used appropriately in this specification. This is not intended to be limiting, but may be taken as an example to indicate that a device transmits and receives various types of information and data through a communication I/F (through a communication unit) based on the control of a control unit (such as a processor).

In addition, in this specification, when the terms "related to" and "associated" are used, such as "B related to A" or "B related to A," this may mean, by way of example and not limitation, that "B" has some kind of relationship with "A." Specific examples of this will be described later.

In addition, in this specification, when a device performs processing on two or more objects, such as "transmitting A and B" or "receiving A and B," this may include performing "A" and "B" in a synchronized manner (hereinafter referred to as "simultaneous"), and performing "A" and "B" with a different timing (hereinafter referred to as "non-simultaneous").
As an example and not a limitation, when referring to transmitting first information and second information, this may include both concepts of transmitting the first information and the second information in a synchronized manner and transmitting the first information and the second information with a lag in timing.
In addition, taking into consideration the lag (time lag), "simultaneous" may include "almost simultaneously."

Note that, even if "A" and "B" are performed at different times, this only needs to be the processing targeting "A" and "B," and the purpose does not necessarily have to be the same.
As an example and not a limitation, when the first information and the second information are transmitted as described above, it is sufficient to transmit the first information and the second information, and this may include cases where the first information and the second information are transmitted for the same purpose as well as cases where the first information and the second information are transmitted for different purposes.

<Example>
An example of an embodiment to which the present invention is applied will be described below.
For example, when a software component operates by distributed processing using multiple servers, the software component may exchange information (messages) through a message queue to perform inter-process communication (for example, but not limited to, RPC (Remote Procedure Call)). In this case, if a failure occurs in an MQ system (for example, but not limited to, ActiveMQ or RabbitMQ (registered trademark)) that manages the message queue, the inter-process communication that is currently occurring will be involved and the inter-process communication will be interrupted, which may have a significant impact on the operation of the software component.

Also, as a non-limiting example, in OpenStack (registered trademark), which is a group of software components for realizing cloud computing, the number of servers constituting a server group (cluster) that runs each software component (as a non-limiting example, NOVA, NEUTRON, etc.) becomes enormous as the services provided in cloud computing become more complex.
As a non-limiting example, if the number of servers constituting a cluster (as a non-limiting example, the total number of virtual servers controlled by the group of physical servers) exceeds 40,000, the operating load of the MQ system increases, causing delays in inter-process communication, etc., which may make it difficult to ensure stable operation of software components.

In the embodiment described below, when inter-process communication is performed between servers constituting a cluster, messages can be sent and received directly without going through an MQ system, eliminating single points of failure (SPOF) and achieving high availability. Even when the number of servers constituting a cluster is enormous, inter-process communication can be performed directly between the servers, thereby speeding up the operation of software components running in the cluster and reducing the load on the entire cluster.

In the following, as an example and not a limitation, among the servers that belong to (constitute) a cluster that runs a software component, a server that is directly involved in processing the software component is referred to as a "component server." A component server may be a virtual server (virtual machine) or a physical server (physical machine).

In the following, it is assumed, by way of example and not limitation, that inter-process communication is performed according to RPC. Note that, by way of example and not limitation, inter-process communication may be performed according to RMI (Remote Method Invocation). In addition, inter-process communication is not limited to communication between multiple processes using the same program.

Furthermore, in the following, by way of example and not limitation, a software component will be taken to include various software modules. And, by way of example and not limitation, a software module for realizing inter-process communication in a software component will be referred to as a "messaging module."

By way of example and not limitation, if the software component is an OpenStack component, the messaging module may be implemented by, by way of example and not limitation, the "oslo.messaging" module of the OpenStack shared library "Oslo".

Also, hereinafter, by way of example and not by way of limitation, the messaging module includes a messaging driver for sending and receiving inter-process communications from software components using various message delivery methods. By way of example and not by way of limitation, the messaging driver provided in the present invention will be referred to as an "http messaging driver."
By having the messaging module realize inter-process communication via the messaging driver, software components can make calls to and respond to the messaging module without depending on the messaging driver's message transmission method (which may also be called the transport layer used).

By way of example and not limitation, in the "oslo.messaging" module, by changing the messaging driver from an "Advanced Message Queuing Protocol (AMQP) driver" that uses an MQ system to an "http messaging driver," the method of message delivery can be changed without modifying the software components.

Note that the "http messaging driver" refers to any program (software driver) that applies the information processing method of the present invention, and is not limited to the messaging driver in the "oslo.messaging" module.

The messaging module may be referred to as, for example and not limitation, middleware located between a transport layer for inter-process communication (for example and not limitation, a message queuing service or an HTTP sending and receiving service) and a software component.
A messaging driver may be said to be a software driver program that bridges the middleware and the transport layer.

In the following, by way of example and not limitation, a component server that is the source of inter-process communication will be referred to as an "invoker," and a component server that is the destination of inter-process communication will be referred to as a "worker."
An invoker may be referred to as the caller or invoker of a function, and a worker may be referred to as the callee or procedure of a function.

As an example and not a limitation, we can refer to the invoker as the "client" and the worker as the "server" in a client-server model.

First Example
In the first embodiment, as an example and not as a limitation, an invoker searches for an appropriate worker using a call destination resolution server for resolving the destination of inter-process communication, and the invoker and the worker communicate with each other by means of http (Hypertext Transfer Protocol), as an example and not as a limitation, to realize inter-process communication.

The contents described in the first embodiment are applicable to any of the other embodiments and other modified examples.
Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

<System Configuration>
FIG. 1A is a diagram illustrating an example of a system configuration of a communication system 1 according to an embodiment of the present disclosure.
In the communication system 1, as an example and not a limitation, a call destination resolution server 10, a mass call server 40, and multiple component servers 20 (component server 20A, component server 20B, component server 20C, ...) are connected via a network 30.

The component server 20 has the function of providing predetermined services (for example, but not limited to, a user authentication service, a virtual network service, etc.) via the network 30 to, for example, but not limited to, a terminal (not shown) owned by a user who uses the software component and/or a server (not shown) that realizes other software components.
Hereinafter, the component servers 20 may be simply referred to as "servers 20 (server 20A, server 20B, server 20C, ...)." Note that each of the component servers 20A, 20B, 20C, ... may be a virtual server or a physical server.

The callee resolution server 10 has a function of providing a predetermined service (such as an inter-process communication callee resolution service, for example and not for limitation) to the component server 20 via the network 30. The callee resolution server 10 can also be expressed as a cluster (component server cluster) management server, for example and not for limitation.
Hereinafter, the call destination resolution server 10 may be simply referred to as the "server 10."

The call destination resolution server 10 may be, by way of example and not limitation, a single physical or virtual server, or a cluster (server system) consisting of multiple physical and/or virtual servers.

The mass call server 40 has a function of providing a predetermined service (such as an inter-process communication mass call service, for example and not for limitation) to the component servers 20 via the network 30. The mass call server 40 can also be expressed as a broadcast server or a broadcaster, for example and not for limitation.
Hereinafter, the mass calling server 40 may be simply referred to as the "server 40."

Note that the mass call server 40 may be, by way of example and not limitation, a single physical or virtual server, or a cluster (server system) consisting of multiple physical and/or virtual servers.

In this embodiment, by way of example and not limitation, the operator of the server system consisting of the component server 20, the call destination resolution server 10, and the mass call server 40 may be referred to as a user of the component server 20, a user of the call destination resolution server 10, and a user of the mass call server 40, respectively. Also, by way of example and not limitation, the user of the server system consisting of the component server 20, the call destination resolution server 10, and the mass call server 40 may be referred to as a user of a terminal (not shown) or a user of another software component.

The component server 20 (component server 20A, component server 20B, component server 20C, ...) (not limited to, but an example of a server, information processing device, information management device, server system, cluster) may be any terminal that is an information processing device capable of realizing the functions described in each embodiment.
Component server 20 may include, by way of example and not limitation, a server appliance, a computer (by way of example and not limitation, a desktop, laptop, tablet, etc.), a media computing platform (by way of example and not limitation, a cable, satellite set-top box, digital video recorder, etc.), a handheld computing device (by way of example and not limitation, a PDA, email client, etc.), or any other type of computer, hypervisor, or communications platform.
If there is no need to distinguish between the component server 20 and/or the call destination resolution server 10 and/or the mass call server 40, the component server 20 and/or the call destination resolution server 10 and/or the mass call server 40 may or may not be represented as information processing devices.

The component server 20A, the component server 20B, and the component server 20C may have the same configuration, for example and not by way of limitation.
Furthermore, server information in a specific service (process) associated with the component server 20X may or may not be expressed as server information X, as necessary.
The server information is information associated with a server in a specific service (process). The server information includes, for example and without limitation, information associated with a server, such as the name of the server, the IP address of the server, the MAC address of the server, the processing capacity of the server (for example and without limitation, MIPS or FLOPS), configuration information of the server (for example and without limitation, the number of processor cores and/or RAM capacity, etc.), and a server identifier, which are input by a user or assigned by a specific service, and may be any one of these, or a combination of these, or may not be the same.

The network 30 serves to connect one or more component servers 20, one or more call destination resolution servers 10, and one or more mass call servers 40. In other words, the network 30 refers to a communication network that provides a connection path so that the above-mentioned various devices can connect and then send and receive data.

The number of call destination resolution servers 10, the number of mass call servers 40, and the number of component servers 20 connected to the network 30 are not limited.

One or more portions of network 30 may or may not be wired or wireless. Network 30 may include, by way of example and not limitation, an ad hoc network, an intranet, an extranet, a virtual private network (VPN), a local area network (LAN), a wireless LAN (WLAN), a wide area network (WAN), a wireless WAN (WWAN), a metropolitan area network (MAN), a portion of the Internet, a portion of the Public Switched Telephone Network (PSTN), a cellular network, integrated service digital networks (ISDN), wireless LAN, long term evolution (LTE), code division multiple access (CDMA), Bluetooth, satellite communications, or the like, or a combination of two or more thereof. Network 30 may include one or more networks 30.

The callee resolution server 10 (which is an example, but not limited to, of a server, information processing device, information management device, server system, or cluster) has a function of providing a specific service to the component server 20. The callee resolution server 10 may be any information processing device capable of implementing the functions described in each embodiment. The callee resolution server 10 may include, but is not limited to, a server device, a computer (which may be, but is not limited to, a desktop, laptop, tablet, or the like), a media computing platform (which may be, but is not limited to, a cable or satellite set-top box, or a digital video recorder), a handheld computing device (which may be, but is not limited to, a PDA, or an email client, or the like), or any other type of computer, hypervisor, or communication platform.

By way of example and not limitation, if there is no need to distinguish between the called resolution server 10 and the component server 20, the called resolution server 10 and the component server 20 may or may not be represented as information processing devices.

The mass call server 40 (which is an example, but not limited to, of a server, information processing device, information management device, server system, or cluster) has a function of providing a predetermined service to the component server 20. The mass call server 40 may be any information processing device capable of implementing the functions described in each embodiment. The mass call server 40 may include, but is not limited to, a server device, a computer (which may be, but is not limited to, a desktop, laptop, tablet, etc.), a media computer platform (which may be, but is not limited to, a cable or satellite set-top box, digital video recorder, etc.), a handheld computer device (which may be, but is not limited to, a PDA, email client, etc.), or other types of computers, hypervisors, or communication platforms.

As an example and not as a limitation, if there is no need to distinguish between the call destination resolution server 10 and the mass call server 40, the call destination resolution server 10 and the mass call server 40 may or may not be represented as information processing devices.
Also, by way of example and not limitation, if there is no need to distinguish between the mass call server 40 and the component server 20, the mass call server 40 and the component server 20 may or may not be represented as information processing devices.

[Hardware (HW) configuration of each device]
The HW configuration of each device included in the communication system 1 will be described.

(1) HW Configuration of Servers FIG. 1A shows an example of the HW configuration of a call destination resolution server 10, a component server 20, and a general call server 40. As shown in FIG.
The call destination resolution server 10 includes a control unit 11 (CPU), a storage unit 15, a communication I/F 14 (interface), an input/output unit 12, and a clock unit 19. The components of the HW of the call destination resolution server 10 are connected to each other via a bus B, for example and not for limitation. It is not essential that the HW of the call destination resolution server 10 includes all components as the configuration of the HW of the call destination resolution server 10. For example and not for limitation, the HW of the call destination resolution server 10 may or may not be configured to remove individual components or multiple components.

The control unit 11 has circuitry that is physically structured to execute functions realized by the code or instructions contained in the program, and is realized, for example and not by way of limitation, by a data processing device built into hardware.

The control unit 11 is typically a central processing unit (CPU), but may also be a microprocessor, a processor core, a multiprocessor, an ASIC, or an FPGA, or may not be such a unit. In this disclosure, the control unit 11 is not limited to these.

The storage unit 15 has a function of storing various programs and various data required for the operation of the call destination resolution server 10. The storage unit 15 is realized by various storage media such as a HDD, SSD, and flash memory. However, in this disclosure, the storage unit 15 is not limited to these. Furthermore, the storage unit 15 may or may not be expressed as a memory.

The communication I/F 14 transmits and receives various data via the network 30. The communication may be performed either wired or wirelessly, and any communication protocol may be used as long as the communication between the two devices is possible. The communication I/F 14 has a function of communicating with various devices such as the component server 20 via the network 30. The communication I/F 14 transmits various data to various devices such as the component server 20 according to instructions from the control unit 11. The communication I/F 14 also receives various data transmitted from various devices such as the component server 20 and transmits it to the control unit 11. The communication I/F 14 may also be simply referred to as a communication unit. When the communication I/F 14 is configured with a physically structured circuit, it may also be referred to as a communication circuit.

The input/output unit 12 includes a device for inputting various operations to the call destination resolution server 10, a device for outputting the results of processing performed by the call destination resolution server 10, and the like. The input/output unit 12 may be an integrated input unit and an output unit, may be separate input unit and output unit, or may not be.

The input unit is realized by any one or combination of all types of devices that can accept input from a user and transmit information related to the input to the control unit 11. The input unit is typically realized by hardware keys such as a keyboard, or a pointing device such as a mouse. Note that the input unit may or may not include a touch panel, a camera (operation input via video images), or a microphone (operation input by voice), but is not limited to these.

The output unit is realized by any one or a combination of any type of device capable of outputting the results of processing by the control unit 11. Examples of the output unit include, but are not limited to, a touch panel, a touch display, a speaker (sound output), a lens (for example, but not limited to, 3D (three dimensions) output or hologram output), a printer, etc.

By way of example only, the input/output unit 12 is equipped with a display unit 13, by way of example and not by way of limitation.

The display unit 13 is realized by a display or the like. The display is typically realized by a monitor (for example, but not limited to, a liquid crystal display or an organic electroluminescence display (OELD). The display may or may not be a head mounted display (HDM) or the like. These displays may or may not be capable of displaying display data in 3D. In the present disclosure, displays are not limited to these.

The clock unit 19 is a built-in clock of the call destination resolution server 10, and outputs time information (timekeeping information). The clock unit 19 is configured to include, for example and not limitation, an RTC (Real Time Clock) as a hardware clock, a system clock, etc. The clock unit 19 can also be expressed as a timekeeping unit or a time information detection unit, for example and not limitation.

By way of example and not limitation, the component server 20 and the mass call server 40 can be configured in the same manner as the call destination resolution server 10.

(2) Others The call destination resolution server 10 stores the program P in the storage unit 15, and by executing this program P, the control unit 11 executes the processing of each unit included in the control unit 11. In other words, the program P stored in the storage unit 15 causes the call destination resolution server 10 to realize each function executed by the control unit 11. This program P may or may not be expressed as a program module.
The same applies to other devices.

In each embodiment of the present disclosure, the CPU of the component server 20 and/or the call destination resolution server 10 and/or the mass call server 40 is described as executing the program P to achieve this.

In addition, the control unit 21 of the component server 20, and/or the control unit 11 of the call destination resolution server 10, and/or the control unit 41 of the mass calling server 40 may or may not realize each process by a logic circuit (hardware) formed in an integrated circuit (IC (Integrated Circuit) chip, LSI (Large Scale Integration)) or a dedicated circuit, as well as a CPU having a control circuit. In addition, these circuits may be realized by one or more integrated circuits, and the multiple processes shown in each embodiment may or may not be realized by one integrated circuit. In addition, LSIs may be called VLSIs, super LSIs, ultra LSIs, etc. depending on the degree of integration. Therefore, by way of example and not limitation, the control unit 21 may or may not be expressed as a control circuit.
The same applies to other devices.

In addition, the program P (which may be, for example and not by way of limitation, a software program, computer program, or program module) of each embodiment of the present disclosure may or may not be provided in a state stored in a computer-readable storage medium. The storage medium is capable of storing the program P in a "non-transitory tangible medium." The program P may or may not be for realizing part of the functions of each embodiment of the present disclosure. Furthermore, the program P may or may not be a so-called difference file (difference program) that can realize the functions of each embodiment of the present disclosure in combination with a program P already recorded in a storage medium.

Furthermore, when referring to a system program (a program executed by the system), the system is as described above. The above-mentioned system program is a program that can be executed by the entire system, and this program may be composed of individual programs of the devices that make up the system, for example and without limitation, and the programs stored in each device that makes up the system may be different from each other. In other words, it is not necessary for the programs to be common to the individual devices that make up the system.
As an example and not a limitation, when a system is composed of multiple servers (server system or cluster), the system program P1 is composed of a program P2 stored in the call destination resolution server 10 and a program P3 stored in the component server 20, and P2 and P3 are for executing the system program and may be different programs. As an example and not a limitation, the program P2 stored in the call destination resolution server 10 may be a program that executes a first process and transmits the result of the first process to the server, and the program P3 stored in the component server 20 may be a program that executes a second process on the received result of the first process and transmits the result of the second process to the call destination resolution server 10.
The same applies to other devices.

The storage medium may include one or more semiconductor-based or other integrated circuits (ICs) (such as, by way of example and not limitation, a field programmable gate array (FPGA) or an application specific IC (ASIC)), a hard disk drive (HDD), a hybrid hard drive (HHD), an optical disk, an optical disk drive (ODD), a magneto-optical disk, a magneto-optical drive, a floppy diskette, a floppy disk drive (FDD), a magnetic tape, a solid-state drive (SSD), a RAM drive, a secure digital card, or a drive, any other suitable storage medium, or a suitable combination of two or more thereof. The storage medium may be volatile, non-volatile, or a combination of volatile and non-volatile, as appropriate. It should be noted that the storage medium is not limited to these examples and may be any device or medium capable of storing the program P. Also, the storage medium may or may not be referred to as a memory.

By way of example and not limitation, the call destination resolution server 10 and/or the mass call server 40 and/or the component server 20 can realize the functions of the multiple functional units shown in each embodiment by reading a program P stored in a storage medium and executing the read program P.

In addition, the program P of the present disclosure may or may not be provided to the call destination resolution server 10 and/or the mass call server 40 and/or the component server 20 via any transmission medium capable of transmitting a program (such as a communication network or broadcast waves). The call destination resolution server 10 and/or the mass call server 40 and/or the component server 20 executes the program P downloaded via the Internet or the like, by way of example and not limitation, thereby realizing the functions of the multiple functional units shown in each embodiment.

In addition, each embodiment of the present disclosure may be realized in the form of a data signal in which the program P is embodied by electronic transmission.
At least a part of the processing in the call destination resolution server 10 and/or the mass call server 40 and/or the component server 20 may or may not be realized by cloud computing consisting of one or more computers.
At least a part or all of the processing in the component server 20 may or may not be performed by the call destination resolution server 10 and/or the mass call server 40. In this case, at least a part or all of the processing of each functional unit of the control unit 21 of the component server 20 may or may not be performed by the call destination resolution server 10 and/or the mass call server 40.
At least a part or all of the processing in the call destination resolution server 10 and/or the mass call server 40 may or may not be performed by the component server 20. In this case, at least a part or all of the processing of each functional unit of the control unit 11 of the call destination resolution server 10 and/or the control unit 41 of the mass call server 40 may or may not be performed by the component server 20.

At least a part or all of the processing in the call destination resolution server 10 may or may not be performed by the mass call server 40. In this case, at least a part or all of the processing of each functional unit of the control unit 11 of the call destination resolution server 10 may or may not be performed by the mass call server 40.
At least a part or all of the processing in the mass call server 40 may or may not be performed by the call destination resolution server 10. In this case, at least a part or all of the processing of each functional unit of the control unit 41 of the mass call server 40 may or may not be performed by the call destination resolution server 10.

Unless explicitly stated, the judgment configuration in the embodiments of the present disclosure is not essential, and a specified process may or may not be executed when the judgment condition is satisfied, or when the judgment condition is not satisfied.

The programs disclosed herein may be implemented using, by way of example and not limitation, scripting languages such as ActionScript and JavaScript (registered trademark), compiler languages such as Go, Objective-C and Java (registered trademark), and markup languages such as HTML Living Standard.

<Functional configuration>
(1) Functional Configuration of the Component Server 20 FIG. 1B is a diagram showing an example of functions realized by the control unit 21 of the component server 20 in this embodiment.
The control unit 21 includes, as a functional unit, a component program processing unit 211 for executing component program processing in accordance with a component processing program 251 stored in the storage unit 25, by way of example and not of limitation.
The control unit 21 also includes, as a functional unit, an http daemon processing unit 213 for executing an http daemon process for sending and receiving information via HTTP in accordance with an http daemon program 253 stored in the memory unit 25, by way of example and not limitation.

FIG. 1C is a diagram showing an example of information stored in the storage unit 25 of the component server 20 in this embodiment.
The memory unit 25 stores, by way of example and not limitation, a component processing program 251 executed by the control unit 21 as a component program process, an http daemon program 253 executed by the control unit 21 as an http daemon process, and a server ID 255.

By way of example and not limitation, the component processing program 251 may be referred to as a software component.

The http daemon program 253 may be realized (implemented) by, for example but not limited to, Apache (registered trademark) HTTP Server, nginx (registered trademark), WSGI (Web Server Gateway Interface) Server, etc.

The component processing program 251 includes, by way of example and not by way of limitation, a messaging module 2513. The messaging module 2513 also includes, by way of example and not by way of limitation, an http messaging driver 2515.

The server ID 255 is, by way of example and not limitation, information for identifying a particular component server 20 in a cluster (server system) that executes a component processing program.
For example and not limitation, when a component server 20 starts a component program process, identification information assigned to each component server 20 in accordance with the component processing program 251 may be stored in the server ID 255 .

(2) Functional Configuration of the Call Destination Resolution Server 10 FIG. 1-4 is a diagram showing an example of functions realized by the control unit 11 of the call destination resolution server 10 in this embodiment.
The control unit 11 includes, as a functional unit and not as a limitation, a callee resolution processing unit 111 for executing callee resolution processing of inter-process communication between component servers 20 in accordance with a callee resolution processing program 151 stored in the memory unit 15.
In addition, the control unit 11 may include, as a non-limiting example, an HTTP daemon processing unit as a functional unit for executing HTTP daemon processing to send and receive information via HTTP in accordance with an HTTP daemon program stored in the memory unit 15.

FIG. 1-5 is a diagram showing an example of information stored in the storage unit 15 of the call destination resolution server 10 in this embodiment.
In the storage unit 15, for example and not for limitation, a callee resolution processing program 151 executed by the control unit 11 as the callee resolution processing, and callee management data 153 are stored.
The storage unit 15 may also be configured to store an http daemon program.

The callee management data 153 is registration data related to each component server 20 in a cluster (server system) that executes a component program (such as, but not limited to, NOVA or NEUTRON in OpenStack). An example of the data configuration is shown in FIG.
In the call destination management data 153, for example and not for limitation, a server ID, bind key information, and other registration information are stored in association with each other.

The server ID is identification information of the component server 20 that constitutes the cluster that executes the component processing program, and as a non-limiting example, the server ID sent from the component server 20 when the component server 20 executes the component processing program is stored.

The server ID may be information that can be identified by the component server 20 (for example, but not limited to, an IP address, a port number, a MAC address, a URI, etc.).
The server ID may also be called RPC endpoint information.

In addition, as an example and not a limitation, the server ID may be set and stored as a unique value (proper value) for each component server 20 by the callee resolution server 10 when the component server 20 executes the component processing program.
In this case, the call destination resolution server 10 may transmit the set server ID to the component server 20. Then, the component server 20 may store the received server ID in the storage unit 25.

The bind key information is, by way of example and not by way of limitation, information for determining the call destination of inter-process communication in an RPC. As an example and not by way of limitation, this bind key information stores the bind key information sent from the component server 20 when the component server 20 executes a component processing program.

In addition, as a non-limiting example, the bind key information may be set and stored by the called resolution server 10 when the component server 20 executes the component processing program.

In addition, the bind key information is, by way of example and not limitation, information required for the messaging module 2513 to accept inter-process communication according to RPC, and, by way of example and not limitation, if there is no need to maintain compatibility with RPC, the bind key information may not be stored.

The bind key information may also include, by way of example and not limitation, an expression indicating a string pattern (by way of example and not limitation, one word match (by way of example and not limitation, "*") or multiple word match (by way of example and not limitation, "#")). The bind key information may also include, by way of example and not limitation, multiple bind key strings.

The other registered information may include, by way of example and not limitation, server information about the component server 20, configuration information about the component server 20 (by way of example and not limitation, the number of CPU cores, main memory capacity, etc.), and various other information such as uptime and load average. The other registered information may also include information regarding alive monitoring of each component server 20 by the called resolution server 10.

In addition, other registration information may include information for identifying the role of the server (hereinafter referred to as "server role information"), such as "worker" indicating that RPCs can be accepted, as an example and not a limitation.

The call destination management data 153 may store registration information of the mass calling server 40 .
In this case, for example and not for limitation, the server role information may be set to, for example and not for limitation, "broadcaster." There may or may not be associated bind key information.
The server ID may be set by the mass calling server 40 or by the call destination resolution server 10 .

As an example and not a limitation, while a certain mass call server 40 is executing the RPC message information amplification and transmission process described below, the record (server ID, etc.) related to that mass call server 40 may be temporarily deleted from the call destination management data 153.

The call destination resolution processing program 151 may be implemented based on, for example and not by way of limitation, a service discovery system such as Consul or DNS (Domain Name System).

(3) Functional Configuration of the Mass Calling Server 40 FIG. 1-7 is a diagram showing an example of functions realized by the control unit 41 of the mass calling server 40 in this embodiment.
The control unit 41 includes, as a functional unit and not as a limitation, a simultaneous call program processing unit 411 for executing inter-process communication with multiple component servers 20 in accordance with a simultaneous call processing program 451 stored in the memory unit 45 .
The control unit 41 also includes, as a functional unit, an HTTP daemon processing unit 413 for executing HTTP daemon processing for sending and receiving information via HTTP in accordance with an HTTP daemon program 453 stored in the memory unit 45, for example and not for limitation.

FIG. 1-8 is a diagram showing an example of information stored in the storage unit 45 of the mass calling server 40 in this embodiment.
The memory unit 45 stores, by way of example and not limitation, a mass call processing program 451 executed by the control unit 41 as a mass call process, an http daemon program 453 executed by the control unit 41 as an http daemon process, and component server list information 455.

The component server list information 455 is a list of component servers 20 that are workers designated as the destination of a mass call when the component server 20 that is an invoker executes a mass call (for example, but not limited to, rpc.fanout) in inter-process communication, and, for example, but not limited to, the server ID (server identification information) of each component server 20 is stored and saved.

In addition, the mass call server 40 may be described as an API server for mediating and amplifying HTTP communications, but is not limited to this example.

<Processing>
1-9 is a flowchart showing an example of the flow of processing executed by each device in this embodiment. In this flowchart, as an example and not a limitation, an RPC.call communication in which a response is expected from the procedure side is described. Also, in this flowchart, as an example and not a limitation, the component server 20A is the RPC call side (invoker) and the component server 20B is the RPC procedure side (worker).
This figure shows, from the left, the processing performed by the control unit 21 of the component server 20A which is the invoker, the processing performed by the control unit 11 of the called resolution server 10, and the processing performed by the control unit 21 of the component server 20B which is the worker.

Prior to the flowchart, the control unit 21 of each component server 20 starts component program processing and http daemon processing according to, for example and not limitation, the component processing program 251 and the http daemon program 253. Then, the control unit 21 of each component server 20 sends component program start-up information including the server ID 255 stored in the storage unit 25 to the call destination resolution server 10 via the communication I/F 22 according to, for example and not limitation, the http messaging driver 2515.

In addition, the component program startup information may include, by way of example and not by way of limitation, server information such as configuration information regarding each component server 20. In addition, the component program startup information may include, by way of example and not by way of limitation, bind key information that is set when the component program process is started.

When the component program start information is received from the component server 20 via the communication I/F 14, the control unit 11 of the call destination resolution server 10 executes a worker update process, for example and not for limitation (S110).
In the worker update process, the control unit 11 of the callee resolution server 10 updates and registers the callee management data 153 so that each component server 20 becomes a "worker" based on the received component program start-up information, for example and not limitation.

In addition, by way of example and not limitation, when the control unit 21 of each component server 20 starts component program processing, the control unit 21 may, by way of example and not limitation, transmit component program startup information to the called resolution server 10 at a predetermined time (by way of example and not limitation, "00 minutes past the hour") or at predetermined intervals (by way of example and not limitation, "7200 seconds").
Then, when the control unit 11 of the call destination resolution server 10 receives the component program start information from the component server 20, the control unit 11 may update the call destination management data 153 based on the received component program start information.

In addition, the control unit 11 of the destination resolution server 10 may, by way of example and not limitation, send component program operation confirmation information to each component server 20 at a predetermined time (as an example and not limitation, "00 seconds every minute") or at a predetermined period (as an example and not limitation, "60 seconds") to confirm that each component server 20 is operating as a worker.
When component program operation confirmation information is received from the called resolution server 10 via the communication I/F 24, the control unit 21 of the component server 20 may, as a non-limiting example, send component program start-up information to the called resolution server 10.
Then, when the control unit 11 of the call destination resolution server 10 receives the component program start information from the component server 20, the control unit 11 may update the call destination management data 153 based on the received component program start information.

When the control unit 11 of the call destination resolution server 10 determines that it is unable to receive component program startup information from a certain component server 20, it may delete that component server 20 from the call destination management data 153.

This allows the called resolution server 10 to perform alive monitoring according to the operating status of each component server 20.

Thereafter, the control unit 21 of the component server 20A, which is the invoker, starts executing rpc.call processing based on the rpc.call procedure in the component program, for example and not by way of limitation (A110).
In the rpc.call process, the component program processing unit 211 of the component server 20A calls an RPC client (narrowly defined as an invoker) of the messaging module 2513 in which the http messaging driver 2515 is embedded, for example and not by way of limitation.

In the following, the content of the RPC processing specified in the calling arguments of the messaging module 2513 from the component processing program 251 will be referred to as "RPC processing request information" by way of example and not by way of limitation.

The RPC processing request information may be composed of the following elements, by way of example and not limitation:
RPC message information: Specific processing contents (which may be called functions) performed on the procedure side.
Target: Information for identifying a method for searching for a procedural component server 20.
Routing key: Information used when searching for the component server 20 and for matching with the bind key information.

In addition, by way of example and not limitation, the RPC processing request information may be more simply composed of a routing key and RPC message information.

In addition, below, information regarding the result of RPC processing on the procedure side based on RPC message information (which can also be said to be the return value of the function) is referred to as "RPC processing result information."

Then, the control unit 21 of the component server 20A, by way of example and not limitation, sends worker list request information, which is information necessary to identify the RPC procedure destination, to the call destination resolution server 10 via the communication I/F 24 in accordance with the HTTP messaging driver 2515 (A120).
Note that, by way of example and not limitation, the information for identifying the call destination resolution server 10 (such as an IP address or a URI of an API server) may be stored by the HTTP messaging driver 2515. Also, the information for identifying the call destination resolution server 10 may be transmitted from the call destination resolution server 10 to the component server 20 as needed.

When worker list request information is received from component server 20A via communication I/F 14, the control unit 11 of the callee resolution server 10 refers to the callee management data 153 and, as an example but not limited to, sends worker list information including a server ID whose server role information is "worker" and binding key information to the component server 20A via communication I/F 14 (S130).
The worker list information may include various types of server information such as configuration information and load average of each component server 20 .

Note that the sending and receiving of worker list request information and worker list information may be performed according to the HTTP protocol or according to DNS, but this is not a limitation of the present invention.

In addition, the control unit 21 of the component server 20A may, for example and not for limitation, obtain worker list information from a URI indicating the called resolution server 10 via a REST API (RESTful API).

When the worker list information is received from the call destination resolution server 10 via the communication I/F 24, the control unit 21 of the component server 20A executes a worker search process (A130).
In the worker search process, the control unit 21 of the component server 20A determines a worker (in this example, component server 20B) to send the RPC message information based on the received worker list information and RPC processing request information, by way of example and not limitation.

More specifically, the control unit 21 of the component server 20A may search for the server ID of a component server 20 having bind key information that satisfies the target and routing key conditions in the RPC processing request information, for example and not limitation.

As an example and not by way of limitation, when the target is "direct", the control unit 21 of the component server 20A may select as a worker a component server 20 having a server ID whose bind key information matches the routing key.
Also, as an example and not a limitation, when the target is a “topic”, the control unit 21 of the component server 20A may use an expression indicating a string pattern in the binding key information, and designate a component server 20 having a server ID that matches the routing key as a worker.
Also, as a non-limiting example, when the target is “null (unspecified)”, the control unit 21 of the component server 20A may designate as a worker a component server 20 having a server ID whose binding key information completely matches the routing key.

In addition, in the worker search process, the control unit 21 of the component server 20A may output multiple server IDs as the search result.

When the server ID to be a worker is found, the control unit 21 of the component server 20A transmits rpc message information to the component server 20B via the communication I/F 24 based on the found server ID (A150).
Furthermore, the control unit 21 of the component server 20B receives the rpc message information from the component server 20A via the communication I/F 24 (B110).

In sending and receiving rpc message information, as a non-limiting example, the http daemon processing unit 213 of the component server 20 may send and receive information according to http. In this case, the control unit 21 of the component server 20A may send the rpc message information to the component server 20B by the POST method. Also, the control unit 21 of the component server 20B may receive the rpc message information from the component server 20A by the GET method.

The protocol used may be http/1.0, http/1.1, http/2, or any other version.

As an example and not a limitation, by using HTTP to send and receive RPC message information, the calling component server 20A (invoker) can determine whether the RPC message information has arrived at the procedure component server 20 (worker).

In addition, when sending and receiving RPC message information, communication may be performed using a protocol other than HTTP (such as, but not limited to, SSH (Secure Shell)).

In addition, when the control unit 21 of the component server 20B receives the RPC message information from the component server 20A via the communication I/F 24, the control unit 21 may transmit RPC processing information to the call destination resolution server 10 via the communication I/F 22.
When RPC processing in progress information is received from the component server 20B via the communication I/F 14, the control unit 11 of the callee resolution server 10 may, for example and not by way of limitation, update the callee management data 153 based on the received RPC processing in progress information (for example and not by way of limitation, the server role information may be set to “busy”).
Then, the control unit 11 of the call destination resolution server 10 may, for example and without limitation, not include the component server 20 whose server role information is "busy" in the worker list information.
This makes it possible to temporarily remove the component server 20B undergoing a procedure by rpc from the worker list, thereby preventing it from being selected as the procedure side by other component servers 20 in duplicate.

When the rpc message information is received from the component server 20A via the communication I/F 24, the control unit 21 of the component server 20B executes the component program processing (B130).
In the component program processing, the control unit 21 of the component server 20B calls the RPC server (worker in the narrow sense) of the messaging module 2513 in which the http messaging driver 2515 is built, based on the received rpc message information.
Then, the component program processing unit 211 of the component server 20 B executes the procedure (processing) specified in the RPC message information received via the messaging module 2513 .

As an example and not a limitation, when the component program processing is completed, the control unit 21 of the component server 20B transmits rpc processing result information including the processing result of the component program processing to the component server 20A via the communication I/F 24 (B150).
Furthermore, the control unit 21 of the component server 20A receives the RPC processing result information from the component server 20B via the communication I/F 24 (A170).

In transmitting and receiving RPC processing result information, as an example and not a limitation, the control unit 21 of the component server 20 may transmit and receive information according to HTTP, similar to the transmission and reception of RPC message information.
By using HTTP to send and receive the RPC processing result information, the component server 20 (worker) on the procedure side can determine whether or not the RPC processing result information has arrived at the component server 20A (invoker) on the calling side.

Note that an HTTP request may be generated for each transmission and reception of RPC message information and RPC processing result information, or the RPC processing result information may be transmitted and received as a response to an HTTP request generated by the transmission and reception of RPC message information.

In addition, when sending and receiving RPC processing result information, communication may be performed using a protocol other than HTTP (such as, but not limited to, SSH (Secure Shell)).

In addition, when the control unit 21 of the component server 20B transmits the RPC processing result information to the component server 20A via the communication I/F 24, the control unit 21 may transmit the RPC processing end information to the call destination resolution server 10 via the communication I/F 22.
When RPC processing end information is received from the component server 20B via the communication I/F 14, the control unit 11 of the callee resolution server 10 may, for example and not by way of limitation, update the callee management data 153 based on the received component program processing end information (for example and not by way of limitation, the server role information may be set to "worker").

In addition, when the control unit 21 of the component server 20A receives RPC processing result information from the component server 20B via the communication I/F 24, it may transmit RPC processing end information to the call destination resolution server 10 via the communication I/F 22.
When RPC processing end information is received from the component server 20A via the communication I/F 14, the control unit 11 of the callee resolution server 10 may, for example and not by way of limitation, update the callee management data 153 based on the received component program processing end information (for example and not by way of limitation, the server role information may be set to "worker").

By performing these processes, the component server 20 that has been released from the RPC can be returned to the worker list and can be selected as the procedure side by other component servers 20.

Note that, for rpc.cast communication that does not expect a response from the procedure side, as an example and not a limitation, it may be realized by omitting steps B150 and A170.
For rpc.cast communication, it can also be determined whether or not rpc message information has been received from the invoker to the worker.

In addition, in this example, the case where the server ID of component server 20B is searched for in the worker search process has been illustrated, but in the case where multiple server IDs are searched for in the worker search process, RPC message information and/or RPC processing result information may be sent and received to multiple workers in a similar manner.

FIG. 1-10 is a block diagram showing a comparison of the cooperative operations between software modules in the method proposed in the present invention and the conventional method using AMQP.
The upper part of FIG. 1-10 shows the operation when using the proposed method, that is, an HTTP messaging driver, and the lower part shows the operation when using an AMQP driver.
In the block diagrams, the contents written in numbers in circles will be represented as "((number))" for convenience in the text.

The operations in the proposed method are, by way of example and not by way of limitation, as follows: Note that the operations in the proposed method are not limited to the following operations.
((1)) An application process (for example, but not limited to, an example of a component program process) on the invoker side communicates with an RPC client of an RPC messaging client module (for example, but not limited to, an example of a messaging module) to perform RPC communication. Also, the RPC client sends RPC processing request information to an HTTP messaging driver.
((2)) The HTTP messaging driver communicates with the callee resolution service provided by the callee resolution server 10.
((3)) The callee resolution service transmits information necessary to identify the destination of the RPC procedure to the http messaging driver. As an example and not a limitation, the http messaging driver identifies the server 20B that will be the destination of the procedure (Exchange and Bind).
((4)) The HTTP messaging driver on the invoker side sends the RPC message information to the worker server 20B. Also, once the RPC message information has been sent, information indicating that the sending has been completed can be communicated to the application process via the RPC client, by way of example and not limitation.
((5)) In the RPC messaging server module on the worker side (for example, but not limited to, an example of a messaging module), the HTTP messaging driver sends the received RPC message information to the RPC server. The RPC server requests the application process on the worker side (for example, but not limited to, an example of a component program process) to perform processing based on the RPC message information.
((6)) The application process on the worker side sends the RPC processing result information to the RPC messaging server module. The information is transmitted to the HTTP messaging driver via the RPC server.
((7)) The worker-side http messaging driver sends the RPC processing result information to the invoker, server 20A. Also, once the RPC processing result information has been sent, information indicating that the sending has been completed can be communicated to the application process via the RPC server, by way of example and not limitation.
((8)) In the RPC messaging client module on the invoker side, the HTTP messaging driver sends the received RPC processing result information to the RPC client. The RPC client passes the RPC processing result information to the application process on the invoker side as a return value.

Also, the operation of the conventional approach is as follows, by way of example and not by way of limitation.
((1)) The application process on the invoker side communicates with the RPC client of the RPC messaging client module to perform RPC communication. Also, the RPC client sends RPC processing request information to the AMQP driver.
((2)) The AMQP driver issues an RPC processing request based on the RPC processing request information to a message queuing service (such as, for example and not limitation, RabbitMQ). In the message queuing service, a queue linked to the server 20B that is the destination of the procedure is identified, and the RPC message information is stored in the queue (Exchange, Bind and Queue).
((3)) In the RPC messaging server module on the worker side, the AMQP driver periodically fetches the queue of the message queuing service.
((4)) If RPC message information addressed to server 20B exists in the queue, the AMQP driver reads the RPC message information from the queue.
((5)) The AMQP driver sends the received RPC message information to the RPC server. The RPC server requests the worker application process to process the RPC message information.
((6)) The application process on the worker side sends the RPC processing result information to the RPC messaging server module. The information is transmitted to the AMQP driver via the RPC server.
((7)) The AMQP driver on the worker side sends the RPC processing result information to the message queuing service (queueing).
((8)) The message queuing service sends the RPC processing result information to the AMQP driver on the invoker side.
((9)) In the RPC messaging client module on the invoker side, the AMQP driver sends the received RPC processing result information to the RPC client. The RPC client passes the RPC processing result information to the application process on the invoker side as a return value.

From these operations, it can be seen that in the proposed method, RPC message information can be directly exchanged between the HTTP messaging driver on the invoker side and the HTTP messaging driver on the worker side. The same is true for RPC processing result information.
Therefore, if the HTTP messaging driver on the invoker side has completed the resolution of the worker to be the destination, there will be no problems with subsequent inter-process communication. Also, even if the call destination resolution service stops, the invoker side can detect the problem before sending the RPC message information. This makes it easy to have the application process execute exception handling, etc.

In contrast, in the conventional method, all RPC message information and RPC processing result information must go through a message queuing service (the message queuing service is an SPOF).
For this reason, when the message queuing service stops, it causes problems in inter-process communication in general, including RPC message information being sent and received and RPC processing result information. In addition, if some kind of modification occurs to the queue of the message queuing service, it may cause confusion in inter-process communication, resulting in an error in the application process whose cause is difficult to identify.

Furthermore, in the conventional method, the AMQP driver on the worker side needs to fetch from the queue of the message queuing service from time to time in order to receive the RPC message information sent from the invoker.
On the other hand, in the proposed method, it can be seen that RPC message information is transmitted between software modules in a straight line from the application process on the invoker side to the application process on the worker side. The same is true for RPC processing result information.
Therefore, the proposed method does not incur overhead for fetching during processing, and can reduce the load on the entire cluster running application processes.

In addition, in the proposed method, the application process on the invoker side can detect that RPC message information has arrived at the worker, and the application process on the worker side can detect that RPC processing result information has arrived at the invoker.
In contrast, the conventional method can only detect whether or not RPC message information and/or RPC processing result information has been queued in a message queuing service.
Therefore, the proposed method can accurately grasp the progress of inter-process communication, and by way of example and not limitation, can efficiently perform speculative execution in application processes. In addition, debugging operations of application processes becomes easier.

In addition, the message queuing service in the conventional method requires more complex processing than the callee resolution service. As a result, the proposed method can reduce the resources of the entire cluster that runs application processes, including services for implementing inter-process communication. In addition, the callee resolution service is simpler than the message queuing service, so it is expected to have a longer mean time between failures (MTBF) and a shorter mean time to recovery (MTTR). As a result, the reliability of the entire cluster that runs application processes can be improved.

Note that inter-process communication in the present invention is not limited to rpc.call communication or rpc.cast communication.

1-11 is a flowchart showing another example of the flow of processing executed by each device in this embodiment. In this flowchart, as an example and not a limitation, an RPC.fanout communication that does not expect a response from the procedure side is described. Also, in this flowchart, as an example and not a limitation, the component server 20A is the RPC caller (invoker), and the component server 20B, the component server 20C, the component server 20D, ... are the RPC procedure side (workers).
In this figure, from the left, there are shown a process executed by the control unit 21 of the component server 20A which is an invoker, a process executed by the control unit 11 of the called resolution server 10, a process executed by the control unit 41 of the mass calling server 40, and a process executed by the control unit 21 of the component server 20B which is a worker. Note that, for the other workers, the process executed by the control unit 21 of the component server 20B can be performed in the same manner as the process executed by the control unit 21 of the component server 20B, by way of example and not limitation.

For the sake of simplicity, this flowchart illustrates, by way of example and not limitation, a case in which there is one mass call server 40 (one broadcaster). By way of example and not limitation, there may be multiple mass call servers 40 (by way of example and not limitation, mass call server 40A, mass call server 40B, mass call server 40C, ..., etc.). In this case, different bind key information may be assigned to each mass call server 40.

Prior to the flow chart, as described above, the control unit 21 of each component server 20 transmits component program start information to the call destination resolution server 10 .
Furthermore, the control unit 11 of the call destination resolution server 10 updates the call destination management data 153 so as to designate each component server 20 as a "worker" based on the received component program start-up information, for example and not for limitation.

The control unit 41 of the mass calling server 40, by way of example and not limitation, transmits worker list request information to the call destination resolution server 10 via the communication I/F 44. Then, upon receiving the worker list request information from the mass calling server 40 via the communication I/F 14, the control unit 11 of the call destination resolution server 10 transmits the worker list information to the mass calling server 40 via the communication I/F 14. Note that the worker list information transmitted to the mass calling server 40 may include component servers 20 whose server role information is "busy."
Furthermore, the control unit 11 of the call destination resolution server 10, by way of example and not limitation, refers to the call destination management data 153 and updates the server role information of the mass call server 40 that sent the worker list request information to "broadcaster".
When the communication I/F 44 receives the worker list information from the call destination resolution server 10, the control unit 41 of the batch call server 40 updates the component server list information 455 based on the received worker list information.

In addition, when bind key information is assigned to the mass call server 40, the control unit 41 of the mass call server 40 may store a list of server IDs of component servers 20 that match the bind key information of the mass call server 40 from the received worker list information in the component server list information 455.
As a non-limiting example, in FIG. 1-6, if the bind key information of the mass call server 40 is “apple,” the component server list information 455 may store identification information for each component server 20 having server IDs “SID20A” to “SID20D” that include “apple.”

In addition, the control unit 41 of the mass call server 40 may, for example and not for limitation, update the component server list information 455 by sending worker list request information to the call destination resolution server 10 at a predetermined time (for example and not for limitation, "every hour at 00 minutes") or at predetermined intervals (for example and not for limitation, "7200 seconds").

The control unit 21 of each component server 20 may transmit component program start-up information to the mass call server 40. The control unit 41 of the mass call server 40 may then update the component server list information 455 based on the received component program start-up information.

First, the control unit 21 of the component server 20A, which is the invoker, starts executing rpc.fanout processing based on the rpc.fanout procedure in the component program, for example and not for limitation (A210).
In the rpc.fanout process, the component program processing unit 211 of the component server 20A calls an RPC client of a messaging module 2513 that includes, by way of example and not limitation, an http messaging driver 2515.

Then, the control unit 21 of the component server 20A, by way of example and not limitation, sends broadcast request information requesting information required to identify the RPC procedure destination to the call destination resolution server 10 via the communication I/F 24 in accordance with the http messaging driver 2515 (A230).

The control unit 11 of the call destination resolution server 10 then refers to the call destination management data 153, and by way of example and not limitation, transmits broadcaster information including a server ID whose server role information is "broadcaster" and bind key information to the component server 20A via the communication I/F 14 (S210). Note that the broadcaster information may also include various types of information such as the load average of each simultaneous call server 40.

When the control unit 11 of the called resolution server 10 receives broadcast request information from the component server 20A via the communication I/F 14, the control unit 11 of the called resolution server 10 may execute a worker update process.

In addition, the control unit 21 of the component server 20A may, for example and not for limitation, obtain broadcaster information from a URI indicating the called resolution server 10 via a REST API, for example and not for limitation.

When the broadcaster information is received from the call destination resolution server 10 via the communication I/F 24, the control unit 21 of the component server 20A executes a broadcaster search process (A250).
In the broadcaster search process, the control unit 21 of the component server 20A determines, by way of example and not limitation, the broadcaster (in this example, the mass call server 40) that will send the RPC message information based on the received broadcaster information and RPC processing request information.

As a more specific example, the control unit 21 of the component server 20A may, by way of example and not limitation, search for the server ID of a mass call server 40 having bind key information that satisfies the target and routing key conditions in the RPC processing request information.
As an example and not of limitation, when the target is "fan out", the control unit 21 of the component server 20A may set the mass call server 40 of the server ID whose bind key information matches the routing key as the broadcaster.
Also, as a non-limiting example, when the target is "fan out" and the routing key is "null (unspecified)," the control unit 21 of the component server 20A may designate a mass call server 40 of any server ID as the broadcaster, or may designate a mass call server 40 of a server ID with the lowest load average as the broadcaster.

The broadcaster identification information (such as, for example and not limitation, an IP address or an API server URI) may be stored by the http messaging driver 2515. The searched server ID may be referred to as the broadcaster identification information. The broadcaster identification information may be transmitted by the mass call server 40 to each component server 20 at any time, for example and not limitation.

When the server ID to be the broadcaster is found, the control unit 21 of the component server 20A transmits rpc message information to the broadcast call server 40 via the communication I/F 24 based on the found server ID (A270).
Furthermore, the control unit 41 of the mass calling server 40 receives the RPC message information from the component server 20A via the communication I/F 44 (L210).

In sending and receiving rpc message information, as a non-limiting example, the http daemon processing unit 213 of the component server 20A and the http daemon processing unit 413 of the mass call server 40 may send and receive information according to http. In this case, the control unit 21 of the component server 20A may send the rpc message information to the mass call server 40 by the POST method. Also, the control unit 21 of the mass call server 40 may receive the rpc message information from the component server 20A by the GET method.

In addition, when sending and receiving RPC message information, as an example and not a limitation, the control unit 21 of the component server 20A may send the RPC message information to a URI indicating the mass call server 40 via a REST API, as an example and not a limitation.

In addition, when sending and receiving RPC message information, communication may be performed using a protocol other than HTTP (such as, but not limited to, SSH (Secure Shell)).

By way of example and not limitation, by using HTTP to send and receive RPC message information, the calling component server 20A (invoker) can determine whether the RPC message information has reached the mass call server 40 (broadcaster).

When the RPC message information is received from the component server 20A via the communication I/F 44, the control unit 41 of the batch call server 40 executes an RPC message information amplification and transmission process (L230).
In the RPC message information amplification and transmission process, the control unit 41 of the mass call server 40, by way of example and not limitation, refers to the component server list information 455 and transmits the RPC message information via the communication I/F 44 to each component server 20 (by way of example and not limitation, component server 20A, component server 20B, component server 20C, ...) registered as a list of component servers (workers) to which the broadcaster transmits.
The control unit 21 of the component server 20B also receives the RPC message information from the mass calling server 40 via the communication I/F 44 (B110). Upon receiving the RPC message information from the mass calling server 40, the control unit 21 of the component server 20B executes component program processing (B130).

In sending and receiving rpc message information, as a non-limiting example, the http daemon processing unit 413 of the mass call server 40 and the http daemon processing unit 213 of the component server 20B may send and receive information according to http. In this case, the control unit 41 of the mass call server 40 may send the rpc message information to the component server 20B by the POST method. Also, the control unit 21 of the component server 20B may receive the rpc message information from the mass call server 40 by the GET method.

In addition, in the rpc message information amplification and transmission process, the control unit 41 of the mass call server 40 may choose not to transmit the rpc message information if the destination of the rpc message information is an invoker (in this case, the component server 20A).

In addition, when sending and receiving RPC message information, communication may be performed using a protocol other than HTTP (such as, but not limited to, SSH (Secure Shell)).

By way of example and not limitation, by using HTTP to send and receive RPC message information, the mass call server 40 (broadcaster) can determine whether the RPC message information has reached each component server 20 (worker) on the procedure side.

In addition, as a non-limiting example, when the control unit 41 of the mass call server 40 determines that RPC message information has arrived at each component server 20 on the procedure side, it may send RPC message arrival information indicating that the RPC message information has arrived to the component server 20A (invoker) on the calling side.
The RPC message arrival information may be sent each time it is determined that the RPC message information has reached each worker, or it may be sent when it is determined that the RPC message information has reached all workers.
As a result, even in rpc.fanout communication, the component server 20A (invoker) on the calling side can determine whether or not the rpc message information has reached each component server 20 (worker) on the procedure side.

Also, as a non-limiting example, when the control unit 41 of the mass call server 40 receives RPC message information from the component server 20A via the communication I/F 44, the control unit 41 may update the component server list information 455 by sending worker list request information to the called resolution server 10.

By way of example and not limitation, in RPC.fanout communication, when it is necessary to communicate with multiple workers, the invoker can send RPC message information to each worker via a broadcaster. This reduces the load on the invoker compared to when the invoker sends RPC message information directly to each worker (or issues a messaging queue). By offloading the communication load of the invoker to a broadcaster that is not directly involved in component program processing, the load on the cluster that runs the software component is reduced, improving the operational stability of the software component and speeding up processing.

Effects of the First Embodiment
In this embodiment, in a server system that performs an RPC (not limited to, but an example of inter-process communication) from a component server 20A (not limited to, but an example of a first server) that is an invoker to at least a component server 20B (not limited to, but an example of a second server) that is a worker, the server system includes a called resolution server 10 (not limited to, but an example of a resolution server) that executes a worker list information transmission process (not limited to, but an example of a process related to identifying an inter-process communication destination). Then, when the control unit 21 of the component server 20A receives worker list information (not limited to, but an example of first information) for identifying the component server 20B from the called resolution server 10, the control unit 21 transmits rpc message information (not limited to, but an example of second information) to the component server 20B based on the worker list information. Also, when the control unit 21 of the component server 20B receives rpc message information from the component server 20A, the control unit 21 of the component server 20B performs a component program process (not limited to, but an example of a first process) based on the rpc message information.
As an example of the effect of the embodiment obtained by such a configuration, the first server can identify the second server with which to perform inter-process communication from the first information received from the solution server. The first server can then directly transmit the second information for requesting processing of the inter-process communication to the second server. The second server can then directly receive the second information from the first server and execute the first processing based on the second information.
As a result, the availability of the server system can be improved.

Moreover, this embodiment shows a configuration in which RPC message information is transmitted and received based on HTTP.
As an example of an effect of the embodiment obtained by such a configuration, by transmitting and receiving the second information based on HTTP, which is a stateless protocol, the communication load on the control units of the first server and the second server can be reduced, and therefore the load related to the transmission and reception process can be reduced compared to the case where communication is based on TCP (Transmission Control Protocol) or SSH, which are stateful.
It should be noted that, by way of example and not limitation, AMQP performs communications based on TCP.

In addition, this embodiment shows a configuration in which the control unit 21 of the component server 20A, which is an invoker, determines that the component server 20B, which is a worker, has received rpc message information.
As an example of an effect of the embodiment obtained by such a configuration, it is possible to realize the first server performing exception processing based on whether the second server has received the second information, thereby improving the availability of the server system.

In this embodiment, the control unit 21 of the component server 20A receives worker list information (according to an http messaging driver) via an http messaging driver 2515 (not limited to, but an example of a messaging driver) incorporated in a messaging module 2513 (not limited to, but an example of middleware) that controls RPC communication, and controls the transmission of RPC message information.The control unit 21 of the component server 20B is configured to control the reception of RPC message information via the http messaging driver 2515 (according to the http messaging driver).
As an example of the effect of the embodiment obtained by such a configuration, by changing the messaging driver of the middleware between the first server and the second server, the method of realizing inter-process communication can be easily changed. Therefore, the user of the server system can quickly and flexibly adjust the method of realizing inter-process communication by selecting the messaging driver.

In this embodiment, the control unit 21 of the component server 20B, which is a worker, transmits RPC processing result information (not limited to this, but an example of the third information) based on the component program processing based on the RPC message information. The control unit 21 of the component server 20A receives the RPC processing result information from the component server 20B.
As an example of an effect of the embodiment obtained by such a configuration, the second server can directly transmit the third information, which is the processing result of the inter-process communication, to the first server, and the first server can directly receive the third information from the second server and complete the processing of the inter-process communication.
As a result, the availability of the server system can be improved.

Moreover, this embodiment shows a configuration in which RPC message information and RPC processing result information are transmitted and received based on HTTP.
As an example of an effect of the embodiment obtained by such a configuration, the second information and the third information are transmitted and received based on HTTP, which is a stateless protocol, so that the communication load on the control units of the first server and the second server can be reduced, and therefore the transmission and reception process can be executed more quickly than when communication is performed based on SMTP (Simple Mail Transfer Protocol) or FTP (File Transfer Protocol), which are stateful.

In addition, this embodiment shows a configuration in which the control unit 21 of the component server 20B, which is a worker, determines that the component server 20A, which is an invoker, has received the rpc processing result information.
As an example of an effect of the embodiment obtained by such a configuration, it is possible to realize the second server to execute exception processing or the like based on whether the first server has received the third information or not. As a result, it becomes easier for the user of the server system to execute system debugging or the like, and the user convenience can be improved.

In this embodiment, the control unit 21 of the component server 20A receives worker list information (according to an HTTP messaging driver) via an HTTP messaging driver 2515 (not limited to, but an example of a messaging driver) incorporated in a messaging module 2513 (not limited to, but an example of middleware) that controls RPC communication, transmits RPC message information, and receives RPC processing result information.The control unit 21 of the component server 20B is configured to transmit RPC message information (according to an HTTP messaging driver) via the HTTP messaging driver 2515, and to receive RPC processing result information.
As an example of the effect of the embodiment obtained by such a configuration, by changing the messaging driver of the middleware between the first server and the second server, the method of realizing inter-process communication can be easily changed. Therefore, the user of the server system can quickly and flexibly adjust the method of realizing inter-process communication by selecting the messaging driver.

In addition, in this embodiment, the server system includes a simultaneous call server 40 (not limited to, but an example of an amplification server) that executes an RPC message information amplification and transmission process (not limited to, but an example of a process related to requesting a process for inter-process communication) to at least the component server 20B and the component server 20C (not limited to, but an example of a third server) that are workers. Then, the control unit 21 of the component server 20A that is an invoker receives broadcaster information (not limited to, but an example of the fourth information) for identifying the simultaneous call server 40 from the call destination resolution server 10, and transmits RPC message information (not limited to, but an example of the fifth information) to the simultaneous call server 40 based on the broadcaster information. Furthermore, when the control unit 41 of the simultaneous call server 40 receives the RPC message information from the component server 20A, it transmits the RPC message information to at least the component server 20B and the component server 20C. The control units 21 of the component servers 20B and 20C are configured to execute component program processing (not limited to this, but an example of processing based on the fifth information) based on the rpc message information upon receiving the rpc message information.
As an example of the effect of the embodiment obtained by such a configuration, the first server can identify the amplification server from the fourth information received from the resolution server. Then, the first server can transmit the fifth information for requesting the processing of the inter-process communication to the amplification server only once, and can transmit the fifth information to the second server and the third server via the amplification server.
Also, the first server can directly transmit the fifth information to the amplification server, and the amplification server can directly transmit the fifth information to at least the second server and the third server.
As a result, when a request for inter-process communication processing is made to a plurality of servers, the load on the first server can be reduced compared to when the first server directly transmits the fifth information to the plurality of servers, and the availability of the server system can be improved.

Moreover, this embodiment shows a configuration in which RPC message information is transmitted and received based on HTTP.
As an example of an effect of the embodiment obtained by such a configuration, by transmitting and receiving the fifth information based on HTTP, which is a stateless protocol, the communication load on the control units of the first server and the second server can be reduced, and therefore, the transmission and reception process can be executed more quickly than in the case of communication based on a stateful protocol.

In this embodiment, the control unit 21 of the component server 20A receives broadcast information (according to the http messaging driver) via an http messaging driver 2515 (not limited to, but an example of a messaging driver) incorporated in a messaging module 2513 (not limited to, but an example of middleware) that controls RPC communication, and controls the transmission of RPC message information. The control units 21 of the component servers 20B and 20C each control the reception of RPC message information via the http messaging driver 2515 (according to the http messaging driver).
As an example of the effect of the embodiment obtained by such a configuration, by changing the messaging driver of the middleware between the first server and the second server, the method of realizing inter-process communication can be easily changed. Therefore, the user of the server system can quickly and flexibly adjust the method of realizing inter-process communication by selecting the messaging driver.

Furthermore, this embodiment shows a configuration in which inter-process communication is based on RPC.
As an example of the effect of the embodiment obtained by such a configuration, inter-process communication can be realized based on RPC, which is defined in RFC (Request For Comments) and is widely used in various systems as a standardized technology, thereby improving user convenience.

<First Modification (1)>
In the above embodiment, the worker search process is executed in the component server 20A that is the invoker, but this is not limited to this. As a non-limiting example, the worker search process may be executed in the call destination resolution server 10.

In this case, as an example and not a limitation, in FIG. 1-9, when the control unit 21 of the component server 20A starts executing the rpc.call process (A110), the control unit 21 may send worker search request information including the target and routing key in the rpc processing request information to the called resolution server 10 via the communication I/F 24.

When worker search request information is received from the component server 20A via the communication I/F 14, the control unit 11 of the callee resolution server 10 refers to the callee management data 153, by way of example and not limitation, and performs worker search processing based on each record of the server ID whose server role information is ``worker'' and the worker search request information, by way of example and not limitation.
The worker search process may be executed in the same manner as the worker search process in the control unit 21 of the component server 20A, for example and without limitation.

When the worker search process is executed, the control unit 11 of the called resolution server 10 may, by way of example and not limitation, send worker solution information including the searched server ID to the component server 20A via the communication I/F 14.
Then, the control unit 21 of the component server 20A may transmit the rpc message information to the component server 20B via the communication I/F 24 based on the received worker solution information.

By executing the worker search process on the called resolution server 10, the processing load of each component server 20 can be distributed to the called resolution server 10, which is expected to improve the processing speed of software components and enable more flexible scaling.

<First Modification (2)>
In the above embodiment, when the component server 20B that has become a worker receives the rpc message information, it executes the component program processing based on the rpc message information, but the present invention is not limited to this.
As an example and not as a limitation, the control unit 21 of the component server 20A that has become the invoker may determine that the component server 20B has received RPC message information, and if no RPC processing result information is received even after a predetermined time has elapsed (for example and not as a limitation, "60 seconds"), it may determine that some kind of trouble has occurred in the worker.

In this case, the control unit 21 of the component server 20A may, for example and not for limitation, send RPC stop request information for stopping processing based on the RPC message information sent to the worker to the component server 20B via the communication I/F 24 via an HTTP messaging driver.

In addition, the control unit 21 of the component server 20A may, for example and not for limitation, regenerate RPC processing request information based on the requested RPC.call processing in the messaging module, and, for example and not for limitation, redo the worker search processing and the RPC message information transmission processing.

In addition, in a retry worker search process, the control unit 21 of the component server 20A may determine a worker other than the worker searched for previously (e.g., component server 20B) as the destination.

This prevents deadlocks in inter-process communication and allows inter-process communication retries to be performed at the messaging module level (layer).

<First Modification (3)>
In the above embodiment, in the rpc.fanout process, the control unit 21 of the component server 20A that has become the invoker transmits the rpc message information to one general call server 40, but the present invention is not limited to this.
As a non-limiting example, in the broadcaster search process, the control unit 21 of the component server 20A may output a plurality of server IDs as a search result.
Then, the control unit 21 of the component server 20A may send RPC message information to the mass call servers 40 (for example, but not limited to, the mass call server 40A, the mass call server 40B, ..., etc.) corresponding to the multiple server IDs found as a result of the search.

This makes it possible to distribute the load on the broadcaster and quickly mediate inter-process communication even when there are a huge number of fanout workers.

Also, as a non-limiting example, different bind key information may be provided for each different mass call server 40. Then, in the broadcaster search process, the control unit 21 of the component server 20A may be able to output multiple mass call servers 40 that match the routing key as search results, similar to the worker search process.

This allows the invoker to implement inter-process communication flexibly and succinctly across many different workers.

<First Modification (4)>
In the above embodiment, the control unit 41 of the mass calling server 40 updates the component server list information 455 in advance, but the present invention is not limited to this.

As a non-limiting example, when the control unit 41 of the mass calling server 40 receives RPC message information from the component server 20A, which is the invoker, the control unit 41 may transmit worker list request information to the call destination resolution server 10 via the communication I/F 44. Then, when the control unit 11 of the call destination resolution server 10 receives the worker list request information from the mass calling server 40, the control unit 11 of the call destination resolution server 10 may transmit the worker list information to the mass calling server 40 via the communication I/F 14.
When the communication I/F 44 receives the worker list information from the call destination resolution server 10, the control unit 41 of the batch call server 40 may update the component server list information 455 based on the received worker list information.

By way of example and not limitation, the control unit 41 of the mass call server 40 may execute an RPC message information amplification and transmission process when the component server list information 455 is updated.

This allows the control unit 41 of the mass call server 40 to execute the RPC message information amplification and transmission process based on the latest worker list information, thereby preventing the RPC message information from being missed or the RPC message information from being erroneously sent to a component server 20 that has stopped functioning as a worker.

<First Modification (5)>
In the above embodiment, the rpc.fanout communication is exemplified, in which no response is expected from the procedure side, but the present invention is not limited to this. As a non-limiting example, the rpc.fanout communication may receive a response from the procedure side.

In this case, by way of example and not limitation, in FIG. 1-11, when the control unit 21 of the component server 20B executes the component program processing (B130), it may transmit RPC processing result information including the processing result of the component program processing to the component server 20A via the communication I/F 24. The same applies to other component servers that become workers.

When the control unit 21 of the component server 20B executes the component program processing, it may, for example and not by way of limitation, transmit RPC processing result information to the mass call server 40 that received the RPC message information via the communication I/F 24. Then, when the control unit 41 of the mass call server 40 receives the RPC processing result information from the component server 20B, it may transmit the RPC processing result information to the component server 20A that received the RPC message information. The same applies to the other component servers that become workers.

In addition, when the transmission and reception of the RPC message information in the RPC message information amplification and transmission process is completed (L230), the control unit 41 of the mass call server 40 may transmit and receive a response to the HTTP request associated with the transmission and reception of the RPC message information (A270: L210) to the component server 20A, which is the invoker.

That is, as an example, but not limited to, the following two patterns of implementation are possible for rpc.fanout communication that expects a response from the procedure side.
(1). RPC. Call fanout.
(2) Confirm completion of execution of .rpc.cast in fanout.

Second Example
In cloud computing, in order to improve system availability or as a disaster prevention measure, systems are sometimes operated in a redundant and distributed manner (so-called multi-region or multi-zone) by separating them into separate systems for each location where a physical server is installed (for example, but not limited to, a data center).
A second embodiment is an embodiment, by way of example and not limitation, in which an invoker can invoke workers across regions and zones (availability zones).

The contents described in the second embodiment are applicable to any of the other embodiments and other modified examples.
Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

In the second embodiment, a multi-region configuration spanning data centers will be illustrated as an example and not a limitation.
In the following, the call destination resolution server 10 belonging to data center A will be referred to as the "call destination resolution server 10'", the call destination resolution server 10 belonging to data center B will be referred to as the "call destination resolution server 10", the call destination resolution server 10 belonging to data center C will be referred to as the "call destination resolution server 10"", ... by the number of "'". The same applies to the other component servers 20 and the mass call server 40.

FIG. 2A is a block diagram showing the concept of the multi-region communication system configuration and processing flow in this embodiment.
In order to simplify the diagram, the network 30 connecting the servers is not shown. In addition, in the block diagram, the contents written in circles with numbers will be written as "((number))" for convenience in the text.
In addition, in this block diagram, as an example and not a limitation, the component server 20A' in data center A is the rpc caller (invoker), and the component server 20B'' in data center B is the rpc procedure (worker).

Furthermore, in the following, as an example and not a limitation, the connections within each data center will be referred to as network 30X (network 30A, network 30B, network 30C, ...), and the network 30 for connecting each data center will be referred to as "global network 30."

In general, the global network 30 will have lower connection performance (for example, but not limited to, higher latency and/or lower throughput) compared to the networks 30X within each data center.

In a multi-region communication system, as an example and not a limitation, in a data center A, a call destination resolution server 10', a mass call server 40', and multiple component servers 20' (component server 20A', component server 20B', component server 20C', ...) are connected via a network 30A.
Also, as an example and not a limitation, in data center B, a call destination resolution server 10'', a mass call server 40'', and multiple component servers 20'' (component server 20A'', component server 20B'', component server 20C'', ...) are connected via network 30B.
Also, as an example and not a limitation, in data center C, a call destination resolution server 10'''', a mass call server 40'''', and a plurality of component servers 20''' (component server 20A'''', component server 20B'', component server 20C''...) are connected via a network 30C.

The same applies to other data centers.

An example of the flow of processing executed by each device in this embodiment will be shown below.
Prior to the processing, as described above, in each data center, the control unit 21 of each component server 20 starts component program processing and http daemon processing. Then, the control unit 11 of the call destination resolution server 10 updates the call destination management data 153 for each server 20 in the data center, by way of example and not by way of limitation. Also, the control unit 41 of the simultaneous call server 40 updates the component server list information 455 for each server 20 across the data centers, by way of example and not by way of limitation.

((1)). The control unit 11 of the callee resolution server 10 (callee resolution server 10′, callee resolution server 10″, callee resolution server 10′″, ...) of each data center synchronizes each callee management data 153 via the global network 30, for example and not by way of limitation.
In addition, the control unit 11 of the call destination resolution server 10 may, by way of example and not by way of limitation, synchronize the call destination management data 153 at a predetermined time (by way of example and not by way of limitation, "00 seconds every minute") or at a predetermined period of time (by way of example and not by way of limitation, "60 seconds").

((2)). The control unit 21 of the server 20A' in data center A starts executing an rpc.call process based on the rpc.call procedure in the component program, for example and not for limitation. The control unit 21 of the server 20A' sends worker list request information to the call destination resolution server 10' in the same data center based on the rpc process request information according to the http messaging driver 2515, for example and not for limitation.
In addition, when the destination resolution server 10' is stopped, the control unit 21 of the server 20A' may, for example and not limitation, send the worker list request information to the destination resolution server 10 in the nearest data center (for example and not limitation, the data center with the lowest latency to the server 10 and/or the physical server located close by).

((3)) The control unit 11 of the call destination resolution server 10′ executes a worker update process, for example and not for limitation. Then, the control unit 11 of the call destination resolution server 10′ transmits worker list information to the server 20A′, for example and not for limitation.
Due to a problem such as the timing of synchronization of the callee management data 153, there is a possibility that the server 20B'' in another data center is not registered in the callee management data 153 of the callee resolution server 10'.
When receiving the worker list information from the call destination resolution server 10′, the control unit 21 of the component server 20A′ executes a worker search process. In the worker search process, as an example and not a limitation, it is assumed that the server 20B″ in another data center cannot be searched as a search result, and the worker search process fails.

If the worker search process is successful, the control unit 21 of the component server 20A' executes the rpc message information sending process.

((4)) If the worker search process fails, the control unit 21 of the component server 20A' sends the worker list request information to the call destination resolution server 10'' in the nearest data center.

((5)). The control unit 11 of the called resolution server 10'' executes a worker update process, for example and not for limitation. Then, the control unit 11 of the called resolution server 10'' transmits worker list request information to the server 20A' based on the called management data 153 of the called resolution server 10''.

((6)). Upon receiving the worker list information from the called resolution server 10'', the control unit 21 of the component server 20A' executes a worker search process. If the worker search process is successful, the control unit 21 of the component server 20A' sends the rpc message information to the component server 20B', which is the worker.

If the worker search process fails, the control unit 21 of the component server 20A' again sends the worker list request information to the call destination resolution server 10''' in the next closest data center.

This allows the control unit 21 of the worker server 20A' to minimize the use of the global network 30, which has low connection performance. In addition, in each data center, the call destination resolution server 10 operates independently, so redundancy can be maintained.

A comparison is made with the conventional method using a message queuing service.
As a non-limiting example, when configuring a cluster of component servers 20 for each data center to provide redundancy, in a single cluster system in which one message queuing service is configured across data centers, the traffic of the message queuing service communicating across data centers increases, causing the global network 30 to become a bottleneck and causing the performance of the entire cluster to hit a plateau.

In addition, in the single cluster system, all component servers 20 located in multiple data centers are connected to the message queuing service, so as the number of data centers increases, the number of servers connected to the message queuing service increases proportionally, resulting in a problem of increased load on the message queuing service.

The above problem can be solved by a multiple cluster method in which a message queuing service is configured for each data center, but by way of example and not limitation, it is desirable for the messaging module 2513 to support multiple message queuing services. In order to support multiple message queuing services in the messaging module 2513, it becomes necessary to manage, by way of example and not limitation, the mapping between the access destination of the message queuing service for each data center and the MQ cluster, the operating status of the message queuing service for each data center, etc. This causes the configuration of the messaging module 2513 to become complex, which causes a problem of an increased load on the entire program component cluster.

Furthermore, by way of example and not limitation, if messaging module 2513 does not support multiple message queuing services (for example and not limitation, the "oslo.messaging" module), it becomes necessary for the software component to support multiple message queuing services, which causes a problem of reduced convenience when realizing inter-process communication via messaging module 2513.

In contrast, the proposed method uses a multiple cluster approach that allows each data center to operate autonomously, and prioritizes calling the call destination resolution server 10 of the data center to which the invoker belongs, thereby minimizing the increase in traffic between data centers.

In addition, since the HTTP messaging driver 2515 can manage the identification information of the inter-process communication end points (invoker and worker) even when the data center is spanned, there is no need to modify the messaging module 2513 or the component processing program 251, improving the convenience of realizing inter-process communication via the messaging module 2513.

<Effects of the Second Example>
In this embodiment, the server system includes a callee resolution server 10'' (not limited to, an example of a first resolution server) belonging to a data center B (not limited to, an example of a region or zone) different from the callee resolution server 10' (not limited to, a resolution server) belonging to the data center A. Then, when the control unit 21 of the component server 20A', which is an invoker, cannot search for the server ID (not limited to, an example of identification information) of the component server 20B'' as a worker based on the worker list information (not limited to, an example of the first information) received from the callee resolution server 10' (not limited to, an example of a case where the component server 20B'' cannot be resolved), the control unit 21 receives worker list information (not limited to, an example of the sixth information) for identifying the component server 20B'' from the callee resolution server 10''. Then, the control unit 21 of the component server 20A transmits RPC message information to the component server 20B'' based on the worker list information (not limited to, an example of the sixth information) received from the callee resolution server 10''.
As an example of the effect of the embodiment obtained by such a configuration, when the first server cannot identify the second server by the first information received from the resolution server, the first server can identify the second server by using the sixth information received from the first resolution server. Therefore, the first server can specify the second server, which is the other party of the inter-process communication, by using the resolution server system in which the resolution server and the first resolution server are redundantly configured across different regions or zones.
As a result, the availability of the server system can be improved.

In this embodiment, RPC message information is sent and received based on HTTP. The control unit 21 of the component server 20A', which is an invoker, receives worker list information (not limited to, an example of the first information and the sixth information) (according to the HTTP messaging driver) via the HTTP messaging driver 2515 (not limited to, an example of a messaging driver) incorporated in the messaging module 2513 (not limited to, an example of middleware) that controls RPC communication, and controls the transmission of the RPC message information. The control unit 21 of the component server 20B'' shows a configuration in which it controls the reception of RPC message information via the HTTP messaging driver 2515 (according to the HTTP messaging driver).
As an example of the effect of the embodiment obtained by such a configuration, by changing the messaging driver of the middleware between the first server and the second server, the method of realizing inter-process communication can be easily changed. Therefore, the user of the server system can easily change the method of realizing inter-process communication by selecting the messaging driver.

In addition, in this embodiment, the component server 20A' and the called resolution server 10' belong to the same data center A (not limited to this, but an example of the same region or zone), and the control unit 21 of the component server 20A' receives worker list information from the called resolution server 10'' which has the lowest communication latency with the component server 20A' (not limited to this, but an example of this belonging to the closest region or zone).
As an example of the effect of the embodiment obtained by such a configuration, it is possible to minimize the processing delay caused by communication across regions or zones. Also, it is possible to minimize the occurrence of communication across regions or zones. As a result, it is possible to reduce the communication load generated in the entire server system while maintaining a redundant configuration based on regions or zones.

<Second Modification Example (1)>
In the above embodiment, a multi-region configuration across data centers is illustrated, but is not limited to this. By way of example and not limitation, a multi-zone configuration can be similarly realized by regarding each data center as an availability zone.
Similarly, a multi-site system using both multi-regions and multi-zones can be realized.

<Second Modification Example (2)>
In the above embodiment, the worker search process is executed in the component server 20A' that is the invoker, but this is not limited to this. As a non-limiting example, the worker search process may be executed in the call destination resolution server 10 of each data center.

Figure 2-2 is a block diagram showing the concept of the multi-region communication system configuration and processing flow in this modified example.

An example of the flow of processes executed by each device in this modified example will be shown below.
Prior to the processing, as described above, by way of example and not limitation, the callee management data 153 and the component server list information 455 may be updated for each server 20 in the data center.

((1)). The control unit 11 of the callee resolution server 10 (callee resolution server 10', callee resolution server 10'', callee resolution server 10''', ...) of each data center synchronizes the callee management data 153 of each data center via the global network 30, for example and not for limitation.

((2)). The control unit 21 of the server 20A' in the data center A starts to execute the rpc.call process based on the rpc.call procedure in the component program, for example and not for limitation. The control unit 21 of the server 20A' sends the worker search request information to the call destination resolution server 10' in the same data center based on the rpc process request information according to the http messaging driver 2515, for example and not for limitation.
In addition, when the destination resolution server 10' is stopped, the control unit 21 of the server 20A' may, for example and not limitation, send the worker search request information to the destination resolution server 10 in the closest data center (for example and not limitation, with low latency to the server 10).

((3)) The control unit 11 of the call destination resolution server 10′ executes a worker update process, for example and not for limitation. Then, the control unit 11 of the call destination resolution server 10′ executes a worker search process, for example and not for limitation, by referring to the call destination management data 153 of the call destination resolution server 10′.
In the worker search process, if the procedure side server (in this example, server 10B") cannot be found from the callee management data 153 of the callee resolution server 10' due to issues such as the timing of synchronization of the callee management data 153, the control unit 11 of the callee resolution server 10' will, by way of example and not limitation, send worker search request information to the callee resolution server 10'' in the nearest data center.

In addition, in the worker search process, if the procedure side server can be found from the callee management data 153 of the callee resolution server 10', the control unit 11 of the callee resolution server 10' sends the worker resolution information to the server 20A'.

((4)) When worker search request information is received from the call destination resolution server 10′ via the communication I/F 14, the control unit 11 of the call destination resolution server 10″, by way of example and not limitation, refers to the call destination management data 153 of the call destination resolution server 10″ and executes a worker search process.
In the worker search process, when the control unit 11 of the call destination resolution server 10'' searches for a procedure side server (in this example, server 10B'') from the call destination management data 153 of the call destination resolution server 10'', it transmits worker solution information to the server 20A'.

The control unit 11 of the called resolution server 10'' may transmit the worker resolution information to the server 20A' via the called resolution server 10'.

When worker resolution information is received from the called resolution server 10'', the control unit 21 of the component server 20A' sends the rpc message information to the worker component server 20B''.

By executing the worker search process on the call destination resolution server 10 of each data center, the processing load of each component server 20 can be distributed to the call destination resolution server 10.

<Second Modification Example (3)>
In the above embodiment, the process using the call destination resolution server 10 (as an example and not a limitation, rpc.call communication and rpc.cast communication) is illustrated, but the present invention is not limited to this. As an example and not a limitation, rpc.fanout communication using the general call server 40 may also be configured to minimize the traffic generated between data centers.

In this case, by way of example and not limitation, the component server list information 455 in the mass call server 40' may describe the RPC message information as the following elements (A)+(B):
(A): Identification information of each component server 20 that exists in the same data center as the mass paging server 40.
(B): Identification information of each of the mass paging servers 40 that exist in a data center different from the mass paging server 40 .

When the control unit 41 of the mass call server 40', which exists in the same data center as the invoker (as an example, not a limitation, the component server 20A'), receives RPC message information from the invoker, in the RPC message information amplification and transmission process, it transmits the RPC message information to (A) and (B), as an example, not a limitation.

When the control unit 41 of the mass call server 40, which exists in a data center different from the invoker, receives the RPC message information from the mass call server 40', in the RPC message information amplification and transmission process, it transmits the RPC message information to (A) as a non-limiting example.

In this way, the mass call server 40 in the data center where the invoker exists is treated as the parent, and the mass call servers 40 in other data centers are treated as children, and RPC message information is sent recursively, thereby minimizing the traffic generated between data centers.

<Other Examples>
(1) Information Processing Device In the above embodiment, the information processing device in the present disclosure has been described as the call destination resolution server 10 and/or the mass call server 40, but is not limited thereto.

Instead of having a single call destination resolution server 10 and/or a single mass call server 40, the call destination resolution server 10 and/or the mass call server 40 may be divided into multiple servers, and each of these servers may be an information processing device in the present disclosure.

In addition, instead of a server, a terminal such as a management computer that communicates with a terminal that uses a software component, or a terminal such as a management smartphone, may be the information processing device in this disclosure.

It is also possible to configure a system including multiple information processing devices, and have this system perform the various processes of the call destination resolution server 10 and/or the mass call server 40 described in the above embodiment.

(2) Others As described above, the contents described in the above embodiments, the respective modifications, and other embodiments can be applied in combination with each other.

<Other embodiments>
Another aspect of the present invention is a driver program incorporated into middleware that controls inter-process communication from a first server to at least a second server, the driver program including a process for communicating with a resolution server that executes a process related to identifying an inter-process communication destination in the inter-process communication, the driver program causing the first server to receive first information for identifying the second server from the resolution server, and based on the first information, transmitting second information to the second server for requesting processing of the inter-process communication, and causing the second server to receive the second information from the first server.

The driver program may also transmit and receive the second information based on the HyperText Transfer Protocol.

The driver program may also cause the second server to transmit third information regarding the first process based on the second information to the first server, and cause the first server to receive the third information from the second server.

The driver program may also transmit and receive the second information and the third information based on the HyperText Transfer Protocol.

The driver program may also include a process for communicating with an amplification server that executes a process for requesting the second server and at least a third server to process inter-process communication, and the driver program may cause the first server to receive fourth information for identifying the amplification server from the resolution server, and based on the fourth information, transmit fifth information for requesting the amplification server to process the inter-process communication, and cause the second server and the third server to receive the fifth information from the amplification server.

The driver program may also transmit and receive the fifth information based on the HyperText Transfer Protocol.

Reference Signs List 1 Communication system 10 Call destination resolution server 20 Component server 30 Network 40 Mass call server

Claims (16)

An information processing method for a server system performing inter-process communication from a first server to at least a second server, comprising the steps of:
the server system includes a resolution server that executes a process related to identifying an inter-process communication destination in the inter-process communication;
The first server
receiving first information for identifying the second server from the resolution server;
transmitting second information for requesting the second server to process the inter-process communication based on the first information;
The second server,
receiving the second information from the first server;
A first process is executed based on the second information. 2. The information processing method according to claim 1,
The second information is transmitted and received based on the HyperText Transfer Protocol. 3. The information processing method according to claim 2,
The first server determines that the second server has received the second information. 3. The information processing method according to claim 2,
The first server
receiving the first information via a messaging driver incorporated in a middleware that controls the inter-process communication;
Sending the second information via the messaging driver;
The second server,
The second information is received via the messaging driver. 2. The information processing method according to claim 1,
the second server transmits third information based on the first process to the first server;
The first server receives the third information from the second server. 6. An information processing method according to claim 5,
The second information and the third information are transmitted and received based on the HyperText Transfer Protocol. 7. An information processing method according to claim 6,
The second server determines that the first server has received the third information. 7. An information processing method according to claim 6,
The first server
receiving the first information via a messaging driver incorporated in a middleware that controls the inter-process communication;
Sending the second information via the messaging driver;
receiving the third information via the messaging driver;
The second server,
receiving the second information via the messaging driver;
The third information is sent via the messaging driver. 2. The information processing method according to claim 1,
the server system includes an amplification server that executes a process for requesting the second server and at least a third server to process the inter-process communication;
The first server
receiving fourth information for identifying the amplification server from the resolution server;
transmitting fifth information for requesting the amplification server to process the inter-process communication based on the fourth information;
The amplification server includes:
receiving the fifth information from the first server;
Transmitting the fifth information to at least the second server and the third server;
The second server,
receiving the fifth information from the amplification server;
Executing a process based on the fifth information;
The third server,
receiving the fifth information from the amplification server;
A process based on the fifth information is executed. 10. The information processing method according to claim 9,
The fifth information is transmitted and received based on the hypertext transfer protocol. 11. The information processing method according to claim 10,
The first server
receiving the fourth information via a messaging driver incorporated in the middleware that controls the inter-process communication;
Sending the fifth information via the messaging driver;
The second server and the third server receive the fifth information via the messaging driver. 2. The information processing method according to claim 1,
The server system further includes a first resolution server that belongs to a different region or zone from the resolution server;
The first server
receiving sixth information for identifying the second server from the first resolution server when the identification information of the second server cannot be resolved based on the first information;
The second information is transmitted to the second server based on the sixth information. 13. The information processing method according to claim 12,
the second information is transmitted and received based on a hypertext transfer protocol;
The first server
receiving the first information and the sixth information via a messaging driver incorporated in a middleware that controls the inter-process communication;
Sending the second information via the messaging driver;
The second server,
The second information is received via the messaging driver. 13. The information processing method according to claim 12,
The first server and the resolution server belong to the same region or zone;
The first server receives the sixth information from the first resolution server that belongs to the region or zone that is closest to the first server. 15. An information processing method according to any one of claims 1 to 14, comprising:
The inter-process communication is based on the remote procedure call protocol. A server system that performs inter-process communication from a first server to at least a second server,
the server system includes a resolution server that executes a process related to identifying an inter-process communication destination in the inter-process communication;
the first server includes a communication unit that receives first information for identifying the second server from the resolution server, and transmits second information for requesting the second server to process the inter-process communication based on the first information;
The second server,
A communication unit that receives the second information from the first server;
and a control unit that executes a first process based on the second information.

Images