JP6501632B2 - 情報処理システム、およびその制御方法 - Google Patents

Description

本発明は、複数のキューを用いたデータの処理の順序などの制御を実現するための技術に関する。

クラウドサービスを用いて構築されたコンピューティングシステムによって、さまざまなネットワークデバイスを管理するサービスが存在する。ここで、ネットワークデバイスとしては、健康器具や画像処理装置、家電製品や車載端末などが含まれる。クラウドサービスを用いた情報処理システムにおいては、複数のネットワークデバイスから稼働状況を示すログなどの大量のデータ収集し、その後、その大量のデータを集計したり、分析したりする。集計や分析の結果は、レポートとしてユーザに提供することも可能である。ここでレポートの方法としては、Ｗｅｂページ上での表示や、ＰＤＦ等のファイルとして作成したレポートのユーザへの提供が可能である。

ここで、大量のログの集計や分析には時間がかる。そのため、ログの集計の方法としては、例えば、定期的に集計処理の要求を自動生成して実行する方法や、ユーザからレポートの作成要求を受け付けた際に集計を実行する方法がとられている。

この際、集計処理などを要求毎に順次処理するとして、定期的な集計処理の実行中に、ユーザからレポートの作成要求を受け付けた場合を考える。前者の集計処理の完了を待ってからレポート作成要求による集計処理を実行していると、ユーザにレポートを提供するまでに相当の時間がかかってしまう。そのため、ユーザへレポートを短時間で提供するためには、集計処理の優先度を適切に管理する必要がある。

特許文献１には、データ伝送を効率化させるために、複数の種類のキューを利用して、データ処理の優先度を管理する技術が開示されている。具体的には、高速キューと低速キューといった二つのキューを用いて、処理するデータの優先度に応じてキューにデータを振り分けて処理している。

前述した、情報処理システムにおける集計や分析の処理においても、複数のキューを利用して、各要求の優先度を考慮した処理を実現することが可能となる。具体的には、ユーザからレポートの作成要求を受け付けた場合には、その相対的に優先度の高い要求を処理するための優先キューに投入する。そして、集計を行う場合には優先キューに投入された要求から処理するようにすればよい。

特開２０１０−２６８１５号公報

前述したように優先度の異なる要求を管理するために複数のキューを用いることで、例えばユーザからレポート作成が要求された場合に、レポートを提供するまでのユーザの待ち時間を軽減することが可能となる。

しかしながら、ユーザからのレポート作成の要求を、全て同じ高い優先度の要求として優先キューに投入してしまうと、優先キューのなかでより優先度の高い要求の処理が遅れてしまう可能性がある。また、ユーザからのレポート作成などの要求の中には、処理負荷が低い要求も存在する。

したがって、システムでの各要求の処理効率や、システム利用者の待ち時間を考慮した場合に、優先キューに投入すべき要求についても、その内容によっては、投入方法や処理順などを制御する必要がある。

上記課題を解決するために、本発明は、複数のキューで管理されたジョブを処理する情報処理システムであって、前記情報処理システム内で定期的に生成される第１のジョブを第１のキューに投入する第１の投入手段と、前記情報処理システムが提供する画面を介した入力に対応する要求の受信に応じて生成される第２のジョブを、複数のキューの何れかに投入すべきか判定する判定手段と、前記判定手段による判定に従い、前記第２のジョブを複数のキューの何れかに投入する第２の投入手段と、前記第２のジョブの処理対象となったデータを用いた情報提供を行う提供手段と、を有し、
前記判定手段は、前記第２のジョブの処理対象となるデータの処理が完了していない場合には第２のキューに前記第２のジョブを投入すべきと判定し、前記第２のジョブの処理対象となるデータの処理が完了していた場合には第３のキューに前記第２のジョブを投入すべきと判定し、前記第２のキューで管理された前記第２のジョブが情報処理システムで処理された場合には、前記第３のキューに当該第２のジョブに対応して生成されたジョブが投入され、前記提供手段は、前記第３のキューで管理されたジョブの属性情報に従い、前記第２のジョブの処理対象となったデータを用いた情報提供を行うことを特徴とする。

本発明によれば、要求の内容を考慮したうえで優先キューに対する要求の投入などを制御し、要求の処理に係る待ち時間などを軽減することができる。

