JP5724687B2 - 情報処理装置、サーバ選択方法、及びプログラム - Google Patents

Description

本発明は、複数のサーバの中から、クライアントにより要求された処理を実行するサーバを選択する情報処理装置、サーバ選択方法、及びプログラムに関する。

Ｗｅｂシステムのように、複数のサーバを並べてアプリケーションプログラムの処理を並列化する情報処理システムでは、クライアントにより要求された処理を実行するサーバを決定するために、ロードバランサと呼ばれる情報処理装置が設けられることが多い。

図１は、このような情報処理システムの構成例を示している。図１の情報処理システムは、ロードバランサ１０３及びアプリケーション（ＡＰ）サーバ１０４−１〜１０４−４を含む。ロードバランサ１０３は、クライアント１０１からの処理要求をインターネット等の通信ネットワーク１０２を介して受信し、ＡＰサーバ１０４−１〜１０４−４に振り分けることにより負荷を分散させる。これにより、クライアント１０１に対して安定したサービスを提供するとともに、いずれかのＡＰサーバの故障時にも継続してサービスを提供することができる。

ロードバランサ１０３は、クライアント１０１だけでなく、他のクライアントを含む複数のクライアントからの処理要求を受信して、ＡＰサーバ１０４−１〜１０４−４に振り分けることができる。以下の説明では、アプリケーションプログラムを単にアプリケーションと称する場合がある。

ロードバランサが使用する負荷分散のアルゴリズム（戦略）は数種類あるが、以下の２種類が一般的である。
（１）スティッキー型
このアルゴリズム（戦略）では、同一のクライアントからの複数の処理要求を、同一のＡＰサーバに振り分ける。この場合、クライアントのインターネットプロトコル（ＩＰ）アドレスやクッキー情報等を識別情報として用いて、同一のクライアントにより要求された処理を実行するＡＰサーバとして同一のＡＰサーバを選択する。この戦略によれば、分散処理されることを意識しない既存のアプリケーションでも正しく動作する可能性が高いため、よく利用されている。一方、ＡＰサーバの数が過剰になった場合等に簡単にＡＰサーバを停止できないという問題や、ＡＰサーバがダウンしたときにそのＡＰサーバを利用していたクライアントの処理がすべて停止してしまうという問題が指摘されている。
（２）ラウンドロビン型
このアルゴリズム（戦略）では、同一又は複数のクライアントからの複数の処理要求を、所定のアルゴリズムにより複数のＡＰサーバに振り分ける。この戦略は仕組みが単純である一方で、アプリケーションが分散処理に対応するように作成されていないと、正しく動作しない可能性がある。

また、複数のウェブサイトを含むウェブ・ファームにおいて、特定のウェブサイトをアクセスするための顧客要求を共用可能顧客要求と共用不能顧客要求に分類する技術も知られている。この技術では、共用可能顧客要求を他のウェブサイトに割り当てられたサーバに処理させ、共用不能顧客要求を特定のウェブサイトサーバに割り当てられたサーバに処理させる。

複数のＡＰサーバを有するシステムにおいて、ロードバランサにより選択されたＡＰサーバがアプリケーションを実行する際に作成したセッションデータを、ＡＰサーバ間で共有する技術も知られている。

特許第３９８９４４３号明細書 特許第３５３７３３８号明細書 特開２０１０−０７９５２３号公報

上述した従来の情報処理システムには、以下のような問題がある。
近年では、Platform as a Service（ＰａａＳ）等のクラウド型のサービスが普及し始め、そのサービスでは、ラウンドロビン型の分散戦略が採用されるケースが多くなっている。

ラウンドロビン型で動作しないアプリケーションの多くは、クライアントの状態をＡＰサーバのメモリやローカルディスク内に保持する仕組みになっている。クライアントの状態としては、クライアントがログインしているか否か、オンラインショッピングサービスのショッピングカートに入っている商品は何か等の情報が挙げられる。ＡＰサーバがクライアントの状態を保持する場合はスティッキー型の分散戦略が望ましく、ラウンドロビン型の分散戦略を採用するには、アプリケーションを並列処理可能なように改変する必要がある。

例えば、アプリケーションをオンプレミスからクラウドに移行する場合、オンプレミスでスティッキー型の分散戦略を採用していると、そのままではクラウドに移行してもアプリケーションが正しく動作しない。このため、アプリケーションの改変が必要になるが、アプリケーションの規模が大きくなると、アプリケーション全体を改変するために多大なコストと時間を要する。

１つの側面では、本発明は、要求される処理を実行するサーバを選択するための選択アルゴリズムを処理の種別に応じて柔軟に変更できるようにすることを目的とする。

情報処理装置は、格納手段、受信手段、選択手段、及び送信手段を含む。
格納手段は、要求される処理を示す処理識別情報と、複数のサーバの中から処理を実行するサーバを選択するための選択アルゴリズムとの対応関係を格納する。受信手段は、クライアントから処理要求を受信する。選択手段は、格納手段から、処理要求により指定される処理識別情報に対応する選択アルゴリズムを取得し、取得した選択アルゴリズムに基づいて、複数のサーバの中から、その処理要求により要求された処理を実行するサーバを選択する。送信手段は、選択されたサーバに処理要求を送信する。

要求される処理を実行するサーバを選択するための選択アルゴリズムを処理の種別に応じて柔軟に変更できる。

従来の情報処理システムの構成図である。 情報処理装置の機能的構成図である。 サーバ選択処理のフローチャートである。 第１の情報処理システムの構成図である。 戦略情報を示す図である。 第１の負荷分散処理のフローチャートである。 第１のアプリケーション実行処理のフローチャートである。 第２の情報処理システムの構成図である。 第３の情報処理システムの構成図である。 HyperText Transfer Protocol（ＨＴＴＰ）レスポンス情報を示す図である。 データベース（ＤＢ）リクエスト情報を示す図である。 第２の負荷分散処理のフローチャート（その１）である。 第２の負荷分散処理のフローチャート（その２）である。 第２のアプリケーション実行処理のフローチャートである。 第３の情報処理システムにおける通信手順を示す図である。 第４の情報処理システムの構成図である。 テストシナリオ実行処理のフローチャートである。 情報処理装置の構成図である。

以下、図面を参照しながら、実施形態を詳細に説明する。
図２は、実施形態の情報処理装置の機能的構成例を示している。図２の情報処理装置２０１は、受信部２１１、選択部２１２、送信部２１３、及び格納部２１４を含み、複数のサーバの中から、クライアントにより要求された処理を実行するサーバを選択する。

格納部２１４は、要求される処理を示す処理識別情報と、複数のサーバの中から処理を実行するサーバを選択するための選択アルゴリズムとの対応関係を格納する。例えば、Ｗｅｂシステムの場合は、HyperText Transfer Protocol（ＨＴＴＰ）リクエストに含まれるUniform Resource Locator（ＵＲＬ）が、処理識別情報として用いられる。また、それ以外の情報処理システムの場合は、クライアントからサーバに対するコマンドの文字列等を、処理識別情報として用いてもよい。選択アルゴリズムとしては、スティッキー型及びラウンドロビン型を含む複数のサーバ選択アルゴリズムが用いられる。

図３は、図２の情報処理装置によるサーバ選択処理のフローチャートである。まず、受信部２１１は、クライアントから処理要求を受信する（ステップ３０１）。選択部２１３は、格納部２１４から、処理要求により指定される処理識別情報に対応する選択アルゴリズムを取得する（ステップ３０２）。そして、取得した選択アルゴリズムに基づいて、複数のサーバの中から、その処理要求により要求された処理を実行するサーバを選択する（ステップ３０３）。送信部２１３は、選択されたサーバに処理要求を送信する（ステップ３０４）。
このような情報処理装置によれば、要求される処理を実行するサーバを選択するための選択アルゴリズムを処理の種別に応じて柔軟に変更できる。

図４は、図２の情報処理装置をロードバランサとして使用した情報処理システムの構成例を示している。図４の情報処理システムは、ロードバランサ４０３及びＡＰサーバ４０４−１〜４０４−４を含む。

クライアント４０１は、パーソナルコンピュータや携帯端末等の情報処理装置であり、インターネット等の通信ネットワーク４０２を介して、ロードバランサ４０３にアクセスする。クライアント４０１は、ＨＴＴＰリクエスト等の処理要求をロードバランサ４０３に送信する。

ＨＴＴＰリクエストを送信する場合、クライアント４０１のユーザは、ＵＲＬを直接入力したり、ブックマークを選択したりすることで、アクセス先のＵＲＬを指定する。これにより、指定されたＵＲＬとクエリを含むＨＴＴＰリクエストが、ロードバランサ４０３に送信される。

