JP2011070435A - 計算機システム、リクエスト処理方法及びサーバ装置 - Google Patents

Abstract

【課題】ＳａａＳアプリケーションにおいて、ある組織のユーザからのリクエスト量が多過ぎるために、他の組織のユーザのリクエストを処理できないという状況が発生する。
【解決手段】第１の計算機と、第１の計算機から送信されるリクエストを受け付ける第２の計算機とを備える計算機システムであって、第２の計算機は、第１の計算機からリクエストを受信した場合、受け付けたリクエストの総数が第１の閾値以下か否かを判定し、受け付けたリクエストの総数が第１の閾値より大きいと判定された場合、第１の計算機から受信したリクエストの送信元のユーザが所属するグループを特定し、特定されたグループから受け付けたリクエスト数が第２の閾値以下か否かを判定し、特定されたグループから受け付けたリクエスト数が第２の閾値以下と判定された場合、特定されたグループからのリクエストを受け付ける。
【選択図】図１

Description

本発明は、一つのシステムを複数の組織が利用する形態であるマルチテナント対応システム構成方法に関し、組織間で偏りなくリクエストを処理するための技術に関する。

これまでクライアント装置上で実行するデスクトップアプリケーションとして実装されてきた企業内の業務システムの多くが、Ｗｅｂ上のサービスＳａａＳ（Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）として提供されはじめている。

ＳａａＳの特徴としてマルチテナントが挙げられる。マルチテナントとは、一つのシステムを複数の組織が利用する形態のことである。ここで、組織とは、複数のユーザから構成されるグループのことを示す。

マルチテナントでは、組織ごとのデータの管理が課題となり、当該課題を解決するための方法が考えられている（例えば、特許文献１参照）。

特表２００９−５１８７１３号公報

特許文献１には、マルチテナントデータベース環境の構築方法に関する技術が開示されており、一つのシステムを複数の組織のユーザが利用することが可能となる。

しかし、特許文献１に開示された技術には、組織間のサービスバランスに関する技術が開示されていない。したがって、ある組織からのリクエスト量が多過ぎるために、サービスを提供するシステムが、他の組織のリクエストを処理できないという状況が発生する。

本発明の代表的な一例を示せば以下の通りである。すなわち、一以上のクライアント装置からリクエストを受け付ける第１の計算機と、前記第１の計算機から送信される前記リクエストを受け付ける第２の計算機とを備える計算機システムであって、前記第１の計算機は、第１のプロセッサと、前記第１のプロセッサに接続される第１のメモリと、前記第２の計算機と通信するための第１の通信部を備え、前記第２の計算機は、第２のプロセッサと、前記第２のプロセッサに接続され、前記第２の計算機に設定される第１の閾値及び前記クライアント装置を操作するユーザが所属するグループごとに設定される第２の閾値が格納される第２のメモリと、前記第１の計算機と通信するための第２の通信部を備え、前記第２の計算機は、前記第１の計算機からリクエストを受信した場合、前記第１の計算機から受け付けたリクエストの総数を算出して、前記第１の計算機から受け付けたリクエストの総数が前記第１の閾値以下か否かを判定し、前記第１の計算機から受け付けたリクエストの総数が前記第１の閾値より大きいと判定された場合、前記第１の計算機から受信したリクエストの送信元のユーザが所属する前記グループを特定し、前記特定されたグループから受け付けたリクエスト数を算出し、前記特定されたグループから受け付けたリクエスト数が前記第２の閾値以下か否かを判定し、前記特定されたグループから受け付けたリクエスト数が前記第２の閾値以下と判定された場合、前記特定されたグループからのリクエストを受け付けることを特徴とする。

本発明によれば、任意のグループにおけるリクエスト数が少ない場合は、当該グループのユーザのリクエストを優先的に受け付けることができる。したがって、特定のグループのユーザからのリクエスト数が多いために、他のグループのユーザからのリクエストを受け付けできない状態を回避することができる。

本発明の第１の実施形態の計算機システムの構成例を示すブロック図である。 本発明の第１の実施形態の流量制御装置がＷｅｂブラウザからリクエストを受け付けた場合に実行する処理を説明するフローチャートである。 本発明の第１の実施形態のサーバのスレッドが実行する処理を説明するフローチャートである。 本発明の第１の実施形態のスレッド−要求元対応テーブルの一例を示す説明図である。 本発明の第１の実施形態のステップ３０３におけるスレッド−要求元対応テーブルの変化を説明する図である。 本発明の第１の実施形態の閾値テーブルの一例を示す説明図である。 本発明の第１の実施形態のリクエスト取得プログラムが実行するステップ３０１における処理の詳細を説明するフローチャートである。 本発明の第１の実施形態における各組織の処理中のサービス量の一例を示した図である。 本発明の第２の実施形態のサーバの構成を示すブロック図である。 本発明の第２の実施形態の閾値制御プログラムによって実行される処理を説明するフローチャートである。 本発明の第２の実施形態におけるシステムの閾値Ｔの変更方法を説明するための図である。 本発明の第３の実施形態の計算機システムの構成例を示すブロック図である。

［第１の実施形態］
以下、図１から図７を用いて、本発明の第１の実施形態を説明する。

図１は、本発明の第１の実施形態の計算機システムの構成例を示すブロック図である。

計算機システムは、情報処理装置１０１、１１０、１５０を備える。情報処理装置１０１と情報処理装置１１０とはインターネットを介して接続され、情報処理装置１１０と情報処理装置１５０とはＬＡＮを介して接続される。なお、情報処理装置１０１、１１０、１５０の接続方式は、これらに限定されない。

情報処理装置１０１は、ＣＰＵ（図示省略）、メモリ（図示省略）、記憶装置（図示省略）、及び通信部（図示省略）を備える。

メモリ（図示省略）にはＷｅｂブラウザが格納され、ＣＰＵ（図示省略）によって実行される。記憶装置（図示省略）は、ＣＰＵ（図示省略）が処理を実行するときに必要となる情報を格納する。通信部（図示省略）は、インターネットを介して情報処理装置１１０と接続する。

本実施形態において、計算機システムは、複数のユーザを一つのグループとして管理している。以下、当該グループを組織と呼ぶ。任意の組織に所属するユーザは、Ｗｅｂブラウザを用いて、情報処理装置１１０にリクエストを送信する。

