JP2017107486A - 処理リソース制御プログラム、処理リソース制御装置、および処理リソース制御方法 - Google Patents

Abstract

【課題】処理実行装置の処理遅延を抑制する。【解決手段】処理リソース制御装置１０１は、ＩＮ量とＯＵＴ量とを取得する。次に、処理リソース制御装置１０１は、ＩＮ量とＯＵＴ量との比率となる増加率を算出する。そして、処理リソース制御装置１０１は、増加率に応じて決定される、処理リソースの追加を行う閾値を決定する。次に、処理リソース制御装置１０１は、決定した閾値に基づいて、スケジュール処理で実行される処理に用いられるリソース量の制御を行う。【選択図】図１

Description

本発明は、処理リソース制御プログラム、処理リソース制御装置、および処理リソース制御方法に関する。

従来、処理を実行する処理実行装置の未処理の処理量に対する閾値を段階的に設定し、設定した閾値を未処理の処理量が超えた場合に、他の装置に処理の実行を依頼することにより、負荷を分散する技術がある。関連する先行技術として、例えば、資源アクセス要求の統計情報から閾値を決定し、キューの長さが閾値より長い場合、到着する資源アクセス要求を他の代替資源管理装置に転送するアクセス要求転送装置を有するものがある。

特開平５−２１６８４２号公報

しかしながら、従来技術によれば、処理を実行する処理実行装置の処理遅延が発生する場合がある。具体的には、未処理の処理量に対する閾値を段階的に設定したとしても、突発的な処理要求が発生して、負荷分散が完了する前に性能限界を超えてしまった場合には、処理遅延が発生する。

１つの側面では、本発明は、処理実行装置の処理遅延を抑制することができる処理リソース制御プログラム、処理リソース制御装置、および処理リソース制御方法を提供することを目的とする。

本発明の一態様によれば、処理実行装置に対して要求され、処理が開始されていない未処理の処理量と、処理実行装置で処理された単位時間あたりの処理量とを取得し、取得した未処理の処理量と単位時間あたりの処理量との比率に応じて決定される、処理リソースの追加を行う閾値に基づいて、処理実行装置で実行される処理に用いられるリソース量の制御を行う処理リソース制御プログラム、処理リソース制御装置、および処理リソース制御方法が提案される。

本発明の一側面によれば、処理実行装置の処理遅延を抑制することができるという効果を奏する。

図１は、本実施の形態にかかる処理リソース制御装置１０１の動作例を示す説明図である。 図２は、システム２００の構成例を示す説明図である。 図３は、スケジュールサーバ２０１のハードウェア構成例を示す説明図である。 図４は、スケジュールサーバ２０１の機能構成例を示す説明図である。 図５は、キュー管理テーブル４２２の一例を示す説明図である。 図６は、スケジュール要求キュー１１１とスケジュール実行中キュー１１２との状態の一例を示す説明図である。 図７は、キューイング時チェック処理手順の一例を示すフローチャートである。 図８は、キューイング処理手順の一例を示すフローチャートである。 図９は、実行依頼処理手順の一例を示すフローチャートである。 図１０は、定期チェック処理手順の一例を示すフローチャートである。 図１１は、閾値設定処理手順の一例を示すフローチャートである。 図１２は、キュー管理テーブル更新初期処理手順の一例を示すフローチャートである。 図１３は、増加率算出処理手順の一例を示すフローチャートである。 図１４は、閾値の変化例を示す説明図（その１）である。 図１５は、閾値の変化例を示す説明図（その２）である。 図１６は、閾値の変化例を示す説明図（その３）である。 図１７は、閾値の具体的な算出例を示す説明図である。 図１８は、変動閾値による負荷状態の検出例を示す説明図である。 図１９は、固定閾値による負荷状態の検出例を示す説明図である。

以下に図面を参照して、開示の処理リソース制御プログラム、処理リソース制御装置、および処理リソース制御方法の実施の形態を詳細に説明する。

図１は、本実施の形態にかかる処理リソース制御装置１０１の動作例を示す説明図である。処理リソース制御装置１０１は、処理リソースを制御するコンピュータである。具体的には、処理リソース制御装置１０１は、処理実行装置で実行される処理に用いられるリソース量の制御を行う。

ここで、リソースは、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、メモリといった計算資源である。例えば、処理リソースを追加する場合には、処理リソース制御装置１０１は、処理を現在実行しているスレッドまたはプロセスを複製し、複製したスレッドまたはプロセスを、処理実行装置に割り当てる。または、処理リソース制御装置１０１は、複製元のスレッドまたはプロセスを実行する処理実行装置とは別のサーバに、複製したスレッドまたはプロセスを割り当ててもよい。

また、処理実行装置は、どのような処理を実行してもよく、例えば、処理を実行する装置に、処理を振り分けるスケジュール処理を行うスケジュールサーバである。ここで、振り分ける対象となる処理を、「ジョブ」と呼称する。ジョブ管理製品分野では、スケジュールサーバと、ジョブを実行する実行サーバとのシステム構成により運用を実現する。

スケジュールサーバの負荷分散は、以下の点で困難である。まず、スケジュールサーバが、未処理のジョブが滞留して、スケジュール処理が遅延すると、ジョブの実行要求が遅延することがある。これに対して、未処理のジョブの滞留数に対する閾値を事前に設定することにより、負荷分散の判断を行うことが考えられる。しかし、予測できない突発的なスケジュール処理要求が大量に発生した場合には、急激に増加するスケジュール処理の処理量に対して、負荷分散の対処が間に合わない場合がある。

ここで、スケジュール処理要求には、大きく分類して２つの発生要因がある。一方は、指定時刻到来により発生するスケジュール処理要求である。以下、指定時刻到来により発生するスケジュール処理要求を、「時刻型スケジュール処理要求」と呼称する。時刻型スケジュール処理要求は、要求が集中する時間帯を事前に把握することにより、負荷分散のタイミングを予測することができるため、負荷分散を行うことが可能である。

他方は、メッセージ受信等のイベント発生を契機とするスケジュール処理要求である。以下、メッセージ受信等のイベント発生を契機とするスケジュール処理要求を、「イベント型スケジュール処理要求」と呼称する。イベント型スケジュール処理要求は、要求が突発的であり、負荷分散判断のタイミングを予測することが困難である。そして、近年では、イベント型スケジュール処理要求中心のオンデマンド運用が主流である。主流となった原因は、スマートフォンやタブレット端末といった情報端末が発達し、ジョブ管理製品の利用シーンが拡大してきていることである。

そして、イベント型スケジュール処理要求により、処理実行装置の処理遅延が発生する場合がある。具体的には、未処理の処理量に対する閾値を段階的に設定したとしても、突発的な処理要求が発生して、負荷分散が完了する前に性能限界を超えてしまった場合には、処理遅延が発生し、業務として遅延が発生する。

また、ジョブの滞留傾向を予測する技術として、近似曲線を活用した予測が考えられる。この技術により、イベント型スケジュール処理要求の増加を早期に検出する可能性があるが、近似曲線を生成する際に用いるデータが少ないと、誤検出する可能性が高くなる。また、誤検出を避けるために、予測の精度を上げようとすると、監視回数を増やすことになり、結果、負荷分散判断のタイミングに遅れが生じることになる。

また、予測した閾値は、過去の稼働実績やテスト運用から算出した固定値であり、この固定値が、突発的なスケジュール処理要求を検出できるとは限らない。そして、閾値に到達しない限り負荷分散の対処が行えないため、対処が遅れることになる。

