JP6639245B2 - サーバシステム、サーバシステムを制御する方法およびプログラム。 - Google Patents

Description

本発明は、ロードバランサに接続され、仮想サーバを備えたサーバシステム、サーバシステムを制御する方法およびプログラムに関する。

クライアントとサーバから構成されるクライアント・サーバシステムにおいて、クライアントの数が増加するにつれサーバの負荷が増大しシステム全体の処理能力が低下する。このため、複数のサーバを連結し、クライアントに対してはあたかも１台の大規模なサーバであるかのようにみせるための技術である負荷分散技術が提供されている。負荷分散を実現するためにはサーバの稼働状況を監視し、クライアントからのリクエストが特定のサーバに偏らないようにリクエストを各サーバに均等に振り分ける負荷分散装置が必要である。負荷分散装置は、ロードバランサと呼称することもある。

従来のロードバランサにおいては、サーバのＣＰＵ利用率を取得して、ＣＰＵ利用率の低いサーバに対してクライアントからのリクエストを転送することでシステム全体の負荷状況を均等にする技術がある（特許文献１参照）。また、ロードバランサは、サーバで稼働するアプリケーションプログラムを仮想的に動作させて、正常な応答が返ってくるかどうかを確認したうえでシステムの稼働状況を把握する技術がある（特許文献２参照）。システムの稼働状況を把握するために行う確認作業をヘルスチェックと呼ぶ。

特開２００８−９４７１８号公報 特開２０１２−１８５５７７号公報

特許文献１に記載の技術はサーバの稼働状況までしか判別できず、サーバ上で動作するアプリケーションが正常に動作するかどうかは判断できない。一方、特許文献２に記載の技術は、サーバ上で複数のアプリケーションが動作するような構成において、それぞれのアプリケーションがロードバランサからのヘルスチェックに対応する機能を実装する必要がある。

本発明では、サーバ上で複数のアプリケーションが動作する構成において、各アプリケーションにヘルスチェックに対応する機能を実装することなく、アプリケーションのヘルスチェックを行うことを目的の１つとする。

本発明の一実施形態に係るサーバシステムは、クライアントのリクエストを分散して送信するロードバランサと通信可能であり、複数の仮想サーバを備えたサーバシステムであって、前記リクエストの送信対象とすることが可能な仮想サーバであるか否かを確認するため、前記ロードバランサから各仮想サーバに対し送信されるヘルスチェックを受信する受信手段と、前記受信手段によりヘルスチェックを受信したことに応じて、前記ヘルスチェックを受信した仮想サーバ内に配備される複数のＷｅｂアプリケーションに対し、予め決められた任意のリクエストを送信する送信手段と、前記送信手段により送信された任意のリクエストに対するレスポンスを各Ｗｅｂアプリケーションから受信し、受信した全てのレスポンスが正常にＷｅｂアプリケーションが稼働していることを示すレスポンスであることを確認したことに応じて、前記ロードバランサにヘルスチェック成功の旨を送信する制御手段と、を有することを特徴とする。

本発明では、サーバ上で複数のアプリケーションが動作する構成において、各アプリケーションにヘルスチェックに対応する機能を実装することなく、アプリケーションのヘルスチェックを行うことが可能となる。

システム全体構成図 コンピュータハードウェア構成図 ロードバランサソフトウェア構成図 サーバソフトウェア構成図 Ｗｅｂサーバソフトウェア構成図 アプリケーションサーバソフトウェア構成図 ロードバランサがサーバのヘルスチェックを行う一連の処理を示したフローチャート Ｗｅｂサーバが実施するヘルスチェック処理を示したフローチャート アプリケーションサーバが実施するログ出力処理を示したフローチャート

［実施例１］
以下、本発明を実施するための形態について図面を用いて説明する。図１は、本発明に係るＷｅｂアプリケーションシステムの全体構成を示すブロック図である。ネットワーク１００は、図１に示すブロック図の各構成要素のうちクライアント装置１０１、ロードバランサ１０２、物理サーバ１０３、仮想サーバ１０４、１０５を接続する通信経路である。ネットワーク１００は、各構成要素間で通信を行うための基盤であって、イントラネット、インターネットもしくはその他のネットワークシステムであっても構わない。クライアント装置１０１は、図１に示すブロック図の各構成要素のうち、ネットワーク１００を介してロードバランサ１０２、物理サーバ１０３、仮想サーバ１０４、１０５と相互に通信可能である。

本実施例においては、クライアント装置１０１はＰＣ（パーソナルコンピュータ。以降、ＰＣと呼称する。）を前提に説明を進めるが、ネットワーク１００を介した通信機能を有する端末であれば種別は問わない。ロードバランサ１０２は、Ｗｅｂアプリケーションシステムを構成するサーバ１台あたりの負荷を抑える装置である。ロードバランサ１０２は、ネットワーク１００を介して、クライアント装置１０１から送信されるＷｅｂアプリケーションシステムへのリクエストを、物理サーバ１０３上の仮想サーバ１０４、に振り分ける。

本実施例におけるＷｅｂアプリケーションシステムは物理サーバ１０３で稼働する複数台の仮想サーバ１０４、１０５によって構成されるものとして説明する。物理サーバ１０３は、ネットワーク１００を介してクライアント装置１０１にＷｅｂアプリケーションの利用させる物理サーバである。

仮想サーバ１０４、１０５は、物理サーバ１０３上で稼働するアプリケーションソフトウェアによって実現される仮想サーバ装置である。物理サーバ１０３のハードウェアにて専用の仮想マシンソフトウェアを実行することによって複数の仮想的なサーバ装置を配備することが可能となる。Ｗｅｂアプリケーションシステムを構成するアプリケーションソフトウェアは仮想サーバ１０４、１０５に配備し、クライアント装置１０１からのリクエストは仮想サーバ１０４、１０５が実行する。仮想サーバ１０４、１０５の稼働状況は随時ロードバランサ１０２によって監視される。なお、図１では物理サーバ１０３のみを記載しているが、その台数を１台に限定するものではない。１台以上の複数台の物理サーバを用意し、夫々の物理サーバ内に複数の仮想サーバを稼働させ、夫々の仮想サーバがロードバランサ１０２により振り分けられるリクエストを処理する構成を想定している。無論、物理サーバ１０３が１台で、仮想サーバが１つのみ稼働している状況であっても良い。