以下、Ｗｅｂブラウザを格納する情報処理装置１０１をＷｅｂブラウザ１０１と呼ぶ。また、リクエストを送信するユーザが所属する組織を要求元とも呼ぶ。

情報処理装置１１０は、ネットワークを介してＷｅｂブラウザ１０１からリクエストを受信し、現在処理されているリクエストの数に応じて、情報処理装置１５０に受信したリクエストを送信する。以下、情報処理装置１１０を、流量制御装置１１０と呼ぶ。なお、流量制御装置１１０が実行する処理の詳細については、図２を用いて後述する。

流量制御装置１１０はＣＰＵ１２０、メモリ１３０、通信部１４０、及び記憶装置（図示省略）を備える。

ＣＰＵ１２０は、メモリ１３０上に展開されるプログラムを実行する。

記憶装置（図示省略）は、ＣＰＵ１２０が処理を実行するために必要となる情報を格納する。記憶装置（図示省略）は、例えば、ハードディスク等が考えられる。

メモリ１３０は、流量制御装置１１０が備える機能を実現するために必要となるプログラム、及び情報を格納する。メモリ１３０上に展開されたプログラムはＣＰＵ１２０によって実行される。

メモリ１３０は、リクエスト取得プログラム１３１、リクエスト数確認プログラム１３２、リクエスト投入プログラム１３３、リクエスト数更新プログラム１３４、リクエスト数１３５、及び上限値１３６を格納する。

リクエスト取得プログラム１３１は、Ｗｅｂブラウザ１０１からリクエストを取得するプログラムである。リクエスト数確認プログラム１３２は、リクエスト数１３５を確認するプログラムである。リクエスト投入プログラム１３３は、情報処理装置１５０にリクエストを投入（送信）するプログラムである。リクエスト数更新プログラム１３４は、リクエスト数１３５を更新するプログラムである。

また、リクエスト数１３５は、情報処理装置１５０に投入（送信）されたリクエストの数を示す。メモリ１３０は、パラメータ値としてリクエスト数１３５を格納する。上限値１３６は、流量制御装置１１０が受け付けることが可能なリクエストの数を示す。つまり、流量制御装置１１０は、上限値１３６より多い数のリクエストの受け付けを拒否する。メモリ１３０は、パラメータ値として上限値１３６を格納する。

なお、本実施形態において、上限値１３６は、予め設定された値であるが、計算機システムの管理者等によって、変更可能である。

通信部１４０は、ＬＡＮを介して情報処理装置１５０と接続する。

なお、流量制御装置１１０は、プロキシサーバとして動作してもよい。また、流量制御装置１１０が備える機能を他の装置、例えば、情報処理装置１５０が備えてもよい。

情報処理装置１５０は、ネットワークを介して流量制御装置１１０からリクエストを受信し、受信したリクエストに対応するサービスを提供する。本実施形態の情報処理装置１５０は、各組織に提供されているサービス量及び提供されている全サービス量に基づいて、リクエストを受け付けるか否かを判定する。以下、情報処理装置１５０を、サーバ１５０と呼ぶ。

サーバ１５０は、ＣＰＵ１６０、メモリ１７０、通信部１８０、及び記憶装置（図示省略）を備える。

ＣＰＵ１６０は、メモリ１７０上に展開されるプログラムを実行する。

記憶装置（図示省略）は、ＣＰＵ１６０が処理を実行するために必要となる情報を格納する。記憶装置（図示省略）は、例えば、ハードディスク等が考えられる。

メモリ１７０は、流量制御装置１１０が備える機能を実現するために必要となるプログラム、及び情報を格納する。メモリ１３０上に展開されたプログラムはＣＰＵ１２０によって実行される。

メモリ１７０は、要求元識別プログラム１７１、キュー追加プログラム１７２、リクエスト取得プログラム１７３、リクエスト処理プログラム１７４、リクエストキュー１７５、スレッド−要求元対応テーブル１７６、閾値テーブル１７７、最後にチェックした組織識別子１７８、及びスレッドプール１７９を格納する。

要求元識別プログラム１７１は、流量制御装置１１０から投入されたリクエストの要求元を識別するプログラムである。キュー追加プログラム１７２は、流量制御装置１１０から投入されたリクエストをリクエストキュー１７５に追加するプログラムである。リクエスト取得プログラム１７３は、閾値テーブル１７７を参照して、リクエストキュー１７５に格納されるリクエストを取得するプログラムである。リクエスト処理プログラム１７４は、リクエストキュー１７５から取得されたリクエストに対応する処理を実行するプログラムである。

リクエストキュー１７５は、流量制御装置１１０から受信したリクエストを格納する。

スレッドプール１７９は、流量制御装置１１０から受信したリクエストに対応する処理を実行するスレッドを格納する。本実施形態においては、一つのリクエストが一つのスレッドに対応し、当該スレッドによって、対応するリクエストの処理が実行される。図１に示す例では、スレッドプール１７９には、スレッド１〜スレッドｎが格納される。

本実施形態において、スレッド数がサーバ１５０の受け付け可能なリクエスト数となり、スレッド数が多いほどサーバ１５０の処理能力は高いことを意味する。

スレッド−要求元対応テーブル１７６は、スレッドと、当該スレッドに対応するリクエストの要求元との対応関係を格納する。スレッド−要求元対応テーブル１７６は、サーバ１５０が現在処理中のサービス量（リクエスト数）を計測するために用いられる。

閾値テーブル１７７は、システム全体のリクエスト数の閾値、及び組織ごとのリクエスト数の閾値を定義するテーブルである。システム全体のリクエスト数の閾値は、組織ごとのリクエスト数の閾値を判断するか否かを判定するための閾値である。また、組織ごとのリクエスト数の閾値は、各組織からリクエストを受け付け可能か否かを判定するための閾値である。閾値テーブル１７７の詳細については、図６を用いて後述する。また、これらの閾値を用いた処理の詳細は、図７を用いて後述する。

最後にチェックした組織識別子１７８は、サーバ１５０が後述する処理（図６参照）において、最後に確認した組織を識別するための識別子である。

図２は、本発明の第１の実施形態の流量制御装置１１０がＷｅｂブラウザ１０１からリクエストを受け付けた場合に実行する処理を説明するフローチャートである。

なお、以下で説明する処理は、ＣＰＵ１２０がメモリ１３０に格納されるプログラムを読み出し、読み出されたプログラムを実行することによって実現される。

