(57)【特許請求の範囲】
【請求項１】
リクエストを処理するサーバソフトウェアを実行可能な複数のサーバ装置を備える情報処理システムと通信を行う情報処理装置であって、
２以上のリクエストを前記サーバソフトウェアを実行するサーバ装置に対して送信し、前記２以上のリクエストの間では前記サーバソフトウェアの状態をリセットするよう指示する命令を送信しない第１の送信処理を行い、また、前記２以上のリクエストを前記サーバソフトウェアを実行するサーバ装置に対して送信し、前記２以上のリクエストの間では前記命令を送信する第２の送信処理を行う送信部と、
前記第１の送信処理に対応して受信される第１のレスポンスと前記第２の送信処理に対応して受信される第２のレスポンスとを比較し、比較結果に基づいて、前記２以上のリクエストについて同じサーバ装置が処理するよう制限するか否か判定する判定部と、
を有する情報処理装置。
【請求項２】
前記命令は、前記サーバソフトウェアを実行するサーバ装置に対して記憶装置に記憶されたデータを復元するよう指示することを示す、請求項１記載の情報処理装置。
【請求項３】
前記送信部は、前記第２の送信処理では、２以上のサーバ装置、または、１またはそれ以上のサーバ装置を用いて動作する２以上の仮想サーバ装置に対して、前記２以上のリクエストを分散して送信する、請求項１または２記載の情報処理装置。
【請求項４】
前記判定部は、判定結果に応じて、前記２以上のリクエストで指定されたファイルパスを用いて、リクエストを前記複数のサーバ装置に振り分けるときに参照される振り分けルールを生成する、請求項１乃至３の何れか一項に記載の情報処理装置。
【請求項５】
前記判定部は、前記複数のサーバ装置が第１のサーバソフトウェアを第２のサーバソフトウェアに更新するとき、前記第２のサーバソフトウェアについて判定を行い、
前記判定部は、前記第１のサーバソフトウェアに対応する第１の振り分けルールと判定結果に応じた第２の振り分けルールとから、前記第１のサーバソフトウェアから前記第２のサーバソフトウェアへの更新中に適用される第３の振り分けルールを生成する、
請求項４記載の情報処理装置。
【請求項６】
前記情報処理装置は、前記２以上のリクエストを生成するクライアント装置、または、前記クライアント装置と前記複数のサーバ装置との間で前記２以上のリクエストを中継する中継装置である、請求項１乃至５の何れか一項に記載の情報処理装置。
【請求項７】
リクエストを処理するサーバソフトウェアを実行可能な複数のサーバ装置を備える情報処理システムのテスト方法であって、情報処理装置が、
２以上のリクエストを前記サーバソフトウェアを実行するサーバ装置に対して送信し、前記２以上のリクエストの間では前記サーバソフトウェアの状態をリセットするよう指示する命令を送信しない第１の送信処理を行い、
前記２以上のリクエストを前記サーバソフトウェアを実行するサーバ装置に対して送信し、前記２以上のリクエストの間では前記命令を送信する第２の送信処理を行い、
前記第１の送信処理に対応して受信される第１のレスポンスと前記第２の送信処理に対応して受信される第２のレスポンスとを比較し、比較結果に基づいて、前記２以上のリクエストについて同じサーバ装置が処理するよう制限するか否か判定する、
情報処理システムのテスト方法。
【請求項８】
リクエストを処理するサーバソフトウェアを実行可能な複数のサーバ装置を備える情報処理システムと通信を行うコンピュータに実行させるプログラムであって、前記コンピュータに、
２以上のリクエストを前記サーバソフトウェアを実行するサーバ装置に対して送信し、前記２以上のリクエストの間では前記サーバソフトウェアの状態をリセットするよう指示する命令を送信しない第１の送信処理を行い、
前記２以上のリクエストを前記サーバソフトウェアを実行するサーバ装置に対して送信し、前記２以上のリクエストの間では前記命令を送信する第２の送信処理を行い、
前記第１の送信処理に対応して受信される第１のレスポンスと前記第２の送信処理に対応して受信される第２のレスポンスとを比較し、比較結果に基づいて、前記２以上のリクエストについて同じサーバ装置が処理するよう制限するか否か判定する、
処理を実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は情報処理装置、情報処理システムのテスト方法およびプログラムに関する。
【背景技術】
【０００２】
クライアント装置がサーバ装置にネットワーク経由でリクエストを送信し、サーバ装置がリクエストに応じた処理を行ってクライアント装置にネットワーク経由でレスポンスを送信するクライアント・サーバ型の情報処理システムが広く利用されている。このような情報処理システムの一例として、クライアント装置がサーバ装置にＨＴＴＰ（Hypertext Transfer Protocol）リクエストを送信し、サーバ装置がクライアント装置にＨＴＴＰレスポンスを送信するＷＷＷ（World Wide Web）システムが挙げられる。
【０００３】
単位時間当たりに情報処理システムが受信するリクエストが増加すると、サーバ装置の処理能力には限界があるため、単一のサーバ装置では受信した全てのリクエストを処理することが困難になることがある。そこで、複数のサーバ装置を設置し、リクエストを複数のサーバ装置に振り分けて処理させる情報処理システムがある。例えば、ロードバランサと呼ばれる中継装置が、クライアント装置からリクエストを受信し、複数のサーバ装置の負荷を考慮してリクエストを何れかのサーバ装置に転送するものがある。
【０００４】
なお、複数のサーバを備え、ウェブサイトで受信されるリクエストを共用可能リクエストと共用不能リクエストとに分類し、共用可能リクエストは何れのサーバも処理できるようにし、共用不能リクエストは特定のサーバに処理させるシステムが提案されている。また、リクエストを複数のアプリケーションサーバに振り分けるロードバランサが、アプリケーションサーバからのレスポンスに含まれるセッションデータを抽出して保存することで、アプリケーションサーバ間でセッションデータを共有する方法が提案されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】国際公開第０３／０６３４４７号
【特許文献２】特開２０１０−７９５２３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ところで、サーバ装置で実行されるサーバソフトウェアの中には、同一のクライアント装置と複数回通信を行うことで、一連の纏まった処理を完結させるものがある。例えば、１つ目のリクエストを受けて、クライアント装置から指定された条件に合致する項目を検索して検索結果を提示し、２つ目のリクエストを受けて、先の検索結果の中から選択された項目についてデータベースを更新するサーバソフトウェアが考えられる。一連の纏まった処理に対応する１つのセッションでは、サーバソフトウェアは、クライアント装置からのリクエストの受信とクライアント装置へのレスポンスの送信とを複数回繰り返し得る。
【０００７】
サーバソフトウェアは、先のリクエストと同一セッションに属する後のリクエストを処理するとき、リクエストの内容に応じて、先のリクエストに関するデータ（例えば、処理結果）を利用することもあるし、利用しないこともある。先のリクエストの処理から後のリクエストの処理にデータを引き継ぐ場合、サーバソフトウェアは、当該サーバソフトウェアが実行されているサーバ装置の記憶装置（例えば、ＲＡＭ（Random Access Memory）やＨＤＤ（Hard Disk Drive））にデータを書き込んでおくことが考えられる。先のリクエストに関するデータをサーバ装置上に保持することは、サーバソフトウェアの状態を変化させることになり、後のリクエストの処理に影響を与え得る。
【０００８】
そこで、ロードバランシングでは、データの引き継ぎが生じ得る２以上のリクエストは同一のサーバ装置が処理するように、リクエストを振り分けることが好ましい。例えば、ロードバランサは、リクエストの内容（例えば、リクエストが指定するファイルのパス）とリクエストに含まれるセッションＩＤ（Identifier）とに基づいて、当該リクエストの転送先のサーバ装置を判定する。同一のサーバ装置が処理すべきであるというリクエストの特徴を、スティッキネス（Stickiness）と呼ぶことがある。
【０００９】
サーバソフトウェアを複数のサーバ装置に配置して情報処理システムの運用を開始するとき、ロードバランシングのルールが情報処理システムに設定される。しかし、ルールを設定するにあたり、ある２以上のリクエストが同一のサーバ装置によって処理されるべきものか否かを、どのように判定すればよいかが問題となる。同一のサーバ装置が処理すべき２以上のリクエストを異なるサーバ装置に振り分けると、処理が適切に行われなくなってしまう。一方、同一のサーバ装置が処理しなくてもよい２以上のリクエストを同一のサーバ装置が処理するよう制限すると、ロードバランシングの効率が低下し得る。
【００１０】
一側面では、本発明は、複数のサーバ装置を備える情報処理システムにおけるロードバランシングのルールを判定することができる情報処理装置、情報処理システムのテスト方法およびプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１１】
一実施態様では、リクエストを処理するためのサーバソフトウェアを実行可能な複数のサーバ装置を備える情報処理システムのテストに用いられる情報処理装置が提供される。情報処理装置は、送信部と判定部とを有する。送信部は、１つのセッションに属する２以上のリクエストを、サーバソフトウェアの状態をリクエスト間でリセットせず、当該サーバソフトウェアを実行するサーバ装置に対して送信する第１の送信処理を行い、また、２以上のリクエストを、サーバソフトウェアの状態をリクエスト間でリセットしつつ、当該サーバソフトウェアを実行するサーバ装置に対して送信する第２の送信処理を行う。判定部は、第１の送信処理に対応して受信される第１のレスポンスと第２の送信処理に対応して受信される第２のレスポンスとを比較し、比較結果に基づいて、２以上のリクエストについて同じサーバ装置が処理するよう制限するか否か判定する。
【００１２】
また、一実施態様では、リクエストを処理するためのサーバソフトウェアを実行可能な複数のサーバ装置を備える情報処理システムのテスト方法が提供される。情報処理装置が、１つのセッションに属する２以上のリクエストを、サーバソフトウェアの状態をリクエスト間でリセットせず、当該サーバソフトウェアを実行するサーバ装置に対して送信する第１の送信処理を行う。２以上のリクエストを、サーバソフトウェアの状態をリクエスト間でリセットしつつ、当該サーバソフトウェアを実行するサーバ装置に対して送信する第２の送信処理を行う。第１の送信処理に対応して受信される第１のレスポンスと第２の送信処理に対応して受信される第２のレスポンスとを比較し、比較結果に基づいて、２以上のリクエストについて同じサーバ装置が処理するよう制限するか否か判定する。
【００１３】
また、一実施態様では、コンピュータに実行させるプログラムであって、リクエストを処理するためのサーバソフトウェアを実行可能な複数のサーバ装置を備える情報処理システムのテストに用いられるプログラムが提供される。
【発明の効果】
【００１４】
一実施態様によれば、複数のサーバ装置を備える情報処理システムにおけるロードバランシングのルールを判定することができる。
【図面の簡単な説明】
【００１５】
【図１】第１の実施の形態の情報処理装置を示す図である。
【図２】第２の実施の形態の情報処理システムを示す図である。
【図３】リバースプロキシサーバのハードウェア例を示すブロック図である。
【図４】第２の実施の形態のソフトウェア例を示すブロック図である。
【図５】リクエスト記憶テーブルの例を示す図である。
【図６】レスポンス記憶テーブルの例を示す図である。
【図７】パス判定の処理例を示すフローチャートである。
【図８】パス判定の第１のシーケンス例を示す図である。
【図９】ロードバランシングの処理例を示すフローチャートである。
【図１０】ロードバランシングのシーケンス例を示す図である。
【図１１】第３の実施の形態のソフトウェア例を示すブロック図である。
【図１２】第４の実施の形態のソフトウェア例を示すブロック図である。
【図１３】パス判定の第２のシーケンス例を示す図である。
【図１４】第５の実施の形態のソフトウェア例を示すブロック図である。
【図１５】サーバ更新時の一時ルールの生成例を示す図である。
【図１６】サーバ更新の処理例を示すフローチャートである。
【発明を実施するための形態】
【００１６】
以下、本実施の形態を図面を参照して説明する。
［第１の実施の形態］
図１は、第１の実施の形態の情報処理装置を示す図である。情報処理装置１０は、サーバ装置２０，２０ａを備える情報処理システムのテストに用いられる。サーバ装置２０，２０ａは、リクエストを処理するためのサーバソフトウェアを実行することができる。
【００１７】
情報処理装置１０とサーバ装置２０，２０ａとは、ネットワークで接続されている。情報処理装置１０は、リクエストを生成するクライアント装置でもよいし、クライアント装置とサーバ装置２０，２０ａとの間でリクエストを中継する中継装置（例えば、ロードバランサと呼ばれるものやリバースプロキシと呼ばれるものなど）でもよい。情報処理装置１０は、ＣＰＵ（Central Processing Unit）などのプロセッサとＲＡＭなどのメモリとを備えてもよく、メモリに記憶されたプログラムをプロセッサが実行するコンピュータであってもよい。情報処理装置１０は、送信部１１および判定部１２を有する。
【００１８】
送信部１１は、１つのセッションに属する同一の２以上のリクエストについて、第１の送信処理（送信処理＃１）と第２の送信処理（送信処理＃２）とを実行する。送信部１１は、送信処理＃１では、２以上のリクエストを、サーバソフトウェアの状態をリクエスト間でリセットせずに、当該サーバソフトウェアを実行するサーバ装置に対して送信する。送信処理＃２では、２以上のリクエストを、サーバソフトウェアの状態をリクエスト間でリセットしつつ、当該サーバソフトウェアを実行するサーバ装置に対して送信する。送信部１１は、送信処理＃１，＃２の何れを先に実行してもよい。
【００１９】
送信処理＃１では、好ましくは、２以上のリクエストが単一のサーバ装置（例えば、サーバ装置２０）に送信される。送信処理＃２では、２以上のリクエストが、単一のサーバ装置に送信されてもよいし、２以上のサーバ装置（例えば、サーバ装置２０，２０ａ）に分散して送信されてもよい。また、送信処理＃２では、２以上のリクエストが、１またはそれ以上のサーバ装置で動作する２以上の仮想サーバ装置（仮想マシン）に分散して送信されてもよい。送信処理＃１の送信先と送信処理＃２の送信先とは異なってもよい。リクエストは、ＨＴＴＰリクエストであってもよく、リクエスト対象のファイルのパス（例えば、ＵＲＬ（Uniform Resource Locator）のパス）を含んでもよい。
【００２０】
サーバソフトウェアの状態は、例えば、サーバ装置２０，２０ａが記憶装置（例えば、ＲＡＭやＨＤＤなど）内のサーバソフトウェアの使用する記憶領域のデータを、リクエスト処理前のデータに戻す（リバートする）ことでリセットすることができる。その場合、サーバ装置２０，２０ａは、リクエスト処理前の上記記憶領域のデータを退避しておく。送信部１１は、リクエスト間で、状態をリセットするようリクエストの送信先に指示してもよい。例えば、送信部１１は、リクエスト＃１をサーバ装置２０に送信し、サーバ装置２０に状態のリセットを指示した後、リクエスト＃２をサーバ装置２０に送信する。
【００２１】
判定部１２は、送信処理＃１に対応して受信される第１のレスポンス（レスポンス＃１）と、送信処理＃２に対応して受信される第２のレスポンス（レスポンス＃２）とを取得する。レスポンス＃１，＃２として、それぞれ、２以上のリクエストに対応する２以上のレスポンスが受信され得る。判定部１２は、レスポンス＃１，＃２を比較し、比較結果に基づいて、送信部１１が送信した２以上のリクエストが同じサーバ装置で処理されるべきか判定する。例えば、判定部１２は、レスポンス＃１，＃２の内容が同じ場合、異なるサーバ装置で処理してもよいと判定し、レスポンス＃１，＃２の内容が異なる場合、同じサーバ装置で処理すべきと判定する。レスポンスは、ＨＴＴＰレスポンスであってもよい。
【００２２】
ここで、判定部１２は、判定結果を情報処理システムの管理者に通知してもよいし、判定結果に基づいてロードバランシングのルールを生成して中継装置（例えば、ロードバランサやリバースプロキシなど）に登録してもよい。後者の場合、判定部１２は、例えば、送信部１１が送信した２以上のリクエストで指定されているパスを抽出し、抽出したパスを、同一セッションの先のリクエストと同じサーバ装置にリクエストを転送すべきパス（スティッキーなパス）としてルールに登録する。
【００２３】
第１の実施の形態の情報処理装置１０によれば、１つのセッションに属する２以上のリクエストを、サーバソフトウェアの状態をリクエスト間でリセットせず、サーバソフトウェアを実行するサーバ装置に対して送信する（送信処理＃１）。また、当該２以上のリクエストを、サーバソフトウェアの状態をリクエスト間でリセットしつつ、サーバソフトウェアを実行するサーバ装置に対して送信する（送信処理＃２）。送信処理＃１に対応して受信されるレスポンス＃１と送信処理＃２に対応して受信されるレスポンス＃２とを比較し、比較結果に基づいて、上記２以上のリクエストについて同じサーバ装置が処理するよう制限するか否か判定する。これにより、複数のサーバ装置を備える情報処理システムにおけるロードバランシングのルールを、効率的に判定することができる。
【００２４】
例えば、サーバソフトウェアの状態の変化（副作用と呼ぶことがある）を検出する方法として、サーバ装置２０，２０ａが備えるＲＡＭやＨＤＤなどの記憶装置へのデータの書き込みを監視する方法も考えられる。しかし、この方法では、サーバソフトウェア毎に個別の改変が必要であり、サーバソフトウェアの改変や監視用ソフトウェアのサーバ装置２０，２０ａへの追加を行うことになり、テストの負担が大きいという問題がある。また、サーバ装置２０，２０ａの記憶装置に書き込まれるデータが、１つのリクエストの処理内で利用される一時的なデータに過ぎず、後のリクエストの処理に引き継がれない（副作用でない）場合もある。このため、スティッキネスの判定を誤る可能性がある。一方、情報処理装置１０によれば、サーバ装置２０，２０ａの外部から、スティッキネスを効率的に判定することができる。
【００２５】
以下に説明する第２〜第５の実施の形態では、ＨＴＴＰを用いてＨＴＭＬ（HyperText Markup Language）文書などのファイルを、サーバ装置からクライアント装置に送信するＷＷＷシステムの例を挙げる。ただし、第１の実施の形態の方法は、ＷＷＷシステム以外の情報処理システムに適用することも可能である。
【００２６】
［第２の実施の形態］
図２は、第２の実施の形態の情報処理システムを示す図である。第２の実施の形態の情報処理システムは、リバースプロキシサーバ１００、アプリケーションサーバ２００，２００ａ，２００ｂ、データベースサーバ３００およびクライアント４００，４００ａを含む。
【００２７】
ネットワーク３１に、リバースプロキシサーバ１００、アプリケーションサーバ２００，２００ａ，２００ｂおよびデータベースサーバ３００が接続されている。ネットワーク３２に、リバースプロキシサーバ１００およびクライアント４００，４００ａが接続されている。ネットワーク３１はＬＡＮ（Local Area Network）でもよく、ネットワーク３２はインターネットなどの広域ネットワークでもよい。ただし、アプリケーションサーバ２００，２００ａ，２００ｂとクライアント４００，４００ａが、同一ネットワークに接続されてもよい。
【００２８】
リバースプロキシサーバ１００は、ロードバランサおよびリバースプロキシとして動作するサーバコンピュータである。リバースプロキシサーバ１００は、クライアント４００，４００ａからリクエストを受信し、アプリケーションサーバ２００，２００ａ，２００ｂの何れかに転送する。また、アプリケーションサーバ２００，２００ａ，２００ｂからレスポンスを受信し、レスポンスで指定された宛先のクライアントに転送する。リバースプロキシサーバ１００は、ロードバランシングのため、リバースプロキシサーバ１００に設定されたルールに基づいて、受信したリクエストをアプリケーションサーバ２００，２００ａ，２００ｂに振り分ける。
【００２９】
アプリケーションサーバ２００，２００ａ，２００ｂは、リクエストを処理するサーバソフトウェア（例えば、Ｗｅｂアプリケーションソフトウェア）を実行するサーバコンピュータである。アプリケーションサーバ２００，２００ａ，２００ｂは、リクエストとしてＨＴＴＰリクエストを受信し、リクエストで指定されるパス（例えば、ＵＲＬのパス）に応じた処理を行い、レスポンスとしてＨＴＴＰレスポンスを送信する。アプリケーションサーバ２００，２００ａ，２００ｂは、リクエストの処理において、データの読み出しや更新のため、データベースサーバ３００にアクセスすることがある。
【００３０】
データベースサーバ３００は、データベース管理システム（ＤＢＭＳ：Database Management System）を実行するサーバコンピュータである。データベースサーバ３００は、アプリケーションサーバ２００，２００ａ，２００ｂが利用するデータを不揮発性の記憶装置に記憶し、アクセスに応じてデータの読み出しや更新を行う。
【００３１】
クライアント４００，４００ａは、リクエストを発行するクライアントソフトウェア（例えば、Ｗｅｂブラウザ）を実行するクライアントコンピュータであり、例えば、情報処理システムのユーザや管理者が操作する端末装置である。クライアント４００，４００ａは、リクエストとしてＨＴＴＰリクエストを送信し、レスポンスとしてＨＴＴＰレスポンスを受信する。例えば、ＨＴＴＰリクエストにはＵＲＬが含まれ、ＨＴＴＰレスポンスにはＨＴＭＬ文書が含まれる。クライアント４００，４００ａは、例えば、ＨＴＴＰレスポンスに含まれるＨＴＭＬ文書をディスプレイに表示（レンダリング）する。
【００３２】
ここで、同一のクライアントが行う一連のＨＴＴＰ通信には、セッションＩＤが用いられる。クライアント４００，４００ａは、セッションの最初では、セッションＩＤを含まないリクエストを送信する。アプリケーションサーバ２００，２００ａ，２００ｂは、セッションＩＤを含まないリクエストを受信すると、新たなセッションＩＤを生成し、生成したセッションＩＤを含むレスポンスを送信する。クライアント４００，４００ａは、レスポンスに含まれるセッションＩＤを自装置に保存し、以降、同一セッションでは、保存したセッションＩＤを含むリクエストを送信する。
【００３３】
ロードバランシングでは、リクエストに含まれるパスとセッションＩＤとに基づいて、当該リクエストを処理するアプリケーションサーバが選択される。リクエスト振り分けのルールでは、スティッキーなパスが指定されている。リバースプロキシサーバ１００は、リクエストがセッションＩＤを含まない場合、当該リクエストを任意のアプリケーションサーバに転送する。また、リクエストがスティッキーでないパスを指定している場合も、当該リクエストを任意のアプリケーションサーバに転送する。一方、リクエストがセッションＩＤを含みスティッキーなパスを指定している場合、同一セッションに属する先のリクエストと同じアプリケーションサーバに、当該リクエストを転送する。当該リクエストは、先のリクエストに関するデータを利用して処理される可能性があるためである。
【００３４】
任意のアプリケーションサーバを選択する場合、ラウンドロビンによって転送先を選択してもよい。また、アプリケーションサーバ２００，２００ａ，２００ｂの処理能力や現在の負荷に基づいて転送頻度を重み付けして、転送先を選択してもよい。
【００３５】
先のリクエストと同じアプリケーションサーバを選択する場合、例えば、以下のような方法を用いる。まず、アプリケーションサーバ２００，２００ａ，２００ｂが、セッションＩＤを生成したあとリバースプロキシサーバ１００がアプリケーションサーバを識別できるようにする。例えば、セッションＩＤの末尾に、アプリケーションサーバを識別するための文字を付加する。一例として、アプリケーションサーバ２００ａからのレスポンスには“．ａ”をセッションＩＤの末尾に付加し、アプリケーションサーバ２００ｂからのレスポンスには“．ｂ”をセッションＩＤの末尾に付加するようにする。リバースプロキシサーバ１００は、セッションＩＤの末尾を参照して当該セッションＩＤを付与したアプリケーションサーバを判定し、リクエストの転送先を選択する。ただし、上記方法は一例であり、他の方法を用いてもよい。例えば、リバースプロキシサーバ１００が、アプリケーションサーバ２００，２００ａ，２００ｂとセッションＩＤの対応関係を記憶してもよい。
【００３６】
第２の実施の形態では、ロードバランシングのルールを設定するにあたり、リバースプロキシサーバ１００、アプリケーションサーバ２００およびクライアント４００を用いて、アプリケーションソフトウェアのテストを行い、スティッキーなパスを判定する。以下、ロードバランシングのルールの設定方法を説明する。
【００３７】
図３は、リバースプロキシサーバのハードウェア例を示すブロック図である。リバースプロキシサーバ１００は、ＣＰＵ１０１、ＲＡＭ１０２、ＨＤＤ１０３、画像信号処理部１０４、入力信号処理部１０５、ディスクドライブ１０６および通信部１０７，１０８を有する。各ユニットがリバースプロキシサーバ１００のバスに接続されている。アプリケーションサーバ２００，２００ａ，２００ｂ、データベースサーバ３００およびクライアント４００，４００ａも、リバースプロキシサーバ１００と同様のハードウェアを用いて実装できる。
【００３８】
ＣＰＵ１０１は、リバースプロキシサーバ１００の情報処理を制御するプロセッサである。ＣＰＵ１０１は、ＨＤＤ１０３に記憶されているプログラムやデータの少なくとも一部を読み出し、ＲＡＭ１０２に展開してプログラムを実行する。なお、リバースプロキシサーバ１００は、複数のプロセッサを設けて、プログラムを分散して実行してもよい。
【００３９】
ＲＡＭ１０２は、ＣＰＵ１０１が実行するプログラムや処理に用いるデータを一時的に記憶する揮発性メモリである。なお、リバースプロキシサーバ１００は、ＲＡＭ以外の種類のメモリを備えてもよく、複数個のメモリを備えていてもよい。
【００４０】
ＨＤＤ１０３は、ＯＳ（Operating System）プログラムやアプリケーションプログラムなどのプログラムおよびデータを記憶する不揮発性の記憶装置である。ＨＤＤ１０３は、ＣＰＵ１０１の命令に従って、内蔵の磁気ディスクに対してデータの読み書きを行う。なお、リバースプロキシサーバ１００は、ＨＤＤ以外の種類の不揮発性の記憶装置（例えば、ＳＳＤなど）を備えてもよく、複数の記憶装置を備えていてもよい。
【００４１】
画像信号処理部１０４は、ＣＰＵ１０１の命令に従って、リバースプロキシサーバ１００に接続されたディスプレイ４１に画像を出力する。ディスプレイ４１としては、例えば、ＣＲＴ（Cathode Ray Tube）ディスプレイや液晶ディスプレイを用いることができる。
【００４２】
入力信号処理部１０５は、リバースプロキシサーバ１００に接続された入力デバイス４２から入力信号を取得し、ＣＰＵ１０１に出力する。入力デバイス４２としては、例えば、マウスやタッチパネルなどのポインティングデバイス、キーボードなどを用いることができる。
【００４３】
ディスクドライブ１０６は、記録媒体４３に記録されたプログラムやデータを読み取る駆動装置である。記録媒体４３として、例えば、フレキシブルディスク（ＦＤ：Flexible Disk）やＨＤＤなどの磁気ディスク、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disc）などの光ディスク、光磁気ディスク（ＭＯ：Magneto-Optical disk）を使用できる。ディスクドライブ１０６は、例えば、ＣＰＵ１０１の命令に従って、記録媒体４３から読み取ったプログラムやデータをＲＡＭ１０２またはＨＤＤ１０３に格納する。
【００４４】
通信部１０７は、ネットワーク３１を介してアプリケーションサーバ２００，２００ａ，２００ｂと通信を行う通信インタフェースである。通信部１０８は、ネットワーク３２を介してクライアント４００，４００ａと通信を行う通信インタフェースである。通信部１０７，１０８は、有線通信インタフェースでもよいし、無線通信インタフェースでもよい。なお、リバースプロキシサーバ１００は、１つの通信インタフェースで、ネットワーク３１，３２を介した通信を行えるようにしてもよい。
【００４５】
図４は、第２の実施の形態のソフトウェア例を示すブロック図である。図４に示すユニットの一部または全部は、リバースプロキシサーバ１００、アプリケーションサーバ２００およびクライアント４００が実行するプログラムのモジュールであってもよい。また、図４に示すユニットの一部または全部は、ＦＰＧＡ（Field Programmable Gate Array）やＡＳＩＣ（Application Specific Integrated Circuit）などの電子回路であってもよい。
【００４６】
リバースプロキシサーバ１００は、テスト中継部１１１，１１２、リクエスト処理部１１３、リクエスト記憶部１１４、レスポンス処理部１１５、レスポンス記憶部１１６、退避復元指示部１１７、ルール記憶部１２１および中継部１２２を有する。
【００４７】
テスト中継部１１１は、サーバソフトウェアのテストに関して、クライアント４００と通信を行う。テスト中継部１１１は、クライアント４００からリクエストを受信し、受信したリクエストをリクエスト処理部１１３に出力する。また、レスポンス処理部１１５からレスポンスを取得し、取得したレスポンスをクライアント４００に送信する。
【００４８】
テスト中継部１１２は、サーバソフトウェアのテストに関して、アプリケーションサーバ２００と通信を行う。テスト中継部１１２は、リクエスト処理部１１３からリクエストを取得し、取得したリクエストをアプリケーションサーバ２００に送信する。また、アプリケーションサーバ２００からレスポンスを受信し、受信したレスポンスをレスポンス処理部１１５に出力する。また、テスト中継部１１２は、アプリケーションサーバ２００からのレスポンスの受信状況を、退避復元指示部１１７に通知する。
【００４９】
リクエスト処理部１１３は、テストの第１フェーズにおいて、テスト中継部１１１からリクエストを取得し、取得したリクエストをリクエスト記憶部１１４に記憶し、また、取得したリクエストをテスト中継部１１２に出力する。また、リクエスト処理部１１３は、テストの第２フェーズにおいて、リクエスト記憶部１１４から第１フェーズで格納した順番に１つずつリクエストを読み出し、テスト中継部１１２に出力する。
【００５０】
リクエスト記憶部１１４は、クライアント４００が送信したリクエストを、送信順序を維持して記憶する。リクエスト記憶部１１４は、ＲＡＭ１０２に確保された記憶領域でもよいし、ＨＤＤ１０３に確保された記憶領域であってもよい。
【００５１】
レスポンス処理部１１５は、テストの第１フェーズにおいて、テスト中継部１１２からレスポンスを取得し、取得したレスポンスをレスポンス記憶部１１６に記憶し、また、取得したレスポンスをテスト中継部１１１に出力する。また、レスポンス処理部１１５は、テストの第２フェーズにおいて、テスト中継部１１２からレスポンスを取得し、取得したレスポンスと第１フェーズでレスポンス記憶部１１６に格納したレスポンスを比較する。そして、比較結果に基づいて、リクエストで指定されたパスがスティッキーか判定する。レスポンス処理部１１５は、判定結果をクライアント４００に報告する。
【００５２】
レスポンス記憶部１１６は、アプリケーションサーバ２００が送信したレスポンスを、送信順序を維持して記憶する。レスポンス記憶部１１６は、ＲＡＭ１０２に確保された記憶領域でもよいし、ＨＤＤ１０３に確保された記憶領域であってもよい。
【００５３】
退避復元指示部１１７は、クライアント４００からコマンドを受信し、サーバソフトウェアのテストを制御する。退避復元指示部１１７は、テストの第１フェーズの最初に、サーバソフトウェアの状態のスナップショットを作成する命令（退避コマンド）を、アプリケーションサーバ２００に送信する。また、退避復元指示部１１７は、テストの第２フェーズの最初および第２フェーズのレスポンスを受信する毎に、サーバソフトウェアの状態を戻す命令（復元コマンド）を、アプリケーションサーバ２００に送信する。
【００５４】
ルール記憶部１２１は、ロードバランシングのルールを記憶する。ルールは、例えば、クライアント４００を操作する管理者によって作成され、ルール記憶部１２１に登録される。ルールには、スティッキーなパスが含まれる。ルール記憶部１２１は、ＲＡＭ１０２に確保された記憶領域でもよいし、ＨＤＤ１０３に確保された記憶領域であってもよい。
【００５５】
中継部１２２は、運用開始後のサーバソフトウェアに関して、リクエストおよびレスポンスを中継する。中継部１２２は、クライアント４００，４００ａからリクエストを受信し、ルール記憶部１２１に記憶されたルールを参照し、受信したリクエストをアプリケーションサーバ２００，２００ａ，２００ｂの何れかに転送する。また、中継部１２２は、アプリケーションサーバ２００，２００ａ，２００ｂからレスポンスを受信し、受信したレスポンスを当該レスポンスが指定する宛先のクライアントに転送する。
【００５６】
アプリケーションサーバ２００は、コンピュータの仮想化技術を用いて、１またはそれ以上の仮想マシンを動作させる。アプリケーションサーバ２００は、仮想マシン２１１およびハイパーバイザ２１２を有する。ハイパーバイザ２１２は、スナップショット管理部２１３、メモリデータ記憶部２１４およびディスク差分記憶部２１５を有する。
【００５７】
仮想マシン２１１は、サーバソフトウェア（例えば、Ｗｅｂアプリケーションソフトウェア）を実行する仮想的なコンピュータである。アプリケーションサーバ２００は、複数の仮想マシンを動作させてもよく、１またはそれ以上の仮想マシンにＤＢＭＳを実行させてもよい。各仮想マシンは、ＯＳを実行し、ハイパーバイザ２１２から割り当てられたリソース（ＣＰＵの処理能力やＲＡＭの記憶領域など）を用いて処理を行う。
【００５８】
ハイパーバイザ２１２は、仮想マシン２１１を含む１またはそれ以上の仮想マシンにリソースを割り当て、仮想マシンを管理する制御ソフトウェアである。
スナップショット管理部２１３は、サーバソフトウェアを実行する仮想マシン２１１のスナップショットを管理する。スナップショット管理部２１３は、リバースプロキシサーバ１００から退避コマンドを受信すると、受信時点のＲＡＭ上にある仮想マシン２１１のデータを、メモリデータ記憶部２１４に退避する。また、受信時点のＨＤＤ上にある仮想マシン２１１のデータを、ディスク差分記憶部２１５に退避する。また、スナップショット管理部２１３は、リバースプロキシサーバ１００から復元コマンドを受信すると、メモリデータ記憶部２１４に退避したデータをＲＡＭに戻し、ディスク差分記憶部２１５に退避したデータをＨＤＤに戻す（リバートする）。
【００５９】
メモリデータ記憶部２１４は、ＲＡＭ上にある仮想マシン２１１のある時点のデータ（スナップショット）を記憶する。メモリデータ記憶部２１４は、例えば、ＨＤＤに確保された記憶領域とすることができる。
【００６０】
ディスク差分記憶部２１５は、ＨＤＤ上にある仮想マシン２１１のある時点のデータ（スナップショット）を記憶する。ディスク差分記憶部２１５は、例えば、ＨＤＤに確保された記憶領域とすることができる。なお、ディスク差分記憶部２１５が管理するデータは、アプリケーションサーバ２００で動作させる仮想マシンの基本となるイメージデータと、仮想マシン２１１の個別のディスクデータとの間の差分である。アプリケーションサーバ２００は、基本となるイメージデータと仮想マシン２１１に対応する差分データとを合成することで、仮想マシン２１１のディスクデータを得ることができる。
【００６１】
クライアント４００は、テスト実行部４１１を有する。
テスト実行部４１１は、クライアント４００を操作する管理者の指示に応じて、サーバソフトウェアのテストを制御する。テスト実行部４１１は、テストの第１フェーズの開始を指示するコマンドをリバースプロキシサーバ１００に送信する。そして、テストケースとして同一セッションに属する２以上のリクエストの列を生成し、２以上のリクエストを順次リバースプロキシサーバ１００に送信する。例えば、テスト実行部４１１は、１つのリクエストの送信と当該リクエストに対応する１つのレスポンスの受信とを、テストケースに含まれる全てのリクエストを送信し終えるまで繰り返す。また、テスト実行部４１１は、テストの第２フェーズの開始を指示するコマンドをリバースプロキシサーバ１００に送信する。テスト実行部４１１は、パスの判定結果をリバースプロキシサーバ１００から受信し、ディスプレイに表示する。
【００６２】
なお、第２の実施の形態のリバースプロキシサーバ１００は、第１の実施の形態の情報処理装置１０の一例である。通信部１０７、または、テスト中継部１１２および退避復元指示部１１７は、送信部１１の一例である。ＣＰＵ１０１およびＲＡＭ１０２、または、レスポンス処理部１１５は、判定部１２の一例である。
【００６３】
図５は、リクエスト記憶テーブルの例を示す図である。リクエスト記憶テーブル１３１は、リバースプロキシサーバ１００のリクエスト記憶部１１４に記憶される。リクエスト記憶テーブル１３１は、順序、メソッド、パスおよびボディの項目を含む。
【００６４】
順序の項目には、テストの第１フェーズでクライアント４００から受信したリクエストの順序を示す値（例えば、連番の自然数）が登録される。メソッドの項目には、リクエストに含まれるＨＴＴＰメソッドが登録される。例えば、メソッド＝ＧＥＴは、ＵＲＬで指定した情報の要求を示し、メソッド＝ＰＯＳＴは、クライアントソフトウェアからサーバソフトウェアへのデータ送信を伴うことを示す。パスの項目には、リクエストに含まれるＵＲＬ内のパス名が登録される。ボディの項目には、リクエストに含まれるＨＴＴＰのボディが登録される。リクエストは、ボディを含まない場合もある。
【００６５】
ＵＲＬは、例えば、プロトコルに応じたスキーム名とドメイン名を含むホスト名とに続けて、パス名を記述する。パスは、例えば、ＨＴＭＬ文書、画像ファイル、ＨＴＭＬ文書を生成するプログラムのファイルなどのファイルを指定する。
【００６６】
図６は、レスポンス記憶テーブルの例を示す図である。レスポンス記憶テーブル１３２は、リバースプロキシサーバ１００のレスポンス記憶部１１６に記憶される。レスポンス記憶テーブル１３２は、順序、レスポンスコードおよびボディの項目を含む。
【００６７】
順序の項目には、テストの第１フェーズでアプリケーションサーバ２００から受信したレスポンスの順序を示す値（例えば、連番の自然数）が登録される。レスポンスコードの項目には、レスポンスに含まれるレスポンスコードが登録される。レスポンスコードは、リクエストがサーバソフトウェアによってどのように処理されたかを示す。例えば、レスポンスコード＝２００は、リクエストの成功を示し、メソッド＝ＧＥＴに対応するレスポンスで使用され得る。レスポンス＝３０４は、レスポンスのボディが前回から変化がないことを示し、メソッド＝ＰＯＳＴに対応するレスポンスで使用され得る。ボディの項目には、レスポンスに含まれるＨＴＴＰのボディ（例えば、ＨＴＭＬ文書のテキスト）が登録される。レスポンスは、ボディを含まない場合もある。
【００６８】
図７は、パス判定の処理例を示すフローチャートである。
（ステップＳ１１）テスト実行部４１１は、テストの第１フェーズの開始を示す開始コマンドを、リバースプロキシサーバ１００に送信する。退避復元指示部１１７は、退避コマンドをアプリケーションサーバ２００に送信する。スナップショット管理部２１３は、仮想マシン２１１について、退避コマンドを受信した時点のＲＡＭのデータを、スナップショットとしてメモリデータ記憶部２１４に保存する。また、退避コマンドを受信した時点のＨＤＤのディスクデータと基本となるイメージデータとの間の差分を算出し、差分データを、スナップショットしてディスク差分記憶部２１５に保存する。
【００６９】
（ステップＳ１２）テスト実行部４１１は、テストケースに含まれる１つのリクエストをリバースプロキシサーバ１００に送信する。リクエスト処理部１１３は、テスト実行部４１１から受信したリクエストをリクエスト記憶部１１４に保存し、また、当該リクエストをアプリケーションサーバ２００に転送する。仮想マシン２１１は、リバースプロキシサーバ１００から受信したリクエストの指定するパスに応じた処理を行い、レスポンスをリバースプロキシサーバ１００に送信する。このとき、仮想マシン２１１は、レスポンスにセッションＩＤを付与することがある。また、ＲＡＭやＨＤＤに記憶されているセッションのデータを利用することがあり、セッションのデータを更新することもある。
【００７０】
（ステップＳ１３）レスポンス処理部１１５は、アプリケーションサーバ２００から受信したレスポンスをレスポンス記憶部１１６に保存し、また、当該レスポンスをクライアント４００に転送する。テスト実行部４１１は、レスポンスを受信する。
【００７１】
（ステップＳ１４）テスト実行部４１１は、テストケースに後続のリクエストが含まれているか判断する。後続のリクエストがある場合、後続のリクエストが先のリクエストと同一のセッションに属するように（例えば、後続のリクエストがアプリケーションサーバ２００から付与されたセッションＩＤを含むように）して、処理をステップＳ１２に進める。後続のリクエストがない場合、処理をステップＳ１５に進める。
【００７２】
（ステップＳ１５）テスト実行部４１１は、テストの第２フェーズの開始を示す開始コマンドを、リバースプロキシサーバ１００に送信する。退避復元指示部１１７は、復元コマンドをアプリケーションサーバ２００に送信する。スナップショット管理部２１３は、メモリデータ記憶部２１４にスナップショットとして記憶されたデータを、ＲＡＭ１０２に書き戻す。また、ディスク差分記憶部２１５にスナップショットとして記憶された差分データを用いて、ＨＤＤ１０３のディスクデータを復元する。これにより、仮想マシン２１１で実行されるサーバソフトウェアの状態が、テストケース実行前の状態に戻る。
【００７３】
（ステップＳ１６）リクエスト処理部１１３は、リクエスト記憶部１１４に記憶されたリクエストを、格納順序の早い方から１つ抽出し、リクエストをアプリケーションサーバ２００に再送する。仮想マシン２１１は、リバースプロキシサーバ１００から受信したリクエストの指定するパスに応じた処理を行い、レスポンスをリバースプロキシサーバ１００に送信する。
【００７４】
（ステップＳ１７）レスポンス処理部１１５は、レスポンス記憶部１１６に記憶されたレスポンスを、格納順序の早い方から１つ抽出し、アプリケーションサーバ２００から受信したレスポンスと比較する。レスポンス処理部１１５は、２つのレスポンスの内容の同一性を判定する。例えば、レスポンスコードとボディのテキストとの両方が一致したときに同一であると判定し、少なくとも一方が異なるときには同一でないと判定する。レスポンスコードとボディ以外の情報は、同一性の判定において無視してもよい。
【００７５】
（ステップＳ１８）退避復元指示部１１７は、第２フェーズにおけるレスポンスの受信を検出すると、復元コマンドをアプリケーションサーバ２００に送信する。スナップショット管理部２１３は、メモリデータ記憶部２１４およびディスク差分記憶部２１５に記憶されたスナップショットを用いて、ＲＡＭ１０２のデータおよびＨＤＤ１０３のディスクデータを復元する。これにより、サーバソフトウェアの状態が、ステップＳ１６のリクエストを処理する前の状態に戻る。なお、レスポンス処理部１１５による判定処理（ステップＳ１７）と、スナップショット管理部２１３による復元処理（ステップＳ１８）とは、任意の順序で実行してよく、並列に実行することもできる。
【００７６】
（ステップＳ１９）リクエスト処理部１１３は、リクエスト記憶部１１４に残りのリクエストが記憶されているか判断する。残りのリクエストがある場合、処理をステップＳ１６に進める。残りのリクエストがない場合、処理をステップＳ２０に進める。
【００７７】
（ステップＳ２０）レスポンス処理部１１５は、パス判定結果をクライアント４００に報告する。ステップＳ１７で少なくとも１つのレスポンスについて同一でないと判定したときは、２以上のリクエストそれぞれで指定されたパスを、スティッキーなパスと判定する。一方、ステップＳ１７で全てのレスポンスについて同一であると判定したときは、２以上のリクエストそれぞれで指定されたパスを、スティッキーでないパスと判定する。テスト実行部４１１は、リバースプロキシサーバ１００から報告されたパス判定結果を、例えば、クライアント４００に接続されたディスプレイに表示する。管理者は、パス判定結果を参照して、ロードバランシングのルールを作成することができる。
【００７８】
なお、図７のフローでは、第２フェーズのステップＳ１６〜Ｓ１８の処理を、テストケースに含まれる全てのリクエストについて行った。しかし、ステップＳ１７で、あるレスポンスについて同一でないと判定された場合、その時点で第２フェーズを終了して以降のリクエストをアプリケーションサーバ２００に再送しないようにしてもよい。
【００７９】
図８は、パス判定の第１のシーケンス例を示す図である。
クライアント４００は、第１フェーズの開始コマンドを、リバースプロキシサーバ１００に送信する（ステップＳ１１１）。リバースプロキシサーバ１００は、退避コマンドをアプリケーションサーバ２００に送信する。アプリケーションサーバ２００は、テストケース実行前のサーバソフトウェアの状態に対応するスナップショットを保存する（ステップＳ１１２）。
【００８０】
クライアント４００は、テストケースに含まれるリクエストを１つリバースプロキシサーバ１００に送信する（ステップＳ１１３）。リバースプロキシサーバ１００は、リクエストを保存し、また、当該リクエストをアプリケーションサーバ２００に転送する（ステップＳ１１４）アプリケーションサーバ２００は、リクエストを処理し、レスポンスをリバースプロキシサーバ１００に送信する（ステップＳ１１５）。リバースプロキシサーバ１００は、レスポンスを保存し、また、当該レスポンスをクライアント４００に転送する（ステップＳ１１６）。以下、ステップＳ１１３〜Ｓ１１６のシーケンスが、リクエスト数に応じて繰り返される。
【００８１】
クライアント４００は、第２フェーズの開始コマンドを、リバースプロキシサーバ１００に送信する（ステップＳ１１７）。リバースプロキシサーバ１００は、復元コマンドをアプリケーションサーバ２００に送信する。アプリケーションサーバ２００は、サーバソフトウェアの状態をテストケース実行前の状態にリバートする（ステップＳ１１８）。
【００８２】
リバースプロキシサーバ１００は、保存しておいたリクエストを１つアプリケーションサーバ２００に再送する（ステップＳ１１９）。アプリケーションサーバ２００は、リクエストを処理し、レスポンスをリバースプロキシサーバ１００に送信する。リバースプロキシサーバ１００は、第１フェーズのレスポンスと第２フェーズのレスポンスとを比較して、内容の同一性を判定する（ステップＳ１２０）。リバースプロキシサーバ１００は、復元コマンドをアプリケーションサーバ２００に送信する。アプリケーションサーバ２００は、サーバソフトウェアの状態をリクエスト処理前の状態にリバートする（ステップＳ１２１）。以下、ステップＳ１１９〜Ｓ１２１のシーケンスが、リクエスト数に応じて繰り返される。
【００８３】
リバースプロキシサーバ１００は、ステップＳ１２０で判定されたレスポンスの同一性に基づいて、リクエストで指定されたパスがスティッキーであるか否かを示すパス判定結果を、クライアント４００に報告する（ステップＳ１２２）。
【００８４】
図９は、ロードバランシングの処理例を示すフローチャートである。ここでは、ロードバランシングのルールが設定された後、クライアント４００ａが送信したリクエストを、アプリケーションサーバ２００ａ，２００ｂが処理する場合を考える。
【００８５】
（ステップＳ２１）中継部１２２は、クライアント４００ａのリクエストを受信する。
（ステップＳ２２）中継部１２２は、受信したリクエストに含まれるＵＲＬのパスが、ルール記憶部１２１に記憶されたルールにスティッキーなパスとして登録されているか判断する。パスが登録されている場合、処理をステップＳ２３に進める。パスが登録されていない場合、処理をステップＳ２５に進める。
【００８６】
（ステップＳ２３）中継部１２２は、受信したリクエストがセッションＩＤを含むか判断する。セッションＩＤを含む場合、処理をステップＳ２４に進める。セッションＩＤを含まない場合、処理をステップＳ２５に進める。なお、セッションＩＤとしては、ＪＳＥＳＳＩＯＮＩＤを用いてもよい。セッションＩＤは、ＵＲＬに付加されていることもあるし、ＨＴＴＰヘッダにＣｏｏｋｉｅの値として挿入されていることもあるし、ＨＴＴＰのボディにｈｉｄｄｅｎ項目として挿入されていることもある。
【００８７】
（ステップＳ２４）中継部１２２は、セッションＩＤから転送先のアプリケーションサーバを判定する。例えば、中継部１２２は、セッションＩＤの末尾を確認し、末尾が“．ａ”のときはアプリケーションサーバ２００ａ、末尾が“．ｂ”のときはアプリケーションサーバ２００ｂを、転送先と判定する。そして、処理をステップＳ２６に進める。
【００８８】
（ステップＳ２５）中継部１２２は、任意のアプリケーションサーバを、リクエストの転送先として選択する。例えば、中継部１２２は、ラウンドロビンにより、アプリケーションサーバ２００ａ，２００ｂを交互に選択する。選択アルゴリズムは、ルール記憶部１２１に記憶されるルールで指定しておいてもよい。
【００８９】
（ステップＳ２６）中継部１２２は、ステップＳ２４またはステップＳ２５で選択されたアプリケーションサーバに、受信したリクエストを転送する。
（ステップＳ２７）中継部１２２は、リクエストの転送先のアプリケーションサーバからレスポンスを受信し、レスポンスの宛先のクライアントに転送する。
【００９０】
図１０は、ロードバランシングのシーケンス例を示す図である。
クライアント４００ａは、セッションの最初に、セッションＩＤを含まないリクエストをリバースプロキシサーバ１００に送信する（ステップＳ２１１）。リバースプロキシサーバ１００は、任意のアプリケーションサーバ（図１０のシーケンス例では、アプリケーションサーバ２００ａ）を選択し、リクエストを転送する（ステップＳ２１２）。
【００９１】
アプリケーションサーバ２００ａは、セッションＩＤ＝ＸＸＸを生成し、リクエストが指定するパスに応じた処理を行う。リクエストの処理では、アプリケーションサーバ２００ａが備えるＲＡＭやＨＤＤに、セッションＩＤと対応づけてデータが書き込まれることがある。アプリケーションサーバ２００ａは、セッションＩＤ＝ＸＸＸを含むレスポンスを、リバースプロキシサーバ１００に送信する（ステップＳ２１３）。リバースプロキシサーバ１００は、セッションＩＤをＸＸＸ．ａに書き換えたレスポンスをクライアント４００ａに転送する（ステップＳ２１４）。
【００９２】
クライアント４００ａは、ステップＳ２１１と同一セッションのリクエストを、ステップＳ２１３で付与されたセッションＩＤ＝ＸＸＸ．ａを付加して、リバースプロキシサーバ１００に送信する（ステップＳ２１５）。リバースプロキシサーバ１００は、リクエストが指定するパスがスティッキーなパスであることを確認すると、セッションＩＤの末尾を参照してアプリケーションサーバ２００ａを選択し、セッションＩＤをＸＸＸに書き換えたリクエストを転送する（ステップＳ２１６）。
【００９３】
アプリケーションサーバ２００ａは、リクエストが指定するパスに応じた処理を行う。リクエストの処理では、アプリケーションサーバ２００ａのＲＡＭやＨＤＤに記憶されているセッションＩＤ＝ＸＸＸ．ａに対応するデータが利用されることがあり、当該データが更新されることもある。アプリケーションサーバ２００ａは、レスポンスをリバースプロキシサーバ１００に送信する（ステップＳ２１７）。リバースプロキシサーバ１００は、レスポンスをクライアント４００ａに転送する（ステップＳ２１８）。
【００９４】
クライアント４００ａは、ステップＳ２１１，Ｓ２１５と異なるセッションのリクエストとして、セッションＩＤを含まないリクエストをリバースプロキシサーバ１００に送信する（ステップＳ２１９）。リバースプロキシサーバ１００は、任意のアプリケーションサーバ（図１０のシーケンス例では、アプリケーションサーバ２００ｂ）を選択し、リクエストをアプリケーションサーバ２００ｂに転送する（ステップＳ２２０）。
【００９５】
アプリケーションサーバ２００ｂは、セッションＩＤ＝ＸＸＸを生成し、リクエストが指定するパスに応じた処理を行う。リクエストの処理では、アプリケーションサーバ２００ｂが備えるＲＡＭやＨＤＤに、セッションＩＤと対応づけてデータが書き込まれることがある。アプリケーションサーバ２００ｂは、セッションＩＤ＝ＸＸＸを含むレスポンスを、リバースプロキシサーバ１００に送信する（ステップＳ２２１）。リバースプロキシサーバ１００は、セッションＩＤをＸＸＸ．ｂに書き換えたレスポンスをクライアント４００ａに転送する（ステップＳ２２２）。
【００９６】
なお、以上の第２の実施の形態の説明では、サーバソフトウェアの状態を戻すために、ハイパーバイザ２１２が、仮想マシン２１１のスナップショットを退避しておき、復元時にＲＡＭおよびＨＤＤ上にある仮想マシン２１１のデータを書き換えることとした。しかし、他の方法によって、サーバソフトウェアの状態を戻すこともできる。例えば、アプリケーションサーバ２００は、ファイルシステム上のサーバソフトウェアが使用するディレクトリを退避しておき、復元時にｃｈｒｏｏｔコマンドを用いて、サーバソフトウェアによって認識されるルートディレクトリを入れ替えるようにしてもよい。
【００９７】
第２の実施の形態の情報処理システムによれば、ロードバランシングのルールに登録するスティッキーなパスを、効率的に判定することができる。第２の実施の形態の方法は、アプリケーションサーバ２００が備えるＲＡＭやＨＤＤへのデータの書き込みを監視する方法と比べて、テストの負担を軽減することができ、また、判定精度を向上させることができる。また、リバースプロキシサーバ１００が、アプリケーションサーバ２００とクライアント４００との間でテストを実行するため、特定の種類のサーバソフトウェアやクライアントソフトウェアに依存しない方法で、効率的にテストを実行できる。
【００９８】
［第３の実施の形態］
次に、第３の実施の形態を説明する。第２の実施の形態との差異を中心に説明し、第２の実施の形態と同様の事項については説明を省略する。第３の実施の形態の情報処理システムは、パス判定をリバースプロキシサーバでなくクライアントが実行する。
【００９９】
図１１は、第３の実施の形態のソフトウェア例を示すブロック図である。クライアント４００ｂは、テスト実行部４２１、テスト中継部４２２、レスポンス処理部４２３、レスポンス記憶部４２４および退避復元指示部４２５を有する。図１１に示すクライアント４００ｂのユニットの一部または全部は、クライアント４００ｂが実行するプログラムのモジュールであってもよく、ＦＰＧＡやＡＳＩＣなどの電子回路であってもよい。
【０１００】
テスト実行部４２１は、サーバソフトウェアのテストを制御する。テスト実行部４２１は、テストケースとして同一セッションに属する２以上のリクエストの列を生成する。そして、テストの第１フェーズおよび第２フェーズそれぞれにおいて、生成した２以上のリクエストをテスト中継部４２２に順次出力する。
【０１０１】
テスト中継部４２２は、サーバソフトウェアのテストに関する通信を行う。テスト中継部４２２は、テスト実行部４２１からリクエストを取得し、取得したリクエストをアプリケーションサーバ２００に送信する。また、アプリケーションサーバ２００からレスポンスを受信し、受信したレスポンスをレスポンス処理部４２３に出力する。
【０１０２】
レスポンス処理部４２３は、テストの第１フェーズにおいて、テスト中継部４２２からレスポンスを取得し、取得したレスポンスをレスポンス記憶部４２４に記憶する。また、レスポンス処理部４２３は、テストの第２フェーズにおいて、テスト中継部４２２からレスポンスを取得し、取得したレスポンスとレスポンス記憶部４２４に格納したレスポンスを比較する。そして、比較結果に基づいて、リクエストで指定されたパスがスティッキーか判定する。レスポンス処理部４２３は、例えば、判定結果をディスプレイに表示する。
【０１０３】
レスポンス記憶部４２４は、アプリケーションサーバ２００が送信したレスポンスを、送信順序を維持して記憶する。レスポンス記憶部４２４は、クライアント４００ｂが備えるＲＡＭやＨＤＤに確保された記憶領域であってもよい。
【０１０４】
退避復元指示部４２５は、テストの第１フェーズの最初に、退避コマンドをアプリケーションサーバ２００に送信する。また、退避復元指示部４２５は、テストの第２フェーズの最初および第２フェーズのレスポンスを受信する毎に、サーバソフトウェアの状態の復元（リバート）を示す復元コマンドを、アプリケーションサーバ２００に送信する。
【０１０５】
なお、第３の実施の形態のクライアント４００ｂは、第１の実施の形態の情報処理装置１０の一例である。クライアント４００ｂが備える通信部、または、テスト中継部４２２および退避復元指示部４２５は、送信部１１の一例である。クライアント４００ｂが備えるＣＰＵおよびＲＡＭ、または、レスポンス処理部４２３は、判定部１２の一例である。
【０１０６】
第３の実施の形態の情報処理システムによれば、第２の実施の形態と同様、ロードバランシングのルールに登録するスティッキーなパスを、効率的に判定することができる。また、第３の実施の形態では、クライアント４００ｂがテストを実行するため、リバースプロキシサーバを改変せずにテストを実行できる。なお、図１１において、アプリケーションサーバ２００とクライアント４００ｂの間で、リバースプロキシサーバがリクエストおよびレスポンスを中継してもよい。また、前述のように、アプリケーションサーバ２００は、ｃｈｒｏｏｔコマンドを用いて、サーバソフトウェアの状態を復元するようにしてもよい。
【０１０７】
［第４の実施の形態］
次に、第４の実施の形態を説明する。第２および第３の実施の形態との差異を中心に説明し、第２および第３の実施の形態と同様の事項については説明を省略する。第４の実施の形態の情報処理システムは、テストの第２フェーズを、１またはそれ以上のアプリケーションサーバ上で動作する複数の仮想マシンを用いて並行処理する。
【０１０８】
図１２は、第４の実施の形態のソフトウェア例を示すブロック図である。図１２に示すリバースプロキシサーバ１００ａおよびアプリケーションサーバ２００ｃ，２００ｄのモジュールの一部または全部は、各サーバに実行させるプログラムのモジュールでもよいし、ＦＰＧＡやＡＳＩＣなどの電子回路であってもよい。
【０１０９】
リバースプロキシサーバ１００ａは、テスト中継部１１１，１１８、リクエスト処理部１１３、リクエスト記憶部１１４、レスポンス処理部１１５、レスポンス記憶部１１６、退避復元指示部１１７、ルール記憶部１２１および中継部１２２を有する。
【０１１０】
テスト中継部１１８は、テストの第１フェーズでは、リクエスト処理部１１３から取得する一連のリクエストを、あるアプリケーションサーバ（例えば、アプリケーションサーバ２００ｃ）上で動作する単一の仮想マシン宛てに送信する。また、テストの第２フェーズでは、リクエスト処理部１１３から取得する一連のリクエストを、アプリケーションサーバ２００ｃ，２００ｄ上で動作する複数の仮想マシンに振り分けて送信する。また、テスト中継部１１８は、アプリケーションサーバ２００ｃ，２００ｄからレスポンスを受信し、受信したレスポンスをレスポンス処理部１１５に出力する。
【０１１１】
なお、テストの第２フェーズにおけるリクエストの振り分けは、ラウンドロビン方式で行ってもよい。また、復元コマンドに応じて状態の復元が完了した仮想マシン（次のリクエストを受け付け可能な仮想マシン）の中から、選択するようにしてもよい。
【０１１２】
アプリケーションサーバ２００ｃは、コンピュータの仮想化技術を用いて、複数の仮想マシンを動作させる。アプリケーションサーバ２００ｃは、仮想マシン２１１，２１６およびハイパーバイザ２１２を有する。アプリケーションサーバ２００ｄも、アプリケーションサーバ２００ｃと同様のモジュールを用いて実現できる。
【０１１３】
仮想マシン２１１，２１６は、それぞれ、サーバソフトウェア（例えば、Ｗｅｂアプリケーションソフトウェア）を実行する。仮想マシン２１１，２１６は、それぞれ、リバースプロキシサーバ１００ａから受信したリクエストを、他の仮想マシンとは独立に処理する。仮想マシン２１１と仮想マシン２１６は、セッションのデータを共有しない。アプリケーションサーバ２００ｃのＲＡＭおよびＨＤＤ上にある仮想マシン２１１，２１６のデータは、ハイパーバイザ２１２によって仮想マシン毎に管理される。
【０１１４】
図１３は、パス判定の第２のシーケンス例を示す図である。
クライアント４００は、第１フェーズの開始コマンドを、リバースプロキシサーバ１００ａに送信する（ステップＳ１３１）。リバースプロキシサーバ１００ａは、アプリケーションサーバ２００ｃ，２００ｄに退避コマンドを送信する。アプリケーションサーバ２００ｃは、テストケース実行前の仮想マシン２１１，２１６のスナップショットを保存する。アプリケーションサーバ２００ｄも同様に退避処理を行う（ステップＳ１３２）。
【０１１５】
クライアント４００は、テストケースに含まれるリクエストを１つリバースプロキシサーバ１００ａに送信する（ステップＳ１３３）。リバースプロキシサーバ１００ａは、リクエストを仮想マシン２１１宛てに転送する（ステップＳ１３４）。仮想マシン２１１は、リクエストを処理し、レスポンスをリバースプロキシサーバ１００ａに送信する（ステップＳ１３５）。リバースプロキシサーバ１００ａは、レスポンスをクライアント４００に転送する（ステップＳ１３６）。
【０１１６】
クライアント４００は、ステップＳ１３３のリクエストに続くリクエストを、リバースプロキシサーバ１００ａに送信する（ステップＳ１３７）。リバースプロキシサーバ１００ａは、リクエストを、ステップＳ１３４の宛先と同じ仮想マシン２１１宛てに転送する（ステップＳ１３８）。仮想マシン２１１は、リクエストを処理し、レスポンスをリバースプロキシサーバ１００ａに送信する（ステップＳ１３９）。リバースプロキシサーバ１００ａは、レスポンスをクライアント４００に転送する（ステップＳ１４０）。このように、第１フェーズのリクエスト処理が、単一の仮想マシンを用いて実行される。
【０１１７】
クライアント４００は、第２フェーズの開始コマンドを、リバースプロキシサーバ１００ａに送信する（ステップＳ１４１）。リバースプロキシサーバ１００ａは、仮想マシン２１１の状態を復元する復元コマンドを、アプリケーションサーバ２００ｃに送信する。アプリケーションサーバ２００ｃは、スナップショットを用いて、仮想マシン２１１の状態をテストケース実行前の状態にリバートする（ステップＳ１４２）。
【０１１８】
リバースプロキシサーバ１００ａは、複数の仮想マシンの中から仮想マシン２１１を選択し、リクエストを仮想マシン２１１宛てに再送する（ステップＳ１４３）。仮想マシン２１１は、リクエストを処理し、レスポンスをリバースプロキシサーバ１００ａに送信する。リバースプロキシサーバ１００ａは、第１フェーズのレスポンスと第２フェーズのレスポンスとを比較して、内容の同一性を判定する（ステップＳ１４４）。リバースプロキシサーバ１００ａは、仮想マシン２１１の状態を復元する復元コマンドを、アプリケーションサーバ２００ｃに送信する。アプリケーションサーバ２００ｃは、スナップショットを用いて、仮想マシン２１１の状態をリクエスト処理前の状態にリバートする（ステップＳ１４５）。
【０１１９】
リバースプロキシサーバ１００ａは、複数の仮想マシンの中から、ステップＳ１４３の宛先と異なる仮想マシン２１６を選択し、リクエストを仮想マシン２１６宛てに再送する（ステップＳ１４６）。仮想マシン２１６は、リクエストを処理し、レスポンスをリバースプロキシサーバ１００ａに送信する。リバースプロキシサーバ１００ａは、第１フェーズのレスポンスと第２フェーズのレスポンスとを比較して、内容の同一性を判定する（ステップＳ１４７）。リバースプロキシサーバ１００ａは、仮想マシン２１６の状態を復元する復元コマンドを、アプリケーションサーバ２００ｃに送信する。アプリケーションサーバ２００ｃは、スナップショットを用いて、仮想マシン２１６の状態をリバートする（ステップＳ１４８）。このように、第２フェーズのリクエスト処理が、複数の仮想マシンを用いて実行される。
【０１２０】
リバースプロキシサーバ１００ａは、ステップＳ１４４，Ｓ１４７で判定されたレスポンスの同一性に基づいて、リクエストで指定されたパスがスティッキーであるか否かを示すパス判定結果を、クライアント４００に報告する（ステップＳ１４９）。
【０１２１】
第４の実施の形態の情報処理システムによれば、第２および第３の実施の形態と同様、ロードバランシングのルールに登録するスティッキーなパスを、効率的に判定することができる。また、第４の実施の形態では、テストの第２のフェーズで複数の仮想マシンを使用するため、ある仮想マシンがリバート中でも他の仮想マシンにリクエストを処理させることができ、リバート待ちの時間を削減し、テストの実行時間を短縮できる。なお、前述のように、アプリケーションサーバ２００ｃは、ｃｈｒｏｏｔコマンドを用いて、仮想マシン２１１，２１６の状態を復元するようにしてもよい。
【０１２２】
［第５の実施の形態］
次に、第５の実施の形態を説明する。第２乃至第４の実施の形態との差異を中心に説明し、第２乃至第４の実施の形態と同様の事項については説明を省略する。第５の実施の形態の情報処理システムは、クライアントへのサービス提供を停止せずにサーバソフトウェアを旧バージョンから新バージョンに移行するとき、移行を円滑に行えるように、ロードバランシングのルールを自動的に生成してリバースプロキシサーバに適用する。
【０１２３】
図１４は、第５の実施の形態のソフトウェア例を示すブロック図である。リバースプロキシサーバ１００ｂは、テスト中継部１１１，１１２、リクエスト処理部１１３、リクエスト記憶部１１４、レスポンス処理部１１５、レスポンス記憶部１１６、退避復元指示部１１７、ルール記憶部１２１、中継部１２２、サーバ更新部１２３およびルール更新部１２４を有する。リバースプロキシサーバ１００ｂのユニットの一部または全部は、プログラムのモジュールでもよく、ＦＰＧＡやＡＳＩＣなどの電子回路であってもよい。
【０１２４】
サーバ更新部１２３は、サーバソフトウェアのローリングアップデートを実行する。ローリングアップデートでは、アプリケーションサーバ２００，２００ａ，２００ｂを順番に更新していく。例えば、サーバ更新部１２３は、アプリケーションサーバ２００に更新を指示し、アプリケーションサーバ２００の更新が完了すると、アプリケーションサーバ２００ａに更新を指示する。アプリケーションサーバ２００ａの更新が完了すると、アプリケーションサーバ２００ｂに更新を指示する。なお、更新中のアプリケーションサーバは、リクエストの転送先から除外される。
【０１２５】
ルール更新部１２４は、新バージョンのサーバソフトウェアについてのパス判定結果をレスポンス処理部１１５から取得し、スティッキーなパスを含む新ルールを生成する。そして、新ルールとルール記憶部１２１に記憶された旧ルールから、ローリングアップデート中に適用する一時ルールを生成する。ルール更新部１２４は、ローリングアップデートの開始時、旧ルールに代えて一時ルールをルール記憶部１２１に書き込み、ローリングアップデートの終了時、一時ルールに代えて新ルールをルール記憶部１２１に書き込む。
【０１２６】
図１５は、サーバ更新時の一時ルールの生成例を示す図である。
第１のパス（／ｗｗｗ／）は、旧バージョンのサーバソフトウェアに対応する旧ルールでスティッキーであり、新バージョンのサーバソフトウェアに対応する新ルールでもスティッキーである。第２のパス（／ｘｘｘ／）は、旧ルールではスティッキーであるが、新ルールではスティッキーでない。第３のパス（／ｙｙｙ／）は、旧ルールではスティッキーでないが、新ルールではスティッキーである。第４のパス（／ｚｚｚ／）は、旧ルールでスティッキーでなく、新ルールでもスティッキーでない。
【０１２７】
ここで、ローリングアップデート中は、旧ルールと新ルールの少なくとも一方でスティッキーであると指定されているパスは、スティッキーとして取り扱う。よって、一時ルールでは、第１乃至第３のパスがスティッキーであると指定されることになる。
【０１２８】
もし、ローリングアップデートの開始時に新ルールを適用すると、第２のパスを含むリクエストが、同一セッションの先のリクエストと異なるアプリケーションサーバに転送され得る。このとき、転送先のアプリケーションサーバがまだ旧バージョンのサーバソフトウェアを実行していると、リクエストが正常に処理されないおそれがある。また、ローリングアップデートの終了まで旧ルールを適用すると、第３のパスを含むリクエストが、同一セッションの先のリクエストと異なるアプリケーションサーバに転送され得る。このとき、転送先のアプリケーションサーバが既に新バージョンのサーバソフトウェアを実行していると、リクエストが正常に処理されないおそれがある。そこで、ローリングアップデート中は、第２および第３のパスの両方をスティッキーとして取り扱う。
【０１２９】
図１６は、サーバ更新の処理例を示すフローチャートである。
（ステップＳ３１）レスポンス処理部１１５は、図７に示した方法で、新バージョンのサーバソフトウェアについて、スティッキーなパスを判定する。
【０１３０】
（ステップＳ３２）ルール更新部１２４は、ステップＳ３１の判定結果から、ロードバランシングの新ルールを生成する。ルール更新部１２４は、ルール記憶部１２１に記憶されている旧ルールと生成した新ルールとから、ローリングアップデート中に適用する一時ルールを生成する。一時ルールが指定するスティッキーなパスは、新ルールが指定するパスと旧ルールが指定するパスの和集合である。ルール更新部１２４は、生成した一時ルールを、ルール記憶部１２１に書き込んで適用を開始する。
【０１３１】
（ステップＳ３３）サーバ更新部１２３は、アプリケーションサーバ２００，２００ａ，２００ｂから、未更新のアプリケーションサーバを１つ選択する。
（ステップＳ３４）中継部１２２は、ステップＳ３３で選択されたアプリケーションサーバを、リクエストの転送先の候補から除外する。
【０１３２】
（ステップＳ３５）サーバ更新部１２３は、ステップＳ３３で選択したアプリケーションサーバに、サーバソフトウェアの更新を指示する。指示を受けたアプリケーションサーバの仮想マシンは、実行中の旧バージョンのサーバソフトウェアを停止し、新バージョンのサーバソフトウェアのプログラムを読み込んで起動する。サーバ更新部１２３は、当該アプリケーションサーバから、更新完了の報告を受信する。
【０１３３】
（ステップＳ３６）中継部１２２は、更新完了の報告があると、ステップＳ３３で選択されたアプリケーションサーバを、リクエストの転送先の候補に戻す。
（ステップＳ３７）サーバ更新部１２３は、未更新のアプリケーションサーバが存在するか判断する。存在する場合、処理をステップＳ３３に進める。存在しない場合、ローリングアップデートが完了したと判断し、処理をステップＳ３８に進める。
【０１３４】
（ステップＳ３８）ルール更新部１２４は、ステップＳ３２で生成した新ルールを、ルール記憶部１２１に書き込んで適用を開始する。
第５の実施の形態の情報処理システムによれば、第２乃至第４の実施の形態と同様、ロードバランシングのルールに登録するスティッキーなパスを、効率的に判定することができる。また、第５の実施の形態では、リバースプロキシサーバ１００ｂが、旧ルールと新ルールとに基づいて一時ルールを生成してローリングアップデート中に適用する。これにより、先のリクエストに関するデータを取得できないことによる不具合を抑制し、ローリングアップデート中もクライアント４００へのサービス提供を継続することができる。なお、前述のように、アプリケーションサーバ２００は、ｃｈｒｏｏｔコマンドを用いて、仮想マシン２１１の状態を復元するようにしてもよい。
【符号の説明】
【０１３５】
１０  情報処理装置
１１  送信部
１２  判定部
２０，２０ａ  サーバ装置
【図１】
0005729209.tif 000002
【図２】
0005729209.tif 000003
【図３】
0005729209.tif 000004
【図４】
0005729209.tif 000005
【図５】
0005729209.tif 000006
【図６】
0005729209.tif 000007
【図７】
0005729209.tif 000008
【図８】
0005729209.tif 000009
【図９】
0005729209.tif 000010
【図１０】
0005729209.tif 000011
【図１１】
0005729209.tif 000012
【図１２】
0005729209.tif 000013
【図１３】
0005729209.tif 000014
【図１４】
0005729209.tif 000015
【図１５】
0005729209.tif 000016
【図１６】
0005729209.tif 000017