図２は、本発明に係るクライアント装置１０１、ロードバランサ１０２、物理サーバ１０３のハードウェア構成図の一例を示すブロック図である。システムバス２００は、各ハードウェアを相互に接続するバスである。本実施例においては特に断らない限り、システムバス２００はＣＰＵ２０３からの制御命令を、システムバスに接続された各ハードウェアに伝播させるものとする。ユーザインタフェース２０１は、ディスプレイ、キーボード、マウスなどによる情報の入出力を行うハードウェアである。これらのハードウェアを備えないコンピュータは、リモート接続などにより、他のコンピュータからネットワーク１００を介して接続および操作することも可能である。

ネットワークインターフェース２０２は、ネットワーク１００などのネットワークに接続して、他のコンピュータやネットワーク機器との通信を行うハードウェアである。ＣＰＵ２０３は、ＲＯＭ２０４、ＲＡＭ２０５、二次記憶装置２０６から読み込んだプログラムを実行し、各機能を実現する。システムバス２００で接続される各構成要素を直接的、あるいは間接的に制御する。ＲＯＭ２０４は、読み込み専用の記憶装置であり、ＢＩＯＳ等の組込済みプログラムおよびデータが記録されている。ＲＡＭ２０５は、ＣＰＵ２０３が動作するためのワーク領域として利用される一時メモリ領域である。二次記憶装置２０６は、基本ソフトウェアであるＯＳやその他ソフトウェアモジュールが記憶されているＨＤＤに代表されるような外部記憶装置である。なお、仮想サーバ１０４、１０５においては、図２に示した各ハードウェア要素が仮想マシンソフトウェアによって仮想的に実現され、その挙動は物理サーバ１０３と同様の挙動をとるものとする。仮想サーバ１０４、１０５の夫々のハードウェア要素は、実際は物理サーバ１０３のハードウェアリソースの一部を利用し再現しているものである。仮想化の技術に関しては一般的な機能であるため詳細は割愛する。

図３は、本発明に係るロードバランサ１０２のソフトウェアモジュールの構成図を示すブロック図である。これらのソフトウェアモジュールはロードバランサ１０２の二次記憶装置２０６で管理され、ＣＰＵ２０３により実行され、各機能が実現する。なお、本実施例と直接関係のない処理については記載を省略する。

制御部３００は、ロードバランサ１０２の全体を制御し、ソフトウェアモジュールの各構成要素に対する指示および管理を行う。受信部３０１は、ネットワーク１００を介して接続されるクライアント装置１０１から送信されるリクエストの受信処理を行う。受信部３０１がクライアント装置から受信するリクエストのデータ例をＨＴＴＰリクエストデータテーブルに示す。

ＨＴＴＰリクエストカラムには、リクエストの送信先ＵＲＬ、リクエストのＨＴＴＰメソッド、リクエストの送信プロトコルの値が格納される。表１に示した例の場合、送信ＵＲＬは「ｈｔｔｐ：／／ｗｅｂａｐｐ．ｃｏｍ／ａｐｐ１／ｍｅｔｈｏｄ１」、ＨＴＴＰメソッドは「ＧＥＴ」、送信プロトコルは「ＨＴＴＰ／１．１」となる。ＨＴＴＰヘッダカラムには、リクエストに関連するＨＴＴＰヘッダ情報が格納される。ロードバランサ１０２における挙動とは関係のないため、説明を省略する。ＨＴＴＰボディカラムには、リクエストに関連するＨＴＴＰボディ情報が格納される。ロードバランサ１０２における挙動とは関係のないため、説明を省略する。

送信部３０２は、ネットワーク１００を介して、仮想サーバ１０４、１０５にクライアント装置１０１から受信したリクエストを送信する。また、送信部３０２は、仮想サーバ１０４から受信したレスポンスをクライアント装置１０１に送信する。サーバ情報管理部３０３は、ロードバランサ１０２がクライアント装置１０１からのリクエストの振り分け対象となる仮想サーバの情報を管理する。受信部３０１がクライアント装置１０１からリクエストを受信した場合には、送信部３０２はサーバ情報管理部３０３で管理する情報に基づきリクエストの振り分け先となる仮想サーバを決定する。サーバ情報管理部３０３で管理される振り分け先の仮想サーバのサーバ情報のデータ例をサーバ情報テーブルに示す。

管理ＩＤカラムは、ロードバランサ１０２がリクエストの振り分けを行うサーバの情報を一意に管理するために付与されたＩＤを格納するカラムである。振り分け先サーバＵＲＬカラムは、リクエストの振り分け先として候補となる仮想サーバのＵＲＬを格納するカラムである。ロードバランサ１０２は、本カラムに登録されているＵＲＬにクライアント装置１０１からのリクエストを転送する。稼働状況カラムは、リクエストの振り分け先として候補となる仮想サーバの稼働状況情報を格納するカラムである。稼働状況情報は後述するヘルスチェック実行部３０５によって取得される。 前回確認日時カラムは、前回のヘルスチェックが完了した日時を格納するカラムである。
ロードバランサ１０２によるリクエストの振り分けの方法については、本実施例の対象ではないため説明を省略する。一般的には、サーバ情報テーブルに登録された振り分け先を順番に振り分けていく方法や、特許文献２に示したようにサーバの負荷状況の軽いサーバに優先的に振り分ける方法など様々な方法がある。ヘルスチェック設定管理部３０４は、ロードバランサ１０２がクライアント装置１０１からのリクエストを振り分ける仮想サーバに対するヘルスチェックの設定情報を管理する。ヘルスチェック設定管理部３０４で管理されるヘルスチェックの設定情報のデータ例をヘルスチェック設定情報テーブルに示す。

ヘルスチェックＵＲＬカラムは、ヘルスチェックリスエストの送信先ＵＲＬを格納するカラムである。ヘルスチェックＵＲＬは相対パスで記載される。タイムアウトカラムは、ロードバランサ１０２がヘルスチェックリクエストを送信してから応答を受信するまでのタイムアウト時間を格納するカラムである。本カラムに格納された時間以上経過してもヘルスチェックの応答が返ってこなかった場合にはロードバランサ１０２はヘルスチェック結果が非正常と判断する。ロードバランサ１０２は、非正常となった仮想サーバをリクエストの振り分け対象から外すことで、リクエストの処理が行われない状況を回避する。

