JP2014149690A

JP2014149690A - 情報処理システム、監視装置、情報処理システムの制御方法およびコンピュータプログラム

Info

Publication number: JP2014149690A
Application number: JP2013018219A
Authority: JP
Inventors: Keisho Towata; 啓晶砥綿
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2013-02-01
Filing date: 2013-02-01
Publication date: 2014-08-21

Abstract

【課題】ジョブの実行状況とスケーリングの効果に基づいて、スケーリング条件を定義することなしに自動スケーリングを実現する情報処理装置を提供すること。
【解決手段】情報処理システムが備える監視装置１０９は、複数のジョブ処理装置１０３、１０４の動作状況を監視し、特定のジョブ処理装置１０３、１０４が規定数を超えるジョブを処理していることに応じて、いずれか一つのジョブ処理装置１０３、１０４のタスクを増加させるように指示し、スケールアウト指示に基づきタスクを増加させてジョブを処理するジョブ処理装置１０３、１０４を規定時間の間監視し、タスクを増加させた前記ジョブ処理装置１０３、１０４においてスループットが向上されているか否かを確認し、前記スループットが向上されていないと確認された場合、増加された前記タスクを削減するように指示する。
【選択図】図１

Description

本発明は、情報処理システム、監視装置、情報処理システムの制御方法およびコンピュータプログラムに関する。

サーバコンピュータ側で各種処理を行う形態として、クラウドコンピューティングシステムやＳａａＳ（ＳｏｆｔｗａｒｅａｓａＳｅｒｖｉｃｅ）という技術が利用され始めている。クラウドコンピューティングでは、多くのコンピューティング・リソースを利用し、データ変換やデータ処理を分散実行することで、多くのクライアントからの要求を同時に処理することが可能となる。また、クラウドコンピューティングの特徴を活用するため、下記のような方式でクライアントからの要求を実行する技術が存在する。

まず、サーバでの一連の処理であるジョブを細かく規定されたタスクの連結として定義する。次に、それらを複数のサーバ、複数のプロセスによって同時並行で処理する。それによって、多数のジョブをスケーラブルに処理することができる。上記のタスクは、複数のサーバが、キューイングされたクライアントの要求を非同期で取得して実行している。この構成は、コンピュータリソースのスケーラビリティ向上や、クライアントからの要求のピーク時にシステムダウンを防ぐ効果をもたらす。本明細書ではこのようなシステムをクラウドシステムと称する。

クラウドシステムにおいて、タスクを起動、停止することにより、クラウドシステムとしてのスループットを拡大、縮小することができる。スループットの拡大のためにタスクを起動させることをスケールアウト、スループットの縮小のためにタスクを停止させることをスケールインと呼ぶ。スケールアウトすることによって、スループットが拡大し、より多くのクライアントからの要求を処理することができる。また、スケールインすることで、スループットは減少するもの、サーバリソースを運用するためのコストを削減することができる。以下では、スケールアウト、スケールインをまとめてスケーリングと呼ぶ。

スケーリングは管理装置等を介してクライアントが手動で実施することができるが、クライアントからの要求に対してより適した細やかなスケーリングを実施するために、自動的にスケーリングを実行できることが求められる。また、自動的にスケーリングを行うためには、その判断基準となるスケーリング条件が必要になる。例えば、特許文献１は、ジョブを処理するジョブ処理装置を監視する監視装置から計測値を取得し、当該計測値と予め定義されたスケーリング条件に基づいてスケーリングを実行する情報処理システムを開示する。

特開２０１２−８９１０９号公報

上述の自動スケーリング技術では、スケーリング条件をあらかじめ厳密に定義する必要がある。しかしながら、ジョブの実行に必要なリソースは、実行するジョブの内容や、サーバのリソース消費状況によって変化するため、スケーリング条件を厳密に定義するのは難しいという課題がある。スケーリング条件を誤って設定してしまった場合には、効果のないスケーリング、逆効果となるスケーリングを実施してしまう可能性もある。そこで、本発明は、ジョブの実行状況とスケーリングの効果に基づいて、スケーリング条件を定義することなしに自動スケーリングを実現する情報処理装置を提供することを目的とする。

本発明の一実施形態の情報処理システムは、ユーザ装置からジョブ処理要求を受付ける管理装置と、前記管理装置にジョブを問合せ、前記問合せに応じて取得したジョブを処理する複数のジョブ処理装置と、監視装置とを備える。前記監視装置は、前記情報処理システム上で動作する前記複数のジョブ処理装置の動作状況を監視する監視手段と、前記監視手段により、特定のジョブ処理装置が規定数を超えるジョブを処理していることが監視されたことに応じて、前記複数のジョブ処理装置のうちいずれか一つのジョブ処理装置のタスクを増加させるスケールアウトを指示するスケールアウト指示手段と、前記スケールアウト指示手段による指示に基づきタスクを増加させてジョブを処理する前記ジョブ処理装置を規定時間の間監視し、タスクを増加させた前記ジョブ処理装置においてスループットが向上されているか否かを確認する確認手段と、前記確認手段による確認の結果、前記スループットが向上されていないと確認された場合、増加された前記タスクを削減するスケールインを指示するスケールイン指示手段と、を有する。

本発明の情報処理システムによれば、ジョブの実行状況とスケーリングの効果に基づいて、スケーリング条件を定義することなしに自動スケーリングを実現することが可能となる。

本実施形態の情報処理システムの全体構成を示す図である。クライアント端末、サーバコンピュータのハードウェア構成図である。クライアント端末のシステム構成図である。画像形成装置の内部構成の詳細を示す図である。スキャンサービスサーバ群の構成例を示す図である。スキャンチケット作成画面の例を示す図である。チケット一覧画面の一例を示す図である。チケット管理ＤＢとテンプレート管理ＤＢの一例を示す図である。タスクサーバの構成例を示す図である。フローサービスサーバ群の構成例を示す図である。ルート管理サービスサーバ群の構成例を示す図である。ルート情報管理ＤＢの一例を示す図である。タスク情報管理ＤＢの一例を示す図である。ジョブ管理サービスサーバ群の構成例を示す図である。ジョブ情報管理ＤＢの一例を示す図である。ジョブ量管理ＤＢの一例を示す図である。スケーリングサーバの構成例を示す図である。監視履歴ＤＢの一例を示す図である。タスクステータスＤＢの一例を示す図である。スケールアウト実行履歴ＤＢの一例を示す図である。スケールイン実行履歴ＤＢの一例を示す図である。実行履歴画面の一例を示す図である。情報処理システムの動作処理の例を説明するシーケンス図である。スケールアウトのフローチャート（前半部）である。スケールアウトのフローチャート（後半部）である。スケールインのフローチャート（前半部）である。スケールインのフローチャート（後半部）である。

（実施例１）
図１は、本実施形態の情報処理システムの全体構成を示す図である。本実施形態の情報処理システムは、クラウドシステムであって、クライアント端末１０６のユーザに画像処理サービスを提供する。

図１中の情報処理システムは、スキャンサービスサーバ群１０１、フローサービスサーバ群１０２、タスクサーバ１０３、１０４、クライアント端末１０６、画像形成装置１０７、クラウドサービスサーバ１０８、スケーリングサーバ１０９を備える。図１に示す例では、タスクサーバは２台であるが、情報処理システムが備えるタスクサーバの数は、２台に限定されない。情報処理システムは、複数の任意数のタスクサーバを備えることができる。

スキャンサービスサーバ群１０１乃至タスクサーバ１０４は、ネットワーク１１０を介して通信可能に接続されている。クライアント端末１０６および画像形成装置１０７と、スキャンサービスサーバ群１０１乃至タスクサーバ１０４とは、ネットワーク１１１およびネットワーク１１０を介して通信可能に接続されている。また、クラウドサービスサーバ群１０８とスキャンサービスサーバ群１０１乃至タスクサーバ１０４とは、ネットワーク１１２およびネットワーク１１０を介して通信可能に接続されている。スケーリングサーバ１０９と、スキャンサービスサーバ群１０１乃至タスクサーバ１０４とは、ネットワーク１１０を介して通信可能に接続されている。

タスクサーバ、クライアント端末１０６、画像形成装置１０７、クラウドサービスサーバ群１０８は、複数台設けられている。ネットワーク１１０乃至１１２は、例えば、インターネット等のＬＡＮ、ＷＡＮ、電話回線、専用デジタル回線、ＡＴＭやフレームリレー回線、ケーブルテレビ回線、データ放送用無線回線等である。ＬＡＮは、ＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋの略称である。ＷＡＮは、ＷｉｄｅＡｒｅａＮｅｔｗｏｒｋの略称である。ＡＴＭは、ＡｓｙｎｃｈｒｏｎｏｕｓＴｒａｎｓｆｅｒＭｏｄｅの略称である。

ネットワーク１１０乃至１１２が、上述したＬＡＮ乃至データ放送用無線回線の組み合わせにより実現される通信ネットワークであってもよい。すなわち、ネットワーク１１０乃至１１２は、データの送受信が可能であればよい。この例では、本実施形態の情報処理システムは、クラウドシステムであるので、ネットワーク１１０、１１２は、インターネット、ネットワーク１１１は、企業内ネットワークやサービスプロバイダーのネットワークである。

スキャンサービスサーバ群１０１、フローサービスサーバ群１０２、タスクサーバ１０３、１０４は、複数のサーバコンピュータ群を有する。これらサーバコンピュータ群がクラウドサービスサーバ群を構成しており、ユーザに対してクラウドサービスを提供する。

この例では、クライアント端末１０６のユーザからの要求に応じて、画像形成装置１０７がスキャン実行を行って画像データを生成し、生成した画像データをスキャンサービスサーバ群１０１に投入する。スキャンサービスサーバ群１０１は、当該画像データに対応するジョブをフローサービスサーバ群１０２に投入するジョブ投入部として機能する。この例では、ジョブは、複数のタスクから構成される。例えば、ユーザからの要求に従い発行されるジョブがスキャンジョブであった場合、スキャン画像に対し画像処理を行う工程と、画像処理が施されたスキャン画像を保存する工程とが実行されるケースが考えられる。本願発明は、夫々の工程をタスクという単位で区切ることで、１つのジョブを複数のタスクで構成する。この形態のメリットは、複数のタスクを組み合わせることで、多様なジョブ処理を行うことができるという点である。フローサービスサーバ群１０２は、投入されたジョブを管理する。すなわちフローサービスサーバ群１０２は、ジョブ処理要求を受付ける管管理装置として機能する。

タスクサーバ１０３、１０４は、フローサービスサーバ群１０２にジョブを問合せ、問合せに応じて取得したジョブを処理する。このとき、タスクサーバ１０３、１０４は、フローサービスサーバ群１０２が管理するジョブに含まれるタスクを非同期で取得要求する。フローサービスサーバ群１０２は、管理しているジョブに含まれる複数のタスクのうち、取得要求元のタスクサーバに対応するタスクであって、処理待ち状態のタスクを、取得要求元のタスクサーバに渡す。タスクを受け取ったタスクサーバ１０３は、特定のジョブ処理を施す。タスクサーバ１０３は、例えば、処理対象の画像データに対して画像処理を行ったり、ファイル共有機能を提供する他のクラウドサービスサーバ群に対して、画像データを送信する処理を行う。

なお、スキャンサービスサーバ群１０１乃至タスクサーバ１０４で構成されるクラウドサービスサーバ群とは異なる他のクラウドサービスサーバ群１０８がインターネット上に公開されており、これらも複数のサーバコンピュータ上にて実行されている。