ロードバランサ４０３は、並列処理に適したサーバオペレーティングシステム（ＯＳ）を搭載した情報処理装置であり、クライアント４０１からの処理要求を受信してＡＰサーバ４０４−１〜４０４−４に振り分ける。ロードバランサ４０３には、スティッキー型及びラウンドロビン型を含む複数のサーバ選択アルゴリズムが組み込まれており、セッションデータベース（ＤＢ）４１１及び戦略情報４１２が格納されている。

セッションＤＢ４１１は、クライアント４０１のセッションを識別する識別情報（セッションＩＤ）と、セッション開始時のＨＴＴＰリクエストを処理したＡＰサーバ４０４の識別情報（サーバＩＤ）との対応関係を表す。セッション開始時に、セッションＩＤとサーバＩＤがセッションＤＢ４１１に登録され、セッション終了時に、登録された情報が削除される。戦略情報４１２は、アクセス先のＵＲＬと選択アルゴリズムの対応関係を表す。

図５は、戦略情報４１２の例を示している。図５の戦略情報４１２において、エントリ５０１〜５０４の“Ｒ”は、ラウンドロビン型の選択アルゴリズムを表し、エントリ５０５の“Ｓ”は、スティッキー型の選択アルゴリズムを表している。戦略情報４１２に登録されるＵＲＬは、アクセス先のＵＲＬのすべての文字列である必要はなく、その一部の文字列でもよい。例えば、エントリ５０１の“/login.do”なる文字列を含むＵＲＬには、ラウンドロビン型の選択アルゴリズムが対応付けられており、エントリ５０５の“/hotitem.do”なる文字列を含むＵＲＬには、スティッキー型の選択アルゴリズムが対応付けられている。

スティッキー型の選択アルゴリズムでは、同一のセッションに属する複数のＨＴＴＰリクエストが同一のＡＰサーバ４０４に振り分けられる。例えば、同一のＩＰアドレスや同一のクッキー情報が使用されている複数のＨＴＴＰリクエストは、同一のセッションに属する。

ラウンドロビン型の選択アルゴリズムでは、例えば、ＡＰサーバ４０４−１〜４０４−４から１つのＡＰサーバが所定の順番で選択される。所定の順番は、サーバＩＤの順番でもよく、負荷の低い順でもよい。さらに、ラウンドロビン型の選択アルゴリズムでは、ＡＰサーバ４０４−１〜４０４−４から１つのＡＰサーバをランダムに選択してもよい。

戦略情報４１２は、例えば、アプリケーションの開発者が並列処理可能か否か等のアプリケーションの特性を考慮して、手作業で入力してもよく、ロードバランサ４０３自身が所定のアルゴリズムにより生成してもよい。ロードバランサ４０３は、戦略情報４１２を参照して、処理要求に含まれるＵＲＬに対応する選択アルゴリズムを取得し、その選択アルゴリズムに基づいて処理を実行するサーバを選択する。

ロードバランサ４０３は、クライアント４０１だけでなく、他のクライアントを含む複数のクライアントからの処理要求を受信して、ＡＰサーバ４０４−１〜４０４−４に振り分けることができる。

ＡＰサーバ４０４−１〜４０４−４は、並列処理に適したサーバＯＳを搭載した情報処理装置であり、ロードバランサ４０３から受信した処理要求に基づいて、アプリケーションを実行する。

図６は、ラウンドロビン型及びスティッキー型の２種類の選択アルゴリズムが適用される場合の、図４のロードバランサ４０３による負荷分散処理の例を示すフローチャートである。

ロードバランサ４０３は、クライアント４０１からＨＴＴＰリクエストを受信し（ステップ６０１）、そのＨＴＴＰリクエストからクッキー情報等のセッションＩＤを抽出する（ステップ６０２）。そして、抽出したセッションＩＤがセッションＤＢ４１１に登録された最新のセッションＩＤと一致するか否かをチェックする（ステップ６０３）。

抽出したセッションＩＤが最新のセッションＩＤでなければ（ステップ６０３，Ｎｏ）、ラウンドロビン型の選択アルゴリズムにより振り分け先ＡＰサーバ４０４を選択する（ステップ６０４）。そして、セッションＩＤと、選択したＡＰサーバ４０４のサーバＩＤとを対応付けて、セッションＤＢ４１１に登録し（ステップ６０５）、そのＡＰサーバ４０４にＨＴＴＰリクエストを送信する（ステップ６０６）。

一方、抽出したセッションＩＤが最新のセッションＩＤであれば（ステップ６０３，Ｙｅｓ）、ＨＴＴＰリクエストからＵＲＬを抽出し、戦略情報４１２を参照して、そのＵＲＬに対応する選択アルゴリズムを取得する（ステップ６０８）。そして、取得した選択アルゴリズムがラウンドロビン型又はスティッキー型のいずれであるかをチェックする（ステップ６０９）。

選択アルゴリズムがラウンドロビン型であれば（ステップ６０９，Ｙｅｓ）、ラウンドロビン型の選択アルゴリズムにより振り分け先ＡＰサーバ４０４を選択し（ステップ６１０）、ステップ６０６の処理を行う。一方、選択アルゴリズムがスティッキー型であれば（ステップ６０９，Ｎｏ）、セッションＤＢ４１１からセッションＩＤに対応するサーバＩＤを取得し、そのサーバＩＤが示すＡＰサーバ４０４を振り分け先に決定する（ステップ６１１）。そして、ステップ６０６の処理を行う。

図７は、図４のＡＰサーバ４０４によるアプリケーション実行処理の例を示すフローチャートである。ＡＰサーバ４０４は、ロードバランサ４０３からＨＴＴＰリクエストを受信し（ステップ７０１）、そのＨＴＴＰリクエストにより要求される処理を実行する（ステップ７０２）。そして、処理結果を含むＨＴＴＰレスポンスをロードバランサ４０３に送信する（ステップ７０３）。

このような情報処理システムによれば、１台のロードバランサ４０３により、アクセス先のＵＲＬ毎にＡＰサーバ４０４の選択アルゴリズムを切り替えることができる。このため、例えば、オンプレミスでスティッキー型の選択アルゴリズムに基づき動作していたアプリケーションをクラウドに移行する場合に、アプリケーションをＵＲＬに対応する部分毎に分割して、部分毎に異なる選択アルゴリズムを採用することができる。したがって、大規模なアプリケーションであっても一部のみの改変で対応することが可能になり、改変に要する負担が軽減される。例えば、アプリケーションを２つに分割してその一方のみを改変すれば、改変に要する負担は半分に軽減される。

また、この情報処理システムをクラウド環境で運用する場合、既存のアプリケーションと新規なアプリケーションの両方を搭載したプラットフォームを構築することができる。

図８は、情報処理システムの別の構成例を示している。図８の情報処理システムは、図４の情報処理システムにデータベース（ＤＢ）サーバ８０１を追加した構成を有する。
ＡＰサーバ４０４は、ロードバランサ４０３から受信した処理要求に基づいてデータ要求を生成し、ＤＢサーバ８０１に送信する。ＤＢサーバ８０１は、並列処理に適したサーバＯＳを搭載した情報処理装置であり、リレーショナルデータベース（ＲＤＢ）等のＤＢを保持する。ＤＢサーバ８０１は、ＡＰサーバ４０４から受信したデータ要求に対するデータ応答を生成して、ＡＰサーバ４０４に返信する。

このような情報処理システムにおいても、図４の情報処理システムと同様に、ロードバランサ４０３により、アクセス先のＵＲＬ毎にＡＰサーバ４０４の選択アルゴリズムを切り替えることができる。

図４及び図８の情報処理システムは４台のＡＰサーバを含んでいるが、実施形態の情報処理システムに含まれるＡＰサーバの数は３台以下の場合もあり、５台以上の場合もある。実際の情報処理システムでは、システムへの負荷に合わせてＡＰサーバの台数が決定される。クラウド環境では、ＡＰサーバの台数が柔軟に増減される場合もある。

次に、図９から図１５までを参照しながら、ロードバランサ４０３が戦略情報４１２を生成する構成と動作について説明する。
図９は、このような情報処理システムにおけるロードバランサ４０３とＡＰサーバ４０４−１及び４０４−２の機能的構成例を示している。ＡＰサーバの数が３台以上の場合も、同様の機能的構成が用いられる。

図９のロードバランサ４０３は、図２の情報処理装置に対応し、ＤＢリクエスト管理部９１１及びＨＴＴＰレスポンス管理部９１２を含む。ロードバランサ４０３は、ＤＢリクエスト情報９１３及びＨＴＴＰレスポンス情報９１４を用いて、戦略情報４１２を生成する。