正常閾値カラムは、ロードバランサ１０２がヘルスチェックの結果を“正常”と判定するために、リクエストの正常応答を連続して受信する回数を格納するカラムである。ヘルスチェック実行部３０５は正常閾値カラムに格納された値の回数分だけ正常応答を受信すると、サーバ情報テーブル内のサーバの稼働状況カラムの値を“正常”に更新する。非正常閾値カラムは、ロードバランサ１０２がヘルスチェックの結果を“非正常”と判定するために、リクエストのエラー応答を連続して受信する回数を格納するカラムである。ヘルスチェック実行部３０５は非正常閾値カラムに格納された値の回数分だけエラー応答を受信すると、サーバ情報テーブルの該当するサーバの稼働状況カラムの値を“非正常”に更新する。

また、ロードバランサ１０２のヘルスチェック実行部３０５は、サーバ情報テーブルの該当するレコードの前回確認日時カラムの値に、ヘルスチェックの応答を受信した日時を格納する。ヘルスチェック実行部３０５は、サーバ情報テーブルに登録されたそれぞれの仮想サーバに対してヘルスチェックリクエストを送信する。ヘルスチェックリクエストの設定についてはヘルスチェック設定情報テーブルに従って送信される。また、ヘルスチェック実行部３０５は、ヘルスチェックリクエストの応答を解析し、ヘルスチェックの結果が正常であったか非正常であったかを確認する。ヘルスチェックの結果が正常である仮想サーバはクライアントから送信されたリクエストの送信対象となる仮想サーバと見做される。

図４は、本発明に係る仮想サーバ１０４、１０５のソフトウェア構成図を示すブロック図である。Ｗｅｂサーバ４０１は、クライアント装置１０１からリクエストを受信するＷｅｂサーバソフトウェアである。Ｗｅｂサーバ４０１は、クライアント装置１０１から受信した処理を実行し、その結果からレスポンスを生成し、クライアント装置１０１に返す。また、Ｗｅｂサーバ４０１は、クライアント装置１０１から受信したリクエストをアプリケーションサーバ４０２に転送して、アプリケーションサーバ４０２での処理の実行結果をレスポンスとして、クライアント装置１０１に返すこともある。クライアント装置１０１からのリクエストの内容によって適宜何れかの処理がＷｅｂサーバ４０１によって実行される。

アプリケーションサーバ４０２は、Ｗｅｂサーバ４０１から転送されたクライアント装置１０１のリクエストを処理するアプリケーションサーバソフトウェアである。アプリケーションサーバには１つ以上のアプリケーション４０３、４０４が配備されており、リクエストの内容に応じてアプリケーションサーバ４０３が実行するアプリケーションを決定する。即ち、１つの仮想サーバ内には複数のアプリケーションが配備されていることになる。アプリケーションサーバ４０２は、リクエストの実行結果をＷｅｂサーバ４０１に転送する。

本実施例においては、Ｗｅｂサーバ４０１およびアプリケーションサーバ４０２が同一の仮想サーバ１０４、１０５上にそれぞれ存在する前提で説明を行う。Ｗｅｂサーバ４０１およびアプリケーションサーバ４０２の詳細な説明については後述する。また、本実施例においてはアプリケーションサーバ４０２に配備されているアプリケーションの数を２つとしているが、その数を限定する意図で記載しているわけではない。アプリケーションサーバ４０２に配備されるアプリケーションの数は１つ以上であればその数を限定するものではない。本実施例において、アプリケーション４０３、４０４の処理内容、それぞれ受信するリクエストの例を表８に示す。

アプリケーションカラムは、仮想サーバ１０４、１０５で稼働するアプリケーションを識別する値を格納するカラムである。アプリケーションＵＲＬカラムは、アプリケーションへリクエストを送信する場合のＵＲＬの値を格納するカラムである。アプリケーション概要カラムは、アプリケーションが実現する具体的な内容を格納するカラムである。公開機能カラムは、アプリケーションがクライアント装置１０１に対して公開している機能名称を格納するカラムである。ＨＴＴＰメソッドカラムは、公開機能カラムに示した機能をクライアント装置１０１が実行するためにリクエストを送信する際のＨＴＴＰメソッドを定義したカラムである。リクエストフォーマットカラムは、公開機能カラムに示した機能をクライアント装置１０１が実行するためにリクエストを送信する際のリクエストボディに格納するデータのフォーマットを定義したカラムである。この定義に反する値をリクエストボディに格納して、各アプリケーションにリクエストを送信した場合、アプリケーションは通常エラーを返す。例えば、アプリケーション４０３は製品情報を管理するアプリケーションであり、アプリケーション４０４はユーザ情報を管理するアプリケーションとする。

図５は、本発明に係るＷｅｂサーバ４０１のソフトウェアモジュールの構成図を示すブロック図である。これらのソフトウェアは仮想サーバ１０４、１０５の二次記憶装置２０６で管理され、仮想サーバ１０４、１０５のＣＰＵ２０３により実行され、仮想サーバ上にて各機能が実現する。なお、本実施例と直接関係のない処理部については記載を省略する。

制御部５００は、Ｗｅｂサーバ４０１の全体を制御し、ソフトウェアモジュールの各構成要素に対する指示および管理を行う。受信部５０１は、ネットワーク１００を介して接続されるクライアント装置１０１、ロードバランサ１０２から送信されるリクエストの受信処理を行う。クライアント装置１０１からのリクエストは主にアプリケーションサーバ４０２に配備されたアプリケーションへの実行要求である。ロードバランサ１０２からのリクエストはサーバ１０３のヘルスチェックリクエストである。送信部５０２はネットワーク１００を介して、クライアント装置１０１、ロードバランサ１０２にレスポンスを送信する。また、送信部５０２は、ネットワーク１００を介してアプリケーションサーバ４０２に、受信したリクエストを転送する。ヘルスチェックスクリプト実行部５０３は、受信部５０１が受信したリクエストがロードバランサ１０２からのヘルスチェックリクエストであった場合に、ヘルスチェック処理を実行する。受信部５０１が受信するリクエストのデータ例をヘルスチェックリクエストテーブルに示す。

ＨＴＴＰメソッドカラムは、リクエストのＨＴＴＰメソッド名を格納するカラムである。ヘルスチェックリクエストの場合には「ＧＥＴ」の値が格納される。リクエスト送信元ＵＲＬカラムは、リクエストを送信した端末のＵＲＬが格納される。ヘルスチェックリクエストの場合には、ロードバランサ１０２のＵＲＬが格納される。Ｗｅｂサーバ４０１はヘルスチェックリクエストの実行結果を、リクエスト送信元ＵＲＬカラムに格納されたＵＲＬに返す。リクエスト送信先ＵＲＬカラムは、リクエストの送信先ＵＲＬが格納される。ヘルスチェックリクエストの場合は、Ｗｅｂサーバ４０１のヘルスチェックスクリプト管理部５０５に格納されたヘルスチェックスクリプトのＵＲＬが格納される。

