(57)【要約】【課題】ジョブの処理の代行における非効率性を低減することが可能な情報処理システムを提供することを課題とする。【解決手段】情報処理システムであって、処理の種類ごとに振り分けられたジョブを、処理する順番に保持する保持手段と、担当する保持手段が保持しているジョブを処理する順番に実行する複数の実行手段と、を備え、一の実行手段は、担当する一の保持手段がジョブを保持しておらず、他の実行手段が担当する他の保持手段のジョブの処理を代行する場合に、他の実行手段の処理状況に応じて、ジョブの処理の代行を中止することにより、上記課題を解決する。【選択図】  図７
2020144606.tif 000002
【特許請求の範囲】
【請求項１】
一台以上の情報処理装置を含むように構成される情報処理システムであって、
処理の種類ごとに振り分けられたジョブを、処理する順番に保持する保持手段と、
担当する前記保持手段が保持している前記ジョブを前記処理する順番に実行する複数の実行手段と、
を備え、
一の前記実行手段は、担当する一の前記保持手段が前記ジョブを保持しておらず、他の前記実行手段が担当する他の前記保持手段の前記ジョブの処理を代行する場合に、他の前記実行手段の処理状況に応じて、前記ジョブの処理の代行を中止すること
を特徴とする情報処理システム。
【請求項２】
一の前記実行手段は、他の前記実行手段の全てが同一の種類の処理を実行している処理状況であれば、前記同一の種類の処理の代行を中止すること
を特徴とする請求項１記載の情報処理システム。
【請求項３】
一の前記実行手段は、他の前記実行手段の少なくとも一つが所定時間以上、前記ジョブの処理を継続している処理状況であれば、継続している前記処理と同一の種類の処理の代行を中止すること
を特徴とする請求項１又は２記載の情報処理システム。
【請求項４】
一の前記実行手段は、前記処理を代行する前記ジョブの候補と同一の依頼者からの処理を他の前記実行手段の少なくとも一つが実行している処理状況であれば、前記ジョブの候補の処理の代行を中止すること
を特徴とする請求項１乃至３何れか一項記載の情報処理システム。
【請求項５】
一の前記実行手段は、他の前記実行手段の全てが同一の種類の処理を実行している処理状況であるか、他の前記実行手段の少なくとも一つが所定時間以上、前記ジョブの処理を継続している処理状況であるか、処理を代行する前記ジョブの候補と同一の依頼者からの処理を他の前記実行手段の少なくとも一つが実行している処理状況であるか、の二つ以上の条件を組み合わせた判定に従って、前記同一の種類の処理の代行を中止すること
を特徴とする請求項１記載の情報処理システム。
【請求項６】
一の前記実行手段は、前記処理を代行する前記ジョブの候補として、前記保持手段に保持されている前記ジョブの数が一番少ない依頼者からの前記ジョブを選択すること
を特徴とする請求項１乃至５何れか一項記載の情報処理システム。
【請求項７】
一の前記実行手段は、前記処理を代行する前記ジョブの候補として、前記保持手段に保持されてからの経過時間が最も長い前記ジョブを選択すること
を特徴とする請求項１乃至５何れか一項記載の情報処理システム。
【請求項８】
一の前記実行手段は、前記処理の種類に応じた前記ジョブの処理負荷に基づいて、前記情報処理システムが消費するリソース消費量が所定値を超えないように、前記処理を代行する前記ジョブの候補を選択すること
を特徴とする請求項１乃至５何れか一項記載の情報処理システム。
【請求項９】
一台以上の情報処理装置を含むように構成される情報処理システムが実行する情報処理方法であって、
処理の種類ごとに振り分けられたジョブを、処理する順番に保持手段へ保持する保持ステップと、
担当する前記保持手段が保持している前記ジョブを複数の実行手段が前記処理する順番に実行する実行ステップと、
を備え、
一の前記実行手段は、担当する一の前記保持手段が前記ジョブを保持しておらず、他の前記実行手段が担当する他の前記保持手段の前記ジョブの処理を代行する場合に、他の前記実行手段の処理状況に応じて、前記ジョブの処理の代行を中止すること
を特徴とする情報処理方法。
【請求項１０】
処理の種類ごとに振り分けられたジョブを、処理する順番に保持する保持手段と、
担当する前記保持手段が保持している前記ジョブを前記処理する順番に実行する複数の実行手段と、
を備え、
一の前記実行手段は、担当する一の前記保持手段が前記ジョブを保持しておらず、他の前記実行手段が担当する他の前記保持手段の前記ジョブの処理を代行する場合に、他の前記実行手段の処理状況に応じて、前記ジョブの処理の代行を中止すること
を特徴とする情報処理装置。
【請求項１１】
コンピュータを、
処理の種類ごとに振り分けられたジョブを、処理する順番に保持する保持手段、
担当する前記保持手段が保持している前記ジョブを前記処理する順番に実行する複数の実行手段、
として機能させ、
一の前記実行手段は、担当する一の前記保持手段が前記ジョブを保持しておらず、他の前記実行手段が担当する他の前記保持手段の前記ジョブの処理を代行する場合に、他の前記実行手段の処理状況に応じて、前記ジョブの処理の代行を中止すること
を特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は情報処理システム、情報処理方法、情報処理装置及びプログラムに関する。
【背景技術】
【０００２】
従来、マスタ計算機（以下、単に「マスタ」という）が複数のワーカ計算機（以下、単に「ワーカ」という）に処理群を分散処理させるグリッドコンピューティングにおける分散処理方法があった。ネットワークを介して通信可能なマスタ／ワーカ間でやり取りされるジョブの流れでは、まず、マスタがジョブおよびその処理に必要なデータをワーカに投入する。つぎに、投入されたワーカは、ジョブの処理を実行する。
【０００３】
そして、そのワーカは、ジョブの処理結果をマスタに返す。マスタは、これらを複数のワーカに対しておこなうことにより、ジョブ全体をワーカに分散処理させている。（例えば特許文献１参照）。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
例えばユーザから受け付けたジョブを、そのジョブの処理の種類に対応したキューに割り当て、そのキューを担当するＷｏｒｋｅｒ（ワーカ）が非同期にジョブの処理を実行する情報処理システムがある。このような情報処理システムでは、キューに割り当てられたジョブの処理を、そのキューの担当ではないワーカ（他のワーカ）が代行する仕組みを備えているものがあった。しかしながら、従来の情報処理システムではジョブの処理を他のワーカが代行する仕組みを利用する方が非効率となる場合があった。なお、引用文献１の分散処理方法では、このような場合についての記載がない。
【０００５】
本発明の実施の形態は上記の点に鑑みなされたもので、ジョブの処理の代行における非効率性を低減することが可能な情報処理システムを提供することを目的とする。
【課題を解決するための手段】
【０００６】
上記目的を達成するために本願請求項１は、一台以上の情報処理装置を含むように構成される情報処理システムであって、処理の種類ごとに振り分けられたジョブを、処理する順番に保持する保持手段と、担当する前記保持手段が保持している前記ジョブを前記処理する順番に実行する複数の実行手段と、を備え、一の前記実行手段は、担当する一の前記保持手段が前記ジョブを保持しておらず、他の前記実行手段が担当する他の前記保持手段の前記ジョブの処理を代行する場合に、他の前記実行手段の処理状況に応じて、前記ジョブの処理の代行を中止することを特徴とする。
【発明の効果】
【０００７】
本発明の実施の形態によれば、ジョブの処理の代行における非効率性を低減することが可能である。
【図面の簡単な説明】
【０００８】
【図１】第１の実施形態に係るシステムの一例の構成図である。
【図２】コンピュータの一例のハードウェア構成図である。
【図３】第１の実施形態に係るサービス提供システムの一例の処理ブロック図である。
【図４】第１の実施形態に係るサービス提供システムにおいてジョブ実行処理を実現する一例の処理ブロック図である。
【図５】ワーカのキュー処理の一例について説明する図である。
【図６】ジョブの処理を代行する仕組みについて説明する図である。
【図７】ジョブの処理の代行を中止する仕組みについて説明する図である。
【図８】ワーカのジョブ実行処理の一例のフローチャートである。
【図９】ジョブ情報テーブルの一例の構成図である。
【図１０】タスクステータステーブルの一例の構成図である。
【図１１】処理負荷テーブルの一例の構成図である。
【発明を実施するための形態】
【０００９】
以下、本発明の実施形態について図面を参照しながら説明する。
［第１の実施形態］
＜システム構成＞
図１は第１の実施形態に係るシステムの一例の構成図である。図１のシステム１０００は例えばオフィス内ネットワーク等のネットワークＮ１と、クラウドサービスに代表されるサービス提供システム１１００のネットワークＮ２と、インターネットなどのネットワークＮ３とを有する。
【００１０】
ネットワークＮ１は、ファイヤウォールＦＷの内側にあるプライベートなネットワークである。ネットワークＮ１にはクライアント端末１０１１、携帯端末１０１２、複合機などの画像形成装置１０１３が接続されている。クライアント端末１０１１、携帯端末１０１２、複合機などの画像形成装置１０１３は無線による通信の手段または有線による通信の手段を有する。
【００１１】
クライアント端末１０１１は端末装置の一例である。クライアント端末１０１１はデスクトップＰＣやノートＰＣなどのユーザが操作可能な端末である。携帯端末１０１２は端末装置の一例である。携帯端末１０１２はスマートフォン、携帯電話、タブレット端末などのユーザが携帯可能な端末である。
【００１２】
画像形成装置１０１３は複合機などの画像形成機能を有する装置である。画像形成装置１０１３は複合機、コピー機、スキャナ、プリンタ、レーザプリンタ、プロジェクタ、電子黒板などの画像形成に係る処理を行う装置である。
【００１３】
なお、画像形成装置１０１３は一例であって、例えば、ＰＪ（Projector：プロジェクタ）、ＩＷＢ（Interactive White Board：相互通信が可能な電子式の黒板機能を有する白板）、デジタルサイネージ等の出力装置、ＨＵＤ（Head Up Display）装置、産業機械、撮像装置、集音装置、医療機器、ネットワーク家電、自動車（Connected Car）、ノートＰＣ、携帯電話、スマートフォン、タブレット端末、ゲーム機、ＰＤＡ（Personal Digital Assistant）、デジタルカメラ、ウェアラブルＰＣまたはデスクトップＰＣ等であってもよい。また、図１ではクライアント端末１０１１、携帯端末１０１２、及び画像形成装置１０１３がそれぞれ一台である例を示しているが複数台であってもよい。
【００１４】
ネットワークＮ２はアクセス制御装置１０２１によってネットワークＮ３に接続されている。ネットワークＮ２にはプリントサービス提供装置１０２２、スキャンサービス提供装置１０２３、他サービス提供装置１０２４が接続されている。
【００１５】
図１のシステム１０００は、アクセス制御装置１０２１、プリントサービス提供装置１０２２、スキャンサービス提供装置１０２３、他サービス提供装置１０２４がサービス提供システム１１００を実現している。
【００１６】
アクセス制御装置１０２１はプリントサービス提供装置１０２２が提供するプリントサービスやスキャンサービス提供装置１０２３が提供するスキャンサービスなどへのログインを制御する。
【００１７】
アクセス制御装置１０２１、プリントサービス提供装置１０２２、スキャンサービス提供装置１０２３、他サービス提供装置１０２４は、一台以上の情報処理装置によって実現される。
【００１８】
アクセス制御装置１０２１、プリントサービス提供装置１０２２、スキャンサービス提供装置１０２３、他サービス提供装置１０２４は一台の情報処理装置に統合して実現してもよいし、複数の情報処理装置に分散して実現してもよい。
【００１９】
ネットワークＮ２側のサービスの一部はネットワークＮ２以外にあってもよい。携帯端末１０１２は、オフィス内ネットワーク等のネットワークＮ１以外にあってもよい。図１のシステム１０００では携帯端末１０１２がネットワークＮ１と、ネットワークＮ３とにある例を示している。
【００２０】
＜ハードウェア構成＞
クライアント端末１０１１、携帯端末１０１２、アクセス制御装置１０２１、プリントサービス提供装置１０２２、スキャンサービス提供装置１０２３、他サービス提供装置１０２４は、例えば図２に示すハードウェア構成のコンピュータにより実現される。
【００２１】
図２はコンピュータの一例のハードウェア構成図である。コンピュータ１５００は、入力装置１５０１、表示装置１５０２、外部Ｉ／Ｆ１５０３、ＲＡＭ（Random Access Memory）１５０４、ＲＯＭ（Read Only Memory）１５０５、ＣＰＵ（Central Processing Unit）１５０６、通信Ｉ／Ｆ１５０７、及びＨＤＤ（Hard Disk Drive）１５０８などを備え、それぞれがバスＢで相互に接続されている。
【００２２】
入力装置１５０１はキーボードやマウス、タッチパネルなどを含み、ユーザが各操作信号を入力するのに用いられる。表示装置１５０２はディスプレイ等を含み、コンピュータ１５００による処理結果を表示する。なお、入力装置１５０１及び表示装置１５０２は必要なときに接続して利用する形態であってもよい。
【００２３】
通信Ｉ／Ｆ１５０７はコンピュータ１５００をネットワークＮ１〜Ｎ３に接続するインタフェースである。これにより、コンピュータ１５００は、通信Ｉ／Ｆ１５０７を介してデータ通信を行うことができる。
【００２４】
ＨＤＤ１５０８はプログラムやデータを格納している不揮発性の記憶装置である。格納されるプログラムやデータにはコンピュータ１５００全体を制御する基本ソフトウェアであるＯＳ（Operating System）やＯＳ上において各種機能を提供するアプリケーションソフトウェアなどがある。なお、コンピュータ１５００はＨＤＤ１５０８に替え、記憶媒体としてフラッシュメモリを用いるドライブ装置（例えばソリッドステートドライブ：ＳＳＤ）を利用するものであってもよい。
【００２５】
外部Ｉ／Ｆ１５０３は、外部装置とのインタフェースである。外部装置には、記録媒体１５０３ａなどがある。これにより、コンピュータ１５００は外部Ｉ／Ｆ１５０３を介して記録媒体１５０３ａの読み取り及び／又は書き込みを行うことができる。記録媒体１５０３ａにはフレキシブルディスク、ＣＤ（Compact Disk）、ＤＶＤ（Digital Versatile Disk）、ＳＤメモリカード（SD Memory card）、ＵＳＢメモリ（Universal Serial Bus memory）などがある。
【００２６】
ＲＯＭ１５０５は、電源を切ってもプログラムやデータを保持することができる不揮発性の半導体メモリ（記憶装置）である。ＲＯＭ１５０５には、コンピュータ１５００の起動時に実行されるＢＩＯＳ（Basic Input/Output System）、ＯＳ設定、ネットワーク設定などのプログラムやデータが格納されている。ＲＡＭ１５０４は、プログラムやデータを一時保持する揮発性の半導体メモリ（記憶装置）である。
【００２７】
ＣＰＵ１５０６は、ＲＯＭ１５０５やＨＤＤ１５０８などの記憶装置からプログラムやデータをＲＡＭ１５０４上に読み出し、処理を実行することで、コンピュータ１５００全体の制御や機能を実現する演算装置である。
【００２８】
クライアント端末１０１１、携帯端末１０１２、アクセス制御装置１０２１、プリントサービス提供装置１０２２、スキャンサービス提供装置１０２３、他サービス提供装置１０２４は、コンピュータ１５００のハードウェア構成により、後述するような各種処理を実現できる。
【００２９】
＜ソフトウェア構成＞
《サービス提供システム》
図１のサービス提供システム１１００は例えば図３に示すような処理ブロックにより実現される。図３は第１の実施形態に係るサービス提供システムの一例の処理ブロック図である。
【００３０】
図３のサービス提供システム１１００は、プログラムを実行することにより、サービスアプリ１１０１、プラットフォーム１１０２、管理データ記憶部１１０３及びプラットフォームＡＰＩ（Application Programming Interface）１１０４を実現している。
【００３１】
サービスアプリ１１０１は、プリントサービスアプリ１１１１、スキャンサービスアプリ１１１２、１つ以上のその他のサービスアプリ１１１３を一例として有する。
【００３２】
プリントサービスアプリ１１１１はプリントサービスを提供するアプリケーションである。スキャンサービスアプリ１１１２はスキャンサービスを提供するアプリケーションである。その他のサービスアプリ１１１３は何らかのサービスを提供するアプリケーションである。
【００３３】
プラットフォームＡＰＩ１１０４はプリントサービスアプリ１１１１、スキャンサービスアプリ１１１２、その他のサービスアプリ１１１３などのサービスアプリ１１０１が、プラットフォーム１１０２を利用するためのインタフェースである。プラットフォームＡＰＩ１１０４はサービスアプリ１１０１からの要求をプラットフォーム１１０２が受信するために設けられた予め定義されたインタフェースであり、例えば関数やクラス等により構成される。なお、サービス提供システム１１００を複数の情報処理装置に分散して構成する場合、プラットフォームＡＰＩ１１０４にはネットワーク経由で利用可能な例えばＷｅｂ  ＡＰＩを利用できる。
【００３４】
プラットフォーム１１０２は、認証処理部１１２１、機器通信部１１２２、セッション管理部１１２３、処理制御部１１２４、データ処理部１１２５を有する。データ処理部１１２５は、メッセージキュー１１３１、１つ以上のワーカ（Ｗｏｒｋｅｒ）１１３２を有する。
【００３５】
認証処理部１１２１はクライアント端末１０１１、携帯端末１０１２や画像形成装置１０１３などのオフィス機器からのログイン要求に基づいて認証を実行する。オフィス機器はクライアント端末１０１１、携帯端末１０１２、画像形成装置１０１３などの総称である。認証処理部１１２１は例えばユーザ管理情報記憶部１１４２にアクセスしてユーザを認証する。また、認証処理部１１２１は組織管理情報記憶部１１４１、機器管理情報記憶部１１４３にアクセスして画像形成装置１０１３などを認証する。
【００３６】
機器通信部１１２２はオフィス機器との通信を実行する。セッション管理部１１２３はオフィス機器とのセッションを管理する。処理制御部１１２４はサービスアプリ１１０１からの要求に基づいてデータ処理部１１２５が実行するデータ処理を制御する。データ処理部１１２５は処理制御部１１２４の制御によりデータ処理を実行する。
【００３７】
メッセージキュー１１３１はジョブの処理の種類（ジョブタイプ）に対応するキューを有し、処理制御部１１２４からジョブをキューイングされる。キューはジョブを処理する順番に保持する。ワーカ１１３２は担当するキューを監視している。ワーカ１１３２は監視しているキューにジョブがキューイングされると、そのジョブのジョブタイプに応じた処理を行う。また、ワーカ１１３２は後述するように、担当するキュー以外であっても条件に合致すれば、代行でジョブの処理を行う場合がある。
【００３８】
管理データ記憶部１１０３は組織管理情報記憶部１１４１、ユーザ管理情報記憶部１１４２、機器管理情報記憶部１１４３、ジョブ情報管理記憶部１１４４、共有ファイルストレージ１１４５を有する。
【００３９】
組織管理情報記憶部１１４１は、組織管理情報を記憶する。ユーザ管理情報記憶部１１４２は、ユーザ管理情報を記憶する。機器管理情報記憶部１１４３は機器管理情報を記憶する。ジョブ情報管理記憶部１１４４は、後述のジョブ情報テーブル１２０３、タスクステータステーブル１２０４、及び処理負荷テーブル１２０５を記憶している。共有ファイルストレージ１１４５は、キューイングされたジョブの電子文書ファイル等のファイルを記憶する。
【００４０】
サービス提供システム１１００は、例えば認証やデータ処理といった機能を提供するクラウド基盤と、クラウド基盤の機能を利用してプリントサービス等のサービス提供を行うサービス群として機能する。クラウド基盤は、例えばプラットフォーム１１０２、管理データ記憶部１１０３、プラットフォームＡＰＩ１１０４によって構成される。サービス群は例えばサービスアプリ１１０１によって構成される。
【００４１】
《ジョブ実行機能》
第１の実施形態に係るサービス提供システム１１００は図４に示す処理ブロックによりジョブ実行処理を実現している。図４は第１の実施形態に係るサービス提供システムにおいてジョブ実行処理を実現する一例の処理ブロック図である。
【００４２】
図４のサービス提供システム１１００は、フロントエンドアプリ１１１１ａ、プラットフォーム１１０２、ジョブ情報管理記憶部１１４４及び共有ファイルストレージ１１４５により、ユーザからのジョブを実行する。
【００４３】
図４では、プリントサービスアプリ１１１１の一機能であるフロントエンドアプリ１１１１ａを表しているが、スキャンサービスアプリ１１１２や、その他のサービスアプリ１１１３の一機能であるフロントエンドアプリであってもよい。
【００４４】
また、図４のサービス提供システム１１００はプラットフォーム１１０２のドキュメント処理要求管理部１１２４ａ、メッセージキュー１１３１及びワーカ１１３２を利用してユーザからのジョブを実行する。ドキュメント処理要求管理部１１２４ａは処理制御部１１２４の一機能である。
【００４５】
フロントエンドアプリ１１１１ａはクライアント端末１０１１などの端末装置から送信されたジョブを受信する。フロントエンドアプリ１１１１ａは、ジョブに含まれる電子文書ファイル等の処理対象のファイルを共有ファイルストレージ１１４５に登録する機能を有する。また、フロントエンドアプリ１１１１ａは、共有ファイルストレージ１１４５に登録した処理対象のファイルのＵＲＩとともに、ジョブをドキュメント処理要求管理部１１２４ａに投入する機能を備える。このように、フロントエンドアプリ１１１１ａは必要な処理を判断してプラットフォーム１１０２にジョブの処理を実行させる制御を行う。
【００４６】
フロントエンドアプリ１１１１ａは判断した必要な処理を「ｄｏｃ２ｒｐｃｓ」のようなジョブタイプのパラメータにして、ドキュメント処理要求管理部１１２４ａへのジョブ情報に埋め込む。なお、ジョブタイプのパラメータの詳細は後述する。
【００４７】
ドキュメント処理要求管理部１１２４ａはジョブタイプをパラメータとして含むジョブ情報を受け付ける。ドキュメント処理要求管理部１１２４ａはフロントエンドアプリ１１１１ａから受け付けたジョブ情報を解析し、ジョブタイプが合致するメッセージキュー１１３１のキューに、ジョブを入れる（キューイングする）。また、ドキュメント処理要求管理部１１２４ａは、メッセージキュー１１３１のキューへジョブを入れることに並行して、ジョブ情報管理記憶部１１４４にジョブ情報を登録する。
【００４８】
メッセージキュー１１３１は複数のジョブタイプに対応するキューを有する。ワーカ１１３２は、自分が担当するキューを監視（ポーリング）しており、キューにジョブが存在していたら、ジョブ情報管理記憶部１１４４に登録された、そのジョブに対応するジョブ情報を取りに行く。
【００４９】
また、ワーカ１１３２は処理対象のファイルを共有ファイルストレージ１１４５から取得する。ワーカ１１３２は、取得した処理対象のファイルに対し、ジョブ情報管理記憶部１１４４から取得したジョブ情報に基づいて、処理を行う。
【００５０】
例えばデータ変換の処理を行う場合、ワーカ１１３２は処理対象のファイルのＵＲＩに基づいて、共有ファイルストレージ１１４５から処理対象のファイルを取得する。ワーカ１１３２は取得した処理対象のファイルのデータ変換を行う。ワーカ１１３２は、データ変換後のファイルを共有ファイルストレージ１１４５に登録し、ジョブ情報管理記憶部１１４４に登録されているジョブ情報を更新する。
【００５１】
第１の実施形態に係るサービス提供システム１１００は、ジョブの処理の代行における非効率性を低減するため、後述するようなジョブ情報テーブル１２０３、タスクステータステーブル１２０４、及び処理負荷テーブル１２０５をジョブ情報管理記憶部１１４４に記憶している。
【００５２】
例えば処理を行うワーカ１１３２は、実行中のジョブの処理の種類と開始日時とをタスクステータステーブル１２０４にジョブの情報として登録しておく。ジョブの処理が終わると、ワーカ１１３２はタスクステータステーブル１２０４から処理が終わったジョブの情報を削除する。また、ワーカ１１３２は共有ファイルストレージ１１４５に処理結果を登録し、そのＵＲＩとともにジョブ情報テーブル１２０３のステータスを処理完了に更新する。
【００５３】
第１の実施形態に係るサービス提供システム１１００は、後述するようなジョブ情報テーブル１２０３、タスクステータステーブル１２０４、及び処理負荷テーブル１２０５を利用して、後述のように、ジョブの処理の代行における非効率性を低減する。
【００５４】
＜処理の詳細＞
以下では第１の実施形態に係るサービス提供システム１１００のジョブ実行処理の詳細について説明する。
【００５５】
《ワーカのキュー処理》
図５は、ワーカのキュー処理の一例について説明する図である。図５では「ｉｍａｇｅ２ｐｄｆ」のジョブタイプを担当するワーカ１１３２（以下、単に「Ｗｏｒｋｅｒ１」と呼ぶ）と、「ｓｅｎｄ＿ｍａｉｌ」のジョブタイプを担当するワーカ１１３２（以下、単に「Ｗｏｒｋｅｒ２」と呼ぶ）と、「ｂａｒｃｏｄｅＲｅｃｏｇｎｉｔｉｏｎ」のジョブタイプを担当するワーカ１１３２（以下、単に「Ｗｏｒｋｅｒ３」と呼ぶ）とを一例として表している。
【００５６】
例えば「ｉｍａｇｅ２ｐｄｆ」のジョブタイプは、画像をＰＤＦに変換する処理の種類を表している。「ｓｅｎｄ＿ｍａｉｌ」のジョブタイプは、メール送信の処理の種類を表している。「ｂａｒｃｏｄｅＲｅｃｏｇｎｉｔｉｏｎ」のジョブタイプは、バーコード認識の処理の種類を表している。Ｗｏｒｋｅｒ１、Ｗｏｒｋｅｒ２、及びＷｏｒｋｅｒ３はメッセージキュー１１３１を監視し、自分が担当するキューからジョブを取得し、そのジョブのジョブタイプに応じた処理を行う。
【００５７】
なお、図５では省略して記載しているが、ジョブタイプが合致するメッセージキュー１１３１のキューにジョブが振り分けられて、キューイングされているものとする。例えば図５（Ａ）ではＷｏｒｋｅｒ１が「１」のジョブ、Ｗｏｒｋｅｒ２が「２」がジョブ、及びＷｏｒｋｅｒ３が「５」のジョブを取得して処理を行う。なお、図５（Ａ）の処理が終わると、メッセージキュー１１３１に存在するジョブは図５（Ｂ）のようになる。
【００５８】
図５（Ｂ）では担当するジョブタイプ「ｉｍａｇｅ２ｐｄｆ」のジョブが存在するＷｏｒｋｅｒ１が「３」のジョブを取得して処理を行う。一方、担当するジョブタイプ「ｓｅｎｄ＿ｍａｉｌ」のジョブが存在しないＷｏｒｋｅｒ２は何もせず、ジョブタイプ「ｓｅｎｄ＿ｍａｉｌ」のジョブがキューイングされるのを待ち続ける。
【００５９】
同様に、担当するジョブタイプ「ｂａｒｃｏｄｅＲｅｃｏｇｎｉｔｉｏｎ」のジョブが存在しないＷｏｒｋｅｒ３は何もせず、ジョブタイプ「ｂａｒｃｏｄｅＲｅｃｏｇｎｉｔｉｏｎ」のジョブがキューイングされるのを待ち続ける。
【００６０】
図５のようにＷｏｒｋｅｒ１のみがジョブタイプ「ｉｍａｇｅ２ｐｄｆ」を担当する場合は、図５（Ｂ）の状況から「３」「４」「６」のジョブがＷｏｒｋｅｒ１によって順番に処理される。
【００６１】
このため、図５の例ではＷｏｒｋｅｒ２及びＷｏｒｋｅｒ３が動くためのリソース（ＣＰＵ／メモリ／ＨＤＤ／ネットワークなど）が残っているにも関わらず、「６」のジョブを依頼したユーザの待ち時間が長くなるという問題がある。
【００６２】
そこで、このような問題を緩和するため、例えばＷｏｒｋｅｒ１及びＷｏｒｋｅｒ２に二つのジョブタイプ「ｉｍａｇｅ２ｐｄｆ」及び「ｓｅｎｄ＿ｍａｉｌ」を担当させることが考えられる。この場合は、二つのジョブタイプ「ｉｍａｇｅ２ｐｄｆ」及び「ｓｅｎｄ＿ｍａｉｌ」のどちらのジョブがキューに溜まっても、Ｗｏｒｋｅｒ１及びＷｏｒｋｅｒ２がジョブを取得して処理できる。
【００６３】
しかし、担当するジョブタイプ「ｂａｒｃｏｄｅＲｅｃｏｇｎｉｔｉｏｎ」のジョブが存在しないＷｏｒｋｅｒ３は何もせず、ジョブタイプ「ｂａｒｃｏｄｅＲｅｃｏｇｎｉｔｉｏｎ」のジョブがキューイングされるのを待ち続ける。このように、ワーカ１１３２が担当するジョブタイプを静的に決める場合は、ユーザが多く投入するジョブタイプが分からないことから、ジョブの処理の非効率性を低減させることが難しかった。
【００６４】
また、上記のような問題を緩和するため、Ｗｏｒｋｅｒ１、Ｗｏｒｋｅｒ２、及びＷｏｒｋｅｒ３は、担当するジョブタイプを動的に変えてジョブの処理を代行する図６のような仕組みを備えることが考えられる。
【００６５】
図６は、ジョブの処理を代行する仕組みについて説明する図である。図６（Ａ）は図５（Ａ）と同一である。図６（Ｂ）では担当するジョブタイプ「ｉｍａｇｅ２ｐｄｆ」のジョブが存在するＷｏｒｋｅｒ１が「３」のジョブを取得して処理を行う。また、自分の担当するジョブタイプのジョブがメッセージキュー１１３１に存在しないＷｏｒｋｅｒ２及びＷｏｒｋｅｒ３は、他のＷｏｒｋｅｒ１が担当しているジョブタイプのジョブが所定数以上溜まっている場合に、溜まっているジョブの処理を代行する。例えば図６（Ｂ）ではＷｏｒｋｅｒ１が「３」のジョブ、Ｗｏｒｋｅｒ２が「４」のジョブ、及びＷｏｒｋｅｒ３が「６」のジョブを取得して処理を行う。
【００６６】
図６の仕組みを導入すれば、図５の仕組みよりもリソースを効率的に活用することができるので、図５の仕組みよりも「６」のジョブを依頼したユーザの待ち時間を短くすることができる。しかし、図６（Ｂ）では全てのＷｏｒｋｅｒ１、Ｗｏｒｋｅｒ２、及びＷｏｒｋｅｒ３がジョブタイプ「ｉｍａｇｅ２ｐｄｆ」のジョブを実行することになる。
【００６７】
すると、例えばＷｏｒｋｅｒ２が「４」のジョブを取得した後にメッセージキュー１１３１にキューイングされたジョブタイプ「ｓｅｎｄ＿ｍａｉｌ」の「７」のジョブが処理されずに滞ってしまう。このような状況は、いずれかのユーザがジョブタイプ「ｉｍａｇｅ２ｐｄｆ」のジョブを大量に投入した際に起こり得る。このような状況はサービス提供システム１１００を利用するユーザが増加すると、さらに発生頻度が増すことになり、一つのジョブを投入したユーザの待ち時間が長くなる場合があるという問題がある。
【００６８】
さらに、サービス提供システム１１００では正常に動作しているかを調べるため、所定時間の間隔で所定のジョブ（以下、監視ジョブと呼ぶ）を投入し、ジョブの処理結果が正常終了するか否かをチェックしている。このようにサービス提供システム１１００では監視ジョブの処理が終わるのを所定時間待って、監視ジョブの処理結果が正常終了であるかをチェックしている。
【００６９】
しかし、図６（Ｂ）のように全てのＷｏｒｋｅｒ１、Ｗｏｒｋｅｒ２、及びＷｏｒｋｅｒ３がジョブタイプ「ｉｍａｇｅ２ｐｄｆ」のジョブを実行している状況で、監視ジョブが投入されると、所定時間で監視ジョブの処理が正常終了しない場合があった。サービス提供システム１１００は所定時間で監視ジョブの処理が正常終了していなければエラーを出力する。なお、エラーが出力された場合、システム管理者やユーザにエラーの発生を通知するサービス提供システム１１００では、サービスレベル目標（ＳＬＯ）を守れないシステムになってしまい、システム運用上も回避すべき重要な課題である。
【００７０】
そこで、第１の実施形態に係るサービス提供システム１１００のジョブ実行処理では図６のジョブの処理を代行する仕組みに、図７に示すジョブの処理の代行を中止する仕組みを追加する。図７は、ジョブの処理の代行を中止する仕組みについて説明する図である。
【００７１】
図７（Ａ）は図５（Ａ）と同一である。図７（Ｂ）では、担当するジョブタイプ「ｉｍａｇｅ２ｐｄｆ」のジョブが存在するＷｏｒｋｅｒ１が「３」のジョブを取得して処理を行う。また、自分の担当するジョブタイプのジョブがメッセージキュー１１３１に存在しないＷｏｒｋｅｒ２は、他のＷｏｒｋｅｒ１が担当しているジョブタイプ「ｉｍａｇｅ２ｐｄｆ」のジョブの処理を代行する。
【００７２】
一方で、自分の担当するジョブタイプのジョブがメッセージキュー１１３１に存在しないＷｏｒｋｅｒ３は、他のＷｏｒｋｅｒ１が担当しているジョブタイプ「ｉｍａｇｅ２ｐｄｆ」のジョブの処理を代行しない。
【００７３】
このように、第１の実施形態に係るサービス提供システム１１００のジョブ実行処理では自分の担当するジョブタイプのジョブがメッセージキュー１１３１に存在しないＷｏｒｋｅｒ２及びＷｏｒｋｅｒ３がジョブの処理の代行について異なる判定を行う。第１の実施形態に係るサービス提供システム１１００ではワーカ１１３２が例えば図８に示す手順でジョブ実行処理を行う。
【００７４】
図８はワーカのジョブ実行処理の一例のフローチャートである。ステップＳ１０においてワーカ１１３２はメッセージキュー１１３１及び図９のジョブ情報テーブル１２０３を参照し、自分の担当するジョブタイプのジョブがメッセージキュー１１３１に存在するか否かを判定する。
【００７５】
図９はジョブ情報テーブルの一例の構成図である。ジョブ情報テーブル１２０３は実行中のジョブ、受け付け状態のジョブ、完了したジョブ、エラーになったジョブを含め、全てのジョブの情報が格納されている。ジョブ情報テーブル１２０３はジョブＩＤ、ユーザＩＤ、ステータス、投入日時、ジョブタイプ、及びパラメータをデータ項目として有している。
【００７６】
ジョブＩＤはジョブの識別情報の一例である。ユーザＩＤはジョブを投入したユーザの識別情報の一例である。ステータスは実行中、受け付け状態、完了、エラーなどのジョブの処理状況を示している。投入日時はジョブが投入された日時を示している。ジョブタイプはジョブの処理の種類を示している。パラメータはジョブの処理に必要なパラメータを示している。
【００７７】
ワーカ１１３２は自分の担当するジョブタイプのジョブがメッセージキュー１１３１に存在すればステップＳ２０に進み、メッセージキュー１１３１のキューから自分の担当するジョブタイプのジョブを取得して、ジョブの処理を実行する。
【００７８】
一方、ワーカ１１３２は自分の担当するジョブタイプのジョブがメッセージキュー１１３１に存在しなればステップＳ１２に進み、他のワーカ１１３２が担当するジョブタイプのジョブが三つ以上溜まっているキューがあるか否かを判定する。なお、ステップＳ１２における条件値（三つのジョブ）は一例であって、五つのジョブ等、他の条件値であってもよい。
【００７９】
他のワーカ１１３２が担当するジョブタイプのジョブが三つ以上溜まっているキューがあればステップＳ１４に進み、図１０に示すようなタスクステータステーブル１２０４からタスク一覧を取得する。
【００８０】
図１０はタスクステータステーブルの一例の構成図である。タスクステータステーブル１２０４は担当Ｗｏｒｋｅｒ、ジョブＩＤ、ジョブタイプ、ステータス、開始日時、及びユーザＩＤをデータ項目として有している。
【００８１】
ジョブＩＤ、ジョブタイプ、ステータス、及びユーザＩＤは図９のジョブ情報テーブルと同一であるため、説明を省略する。担当Ｗｏｒｋｅｒはワーカ１１３２を識別する識別情報の一例である。開始日時はジョブの処理が開始された日時を示している。図１０のタスクステータステーブル１２０４から読み出すタスク一覧は、現在、ワーカ１１３２により実行されているジョブの情報を示している。図１０のタスクステータステーブル１２０４によれば、現在、ワーカ１１３２により実行されているジョブのジョブＩＤ、ジョブタイプ、ステータス、開始日時、及びユーザＩＤを確認できる。
【００８２】
ステップＳ１４に続いてステップＳ１６に進み、ワーカ１１３２はステップＳ１４で取得したタスク一覧を参照しながら、ジョブの処理の代行を中止する下記の条件、又は下記の条件の組み合わせに合致するか否かを判定する。
【００８３】
例えばジョブの処理の代行を中止する条件の一例としては、自分が代行して処理しようとしているジョブ（候補ジョブ）のジョブタイプが、自分以外のワーカ１１３２の全てが実行しているジョブのジョブタイプと同一である処理状況がある。
【００８４】
また、ジョブの処理の代行を中止する条件の一例としては、自分が代行して処理しようとしているジョブタイプのジョブを、所定時間（例えば１０分）以上、継続して処理している自分以外のワーカ１１３２がある処理状況がある。ジョブの処理の継続時間は現在日時と開始日時との差分から算出できる。また、ジョブの処理の代行を中止する条件の一例としては、候補ジョブを依頼したユーザ（依頼者）が、自分以外のワーカ１１３２が実行しているジョブの依頼者に含まれている処理状況がある。
【００８５】
ジョブの処理の代行を中止する下記の条件、又は下記の条件の組み合わせに合致していなければステップＳ２０に進み、ワーカ１１３２は候補ジョブの処理を代行する。ワーカ１１３２はジョブの処理の代行を中止する下記の条件、又は下記の条件の組み合わせに合致していれば、ステップＳ１８に進む。
【００８６】
ステップＳ１８において、ワーカ１１３２は再びメッセージキュー１１３１及びジョブ情報テーブル１２０３を参照し、次の候補ジョブがあるか否かを判定する。なお、次の候補ジョブは例えば下記のような方法で選択される。
【００８７】
次の候補ジョブを選択する方法の一例としては、他のワーカ１１３２が担当するジョブタイプのジョブのうち、三つ以上溜まっていないキューのジョブが選択される。例えば図７の例であればＷｏｒｋｅｒ３が「７」のジョブを候補ジョブとして選択する。
【００８８】
また、次の候補ジョブを選択する方法の一例としては、例えばジョブ情報テーブル１２０３を参照し、ジョブの投入数が最も少ないユーザのジョブが選択される。図９のジョブ情報テーブル１２０３の場合、ユーザＩＤ「ＡＡＡ」のユーザのジョブが３件、ユーザＩＤ「ＢＢＢ」のユーザのジョブが２件、ユーザＩＤ「ＣＣＣ」のユーザのジョブが１件であるため、ジョブＩＤ「８」のジョブが候補ジョブとして選択される。
【００８９】
また、次の候補ジョブを選択する方法の一例としては、例えばジョブ情報テーブル１２０３を参照し、投入日時からの経過時間が最も長いジョブが選択される。図９のジョブ情報テーブル１２０３の場合、投入日時からの経過時間（待たされている時間）は現在日時と開始日時との差分から算出できる。図９のジョブ情報テーブル１２０３では、投入日時からの経過時間が最も長いジョブＩＤ「６」のジョブが、ステップＳ１６で代行を中止すると判定したジョブタイプ「ｉｍａｇｅ２ｐｄｆ」であるため、候補ジョブとして選択されない。投入日時からの経過時間が次に長いジョブＩＤ「７」のジョブが、候補ジョブとして選択される。
【００９０】
さらに、次の候補ジョブを選択する方法の一例としては、タスクステータステーブル１２０４及び図１１の処理負荷テーブル１２０５を参照し、負荷の重いジョブが実行中であれば負荷の軽いジョブを候補ジョブとして選択し、負荷の軽いジョブが実行中であれば負荷の重いジョブを候補ジョブとして選択する。
【００９１】
図１１は処理負荷テーブルの一例の構成図である。処理負荷テーブル１２０５はジョブタイプ及びリソース消費量をデータ項目として有している。処理負荷テーブル１２０５は各ジョブタイプのジョブを実行するときのリソースの負荷を数値化して表したリソース消費量を表している。リソース消費量の数値が大きいほど、リソースの負荷が重い。例えばリソース消費量は、ジョブの処理を実行するサーバインスタンスのリソースのうち、その処理が利用するＣＰＵコア数、メモリ量、及びＨＤＤ容量と、その処理の処理時間を元に算出する指標値である。
【００９２】
図１１の処理負荷テーブル１２０５の場合、例えばジョブタイプ「ｏｃｒ」のジョブが実行中であれば、ジョブタイプ「ｓｅｎｄ＿ｍａｉｌ」のジョブが候補ジョブとして選択される。例えばジョブタイプ「ｉｍａｇｅ２ｐｄｆ」のジョブが実行中であれば、ジョブタイプ「ｂａｒｃｏｄｅＲｅｃｏｇｎｉｔｉｏｎ」のジョブが候補ジョブとして選択されることになる。例えば図１１の処理負荷テーブル１２０５の場合はリソース消費量の合計値が「１１０」よりも大きくならないように候補ジョブを選択する。
【００９３】
ステップＳ１８において、次の候補ジョブがあればワーカ１１３２はステップＳ２０に進み、次の候補ジョブの処理を代行する。次の候補ジョブがなければ、ワーカ１１３２はジョブを実行せずに次回のポーリングまで待機する。なお、ステップＳ１２において他のワーカ１１３２が担当するジョブタイプのジョブが三つ以上溜まっているキューがなければステップＳ１８にスキップする。
【００９４】
ここで、図７（Ｂ）のＷｏｒｋｅｒ３を一例として、図８のフローチャートのジョブ実行処理について説明する。ステップＳ１０においてＷｏｒｋｅｒ３は自分が担当しているジョブタイプ「ｂａｒｃｏｄｅＲｅｃｏｇｎｉｔｉｏｎ」のジョブがメッセージキュー１１３１に存在しないと判定する。
【００９５】
ステップＳ１２に進み、Ｗｏｒｋｅｒ３は他のＷｏｒｋｅｒ１が担当しているジョブタイプ「ｉｍｅｇｅ２ｐｄｆ」のジョブがキューに三つ以上溜まっていると判定する。Ｗｏｒｋｅｒ３はステップＳ１４に進み、タスクステータステーブル１２０４からタスク一覧を取得する。なお、タスク一覧はステップＳ２０でジョブの処理が実行する際に、タスクステータステーブル１２０４に書き込まれる。
【００９６】
ステップＳ１６に進み、Ｗｏｒｋｅｒ３はジョブの処理の代行を中止する条件の一例である「自分が代行して処理しようとしているジョブ（候補ジョブ）のジョブタイプが、自分以外のワーカ１１３２の全てが実行しているジョブのジョブタイプと同一である処理状況」と判定し、図７（Ｂ）の「６」のジョブの処理の代行を中止する。ステップＳ１８に進み、Ｗｏｒｋｅｒ３は三つ以上溜まっていないキューの「７」のジョブを候補ジョブとして選択し、この候補ジョブの処理を代行する。
【００９７】
＜まとめ＞
第１の実施形態によれば、ジョブの処理の代行における非効率性を低減することが可能なサービス提供システム１１００を提供できる。
【００９８】
本発明は、具体的に開示された上記の実施形態に限定されるものではなく、特許請求の範囲から逸脱することなく、種々の変形や変更が可能である。上記で説明した実施形態の各機能は、一又は複数の処理回路によって実現することが可能である。ここで、本明細書における「処理回路」とは、電子回路により実装されるプロセッサのようにソフトウェアによって各機能を実行するようプログラミングされたプロセッサや、上記で説明した各機能を実行するよう設計されたASIC(Application Specific Integrated Circuit)、DSP（digital signal processor）、FPGA（field programmable gate array）や従来の回路モジュール等のデバイスを含むものとする。
【００９９】
なお、ワーカ１１３２は特許請求の範囲に記載した実行手段の一例である。メッセージキュー１１３１のキューは保持手段の一例である。システム１０００及びサービス提供システム１１００は情報処理システムの一例である。
【符号の説明】
【０１００】
１０００    システム
１０１１    クライアント端末
１０１２    携帯端末
１０１３    画像形成装置
１０２１    アクセス制御装置
１０２２    プリントサービス提供装置
１０２３    スキャンサービス提供装置
１０２４    他サービス提供装置
１１００    サービス提供システム
１１０１    サービスアプリ
１１０２    プラットフォーム
１１０３    管理データ記憶部
１１０４    プラットフォームＡＰＩ（Application Programming Interface）
１１１１    プリントサービスアプリ
１１１１ａ    フロントエンドアプリ
１１１２    スキャンサービスアプリ
１１１３    その他のサービスアプリ
１１２１    認証処理部
１１２２    機器通信部
１１２３    セッション管理部
１１２４    処理制御部
１１２４ａ    ドキュメント処理要求管理部
１１２５    データ処理部
１１３１    メッセージキュー
１１３２    ワーカ（Ｗｏｒｋｅｒ）
１１４１    組織管理情報記憶部
１１４２    ユーザ管理情報記憶部
１１４３    機器管理情報記憶部
１１４４    ジョブ情報管理記憶部
１１４５    共有ファイルストレージ
１２０３    ジョブ情報テーブル
１２０４    タスクステータステーブル
１２０５    処理負荷テーブル
１５００    コンピュータ
１５０１    入力装置
１５０２    表示装置
１５０３    外部Ｉ／Ｆ
１５０３ａ    記録媒体
１５０４    ＲＡＭ
１５０５    ＲＯＭ
１５０６    ＣＰＵ
１５０７    通信Ｉ／Ｆ
１５０８    ＨＤＤ
Ｂ    バス
ＦＷ    ファイヤウォール
Ｎ１〜Ｎ３    ネットワーク
【先行技術文献】
【特許文献】
【０１０１】
【特許文献１】特開２００９−１６９７５６号公報
【図１】
2020144606.tif 000003
【図２】
2020144606.tif 000004
【図３】
2020144606.tif 000005
【図４】
2020144606.tif 000006
【図５】
2020144606.tif 000007
【図６】
2020144606.tif 000008
【図７】
2020144606.tif 000009
【図８】
2020144606.tif 000010
【図９】
2020144606.tif 000011
【図１０】
2020144606.tif 000012
【図１１】
2020144606.tif 000013