ＤＢリクエスト管理部９１１は、ＡＰサーバ４０４がＤＢサーバ８０１に送信したＤＢリクエストと、ＡＰサーバ４０４がＤＢサーバ８０１から受信したＤＢレスポンスとを、ＤＢリクエスト情報９１３として格納する。ＤＢリクエストには、クエリやデータ更新処理命令等が含まれる。

ロードバランサ４０３は、同一のＨＴＴＰリクエストをＡＰサーバ４０４−１及び４０４−２に送信することができる。ＨＴＴＰレスポンス管理部９１２は、ＡＰサーバ４０４−１及び４０４−２に送信されたＨＴＴＰリクエストに対する応答であるＨＴＴＰレスポンスを、ＨＴＴＰレスポンス情報９１４として格納する。

ＡＰサーバ４０４−ｉ（ｉ＝１，２）には１つ以上のアプリケーションがデプロイされており、ＵＲＬ等のルールに応じて対応するアプリケーションが起動される。アプリケーションには、ＤＢサーバ８０１にＤＢリクエストを送信するプログラムが記述されている。ＡＰサーバ４０４−ｉは、ＤＢリクエストブロック部９２１−ｉ、ＤＢリクエスト取得部９２２−ｉ、ＤＢレスポンス処理部９２３−ｉ、及びＨＴＴＰレスポンス処理部９２４−ｉを含む。

ＤＢリクエストブロック部９２１−ｉは、所定の条件に従って、ＤＢサーバ８０１に対するＤＢリクエストの送信を遮断する。ＤＢリクエスト取得部９２２−ｉは、ＤＢサーバ８０１に送信されたＤＢリクエストとＤＢサーバ８０１から受信したＤＢレスポンスとを取得する。ＤＢレスポンス処理部９２３−ｉは、ブロックされたＤＢリクエストに対して、ダミーのＤＢレスポンスを返却する。ＨＴＴＰレスポンス処理部９２４−ｉは、ＤＢレスポンスからＨＴＴＰレスポンスを生成して、ロードバランサ４０３に送信する。

図１０は、ＨＴＴＰレスポンス情報９１４の例を示している。図１０のＤＢリクエスト情報９１４には、セッションＩＤ、セッション内画面ＩＤ、サーバＩＤ、ＨＴＴＰリクエスト、及びＨＴＴＰレスポンスが対応付けられて登録される。

１つのセッションにおいてクライアント４０１から複数のＨＴＴＰリクエストが送信される場合、クライアント４０１の表示装置には、複数のＨＴＴＰレスポンスに対応して複数の画面が順に表示されることがある。このような画面遷移が行われる場合、セッション内画面ＩＤによりそれぞれの画面が識別される。

サーバＩＤは、ＨＴＴＰリクエストの送信先のＡＰサーバ４０４を示しており、ＡＰサーバ４０４−１及び４０４−２のサーバＩＤは、それぞれ“Ａ”及び“Ｂ”である。ＨＴＴＰリクエストには、アクセス先のＵＲＬが含まれている。ＨＴＴＰレスポンスは、例えば、ＨＴＴＰリクエストに対する応答画面を表示するためのHyperText Markup Language（ＨＴＭＬ）ファイルである。

図１１は、ＤＢリクエスト情報９１３の例を示している。図１０のＤＢリクエスト情報９１３には、セッションＩＤ、セッション内画面ＩＤ、ＤＢリクエスト、及びＤＢレスポンスが対応付けられて登録される。

図９の情報処理システムでは、ＵＲＬ毎に正しい選択アルゴリズムを適用可能な戦略情報４１２を生成することが望ましい。そこで、１人のユーザがセッションを継続しながら一連の操作を行う場合に、同一のＡＰサーバ４０４−１ですべての処理を実行したときの処理結果と、１画面毎にＡＰサーバ４０４−１及び４０４−２を切り替えて処理を実行したときの処理結果を比較する。そして、両方の処理結果が一致していれば、ラウンドロビン型の選択アルゴリズムを適用可能と判断する。

この場合、２回目のＨＴＴＰリクエストに対して、ＡＰサーバ４０４−１による処理結果とＡＰサーバ４０４−２による処理結果が比較される。ただし、各ＡＰサーバ４０４がそれぞれＤＢサーバ８０１に問い合わせを行うと、ＡＰサーバ４０４間でＤＢサーバ８０１における処理結果が変化することがあり得る。

例えば、１回目のＨＴＴＰリクエストでログインし、２回目のＨＴＴＰリクエストで商品をショッピングカートに入れて在庫引き当てを行うアプリケーションを想定する。１回目のＨＴＴＰリクエストはＡＰサーバ４０４−１で処理される。

２回目のＨＴＴＰリクエストについては、最初に、ＡＰサーバ４０４−１で処理され、得られたＨＴＴＰレスポンスがＨＴＴＰレスポンス情報９１４に登録される。次に、ＡＰサーバ４０４−１に送信されたＨＴＴＰリクエストと同一のＨＴＴＰリクエストが、ロードバランサ４０３からＡＰサーバ４０４−２に送信され、得られたＨＴＴＰレスポンスがＨＴＴＰレスポンス情報９１４に登録される。そして、２つのＨＴＴＰレスポンスが比較される。

ところが、２回目のＨＴＴＰレスポンスをＡＰサーバ４０４−１が処理したときに、ＤＢサーバ８０１の在庫を減らして、商品の数を１から０に変更すると、次に同じ処理をＡＰサーバ４０４−２が行ったときに、商品をショッピングカートに入れることができない。このため、本来一致すべき２つのＨＴＴＰレスポンスが異なってしまい、ラウンドロビン型で処理できるＵＲＬであっても、スティッキー型を採用せざるを得なくなる。

そこで、１つのＨＴＴＰリクエストに対して、ＤＢサーバ８０１への問い合わせは１回のみ行い、その応答をＡＰサーバ４０４間で利用できるようにすることが好ましい。この場合、ＡＰサーバ４０４−１及び４０４−２がともにＤＢサーバ８０１に問い合わせを行うのではなく、ＡＰサーバ４０４−１によるＤＢリクエストに対するＤＢレスポンスを保存しておき、それをＡＰサーバ４０４−２からのＤＢレスポンスとして利用する。このとき、ＤＢリクエストブロック部９２１−２は、ＡＰサーバ４０４−２からのＤＢリクエストの送信を遮断する。

図１２及び図１３は、ラウンドロビン型及びスティッキー型の２種類の選択アルゴリズムが適用される場合の、図９のロードバランサ４０３による負荷分散処理の例を示すフローチャートである。

ロードバランサ４０３は、クライアント４０１からＨＴＴＰリクエストを受信し（図１２のステップ１２０１）、そのＨＴＴＰリクエストからセッションＩＤとＵＲＬを抽出する（ステップ１２０２）。そして、抽出したセッションＩＤがＨＴＴＰレスポンス情報９１４に登録された最新のセッションＩＤと一致するか否かをチェックする（ステップ１２０３）。

抽出したセッションＩＤが最新のセッションＩＤでなければ（ステップ１２０３，Ｎｏ）、ラウンドロビン型の選択アルゴリズムにより振り分け先ＡＰサーバ４０４を選択する（ステップ１２０４）。そして、そのＡＰサーバ４０４に、セッションＩＤ、セッション内画面ＩＤ、及びＨＴＴＰリクエストを送信する（ステップ１２０５）。

このとき、ＨＴＴＰレスポンス管理部９１２は、セッションＩＤと、セッション内画面ＩＤと、選択したＡＰサーバ４０４のサーバＩＤと、ＨＴＴＰリクエストとを対応付けて、ＨＴＴＰレスポンス情報９１４に登録する。また、抽出したＵＲＬとラウンドロビン型の選択アルゴリズムとを対応付けて戦略情報４１２に登録する。

次に、ロードバランサ４０３は、振り分け先ＡＰサーバ４０４から、セッションＩＤ及びセッション内画面ＩＤとともに、送信したＨＴＴＰリクエストに基づくＤＢリクエストを受信する（ステップ１２０６）。このとき、ＤＢリクエスト管理部９１１は、受信したセッションＩＤ、セッション内画面ＩＤ、及びＤＢリクエストを対応付けて、ＤＢリクエスト情報９１３に登録する。

次に、ロードバランサ４０３は、振り分け先ＡＰサーバ４０４から、セッションＩＤ及びセッション内画面ＩＤとともに、ＤＢリクエストに対するＤＢサーバ８０１からの応答であるＤＢレスポンスを受信する（ステップ１２０７）。このとき、ＤＢリクエスト管理部９１１は、ＤＢリクエスト情報９１３に登録されているセッションＩＤ、セッション内画面ＩＤ、及びＤＢリクエストと対応付けて、受信したＤＢレスポンスを追加登録する。