リクエスト取得プログラム１３１は、Ｗｅｂブラウザ１０１から送信されるリクエストの到着を監視する（ステップ２０１）。なお、リクエスト取得プログラム１３１は、Ｗｅｂブラウザ１０１から送信されるリクエストの到着を常時監視してもよいし、周期的に監視してもよい。

リクエスト取得プログラム１３１がＷｅｂブラウザ１０１からリクエストの到着を検出した場合、リクエスト数確認プログラム１３２は、リクエスト数１３５及び上限値１３６を参照し、リクエスト数１３５が上限値１３６以下であるか否かを判定する（ステップ２０２）。

リクエスト数１３５が上限値１３６より大きいと判定された場合、流量制御装置１１０は、Ｗｅｂブラウザ１０１から送信されたリクエストの受け付けを拒否する。つまり、Ｗｅｂブラウザ１０１から送信されたリクエストが破棄される。流量制御装置１１０は、Ｗｅｂブラウザ１０１から送信されたリクエストを破棄した後に、ステップ２０１に戻り、同様の処理を実行する。

リクエスト数１３５が上限値１３６以下であると判定された場合、リクエスト数更新プログラム１３４は、リクエスト数１３５の値を「１」増加する（ステップ２０３）。

また、リクエスト投入プログラム１３３は、Ｗｅｂブラウザ１０１から送信されたリクエストをサーバ１５０に投入する（ステップ２０４）。

サーバ１５０から、投入されたリクエストに対するレスポンスが返ってきた場合、リクエスト数更新プログラム１３４は、リクエスト数１３５の値を「１」減少させる（ステップ２０５）。

以下、図２において説明した処理の具体例について説明する。

上限値１３６が「１００」、及びリクエスト数１３５が「９０」の場合について説明する。この場合、Ｗｅｂブラウザ１０１からリクエストの到着を検出した流量制御装置１１０は、リクエスト数１３５と上限値１３６とを参照して、リクエスト数１３５が上限値１３６以下であると判定する。

次に、リクエスト数更新プログラム１３４がリクエスト数１３５を更新（「１」増加）した後、リクエスト投入プログラム１３３がＷｅｂブラウザ１０１から受信したリクエストをサーバ１５０に投入する。

投入されたリクエストに対するレスポンスがサーバ１５０から返ってきた場合、リクエスト数更新プログラム１３４は、リクエスト数１３５を「１」減少する。

なお、リクエスト数１３５が「１００」であると判定された場合、流量制御装置１１０は、Ｗｅｂブラウザ１０１から到着したリクエストを破棄し、次のリクエストの到着を監視する。

流量制御装置１１０は、リクエスト数１３５及び上限値１３６に基づいて、当該リクエストをサーバ１５０に投入するか否かを判定する。

図３は、本発明の第１の実施形態のサーバ１５０のスレッドが実行する処理を説明するフローチャートである。スレッドは、周期的に以下で説明する処理を実行する。

なお、以下で説明する処理は、ＣＰＵ１６０がメモリ１７０に格納されるプログラムを読む出し、読み出されたプログラムを実行することによって実現される。

まず、リクエスト取得プログラム１７３が、閾値テーブル１７７を参照して、リクエストキュー１７５からリクエストを取得するための処理を実行する（ステップ３０１）。リクエスト取得プログラム１７３が実行する処理の詳細は、図７を用いて後述する。

リクエスト取得プログラム１７３は、リクエストを取得できたか否かを判定する（ステップ３０２）。

リクエストを取得できないと判定された場合、リクエスト取得プログラム１７３は、所定時間スリープした後（ステップ３０６）、再びリクエストを取得するための処理を実行する。

リクエストを取得できたと判定された場合、要求元識別プログラム１７１は、取得されたリクエストの要求元を特定する。次に、リクエスト取得プログラム１７３は、特定された要求元に基づいて、スレッド−要求元対応テーブル１７６を更新する（ステップ３０３）。

具体的には、リクエスト取得プログラム１７３は、スレッド−要求元対応テーブル１７６の取得されたリクエストに対応するスレッドのエントリに、特定された要求元を追加する。

なお、本実施形態において、要求元から送信されるリクエストには、要求元（リクエストを送信するユーザが所属する組織）を識別するための識別子が含まれる。要求元識別プログラム１７１は、当該識別子を参照することによって、取得されたリクエストの要求元を判別することができる。

また、ユーザがＷｅｂブラウザ１０１にログイン時に用いた情報（ログイン情報）、例えば、ユーザＩＤ、をサーバ１５０が取得し、要求元識別プログラム１７１が、取得された情報に基づいて、要求元を特定してもよい。この場合、サーバ１５０が組織と組織に所属するユーザＩＤとの対応関係を管理するテーブルを備え、要求元識別プログラム１７１が、当該テーブルを参照して、ユーザＩＤから取得されたリクエストの要求元を判別できる。

スレッドプール１７９のスレッドによって、取得されたリクエストが処理される（ステップ３０４）。具体的には、スレッド上でリクエスト処理プログラム１７４が実行され、リクエストが処理される。

リクエストの処理が終了した後、スレッドは、スレッド−要求元対応テーブル１７６の当該スレッドに対応するエントリから要求元を削除し（ステップ３０５）、ステップ３０１に戻り同様の処理（ステップ３０１〜３０６）を実行する。

図４は、本発明の第１の実施形態のスレッド−要求元対応テーブル１７６の一例を示す説明図である。

スレッド−要求元対応テーブル１７６は、スレッド番号４０１と処理中の要求元４０２とを含む。

スレッド番号４０１は、スレッドプール１７９に格納されるスレッドを識別するための識別子である。処理中の要求元４０２は、スレッドに対応するリクエストの要求元を識別するための識別子である。なお、スレッドに対応するリクエストが無い場合、処理中の要求元４０２は空白となる。この場合、スレッドプール１７９に格納されるスレッドは待機状態となる。

以下、図５を用いて、図３のステップ３０３における処理の具体例を説明する。

図５は、本発明の第１の実施形態のステップ３０３におけるスレッド−要求元対応テーブル１７６の変化を説明する図である。

図５に示す例では、スレッド番号４０１が「２」のスレッドは、待機状態となっている。