クライアント端末１０６は、例えば、デスクトップパソコン、ノートパソコン、モバイルパソコン、ＰＤＡ（パーソナルデータシスタント）等である。クライアント端末１０６が、プログラムの実行環境が内蔵された携帯電話であってもよい。クライアント端末１０６では、Ｗｅｂブラウザ（インターネットブラウザ、ＷＷＷブラウザ、ＷｏｒｌｄＷｉｄｅＷｅｂの利用に供するブラウザ）等のプログラムを実行する環境が内蔵されている。

本実施形態の制御方法は、図１に示す情報処理システムの制御方法である。また、本実施形態のコンピュータプログラムは、この制御方法をコンピュータに実行させる。

図２は、クライアント端末、スキャンサービスサーバ群、フローサービスサーバ群、タスクサーバを実現するサーバコンピュータのハードウェア構成図の例である。クライアント端末１０６、サーバコンピュータは、ＣＰＵ２０２、ＲＡＭ２０３、ＲＯＭ２０４、ＨＤＤ２０５を備える。ＣＰＵは、ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔの略称である。ＲＡＭは、ＲａｎｄｏｍＡｃｃｅｓｓＭｅｍｏｒｙの略称である。ＲＯＭは、ＲｅａｄＯｎｌｙＭｅｍｏｒｙの略称である。ＨＤＤは、ＨａｒｄＤｉｓｋＤｒｉｖｅの略称である。また、クライアント端末１０６、サーバコンピュータは、ＮＩＣ２０９、キーボード２０７、ディスプレイ２０６、インタフェース２０８を備える。ＮＩＣは、ＮｅｔｗｏｒｋＩｎｔｅｒｆａｃｅＣａｒｄの略称である。

ＣＰＵ２０２は、装置全体の制御を行う。ＣＰＵ２０２は、ＨＤＤ２０５に格納されているアプリケーションプログラム、ＯＳ等を実行し、ＲＡＭ２０３にプログラムの実行に必要な情報、ファイル等を一時的に格納する制御を行う。ＯＳは、ＯｐｅｒａｔｉｎｇＳｕｓｔｅｍの略称である。ＲＯＭ２０４は、記憶手段であり、内部には、基本Ｉ／Ｏプログラム等の各種データを記憶する。ＲＡＭ２０３は、一時記憶手段であり、ＣＰＵ２０２の主メモリ、ワークエリア等として機能する。ＨＤＤ２０５は、外部記憶手段の一つであり、大容量メモリとして機能し、Ｗｅｂブラウザ等のアプリケーションプログラム、サービス群のプログラム、ＯＳ、関連プログラム等を格納している。

ディスプレイ２０６は、表示手段であり、キーボード２０７から入力したコマンド等を表示したりする。インタフェース２０８は、外部装置Ｉ／Ｆであり、プリンタ、ＵＳＢ機器、周辺機器を接続する。キーボード２０７は指示入力手段である。システムバス２０１は、装置内におけるデータの流れを司る。ＣＰＵ２０２乃至インタフェース２０８は、システムバス２０１に接続されている。インタフェースＮＩＣ２０９は、インタフェース２０８およびネットワーク１１０乃至１１２を介して、外部装置とのデータのやり取りを行う。なお、図２中に示す装置構成は一例であり、図２の構成例に限定されるものではない。例えば、データやプログラムの格納先は、その特徴に応じてＲＯＭ２０４、ＲＡＭ２０３、ＨＤＤ２０５のうちのいずれであってもよい。

図３は、クライアント端末を示す図である。図３は、クライアント端末１０６の構成例を示す。クライアント端末１０６は、Ｗｅｂブラウザ３０１を備える。Ｗｅｂブラウザ３０１は、スキャンサービスサーバ群１０１（図１）が提供するＷｅｂアプリケーションへのリクエストの送信と、レスポンスの表示等を行う。クラウドサービスを利用するユーザは、クライアント端末１０６のＷｅｂブラウザ３０１を利用して、クラウドサービスを利用する。

図４は、画像形成装置１０７の構成例を示す。この例では、画像形成装置１０７は、スキャン機能とプリント機能を併せ持つ装置である。なお、スキャンサービスを実現するためには、画像形成装置１０７が、プリント機能のない、スキャン専用装置であってもよい。

画像形成装置１０７は、画像処理ユニット４０１、印刷ユニット４０２、読み込みユニット４０３を備える。画像処理ユニット４０１は、画像処理を実行する。画像処理ユニット４０１は、例えば、印刷設定に応じたプリントデータを生成する。印刷ユニット４０２は、画像処理ユニット４０１によって生成されたプリントデータを媒体（例えば、紙媒体）に印刷出力する。読み込みユニット４０２は、例えば、不図示のスキャン装置を用いて、画像データを読み込む。

画像処理ユニット４０１は、ＣＰＵ４０４、直接記憶部４０５、間接記憶部４０６、ユーザインタフェース４０７、外部インタフェース４０８を備える。ＣＰＵ４０４は、所定のプログラムを実行し、画像形成装置１０７の各種制御を指示する。ＣＰＵ４０４は、ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔの略称である。直接記憶部４０５は、ＣＰＵ４０４がプログラムを実行する際に使用するワークメモリである。ＣＰＵ４０４が実行するプログラムは、直接記憶部４０５にロードされる。なお、ＣＰＵ４０４は、マルチプロセッサでもよい。

直接記憶部４０５は、ＲＡＭにより実現される。間接記憶部４０６には、アプリケーションプログラムおよびプラットフォームプログラムを含む各種プログラムが記憶されている。ＣＰＵ４０４が、間接記憶部４０６に記憶されている各種プログラムの実行時に、この各種プログラムを直接記憶部４０５へ移動する。間接記憶部４０６は、ＳＳＤ（Solid State Drive）、または、ＨＤＤ(Hard Disc Drive) により実現される。

この例では、ユーザが独自に開発した新しいアプリケーションを画像形成装置１０７上で実行できるプラットフォームを実現するプラットフォームプログラムが、間接記憶部４０６に記憶されている。プラットフォームによれば、画像形成装置１０７の操作画面をカスタマイズすることも可能になる。

以下に、プラットフォームの実現方法について説明する。ＣＰＵ４０４は、間接記憶部４０６に記憶されたプラットフォームプログラムを直接記憶部４０５に移動する。移動が完了するとＣＰＵ４０４は、プラットフォームプログラム（例えば、Ｊａｖａ（登録商標））を実行することができる状態になる。この例では、ＣＰＵ４０４が、プラットフォームプログラムを実行することを、プラットフォームが起動すると称する。なお、プラットフォームは、画像形成装置１０７のファームウェア上で動作することになる。プラットフォームプログラムは、オブジェクト指向で記述されたアプリケーションプログラムを実行するための環境を提供する。

次に、プラットフォーム上でアプリケーションプログラムを実行する方法について詳細に説明する。この例では、プラットフォーム上には、スキャンした画像をクラウドサービスに送信するスキャンソフトウェアが動作している。スキャンソフトウェアは、ネットワークを介して接続されているスキャンサービスサーバ群１０１より、例えば、ＨＴＴＰ（Hyper Text Transfer Protocol）などの通信プロトコルによってスキャンチケットの一覧の受信を行う。スキャンチケットにはスキャンの為の設定や、その後の処理フローといった情報が記録されている。以降、スキャンソフトウェアを実行することで実現するソフトウェア部をスキャンソフトウェア部と呼ぶ。

ユーザは、スキャンソフトウェア部にて表示されたスキャンチケット一覧からスキャンチケットを選択し、原稿を読み込ませることでスキャンを完了できる。スキャンソフトウェア部は、ユーザが選択したスキャンチケットの情報とスキャンした画像データを合わせてスキャンサービスサーバ群１０１に送信する。このように、プラットフォームでアプリケーションプログラムを実行することによって、画像形成装置１０７の制御を実現することができる。

次に、アプリケーションプログラムの実行方法について説明する。起動したプラットフォームは、間接記憶部４０６に記憶されたアプリケーションプログラムを直接記憶部４０５に移動する。移動が完了すると、プラットフォームは、アプリケーションプログラムを実行することができる状態になる。そして、プラットフォームは、アプリケーションプログラムを実行する。このように、アプリケーションプログラムを実行することで提供できるプラットフォームの機能を、この例ではプラットフォームアプリケーションと呼ぶ。さらに、プラットフォームは、本実施形態で開示するフローチャートの各処理の一部を行うことが可能である。

ユーザインタフェース４０７は、ユーザからの処理依頼を受け付ける。ユーザインタフェース４０７は、例えば、キーボード、マウス等を通してユーザが入力した指示に応じた信号を受け付ける。外部インタフェース４０８は、外部装置からのデータ受信や外部装置へのデータ送信が可能である。上記外部装置は、例えば、外付けＨＤＤや外付けＵＳＢメモリ等の外付け記憶装置、またはネットワークを介して接続された別体のホストコンピュータや画像形成装置等の別体装置である。画像形成装置１０７は、ネットワーク１１０、１１１を介して、クライアント端末１０６、スキャンサービスサーバ群１０１と通信可能である。

次に、クラウドサービスを提供するスキャンサービスサーバ群１０１、タスクサーバ１０３、１０４の各サービスサーバ群に関して説明する。さらには、各サービスサーバ群の説明とともに、スキャン処理の流れを合わせて説明する。

図５は、スキャンサービスサーバ群の構成例を示す図である。スキャンサービスサーバ群１０１はクラウドサービスにおけるスキャン機能の提供を行うサービスサーバ群である。

スキャンサービスサーバ群１０１は、Ｗｅｂアプリケーション部５０１、チケット管理ＤＢ５０２、テンプレート管理ＤＢ５０３を備える。これら構成要素により各種処理が実行されることでスキャンサービスサーバ群１０１がユーザに提供される。

Ｗｅｂアプリケーション部５０１は、スキャン機能を提供するアプリケーションプログラムを提供する。Ｗｅｂアプリケーション部５０１は、チケット作成部５１１、チケット一覧部５１２、スキャン受信部５１３、外部Ｉ／Ｆ５１４、チケット管理部５１５、テンプレート管理部５１６を備える。チケット作成部５１１は、ユーザがスキャンチケットを作成するための一連の機能を実現する。スキャンチケットは、画像形成装置１０７で原稿をスキャンする際の設定や、その後の処理フローの定義、各処理フローで実施されるタスクの為のパラメータ等を含む定義情報である。

以下に、スキャンチケットの作成処理について説明する。クライアント端末１０６のＷｅｂブラウザ３０１が、ユーザ操作にしたがって、チケット作成画面リクエスト（この例では、スキャンチケット作成画面リクエスト）をスキャンサービスサーバ群１０１に対して行う。チケット作成部５１１が、チケット作成画面リクエストにしたがって、チケット作成画面（この例では、スキャンチケット作成画面）をクライアント端末１０６に提供する。クライアント端末１０６のＷｅｂブラウザ３０１が、スキャンチケット作成画面を表示する。

図６は、スキャンチケット作成画面の例を示す図である。スキャンチケット作成画面６０１には、テンプレート６０２乃至６０４が表示される。テンプレートは、画像処理（例えばスキャン処理）の設定を行うための定義情報である。例えば、テンプレート６０２は、スキャンして得られる画像データをクラウドサービスサーバ１０８に送信する処理を定義している。テンプレート管理部５１６が、テンプレート管理ＤＢ５０３内に記憶されているテンプレートを管理している。

チケット作成部５１１は、テンプレートをテンプレート管理ＤＢ５０３から取得し、取得したテンプレートを含むスキャンチケット作成画面をＷｅｂブラウザ３０１に対して提供する。

ユーザが、スキャンチケット作成画面６０１上に表示されたテンプレートの中から、実行するテンプレートを選択すると、Ｗｅｂブラウザ３０１が、詳細設定画面６０５を表示する。詳細設定画面６０５は、詳細なチケット設定を行うための画面である。