次に、ロードバランサ４０３は、振り分け先ＡＰサーバ４０４から、セッションＩＤ及びセッション内画面ＩＤとともに、ＨＴＴＰリクエストに対するＨＴＴＰレスポンスを受信する（ステップ１２０８）。このとき、ＨＴＴＰレスポンス管理部９１２は、ＨＴＴＰレスポンス情報９１４に登録されているセッションＩＤ、セッション内画面ＩＤ、サーバＩＤ、及びＨＴＴＰリクエストと対応付けて、受信したＨＴＴＰレスポンスを追加登録する。

一方、抽出したセッションＩＤが最新のセッションＩＤであれば（ステップ１２０３，Ｙｅｓ）、ロードバランサ４０３は、抽出したＵＲＬが戦略情報４１２に登録されているか否かをチェックする（ステップ１２０９）。抽出したＵＲＬが戦略情報４１２に登録されていれば（ステップ１２０９，Ｙｅｓ）、戦略情報４１２からそのＵＲＬに対応する選択アルゴリズムを取得する（ステップ１２１０）。そして、取得した選択アルゴリズムがラウンドロビン型又はスティッキー型のいずれであるかをチェックする（ステップ１２１１）。

選択アルゴリズムがラウンドロビン型であれば（ステップ１２１１，Ｙｅｓ）、ラウンドロビン型の選択アルゴリズムにより振り分け先ＡＰサーバ４０４を選択し（ステップ１２１２）、ステップ１２０５以降の処理を行う。一方、選択アルゴリズムがスティッキー型であれば（ステップ１２１１，Ｎｏ）、ＨＴＴＰレスポンス情報９１４からセッションＩＤに対応するサーバＩＤを取得し、そのサーバＩＤが示すＡＰサーバ４０４を振り分け先に決定する（ステップ１２１３）。そして、ステップ１２０５以降の処理を行う。

一方、抽出したＵＲＬが戦略情報４１２に登録されていなければ（ステップ１２０９，Ｎｏ）、ロードバランサ４０３は、最初にスティッキー型の選択アルゴリズムに基づき、振り分け先のＡＰサーバ４０４を選択する（ステップ１３０１）。この場合、ステップ１２１３と同様に、ＨＴＴＰレスポンス情報９１４からセッションＩＤに対応するサーバＩＤを取得し、そのサーバＩＤが示すＡＰサーバ４０４を振り分け先に決定する。そして、ステップ１３０２〜１３０５の処理を行う。ステップ１３０２〜１３０５の処理は、ステップ１２０５〜１２０８の処理と同様である。

次に、ロードバランサ４０３は、ラウンドロビン型の選択アルゴリズムにより振り分け先ＡＰサーバ４０４を選択し（ステップ１３０６）、そのＡＰサーバ４０４に、セッションＩＤ、セッション内画面ＩＤ、及びＨＴＴＰリクエストを送信する（ステップ１３０７）。このとき、ＨＴＴＰレスポンス管理部９１２は、セッションＩＤと、セッション内画面ＩＤと、選択したＡＰサーバ４０４のサーバＩＤと、ＨＴＴＰリクエストとを対応付けて、ＨＴＴＰレスポンス情報９１４に登録する。

次に、ロードバランサ４０３は、振り分け先ＡＰサーバ４０４から、セッションＩＤ及びセッション内画面ＩＤとともに、送信したＨＴＴＰリクエストに基づくＤＢリクエストを受信する（ステップ１３０８）。

そして、ＤＢリクエスト管理部９１１は、受信したセッションＩＤ、セッション内画面ＩＤ、及びＤＢリクエストの組み合わせがＤＢリクエスト情報９１３に登録されているか否かをチェックする（ステップ１３０９）。その組み合わせがＤＢリクエスト情報９１３に登録されていれば（ステップ１３０９，Ｙｅｓ）、ＤＢリクエスト情報９１３から対応するＤＢレスポンスを取得して、振り分け先ＡＰサーバ４０４に送信する（ステップ１３１０）。

次に、ロードバランサ４０３は、振り分け先ＡＰサーバ４０４から、セッションＩＤ及びセッション内画面ＩＤとともに、ＨＴＴＰリクエストに対するＨＴＴＰレスポンスを受信する（ステップ１３１１）。このとき、ＨＴＴＰレスポンス管理部９１２は、ＨＴＴＰレスポンス情報９１４に登録されているセッションＩＤ、セッション内画面ＩＤ、サーバＩＤ、及びＨＴＴＰリクエストと対応付けて、受信したＨＴＴＰレスポンスを追加登録する。

次に、ＨＴＴＰレスポンス管理部９１２は、ステップ１３０５で登録されたＨＴＴＰレスポンスと、ステップ１３１１で登録されたＨＴＴＰレスポンスとを比較する（ステップ１３１２）。そして、２つのＨＴＴＰレスポンスが一致すれば（ステップ１３１２，Ｙｅｓ）、そのＵＲＬに対してラウンドロビン型の選択アルゴリズムを適用可能と判断し、ＵＲＬとラウンドロビン型の選択アルゴリズムとを対応付けて戦略情報４１２に登録する（ステップ１３１３）。

一方、２つのＨＴＴＰレスポンスが一致しなければ（ステップ１３１２，Ｎｏ）、そのＵＲＬに対してラウンドロビン型の選択アルゴリズムを適用不可能と判断し、ＵＲＬとスティッキー型の選択アルゴリズムとを対応付けて戦略情報４１２に登録する（ステップ１３１４）。また、受信したセッションＩＤ、セッション内画面ＩＤ、及びＤＢリクエストの組み合わせがＤＢリクエスト情報９１３に登録されていない場合も（ステップ１３０９，Ｎｏ）、ステップ１３１４の処理を行う。

図１４は、図９のＡＰサーバ４０４によるアプリケーション実行処理の例を示すフローチャートである。ＡＰサーバ４０４は、ロードバランサ４０３から、セッションＩＤ、セッション内画面ＩＤ、及びＨＴＴＰリクエストを受信する（ステップ１４０１）。

ＤＢリクエストブロック部９２１は、受信したＨＴＴＰリクエストからＤＢリクエストを生成して（ステップ１４０２）、セッションＩＤ及びセッション内画面ＩＤとともに、ロードバランサ４０３に送信する（ステップ１４０３）。そして、ロードバランサ４０３からＤＢレスポンスを受信したか否かをチェックする（ステップ１４０４）。

ＤＢレスポンスを受信しなければ（ステップ１４０４，Ｎｏ）、ＤＢリクエストブロック部９２１は、生成したＤＢリクエストをＤＢサーバ８０１に送信する（ステップ１４０７）。そして、ＡＰサーバ４０４は、ＤＢサーバ８０１から、ＤＢリクエストに対するＤＢレスポンスを受信する（ステップ１４０８）。

ＤＢリクエスト取得部９２３は、ＤＢサーバ８０１に送信されたＤＢリクエストと、ＤＢサーバ８０１から受信したＤＢレスポンスとを取得する。そして、ＤＢレスポンスをアプリケーションに返却するとともに、セッションＩＤ及びセッション内画面ＩＤとともに、ＤＢレスポンスをロードバランサ４０３に送信する（ステップ１４０９）。

一方、ロードバランサ４０３からＤＢレスポンスを受信すれば（ステップ１４０４，Ｙｅｓ）、ＤＢリクエストブロック部９２１は、そのＤＢレスポンスをＤＢレスポンス処理部９２３に転送する（ステップ１４０５）。そして、ＤＢレスポンス処理部９２３は、転送されたＤＢレスポンスを、ＤＢサーバ８０１からのＤＢレスポンスとしてアプリケーションに返却する。

次に、ＨＴＴＰレスポンス処理部９２４は、ＤＢレスポンスからＨＴＴＰレスポンスを生成して、セッションＩＤ及びセッション内画面ＩＤとともに、ロードバランサ４０３に送信する（ステップ１４０６）。

ロードバランサ４０３は、ＨＴＴＰレスポンスをクライアント４０１に送信し、クライアント４０１は、受信したＨＴＴＰレスポンスに含まれるＨＴＭＬファイルに基づいて画面をレンダリングし、処理結果を表示する。

ところで、振り分け先ＡＰサーバ４０４のアプリケーションがラウンドロビン型で動作しないアプリケーションの場合、セッションＩＤ等のセッション情報をＡＰサーバ４０４内に保持しておき、その情報に基づいて要求された処理を実行することが多い。