そこで、本実施の形態では、スケジュール処理要求され、スケジュール処理が開始されていない未処理の処理数と単位時間当たりの処理数との比率に応じた閾値に基づいて、スケジュール処理に用いるリソース量を制御することについて説明する。

図１を用いて、処理リソース制御装置１０１の動作例を説明する。図１では、処理実行装置が、処理リソース制御装置１０１となる例を説明する。また、処理リソース制御装置１０１は、ジョブを実行する複数の実行サーバと接続する。

処理リソース制御装置１０１は、処理リソース制御装置１０１に対して要求され、処理が開始していない未処理の処理量と、処理リソース制御装置１０１で処理された単位時間あたりの処理量とを取得する。取得する未処理の処理量は、処理リソース制御装置１０１に対して単位時間あたりで要求され、処理が開始していない未処理の処理量でもよい。

また、処理量は、データ量で計測する考え方とデータ数で計測する考え方と２通り存在する。前者は、スケジュール処理要求のジョブのデータ総量を計測するものである。このため、厳密な情報量を計測できるが関連情報全てを積算するので計測自体に処理時間を要するため、高速性が劣る。一方後者は、スケジュール処理要求を数として捉えるものである。このため、量として捉える前者の考え方に比べると総量積算が無く、スケジュール処理要求の数自体がスケジュール処理中に算出されるものであり、特別な計算をしないで内部情報を使い回せるため、高速性で優位となる。本実施の形態の趣旨が早期判断の実現であることから、処理量については高速性を重視した後者の方式を採用することが好ましい。以下の記載では、処理量を、データ数で計測する考え方を用いて説明する。

ここで、処理リソース制御装置１０１は、スケジュール要求キュー１１１とスケジュール実行中キュー１１２とを有する。スケジュール要求キュー１１１は、処理リソース制御装置１０１に対してスケジュール要求され、スケジュール処理が開始していない未処理のジョブに関する情報を蓄えるキューである。また、スケジュール実行中キュー１１２は、スケジュール処理が終了しており、実行サーバに依頼したジョブに関する情報を蓄えるキューである。

ここで、スケジュール要求キュー１１１やスケジュール実行中キュー１１２にキューイングされる、ジョブに関する情報を、「スケジュール情報」と呼称する。スケジュール情報には、要求を受け付けた順序を示す番号と、ジョブのＩＤ（ＩＤｅｎｔｉｆｉｅｒ）とが含まれる。また、スケジュール情報が、スケジュール要求キュー１１１に含まれる状態、またはスケジュール実行中キュー１１２に含まれる状態を識別するフラグを有してもよい。また、スケジュール要求キュー１１１に蓄積可能なスケジュール情報の最大値を、「スケジュール要求最大値」と呼称する。

図１、図６、図１４〜図１７では、円の中に番号を入れた記号を、スケジュール情報として示す。また、円の輪郭が破線となったスケジュール情報は、該当のキューから移動したことを示す。

図１で示すフェーズ１では、スケジュール要求キュー１１１には、スケジュール情報１、２がスケジュール要求キュー１１１にキューイングされている。また、フェーズ１から所定時間として監視間隔時間経過したフェーズ２では、スケジュール情報１、２が状態遷移し、スケジュール実行中キュー１１２にキューイングされている。さらに、フェーズ２では、スケジュール情報３、４がスケジュール要求キュー１１１にキューイングされている。

図１で示すように、単位時間となる監視間隔時間で、スケジュール要求キュー１１１にキューイングされたスケジュール情報は２つであり、スケジュール実行中キュー１１２に状態遷移したスケジュール情報は２つである。

以下、監視間隔時間で、スケジュール要求キュー１１１にキューイングされたスケジュール情報の個数を、「ＩＮ量」と呼称する。同様に、監視間隔時間で、スケジュール実行中キュー１１２に状態遷移したスケジュール情報の個数を、「ＯＵＴ量」と呼称する。

図１の（１）で示すように、処理リソース制御装置１０１は、ＩＮ量として２と、ＯＵＴ量として２とを取得する。

次に、図１の（２）で示すように、処理リソース制御装置１０１は、ＩＮ量とＯＵＴ量との比率を算出する。ＩＮ量とＯＵＴ量との比率は、ＯＵＴ量に対するＩＮ量の割合、すなわちＩＮ量÷ＯＵＴ量でもよいし、ＩＮ量に対するＯＵＴ量の割合、すなわちＯＵＴ量÷ＩＮ量でもよい。本実施の形態では、ＩＮ量÷ＯＵＴ量を算出し、算出して得られた値を増加率として定義する。ただし、計算の都合上、分母に０がこないようにするため、処理リソース制御装置１０１は、ＯＵＴ量が０の場合、増加率をＩＮ量として算出する。また、増加率を用いて閾値を決定する際の都合上、ＩＮ量よりＯＵＴ量が大きい場合には、処理リソース制御装置１０１は、増加率を１として算出する。図１の例では、処理リソース制御装置１０１は、増加率を２÷２＝１と算出する。

そして、図１の（３）で示すように、処理リソース制御装置１０１は、増加率に応じて決定される、処理リソースの追加を行う閾値を決定する。例えば、処理リソース制御装置１０１は、スケジュール要求最大値÷増加率を算出し、算出して得られた値を閾値として決定する。ただし、増加率が１以下である場合、および初期設定時には、処理リソース制御装置１０１は、閾値をスケジュール要求最大値−１として算出する。図１の例では、増加率が１であるため、処理リソース制御装置１０１は、閾値をスケジュール要求最大値−１と算出する。

次に、図１の（４）で示すように、処理リソース制御装置１０１は、決定した閾値に基づいて、スケジュール処理で実行される処理に用いられるリソース量の制御を行う。例えば、処理リソース制御装置１０１は、スケジュール要求キュー１１１にキューイングされたスケジュール情報の数が閾値を超えている場合、スケジュール処理で実行される処理に用いられるリソース量の追加を行う。

以上により、決定される閾値が増加率に応じた連続値となるため、処理リソース制御装置１０１は、負荷分散のタイミングが適切となって処理遅延を抑制することができる。

なお、図１の説明では、処理実行装置は、ジョブを振り分けるスケジュール処理を行うスケジュールサーバであったが、これに限らない。例えば、処理実行装置は、ジョブを実行する装置であってもよい。そして、処理リソース制御装置１０１は、ジョブを実行する装置に対して要求され、ジョブを開始していない未処理のジョブの処理量と、処理された単位時間あたりのジョブの処理量を取得する。そして、処理リソース制御装置１０１は、未処理のジョブの処理量と、処理された単位時間あたりのジョブの処理量との比率に応じて閾値を決定し、決定した閾値に基づいて、ジョブの実行に用いられるリソースの制御を行ってもよい。次に、処理リソース制御装置１０１を、スケジュールサーバとして適用した例を、図２を用いて説明する。

図２は、システム２００の構成例を示す説明図である。システム２００は、スケジュールサーバ２０１と、実行サーバ２０２と、クライアント端末２０３とを有する。スケジュールサーバ２０１とクライアント端末２０３とはネットワーク２０４で接続される。ここで、スケジュールサーバ２０１は、図１で示した処理リソース制御装置１０１に相当する。

スケジュールサーバ２０１は、ジョブのスケジュールを管理するサーバである。実行サーバ２０２は、ジョブを実行するサーバである。クライアント端末２０３は、スケジュールサーバ２０１に、ジョブの実行要求を送信するコンピュータである。

