JP6639245B2 - Server system, method and program for controlling server system. - Google Patents

Description

  The present invention relates to a server system connected to a load balancer and having a virtual server, a method for controlling the server system, and a program.

  In a client-server system including a client and a server, as the number of clients increases, the load on the server increases and the processing capacity of the entire system decreases. For this reason, a load distribution technology is provided, which is a technology for connecting a plurality of servers and making a client appear as if it is one large-scale server. In order to achieve load distribution, a load distribution device that monitors the operation status of servers and distributes requests equally to each server so that requests from clients are not biased to a specific server is required. The load balancer may be called a load balancer.

  In a conventional load balancer, there is a technique for obtaining the CPU utilization of a server and transferring a request from a client to a server having a low CPU utilization to equalize the load situation of the entire system (Patent Document 1) 1). In addition, there is a technology in which a load balancer virtually operates an application program running on a server to check whether a normal response is returned and then grasp the operating status of the system (see Patent Document 2). . The confirmation work performed to grasp the operation status of the system is called a health check.

JP 2008-94718 A JP 2012-185577 A

  The technique described in Patent Literature 1 can determine only the operation status of a server, and cannot determine whether an application running on the server normally operates. On the other hand, in the technology described in Patent Document 2, in a configuration in which a plurality of applications operate on a server, it is necessary for each application to implement a function corresponding to a health check from a load balancer.

  An object of the present invention is to perform a health check of an application in a configuration in which a plurality of applications operate on a server without implementing a function corresponding to the health check in each application.

  A server system according to an embodiment of the present invention is a server system that can communicate with a load balancer that transmits client requests in a distributed manner and includes a plurality of virtual servers, and is a transmission target of the requests. Receiving means for receiving a health check transmitted from the load balancer to each virtual server to confirm whether or not the virtual server is possible, in response to receiving the health check by the receiving means, A transmitting unit that transmits a predetermined arbitrary request to a plurality of Web applications deployed in the virtual server that has received the health check, and a response to the arbitrary request transmitted by the transmitting unit to each Web application And all the received responses are normally In response to confirming that the publication is a response indicating that it is running, and having a control means for transmitting the effect of the health check succeeds to the load balancer.

  According to the present invention, in a configuration in which a plurality of applications operate on a server, it is possible to perform a health check of an application without mounting a function corresponding to the health check in each application.

Overall system configuration diagram Computer hardware configuration diagram Load balancer software configuration diagram Server software configuration diagram Web server software configuration diagram Application server software configuration diagram Flowchart showing a series of processes in which the load balancer performs a server health check Flow chart showing the health check process performed by the Web server Flowchart showing log output processing performed by the application server

