JP2013186745A - 処理システム及びプログラム - Google Patents

Abstract

【課題】個々のジョブ処理部の状態を監視する監視装置を設けなくても、スケールイン（ジョブ処理部の数の削減）を行う場合に、処理要求の処理が完了したジョブ処理部を停止させる。
【解決手段】監視部１６０はジョブキュー１４２内のジョブ数等から求めた処理グループ１１０の処理負荷が閾値を下回った場合、スケールイン指示をスケールインキュー１４６に送信する。処理グループ１１０内のジョブ処理部１００のうち早い者勝ちでそのスケールイン指示を受け取ったジョブ処理部１００は、ジョブキュー１４２からのジョブの取得を停止し、現在実行中のジョブの実行は継続する。そして、それら実行中のジョブがすべて完了すると、そのジョブ処理部１００は自らを停止するコマンドを発し、これによりそのジョブ処理部１００が消滅することで、処理グループ１１０のスケールインが実現される。
【選択図】図１

Description

本発明は、処理システム及びプログラムに関する。

近年、クラウドコンピューティングサービスのように、サービス提供者の有する計算リソースをユーザに対して例えば課金方式等の形で利用させるシステムが普及しつつある。このようなサービスは、一般に、ユーザのための処理に用いる計算リソースを必要に応じて自動的に増減する、いわゆるオートスケーリング機能を有する。例えばＡｍａｚｏｎ ＥＣ２ (Elastic Compute Cloud)というクラウドサービスでは、ユーザに対してＥＣ２インスタンスと呼ぶ仮想マシンを割り当てるが、処理負荷に応じてそのインスタンスの数を自動的に増減する（非特許文献１参照）。一般的に、インスタンスの数を増加させることを「スケールアウト」、減少させることを「スケールイン」と呼んでいる。例えば、サービスの利用料金が使用するリソースの量に応じて定められている場合、処理負荷が低下したときに使用リソースの量を自動的に減らすことで、利用料金が節約される。

特許文献１には、ロードバランス機能をクライアントとサーバに分散した情報処理システム及びクライアントとサーバに分散したロードバランス機能によって自律的にサーバ間のロードバランスをとる並列ロードバランサ方式が記載されている。この方式のシステムは、初期に指定されているサーバに対してセッション確立要求を送信し、該初期に指定さているサーバからの該セッション確立要求への応答に従ってタスクを実行するサーバを選択するクライアント・ロードバランサを備えるクライアントと、該クライアント・ロードバランサからのセッション確立要求を受けた時に複数のサーバのセッション数を比較して該セッション確立要求への応答を該クライアント・ロードバランサに送信すると共にセッション数を管理するサーバ・ロードバランサを備えるサーバとによって構成される。

特許文献２には、サーバに仮想マシンモニタを搭載して複数の仮想マシンを並列構成で設置し、各仮想マシンの負荷を計測する負荷計測手段と、計測した負荷に応じて必要な資源量を決定する資源量決定手段と、決定した資源量を各仮想マシンに割り当てる資源割り当て手段とを備え、各仮想マシンの資源割り当てを一元的に管理することを特徴とする仮想化サーバ、が開示されている。

特許文献３には、Ｗｅｂ型クライアントサーバシステムにおいて、負荷バランサを用いることなく、各Ｗｅｂサーバの負荷の分散を図るための方法が開示される。この方法では、各Ｗｅｂサーバの各々に対し予め決定された優先順位データテーブルを記憶し、各Ｗｅｂサーバの稼働状態が稼働中又は停止中であるかを把握すると共に、クライアント計算機からリクエストがあった場合には、稼働状態が稼働中であるＷｅｂサーバの中から、優先順位データテーブルに書き込まれた優先順位が最も高いＷｅｂサーバへと、このリクエストを割り振る。リクエストが割り振られたＷｅｂサーバは、自己の負荷が許容負荷以内である場合にはこのリクエストに対するタスクを実行し、自己の負荷が許容負荷よりも大きい場合には、稼働中であるＷｅｂサーバ１３の中の自己以外で優先順位が最も高いＷｅｂサーバへリクエストを転送する。

特許文献４には、要求元にエラーを返さずに処理を継続するトランザクション処理方法が記載されている。この方法では、リクエスト代理装置が受け取ったリクエスト情報を要求情報管理装置に記録し、管理下にある冗長化されたサーバにリクエストを発行する。サーバに障害が発生したときには、記録していたリクエスト情報からトランザクション処理を継続し、他のサーバで処理を引き継ぐ。この方法では、ロードバランサと組み合わせてスケールインする場合も、障害発生と同様の仕組みで、他のサーバに処理を引き継ぐことが可能としている。

特許文献５には、コンピュータのうちの一つに障害が発生したとき、そのコンピュータに登録されていたジョブを二重起動することなしに別のコンピュータで自動的に再起動するシステムが記載されている。このシステムでは、共有ディスク装置は、障害検出手段と接続切替手段をもつ外部記憶装置であり、その接続は複数のコンピュータに対して行われるが、接続切替手段は常時一つのコンピュータからの接続のみを受け付ける。障害検出手段はバッチを処理するコンピュータの障害を検出し、接続切替手段の接続を切替える。平時、共有ディスク装置は現用コンピュータのジョブ情報とジョブ実行結果の記録を行っているが、障害発生時は代替用コンピュータに接続が切替えられ、ジョブ再投入手段群を用いて代替用コンピュータに再投入することで、自動的に再実行を行う。

特開２００２−３４２２９８号公報 特開２００９−２６５７７８号公報 特開２００４−１９２４４９号公報 特開２００８−０２７１８９号公報 特開平１０−３２６２０１号公報

"Auto Scaling"、[online]、[平成24年1月10日検索]、インターネット<http://aws.amazon.com/jp/autoscaling/>

複数の処理部によりユーザからの複数の処理要求を分散処理している場合において、処理負荷が低くなってスケールイン、すなわち一部の処理部を停止させる場合を考える。この場合、処理要求を処理中の処理部を停止させると、その処理要求が処理されないので問題がある。ここで、個々の処理部の状態を監視している監視装置が存在していれば、その監視装置がそれら各処理部から処理要求の処理を完了したものを見出し、そのような処理部を停止させることで、そのような問題が解消される。しかしながら、個々の処理部の状態を監視する監視装置を設けることはシステムのコスト高に繋がり、また監視のための監視装置と各処理部との間の通信のためにネットワークの負荷が高まってしまう。

本発明は、個々の処理部の状態を監視する監視装置を設けなくても、スケールインを行う場合に、処理要求の処理が完了した処理部を停止させることができるようにすることを目的とする。

請求項１に係る発明は、処理グループ宛に到来した処理要求が追加される、当該処理グループに対応づけられた処理要求キューと、前記処理グループに属する１以上の処理部であって、新たな処理要求を受け付け可能になったときに、前記処理要求キューから処理要求を取得し、取得した処理要求を処理する１以上の処理部と、前記処理グループの処理負荷を監視し、当該監視により前記処理グループの処理負荷があらかじめ定められた縮小閾値より低くなったことがわかった場合、当該処理グループに対してグループ縮小指示を発行する監視部と、を備え、前記グループ縮小指示が発せられた場合、前記処理グループのうちのあらかじめ定められた数の前記処理部が停止対象となり、停止対象となった前記処理部は、当該処理グループの処理要求キューからの新たな処理要求の取得を停止すると共に、既に取得済みのすべての処理要求の処理が完了すると動作を停止して前記処理グループから外れる、ことを特徴とする処理システムである。

請求項２に係る発明は、前記処理グループに対応づけられたリカバリキューをさらに備え、前記停止対象となった前記処理部は、前記既に取得済みの処理要求の中に、処理の中断からの再開待ちの状態である再開待ち状態のものがある場合には、当該再開待ち状態の処理要求を前記リカバリキューに追加することで、当該処理要求を前記既に取得済みの処理要求に該当しないものとみなし、前記各処理部は、新たな処理要求を受け付け可能になったときに、前記リカバリキューから優先的に処理要求を取得し、当該リカバリキューに処理要求がない場合に前記処理要求キューから処理要求を取得する、ことを特徴とする請求項１に記載の処理システムである。

請求項３に係る発明は、処理要求の処理の途中段階の処理結果を記憶するための途中結果記憶部、をさらに備え、前記停止対象となった前記処理部は、前記再開待ち状態の処理要求についての当該再開待ち状態の段階までの途中の処理結果を、前記リカバリキューに追加した当該処理要求に対応づけて前記途中処理結果記憶部に記憶させ、前記各処理部は、前記リカバリキューから処理要求を取得した場合に、当該処理要求に対応づけて前記途中処理結果記憶部に記憶されている途中の処理結果を用いることにより、当該処理要求の処理が前記再開待ち状態の段階まで済んだものとして、当該処理を再開する、ことを特徴とする請求項２に記載の処理システムである。