本発明に係るネットワークシステムの構成の一例を示す図である。 本発明に係るフロントサーバ１０２の構成例を示す図である。 本発明に係る集計サーバ１０６の構成例を示す図である。 締め前キューまたは締め済みキューで管理されるジョブの例を示す図である。 通常キューで管理されるジョブの例を示す図である。 情報処理システム１００の利用者を管理するためのユーザＩＤテーブルの例を示す図である。 スケジューラ１０１によるジョブ投入処理を説明するためのフローチャートである。 各月の集計状態テーブルの例を示す図である。 実施例１に係るフロントサーバ１０２による処理要求を受信した場合の処理を説明するためのフローチャートである。 実施例１に係る集計サーバ１０６によるジョブ取得処理を説明するためのフローチャートである。 実施例１に係る集計サーバ１０６による切替処理を説明するためのフローチャートである。 本発明に係るレポート作成サーバ１０８による処理を説明するためのフローチャートである。 本発明に係るレポート作成ページの一例を示す図である。 本発明に係るユーザに提供されるレポートの一例を示す図である。 実施例２に係るフロントサーバ１０２による処理要求を受信した場合の処理を説明するためのフローチャートである。 実施例３に係るネットワークシステムの構成の一例を示す図である。 実施例４に係るフロントサーバ１０２による処理要求を受信した場合の処理を説明するためのフローチャートである。 実施例４に係るジョブの削除処理の流れの例を説明するためのフローチャートである。 実施例５に係る集計サーバ１０６によるジョブ取得処理を説明するためのフローチャートである。 実施例５に係る各キューに設定された重み付けを管理するテーブルの例を示す図である。 実施例６に係る各キューに対する重み付けの変更処理を説明するためのフローチャートである。

以下、本発明を実施するための最良の形態について図面を用いて説明する。

（実施例１）
図１は、本発明に係るネットワークシステムの構成の一例を示す図である。情報処理システム１００は、スケジューラ１０１、フロントサーバ１０２、複数のキューやデータベース、集計サーバ１０６、レポート作成サーバ１０８などから構成される。

ここで、情報処理システム１００は、データセンターなど、複数の情報処理装置により提供されるハードウェアリソースを利用して構築されるシステムであり、複数の仮想マシンが上述したフロントサーバ１０２などのサーバとして動作している。ここで、情報処理装置は、ハードウェア構成として、例えば、ＣＰＵ、ＲＡＭ、ＲＯＭ、外部記憶装置、ネットワークＩ／Ｆ制御装置などを有する。ＣＰＵが、オペレーションシステム（ＯＳ）や仮想マシンを構成するための所定のプログラムを実行する。そして、仮想マシン上で、後述するような本発明に係る処理を実現するためのプログラムが実行されることになる。なお、情報処理システム１００には、仮想化技術を利用することなく構築することも可能である。また、情報処理システム１００に含まれるサーバ群は、すべて同じ地域に存在する必要はなく、それぞれがネットワークを介して通信できるのであれば、サーバ群のそれぞれが異なる国や地域に配置されてもよい。

情報処理システム１００は、ユーザシステム１２０内のコンピュータに対して入力された管理者などからの要求を受け付けて処理する。ユーザシステム１２０には、管理者が操作するＰＣ以外にも、サービスを提供するアプリケーションサーバなども存在し得る。ユーザシステム１２０は、インターネットなどのネットワークを経由して、情報処理システム１００に接続する。管理対象システム１２１は、情報処理システム１００の管理対象となるネットワークデバイスを含むネットワーク環境を示す。管理対象システム１２１内のネットワークデバイスの稼働状況を示すログなど、ネットワークデバイスに関するデータは、ネットワークを介して、情報処理システム１００で収集され、ＤＢ（データベース）１０９に格納される。ユーザシステム１２０、管理対象システム１２１は、それぞれ、複数ネットワーク上に存在してもよい。

情報処理システム１００のスケジューラ１０１は、予め定められたスケジュールに従い、通常キュー１０３にジョブを投入する。フロントサーバ１０２は、ユーザシステム１２０または管理対象システム１２１からの要求を受け付け、処理する。レポート作成などといった要求を受け付けた場合には、締め前キュー１０４または締め済みキュー１０５に該要求に対応するジョブを投入する。ここで、締め前キュー１０４及び、締め済みキュー１０５は、通常キュー１０３と比較して、管理者などからの直接的な指示入力により生成された要求に対応する即時性が必要となる優先度の高いジョブを管理することになる。

集計サーバ１０６は、通常キュー１０３、締め前キュー１０４、及び締め済みキュー１０５から、ジョブを取得し、ジョブに応じた処理を実行する。例えば、集計や分析などの処理要求に対応するジョブであった場合には、対象となるデータをＤＢ１０９から取得して、集計や分析などの処理を実行する。また、レポート作成要求に対応するジョブであった場合には、対象となるデータをＤＢ１０９から取得して、集計処理を実行し、その完了後、レポートキュー１０７にレポート作成の処理要求に対応するジョブを投入する。レポート作成サーバ１０８は、レポートキュー１０７からジョブを取得し、ＤＢ１０９に格納された集計済みデータを用いて、レポート作成処理を実行する。その後、要求基に対して作成したレポートによる情報提供を行う。