例えば、システム２００は、チケット予約システムに適用できる。この場合、実行サーバ２０２は、チケットの予約を行うサーバである。クライアント端末２０３は、例えば、チケット予約システムにアクセスする利用者の情報端末となるスマートフォンやタブレット端末であったり、チケット予約システムを提供する企業の担当者の専用端末であったりする。そして、あるチケットの販売時刻となった場合には、クライアント端末２０３から、チケットの予約要求がスケジュールサーバ２０１に送信されることになる。

図３は、スケジュールサーバ２０１のハードウェア構成例を示す説明図である。図３において、スケジュールサーバ２０１は、ＣＰＵ３０１と、ＲＯＭ（Ｒｅａｄ−Ｏｎｌｙ Ｍｅｍｏｒｙ）３０２と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）３０３と、を含む。また、スケジュールサーバ２０１は、ディスクドライブ３０４およびディスク３０５と、通信インターフェース３０６と、を含む。また、ＣＰＵ３０１〜ディスクドライブ３０４、通信インターフェース３０６はバス３０７によってそれぞれ接続される。

ＣＰＵ３０１は、スケジュールサーバ２０１の全体の制御を司る演算処理装置である。ＣＰＵ３０１は、複数のプロセッサコアを有してもよい。

ＲＯＭ３０２は、ブートプログラムなどのプログラムを記憶する不揮発性メモリである。ＲＡＭ３０３は、ＣＰＵ３０１のワークエリアとして使用される揮発性メモリである。

ディスクドライブ３０４は、ＣＰＵ３０１の制御に従ってディスク３０５に対するデータのリードおよびライトを制御する制御装置である。ディスクドライブ３０４には、例えば、磁気ディスクドライブ、光ディスクドライブ、ソリッドステートドライブなどを採用することができる。ディスク３０５は、ディスクドライブ３０４の制御で書き込まれたデータを記憶する不揮発性メモリである。例えばディスクドライブ３０４が磁気ディスクドライブである場合、ディスク３０５には、磁気ディスクを採用することができる。また、ディスクドライブ３０４が光ディスクドライブである場合、ディスク３０５には、光ディスクを採用することができる。また、ディスクドライブ３０４がソリッドステートドライブである場合、ディスク３０５には、半導体素子によって形成された半導体メモリ、いわゆる半導体ディスクを採用することができる。

通信インターフェース３０６は、ネットワーク２０４等と内部のインターフェースを司り、他の装置からのデータの入出力を制御する制御装置である。具体的に、通信インターフェース３０６は、通信回線を通じてネットワーク２０４等を介して他の装置に接続される。通信インターフェース３０６には、例えば、モデムやＬＡＮアダプタなどを採用することができる。

また、システム２００の管理者が、スケジュールサーバ２０１を直接操作する場合、スケジュールサーバ２０１は、ディスプレイ、キーボード、マウスといったハードウェアを有してもよい。また、実行サーバ２０２も、スケジュールサーバ２０１が有するハードウェアと同等のハードウェアを有する。また、クライアント端末２０３も、スケジュールサーバ２０１が有するハードウェアと同等のハードウェアと、ディスプレイ、キーボード、マウスといったハードウェアとを有する。

（スケジュールサーバ２０１の機能構成例）
図４は、スケジュールサーバ２０１の機能構成例を示す説明図である。スケジュールサーバ２０１は、イベント型スケジュール投入部４０１と、スケジュール制御部４０２と、閾値監視部４０３と、負荷分散制御部４０４と、キュー制御部４０５と、を含む。閾値監視部４０３は、取得部４１１と、算出部４１２と、決定部４１３とを有する。制御部となるイベント型スケジュール投入部４０１〜キュー制御部４０５は、記憶装置に記憶されたプログラムをＣＰＵ３０１が実行することにより、各部の機能を実現する。記憶装置とは、具体的には、例えば、図３に示したＲＯＭ３０２、ＲＡＭ３０３、ディスク３０５などである。また、各部の処理結果は、ＣＰＵ３０１のレジスタや、ＣＰＵ３０１のキャッシュメモリ、ＲＡＭ３０３等に格納される。

また、スケジュールサーバ２０１は、システム情報テーブル４２１と、キュー管理テーブル４２２とにアクセス可能である。システム情報テーブル４２１と、キュー管理テーブル４２２とは、ＲＡＭ３０３、ディスク３０５といった記憶装置に格納される。システム情報テーブル４２１には、スケジュール要求最大値が含まれる。キュー管理テーブル４２２は、ＩＮ量、ＯＵＴ量、閾値が含まれる。キュー管理テーブル４２２の詳細については、図５で説明する。

イベント型スケジュール投入部４０１は、クライアント端末２０３からジョブの実行依頼を受け付けた際に、スケジュール制御部４０２にスケジュール情報の投入依頼を通知する。

スケジュール制御部４０２は、スケジュール処理を実行する。具体的には、スケジュール制御部４０２は、トリガイベントが発生した際に、スケジュール処理を行い、実行サーバ２０２にジョブの実行依頼を行う。

閾値監視部４０３は、キュー管理テーブル４２２の閾値を監視する。より具体的な機能については、取得部４１１〜決定部４１３で説明する。

取得部４１１は、スケジュール要求キュー１１１やスケジュール実行中キュー１１２にキューイングされたスケジュール情報に基づいて、ＩＮ量とＯＵＴ量とを取得する。さらに、取得部４１１は、処理実行装置に対して要求され、処理が開始されていない処理量を取得してもよい。処理実行装置に対して要求され、処理が開始されていない処理量は、スケジュール要求キュー１１１にキューイングされているスケジュール情報の数となる。スケジュール要求キュー１１１にキューイングされているスケジュール情報の数を、「滞留数」と呼称する。

算出部４１２は、取得部４１１が取得したＩＮ量とＯＵＴ量とから、増加率を算出する。増加率の算出方法は、図１で説明した通りである。また、算出部４１２は、滞留数とＯＵＴ量との比率を算出してもよい。

決定部４１３は、算出部４１２が算出した増加率に応じて閾値を決定する。増加率に応じた閾値の決定方法は、図１で説明した通りである。また、決定部４１３は、算出部４１２が算出した増加率を用いず、ＩＮ量とＯＵＴ量とから、閾値を算出してもよい。例えば、決定部４１３は、スケジュール要求最大値÷ＩＮ量×ＯＵＴ量を算出し、算出して得られた値を閾値として決定する。ただし、分母となるＩＮ量が０となったり、得られた値がスケジュール要求最大値−１を超えたりする場合には、決定部４１３は、閾値をスケジュール要求最大値−１として決定する。

また、決定部４１３は、滞留数とＯＵＴ量との比率に応じて閾値を決定してもよい。例えば、決定部４１３は、スケジュール要求最大値÷滞留数×ＯＵＴ量を算出し、算出して得られた値を閾値として決定する。ただし、分母となる滞留数が０となったり、得られた値がスケジュール要求最大値−１を超えたりする場合には、決定部４１３は、閾値をスケジュール要求最大値−１として決定する。決定部４１３は、決定した閾値をキュー管理テーブル４２２に格納する。

負荷分散制御部４０４は、キュー管理テーブル４２２の閾値に基づいて、スケジュール処理に用いられるリソース量の制御を行う。例えば、負荷分散制御部４０４は、滞留数と閾値との比較結果に基づいて、リソース量の制御を行う。具体的には、負荷分散制御部４０４は、滞留数が閾値より大きい場合に、リソースを追加する。また、負荷分散を行って、リソース追加処理を実施中に負荷状況が改善した場合、負荷分散制御部４０４は、リソース追加処理をキャンセルしてもよいし、継続してもよい。