[Example 1]
Hereinafter, embodiments for carrying out the present invention will be described with reference to the drawings. FIG. 1 is a block diagram showing the overall configuration of a Web application system according to the present invention. The network 100 is a communication path that connects the client device 101, the load balancer 102, the physical server 103, and the virtual servers 104 and 105 among the components in the block diagram shown in FIG. The network 100 is a base for performing communication between components, and may be an intranet, the Internet, or another network system. The client device 101 can mutually communicate with the load balancer 102, the physical server 103, and the virtual servers 104 and 105 via the network 100 among the components in the block diagram shown in FIG.

  In the present embodiment, the description will be given on the assumption that the client device 101 is a PC (personal computer; hereinafter, referred to as PC). However, any type of terminal may be used as long as the terminal has a communication function via the network 100. The load balancer 102 is a device that suppresses the load per server constituting the Web application system. The load balancer 102 distributes a request to the Web application system transmitted from the client device 101 via the network 100 to the virtual server 104 on the physical server 103.

  The Web application system in this embodiment is described as being configured by a plurality of virtual servers 104 and 105 operating on the physical server 103. The physical server 103 is a physical server that allows the client device 101 to use a Web application via the network 100.

  The virtual servers 104 and 105 are virtual server devices realized by application software running on the physical server 103. By executing dedicated virtual machine software on the hardware of the physical server 103, a plurality of virtual server devices can be deployed. Application software configuring the Web application system is deployed on the virtual servers 104 and 105, and requests from the client device 101 are executed by the virtual servers 104 and 105. The operation status of the virtual servers 104 and 105 is monitored by the load balancer 102 as needed. Although FIG. 1 shows only the physical server 103, the number is not limited to one. It is assumed that one or more physical servers are prepared, a plurality of virtual servers are operated in each physical server, and each virtual server processes a request distributed by the load balancer 102. Of course, there may be a situation where there is one physical server 103 and only one virtual server is operating.

  FIG. 2 is a block diagram illustrating an example of a hardware configuration diagram of the client device 101, the load balancer 102, and the physical server 103 according to the present invention. The system bus 200 is a bus that interconnects the hardware. In this embodiment, unless otherwise specified, the system bus 200 propagates a control command from the CPU 203 to each piece of hardware connected to the system bus. The user interface 201 is hardware that inputs and outputs information using a display, a keyboard, a mouse, and the like. A computer without these hardware can also be connected and operated from another computer via the network 100 by remote connection or the like.

  The network interface 202 is hardware that connects to a network such as the network 100 and communicates with other computers and network devices. The CPU 203 executes programs read from the ROM 204, the RAM 205, and the secondary storage device 206 to realize each function. Each component connected by the system bus 200 is controlled directly or indirectly. The ROM 204 is a read-only storage device, and stores an installed program such as BIOS and data. The RAM 205 is a temporary memory area used as a work area for the CPU 203 to operate. The secondary storage device 206 is an external storage device typified by an HDD in which an OS as basic software and other software modules are stored. In the virtual servers 104 and 105, each hardware element shown in FIG. 2 is virtually realized by virtual machine software, and the behavior is the same as that of the physical server 103. The hardware components of the virtual servers 104 and 105 are actually reproduced by using a part of the hardware resources of the physical server 103. The details of the virtualization technology are omitted because it is a general function.

  FIG. 3 is a block diagram showing a configuration diagram of a software module of the load balancer 102 according to the present invention. These software modules are managed by the secondary storage device 206 of the load balancer 102, executed by the CPU 203, and realize each function. Descriptions of processes not directly related to this embodiment are omitted.

  The control unit 300 controls the entire load balancer 102, and instructs and manages each component of the software module. The receiving unit 301 performs a process of receiving a request transmitted from the client device 101 connected via the network 100. An example of data of a request received by the receiving unit 301 from the client device is shown in an HTTP request data table.

The HTTP request column stores the URL of the destination of the request, the HTTP method of the request, and the value of the transmission protocol of the request. In the case of the example shown in Table 1, the transmission URL is “http://webapp.com/app1/method1”, the HTTP method is “GET”, and the transmission protocol is “HTTP / 1.1”. The HTTP header column stores HTTP header information related to the request. Since it has nothing to do with the behavior in the load balancer 102, the description is omitted. The HTTP body column stores HTTP body information related to the request. Since it has nothing to do with the behavior in the load balancer 102, the description is omitted.

  The transmission unit 302 transmits the request received from the client device 101 to the virtual servers 104 and 105 via the network 100. The transmitting unit 302 transmits the response received from the virtual server 104 to the client device 101. The server information management unit 303 manages information on a virtual server to which the load balancer 102 distributes a request from the client device 101. When the receiving unit 301 receives a request from the client device 101, the transmitting unit 302 determines a virtual server to which the request is to be distributed based on the information managed by the server information management unit 303. An example of data of server information of the distribution destination virtual server managed by the server information management unit 303 is shown in a server information table.

The management ID column is a column for storing an ID assigned to uniquely manage information of a server to which the load balancer 102 distributes requests. The distribution destination server URL column is a column that stores the URL of a virtual server that is a candidate as a distribution destination of a request. The load balancer 102 transfers the request from the client device 101 to the URL registered in this column. The operation status column is a column for storing operation status information of a virtual server that is a candidate as a request distribution destination. The operation status information is acquired by a health check execution unit 305 described later. The previous confirmation date column is a column that stores the date and time when the previous health check was completed.
The method of distributing requests by the load balancer 102 is not the subject of this embodiment, and a description thereof will be omitted. In general, there are various methods such as a method of sequentially allocating the distribution destinations registered in the server information table, and a method of preferentially allocating to servers with a light load on the server as shown in Patent Document 2. . The health check setting management unit 304 manages health check setting information for a virtual server to which the load balancer 102 distributes requests from the client device 101. A data example of the health check setting information managed by the health check setting management unit 304 is shown in a health check setting information table.