なお、ＤＢ１０９には、本システムを実現するためのプログラムや、情報処理システム１００の管理対象となるネットワークデバイスを保有する全ての利用者にサービスを提供するための各種データなどが格納されている。また、フロントサーバ１０２、集計サーバ１０６、レポート作成サーバ１０８は、複数存在してもよい。

図２は、本発明に係るフロントサーバ１０２の構成例を示す図である。フロントサーバは提供部２０１、受信部２０２、登録部２０３を有する。

提供部２０１は、管理者などから、レポート作成の要求などを受付けるためのＧＵＩ（グラフィカルユーザインタフェース）をユーザシステム１２０または管理対象システム１２１内のＰＣに提供する。ＰＣで動作するウェブブラウザ上で、提供部２０１からの提供情報に係る表示を行うことができる。また、提供部２０１は、レポート作成の要求以外にも、情報処理システム１００で管理している様々な情報を、ネットワークを介して、ＰＣに対して提供することが可能である。

受信部２０２は、提供部２０１による提供情報に基づくＧＵＩを通じて入力さえた指示に応じた様々な要求を受け付ける。ここで、レポート作成の要求には、対象デバイスや対象ユーザ、対象ユーザグループ、対象期間など、レポート作成のための様々な属性が含まれる。登録部２０３は、受け付けた要求を、ジョブとして、締め前キュー１０４または締め済みキュー１０５などに投入する。各キューで管理されるジョブの詳細については、図４を用いて後述する。

図３は、本発明に係る集計サーバ１０６の構成例を示す図である。集計サーバは、選択部３０１、切替部３０２、処理部３０３を有する。

選択部３０１は、通常キュー１０３、締め前キュー１０４、及び締め済みキュー１０５のいずれからジョブを取得するかを決定する。切替部３０２は、通常キュー１０３、締め前キュー１０４、締め済みキュー１０５のいずれからジョブを取得したかによって、ジョブ取得後の処理を切り替える。処理部３０３は、ジョブで要求された集計や分析などの処理を実行する。

図４は、締め前キュー１０４または締め済みキュー１０５で管理されるジョブ４００に含まれる属性情報の例を示す図である。

対象ユーザ４０１は、処理対象となるデータを特定するためのユーザＩＤを指定する項目である。情報処理システム１００の管理対象となるネットワークデバイスを保有する全ての利用者には、図６で示すユーザＩＤテーブル６０１で示すユーザＩＤが割り当てられている。例えば、フロントサーバ１０２でレポート作成の要求に対応するジョブが生成された場合には、該要求に含まれるユーザＩＤがジョブに設定されることになる。対象期間４０２は、処理対象となるデータを特定するための年月などの時間情報が指定される。この情報についても、レポート作成の要求に含まれる。

レポート作成４０３は、レポート作成を実行するかどうかを示す項目である。作成する必要がある場合には「ｔｒｕｅ」、単なる集計、分析のみの要求であってレポート作成を実行しない場合は「ｆａｌｓｅ」が設定される。なお、ジョブの属性情報としては、ほかにも処理対象を特定するための情報として、対象ネットワークデバイスの指定、対象ユーザグループの指定なども可能である。

図５は、通常キュー１０３で管理されるジョブ５００に含まれる属性情報の例を示す図である。
ジョブ５００にも、ジョブ４００と同様に、対象ユーザ５０１、対象期間５０２、レポート作成５０３といった属性情報が含まれている。

ここで、ジョブ５００はスケジューラ１０１により自動生成されるジョブである。

情報処理システム１００は、レポート作成サーバ１０８により、月などの期間を指定して、レポートを作成することができる。さらに、情報処理システム１００は、特定の時期までの集計結果をそれ以降変更できないようにするために、例えば、月ごとに締め処理（集計結果の確定処理）を行っている。スケジューラ１０１は、このような締め処理を目的に、月ごとに、全て利用者のそれぞれについて、ＤＢ１０９に格納されているログなどのデータを集計するためのタスクを自動生成する。

ジョブ５００は、ユーザＩＤ「Ａ００００２」で示す利用者のログの中で、締め処理が未完了であるすべての月のログを処理対象として、集計処理を実行させるためのジョブであることを示している。

図７は、スケジューラ１０１により定期的に実行されるジョブの投入処理を説明するためのフローチャートである。スケジューラ１０１は、予め定められた時間間隔で、締め処理を目的としたジョブを自動生成し、通常キューに投入する。本実施例では、ネットワークデバイスの利用に対する課金や稼働状況レポートなどを逐次ユーザに提供するため、毎月、月末などに、図７で示す処理を自動実行することを想定している。