図６に示す例では、同一画面内にテンプレートと詳細設定画面６０５とが表示されているが、Ｗｅｂブラウザ３０１が、詳細設定画面６０５を、テンプレートが表示されている画面とは異なる画面（別ウィンドウ）で開くようにしてもよい。ユーザは、詳細設定画面６０５上で、選択したテンプレートに応じたスキャンの設定を行うことができる。例えば、スキャン設定の例としては、図６中に示すように、サイズや、カラー、白黒といった色調、またスキャンデータのフォーマット等の設定がある。ユーザが、詳細な設定を行った後、チケット発行ボタン６０６を押下すると、Ｗｅｂブラウザ３０１からスキャンサービスサーバ群１０１に対して、スキャンチケット作成リクエストが発行される。スキャンチケット作成リクエストは、スキャンチケットの作成を求める要求であり、スキャンチケット作成画面上で行われたチケット設定の情報を含む。

チケット作成部５１１は、スキャンチケット作成リクエストに含まれるチケット設定の情報に基づいて、スキャンチケットを作成し、チケット管理部５１５に指示してスキャンチケットに関する情報（チケット情報）を保存させる。チケット管理部５１５は、チケット作成部５１１からの指示にしたがって、チケット管理ＤＢ５０２にチケット情報を保存する。

外部Ｉ／Ｆ５１４は、画像形成装置１０７上で動作するスキャンソフトウェア部との通信を行う。具体的には、外部Ｉ／Ｆ５１４は、スキャンソフトウェア部から、チケット一覧部５１２の機能や、スキャン受信部５１３の機能へのアクセスを受け付ける。チケット一覧部５１２は、画像形成装置１０７からの要求にしたがい、チケット管理部５１５に保存されているチケット情報に基づいて、チケットの一覧を生成して画像形成装置１０７に返す。画像形成装置１０７は、取得したチケット一覧をチケット一覧画面上に表示する。

図７は、チケット一覧画面の一例を示す図である。この例では、チケット一覧画面４０７上には、チケット９０１乃至９０６（この例ではスキャンチケット）が表示される。ユーザが、チケット一覧画面４０７上に表示されたスキャンチケットのいずれかを選択し、画像形成装置１０７に備え付けられたスキャン装置に紙を設置し、スキャンボタン９０７を押し下げすると、スキャン実行される。そして、画像形成装置１０７が、チケット一覧画面上で選択されたスキャンチケットと、スキャン実行により得られた画像データとをスキャンサービスサーバ群１０１に対して送信する。

スキャンサービスサーバ群１０１が備えるスキャン受信部５１３は、画像形成装置１０７からスキャンチケットと画像データとを受信する。そして、スキャン受信部５１３は、受信した画像データをフローサービスサーバ群１０２に投入する。

図８は、チケット管理ＤＢとテンプレート管理ＤＢの一例を示す図である。図８（Ａ）は、チケット管理ＤＢ５０２の一例を示す。チケット管理ＤＢ５０２が保存しているチケットの情報は、ユーザＩＤ７０１、チケットＩＤ７０２、ルートＩＤ７０３、パラメータ７０４といったデータ項目を有する。ユーザＩＤ７０１は、チケットを作成したユーザを一意に識別する識別情報である。具体的には、ユーザＩＤ７０１は、スキャンサービスサーバ群１０１が管理しているＩＤであり、スキャンサービスサーバ群１０１を利用する際に発行されるものである。チケットＩＤ７０２は、チケットを一意に識別する識別情報である。チケットＩＤ７０２は、図６に示すスキャンチケット作成画面上でチケット発行６０６が押下げられたときにチケット作成部５１１によって生成され、チケット管理ＤＢ５０２に保存される。

ルートＩＤ７０３は、ルート情報を一意に識別する識別情報である。ルート情報は、スキャンチケット作成画面６０１上で選択されたテンプレートに対応する処理（例えばスキャン処理）を示す情報である。具体的には、ルート情報は、テンプレートに対応する処理を実現するジョブに含まれる各々のタスクを連結させたルートの情報であって、そのジョブにおけるタスクの処理順序を示す処理順情報を含む。すなわち、ルート情報は、タスクの連結をルートという単位で定義するための情報である。

ユーザが、テンプレートを選択し、スキャンを実行した場合には、スキャンデータは、ルートＩＤ７０３に対応付けて定義されたタスクの順番で処理される。パラメータ７０４は、図５中に示す詳細設定画面６０５上で設定されたスキャンの設定情報である。

図８（Ｂ）は、テンプレート管理ＤＢの一例を示す図である。テンプレート管理ＤＢ５０３には、テンプレート情報が設定されている。テンプレート情報は、図１２を参照して後述するルート情報管理ＤＢ１３０１で管理されるルート情報と、チケット作成画面上に表示されるテンプレートとを紐づける情報である。テンプレート情報は、テンプレートＩＤ８０１、テンプレート名８０２、ルートＩＤ８０３といったデータ項目を有する。

テンプレートＩＤ８０１は、テンプレートを一意に識別する識別情報である。テンプレート名８０２は、テンプレートの名称である。テンプレート名は、図５中のチケット作成画面６０１上に表示される。ルートＩＤ８０３は、ルート情報管理ＤＢ１３０１が管理するルート情報に含まれるルートＩＤ１４０１（図１２）への外部キーである。

図９は、タスクサーバの構成例を示す図である。タスクサーバ１０３は、タスクプロセス１０１０、１０１１、およびエージェント１０２０を備える。タスクプロセス１０１０、１０１１は、スキャンサービスを実現するための要素機能を実現する実行プロセスである。タスクプロセス１０１０、１０１１は、タスクサーバ１０３のリソース残量が多い、つまりサーバリソースに余裕がある限り任意の数を起動させることができる。

図９に示すように、タスクプロセス１０１０は、タスク取得部１０１２、データ取得部１０１３、データ保存部１０１４、タスクステータス通知部１０１５、タスク処理部１０１６を備える。タスク取得部１０１２は、定期的にフローサービスサーバ群１０２に問い合わせを行い、タスクサーバ１０３にて処理可能なタスクを取得する。データ取得部１０１３は、タスク取得部１０１２が取得したタスクの情報に基づいて、フローサービスサーバ群１０２から、処理すべき画像データを取得する。タスク処理部１０１６は、データ取得部１０１３が取得した画像データに対して各種処理を行う。また、タスク処理部１０１６は、タスク処理部１０１６による処理結果をデータ保存部１０１４に渡す。データ保存部１０１４は、タスク処理部１０１６から受け取った処理結果をフローサービスサーバ群１０３に保存する。タスクステータス通知部１０１５は、定期的にフローサービスサーバ群１０２に状態通知を行う。状態通知は、タスクサーバがタスク処理中であることを知らせる通知である。

なお、タスクプロセスの例としては、画像データに対して画像処理を行うタスクプロセスや、ファイル共有機能を提供するような他のクラウドサービスサーバ群１０８に対して、画像データを送信する処理を行うタスクプロセスがある。本実施例においては、タスクプロセス１０１０は、画像データに対してＯＣＲ処理を行いＯＣＲ結果のテキストデータを画像データに埋め込む処理を行う。また、タスクプロセス１０１１は、クラウドサービスサーバ群１０８の中のストレージ機能を提供する特定のサービスに対して、画像データをアップロードし保管する処理を行う。

エージェント１０２０は、外部Ｉ／Ｆ１０２１、タスク起動部１０２２、タスク停止部１０２３、タスク監視部１０２４を備える。エージェント１０２０は、タスクサーバ１０３上でのタスクプロセス１０１０、１０２０の数を監視し、スケーリングサーバ１０９に対して一定周期でタスクサーバ１０３上でのタスクプロセス１０１０、１０２０の数を通知する。また、スケーリングサーバ１０９からタスクサーバ１０３上でのタスクプロセス１０１０、１０２０の数の通知に基づく指示を受け付け、タスクプロセス１０１０、１０２０の起動、停止を行う。

図１０は、フローサービスサーバ群の構成例を示す図である。フローサービスサーバ群１０２は、ルート管理、ジョブ管理、一時ファイル管理を行うサービスサーバ群である。フローサービスサーバ群１０２は、ルート管理サービスサーバ群１２０１、ジョブ管理サービスサーバ群１２０２、一時ファイル管理サービスサーバ群１２０３を備える。ルート管理サービスサーバ群１２０１は、ルート情報を管理する。ジョブ管理サービスサーバ群１２０２は、ルート情報に基づいて、ジョブの処理を管理する。

一時ファイル管理サービスサーバ群１２０３は、ジョブ投入時のデータや各タスクの処理結果データの保存を管理する。具体的には、一時ファイル管理サービスサーバ群１２０３は、スキャンサービスサーバ群１０１やタスクサーバ（１０３、１０４）からの要求に応じて、ファイルを格納し、その格納先のパスを管理する。スキャンサービスサーバ群１０１は、タスクサーバからファイル取得要求があった場合には、保存したファイルのバイナリデータをタスクサーバに返却する。また、一時ファイル管理サービスサーバ群１２０３は、タスクサーバやジョブ管理サービスサーバ群１２０２からファイル削除の要求があった場合には、保存したファイルを削除する。一時ファイル管理サービスサーバ群１２０３の機能を利用することによって、スキャンサービスサーバ群１０１やタスクサーバは、ファイルの格納先のパスやファイルサーバの状態を気にすることなく、ファイルの保存、取得、削除を行うことができる。

図１１は、ルート管理サービスサーバ群の構成例を示す図である。ルート管理サービスサーバ群１２０１は、ルート情報管理ＤＢ１３０１、タスク情報管理ＤＢ１３０２、外部Ｉ／Ｆ１３０３を備える。ルート情報管理ＤＢ１３０１は、ルート情報を保持する。タスク情報管理ＤＢ１３０２は、タスクに関する情報（タスク情報）を保持している。この例では、タスクは、ジョブに含まれる処理単位を示す。外部Ｉ／Ｆ１３０３は、ルート管理サービスサーバ群１２０１への問い合わせに用いられるＩ／Ｆである。ジョブ管理サービスサーバ群１２０２等は、外部Ｉ／Ｆ１３０３を介して、ルート情報管理ＤＢ１３０１やタスク情報管理ＤＢ１３０２を参照する。

図１２は、ルート情報管理ＤＢの一例を示す図である。ルート情報は、ルートＩＤ１４０１、シーケンス番号１４０２、タスクＩＤ１４０３といったデータ項目を有する。ルートＩＤは、ルートを一意に識別する識別情報である。タスクＩＤ１４０３は、各々のルートを構成するタスク、つまり、ユーザによって選択されたテンプレートに対応する処理を実現するジョブに含まれるタスクを一意に識別する識別情報である。

シーケンス番号１４０２は、タスクが、そのタスクが含まれるルートにおいて、何番目に実行されるタスクであるかを示す番号である。言い換えると、シーケンス番号１４０２は、ルートに対応するジョブに含まれる各々のタスクが、ジョブ内で何番目に実行されるタスクであるかを示す処理順情報である。したがって、ルート情報管理ＤＢ１３０１は、処理順情報を含むルート情報を記憶する処理順情報記憶部として機能する。

図１２を参照すると、例えば、ルートＩＤが００２であるルートは、シーケンス番号が小さい順に、Ｔａｓｋ１、Ｔａｓｋ３、Ｔａｓｋ５、Ｔａｓｋ７を含んでいる。したがって、このルートに対応するジョブに含まれるタスクのうち、最先に実行されるタスクは、Ｔａｓｋ１であり、２番目に実行されるタスクは、Ｔａｓｋ３である。また、３番目に実行されるタスクは、Ｔａｓｋ５であり、４番目に実行されるタスクは、Ｔａｓｋ７である。