The health check URL column is a column that stores a transmission destination URL of the health check request. The health check URL is described by a relative path. The timeout column is a column that stores a timeout period from when the load balancer 102 transmits a health check request to when a response is received. If a response to the health check is not returned even after the time stored in this column has elapsed, the load balancer 102 determines that the result of the health check is abnormal. The load balancer 102 avoids a situation where the request is not processed by excluding the abnormal virtual server from the request distribution target.

  The normal threshold column is a column that stores the number of times a normal response to a request is continuously received in order for the load balancer 102 to determine that the result of the health check is “normal”. When the health check execution unit 305 receives the normal response by the number of times of the value stored in the normal threshold column, it updates the value of the server operation status column in the server information table to “normal”. The abnormal threshold column is a column that stores the number of times that the load balancer 102 continuously receives an error response to a request in order to determine that the result of the health check is “abnormal”. When receiving the error responses for the number of times stored in the abnormal threshold column, the health check execution unit 305 updates the value of the operation status column of the corresponding server in the server information table to “abnormal”.

  In addition, the health check execution unit 305 of the load balancer 102 stores the date and time when the health check response was received in the value of the previous confirmation date and time column of the corresponding record in the server information table. The health check execution unit 305 transmits a health check request to each virtual server registered in the server information table. The setting of the health check request is transmitted according to the health check setting information table. Further, the health check execution unit 305 analyzes the response of the health check request, and checks whether the result of the health check is normal or abnormal. A virtual server whose health check result is normal is regarded as a virtual server to which a request transmitted from a client is to be transmitted.

  FIG. 4 is a block diagram showing a software configuration diagram of the virtual servers 104 and 105 according to the present invention. The Web server 401 is Web server software that receives a request from the client device 101. The Web server 401 executes the process received from the client device 101, generates a response from the result, and returns the response to the client device 101. Further, the Web server 401 may transfer the request received from the client device 101 to the application server 402, and return the execution result of the process in the application server 402 to the client device 101 as a response. Any process is appropriately executed by the Web server 401 depending on the content of the request from the client device 101.

  The application server 402 is application server software that processes a request from the client device 101 transferred from the Web server 401. One or more applications 403 and 404 are deployed in the application server, and the application to be executed by the application server 403 is determined according to the content of the request. That is, a plurality of applications are deployed in one virtual server. The application server 402 transfers the request execution result to the Web server 401.

  In the present embodiment, description will be made on the assumption that the Web server 401 and the application server 402 exist on the same virtual servers 104 and 105, respectively. The detailed description of the Web server 401 and the application server 402 will be described later. Further, in the present embodiment, the number of applications deployed on the application server 402 is two, but this is not intended to limit the number. The number of applications deployed on the application server 402 is not limited as long as it is one or more. In this embodiment, Table 8 shows the processing contents of the applications 403 and 404 and examples of the respective requests received.

The application column is a column for storing a value for identifying an application running on the virtual servers 104 and 105. The application URL column is a column that stores a URL value when a request is transmitted to an application. The application outline column is a column for storing specific contents realized by the application. The public function column is a column for storing a function name that the application discloses to the client device 101. The HTTP method column is a column that defines an HTTP method used when the client device 101 transmits a request to execute the function shown in the public function column. The request format column is a column that defines the format of data stored in the request body when transmitting a request for the client device 101 to execute the function shown in the public function column. When a value contrary to this definition is stored in the request body and a request is sent to each application, the application usually returns an error. For example, the application 403 is an application for managing product information, and the application 404 is an application for managing user information.

  FIG. 5 is a block diagram showing a configuration diagram of a software module of the Web server 401 according to the present invention. These software are managed by the secondary storage device 206 of the virtual servers 104 and 105, and are executed by the CPU 203 of the virtual servers 104 and 105, and each function is realized on the virtual server. The description of the processing units not directly related to the present embodiment is omitted.

  The control unit 500 controls the entire Web server 401, and instructs and manages each component of the software module. The receiving unit 501 performs a process of receiving a request transmitted from the client device 101 and the load balancer 102 connected via the network 100. The request from the client device 101 is mainly an execution request to an application deployed on the application server 402. The request from the load balancer 102 is a health check request of the server 103. The transmission unit 502 transmits a response to the client device 101 and the load balancer 102 via the network 100. Further, the transmission unit 502 transfers the received request to the application server 402 via the network 100. The health check script execution unit 503 executes a health check process when the request received by the reception unit 501 is a health check request from the load balancer 102. A data example of the request received by the receiving unit 501 is shown in the health check request table.

