JP4451339B2 - Load balancing system and load balancing method - Google Patents

Description

  The present invention relates to a load distribution technique for distributing a request from a client to a plurality of systems.

In order to process a request from each client, there is a load balancing technique that operates a plurality of servers in parallel and distributes the processing so that the load among the servers is equalized. For example, Patent Literature 1 describes a server load notification system that notifies a client of a load status of a server and displays the load status of the server on a display device of the client.
JP-A-10-105497

  By the way, as the number of accesses from clients increases, resources such as servers and databases are augmented, and access requests from clients are distributed and distributed to multiple resources using a load balancer, making the entire system efficient. There is a way to make it work.

  However, when a large increase in the number of accesses is expected, it may be difficult to ensure a predetermined performance only by increasing each resource. In such a case, it is necessary to reinforce a large-scale system such as adding another set of the current system that is currently in operation. In this way, when a new system different from the current system is installed, it is necessary to distribute access from each client to either system by a predetermined method. On the client side, it is difficult to make the user conscious of whether to access the current system or the new system, and there is a possibility that the user service may be deteriorated.

  The present invention has been made in view of the above circumstances, and an object of the present invention is to distribute a request from a client among a plurality of systems without making the client side aware of the plurality of systems.

  In order to solve the above problems, the present invention is, for example, a load distribution system that includes a plurality of business systems and distributes requests from clients to the plurality of business systems. Each business system stores a user DB storing a user ID and a group to which the user ID belongs, each group, and system information for identifying the business system assigned to the group. And the system information corresponding to the user ID received by the request receiving means by referring to the user DB and the distribution table, and receiving the request including the user ID from the client. An acquisition unit to acquire, a determination unit to determine whether or not the system information acquired by the acquisition unit is system information of the own business system, and processing according to the request when determined to be system information of the own business system When the request processing means that performs the request and system information of other business systems other than the own business system The other business system to said request receiving means generates screen information for transferring the request accepted, having a transfer means for transmitting to said client.

  In the present invention, a request from a client can be distributed among a plurality of systems without making the client side aware of the plurality of systems. In the present invention, a request from each client can be transferred to the system assigned to the client.

  Embodiments of the present invention will be described below.

  FIG. 1 is an overall configuration diagram of a trading system to which an embodiment of the present invention is applied. The trade system is a system in which an investor buys and sells stocks via a network. In the trading system of this embodiment, in order to process a large amount of transaction data from each client, the processing is distributed at two sites (A site and B site).

  The illustrated trading system includes at least one client 1, a system at A site (hereinafter referred to as “A system”) 2, a system at B site (hereinafter referred to as “B system”) 3, a DNS server 4 for A site, and B And a site DNS server 5. These devices are connected by a network 9 such as the Internet.

  The A site DNS server 4 is connected to the A system 2, and the B site DNS server 5 is connected to the B system 3. The A site DNS server 4 and the B site DNS server 5 are connected to each other via the A system 2 and the B system 3.

  The client 1 has a Web browser 11, receives a user instruction, and transmits various requests to the A system 2 or the B system 3.

  The A system 2 is a three-layer system including a PL (presentation layer) server 21, a BL (business logic layer) server 22, and a DB (database) server 23. The PL server 21 includes an input receiving unit 211 that receives various requests from the client 1 and an output unit 212 that transmits response information (screen information) to the requesting client 1.

  The BL server 2 is a business processing server that processes various requests received by the PL server 2, and includes a determination unit 221, a business processing unit 222, and a transfer unit 223. The determination unit 221 determines whether the request received by the PL server 21 is a request from the client 1 assigned to the own system. If the determination unit 221 determines that the request is from the client 1 of its own system, the business processing unit 222 performs login processing and various types of processing. When the determination unit 221 determines that the request is from a client of another system, the transfer unit 223 transfers the request received from the client to the other system.

  The DB server 23 includes a data management unit 231 that manages various data, a user DB 232, and a distribution table 233. The user DB 232 is a database for managing the attributes of each user. The distribution table 233 is a table in which a department code for grouping each user into a predetermined group and system information corresponding to the department code are stored. The user DB 232 and the distribution table 233 will be described later.

  As with the A system 2, the B system 3 includes a PL server 31, a BL server 32, and a DB server 33. The PL server 31, BL server 32, and DB server 33 of the B system 3 are the same as the PL server 21, BL server 22, and DB server 23 of the A system 2, respectively.

  The DNS (Domain Name System) server 4 for the A site is a so-called name server and converts a virtual URL (Uniform Resource Locator) indicating the trading system designated by the client 1 into the URL of the A system 2 or the B system 3 To do. The A-site DNS server 4 shown in the figure includes a name resolution unit 41, a monitoring unit 42, and a name resolution table 43. The name resolution unit 41 converts the virtual URL into the URL of the A system 2 or the B system 3. The monitoring unit 42 monitors the operating states of the A system 2 and the B system 3 to which the A site DNS server 4 is connected. Note that the monitoring unit 42 monitors the operating state of the B system 3 via the A system 2. The name resolution table 43 is a table in which the virtual URL is associated with the URL of the A system 2 and the URL of the B system 3. The name resolution table 43 will be described later. Further, the DNS server 5 for the B site is the same as the DNS server 4 for the A site.

  Each of the clients 1, the A system 2 and the B system 3 server, the A site DNS server 4 and the B site DNS server 5 described above includes, for example, a CPU 901 and a memory 902 as shown in FIG. A general-purpose computer system including an external storage device 903 such as an HDD, an input device 904 such as a keyboard and a mouse, an output device 905 such as a display and a printer, and a communication control device 906 for connecting to a network. Can be used. In this computer system, the CPU 901 executes a predetermined program loaded on the memory 902, thereby realizing each function of each device.

  For example, each function of each device of the A system 2 is the CPU 901 of the PL server 21 in the case of the program for the PL server 21, the CPU 901 of the BL server 22 in the case of the program for the BL server 22, and the DB server 23. In the case of a program for use, it is realized by the CPU 901 of the DB server 23 executing it. It is assumed that the memory 902 or the external storage device 903 of the DB server 23 is used for the user DB 232 and the distribution table 233 of the DB server 23. In addition, regarding the input device 904 and the output device 905, each device is provided as necessary.

  Next, the user DB 232 of the DB servers 23 and 33 will be described. Note that the user DB 232 of the A system 2 and the user DB 232 of the B system 3 are the same DB in which the same data is registered. Each user DB 232 stores the attribute of the user who has registered as a user (opened an account) in this trading system. In the present embodiment, a user who has performed user registration is referred to as a customer.

  FIG. 3 is a diagram illustrating an example of the user DB 232. The illustrated user DB 232 has a user ID 31, a department code 32 and an account number 33 corresponding to the user ID 31. The user ID 31, the department code 32 and the account number 33 are assigned to each user when the account is opened. In the present embodiment, it is assumed that a request from each client is distributed to the A system 2 or the B system 3 using the department code 32. However, it is also possible to use other group information that allows grouping of each user ID into a predetermined group (grouping is possible) without using the department code 32.

  Next, the distribution table 233 of the DB servers 23 and 33 will be described. The distribution table 233 of the A system 2 and the distribution table 233 of the B system 3 are the same table in which the same data is registered.

  FIG. 4 is a diagram illustrating an example of the distribution table 233. The distribution table 233 shown in the figure includes a department store code 41 and site information (or system information) 42 for identifying a site assigned to the department code 41. As the site information 42, it is conceivable to use a site name, a site classification code, or the like.

  Next, the name resolution table 43 of the A site DNS server 4 and the B site DNS server 5 will be described. The name resolution table 43 of the A site DNS server 4 and the name resolution table 43 of the B site DNS server 5 are basically the same table in which the same data is registered.

  FIG. 5 is a diagram showing an example of the name resolution table 43. The name resolution table 43 is a table for converting a virtual URL of this trading system into a real URL of the A system 2 or the B system 3. The illustrated name resolution table 43 has two real URLs 52 for the A system and the B system for one virtual URL 51. The virtual URL 51 is a virtual URL of this trading system that is input to the Web browser 11 of the client 1. By using the virtual URL, the client side can access the trading system without being aware of the two systems (A system 2 and B system 3) provided in the trading system.

  The name resolution table 43 has an initial access flag 53 and a failure flag 54 for each real URL 52. The initial access flag 53 is a flag for identifying (specifying) the system of the site to be accessed first when each client accesses this trading system. In the illustrated example, the system that is accessed for the first time is the A system 2 in which “ON” is set in the initial access flag 53.

  The failure flag 54 is a flag for identifying whether the A system 2 and the B system 3 are in failure. In the illustrated example, “ON” indicates that a failure has occurred, and “OFF” indicates that the device is operating normally. The monitoring unit 42 checks the operating state of each device of the A system 2 and the B system 3 at a predetermined timing, and when a failure is detected, changes the failure flag from “OFF” to “ON”. In the illustrated example, it is assumed that “OFF (normal)” is set in both the A system 2 and the B system 3.

  Next, name resolution processing of the A site DNS server 4 and the B site DNS server 5 will be described.

  First, when a local DNS server (not shown) receives a virtual URL of the trading system from the Web browser 11 of the client 1, a name resolution request (real URL request) of the virtual URL is sent to the A-site DNS server 4 and B It transmits to the site DNS server 5. Then, the A site DNS server 4 and the B site DNS server 5 each perform the name resolution processing shown in FIG. 6 and transmit a predetermined real URL to the local DNS server.

  Then, the local DNS server adopts the real URL acquired from the DNS server 4 or 5 with the faster response. Then, the local DNS server acquires an IP address corresponding to the actual URL from the correspondence table of the local DNS server (or a higher DNS server (not shown)), and transmits the IP address to the requesting client 1. The correspondence table is a table in which URLs and IP addresses are associated with each other. As a result, even if one of the A site DNS server 4 and the B site DNS server 5 fails, the local DNS server obtains the actual URL from the other normal servers 4 and 5. be able to.

  FIG. 6 is a process flow diagram of name resolution processing performed by the A site DNS server 4 and the B site DNS server 5, respectively.

  First, the name resolution part 41 of each DNS server 4 and 5 receives a name resolution request from a local DNS server (S21). It is assumed that the virtual URL of this trading system is specified in the name resolution request. Then, the name resolution unit 41 refers to the name resolution table 43 (see FIG. 5), and identifies the actual URL whose initial access flag is “ON” (S22).

  Then, the name resolution unit 41 refers to the failure flag corresponding to the specified actual URL, and determines whether or not the system of the actual URL is operating normally (S23). When the failure flag of the specified real URL is normal (OFF) (S23: YES), the name resolution unit 41 transmits the real URL specified in S22 to the local DNS server (S24). On the other hand, when the failure flag of the specified real URL is failure (ON) (S23: NO), the name resolution unit 41 refers to the failure flag of the other real URL (the real URL other than the specified real URL). If the failure flag of the other real URL is normal, the name resolution unit 41 transmits the other real URL to the local DNS server (S25).

  In this way, when the name resolution unit 41 refers to the failure flag in the name resolution table 43 and one of the systems has a failure, the actual URL of the other normally operating system is changed to the local DNS. Can be sent to the server.

  Next, the process at the time of login to this trade system will be described.

  It is assumed that there are two types of users, customers and visitors, in the user of this embodiment. It is assumed that the customer is a user who has performed user registration (account opening) in the trade system as described above, and has obtained a user ID, a password, and the like in advance. Visitors are an unspecified number of users who have not registered with the system.

  In this embodiment, it is assumed that the request transmitted from the client 1 used by the visitor can be processed by either the A system 2 or the B system 3. On the other hand, it is assumed that a request transmitted from the client 1 used by a customer can be processed only by one of the systems assigned to each department code (group) to which the customer belongs.

  FIG. 7 is a processing flow diagram when logging into the trading system. The illustrated processing flow is a processing flow diagram when the user is a customer.

  First, the Web browser 11 of the client 1 receives a user instruction and transmits a login request in which a virtual URL is specified to the network 9. Then, as described with reference to FIGS. 5 and 6, the Web browser 11 acquires the IP address of the actual URL transmitted from the DNS server 4 for the A site or the DNS server 5 for the B site from a local DNS server (not shown). To do. In the illustrated process, the Web browser 11 acquires the IP address of the A system 2 (that is, the PL server 21).

  Then, the Web browser 11 first accesses the A system 2 using the acquired IP address, acquires screen information of the top page (first displayed screen) from the A system 2, and displays the top page screen. It is assumed that it is outputting to the output device (S41). It is assumed that the screen of the top page has a login part for the customer to log in. In the login portion, a user ID input field, a password input field, and a login button are displayed.

  The customer inputs the user ID and password and clicks (presses) the login button. The web browser 11 receives a click (event) of the login button, and transmits a login request including the input user ID and password to the PL server 21 of the A system 2 (S42).

  The input reception unit 211 of the PL server 21 of the A system 2 receives a login request from the client 1 and delivers the login request to the BL server 22. The determination unit 221 of the BL server 22 acquires site information of the user ID included in the accepted login request (S43). That is, the determination unit 221 accesses the DB server 23 and first acquires a department store code of the user ID from the user DB 232. The data management unit 231 of the DB server 23 searches the user DB 232 (see FIG. 3), identifies the department code of the user ID, and sends the identified department code to the BL server 22. Then, the determination unit 221 acquires the site name corresponding to the acquired department store code from the distribution table 233 of the DB server 23. That is, the data management unit 231 of the DB server 23 searches the distribution table 233 (see FIG. 4), specifies site information corresponding to the department code, and sends the specified site information to the BL server 22.

  Then, the determination unit 221 of the BL server 22 determines whether the acquired site information is the site information of its own site (“A site” in the case of illustration) (S44). It is assumed that site information (“A site”) of the BL server 22 is stored in the memory of the BL server 22 or the external storage device. When the acquired site information is “A site”, the determination unit 221 determines that the site is the own site, and when the acquired site information is “B site”, the determination unit 221 determines that the site is another site.

  If the determining unit 221 determines that the site information is the site information of the own site (S44: YES), the business processing unit 222 performs a predetermined authentication process (such as checking a password or an account number). If the authentication is successful, the business processing unit 222 generates screen information of a login completion screen and sends the generated screen information to the PL server 21 (S45). The output unit 212 of the PL server 21 receives the screen information of the login completion screen and transmits it to the client 1 that is the login request source via the network 9. The screen information is described in a markup language such as HTML (HyperText Markup Language) or XML (eXtensible Markup Language). Then, the Web browser 11 of the client 1 receives the screen information of the login completion screen and outputs the login completion screen to the output device (S53).

  On the other hand, when the determination unit 221 determines that the site information is the other site (S44: NO), the transfer unit 223 generates screen information of the redirect screen and sends it to the PL server 21 (S46). The redirect screen is a screen for transferring a login request to the system of another site (B site), and is a white screen on which nothing is displayed. The transfer unit 223 embeds a script (program) to be executed on the Web browser 11 side in the screen information of the redirect screen described using HTML or the like. The transfer unit 223 also embeds the POST variable (argument) of the script in the screen information of the redirect screen.

  The POST variable includes the user ID and password included in the login request in S42 and the URL of the other site (B site). It is assumed that the URL of another site is stored in advance in the memory of the BL server 22 or the external storage device. In addition, the transfer unit 223 embeds such a POST variable in the screen information as hidden data. That is, in the case of screen information described using HTML, the transfer unit 223 uses “TYPE = hidden” of the “INPUT” tag to display hidden data (POST variable) that is not displayed on the output device of the client 1 as the client. 1 to send. The script executed by the Web browser 11 will be described later.

  Then, the output unit 212 of the PL server 21 transmits the screen information of the redirect screen received from the BL server 22 to the client 1 via the network 9.

  The Web browser 11 of the client 1 receives the screen information of the redirect screen, analyzes the screen information and displays it on the output device (S47), and executes the script included in the screen information (S48). The script included in the screen information of the redirect screen detects the timing (event) when the redirect screen is displayed (loaded) on the output device of the client 1 in the Web browser 11 and transfers the login request to another site. It is what you want to do.

  Accordingly, the Web browser 11 transmits a login request including the user ID and password included in the post variable to the URL of the other site (B site) included in the post variable by executing the script included in the screen information. . The redirect screen is a white screen on which nothing is displayed. For this reason, the time required for the Web browser 11 to analyze the screen information and display the redirect screen on the output device is very short (instant). Accordingly, the user can automatically transfer the login request to another site without recognizing the redirect screen displayed for a moment on the output device of the client 1.

  Then, the input reception unit 211 of the PL server 31 of the other site (B site) receives the login request transferred from the client 1 and delivers the login request to the BL server 32. And the discrimination | determination part 221 of BL server 32 acquires the site information of the user ID contained in the received login request similarly to S43. And the discrimination | determination part 221 discriminate | determines whether the acquired site information is site information of an own site similarly to S44 (S50). Note that the site information (B site) of the BL server 32 is stored in the memory of the BL server 32 or the external storage device. When the acquired site information is “B site”, the determination unit 221 determines that the site is the own site. In addition, when the acquired site information is “A site”, the determination unit 221 determines that this login request is a log-in request transferred from the A site and is an error.

  When the determination unit 221 determines that the site is the own site (S50: YES), the business processing unit 222 performs a predetermined authentication process as in S45, and generates screen information of a login completion screen. Then, the task processing unit 222 sends the generated screen information of the login completion screen to the PL server 31. The output unit 212 of the PL server 31 receives the screen information of the login completion screen, and transmits it to the client 1 that is the login request source via the network 9 (S51). The Web browser 11 of the client 1 receives the screen information of the login completion screen and outputs the login completion screen to the output device (S53).

  On the other hand, when the determination unit 221 determines an error (S50: NO), the business processing unit 222 performs a predetermined error process (S52). That is, for example, the job processing unit 222 transmits an error message to the client 1, stores error log information in a memory or an external storage device, or sends an error message to a failure server (not shown) that performs error processing. Perform error handling such as sending.

  By performing the illustrated login process, the client side (user) can log in to the target system without being aware of the system assigned to him / her.

  When the user is a visitor, the Web browser 11 of the client 1 transmits a login request in which a virtual URL is specified to the network 9, and the DNS server 4 for the A site or the DNS server 5 for the B site transmits from the local DNS server. Obtain the IP address of the actual URL that was sent. In the case of the name resolution table 43 shown in FIG. 5, the Web browser 11 first accesses the A system 2, receives screen information of the top page from the A system 2, and displays the screen of the top page on the output device. . In the case of a visitor, processing can be performed by either the A system 2 or the B system 3. Therefore, when the A system is in failure, the A site DNS server 4 or the B site DNS server 5 transmits the URL of the B system, so that the Web browser 11 accesses the B system and performs processing in the B system. Assumed to be performed.

  The embodiment of the present invention has been described above.

  In the present embodiment, when receiving a request from a user (customer) other than its own site, the BL servers 22 and 32 of each system generate screen information of a redirect screen and transmit it to the requesting client. The client automatically executes the script included in the screen information of the redirect screen to automatically transfer the login request to the system of another site (site allocated to the user). This makes it possible to distribute requests from clients among a plurality of systems without making the client side aware of the plurality of systems. Further, since the login request is transferred as necessary by simply inputting the user ID and password once, the operation load on the user is not increased.

  In addition, the script included in the screen information of the redirect screen according to the present embodiment detects the display of the white screen redirect screen and transfers the login request. Thereby, login information can be transferred in an instant without making the user who uses the client 1 aware of the presence of the redirect screen.

  In addition, the trading system of the present embodiment includes the DNS server 4 for the A site and the DNS server 5 for the B site, and converts the virtual URL of the trading system into the actual URL of the A system 2 or the B system 3. Thereby, the client 1 can access a predetermined system without being aware of the two systems included in the present trading system.

  In addition, the name resolution table (see FIG. 5) of the present embodiment has a failure flag. Thereby, when a failure occurs in one system, the URL of the other normally operating system can be transmitted. In this case, regarding a visitor request that can be processed by both the A system 2 and the B system 3, the processing can be continued in either system.