キュー制御部４０５は、スケジュール要求キュー１１１、スケジュール実行中キュー１１２を制御する。なお、スケジュール要求キュー１１１、スケジュール実行中キュー１１２の制御は、スケジュール制御部４０２が行ってもよい。

図５は、キュー管理テーブル４２２の一例を示す説明図である。キュー管理テーブル４２２は、スケジュール要求キュー１１１とスケジュール実行中キュー１１２とを管理するテーブルである。また、図５では、キュー管理テーブル４２２の説明のために、システム情報テーブル４２１も併せて表示する。

キュー管理テーブル４２２は、ＩＮ情報と、ＯＵＴ情報と、ＩＮ＿ｏｌｄ情報と、ＯＵＴ＿ｏｌｄ情報と、ＩＮ＿ｎｅｗ情報と、ＯＵＴ＿ｎｅｗ情報と、滞留数と、ＩＮ量と、ＯＵＴ量と、増加率と、閾値というフィールドを含む。

ＩＮ情報フィールドには、スケジュール要求キュー１１１にキューイングされた最新のスケジュール情報の番号が格納される。ＯＵＴ情報フィールドには、実行依頼された最新のスケジュール情報の番号が格納される。ＩＮ＿ｏｌｄ情報フィールドには、１回前の定期チェック時に読み込んだ際のＩＮ情報が格納される。ＯＵＴ＿ｏｌｄ情報フィールドには、１回前の定期チェック時に読み込んだ際のＯＵＴ情報が格納される。ＩＮ＿ｎｅｗ情報フィールドには、今回の定期チェック時に読み込んだ際のＩＮ情報が格納される。ＯＵＴ＿ｎｅｗ情報フィールドには、今回の定期チェック時に読み込んだ際のＯＵＴ情報が格納される。

滞留数フィールドには、ＩＮ＿ｎｅｗ情報−ＯＵＴ＿ｎｅｗ情報で算出される値が格納される。滞留数は、スケジュール要求キュー１１１に滞留するスケジュール情報の数を示す。

ＩＮ量フィールドには、ＩＮ＿ｎｅｗ情報−ＩＮ＿ｏｌｄ情報で算出される値が格納される。ＩＮ量は、１回前の定期チェック時から今回の定期チェック時までの間に、スケジュール要求キュー１１１にキューイングされたスケジュール情報の数を示す。

ＯＵＴ量フィールドには、ＯＵＴ＿ｎｅｗ情報−ＯＵＴ＿ｏｌｄ情報で算出される値が格納される。また、算出された値が０である場合、ＯＵＴ量フィールドには、補正値として１が格納される。ＯＵＴ量は、１回前の定期チェック時から今回の定期チェック時までの間に、スケジュール実行中キュー１１２にキューイングされたスケジュール情報の数を示す。

増加率フィールドには、ＩＮ量÷ＯＵＴ量で算出される値が格納される。また、算出された値が１未満である場合、増加率フィールドには、補正値として１が格納される。増加率は、単位時間あたりのスケジュール要求キュー１１１に含まれるスケジュール情報の増加数を示す。

閾値フィールドには、スケジュール要求最大値÷増加率で算出される値が格納される。また、増加率が１の場合、閾値フィールドには、補正値として、スケジュール要求最大値−１が格納される。

図５には、ＩＮ情報、ＯＵＴ情報の各フィールドに格納された値を、それぞれ、ＩＮ、ＯＵＴとし、ＩＮ＿ｏｌｄ情報〜閾値情報の各フィールドに格納された値を、それぞれ、Ａ〜Ｉとし、スケジュール要求最大値をＱＭＡＸとしたものを示す。そして、図５では、滞留数〜閾値の各フィールドについて、Ａ〜Ｉ、ＱＭＡＸを用いた具体的な算出式を示す。また、図５において、一点鎖線で囲ったフィールドは、キューイング時や、実行依頼時に更新されるフィールドである。また、点線で囲ったフィールドは、定期チェック時に更新されるフィールドである。また、網掛けを付与したフィールドは、補正される場合があるフィールドである。

図６は、スケジュール要求キュー１１１とスケジュール実行中キュー１１２との状態の一例を示す説明図である。図６の（Ａ）は、初期状態を示す。ＩＮ情報およびＯＵＴ情報は、初期値として０が設定されている。

図６の（Ｂ）は、図６の（Ａ）で示した状態の後に、スケジュール要求キュー１１１にスケジュール情報をキューイングした時の状態を示す。トリガイベントが発生すると、スケジュール情報１がスケジュール要求キュー１１１にキューイングされるため、ＩＮ情報が１に更新される。このように、ＩＮ情報は、スケジュール要求キュー１１１にキューイングされた最新のスケジュール情報の番号を表す。

図６の（Ｃ）は、図６の（Ｂ）で示した状態の後に、スケジュール情報１の状態遷移が発生した状態を示す。スケジュールサーバ２０１は、実行サーバ２０２に、スケジュール情報１のジョブの実行を依頼するため、ＯＵＴ情報を更新する。このように、ＯＵＴ情報は、実行依頼した最新のスケジュールの番号を表す。

図６の（Ｄ）は、図６の（Ｃ）で示した状態の後に、スケジュール情報１、２のジョブの実行が完了しており、スケジュール情報３、４のジョブの実行を依頼しており、スケジュール情報５〜８がスケジュール要求キュー１１１にキューイングされた状態を示す。この場合、ＩＮ情報が８となり、ＯＵＴ情報が４となる。

次に、図７〜図１３を用いて、スケジュールサーバ２０１が実行するフローチャートを示す。

図７は、キューイング時チェック処理手順の一例を示すフローチャートである。キューイング時チェック処理は、スケジュール情報をスケジュール要求キュー１１１にキューイングする際に行う処理である。キューイング時チェック処理は、スケジュール制御部４０２が実行する処理である。

スケジュール制御部４０２が、システム情報テーブル４２１からスケジュール要求最大値を取得する（ステップＳ７０１）。次に、スケジュール制御部４０２は、閾値設定処理を実行する（ステップＳ７０２）。閾値設定処理については、図１１で説明する。そして、スケジュール制御部４０２が、トリガイベントが発生したか否かを判断する（ステップＳ７０３）。トリガイベントが発生していない場合（ステップＳ７０３：Ｎｏ）、スケジュール制御部４０２が、再びステップＳ７０３の処理を実行する。このように、スケジュール制御部４０２は、トリガイベント待ちループを実行することになる。

一方、トリガイベントが発生した場合（ステップＳ７０３：Ｙｅｓ）、スケジュール制御部４０２が、キューイング処理を実行する（ステップＳ７０４）。キューイング処理は、図８で説明する。次に、スケジュール制御部４０２が、滞留数が閾値を超えているか否かを判断する（ステップＳ７０５）。滞留数が閾値を超えている場合（ステップＳ７０５：Ｙｅｓ）、スケジュール制御部４０２が、負荷分散実行タイミングと判断する（ステップＳ７０６）。そして、スケジュール制御部４０２が、負荷分散指示を負荷分散制御部４０４へ通知する（ステップＳ７０７）。

ステップＳ７０７の処理終了後、または、滞留数が閾値を超えていない場合（ステップＳ７０５：Ｎｏ）、スケジュール制御部４０２が、実行依頼処理を実行する（ステップＳ７０８）。ステップＳ７０８の処理終了後、スケジュール制御部４０２が、ステップＳ７０３の処理に移行する。キューイング時チェック処理を実行することにより、スケジュール制御部４０２は、キューイング時に負荷分散を行うべきか否かを判断することができる。