ヘルスチェックスクリプト実行部５０３は、ヘルスチェックリクエストに従って、ヘルスチェックリクエスト管理部５０５からヘルスチェックスクリプト、ヘルスチェックルール管理部５０４からヘルスチェックルールを取得して、ヘルスチェック処理を事項する。ヘルスチェックルール管理部５０４は、ヘルスチェックスクリプト実行部５０３が実行するヘルスチェックスクリプトに代入する各パラメータ値をヘルスチェックルールとして、まとめて管理する。ヘルスチェックルール管理部５０４が管理するヘルスチェックルールのデータ例をヘルスチェックルールテーブルに示す。ヘルスチェックルールは、Ｗｅｂアプリケーション毎にルールが定義されており、各Ｗｅｂアプリケーションには、対応するヘルスチェックリクエストが送信されることになる。

ルール番号カラムは、ヘルスチェックスクリプト実行部５０３がアプリケーションサーバ４０２に送信するヘルスチェックリクエストのルールを一意に識別する番号を格納するカラムである。ＨＴＴＰメソッドカラムは、ヘルスチェックスクリプト実行部５０３がアプリケーションサーバ４０２に送信するヘルスチェックリクエストのＨＴＴＰメソッドを格納する。ＨＴＴＰメソッドカラムに格納するＨＴＴＰメソッドの値は、表８に示したアプリケーションに対応したＨＴＴＰメソッドの値が格納される。

ヘルスチェックリクエスト送信先ＵＲＬカラムは、ヘルスチェックスクリプト実行部５０３がアプリケーションサーバ４０２に送信するヘルスチェックリクエストの送信先ＵＲＬを格納する。本カラムに格納される値はアプリケーションサーバ４０２で稼働するアプリケーション４０３、４０４に対応する。具体的には表８に示したアプリケーションＵＲＬカラムの値が格納される。ヘルスチェックリクエストボディカラムは、ヘルスチェックスクリプト実行部５０３がアプリケーションサーバ４０２に送信するヘルスチェックリクエストのリクエストボディ情報を格納するカラムである。本カラムに格納される値は、ヘルスチェックリクエスト送信先ＵＲＬカラムの値に応じて異なる。具体的には表８に示したアプリケーションに対応したリクエストフォーマットカラムに定義された情報が格納される。

例えば、ルール番号カラムの値が「１」のヘルスチェックルールの場合には、表５に示される定義に従い、アプリケーション４０３に対してＨＴＴＰメソッド「ＰＯＳＴ」で「ＰｒｏｄｕｃｔＮａｍｅ」の値が「複合機ＴｙｐｅＡ」、「Ｎａｍｅ」の値が「ＭＦＰＡ００１」のリクエストボディで、ヘルスチェックスクリプト実行部５０３がリクエストを送信することを意味している。

ヘルスチェック成功判定応答コードカラムは、ヘルスチェックスクリプト実行部５０３がヘルスチェックルールに基づき送信したリクエストに対し、アプリケーションサーバ４０２から受信したヘルスチェックリクエストの応答で、アプリケーション４０３、４０４が正常に稼働していると判断するＨＴＴＰレスポンスコードを格納する値である。本カラムに格納する値は、一般的に正常応答を意味するＨＴＴＰレスポンスコード「２００」以外の値を格納しても構わない。

例えば、ルール番号カラムの値が「１」のヘルスチェックルールに基づいたリクエストをヘルスチェックスクリプト実行部５０３がアプリケーション４０３に送信した場合、リクエストボディカラムの「ＰｒｏｄｕｃｔＮａｍｅ」の値に全角文字が含まれている。アプリケーション４０３は表８のリクエストフォーマットカラムの値が示すように、「ＰｒｏｄｕｃｔＮａｍｅ」の値を「半角英数字」と定めているため、ヘルスチェックスクリプト実行部５０３が送信するリクエストはアプリケーション４０３にとっては、不正なリクエストと判断されることが予測される。そのためヘルスチェック成功判定応答コードカラムにはＨＴＴＰレスポンスコード「４００」を格納することになる。

ヘルスチェックリクエストの目的はアプリケーションが稼働していることを確認することである。ルール番号カラムの値が「１」のヘルスチェックルールに基づいたリクエストはアプリケーション４０３によって不正なリクエストと判断される。しかし、そう判断されるということはアプリケーション４０３が正常に稼働し、不正なリクエスト値を正しく判断してエラー処理したことを意味している。

一方、アプリケーション４０３が正常に稼働していなければサーバはリクエストを正しく処理することができない。そのような場合、アプリケーションが稼働するアプリケーションサーバ４０２に異常が発生していることを示すＨＴＴＰレスポンスコードの５００番の値がクライアント装置１０１に返される。そのためヘルスチェックルールテーブルには、ヘルスチェック成功判定応答コードカラムの値が５００番台以外となるルールを登録することで、アプリケーションサーバ４０２の稼働状況をチェックすることができる。ヘルスチェックスクリプト管理部５０５は、ヘルスチェックスクリプト実行部５０３が実行するヘルスチェックスクリプトを管理する。チェックスクリプトが実行されることで各アプリケーションに対してヘルスチェックリクエストが送信される。

図６は、本発明に係るアプリケーションサーバ４０２のソフトウェアモジュールの構成図を示すブロック図である。これらのソフトウェアは仮想サーバ１０４、１０５の二次記憶装置２０６で管理され、仮想サーバ１０４、１０５のＣＰＵ２０３により実行され、各機能が実現する。なお、本実施例と直接関係のない処理部については記載を省略する。

制御部６００は、アプリケーションサーバ４０２全体を制御し、ソフトウェアモジュールの各構成要素に対する指示および管理を行う。受信部６０１は、ネットワーク１００を介して接続されるクライアント装置１０１、ロードバランサ１０２から送信されるリクエストの受信処理を行う。送信部６０２はネットワーク１００を介して、アプリケーション実行部６０３の実行結果のレスポンスをＷｅｂサーバ４０１に返す。アプリケーション実行部６０３は、受信部６０１が受信したリクエストに対応したアプリケーション４０３、４０４で実行する。ヘルスチェックリクエストを受信したＷｅｂサーバ４０１により送信される、アプリケーションが正常に稼働しているか否かを確認するためのリクエスト、即ちヘルスチェックルールに従って送信されるリクエストもアプリケーション実行部６０３により実行される。そのようなリクエストはヘルスチェックを確認するためのリクエストではあるが、アプリケーション４０３、４０４にとってはヘルスチェックリクエストとは異なる通常のリクエストの内容と何ら変わりはない。上述した構成を仮想サーバで実現することで、各アプリケーションがヘルスチェックリクエストに対応する機能を搭載しておらずとも、アプリケーションのヘルスチェックが可能になるのが本発明のポイントの１つである。