In addition, this invention is not limited to said embodiment, Many deformation | transformation are possible within the range of the summary. For example, the name resolution table (see FIG. 5) of the above embodiment is a table for converting a virtual URL into a real URL. However, the present invention is not limited to this, and the name resolution table may further include an IP address corresponding to the actual URL. In this case, the name resolution unit 41 of each DNS server 4, 5 converts the virtual URL into the IP address of the A system 2 or the IP address of the B system 3.

It is a figure showing the whole trade system composition to which one embodiment of the present invention was applied. It is a figure which shows the hardware structural example of each apparatus. It is a figure which shows an example of user DB. It is a figure which shows an example of a distribution table. It is a figure which shows an example of a name resolution table. It is a processing flow figure of the name resolution process of a DNS server. It is a processing flow figure of login processing.

Explanation of symbols

1: Client, 11: Web browser, 2: Site A system, 21: PL server, 211: Input reception unit, 212: Output unit, 22: BL server, 221: Discrimination unit, 222: Business processing unit, 223: Transfer unit, 23: DB server, 231: Data management unit, 232: User DB, 233: Distribution table, 3: B site system, 31: PL server, 32: BL server, 33: DB server, 4: A DNS server for site, 41: name resolution unit, 42: monitoring unit, 43: name resolution table, 5: DNS server for B site, 9: network