ステップ３０２において、リクエストが取得されたと判定された場合、要求元識別プログラム１７１が、取得されたリクエストの要求元を特定する。ここでは、取得されたリクエストの要求元は「Ｂ」であると特定される。なお、要求元識別プログラム１７１は、ＣＰＵ１６０によってメモリ１７０から読み出され、ＣＰＵ１６０によって実行される。

次に、リクエスト取得プログラム１７３は、スレッド−要求元対応テーブル１７６を参照して、待機状態のスレッドを検索し、スレッド番号４０１が「２」のスレッドが待機状態であることを検出する。なお、リクエスト取得プログラム１７３は、ＣＰＵ１６０によってメモリ１７０から読み出され、ＣＰＵ１６０によって実行される。

リクエスト取得プログラム１７３は、スレッド番号４０１が「２」のエントリの処理中の要求元４０２に「Ｂ」を追加する。

これによって、サーバ１５０は、当該サーバ１５０が処理している要求元のリクエストの数を把握することができる。

図６は、本発明の第１の実施形態の閾値テーブル１７７の一例を示す説明図である。

閾値テーブル１７７は、組織７０１と閾値７０２とを含む。

組織７０１は、リクエストの要求元のユーザが所属する組織を識別するための識別子である。なお、サーバ１５０に対応するエントリの組織７０１には、サーバ１５０を示す識別子「システム」が格納される。閾値７０２は、組織７０１に対応する組織のリクエスト数の閾値を示す。

本実施形態では、閾値７０２に格納された閾値に基づいて後述する処理（図７参照）が実行される。

図６に示すように、閾値テーブル１７７は、各組織の閾値と、システム（サーバ１５０）の閾値とを格納する。具体的には、組織Ａの閾値は「３０」、組織Ｂの閾値は「２０」、組織Ｃの閾値は「１０」、及びシステム（サーバ１５０）の閾値は「５０」である。

次に、ステップ３０１における処理について説明する。

図７は、本発明の第１の実施形態のリクエスト取得プログラム１７３が実行するステップ３０１における処理の詳細を説明するフローチャートである。リクエスト取得プログラム１７３は、サーバ１５０がリクエストを取得する度に以下で説明する処理を実行する。

なお、以下で説明する処理は、ＣＰＵ１６０がメモリ１７０に格納されるプログラムを読む出し、読み出されたプログラムを実行することによって実現される。

リクエスト取得プログラム１７３は、最後にチェックした組織識別子１７８を参照し、最後にチェックした組織識別子１７８に示された組織の次の組織から以下の処理を開始する（ステップ６０１）。以下、ステップ６０１において、処理の対象となる組織を処理対象組織とも呼ぶ。

なお、リクエスト取得プログラム１７３は、閾値テーブル１７７、及び最後にチェックした組織識別子１７８を参照することによって、処理対象組織が分かる。

例えば、前回実行されたステップ３０１の処理において、「組織Ｂ」で処理が終了した場合、最後にチェックした組織識別子１７８には、「組織Ｂ」が格納され、当該最後にチェックした組織識別子１７８を参照したリクエスト取得プログラム１７３は、「組織Ｃ」から処理を開始する。なお、各組織における処理の順番の決定方法は、予めサーバ１５０に設定された各組織の処理の順番に基づいて決定する方法、及び、サーバ１５０が格納する、各組織の処理の順番を規定するテーブル（図示省略）に基づいて決定する方法が考えられる。

毎回、同じ組織から処理が開始された場合当該組織のリクエストが優先的に処理されるが、ステップ６０１の処理によって、各組織のリクエストを均等に処理できる。

リクエスト取得プログラム１７３は、リクエストキュー１７５に処理対象組織のリクエストが格納されるか否かを判定する（ステップ６０２）。

リクエストキュー１７５に処理対象組織のリクエストが格納されないと判定された場合、リクエスト取得プログラム１７３は、流量制御装置１１０にｎｕｌｌを返す（ステップ６０３）。

リクエストキュー１７５に処理対象組織のリクエストが格納されると判定された場合、リクエスト取得プログラム１７３は、サーバ１５０が処理する全てのサービス量（総サービス量）がシステム全体（サーバ１５０）の閾値７０２以下であるか否かを判定する（ステップ６０４）。

具体的には、リクエスト取得プログラム１７３は、スレッド−要求元対応テーブル１７６を参照して、システム（サーバ１５０）全体の総サービス量Ｑ（ｔ）を算出する。次に、リクエスト取得プログラム１７３は、閾値テーブル１７７を参照して、算出された総サービス量Ｑ（ｔ）がシステムの閾値７０２以下であるか否を判定する。以下、システムの閾値７０２をシステムの閾値Ｔとも呼ぶ。

ステップ６０４における処理は、組織間のサービス量を調整する必要があるか否かを判定するための処理である。総サービス量Ｑ（ｔ）がシステムの閾値以下である場合、リクエスト取得プログラム１７３は、組織間のサービス量を調整する必要がないと判定する。総サービス量Ｑ（ｔ）がシステムの閾値より大きい場合、リクエスト取得プログラム１７３は、各組織間のサービス量を調整する必要がある判定し、ステップ６０６以下の処理を開始する。

なお、総サービス量Ｑ（ｔ）の算出方法としては、処理中の要求元４０２に格納された、全ての組織の数を足し合わせる方法が考えられる。例えば、図４に示す例では、総サービス量Ｑ（ｔ）は、「３」と算出される。

総サービス量Ｑ（ｔ）がシステムの閾値Ｔ以下であると判定された場合、リクエスト取得プログラム１７３は、リクエストキュー１７５からリクエストを取得する（ステップ６０５）。

当該取得されたリクエストは、リクエスト処理プログラム１７４によって処理され、当該リクエストに対するレスポンスが流量制御装置１１０に送信される。また、リクエスト取得プログラム１７３は、最後にチェックした組織識別子１７８を当該処理対象組織の識別子に更新する。

総サービス量Ｑ（ｔ）がシステムの閾値Ｔより大きいと判定された場合、リクエスト取得プログラム１７３は、組織間のサービス量を調整するための処理を開始する。

まず、リクエスト取得プログラム１７３は、処理対象組織のサービス量が当該処理対象組織の閾値７０２以下であるか否かを判定する（ステップ６０６）。