図７は本発明に係る、ロードバランサ１０２がサーバ１０３およびサーバ１０３上で稼働する仮想サーバ１０４、１０５に対してヘルスチェックを行う一連の処理を示したフローチャートである。ステップＳ７０１において、ロードバランサ１０２のヘルスチェック実行部３０５は、サーバ情報管理部３０３で管理されるサーバ情報テーブルにレコードが登録されていることを確認する。そしてヘルスチェック実行部３０５は、前述したレコードの前回確認日時カラムの値と現在時刻を比較して、ヘルスチェックが未実施のサーバがあるか否かを確認する。具体的には、ロードバランサ１０２が管理する現在時刻が、前回確認日時カラムの時刻からヘルスチェック設定情報テーブルの間隔カラムの値以上時刻が経過しているかどうかを確認する。間隔カラムの値以上、前回ヘルスチェックを行ってから時刻が経過している仮想サーバが存在していた場合にはステップＳ７０２に進む。間隔カラムの値以上、前回ヘルスチェックを行ってから時刻が経過している仮想サーバが存在していない場合には、ロードバランサ１０２は一旦処理を終了し、一定時刻経過後再度ステップＳ７０１を行う。

ステップＳ７０２において、ヘルスチェック実行部３０５は、ヘルスチェックリクエストを作成する。具体的には、ヘルスチェック実行部３０５は、ヘルスチェックリクエストレコードのリクエスト送信元ＵＲＬに自身が保持するＵＲＬを格納する。ヘルスチェック実行部３０５は、ヘルスチェックリクエストレコードのリクエスト送信先ＵＲＬカラムにサーバ情報テーブルの振り分け先サーバＵＲＬカラムの値とヘルスチェック設定情報テーブルのヘルスチェックＵＲＬカラムの値を連結したＵＲＬを格納する。

ステップＳ７０３において、送信部３０２は、仮想サーバ１０４、１０５に対してヘルスチェックリクエストを送信する。ステップＳ７０４において、仮想サーバ１０４、１０５で稼働するＷｅｂサーバ４０１の受信部５０１はロードバランサ１０２からヘルスチェックリクエストを受信して、ヘルスチェック処理を実行する。ヘルスチェック処理の詳細なフローについては、図８で説明する。ステップＳ７０５において、ロードバランサ１０２の受信部３０１は仮想サーバ１０４、１０５からヘルスチェックレスポンスを受信する。受信部３０１が受信するヘルスチェックレスポンスのデータ例をヘルスチェックレスポンステーブルに示す。

ＨＴＴＰステータスコードカラムは、ヘルスチェックリクエストに対する仮想サーバ１０４、１０５からのレスポンスの意味を表すＨＴＴＰステータスコードを格納するカラムである。本実施例においては、ヘルスチェックリクエストを実行して、仮想サーバの稼働確認に成功した場合には、ＨＴＴＰステータスコードの値を２００として返すものとする。また、仮想サーバの稼働確認に失敗した場合には、ＨＴＴＰステータスコードの値を５０３として返すものとする。レスポンスボディカラムは、ヘルスチェックリクエストに対する仮想サーバ１０４、１０５からのレスポンスの詳細な内容の値を格納するカラムである。詳細は後述するが、仮想サーバ１０４、１０５は夫々に配備された全てのアプリケーションが正常に稼働していることを確認し、１つでも正常に稼働していないアプリケーションがあればその時点でヘルスチェックエラーレスポンスをロードバランサ１０２へ返す。即ち、１つでも正常に稼働していないアプリケーションがあれば仮想サーバとしては機能できないサーバであることをロードバランサ１０２へ伝えるのである。これにより、クライアントからのリクエストが、サーバの不正稼働によって処理できない状況を回避できる。

ステップＳ７０６において、ロードバランサ１０２のヘルスチェック実行部３０５は、ステップＳ７０５で受信したヘルスチェックレスポンスレコードの内容を確認する。ＨＴＴＰステータスコードカラムの値が「２００」であった場合にはヘルスチェックに成功したものと判断し、サーバ情報テーブルの前回確認日時カラムの値に現在時刻を格納する。加えてヘルスチェック設定情報テーブルの正常閾値カラムに格納された値の回数分連続してヘルスチェックに成功した場合、ヘルスチェック実行部３０５は、サーバ情報テーブルの稼働状況カラムの値を「正常」に変更する。また、ＨＴＴＰステータスコードカラムの値が「２００」以外であった場合には、ヘルスチェックに失敗したものと判断し、サーバ情報テーブルの前回確認日時カラムの値に現在時刻を格納する。ヘルスチェック設定情報テーブルの非正常閾値カラムに格納された値の回数分連続してヘルスチェックに失敗した場合には、ヘルスチェック実行部３０５は、サーバ情報テーブルの稼働状況カラムの値を「非正常」に変更する。

ステップＳ７０７において、ロードバランサ１０２の制御部３００は、ステップＳ７０６の結果、サーバ情報テーブルの稼働状況カラムの値を「非正常」となった仮想サーバの有無を確認する。「非正常」となった仮想サーバが存在する場合にはステップＳ７０８に進む。「非正常」となった仮想サーバが存在しない場合にはステップＳ７０１に進む。

ステップＳ７０８において、ロードバランサ１０２の制御部３００は、ステップＳ７０７で認識した仮想サーバをロードバランサ１０２の監視対象から外し、該当する仮想サーバを破棄する処理を行う。具体的には仮想サーバのデータを削除し、仮想サーバを構成するリソースを解放するとともにサーバ情報テーブルから該当のレコードを削除する。ステップＳ７０９において、ロードバランサ１０２の制御部３００は、新たに仮想サーバを作成して監視対象に登録する。具体的には仮想サーバのデータを新規作成するとともにサーバ情報テーブルに該当のレコードを登録する。