Ｓ７０１〜Ｓ７０３までの処理を、スケジューラ１０１は、情報処理システム１００の管理対象となるネットワークデバイスを保有する全ての利用者について実行する。Ｓ７０２では、スケジューラ１０１は、通常キュー１０３に各利用者に対応するジョブ５００を投入する。

図８は、ＤＢ１０９に格納される各月の集計状態テーブルの例を示す図である。該テーブルでは、ユーザごとに各集計期間の締め状態が管理される。

集計サーバ１０６により集計処理が完了した場合に、該当する締め状態８０３の値が更新される。集計処理が完了し、締め済みとなれば、締め状態８０３の値が「０」から「１」に更新される。例えば、レコード８１１で示すように、ユーザＩＤ８０１「Ａ００００１」、集計年月８０２「２０１５／０３」で特定されるデータに関しては、集計処理が未完了であるために、締め状態８０３の値が「０」となっている。

図９は、実施例１に係るフロントサーバ１０２で実行される処理要求を受信した場合の処理を説明するためのフローチャートである。本処理は、ユーザによる入力に従い、フロントサーバ１０２で受信した要求に応答して、ジョブを所定のキューに投入するための処理である。

Ｓ９０１で、受信部２０２が、提供部２０１が提供したＧＵＩを通じて入力された要求を受信する。ここでは、図１３で示すＧＵＩ画面を介してレポート作成のための要求を受信したとする。この画面は、提供部２０１が提供するＨＴＭＬなどのデータに基づき、ウェブブラウザなどにより表示されるレポート作成ページの例を示す。管理者などは、作成ボタン１３００を押下指示して、対象期間を選択しつつ、レポート作成を要求することができる。さらに、管理者などは、ダウンロードボタン１３０３を押下指示して、作成されたレポート（ファイル）のダウンロードを、フロントサーバ１０２に対して要求することが可能である。ここで、ダウンロードボタン１３０３は、集計処理が完了し、レポート作成が完了した場合に提供されるボタンである。なお、管理者がレポート作成ボタン１３０１を押した後、１３０２の位置にダウンロードボタンが表示されるまでに長い時間が掛かってしまうと、ユーザビリティが低下してしまうことになる。本実施例では、このユーザビリティが低下を抑えることを目的としている。

Ｓ９０２で、登録部２０３は、図８で示す集計状態テーブルを参照し、受信した要求で指定される対象期間が締め済みであるか否かを判定する。つまり、登録部２０３は、すでに収集データの集計サーバ１０６による集計処理が完了した締め済みの期間のデータを対象とする要求であった場合にはＳ９０３に進み、そうでないと判定された場合にはＳ９０４に進む。

Ｓ９０３で、登録部２０３は、締め済みキュー１０５に、受信した要求で指定された内容を属性情報として含むジョブを投入する。Ｓ９０４で、登録部２０３は、締め前キュー１０４に、受信した要求で指定された内容を属性情報として含むジョブを投入する。以上で、本処理は終了する。

図１０は、実施例１に係る集計サーバ１０６によるジョブ取得処理を説明するためのフローチャートである。集計サーバ１０６は、Ｓ１００１〜Ｓ１００９までの処理を繰り返す。

Ｓ１００２では、選択部３０１は、締め済みキュー１０５でジョブが管理されているか否かを判断する。締め済みキュー１０５でジョブが管理されていた場合にはＳ１００３に進み、管理されていなかった場合にはＳ１００４に進む。Ｓ１００３では、選択部３０１が、締め済みキュー１０５から先頭のジョブを取得する。

Ｓ１００４では、選択部３０１は、締め前キュー１０４でジョブが管理されているか否かを判断する。締め前キュー１０４でジョブが管理されている場合にはＳ１００５に進み、管理されていなかった場合にはＳ１００６に進む。Ｓ１００５では、選択部３０１が、締め前キュー１０４から先頭のジョブを取得する。

Ｓ１００６では、選択部３０１は、通常キュー１０３でジョブが管理されているか否かを判断する。通常キュー１０３でジョブが管理されている場合にはＳ１００７に進み、管理されていなかった場合にはＳ１００９に進む。Ｓ１００７では、選択部３０１が、通常キュー１０３から先頭のジョブを取得する。

Ｓ１００８では、切替部３０２が、切替処理（図１１）を実行する。

図１１は、実施例１に係る集計サーバ１０６による切替処理を説明するためのフローチャートである。