具体的には、リクエスト取得プログラム１７３は、スレッド−要求元対応テーブル１７６を参照して、処理対象組織のサービス量Ｑ_i（ｔ）を算出する。次に、リクエスト取得プログラム１７３は、閾値テーブル１７７を参照して、算出された処理対象組織のサービス量Ｑ_i（ｔ）が当該処理対象組織の閾値７０２以下であるか否を判定する。ここで、ｉは、組織Ａ又はＢなどの処理対象組織を識別するための添え字であり、組織の数だけ存在する。以下、処理対象組織の閾値７０２を処理対象組織の閾値Ｔ_iとも呼ぶ。

なお、処理対象組織のサービス量Ｑ_i（ｔ）の算出方法としては、処理中の要求元４０２に格納された、処理対象組織に対応する識別子の数を足し合わせる方法が考えられる。例えば、図４に示す例において、処理対象組織が「Ａ」である場合、処理対象組織のサービス量Ｑ_A（ｔ）は、「２」と算出される。

処理対象組織のサービス量が当該処理対象組織の閾値以下であると判定された場合、リクエスト取得プログラム１７３は、リクエストキュー１７５からリクエストを取得する（ステップ６０７）。

当該取得されたリクエストは、リクエスト処理プログラム１７４によって処理され、当該リクエストに対するレスポンスが流量制御装置１１０に送信される。また、リクエスト取得プログラム１７３は、最後にチェックした組織識別子１７８を当該処理対象組織の識別子に更新する。

処理対象組織のサービス量が当該処理対象組織の閾値より大きいと判定された場合、リクエスト取得プログラム１７３は、リクエストキュー１７５に処理されていない組織のリクエストがあるか否かを判定する（ステップ６０８）。つまり、当該処理対象組織のサービス量が集中していることを示す。したがって、当該処理対象組織のサービス量を調整するため、当該処理対象組織のリクエストは取得されない。

リクエストキュー１７５に処理されていない組織のリクエストがあると判定された場合、リクエスト取得プログラム１７３は、ステップ６０６に戻り同様の処理を実行する。

リクエストキュー１７５に処理されていない組織のリクエストがないと判定された場合、リクエスト取得プログラム１７３は、流量制御装置１１０にｎｕｌｌを返す（ステップ６０９）。

図７のステップ６０４〜ステップ６０９の処理による効果について説明する。

本実施形態では、まず、システム全体の総サービス量がシステムの閾値７０２以下であるか否かが判定される（ステップ６０４）。

システム全体の総サービス量がシステムのリクエスト数の閾値７０２以下であれば、リクエスト取得プログラム１７３がリクエストキューからリクエストを取得し（ステップ６０５）、リクエスト処理プログラム１７４によって、当該リクエストに対応するサービスが処理対象組織に提供される。つまり、組織間のサービス量の調整は実行されない。

一方、システム全体の総サービス量がシステムのリクエスト数の閾値７０２より大きい場合、処理中の組織ごとのサービス量に応じて、リクエストを受け付けるか否かを判定するための処理（ステップ６０６〜ステップ６０９）が実行される。つまり、組織間のサービス量を調整するための処理が実行される。

従来は、システム全体の総サービス量が一定以上であればリクエストの受け付けを拒否していたため、組織間のサービス量が考慮されることなく、リクエストの受け付けが拒否されていた。したがって、組織間にサービス量の偏りが生じる原因となっていた。

しかし、本実施形態では、システム全体の総サービス量がシステムの閾値７０２より大きいと判定されたことを契機に、組織毎のサービス量に基づいて、受け付けるリクエスト数を調整するための処理（ステップ６０６〜ステップ６０９）が実行される。つまり、組織間のサービス量の偏りを考慮して、リクエストを受け付けるか否かの処理が実行される。これによって、組織間のサービス量の偏りを解消することが可能となる。

したがって、サービス量が少ない組織からのリクエストを優先的に処理することができる。

また、ステップ６０４〜ステップ６０９の処理による別の効果について説明する。なお、以下の説明において、閾値テーブル１７７は、図６に示す状態とし、また、現在、サーバ１５０が処理中のサービス量については、Ａが「３０」、Ｂが「０」、Ｃが「０」であるとする。

処理対象組織の閾値のみを考慮する場合、組織Ａは、閾値テーブル１７７において設定された閾値７０２より大きくなるため、サーバ１５０は、組織Ａから、閾値７０２以上のリクエストを受け付けない。

しかし、組織Ｂ及びＣのサービス量は「０」であるため、スレッドに空きがある。そこで、システムの閾値を考慮することによって、サーバ１５０が処理中の全サービス量の合計がシステムの閾値以下の場合に、サーバ１５０が組織Ａからのリクエストを受け付けることによって、スレッドに空きを有効に利用することが可能となる。

なお、組織Ａの閾値を超えるリクエストが受け付けられた後、組織Ｂ又はＣのサービス量が増加することによってシステム全体のサービス量がシステムの閾値より大きくなった場合、組織間のサービス量を調整するための処理（ステップ６０６〜ステップ６０９）が実行される。したがって、組織の閾値より多くのリクエストが受け付けられた組織Ａのリクエストは受け付けらない。したがって、組織Ａのサービス量は減少していき、組織Ａのサービス量は閾値の範囲内に落ち着く。

次に、システムの閾値Ｔの設定方法について説明する。

図８は、本発明の第１の実施形態における各組織の処理中のサービス量の一例を示した図である。

閾値テーブル１７７が図６に示す値である場合、システムのサービス量は、図８に示す状態で最大となる。つまり、組織の閾値が最も小さい組織Ｃのサービス量が、図６に示すシステムの閾値と同一であり（組織Ｃのサービス量が５０）、他の組織Ａ及びＢが、各々の組織のサービス量が閾値までサービスを受けているときが最大（組織Ａのサービス量が３０、組織Ｂのサービス量が２０）のとき、システムのサービス量が最大となる。

具体的には、システムの最大サービス量Ｑ_maxは、下式で表される。

Ｑ_max＝Ｔ＋ΣＴｉ−ｍｉｎ（ＴＡ、ＴＢ、・・・） （数１）

システムの最大サービス量Ｑ_maxが上限値１３６に設定された値に収まるようにすれば最もスループットが高くなる。

ここで、上限値１３６に設定された値をＫとすると、Ｑ_max＝Ｋをシステムの閾値Ｔで解いた式は以下のようになる。

Ｔ＝Ｋ−（ΣＴｉ−ｍｉｎ（ＴＡ、ＴＢｍ、・・・）） （数２）