この場合、ステップ１４０３で誤ったセッションＩＤ及びセッション内画面ＩＤがロードバランサ４０３に送信され、ステップ１３０９の判定結果がＮｏとなる可能性がある。あるいはステップ１４０６で、誤ったセッションＩＤ及びセッション内画面ＩＤ、又は誤ったＨＴＴＰレスポンスがロードバランサ４０３に送信され、ステップ１３１２の判定結果がＮｏとなる可能性もある。このような場合には、ステップ１３１４でラウンドロビン型の選択アルゴリズムは適用不可能と判断され、スティッキー型の選択アルゴリズムが戦略情報４１２に登録される。

図１２〜図１４に示したフローチャートにおいて、必ずしもすべてのステップを実行する必要はなく、情報処理システムの構成や条件に応じて一部のステップを省略することも可能である。例えば、ＤＢサーバ８０１に対する問い合わせが発生しない場合は、図１２のステップ１２０６及び１２０７、図１３のステップ１３０３、１３０４、及び１３０８〜１３１０、図１４のステップ１４０２〜１４０５及び１４０７〜１４０９の処理を省略してもよい。

次に、図１０のＨＴＴＰレスポンス情報９１４と図１１のＤＢリクエスト情報９１３を用いて、戦略情報４１２の生成処理の具体例を説明する。図１５は、この具体例において、ロードバランサ４０３とＡＰサーバ４０４の間で行われる通信と、ＡＰサーバ４０４とＤＢサーバ８０１の間で行われる通信の手順を示している。

手順１５０１−１：ロードバランサ４０３は、クライアント４０１から１回目のＨＴＴＰリクエストを受信する（ステップ１２０１）。１回目のＨＴＴＰリクエストのセッションＩＤは、図１０のＨＴＴＰレスポンス情報９１４にまだ登録されていないため、ステップ１２０３の判定結果はＮｏとなる。そこで、ロードバランサ４０３は、受信したＨＴＴＰリクエストをＡＰサーバ４０４−１に送信する（ステップ１２０５）。そして、ＨＴＴＰリクエストを、図１０のＨＴＴＰレスポンス情報９１４のエントリ１００１に登録し、ＵＲＬとラウンドロビン型の選択アルゴリズムとを対応付けて、図５の戦略情報４１２のエントリ５０１に登録する。

手順１５０１−２：ＡＰサーバ４０４−１は、受信したＨＴＴＰリクエストを処理するアプリケーションを実行する。アプリケーション中にＤＢアクセスがあるため、ＡＰサーバ４０４−１は、ＤＢリクエストをロードバランサ４０３に送信する（ステップ１４０３）。そして、ロードバランサ４０３は、受信したＤＢリクエストを、図１１のＤＢリクエスト情報９１３のエントリ１１０１に登録する（ステップ１２０６）。

手順１５０１−３：ロードバランサ４０３からＤＢレスポンスを受信しないため、ステップ１４０４の判定結果はＮｏとなる。そこで、ＡＰサーバ４０４−１は、ＤＢリクエストをＤＢサーバ８０１に送信する（ステップ１４０７）。

手順１５０１−４：ＡＰサーバ４０４−１は、ＤＢサーバ８０１からＤＢレスポンスを受信する（ステップ１４０８）。

手順１５０１−５：ＡＰサーバ４０４−１は、ＤＢレスポンス及びＨＴＴＰレスポンスをロードバランサ４０３に送信する（ステップ１４０９、１４０６）。そして、ロードバランサ４０３は、受信したＤＢレスポンスを、図１１のＤＢリクエスト情報９１３のエントリ１１０１に追加登録する（ステップ１２０７）。また、受信したＨＴＴＰレスポンスを、図１０のＨＴＴＰレスポンス情報９１４のエントリ１００１に追加登録する（ステップ１２０８）。

手順１５０２−１：ロードバランサ４０３は、クライアント４０１から２回目のＨＴＴＰリクエストを受信する（ステップ１２０１）。２回目のＨＴＴＰリクエストのセッションＩＤは、図１０のＨＴＴＰレスポンス情報９１４のエントリ１００１のセッションＩＤと一致するため、ステップ１２０３の判定結果はＹｅｓとなる。また、２回目のＨＴＴＰリクエストのＵＲＬは、図５の戦略情報４１２にまだ登録されていないため、ステップ１２０９の判定結果はＮｏとなる。そこで、ロードバランサ４０３は、受信したＨＴＴＰリクエストを、１回目と同じＡＰサーバ４０４−１に送信する（ステップ１３０２）。そして、ＨＴＴＰリクエストを、図１０のＨＴＴＰレスポンス情報９１４のエントリ１００２に登録する。

手順１５０２−２：ＡＰサーバ４０４−１は、受信したＨＴＴＰリクエストを処理するアプリケーションを実行する。アプリケーション中にＤＢアクセスがあるため、ＡＰサーバ４０４−１は、ＤＢリクエストをロードバランサ４０３に送信する（ステップ１４０３）。そして、ロードバランサ４０３は、受信したＤＢリクエストを、図１１のＤＢリクエスト情報９１３に登録する（ステップ１３０３）。

ところで、１つのＨＴＴＰリクエストを処理する際に複数のＤＢリクエストが発生することもあり得る。この例では、２回目のＨＴＴＰリクエストを処理する際に、図１１のエントリ１１０２及び１１０３が示す２つのＤＢリクエストが生成されている。エントリ１１０２のＤＢリクエストは、在庫を確認するＤＢリクエストであり、エントリ１１０３のＤＢリクエストは、在庫を引き当てるＤＢリクエストである。この場合、図１１のＤＢリクエスト情報９１３のエントリ１１０２及び１１０３に、それぞれのＤＢリクエストが登録される。

在庫引き当てを行うアプリケーションではトランザクションが実行されることが多いが、その場合でも、トランザクションを分割して、それぞれのＤＢリクエストがＤＢリクエスト情報９１３に登録される。

手順１５０２−３：ロードバランサ４０３からＤＢレスポンスを受信しないため、ステップ１４０４の判定結果はＮｏとなる。そこで、ＡＰサーバ４０４−１は、２つのＤＢリクエストをＤＢサーバ８０１に送信する（ステップ１４０７）。

手順１５０２−４：ＡＰサーバ４０４−１は、ＤＢサーバ８０１から２つのＤＢレスポンスを受信する（ステップ１４０８）。

手順１５０２−５：ＡＰサーバ４０４−１は、２つのＤＢレスポンスとＨＴＴＰレスポンスとをロードバランサ４０３に送信する（ステップ１４０９、１４０６）。そして、ロードバランサ４０３は、受信した２つのＤＢレスポンスを、図１１のＤＢリクエスト情報９１３のエントリ１１０２及び１１０３に追加登録する（ステップ１３０４）。また、受信したＨＴＴＰレスポンスを、図１０のＨＴＴＰレスポンス情報９１４のエントリ１００２に追加登録する（ステップ１３０５）。

手順１５０３−１：次に、ロードバランサ４０３は、２回目のＨＴＴＰリクエストを別のＡＰサーバ４０４−２に送信する（ステップ１３０７）。そして、ＨＴＴＰリクエストを、図１０のＨＴＴＰレスポンス情報９１４のエントリ１００３に登録する。

手順１５０３−２：ＡＰサーバ４０４−２は、受信したＨＴＴＰリクエストを処理するアプリケーションを実行する。アプリケーション中に２つのＤＢアクセスがあるため、ＡＰサーバ４０４−２は、２つのＤＢリクエストをロードバランサ４０３に送信する（ステップ１４０３）。

手順１５０３−３：このとき、図１１のＤＢリクエスト情報９１３のエントリ１１０２及び１１０３に、それぞれのＤＢリクエストが登録されているため、ロードバランサ４０３は、それらのＤＢレスポンスをＡＰサーバ４０４−２に送信する（ステップ１３１０）。

手順１５０３−４：ロードバランサ４０３からＤＢレスポンスを受信すると、ステップ１４０４の判定結果はＹｅｓとなる。そこで、ＡＰサーバ４０４−２は、受信した２つのＤＢレスポンスを用いてＨＴＴＰレスポンスを生成し、ロードバランサ４０３に送信する（ステップ１４０５、１４０６）。この場合、ＤＢサーバ８０１へのＤＢリクエストの送信は遮断される。ロードバランサ４０３は、受信したＨＴＴＰレスポンスを、図１０のＨＴＴＰレスポンス情報９１４のエントリ１００３に追加登録する（ステップ１３１１）。

このとき、ＨＴＴＰレスポンス情報９１４に登録されたエントリ１００２のＨＴＴＰレスポンスとエントリ１００３のＨＴＴＰレスポンスとが一致するため、ステップ１３１２の判定結果はＹｅｓとなる。そこで、ロードバランサ４０３は、２回目のＨＴＴＰリクエストのＵＲＬとラウンドロビン型の選択アルゴリズムとを対応付けて、戦略情報４１２のエントリ５０２に登録する（ステップ１３１３）。