図８は、ステップＳ７０４において、Ｗｅｂサーバ４０１が実施するヘルスチェック処理の詳細を示したフローチャートである。ステップＳ８０１において、Ｗｅｂサーバ４０１の受信部５０１は、ロードバランサ１０２の送信部３０２からリクエストを受信する。ステップＳ８０２において、受信部５０１は、受信したリクエストがヘルスチェックリクエストかどうかを確認する。具体的にはリクエストレコードのＨＴＴＰメソッドカラムの値が「ＧＥＴ」、リクエスト送信元ＵＲＬカラムの値がロードバランサ１０２のＵＲＬ、リクエスト送信先ＵＲＬカラムの値がヘルスチェック設定情報のヘルスチェックＵＲＬカラムの値と一致していた場合、受信部５０１は、受信したリクエストがヘルスチェックリクエストと判断し、ステップＳ８０３へ進む。ヘルスチェックリクエストと異なる通常のリクエストの場合は、受信部５０１は、アプリケーション４０３，４０４への通常のリクエストと判断し、ステップＳ８１５に進む。ステップＳ８０３において、受信部５０１は、ヘルスチェックリクエスト実行部５０３にヘルスチェックリクエストを渡す。

ステップＳ８０４において、ヘルスチェックスクリプト実行部５０３は、ヘルスチェックルール管理部５０４が管理するヘルスチェックルールテーブルからヘルスチェックルールレコードを一件取得する。ステップＳ８０５において、ヘルスチェックスクリプト実行部５０３は、未実行のヘルスチェックレコードの取得に成功したかどうかを確認する。未実行のヘルスチェックレコードを取得に成功した場合にはステップＳ８０６に進む。ヘルスチェックルールテーブルにヘルスチェックレコードが存在していない場合、あるいは全てのヘルスチェックレコードを取得してヘルスチェック処理を全て実行した場合にはステップＳ８１４に進む。ステップＳ８０６において、ヘルスチェックスクリプト実行部５０３は、ヘルスチェックスクリプト管理部５０５からヘルスチェックスクリプトを取得する。ステップＳ８０７において、ヘルスチェックスクリプト実行部５０３は、ステップＳ８０４で取得したヘルスチェックルールレコードの各カラムの値に基づき、リクエストを作成して、送信部５０２を介してアプリケーションサーバ４０２に送信する。例えば本実施例においては、表５に基づきアプリケーション４０３のＵＲＬ「／ａｐｐ１／Ｐｒｏｄｕｃｔ」にＨＴＴＰメソッド「ＰＯＳＴ」のリクエストと、アプリケーション４０４のＵＲＬ「／ａｐｐ２／Ｕｓｅｒ」にＨＴＴＰメソッド「ＰＵＴ」のリクエストを送信する。

ステップＳ８０８において、アプリケーションサーバ４０２の受信部６０１は、Ｗｅｂサーバ４０１の送信部５０２からリクエストを受信する。ステップＳ８０９において、アプリケーション実行部６０３は、ステップＳ８０８において受信したリクエストのＨＴＴＰリクエストカラムの値を参照する。そして、アプリケーションサーバ４０２で稼働するアプリケーション４０３、４０４のうち該当するアプリケーションを選択する。そして、アプリケーション実行部６０３は該当するアプリケーションにＨＴＴＰリクエストを転送して、アプリケーションを実行する。例えば本実施例においては、アプリケーション４０３にはＨＴＴＰメソッド「ＰＯＳＴ」で「ＰｒｏｄｕｃｔＮａｍｅ」の値が「複合機ＴｙｐｅＡ」、「Ｎａｍｅ」の値が「ＭＦＰＡ００１」のリクエストボディのリクエストがアプリケーション実行部６０３から転送されてくる。表８のリクエストフォーマットカラムに定義されたデータフォーマットルールに従って、アプリケーション４０３はリクエストボディの値のフォーマットチェックをまず行う。「ＰｒｏｄｕｃｔＮａｍｅ」の値に全角文字が含まれているため、アプリケーション４０３は受信したリクエストを不正なリクエストと判断し、ＨＴＴＰレスポンスコード「４００」を発行する。

また、本実施例においては、アプリケーション４０４にはＨＴＴＰメソッド「ＰＵＴ」で「ＵｓｅｒＩＤ」の値が「９９９９９」、「Ｎａｍｅ」の値が「ＨｅａｌｔｈＣｈｅｃｋＵｓｅｒ」のリクエストボディのリクエストがアプリケーション実行部６０３から転送されてくる。表８のリクエストフォーマットカラムに定義されたデータフォーマットルールに従って、アプリケーション４０４はリクエストボディの値のフォーマットチェックをまず行う。フォーマットチェック正常なリクエストとアプリケーション４０４が判断すると、アプリケーション４０４は「ＵｓｅｒＩＤ」の値に該当するユーザ情報が存在するかどうかを確認する。この時、仮に「ＵｓｅｒＩＤ」の値が「９９９９９」のユーザ情報が存在しない場合には、データ未検出を意味するＨＴＴＰレスポンスコード「４０４」を発行する。

ステップＳ８１０において、アプリケーション実行部６０３はステップＳ８１０の実行結果からヘルスチェックレスポンスを作成して、送信部６０２を介してＷｅｂサーバ４０１の受信部５０１に送信する。ステップＳ８１１において、ヘルスチェックスクリプト実行部５０３は、ステップＳ８１０で受信したヘルスチェックレスポンスのＨＴＴＰステータスコードカラムの値を取得する。ステップＳ８１２において、ヘルスチェックスクリプト実行部５０３はステップＳ８１１で取得したＨＴＴＰステータスコードカラムの値とステップＳ８０５で取得したヘルスチェックレコードのヘルスチェック成功判定応答コードの値とを比較する。値が一致していた場合には、ステップＳ８０４に進み、再びヘルスチェックレコードに基づくヘルスチェック処理を継続する。

ヘルスチェックスクリプト実行部５０３において、繰り返し実行されるヘルスチェック処理の結果として、一回でもステップＳ８１１で取得したＨＴＴＰステータスコードカラムの値とステップＳ８０５で取得したヘルスチェックレコードのヘルスチェック成功判定応答コードの値が一致しなかった場合には、ステップＳ８１３に進む。例えば本実施例においては、ステップＳ８０９においてアプリケーション４０３とアプリケーション４０４からそれぞれＨＨＴＰステータスコード「４００」と「４０４」のレスポンスを受信することになり、ヘルスチェックレコードのヘルスチェック成功判定応答コードの値が一致する。そのため、アプリケーションサーバ４０２は正常に稼働していると判断され、ステップＳ８１４に進む。仮に、いずれかのアプリケーションの実行時に、アプリケーションサーバが稼働していなかった場合、ＨＴＴＰステータスコード「５００」が返却されてヘルスチェックレコードのヘルスチェック成功判定応答コードの値が一致しなくなる。その結果、ステップＳ８１３に進むことになる。本実施例では、全てのアプリケーションからのＨＴＴＰステータスコードが返されずとも、１つでもアプリケーションが正常に稼働していないと判断した時点でロードバランサ１０２にヘルスチェックエラーの旨を送信することを想定している。しかし、全てのアプリケーションからのＨＴＴＰステータスコードが返された時点で、ヘルスチェックエラーの旨を送信する形態であっても良い。