第１の実施形態では、（式２）によって算出される値が、システムの閾値Ｔとして閾値テーブル１７７に設定される。

［第２の実施形態］
第１の実施形態において、システムの閾値Ｔ≒Ｋの場合、サーバ１５０に空きがある（スレッドに空きがある）ときには、リクエストは原則到着順に処理され、当該リクエストに対するサービスが提供される。したがって、システムとしては高スループットを期待する（サーバ１５０のＣＰＵ１６０の利用率の向上を期待する）ことができる。しかし、この場合、特定の組織のリクエストが大量に到着すると、後から到着した他の組織からのリクエストに対するサービスを提供できない可能性がある。

また、第１の実施形態において、システムの閾値Ｔ≒０の場合、サーバ１５０は、各組織から、各々の組織に設定された閾値までのリクエストを受け付けることができる。すなわち、各組織からのリクエストに対して偏りなくサービスを提供することができる。しかし、リクエストキュー１７５にリクエストが留まる確率が高くなる。そのため、特定の組織からのリクエストしか到着しない場合においては、当該組織に設定された閾値までしかサービスを提供することができず、システムとしてはスループットの低下を招く（サーバ１５０のＣＰＵ１６０の利用率の低下を招く）ことになる。

そこで、第２の実施形態では、各組織からのリクエストの到着状況に応じて、（１）システムスループットの最大化を図る。（２）各組織間の処理中のサービス量を保証するように、システムの閾値Ｔの値を変更させる。

具体的には、第２の実施形態では、ＣＰＵ利用率に応じて、システムの閾値Ｔを変更する。

第２の実施形態の計算機システムの構成は、第１の実施形態と同一であるため説明を省略する。第２の実施形態では、Ｗｅｂブラウザ１０１及び流量制御装置１１０の構成は第１の実施形態と同一であるが、サーバ９００の構成が第１の実施形態と異なる。以下、第１の実施形態との差異を中心に説明する。

図９は、本発明の第２の実施形態のサーバ９００の構成を示すブロック図である。

サーバ９００のハードウェア構成は第１の実施形態と同一であるため説明を省略する。

サーバ９００のメモリ１７０は、新たに、ＣＰＵ利用率監視プログラム９０１、閾値制御プログラム９０２、ＣＰＵ基準値９０３、及びＣＰＵ利用率−サービス量対応テーブル９０４を含む。

ＣＰＵ利用率監視プログラム９０１は、サーバ９００のＣＰＵ１６０の利用率を監視するプログラムである。ＣＰＵ１６０が、周期的に、ＣＰＵ利用率監視プログラム９０１を実行することによって、ＣＰＵ１６０の利用率を取得する。

閾値制御プログラム９０２は、ＣＰＵ１６０の利用率に応じて、閾値テーブル１７７におけるシステムの閾値Ｔを変更するプログラムである。閾値制御プログラム９０２によって実行される処理の詳細は、図１０を用いて後述する。

ＣＰＵ基準値９０３は、後述する閾値制御プログラム９０２によって実行される処理において、ＣＰＵ１６０の利用率を判定する場合に用いられる値である。ＣＰＵ基準値９０３は、予め設定された値であるが、システムの管理者等によって変更することも可能な値である。

ＣＰＵ利用率−サービス量対応テーブル９０４は、ＣＰＵ１６０の利用率とサーバ１５０が提供するサービス量との対応関係を示すテーブルである。

図１０は、本発明の第２の実施形態の閾値制御プログラム９０２によって実行される処理を説明するフローチャートである。

なお、以下で説明する処理は、ＣＰＵ１６０がメモリ１７０に格納されるプログラムを読む出し、読み出されたプログラムを実行することによって実現される。

ＣＰＵ利用率監視プログラム９０１は、ＣＰＵ１６０の利用率を取得し、ＣＰＵ基準値９０３を参照して、取得されたＣＰＵ１６０の利用率が、ＣＰＵ基準値９０３より低いか否かを判定する（ステップ１００１）。なお、ＣＰＵ１６０の利用率は、ＣＰＵ利用率監視プログラム９０１が実行されることによって得られた値である。

取得されたＣＰＵ１６０の利用率が、ＣＰＵ基準値９０３より低いと判定された場合、閾値制御プログラム９０２は、システムの閾値Ｔを増加させ（ステップ１００２）、ステップ１００１に戻り同様の処理を実行する。

取得されたＣＰＵ１６０の利用率が、ＣＰＵ基準値９０３より低いと判定された場合、閾値制御プログラム９０２は、システムの閾値Ｔを減少させ（ステップ１００３）、ステップ１００１に戻り同様の処理を実行する。

次に、システムの閾値Ｔの変更の方法について説明する。

図１１は、本発明の第２の実施形態におけるシステムの閾値Ｔの変更方法を説明するための図である。

図１１において、横軸はシステムの閾値Ｔを示し、縦軸はサーバ１５０が提供する全サービス量（システムのサービス量）を示す。

以下の説明において、現在の全サービス量をＱ₀とし、現在のシステムの閾値をＴ₀とする。また、ステップ１００１の判定時に使用されるＣＰＵ基準値９０３に対応する全サービス量をＱ₁とする。なお、閾値制御プログラム９０２は、ＣＰＵ利用率−サービス量対応テーブル９０４を参照することによって、ＣＰＵ１６０の利用率から、現在、サーバ１５０が提供するサービス量を知ることができる。なお、閾値制御プログラム９０２は、ＣＰＵ１６０によってメモリ１７０から読み出され、ＣＰＵ１６０によって実行される。

直線１１０１は、（数１）をプロットしたものである。具体的には、システムの閾値Ｔの最大値をプロットした直線である。

ステップ１００１において、現在の全サービス量Ｑ₀が、ＣＰＵ基準値９０３に対応するサービス量Ｑ₁より低いため、閾値制御プログラム９０２は、ステップ１００２に進む。

ステップ１００２において、閾値制御プログラム９０２は、現在の全サービス量Ｑ₀及び閾値Ｔ₀が交わった交点１１０３と、サービス量の上限値Ｑ_max及びシステムの閾値の上限値Ｋが交わった交点１１０４とを結ぶ直線１１０２を算出する。

次に、閾値制御プログラム９０２は、直線１１０２に、ＣＰＵ基準値９０３に対応するサービス量Ｑ₁を代入し、Ｔ₁を算出する。