図８は、キューイング処理手順の一例を示すフローチャートである。キューイング処理は、スケジュール情報をスケジュール要求キュー１１１にキューイングする処理である。また、キューイング処理は、イベント型スケジュール投入部４０１と、スケジュール制御部４０２とが協働する処理である。

イベント型スケジュール投入部４０１が、スケジュール制御部４０２にスケジュール情報の投入依頼を通知する（ステップＳ８０１）。通知を受けたスケジュール制御部４０２が、キュー管理テーブル４２２のＩＮ情報をカウントアップする（ステップＳ８０２）。次に、スケジュール制御部４０２が、スケジュール情報をスケジュール要求キュー１１１にキューイングする（ステップＳ８０３）。そして、スケジュール制御部４０２が、ＩＮ情報とＯＵＴ情報とから、滞留数を算出する（ステップＳ８０４）。次に、スケジュール制御部４０２が、算出した滞留数でキュー管理テーブル４２２を更新する（ステップＳ８０５）。そして、スケジュール制御部４０２が、キュー管理テーブル４２２から閾値を取得する（ステップＳ８０６）。

ステップＳ８０６の処理終了後、スケジュール制御部４０２は、キューイング処理を終了する。キューイング処理を実行することにより、スケジュール制御部４０２は、スケジュール情報をスケジュール要求キュー１１１にキューイングするとともに、ＩＮ情報、滞留数を最新の情報に更新することができる。

図９は、実行依頼処理手順の一例を示すフローチャートである。実行依頼処理は、実行サーバ２０２にジョブの実行を依頼する処理である。実行依頼処理は、スケジュール制御部４０２が実行する処理である。

スケジュール制御部４０２が、キュー管理テーブル４２２のＯＵＴ情報をカウントアップする（ステップＳ９０１）。次に、スケジュール制御部４０２が、スケジュール要求キュー１１１からスケジュール情報のキューイングを解除する（ステップＳ９０２）。そして、スケジュール制御部４０２が、キューイング解除したスケジュール情報をスケジュール実行中キュー１１２に状態遷移する（ステップＳ９０３）。次に、スケジュール制御部４０２が、実行サーバ２０２に、キューイングしたスケジュール情報のジョブの実行依頼を通知する（ステップＳ９０４）。

ステップＳ９０４の処理終了後、スケジュール制御部４０２は、実行依頼処理を終了する。実行依頼処理を実行することにより、スケジュール制御部４０２は、実行サーバ２０２にジョブの実行を依頼するとともに、ＯＵＴ情報を最新の情報に更新することができる。

図１０は、定期チェック処理手順の一例を示すフローチャートである。定期チェック処理は、負荷分散を行うべきか否かを定期的に確認する処理である。定期チェック処理は、閾値監視部４０３が実行する処理である。

閾値監視部４０３が、システム情報テーブル４２１からスケジュール要求最大値を取得する（ステップＳ１００１）。次に、閾値監視部４０３が、監視間隔時間が経過したか否かを判断する（ステップＳ１００２）。監視間隔時間が経過していない場合（ステップＳ１００２：Ｎｏ）、閾値監視部４０３が、再びステップＳ１００２の処理を実行する。一方、監視間隔時間が経過した場合（ステップＳ１００２：Ｙｅｓ）、閾値監視部４０３が、閾値設定処理を実行する（ステップＳ１００３）。

次に、閾値監視部４０３が、キュー管理テーブル４２２のＩＮ情報とＯＵＴ情報とから、滞留数を算出する（ステップＳ１００４）。そして、閾値監視部４０３が、算出した滞留数でキュー管理テーブル４２２を更新する（ステップＳ１００５）。次に、閾値監視部４０３が、滞留数が閾値を超えているか否かを判断する（ステップＳ１００６）。滞留数が閾値を超えている場合（ステップＳ１００６：Ｙｅｓ）、閾値監視部４０３が、負荷分散実行タイミングと判断する（ステップＳ１００７）。次に、閾値監視部４０３が、負荷分散指示を負荷分散制御部４０４へ通知する（ステップＳ１００８）。

ステップＳ１００８の処理終了後、または、滞留数が閾値を超えていない場合（ステップＳ１００６：Ｎｏ）、閾値監視部４０３が、ステップＳ１００２の処理に移行する。定期チェック処理を実行することにより、閾値監視部４０３は、定期的に負荷分散の判断を行うことができる。

図１１は、閾値設定処理手順の一例を示すフローチャートである。閾値設定処理は、閾値を設定する処理である。閾値設定処理は、スケジュール制御部４０２と、閾値監視部４０３とが実行する処理である。

まず、スケジュール制御部４０２が閾値設定処理を実行する場合について説明する。スケジュール制御部４０２が、キューイング処理から呼ばれたか否かを判断する（ステップＳ１１０１）。ここで、スケジュール制御部４０２が実行する場合には、ステップＳ１１０１：Ｙｅｓとなる。キューイング処理から呼ばれた場合（ステップＳ１１０１：Ｙｅｓ）、スケジュール制御部４０２が、閾値を、スケジュール要求最大値−１として算出する（ステップＳ１１０８）。そして、スケジュール制御部４０２が、算出した閾値でキュー管理テーブル４２２を更新する（ステップＳ１１０９）。そして、スケジュール制御部４０２が、閾値設定処理を終了する。閾値設定処理を実行することにより、スケジュール制御部４０２は、閾値の初期設定を行うことができる。

次に、閾値監視部４０３が閾値設定処理を実行する場合について説明する。閾値監視部４０３が、キューイング処理から呼ばれたか否かを判断する（ステップＳ１１０１）。ここで、閾値監視部４０３が実行する場合には、ステップＳ１１０１：Ｎｏとなる。キューイング処理から呼ばれていない場合（ステップＳ１１０１：Ｎｏ）、閾値監視部４０３が、キュー管理テーブル更新初期処理を実行する（ステップＳ１１０２）。キュー管理テーブル更新初期処理は、図１２で説明する。次に、閾値監視部４０３が、ＩＮ情報＝ＯＵＴ情報となるか否かを判断する（ステップＳ１１０３）。

ＩＮ情報＝ＯＵＴ情報となる場合（ステップＳ１１０３：Ｙｅｓ）、スケジュール要求キュー１１１にスケジュール情報が１つもないことを示し、閾値監視部４０３が、ステップＳ１１０８の処理を実行する。

一方、ＩＮ情報＝ＯＵＴ情報とならない場合（ステップＳ１１０３：Ｎｏ）、閾値監視部４０３が、増加率算出処理を実行する（ステップＳ１１０４）。増加率算出処理は、図１３で説明する。次に、閾値監視部４０３が、増加率が１より大きいか否かを判断する（ステップＳ１１０５）。増加率が１以下である場合（ステップＳ１１０５：Ｎｏ）、閾値監視部４０３が、増加率を１として、キュー管理テーブル４２２を更新する（ステップＳ１１０６）。そして、閾値監視部４０３が、ステップＳ１１０８の処理を実行する。

一方、増加率が１より大きい場合（ステップＳ１１０５：Ｙｅｓ）、閾値監視部４０３が、閾値を、スケジュール要求最大値／増加率として算出する（ステップＳ１１０７）。