請求項４に係る発明は、前記監視部は、前記監視により前記処理グループの処理負荷があらかじめ定められた拡大閾値より高くなったことがわかった場合、当該処理グループ内の各処理部に対してグループ拡大指示を発行し、前記グループ拡大指示を受け取った各処理部は、自己が停止対象であるがまだ動作の停止に至っていない場合には、自己を停止対象でなくし、前記処理要求キューからの新たな処理要求の取得を再開する、ことを特徴とする請求項１〜３のいずれか１項に記載の処理システムである。

請求項５に係る発明は、前記処理グループに対応づけられた縮小指示キューをさらに備え、前記監視部は、前記処理グループに対して発行するグループ縮小指示を、当該処理グループに対応づけられた前記縮小指示キューに追加し、前記各処理部は、それぞれ、処理負荷があらかじめ定められた停止対象閾値より低い場合にのみ、前記縮小指示キューからの前記グループ縮小指示の取得動作を行い、この取得動作により前記グループ縮小指示が取得できた場合に、前記停止対象となる、ことを特徴とする請求項１〜４のいずれか１項に記載の処理システムである。

請求項６に係る発明は、コンピュータを、処理グループ宛に到来した処理要求が追加される、当該処理グループに対応づけられた処理要求キュー、前記処理グループに属する１以上の処理部であって、新たな処理要求を受け付け可能になったときに、前記処理要求キューから処理要求を取得し、取得した処理要求を処理する１以上の処理部、前記処理グループの処理負荷を監視し、当該監視により前記処理グループの処理負荷があらかじめ定められた縮小閾値より低くなったことがわかった場合、当該処理グループに対してグループ縮小指示を発行する監視部、として機能させるためのプログラムであって、前記グループ縮小指示が発せられた場合、前記処理グループのうちのあらかじめ定められた数の前記処理部が停止対象となり、停止対象となった前記処理部は、当該処理グループの処理要求キューからの新たな処理要求の取得を停止すると共に、既に取得済みのすべての処理要求の処理が完了すると動作を停止して前記処理グループから外れる、ことを特徴とするプログラムである。

請求項７に係る発明は、前記コンピュータを、前記処理グループに対応づけられたリカバリキューとして更に機能させると共に、前記停止対象となった前記処理部は、前記既に取得済みの処理要求の中に、処理の中断からの再開待ちの状態である再開待ち状態のものがある場合には、当該再開待ち状態の処理要求を前記リカバリキューに追加することで、当該処理要求を前記既に取得済みの処理要求に該当しないものとみなし、前記各処理部は、新たな処理要求を受け付け可能になったときに、前記リカバリキューから優先的に処理要求を取得し、当該リカバリキューに処理要求がない場合に前記処理要求キューから処理要求を取得する、ことを特徴とする請求項６に記載のプログラムである。

請求項８に係る発明は、前記コンピュータを、処理要求の処理の途中段階の処理結果を記憶するための途中結果記憶部として更に機能させると共に、前記停止対象となった前記処理部は、前記再開待ち状態の処理要求についての当該再開待ち状態の段階までの途中の処理結果を、前記リカバリキューに追加した当該処理要求に対応づけて前記途中処理結果記憶部に記憶させ、前記各処理部は、前記リカバリキューから処理要求を取得した場合に、当該処理要求に対応づけて前記途中処理結果記憶部に記憶されている途中の処理結果を用いることにより、当該処理要求の処理が前記再開待ち状態の段階まで済んだものとして、当該処理を再開する、ことを特徴とする請求項７に記載のプログラムである。

請求項９に係る発明は、前記監視部は、前記監視により前記処理グループの処理負荷があらかじめ定められた拡大閾値より高くなったことがわかった場合、当該処理グループ内の各処理部に対してグループ拡大指示を発行し、前記グループ拡大指示を受け取った各処理部は、自己が停止対象であるがまだ動作の停止に至っていない場合には、自己を停止対象でなくし、前記処理要求キューからの新たな処理要求の取得を再開する、ことを特徴とする請求項６〜８のいずれか１項に記載のプログラムである。

請求項１０に係る発明は、前記コンピュータを、前記処理グループに対応づけられた縮小指示キューとして更に機能させると共に、前記監視部は、前記処理グループに対して発行するグループ縮小指示を、当該処理グループに対応づけられた前記縮小指示キューに追加し、前記各処理部は、それぞれ、処理負荷があらかじめ定められた停止対象閾値より低い場合にのみ、前記縮小指示キューからの前記グループ縮小指示の取得動作を行い、この取得動作により前記グループ縮小指示が取得できた場合に、前記停止対象となる、ことを特徴とする請求項６〜９のいずれか１項に記載のプログラムである。

請求項１又は６に係る発明によれば、個々の処理部の状態を監視する監視装置を設けなくても、スケールインを行う場合に、処理要求の処理が完了した処理部を停止させることができる。

請求項２又は７に係る発明によれば、停止対象となった処理部がいつ完了するか不明である再開待ち状態の処理要求の処理を完了させてから停止する場合よりも、より早く処理グループの縮小（すなわち処理グループ内の処理部の削減）を実行することができる。

請求項３又は８に係る発明によれば、停止対象となった処理部がリカバリキューに追加された処理要求を別の処理部が実行する際に、その処理要求のための処理を最初から実行するよりも早く、処理を行うことができる。

請求項４又は９に係る発明によれば、処理グループの処理能力を高める（処理部の数を増やす）必要がでてきた場合に、新たな処理部を立ち上げるよりも素早く、処理能力の増強を実現することができる。

請求項５又は１０に係る発明によれば、処理グループ内のすべての処理部がグループ縮小指示を取得できる場合よりも、処理グループをより早く縮小することができる。

実施形態のシステム構成の例を示す図である。 監視部の処理手順の一例を示すフローチャートである。 ジョブ処理部のジョブ取得動作の手順の一例を示すフローチャートである。 ジョブ処理部のジョブ実行動作の手順の一例を示すフローチャートである。 ジョブ処理部のスケールインのための処理手順の一例を示すフローチャートである。 ジョブ処理部のスケールイン指示の受付可否の切換のための処理手順の一例を示すフローチャートである。 ジョブ処理部のスケールアウトのための処理手順の一例を示すフローチャートである。 再開待ちのジョブがないジョブ処理部がスケールインのために停止する処理の流れの一例を示す図である。 再開待ちのジョブがあるジョブ処理部がスケールインのために停止する処理の流れの一例を示す図である。 第１段階及び第２段階のスケールアウトが行われる流れの例を示す図である。

図１に、本実施形態の処理システムの例を示す。以下において、「スケールイン」とは、処理グループ１１０の規模縮小、すなわち当該処理グループ１１０に所属するジョブ処理部１００の数を減少させる処理を意味し、「スケールアウト」とは、処理グループ１１０の規模拡大、すなわち当該処理グループ１１０に所属するジョブ処理部１００の数を増大させる処理を意味する。

図１のシステムは、図示省略したクライアント装置から、インターネット等のネットワークを介して処理要求を受け取り、それら処理要求に応じた処理を複数のジョブ処理部１００で分散処理する。個々のジョブ処理部１００は、物理的に単体のコンピュータであってもよいし、仮想マシン（すなわちジョブ処理部１００のクラスのインスタンス）であってもよいし、一つの仮想マシン上で複数の顧客向けのサービスを提供する処理を実行するシステムにおける、各顧客向けの処理部であってもよい。複数のジョブ処理部１００は、典型的にはクラウドコンピューティングシステム等のようにネットワーク上に分散しているが、単体のコンピュータ上で設けられる構成もあり得る。処理要求により要求される処理、すなわち、システム内のジョブ処理部１００により実行（あるいは複数のジョブ処理部１００により並列実行）される処理には特に限定はないが、一例を挙げるとすれば、クライアント装置であるデジタル複合機（複写機、スキャナ、プリンタ等の機能を併せ持つ多機能装置）でスキャンされた文書の画像に対して光学文字認識（ＯＣＲ）処理を施し、その文書中の各項目のデータを抽出してデータベースに登録する処理などがある。処理要求には、要求する処理の内容をあらかじめ定められたフォーマットに従って記述した処理手順情報が含まれる。処理手順情報が表す処理は、例えば、個々のコマンドで表される単位的な処理（「タスク」と呼ぶ）が１以上連なった処理フローである。また、処理要求には、処理手順情報が規定する処理の対象となる対象データが含まれていてもよい。対象データは、画像データや、ワードプロセッサや表計算などのアプリケーションで生成された文書データ等、どのようなものであってもよい。また、処理要求には、そのような対象データの実体の代わりに、その実体が格納されたネットワーク上の格納場所を指し示す参照情報が含まれていてもよい。なお、処理要求を発するクライアント装置は、複合機に限られるものではなく、パーソナルコンピュータやファクシミリ装置等といった、情報処理機能を備えた他の種類の装置であってもよい。