Ｓ１１０１で、切替部３０２は、図１０で取得された処理対象となるジョブが締め済みキュー１０５から取得されたか否かを判断する。締め済みキュー１０５から取得された場合にはＳ１１０５に進み、そうでない場合にはＳ１１０２に進む。ここでは、締め済みキュー１０５から取得されたジョブについて、集計処理をスキップして、Ｓ１００５に処理を進める。これは、スケジューラ１０１が自動生成した通常キュー１０３で管理されるジョブや、締め前キュー１０４で管理されていたジョブが処理されたことにより、対象期間などについて既に集計処理が完了しているためである。

Ｓ１１０２では、切替部３０２は、処理対象となるジョブが締め前キュー１０４から取得されたか否かを判断する。締め前キュー１０４から取得された場合にはＳ１１０３に進み、そうでない場合にはＳ１１０４に進む。

Ｓ１１０３及びＳ１１０４では、処理部３０３が、処理対象となるジョブの属性情報に従い、対象となるログなどのデータをＤＢ１０９から取得して、集計処理を実行する。集計済みのデータは、再びＤＢ１０９に格納される。集計処理が完了した場合には、図８で示す管理テーブルの締め状態８０３の値が更新される。ここで実行される集計処理としては、例えば、ネットワークデバイスが対象期間内に処理を実行した処理回数や、エラーなどの障害の発生頻度や、正常稼働していた時間などの集計などが挙げられる。

Ｓ１１０５で、切替部３０２は、レポートキュー１０７に新たにジョブを投入する。ここで投入されるジョブは、本処理の対象となったジョブの対象ユーザ及び対象期間などの属性情報を引き継いだ、レポート作成サーバ１０８にレポート作成を実行させるためのジョブである。

なお、締め前キュー１０４及び締め済みキュー１０５のそれぞれで管理されるジョブは、ともに、ユーザからフロントサーバ１０２が提供するＧＵＩを介して指定された要求に対応するものである。これら要求は、ユーザが直接指定したものであるためレポート提供までに、ある程度の即時性が必要となる優先度の高い要求と言える。一方で、通常キュー１０３で管理されるジョブは、レポート提供などが必要なわけではなく、締め前キュー１０４及び締め済みキュー１０５のそれぞれで管理されるジョブと比較して、相対的に優先度が低いと言える。つまり、本実施例は、締め前キュー１０４及び締め済みキュー１０５の２つの優先キューを利用していると言える。

ここで、図１１で示す処理からもわかるように、締め済みキュー１０５で管理されるジョブは、Ｓ１１０３で示す集計処理をスキップしている分、締め前キュー１０４で管理されるジョブよりも集計サーバ１０６による処理完了が明らかに早くなる。本実施例では、図１０で示したように、締め前キュー１０４よりも締め済みキュー１０５で管理されるジョブを先に処理するように構成している。

例えば、複数のユーザがほぼ同時にレポート作成のための要求を指示し、かつ、それらの要求の中に集計処理が完了している期間などを指定する要求があった場合を想定する。本実施例のような構成にすることで、それら要求に対応するジョブを順次、処理していくよりも、複数のユーザがレポート提供を受けるまでの待ち時間の平均を短縮することが可能になる。また、最初にレポート提供を受けるユーザの待ち時間が大きく改善されることもあり得る。

図１２は、本発明に係るレポート作成サーバ１０８によるレポート作成処理を説明するためのフローチャートである。

レポート作成サーバ１０８は、Ｓ１２０１〜Ｓ１２０５までの処理を繰り返し実行する。Ｓ１２０２では、レポート作成サーバ１０８は、レポートキュー１０７にジョブがある否かを判定する。ジョブが存在する場合にはＳ１２０３に進み、無い場合にはＳ１２０５に進む。

Ｓ１２０３では、レポート作成サーバ１０８は、レポートキュー１０７から先頭のジョブを取得する。Ｓ１２０４では、レポート作成サーバ１０８は、取得されたジョブの属性情報に従い、対象となる集計済みのデータをＤＢ１０９から取得して、レポートを作成する。

図１４は、本発明に係るユーザに提供されるレポートの例を示す図である。レポート１４００にはネットワークデバイスの稼働状況（処理回数や障害履歴など）の期間内の統計データなどが含まれている。ネットワークデバイスの一例である画像形成装置を例に挙げると、指定月や対象年における印刷枚数の合計など、様々な情報を含めることが可能である。図１３で示すダウンロードボタン１３０３を介した要求に従い、このような内容を含むレポートファイルがダウンロードできる。

以上が、実施例１に係る説明である。

（実施例２）
実施例１の図９で示す処理を一部変更することでも、実施例１と同様の効果が得られる。実施例２では、そのような処理について説明する。

図１５は、実施例１の図９の変形例である。なお、実施例２については、図９以外のシステム構成や処理については、実施例１と同様であるため、その説明を省略する。

Ｓ１５０１で、受信部２０２が、提供部２０１が提供したＧＵＩを通じて入力された要求を受信する。