ステップＳ１１０７、またはステップＳ１１０８の処理終了後、閾値監視部４０３が、ステップＳ１１０９の処理を実行する。ステップＳ１１０９の処理終了後、閾値監視部４０３が、閾値設定処理を終了する。閾値設定処理を実行することにより、閾値監視部４０３は、スケジュール情報の滞留傾向に応じた適切な閾値を設定することができる。

図１２は、キュー管理テーブル更新初期処理手順の一例を示すフローチャートである。キュー管理テーブル更新初期処理は、キュー管理テーブル４２２を更新する際に、ＩＮ＿ｏｌｄ情報、ＯＵＴ＿ｏｌｄ情報、ＩＮ＿ｎｅｗ情報、ＯＵＴ＿ｎｅｗ情報を初期化する処理である。キュー管理テーブル更新初期処理は、閾値監視部４０３が実行する処理である。

閾値監視部４０３が、キュー管理テーブル４２２からＩＮ情報、ＯＵＴ情報を取得する（ステップＳ１２０１）。次に、閾値監視部４０３が、ＩＮ＿ｎｅｗ情報でＩＮ＿ｏｌｄ情報を更新する（ステップＳ１２０２）。また、閾値監視部４０３が、ＯＵＴ＿ｎｅｗ情報でＯＵＴ＿ｏｌｄ情報を更新する（ステップＳ１２０３）。そして、閾値監視部４０３が、ＩＮ情報でＩＮ＿ｎｅｗ情報を更新する（ステップＳ１２０４）。また、閾値監視部４０３が、ＯＵＴ情報でＯＵＴ＿ｎｅｗ情報を更新する（ステップＳ１２０５）。

ステップＳ１２０５の処理終了後、閾値監視部４０３は、キュー管理テーブル更新初期処理を終了する。キュー管理テーブル更新初期処理を実行することにより、閾値監視部４０３は、ＩＮ＿ｎｅｗ情報、ＯＵＴ＿ｎｅｗ情報を最新の情報にすることができるとともに、ＩＮ＿ｏｌｄ情報、ＯＵＴ＿ｏｌｄ情報を１つ前の情報にすることができる。

図１３は、増加率算出処理手順の一例を示すフローチャートである。増加率算出処理は、増加率を算出する処理である。増加率算出処理は、閾値監視部４０３が実行する処理である。

閾値監視部４０３が、ＩＮ量として、ＩＮ＿ｎｅｗ情報−ＩＮ＿ｏｌｄ情報を算出する（ステップＳ１３０１）。また、閾値監視部４０３が、ＯＵＴ量として、ＯＵＴ＿ｎｅｗ情報−ＯＵＴ＿ｏｌｄ情報を算出する（ステップＳ１３０２）。そして、閾値監視部４０３が、算出したＩＮ量とＯＵＴ量とでキュー管理テーブル４２２を更新する（ステップＳ１３０３）。

次に、閾値監視部４０３が、ＯＵＴ量＝０か否かを判断する（ステップＳ１３０４）。ＯＵＴ量＝０である場合（ステップＳ１３０４：Ｙｅｓ）、閾値監視部４０３が、ＯＵＴ量を１として、キュー管理テーブル４２２を更新する（ステップＳ１３０５）。

ステップＳ１３０５の処理終了後、または、ＯＵＴ量＝０でない場合（ステップＳ１３０４：Ｎｏ）、閾値監視部４０３が、増加率として、ＩＮ量÷ＯＵＴ量を算出する（ステップＳ１３０６）。そして、閾値監視部４０３が、算出した増加率でキュー管理テーブル４２２を更新する（ステップＳ１３０７）。ステップＳ１３０７の処理終了後、閾値監視部４０３は、増加率算出処理を終了する。増加率算出処理を実行することにより、閾値監視部４０３は、増加率を得ることができる。続いて、閾値の変化例を、図１４〜図１６を用いて説明する。

図１４は、閾値の変化例を示す説明図（その１）である。図１４の（Ａ）で示すフェーズ１は、キュー管理テーブル４２２、スケジュール要求キュー１１１、スケジュール実行中キュー１１２の初期状態を示す。フェーズ１では、スケジュール要求キュー１１１、スケジュール実行中キュー１１２にあるスケジュール情報は１つもなく、ＩＮ情報〜ＩＮ量には０が格納される。また、ＯＵＴ量は、ステップＳ１３０５の処理により、１となる。同様に、増加率は、ステップＳ１１０６の処理により、１となり、閾値は、ステップＳ１１０８の処理により、５９となる。

図１４の（Ｂ）で示すフェーズ２は、フェーズ１から、スケジュール情報１がスケジュール要求キュー１１１にキューイングした状態を示す。フェーズ２では、ＩＮ情報、ＩＮ＿ｎｅｗ情報が１に更新される。そして、滞留数、ＩＮ量、ＯＵＴ量、増加率が１に更新される。閾値は、ステップＳ１１０８の処理により、５９となる。

図１４の（Ｃ）で示すフェーズ３は、フェーズ２から、スケジュール情報１がスケジュール実行中キュー１１２に状態遷移し、スケジュール情報２〜４がスケジュール要求キュー１１１にキューイングした状態を示す。フェーズ３では、ＩＮ情報、ＩＮ＿ｎｅｗ情報が４に更新され、ＯＵＴ情報、ＯＵＴ＿ｎｅｗ情報が１に更新される。そして、ＩＮ＿ｏｌｄ情報、ＯＵＴ＿ｏｌｄ情報が、フェーズ２でのＩＮ＿ｎｅｗ情報、ＯＵＴ＿ｎｅｗ情報となる。そして、ＩＮ量は、４−１＝３となり、ＯＵＴ量は、１−０＝１となり、滞留数は、４−１＝３となり、増加率は、３÷１＝３となり、閾値は、６０÷３＝２０となる。

図１５は、閾値の変化例を示す説明図（その２）である。図１５の（Ｄ）で示すフェーズ４は、フェーズ３から、スケジュール情報２がスケジュール実行中キュー１１２に状態遷移し、スケジュール情報５〜１０がスケジュール要求キュー１１１にキューイングされた状態を示す。フェーズ４では、ＩＮ情報、ＩＮ＿ｎｅｗ情報が１０に更新され、ＯＵＴ情報、ＯＵＴ＿ｎｅｗ情報が２に更新される。そして、ＩＮ＿ｏｌｄ情報、ＯＵＴ＿ｏｌｄ情報が、フェーズ３でのＩＮ＿ｎｅｗ情報、ＯＵＴ＿ｎｅｗ情報となる。そして、ＩＮ量は、１０−４＝６となり、ＯＵＴ量は、２−１＝１となり、滞留数は、１０−２＝８となり、増加率は、６÷１＝６となり、閾値＝６０÷６＝１０となる。

図１５の（Ｅ）で示すフェーズ５は、フェーズ４から、スケジュール情報４、５がスケジュール実行中キュー１１２に状態遷移した状態を示す。フェーズ５では、ＩＮ情報、ＩＮ＿ｎｅｗ情報が１０に更新され、ＯＵＴ情報、ＯＵＴ＿ｎｅｗ情報が５に更新される。そして、ＩＮ＿ｏｌｄ情報、ＯＵＴ＿ｏｌｄ情報が、フェーズ４でのＩＮ＿ｎｅｗ情報、ＯＵＴ＿ｎｅｗ情報となる。そして、ＩＮ量は、１０−１０＝０となり、ＯＵＴ量は、５−２＝３となり、滞留数は、１０−５＝５となり、増加率は、０÷３＝０となるから１に補正され、閾値は、５９となる。