図１３は、タスク情報管理ＤＢの一例を示す図である。タスク情報管理ＤＢ１３０２は、タスク情報を記憶するタスク情報記憶部である。タスク情報は、タスクＩＤ１５０１、タスク名１５０２、中止時間１５０３、状態通知時間１５０４、最大処理時間（実測）１５０５、最大処理時間（予想）１５０６といったデータ項目を有する。

タスクＩＤ１５０１は、タスクを一意に識別する識別情報である。タスク名１５０２は、タスクの名称である。中止時間１５０３は、その時間以内にタスク処理が完了しない場合に、ジョブ管理サービスサーバ群１２０２が、タスク処理を実行中のタスクサーバ（１０３、１０４）から他のタスクサーバにジョブを委譲する時間である。

タスクを実行中のタスクサーバが、所定の時間以内つまりこのタスクに対応する中止時間１５０３に設定された時間以内にタスク処理が完了しない場合、ジョブ管理サービスサーバ群１２０２は、このタスクを実行中のタスクサーバに異常が発生したと判断する。そして、ジョブ管理サービスサーバ群１２０２は、以下の処理を実行する。まず、ジョブ管理サービスサーバ群１２０２は、このタスクを他のタスクサーバに渡す。具体的には、ジョブ管理サービスサーバ群１２０２は、実行中のタスク処理と同じタスク処理が可能なタスクサーバに対してタスク処理を代理で実行するように命令（代理実行命令を発行）する。また、ジョブ管理サービスサーバ群１２０２は、所定のタイミングで、異常が発生したタスクサーバに対して、タスク処理を中止するよう命令する（中止命令を発行する）。これにより、他のタスクサーバにジョブ処理が委譲される。

タスクサーバには、ハードウェア故障やソフトウェアバグが発生したり、ネットワーク切断などにより通信できなくなったりなど、様々な異常が発生する。さらに、例えば、画像処理や外部クラウドへの保存処理など、処理対象のデータが巨大な場合にも、タスクサーバは長時間実行状態となる。このような場合も、異常が発生したと判断される。

状態通知時間１５０４は、ジョブ管理サービスサーバ群１２０２が、タスクサーバに対して状態通知させる時間（通知時間間隔）である。最大処理時間（実測）、最大処理時間（予想）は、各々のタスクの処理内容に対応する処理時間である。最大処理時間（実測）１５０５は、タスクサーバによる当該タスクの処理時間の実測値のうちの最大値である。例えば、ジョブ管理サービスサーバ群１２０２は、最大処理時間（実測）１５０５に基づいて、中止時間１５０３を決定して設定する。ジョブ管理サービスサーバ群１２０２が、最大処理時間（実測）１５０５の値そのものを中止時間１５０３として設定してもよい。また、ジョブ管理サービスサーバ群１２０２は、最大処理時間（実測）１５０５に予め決められた猶予時間を足し合わせたものを中止時間１５０３として設定するようにしてもよい。なお、中止時間１５０３の決定方法としては、上記のものに限定されない。

最大処理時間（予想）１５０６は、タスクの処理時間のうち、予想される最大処理時間である。この例では、タスクサーバ１０３は、画像データに対する処理を行う。したがって、ジョブ管理サービスサーバ群１２０２は、一時ファイル管理サービスサーバ群１２０３が管理できる最大サイズの画像データに対する処理時間を予め計測しておき、この計測結果に基づいて、最大処理時間（予想）１５０６を算出して設定する。また、この例では、タスクサーバ１０４は、画像データをアップロードし保管する処理を行う。したがって、ジョブ管理サービスサーバ群１２０２は、クラウドサービスサーバ群１０８がアップロードを許容する最大のサイズの画像データをアップロードするために要する時間から、最大処理時間（予想）１５０６を算出することができる。なお、ジョブ管理サービスサーバ群１２０２は、最大処理時間（予想）１５０６を、クラウドサービスサーバ群１０８のアップロードタイムアウト値から算出してもよい。最大処理時間（予想）１５０６の算出方法としては、上記のものに限定されない。

最大処理時間（予想）１５０６を、中止時間１５０３を決定する要素として用いるようにしてもよい。例えば、最大処理時間（予想）１５０６の値そのものを中止時間１５０３としてもよいし、最大処理時間（予想）１５０６に予め決められた猶予時間を足し合わせたものを中止時間１５０３としてもよい。前述したように、ジョブ管理サービスサーバ群１２０２は、タスク情報管理ＤＢ１３０２に設定された中止時間に基づいて、タスク処理を実行中のタスクサーバから他のタスクサーバにジョブを委譲することを決定する。すなわち、ジョブ管理サービスサーバ群１２０２は、前述した中止命令、代理実行命令を発行するタイミングを、タスクの処理内容に対応するタスクの処理時間に応じて変化させる。

図１４は、ジョブ管理サービスサーバ群の構成例を示す図である。ジョブ管理サービスサーバ群１２０２は、タスクサーバ（１０３、１０４）からのタスク要求（タスク取得リクエスト）に応じて、タスクを渡す。タスク取得リクエストは、タスクの取得を求める要求である。処理待ち状態のタスクサーバは、所定のポーリング時間毎に、タスク取得リクエストを送信する。また、ジョブ管理サービスサーバ群１２０２は、各タスクの状態を管理する。

ジョブ管理サービスサーバ群１２０２は、外部Ｉ／Ｆ１６０１、ジョブ情報管理ＤＢ１６０２、ジョブ追加部１６０３、ジョブ情報取得部１６０４、ジョブ情報更新部１６０５、ジョブ状態通知部１６０６を備える。

外部Ｉ／Ｆ１６０１は、タスクサーバおよび画像形成装置１０７との間の通信インタフェースである。外部Ｉ／Ｆ１６０１を通じて、ジョブ管理サービスサーバ群１２０２の各機能へのアクセスが行われる。ジョブ情報管理ＤＢ１６０２には、ジョブ情報が記憶される。ジョブ情報は、ジョブに含まれる複数のタスクのうち、現在最先の処理順序のタスクと、そのタスクの状態と、そのタスクを実行中のタスクサーバからタスク処理中であることの通知を受けた最終通知時刻に関する情報とを含む。

ジョブ追加部１６０３は、スキャンサービスサーバ群１０１によって投入されるジョブに関するジョブ情報を、ジョブ情報管理ＤＢ１６０２に記憶する。ジョブ情報取得部１６０４は、タスクサーバからのタスク取得リクエストに応じて、リクエスト元のタスクサーバが処理対象とするタスクに対応するジョブ情報をジョブ情報管理ＤＢ１６０２から、取得し、タスクサーバに渡す。このジョブ情報をタスクサーバに渡すことを、本明細書では「タスクを渡す」と記述している。

ジョブ情報更新部１６０５は、タスクサーバからのジョブ情報更新リクエストに応じて、ジョブ情報管理ＤＢ１６０２内のジョブ情報を更新する。ジョブ情報更新リクエストは、ジョブ情報の更新を求める要求である。ジョブ状態通知部１６０６は、タスクサーバから状態通知を受け付ける。タスクサーバは、自身に対応する状態通知時間毎に状態通知を行う。

図１５は、ジョブ情報管理ＤＢの一例を示す図である。ジョブ情報管理ＤＢ１６０２は、ジョブ情報を記憶するジョブ情報記憶部である。ジョブ情報は、ジョブＩＤ１７０１、ルートＩＤ１７０２、ファイルグループＩＤ１７０３、カレントタスクＩＤ１７０４、ステータス１７０５といったデータ項目を有する。また、このジョブ情報は、最終更新時刻１７０６、パラメータ１７０７、タイムスタンプ１７０８、最終状態通知時刻１７０９といったデータ項目を有する。

ジョブＩＤ１７０１は、ジョブ情報を一意に識別する識別情報である。ルートＩＤ１７０２は、ルートを一意に識別する識別情報である。ルートＩＤ１７０２には、図５のチケット作成画面６０１上で選択されたテンプレートに対応するルートのルートＩＤが設定される。

ファイルグループＩＤ１７０３は、ジョブに含まれる画像データに関するファイルグループを一意に識別する識別情報である。カレントタスクＩＤ１７０４は、当該ジョブに含まれるタスクのうち、現在最先の処理順序のタスクであるカレントタスクを一意に識別する識別情報である。ジョブ管理サービスサーバ群１２０２のジョブ情報取得部１６０４は、カレントタスクＩＤ１７０４に設定されたタスクＩＤが、タスク取得リクエスト元のタスクサーバに割り当てられたタスクＩＤと合致するレコード（一行分のデータ）を特定する。そして、ジョブ情報取得部１６０４は、特定したレコードに対応するカレントタスクを、タスクサーバに渡す。

ジョブ情報更新部１６０５は、タスクの処理が完了した場合には、そのタスクに対応するレコードに含まれるルートＩＤを特定する。ジョブ情報更新部１６０５は、ルート情報管理ＤＢ１３０１を参照して、上記特定したルートＩＤに対応するタスクのうち、処理が完了したタスクの次に処理対象となるタスクを決定する。そして、ジョブ情報更新部１６０５は、ジョブ情報管理ＤＢ１６０２の上記レコードに対応するカレントタスクＩＤを上記決定したタスクのタスクＩＤに更新する。

ステータス１７０５は、当該タスクの状態である。具体的には、ステータス１７０５には、処理待ち状態を示す「０」、実行中状態を示す「１」、またはエラー発生を示す「２」が設定される。ジョブ情報更新部１６０５は、タスクの処理が完了した場合には、ステータス１７０５を０に更新する。

ジョブ情報取得部１６０４がタスクサーバに渡すタスクを選択する際には、ステータスが０であるレコードを選択する。これにより、複数のタスクサーバが同一のタスクを処理するといった事態を防ぐことができる。タスクサーバにタスクが渡されると、ジョブステータス変更部１６０５が、ステータス１７０５を０から１に変更する。

最終更新時刻１７０６は、ジョブ情報の最終更新時刻である。タスクのステータスが更新された時や、タスクサーバにタスクが渡された時に、最終更新時刻１７０６が現在時刻に更新される。ジョブ情報取得部１６０４は、タスク取得リクエスト元のタスクサーバに割り当てられたタスクＩＤがカレントタスクＩＤと等しいレコードが複数存在している場合、最終更新時刻１７０６が最も古いレコードを選択し、選択したレコードに対応するタスクを渡す。これにより、全てのジョブを平均的に処理することが可能となる。

パラメータ１７０７には、詳細設定画面６０５（図５）を用いて設定された設定情報や、タスクサーバが他のタスクサーバに渡す設定情報が設定される。タイムスタンプ１７０８は、ジョブ情報が更新される度に自動的に更新される固有情報である。例えば、タスク処理中のタスクが他のタスクサーバに委譲される度に、タイムスタンプ１７０８が更新される。

タスクサーバとジョブ情報更新部１６０５およびジョブ状態通知部１６０６との間の通信の際に、タイムスタンプの受け渡しを行うことで、他のタスクサーバにジョブが委譲されていないことを保証できる。最終状態通知時刻１７０９は、タスク処理を実行中のタスクサーバから状態通知を受けた最終時刻である。ジョブ情報取得部１６０４は、最終状態通知時刻１７０９から中止時間１５０３経過した場合に、他のタスクサーバへジョブを委譲する。