このシステムは、多数のジョブ処理部１００を有しており、それらジョブ処理部１００のうちの一部をユーザに対して提供する。ここで言うユーザは、個人の場合もあれば、企業のような複数の個人を含んだグループの場合もある。例えば、このシステムは、個々のユーザに対してそれぞれ、１以上のジョブ処理部１００を含んだ処理グループ１１０を割り当て、その処理グループ１１０内の複数のジョブ処理部１００により、当該ユーザからの処理要求を分散処理する。各ジョブ処理部１００は、それぞれ、自己がどの処理グループ１１０に属しているかを知っており（例えばジョブ処理部１００が起動される際に、所属する処理グループのＩＤが通知されるなどの方法による）、所属先の処理グループ１１０に対するジョブを取得して処理する。なお、１ユーザに対して割り当てられる処理グループ１１０は１つに限らなくてもよい。また、複数の契約者で1つの処理グループを共有するが、複数の契約者間の処理は排他的に行う、いわゆるマルチテナントの処理を行うようにしてもよい。

クライアント装置から本システムに送られてきた処理要求は、ジョブ投入部１２０により受け取られる。ジョブ投入部１２０は、受け取った処理要求に含まれる処理手順情報から、本システム内での当該処理要求に対する処理の管理のための「ジョブ」（すなわちジョブは処理要求に対応する処理を表す）を生成し、生成したジョブをジョブ管理部１５０及びキュー管理部１３０に登録する。このとき、生成したジョブには、システム内での各ジョブを一意に識別するジョブＩＤ（識別子）が付与され、ジョブ管理部１５０には、そのジョブＩＤに対応づけて、当該処理要求に含まれていた処理手順情報や対象データ等が登録される。これらの情報は、各ジョブ処理部１００がジョブを実行する際に利用される。また、ジョブ管理部１５０は、各ジョブの実行状態（例えば、未実行、実行中、正常終了、エラー等）の情報をジョブ処理部１００等から得て、ジョブＩＤに対応づけて管理してもよく、この場合、実行状態の情報は要求に応じてクライアント装置に提供される。また、詳細は後述するが、スケールインのために停止対象となったジョブ処理部１００から差し戻された実行途中のジョブの途中段階の処理結果のデータ（以下「途中処理結果データ」と呼ぶ）をジョブＩＤに対応づけて記憶する、途中処理結果記憶部１５２を有していてもよい。

キュー管理部１３０は、本システムが受け付けた処理要求に対応するジョブ群の実行順序を、先入れ先出し方式で管理するためのキュー（待ち行列）構造を管理する。本システムでは、キュー構造として、ジョブキュー１４２、リカバリキュー１４４、及びスケールインキュー１４６という３種類のキューを用いる。

ジョブキュー１４２は、ジョブ投入部１２０から投入されたジョブを保持するキューである。投入されたジョブはジョブキュー１４２の末尾に追加され、先入れ先出し方式でジョブキュー１４２の先頭から取り出され、ジョブ処理部１００に提供される。

リカバリキュー１４４は、スケールイン処理を行うために停止対象とされたジョブ処理部１００から差し戻された実行途中のジョブ（詳細は後述）を保持するキューである。投入されたジョブはリカバリキュー１４４の末尾に追加され、先入れ先出し方式でリカバリキュー１４４の先頭から取り出され、ジョブ処理部１００に提供される。

ジョブキュー１４２とリカバリキュー１４４との間には、優劣関係が設定されている。すなわち、本システムでは、リカバリキュー１４４内のジョブの方がジョブキュー１４２内のジョブよりも優先して処理される。すなわち、各ジョブ処理部１００は、リカバリキュー１４４内にジョブがある間はリカバリキュー１４４からジョブを取得し、リカバリキュー１４４が空になって初めて、ジョブキュー１４２からジョブを取得する。

この例では、ジョブキュー１４２及びリカバリキュー１４４にはジョブＩＤのみが入れられ、ジョブの実体的なデータや管理情報はジョブ管理部１５０に保持されるが、このような構成はあくまで例示的なものである。

ジョブキュー１４２及びリカバリキュー１４４がジョブを保持するキューであるのに対し、スケールインキュー１４６は、スケールイン指示（より厳密には、スケールインすべきことを表すあらかじめ定められた指示情報）を保持するキューである。本システムでは、スケールインの必要が生じた際に、あらかじめ定められた数（これが一回のスケールイン動作の際に停止させようとするジョブ処理部の数であり、例えば「１」である）のスケールイン指示が発せられ、そのスケールイン指示がスケールインキュー１４６に追加される。そして、各ジョブ処理部１００は、自律的にスケールインキュー１４６からのスケールイン指示の取得動作を行い、その結果スケールイン指示を受け取ったジョブ処理部１００のみが、スケールインのための停止対象となる。

また、本システムは、上述した３つのキュー１４２〜１４６に加え、スケールアウトトピック１４８と呼ぶ、トピック形式のメッセージ伝達機構も用いる。例えばＪＭＳ（Java (登録商標)Message Service）に用意されているように、「キュー」が１つの受け手に対してメッセージを伝達する機構であるのに対し、「トピック」は、関連する複数の受け手に対してメッセージを伝達（同報）する機構である。スケールアウトトピック１４８には、スケールアウトの必要が生じた際に、スケールアウト指示が入れられる。スケールアウトトピック１４８に入れられたスケールアウト指示は、当該トピック１４８に対応する処理グループ１１０内のすべてのジョブ処理部１００により取得される。後で詳しく説明するが、本システムには、キューからジョブを取得（消費）して実行しているいわば現役のジョブ処理部１００（以下、「通常稼働」状態のジョブ処理部１００という）だけでなく、スケールインのための停止対象となって新たなジョブ消費は停止しているものの既に取得済みのジョブが完了するまでは存在して処理を実行する、いわば退役準備中のジョブ処理部１００（以下、「停止準備状態」のジョブ処理部１００と呼ぶ）があり、スケールアウトトピック１４８は後者の停止準備状態のジョブ処理部１００を通常稼働状態に復帰させるために用いられる。

なお、本システムでは、このような停止準備状態のジョブ処理部１００を通常稼働状態に復帰させる第１段階のスケールアウトの他に、処理グループ１１０に属するジョブ処理部１００を新たに生成する第２段階のスケールアウトも行われる。むしろ、この第２段階のスケールアウトが、一般的な意味でのスケールアウトに該当する。なお、これら２段階のスケールアウトについては、後で詳しく説明する。

本システムでは、キュー管理部１３０は、処理グループ１１０毎に、このようなジョブキュー１４２、リカバリキュー１４４、スケールインキュー１４６、及びスケールアウトトピック１４８を含んだキュー構造１４０を有している。各ジョブ処理部１００は、自己の属する処理グループ１１０に対応するキュー構造１４０から、ジョブやスケールイン指示、スケールアウト指示を受け取って処理を実行する。

また、本システムでは、これら各処理グループ１１０のジョブキュー１４２に保持されるジョブの数は、ジョブ管理部１５０にて管理されており、キューへのジョブの追加、及びキューからのジョブの取り出しに応じて随時更新される。なお、このようにジョブ数をジョブ管理部１５０で管理する代わりに、キュー管理部１３０で管理してももちろんよい。

本システムは、処理グループ１１０に属するジョブ処理部１００の数を、その処理グループ１１０の処理負荷に応じて自動的に調整する、オートスケーリング機能を有している。すなわち、本システムでは、処理グループ１１０の処理負荷が増大すればその増大分に応じてその処理グループ１１０に対して新たなジョブ処理部１００を追加し、処理負荷が減少すればその減少分に応じてその処理グループ１１０に属するジョブ処理部１００を減少させる。これにより、例えば、処理グループ１１０の応答時間（処理要求を送ってからその結果が得られるまでの時間）をほぼ一定に保つために必要最低限の数のジョブ処理部１００が稼働している状態が維持される。稼働させるジョブ処理部１００の数が課金に反映される場合等には、このようにサービス品質を維持できる最低限のジョブ処理部１００のみを稼働させることが望まれることがある。