図１５の（Ｆ）で示すフェーズ６は、フェーズ５から、スケジュール情報６、７がスケジュール実行中キュー１１２に状態遷移し、スケジュール情報１１〜１３がスケジュール要求キュー１１１にキューイングされた状態を示す。フェーズ６では、ＩＮ情報、ＩＮ＿ｎｅｗ情報が１３に更新され、ＯＵＴ情報、ＯＵＴ＿ｎｅｗ情報が７に更新される。そして、ＩＮ＿ｏｌｄ情報、ＯＵＴ＿ｏｌｄ情報が、フェーズ５でのＩＮ＿ｎｅｗ情報、ＯＵＴ＿ｎｅｗ情報となる。そして、ＩＮ量は、１３−１０＝３となり、ＯＵＴ量は、７−５＝２となり、滞留数は、１３−７＝６となり、増加率は、３÷２＝１．５となり、閾値＝６０÷１．５＝４０となる。

このように、各監視間隔における状態の変化によって、閾値が変化している。この方法を活用し、あらゆる状況で最適な閾値を保つことにより、スケジュールサーバ２０１は、滞留数が閾値を超えた時点で負荷分散の実行を判断することが可能となる。フェーズ６に続くフェーズＮ−１、Ｎにおいて、滞留数が閾値を超える例を示す。

図１６は、閾値の変化例を示す説明図（その３）である。図１６の（Ｇ）で示すフェーズＮ−１は、フェーズ６から、スケジュール情報１０、１１がスケジュール実行中キュー１１２に状態遷移し、スケジュール情報１２〜２０がスケジュール要求キュー１１１にキューイングされた状態を示す。フェーズＮ−１では、ＩＮ情報、ＩＮ＿ｎｅｗ情報が２０に更新され、ＯＵＴ情報、ＯＵＴ＿ｎｅｗ情報が１１に更新される。そして、ＩＮ＿ｏｌｄ情報が１６であり、ＯＵＴ＿ｏｌｄ量は１０となる。そして、ＩＮ量は、２０−１６＝４となり、ＯＵＴ量は、１１−１０＝１となり、滞留数は、２０−１１＝９となり、増加率は、４÷１＝４となり、閾値＝６０÷４＝１５となる。

図１６の（Ｈ）で示すフェーズＮは、フェーズＮ−１から、スケジュール情報１２、１３がスケジュール実行中キュー１１２に状態遷移し、スケジュール情報２１〜３０がスケジュール要求キュー１１１にキューイングされた状態を示す。フェーズＮは、ＩＮ情報、ＩＮ＿ｎｅｗ情報が３０に更新され、ＯＵＴ情報、ＯＵＴ＿ｎｅｗ情報が１３に更新される。そして、ＩＮ＿ｏｌｄ情報、ＯＵＴ＿ｏｌｄ情報が、フェーズＮ−１でのＩＮ＿ｎｅｗ情報、ＯＵＴ＿ｎｅｗ情報となる。そして、ＩＮ量は、３０−２０＝１０となり、ＯＵＴ量は、１３−１１＝２となり、滞留数は、３０−１３＝１７となり、増加率は、１０÷２＝５となり、閾値＝６０÷５＝１２となる。

このように、フェーズＮ−１では、滞留数＝９＜閾値＝１５であったが、フェーズＮでは、滞留数＝１７＞閾値＝１２となっている。従って、フェーズＮが、正に負荷分散を実行するタイミングである。

図１７は、閾値の具体的な算出例を示す説明図である。図１７で示すフェーズ１では、初期設定時であり、閾値は、５９となる。フェーズ１から監視間隔時間経過した図１７で示すフェーズ２では、フェーズ１と比較した増加率が、１．５と増加傾向であると算出される。このように、通常のペースに比べて１．５倍のスピードでスケジュール要求キュー１１１にスケジュール情報がキューイングされている。このため、スケジュールサーバ２０１は、閾値をフェーズ１時の閾値に比べて減少させる。

フェーズ２から監視間隔時間経過した図１７で示すフェーズ３では、フェーズ２と比較した増加率が、２と増加傾向と算出される。このように、通常のペースに比べて２倍のスピードでスケジュール要求キュー１１１にスケジュール情報がキューイングされている。このため、スケジュールサーバ２０１は、閾値を、スケジュール要求最大値の半分まで減少させる。

フェーズ３から監視間隔時間経過した図１７で示すフェーズ４では、フェーズ３と比較した増加率が０．５と１未満になり、減少傾向と算出され、１に補正される。スケジュールサーバ２０１は、閾値を、最大の５９まで増加させる。

次に、図１８を用いて、本実施の形態を実行することにより得られる変動閾値による負荷状態の検出例を示し、図１９を用いて、本実施の形態との比較のため、固定閾値による負荷状態の検出例を示す。

図１８は、変動閾値による負荷状態の検出例を示す説明図である。図１８に示すグラフ１８００は、変動閾値による負荷状態の検出例を示すグラフである。グラフ１８００の横軸は、時刻である。グラフ１８００の縦軸は、滞留数である。

グラフ１８００内のＰ₁は、負荷分散判断時刻である。Ｐ₂は、負荷分散終了時刻である。Ｐ₃は、負荷分散を行わない際に性能限界に到達する時刻である。ｔ₁は、負荷分散にかかる時間である。ｔ₂は、負荷分散判断時刻から性能限界に到達するまでの時間である。

グラフ１８００で示すように、ｔ₁＜ｔ₂となり、早期検出により早期負荷分散処理が可能となり、スケジュールサーバ２０１は、性能限界到達前に負荷分散を完了することができる。

図１９は、固定閾値による負荷状態の検出例を示す説明図である。図１９に示すグラフ１９００は、変動閾値による負荷状態の検出例を示すグラフである。グラフ１９００の横軸は、時刻である。グラフ１９００の縦軸は、滞留数である。

グラフ１９００内のＰ₁〜Ｐ₃、ｔ₁、ｔ₂の定義は、グラフ１８００内のＰ₁〜Ｐ₃、ｔ₁、ｔ₂と同じであるため、説明を省略する。

グラフ１９００で示すように、ｔ₂＜ｔ₁となるため、負荷分散処理完了前に性能限界に到達してしまう。

以上説明したように、スケジュールサーバ２０１は、処理要求されて未処理の処理数と単位時間当たりの処理数との比率に応じた閾値に基づいて、スケジュール処理に用いるリソース量を制御する。これにより、スケジュールサーバ２０１は、閾値が増加率に応じた連続値となり、負荷分散判断のタイミングが適切となって処理遅延を抑制することができる。また、スケジュールサーバ２０１は、予測の範囲を上回る負荷が発生した場合でも、適正な負荷分散を実現することができ、業務運用の遅れが生じない。

また、スケジュールサーバ２０１は、ＩＮ量とＯＵＴ量とから算出した増加率に応じた閾値に基づいて、スケジュール処理に用いるリソース量を制御してもよい。また、スケジュールサーバ２０１は、滞留数とＯＵＴ量との比率に基づいて、スケジュール処理に用いるリソース量を制御してもよい。増加率に基づく場合には、突発的なスケジュール処理要求を検出して、負荷分散実行タイミングとして判断することができる。一方、滞留数とＯＵＴ量との比率に基づく場合には、増加率に基づく場合に比べて閾値は小さい値となり、例えば、スケジュールサーバ２０１は、増加率は小さいけれども滞留数÷ＯＵＴ量が大きい場合には、負荷分散実行タイミングとして判断することができる。

