"クライアントから処理要求を受信し、要求される処理を示す処理識別情報と、複数のサーバの中からサーバを選択するための選択アルゴリズムとの対応関係を格納する格納手段から、前記処理要求により指定される処理識別情報に対応する選択アルゴリズムを取得し、取得した選択アルゴリズムに基づいて、前記複数のサーバの中から、該処理要求により要求された処理を実行するサーバを選択し、選択されたサーバに前記処理要求を送信する処理をコンピュータに実行させるプログラム。前記格納手段は、前記クライアントの識別情報に基づいて同一のクライアントにより要求された処理を実行するサーバとして同一のサーバを選択する第1の選択アルゴリズム、又は前記複数のサーバの中からラウンドロビン方式でサーバを選択する第2の選択アルゴリズムのいずれか一方と、前記処理識別情報との対応関係を格納することを特徴とする請求項1記載のプログラム。前記プログラムは、前記格納手段に前記対応関係を登録するとき、前記クライアントから受信する処理要求を、前記第1の選択アルゴリズムにより選択される第1のサーバと前記第2の選択アルゴリズムにより選択される第2のサーバに送信し、前記第1のサーバ及び前記第2のサーバから前記処理要求に対する第1の処理結果及び第2の処理結果をそれぞれ受信し、前記第1の処理結果と前記第2の処理結果が一致しているとき、前記処理要求により要求される処理を示す処理識別情報と前記第2の選択アルゴリズムとを対応付けて前記格納手段に登録する処理を、前記コンピュータにさらに実行させることを特徴とする請求項2記載のプログラム。前記対応関係を登録する処理は、前記クライアントから受信する処理要求に基づいてデータベースに対するデータ要求が発生する場合、前記第1のサーバが前記データ要求を前記データベースに送信して該データベースから受信したデータ応答を含む、前記第1の処理結果を前記第1のサーバから受信し、前記データ応答を前記第2のサーバに送信し、前記データ応答を含む前記第2の処理結果を前記第2のサーバから受信することを特徴とする請求項3記載のプログラム。前記プログラムは、前記格納手段に前記対応関係を登録するとき、1つのセッションで前記クライアントから受信する複数の処理要求を、前記複数のサーバのうち前記第1の選択アルゴリズムにより選択される第1のサーバに送信し、前記第1のサーバから前記複数の処理要求に対する第1の複数の処理結果を受信し、前記複数の処理要求を前記複数のサーバに振り分けて送信し、前記複数のサーバから前記複数の処理要求に対する第2の複数の処理結果を受信し、前記第1の複数の処理結果と前記第2の複数の処理結果が一致しているとき、前記複数の処理要求の各々により要求される処理を示す処理識別情報と前記第2の選択アルゴリズムとを対応付けて前記格納手段に登録する処理を、前記コンピュータにさらに実行させることを特徴とする請求項2記載のプログラム。前記対応関係を登録する処理は、前記複数の処理要求の数が前記複数のサーバの数より多い場合、各サーバに振り分ける処理要求の組み合わせを変更しながら、前記複数の処理要求を前記複数のサーバに振り分けて送信する処理を複数回繰り返し、それぞれの繰り返しについて、前記複数のサーバから前記複数の処理要求に対する第2の複数の処理結果を受信し、前記第1の複数の処理結果と、それぞれの繰り返しについて受信した前記第2の複数の処理結果が一致しているとき、前記複数の処理要求の各々により要求される処理を示す処理識別情報と前記第2の選択アルゴリズムとを対応付けて前記格納手段に登録することを特徴とする請求項5記載のプログラム。要求される処理を示す処理識別情報と、複数のサーバの中からサーバを選択するための選択アルゴリズムとの対応関係を格納する格納手段と、クライアントから処理要求を受信する受信手段と、前記格納手段から、前記処理要求により指定される処理識別情報に対応する選択アルゴリズムを取得し、取得した選択アルゴリズムに基づいて、前記複数のサーバの中から、該処理要求により要求された処理を実行するサーバを選択する選択手段と、選択されたサーバに前記処理要求を送信する送信手段とを備えることを特徴とする情報処理装置。クライアントから処理要求を受信し、要求される処理を示す処理識別情報と、複数のサーバの中からサーバを選択するための選択アルゴリズムとの対応関係を格納する格納手段から、前記処理要求により指定される処理識別情報に対応する選択アルゴリズムを取得し、取得した選択アルゴリズムに基づいて、前記複数のサーバの中から、該処理要求により要求された処理を実行するサーバを選択し、選択されたサーバに前記処理要求を送信することを特徴とするサーバ選択方法。上述した従来の情報処理システムには、以下のような問題がある。近年では、PlatformasaServicePaaS等のクラウド型のサービスが普及し始め、そのサービスでは、ラウンドロビン型の分散戦略が採用されるケースが多くなっている。ラウンドロビン型で動作しないアプリケーションの多くは、クライアントの状態をAPサーバのメモリやローカルディスク内に保持する仕組みになっている。クライアントの状態としては、クライアントがログインしているか否か、オンラインショッピングサービスのショッピングカートに入っている商品は何か等の情報が挙げられる。APサーバがクライアントの状態を保持する場合はスティッキー型の分散戦略が望ましく、ラウンドロビン型の分散戦略を採用するには、アプリケーションを並列処理可能なように改変する必要がある。例えば、アプリケーションをオンプレミスからクラウドに移行する場合、オンプレミスでスティッキー型の分散戦略を採用していると、そのままではクラウドに移行してもアプリケーションが正しく動作しない。このため、アプリケーションの改変が必要になるが、アプリケーションの規模が大きくなると、アプリケーション全体を改変するために多大なコストと時間を要する。1つの側面では、本発明は、要求される処理を実行するサーバを選択するための選択アルゴリズムを処理の種別に応じて柔軟に変更できるようにすることを目的とする。情報処理装置は、格納手段、受信手段、選択手段、及び送信手段を含む。格納手段は、要求される処理を示す処理識別情報と、複数のサーバの中から処理を実行するサーバを選択するための選択アルゴリズムとの対応関係を格納する。受信手段は、クライアントから処理要求を受信する。選択手段は、格納手段から、処理要求により指定される処理識別情報に対応する選択アルゴリズムを取得し、取得した選択アルゴリズムに基づいて、複数のサーバの中から、その処理要求により要求された処理を実行するサーバを選択する。送信手段は、選択されたサーバに処理要求を送信する。要求される処理を実行するサーバを選択するための選択アルゴリズムを処理の種別に応じて柔軟に変更できる。以下、図面を参照しながら、実施形態を詳細に説明する。図2は、実施形態の情報処理装置の機能的構成例を示している。図2の情報処理装置201は、受信部211、選択部212、送信部213、及び格納部214を含み、複数のサーバの中から、クライアントにより要求された処理を実行するサーバを選択する。格納部214は、要求される処理を示す処理識別情報と、複数のサーバの中から処理を実行するサーバを選択するための選択アルゴリズムとの対応関係を格納する。例えば、Webシステムの場合は、HyperTextTransferProtocolHTTPリクエストに含まれるUniformResourceLocatorURLが、処理識別情報として用いられる。また、それ以外の情報処理システムの場合は、クライアントからサーバに対するコマンドの文字列等を、処理識別情報として用いてもよい。選択アルゴリズムとしては、スティッキー型及びラウンドロビン型を含む複数のサーバ選択アルゴリズムが用いられる。図3は、図2の情報処理装置によるサーバ選択処理のフローチャートである。まず、受信部211は、クライアントから処理要求を受信するステップ301。選択部213は、格納部214から、処理要求により指定される処理識別情報に対応する選択アルゴリズムを取得するステップ302。そして、取得した選択アルゴリズムに基づいて、複数のサーバの中から、その処理要求により要求された処理を実行するサーバを選択するステップ303。送信部213は、選択されたサーバに処理要求を送信するステップ304。このような情報処理装置によれば、要求される処理を実行するサーバを選択するための選択アルゴリズムを処理の種別に応じて柔軟に変更できる。図4は、図2の情報処理装置をロードバランサとして使用した情報処理システムの構成例を示している。図4の情報処理システムは、ロードバランサ403及びAPサーバ404-1~404-4を含む。クライアント401は、パーソナルコンピュータや携帯端末等の情報処理装置であり、インターネット等の通信ネットワーク402を介して、ロードバランサ403にアクセスする。クライアント401は、HTTPリクエスト等の処理要求をロードバランサ403に送信する。HTTPリクエストを送信する場合、クライアント401のユーザは、URLを直接入力したり、ブックマークを選択したりすることで、アクセス先のURLを指定する。これにより、指定されたURLとクエリを含むHTTPリクエストが、ロードバランサ403に送信される。ロードバランサ403は、並列処理に適したサーバオペレーティングシステムOSを搭載した情報処理装置であり、クライアント401からの処理要求を受信してAPサーバ404-1~404-4に振り分ける。ロードバランサ403には、スティッキー型及びラウンドロビン型を含む複数のサーバ選択アルゴリズムが組み込まれており、セッションデータベースDB411及び戦略情報412が格納されている。セッションDB411は、クライアント401のセッションを識別する識別情報セッションIDと、セッション開始時のHTTPリクエストを処理したAPサーバ404の識別情報サーバIDとの対応関係を表す。セッション開始時に、セッションIDとサーバIDがセッションDB411に登録され、セッション終了時に、登録された情報が削除される。戦略情報412は、アクセス先のURLと選択アルゴリズムの対応関係を表す。図5は、戦略情報412の例を示している。図5の戦略情報412において、エントリ501~504のRは、ラウンドロビン型の選択アルゴリズムを表し、エントリ505のSは、スティッキー型の選択アルゴリズムを表している。戦略情報412に登録されるURLは、アクセス先のURLのすべての文字列である必要はなく、その一部の文字列でもよい。例えば、エントリ501のlogindoなる文字列を含むURLには、ラウンドロビン型の選択アルゴリズムが対応付けられており、エントリ505のhotitemdoなる文字列を含むURLには、スティッキー型の選択アルゴリズムが対応付けられている。スティッキー型の選択アルゴリズムでは、同一のセッションに属する複数のHTTPリクエストが同一のAPサーバ404に振り分けられる。例えば、同一のIPアドレスや同一のクッキー情報が使用されている複数のHTTPリクエストは、同一のセッションに属する。ラウンドロビン型の選択アルゴリズムでは、例えば、APサーバ404-1~404-4から1つのAPサーバが所定の順番で選択される。所定の順番は、サーバIDの順番でもよく、負荷の低い順でもよい。さらに、ラウンドロビン型の選択アルゴリズムでは、APサーバ404-1~404-4から1つのAPサーバをランダムに選択してもよい。戦略情報412は、例えば、アプリケーションの開発者が並列処理可能か否か等のアプリケーションの特性を考慮して、手作業で入力してもよく、ロードバランサ403自身が所定のアルゴリズムにより生成してもよい。ロードバランサ403は、戦略情報412を参照して、処理要求に含まれるURLに対応する選択アルゴリズムを取得し、その選択アルゴリズムに基づいて処理を実行するサーバを選択する。ロードバランサ403は、クライアント401だけでなく、他のクライアントを含む複数のクライアントからの処理要求を受信して、APサーバ404-1~404-4に振り分けることができる。APサーバ404-1~404-4は、並列処理に適したサーバOSを搭載した情報処理装置であり、ロードバランサ403から受信した処理要求に基づいて、アプリケーションを実行する。図6は、ラウンドロビン型及びスティッキー型の2種類の選択アルゴリズムが適用される場合の、図4のロードバランサ403による負荷分散処理の例を示すフローチャートである。ロードバランサ403は、クライアント401からHTTPリクエストを受信しステップ601、そのHTTPリクエストからクッキー情報等のセッションIDを抽出するステップ602。そして、抽出したセッションIDがセッションDB411に登録された最新のセッションIDと一致するか否かをチェックするステップ603。抽出したセッションIDが最新のセッションIDでなければステップ603,No、ラウンドロビン型の選択アルゴリズムにより振り分け先APサーバ404を選択するステップ604。そして、セッションIDと、選択したAPサーバ404のサーバIDとを対応付けて、セッションDB411に登録しステップ605、そのAPサーバ404にHTTPリクエストを送信するステップ606。一方、抽出したセッションIDが最新のセッションIDであればステップ603,Yes、HTTPリクエストからURLを抽出し、戦略情報412を参照して、そのURLに対応する選択アルゴリズムを取得するステップ608。そして、取得した選択アルゴリズムがラウンドロビン型又はスティッキー型のいずれであるかをチェックするステップ609。選択アルゴリズムがラウンドロビン型であればステップ609,Yes、ラウンドロビン型の選択アルゴリズムにより振り分け先APサーバ404を選択しステップ610、ステップ606の処理を行う。一方、選択アルゴリズムがスティッキー型であればステップ609,No、セッションDB411からセッションIDに対応するサーバIDを取得し、そのサーバIDが示すAPサーバ404を振り分け先に決定するステップ611。そして、ステップ606の処理を行う。図7は、図4のAPサーバ404によるアプリケーション実行処理の例を示すフローチャートである。APサーバ404は、ロードバランサ403からHTTPリクエストを受信しステップ701、そのHTTPリクエストにより要求される処理を実行するステップ702。そして、処理結果を含むHTTPレスポンスをロードバランサ403に送信するステップ703。このような情報処理システムによれば、1台のロードバランサ403により、アクセス先のURL毎にAPサーバ404の選択アルゴリズムを切り替えることができる。このため、例えば、オンプレミスでスティッキー型の選択アルゴリズムに基づき動作していたアプリケーションをクラウドに移行する場合に、アプリケーションをURLに対応する部分毎に分割して、部分毎に異なる選択アルゴリズムを採用することができる。したがって、大規模なアプリケーションであっても一部のみの改変で対応することが可能になり、改変に要する負担が軽減される。例えば、アプリケーションを2つに分割してその一方のみを改変すれば、改変に要する負担は半分に軽減される。また、この情報処理システムをクラウド環境で運用する場合、既存のアプリケーションと新規なアプリケーションの両方を搭載したプラットフォームを構築することができる。図8は、情報処理システムの別の構成例を示している。図8の情報処理システムは、図4の情報処理システムにデータベースDBサーバ801を追加した構成を有する。APサーバ404は、ロードバランサ403から受信した処理要求に基づいてデータ要求を生成し、DBサーバ801に送信する。DBサーバ801は、並列処理に適したサーバOSを搭載した情報処理装置であり、リレーショナルデータベースRDB等のDBを保持する。DBサーバ801は、APサーバ404から受信したデータ要求に対するデータ応答を生成して、APサーバ404に返信する。このような情報処理システムにおいても、図4の情報処理システムと同様に、ロードバランサ403により、アクセス先のURL毎にAPサーバ404の選択アルゴリズムを切り替えることができる。図4及び図8の情報処理システムは4台のAPサーバを含んでいるが、実施形態の情報処理システムに含まれるAPサーバの数は3台以下の場合もあり、5台以上の場合もある。実際の情報処理システムでは、システムへの負荷に合わせてAPサーバの台数が決定される。クラウド環境では、APサーバの台数が柔軟に増減される場合もある。次に、図9から図15までを参照しながら、ロードバランサ403が戦略情報412を生成する構成と動作について説明する。図9は、このような情報処理システムにおけるロードバランサ403とAPサーバ404-1及び404-2の機能的構成例を示している。APサーバの数が3台以上の場合も、同様の機能的構成が用いられる。図9のロードバランサ403は、図2の情報処理装置に対応し、DBリクエスト管理部911及びHTTPレスポンス管理部912を含む。ロードバランサ403は、DBリクエスト情報913及びHTTPレスポンス情報914を用いて、戦略情報412を生成する。DBリクエスト管理部911は、APサーバ404がDBサーバ801に送信したDBリクエストと、APサーバ404がDBサーバ801から受信したDBレスポンスとを、DBリクエスト情報913として格納する。DBリクエストには、クエリやデータ更新処理命令等が含まれる。ロードバランサ403は、同一のHTTPリクエストをAPサーバ404-1及び404-2に送信することができる。HTTPレスポンス管理部912は、APサーバ404-1及び404-2に送信されたHTTPリクエストに対する応答であるHTTPレスポンスを、HTTPレスポンス情報914として格納する。APサーバ404-ii=1,2には1つ以上のアプリケーションがデプロイされており、URL等のルールに応じて対応するアプリケーションが起動される。アプリケーションには、DBサーバ801にDBリクエストを送信するプログラムが記述されている。APサーバ404-iは、DBリクエストブロック部921-i、DBリクエスト取得部922-i、DBレスポンス処理部923-i、及びHTTPレスポンス処理部924-iを含む。DBリクエストブロック部921-iは、所定の条件に従って、DBサーバ801に対するDBリクエストの送信を遮断する。DBリクエスト取得部922-iは、DBサーバ801に送信されたDBリクエストとDBサーバ801から受信したDBレスポンスとを取得する。DBレスポンス処理部923-iは、ブロックされたDBリクエストに対して、ダミーのDBレスポンスを返却する。HTTPレスポンス処理部924-iは、DBレスポンスからHTTPレスポンスを生成して、ロードバランサ403に送信する。図10は、HTTPレスポンス情報914の例を示している。図10のDBリクエスト情報914には、セッションID、セッション内画面ID、サーバID、HTTPリクエスト、及びHTTPレスポンスが対応付けられて登録される。1つのセッションにおいてクライアント401から複数のHTTPリクエストが送信される場合、クライアント401の表示装置には、複数のHTTPレスポンスに対応して複数の画面が順に表示されることがある。このような画面遷移が行われる場合、セッション内画面IDによりそれぞれの画面が識別される。サーバIDは、HTTPリクエストの送信先のAPサーバ404を示しており、APサーバ404-1及び404-2のサーバIDは、それぞれA及びBである。HTTPリクエストには、アクセス先のURLが含まれている。HTTPレスポンスは、例えば、HTTPリクエストに対する応答画面を表示するためのHyperTextMarkupLanguageHTMLファイルである。図11は、DBリクエスト情報913の例を示している。図10のDBリクエスト情報913には、セッションID、セッション内画面ID、DBリクエスト、及びDBレスポンスが対応付けられて登録される。図9の情報処理システムでは、URL毎に正しい選択アルゴリズムを適用可能な戦略情報412を生成することが望ましい。そこで、1人のユーザがセッションを継続しながら一連の操作を行う場合に、同一のAPサーバ404-1ですべての処理を実行したときの処理結果と、1画面毎にAPサーバ404-1及び404-2を切り替えて処理を実行したときの処理結果を比較する。そして、両方の処理結果が一致していれば、ラウンドロビン型の選択アルゴリズムを適用可能と判断する。この場合、2回目のHTTPリクエストに対して、APサーバ404-1による処理結果とAPサーバ404-2による処理結果が比較される。ただし、各APサーバ404がそれぞれDBサーバ801に問い合わせを行うと、APサーバ404間でDBサーバ801における処理結果が変化することがあり得る。例えば、1回目のHTTPリクエストでログインし、2回目のHTTPリクエストで商品をショッピングカートに入れて在庫引き当てを行うアプリケーションを想定する。1回目のHTTPリクエストはAPサーバ404-1で処理される。2回目のHTTPリクエストについては、最初に、APサーバ404-1で処理され、得られたHTTPレスポンスがHTTPレスポンス情報914に登録される。次に、APサーバ404-1に送信されたHTTPリクエストと同一のHTTPリクエストが、ロードバランサ403からAPサーバ404-2に送信され、得られたHTTPレスポンスがHTTPレスポンス情報914に登録される。そして、2つのHTTPレスポンスが比較される。ところが、2回目のHTTPレスポンスをAPサーバ404-1が処理したときに、DBサーバ801の在庫を減らして、商品の数を1から0に変更すると、次に同じ処理をAPサーバ404-2が行ったときに、商品をショッピングカートに入れることができない。このため、本来一致すべき2つのHTTPレスポンスが異なってしまい、ラウンドロビン型で処理できるURLであっても、スティッキー型を採用せざるを得なくなる。そこで、1つのHTTPリクエストに対して、DBサーバ801への問い合わせは1回のみ行い、その応答をAPサーバ404間で利用できるようにすることが好ましい。この場合、APサーバ404-1及び404-2がともにDBサーバ801に問い合わせを行うのではなく、APサーバ404-1によるDBリクエストに対するDBレスポンスを保存しておき、それをAPサーバ404-2からのDBレスポンスとして利用する。このとき、DBリクエストブロック部921-2は、APサーバ404-2からのDBリクエストの送信を遮断する。図12及び図13は、ラウンドロビン型及びスティッキー型の2種類の選択アルゴリズムが適用される場合の、図9のロードバランサ403による負荷分散処理の例を示すフローチャートである。ロードバランサ403は、クライアント401からHTTPリクエストを受信し図12のステップ1201、そのHTTPリクエストからセッションIDとURLを抽出するステップ1202。そして、抽出したセッションIDがHTTPレスポンス情報914に登録された最新のセッションIDと一致するか否かをチェックするステップ1203。抽出したセッションIDが最新のセッションIDでなければステップ1203,No、ラウンドロビン型の選択アルゴリズムにより振り分け先APサーバ404を選択するステップ1204。そして、そのAPサーバ404に、セッションID、セッション内画面ID、及びHTTPリクエストを送信するステップ1205。このとき、HTTPレスポンス管理部912は、セッションIDと、セッション内画面IDと、選択したAPサーバ404のサーバIDと、HTTPリクエストとを対応付けて、HTTPレスポンス情報914に登録する。また、抽出したURLとラウンドロビン型の選択アルゴリズムとを対応付けて戦略情報412に登録する。次に、ロードバランサ403は、振り分け先APサーバ404から、セッションID及びセッション内画面IDとともに、送信したHTTPリクエストに基づくDBリクエストを受信するステップ1206。このとき、DBリクエスト管理部911は、受信したセッションID、セッション内画面ID、及びDBリクエストを対応付けて、DBリクエスト情報913に登録する。次に、ロードバランサ403は、振り分け先APサーバ404から、セッションID及びセッション内画面IDとともに、DBリクエストに対するDBサーバ801からの応答であるDBレスポンスを受信するステップ1207。このとき、DBリクエスト管理部911は、DBリクエスト情報913に登録されているセッションID、セッション内画面ID、及びDBリクエストと対応付けて、受信したDBレスポンスを追加登録する。次に、ロードバランサ403は、振り分け先APサーバ404から、セッションID及びセッション内画面IDとともに、HTTPリクエストに対するHTTPレスポンスを受信するステップ1208。このとき、HTTPレスポンス管理部912は、HTTPレスポンス情報914に登録されているセッションID、セッション内画面ID、サーバID、及びHTTPリクエストと対応付けて、受信したHTTPレスポンスを追加登録する。一方、抽出したセッションIDが最新のセッションIDであればステップ1203,Yes、ロードバランサ403は、抽出したURLが戦略情報412に登録されているか否かをチェックするステップ1209。抽出したURLが戦略情報412に登録されていればステップ1209,Yes、戦略情報412からそのURLに対応する選択アルゴリズムを取得するステップ1210。そして、取得した選択アルゴリズムがラウンドロビン型又はスティッキー型のいずれであるかをチェックするステップ1211。選択アルゴリズムがラウンドロビン型であればステップ1211,Yes、ラウンドロビン型の選択アルゴリズムにより振り分け先APサーバ404を選択しステップ1212、ステップ1205以降の処理を行う。一方、選択アルゴリズムがスティッキー型であればステップ1211,No、HTTPレスポンス情報914からセッションIDに対応するサーバIDを取得し、そのサーバIDが示すAPサーバ404を振り分け先に決定するステップ1213。そして、ステップ1205以降の処理を行う。一方、抽出したURLが戦略情報412に登録されていなければステップ1209,No、ロードバランサ403は、最初にスティッキー型の選択アルゴリズムに基づき、振り分け先のAPサーバ404を選択するステップ1301。この場合、ステップ1213と同様に、HTTPレスポンス情報914からセッションIDに対応するサーバIDを取得し、そのサーバIDが示すAPサーバ404を振り分け先に決定する。そして、ステップ1302~1305の処理を行う。ステップ1302~1305の処理は、ステップ1205~1208の処理と同様である。次に、ロードバランサ403は、ラウンドロビン型の選択アルゴリズムにより振り分け先APサーバ404を選択しステップ1306、そのAPサーバ404に、セッションID、セッション内画面ID、及びHTTPリクエストを送信するステップ1307。このとき、HTTPレスポンス管理部912は、セッションIDと、セッション内画面IDと、選択したAPサーバ404のサーバIDと、HTTPリクエストとを対応付けて、HTTPレスポンス情報914に登録する。次に、ロードバランサ403は、振り分け先APサーバ404から、セッションID及びセッション内画面IDとともに、送信したHTTPリクエストに基づくDBリクエストを受信するステップ1308。そして、DBリクエスト管理部911は、受信したセッションID、セッション内画面ID、及びDBリクエストの組み合わせがDBリクエスト情報913に登録されているか否かをチェックするステップ1309。その組み合わせがDBリクエスト情報913に登録されていればステップ1309,Yes、DBリクエスト情報913から対応するDBレスポンスを取得して、振り分け先APサーバ404に送信するステップ1310。次に、ロードバランサ403は、振り分け先APサーバ404から、セッションID及びセッション内画面IDとともに、HTTPリクエストに対するHTTPレスポンスを受信するステップ1311。このとき、HTTPレスポンス管理部912は、HTTPレスポンス情報914に登録されているセッションID、セッション内画面ID、サーバID、及びHTTPリクエストと対応付けて、受信したHTTPレスポンスを追加登録する。次に、HTTPレスポンス管理部912は、ステップ1305で登録されたHTTPレスポンスと、ステップ1311で登録されたHTTPレスポンスとを比較するステップ1312。そして、2つのHTTPレスポンスが一致すればステップ1312,Yes、そのURLに対してラウンドロビン型の選択アルゴリズムを適用可能と判断し、URLとラウンドロビン型の選択アルゴリズムとを対応付けて戦略情報412に登録するステップ1313。一方、2つのHTTPレスポンスが一致しなければステップ1312,No、そのURLに対してラウンドロビン型の選択アルゴリズムを適用不可能と判断し、URLとスティッキー型の選択アルゴリズムとを対応付けて戦略情報412に登録するステップ1314。また、受信したセッションID、セッション内画面ID、及びDBリクエストの組み合わせがDBリクエスト情報913に登録されていない場合もステップ1309,No、ステップ1314の処理を行う。図14は、図9のAPサーバ404によるアプリケーション実行処理の例を示すフローチャートである。APサーバ404は、ロードバランサ403から、セッションID、セッション内画面ID、及びHTTPリクエストを受信するステップ1401。DBリクエストブロック部921は、受信したHTTPリクエストからDBリクエストを生成してステップ1402、セッションID及びセッション内画面IDとともに、ロードバランサ403に送信するステップ1403。そして、ロードバランサ403からDBレスポンスを受信したか否かをチェックするステップ1404。DBレスポンスを受信しなければステップ1404,No、DBリクエストブロック部921は、生成したDBリクエストをDBサーバ801に送信するステップ1407。そして、APサーバ404は、DBサーバ801から、DBリクエストに対するDBレスポンスを受信するステップ1408。DBリクエスト取得部923は、DBサーバ801に送信されたDBリクエストと、DBサーバ801から受信したDBレスポンスとを取得する。そして、DBレスポンスをアプリケーションに返却するとともに、セッションID及びセッション内画面IDとともに、DBレスポンスをロードバランサ403に送信するステップ1409。一方、ロードバランサ403からDBレスポンスを受信すればステップ1404,Yes、DBリクエストブロック部921は、そのDBレスポンスをDBレスポンス処理部923に転送するステップ1405。そして、DBレスポンス処理部923は、転送されたDBレスポンスを、DBサーバ801からのDBレスポンスとしてアプリケーションに返却する。次に、HTTPレスポンス処理部924は、DBレスポンスからHTTPレスポンスを生成して、セッションID及びセッション内画面IDとともに、ロードバランサ403に送信するステップ1406。ロードバランサ403は、HTTPレスポンスをクライアント401に送信し、クライアント401は、受信したHTTPレスポンスに含まれるHTMLファイルに基づいて画面をレンダリングし、処理結果を表示する。ところで、振り分け先APサーバ404のアプリケーションがラウンドロビン型で動作しないアプリケーションの場合、セッションID等のセッション情報をAPサーバ404内に保持しておき、その情報に基づいて要求された処理を実行することが多い。この場合、ステップ1403で誤ったセッションID及びセッション内画面IDがロードバランサ403に送信され、ステップ1309の判定結果がNoとなる可能性がある。あるいはステップ1406で、誤ったセッションID及びセッション内画面ID、又は誤ったHTTPレスポンスがロードバランサ403に送信され、ステップ1312の判定結果がNoとなる可能性もある。このような場合には、ステップ1314でラウンドロビン型の選択アルゴリズムは適用不可能と判断され、スティッキー型の選択アルゴリズムが戦略情報412に登録される。図12~図14に示したフローチャートにおいて、必ずしもすべてのステップを実行する必要はなく、情報処理システムの構成や条件に応じて一部のステップを省略することも可能である。例えば、DBサーバ801に対する問い合わせが発生しない場合は、図12のステップ1206及び1207、図13のステップ1303、1304、及び1308~1310、図14のステップ1402~1405及び1407~1409の処理を省略してもよい。次に、図10のHTTPレスポンス情報914と図11のDBリクエスト情報913を用いて、戦略情報412の生成処理の具体例を説明する。図15は、この具体例において、ロードバランサ403とAPサーバ404の間で行われる通信と、APサーバ404とDBサーバ801の間で行われる通信の手順を示している。手順1501-1:ロードバランサ403は、クライアント401から1回目のHTTPリクエストを受信するステップ1201。1回目のHTTPリクエストのセッションIDは、図10のHTTPレスポンス情報914にまだ登録されていないため、ステップ1203の判定結果はNoとなる。そこで、ロードバランサ403は、受信したHTTPリクエストをAPサーバ404-1に送信するステップ1205。そして、HTTPリクエストを、図10のHTTPレスポンス情報914のエントリ1001に登録し、URLとラウンドロビン型の選択アルゴリズムとを対応付けて、図5の戦略情報412のエントリ501に登録する。手順1501-2:APサーバ404-1は、受信したHTTPリクエストを処理するアプリケーションを実行する。アプリケーション中にDBアクセスがあるため、APサーバ404-1は、DBリクエストをロードバランサ403に送信するステップ1403。そして、ロードバランサ403は、受信したDBリクエストを、図11のDBリクエスト情報913のエントリ1101に登録するステップ1206。手順1501-3:ロードバランサ403からDBレスポンスを受信しないため、ステップ1404の判定結果はNoとなる。そこで、APサーバ404-1は、DBリクエストをDBサーバ801に送信するステップ1407。手順1501-4:APサーバ404-1は、DBサーバ801からDBレスポンスを受信するステップ1408。手順1501-5:APサーバ404-1は、DBレスポンス及びHTTPレスポンスをロードバランサ403に送信するステップ1409、1406。そして、ロードバランサ403は、受信したDBレスポンスを、図11のDBリクエスト情報913のエントリ1101に追加登録するステップ1207。また、受信したHTTPレスポンスを、図10のHTTPレスポンス情報914のエントリ1001に追加登録するステップ1208。手順1502-1:ロードバランサ403は、クライアント401から2回目のHTTPリクエストを受信するステップ1201。2回目のHTTPリクエストのセッションIDは、図10のHTTPレスポンス情報914のエントリ1001のセッションIDと一致するため、ステップ1203の判定結果はYesとなる。また、2回目のHTTPリクエストのURLは、図5の戦略情報412にまだ登録されていないため、ステップ1209の判定結果はNoとなる。そこで、ロードバランサ403は、受信したHTTPリクエストを、1回目と同じAPサーバ404-1に送信するステップ1302。そして、HTTPリクエストを、図10のHTTPレスポンス情報914のエントリ1002に登録する。手順1502-2:APサーバ404-1は、受信したHTTPリクエストを処理するアプリケーションを実行する。アプリケーション中にDBアクセスがあるため、APサーバ404-1は、DBリクエストをロードバランサ403に送信するステップ1403。そして、ロードバランサ403は、受信したDBリクエストを、図11のDBリクエスト情報913に登録するステップ1303。ところで、1つのHTTPリクエストを処理する際に複数のDBリクエストが発生することもあり得る。この例では、2回目のHTTPリクエストを処理する際に、図11のエントリ1102及び1103が示す2つのDBリクエストが生成されている。エントリ1102のDBリクエストは、在庫を確認するDBリクエストであり、エントリ1103のDBリクエストは、在庫を引き当てるDBリクエストである。この場合、図11のDBリクエスト情報913のエントリ1102及び1103に、それぞれのDBリクエストが登録される。在庫引き当てを行うアプリケーションではトランザクションが実行されることが多いが、その場合でも、トランザクションを分割して、それぞれのDBリクエストがDBリクエスト情報913に登録される。手順1502-3:ロードバランサ403からDBレスポンスを受信しないため、ステップ1404の判定結果はNoとなる。そこで、APサーバ404-1は、2つのDBリクエストをDBサーバ801に送信するステップ1407。手順1502-4:APサーバ404-1は、DBサーバ801から2つのDBレスポンスを受信するステップ1408。手順1502-5:APサーバ404-1は、2つのDBレスポンスとHTTPレスポンスとをロードバランサ403に送信するステップ1409、1406。そして、ロードバランサ403は、受信した2つのDBレスポンスを、図11のDBリクエスト情報913のエントリ1102及び1103に追加登録するステップ1304。また、受信したHTTPレスポンスを、図10のHTTPレスポンス情報914のエントリ1002に追加登録するステップ1305。手順1503-1:次に、ロードバランサ403は、2回目のHTTPリクエストを別のAPサーバ404-2に送信するステップ1307。そして、HTTPリクエストを、図10のHTTPレスポンス情報914のエントリ1003に登録する。手順1503-2:APサーバ404-2は、受信したHTTPリクエストを処理するアプリケーションを実行する。アプリケーション中に2つのDBアクセスがあるため、APサーバ404-2は、2つのDBリクエストをロードバランサ403に送信するステップ1403。手順1503-3:このとき、図11のDBリクエスト情報913のエントリ1102及び1103に、それぞれのDBリクエストが登録されているため、ロードバランサ403は、それらのDBレスポンスをAPサーバ404-2に送信するステップ1310。手順1503-4:ロードバランサ403からDBレスポンスを受信すると、ステップ1404の判定結果はYesとなる。そこで、APサーバ404-2は、受信した2つのDBレスポンスを用いてHTTPレスポンスを生成し、ロードバランサ403に送信するステップ1405、1406。この場合、DBサーバ801へのDBリクエストの送信は遮断される。ロードバランサ403は、受信したHTTPレスポンスを、図10のHTTPレスポンス情報914のエントリ1003に追加登録するステップ1311。このとき、HTTPレスポンス情報914に登録されたエントリ1002のHTTPレスポンスとエントリ1003のHTTPレスポンスとが一致するため、ステップ1312の判定結果はYesとなる。そこで、ロードバランサ403は、2回目のHTTPリクエストのURLとラウンドロビン型の選択アルゴリズムとを対応付けて、戦略情報412のエントリ502に登録するステップ1313。その後、別のクライアントにより別のセッションが開始された場合、そのセッションのURLが戦略情報412に登録されていればステップ1209,Yes、対応する選択アルゴリズムを適用することができる。URLが戦略情報412に登録されていない場合はステップ1209,No、図15と同様の手順で処理を行うことで、URLと選択アルゴリズムを戦略情報412に追加登録することができる。ロードバランサ403が戦略情報412を生成することで、アプリケーションの開発者が戦略情報412を入力する作業が不要になる。特に大規模なアプリケーションの場合、多数のURLの各々に対して選択アルゴリズムを入力する作業が発生するため、その時間を削減することで作業効率が向上する。上述した具体例では、1つのセッション中の2つの画面について戦略情報412を生成する場合の構成と動作を説明した。しかし、現実のアプリケーションはより複雑であり、1つのセッションで10画面~数十画面を切り替えながら処理を行うことが多い。このような場合でも、画面の数HTTPリクエストの数と同じ数のAPサーバを用意して、図13のステップ1306においてHTTPリクエスト毎に異なるAPサーバを振り分け先に決定すれば、同様にして戦略情報412を生成することが可能である。しかし、実際に画面の数と同じ数のAPサーバを用意することは、サーバコスト、設置場所、消費電力等の観点から難しいと考えられる。そこで、画面の数がAPサーバの数より多い場合に、テストシナリオに従って複数のHTTPリクエストを順に処理するテストを繰り返し、戦略情報412を生成する方法が考えられる。この場合、ロードバランサ403は、各APサーバに振り分けるHTTPリクエストの組み合わせを変更しながら、複数のHTTPリクエストを複数のAPサーバに振り分ける処理を複数回繰り返す。そして、それぞれの振り分け処理について、複数のAPサーバからすべてのHTTPリクエストに対するHTTPレスポンスを受信する。ロードバランサ403は、受信したHTTPレスポンスが、すべてのHTTPリクエストを同一のAPサーバで処理した場合のHTTPレスポンスと一致すれば、それらのHTTPリクエストのURLに対してラウンドロビン型の選択アルゴリズムを適用可能と判断する。図16は、このような情報処理システムにおけるロードバランサ403の機能的構成例を示している。図16のロードバランサ403は、図9のロードバランサ403にセッションID変換部1621を追加した構成を有し、DBリクエスト情報913、HTTPレスポンス情報914、テストシナリオ1622、及び順序情報1623を用いて戦略情報412を生成する。なお、図16の情報処理システムは4台のAPサーバ404-1~404-4を含んでいるが、APサーバの数が3台以下又は5台以上の場合も、同様の機能的構成が用いられる。クライアント401には、テストシナリオ1611を自動実行するアプリケーションがインストールされている。テストシナリオ1611には、1つのセッションで使用されるHTTPリクエストの配列が記録されており、クライアント401は、それらのHTTPリクエストを順にロードバランサ403に送信する。テストは複数回に分けて行われる。1回目のテストでは、クライアント401がテストシナリオ1611に従ってHTTPリクエストを順に送信し、ロードバランサ403は、受信したすべてのHTTPリクエストを同一のAPサーバに送信する。そして、各HTTPリクエストに基づいて発生したDBリクエスト及びDBレスポンスを、DBリクエスト情報913に登録し、HTTPリクエスト及びHTTPレスポンスをHTTPレスポンス情報914に登録する。このとき、ロードバランサ403は、受信したHTTPリクエストをテストシナリオ1622に登録しておく。2回目のテストでは、ロードバランサ403は、テストシナリオ1622に登録されたHTTPリクエストを、ラウンドロビン型の選択アルゴリズムによりAPサーバ404-1~404-4に振り分ける。このとき、APサーバ404により1回目のテストと2回目のテストが同一セッションとして扱われることを防ぐために、セッションID変換部1621は、2回目以降のテストにおけるセッションIDを変更する。例えば、HTTPリクエストにクッキー情報を新規に付加することで、セッションIDを変更することができる。2回目のテストでは、例えば、APサーバ404-1、404-2、404-3、404-4の順にHTTPリクエストが振り分けられる。HTTPリクエストの数がAPサーバの数より多い場合は、再びAPサーバ404-1に戻って、残りのHTTPリクエストが順に振り分けられる。このとき、各APサーバ404が処理したHTTPリクエストの組み合わせと処理順序を、順序情報1623に登録しておく。例えば、テストシナリオ1622に10個のHTTPリクエストR1~R10が含まれている場合、1、5、及び9番目のHTTPリクエストがAPサーバ404-1に送信され、2、6、及び10番目のHTTPリクエストがAPサーバ404-2に送信される。また、3及び7番目のHTTPリクエストがAPサーバ404-3に送信され、4及び8番目のHTTPリクエストがAPサーバ404-4に送信される。APサーバ404-1、404-2、404-3、及び404-4のサーバIDをそれぞれA、B、C、及びDとすると、これらの4つのグループのHTTPリクエストが、下記のように順序情報1623に登録される。A:R1、R5、R9B:R2、R6、R10C:R3、R7D:R4、R82回目のテストにおけるすべてのHTTPレスポンスが、1回目のテストにおけるすべてのHTTPレスポンスと一致すれば、テストシナリオ1622に含まれるすべてのHTTPリクエストのURLに対して、ラウンドロビン型の選択アルゴリズムを適用可能と判断できる。ただし、同一のAPサーバ404で処理されたHTTPリクエストについては、それらがそれぞれ異なるAPサーバ404で処理された場合に同じHTTPレスポンスが得られることが保証されないため、3回目以降のテストを行うことが望ましい。3回目のテストでは、順序情報1623に登録されたHTTPリクエストのうち、同一のグループに含まれるHTTPリクエストがそれぞれ異なるAPサーバ404に送信されるように、HTTPリクエストが振り分けられる。この場合、R1、R5、及びR9がそれぞれ異なるAPサーバ404に送信され、R2、R6、及びR10がそれぞれ異なるAPサーバ404に送信される。また、R3及びR7がそれぞれ異なるAPサーバ404に送信され、R4及びR8がそれぞれ異なるAPサーバ404に送信される。そこで、例えば、下記のようにHTTPリクエストを振り分ければよい。A:R1、R2、R3、R4B:R5、R6、R7、R8C:R9、R102回目及び3回目のテストにおけるすべてのHTTPレスポンスが、1回目のテストにおけるすべてのHTTPレスポンスと一致すれば、すべてのURLに対して、ラウンドロビン型の選択アルゴリズムを適用可能と判断できる。3回目以降のテストにこのようなルールを順次適用することで、16個以内のHTTPリクエストであれば、3回以下のテストにより十分な組み合わせを実現できる。さらに4回目のテストを行えば、64個までのHTTPリクエストに対して十分な組み合わせを実現可能である。ロードバランサ403は、2回目以降の各テストにおけるすべてのHTTPレスポンスが、1回目のテストにおけるすべてのHTTPレスポンスと一致すれば、すべてのURLとラウンドロビン型の選択アルゴリズムとを対応付けて戦略情報412に登録する。一方、いずれかのテストにおけるいずれかのHTTPレスポンスが、1回目のテストにおけるHTTPレスポンスと一致しなければ、すべてのURLとスティッキー型の選択アルゴリズムとを対応付けて戦略情報412に登録する。図17は、ラウンドロビン型及びスティッキー型の2種類の選択アルゴリズムが適用される場合の、図16のロードバランサ403によるテストシナリオ実行処理の例を示すフローチャートである。図17のフローチャートでは、DBリクエスト、DBレスポンス、及びHTTPレスポンスに関する処理が省略されているが、それらの処理については図12及び図13と同様である。ロードバランサ403は、クライアント401からHTTPリクエストを受信し、そのHTTPリクエストをテストシナリオ1622に登録するステップ1701。そして、ラウンドロビン型の選択アルゴリズムにより振り分け先APサーバ404を選択し、そのAPサーバ404にHTTPリクエストを送信するステップ1702。次に、クライアント401からテストシナリオ1611に含まれる最後のHTTPリクエストを受信したか否かをチェックしステップ1703、受信していなければステップ1703,No、ステップ1701及び1702の処理を繰り返す。これにより、テストシナリオ1611に含まれるすべてのHTTPリクエストが同一のAPサーバ404に送信され、そのAPサーバ404からそれぞれのHTTPリクエストに対するHTTPレスポンスを受信する。最後のHTTPリクエストを受信するとステップ1703,Yes、ロードバランサ403は、ラウンドロビン型の選択アルゴリズムに基づいてテストを行うステップ1704。このテストでは、テストシナリオ1622に登録されたHTTPリクエストがAPサーバ404-1~404-4に振り分けて送信され、APサーバ404-1~404-4からそれぞれのHTTPリクエストに対するHTTPレスポンスを受信する。次に、ロードバランサ403は、各APサーバ404に振り分けられた同一グループのHTTPリクエストが、既にそれぞれ異なるAPサーバ404に振り分け済みか否かをチェックするステップ1705。同一グループのHTTPリクエストを異なるAPサーバ404に振り分け済みでなければステップ1705,No、ステップ1704のテストを繰り返す。繰り返しのテストでは、同一グループのHTTPリクエストが異なるAPサーバ404に振り分けられるように、各APサーバに振り分けるHTTPリクエストの組み合わせが変更される。各テストにおける同一グループのHTTPリクエストがそれぞれ異なるAPサーバ404に振り分け済みであればステップ1705,Yes、各テストで受信したHTTPリクエストをチェックするステップ1706。このとき、各テストにおけるすべてのHTTPリクエストが、ステップ1701~1703で受信したすべてのHTTPリクエストと比較される。そして、各テストにおけるすべてのHTTPレスポンスが、ステップ1701~1703で受信したすべてのHTTPレスポンスと一致すれば、すべてのURLとラウンドロビン型の選択アルゴリズムとを対応付けて戦略情報412に登録するステップ1707。一方、いずれかのテストにおけるいずれかのHTTPレスポンスが、ステップ1701~1703で受信したHTTPレスポンスと一致しなければ、すべてのURLとスティッキー型の選択アルゴリズムとを対応付けて戦略情報412に登録するステップ1708。図16の情報処理システムによれば、テストシナリオ1611に含まれるHTTPリクエストの数がAPサーバの数より多い場合でも、最も効率的なテスト回数で、ラウンドロビン型の選択アルゴリズムを適用可能か否かを判断することができる。なお、HTTPリクエストの数がAPサーバの数以下の場合は、ステップ1704のテストを1回行うだけで、すべてのHTTPリクエストをそれぞれ異なるAPサーバ404に振り分けられる。この場合、ステップ1705の判定結果はYesとなり、直ちにステップ1706以降の処理が行われる。図2~図16の実施形態において、HTTPリクエストの代わりにコマンドが用いられる場合は、戦略情報412のURLの代わりにコマンドの文字列が用いられ、HTTPレスポンスの代わりにコマンドに対する応答が用いられる。図2の情報処理装置201、図4、図8、図9、及び図16のクライアント401、ロードバランサ403、APサーバ404、及びDBサーバ801は、例えば、図18に示すような情報処理装置コンピュータを用いて実現可能である。図18の情報処理装置は、CentralProcessingUnitCPU1801、メモリ1802、入力装置1803、出力装置1804、外部記憶装置1805、媒体駆動装置1806、及びネットワーク接続装置1807を備える。これらはバス1808により互いに接続されている。メモリ1802は、例えば、ReadOnlyMemoryROM、RandomAccessMemoryRAM、フラッシュメモリ等の半導体メモリであり、処理に用いられるプログラム及びデータを格納する。例えば、CPU1801は、メモリ1802を利用してプログラムを実行することにより、クライアント401、ロードバランサ403、APサーバ404、又はDBサーバ801の処理を行う。メモリ1802は、図2の格納部214としても使用でき、セッションDB411、戦略情報412、DBリクエスト情報913、HTTPレスポンス情報914、テストシナリオ1611、1622、及び順序情報1623を格納することもできる。入力装置1803は、例えば、キーボード、ポインティングデバイス等であり、ユーザ又はオペレータからの指示や情報の入力に用いられる。出力装置1804は、例えば、表示装置、プリンタ、スピーカ等であり、ユーザ又はオペレータへの問い合わせや処理結果の出力に用いられる。クライアント401の処理結果には、HTTPレスポンスに基づいてレンダリングされた画面も含まれる。外部記憶装置1805は、例えば、磁気ディスク装置、光ディスク装置、光磁気ディスク装置、テープ装置等である。この外部記憶装置1805には、ハードディスクドライブも含まれる。情報処理装置は、この外部記憶装置1805にプログラム及びデータを格納しておき、それらをメモリ1802にロードして使用することができる。媒体駆動装置1806は、可搬型記録媒体1809を駆動し、その記録内容にアクセスする。可搬型記録媒体1809は、メモリデバイス、フレキシブルディスク、光ディスク、光磁気ディスク等である。この可搬型記録媒体1809には、CompactDiskReadOnlyMemoryCD-ROM、DigitalVersatileDiskDVD、UniversalSerialBusUSBメモリ等も含まれる。ユーザ又はオペレータは、この可搬型記録媒体1809にプログラム及びデータを格納しておき、それらをメモリ1802にロードして使用することができる。このように、各種処理に用いられるプログラム及びデータを格納するコンピュータ読み取り可能な記録媒体には、メモリ1802、外部記憶装置1805、及び可搬型記録媒体1809のような、物理的な非一時的な記録媒体が含まれる。ネットワーク接続装置1807は、LocalAreaNetworkLAN、インターネット等の通信ネットワークに接続され、通信に伴うデータ変換を行う通信インタフェースである。情報処理装置は、プログラム及びデータを外部の装置からネットワーク接続装置1807を介して受け取り、それらをメモリ1802にロードして使用することもできる。なお、情報処理装置が図18のすべての構成要素を含む必要はなく、用途や条件に応じて一部の構成要素を省略することも可能である。例えば、情報処理装置がロードバランサ403、APサーバ404、又はDBサーバ801として使用される場合は、入力装置1803及び出力装置1804を省略してもよい。開示の実施形態とその利点について詳しく説明したが、当業者は、特許請求の範囲に明確に記載した本発明の範囲から逸脱することなく、様々な変更、追加、省略をすることができるであろう。"