(57)【要約】【課題】ＳａａＳアプリケーションにおいて、ある組織のユーザからのリクエスト量が多過ぎるために、他の組織のユーザのリクエストを処理できないという状況が発生する。【解決手段】第１の計算機と、第１の計算機から送信されるリクエストを受け付ける第２の計算機とを備える計算機システムであって、第２の計算機は、第１の計算機からリクエストを受信した場合、受け付けたリクエストの総数が第１の閾値以下か否かを判定し、受け付けたリクエストの総数が第１の閾値より大きいと判定された場合、第１の計算機から受信したリクエストの送信元のユーザが所属するグループを特定し、特定されたグループから受け付けたリクエスト数が第２の閾値以下か否かを判定し、特定されたグループから受け付けたリクエスト数が第２の閾値以下と判定された場合、特定されたグループからのリクエストを受け付ける。【選択図】図１
2011070435.tif 000002
【特許請求の範囲】
【請求項１】
一以上のクライアント装置からリクエストを受け付ける第１の計算機と、前記第１の計算機から送信される前記リクエストを受け付ける第２の計算機とを備える計算機システムであって、
前記第１の計算機は、第１のプロセッサと、前記第１のプロセッサに接続される第１のメモリと、前記第２の計算機と通信するための第１の通信部を備え、
前記第２の計算機は、第２のプロセッサと、前記第２のプロセッサに接続され、前記第２の計算機に設定される第１の閾値及び前記クライアント装置を操作するユーザが所属するグループごとに設定される第２の閾値が格納される第２のメモリと、前記第１の計算機と通信するための第２の通信部を備え、
前記第２の計算機は、
前記第１の計算機からリクエストを受信した場合、前記第１の計算機から受け付けたリクエストの総数を算出して、前記第１の計算機から受け付けたリクエストの総数が前記第１の閾値以下か否かを判定し、
前記第１の計算機から受け付けたリクエストの総数が前記第１の閾値より大きいと判定された場合、前記第１の計算機から受信したリクエストの送信元のユーザが所属する前記グループを特定し、
前記特定されたグループから受け付けたリクエスト数を算出し、前記特定されたグループから受け付けたリクエスト数が前記第２の閾値以下か否かを判定し、
前記特定されたグループから受け付けたリクエスト数が前記第２の閾値以下と判定された場合、前記特定されたグループからのリクエストを受け付けることを特徴とする計算機システム。
【請求項２】
前記第２の計算機は、
前記第１の計算機から受け付けたリクエストの総数が前記第１の閾値以下と判定された場合、前記第１の計算機から受信したリクエストの送信元のユーザが所属する前記グループを特定し、前記特定されたグループからのリクエストを受け付けることを特徴とする請求項１に記載の計算機システム。
【請求項３】
前記第２の計算機は、
前記特定されたグループから受け付けたリクエスト数が前記第２の閾値より大きいと判定された場合、前記特定されたグループからのリクエストを受け付けないことを特徴とする請求項２に記載の計算機システム。
【請求項４】
前記第２の閾値は、前記第２の計算機が当該グループから受け付け可能なリクエスト数を示すことを特徴とする請求項３に記載の計算機システム。
【請求項５】
前記第１のメモリには、前記第１の計算機が受け付けることが可能なリクエスト数を示す上限値と、前記第１の計算機から前記第２の計算機に送信され、前記第２の計算機に受け付けられたリクエストの数を示す、受け付けリクエスト数とが格納され、
前記第１の計算機は、
前記クライアント装置からリクエストが送信された場合、前記受け付けリクエスト数と前記上限値とを参照して、前記受け付けリクエスト数が、前記上限値以上か否かを判定し、
前記受け付けリクエスト数が、前記上限値より小さいと判定された場合、前記クライアント装置から受信したリクエストを受け付け、前記受け付けたリクエストを前記第２の計算機に送信することを特徴とする請求項４に記載の計算機システム。
【請求項６】
前記第２のメモリは、前記第２のプロセッサの負荷を監視するための監視プログラムを備え、
前記第２の計算機は、
前記第２のプロセッサの負荷が所定値以上の場合、前記第１の閾値が小さくなるように変更し、
前記第２のプロセッサの負荷が前記所定値以下の場合、前記第１の閾値が大きくなるように変更することを特徴とする請求項５に記載の計算機システム。
【請求項７】
前記第２の計算機は、
前記クライアント装置から送信されたリクエストの送信元のユーザが、前記クライアント装置からリクエストを送信するために使用されたログイン情報を、前記クライアント装置から取得し、
前記取得された前記ログイン情報に基づいて、前記第１の計算機から受信したリクエストの送信元のユーザが所属するグループを特定することを特徴とする請求項６に記載の計算機システム。
【請求項８】
前記第２のメモリは、前記第２の計算機が、各々の前記グループに所属するユーザから受け付けたリクエストを管理するためのリクエスト数管理テーブルを備え、
前記第２の計算機は、前記リクエスト数管理テーブルを参照して、前記特定されたグループから受け付けたリクエスト数を算出することを特徴とする請求項６に記載の計算機システム。
【請求項９】
前記第２のメモリは、前記第１の閾値と前記第２の閾値とを格納する閾値管理テーブルを備え、
前記第２の計算機は、
前記閾値管理テーブルを参照して、前記第１の計算機から受け付けたリクエストの総数が前記第１の閾値以下か否かを判定し、
前記閾値管理テーブルを参照して、前記特定されたグループから受け付けたリクエストが前記第２の閾値以下か否かを判定することを特徴とする請求項６に記載の計算機システム。
【請求項１０】
前記計算機システムは、さらに、前記リクエストを処理する複数の第３の計算機を備え、
前記第２の計算機は、前記受け付けたリクエストをラウンドロビンによって前記第３の計算機に割り当てることを特徴とする請求項１に記載の計算機システム。
【請求項１１】
前記計算機システムは、さらに、前記リクエストを処理する複数の第３の計算機を備え、
前記第２の計算機は、前記第３の計算機の負荷の低い順に、前記受け付けたリクエストを前記各第３の計算機に割り当てることを特徴とする請求項１に記載の計算機システム。
【請求項１２】
一以上のクライアント装置からリクエストを受け付ける第１の計算機と、前記第１の計算機から送信される前記リクエストを受け付ける第２の計算機とを備える計算機システムにおけるリクエスト処理方法であって、
前記第１の計算機は、第１のプロセッサと、前記第１のプロセッサに接続される第１のメモリと、前記第２の計算機と通信するための第１の通信部を備え、
前記第２の計算機は、第２のプロセッサと、前記第２のプロセッサに接続され、前記第２の計算機に設定される第１の閾値及び前記クラインと装置を操作するユーザが所属するグループごとに設定される第２の閾値が格納される第２のメモリと、前記第１の計算機と通信するための第２の通信部を備え、
前記方法は、
前記第２の計算機が、前記第１の計算機からリクエストを受信した場合、前記第１の計算機から受け付けたリクエストの総数を算出して、前記第１の計算機から受け付けたリクエストの総数が前記第１の閾値以下か否かを判定する第１のステップと、
前記第２の計算機が、前記第１の計算機から受け付けたリクエストの総数が前記第１の閾値より大きいと判定された場合、前記第１の計算機から受信したリクエストの送信元のユーザが所属する前記グループを特定する第２のステップと、
前記第２の計算機が、前記特定されたグループから受け付けたリクエスト数を算出し、前記特定されたグループから受け付けたリクエスト数が前記第２の閾値以下か否かを判定する第３のステップと、
前記第２の計算機が、前記特定されたグループから受け付けたリクエスト数が前記第２の閾値以下と判定された場合、前記特定されたグループからのリクエストを受け付ける第４のステップと、を含むことを特徴とするリクエスト処理方法。
【請求項１３】
前記第１のステップにおいて、前記第１の計算機から受け付けたリクエストの総数が前記第１の閾値以下と判定された場合、前記第２の計算機が、前記第１の計算機から受信したリクエストの送信元のユーザが所属する前記グループを特定し、前記特定されたグループからのリクエストを受け付けるステップを含むこと特徴とする請求項１２に記載のリクエスト処理方法。
【請求項１４】
前記第２の閾値は、前記第２の計算機が当該グループから受け付け可能なリクエスト数を示す閾値であり、
前記方法は、前記第３のステップにおいて、前記特定されたグループから受け付けたリクエスト数が前記第２の閾値より大きいと判定された場合、前記第２の計算機が、前記特定されたグループからのリクエストを受け付けないステップを含むこと特徴とする請求項１２に記載のリクエスト処理方法。
【請求項１５】
一以上のクライアント装置からリクエストを受け付ける計算機と接続され、前記計算機から送信される前記リクエストを受け付けるサーバ装置であって、
前記サーバ装置は、プロセッサと、前記プロセッサに接続され、前記サーバ装置に設定される第１の閾値及び前記クライアント装置を操作するユーザが所属するグループごとに設定される第２の閾値が格納されるメモリと、前記計算機と通信するための通信部を備え、
前記サーバ装置は、
前記計算機からリクエストを受信した場合、前記計算機から受け付けたリクエストの総数を算出して、前記計算機から受け付けたリクエストの総数が前記第１の閾値以下か否かを判定し、
前記計算機から受け付けたリクエストの総数が前記第１の閾値以下と判定された場合、前記計算機から受信したリクエストの送信元のユーザが所属する前記グループを特定し、前記特定されたグループからのリクエストを受け付け、
前記計算機から受け付けたリクエストの総数が前記第１の閾値より大きいと判定された場合、前記計算機から受信したリクエストの送信元のユーザが所属する前記グループを特定し、
前記特定されたグループから受け付けたリクエスト数を算出し、前記特定されたグループから受け付けたリクエスト数が前記第２の閾値以下か否かを判定し、
前記特定されたグループから受け付けたリクエスト数が前記第２の閾値より大きいと判定された場合、前記特定されたグループからのリクエストを受け付けず、
前記特定されたグループから受け付けたリクエスト数が前記第２の閾値以下と判定された場合、前記特定されたグループからのリクエストを受け付けることを特徴とするサーバ装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一つのシステムを複数の組織が利用する形態であるマルチテナント対応システム構成方法に関し、組織間で偏りなくリクエストを処理するための技術に関する。
【背景技術】
【０００２】
これまでクライアント装置上で実行するデスクトップアプリケーションとして実装されてきた企業内の業務システムの多くが、Ｗｅｂ上のサービスＳａａＳ（Ｓｏｆｔｗａｒｅ  ａｓ  ａ  Ｓｅｒｖｉｃｅ）として提供されはじめている。
【０００３】
ＳａａＳの特徴としてマルチテナントが挙げられる。マルチテナントとは、一つのシステムを複数の組織が利用する形態のことである。ここで、組織とは、複数のユーザから構成されるグループのことを示す。
【０００４】
マルチテナントでは、組織ごとのデータの管理が課題となり、当該課題を解決するための方法が考えられている（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特表２００９−５１８７１３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
特許文献１には、マルチテナントデータベース環境の構築方法に関する技術が開示されており、一つのシステムを複数の組織のユーザが利用することが可能となる。
【０００７】
しかし、特許文献１に開示された技術には、組織間のサービスバランスに関する技術が開示されていない。したがって、ある組織からのリクエスト量が多過ぎるために、サービスを提供するシステムが、他の組織のリクエストを処理できないという状況が発生する。
【課題を解決するための手段】
【０００８】
本発明の代表的な一例を示せば以下の通りである。すなわち、一以上のクライアント装置からリクエストを受け付ける第１の計算機と、前記第１の計算機から送信される前記リクエストを受け付ける第２の計算機とを備える計算機システムであって、前記第１の計算機は、第１のプロセッサと、前記第１のプロセッサに接続される第１のメモリと、前記第２の計算機と通信するための第１の通信部を備え、前記第２の計算機は、第２のプロセッサと、前記第２のプロセッサに接続され、前記第２の計算機に設定される第１の閾値及び前記クライアント装置を操作するユーザが所属するグループごとに設定される第２の閾値が格納される第２のメモリと、前記第１の計算機と通信するための第２の通信部を備え、前記第２の計算機は、前記第１の計算機からリクエストを受信した場合、前記第１の計算機から受け付けたリクエストの総数を算出して、前記第１の計算機から受け付けたリクエストの総数が前記第１の閾値以下か否かを判定し、前記第１の計算機から受け付けたリクエストの総数が前記第１の閾値より大きいと判定された場合、前記第１の計算機から受信したリクエストの送信元のユーザが所属する前記グループを特定し、前記特定されたグループから受け付けたリクエスト数を算出し、前記特定されたグループから受け付けたリクエスト数が前記第２の閾値以下か否かを判定し、前記特定されたグループから受け付けたリクエスト数が前記第２の閾値以下と判定された場合、前記特定されたグループからのリクエストを受け付けることを特徴とする。
【発明の効果】
【０００９】
本発明によれば、任意のグループにおけるリクエスト数が少ない場合は、当該グループのユーザのリクエストを優先的に受け付けることができる。したがって、特定のグループのユーザからのリクエスト数が多いために、他のグループのユーザからのリクエストを受け付けできない状態を回避することができる。
【図面の簡単な説明】
【００１０】
【図１】本発明の第１の実施形態の計算機システムの構成例を示すブロック図である。
【図２】本発明の第１の実施形態の流量制御装置がＷｅｂブラウザからリクエストを受け付けた場合に実行する処理を説明するフローチャートである。
【図３】本発明の第１の実施形態のサーバのスレッドが実行する処理を説明するフローチャートである。
【図４】本発明の第１の実施形態のスレッド−要求元対応テーブルの一例を示す説明図である。
【図５】本発明の第１の実施形態のステップ３０３におけるスレッド−要求元対応テーブルの変化を説明する図である。
【図６】本発明の第１の実施形態の閾値テーブルの一例を示す説明図である。
【図７】本発明の第１の実施形態のリクエスト取得プログラムが実行するステップ３０１における処理の詳細を説明するフローチャートである。
【図８】本発明の第１の実施形態における各組織の処理中のサービス量の一例を示した図である。
【図９】本発明の第２の実施形態のサーバの構成を示すブロック図である。
【図１０】本発明の第２の実施形態の閾値制御プログラムによって実行される処理を説明するフローチャートである。
【図１１】本発明の第２の実施形態におけるシステムの閾値Ｔの変更方法を説明するための図である。
【図１２】本発明の第３の実施形態の計算機システムの構成例を示すブロック図である。
【発明を実施するための形態】
【００１１】
［第１の実施形態］
以下、図１から図７を用いて、本発明の第１の実施形態を説明する。
【００１２】
図１は、本発明の第１の実施形態の計算機システムの構成例を示すブロック図である。
【００１３】
計算機システムは、情報処理装置１０１、１１０、１５０を備える。情報処理装置１０１と情報処理装置１１０とはインターネットを介して接続され、情報処理装置１１０と情報処理装置１５０とはＬＡＮを介して接続される。なお、情報処理装置１０１、１１０、１５０の接続方式は、これらに限定されない。
【００１４】
情報処理装置１０１は、ＣＰＵ（図示省略）、メモリ（図示省略）、記憶装置（図示省略）、及び通信部（図示省略）を備える。
【００１５】
メモリ（図示省略）にはＷｅｂブラウザが格納され、ＣＰＵ（図示省略）によって実行される。記憶装置（図示省略）は、ＣＰＵ（図示省略）が処理を実行するときに必要となる情報を格納する。通信部（図示省略）は、インターネットを介して情報処理装置１１０と接続する。
【００１６】
本実施形態において、計算機システムは、複数のユーザを一つのグループとして管理している。以下、当該グループを組織と呼ぶ。任意の組織に所属するユーザは、Ｗｅｂブラウザを用いて、情報処理装置１１０にリクエストを送信する。
【００１７】
以下、Ｗｅｂブラウザを格納する情報処理装置１０１をＷｅｂブラウザ１０１と呼ぶ。また、リクエストを送信するユーザが所属する組織を要求元とも呼ぶ。
【００１８】
情報処理装置１１０は、ネットワークを介してＷｅｂブラウザ１０１からリクエストを受信し、現在処理されているリクエストの数に応じて、情報処理装置１５０に受信したリクエストを送信する。以下、情報処理装置１１０を、流量制御装置１１０と呼ぶ。なお、流量制御装置１１０が実行する処理の詳細については、図２を用いて後述する。
【００１９】
流量制御装置１１０はＣＰＵ１２０、メモリ１３０、通信部１４０、及び記憶装置（図示省略）を備える。
【００２０】
ＣＰＵ１２０は、メモリ１３０上に展開されるプログラムを実行する。
【００２１】
記憶装置（図示省略）は、ＣＰＵ１２０が処理を実行するために必要となる情報を格納する。記憶装置（図示省略）は、例えば、ハードディスク等が考えられる。
【００２２】
メモリ１３０は、流量制御装置１１０が備える機能を実現するために必要となるプログラム、及び情報を格納する。メモリ１３０上に展開されたプログラムはＣＰＵ１２０によって実行される。
【００２３】
メモリ１３０は、リクエスト取得プログラム１３１、リクエスト数確認プログラム１３２、リクエスト投入プログラム１３３、リクエスト数更新プログラム１３４、リクエスト数１３５、及び上限値１３６を格納する。
【００２４】
リクエスト取得プログラム１３１は、Ｗｅｂブラウザ１０１からリクエストを取得するプログラムである。リクエスト数確認プログラム１３２は、リクエスト数１３５を確認するプログラムである。リクエスト投入プログラム１３３は、情報処理装置１５０にリクエストを投入（送信）するプログラムである。リクエスト数更新プログラム１３４は、リクエスト数１３５を更新するプログラムである。
【００２５】
また、リクエスト数１３５は、情報処理装置１５０に投入（送信）されたリクエストの数を示す。メモリ１３０は、パラメータ値としてリクエスト数１３５を格納する。上限値１３６は、流量制御装置１１０が受け付けることが可能なリクエストの数を示す。つまり、流量制御装置１１０は、上限値１３６より多い数のリクエストの受け付けを拒否する。メモリ１３０は、パラメータ値として上限値１３６を格納する。
【００２６】
なお、本実施形態において、上限値１３６は、予め設定された値であるが、計算機システムの管理者等によって、変更可能である。
【００２７】
通信部１４０は、ＬＡＮを介して情報処理装置１５０と接続する。
【００２８】
なお、流量制御装置１１０は、プロキシサーバとして動作してもよい。また、流量制御装置１１０が備える機能を他の装置、例えば、情報処理装置１５０が備えてもよい。
【００２９】
情報処理装置１５０は、ネットワークを介して流量制御装置１１０からリクエストを受信し、受信したリクエストに対応するサービスを提供する。本実施形態の情報処理装置１５０は、各組織に提供されているサービス量及び提供されている全サービス量に基づいて、リクエストを受け付けるか否かを判定する。以下、情報処理装置１５０を、サーバ１５０と呼ぶ。
【００３０】
サーバ１５０は、ＣＰＵ１６０、メモリ１７０、通信部１８０、及び記憶装置（図示省略）を備える。
【００３１】
ＣＰＵ１６０は、メモリ１７０上に展開されるプログラムを実行する。
【００３２】
記憶装置（図示省略）は、ＣＰＵ１６０が処理を実行するために必要となる情報を格納する。記憶装置（図示省略）は、例えば、ハードディスク等が考えられる。
【００３３】
メモリ１７０は、流量制御装置１１０が備える機能を実現するために必要となるプログラム、及び情報を格納する。メモリ１３０上に展開されたプログラムはＣＰＵ１２０によって実行される。
【００３４】
メモリ１７０は、要求元識別プログラム１７１、キュー追加プログラム１７２、リクエスト取得プログラム１７３、リクエスト処理プログラム１７４、リクエストキュー１７５、スレッド−要求元対応テーブル１７６、閾値テーブル１７７、最後にチェックした組織識別子１７８、及びスレッドプール１７９を格納する。
【００３５】
要求元識別プログラム１７１は、流量制御装置１１０から投入されたリクエストの要求元を識別するプログラムである。キュー追加プログラム１７２は、流量制御装置１１０から投入されたリクエストをリクエストキュー１７５に追加するプログラムである。リクエスト取得プログラム１７３は、閾値テーブル１７７を参照して、リクエストキュー１７５に格納されるリクエストを取得するプログラムである。リクエスト処理プログラム１７４は、リクエストキュー１７５から取得されたリクエストに対応する処理を実行するプログラムである。
【００３６】
リクエストキュー１７５は、流量制御装置１１０から受信したリクエストを格納する。
【００３７】
スレッドプール１７９は、流量制御装置１１０から受信したリクエストに対応する処理を実行するスレッドを格納する。本実施形態においては、一つのリクエストが一つのスレッドに対応し、当該スレッドによって、対応するリクエストの処理が実行される。図１に示す例では、スレッドプール１７９には、スレッド１〜スレッドｎが格納される。
【００３８】
本実施形態において、スレッド数がサーバ１５０の受け付け可能なリクエスト数となり、スレッド数が多いほどサーバ１５０の処理能力は高いことを意味する。
【００３９】
スレッド−要求元対応テーブル１７６は、スレッドと、当該スレッドに対応するリクエストの要求元との対応関係を格納する。スレッド−要求元対応テーブル１７６は、サーバ１５０が現在処理中のサービス量（リクエスト数）を計測するために用いられる。
【００４０】
閾値テーブル１７７は、システム全体のリクエスト数の閾値、及び組織ごとのリクエスト数の閾値を定義するテーブルである。システム全体のリクエスト数の閾値は、組織ごとのリクエスト数の閾値を判断するか否かを判定するための閾値である。また、組織ごとのリクエスト数の閾値は、各組織からリクエストを受け付け可能か否かを判定するための閾値である。閾値テーブル１７７の詳細については、図６を用いて後述する。また、これらの閾値を用いた処理の詳細は、図７を用いて後述する。
【００４１】
最後にチェックした組織識別子１７８は、サーバ１５０が後述する処理（図６参照）において、最後に確認した組織を識別するための識別子である。
【００４２】
図２は、本発明の第１の実施形態の流量制御装置１１０がＷｅｂブラウザ１０１からリクエストを受け付けた場合に実行する処理を説明するフローチャートである。
【００４３】
なお、以下で説明する処理は、ＣＰＵ１２０がメモリ１３０に格納されるプログラムを読み出し、読み出されたプログラムを実行することによって実現される。
【００４４】
リクエスト取得プログラム１３１は、Ｗｅｂブラウザ１０１から送信されるリクエストの到着を監視する（ステップ２０１）。なお、リクエスト取得プログラム１３１は、Ｗｅｂブラウザ１０１から送信されるリクエストの到着を常時監視してもよいし、周期的に監視してもよい。
【００４５】
リクエスト取得プログラム１３１がＷｅｂブラウザ１０１からリクエストの到着を検出した場合、リクエスト数確認プログラム１３２は、リクエスト数１３５及び上限値１３６を参照し、リクエスト数１３５が上限値１３６以下であるか否かを判定する（ステップ２０２）。
【００４６】
リクエスト数１３５が上限値１３６より大きいと判定された場合、流量制御装置１１０は、Ｗｅｂブラウザ１０１から送信されたリクエストの受け付けを拒否する。つまり、Ｗｅｂブラウザ１０１から送信されたリクエストが破棄される。流量制御装置１１０は、Ｗｅｂブラウザ１０１から送信されたリクエストを破棄した後に、ステップ２０１に戻り、同様の処理を実行する。
【００４７】
リクエスト数１３５が上限値１３６以下であると判定された場合、リクエスト数更新プログラム１３４は、リクエスト数１３５の値を「１」増加する（ステップ２０３）。
【００４８】
また、リクエスト投入プログラム１３３は、Ｗｅｂブラウザ１０１から送信されたリクエストをサーバ１５０に投入する（ステップ２０４）。
【００４９】
サーバ１５０から、投入されたリクエストに対するレスポンスが返ってきた場合、リクエスト数更新プログラム１３４は、リクエスト数１３５の値を「１」減少させる（ステップ２０５）。
【００５０】
以下、図２において説明した処理の具体例について説明する。
【００５１】
上限値１３６が「１００」、及びリクエスト数１３５が「９０」の場合について説明する。この場合、Ｗｅｂブラウザ１０１からリクエストの到着を検出した流量制御装置１１０は、リクエスト数１３５と上限値１３６とを参照して、リクエスト数１３５が上限値１３６以下であると判定する。
【００５２】
次に、リクエスト数更新プログラム１３４がリクエスト数１３５を更新（「１」増加）した後、リクエスト投入プログラム１３３がＷｅｂブラウザ１０１から受信したリクエストをサーバ１５０に投入する。
【００５３】
投入されたリクエストに対するレスポンスがサーバ１５０から返ってきた場合、リクエスト数更新プログラム１３４は、リクエスト数１３５を「１」減少する。
【００５４】
なお、リクエスト数１３５が「１００」であると判定された場合、流量制御装置１１０は、Ｗｅｂブラウザ１０１から到着したリクエストを破棄し、次のリクエストの到着を監視する。
【００５５】
流量制御装置１１０は、リクエスト数１３５及び上限値１３６に基づいて、当該リクエストをサーバ１５０に投入するか否かを判定する。
【００５６】
図３は、本発明の第１の実施形態のサーバ１５０のスレッドが実行する処理を説明するフローチャートである。スレッドは、周期的に以下で説明する処理を実行する。
【００５７】
なお、以下で説明する処理は、ＣＰＵ１６０がメモリ１７０に格納されるプログラムを読む出し、読み出されたプログラムを実行することによって実現される。
【００５８】
まず、リクエスト取得プログラム１７３が、閾値テーブル１７７を参照して、リクエストキュー１７５からリクエストを取得するための処理を実行する（ステップ３０１）。リクエスト取得プログラム１７３が実行する処理の詳細は、図７を用いて後述する。
【００５９】
リクエスト取得プログラム１７３は、リクエストを取得できたか否かを判定する（ステップ３０２）。
【００６０】
リクエストを取得できないと判定された場合、リクエスト取得プログラム１７３は、所定時間スリープした後（ステップ３０６）、再びリクエストを取得するための処理を実行する。
【００６１】
リクエストを取得できたと判定された場合、要求元識別プログラム１７１は、取得されたリクエストの要求元を特定する。次に、リクエスト取得プログラム１７３は、特定された要求元に基づいて、スレッド−要求元対応テーブル１７６を更新する（ステップ３０３）。
【００６２】
具体的には、リクエスト取得プログラム１７３は、スレッド−要求元対応テーブル１７６の取得されたリクエストに対応するスレッドのエントリに、特定された要求元を追加する。
【００６３】
なお、本実施形態において、要求元から送信されるリクエストには、要求元（リクエストを送信するユーザが所属する組織）を識別するための識別子が含まれる。要求元識別プログラム１７１は、当該識別子を参照することによって、取得されたリクエストの要求元を判別することができる。
【００６４】
また、ユーザがＷｅｂブラウザ１０１にログイン時に用いた情報（ログイン情報）、例えば、ユーザＩＤ、をサーバ１５０が取得し、要求元識別プログラム１７１が、取得された情報に基づいて、要求元を特定してもよい。この場合、サーバ１５０が組織と組織に所属するユーザＩＤとの対応関係を管理するテーブルを備え、要求元識別プログラム１７１が、当該テーブルを参照して、ユーザＩＤから取得されたリクエストの要求元を判別できる。
【００６５】
スレッドプール１７９のスレッドによって、取得されたリクエストが処理される（ステップ３０４）。具体的には、スレッド上でリクエスト処理プログラム１７４が実行され、リクエストが処理される。
【００６６】
リクエストの処理が終了した後、スレッドは、スレッド−要求元対応テーブル１７６の当該スレッドに対応するエントリから要求元を削除し（ステップ３０５）、ステップ３０１に戻り同様の処理（ステップ３０１〜３０６）を実行する。
【００６７】
図４は、本発明の第１の実施形態のスレッド−要求元対応テーブル１７６の一例を示す説明図である。
【００６８】
スレッド−要求元対応テーブル１７６は、スレッド番号４０１と処理中の要求元４０２とを含む。
【００６９】
スレッド番号４０１は、スレッドプール１７９に格納されるスレッドを識別するための識別子である。処理中の要求元４０２は、スレッドに対応するリクエストの要求元を識別するための識別子である。なお、スレッドに対応するリクエストが無い場合、処理中の要求元４０２は空白となる。この場合、スレッドプール１７９に格納されるスレッドは待機状態となる。
【００７０】
以下、図５を用いて、図３のステップ３０３における処理の具体例を説明する。
【００７１】
図５は、本発明の第１の実施形態のステップ３０３におけるスレッド−要求元対応テーブル１７６の変化を説明する図である。
【００７２】
図５に示す例では、スレッド番号４０１が「２」のスレッドは、待機状態となっている。
【００７３】
ステップ３０２において、リクエストが取得されたと判定された場合、要求元識別プログラム１７１が、取得されたリクエストの要求元を特定する。ここでは、取得されたリクエストの要求元は「Ｂ」であると特定される。なお、要求元識別プログラム１７１は、ＣＰＵ１６０によってメモリ１７０から読み出され、ＣＰＵ１６０によって実行される。
【００７４】
次に、リクエスト取得プログラム１７３は、スレッド−要求元対応テーブル１７６を参照して、待機状態のスレッドを検索し、スレッド番号４０１が「２」のスレッドが待機状態であることを検出する。なお、リクエスト取得プログラム１７３は、ＣＰＵ１６０によってメモリ１７０から読み出され、ＣＰＵ１６０によって実行される。
【００７５】
リクエスト取得プログラム１７３は、スレッド番号４０１が「２」のエントリの処理中の要求元４０２に「Ｂ」を追加する。
【００７６】
これによって、サーバ１５０は、当該サーバ１５０が処理している要求元のリクエストの数を把握することができる。
【００７７】
図６は、本発明の第１の実施形態の閾値テーブル１７７の一例を示す説明図である。
【００７８】
閾値テーブル１７７は、組織７０１と閾値７０２とを含む。
【００７９】
組織７０１は、リクエストの要求元のユーザが所属する組織を識別するための識別子である。なお、サーバ１５０に対応するエントリの組織７０１には、サーバ１５０を示す識別子「システム」が格納される。閾値７０２は、組織７０１に対応する組織のリクエスト数の閾値を示す。
【００８０】
本実施形態では、閾値７０２に格納された閾値に基づいて後述する処理（図７参照）が実行される。
【００８１】
図６に示すように、閾値テーブル１７７は、各組織の閾値と、システム（サーバ１５０）の閾値とを格納する。具体的には、組織Ａの閾値は「３０」、組織Ｂの閾値は「２０」、組織Ｃの閾値は「１０」、及びシステム（サーバ１５０）の閾値は「５０」である。
【００８２】
次に、ステップ３０１における処理について説明する。
【００８３】
図７は、本発明の第１の実施形態のリクエスト取得プログラム１７３が実行するステップ３０１における処理の詳細を説明するフローチャートである。リクエスト取得プログラム１７３は、サーバ１５０がリクエストを取得する度に以下で説明する処理を実行する。
【００８４】
なお、以下で説明する処理は、ＣＰＵ１６０がメモリ１７０に格納されるプログラムを読む出し、読み出されたプログラムを実行することによって実現される。
【００８５】
リクエスト取得プログラム１７３は、最後にチェックした組織識別子１７８を参照し、最後にチェックした組織識別子１７８に示された組織の次の組織から以下の処理を開始する（ステップ６０１）。以下、ステップ６０１において、処理の対象となる組織を処理対象組織とも呼ぶ。
【００８６】
なお、リクエスト取得プログラム１７３は、閾値テーブル１７７、及び最後にチェックした組織識別子１７８を参照することによって、処理対象組織が分かる。
【００８７】
例えば、前回実行されたステップ３０１の処理において、「組織Ｂ」で処理が終了した場合、最後にチェックした組織識別子１７８には、「組織Ｂ」が格納され、当該最後にチェックした組織識別子１７８を参照したリクエスト取得プログラム１７３は、「組織Ｃ」から処理を開始する。なお、各組織における処理の順番の決定方法は、予めサーバ１５０に設定された各組織の処理の順番に基づいて決定する方法、及び、サーバ１５０が格納する、各組織の処理の順番を規定するテーブル（図示省略）に基づいて決定する方法が考えられる。
【００８８】
毎回、同じ組織から処理が開始された場合当該組織のリクエストが優先的に処理されるが、ステップ６０１の処理によって、各組織のリクエストを均等に処理できる。
【００８９】
リクエスト取得プログラム１７３は、リクエストキュー１７５に処理対象組織のリクエストが格納されるか否かを判定する（ステップ６０２）。
【００９０】
リクエストキュー１７５に処理対象組織のリクエストが格納されないと判定された場合、リクエスト取得プログラム１７３は、流量制御装置１１０にｎｕｌｌを返す（ステップ６０３）。
【００９１】
リクエストキュー１７５に処理対象組織のリクエストが格納されると判定された場合、リクエスト取得プログラム１７３は、サーバ１５０が処理する全てのサービス量（総サービス量）がシステム全体（サーバ１５０）の閾値７０２以下であるか否かを判定する（ステップ６０４）。
【００９２】
具体的には、リクエスト取得プログラム１７３は、スレッド−要求元対応テーブル１７６を参照して、システム（サーバ１５０）全体の総サービス量Ｑ（ｔ）を算出する。次に、リクエスト取得プログラム１７３は、閾値テーブル１７７を参照して、算出された総サービス量Ｑ（ｔ）がシステムの閾値７０２以下であるか否を判定する。以下、システムの閾値７０２をシステムの閾値Ｔとも呼ぶ。
【００９３】
ステップ６０４における処理は、組織間のサービス量を調整する必要があるか否かを判定するための処理である。総サービス量Ｑ（ｔ）がシステムの閾値以下である場合、リクエスト取得プログラム１７３は、組織間のサービス量を調整する必要がないと判定する。総サービス量Ｑ（ｔ）がシステムの閾値より大きい場合、リクエスト取得プログラム１７３は、各組織間のサービス量を調整する必要がある判定し、ステップ６０６以下の処理を開始する。
【００９４】
なお、総サービス量Ｑ（ｔ）の算出方法としては、処理中の要求元４０２に格納された、全ての組織の数を足し合わせる方法が考えられる。例えば、図４に示す例では、総サービス量Ｑ（ｔ）は、「３」と算出される。
【００９５】
総サービス量Ｑ（ｔ）がシステムの閾値Ｔ以下であると判定された場合、リクエスト取得プログラム１７３は、リクエストキュー１７５からリクエストを取得する（ステップ６０５）。
【００９６】
当該取得されたリクエストは、リクエスト処理プログラム１７４によって処理され、当該リクエストに対するレスポンスが流量制御装置１１０に送信される。また、リクエスト取得プログラム１７３は、最後にチェックした組織識別子１７８を当該処理対象組織の識別子に更新する。
【００９７】
総サービス量Ｑ（ｔ）がシステムの閾値Ｔより大きいと判定された場合、リクエスト取得プログラム１７３は、組織間のサービス量を調整するための処理を開始する。
【００９８】
まず、リクエスト取得プログラム１７３は、処理対象組織のサービス量が当該処理対象組織の閾値７０２以下であるか否かを判定する（ステップ６０６）。
【００９９】
具体的には、リクエスト取得プログラム１７３は、スレッド−要求元対応テーブル１７６を参照して、処理対象組織のサービス量Ｑi（ｔ）を算出する。次に、リクエスト取得プログラム１７３は、閾値テーブル１７７を参照して、算出された処理対象組織のサービス量Ｑi（ｔ）が当該処理対象組織の閾値７０２以下であるか否を判定する。ここで、ｉは、組織Ａ又はＢなどの処理対象組織を識別するための添え字であり、組織の数だけ存在する。以下、処理対象組織の閾値７０２を処理対象組織の閾値Ｔiとも呼ぶ。
【０１００】
なお、処理対象組織のサービス量Ｑi（ｔ）の算出方法としては、処理中の要求元４０２に格納された、処理対象組織に対応する識別子の数を足し合わせる方法が考えられる。例えば、図４に示す例において、処理対象組織が「Ａ」である場合、処理対象組織のサービス量ＱA（ｔ）は、「２」と算出される。
【０１０１】
処理対象組織のサービス量が当該処理対象組織の閾値以下であると判定された場合、リクエスト取得プログラム１７３は、リクエストキュー１７５からリクエストを取得する（ステップ６０７）。
【０１０２】
当該取得されたリクエストは、リクエスト処理プログラム１７４によって処理され、当該リクエストに対するレスポンスが流量制御装置１１０に送信される。また、リクエスト取得プログラム１７３は、最後にチェックした組織識別子１７８を当該処理対象組織の識別子に更新する。
【０１０３】
処理対象組織のサービス量が当該処理対象組織の閾値より大きいと判定された場合、リクエスト取得プログラム１７３は、リクエストキュー１７５に処理されていない組織のリクエストがあるか否かを判定する（ステップ６０８）。つまり、当該処理対象組織のサービス量が集中していることを示す。したがって、当該処理対象組織のサービス量を調整するため、当該処理対象組織のリクエストは取得されない。
【０１０４】
リクエストキュー１７５に処理されていない組織のリクエストがあると判定された場合、リクエスト取得プログラム１７３は、ステップ６０６に戻り同様の処理を実行する。
【０１０５】
リクエストキュー１７５に処理されていない組織のリクエストがないと判定された場合、リクエスト取得プログラム１７３は、流量制御装置１１０にｎｕｌｌを返す（ステップ６０９）。
【０１０６】
図７のステップ６０４〜ステップ６０９の処理による効果について説明する。
【０１０７】
本実施形態では、まず、システム全体の総サービス量がシステムの閾値７０２以下であるか否かが判定される（ステップ６０４）。
【０１０８】
システム全体の総サービス量がシステムのリクエスト数の閾値７０２以下であれば、リクエスト取得プログラム１７３がリクエストキューからリクエストを取得し（ステップ６０５）、リクエスト処理プログラム１７４によって、当該リクエストに対応するサービスが処理対象組織に提供される。つまり、組織間のサービス量の調整は実行されない。
【０１０９】
一方、システム全体の総サービス量がシステムのリクエスト数の閾値７０２より大きい場合、処理中の組織ごとのサービス量に応じて、リクエストを受け付けるか否かを判定するための処理（ステップ６０６〜ステップ６０９）が実行される。つまり、組織間のサービス量を調整するための処理が実行される。
【０１１０】
従来は、システム全体の総サービス量が一定以上であればリクエストの受け付けを拒否していたため、組織間のサービス量が考慮されることなく、リクエストの受け付けが拒否されていた。したがって、組織間にサービス量の偏りが生じる原因となっていた。
【０１１１】
しかし、本実施形態では、システム全体の総サービス量がシステムの閾値７０２より大きいと判定されたことを契機に、組織毎のサービス量に基づいて、受け付けるリクエスト数を調整するための処理（ステップ６０６〜ステップ６０９）が実行される。つまり、組織間のサービス量の偏りを考慮して、リクエストを受け付けるか否かの処理が実行される。これによって、組織間のサービス量の偏りを解消することが可能となる。
【０１１２】
したがって、サービス量が少ない組織からのリクエストを優先的に処理することができる。
【０１１３】
また、ステップ６０４〜ステップ６０９の処理による別の効果について説明する。なお、以下の説明において、閾値テーブル１７７は、図６に示す状態とし、また、現在、サーバ１５０が処理中のサービス量については、Ａが「３０」、Ｂが「０」、Ｃが「０」であるとする。
【０１１４】
処理対象組織の閾値のみを考慮する場合、組織Ａは、閾値テーブル１７７において設定された閾値７０２より大きくなるため、サーバ１５０は、組織Ａから、閾値７０２以上のリクエストを受け付けない。
【０１１５】
しかし、組織Ｂ及びＣのサービス量は「０」であるため、スレッドに空きがある。そこで、システムの閾値を考慮することによって、サーバ１５０が処理中の全サービス量の合計がシステムの閾値以下の場合に、サーバ１５０が組織Ａからのリクエストを受け付けることによって、スレッドに空きを有効に利用することが可能となる。
【０１１６】
なお、組織Ａの閾値を超えるリクエストが受け付けられた後、組織Ｂ又はＣのサービス量が増加することによってシステム全体のサービス量がシステムの閾値より大きくなった場合、組織間のサービス量を調整するための処理（ステップ６０６〜ステップ６０９）が実行される。したがって、組織の閾値より多くのリクエストが受け付けられた組織Ａのリクエストは受け付けらない。したがって、組織Ａのサービス量は減少していき、組織Ａのサービス量は閾値の範囲内に落ち着く。
【０１１７】
次に、システムの閾値Ｔの設定方法について説明する。
【０１１８】
図８は、本発明の第１の実施形態における各組織の処理中のサービス量の一例を示した図である。
【０１１９】
閾値テーブル１７７が図６に示す値である場合、システムのサービス量は、図８に示す状態で最大となる。つまり、組織の閾値が最も小さい組織Ｃのサービス量が、図６に示すシステムの閾値と同一であり（組織Ｃのサービス量が５０）、他の組織Ａ及びＢが、各々の組織のサービス量が閾値までサービスを受けているときが最大（組織Ａのサービス量が３０、組織Ｂのサービス量が２０）のとき、システムのサービス量が最大となる。
【０１２０】
具体的には、システムの最大サービス量Ｑmaxは、下式で表される。
【０１２１】
Ｑmax＝Ｔ＋ΣＴｉ−ｍｉｎ（ＴＡ、ＴＢ、・・・）        （数１）
【０１２２】
システムの最大サービス量Ｑmaxが上限値１３６に設定された値に収まるようにすれば最もスループットが高くなる。
【０１２３】
ここで、上限値１３６に設定された値をＫとすると、Ｑmax＝Ｋをシステムの閾値Ｔで解いた式は以下のようになる。
【０１２４】
Ｔ＝Ｋ−（ΣＴｉ−ｍｉｎ（ＴＡ、ＴＢｍ、・・・））      （数２）
【０１２５】
第１の実施形態では、（式２）によって算出される値が、システムの閾値Ｔとして閾値テーブル１７７に設定される。
【０１２６】
［第２の実施形態］
第１の実施形態において、システムの閾値Ｔ≒Ｋの場合、サーバ１５０に空きがある（スレッドに空きがある）ときには、リクエストは原則到着順に処理され、当該リクエストに対するサービスが提供される。したがって、システムとしては高スループットを期待する（サーバ１５０のＣＰＵ１６０の利用率の向上を期待する）ことができる。しかし、この場合、特定の組織のリクエストが大量に到着すると、後から到着した他の組織からのリクエストに対するサービスを提供できない可能性がある。
【０１２７】
また、第１の実施形態において、システムの閾値Ｔ≒０の場合、サーバ１５０は、各組織から、各々の組織に設定された閾値までのリクエストを受け付けることができる。すなわち、各組織からのリクエストに対して偏りなくサービスを提供することができる。しかし、リクエストキュー１７５にリクエストが留まる確率が高くなる。そのため、特定の組織からのリクエストしか到着しない場合においては、当該組織に設定された閾値までしかサービスを提供することができず、システムとしてはスループットの低下を招く（サーバ１５０のＣＰＵ１６０の利用率の低下を招く）ことになる。
【０１２８】
そこで、第２の実施形態では、各組織からのリクエストの到着状況に応じて、（１）システムスループットの最大化を図る。（２）各組織間の処理中のサービス量を保証するように、システムの閾値Ｔの値を変更させる。
【０１２９】
具体的には、第２の実施形態では、ＣＰＵ利用率に応じて、システムの閾値Ｔを変更する。
【０１３０】
第２の実施形態の計算機システムの構成は、第１の実施形態と同一であるため説明を省略する。第２の実施形態では、Ｗｅｂブラウザ１０１及び流量制御装置１１０の構成は第１の実施形態と同一であるが、サーバ９００の構成が第１の実施形態と異なる。以下、第１の実施形態との差異を中心に説明する。
【０１３１】
図９は、本発明の第２の実施形態のサーバ９００の構成を示すブロック図である。
【０１３２】
サーバ９００のハードウェア構成は第１の実施形態と同一であるため説明を省略する。
【０１３３】
サーバ９００のメモリ１７０は、新たに、ＣＰＵ利用率監視プログラム９０１、閾値制御プログラム９０２、ＣＰＵ基準値９０３、及びＣＰＵ利用率−サービス量対応テーブル９０４を含む。
【０１３４】
ＣＰＵ利用率監視プログラム９０１は、サーバ９００のＣＰＵ１６０の利用率を監視するプログラムである。ＣＰＵ１６０が、周期的に、ＣＰＵ利用率監視プログラム９０１を実行することによって、ＣＰＵ１６０の利用率を取得する。
【０１３５】
閾値制御プログラム９０２は、ＣＰＵ１６０の利用率に応じて、閾値テーブル１７７におけるシステムの閾値Ｔを変更するプログラムである。閾値制御プログラム９０２によって実行される処理の詳細は、図１０を用いて後述する。
【０１３６】
ＣＰＵ基準値９０３は、後述する閾値制御プログラム９０２によって実行される処理において、ＣＰＵ１６０の利用率を判定する場合に用いられる値である。ＣＰＵ基準値９０３は、予め設定された値であるが、システムの管理者等によって変更することも可能な値である。
【０１３７】
ＣＰＵ利用率−サービス量対応テーブル９０４は、ＣＰＵ１６０の利用率とサーバ１５０が提供するサービス量との対応関係を示すテーブルである。
【０１３８】
図１０は、本発明の第２の実施形態の閾値制御プログラム９０２によって実行される処理を説明するフローチャートである。
【０１３９】
なお、以下で説明する処理は、ＣＰＵ１６０がメモリ１７０に格納されるプログラムを読む出し、読み出されたプログラムを実行することによって実現される。
【０１４０】
ＣＰＵ利用率監視プログラム９０１は、ＣＰＵ１６０の利用率を取得し、ＣＰＵ基準値９０３を参照して、取得されたＣＰＵ１６０の利用率が、ＣＰＵ基準値９０３より低いか否かを判定する（ステップ１００１）。なお、ＣＰＵ１６０の利用率は、ＣＰＵ利用率監視プログラム９０１が実行されることによって得られた値である。
【０１４１】
取得されたＣＰＵ１６０の利用率が、ＣＰＵ基準値９０３より低いと判定された場合、閾値制御プログラム９０２は、システムの閾値Ｔを増加させ（ステップ１００２）、ステップ１００１に戻り同様の処理を実行する。
【０１４２】
取得されたＣＰＵ１６０の利用率が、ＣＰＵ基準値９０３より低いと判定された場合、閾値制御プログラム９０２は、システムの閾値Ｔを減少させ（ステップ１００３）、ステップ１００１に戻り同様の処理を実行する。
【０１４３】
次に、システムの閾値Ｔの変更の方法について説明する。
【０１４４】
図１１は、本発明の第２の実施形態におけるシステムの閾値Ｔの変更方法を説明するための図である。
【０１４５】
図１１において、横軸はシステムの閾値Ｔを示し、縦軸はサーバ１５０が提供する全サービス量（システムのサービス量）を示す。
【０１４６】
以下の説明において、現在の全サービス量をＱ0とし、現在のシステムの閾値をＴ0とする。また、ステップ１００１の判定時に使用されるＣＰＵ基準値９０３に対応する全サービス量をＱ1とする。なお、閾値制御プログラム９０２は、ＣＰＵ利用率−サービス量対応テーブル９０４を参照することによって、ＣＰＵ１６０の利用率から、現在、サーバ１５０が提供するサービス量を知ることができる。なお、閾値制御プログラム９０２は、ＣＰＵ１６０によってメモリ１７０から読み出され、ＣＰＵ１６０によって実行される。
【０１４７】
直線１１０１は、（数１）をプロットしたものである。具体的には、システムの閾値Ｔの最大値をプロットした直線である。
【０１４８】
ステップ１００１において、現在の全サービス量Ｑ0が、ＣＰＵ基準値９０３に対応するサービス量Ｑ1より低いため、閾値制御プログラム９０２は、ステップ１００２に進む。
【０１４９】
ステップ１００２において、閾値制御プログラム９０２は、現在の全サービス量Ｑ0及び閾値Ｔ0が交わった交点１１０３と、サービス量の上限値Ｑmax及びシステムの閾値の上限値Ｋが交わった交点１１０４とを結ぶ直線１１０２を算出する。
【０１５０】
次に、閾値制御プログラム９０２は、直線１１０２に、ＣＰＵ基準値９０３に対応するサービス量Ｑ1を代入し、Ｔ1を算出する。
【０１５１】
閾値制御プログラム９０２は、算出されたシステムの閾値Ｔ1を新たなシステムの閾値Ｔとして設定する。具体的には、閾値テーブル１７７のシステムのエントリの閾値７０２がＴ0からＴ1に変更される。
【０１５２】
前述した方法では、閾値制御プログラム９０２は、算出されたＴ1を新たなシステムの閾値Ｔとしたが、Ｔ0からＴ1の範囲にある値に変更する方法であってもよい。
【０１５３】
なお、ステップ１００３においても、同様の処理によって、システムの閾値Ｔが変更される。
【０１５４】
［第３の実施形態］
第３の実施形態では、計算機システムが複数のサーバを備える点が第１の実施形態と異なる。以下、第１の実施形態との差異を中心に第３の実施形態について説明する。
【０１５５】
図１２は、本発明の第３の実施形態の計算機システムの構成例を示すブロック図である。
【０１５６】
第３の実施形態の計算機システムは、複数のサーバ１２０２を備え、また、流量制御装置１１０と複数のサーバ１２０２との間にロードバランサ１２０１を備える。図１２に示す例では、計算機システムは、サーバ１〜サーバｎまでのｎ個のサーバを備える。
【０１５７】
ロードバランサ１２０１は、サーバ１２０２が受け付けるリクエスト数を制御するための機能を備える。具体的には、ロードバランサ１２０１は、少なくとも、要求元識別プログラム１７１、スレッド−要求元対応テーブル１７６、閾値テーブル１７７、及び最後にチェックした組織識別子１７８を格納する。
【０１５８】
第３の実施形態では、サーバ１２０２がリクエストの受け付けを制御するための機能を備える必要はない。
【０１５９】
ロードバランサ１２０１は、第１の実施形態と同様に、各組織に提供されるサービス量に応じて、リクエストを取得する。さらに、ロードバランサ１２０１は、各サーバ１２０２に取得されたリクエストを割り振る。割り振る方法としては、ラウンドロビン方式、及び負荷の最も低いサーバ１２０２に割り振る方式が考えられる。
【０１６０】
本発明の一形態によれば、システム及び各組織の閾値に基づいて、サーバ１５０がリクエストを受け付けるか否かを判定することによって、組織間のサービス量のバランスをとることができる。したがって、ある組織からのリクエスト量が多過ぎるために、サーバ１５０が、他の組織のリクエストを処理できないという状況を解消できる。
【符号の説明】
【０１６１】
１０１  Ｗｅｂブラウザ
１１０  流量制御装置
１２０  ＣＰＵ
１３０  メモリ
１３１  リクエスト取得プログラム
１３２  リクエスト数確認プログラム
１３３  リクエスト投入プログラム
１３４  リクエスト数更新プログラム
１３５  リクエスト数
１３６  上限値
１４０  通信部
１５０  サーバ
１６０  ＣＰＵ
１７０  メモリ
１７１  要求元識別プログラム
１７２  キュー追加プログラム
１７３  リクエスト取得プログラム
１７４  リクエスト処理プログラム
１７５  リクエストキュー
１７６  スレッド−要求元対応テーブル
１７７  閾値テーブル
１７８  最後にチェックした組織識別子
１７９  スレッドプール
１８０  通信部
４０１  スレッド番号
４０２  処理中の要求元
７０１  組織
７０２  閾値
９００  サーバ
９０１  ＣＰＵ利用率監視プログラム
９０２  閾値制御プログラム
９０３  ＣＰＵ基準値
９０４  ＣＰＵ利用率−サービス量対応テーブル
１１０１  直線
１１０２  直線
１１０３  交点
１１０４  交点
１２０１  ロードバランサ
１２０２  サーバ
【図１】
2011070435.tif 000003
【図２】
2011070435.tif 000004
【図３】
2011070435.tif 000005
【図４】
2011070435.tif 000006
【図５】
2011070435.tif 000007
【図６】
2011070435.tif 000008
【図７】
2011070435.tif 000009
【図８】
2011070435.tif 000010
【図９】
2011070435.tif 000011
【図１０】
2011070435.tif 000012
【図１１】
2011070435.tif 000013
【図１２】
2011070435.tif 000014