本システムのオートスケーリング機能は、監視部１６０及びオートスケーラー１７０による中央での管理と、個々のジョブ処理部１００によるスケールイン指示及びスケールアウト指示に応じた自律的な動作と、の協働により実現される。

監視部１６０は、処理グループ１１０毎に、その処理グループ１１０をスケールアウト（ジョブ処理部１００を増すこと）又はスケールイン（減らすこと）する判断材料となる情報を監視し、その監視の結果に応じてスケールイン又はスケールアウトの要否を判定する。この判断材料の情報は、処理グループ１１０の処理負荷の量である。そして、その判定の結果に応じて、スケールイン又はスケールアウトの指示をキュー管理部１３０に送る。このような監視部１６０の詳細な処理手順の一例を図２に示す。監視部１６０は、システム内に存在する処理グループ１１０毎に、図２の手順を実行する（あるいは、処理グループ１１０毎に、それぞれ専用の監視部１６０が動作していると考えてもよい）。

図２の手順では、監視部１６０は、あらかじめ定められた時間間隔で到来するタイミングのような、あらかじめ定められた規則によって決まる監視タイミングの到来を待つ（Ｓ１０）。監視タイミングが到来すると、監視対象の処理グループ１１０の処理負荷の指標値を、ジョブ管理部１５０から取得する（Ｓ１２）。この指標値は、例えば、当該処理グループ１１０のジョブキュー１４２内に存在しているジョブの数である。このジョブ数が多いほど、未処理のジョブが多いということであり、処理グループ１１０の現状の処理能力（基本的にジョブ処理部１００の数が多いほど高くなる）に比して実行すべきジョブの数が多く、新たなジョブが処理グループ１１０により処理されるまでに時間がかかるという意味で、処理負荷が高いことになる。この例では、監視部１６０は、監視対象の処理グループ１１０に対応するジョブキュー１４２内のジョブ数をジョブ管理部１５０から取得する。

監視部１６０は、取得した処理負荷の指標値を、あらかじめ定められたスケールイン閾値と比較（図示例では、指標値がスケールイン閾値未満かどうかを判定）する（Ｓ１４）。そして、処理負荷の指標値がそのスケールイン閾値よりも低い場合（Ｓ１４の判定結果がＹｅｓ）には、監視部１６０は、監視対象の処理グループ１１０についてスケールインが必要と判定し、その処理グループ１１０に対応するスケールインキュー１４６に、あらかじめ定めた数（例えば１つ）のスケールイン指示を追加する（Ｓ１６）。スケールインキュー１４６内のスケールイン指示は、先入れ先出し順に、アクセスしてきた当該処理グループ１１０内のジョブ処理部１００により当該キュー１４６の先頭から取り出される。

また、処理負荷の指標値がスケールイン閾値以上の場合（Ｓ１４の判定結果がＮｏ）、監視部１６０は、その指標値をあらかじめ定められた第１スケールアウト閾値と比較（図示例では、指標値が第１スケールアウト閾値より高いかどうかを判定）する（Ｓ１８）。ここで用いる第１スケールアウト閾値は、スケールイン閾値以上の値である。そして、処理負荷の指標値が第１スケールアウト閾値よりも高い場合（Ｓ１８の判定結果がＹｅｓ）には、監視部１６０は、監視対象の処理グループ１１０についてスケールアウトが必要と判定し、その処理グループ１１０に対応するスケールアウトトピック１４８にスケールアウト指示を送信する（Ｓ２０）。スケールアウトトピック１４８が受け取ったスケールアウト指示は、当該処理グループ１１０に属するすべてのジョブ処理部１００により取得される。（ジョブ処理部１００のスケールアウト関連の処理手順については後述する図７参照）。

なお、このスケールアウトトピック１４８を用いたスケールアウトは、前述した第１段階のスケールアウト、すなわち停止準備状態のジョブ処理部１００を通常稼働状態に戻す処理である。例えば、停止準備状態のジョブ処理部１００が存在しない場合等のように、この第１段階のスケールアウトで間に合わない（すなわち処理負荷の低減効果が得られない）場合もある。このような場合には、第２段階のスケールアウト（すなわち一般的な意味でのスケールアウト）、すなわち、新たなジョブ処理部１００を生成して、スケールアウトの対象の処理グループ１１０に所属させる処理を行うこととなる。

すなわち、図２の手順では、監視部１６０は、さらに、監視対象の処理グループ１１０の処理負荷の指標値を、第１スケールアウト閾値よりも高い第２スケールアウト閾値と比較する（Ｓ２２）。すなわち、処理グループ１１０の処理負荷が第１スケールアウト閾値よりも大きくなると第１段階のスケールアウトが行われる（試みられる）が、停止準備中のジョブ処理部１００をすべて通常稼働（ジョブ消費）状態に戻しても処理負荷の増大が解消されないと、いずれ処理負荷が第２スケールアウト閾値よりも大きくなり、Ｓ２２の判定結果がＹｅｓとなる。Ｓ２２の判定結果がＹｅｓとなると、監視部１６０は、オートスケーラー１７０に対して、当該処理グループ１１０に対して通常のスケールアウト（すなわち新規のジョブ処理部１００をあらかじめ定められた数だけ追加すること）を依頼する（Ｓ２４）。オートスケーラー１７０は、ジョブ処理部１００群を管理するシステム（例えば仮想マシン群を管理するサーバ）に対してジョブ処理部の生成を指示する生成コマンドを発することにより、仮想マシンとしてのジョブ処理部１００を新たに生成する。生成されたジョブ処理部１００には、スケールアウト対象であるその処理グループ１１０のＩＤが通知（例えば生成コマンドの引数として）される。これにより、その生成されたジョブ処理部１００は、その処理グループ１１０に所属することとなる。すなわち、そのジョブ処理部１００は、キュー管理部１３０にアクセスしたときに、その通知された処理グループ１１０のＩＤを提示することで、自己が所属する処理グループ１１０宛のジョブや各種指示を受け取ることが可能となる。なお、オートスケーラー１７０が実行する第２段階のスケールアウト処理は、従来のオートスケーラーが行うスケールアウト処理と同様のものである。

処理グループ１１０の処理負荷が、スケールイン閾値以上、且つ、第１スケールアウト閾値以下の場合は、その処理グループ１１０についてはスケールインのための処理もスケールアウトのための処理も行われない。

なお、本システムでは、スケールインは監視部１６０によるスケールイン指示に応じて実現されるので、オートスケーラー１７０はスケールインのための処理を実行しなくてよい。なお、公知のオートスケーラー１７０に、この実施形態の監視部１６０の機能を持たせるようにしてももちろんよい。

以上の説明では、ジョブキュー１４２内のジョブ数を処理負荷の指標値としたが、この代わりに、ジョブキュー１４２とリカバリキュー１４４内のジョブ数との和を処理負荷の指標値として用いてもよい。また、キュー１４２（及び１４４）内のジョブ数だけでなく、ジョブ管理部１５０が管理している処理グループ１１０に関する他の情報も加味して、その処理グループ１１０の処理負荷の指標値を求めてもよい。

次に、ジョブ処理部１００の動作について説明する。ジョブ処理部１００の動作には、ジョブを取得して実行するという基本動作と、スケールインの指示の取得及びその指示に対応する動作と、スケールアウトの指示の取得及びその指示に対応する動作と、が含まれる。以下、それら各動作の流れを順に説明する。

基本動作の処理手順の一例を、図３及び図４に示す。図３の処理はジョブ処理部１００がジョブを受け付ける際の処理であり、図４の処理はジョブ処理部１００が受け付けたジョブを実行する際の処理である。この例では、ジョブ処理部１００は複数のスレッド又はプロセス等を走らせることで複数のジョブを並列に実行することが可能であるとする（ただし、これに限られるものではない。）図３に示すように、ジョブ処理部１００は、新たなジョブを受け付け可能な状態になる毎に（Ｓ３０）、自己の属する処理グループ１１０に対応するキュー構造１４０から、新たなジョブを取得する。例えば、当該ジョブ処理部１００が同時実行可能な上限ジョブ数よりも、実際に同時実行しているジョブ数が少なくなった場合に、Ｓ３０で新規ジョブが受け付け可能と判定される。また、別の例では、ジョブ処理部１００が、キュー構造１４０から取得したジョブを入れる自前のキューを有し、そのキューからジョブを順次取得して実行していく構成を有している場合、そのキュー内の実際のジョブ数がそのキューに保持可能なジョブの上限数よりも少ない場合に、新規ジョブが受け付け可能と判定される。