図１６は、ジョブ量管理ＤＢの一例を示す図である。ジョブ量管理ＤＢ１６０６は、タスクサーバに投入されたタスクの投入数とスループットを記憶するジョブ量記憶部である。ジョブ量管理ＤＢ１６０６は、タスクＩＤ２３０１、投入数２３０２、スループット２３０３、開始時刻２３０４、終了時刻２３０５といったデータ項目を有する。タスクＩＤ２３０１は、タスクの種別を一意に識別するためのＩＤである。投入数２３０２は、開始時刻２３０４から終了時刻２３０５までの間にタスクサーバが受け付けたタスク数のことである。スループット２３０３は、開始時刻２３０４から終了時刻２３０５までの間にタスクサーバが実行したタスク数のことである。開始時刻２３０４、終了時刻２３０５は本実施例においては５秒の間隔である。ジョブ管理サービスサーバ群１２０２は、５秒ごとに新しい行を追加して、投入数２３０２、スループット２３０３を記録する。

図１７は、スケーリングサーバの構成例を示す図である。スケーリングサーバ１０９は、ジョブ管理サービスサーバ群１２０２のジョブ情報管理ＤＢ１６０２を一定周期で監視することで、スケールアウト、またはスケールインの必要性を判断し、スケールアウト、またはスケールインを指示する。すなわち、スケーリングサーバ１０９は、情報処理システム上で動作する前記複数のジョブ処理装置の動作状況を監視する監視装置として機能する。スケールアウト、スケールインの指示は、スケーリングサーバ１０９のＣＰＵ２０２がエージェント１０２０に対するタスクの起動、または停止の命令を送信することによって行われる。スケーリングサーバ１０９は、外部Ｉ／Ｆ１８０１、監視履歴ＤＢ１８０２、スケールアウト実行履歴ＤＢ１８０３、実行履歴画面表示部１８０４、タスクステータスＤＢ１８０５、スケールイン実行履歴ＤＢ１８０６を備える。

外部Ｉ／Ｆ１８０１は、ジョブ管理サービスサーバ群１２０２のジョブ情報管理ＤＢ１６０２、ジョブ量管理ＤＢ１６０６からデータを取得するためのＩ／Ｆである。また、タスクサーバ１０３のエージェント１０２０からタスクの起動状況の通知を受け取り、タスクステータスＤＢ１８０５に格納する。また、エージェント１０２０に対して、タスクの起動、または停止の通知を送信する。

図１８は、監視履歴ＤＢの一例を示す図である。監視履歴ＤＢ１８０２は、スケーリングサーバ１０９が一定周期でジョブ情報管理ＤＢ１６０２、ジョブ量管理ＤＢ１６０６に対する監視を実行するたびに更新される。監視履歴ＤＢ１８０２は、監視ＩＤ１９０１、タスクＩＤ１９０２、待ち数１９０３、日時１９０４といったデータ項目を有する。

監視ＩＤ１９０１は、監視記録を一意に識別するＩＤである。タスクＩＤ１９０２は、後述のルート管理サービスサーバ群１２０１のタスク情報管理ＤＢ１３０２で管理されるＩＤである。スケーリングサーバ１０９は、タスクＩＤ１９０２ごとに、ジョブ情報管理ＤＢ１６０２に問い合わせを行う。待ち数１９０３は上記の問い合わせにより算出された、実行待ちとなっているジョブ数を表わす。実行待ちとなっているジョブ数は、ジョブ情報管理ＤＢ１６０２のカレントタスクＩＤ１７０４が問い合わせ対象のタスクＩＤと等しい。また、ステータスが０（待ち）状態となっているジョブ数をスケーリングサーバ１０９が取得することで算出できる。日時１９０４は、問い合わせを実施した日時を表わす。本実施例については、スケーリングサーバ１０９は５分ごとに監視を実施しているため、日時１９０４は５分間隔で記録される。

図１９は、タスクステータスの一例を示す図である。タスクステータスＤＢ１８０５は、各タスクサーバ１０３上でのタスクプロセス１０１０、１０１１の起動数を管理する。スケーリングサーバ１０９は、エージェント１０２０からタスクＩＤ、起動数の通知を受け付けると、タスクステータスＤＢ１８０５を更新する。エージェント１０２０は一定周期で通知を行うため、タスクステータスＤＢ１８０５も一定周期で更新される。タスクステータスＤＢ１８０５は、タスクサーバＩＤ２００１、タスクＩＤ２００２、起動数２００３といったデータ項目を有する。タスクサーバＩＤ２００１は、タスクプロセス１０１０、１０１１が起動しているタスクサーバ１０３を一意に識別するＩＤである。タスクＩＤ２００２は、タスクの種別を一意に識別するＩＤである。起動数２００３は、タスクサーバ１０３上でのタスクの起動数を示す。

図２０は、スケールアウト実行履歴ＤＢの一例を示す。スケールアウト実行履歴ＤＢは、スケールアウトＩＤ２１０１、結果２１０２、タスクＩＤ２１０３、タスクサーバＩＤ２１０４、日時２１０５といったデータ項目を有する。スケールアウトＩＤ２１０１は、実施されたスケールアウトを一意に識別するためのＩＤである。結果２１０２は、スケールアウトを実施した結果である。結果２１０２のＯＫは、スケールアウトの効果があったことを示す。ＮＧは、スケールアウトの効果が無かったことを示す。スケールアウトの効果の確認方法は、図２５のＳ２４０７で詳細に記述するため、省略する。

“Ｍｏｎｉｔｏｒｉｎｇ”は、スケールアウトの効果の有無を確認中であることを示す。Ｍｏｎｉｔｏｒｉｎｇ状態の行が一つでも存在すると、スケーリングサーバ１０９は新たなスケールアウト、スケールインを実施しないため、スケールアウト実行履歴ＤＢ１８０３においてＭｏｎｉｔｏｒｉｎｇ状態の行は常に一つである。タスクＩＤ２１０３は、スケーリングサーバ１０９がスケールアウトを実施したタスクの種別を一意に識別するためのＩＤである。タスクサーバＩＤ２１０４は、スケーリングサーバ１０９がスケールアウトを実施したタスクサーバ１０３を一意に識別するためのＩＤである。スケーリングサーバ１０９は、結果２１０２、タスクＩＤ２１０３、タスクサーバＩＤ２１０４から、タスクサーバ１０３上での、タスクＩＤ２１０３で示される種類のタスクのスケールアウト効果の有無を確認することができる。日時２１０５は、結果２１０２を登録した日時を表わす。

図２１は、スケールイン実行履歴ＤＢの一例を示す。スケールイン実行履歴ＤＢ１８０６は、スケールインＩＤ２２０１、結果２２０２、タスクＩＤ２２０３、タスクサーバＩＤ２２０４、日時２２０５といったデータ項目を有する。スケールインＩＤ２２０１は、実施されたスケールインを一意に識別するためのＩＤである。結果２２０２は、スケールインを実施した結果である。結果２２０２のＯＫは、スケールインした結果、スループットが低下してしまい、結果としてスケールアウトが必要な状況にならなかったことを示す。ＮＧは、スループットが低下してしまい、スケールアウトが必要な状況になったことを示す。

“Ｍｏｎｉｔｏｒｉｎｇ”であれば、スケールインの効果の有無を確認中であることを示す。Ｍｏｎｉｔｏｒｉｎｇ状態の行が一つでも存在すると、スケーリングサーバ１０９は新たなスケールアウト、スケールインを実施しないため、スケールイン実行履歴ＤＢ１８０６においてＭｏｎｉｔｏｒｉｎｇ状態の行は常に一つである。タスクＩＤ２２０３はスケーリングサーバ１０９がスケールアウトを実施したタスクの種別を一意に識別するためのＩＤである。タスクサーバＩＤ２２０４は、スケーリングサーバ１０９がスケールアウトを実施したタスクサーバ１０３を一意に識別するためのＩＤである。上記の結果２２０２、タスクＩＤ２２０３、タスクサーバＩＤ２２０４から、タスクサーバＩＤ２２０４で示されるタスクサーバ１０３上での、タスクＩＤ２２０３で示される種類のタスクのスケールインが有効であったかを確認することができる。日時２２０５は、結果２２０２を登録した日時を表わす。

図２２は、実行履歴画面の一例を示す図である。スケーリングサーバ１０９は、運用者が利用するウェブブラウザ３０１に対して、前述のスケールアウト実行履歴ＤＢ１８０３で示されるスケールアウトの結果を確認する画面を送付する機能を有する。実行履歴画面表示２６００において、運用者はスケールアウトの結果を確認し、必要であれば実行ボタン２６０１を押下することで、データスクサーバ１０３をスケールアウトすることができる。一般的に、タスクサーバ１０３のようなサーバをスケールアウトするとコストが発生する。例えば、ＩａａＳ（ＩｎｆｒａｓｔｒｕｃｔｕｒｅａｓａＳｅｒｖｉｃｅ）を利用してサーバを運用している場合には、サーバをスケールアウトした時点で料金の請求が開始されるのが一般的である。よって、本実施例では、運用者の意思によって実行ボタン２６０１を押下することによってはじめて、タスクサーバを新たにスケールアウトする。ただし、ＶＭのスケールアウトがあらかじめ想定されたコストであれば、実行履歴画面表示２６００を介さず、自動的にタスクサーバをスケールアウトしてもよい。

図２３は、本実施形態の情報処理システムの動作処理の例を説明するシーケンス図である。まず、クライアント端末１０６が備えるＷｅｂブラウザ３０１が、スキャンサービスサービスサーバ群１０１に対して、スキャンチケット作成画面リクエストを送信する（ステップＳ１１０１）。続いて、スキャンサービスサービスサーバ群１０１が備えるチケット作成部５１１は、スキャンチケット作成画面リクエストにしたがって、スキャンチケット作成画面を生成し、Ｗｅｂブラウザ３０１にレスポンスとして返す（ステップＳ１１０２）。具体的には、チケット作成部５１１は、テンプレート管理部５１６から、テンプレート管理ＤＢ５０３に登録されているスキャンチケットのテンプレートを取得する。そして、チケット作成部５１１は、取得したテンプレートに含まれるテンプレート名を含むスキャンチケット作成画面を作成し、Ｗｅｂブラウザ３０１に対して送信する。Ｗｅｂブラウザは、受信したスキャンチケット作成画面を表示する（図５）。

次に、スキャンチケット作成画面上でのユーザの操作にしたがって、Ｗｅｂブラウザ３０１が、スキャンサービスサーバ群１０１に対して、スキャンチケット作成リクエストを送信する（ステップＳ１１０３）。スキャンサービスサーバ群１０１が備えるチケット作成部５１１が、スキャンチケット作成リクエストにしたがってスキャンチケットを作成する。また、チケット管理部５１５が、作成されたスキャンチケットをチケット管理ＤＢ５０２に保存し、Ｗｅｂブラウザ３０１に対してレスポンスを返す。

次に、画像形成装置１０７のスキャンソフトウェア部が、外部Ｉ／Ｆ５１４を介し、チケット一覧部５１２に対して、チケット一覧取得リクエストを送信する（ステップＳ１１０５）。チケット一覧取得リクエストは、チケットの一覧の送信を求める要求である。チケット一覧部５１２は、チケット一覧取得リクエストにしたがって、チケットの一覧を生成してＷｅｂブラウザ３０１に返す（ステップＳ１１０６）。Ｗｅｂブラウザ３０１は、返されたチケット一覧をチケット一覧画面（図７）上に表示する。

次に、チケット一覧画面上でのユーザの操作にしたがって、画像形成装置１０７のスキャンソフトウェア部が、スキャン処理を実行して画像データを取得する（ステップＳ１１０７）。そして、スキャンソフトウェア部が、上記スキャン処理によって取得した画像データと、チケット一覧画面上でのユーザの操作により選択されたスキャンチケットとをスキャンサービスサーバ群１０１のスキャン受信部５１３に送信する（ステップＳ１１０８）