The HTTP method column is a column that stores the HTTP method name of the request. In the case of a health check request, a value of “GET” is stored. The request transmission source URL column stores the URL of the terminal that transmitted the request. In the case of a health check request, the URL of the load balancer 102 is stored. The Web server 401 returns the execution result of the health check request to the URL stored in the request transmission source URL column. The request transmission destination URL column stores the transmission destination URL of the request. In the case of a health check request, the URL of the health check script stored in the health check script management unit 505 of the Web server 401 is stored.

  The health check script execution unit 503 acquires a health check script from the health check request management unit 505 and a health check rule from the health check rule management unit 504 according to the health check request, and performs a health check process. The health check rule management unit 504 collectively manages the parameter values assigned to the health check script executed by the health check script execution unit 503 as a health check rule. A data example of a health check rule managed by the health check rule management unit 504 is shown in a health check rule table. The health check rule is defined for each Web application, and a corresponding health check request is transmitted to each Web application.

The rule number column is a column for storing a number for uniquely identifying a rule of a health check request transmitted from the health check script execution unit 503 to the application server 402. The HTTP method column stores an HTTP method of a health check request transmitted from the health check script execution unit 503 to the application server 402. As the value of the HTTP method stored in the HTTP method column, the value of the HTTP method corresponding to the application shown in Table 8 is stored.

  The health check request transmission destination URL column stores the transmission destination URL of the health check request transmitted from the health check script execution unit 503 to the application server 402. The values stored in this column correspond to the applications 403 and 404 running on the application server 402. Specifically, the value of the application URL column shown in Table 8 is stored. The health check request body column is a column for storing request body information of a health check request transmitted from the health check script execution unit 503 to the application server 402. The value stored in this column differs according to the value of the health check request transmission destination URL column. Specifically, information defined in the request format column corresponding to the application shown in Table 8 is stored.

  For example, when the value of the rule number column is a health check rule of “1”, the value of “ProductName” is “Multifunction machine TypeA” for the application 403 by the HTTP method “POST” according to the definition shown in Table 5. , “Name” is a request body of “MFPA001”, which means that the health check script execution unit 503 transmits a request.

  The health check success determination response code column is a response of the health check request received from the application server 402 to the request transmitted by the health check script execution unit 503 based on the health check rule, and indicates that the applications 403 and 404 operate normally. This is a value that stores the HTTP response code that is determined to be present. The value stored in this column may generally store a value other than the HTTP response code “200” which means a normal response.

  For example, when the health check script execution unit 503 transmits a request based on the health check rule whose rule number column value is “1” to the application 403, the value of “ProductName” in the request body column includes double-byte characters. I have. As indicated by the value of the request format column in Table 8, the application 403 sets the value of “ProductName” to “half-width alphanumeric characters”. Therefore, the request transmitted by the health check script execution unit 503 is invalid for the application 403. It is expected that the request will be determined to be a simple request. Therefore, the HTTP response code “400” is stored in the health check success determination response code column.

  The purpose of the health check request is to confirm that the application is running. A request based on the health check rule whose value in the rule number column is “1” is determined by the application 403 to be an invalid request. However, the fact that the judgment is made means that the application 403 operates normally and an invalid request value is correctly judged and error processing is performed.

  On the other hand, if the application 403 is not operating normally, the server cannot process the request correctly. In such a case, the 500th value of the HTTP response code indicating that an error has occurred in the application server 402 on which the application runs is returned to the client device 101. Therefore, the operating status of the application server 402 can be checked by registering a rule in which the value of the health check success determination response code column is other than the 500s in the health check rule table. The health check script management unit 505 manages a health check script executed by the health check script execution unit 503. A health check request is sent to each application by executing the check script.

  FIG. 6 is a block diagram showing a configuration diagram of a software module of the application server 402 according to the present invention. These software are managed by the secondary storage device 206 of the virtual servers 104 and 105, and are executed by the CPU 203 of the virtual servers 104 and 105 to realize each function. The description of the processing units not directly related to the present embodiment is omitted.

  The control unit 600 controls the entire application server 402, and instructs and manages each component of the software module. The receiving unit 601 performs a process of receiving a request transmitted from the client device 101 and the load balancer 102 connected via the network 100. The transmission unit 602 returns a response of the execution result of the application execution unit 603 to the Web server 401 via the network 100. The application execution unit 603 is executed by the applications 403 and 404 corresponding to the request received by the reception unit 601. The application execution unit 603 also executes a request transmitted by the Web server 401 that has received the health check request to confirm whether the application is operating normally, that is, a request transmitted according to the health check rule. Such a request is a request for confirming the health check, but is not different from the contents of a normal request different from the health check request for the applications 403 and 404. One of the points of the present invention is that by realizing the above-described configuration by the virtual server, the health check of the application can be performed even if each application does not have a function corresponding to the health check request.

  FIG. 7 is a flowchart showing a series of processing in which the load balancer 102 performs a health check on the server 103 and the virtual servers 104 and 105 running on the server 103 according to the present invention. In step S701, the health check execution unit 305 of the load balancer 102 confirms that a record is registered in the server information table managed by the server information management unit 303. Then, the health check execution unit 305 compares the value of the previous confirmation date / time column of the record with the current time to confirm whether there is a server for which the health check has not been performed. Specifically, it is checked whether the current time managed by the load balancer 102 has passed from the time in the previous confirmation date and time column by the value in the interval column of the health check setting information table. If there is a virtual server whose time has passed since the last time the health check was performed, the process proceeds to step S702. If there is no virtual server whose time has passed since the last time the health check was performed, the load balancer 102 terminates the processing once, and performs step S701 again after a certain time has passed.

  In step S702, the health check execution unit 305 creates a health check request. Specifically, the health check execution unit 305 stores the URL held by itself in the request transmission source URL of the health check request record. The health check execution unit 305 stores, in the request transmission destination URL column of the health check request record, a URL in which the value of the distribution destination server URL column of the server information table and the value of the health check URL column of the health check setting information table are linked.

  In step S703, the transmission unit 302 transmits a health check request to the virtual servers 104 and 105. In step S704, the receiving unit 501 of the Web server 401 running on the virtual servers 104 and 105 receives the health check request from the load balancer 102 and executes a health check process. The detailed flow of the health check process will be described with reference to FIG. In step S705, the receiving unit 301 of the load balancer 102 receives a health check response from the virtual servers 104 and 105. A data example of a health check response received by the receiving unit 301 is shown in a health check response table.