その後、別のクライアントにより別のセッションが開始された場合、そのセッションのＵＲＬが戦略情報４１２に登録されていれば（ステップ１２０９，Ｙｅｓ）、対応する選択アルゴリズムを適用することができる。ＵＲＬが戦略情報４１２に登録されていない場合は（ステップ１２０９，Ｎｏ）、図１５と同様の手順で処理を行うことで、ＵＲＬと選択アルゴリズムを戦略情報４１２に追加登録することができる。

ロードバランサ４０３が戦略情報４１２を生成することで、アプリケーションの開発者が戦略情報４１２を入力する作業が不要になる。特に大規模なアプリケーションの場合、多数のＵＲＬの各々に対して選択アルゴリズムを入力する作業が発生するため、その時間を削減することで作業効率が向上する。

上述した具体例では、１つのセッション中の２つの画面について戦略情報４１２を生成する場合の構成と動作を説明した。しかし、現実のアプリケーションはより複雑であり、１つのセッションで１０画面〜数十画面を切り替えながら処理を行うことが多い。

このような場合でも、画面の数（ＨＴＴＰリクエストの数）と同じ数のＡＰサーバを用意して、図１３のステップ１３０６においてＨＴＴＰリクエスト毎に異なるＡＰサーバを振り分け先に決定すれば、同様にして戦略情報４１２を生成することが可能である。しかし、実際に画面の数と同じ数のＡＰサーバを用意することは、サーバコスト、設置場所、消費電力等の観点から難しいと考えられる。

そこで、画面の数がＡＰサーバの数より多い場合に、テストシナリオに従って複数のＨＴＴＰリクエストを順に処理するテストを繰り返し、戦略情報４１２を生成する方法が考えられる。

この場合、ロードバランサ４０３は、各ＡＰサーバに振り分けるＨＴＴＰリクエストの組み合わせを変更しながら、複数のＨＴＴＰリクエストを複数のＡＰサーバに振り分ける処理を複数回繰り返す。そして、それぞれの振り分け処理について、複数のＡＰサーバからすべてのＨＴＴＰリクエストに対するＨＴＴＰレスポンスを受信する。ロードバランサ４０３は、受信したＨＴＴＰレスポンスが、すべてのＨＴＴＰリクエストを同一のＡＰサーバで処理した場合のＨＴＴＰレスポンスと一致すれば、それらのＨＴＴＰリクエストのＵＲＬに対してラウンドロビン型の選択アルゴリズムを適用可能と判断する。

図１６は、このような情報処理システムにおけるロードバランサ４０３の機能的構成例を示している。図１６のロードバランサ４０３は、図９のロードバランサ４０３にセッションＩＤ変換部１６２１を追加した構成を有し、ＤＢリクエスト情報９１３、ＨＴＴＰレスポンス情報９１４、テストシナリオ１６２２、及び順序情報１６２３を用いて戦略情報４１２を生成する。

なお、図１６の情報処理システムは４台のＡＰサーバ４０４−１〜４０４−４を含んでいるが、ＡＰサーバの数が３台以下又は５台以上の場合も、同様の機能的構成が用いられる。

クライアント４０１には、テストシナリオ１６１１を自動実行するアプリケーションがインストールされている。テストシナリオ１６１１には、１つのセッションで使用されるＨＴＴＰリクエストの配列が記録されており、クライアント４０１は、それらのＨＴＴＰリクエストを順にロードバランサ４０３に送信する。

テストは複数回に分けて行われる。１回目のテストでは、クライアント４０１がテストシナリオ１６１１に従ってＨＴＴＰリクエストを順に送信し、ロードバランサ４０３は、受信したすべてのＨＴＴＰリクエストを同一のＡＰサーバに送信する。そして、各ＨＴＴＰリクエストに基づいて発生したＤＢリクエスト及びＤＢレスポンスを、ＤＢリクエスト情報９１３に登録し、ＨＴＴＰリクエスト及びＨＴＴＰレスポンスをＨＴＴＰレスポンス情報９１４に登録する。このとき、ロードバランサ４０３は、受信したＨＴＴＰリクエストをテストシナリオ１６２２に登録しておく。

２回目のテストでは、ロードバランサ４０３は、テストシナリオ１６２２に登録されたＨＴＴＰリクエストを、ラウンドロビン型の選択アルゴリズムによりＡＰサーバ４０４−１〜４０４−４に振り分ける。このとき、ＡＰサーバ４０４により１回目のテストと２回目のテストが同一セッションとして扱われることを防ぐために、セッションＩＤ変換部１６２１は、２回目以降のテストにおけるセッションＩＤを変更する。例えば、ＨＴＴＰリクエストにクッキー情報を新規に付加することで、セッションＩＤを変更することができる。

２回目のテストでは、例えば、ＡＰサーバ４０４−１、４０４−２、４０４−３、４０４−４の順にＨＴＴＰリクエストが振り分けられる。ＨＴＴＰリクエストの数がＡＰサーバの数より多い場合は、再びＡＰサーバ４０４−１に戻って、残りのＨＴＴＰリクエストが順に振り分けられる。このとき、各ＡＰサーバ４０４が処理したＨＴＴＰリクエストの組み合わせと処理順序を、順序情報１６２３に登録しておく。

例えば、テストシナリオ１６２２に１０個のＨＴＴＰリクエストＲ１〜Ｒ１０が含まれている場合、１、５、及び９番目のＨＴＴＰリクエストがＡＰサーバ４０４−１に送信され、２、６、及び１０番目のＨＴＴＰリクエストがＡＰサーバ４０４−２に送信される。また、３及び７番目のＨＴＴＰリクエストがＡＰサーバ４０４−３に送信され、４及び８番目のＨＴＴＰリクエストがＡＰサーバ４０４−４に送信される。

ＡＰサーバ４０４−１、４０４−２、４０４−３、及び４０４−４のサーバＩＤをそれぞれ“Ａ”、“Ｂ”、“Ｃ”、及び“Ｄ”とすると、これらの４つのグループのＨＴＴＰリクエストが、下記のように順序情報１６２３に登録される。
Ａ：Ｒ１、Ｒ５、Ｒ９
Ｂ：Ｒ２、Ｒ６、Ｒ１０
Ｃ：Ｒ３、Ｒ７
Ｄ：Ｒ４、Ｒ８

２回目のテストにおけるすべてのＨＴＴＰレスポンスが、１回目のテストにおけるすべてのＨＴＴＰレスポンスと一致すれば、テストシナリオ１６２２に含まれるすべてのＨＴＴＰリクエストのＵＲＬに対して、ラウンドロビン型の選択アルゴリズムを適用可能と判断できる。

ただし、同一のＡＰサーバ４０４で処理されたＨＴＴＰリクエストについては、それらがそれぞれ異なるＡＰサーバ４０４で処理された場合に同じＨＴＴＰレスポンスが得られることが保証されないため、３回目以降のテストを行うことが望ましい。

３回目のテストでは、順序情報１６２３に登録されたＨＴＴＰリクエストのうち、同一のグループに含まれるＨＴＴＰリクエストがそれぞれ異なるＡＰサーバ４０４に送信されるように、ＨＴＴＰリクエストが振り分けられる。

この場合、Ｒ１、Ｒ５、及びＲ９がそれぞれ異なるＡＰサーバ４０４に送信され、Ｒ２、Ｒ６、及びＲ１０がそれぞれ異なるＡＰサーバ４０４に送信される。また、Ｒ３及びＲ７がそれぞれ異なるＡＰサーバ４０４に送信され、Ｒ４及びＲ８がそれぞれ異なるＡＰサーバ４０４に送信される。そこで、例えば、下記のようにＨＴＴＰリクエストを振り分ければよい。
Ａ：Ｒ１、Ｒ２、Ｒ３、Ｒ４
Ｂ：Ｒ５、Ｒ６、Ｒ７、Ｒ８
Ｃ：Ｒ９、Ｒ１０

２回目及び３回目のテストにおけるすべてのＨＴＴＰレスポンスが、１回目のテストにおけるすべてのＨＴＴＰレスポンスと一致すれば、すべてのＵＲＬに対して、ラウンドロビン型の選択アルゴリズムを適用可能と判断できる。

３回目以降のテストにこのようなルールを順次適用することで、１６個以内のＨＴＴＰリクエストであれば、３回以下のテストにより十分な組み合わせを実現できる。さらに４回目のテストを行えば、６４個までのＨＴＴＰリクエストに対して十分な組み合わせを実現可能である。