Ｓ１５０２で、登録部２０３は、図８で示す集計状態テーブルを参照し、受信した要求で指定される対象期間が締め済みであるか否かを判定する。締め済み場合にはＳ１５０３に進み、そうでないと判定された場合にはＳ１５０４に進む。

Ｓ１５０３で、登録部２０３は、レポートキュー１０７に、直接、受信した要求で指定された内容を属性情報として含むジョブを投入する。このジョブは、レポート作成サーバ１０８にレポート作成を実行させるためのジョブである。Ｓ１５０４で、登録部２０３は、締め前キュー１０４に、受信した要求で指定された内容を属性情報として含むジョブを投入する。以上で、本処理は終了する。

本処理に依れば、締め済みの期間のデータを利用するレポート作成要求に対応するジョブについては、集計処理をスキップして、レポート作成サーバ１０８に優先的に処理させるような構成をとっている。これにより、実施例１と同様に、複数のユーザがほぼ同時にレポート作成のための要求を指示した場合などに、それらユーザの待ち時間を軽減できるといった効果が期待できる。

なお、実施例２では、締め済みキュー１０５を情報処理システム１００で用意することなく、実現できる手法である。締め済みキュー１０５を用意しない場合には、実施例１の図１０のＳ１００２、Ｓ１００３、図１１のＳ１１０１といった処理についても省略することになる。

（実施例３）
本実施例では、情報処理システム１００が、各キューで管理されているジョブ数を監視する構成をさらに備える形態について説明する。本実施例は、監視の結果、各キューに設定されたジョブ数の上限（閾値）を超えた場合に、集計サーバ１０６をスケールアウトまたはスケールアップさせる。なお、本実施例の他の処理については、上述した実施例とほぼ同様の構成をとるため、差分についてのみ説明を行う。

集計サーバ１０６は、１以上の仮想マシンにより実現されている。仮想マシンを提供するクラウドサービスは、集計サーバ１０６として機能する仮想マシンの台数を増加（スケールアウト）させたり、集計サーバ１０６として機能する仮想マシンの処理能力を向上（スケールアップ）させたりできる。これにより、処理すべきジョブが多い場合であっても、集計サーバ１０６により処理が滞ることを抑制できる。なお、各キューで管理されているジョブ数が少ない場合に、スケールインまたはスケールダウンさせることも可能である。

図１６は、実施例３に係るネットワークシステムの構成の一例を示す図である。図１と比較し、キュー監視１１０をさらに持ち、集計サーバ１０６が複数台構成となっている点が異なる。

キュー監視部１１０は、通常キュー１０３、締め前キュー１０４および締め済みキュー１０５のジョブ数を監視する。キューが保持するジョブ数が予め定められた閾値を超えた場合、キュー監視部１１０は集計サーバ１０６をスケールアウトまたはスケールアップさせる。

なお、ジョブ数の閾値はキューごとに異なる値に設定することが可能である。本実施例では、通常キュー１０３は５０件、締め前キュー１０４は１０件のように、通常キュー１０３に対して締め前キュー１０４の閾値を相対的に低くする。これによって、レポート作成がユーザに要求された際、早めに集計サーバ１０６をスケールアウトまたはスケールアップさせることで、ユーザにレポートを提供するまでの時間を短縮することが可能である。

なお、本実施例では、キュー監視部１１０は、情報処理システム１００内の他のサーバとは異なる仮想マシンで実現されているように記載している。しかしながら、フロントサーバ１０２、集計サーバ１０６に、同様のキュー監視の機能を組み込むことも可能である。

（実施例４）
本実施例については、実施例１におけるフロントサーバ１０２による処理の変形例について説明する。なお、本実施例の他の処理については、上述した実施例とほぼ同様の構成をとるため、差分についてのみ説明を行う。

本実施例は、フロントサーバ１０２が締め前キュー１０４にジョブを投入した際に、該ジョブと処理対象が重複する通常キュー１０３のジョブを削除するよう構成される。これにより、集計サーバ１０６による無駄な集計処理などが削減できる。

図１７は、本実施例に係るフロントサーバ１０２による処理要求を受信した場合の処理を説明するためのフローチャートである。
Ｓ１７０１で、フ受信部２０２が、提供部２０１が提供したＧＵＩを通じて入力された要求を受信する。Ｓ１７０２では、処理対象が重複しているジョブの削除処理（図１８）を実行する。