ステップＳ８１３、８１８において、ヘルスチェックスクリプト実行部５０３は、ヘルスチェックの失敗を示すヘルスチェックエラーレスポンスを作成して、送信部５０２を介してロードバランサ１０２にレスポンスを送信する。ステップＳ８１４、８１８において、ヘルスチェックスクリプト実行部５０３は、ヘルスチェックルールテーブルに登録された全てのヘルスチェックルールに基づくヘルスチェック処理に成功したと判定する。そして、ヘルスチェック成功レスポンスを作成して、送信部５０２を介してロードバランサ１０２にレスポンスを送信する。ステップＳ８１５において、アプリケーションサーバ４０２の受信部６０１は、Ｗｅｂサーバ４０１の送信部５０２からリクエストを受信する。ステップＳ８１６、８１７、８１８において、アプリケーション実行部６０３は、ステップＳ８０１において受信したリクエストに応じたアプリケーションアプリケーションを実行して、その結果からレスポンスを作成し、ロードバランサ１０２に送信する。

以上、図７および図８に示したフローチャートによって、サーバ上で動作するアプリケーションの稼働状況を加味したうえでサーバの稼働状況を把握することができる。また、ヘルスチェックルールテーブルに登録するレコードに従ってアプリケーションの稼働状況を把握することで、アプリケーションに新たにヘルスチェック用の機能をつくることなく、既存の機能を流用してヘルスチェックを行うことが可能になる。
［実施例２］
実施例１の構成では、ヘルスチェックを達成することが目的であるとはいえ、ヘルスチェックスクリプトが意図的にエラーレスポンスを発生させるリクエストを定期的にアプリケーションに送信することになる。そのため、実際にユーザクライアントからのリクエストに対してエラーレスポンスをアプリケーションが送信した場合と、ヘルスチェック目的でエラーレスポンスをアプリケーションが送信した場合の判別が困難となってしまう。具体的にはアプリケーションが出力するログファイルに記録されるエラーログが大量になり、ユーザクライアントからのリクエストによって生じたエラーの原因究明が困難となることが考えられる。本実施例においては、ヘルスチェックスクリプトからのリクエストによって生じたエラーと、実際のユーザクライアントからのリクエストによって生じたエラーとが判別しやすいようにログの出力を抑制する方法を、図９を用いて示す。その他、本実施例で説明しない箇所については実施例１と同様である。

図９は、アプリケーションサーバ４０２の受信部６０１が受信したリクエストに基づき、対応するアプリケーションを実行する際のログ出力処理の詳細を示したフローチャートである。本フローチャートに示す処理は、実施例１に記載の図８におけるステップＳ８０８からステップＳ８１０、およびステップＳ８１５からステップＳ８１７に置き換わる処理となる。

ステップＳ９０１において、アプリケーションサーバ４０２の受信部６０１は、Ｗｅｂサーバ４０１の送信部５０２からリクエストを受信する。ステップＳ９０２において、受信部６０１はリクエストのＨＴＴＰリクエストカラムから送信元のＵＲＬ情報を取得する。このとき、リクエストの送信元がＷｅｂサーバ４０１のヘルスチェックスクリプト実行部５０３である場合には、Ｗｅｂサーバ４０１とアプリケーションサーバ４０２は同一のサーバ上で稼働している。そのためＨＴＴＰリクエストカラムには「ｌｏｃａｌｈｏｓｔ」の値が格納されていることになる。また、リクエストの送信元が任意のクライアント装置１０１であった場合には、「ｌｏｃａｌｈｏｓｔ」以外の値が格納されていることになる。

ステップＳ９０３において、アプリケーション実行部６０３は、ステップＳ９０１で受信したリクエストに該当するアプリケーションにＨＴＴＰリクエストを転送して、アプリケーションを実行する。ステップＳ９０４において、アプリケーション実行部６０３は、受信したリクエストが自らのサーバ１０３から送信されたリクエストであるかどうかを確認する。具体的にはステップＳ９０２で取得したＵＲＬの値を確認し、「ｌｏｃａｌｈｏｓｔ」となっていた場合には、自らのサーバ１０３から送信されたヘルスチェックリクエストと判断し、ステップＳ９０６に進む。「ｌｏｃａｌｈｏｓｔ」以外の値であった場合にはクライアント装置１０１から送信されたリクエストと判断し、ステップＳ９０５に進む。

ステップＳ９０５において、アプリケーション実行部６０３は、アプリケーションの実行の際生じたログデータをサーバの二次記憶装置２０６に保存する。

ステップＳ９０６において、アプリケーション実行部６０３はステップＳ９０３の実行結果からレスポンスを作成する。ステップＳ９０７において、アプリケーション実行部６０３は送信部６０２を介してＷｅｂサーバ４０１の受信部５０１にレスポンスを送信する。以上、図９に示したフローチャートによって、ヘルスチェックリクエストにより生じたアプリケーションの実行ログ情報を除外し、クライアント装置１０１からのリクエストにより生じたアプリケーションの実行ログ情報のみを残すことが可能となる。
［その他の実施例］
本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施例の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

１００ ネットワーク
１０１ クライアント装置
１０２ ロードバランサ
１０３ 物理サーバ
１０４、１０５ 仮想サーバ

Claims (13)

1. クライアントのリクエストを分散して送信するロードバランサと通信可能であり、複数の仮想サーバを備えたサーバシステムであって、
   前記リクエストの送信対象とすることが可能な仮想サーバであるか否かを確認するため、前記ロードバランサから各仮想サーバに対し送信されるヘルスチェックを受信する受信手段と、
   前記受信手段によりヘルスチェックを受信したことに応じて、前記ヘルスチェックを受信した仮想サーバ内に配備される複数のＷｅｂアプリケーションに対し、予め決められた任意のリクエストを送信する送信手段と、
   前記送信手段により送信された任意のリクエストに対するレスポンスを各Ｗｅｂアプリケーションから受信し、受信した全てのレスポンスが正常にＷｅｂアプリケーションが稼働していることを示すレスポンスであることを確認したことに応じて、前記ロードバランサにヘルスチェック成功の旨を送信する制御手段と、を有するサーバシステム。