ロードバランサ４０３は、２回目以降の各テストにおけるすべてのＨＴＴＰレスポンスが、１回目のテストにおけるすべてのＨＴＴＰレスポンスと一致すれば、すべてのＵＲＬとラウンドロビン型の選択アルゴリズムとを対応付けて戦略情報４１２に登録する。一方、いずれかのテストにおけるいずれかのＨＴＴＰレスポンスが、１回目のテストにおけるＨＴＴＰレスポンスと一致しなければ、すべてのＵＲＬとスティッキー型の選択アルゴリズムとを対応付けて戦略情報４１２に登録する。

図１７は、ラウンドロビン型及びスティッキー型の２種類の選択アルゴリズムが適用される場合の、図１６のロードバランサ４０３によるテストシナリオ実行処理の例を示すフローチャートである。図１７のフローチャートでは、ＤＢリクエスト、ＤＢレスポンス、及びＨＴＴＰレスポンスに関する処理が省略されているが、それらの処理については図１２及び図１３と同様である。

ロードバランサ４０３は、クライアント４０１からＨＴＴＰリクエストを受信し、そのＨＴＴＰリクエストをテストシナリオ１６２２に登録する（ステップ１７０１）。そして、ラウンドロビン型の選択アルゴリズムにより振り分け先ＡＰサーバ４０４を選択し、そのＡＰサーバ４０４にＨＴＴＰリクエストを送信する（ステップ１７０２）。

次に、クライアント４０１からテストシナリオ１６１１に含まれる最後のＨＴＴＰリクエストを受信したか否かをチェックし（ステップ１７０３）、受信していなければ（ステップ１７０３，Ｎｏ）、ステップ１７０１及び１７０２の処理を繰り返す。これにより、テストシナリオ１６１１に含まれるすべてのＨＴＴＰリクエストが同一のＡＰサーバ４０４に送信され、そのＡＰサーバ４０４からそれぞれのＨＴＴＰリクエストに対するＨＴＴＰレスポンスを受信する。

最後のＨＴＴＰリクエストを受信すると（ステップ１７０３，Ｙｅｓ）、ロードバランサ４０３は、ラウンドロビン型の選択アルゴリズムに基づいてテストを行う（ステップ１７０４）。このテストでは、テストシナリオ１６２２に登録されたＨＴＴＰリクエストがＡＰサーバ４０４−１〜４０４−４に振り分けて送信され、ＡＰサーバ４０４−１〜４０４−４からそれぞれのＨＴＴＰリクエストに対するＨＴＴＰレスポンスを受信する。

次に、ロードバランサ４０３は、各ＡＰサーバ４０４に振り分けられた同一グループのＨＴＴＰリクエストが、既にそれぞれ異なるＡＰサーバ４０４に振り分け済みか否かをチェックする（ステップ１７０５）。同一グループのＨＴＴＰリクエストを異なるＡＰサーバ４０４に振り分け済みでなければ（ステップ１７０５，Ｎｏ）、ステップ１７０４のテストを繰り返す。繰り返しのテストでは、同一グループのＨＴＴＰリクエストが異なるＡＰサーバ４０４に振り分けられるように、各ＡＰサーバに振り分けるＨＴＴＰリクエストの組み合わせが変更される。

各テストにおける同一グループのＨＴＴＰリクエストがそれぞれ異なるＡＰサーバ４０４に振り分け済みであれば（ステップ１７０５，Ｙｅｓ）、各テストで受信したＨＴＴＰレスポンスをチェックする（ステップ１７０６）。このとき、各テストにおけるすべてのＨＴＴＰレスポンスが、ステップ１７０１〜１７０３で受信したすべてのＨＴＴＰレスポンスと比較される。

そして、各テストにおけるすべてのＨＴＴＰレスポンスが、ステップ１７０１〜１７０３で受信したすべてのＨＴＴＰレスポンスと一致すれば、すべてのＵＲＬとラウンドロビン型の選択アルゴリズムとを対応付けて戦略情報４１２に登録する（ステップ１７０７）。一方、いずれかのテストにおけるいずれかのＨＴＴＰレスポンスが、ステップ１７０１〜１７０３で受信したＨＴＴＰレスポンスと一致しなければ、すべてのＵＲＬとスティッキー型の選択アルゴリズムとを対応付けて戦略情報４１２に登録する（ステップ１７０８）。

図１６の情報処理システムによれば、テストシナリオ１６１１に含まれるＨＴＴＰリクエストの数がＡＰサーバの数より多い場合でも、最も効率的なテスト回数で、ラウンドロビン型の選択アルゴリズムを適用可能か否かを判断することができる。

なお、ＨＴＴＰリクエストの数がＡＰサーバの数以下の場合は、ステップ１７０４のテストを１回行うだけで、すべてのＨＴＴＰリクエストをそれぞれ異なるＡＰサーバ４０４に振り分けられる。この場合、ステップ１７０５の判定結果はＹｅｓとなり、直ちにステップ１７０６以降の処理が行われる。

図２〜図１６の実施形態において、ＨＴＴＰリクエストの代わりにコマンドが用いられる場合は、戦略情報４１２のＵＲＬの代わりにコマンドの文字列が用いられ、ＨＴＴＰレスポンスの代わりにコマンドに対する応答が用いられる。

図２の情報処理装置２０１、図４、図８、図９、及び図１６のクライアント４０１、ロードバランサ４０３、ＡＰサーバ４０４、及びＤＢサーバ８０１は、例えば、図１８に示すような情報処理装置（コンピュータ）を用いて実現可能である。

図１８の情報処理装置は、Central Processing Unit （ＣＰＵ）１８０１、メモリ１８０２、入力装置１８０３、出力装置１８０４、外部記憶装置１８０５、媒体駆動装置１８０６、及びネットワーク接続装置１８０７を備える。これらはバス１８０８により互いに接続されている。

メモリ１８０２は、例えば、Read Only Memory（ＲＯＭ）、Random Access Memory（ＲＡＭ）、フラッシュメモリ等の半導体メモリであり、処理に用いられるプログラム及びデータを格納する。例えば、ＣＰＵ１８０１は、メモリ１８０２を利用してプログラムを実行することにより、クライアント４０１、ロードバランサ４０３、ＡＰサーバ４０４、又はＤＢサーバ８０１の処理を行う。メモリ１８０２は、図２の格納部２１４としても使用でき、セッションＤＢ４１１、戦略情報４１２、ＤＢリクエスト情報９１３、ＨＴＴＰレスポンス情報９１４、テストシナリオ１６１１、１６２２、及び順序情報１６２３を格納することもできる。

入力装置１８０３は、例えば、キーボード、ポインティングデバイス等であり、ユーザ又はオペレータからの指示や情報の入力に用いられる。出力装置１８０４は、例えば、表示装置、プリンタ、スピーカ等であり、ユーザ又はオペレータへの問い合わせや処理結果の出力に用いられる。クライアント４０１の処理結果には、ＨＴＴＰレスポンスに基づいてレンダリングされた画面も含まれる。

外部記憶装置１８０５は、例えば、磁気ディスク装置、光ディスク装置、光磁気ディスク装置、テープ装置等である。この外部記憶装置１８０５には、ハードディスクドライブも含まれる。情報処理装置は、この外部記憶装置１８０５にプログラム及びデータを格納しておき、それらをメモリ１８０２にロードして使用することができる。

媒体駆動装置１８０６は、可搬型記録媒体１８０９を駆動し、その記録内容にアクセスする。可搬型記録媒体１８０９は、メモリデバイス、フレキシブルディスク、光ディスク、光磁気ディスク等である。この可搬型記録媒体１８０９には、Compact Disk Read Only Memory （ＣＤ−ＲＯＭ）、Digital Versatile Disk（ＤＶＤ）、Universal Serial Bus（ＵＳＢ）メモリ等も含まれる。ユーザ又はオペレータは、この可搬型記録媒体１８０９にプログラム及びデータを格納しておき、それらをメモリ１８０２にロードして使用することができる。

このように、各種処理に用いられるプログラム及びデータを格納するコンピュータ読み取り可能な記録媒体には、メモリ１８０２、外部記憶装置１８０５、及び可搬型記録媒体１８０９のような、物理的な（非一時的な）記録媒体が含まれる。

ネットワーク接続装置１８０７は、Local Area Network（ＬＡＮ）、インターネット等の通信ネットワークに接続され、通信に伴うデータ変換を行う通信インタフェースである。情報処理装置は、プログラム及びデータを外部の装置からネットワーク接続装置１８０７を介して受け取り、それらをメモリ１８０２にロードして使用することもできる。

なお、情報処理装置が図１８のすべての構成要素を含む必要はなく、用途や条件に応じて一部の構成要素を省略することも可能である。例えば、情報処理装置がロードバランサ４０３、ＡＰサーバ４０４、又はＤＢサーバ８０１として使用される場合は、入力装置１８０３及び出力装置１８０４を省略してもよい。