次に、スキャン受信部５１３が、受信した画像データをフローサービスサーバ群１０２に投入する（ステップＳ１１０９）。フローサービスサーバ群１０２が画像データを正しく受信できた場合には、フローサービスサーバ群１０２は、スキャンサービスサーバ群１０１に対して、受信した画像データに対応するファイルグループを応答する（ステップＳ１１０）。続いて、スキャンサービスサーバ群１０１のスキャン受信部５１３が、フローサービスサーバ群１０２に対して、ファイルグループＩＤとスキャンチケットとを送信する。これにより、フローサービスサーバ群１０２にジョブが投入される（Ｓ１１１１）。

次に、フローサービスサーバ群１０２がタスクサーバからのタスク取得リクエストに応じてタスクを渡す処理について説明する。各々のタスクサーバ（１０３，１０４）のタスク取得部１０１２が、定期的にフローサービスサーバ群１０２に問い合わせ（タスク取得リクエスト）を行う。そして、タスク取得部１０１２が、タスクサーバにて処理可能なタスクを取得する（ステップＳ１１１２、Ｓ１１１３、Ｓ１１２０、Ｓ１１２１）。

タスクサーバのデータ取得部１０１３が、タスク取得部１０１２によって取得したタスクに対応する、処理すべき画像データをフローサービスサーバ群１０２から取得する（ステップＳ１１１４、Ｓ１１１５、Ｓ１１２２、Ｓ１１２３）。タスクサーバのタスク処理部１０１６が、フローサービスサーバ群１０２から取得した画像データに対して各種処理（タスク処理）を実行する（ステップＳ１１１６、Ｓ１１２４）。また、タスクサーバのタスクステータス通知部１０１５は、定期的にフローサービスサーバ群１０２に状態通知を行う（ステップＳ１１１７、Ｓ１１２５）。

図２３に示す例では、タスクサーバ１０３のタスク処理部１０１６は、ステップＳ１１１６におけるタスク処理の結果を、データ保存部１０１４を介してフローサービスサーバ群１０３に保存する（ステップＳ１１１８）。また、タスクサーバ１０４のタスク処理部１０１６は、ステップＳ１１２４におけるタスク処理の結果を、クラウドサービスサーバ群１０８にデータ送信する（ステップＳ１１２６）。

また、タスクサーバ（１０３、１０４）のタスクステータス通知部１０１５は、一連のタスク処理の終了結果をフローサービスサーバ群１０３に通知する（ステップＳ１１１９、Ｓ１１２７）。

次に、スケーリングサーバ１０９が実行するスケーアウト処理を図２４、図２５を用いて説明する。スケーリングサーバ１０９は、一定周期でジョブ情報管理ＤＢ１６０２を監視することにより図２４、図２５の処理をそれぞれ繰り返し実行する。図２４、図２５の処理は、スケーリングサーバ１０９の起動時、もしくは運用者のコマンドによる実行などにより開始される。また、本実施例においてスケーリングサーバ１０９は図２４、図２５の処理を続けて処理する。また、本フローに係るスケーリングサーバ１０９のプログラムは、ＲＯＭ２０４やＨＤＤ２０５に記憶されており、ＲＡＭ２０３に読み出されＣＰＵ２０２によって実行される。

図２４、図２５は、スケーリングサーバ１０９が実施するスケールアウトのフローチャートを示す。Ｓ２４０１で、スケーリングサーバ１０９は、Ｓ２４０１からＳ２４１８の処理を繰り返す。Ｓ２４０２で、スケーリングサーバ１０９のＣＰＵ２０２は、図１５に示すフローサービスサーバ群１０２のジョブ情報管理ＤＢ１６０２を監視する。具体的には、スケーリングサーバ１０９は、図１３に示すタスク情報管理ＤＢ１３０２で管理されるタスクＩＤごとに、ジョブ情報管理ＤＢ１６０２を監視し、ジョブの実行待ちとなっている待ち数を監視する。Ｓ２４０３で、スケーリングサーバ１０９は、Ｓ２４０２で監視した待ち数をもとに、図１８に示す自装置の監視履歴ＤＢ１８０２を更新する。

Ｓ２４０４で、スケーリングサーバ１０９は、図２０に示すスケールアウト実行履歴ＤＢ１８０３を参照する。Ｓ２４０５で、スケーリングサーバ１０９は、スケールアウトがすでに実行中であればＳ２４０６へ、実行中でなければＳ２４１１へ処理を分岐させる。スケールアウトが実行中であることは、スケールアウト実行履歴ＤＢ１８０３に、結果が“Ｍｏｎｉｔｏｒｉｎｇ”になっている行が存在するか否かを確認することで判断できる。

スケールアウトが実行中である場合、図２５のＳ２４０６に処理が進み、スケーリングサーバ１０９は、スケールアウト実行履歴ＤＢ１８０３を確認する。具体的には、Ｓ２４０６で、スケーリングサーバ１０９は、スケールアウト実行履歴ＤＢ１８０３の結果が“Ｍｏｎｉｔｏｒｉｎｇ”になってから、確認期間以上経過しているか確認する。確認期間はあらかじめ定義された値であり、本実施例においては１５分間としている。この確認期間は、実施したスケールアウトの効果があったかどうかを確認する期間である。つまり、スケーリングサーバ１０９のＣＰＵ２０２は、タスクを増加させたタスクサーバ１０３を規定時間の間監視し、タスクを増加させたタスクサーバ１０３においてスループットが向上されているか否かを確認する確認手段として機能する。

Ｓ２４０７で、スケーリングサーバ１０９はスケールアウトを実施したタスクについてのスケールアウトの効果を確認する。このとき、スケールアウトの効果があったかどうかは、図１６に示すジョブ量管理ＤＢ１６０６のスループット列を確認することで判断できる。従って、スケーリングサーバは、スケールアウトが行われてから１５分以上経過した場合に、ジョブ量管理ＤＢ１６０６のスループット列を確認する。本実施例では、スケーリングサーバ１０９がスケールアウトを行う前、つまりタスクの増加前のジョブの処理数と、スケールアウトを行った規定時間後のジョブの処理数を比較して、スループットが向上しているかを確認する。

例えば、スケーリングサーバ１０９は、図２０中のスケールアウト実行履歴ＤＢ１８０３を参照し、２０１１／０９／１５１２：００：０３にスケールアウトが実行されていることを確認する。このとき、スケールアウトが実行されたのはタスクＩＤが１であるＴａｓｋ１のタスクである。次に、スケーリングサーバ１０９は、タスクＩＤが１であるタスクサーバについて、フローサービスサーバ群１０２のジョブ量管理ＤＢ１６０６のスループット列を参照する。この時、スケールアウトの実行時刻２０１１／０９／１５１２：００：０３の前の時刻は２０１１／０９／１５１２：００：００である。また、スケールアウトの実行時刻２０１１／０９／１５１２：００：０３の後の時刻は２０１１／０９／１５１２：００：２５である。従って、スケーリングサーバ１０９は、スループットが６から１０に増加していることを確認できる。スループットの比較方法については、平均値を比較する方法、最大値を比較する方法、最近のスループットに重みを付けて比較する方法などが想定されるが、任意の比較方法が適用されてよい。

Ｓ２４０８で、スケーリングサーバ１０９は、Ｓ２４０７において、スループットが向上されたと判断した場合は、スケールアウト実行履歴ＤＢ１８０３の結果が“Ｍｏｎｉｔｏｒｉｎｇ”となっている行の結果を、“ＯＫ”に変更する。スケーリングサーバ１０９は、スループットが向上されなかったと判断した場合は、スケールアウト実行履歴ＤＢ１８０３の結果が“Ｍｏｎｉｔｏｒｉｎｇ”となっている行の結果を、“ＮＧ”に変更する。そして、スケーリングサーバ１０９がスケールアウトの効果の判断結果をスケールアウト実行履歴ＤＢ１８０３に記憶させることで、“ＮＧ”と判断されたタスクサーバをスケールアウト対象から除外することが可能となる。

Ｓ２４０９で、スケーリングサーバ１０９は、Ｓ２４０８の結果が“ＯＫ”だった場合はＳ２４１８へ、“ＮＧ”だった場合はＳ２４１０へ処理を分岐させる。
Ｓ２４１０で、スケーリングサーバ１０９は、スケールインを実施する。このスケールインは、スケールアウト効果が“ＮＧ”だったため、タスクサーバ１０３上でスケールアウトされたタスクプロセス１０１０、１０１１の起動状況をスケールアウト前に戻すために実施される。具体的には、スケーリングサーバ１０９は、タスクサーバ１０３のエージェント１０２０が備えるタスク停止部１０２３に、タスク起動部１０２２がスケールアウトしたタスクを停止するように指示を出す。このように、タスクプロセス１０１０、１０１１をスケールアウトしても効果が無かった場合は、自動的に元の状態に戻せるため、自動的に適切なタスクプロセス１０１０、１０１１の起動数を調節することができる。

Ｓ２４０５の処理において、スケールアウトが実行中ではなかった場合に、処理はＳ２４１１に進み、スケーリングサーバ１０９は監視履歴ＤＢ１８０２を確認する。Ｓ２４１１で、スケーリングサーバ１０９は、スケールアウト対象タスクを抽出する。スケーリングサーバ１０９は、タスクＩＤごとに、監視履歴ＤＢ１８０２を参照し、ジョブの実行待ちとなっている待ち数１９０３を確認する。本実施例では、あるタスクＩＤに対して、最新の確認結果から一定期間の間の待ち数が、タスクステータスＤＢ１８０５で管理されたタスクプロセス１０１０、１０１１の規定数、つまり起動数以上の場合、スケールアウトが必要であると判断する。上記の状況は、タスクプロセス１０１０、１０１１が処理すべき待ちジョブ数がタスクプロセス１０１０、１０１１の総和より大きくなった状況であり、そのままにしてくと待ちジョブ数がより大きくなり続けると想定される。従って、実行待ち状態のジョブの数が当該ジョブに対応するタスクの起動数以上である場合にタスクを増加させることで、ジョブ処理の効率化を図る。

Ｓ２４１２で、スケーリングサーバ１０９は、Ｓ２４１１での判断の結果、スケールアウトが必要なタスクが存在すればＳ２４１３、存在しなければＳ２４１８へ処理を分岐させる。Ｓ２４１３で、スケーリングサーバ１０９はスケールアウトするタスクサーバ１０３を選択する。タスクサーバ１０３を選択する条件は、タスクステータスＤＢ１８０５上データスクプロセス１０１０、１０１１の起動数が最も少なく、スケールアウト実行履歴ＤＢ１８０３で“ＮＧ“となった履歴が存在しないことである。つまり、スケーリングサーバ１０９は、スケールアウトの効果の判断結果に基づいて、スループットが向上していないタスクサーバを除くジョブ処理装置に対してタスクを増加させるように指示する。

例えば、タスクサーバＩＤが１であるタスクサーバ１０３の監視履歴ＤＢ１８０２にスケールアウトが必要なタスクが存在すれば、タスクプロセスの起動数が最も少ない、例えばタスクサーバＩＤが２であるタスクサーバ１０３を選択する。このように、タスクプロセス１０１０、１０１１の起動数が最も少ないタスクサーバ１０３を選択することで、比較的サーバリソースに余裕のあるタスクサーバ１０３上にタスクプロセス１０１０、１０１１を起動することが可能である。また、スケールアウト実行履歴ＤＢ１８０３で“ＮＧ”となっていないタスクサーバ１０３を選択することで、スケールアウトの効果がなかったタスクサーバ１０３で再度スケールアウトを実施することを防止することができる。