閾値制御プログラム９０２は、算出されたシステムの閾値Ｔ₁を新たなシステムの閾値Ｔとして設定する。具体的には、閾値テーブル１７７のシステムのエントリの閾値７０２がＴ₀からＴ₁に変更される。

前述した方法では、閾値制御プログラム９０２は、算出されたＴ₁を新たなシステムの閾値Ｔとしたが、Ｔ₀からＴ₁の範囲にある値に変更する方法であってもよい。

なお、ステップ１００３においても、同様の処理によって、システムの閾値Ｔが変更される。

［第３の実施形態］
第３の実施形態では、計算機システムが複数のサーバを備える点が第１の実施形態と異なる。以下、第１の実施形態との差異を中心に第３の実施形態について説明する。

図１２は、本発明の第３の実施形態の計算機システムの構成例を示すブロック図である。

第３の実施形態の計算機システムは、複数のサーバ１２０２を備え、また、流量制御装置１１０と複数のサーバ１２０２との間にロードバランサ１２０１を備える。図１２に示す例では、計算機システムは、サーバ１〜サーバｎまでのｎ個のサーバを備える。

ロードバランサ１２０１は、サーバ１２０２が受け付けるリクエスト数を制御するための機能を備える。具体的には、ロードバランサ１２０１は、少なくとも、要求元識別プログラム１７１、スレッド−要求元対応テーブル１７６、閾値テーブル１７７、及び最後にチェックした組織識別子１７８を格納する。

第３の実施形態では、サーバ１２０２がリクエストの受け付けを制御するための機能を備える必要はない。

ロードバランサ１２０１は、第１の実施形態と同様に、各組織に提供されるサービス量に応じて、リクエストを取得する。さらに、ロードバランサ１２０１は、各サーバ１２０２に取得されたリクエストを割り振る。割り振る方法としては、ラウンドロビン方式、及び負荷の最も低いサーバ１２０２に割り振る方式が考えられる。

本発明の一形態によれば、システム及び各組織の閾値に基づいて、サーバ１５０がリクエストを受け付けるか否かを判定することによって、組織間のサービス量のバランスをとることができる。したがって、ある組織からのリクエスト量が多過ぎるために、サーバ１５０が、他の組織のリクエストを処理できないという状況を解消できる。

１０１ Ｗｅｂブラウザ
１１０ 流量制御装置
１２０ ＣＰＵ
１３０ メモリ
１３１ リクエスト取得プログラム
１３２ リクエスト数確認プログラム
１３３ リクエスト投入プログラム
１３４ リクエスト数更新プログラム
１３５ リクエスト数
１３６ 上限値
１４０ 通信部
１５０ サーバ
１６０ ＣＰＵ
１７０ メモリ
１７１ 要求元識別プログラム
１７２ キュー追加プログラム
１７３ リクエスト取得プログラム
１７４ リクエスト処理プログラム
１７５ リクエストキュー
１７６ スレッド−要求元対応テーブル
１７７ 閾値テーブル
１７８ 最後にチェックした組織識別子
１７９ スレッドプール
１８０ 通信部
４０１ スレッド番号
４０２ 処理中の要求元
７０１ 組織
７０２ 閾値
９００ サーバ
９０１ ＣＰＵ利用率監視プログラム
９０２ 閾値制御プログラム
９０３ ＣＰＵ基準値
９０４ ＣＰＵ利用率−サービス量対応テーブル
１１０１ 直線
１１０２ 直線
１１０３ 交点
１１０４ 交点
１２０１ ロードバランサ
１２０２ サーバ

Claims (15)

1. 一以上のクライアント装置からリクエストを受け付ける第１の計算機と、前記第１の計算機から送信される前記リクエストを受け付ける第２の計算機とを備える計算機システムであって、
   前記第１の計算機は、第１のプロセッサと、前記第１のプロセッサに接続される第１のメモリと、前記第２の計算機と通信するための第１の通信部を備え、
   前記第２の計算機は、第２のプロセッサと、前記第２のプロセッサに接続され、前記第２の計算機に設定される第１の閾値及び前記クライアント装置を操作するユーザが所属するグループごとに設定される第２の閾値が格納される第２のメモリと、前記第１の計算機と通信するための第２の通信部を備え、
   前記第２の計算機は、
   前記第１の計算機からリクエストを受信した場合、前記第１の計算機から受け付けたリクエストの総数を算出して、前記第１の計算機から受け付けたリクエストの総数が前記第１の閾値以下か否かを判定し、
   前記第１の計算機から受け付けたリクエストの総数が前記第１の閾値より大きいと判定された場合、前記第１の計算機から受信したリクエストの送信元のユーザが所属する前記グループを特定し、
   前記特定されたグループから受け付けたリクエスト数を算出し、前記特定されたグループから受け付けたリクエスト数が前記第２の閾値以下か否かを判定し、
   前記特定されたグループから受け付けたリクエスト数が前記第２の閾値以下と判定された場合、前記特定されたグループからのリクエストを受け付けることを特徴とする計算機システム。
2. 前記第２の計算機は、
   前記第１の計算機から受け付けたリクエストの総数が前記第１の閾値以下と判定された場合、前記第１の計算機から受信したリクエストの送信元のユーザが所属する前記グループを特定し、前記特定されたグループからのリクエストを受け付けることを特徴とする請求項１に記載の計算機システム。
3. 前記第２の計算機は、
   前記特定されたグループから受け付けたリクエスト数が前記第２の閾値より大きいと判定された場合、前記特定されたグループからのリクエストを受け付けないことを特徴とする請求項２に記載の計算機システム。
4. 前記第２の閾値は、前記第２の計算機が当該グループから受け付け可能なリクエスト数を示すことを特徴とする請求項３に記載の計算機システム。
5. 前記第１のメモリには、前記第１の計算機が受け付けることが可能なリクエスト数を示す上限値と、前記第１の計算機から前記第２の計算機に送信され、前記第２の計算機に受け付けられたリクエストの数を示す、受け付けリクエスト数とが格納され、
   前記第１の計算機は、
   前記クライアント装置からリクエストが送信された場合、前記受け付けリクエスト数と前記上限値とを参照して、前記受け付けリクエスト数が、前記上限値以上か否かを判定し、
   前記受け付けリクエスト数が、前記上限値より小さいと判定された場合、前記クライアント装置から受信したリクエストを受け付け、前記受け付けたリクエストを前記第２の計算機に送信することを特徴とする請求項４に記載の計算機システム。
