以下に図面を参照して、開示の処理リソース制御プログラム、処理リソース制御装置、および処理リソース制御方法の実施の形態を詳細に説明する。
図1は、本実施の形態にかかる処理リソース制御装置101の動作例を示す説明図である。処理リソース制御装置101は、処理リソースを制御するコンピュータである。具体的には、処理リソース制御装置101は、処理実行装置で実行される処理に用いられるリソース量の制御を行う。
ここで、リソースは、CPU(Central Processing Unit)、メモリといった計算資源である。例えば、処理リソースを追加する場合には、処理リソース制御装置101は、処理を現在実行しているスレッドまたはプロセスを複製し、複製したスレッドまたはプロセスを、処理実行装置に割り当てる。または、処理リソース制御装置101は、複製元のスレッドまたはプロセスを実行する処理実行装置とは別のサーバに、複製したスレッドまたはプロセスを割り当ててもよい。
また、処理実行装置は、どのような処理を実行してもよく、例えば、処理を実行する装置に、処理を振り分けるスケジュール処理を行うスケジュールサーバである。ここで、振り分ける対象となる処理を、「ジョブ」と呼称する。ジョブ管理製品分野では、スケジュールサーバと、ジョブを実行する実行サーバとのシステム構成により運用を実現する。
スケジュールサーバの負荷分散は、以下の点で困難である。まず、スケジュールサーバが、未処理のジョブが滞留して、スケジュール処理が遅延すると、ジョブの実行要求が遅延することがある。これに対して、未処理のジョブの滞留数に対する閾値を事前に設定することにより、負荷分散の判断を行うことが考えられる。しかし、予測できない突発的なスケジュール処理要求が大量に発生した場合には、急激に増加するスケジュール処理の処理量に対して、負荷分散の対処が間に合わない場合がある。
ここで、スケジュール処理要求には、大きく分類して2つの発生要因がある。一方は、指定時刻到来により発生するスケジュール処理要求である。以下、指定時刻到来により発生するスケジュール処理要求を、「時刻型スケジュール処理要求」と呼称する。時刻型スケジュール処理要求は、要求が集中する時間帯を事前に把握することにより、負荷分散のタイミングを予測することができるため、負荷分散を行うことが可能である。
他方は、メッセージ受信等のイベント発生を契機とするスケジュール処理要求である。以下、メッセージ受信等のイベント発生を契機とするスケジュール処理要求を、「イベント型スケジュール処理要求」と呼称する。イベント型スケジュール処理要求は、要求が突発的であり、負荷分散判断のタイミングを予測することが困難である。そして、近年では、イベント型スケジュール処理要求中心のオンデマンド運用が主流である。主流となった原因は、スマートフォンやタブレット端末といった情報端末が発達し、ジョブ管理製品の利用シーンが拡大してきていることである。
そして、イベント型スケジュール処理要求により、処理実行装置の処理遅延が発生する場合がある。具体的には、未処理の処理量に対する閾値を段階的に設定したとしても、突発的な処理要求が発生して、負荷分散が完了する前に性能限界を超えてしまった場合には、処理遅延が発生し、業務として遅延が発生する。
また、ジョブの滞留傾向を予測する技術として、近似曲線を活用した予測が考えられる。この技術により、イベント型スケジュール処理要求の増加を早期に検出する可能性があるが、近似曲線を生成する際に用いるデータが少ないと、誤検出する可能性が高くなる。また、誤検出を避けるために、予測の精度を上げようとすると、監視回数を増やすことになり、結果、負荷分散判断のタイミングに遅れが生じることになる。
また、予測した閾値は、過去の稼働実績やテスト運用から算出した固定値であり、この固定値が、突発的なスケジュール処理要求を検出できるとは限らない。そして、閾値に到達しない限り負荷分散の対処が行えないため、対処が遅れることになる。
そこで、本実施の形態では、スケジュール処理要求され、スケジュール処理が開始されていない未処理の処理数と単位時間当たりの処理数との比率に応じた閾値に基づいて、スケジュール処理に用いるリソース量を制御することについて説明する。
図1を用いて、処理リソース制御装置101の動作例を説明する。図1では、処理実行装置が、処理リソース制御装置101となる例を説明する。また、処理リソース制御装置101は、ジョブを実行する複数の実行サーバと接続する。
処理リソース制御装置101は、処理リソース制御装置101に対して要求され、処理が開始していない未処理の処理量と、処理リソース制御装置101で処理された単位時間あたりの処理量とを取得する。取得する未処理の処理量は、処理リソース制御装置101に対して単位時間あたりで要求され、処理が開始していない未処理の処理量でもよい。
また、処理量は、データ量で計測する考え方とデータ数で計測する考え方と2通り存在する。前者は、スケジュール処理要求のジョブのデータ総量を計測するものである。このため、厳密な情報量を計測できるが関連情報全てを積算するので計測自体に処理時間を要するため、高速性が劣る。一方後者は、スケジュール処理要求を数として捉えるものである。このため、量として捉える前者の考え方に比べると総量積算が無く、スケジュール処理要求の数自体がスケジュール処理中に算出されるものであり、特別な計算をしないで内部情報を使い回せるため、高速性で優位となる。本実施の形態の趣旨が早期判断の実現であることから、処理量については高速性を重視した後者の方式を採用することが好ましい。以下の記載では、処理量を、データ数で計測する考え方を用いて説明する。
ここで、処理リソース制御装置101は、スケジュール要求キュー111とスケジュール実行中キュー112とを有する。スケジュール要求キュー111は、処理リソース制御装置101に対してスケジュール要求され、スケジュール処理が開始していない未処理のジョブに関する情報を蓄えるキューである。また、スケジュール実行中キュー112は、スケジュール処理が終了しており、実行サーバに依頼したジョブに関する情報を蓄えるキューである。
ここで、スケジュール要求キュー111やスケジュール実行中キュー112にキューイングされる、ジョブに関する情報を、「スケジュール情報」と呼称する。スケジュール情報には、要求を受け付けた順序を示す番号と、ジョブのID(IDentifier)とが含まれる。また、スケジュール情報が、スケジュール要求キュー111に含まれる状態、またはスケジュール実行中キュー112に含まれる状態を識別するフラグを有してもよい。また、スケジュール要求キュー111に蓄積可能なスケジュール情報の最大値を、「スケジュール要求最大値」と呼称する。
図1、図6、図14〜図17では、円の中に番号を入れた記号を、スケジュール情報として示す。また、円の輪郭が破線となったスケジュール情報は、該当のキューから移動したことを示す。
図1で示すフェーズ1では、スケジュール要求キュー111には、スケジュール情報1、2がスケジュール要求キュー111にキューイングされている。また、フェーズ1から所定時間として監視間隔時間経過したフェーズ2では、スケジュール情報1、2が状態遷移し、スケジュール実行中キュー112にキューイングされている。さらに、フェーズ2では、スケジュール情報3、4がスケジュール要求キュー111にキューイングされている。
図1で示すように、単位時間となる監視間隔時間で、スケジュール要求キュー111にキューイングされたスケジュール情報は2つであり、スケジュール実行中キュー112に状態遷移したスケジュール情報は2つである。
以下、監視間隔時間で、スケジュール要求キュー111にキューイングされたスケジュール情報の個数を、「IN量」と呼称する。同様に、監視間隔時間で、スケジュール実行中キュー112に状態遷移したスケジュール情報の個数を、「OUT量」と呼称する。
図1の(1)で示すように、処理リソース制御装置101は、IN量として2と、OUT量として2とを取得する。
次に、図1の(2)で示すように、処理リソース制御装置101は、IN量とOUT量との比率を算出する。IN量とOUT量との比率は、OUT量に対するIN量の割合、すなわちIN量÷OUT量でもよいし、IN量に対するOUT量の割合、すなわちOUT量÷IN量でもよい。本実施の形態では、IN量÷OUT量を算出し、算出して得られた値を増加率として定義する。ただし、計算の都合上、分母に0がこないようにするため、処理リソース制御装置101は、OUT量が0の場合、増加率をIN量として算出する。また、増加率を用いて閾値を決定する際の都合上、IN量よりOUT量が大きい場合には、処理リソース制御装置101は、増加率を1として算出する。図1の例では、処理リソース制御装置101は、増加率を2÷2=1と算出する。
そして、図1の(3)で示すように、処理リソース制御装置101は、増加率に応じて決定される、処理リソースの追加を行う閾値を決定する。例えば、処理リソース制御装置101は、スケジュール要求最大値÷増加率を算出し、算出して得られた値を閾値として決定する。ただし、増加率が1以下である場合、および初期設定時には、処理リソース制御装置101は、閾値をスケジュール要求最大値−1として算出する。図1の例では、増加率が1であるため、処理リソース制御装置101は、閾値をスケジュール要求最大値−1と算出する。
次に、図1の(4)で示すように、処理リソース制御装置101は、決定した閾値に基づいて、スケジュール処理で実行される処理に用いられるリソース量の制御を行う。例えば、処理リソース制御装置101は、スケジュール要求キュー111にキューイングされたスケジュール情報の数が閾値を超えている場合、スケジュール処理で実行される処理に用いられるリソース量の追加を行う。
以上により、決定される閾値が増加率に応じた連続値となるため、処理リソース制御装置101は、負荷分散のタイミングが適切となって処理遅延を抑制することができる。
なお、図1の説明では、処理実行装置は、ジョブを振り分けるスケジュール処理を行うスケジュールサーバであったが、これに限らない。例えば、処理実行装置は、ジョブを実行する装置であってもよい。そして、処理リソース制御装置101は、ジョブを実行する装置に対して要求され、ジョブを開始していない未処理のジョブの処理量と、処理された単位時間あたりのジョブの処理量を取得する。そして、処理リソース制御装置101は、未処理のジョブの処理量と、処理された単位時間あたりのジョブの処理量との比率に応じて閾値を決定し、決定した閾値に基づいて、ジョブの実行に用いられるリソースの制御を行ってもよい。次に、処理リソース制御装置101を、スケジュールサーバとして適用した例を、図2を用いて説明する。
図2は、システム200の構成例を示す説明図である。システム200は、スケジュールサーバ201と、実行サーバ202と、クライアント端末203とを有する。スケジュールサーバ201とクライアント端末203とはネットワーク204で接続される。ここで、スケジュールサーバ201は、図1で示した処理リソース制御装置101に相当する。
スケジュールサーバ201は、ジョブのスケジュールを管理するサーバである。実行サーバ202は、ジョブを実行するサーバである。クライアント端末203は、スケジュールサーバ201に、ジョブの実行要求を送信するコンピュータである。
例えば、システム200は、チケット予約システムに適用できる。この場合、実行サーバ202は、チケットの予約を行うサーバである。クライアント端末203は、例えば、チケット予約システムにアクセスする利用者の情報端末となるスマートフォンやタブレット端末であったり、チケット予約システムを提供する企業の担当者の専用端末であったりする。そして、あるチケットの販売時刻となった場合には、クライアント端末203から、チケットの予約要求がスケジュールサーバ201に送信されることになる。
図3は、スケジュールサーバ201のハードウェア構成例を示す説明図である。図3において、スケジュールサーバ201は、CPU301と、ROM(Read−Only Memory)302と、RAM(Random Access Memory)303と、を含む。また、スケジュールサーバ201は、ディスクドライブ304およびディスク305と、通信インターフェース306と、を含む。また、CPU301〜ディスクドライブ304、通信インターフェース306はバス307によってそれぞれ接続される。
CPU301は、スケジュールサーバ201の全体の制御を司る演算処理装置である。CPU301は、複数のプロセッサコアを有してもよい。
ROM302は、ブートプログラムなどのプログラムを記憶する不揮発性メモリである。RAM303は、CPU301のワークエリアとして使用される揮発性メモリである。
ディスクドライブ304は、CPU301の制御に従ってディスク305に対するデータのリードおよびライトを制御する制御装置である。ディスクドライブ304には、例えば、磁気ディスクドライブ、光ディスクドライブ、ソリッドステートドライブなどを採用することができる。ディスク305は、ディスクドライブ304の制御で書き込まれたデータを記憶する不揮発性メモリである。例えばディスクドライブ304が磁気ディスクドライブである場合、ディスク305には、磁気ディスクを採用することができる。また、ディスクドライブ304が光ディスクドライブである場合、ディスク305には、光ディスクを採用することができる。また、ディスクドライブ304がソリッドステートドライブである場合、ディスク305には、半導体素子によって形成された半導体メモリ、いわゆる半導体ディスクを採用することができる。
通信インターフェース306は、ネットワーク204等と内部のインターフェースを司り、他の装置からのデータの入出力を制御する制御装置である。具体的に、通信インターフェース306は、通信回線を通じてネットワーク204等を介して他の装置に接続される。通信インターフェース306には、例えば、モデムやLANアダプタなどを採用することができる。
また、システム200の管理者が、スケジュールサーバ201を直接操作する場合、スケジュールサーバ201は、ディスプレイ、キーボード、マウスといったハードウェアを有してもよい。また、実行サーバ202も、スケジュールサーバ201が有するハードウェアと同等のハードウェアを有する。また、クライアント端末203も、スケジュールサーバ201が有するハードウェアと同等のハードウェアと、ディスプレイ、キーボード、マウスといったハードウェアとを有する。
(スケジュールサーバ201の機能構成例)
図4は、スケジュールサーバ201の機能構成例を示す説明図である。スケジュールサーバ201は、イベント型スケジュール投入部401と、スケジュール制御部402と、閾値監視部403と、負荷分散制御部404と、キュー制御部405と、を含む。閾値監視部403は、取得部411と、算出部412と、決定部413とを有する。制御部となるイベント型スケジュール投入部401〜キュー制御部405は、記憶装置に記憶されたプログラムをCPU301が実行することにより、各部の機能を実現する。記憶装置とは、具体的には、例えば、図3に示したROM302、RAM303、ディスク305などである。また、各部の処理結果は、CPU301のレジスタや、CPU301のキャッシュメモリ、RAM303等に格納される。
また、スケジュールサーバ201は、システム情報テーブル421と、キュー管理テーブル422とにアクセス可能である。システム情報テーブル421と、キュー管理テーブル422とは、RAM303、ディスク305といった記憶装置に格納される。システム情報テーブル421には、スケジュール要求最大値が含まれる。キュー管理テーブル422は、IN量、OUT量、閾値が含まれる。キュー管理テーブル422の詳細については、図5で説明する。
イベント型スケジュール投入部401は、クライアント端末203からジョブの実行依頼を受け付けた際に、スケジュール制御部402にスケジュール情報の投入依頼を通知する。
スケジュール制御部402は、スケジュール処理を実行する。具体的には、スケジュール制御部402は、トリガイベントが発生した際に、スケジュール処理を行い、実行サーバ202にジョブの実行依頼を行う。
閾値監視部403は、キュー管理テーブル422の閾値を監視する。より具体的な機能については、取得部411〜決定部413で説明する。
取得部411は、スケジュール要求キュー111やスケジュール実行中キュー112にキューイングされたスケジュール情報に基づいて、IN量とOUT量とを取得する。さらに、取得部411は、処理実行装置に対して要求され、処理が開始されていない処理量を取得してもよい。処理実行装置に対して要求され、処理が開始されていない処理量は、スケジュール要求キュー111にキューイングされているスケジュール情報の数となる。スケジュール要求キュー111にキューイングされているスケジュール情報の数を、「滞留数」と呼称する。
算出部412は、取得部411が取得したIN量とOUT量とから、増加率を算出する。増加率の算出方法は、図1で説明した通りである。また、算出部412は、滞留数とOUT量との比率を算出してもよい。
決定部413は、算出部412が算出した増加率に応じて閾値を決定する。増加率に応じた閾値の決定方法は、図1で説明した通りである。また、決定部413は、算出部412が算出した増加率を用いず、IN量とOUT量とから、閾値を算出してもよい。例えば、決定部413は、スケジュール要求最大値÷IN量×OUT量を算出し、算出して得られた値を閾値として決定する。ただし、分母となるIN量が0となったり、得られた値がスケジュール要求最大値−1を超えたりする場合には、決定部413は、閾値をスケジュール要求最大値−1として決定する。
また、決定部413は、滞留数とOUT量との比率に応じて閾値を決定してもよい。例えば、決定部413は、スケジュール要求最大値÷滞留数×OUT量を算出し、算出して得られた値を閾値として決定する。ただし、分母となる滞留数が0となったり、得られた値がスケジュール要求最大値−1を超えたりする場合には、決定部413は、閾値をスケジュール要求最大値−1として決定する。決定部413は、決定した閾値をキュー管理テーブル422に格納する。
負荷分散制御部404は、キュー管理テーブル422の閾値に基づいて、スケジュール処理に用いられるリソース量の制御を行う。例えば、負荷分散制御部404は、滞留数と閾値との比較結果に基づいて、リソース量の制御を行う。具体的には、負荷分散制御部404は、滞留数が閾値より大きい場合に、リソースを追加する。また、負荷分散を行って、リソース追加処理を実施中に負荷状況が改善した場合、負荷分散制御部404は、リソース追加処理をキャンセルしてもよいし、継続してもよい。
キュー制御部405は、スケジュール要求キュー111、スケジュール実行中キュー112を制御する。なお、スケジュール要求キュー111、スケジュール実行中キュー112の制御は、スケジュール制御部402が行ってもよい。
図5は、キュー管理テーブル422の一例を示す説明図である。キュー管理テーブル422は、スケジュール要求キュー111とスケジュール実行中キュー112とを管理するテーブルである。また、図5では、キュー管理テーブル422の説明のために、システム情報テーブル421も併せて表示する。
キュー管理テーブル422は、IN情報と、OUT情報と、IN_old情報と、OUT_old情報と、IN_new情報と、OUT_new情報と、滞留数と、IN量と、OUT量と、増加率と、閾値というフィールドを含む。
IN情報フィールドには、スケジュール要求キュー111にキューイングされた最新のスケジュール情報の番号が格納される。OUT情報フィールドには、実行依頼された最新のスケジュール情報の番号が格納される。IN_old情報フィールドには、1回前の定期チェック時に読み込んだ際のIN情報が格納される。OUT_old情報フィールドには、1回前の定期チェック時に読み込んだ際のOUT情報が格納される。IN_new情報フィールドには、今回の定期チェック時に読み込んだ際のIN情報が格納される。OUT_new情報フィールドには、今回の定期チェック時に読み込んだ際のOUT情報が格納される。
滞留数フィールドには、IN_new情報−OUT_new情報で算出される値が格納される。滞留数は、スケジュール要求キュー111に滞留するスケジュール情報の数を示す。
IN量フィールドには、IN_new情報−IN_old情報で算出される値が格納される。IN量は、1回前の定期チェック時から今回の定期チェック時までの間に、スケジュール要求キュー111にキューイングされたスケジュール情報の数を示す。
OUT量フィールドには、OUT_new情報−OUT_old情報で算出される値が格納される。また、算出された値が0である場合、OUT量フィールドには、補正値として1が格納される。OUT量は、1回前の定期チェック時から今回の定期チェック時までの間に、スケジュール実行中キュー112にキューイングされたスケジュール情報の数を示す。
増加率フィールドには、IN量÷OUT量で算出される値が格納される。また、算出された値が1未満である場合、増加率フィールドには、補正値として1が格納される。増加率は、単位時間あたりのスケジュール要求キュー111に含まれるスケジュール情報の増加数を示す。
閾値フィールドには、スケジュール要求最大値÷増加率で算出される値が格納される。また、増加率が1の場合、閾値フィールドには、補正値として、スケジュール要求最大値−1が格納される。
図5には、IN情報、OUT情報の各フィールドに格納された値を、それぞれ、IN、OUTとし、IN_old情報〜閾値情報の各フィールドに格納された値を、それぞれ、A〜Iとし、スケジュール要求最大値をQMAXとしたものを示す。そして、図5では、滞留数〜閾値の各フィールドについて、A〜I、QMAXを用いた具体的な算出式を示す。また、図5において、一点鎖線で囲ったフィールドは、キューイング時や、実行依頼時に更新されるフィールドである。また、点線で囲ったフィールドは、定期チェック時に更新されるフィールドである。また、網掛けを付与したフィールドは、補正される場合があるフィールドである。
図6は、スケジュール要求キュー111とスケジュール実行中キュー112との状態の一例を示す説明図である。図6の(A)は、初期状態を示す。IN情報およびOUT情報は、初期値として0が設定されている。
図6の(B)は、図6の(A)で示した状態の後に、スケジュール要求キュー111にスケジュール情報をキューイングした時の状態を示す。トリガイベントが発生すると、スケジュール情報1がスケジュール要求キュー111にキューイングされるため、IN情報が1に更新される。このように、IN情報は、スケジュール要求キュー111にキューイングされた最新のスケジュール情報の番号を表す。
図6の(C)は、図6の(B)で示した状態の後に、スケジュール情報1の状態遷移が発生した状態を示す。スケジュールサーバ201は、実行サーバ202に、スケジュール情報1のジョブの実行を依頼するため、OUT情報を更新する。このように、OUT情報は、実行依頼した最新のスケジュールの番号を表す。
図6の(D)は、図6の(C)で示した状態の後に、スケジュール情報1、2のジョブの実行が完了しており、スケジュール情報3、4のジョブの実行を依頼しており、スケジュール情報5〜8がスケジュール要求キュー111にキューイングされた状態を示す。この場合、IN情報が8となり、OUT情報が4となる。
次に、図7〜図13を用いて、スケジュールサーバ201が実行するフローチャートを示す。
図7は、キューイング時チェック処理手順の一例を示すフローチャートである。キューイング時チェック処理は、スケジュール情報をスケジュール要求キュー111にキューイングする際に行う処理である。キューイング時チェック処理は、スケジュール制御部402が実行する処理である。
スケジュール制御部402が、システム情報テーブル421からスケジュール要求最大値を取得する(ステップS701)。次に、スケジュール制御部402は、閾値設定処理を実行する(ステップS702)。閾値設定処理については、図11で説明する。そして、スケジュール制御部402が、トリガイベントが発生したか否かを判断する(ステップS703)。トリガイベントが発生していない場合(ステップS703:No)、スケジュール制御部402が、再びステップS703の処理を実行する。このように、スケジュール制御部402は、トリガイベント待ちループを実行することになる。
一方、トリガイベントが発生した場合(ステップS703:Yes)、スケジュール制御部402が、キューイング処理を実行する(ステップS704)。キューイング処理は、図8で説明する。次に、スケジュール制御部402が、滞留数が閾値を超えているか否かを判断する(ステップS705)。滞留数が閾値を超えている場合(ステップS705:Yes)、スケジュール制御部402が、負荷分散実行タイミングと判断する(ステップS706)。そして、スケジュール制御部402が、負荷分散指示を負荷分散制御部404へ通知する(ステップS707)。
ステップS707の処理終了後、または、滞留数が閾値を超えていない場合(ステップS705:No)、スケジュール制御部402が、実行依頼処理を実行する(ステップS708)。ステップS708の処理終了後、スケジュール制御部402が、ステップS703の処理に移行する。キューイング時チェック処理を実行することにより、スケジュール制御部402は、キューイング時に負荷分散を行うべきか否かを判断することができる。
図8は、キューイング処理手順の一例を示すフローチャートである。キューイング処理は、スケジュール情報をスケジュール要求キュー111にキューイングする処理である。また、キューイング処理は、イベント型スケジュール投入部401と、スケジュール制御部402とが協働する処理である。
イベント型スケジュール投入部401が、スケジュール制御部402にスケジュール情報の投入依頼を通知する(ステップS801)。通知を受けたスケジュール制御部402が、キュー管理テーブル422のIN情報をカウントアップする(ステップS802)。次に、スケジュール制御部402が、スケジュール情報をスケジュール要求キュー111にキューイングする(ステップS803)。そして、スケジュール制御部402が、IN情報とOUT情報とから、滞留数を算出する(ステップS804)。次に、スケジュール制御部402が、算出した滞留数でキュー管理テーブル422を更新する(ステップS805)。そして、スケジュール制御部402が、キュー管理テーブル422から閾値を取得する(ステップS806)。
ステップS806の処理終了後、スケジュール制御部402は、キューイング処理を終了する。キューイング処理を実行することにより、スケジュール制御部402は、スケジュール情報をスケジュール要求キュー111にキューイングするとともに、IN情報、滞留数を最新の情報に更新することができる。
図9は、実行依頼処理手順の一例を示すフローチャートである。実行依頼処理は、実行サーバ202にジョブの実行を依頼する処理である。実行依頼処理は、スケジュール制御部402が実行する処理である。
スケジュール制御部402が、キュー管理テーブル422のOUT情報をカウントアップする(ステップS901)。次に、スケジュール制御部402が、スケジュール要求キュー111からスケジュール情報のキューイングを解除する(ステップS902)。そして、スケジュール制御部402が、キューイング解除したスケジュール情報をスケジュール実行中キュー112に状態遷移する(ステップS903)。次に、スケジュール制御部402が、実行サーバ202に、キューイングしたスケジュール情報のジョブの実行依頼を通知する(ステップS904)。
ステップS904の処理終了後、スケジュール制御部402は、実行依頼処理を終了する。実行依頼処理を実行することにより、スケジュール制御部402は、実行サーバ202にジョブの実行を依頼するとともに、OUT情報を最新の情報に更新することができる。
図10は、定期チェック処理手順の一例を示すフローチャートである。定期チェック処理は、負荷分散を行うべきか否かを定期的に確認する処理である。定期チェック処理は、閾値監視部403が実行する処理である。
閾値監視部403が、システム情報テーブル421からスケジュール要求最大値を取得する(ステップS1001)。次に、閾値監視部403が、監視間隔時間が経過したか否かを判断する(ステップS1002)。監視間隔時間が経過していない場合(ステップS1002:No)、閾値監視部403が、再びステップS1002の処理を実行する。一方、監視間隔時間が経過した場合(ステップS1002:Yes)、閾値監視部403が、閾値設定処理を実行する(ステップS1003)。
次に、閾値監視部403が、キュー管理テーブル422のIN情報とOUT情報とから、滞留数を算出する(ステップS1004)。そして、閾値監視部403が、算出した滞留数でキュー管理テーブル422を更新する(ステップS1005)。次に、閾値監視部403が、滞留数が閾値を超えているか否かを判断する(ステップS1006)。滞留数が閾値を超えている場合(ステップS1006:Yes)、閾値監視部403が、負荷分散実行タイミングと判断する(ステップS1007)。次に、閾値監視部403が、負荷分散指示を負荷分散制御部404へ通知する(ステップS1008)。
ステップS1008の処理終了後、または、滞留数が閾値を超えていない場合(ステップS1006:No)、閾値監視部403が、ステップS1002の処理に移行する。定期チェック処理を実行することにより、閾値監視部403は、定期的に負荷分散の判断を行うことができる。
図11は、閾値設定処理手順の一例を示すフローチャートである。閾値設定処理は、閾値を設定する処理である。閾値設定処理は、スケジュール制御部402と、閾値監視部403とが実行する処理である。
まず、スケジュール制御部402が閾値設定処理を実行する場合について説明する。スケジュール制御部402が、キューイング処理から呼ばれたか否かを判断する(ステップS1101)。ここで、スケジュール制御部402が実行する場合には、ステップS1101:Yesとなる。キューイング処理から呼ばれた場合(ステップS1101:Yes)、スケジュール制御部402が、閾値を、スケジュール要求最大値−1として算出する(ステップS1108)。そして、スケジュール制御部402が、算出した閾値でキュー管理テーブル422を更新する(ステップS1109)。そして、スケジュール制御部402が、閾値設定処理を終了する。閾値設定処理を実行することにより、スケジュール制御部402は、閾値の初期設定を行うことができる。
次に、閾値監視部403が閾値設定処理を実行する場合について説明する。閾値監視部403が、キューイング処理から呼ばれたか否かを判断する(ステップS1101)。ここで、閾値監視部403が実行する場合には、ステップS1101:Noとなる。キューイング処理から呼ばれていない場合(ステップS1101:No)、閾値監視部403が、キュー管理テーブル更新初期処理を実行する(ステップS1102)。キュー管理テーブル更新初期処理は、図12で説明する。次に、閾値監視部403が、IN情報=OUT情報となるか否かを判断する(ステップS1103)。
IN情報=OUT情報となる場合(ステップS1103:Yes)、スケジュール要求キュー111にスケジュール情報が1つもないことを示し、閾値監視部403が、ステップS1108の処理を実行する。
一方、IN情報=OUT情報とならない場合(ステップS1103:No)、閾値監視部403が、増加率算出処理を実行する(ステップS1104)。増加率算出処理は、図13で説明する。次に、閾値監視部403が、増加率が1より大きいか否かを判断する(ステップS1105)。増加率が1以下である場合(ステップS1105:No)、閾値監視部403が、増加率を1として、キュー管理テーブル422を更新する(ステップS1106)。そして、閾値監視部403が、ステップS1108の処理を実行する。
一方、増加率が1より大きい場合(ステップS1105:Yes)、閾値監視部403が、閾値を、スケジュール要求最大値/増加率として算出する(ステップS1107)。
ステップS1107、またはステップS1108の処理終了後、閾値監視部403が、ステップS1109の処理を実行する。ステップS1109の処理終了後、閾値監視部403が、閾値設定処理を終了する。閾値設定処理を実行することにより、閾値監視部403は、スケジュール情報の滞留傾向に応じた適切な閾値を設定することができる。
図12は、キュー管理テーブル更新初期処理手順の一例を示すフローチャートである。キュー管理テーブル更新初期処理は、キュー管理テーブル422を更新する際に、IN_old情報、OUT_old情報、IN_new情報、OUT_new情報を初期化する処理である。キュー管理テーブル更新初期処理は、閾値監視部403が実行する処理である。
閾値監視部403が、キュー管理テーブル422からIN情報、OUT情報を取得する(ステップS1201)。次に、閾値監視部403が、IN_new情報でIN_old情報を更新する(ステップS1202)。また、閾値監視部403が、OUT_new情報でOUT_old情報を更新する(ステップS1203)。そして、閾値監視部403が、IN情報でIN_new情報を更新する(ステップS1204)。また、閾値監視部403が、OUT情報でOUT_new情報を更新する(ステップS1205)。
ステップS1205の処理終了後、閾値監視部403は、キュー管理テーブル更新初期処理を終了する。キュー管理テーブル更新初期処理を実行することにより、閾値監視部403は、IN_new情報、OUT_new情報を最新の情報にすることができるとともに、IN_old情報、OUT_old情報を1つ前の情報にすることができる。
図13は、増加率算出処理手順の一例を示すフローチャートである。増加率算出処理は、増加率を算出する処理である。増加率算出処理は、閾値監視部403が実行する処理である。
閾値監視部403が、IN量として、IN_new情報−IN_old情報を算出する(ステップS1301)。また、閾値監視部403が、OUT量として、OUT_new情報−OUT_old情報を算出する(ステップS1302)。そして、閾値監視部403が、算出したIN量とOUT量とでキュー管理テーブル422を更新する(ステップS1303)。
次に、閾値監視部403が、OUT量=0か否かを判断する(ステップS1304)。OUT量=0である場合(ステップS1304:Yes)、閾値監視部403が、OUT量を1として、キュー管理テーブル422を更新する(ステップS1305)。
ステップS1305の処理終了後、または、OUT量=0でない場合(ステップS1304:No)、閾値監視部403が、増加率として、IN量÷OUT量を算出する(ステップS1306)。そして、閾値監視部403が、算出した増加率でキュー管理テーブル422を更新する(ステップS1307)。ステップS1307の処理終了後、閾値監視部403は、増加率算出処理を終了する。増加率算出処理を実行することにより、閾値監視部403は、増加率を得ることができる。続いて、閾値の変化例を、図14〜図16を用いて説明する。
図14は、閾値の変化例を示す説明図(その1)である。図14の(A)で示すフェーズ1は、キュー管理テーブル422、スケジュール要求キュー111、スケジュール実行中キュー112の初期状態を示す。フェーズ1では、スケジュール要求キュー111、スケジュール実行中キュー112にあるスケジュール情報は1つもなく、IN情報〜IN量には0が格納される。また、OUT量は、ステップS1305の処理により、1となる。同様に、増加率は、ステップS1106の処理により、1となり、閾値は、ステップS1108の処理により、59となる。
図14の(B)で示すフェーズ2は、フェーズ1から、スケジュール情報1がスケジュール要求キュー111にキューイングした状態を示す。フェーズ2では、IN情報、IN_new情報が1に更新される。そして、滞留数、IN量、OUT量、増加率が1に更新される。閾値は、ステップS1108の処理により、59となる。
図14の(C)で示すフェーズ3は、フェーズ2から、スケジュール情報1がスケジュール実行中キュー112に状態遷移し、スケジュール情報2〜4がスケジュール要求キュー111にキューイングした状態を示す。フェーズ3では、IN情報、IN_new情報が4に更新され、OUT情報、OUT_new情報が1に更新される。そして、IN_old情報、OUT_old情報が、フェーズ2でのIN_new情報、OUT_new情報となる。そして、IN量は、4−1=3となり、OUT量は、1−0=1となり、滞留数は、4−1=3となり、増加率は、3÷1=3となり、閾値は、60÷3=20となる。
図15は、閾値の変化例を示す説明図(その2)である。図15の(D)で示すフェーズ4は、フェーズ3から、スケジュール情報2がスケジュール実行中キュー112に状態遷移し、スケジュール情報5〜10がスケジュール要求キュー111にキューイングされた状態を示す。フェーズ4では、IN情報、IN_new情報が10に更新され、OUT情報、OUT_new情報が2に更新される。そして、IN_old情報、OUT_old情報が、フェーズ3でのIN_new情報、OUT_new情報となる。そして、IN量は、10−4=6となり、OUT量は、2−1=1となり、滞留数は、10−2=8となり、増加率は、6÷1=6となり、閾値=60÷6=10となる。
図15の(E)で示すフェーズ5は、フェーズ4から、スケジュール情報4、5がスケジュール実行中キュー112に状態遷移した状態を示す。フェーズ5では、IN情報、IN_new情報が10に更新され、OUT情報、OUT_new情報が5に更新される。そして、IN_old情報、OUT_old情報が、フェーズ4でのIN_new情報、OUT_new情報となる。そして、IN量は、10−10=0となり、OUT量は、5−2=3となり、滞留数は、10−5=5となり、増加率は、0÷3=0となるから1に補正され、閾値は、59となる。
図15の(F)で示すフェーズ6は、フェーズ5から、スケジュール情報6、7がスケジュール実行中キュー112に状態遷移し、スケジュール情報11〜13がスケジュール要求キュー111にキューイングされた状態を示す。フェーズ6では、IN情報、IN_new情報が13に更新され、OUT情報、OUT_new情報が7に更新される。そして、IN_old情報、OUT_old情報が、フェーズ5でのIN_new情報、OUT_new情報となる。そして、IN量は、13−10=3となり、OUT量は、7−5=2となり、滞留数は、13−7=6となり、増加率は、3÷2=1.5となり、閾値=60÷1.5=40となる。
このように、各監視間隔における状態の変化によって、閾値が変化している。この方法を活用し、あらゆる状況で最適な閾値を保つことにより、スケジュールサーバ201は、滞留数が閾値を超えた時点で負荷分散の実行を判断することが可能となる。フェーズ6に続くフェーズN−1、Nにおいて、滞留数が閾値を超える例を示す。
図16は、閾値の変化例を示す説明図(その3)である。図16の(G)で示すフェーズN−1は、フェーズ6から、スケジュール情報10、11がスケジュール実行中キュー112に状態遷移し、スケジュール情報12〜20がスケジュール要求キュー111にキューイングされた状態を示す。フェーズN−1では、IN情報、IN_new情報が20に更新され、OUT情報、OUT_new情報が11に更新される。そして、IN_old情報が16であり、OUT_old量は10となる。そして、IN量は、20−16=4となり、OUT量は、11−10=1となり、滞留数は、20−11=9となり、増加率は、4÷1=4となり、閾値=60÷4=15となる。
図16の(H)で示すフェーズNは、フェーズN−1から、スケジュール情報12、13がスケジュール実行中キュー112に状態遷移し、スケジュール情報21〜30がスケジュール要求キュー111にキューイングされた状態を示す。フェーズNは、IN情報、IN_new情報が30に更新され、OUT情報、OUT_new情報が13に更新される。そして、IN_old情報、OUT_old情報が、フェーズN−1でのIN_new情報、OUT_new情報となる。そして、IN量は、30−20=10となり、OUT量は、13−11=2となり、滞留数は、30−13=17となり、増加率は、10÷2=5となり、閾値=60÷5=12となる。
このように、フェーズN−1では、滞留数=9<閾値=15であったが、フェーズNでは、滞留数=17>閾値=12となっている。従って、フェーズNが、正に負荷分散を実行するタイミングである。
図17は、閾値の具体的な算出例を示す説明図である。図17で示すフェーズ1では、初期設定時であり、閾値は、59となる。フェーズ1から監視間隔時間経過した図17で示すフェーズ2では、フェーズ1と比較した増加率が、1.5と増加傾向であると算出される。このように、通常のペースに比べて1.5倍のスピードでスケジュール要求キュー111にスケジュール情報がキューイングされている。このため、スケジュールサーバ201は、閾値をフェーズ1時の閾値に比べて減少させる。
フェーズ2から監視間隔時間経過した図17で示すフェーズ3では、フェーズ2と比較した増加率が、2と増加傾向と算出される。このように、通常のペースに比べて2倍のスピードでスケジュール要求キュー111にスケジュール情報がキューイングされている。このため、スケジュールサーバ201は、閾値を、スケジュール要求最大値の半分まで減少させる。
フェーズ3から監視間隔時間経過した図17で示すフェーズ4では、フェーズ3と比較した増加率が0.5と1未満になり、減少傾向と算出され、1に補正される。スケジュールサーバ201は、閾値を、最大の59まで増加させる。
次に、図18を用いて、本実施の形態を実行することにより得られる変動閾値による負荷状態の検出例を示し、図19を用いて、本実施の形態との比較のため、固定閾値による負荷状態の検出例を示す。
図18は、変動閾値による負荷状態の検出例を示す説明図である。図18に示すグラフ1800は、変動閾値による負荷状態の検出例を示すグラフである。グラフ1800の横軸は、時刻である。グラフ1800の縦軸は、滞留数である。
グラフ1800内のP1は、負荷分散判断時刻である。P2は、負荷分散終了時刻である。P3は、負荷分散を行わない際に性能限界に到達する時刻である。t1は、負荷分散にかかる時間である。t2は、負荷分散判断時刻から性能限界に到達するまでの時間である。
グラフ1800で示すように、t1<t2となり、早期検出により早期負荷分散処理が可能となり、スケジュールサーバ201は、性能限界到達前に負荷分散を完了することができる。
図19は、固定閾値による負荷状態の検出例を示す説明図である。図19に示すグラフ1900は、変動閾値による負荷状態の検出例を示すグラフである。グラフ1900の横軸は、時刻である。グラフ1900の縦軸は、滞留数である。
グラフ1900内のP1〜P3、t1、t2の定義は、グラフ1800内のP1〜P3、t1、t2と同じであるため、説明を省略する。
グラフ1900で示すように、t2<t1となるため、負荷分散処理完了前に性能限界に到達してしまう。
以上説明したように、スケジュールサーバ201は、処理要求されて未処理の処理数と単位時間当たりの処理数との比率に応じた閾値に基づいて、スケジュール処理に用いるリソース量を制御する。これにより、スケジュールサーバ201は、閾値が増加率に応じた連続値となり、負荷分散判断のタイミングが適切となって処理遅延を抑制することができる。また、スケジュールサーバ201は、予測の範囲を上回る負荷が発生した場合でも、適正な負荷分散を実現することができ、業務運用の遅れが生じない。
また、スケジュールサーバ201は、IN量とOUT量とから算出した増加率に応じた閾値に基づいて、スケジュール処理に用いるリソース量を制御してもよい。また、スケジュールサーバ201は、滞留数とOUT量との比率に基づいて、スケジュール処理に用いるリソース量を制御してもよい。増加率に基づく場合には、突発的なスケジュール処理要求を検出して、負荷分散実行タイミングとして判断することができる。一方、滞留数とOUT量との比率に基づく場合には、増加率に基づく場合に比べて閾値は小さい値となり、例えば、スケジュールサーバ201は、増加率は小さいけれども滞留数÷OUT量が大きい場合には、負荷分散実行タイミングとして判断することができる。
また、スケジュールサーバ201は、IN量やOUT量として、スケジュール要求の数を用いてもよい。これにより、スケジュールサーバ201は、IN量やOUT量としてスケジュール要求のデータ量を用いるよりも、高速性で優位となる。
また、本実施の形態は、処理実行装置で実行される処理を、複数の実行サーバに処理を振り分けるスケジュール処理に適用してもよい。これにより、スケジュール処理の高負荷による業務運用の遅れを抑制することができる。
なお、本実施の形態で説明した処理リソース制御方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。本処理リソース制御プログラムは、ハードディスク、フレキシブルディスク、CD−ROM(Compact Disc−Read Only Memory)、DVD(Digital Versatile Disk)等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また本処理リソース制御プログラムは、インターネット等のネットワークを介して配布してもよい。
上述した実施の形態に関し、さらに以下の付記を開示する。
(付記1)コンピュータに、
処理実行装置に対して要求され、処理が開始されていない未処理の処理量と、前記処理実行装置で処理された単位時間あたりの処理量とを取得し、
取得した前記未処理の処理量と前記単位時間あたりの処理量との比率に応じて決定される、処理リソースの追加を行う閾値に基づいて、前記処理実行装置で実行される処理に用いられるリソース量の制御を行う、
処理を実行させることを特徴とする処理リソース制御プログラム。
(付記2)前記コンピュータに、
前記比率として、取得した前記単位時間あたりの処理量に対する前記未処理の処理量の割合を算出し、
未処理の処理を蓄積可能な最大値から前記割合を除算した値を前記閾値として決定する、処理を実行させ、
前記制御を行う処理は、
取得した前記未処理の処理量と決定した前記閾値との比較結果に基づいて、前記処理実行装置で実行される処理に用いられるリソース量の制御を行う、
ことを特徴とする付記1に記載の処理リソース制御プログラム。
(付記3)前記取得する処理は、
さらに、前記処理実行装置に対して単位時間あたりに要求され、処理が開始されていない単位時間あたりの未処理の処理量を取得し、
前記算出する処理は、
前記比率として、取得した前記単位時間あたりの処理量に対する前記単位時間あたりの未処理の処理量の割合を算出する、
ことを特徴とする付記2に記載の処理リソース制御プログラム。
(付記4)前記未処理の処理量は、未処理の処理の数であり、
前記単位時間あたりの処理量は、単位時間あたりの処理の数である、
ことを特徴とする付記1〜3のいずれか一つに記載の処理リソース制御プログラム。
(付記5)前記処理実行装置は、複数のサーバに接続しており、
前記処理実行装置で実行される処理は、前記複数のサーバの各々のサーバに処理を振り分ける処理である、
ことを特徴とする付記1〜4のいずれか一つに記載の処理リソース制御プログラム。
(付記6)処理実行装置に対して要求され、処理が開始されていない未処理の処理量と、前記処理実行装置で処理された単位時間あたりの処理量とを取得し、
取得した前記未処理の処理量と前記単位時間あたりの処理量との比率に応じて決定される、処理リソースの追加を行う閾値に基づいて、前記処理実行装置で実行される処理に用いられるリソース量の制御を行う、
制御部を有することを特徴とする処理リソース制御装置。
(付記7)複数のサーバと、前記複数のサーバのいずれかに処理を振り分けるスケジュール処理を実行する処理リソース制御装置とを有するシステムであって、
前記処理リソース制御装置は、
前記処理リソース制御装置に対して要求され、前記スケジュール処理が開始されていない未処理の処理量と、前記処理リソース制御装置で処理された単位時間あたりの処理量とを取得し、
取得した前記未処理の処理量と前記単位時間あたりの処理量との比率に応じて決定される、処理リソースの追加を行う閾値に基づいて、前記スケジュール処理に用いられるリソース量の制御を行い、
前記複数のサーバの各々は、
前記処理リソース制御装置によって振り分けられた処理を実行する、
ことを特徴とするシステム。
(付記8)コンピュータが、
処理実行装置に対して要求され、処理が開始されていない未処理の処理量と、前記処理実行装置で処理された単位時間あたりの処理量とを取得し、
取得した前記未処理の処理量と前記単位時間あたりの処理量との比率に応じて決定される、処理リソースの追加を行う閾値に基づいて、前記処理実行装置で実行される処理に用いられるリソース量の制御を行う、
処理を実行することを特徴とする処理リソース制御方法。