The HTTP status code column is a column that stores an HTTP status code representing the meaning of the response from the virtual servers 104 and 105 to the health check request. In the present embodiment, when the health check request is executed and the operation check of the virtual server succeeds, the value of the HTTP status code is returned as 200. If the operation check of the virtual server fails, the value of the HTTP status code is returned as 503. The response body column is a column that stores the value of the detailed content of the response from the virtual servers 104 and 105 to the health check request. Although details will be described later, the virtual servers 104 and 105 confirm that all the deployed applications are operating normally, and if any of the applications is not operating normally, a health check is performed at that time. An error response is returned to the load balancer 102. That is, if there is even one application that does not operate normally, the server is notified to the load balancer 102 that the server cannot function as a virtual server. As a result, it is possible to avoid a situation where a request from a client cannot be processed due to improper operation of the server.

  In step S706, the health check execution unit 305 of the load balancer 102 checks the contents of the health check response record received in step S705. If the value of the HTTP status code column is “200”, it is determined that the health check has succeeded, and the current time is stored in the value of the previous confirmation date and time column of the server information table. In addition, if the health check succeeds the same number of times as the value stored in the normal threshold column of the health check setting information table, the health check execution unit 305 sets the value of the operation status column of the server information table to “normal”. change. If the value of the HTTP status code column is other than “200”, it is determined that the health check has failed, and the current time is stored in the value of the previous confirmation date and time column of the server information table. If the health check fails consecutively for the number of times stored in the abnormal threshold column of the health check setting information table, the health check execution unit 305 changes the value of the operation status column of the server information table to “abnormal”. To "."

  In step S707, the control unit 300 of the load balancer 102 checks whether or not there is a virtual server in which the value of the operation status column of the server information table has become “abnormal” as a result of step S706. If there is a virtual server that has become “abnormal”, the process proceeds to step S708. If there is no “normal” virtual server, the process proceeds to step S701.

  In step S708, the control unit 300 of the load balancer 102 removes the virtual server recognized in step S707 from the monitoring targets of the load balancer 102, and performs a process of discarding the corresponding virtual server. Specifically, the data of the virtual server is deleted, the resources constituting the virtual server are released, and the corresponding record is deleted from the server information table. In step S709, the control unit 300 of the load balancer 102 creates a new virtual server and registers it as a monitoring target. Specifically, the data of the virtual server is newly created, and the corresponding record is registered in the server information table.

  FIG. 8 is a flowchart showing details of the health check process performed by the Web server 401 in step S704. In step S801, the receiving unit 501 of the Web server 401 receives a request from the transmitting unit 302 of the load balancer 102. In step S802, the receiving unit 501 checks whether the received request is a health check request. Specifically, the value of the HTTP method column of the request record is “GET”, the value of the request source URL column is the URL of the load balancer 102, and the value of the request destination URL column is the value of the health check URL column of the health check setting information. If they match, the receiving unit 501 determines that the received request is a health check request, and proceeds to step S803. If the request is a normal request different from the health check request, the receiving unit 501 determines that the request is a normal request to the applications 403 and 404, and proceeds to step S815. In step S803, the receiving unit 501 passes a health check request to the health check request execution unit 503.

  In step S804, the health check script execution unit 503 acquires one health check rule record from the health check rule table managed by the health check rule management unit 504. In step S805, the health check script execution unit 503 checks whether acquisition of an unexecuted health check record has succeeded. If an unexecuted health check record has been successfully acquired, the process advances to step S806. If there is no health check record in the health check rule table, or if all the health check records have been acquired and all the health check processing has been performed, the process proceeds to step S814. In step S806, the health check script execution unit 503 acquires a health check script from the health check script management unit 505. In step S807, the health check script execution unit 503 creates a request based on the value of each column of the health check rule record acquired in step S804, and transmits the request to the application server 402 via the transmission unit 502. For example, in the present embodiment, based on Table 5, a request for the HTTP method “POST” is sent to the URL “/ app1 / Product” of the application 403, and a request for the HTTP method “PUT” is sent to the URL “/ app2 / User” of the application 404. Send.

  In step S808, the receiving unit 601 of the application server 402 receives the request from the transmitting unit 502 of the Web server 401. In step S809, the application execution unit 603 refers to the value of the HTTP request column of the request received in step S808. Then, a corresponding application is selected from the applications 403 and 404 running on the application server 402. Then, the application execution unit 603 transfers the HTTP request to the corresponding application and executes the application. For example, in the present embodiment, the request of the request body with the value of “ProductName” of “Multifunction machine TypeA” and the value of “Name” of “MFPA001” is transferred from the application execution unit 603 to the application 403 by the HTTP method “POST” Will be. In accordance with the data format rules defined in the request format column of Table 8, the application 403 first checks the format of the value of the request body. Since the value of “ProductName” includes double-byte characters, the application 403 determines that the received request is an invalid request and issues an HTTP response code “400”.

  In the present embodiment, a request of a request body having a value of “99999” and a value of “HealthCheckUser” of “Name” in the HTTP method “PUT” is transferred from the application execution unit 603 to the application 404. Come. According to the data format rules defined in the request format column of Table 8, the application 404 first checks the format of the value of the request body. When the application 404 determines that the request is a normal format check, the application 404 checks whether there is user information corresponding to the value of “UserID”. At this time, if there is no user information whose “UserID” value is “99999”, an HTTP response code “404” indicating that data has not been detected is issued.

  In step S810, the application execution unit 603 creates a health check response from the execution result of step S810, and transmits the health check response to the reception unit 501 of the Web server 401 via the transmission unit 602. In step S811, the health check script execution unit 503 acquires the value of the HTTP status code column of the health check response received in step S810. In step S812, the health check script execution unit 503 compares the value of the HTTP status code column acquired in step S811 with the value of the health check success determination response code of the health check record acquired in step S805. If the values match, the process proceeds to step S804, and the health check processing based on the health check record is continued again.

  In the health check script execution unit 503, as a result of the health check process repeatedly executed, the value of the HTTP status code column acquired in step S811 and the health check success determination response code of the health check record acquired in step S805 at least once. If the values do not match, the process proceeds to step S813. For example, in the present embodiment, in step S809, responses of the HTTP status codes “400” and “404” are received from the application 403 and the application 404, respectively, and the values of the health check success determination response codes in the health check records match. I do. Therefore, it is determined that the application server 402 is operating normally, and the process proceeds to step S814. If the application server is not running when any application is executed, the HTTP status code "500" is returned, and the value of the health check success determination response code in the health check record does not match. As a result, the process proceeds to step S813. In the present embodiment, it is assumed that even if no HTTP status code is returned from all applications, a health check error is transmitted to the load balancer 102 when it is determined that at least one application is not operating normally. are doing. However, the configuration may be such that a health check error is transmitted when the HTTP status code is returned from all applications.

  In steps S813 and S818, the health check script execution unit 503 creates a health check error response indicating a failure of the health check, and transmits the response to the load balancer 102 via the transmission unit 502. In steps S814 and 818, the health check script execution unit 503 determines that the health check process based on all the health check rules registered in the health check rule table has succeeded. Then, a health check success response is created, and the response is transmitted to the load balancer 102 via the transmission unit 502. In step S815, the receiving unit 601 of the application server 402 receives the request from the transmitting unit 502 of the Web server 401. In steps S816, 817, and 818, the application execution unit 603 executes the application corresponding to the request received in step S801, creates a response from the result, and transmits the response to the load balancer 102.