開示の実施形態とその利点について詳しく説明したが、当業者は、特許請求の範囲に明確に記載した本発明の範囲から逸脱することなく、様々な変更、追加、省略をすることができるであろう。

１０１、４０１ クライアント
１０２、４０２ 通信ネットワーク
１０３、４０３ ロードバランサ
１０４−１〜１０４−４、４０４−１〜４０４−４ ＡＰサーバ
２０１ 情報処理装置
２１１ 受信部
２１２ 選択部
２１３ 送信部
２１４ 格納部
４１１ セッションＤＢ
４１２ 戦略情報
５０１〜５０５、１００１〜１００３、１１０１〜１１０３ エントリ
８０１ ＤＢサーバ
９１１ ＤＢリクエスト管理部
９１２ ＨＴＴＰレスポンス管理部
９１３ ＤＢリクエスト情報
９１４ ＨＴＴＰレスポンス情報
９２１−１、９２１−２ ＤＢリクエストブロック部
９２２−１、９２２−２ ＤＢリクエスト取得部
９２３−１、９２３−２ ＤＢレスポンス処理部
９２４−１、９２４−２ ＨＴＴＰレスポンス処理部
１６１１、１６２２ テストシナリオ
１６２１ セッションＩＤ変換部
１６２３ 順序情報
１８０１ ＣＰＵ
１８０２ メモリ
１８０３ 入力装置
１８０４ 出力装置
１８０５ 外部記憶装置
１８０６ 媒体駆動装置
１８０７ ネットワーク接続装置
１８０８ バス
１８０９ 可搬型記録媒体

Claims (6)

1. コンピュータのためのプログラムであって、
   前記プログラムは、
   クライアントから第１の処理要求を受信し、
   要求される処理を示す処理識別情報と、複数のサーバの中から前記クライアントの識別情報に基づいて同一のクライアントにより要求された処理を実行するサーバとして同一のサーバを選択する第１の選択アルゴリズム、又は前記複数のサーバの中からラウンドロビン方式でサーバを選択する第２の選択アルゴリズムのいずれか一方との対応関係を格納する格納手段から、前記第１の処理要求により指定される処理識別情報に対応する選択アルゴリズムを取得し、取得した選択アルゴリズムに基づいて、前記複数のサーバの中から、該第１の処理要求により要求された処理を実行するサーバを選択し、
   選択されたサーバに前記第１の処理要求を送信する
   処理を前記コンピュータに実行させ、
   前記プログラムは、
   前記格納手段に前記対応関係を登録するとき、前記クライアントから受信する第２の処理要求を、前記第１の選択アルゴリズムにより選択される第１のサーバと前記第２の選択アルゴリズムにより選択される第２のサーバに送信し、
   前記第１のサーバ及び前記第２のサーバから前記第２の処理要求に対する第１の処理結果及び第２の処理結果をそれぞれ受信し、
   前記第１の処理結果と前記第２の処理結果が一致しているとき、前記第２の処理要求により要求される処理を示す処理識別情報と前記第２の選択アルゴリズムとを対応付けて前記格納手段に登録する
   処理を前記コンピュータにさらに実行させることを特徴とするプログラム。
2. 前記コンピュータは、前記クライアントから受信する前記第２の処理要求に基づいてデータベースに対するデータ要求が発生する場合、前記第１のサーバが前記データ要求を前記データベースに送信して該データベースから受信したデータ応答を含む、前記第１の処理結果を前記第１のサーバから受信し、前記データ応答を前記第２のサーバに送信し、前記データ応答を含む前記第２の処理結果を前記第２のサーバから受信することを特徴とする請求項１記載のプログラム。
3. コンピュータのためのプログラムであって、
   前記プログラムは、
   クライアントから処理要求を受信し、
   要求される処理を示す処理識別情報と、複数のサーバの中から前記クライアントの識別情報に基づいて同一のクライアントにより要求された処理を実行するサーバとして同一のサーバを選択する第１の選択アルゴリズム、又は前記複数のサーバの中からラウンドロビン方式でサーバを選択する第２の選択アルゴリズムのいずれか一方との対応関係を格納する格納手段から、前記処理要求により指定される処理識別情報に対応する選択アルゴリズムを取得し、取得した選択アルゴリズムに基づいて、前記複数のサーバの中から、該処理要求により要求された処理を実行するサーバを選択し、
   選択されたサーバに前記処理要求を送信する
   処理を前記コンピュータに実行させ、
   前記プログラムは、
   前記格納手段に前記対応関係を登録するとき、１つのセッションで前記クライアントから受信する複数の処理要求を、前記複数のサーバのうち前記第１の選択アルゴリズムにより選択される第１のサーバに送信し、
   前記第１のサーバから前記複数の処理要求に対する第１の複数の処理結果を受信し、
   前記複数の処理要求を前記複数のサーバに振り分けて送信し、
   前記複数のサーバから前記複数の処理要求に対する第２の複数の処理結果を受信し、
   前記第１の複数の処理結果と前記第２の複数の処理結果が一致しているとき、前記複数の処理要求の各々により要求される処理を示す処理識別情報と前記第２の選択アルゴリズムとを対応付けて前記格納手段に登録する
   処理を前記コンピュータにさらに実行させることを特徴とするプログラム。
4. 前記コンピュータは、前記複数の処理要求の数が前記複数のサーバの数より多い場合、各サーバに振り分ける処理要求の組み合わせを変更しながら、前記複数の処理要求を前記複数のサーバに振り分けて送信する処理を複数回繰り返し、それぞれの繰り返しについて、前記複数のサーバから前記複数の処理要求に対する第２の複数の処理結果を受信し、前記第１の複数の処理結果と、それぞれの繰り返しについて受信した前記第２の複数の処理結果が一致しているとき、前記複数の処理要求の各々により要求される処理を示す処理識別情報と前記第２の選択アルゴリズムとを対応付けて前記格納手段に登録することを特徴とする請求項３記載のプログラム。
5. クライアントから第１の処理要求を受信する受信手段と、
   要求される処理を示す処理識別情報と、複数のサーバの中から前記クライアントの識別情報に基づいて同一のクライアントにより要求された処理を実行するサーバとして同一のサーバを選択する第１の選択アルゴリズム、又は前記複数のサーバの中からラウンドロビン方式でサーバを選択する第２の選択アルゴリズムのいずれか一方との対応関係を格納する格納手段と、
   前記格納手段から、前記第１の処理要求により指定される処理識別情報に対応する選択アルゴリズムを取得し、取得した選択アルゴリズムに基づいて、前記複数のサーバの中から、該第１の処理要求により要求された処理を実行するサーバを選択する選択手段と、
   選択されたサーバに前記第１の処理要求を送信する送信手段と、
   前記格納手段に前記対応関係を登録するとき、前記クライアントから受信する第２の処理要求を、前記第１の選択アルゴリズムにより選択される第１のサーバと前記第２の選択アルゴリズムにより選択される第２のサーバに送信し、前記第１のサーバ及び前記第２のサーバから前記第２の処理要求に対する第１の処理結果及び第２の処理結果をそれぞれ受信し、前記第１の処理結果と前記第２の処理結果が一致しているとき、前記第２の処理要求により要求される処理を示す処理識別情報と前記第２の選択アルゴリズムとを対応付けて前記格納手段に登録する手段と
   を備えることを特徴とする情報処理装置。
6. クライアントから第１の処理要求を受信し、
   要求される処理を示す処理識別情報と、複数のサーバの中から前記クライアントの識別情報に基づいて同一のクライアントにより要求された処理を実行するサーバとして同一のサーバを選択する第１の選択アルゴリズム、又は前記複数のサーバの中からラウンドロビン方式でサーバを選択する第２の選択アルゴリズムのいずれか一方との対応関係を格納する格納手段から、前記第１の処理要求により指定される処理識別情報に対応する選択アルゴリズムを取得し、取得した選択アルゴリズムに基づいて、前記複数のサーバの中から、該第１の処理要求により要求された処理を実行するサーバを選択し、
   選択されたサーバに前記第１の処理要求を送信し、
   前記格納手段に前記対応関係を登録するとき、前記クライアントから受信する第２の処理要求を、前記第１の選択アルゴリズムにより選択される第１のサーバと前記第２の選択アルゴリズムにより選択される第２のサーバに送信し、
   前記第１のサーバ及び前記第２のサーバから前記第２の処理要求に対する第１の処理結果及び第２の処理結果をそれぞれ受信し、
   前記第１の処理結果と前記第２の処理結果が一致しているとき、前記第２の処理要求により要求される処理を示す処理識別情報と前記第２の選択アルゴリズムとを対応付けて前記格納手段に登録する
   ことを特徴とするサーバ選択方法。

Images