Ｓ２４１４で、スケーリングサーバ１０９は、Ｓ２４１３の結果、スケールアウトするタスクサーバ１０３が存在すればＳ２４１５へ、存在しなければＳ２４１７へ処理を分岐させる。Ｓ２４１５で、スケーリングサーバ１０９のＣＰＵ２０２は、Ｓ２４１４で選択されたタスクサーバ１０３上のエージェント１０２０に対して、スケールアウト指示を送信する。エージェント１０２０は、スケールアウト指示を受信すると、指定されたタスクプロセス１０１０、１０１１を起動する。Ｓ２４１６で、スケーリングサーバ１０９は、スケールアウト実行履歴ＤＢ１８０３にレコードを追加し、起動されたタスクプロセス１０１０、１０１１の結果を“Ｍｏｎｉｔｏｒｉｎｇ”に設定し、スケールアウト実行履歴を更新する。

Ｓ２４１７で、スケーリングサーバ１０９は、図２２に示す実行履歴画面表示２６００をウェブブラウザ３０１に送信する。実行履歴画面表示２６００は、スケールアウトするためのタスクサーバ１０３が存在しなかったため、タスクサーバ１０３そのもののスケールアウトの実施を指示するための確認画面である。Ｓ２４１８で、スケーリングサーバ１０９は、一定時間停止する。Ｓ２４１９で、スケーリングサーバ１０９は、Ｓ２４０１へ処理を戻す。

図２６および図２７は、スケーリングサーバ１０９が実施するスケールインのフローチャートを示す。Ｓ２５０１で、スケーリングサーバ１０９は、Ｓ２５０２からＳ２５１８の処理を繰り返す。また、本フローに係るスケーリングサーバ１０９のプログラムは、ＲＯＭ２０４やＨＤＤ２０５に記憶されており、ＲＡＭ２０３に読み出されＣＰＵ２０２によって実行される。

Ｓ２５０２で、スケーリングサーバ１０９は、フローサービスサーバ群１０２のジョブ情報管理ＤＢ１６０２を監視する。監視対象は、タスク情報管理ＤＢ１３０２で管理されるタスクＩＤごとに、ジョブの実行待ちとなっている待ち数である。Ｓ２５０３で、スケーリングサーバ１０９は、Ｓ２５０２で監視した情報をもとに、監視履歴ＤＢ１８０２を更新する。Ｓ２５０４で、スケーリングサーバ１０９は、図２１に示すスケールイン実行履歴ＤＢ１８０６を参照する。

Ｓ２５０５で、スケーリングサーバ１０９は、スケールインがすでに実行中であれば図２７に示すＳ２５０６へ、実行中でなければＳ２５１１へ処理を分岐させる。スケールアウト、スケールインが実行中であることは、スケールアウト実行履歴ＤＢ１８０３、またはスケールイン実行履歴ＤＢ１８０６に、結果が“Ｍｏｎｉｔｏｒｉｎｇ”になっている行が存在するか否かを確認することで判断できる。

スケールインが実行中である場合、図２６のＳ２５０６に処理が進み、スケーリングサーバ１０９は、スケールイン実行履歴ＤＢ１８０６を確認する。具体的には、Ｓ２５０６で、スケーリングサーバ１０９は、スケールイン実行履歴ＤＢ１８０６の結果が“Ｍｏｎｉｔｏｒｉｎｇ”になってから、確認期間以上経過しているか確認する。確認期間はあらかじめ定義された値であり、本実施例においては１５分間としている。この確認期間は、実施したスケールインの結果、スループットが低下して、スケールアウトが必要な状況に陥っていないかを確認する期間である。

Ｓ２５０７で、スケーリングサーバ１０９はスケールインを実施したタスクについての待ちジョブ数が増加して、スケールアウトが必要な状況になってしまっていないかを確認する。スケールアウトが必要な状況の判断は、図２５で説明したＳ２４１１の判断処理と同様であるため省略する。スケールアウトが必要な状況になることは、スケールインした結果、スループットが低下してしまったことを意味する。本実施例では、スケールアウトが必要な状況にならないことを確認することで、スケールインの結果を判断する。つまり、スケーリングサーバ１０９は、ジョブの処理の数をタスクの削減前と規定時間後とにおいて比較し、タスクの削減前よりもジョブの処理数が減少している場合に前記スループットが低下していることを確認する。そして、スケーリングサーバ１０９がスケールインの効果の判断結果をスケールイン実行履歴ＤＢ１８０６に記憶させることで、“ＮＧ”と判断されたタスクサーバをスケールイン対象から除外することが可能となる。しかし、例えばタスクサーバ１０３のＣＰＵ、メモリ、ストレージなどのリソース状況を監視して、スケールインによる高負荷の発生を監視する方法もある。本提案においては、スケールインした結果、その結果を確認し、必要であれば元の状態に戻せるという点が重要である。

Ｓ２５０８で、スケーリングサーバ１０９は、Ｓ２５０７において、スケールアウトが必要でないと判断した場合は、スケールイン実行履歴ＤＢ１８０６の結果が“Ｍｏｎｉｔｏｒｉｎｇ”となっている行の結果を、“ＯＫ”に変更する。スケールアウトが必要であると判断した場合は、スケールイン実行履歴ＤＢ１８０６の結果が“Ｍｏｎｉｔｏｒｉｎｇ”となっている行の結果を、“ＮＧ”に変更する。Ｓ２５０９で、スケーリングサーバ１０９は、Ｓ２５０８の結果が“ＯＫ”だった場合はＳ２５１７へ、“ＮＧ”だった場合はＳ２５１０へ処理を分岐させる。

Ｓ２５１０で、スケーリングサーバ１０９は、スケールアウトを実施する。このスケールアウトは、スケールインの効果が“ＮＧ”だったため、タスクサーバ１０３上でのタスクプロセス１０１０、１０１１の起動状況をスケールイン前に戻すために実施する。このように、タスクプロセス１０１０、１０１１をスケールインした結果、スループットが低下してしまい、スケールアウトが必要になった場合には、自動的に元の状態に戻せるため、自動的に適切なタスクプロセス１０１０、１０１１の起動数が調節される。スケールアウトの詳細な手順については、図２５を用いて記載したため省略する。

Ｓ２５０５でスケールインが実行中でない場合、処理はＳ２５１１に進み、スケーリングサーバ１０９は監視履歴ＤＢ１８０２を確認する。Ｓ２５１１で、スケーリングサーバ１０９はスケールイン対象タスクを抽出する。タスクＩＤごとに、監視履歴ＤＢ１８０２を参照し、ジョブの実行待ちとなっている待ち数を確認する。本実施例では、あるタスクＩＤに対して、最新の確認結果から所定期間の間の待ち数が、規定数以下、つまり常に０〜１である場合、タスクの削減が必要であると判断する。上記の状況は、タスクプロセス１０１０、１０１１が処理すべき待ちジョブがほとんど存在しない場合であり、スケールインすることによってサーバリソースを開放すべき状況である。

Ｓ２５１２で、スケーリングサーバ１０９は、Ｓ２５１１での判断の結果、スケールインが必要なタスクが存在すればＳ２５１３、存在しなければＳ２５１７へ処理を分岐させる。Ｓ２５１３で、スケーリングサーバ１０９はスケールインするタスクサーバ１０３を選択する。タスクサーバ１０３を選択する条件は、タスクステータスＤＢ１８０５上のデータスクプロセス１０１０、１０１１の起動数が最も多く、スケールイン実行履歴ＤＢ１８０６で“ＮＧ“となった履歴が存在しないことである。つまり、スケーリングサーバ１０９は、スケールインの効果の判断結果に基づいて、スループットが低下しているタスクサーバを除くジョブ処理装置に対してタスクを増加させるように指示する。さらに、複数のタスクサーバ１０３上にタスクプロセスが合計２つ以上存在することも条件である。

タスクプロセス１０１０、１０１１の起動数が最も多いタスクサーバ１０３を選択することで、比較的サーバリソースを多く消費しているタスクサーバ１０３上データスクプロセス１０１０、１０１１を停止することが可能である。また、スケールイン実行履歴ＤＢ１８０６で”ＮＧ“となっていないタスクサーバ１０３を選択することで、スケールインの効果、スケールアウトが必要になってしまったタスクサーバ１０３での再度のスケールインの実施を防止することができる。また、複数のタスクサーバ１０３データスクプロセス１０１０、１０１１が合計２つ以上存在することを保証することで、可用性を低下させないことができる。あるいは、起動数が最も多いタスクサーバ１０３であっても、当該タスクサーバ１０３の監視履歴ＤＢ１８０２に記録された一定期間の間の待ち数が、常に０であるデータスクプロセス１０１０、１０１１をスケールインしてもよい。これにより、例えば誤起動により起動され、実行されていないタスクプロセス１０１０、１０１１がスケールインされ、サーバリソースが解放される。

また、あるタスクサーバ１０３上で２つのタスクプロセス１０１０、１０１１が起動しているだけだと、タスクサーバ１０３が故障などにより停止してしまった場合に、タスクプロセス１０１０、１０１１が１つも起動していない状況になってしまう。そのため、複数のタスクサーバ１０３でのタスクプロセス１０１０、１０１１の起動を保証する必要がある。本実施例においては、２つ以上のタスクプロセス１０１０、１０１１を複数のタスクサーバ１０３で起動することを保証している。しかし、ｎ個以上のタスクプロセス１０１０、１０１１を起動するなど、ＳＬＡ（ＳｅｒｖｉｃｅＬｅｖｅｌＡｇｒｅｅｍｅｎｔ）に応じて適切な数を設定することが好ましい。

Ｓ２５１４で、スケーリングサーバ１０９は、Ｓ２５１３の結果、スケールインするタスクサーバ１０３が存在すればＳ２５１５へ、存在しなければＳ２５１７へ処理を分岐させる。Ｓ２５１５で、スケーリングサーバ１０９は、Ｓ２５１３で選択されたタスクサーバ１０３上のエージェント１０２０に対して、スケールイン指示を送信する。エージェント１０２０は、スケールイン指示を受信すると、指定されたタスクプロセス１０１０、１０１１を停止する。

Ｓ２５１６で、スケーリングサーバ１０９は、スケールイン実行履歴ＤＢ１８０６上で結果が“Ｍｏｎｉｔｏｒｉｎｇ”になっている行の結果を、“ＯＫ”に更新する。Ｓ２５１７で、スケーリングサーバ１０９は、一定時間停止する。Ｓ２５１８で、スケーリングサーバ１０９は、Ｓ２５０１へ処理を戻す。

以上のように、実施例１では、スケールアウト、スケールインが必要な状況であることをスケーリングサーバがフローサービスサーバ群のジョブ管理ＤＢ、ジョブ量管理ＤＢを参照することで特定し、スケールアウト、スケールインを実施する。また、スケーリングサーバは、スケールアウト、スケールインの結果を保持しておくことで、効果のないスケールアウト、スケールインを繰り返すことを防止している。上述の処理により、情報処理システムによれば、ジョブの実行状況とスケーリングの効果に基づいて、スケーリング条件を定義することなしに自動スケーリングを実現することが可能となる。

（実施例２）
実施例１では、スケールアウトの実施後に、スケールアウトの効果が無かった場合には、スケールアウト実行履歴ＤＢ１８０３に“ＮＧ”を記録し、再度スケールアウト対象となってしまうことを防止した。しかしながら、一旦“ＮＧ”となったタスクプロセス１０１０、１０１１とタスクサーバ１０３の組み合わせであっても、タスクサーバ１０３でのスケールインが実施された後は、スケールアウト効果が表れる可能性がある。スケールインすることによって、タスクサーバ１０３のサーバリソースに空きが生じて、スケールアウトを実施できる可能性があるからである。