As described above, according to the flowcharts shown in FIGS. 7 and 8, the operating status of the server can be grasped in consideration of the operating status of the application operating on the server. In addition, by grasping the operation status of the application according to the records registered in the health check rule table, it is possible to divert the health check using the existing function without creating a new health check function in the application Become.
[Example 2]
In the configuration of the first embodiment, although the purpose is to achieve a health check, the health check script intentionally sends a request for intentionally generating an error response to the application. Therefore, it is difficult to determine whether the application actually transmits an error response to a request from the user client or when the application transmits an error response for the purpose of health check. Specifically, an error log recorded in a log file output by an application becomes large, and it may be difficult to determine the cause of an error caused by a request from a user client. In this embodiment, a method of suppressing log output so that an error generated by a request from a health check script and an error generated by a request from an actual user client can be easily distinguished is described with reference to FIG. Show. Other parts that are not described in this embodiment are the same as those in the first embodiment.

  FIG. 9 is a flowchart showing details of the log output process when executing the corresponding application based on the request received by the receiving unit 601 of the application server 402. The process shown in this flowchart is a process that replaces steps S808 to S810 and steps S815 to S817 in FIG. 8 described in the first embodiment.

  In step S901, the receiving unit 601 of the application server 402 receives a request from the transmitting unit 502 of the Web server 401. In step S902, the receiving unit 601 acquires the URL information of the transmission source from the HTTP request column of the request. At this time, when the request transmission source is the health check script execution unit 503 of the Web server 401, the Web server 401 and the application server 402 are operating on the same server. Therefore, the value of “localhost” is stored in the HTTP request column. If the request transmission source is an arbitrary client device 101, a value other than “localhost” is stored.

  In step S903, the application execution unit 603 transfers the HTTP request to the application corresponding to the request received in step S901, and executes the application. In step S904, the application execution unit 603 checks whether the received request is a request transmitted from its own server 103. Specifically, the value of the URL acquired in step S902 is confirmed, and if it is “localhost”, it is determined that the request is a health check request transmitted from the server 103, and the process proceeds to step S906. If the value is other than “localhost”, it is determined that the request is transmitted from the client device 101, and the process proceeds to step S905.

  In step S905, the application execution unit 603 stores the log data generated during the execution of the application in the secondary storage device 206 of the server.