このように新規ジョブが受け付け可能な場合に、ジョブ処理部１００は、ジョブキュー１４２とリカバリキュー１４４のうちの後者から優先的にジョブを取得する。すなわち、ジョブ処理部１００は、Ｓ３０の判定がＹＥＳの場合、まず、当該ジョブ処理部１００が所属する処理グループ１１０（ジョブ処理部１００は、自己の属する処理グループ１１０のＩＤを有している）のキュー構造１４０内のリカバリキュー１４４から、先頭のジョブを取得する（Ｓ３２）。

Ｓ３２でリカバリキュー１４４からジョブ（のＩＤ）を取得できた場合（Ｓ３４の判定結果がＹｅｓ）、ジョブ処理部１００は、ジョブ管理部１５０から、そのジョブの詳細情報（処理手順情報等）と途中処理結果（及び、その途中処理結果が処理手順内のどのタスクまでの実行結果なのかを示す情報）を取得する（Ｓ４２）。そして、処理手順情報が示すフローの最初からその途中処理結果の段階までのタスクをスキップ（すなわち実際には実行せずに、それらタスクの実行が済んだものとみなすこと）し、途中処理結果に応じてジョブ処理部１００内のそのジョブを実行するスレッド又はプロセス等の内部状態等をセットすることで、そのスレッド等の状態がそのジョブを再開待ち状態の段階となるようにする（Ｓ４４）。そして、図４の処理に進むことで、スケールインのために別のジョブ処理部１００がリカバリキュー１４４に差し戻したジョブが、この図３の手順を実行している当該ジョブ処理部１００により再開されることになる。

リカバリキュー１４４が空の場合は、リカバリキュー１４４からジョブが取得できない（Ｓ３４の判定結果がＮｏ）。この場合に初めて、ジョブ処理部１００は、ジョブキュー１４２から先頭のジョブ（すなわちジョブＩＤ）を取得する（Ｓ３６）。ただし、ジョブキュー１４２にジョブがない場合は、Ｓ３６ではジョブを取得できない（Ｓ３８の判定結果がＮＯ）。この場合は、Ｓ３０以下の処理を繰り返すことになる。Ｓ３６でジョブが取得できた場合（Ｓ３８の判定結果がＹｅｓ）、ジョブ処理部１００は、そのジョブについて図４の処理に進む。

ジョブ処理部１００は、図３の受付処理で受け付けたジョブ毎に、図４の処理を実行する。この処理では、Ｓ３６でジョブキュー１４２から取得したジョブＩＤを取得したジョブについては、そのジョブＩＤに対応するジョブの詳細情報（例えば処理手順情報や対象データ）をジョブ管理部１５０から取得し、その詳細情報を用いてジョブの実行を開始する（Ｓ４０）。なお、ジョブキュー１４２の先頭から取得されたジョブは、そのキュー１４２から削除される（リカバリキュー１４４についても同様）。また、Ｓ３２でリカバリキュー１４４からジョブＩＤを取得したジョブについては、Ｓ４２及びＳ４４でそのジョブ実行状態を再開待ち状態の段階まで進めた状態から、そのジョブの実行を再開する（Ｓ４０）。

その後、そのジョブの実行が完了するまで（Ｓ４６）、そのジョブの処理を、処理手順情報に示されるフローに従って、タスクを順に実行していく。この実行の中で、ジョブが中断され、再開待ち状態に入ることがある。例えば、ジョブの中でユーザとの対話処理を行う場合には、ユーザに対して入力画面を提示した後は、ジョブ処理部１００は、いったんそのジョブの処理を中断し、そのジョブについて再開待ち状態となり、その入力画面に対してユーザがデータを入力し、入力したデータを送信（すなわち、正しい入力データであると確認）するのを待つことになる。この他にも、例えばユーザからジョブ処理の中断指示を受けた場合やジョブ実行中の障害を検知した場合に、ジョブ処理部１００は再開待ち状態になる。本実施形態では、このような再開待ち状態にあるジョブについて、そうでない通常状態のジョブとは異なった取扱をするので、ジョブ処理部１００は、実行中のジョブが再開待ちの状態に入ったかどうかを監視する（Ｓ４８）。再開待ち状態でなければ、Ｓ４６に戻り、ジョブ完了までフローの処理を進める。

Ｓ４８でジョブが再開待ち状態に入った場合、ジョブ処理部１００は、その再開待ち状態に入った段階でのジョブの処理結果（以下「途中処理結果」と呼ぶ）を保存する（Ｓ５０）。例えば、ジョブのフロー中に対話処理のタスクがある場合、そのタスクの直前のタスクまでの途中処理結果を保存するのである。また、ユーザの中断指示や障害などでジョブの実行を中断した場合は、その中断までに実行が完了した最後のタスクまでの途中処理結果を保存する。保存する途中処理結果には、対象データについての途中までの処理結果と、再開待ち状態に入った段階での当該ジョブ処理部１００の内部状態（例えばそのジョブの実行に用いられる変数の値）等が含まれる。この保存は、後述するスケールイン指示取得時の処理の際に、再開待ちの状態のジョブを、途中処理結果と共にキュー管理部１３０に差し戻すための準備である。この保存の後、再開待ち状態を解除する再開条件が満たされるのを待つ（Ｓ５２）。例えば、対話処理のために再開待ち状態に入った場合、対話処理の目的であるユーザからの入力データを受け取ることが再開条件である。再開条件が満たされると（Ｓ５２の判定結果がＹｅｓ）、そのジョブの実行を再開し（Ｓ５４）、Ｓ４６に戻って、ジョブ完了までフローに従って処理を進めていく。そして、ジョブが完了すると、Ｓ４０に戻る。この場合、それまで実行していたジョブが１つ完了したので、新規ジョブが実行可能な状態であり、そのような新たなジョブを受け付けていれば、そのジョブの実行が行われる。

次に、ジョブ処理部１００のスケールインのための動作の例を、図５及び図６を参照して説明する。

図５に示すように、ジョブ処理部１００は、スケールイン確認タイミングであるかをチェックする（Ｓ６０）。スケールイン確認タイミングは、あらかじめ定められた時間間隔で到来するタイミングまたは、ジョブ処理部１００でジョブを開始や終了時のようなジョブの処理量が変化するタイミング等である。このスケールイン確認タイミングが到来すると、ジョブ処理部１００は、自分がスケールイン指示を受付可能な状態であるかどうかを判定する（Ｓ６２）。

ここでこの例では、スケールインが必要となった場合、処理負荷が低いジョブ処理部１００を優先的に停止させるために、個々のジョブ処理部１００の処理負荷に応じて、当該ジョブ処理部１００のスケールイン指示の受付の可否を切り換えている。このための処理手順を、図６に示す。

図６の手順は、例えば定期的に、ジョブ処理部１００により実行される。この手順では、当該ジョブ処理部１００の処理負荷があらかじめ定められた受付開始閾値より低いかどうかを判定し（Ｓ７０）、低ければ、自己の状態をスケールイン指示受付可能状態に遷移させる（Ｓ７２）。ここで、ジョブ処理部１００の処理負荷は、例えば、そのジョブ処理部１００が現在同時に実行中のジョブの数、当該ジョブ処理部１００に割り当てられた計算資源（例えばＣＰＵやメモリ）の現在の使用率、あるいはそれらのうちの２以上から計算される指標値、等により表される。

Ｓ７０の判定結果がＮｏの場合、ジョブ処理部１００は、自己の処理負荷があらかじめ定められた受付停止閾値よりも高いかどうかを判定し（Ｓ７４）、高ければ、自己の状態をスケールイン指示受付不可状態に遷移させる（Ｓ７６）。受付停止閾値には、受付開始閾値よりも高い（より重負荷な）値が設定される。これにより、スケールイン指示受付可能状態とスケールイン指示受付不可状態との間の遷移にヒステリシスがもたらされ、処理不可の微小な変化で状態が頻繁に変化することが防がれる。なお、Ｓ７４の判定結果がＮｏの場合は、スケールイン指示受付可否に関する状態が、現在の状態のまま維持される。

図５の手順の説明に戻ると、Ｓ６２では、このようなスケールイン指示受付可否に関する状態の現在値が、受付可能状態であるか否かが判定されるわけである。