よって、実施例２においては、一旦“ＮＧ”となったタスクプロセス１０１０、１０１１であっても再度スケールアウトを行う処理を説明する。具体的には、スケーリングサーバ１０９は、図２７のフローチャートにおいて、Ｓ２５１５のスケールインを実施した場合に以下の処理を行う。スケーリングサーバ１０９は、スケールアウト実行履歴ＤＢ１８０３で“ＮＧ”となっている行の中で、Ｓ２５１５でスケールインしたタスクサーバ１０３の結果２１０２をすべて“ＯＫ”とする。すなわち、スケーリングサーバ１０９のＣＰＵ２０２は、スケールアウト対象から除外されたタスクサーバのタスクが削減された場合に、当該タスクサーバ１０３、１０４をスケールアウト対象として復帰させる復帰手段として機能する。

例えば、スケールアウト実行履歴ＤＢ１８０３で“ＮＧ”となっている行はスケールアウトＩＤ２１０１が４である行である。そのため、スケーリングサーバ１０９は、タスクサーバＩＤ２１０４が１であるタスクサーバ１０３をスケールインした場合には、スケールアウトＩＤが４である行の結果２１０２を“ＯＫ”に更新する。これにより、タスクサーバＩＤ２１０４が１であるタスクサーバ１０３をスケールアウト対象として復帰させることができる。以上のように、実施例２では、タスクサーバ１０３をスケールアウト対象として復帰させることで、サーバリソースを最大限活用する方法について述べた。

（実施例３）
実施例１では、スケールインの実施後に、スループットが低下してしまい、スケールアウト対象となってしまった場合にはスケールイン実行履歴ＤＢ１８０６に“ＮＧ”を記録し、再度スケールイン対象となってしまうことを防止した。しかしながら、一旦“ＮＧ”となったタスクプロセス１０１０、１０１１とタスクサーバ１０３の組み合わせであっても、ジョブ管理サービスサーバ群１２０２に投入されるジョブ数が低下した場合には、スケールインできる可能性がある。投入するジョブ数が低下することで、ジョブを処理するタスクプロセス１０１０、１０１１をより縮小することができる可能性が生じるためである。

よって、実施例３においては、一旦“ＮＧ”となったタスクプロセス１０１０、１０１１であっても再度スケールインを行う処理を説明する。スケーリングサーバ１０９は、図２６のＳ２５０４でのスケールイン実行履歴ＤＢ１８０６の参照の際に、ジョブ量管理ＤＢ１６０６を監視する。ジョブ量管理ＤＢ１６０６において、ジョブの投入数が減少傾向になっていると判断した場合には、スケールイン実行履歴ＤＢ１８０６で“ＮＧ”となっている行の中で、投入数が減少したタスクＩＤに関する実行履歴をすべて“ＯＫ”とする。すなわち、スケーリングサーバ１０９のＣＰＵ２０２は、スケールイン対象から除外されたタスクサーバのタスクが増加された場合に、当該タスクサーバ１０３、１０４をスケールイン対象として復帰させる。

例えば、ジョブ量管理ＤＢ１６０６において、タスクＩＤがＴａｓｋ２のタスクサーバ１０３に関しては、ジョブの投入数が８から５に減少している。このように、投入数を監視することで、減少傾向になっていることを判別する。投入数が減少傾向になっているタスクＩＤがＴａｓｋ２のタスクサーバ１０３はスケールイン実行履歴ＤＢ１８０６で結果２２０２が“ＮＧ”となっている。よって、スケールインＩＤが３である結果２２０２を“ＯＫ”とする。これにより、スケールイン対象のタスクプロセス１０１０、１０１１として復帰させることができる。

以上のように、実施例３では、タスクプロセス１０１０、１０１１をスケールイン対象として復帰させることで、できるだけスケールインを実施し、サーバリソースを最大限活用する方法について述べた。

（その他の実施形態）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（コンピュータプログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給する。そしてそのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。この場合、そのプログラム、及び該プログラムを記憶した記憶媒体は本発明を構成することになる。

Claims

ユーザ装置からジョブ処理要求を受付ける管理装置と、前記管理装置にジョブを問合せ、前記問合せに応じて取得したジョブを処理する複数のジョブ処理装置と、監視装置とを備える情報処理システムであって、
前記監視装置は、
前記情報処理システム上で動作する前記複数のジョブ処理装置の動作状況を監視する監視手段と、
前記監視手段により、特定のジョブ処理装置が規定数を超えるジョブを処理していることが監視されたことに応じて、前記複数のジョブ処理装置のうちいずれか一つのジョブ処理装置のタスクを増加させるスケールアウトを指示するスケールアウト指示手段と、
前記スケールアウト指示手段による指示に基づきタスクを増加させてジョブを処理する前記ジョブ処理装置を規定時間の間監視し、タスクを増加させた前記ジョブ処理装置においてスループットが向上されているか否かを確認する確認手段と、
前記確認手段による確認の結果、前記スループットが向上されていないと確認された場合、増加された前記タスクを削減するスケールインを指示するスケールイン指示手段と、を有する
ことを特徴とする情報処理システム。
前記スケールイン指示手段は、前記監視手段により、特定のジョブ処理装置が、所定期間の間、規定数以下のジョブを処理していることが監視されたことに応じて、前記複数のジョブ処理装置のうちいずれか一つのジョブ処理装置のタスクを削減させるように指示し、
前記確認手段は、前記スケールイン指示手段による指示に基づきタスクを削減させてジョブを処理する前記ジョブ処理装置を規定時間の間監視し、タスクを削減させた前記ジョブ処理装置においてスループットが低下しているか否かを確認し、
前記スケールアウト指示手段は、前記確認手段による確認の結果、前記スループットが低下していると確認された場合、削減された前記タスクを増加するように指示する
ことを特徴とする請求項１に記載の情報処理システム。
前記確認手段は、
前記タスクを増加させた前記ジョブ処理装置においてスループットが向上されていないと確認した場合に、前記スケールアウトの効果がないと判断し、当該スケールアウトの効果の判断結果を記憶手段に記憶することで、前記ジョブ処理装置をスケールアウト対象から除外し、
前記タスクを削減させた前記ジョブ処理装置においてスループットが低下していると確認した場合に、前記スケールインの効果がないと判断し、当該スケールインの効果の判断結果を前記記憶手段に記憶することで、前記ジョブ処理装置をスケールイン対象から除外する
ことを特徴とする請求項１または２に記載の情報処理システム。
前記スケールアウト対象から除外された前記ジョブ処理装置のタスクが削減された場合に、当該ジョブ処理装置を前記スケールアウト対象として復帰させ、前記スケールイン対象から除外された前記ジョブ処理装置のタスクが増加した場合に、当該ジョブ処理装置をスケールイン対象として復帰させる復帰手段をさらに備える
ことを特徴とする請求項３に記載の情報処理システム。
前記スケールアウト指示手段は、前記記憶手段に記憶された前記スケールアウトの効果の判断結果に基づいて、前記スループットが向上していないジョブ処理装置を除くジョブ処理装置に対し前記タスクを増加させるように指示し、
前記スケールイン指示手段は、前記記憶手段に記憶された前記スケールインの効果の判断結果に基づいて、前記スループットが低下しているジョブ処理装置を除くジョブ処理装置に対して前記タスクを削減させるように指示する
ことを特徴とする請求項３または４に記載の情報処理システム。
前記スケールアウト指示手段は、前記監視手段により、前記特定のジョブ処理装置が規定数を超えるジョブを処理していることが監視されたことに応じて、前記複数のジョブ処理装置のうち、前記タスクの起動数が最も少ないか、またはリソース残量が最も多いジョブ処理装置に対し前記タスクを増加させるように指示し、
前記スケールイン指示手段は、前記監視手段により、特定のジョブ処理装置が、所定期間の間、規定数以下のジョブを処理していることが監視されたことに応じて、前記複数のジョブ処理装置のうち、前記タスクの起動数が最も多いか、またはリソース残量が最も少ないジョブ処理装置に対し前記タスクを減少させるように指示する
ことを特徴とする、請求項１乃至５のいずれか一項に記載の情報処理システム。
前記スケールアウト指示手段は、実行待ち状態のジョブの数が当該ジョブに対応するタスクの起動数以上である場合に当該タスクを増加させるように指示する
ことを特徴とする請求項１乃至６のいずれか一項に記載の情報処理システム。
前記確認手段は、
前記スケールアウト指示手段による指示に基づき前記タスクを増加させてジョブを処理する前記特定のジョブ処理装置におけるジョブの処理数を、前記タスクの増加前と規定時間後とにおいて比較し、前記タスクの増加前よりも前記ジョブの処理数が増加している場合に前記スループットが向上していると確認し、
前記スケールイン指示手段による指示に基づき前記タスクを削減させてジョブを処理する前記特定のジョブ処理装置におけるジョブの処理数を、前記タスクの削減前と規定時間後とにおいて比較し、前記タスクの削減前よりも前記ジョブの処理数が減少している場合に前記スループットが低下していると確認する
ことを特徴とする請求項１乃至７のいずれか一項に記載の情報処理システム。
前記監視手段は、スケールアウト対象のジョブ処理装置が存在しない場合に、前記ユーザ装置に対して前記ジョブ処理装置の追加を促す確認画面を送信する
ことを特徴とする請求項１乃至８のいずれか１項に記載の情報処理システム。
前記スケールアウト指示手段および前記スケールイン指示手段は、前記確認手段が前記ジョブ処理装置を規定時間の間監視している間は、全てのジョブ処理装置のタスクのスケールアウトおよびスケールインを指示しない
ことを特徴とする請求項１乃至９のいずれか一項に記載の情報処理システム。
ユーザ装置からジョブ処理要求を受付ける管理装置にジョブを問合せ、前記問合せに応じて取得したジョブを処理する複数のジョブ処理装置と通信可能な監視装置であって、
特定のジョブ処理装置が規定数を超えるジョブを処理している場合、前記複数のジョブ処理装置のうちいずれか一つのジョブ処理装置のタスクを増加させるスケールアウトを指示するスケールアウト指示手段と、
前記スケールアウト指示手段による指示に基づきタスクを増加させてジョブを処理する前記ジョブ処理装置を規定時間の間監視し、スループットが向上されているか否かを確認する確認手段と、
前記確認手段による確認の結果、スループットが向上されていないと確認された場合、増加された前記タスクを削減するスケールインを指示するスケールイン指示手段と、を有する
ことを特徴とする監視装置。
ユーザ装置からジョブ処理要求を受付ける管理装置と、前記管理装置にジョブを問合せ、前記問合せに応じて取得したジョブを処理する複数のジョブ処理装置と、監視装置とを備える情報処理システムの制御方法であって、
前記監視装置が、前記情報処理システム上で動作する前記複数のジョブ処理装置の動作状況を監視する監視工程と、
前記監視装置が、前記監視工程において、特定のジョブ処理装置が規定数を超えるジョブを処理していることが監視されたことに応じて、前記複数のジョブ処理装置のうちいずれか一つのジョブ処理装置のタスクを増加させるように指示するスケールアウト指示工程と、
前記スケールアウト指示工程における指示に基づきタスクを増加させてジョブを処理する前記ジョブ処理装置を規定時間の間監視し、タスクを増加させた前記ジョブ処理装置においてスループットが向上されているか否かを確認する確認工程と、
前記確認工程における確認の結果、前記スループットが向上されていないと確認された場合、増加された前記タスクを削減するように指示するスケールイン指示工程と、を有する
ことを特徴とする制御方法。
請求項１２に記載の制御方法をコンピュータに実行させることを特徴とするコンピュータプログラム。