In step S906, the application execution unit 603 creates a response from the execution result of step S903. In step S907, the application execution unit 603 transmits a response to the reception unit 501 of the Web server 401 via the transmission unit 602. As described above, according to the flowchart illustrated in FIG. 9, it is possible to exclude the execution log information of the application generated by the health check request and leave only the execution log information of the application generated by the request from the client device 101.
[Other Examples]
The present invention is also realized by executing the following processing. That is, software (program) for realizing the functions of the above-described embodiments is supplied to a system or apparatus via a network or various storage media, and a computer (or CPU, MPU, or the like) of the system or apparatus reads the program and reads the program. This is the process to be performed.

DESCRIPTION OF SYMBOLS 100 Network 101 Client device 102 Load balancer 103 Physical server 104, 105 Virtual server

Claims (13)

A server system that can communicate with a load balancer that transmits client requests in a distributed manner and includes a plurality of virtual servers,
Receiving means for receiving a health check transmitted from the load balancer to each virtual server to confirm whether or not the virtual server can be the transmission target of the request,
A transmitting unit that transmits a predetermined request to a plurality of Web applications deployed in the virtual server that has received the health check in response to receiving the health check by the receiving unit;
In response to receiving a response to the arbitrary request transmitted by the transmission unit from each Web application and confirming that all the received responses are responses indicating that the Web application is operating normally, A control unit for transmitting to the load balancer a message indicating that the health check has succeeded.   When at least one of the received responses is a response indicating that the Web application is not operating normally, the control unit transmits a health check error to the load balancer. The server system according to claim 1, wherein:   The control unit confirms that a response received from one of the plurality of Web applications is a response indicating that the Web application is not operating normally, and responds to the remaining Web applications. 3. The server system according to claim 1, wherein a health check error is transmitted to the load balancer without waiting for reception of a response from the server.   The response indicating that the Web application is operating normally includes a response code indicating a normal response and a response code indicating a response to an invalid request, and a response code indicating that an abnormality has occurred in the Web application. The server system according to claim 1, wherein the server system does not include the server. The virtual server that has received the health check further includes a storage unit that stores any request to be transmitted to a plurality of Web applications, a health check rule defined for each Web application in the virtual server,
4. The apparatus according to claim 1, wherein the transmission unit checks a health check rule stored by the storage unit, checks an arbitrary request corresponding to a Web application, and transmits a predetermined request. 5. The server system according to any one of 4. The transmission unit, in addition to the arbitrary request related to the health check, it is possible to transmit the client request received from the load balancer,
When the Web application receives the client request, the Web application outputs log data in accordance with the processing of the client request. When the Web application receives the arbitrary request related to the health check, the Web application processes the arbitrary request. The server system according to any one of claims 1 to 5, wherein the server system does not output log data. A method for controlling a server system including a plurality of virtual servers, which is capable of communicating with a load balancer that transmits client requests in a distributed manner,
Receiving means receives a health check transmitted from the load balancer to each virtual server to confirm whether the virtual server can be a transmission target of the request,
The transmitting unit transmits a predetermined request to a plurality of Web applications deployed in the virtual server that has received the health check, in response to receiving the health check by the receiving unit,
The control unit receives a response to the arbitrary request transmitted by the transmission unit from each Web application, and confirms that all the received responses are responses indicating that the Web application is operating normally. Transmitting a health check success to the load balancer in response to the request.   When at least one of the received responses is a response indicating that the Web application is not operating normally, the control unit transmits a health check error to the load balancer. The method of claim 7, wherein   The control unit confirms that a response received from one of the plurality of Web applications is a response indicating that the Web application is not operating normally, and responds to the remaining Web applications. The method according to claim 7, wherein a notification of a health check error is transmitted to the load balancer without waiting for reception of a response from the load balancer.   The response indicating that the Web application is operating normally includes a response code indicating a normal response and a response code indicating a response to an invalid request, and a response code indicating that an abnormality has occurred in the Web application. 10. The method according to any one of claims 7 to 9, wherein is not included. The storage unit stores an arbitrary request transmitted by the virtual server to the plurality of Web applications that has received the health check, as a health check rule defined for each Web application in the virtual server,
The said transmission means confirms the health check rule saved by the said storage means, confirms any request corresponding to a Web application, and transmits a predetermined arbitrary request. The method according to any one of claims 10 to 13. The transmission unit, in addition to the arbitrary request related to the health check, it is possible to transmit the client request received from the load balancer,
When the Web application receives the client request, the Web application outputs log data in accordance with the processing of the client request. When the Web application receives the arbitrary request related to the health check, the Web application processes the arbitrary request. 12. The method according to claim 7, wherein the log data is not output. A program that can communicate with a load balancer that distributes and sends client requests and controls a server system including a plurality of virtual servers,
A receiving step of receiving a health check transmitted from the load balancer to each virtual server to check whether or not the virtual server can be the transmission target of the request;
Transmitting a predetermined request to a plurality of Web applications deployed in the virtual server that has received the health check in response to receiving the health check in the receiving step;
In response to receiving a response to the arbitrary request transmitted in the transmitting step from each Web application and confirming that all the received responses are responses indicating that the Web application is operating normally, A control step of transmitting a success of health check to the load balancer.