図１８は、本実施例に係るフロントサーバ１０２によるジョブの削除処理の流れの例を説明するためのフローチャートである。
Ｓ１８０１で、登録部２０３は、図８で示す集計状態テーブルを参照し、受信した要求で指定される対象期間が締め済みであるか否かを判定する。締め済みと判定された場合にはＳ１８０２に進み、そうでないと判定された場合にはＳ１８０３に進む。Ｓ１８０２で、登録部２０３は、締め済みキュー１０５に、受信した要求で指定された内容を属性情報として含むジョブを投入する。Ｓ１８０３で、登録部２０３は、締め前キュー１０４に、受信した要求で指定された内容を属性情報として含むジョブを投入する。

Ｓ１８０４で、登録部２０３は、投入したジョブと同じ属性情報を含むジョブが通常キュー１０３に存在するかを判定する。例えば、図４の対象ユーザ４０１、対象期間４０２と、図５の対象ユーザ５０１、対象期間５０２と、が重複する内容であるジョブがあるかどうかが判定される。Ｓ１８０４で存在すると判定された場合にはＳ１８０５で、登録部２０３が通常キュー１０３から属性情報が重複するジョブを削除する。以上で、本処理は終了する。

（実施例５）
本実施例は、実施例１とは異なる方法で、複数のキューから集計サーバ１０６がジョブを取得する方法について説明する。具体的には、実施例１の図１０の処理の変形例について説明する。なお、本実施例の他の処理については、上述した実施例とほぼ同様の構成をとるため、差分についてのみ説明を行う。

図１９は、実施例５に係る集計サーバ１０６によるジョブ取得処理を説明するためのフローチャートである。集計サーバ１０６は、Ｓ１９００〜Ｓ１９１６までの処理を繰り返す。
Ｓ１９０１〜Ｓ１９０５では、集計サーバ１０６は、締め済みキュー１０５に対して設定された重み付けの値の回数分だけ、繰り返して処理を行う。
Ｓ１９０２で、選択部３０１は、締め済みキュー１０５でジョブが管理されているか否かを判断する。締め済みキュー１０５でジョブが管理されていた場合にはＳ１９０３に進み、管理されていなかった場合にはＳ１９０６に進む。Ｓ１９０３では、選択部３０１が、締め済みキュー１０５から先頭のジョブを取得する。Ｓ１９０４では、切替部３０２が、切替処理（図１１）を実行する。
Ｓ１９０６〜Ｓ１９１０では、集計サーバ１０６は、締め前キュー１０４に対して設定された重み付けの値の回数分だけ、繰り返して処理を行う。
Ｓ１９０７では、選択部３０１は、締め前キュー１０４でジョブが管理されているか否かを判断する。締め前キュー１０４でジョブが管理されている場合にはＳ１９０８に進み、管理されていなかった場合にはＳ１９１１に進む。Ｓ１９０８では、選択部３０１が、締め前キュー１０４から先頭のジョブを取得する。Ｓ１９０９では、切替部３０２が、切替処理（図１１）を実行する。

Ｓ１９１１〜Ｓ１９１５では、集計サーバ１０６は、通常キュー１０３に対して設定された重み付けの値の回数分だけ、繰り返して処理を行う。
Ｓ１９１２では、選択部３０１は、通常キュー１０３でジョブが管理されているか否かを判断する。通常キュー１０３でジョブが管理されている場合にはＳ１９１３に進み、管理されていなかった場合にはＳ１９１６に進む。Ｓ１９１３では、選択部３０１が、通常キュー１０３から先頭のジョブを取得する。Ｓ１９１４では、切替部３０２が、切替処理（図１１）を実行する。

図２０は、各キューに設定された重み付けを管理するテーブルの例を示す図である。当該テーブルは、ＤＢ１０９で格納される。

集計サーバ１０６の選択部３０１は、図１９で示す処理で、このテーブルを参照する。例えば、Ｓ１９０１〜Ｓ１９０５では、締め済みキュー１０５に対応する行２０１３を参照して、６回まで繰り返し処理をすることになる。なお、このテーブルの重みづけを示す数値は、システム管理者などにより任意に変更可能である。

本実施例に依れば、複数のキューを所望の重み付けに従う優先度に応じて、各キューからジョブを取得することが可能となる。

（実施例６）
本実施例では、実施例５で設定していた各キューに対する重みの設定を自動で更新する処理について説明する。本実施例のシステム構成としては、図１６に示す構成とする。

図２１は、実施例６に係るキュー監視部１１０による各キューに対する重み付けの変更処理を説明するためのフローチャートである。