Ｓ６２の判定結果がＹｅｓの場合、ジョブ処理部１００は、自分の属する処理グループ１１０に対応するスケールインキュー１４６からスケールイン指示を待ち受ける待ち受け状態となる（Ｓ６４）。この時点でスケールインキュー１４６が空であれば、スケールイン指示は通知されて来ないのでスケールイン指示は取得できない（Ｓ６６の判定結果がＮｏ）。この場合は、Ｓ６０に戻って次の確認タイミングを待つ。

Ｓ６２の判定結果がＮｏ、すなわち、ジョブ処理部１００がスケールイン指示受付不可状態である場合には、当該ジョブ処理部１００は現在高負荷なので、スケールインの際の停止対象にはならない。したがって、Ｓ６４以降の処理は行わず、スケールインキュー１４６からの通知の待ち受けを停止し、Ｓ６０に戻って次のスケールイン確認タイミングを待つ。

スケールイン指示を待ち受けているジョブ処理１００に対しＳ６６でスケールイン指示が通知された場合、そのジョブ処理部１００は、そのスケールイン指示を取得し、停止準備状態に移行する。すなわち、リカバリキュー１４４及びジョブキュー１４２内のジョブの消費（取得）を停止し、現在実行中のジョブについてはその処理を続行する（Ｓ６８）。ただし、このＳ６８では、現在実行中のジョブの中に再開待ち状態のものがあれば、それを所属する処理グループ１１０のリカバリキュー１４４に差し戻し（すなわちそのジョブをリカバリキュー１４４の末尾に追加し）、そのジョブの実行を取りやめる。すなわち、停止準備状態に入ったジョブ処理部１００は、スケールイン指示取得時点で再開待ち状態であったジョブについては、処理は続行せず、そのジョブの処理を通常稼働状態にある別のジョブ処理部１００に引き継ぐのである。なお、再開待ち状態のジョブのリカバリキュー１４４への差し戻しの際には、再開待ち状態に入る際に保存した途中処理結果のデータ、及び、その途中処理結果が処理手順内のどのタスクまでの実行結果なのかを示す情報を、当該ジョブのＩＤに対応づけてジョブ管理部１５０に登録する。これにより、後でそのジョブをリカバリキュー１４４からジョブを取得した他のジョブ処理部１００は、それら途中処理結果に関する情報を用いて、ジョブの最初からの処理をスキップし、その再開待ち状態に入った段階からジョブを再開する。

Ｓ６８で停止準備段階に入ると、ジョブ処理部１００は、実行中のジョブがすべて処理完了するのを待ち（Ｓ７０）、それらすべてのジョブの実行が完了すると、自ら（ジョブ処理部１００である仮想マシンすなわちインスタンス）を停止する（Ｓ７２）。これにより、そのジョブ処理部１００は存在しなくなり、スケールイン対象の処理グループ１１０内のジョブ処理部１００の数が１つ減ることとなる。以上は、ジョブ処理部１００が自ら停止して消滅することができるシステムの場合であったが、そうでない場合には、ジョブ処理部１００は、例えばジョブ処理部１００の生成、消滅を制御する他の装置（プロセス）に、自らを消すように依頼するなどすればよい。

なお、停止準備状態にあるジョブ処理部１００は、図５の処理手順は実行しない。すなわち、既に停止しようとしているジョブ処理部１００は、新たなスケールイン指示の対象とはならない。

次に、図７を参照して、ジョブ処理部１００のスケールアウトのための動作の例を説明する。

図７の手順では、ジョブ処理部１００は、スケールアウトトピック（スケールアウト指示）の到来を待つ（Ｓ８０）。ここで、ジョブ処理部１００は、スケールアウトトピックを常時待ち受けていてもよいし、ある確認タイミング毎（例えばスケールイン確認タイミングと同時）にスケールアウトトピックがあるか確認してもよい。スケールアウトトピックが到来すると、ジョブ処理部１００は、自分が停止準備状態であるかどうかを判定する（Ｓ８２）。停止準備状態でなければ、Ｓ８０に戻って、スケールアウトトピックを待つ。

Ｓ８２で自分が停止準備状態であると判定した場合は、ジョブ処理部１００は、リカバリキュー１４４及びジョブキュー１４２からのジョブの消費（取得）を再開する（Ｓ８４）。これにより、このジョブ処理部１００は、停止準備状態から抜け出し、通常稼働状態に戻ることになる。一方、Ｓ８２で自分が停止準備状態でない（すなわち通常稼働状態である）と判定した場合は、ジョブ処理部１００は、Ｓ８０で受け取ったスケールアウトトピックを無視し、Ｓ８０に戻る。

このように、スケールアウト指示を受け取った停止準備状態のジョブ処理部１００が通常稼働状態に戻ることで、スケールアウト対象の処理グループ１１０内の通常稼働状態（すなわちジョブを消費する）ジョブ処理部１００の数が増えることになる。

次に、図８〜図１０を参照して、本実施形態のシステムの動作の一例を説明する。

図８は、２つのジョブ処理部１００（＃１及び＃２）からなる処理グループ１１０において、どちらのジョブ処理部＃１及び＃２にも再開待ち状態のジョブが存在しない時に行われるスケールインの処理の流れを示している。

この例では、（１）監視タイミングが到来すると、監視部１６０がジョブ管理部１５０からその処理グループ１１０の処理負荷の情報（キュー構造１４０内の待ちジョブ数等）を取得する。（２，３）一方、ジョブ処理部＃１及び＃２は、それぞれのタイミングで、自分の処理負荷を閾値と比較する。（２．１，３．１）この例では、ジョブ処理部＃１及び＃２は、共に処理負荷が閾値より小さいのでスケールイン指示受付可能（待ち受け）状態となる。図５の例では、各ジョブ処理部１００が確認タイミング毎にキュー管理部１３０にジョブを取りに行ったが、図８の例では、各ジョブ処理部＃１及び＃２は、スケールイン指示の待ち受け状態となった旨をキュー管理部１３０に登録し、キュー管理部１３０は、スケールイン指示がスケールインキュー１４６に入れられると、待ち受け状態の登録の先着順に各ジョブ処理部＃１又は＃２にスケールイン指示を通知するものとする（具体的な実現方法は異なっているが、実現している制御の内容そのものは実質的に同じ）。図８の例では、ジョブ処理部＃１の方が先にキュー管理部１３０に待ち受け状態を登録している。（４）監視部１６０は、処理グループ１１０の処理負荷の確認の結果、スケールインが必要と判定すると、キュー管理部１３０内の当該処理グループ１１０のスケールインキュー１４６に対して、この例では１つのスケールイン指示を送信する。（５）スケールイン指示がスケールインキュー１４６に入れられると、キュー管理部１３０は、そのスケールイン指示を、待ち受け状態の登録の先着順に、この例ではジョブ処理部＃１に対して通知する。スケールインキュー１４６に入れられたスケールイン指示は１つだけなので、ジョブ処理部＃２にはスケールイン指示は通知されない。（６）スケールイン指示を受け取ったジョブ処理部＃１は、停止準備状態となり、キュー管理部１３０からのジョブの消費を停止すると共に、既に取得済みで現在実行中のジョブについてはその処理を続行する。（７）そして、スケールイン指示を受け取った際に実行中であったジョブのうちの最後のものの実行が完了すると、（８）当該ジョブ処理部１００のインスタンス自体を停止する。これにより、処理グループ１１０からジョブ処理部＃１が削除され、処理グループ１１０を構成するジョブ処理部１００の数が１つ減る。

図９は、２つのジョブ処理部＃１及び＃２からなる処理グループ１１０において、スケールイン指示を受け取ったジョブ処理部＃１に再開待ち状態のジョブが存在している場合に行われるスケールインの処理の流れを示している。

図９では省略したが、少なくともジョブ処理部＃１はスケールイン指示の待ち受け状態である旨をキュー管理部１３０に対して登録済みであるとする。（１）監視部１６０の処理負荷の監視の結果、（２）スケールイン指示がキュー管理部１３０内のスケールインキュー１４６に送信されると、（３）キュー管理部１３０はそのスケールイン指示をジョブ処理部＃１に通知する。（４）スケールイン指示を受け取ったジョブ処理部＃１は、停止準備状態となり、キュー管理部１３０からのジョブの消費を停止する。（５）ここで、ジョブ処理部＃１は再開待ち状態のジョブを有しており、有するすべての再開待ちジョブをキュー管理部１３０内のリカバリキュー１４４に差し戻す。そして、ジョブ処理部＃１は、残った現に実行中（すなわち再開待ちでない）のジョブの実行を続行し、それらジョブの実行が完了し次第、（８）自分自身を停止して消滅する。