また、スケジュールサーバ２０１は、ＩＮ量やＯＵＴ量として、スケジュール要求の数を用いてもよい。これにより、スケジュールサーバ２０１は、ＩＮ量やＯＵＴ量としてスケジュール要求のデータ量を用いるよりも、高速性で優位となる。

また、本実施の形態は、処理実行装置で実行される処理を、複数の実行サーバに処理を振り分けるスケジュール処理に適用してもよい。これにより、スケジュール処理の高負荷による業務運用の遅れを抑制することができる。

なお、本実施の形態で説明した処理リソース制御方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。本処理リソース制御プログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｃ−Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また本処理リソース制御プログラムは、インターネット等のネットワークを介して配布してもよい。

上述した実施の形態に関し、さらに以下の付記を開示する。

（付記１）コンピュータに、
処理実行装置に対して要求され、処理が開始されていない未処理の処理量と、前記処理実行装置で処理された単位時間あたりの処理量とを取得し、
取得した前記未処理の処理量と前記単位時間あたりの処理量との比率に応じて決定される、処理リソースの追加を行う閾値に基づいて、前記処理実行装置で実行される処理に用いられるリソース量の制御を行う、
処理を実行させることを特徴とする処理リソース制御プログラム。

（付記２）前記コンピュータに、
前記比率として、取得した前記単位時間あたりの処理量に対する前記未処理の処理量の割合を算出し、
未処理の処理を蓄積可能な最大値から前記割合を除算した値を前記閾値として決定する、処理を実行させ、
前記制御を行う処理は、
取得した前記未処理の処理量と決定した前記閾値との比較結果に基づいて、前記処理実行装置で実行される処理に用いられるリソース量の制御を行う、
ことを特徴とする付記１に記載の処理リソース制御プログラム。

（付記３）前記取得する処理は、
さらに、前記処理実行装置に対して単位時間あたりに要求され、処理が開始されていない単位時間あたりの未処理の処理量を取得し、
前記算出する処理は、
前記比率として、取得した前記単位時間あたりの処理量に対する前記単位時間あたりの未処理の処理量の割合を算出する、
ことを特徴とする付記２に記載の処理リソース制御プログラム。

（付記４）前記未処理の処理量は、未処理の処理の数であり、
前記単位時間あたりの処理量は、単位時間あたりの処理の数である、
ことを特徴とする付記１〜３のいずれか一つに記載の処理リソース制御プログラム。

（付記５）前記処理実行装置は、複数のサーバに接続しており、
前記処理実行装置で実行される処理は、前記複数のサーバの各々のサーバに処理を振り分ける処理である、
ことを特徴とする付記１〜４のいずれか一つに記載の処理リソース制御プログラム。

（付記６）処理実行装置に対して要求され、処理が開始されていない未処理の処理量と、前記処理実行装置で処理された単位時間あたりの処理量とを取得し、
取得した前記未処理の処理量と前記単位時間あたりの処理量との比率に応じて決定される、処理リソースの追加を行う閾値に基づいて、前記処理実行装置で実行される処理に用いられるリソース量の制御を行う、
制御部を有することを特徴とする処理リソース制御装置。

（付記７）複数のサーバと、前記複数のサーバのいずれかに処理を振り分けるスケジュール処理を実行する処理リソース制御装置とを有するシステムであって、
前記処理リソース制御装置は、
前記処理リソース制御装置に対して要求され、前記スケジュール処理が開始されていない未処理の処理量と、前記処理リソース制御装置で処理された単位時間あたりの処理量とを取得し、
取得した前記未処理の処理量と前記単位時間あたりの処理量との比率に応じて決定される、処理リソースの追加を行う閾値に基づいて、前記スケジュール処理に用いられるリソース量の制御を行い、
前記複数のサーバの各々は、
前記処理リソース制御装置によって振り分けられた処理を実行する、
ことを特徴とするシステム。

（付記８）コンピュータが、
処理実行装置に対して要求され、処理が開始されていない未処理の処理量と、前記処理実行装置で処理された単位時間あたりの処理量とを取得し、
取得した前記未処理の処理量と前記単位時間あたりの処理量との比率に応じて決定される、処理リソースの追加を行う閾値に基づいて、前記処理実行装置で実行される処理に用いられるリソース量の制御を行う、
処理を実行することを特徴とする処理リソース制御方法。

１０１ 処理リソース制御装置
１１１ スケジュール要求キュー
１１２ スケジュール実行中キュー
２００ システム
２０１ スケジュールサーバ
２０２ 実行サーバ
４０１ イベント型スケジュール投入部
４０２ スケジュール制御部
４０３ 閾値監視部
４０４ 負荷分散制御部
４０５ キュー制御部
４１１ 取得部
４１２ 算出部
４１３ 決定部

Claims (7)

1. コンピュータに、
   処理実行装置に対して要求され、処理が開始されていない未処理の処理量と、前記処理実行装置で処理された単位時間あたりの処理量とを取得し、
   取得した前記未処理の処理量と前記単位時間あたりの処理量との比率に応じて決定される、処理リソースの追加を行う閾値に基づいて、前記処理実行装置で実行される処理に用いられるリソース量の制御を行う、
   処理を実行させることを特徴とする処理リソース制御プログラム。
2. 前記コンピュータに、
   前記比率として、取得した前記単位時間あたりの処理量に対する前記未処理の処理量の割合を算出し、
   未処理の処理を蓄積可能な最大値から前記割合を除算した値を前記閾値として決定する、処理を実行させ、
   前記制御を行う処理は、
   取得した前記未処理の処理量と決定した前記閾値との比較結果に基づいて、前記処理実行装置で実行される処理に用いられるリソース量の制御を行う、
   ことを特徴とする請求項１に記載の処理リソース制御プログラム。
3. 前記取得する処理は、
   さらに、前記処理実行装置に対して単位時間あたりに要求され、処理が開始されていない単位時間あたりの未処理の処理量を取得し、
   前記算出する処理は、
   前記比率として、取得した前記単位時間あたりの処理量に対する前記単位時間あたりの未処理の処理量の割合を算出する、
   ことを特徴とする請求項２に記載の処理リソース制御プログラム。
4. 前記未処理の処理量は、未処理の処理の数であり、
   前記単位時間あたりの処理量は、単位時間あたりの処理の数である、
   ことを特徴とする請求項１〜３のいずれか一つに記載の処理リソース制御プログラム。
5. 前記処理実行装置は、複数のサーバに接続しており、
   前記処理実行装置で実行される処理は、前記複数のサーバの各々のサーバに処理を振り分ける処理である、
   ことを特徴とする請求項１〜４のいずれか一つに記載の処理リソース制御プログラム。
6. 処理実行装置に対して要求され、処理が開始されていない未処理の処理量と、前記処理実行装置で処理された単位時間あたりの処理量とを取得し、
   取得した前記未処理の処理量と前記単位時間あたりの処理量との比率に応じて決定される、処理リソースの追加を行う閾値に基づいて、前記処理実行装置で実行される処理に用いられるリソース量の制御を行う、
   制御部を有することを特徴とする処理リソース制御装置。
7. コンピュータが、
   処理実行装置に対して要求され、処理が開始されていない未処理の処理量と、前記処理実行装置で処理された単位時間あたりの処理量とを取得し、
   取得した前記未処理の処理量と前記単位時間あたりの処理量との比率に応じて決定される、処理リソースの追加を行う閾値に基づいて、前記処理実行装置で実行される処理に用いられるリソース量の制御を行う、
   処理を実行することを特徴とする処理リソース制御方法。

Images