キュー監視部１１０は、Ｓ２１０１〜Ｓ２１０５までの処理を、所定の周期で繰り返し実行する。Ｓ２１０２で、キュー監視部１１０は、通常キュー１０３、締め前キュー１０４、及び締め済みキュー１０５のそれぞれのジョブ数を取得する。Ｓ２１０３で、キュー監視部１１０は、取得したジョブ数が最も多いキューの重み付けを示す数値を増やす。例えば、図２０で示すテーブルにおける対象キューに対応する数値を１増やすことでテーブルを更新する。なお、重みには最大値を設け、それを超える値には更新しない。Ｓ２１０４で、キュー監視部１１０は、取得したジョブ数が最も少ないキューの重み付けを示す数値を減らす。例えば、図２０で示すテーブルにおける対象キューに対応する数値を１減らすことでテーブルを更新する。なお、重みには最小値（例えば、“１”）を設け、それ未満の値には更新しない。

本実施例により、ジョブの種類ごとにキューに残存するジョブ数を考慮して動的に重み付けを変更することで、滞っている種類のジョブを優先して実行することが可能となる。

（他の実施例）
本発明は、上述した実施形態を適宜組み合わせることにより構成された装置あるいはシステムやその方法も含まれるものとする。

ここで、本発明は、上述した実施形態の機能を実現する１つ以上のソフトウェア（プログラム）を実行する主体となる装置あるいはシステムである。また、その装置あるいはシステムで実行される上述した実施形態を実現するための方法も本発明の１つである。また、そのプログラムは、ネットワークまたは各種記憶媒体を介してシステムあるいは装置に供給され、そのシステムあるいは装置の１つ以上のコンピュータ（ＣＰＵやＭＰＵ等）によりそのプログラムが読み出され、実行される。つまり、本発明の１つとして、さらにそのプログラム自体、あるいは当該プログラムを格納したコンピュータにより読み取り可能な各種記憶媒体も含むものとする。また、上述した実施形態の機能を実現する回路（例えば、ＡＳＩＣ）によっても、本発明は実現可能である。

１００ 情報処理システム
２０３ 登録部
３０１ 選択部
３０２ 切替部

Claims (4)

1. 複数のキューで管理されたジョブを処理する情報処理システムであって、
   前記情報処理システム内で定期的に生成される第１のジョブを第１のキューに投入する第１の投入手段と、
   前記情報処理システムが提供する画面を介した入力に対応する要求の受信に応じて生成される第２のジョブを、複数のキューの何れかに投入すべきか判定する判定手段と、
   前記判定手段による判定に従い、前記第２のジョブを複数のキューの何れかに投入する第２の投入手段と、
   前記第２のジョブの処理対象となったデータを用いた情報提供を行う提供手段と、を有し、
   前記判定手段は、前記第２のジョブの処理対象となるデータの処理が完了していない場合には第２のキューに前記第２のジョブを投入すべきと判定し、前記第２のジョブの処理対象となるデータの処理が完了していた場合には第３キューに前記第２のジョブを投入すべきと判定し、
   前記第２のキューで管理された前記第２のジョブが情報処理システムで処理された場合には、前記第３のキューに当該第２のジョブに対応して生成されたジョブが投入され、
   前記提供手段は、前記第３のキューで管理されたジョブの属性情報に従い、前記第２のジョブの処理対象となったデータを用いた情報提供を行うことを特徴とする情報処理システム。
2. 前記第２の投入手段により前記第２のジョブを前記第２のキューに投入した場合に、前記第２のジョブと同じ属性情報を含む前記第１のキューで管理されている第１のジョブを削除する削除手段を更に有することを特徴とする請求項１に記載の情報処理システム。
3. 前記第１のキューで管理された前記第１のジョブが情報処理システムで処理された場合には、前記第３のキューに当該第１のジョブに対応して生成されたジョブが投入されることを特徴とする請求項１または２に記載の情報処理システム。
4. 複数のキューで管理されたジョブを処理する情報処理システムにおける制御方法であって、
   前記情報処理システム内で定期的に生成される第１のジョブを第１のキューに投入する第１の投入工程と、
   前記情報処理システムが提供する画面を介した入力に対応する要求の受信に応じて生成される第２のジョブを、複数のキューの何れかに投入すべきか判定する判定工程と、
   前記判定工程での判定に従い、前記第２のジョブを複数のキューの何れかに投入する第２の投入工程と、
   前記第２のジョブの処理対象となったデータを用いた情報提供を行う提供工程と、を有し、
   前記判定工程では、前記第２のジョブの処理対象となるデータの処理が完了していない場合には第２のキューに前記第２のジョブを投入すべきと判定され、前記第２のジョブの処理対象となるデータの処理が完了していた場合には第３のキューに前記第２のジョブを投入すべきと判定され、
   前記第２のキューで管理された前記第２のジョブが情報処理システムで処理された場合には、前記第３のキューに当該第２のジョブに対応して生成されたジョブが投入され、
   前記提供工程では、前記第３のキューで管理されたジョブの属性情報に従い、前記第２のジョブの処理対象となったデータを用いた情報提供が行われることを特徴とする制御方法。

Images