Claims (4)

A load balancing system that has a plurality of business systems, distributes requests from clients to the plurality of business systems, and performs processing;
Each of the plurality of business systems includes:
A user DB storing a user ID and a group to which the user ID belongs;
A distribution table storing each group and system information for identifying the business system assigned to the group;
Request accepting means for accepting a request including a user ID from the client;
An acquisition unit that acquires system information corresponding to the user ID received by the request reception unit with reference to the user DB and the distribution table;
Determining means for determining whether the system information acquired by the acquiring means is system information of a self-service system;
If it is determined that the system information of the own business system, request processing means for performing processing according to the request;
If it is determined that the system information of the other business system other than the own business system, the transfer means for generating redirect screen information for transferring the request received by the request receiving means to the other business system, and transmitting to the client; Have
Name servers connected to each business system
A name resolution table storing address information of each of the plurality of business systems;
Monitoring means for monitoring operating states of the plurality of business systems;
The virtual address information of the load balancing system transmitted by the client is received, and the address information determined to be operating normally by the monitoring unit is identified from the business system address information stored in the name resolution table. And a name resolution means for transmitting the load distribution system. The load distribution system according to claim 1,
The name resolution table includes a first flag for identifying whether to access first for each address information of the business system, and a second flag for identifying whether the system is operating normally. And remember further,
The monitoring unit updates a second flag of the name resolution table according to an operating state of the plurality of business systems;
The name resolution means receives the virtual address information, refers to the name resolution table, and if the second flag of the address information in which the first flag is set to on is normal, the name resolution means And when the second flag of the address information in which the first flag is set to ON is faulty, the second flag transmits other normal address information. . The load distribution system according to claim 1 or 2,
The redirect screen information includes a user ID included in the request, address information of the other business system, and a program to be executed by the client.
The program, on the client, characterized in that the redirection screen of the redirect screen information by detecting that displayed on the display device of the client, the address information of the other business system as a destination, to transfer the request Load balancing system. A load balancing method that distributes requests from clients to multiple business systems for processing.
Each of the plurality of business systems includes:
A user DB storing a user ID and a group to which the user ID belongs;
A distribution table storing each group and system information for identifying the business system assigned to the group, and a processing unit,
The processor is
A request receiving step for receiving a request including a user ID from the client;
An acquisition step of referring to the user DB and the distribution table and acquiring system information corresponding to the user ID received in the request reception step;
A determination step of determining whether or not the system information acquired in the acquisition step is system information of the own business system;
If it is determined that the system information of the own business system, a request processing step for performing processing according to the request;
If it is determined that the system information of the other business system other than the own business system, the transfer step of generating redirect screen information for transferring the request received in the request reception step to the other business system, and transmitting to the client; And
Name servers connected to each business system
A name resolution table storing address information of each of the plurality of business systems;
A monitoring step for monitoring an operating state of the plurality of business systems;
Name that receives virtual address information sent by the client, identifies address information determined to be operating normally in the monitoring step from address information of the business system stored in the name resolution table, and sends the name And a solution step.

Images