一方、ジョブ処理部＃２はスケールイン指示を受け取っていないので、通常稼働状態のままであり、ジョブの消費を続けている。（６）ジョブ処理部＃２は、新たなジョブを取得可能になると、まずリカバリキュー１４４からジョブ取得を試みるが、このときリカバリキュー１４４内にはジョブ処理部＃１から差し戻された再開待ちのジョブが存在するので、そのジョブを取得することとなる。（７）再開待ちのジョブを取得したジョブ処理部＃２は、そのジョブのフローの最初から再開待ちまでのタスクをスキップし、再開待ちの段階から実行を再開する。なお、通常稼働状態のジョブ処理部＃２は、リカバリキュー１４４内にジョブがある間は、リカバリキュー１４４から優先的にジョブを取得する。

図１０は、第１段階及び第２段階のスケールアウトが行われる例を示している。この例のうち（１）〜（４）のイベントは、図９の例における（１）〜（４）と同様である。ここで、図１０の例では、停止準備状態となったジョブ処理部＃１が消滅する前に、処理グループ１１０の処理負荷が増大してスケールアウトが必要になった場合を想定している。すなわち、（５）監視部１６０の処理負荷の監視の結果、処理グループ１１０の処理負荷が第１スケールアウト閾値より高くなったことが分かると（図２のＳ１８参照）、（６）監視部１６０はキュー管理部１３０内のスケールアウトトピック１４８にスケールアウト指示を送信する。（７）キュー管理部１３０は、受け取ったスケールアウト指示を、処理グループ１１０内のすべてのジョブ処理部＃１及び＃２に同報する。なお、図７の手順のように、各ジョブ処理部１００がそれぞれ独自のタイミングで非同期にスケールアウトトピック１４８からスケールアウト指示を受け取る構成では、各ジョブ処理部＃１及び＃２がスケールアウト指示を受け取るタイミングは、図示のように同時ではなく、若干の差が出る。（８）ジョブ処理部＃１は、停止準備（ジョブ消費停止）中なので、スケールアウト指示を受け取ると、停止準備状態から抜け、ジョブ消費を再開する。一方、ジョブ処理部＃２は通常稼働状態のままなので、スケールアウト指示を受け取っても何もしない（すなわち、ジョブの取得及び実行を続行する）。以上の（６）〜（８）が第１段階のスケールアウトである。この第１段階のスケールアウトで、処理グループ１１０の処理負荷の増大が十分に抑制されないと、（９）処理グループ１１０の処理負荷が第２スケールアウト閾値を超えることになり、このことが監視部１６０の監視により検出される（図２のＳ２２参照）。（１０）この場合、監視部１６０は、オートスケーラー１７０に対してスケールアウト指示を出す。（１１）この指示を受け取ったオートスケーラー１７０は、当該処理グループ内に新規のジョブ処理部１００を生成する。これにより、処理グループ１１０がスケールアウトされる。

以上に説明したように、この実施形態では、スケールインが必要となった場合、あらかじめ定められた個数（例えば１個）のスケールイン指示がスケールインキュー１４６に入れられる（図２参照）。そして、そのキュー内のスケールイン指示を、スケールイン指示受付可能状態のジョブ処理部１００が早い者勝ちで取得し、停止準備状態に入る。この構成により、スケールインが必要と判定される都度、当該あらかじめ定められた数の通常稼働状態のジョブ処理部１００がジョブ消費を停止し、停止準備状態となって、実行中のジョブが完了し次第消滅することとなる。

すなわち、この実施形態では、中央の監視部１６０が個々のジョブ処理部１００のジョブ実行状況を監視して停止させるべきジョブ処理部１００を特定しなくても、スケールイン指示を受け取ったジョブ処理部１００自身が自律的に停止のための準備をし、実行中のすべてのジョブが完了した時点で停止する。本実施形態では、監視部１６０は、処理グループ１１０内の個々のジョブ処理部１００の処理状況は監視せず、その処理グループ１１０全体の処理負荷を監視しているに過ぎない。

これに対し、スケールアウト指示に応じた第１段階のスケールアウト処理では、スケールアウト指示はトピックの形で、対象の処理グループ１１０内のすべてのジョブ処理部１００に伝達される。したがって、スケールアウト指示は、停止準備状態のすべてのジョブ処理部１００に伝わり、それら停止準備状態のすべてのジョブ処理部１００が通常稼働状態に復帰することになる。なお、停止準備状態は過渡的な状態であり、停止準備状態のジョブ処理部１００は比較的短時間で既存のジョブの実行を完了して消滅する。したがって、スケールアウト指示が発行された時に処理グループ１１０内に存在する停止準備状態のジョブ処理部１００の数は多くはなく（例えば、１回に発行するスケールイン指示の個数程度と考えられる）、それら停止準備状態のジョブ処理部１００がすべて通常稼働状態に復帰したとしても、処理グループ１１０内のジョブ処理部１００の数が突然大幅に増えてしまうということはない。このスケールアウトトピック１４８を利用した第１段階のスケールアウトは、現に存在している停止準備状態のジョブ処理部１００にジョブ消費を再開させるだけの処理なので、新たなジョブ処理部１００を生成する通常の（第２段階の）スケールアウト処理よりも反応速度が速い。したがって、処理負荷の増加に素早く反応し、通常稼働状態のジョブ処理部１００の数を増やして、キュー構造１４０内のジョブの消費速度を速め、処理負荷の増加を解消又は緩和する。

また、本実施形態では、この第１段階のスケールアウトでは過剰な処理負荷が解決できない場合には、第２段階のスケールアウト（図２のＳ２４）により新規のジョブ処理部１００を生成することで、処理グループ１１０の処理能力を高める。

また、本実施形態では、スケールイン指示を受け取った停止対象となった（すなわち停止準備状態の）ジョブ処理部１００は、再開待ち状態のジョブをリカバリキュー１４４に差し戻す。この構成により、停止対象となったジョブ処理部１００は、いつ再開されるか分からず、従っていつ完了するかも分からない再開待ちのジョブの完了を待つことなく、消滅する。

また、リカバリキュー１４４に差し戻された再開待ちのジョブは、通常稼働状態のジョブ処理部１００により、ジョブキュー１４２内のジョブよりも優先して実行されるので、再開待ちのジョブの実行順序が、後から投入されたジョブにより追い抜かれてしまう可能性は少ない。

上述の例では、処理グループ１１０内の通常稼働状態のジョブ処理部１００のうち、処理負荷が受付開始閾値よりも低くなってスケールイン指示受付可能状態となっているジョブ処理部１００のみが、スケールインキュー１４６にスケールイン指示を取りに行くが、これは一例に過ぎない。この代わりに、処理グループ１１０内の通常稼働状態のすべてのジョブ処理部１００がスケールイン指示を取りに行くようにしてもよい。ただし、処理負荷が高い（実行中のジョブ数が多いなど）ジョブ処理部１００ほど、停止準備状態に入ってから消滅するまでに長い時間がかかるので、上述の例のように処理負荷が高いジョブ処理部１００がスケールイン指示を取りに行かないようにした方が、すべてのジョブ処理部１００が取りに行く方式よりも、スケールインがより早く実現されることとなる。

以上の説明では省略したが、実施形態の処理システムは、処理グループ１１０内のジョブ処理部１００の数に応じて課金を行う課金処理部を備えていてもよい。

以上に例示した処理システムのうちの管理機能、すなわちジョブ投入部１２０、キュー管理部１３０、ジョブ管理部１５０、監視部１６０、及びオートスケーラー１７０を担う部分は、例えば、汎用のコンピュータにそれら各機能モジュールの処理を表すプログラムを実行させることにより実現される。ここで、コンピュータは、例えば、ハードウエアとして、ＣＰＵ等のマイクロプロセッサ、ランダムアクセスメモリ（ＲＡＭ）およびリードオンリメモリ（ＲＯＭ）等のメモリ（一次記憶）、ＨＤＤ（ハードディスクドライブ）を制御するＨＤＤコントローラ、各種Ｉ／Ｏ（入出力）インタフェース、ローカル・エリア・ネットワークなどのネットワークとの接続のための制御を行うネットワークインタフェース等が、たとえばバスを介して接続された回路構成を有する。また、そのバスに対し、例えばＩ／Ｏインタフェース経由で、ＣＤやＤＶＤなどの可搬型ディスク記録媒体に対する読み取り及び／又は書き込みのためのディスクドライブ、フラッシュメモリなどの各種規格の可搬型の不揮発性記録媒体に対する読み取り及び／又は書き込みのためのメモリリーダライタ、などが接続されてもよい。上に例示した各機能モジュールの処理内容が記述されたプログラムがＣＤやＤＶＤ等の記録媒体を経由して、又はネットワーク等の通信手段経由で、ハードディスクドライブ等の固定記憶装置に保存され、コンピュータにインストールされる。固定記憶装置に記憶されたプログラムがＲＡＭに読み出されＣＰＵ等のマイクロプロセッサにより実行されることにより、上に例示した機能モジュール群が実現される。なお、それら機能モジュール群のうちの一部又は全部を、専用ＬＳＩ(Large Scale Integration)、ＡＳＩＣ（Application Specific Integrated Circuit、特定用途向け集積回路）又はＦＰＧＡ（Field Programmable Gate Array）等のハードウエア回路として構成してもよい。