2. 前記制御手段は、受信するレスポンスの内の少なくとも１つのレスポンスが正常にＷｅｂアプリケーションが稼働していないことを示すレスポンスである場合は、前記ロードバランサにヘルスチェックエラーの旨を送信することを特徴とする請求項１に記載のサーバシステム。
3. 前記制御手段は、前記複数のＷｅｂアプリケーションの内の１のＷｅｂアプリケーションから受信したレスポンスが正常にＷｅｂアプリケーションが稼働していないことを示すレスポンスであることを確認したことに応じて、残りのＷｅｂアプリケーションからのレスポンスの受信を待つことなく、前記ロードバランサにヘルスチェックエラーの旨を送信することを特徴とする請求項１または２に記載のサーバシステム。
4. 正常にＷｅｂアプリケーションが稼働していることを示す前記レスポンスとは、正常応答を示すレスポンスコードおよび不正なリクエストに対する応答を示すレスポンスコードを含み、Ｗｅｂアプリケーションに異常が発生していることを示すレスポンスコードは含まないことを特徴とする請求項１乃至３の何れか１項に記載のサーバシステム。
5. ヘルスチェックを受信した前記仮想サーバが複数のＷｅｂアプリケーションに対し送信する任意のリクエストを、前記仮想サーバ内のＷｅｂアプリケーション毎に定義したヘルスチェックルールを保存する保存手段を更に有し、
   前記送信手段は、前記保存手段により保存されたヘルスチェックルールを確認し、Ｗｅｂアプリケーションに対応した任意のリクエストを確認し、予め決められた任意のリクエストを送信することを特徴とする請求項１乃至４の何れか１項に記載のサーバシステム。
6. 前記送信手段は、ヘルスチェックに関連する前記任意のリクエストの他に、前記ロードバランサから受信した前記クライアントのリクエストを送信することが可能であり、
   前記Ｗｅｂアプリケーションは、前記クライアントのリクエストを受信した場合には、前記クライアントのリクエストの処理に伴いログデータを出力し、ヘルスチェックに関連する前記任意のリクエストを受信した場合、前記任意のリクエストの処理を行いログデータを出力しないことを特徴とする請求項１乃至５の何れか１項に記載のサーバシステム。
7. クライアントのリクエストを分散して送信するロードバランサと通信可能であり、複数の仮想サーバを備えたサーバシステムを制御する方法であって、
   受信手段は、前記リクエストの送信対象とすることが可能な仮想サーバであるか否かを確認するため、前記ロードバランサから各仮想サーバに対し送信されるヘルスチェックを受信し、
   送信手段は、前記受信手段によりヘルスチェックを受信したことに応じて、前記ヘルスチェックを受信した仮想サーバ内に配備される複数のＷｅｂアプリケーションに対し、予め決められた任意のリクエストを送信し、
   制御手段は、前記送信手段により送信された任意のリクエストに対するレスポンスを各Ｗｅｂアプリケーションから受信し、受信した全てのレスポンスが正常にＷｅｂアプリケーションが稼働していることを示すレスポンスであることを確認したことに応じて、前記ロードバランサにヘルスチェック成功の旨を送信することを特徴とする方法。
8. 前記制御手段は、受信するレスポンスの内の少なくとも１つのレスポンスが正常にＷｅｂアプリケーションが稼働していないことを示すレスポンスである場合は、前記ロードバランサにヘルスチェックエラーの旨を送信することを特徴とする請求項７に記載の方法。
9. 前記制御手段は、前記複数のＷｅｂアプリケーションの内の１のＷｅｂアプリケーションから受信したレスポンスが正常にＷｅｂアプリケーションが稼働していないことを示すレスポンスであることを確認したことに応じて、残りのＷｅｂアプリケーションからのレスポンスの受信を待つことなく、前記ロードバランサにヘルスチェックエラーの旨を送信することを特徴とする請求項７または８に記載の方法。
10. 正常にＷｅｂアプリケーションが稼働していることを示す前記レスポンスとは、正常応答を示すレスポンスコードおよび不正なリクエストに対する応答を示すレスポンスコードを含み、Ｗｅｂアプリケーションに異常が発生していることを示すレスポンスコードは含まないことを特徴とする請求項７乃至９の何れか１項に記載の方法。
11. 保存手段は、ヘルスチェックを受信した前記仮想サーバが複数のＷｅｂアプリケーションに対し送信する任意のリクエストを、前記仮想サーバ内のＷｅｂアプリケーション毎に定義したヘルスチェックルールを保存し、
    前記送信手段は、前記保存手段により保存されたヘルスチェックルールを確認し、Ｗｅｂアプリケーションに対応した任意のリクエストを確認し、予め決められた任意のリクエストを送信することを特徴とする請求項７乃至１０の何れか１項に記載の方法。
12. 前記送信手段は、ヘルスチェックに関連する前記任意のリクエストの他に、前記ロードバランサから受信した前記クライアントのリクエストを送信することが可能であり、
    前記Ｗｅｂアプリケーションは、前記クライアントのリクエストを受信した場合には、前記クライアントのリクエストの処理に伴いログデータを出力し、ヘルスチェックに関連する前記任意のリクエストを受信した場合、前記任意のリクエストの処理を行いログデータを出力しないことを特徴とする請求項７乃至１１の何れか１項に記載の方法。
13. クライアントのリクエストを分散して送信するロードバランサと通信可能であり、複数の仮想サーバを備えたサーバシステムを制御するプログラムであって、
    前記リクエストの送信対象とすることが可能な仮想サーバであるか否かを確認するため、前記ロードバランサから各仮想サーバに対し送信されるヘルスチェックを受信する受信ステップと、
    前記受信ステップにおいてヘルスチェックを受信したことに応じて、前記ヘルスチェックを受信した仮想サーバ内に配備される複数のＷｅｂアプリケーションに対し、予め決められた任意のリクエストを送信する送信ステップと、
    前記送信ステップにおいて送信された任意のリクエストに対するレスポンスを各Ｗｅｂアプリケーションから受信し、受信した全てのレスポンスが正常にＷｅｂアプリケーションが稼働していることを示すレスポンスであることを確認したことに応じて、前記ロードバランサにヘルスチェック成功の旨を送信する制御ステップと、を含むプログラム。