6. 前記第２のメモリは、前記第２のプロセッサの負荷を監視するための監視プログラムを備え、
   前記第２の計算機は、
   前記第２のプロセッサの負荷が所定値以上の場合、前記第１の閾値が小さくなるように変更し、
   前記第２のプロセッサの負荷が前記所定値以下の場合、前記第１の閾値が大きくなるように変更することを特徴とする請求項５に記載の計算機システム。
7. 前記第２の計算機は、
   前記クライアント装置から送信されたリクエストの送信元のユーザが、前記クライアント装置からリクエストを送信するために使用されたログイン情報を、前記クライアント装置から取得し、
   前記取得された前記ログイン情報に基づいて、前記第１の計算機から受信したリクエストの送信元のユーザが所属するグループを特定することを特徴とする請求項６に記載の計算機システム。
8. 前記第２のメモリは、前記第２の計算機が、各々の前記グループに所属するユーザから受け付けたリクエストを管理するためのリクエスト数管理テーブルを備え、
   前記第２の計算機は、前記リクエスト数管理テーブルを参照して、前記特定されたグループから受け付けたリクエスト数を算出することを特徴とする請求項６に記載の計算機システム。
9. 前記第２のメモリは、前記第１の閾値と前記第２の閾値とを格納する閾値管理テーブルを備え、
   前記第２の計算機は、
   前記閾値管理テーブルを参照して、前記第１の計算機から受け付けたリクエストの総数が前記第１の閾値以下か否かを判定し、
   前記閾値管理テーブルを参照して、前記特定されたグループから受け付けたリクエストが前記第２の閾値以下か否かを判定することを特徴とする請求項６に記載の計算機システム。
10. 前記計算機システムは、さらに、前記リクエストを処理する複数の第３の計算機を備え、
    前記第２の計算機は、前記受け付けたリクエストをラウンドロビンによって前記第３の計算機に割り当てることを特徴とする請求項１に記載の計算機システム。
11. 前記計算機システムは、さらに、前記リクエストを処理する複数の第３の計算機を備え、
    前記第２の計算機は、前記第３の計算機の負荷の低い順に、前記受け付けたリクエストを前記各第３の計算機に割り当てることを特徴とする請求項１に記載の計算機システム。
12. 一以上のクライアント装置からリクエストを受け付ける第１の計算機と、前記第１の計算機から送信される前記リクエストを受け付ける第２の計算機とを備える計算機システムにおけるリクエスト処理方法であって、
    前記第１の計算機は、第１のプロセッサと、前記第１のプロセッサに接続される第１のメモリと、前記第２の計算機と通信するための第１の通信部を備え、
    前記第２の計算機は、第２のプロセッサと、前記第２のプロセッサに接続され、前記第２の計算機に設定される第１の閾値及び前記クラインと装置を操作するユーザが所属するグループごとに設定される第２の閾値が格納される第２のメモリと、前記第１の計算機と通信するための第２の通信部を備え、
    前記方法は、
    前記第２の計算機が、前記第１の計算機からリクエストを受信した場合、前記第１の計算機から受け付けたリクエストの総数を算出して、前記第１の計算機から受け付けたリクエストの総数が前記第１の閾値以下か否かを判定する第１のステップと、
    前記第２の計算機が、前記第１の計算機から受け付けたリクエストの総数が前記第１の閾値より大きいと判定された場合、前記第１の計算機から受信したリクエストの送信元のユーザが所属する前記グループを特定する第２のステップと、
    前記第２の計算機が、前記特定されたグループから受け付けたリクエスト数を算出し、前記特定されたグループから受け付けたリクエスト数が前記第２の閾値以下か否かを判定する第３のステップと、
    前記第２の計算機が、前記特定されたグループから受け付けたリクエスト数が前記第２の閾値以下と判定された場合、前記特定されたグループからのリクエストを受け付ける第４のステップと、を含むことを特徴とするリクエスト処理方法。
13. 前記第１のステップにおいて、前記第１の計算機から受け付けたリクエストの総数が前記第１の閾値以下と判定された場合、前記第２の計算機が、前記第１の計算機から受信したリクエストの送信元のユーザが所属する前記グループを特定し、前記特定されたグループからのリクエストを受け付けるステップを含むこと特徴とする請求項１２に記載のリクエスト処理方法。
14. 前記第２の閾値は、前記第２の計算機が当該グループから受け付け可能なリクエスト数を示す閾値であり、
    前記方法は、前記第３のステップにおいて、前記特定されたグループから受け付けたリクエスト数が前記第２の閾値より大きいと判定された場合、前記第２の計算機が、前記特定されたグループからのリクエストを受け付けないステップを含むこと特徴とする請求項１２に記載のリクエスト処理方法。
15. 一以上のクライアント装置からリクエストを受け付ける計算機と接続され、前記計算機から送信される前記リクエストを受け付けるサーバ装置であって、
    前記サーバ装置は、プロセッサと、前記プロセッサに接続され、前記サーバ装置に設定される第１の閾値及び前記クライアント装置を操作するユーザが所属するグループごとに設定される第２の閾値が格納されるメモリと、前記計算機と通信するための通信部を備え、
    前記サーバ装置は、
    前記計算機からリクエストを受信した場合、前記計算機から受け付けたリクエストの総数を算出して、前記計算機から受け付けたリクエストの総数が前記第１の閾値以下か否かを判定し、
    前記計算機から受け付けたリクエストの総数が前記第１の閾値以下と判定された場合、前記計算機から受信したリクエストの送信元のユーザが所属する前記グループを特定し、前記特定されたグループからのリクエストを受け付け、
    前記計算機から受け付けたリクエストの総数が前記第１の閾値より大きいと判定された場合、前記計算機から受信したリクエストの送信元のユーザが所属する前記グループを特定し、
    前記特定されたグループから受け付けたリクエスト数を算出し、前記特定されたグループから受け付けたリクエスト数が前記第２の閾値以下か否かを判定し、
    前記特定されたグループから受け付けたリクエスト数が前記第２の閾値より大きいと判定された場合、前記特定されたグループからのリクエストを受け付けず、
    前記特定されたグループから受け付けたリクエスト数が前記第２の閾値以下と判定された場合、前記特定されたグループからのリクエストを受け付けることを特徴とするサーバ装置。

Images