また、そのように管理機能を構成するすべての機能モジュールを１つのコンピュータ上に実現する代わりに、それら機能モジュールをネットワークに接続された複数のコンピュータに分散して実装し、それら各コンピュータ間で通信を行うことにより管理機能を実現してももちろんよい。

また、各ジョブ処理部１００は、当該管理機能が実装されるコンピュータ、あるいはネットワークに接続された多数のコンピュータの各々に、ジョブ処理部１００の上述の機能（処理手順）を記述したプログラムを実行させることにより実現される。

１００ ジョブ処理部、１１０ 処理グループ、１２０ ジョブ投入部、１３０ キュー管理部、１４０ キュー構造、１４２ ジョブキュー、１４４ リカバリキュー、１４６ スケールインキュー、１４８ スケールアウトトピック、１５０ ジョブ管理部、１５２ 途中処理結果記憶部、１６０ 監視部、１７０ オートスケーラー。

Claims (10)

1. 処理グループ宛に到来した処理要求が追加される、当該処理グループに対応づけられた処理要求キューと、
   前記処理グループに属する１以上の処理部であって、新たな処理要求を受け付け可能になったときに、前記処理要求キューから処理要求を取得し、取得した処理要求を処理する１以上の処理部と、
   前記処理グループの処理負荷を監視し、当該監視により前記処理グループの処理負荷があらかじめ定められた縮小閾値より低くなったことがわかった場合、当該処理グループに対してグループ縮小指示を発行する監視部と、
   を備え、
   前記グループ縮小指示が発せられた場合、前記処理グループのうちのあらかじめ定められた数の前記処理部が停止対象となり、停止対象となった前記処理部は、当該処理グループの処理要求キューからの新たな処理要求の取得を停止すると共に、既に取得済みのすべての処理要求の処理が完了すると動作を停止して前記処理グループから外れる、
   ことを特徴とする処理システム。
2. 前記処理グループに対応づけられたリカバリキューをさらに備え、
   前記停止対象となった前記処理部は、前記既に取得済みの処理要求の中に、処理の中断からの再開待ちの状態である再開待ち状態のものがある場合には、当該再開待ち状態の処理要求を前記リカバリキューに追加することで、当該処理要求を前記既に取得済みの処理要求に該当しないものとみなし、
   前記各処理部は、新たな処理要求を受け付け可能になったときに、前記リカバリキューから優先的に処理要求を取得し、当該リカバリキューに処理要求がない場合に前記処理要求キューから処理要求を取得する、
   ことを特徴とする請求項１に記載の処理システム。
3. 処理要求の処理の途中段階の処理結果を記憶するための途中結果記憶部、をさらに備え、
   前記停止対象となった前記処理部は、前記再開待ち状態の処理要求についての当該再開待ち状態の段階までの途中の処理結果を、前記リカバリキューに追加した当該処理要求に対応づけて前記途中処理結果記憶部に記憶させ、
   前記各処理部は、前記リカバリキューから処理要求を取得した場合に、当該処理要求に対応づけて前記途中処理結果記憶部に記憶されている途中の処理結果を用いることにより、当該処理要求の処理が前記再開待ち状態の段階まで済んだものとして、当該処理を再開する、
   ことを特徴とする請求項２に記載の処理システム。
4. 前記監視部は、前記監視により前記処理グループの処理負荷があらかじめ定められた拡大閾値より高くなったことがわかった場合、当該処理グループ内の各処理部に対してグループ拡大指示を発行し、
   前記グループ拡大指示を受け取った各処理部は、自己が停止対象であるがまだ動作の停止に至っていない場合には、自己を停止対象でなくし、前記処理要求キューからの新たな処理要求の取得を再開する、
   ことを特徴とする請求項１〜３のいずれか１項に記載の処理システム。
5. 前記処理グループに対応づけられた縮小指示キューをさらに備え、
   前記監視部は、前記処理グループに対して発行するグループ縮小指示を、当該処理グループに対応づけられた前記縮小指示キューに追加し、
   前記各処理部は、それぞれ、処理負荷があらかじめ定められた停止対象閾値より低い場合にのみ、前記縮小指示キューからの前記グループ縮小指示の取得動作を行い、この取得動作により前記グループ縮小指示が取得できた場合に、前記停止対象となる、
   ことを特徴とする請求項１〜４のいずれか１項に記載の処理システム。
6. コンピュータを、
   処理グループ宛に到来した処理要求が追加される、当該処理グループに対応づけられた処理要求キュー、
   前記処理グループに属する１以上の処理部であって、新たな処理要求を受け付け可能になったときに、前記処理要求キューから処理要求を取得し、取得した処理要求を処理する１以上の処理部、
   前記処理グループの処理負荷を監視し、当該監視により前記処理グループの処理負荷があらかじめ定められた縮小閾値より低くなったことがわかった場合、当該処理グループに対してグループ縮小指示を発行する監視部、
   として機能させるためのプログラムであって、
   前記グループ縮小指示が発せられた場合、前記処理グループのうちのあらかじめ定められた数の前記処理部が停止対象となり、停止対象となった前記処理部は、当該処理グループの処理要求キューからの新たな処理要求の取得を停止すると共に、既に取得済みのすべての処理要求の処理が完了すると動作を停止して前記処理グループから外れる、
   ことを特徴とするプログラム。
7. 前記コンピュータを、前記処理グループに対応づけられたリカバリキューとして更に機能させると共に、
   前記停止対象となった前記処理部は、前記既に取得済みの処理要求の中に、処理の中断からの再開待ちの状態である再開待ち状態のものがある場合には、当該再開待ち状態の処理要求を前記リカバリキューに追加することで、当該処理要求を前記既に取得済みの処理要求に該当しないものとみなし、
   前記各処理部は、新たな処理要求を受け付け可能になったときに、前記リカバリキューから優先的に処理要求を取得し、当該リカバリキューに処理要求がない場合に前記処理要求キューから処理要求を取得する、
   ことを特徴とする請求項６に記載のプログラム。
8. 前記コンピュータを、処理要求の処理の途中段階の処理結果を記憶するための途中結果記憶部として更に機能させると共に、
   前記停止対象となった前記処理部は、前記再開待ち状態の処理要求についての当該再開待ち状態の段階までの途中の処理結果を、前記リカバリキューに追加した当該処理要求に対応づけて前記途中処理結果記憶部に記憶させ、
   前記各処理部は、前記リカバリキューから処理要求を取得した場合に、当該処理要求に対応づけて前記途中処理結果記憶部に記憶されている途中の処理結果を用いることにより、当該処理要求の処理が前記再開待ち状態の段階まで済んだものとして、当該処理を再開する、
   ことを特徴とする請求項７に記載のプログラム。
9. 前記監視部は、前記監視により前記処理グループの処理負荷があらかじめ定められた拡大閾値より高くなったことがわかった場合、当該処理グループ内の各処理部に対してグループ拡大指示を発行し、
   前記グループ拡大指示を受け取った各処理部は、自己が停止対象であるがまだ動作の停止に至っていない場合には、自己を停止対象でなくし、前記処理要求キューからの新たな処理要求の取得を再開する、
   ことを特徴とする請求項６〜８のいずれか１項に記載のプログラム。
10. 前記コンピュータを、前記処理グループに対応づけられた縮小指示キューとして更に機能させると共に、
    前記監視部は、前記処理グループに対して発行するグループ縮小指示を、当該処理グループに対応づけられた前記縮小指示キューに追加し、
    前記各処理部は、それぞれ、処理負荷があらかじめ定められた停止対象閾値より低い場合にのみ、前記縮小指示キューからの前記グループ縮小指示の取得動作を行い、この取得動作により前記グループ縮小指示が取得できた場合に、前記停止対象となる、
    ことを特徴とする請求項６〜９のいずれか１項に記載のプログラム。
    

Images