JP5984552B2 - 負荷分散システム、負荷分散システムの制御方法、およびコンピュータプログラム - Google Patents

Description

本発明は、負荷分散システム、負荷分散システムの制御方法、およびコンピュータプログラムに関する。

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

クラウドシステムを構築するにあたり、複数のサーバがリクエストを負荷分散する構成が必要になる。例えば、特許文献１が開示する情報処理システムは、ウェブサービスを利用するユーザからリクエストを受けて複数のウェブサーバの１つを決定し、それによりサーバに対する負荷を分散させる負荷分散装置を備えるシステムである。負荷分散装置は、ＳＬＢ（Ｓｏｆｔｗａｒｅ Ｌｏａｄ Ｂａｌａｎｃｅｒ）とも呼称される。ＳＬＢは、通信元と通信先のサーバ群の通信を仲介するように設置され、通信アプリケーションの（ＴＣＰ／ＵＤＰ）ポート番号をもとに、通信元からの通信を複数台のサーバに分散する。

特開２００７−１６４５２７号公報

特許文献１が開示するシステムでは、ユーザのリクエストが負荷分散装置を介してサーバに送信されるが、ＳＬＢを通すとネットワーク帯域がＳＬＢの処理性能を上限として制限されてしまう。場合によっては、ＳＬＢを通した場合、ＳＬＢを通さない場合に比べ、処理速度がネットワーク帯域の半分以下になることがある。従って、ドキュメントやイメージといった比較的大きなバイナリデータをやり取りするシステムでは、ＳＬＢがパフォーマンスボトルネックとなってしまう。結果、ユーザからのリクエストを処理するための時間を余分に要することになる。本発明は、一定量以上の大きなデータを送受信する際はＳＬＢを介さず送信元からサーバに直接データを送信することにより、ＳＬＢによりサーバの負荷分散を実現しつつ処理速度を向上させる負荷分散システムを提供することを目的とする。

本発明の一実施形態の負荷分散システムは、データを転送する転送装置と、転送された前記データを保存する複数の保存装置と、前記転送装置からの転送要求を受信したことに応じて、前記保存装置の中から処理状況に応じて前記データの転送を受ける保存装置を決定する分散装置とを備える。前記転送装置は、転送するデータに応じて、前記分散装置にデータを転送するか、前記分散装置を経由せず前記分散装置により決定される保存装置にデータを転送するか、転送方法を決定する決定手段と、前記決定された転送方法に従い、データを転送する転送手段とを備える。

本発明の負荷分散システムによれば、一定量以上の大きなデータを送受信する際はＳＬＢを介さず送信元からサーバに直接データを送信することにより、ＳＬＢによりサーバの負荷分散を実現しつつ処理速度を向上させることが可能となる。

本実施形態の情報処理システムの全体構成を示す図である。 クライアント端末、スキャンサーバ、フローサーバ、タスクサーバを実現するサーバコンピュータのハードウェア構成図の例である。 クライアント端末と画像形成装置の構成例を示す図である。 スキャンサーバの構成例を示す図である。 スキャンチケット作成画面の例を示す図である。 チケット一覧画面の一例を示す図である。 チケット管理ＤＢとテンプレート管理ＤＢの一例を示す図である。 タスクサーバの構成例を示す図である。 フローサーバ群のシステム構成図の概要である。 ＳＬＢのシステム構成とＳＬＢが管理する管理テーブルを示す図である。 中央管理サーバのシステム構成図である。 データベースサーバのシステム構成図である。 データベースサーバが管理するサーバ情報、ファイルパス情報を示す。 ファイルサーバが保存するエンティティの階層構造を示す図である。 データベースサーバが管理するジョブ情報を示す。 データベースサーバが管理するルート情報を示す。 本実施形態の負荷分散システムの動作処理の例を説明するシーケンス図である。 スキャンサーバが中央管理サーバに対して通信を行う際の動作を表すフローチャートである。 中央管理サーバがスキャンサーバからの通信を受けて行う動作を表すフローチャートである。 実施例２における中央管理サーバ削減処理のフローチャートである。 実施例３におけるスキャンサーバが中央管理サーバに対して通信を行う際の動作を表すフローチャートである。 中央管理サーバがスキャンサーバからの通信を受けて行う動作を表すフローチャートである。

図１は、本発明の実施形態の情報処理システムの全体構成を示す図である。本実施形態の情報処理システムは、クラウドシステムであって、クライアント端末１０６のユーザに画像処理サービスを提供する。図１中の情報処理システムは、スキャンサーバ１０１、フローサーバ１０２、タスクサーバ１０３、１０４、クライアント端末１０６、画像形成装置１０７、クラウドサービスサーバ１０８を備える。

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

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

スキャンサーバ１０１、フローサーバ１０２、タスクサーバ１０３、１０４は、複数のサーバコンピュータを有する。これらサーバコンピュータ群がクラウドシステムを構成しており、ユーザに対してクラウドサービスを提供する。この例では、クライアント端末１０６からの要求に応じて、画像形成装置１０７がスキャン実行を行って画像データを取得し、取得した画像データをスキャンサーバ１０１に投入する。スキャンサービスサーバ１０１は、当該画像データに対応するジョブをフローサーバ１０２に投入する。フローサーバ１０２は、投入されたジョブを管理する。タスクサーバ１０３、１０４は、フローサーバ１０２が管理するジョブを非同期で取得要求する。この例では、ジョブは、複数のタスクから構成される。例えば、ユーザからの要求に従い発行されるジョブがスキャンジョブであった場合、スキャン画像に対し画像処理を行う工程と、画像処理が施されたスキャン画像を保存する工程とが実行されるケースが考えられる。本願発明は、夫々の工程をタスクという単位で区切ることで、１つのジョブを複数のタスクで構成する。この形態のメリットは、複数のタスクを組み合わせることで、多様なジョブ処理を行うことができるという点である。フローサーバ１０２は、管理しているジョブに含まれる複数のタスクのうち、取得要求元のタスクサーバに対応するタスクを取得要求元のタスクサーバに渡す。タスクを受け取ったタスクサーバは、特定のジョブ処理を施す。タスクサーバは、例えば、処理対象の画像データに対して画像処理を行ったり、ファイル共有機能を提供する他のクラウドサービスサーバ群に対して、画像データを送信する処理を行う。

様々な企業などにより、スキャンサーバ１０１乃至クラウドサービスサーバ１０８がインターネット上に公開されており、これらも複数のサーバコンピュータ上にて実行されている。クライアント端末１０６は、例えば、デスクトップパソコン、ノートパソコン、モバイルパソコン、ＰＤＡ（パーソナルデータアシスタント）等である。クライアント端末１０６が、プログラムの実行環境が内蔵された携帯電話であってもよい。クライアント端末１０６では、Ｗｅｂブラウザ（インターネットブラウザ、ＷＷＷブラウザ、Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂの利用に供するブラウザ）等のプログラムを実行する環境が内蔵されている。

図２は、クライアント端末１０６、スキャンサーバ、フローサーバ、タスクサーバ、図９を参照して後述するＳＬＢ、中央管理サーバ、ファイルサーバを実現するサーバコンピュータのハードウェア構成図の例である。クライアント端末１０６、サーバコンピュータは、ＣＰＵ２０２、ＲＡＭ２０３、ＲＯＭ２０４、ＨＤＤ２０５を備える。ＣＰＵは、Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔの略称である。ＲＡＭは、Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙの略称である。ＲＯＭは、Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙの略称である。ＨＤＤは、Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅの略称である。また、クライアント端末１０６、サーバコンピュータは、ＮＩＣ２０９、キーボード２０７、ディスプレイ２０６、インタフェース２０８を備える。ＮＩＣは、Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄの略称である。ＣＰＵ２０２は、装置全体の制御を行う。ＣＰＵ２０２は、ＨＤＤ２０５に格納されているアプリケーションプログラム、ＯＳ等を実行し、ＲＡＭ２０３にプログラムの実行に必要な情報、ファイル等を一時的に格納する制御を行う。ＯＳは、Ｏｐｅｒａｔｉｎｇ Ｓｕｓｔｅｍの略称である。ＲＯＭ２０４は、記憶手段であり、内部には、基本Ｉ／Ｏプログラム等の各種データを記憶する。ＲＡＭ２０３は一時記憶手段であり、ＣＰＵ２０２の主メモリ、ワークエリア等として機能する。ＨＤＤ２０５は外部記憶手段の一つであり、大容量メモリとして機能し、Ｗｅｂブラウザ等のアプリケーションプログラム、サービス群のプログラム、ＯＳ、関連プログラム等を格納している。

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

図３は、クライアント端末と画像形成装置の構成例を示す図である。図３（Ａ）は、クライアント端末１０６の構成例を示す。クライアント端末１０６は、Ｗｅｂブラウザ３０１を備える。このシステムの実態はＲＯＭ２０４に格納されたプログラムであり、これをＣＰＵ２０２がＲＡＭ２０３に読み出して実行することで実現する。図３（Ａ）において、Ｗｅｂブラウザ３０１を利用し、スキャンサーバ１０１（図１）が提供するＷｅｂアプリケーションへのリクエストの送信と、レスポンスの表示等を行う。クラウドサービスを利用するユーザは本クライアント端末１０６のＷｅｂブラウザ３０１を利用して、クラウドサービスを利用する。

図３（Ｂ）は、画像形成装置１０７の構成例を示す。この例では、画像形成装置１０７は、スキャン機能とプリント機能を併せ持つ装置である。なお、スキャンサービスを実現するためには、画像形成装置１０７が、プリント機能のない、スキャン専用装置であってもよい。画像形成装置１０７は、画像処理ユニット４０１、印刷ユニット４０２、読み込みユニット４０３を備える。画像処理ユニット４０１は、画像処理を実行する。画像処理ユニット４０１は、例えば、印刷設定に応じたプリントデータを生成する。印刷ユニット４０２は、画像処理ユニット４０１によって生成されたプリントデータを媒体（例えば、紙媒体）に印刷出力する。読み込みユニット４０２は、例えば、不図示のスキャン装置を用いて、画像データを読み込む。画像処理ユニット４０１は、ＣＰＵ４０４、直接記憶部４０５、間接記憶部４０６、ユーザインタフェース４０７、外部インタフェース４０８を備える。

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

直接記憶部４０５は、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）により実現される。間接記憶部４０６には、アプリケーションプログラムおよびプラットフォームプログラムを含む各種プログラムが記憶されている。ＣＰＵ４０４が間接記憶部４０６に記憶されている各種プログラムの実行時に、この各種プログラムを直接記憶部４０５へ移動する。間接記憶部４０６は、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、または、ＨＤＤ（Ｈａｒｄ Ｄｉｓｃ Ｄｒｉｖｅ）により実現される。

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

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

次に、プラットフォーム上でアプリケーションプログラムを実行する方法について詳細に説明する。この例では、プラットフォーム上では、スキャンした画像をクラウドサービスに送信するスキャンソフトウェアが動作している。スキャンソフトウェアは、ネットワークを介して接続されているスキャンサーバ１０１から、例えば、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）などの通信プロトコルによってスキャンチケットの一覧の受信を行う。スキャンチケットにはスキャン時に画像データをどのように取り込むかに関する設定や、その後の処理フローといった情報が記録されている。以降、スキャンソフトウェアを実行することで実現するソフトウェア部をスキャンソフトウェア部と呼ぶ。

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

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

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

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

図４は、スキャンサーバ１０１の構成例を示す図である。スキャンサーバ１０１はクラウドサービスにおけるスキャン機能の提供を行うサーバである。このサービスの実態はＲＯＭ２０４に格納されたプログラムであり、これをＣＰＵ２０２がＲＡＭ２０３に読み出して実行することで実現する。スキャンサーバ１０１は、Ｗｅｂアプリケーション部５０１、チケット管理ＤＢ部５０２、テンプレート管理ＤＢ部５０３を備える。これら構成要素により各種処理が実行されることでスキャンサーバ１０１がユーザに提供される。

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

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

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

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

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

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

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

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

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

ユーザが、テンプレートを選択し、スキャンを実行した場合には、スキャンデータは、ルートＩＤ７０３に対応付けて定義されたタスクの順番で処理される。ここでいう「タスク」とは、ジョブを構成する各処理を表し、タスクサーバはこの「タスク」を処理する機能を有するサーバである。換言すれば、ジョブ処理は少なくとも１つ以上のタスクを処理することであり、例えば、複数のタスクサーバが連携して夫々のタスクを実行することでジョブ処理が行われる。パラメータ７０４は、図５中に示す詳細設定画面６０５上で設定されたスキャンの設定情報である。

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

図８は、タスクサーバの構成例を示す図である。この例では、タスクサーバ１０３の構成を説明する。このシステムの実態はＲＯＭ２０４に格納されたプログラムであり、これをＣＰＵ２０２がＲＡＭ２０３に読み出して実行することで実現する。各タスクサーバは、クラウドスキャンサーバを実現するための要素機能を実現するサービスである。タスクサーバ１０４の構成は、タスクサーバ１０３の構成と同様である。タスクサーバ１０３は、画像データに対してＯＣＲ処理を行い、ＯＣＲ結果のテキストデータを画像データに埋め込む処理を行う。また、タスクサーバ１０３は転送装置としても機能し、クラウドサービスサーバ群１０８の中のストレージ機能を提供する特定のサーバに対して、画像データを転送し、アップロードして保管するリクエストを行う。各タスクサーバは、与えられたタスクに対応する処理を行い、各サービスを提供する機能を有している。

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

図９は、本実施形態の負荷分散システムを示す。負荷分散システムは、スキャンサーバ１０１、タスクサーバ１０３、１０４、フローサーバ１０２を備える。以下、図９を参照し、フローサーバ１０２の詳細な説明を行う。フローサーバ１０２は本願発明における中心的なサーバであり、ルート管理、ジョブ管理、ファイル管理を行うサーバである。フローサーバ１０２は、中央管理サーバ１２００、１２０１、ファイルサーバＡ１２０２、ファイルサーバＢ１２０３、ファイルサーバＣ１２０４、データベースサーバ１２０５、ＳＬＢ１２０６を備える。フローサーバ１０２は、ネットワーク１１０を介してスキャンサーバ１０１およびタスクサーバ１０３，１０４と通信可能に接続される。また、フローサーバ１０２が備える各サーバは、ネットワーク１２１０を介して通信可能に接続される。また、ネットワーク１２１０はネットワーク１１０と接続されており、ネットワーク１２１０はネットワーク１１０と同様のデータの送受信が可能な通信ネットワークである。

中央管理サーバ１２００、１２０１は一般的にサーバコンピュータ上にて実行されており、その機能の詳細については図１１にて説明する。ファイルサーバ１２０２乃至１２０４は、一般にサーバコンピュータ上にて実行されており、必要に応じてファイルデータを保存、削除、取得する機能を有している。本実施形態では、ファイルデータは画像データなどのバイナリデータであり、単にファイルと呼称する場合もある。データベースサーバ１２０５は、一般にサーバコンピュータ上にて実行されており、その詳細機能については、図１２を参照して説明を行う。図９では、中央管理サーバ１２０１、１２０２、ファイルサーバＡ１２０２、Ｂ１２０３、Ｃ１２０４が示されるが、この数に限定されるものではない。通信データの量に応じて、中央管理サーバやファイルサーバの数は増減されてよい。

ＳＬＢ１２０６には、中央管理サーバ１２００と１２０１のアドレスが登録されており、ＳＬＢ１２０６にリクエストが送られると、ＳＬＢ１２０６は中央管理サーバ１２００もしくは１２０１のどちらかへとリクエストを振り分け・転送する機能を有する。このリクエスト振り分けの目的は、一つの中央管理サーバにアクセスが集中して負荷が偏らないようにするためである。すなわち、ＳＬＢ１２０６は、スキャンサーバ１０３、１０４から転送要求を受信したことに応じて、中央管理サーバ１２００、１２０１の処理状況に応じて中央管理サーバを決定する分散装置として機能する。リクエスト振り分けの方法については、様々な方法がありうる。例えば、中央管理サーバ１２００と１２０１へ順番にリクエストを振り分けるラウンドロビン方式やＳＬＢ１２０６からアクセスしている各中央管理サーバへの接続数を見て、最も少ない中央管理サーバへと振り分ける、最少コネクション方式などがある。本実施例においては、ＳＬＢ１２０６の振り分け方式については特に言及せず、一般的にＳＬＢ１２０６が提供する振り分け方式であれば特に限定しない。

図１０は、ＳＬＢ１２０６のシステム構成とＳＬＢが管理する管理テーブルの一例を示す。図３（Ａ）はＳＬＢ１２０６のシステム構成図である。このシステムの実態はＲＯＭ２０４に格納されたプログラムであり、これをＣＰＵ２０２がＲＡＭ２０３に読み出して実行することで実現する。図１０（Ａ）に示すように、通信受信部３０１は、通信元となるスキャンサーバ１０１、タスクサーバ１０３、１０４からの通信を受信する機能を有する。通信管理部３０３は、通信を分散すべき複数の中央管理サーバ１２００、１２０１を保存・管理する機能を有する。通信管理部３０３が管理する管理テーブルの一例を図１０（Ｂ）に示す。サーバＩＤ３１１は、登録した中央管理サーバを一意に識別するＩＤである。サーバＩＰ３１２は、通信を分散すべき中央管理サーバのＩＰアドレスである。最終転送日時３１３は、該当サーバに対して前回通信が転送された日時である。通信先判断部３０２は、通信受信部３０１が受信した通信を何処へ転送するかを判断する機能を有する。例えば、ラウンドロビン方式で振り分けを行う場合、通信先判断部３０２は、通信管理部３０３の最終転送日時３１３が一番古い日時になっているサーバＩＰに対して通信を転送する。

図１１は、中央管理サーバのシステム構成である。このシステム実態はＲＯＭ２０４に格納されたプログラムであり、これをＣＰＵ２０２がＲＡＭ２０３に読み出して実行することで実現する。中央管理サーバ１２００、１２０１はＷｅｂアプリケーション部１３００を実装するサーバである。Ｗｅｂアプリケーション部１３００は、ジョブ情報更新部１３０１、ジョブ追加部１３０２、ジョブ情報取得部１３０３、ファイル保存部１３０４、ファイル取得部１３０５、ファイル削除部１３０６、バックエンド部１３１０、外部Ｉ／Ｆ１３２０を備える。

本実施形態の中央管理サーバ１２００、１２０１は、スキャンサーバ１０１またはタスクサーバ１０３、１０４から転送されたファイルデータを保存する保存装置として機能する。Ｗｅｂアプリケーション部１３００のファイル保存部１３０４は保存手段として機能し、スキャンサーバ１０１やタスクサーバ１０３、１０４からの要求に応じてファイルデータを受信すると、受信したファイルをファイル保存部１３０４に格納する。また、ファイル保存部１３０４は、格納先のパスを管理する機能を有する。タスクサーバ１０３、１０４からファイル取得要求があった際には、ファイル取得部１３０５はファイル保存部１３０４から保存したファイルデータを取得し、タスクサーバ１０３、１０４に返却する。ファイル削除部１３０６は、スキャンサーバ１０１、タスクサーバ１０３、１０４からファイル削除の要求があった際には、保存したファイルを削除する。Ｗｅｂアプリケーション部１３００を利用することで、スキャンサーバ１０１やタスクサーバ１０３、１０４はファイルの格納先のパスやファイルサーバの状態を気にすることなく、ファイルの保存、取得、削除を行うことができる。

また、ジョブ情報取得部１３０３は、スキャンサーバ１０１からジョブ情報を受信すると、受信したジョブ情報をジョブ追加部１３０２に格納する。ジョブ追加部１３０２は、スキャンサーバ１０１から発行されるジョブ投入リクエストを受け、図１２に示すデータベースサーバ１２０５にジョブ情報を格納する。ジョブ情報更新部１３０１は、タスクサーバ１０３、１０４からの要求に応じて、ジョブ情報の取り出し・更新を行う機能を有する。外部Ｉ／Ｆ１３２０は、中央管理サーバに対する外部からの問い合わせを受け付けるＩ／Ｆであり、ジョブの追加・情報取得・更新、ファイルの保存、取得、削除などの要求をスキャンサーバ１０１、タスクサーバ１０３、１０４から受け付ける。

図１２は、データベースサーバ１２０５のシステム構成である。このシステムの実態はＲＯＭ２０４に格納されたプログラムであり、これをＣＰＵ２０２がＲＡＭ２０３に読み出して実行することで実現する。データベースサーバ１２０５は、外部Ｉ／Ｆ１６０１、ジョブ情報管理ＤＢ１６０２、ファイルサーバ管理ＤＢ１６０３、パス管理ＤＢ１６０４、ルート情報管理ＤＢ１６０５、タスク情報管理ＤＢ１６０６、スケール調整部１６０７を備える。

外部Ｉ／Ｆ１６０１は、中央管理サーバ１２００、１２０１からのリクエストに応えて、データベースサーバ１２０５が備える各ＤＢに対するアクセスを行うためのＩ／Ｆである。ジョブ情報管理ＤＢ部１６０２は、作成された各ジョブのステータスや各ジョブが扱うデータのＩＤを管理する。ジョブ情報管理ＤＢ部１６０２の管理する詳細な内容は、図１５に記載されており、ジョブ情報管理ＤＢ部１６０２の内容に関する説明は後述する。

ファイルサーバ管理ＤＢ部１６０３は、ファイルを格納するファイルサーバ１２０２〜１２０４に関する情報（図１３（Ａ））を管理する。パス管理ＤＢ部１６０４は、中央管理サーバ１２００のＷｅｂアプリケーション部１３００がファイル管理を実現するためのデータ情報を管理する。具体的には、パス管理ＤＢ部１６０４は、Ｗｅｂアプリケーション部１３００が管理している、ファイルサーバ１２０２〜１２０４に保存されたファイルデータとフォルダに関する情報を管理する。本発明では、Ｗｅｂアプリケーション部１３００が管理するファイルデータとフォルダをあわせてエンティティと呼ぶ。

ルート情報管理ＤＢ部１６０５は、タスクの連結をルートという単位で定義するための情報を保持している。タスク情報管理ＤＢ部１６０６は、各処理をタスクという単位で定義し、タスクに関する情報を保持している。スケール調整部１６０７は、中央管理サーバの増設、削減を行う機能を有する。増設する場合には、新たな中央管理サーバを起動してネットワーク１２１０につなげる処理を行う。削減する場合の処理は、実施例２で詳細を説明する。

以下、中央管理サーバ１２００とデータベースサーバ１２０５が行うファイル管理の詳細を説明する。中央管理サーバ１２００のファイル保存部１３０４は、スキャンサーバ１０１やタスクサーバ１０３、１０４からファイル保存リクエストを受けて、ファイルサーバ１２０２〜１２０４にファイルを多重化して保存する機能を実現する。多重度は呼び出し元であるスキャンサーバ１０１、タスクサーバ１０３、１０４が１以上の整数を指定でき、多重度１の場合は多重化せずに保存する場合と同義である。また多重度の最大値は、ファイルサーバ１２０２〜１２０４に存在する共有フォルダ数（図１３）であり、それ以上は無視される。

まず、ファイル保存処理を説明する。ファイル保存部１３０４は、スキャンサーバ１０１から初期データ保存のリクエストを受信すると、まず現在稼働中のファイルサーバの中から保存先のファイルサーバを選択する。この際、ファイル保存部１３０４は、保存しているフォルダ数またはデータ量が少ないファイルサーバから順に指定された多重度分だけ選択する。これは、各ファイルサーバ１２０２〜１２０４の容量を均一化するためである。例えば、多重度３であった場合、ファイル保存部１３０４は、自サーバに初期データを保存するとともに、ファイルサーバＡ，Ｂ，Ｃそれぞれに該初期データを保存する。従って、ユーザがフラグ設定等により、初期データの重要度を高く設定した場合には、３つのファイルサーバに初期データが保存されるため、より強固にデータを保護することが可能となる。スキャンサーバ１０１からの初期データ保存のリクエストには、多重度、タスクＩＤ、ファイルデータのＮｏが含まれる。ファイル保存部１３０４は、ファイルグループＩＤを生成し、ファイルグループＩＤ、タスクＩＤ、Ｎｏに基づいて保存先であるファイルサーバのファイルパスを生成する。なお、初期データを保存した場合は、呼び出し元のスキャンサーバ１０１に対して生成したファイルグループＩＤを返却する。

また、ファイル保存部１３０４がタスク処理を行ったタスクサーバ１０３、１０４からファイル保存のリクエストを受信した場合は、そのリクエストには、多重度、ファイルグループＩＤ、タスクＩＤ、ファイルデータのＮｏが含まれる。ファイル保存部１３０４は、受信したリクエストに含まれるファイルグループＩＤと同一のファイルグループＩＤを持つ初期データが保存されているファイルサーバをパス管理ＤＢ部１６０４から取得する。ファイル保存部１３０４は、初期データが保存されているファイルサーバに対して、タスク処理が行われたファイルを保存する。

ファイルサーバにファイルを保存するために、ファイル保存部１３０４は、バックエンド部１３１０に対して保存先ファイルパスとファイルデータを送信する。バックエンド部１３１０は保存先のファイルサーバとの通信の可否を確認し、通信可能であった場合はファイルを保存先ファイルサーバに保存する。多重保存する場合は上記の処理を多重度分繰り返す。バックエンド部１３１０は、全てのファイルの保存が完了したらファイル保存部１３０４に結果を返す。ファイル保存部１３０４は、パス管理ＤＢ部１６０４に保存先ファイルパスに関するエントリを多重度分追加する（図１３（Ｂ））。

図１３（Ａ）は、ファイルサーバ管理ＤＢ部１６０３が管理する管理テーブルの例を示す。ＩＤ２００１は、ファイルサーバをＷｅｂアプリケーション部１３００内で一意に識別するための情報である。ホスト名２００２は、ネットワーク１８１０上におけるファイルサーバの一意のアドレスを示し、Ｗｅｂアプリケーション部１９０１がバックエンド部１３１０を通じてファイルサーバ１２０２〜１２０４にアクセスする際に使用する。ステータス２００３は、Ｗｅｂアプリケーション部１９０１がバックエンド部１３１０を通じてホスト名２００２に存在するファイルサーバとの通信の可否を示す値であり、正常通信可能な場合は１、新規書き込み不可能な場合は−１を取る。共有フォルダ名２００４はファイルサーバ１２０２〜１２０４上に作成した共有フォルダ名である。ホスト名２００２と共有フォルダ名２００４から、ファイルサーバ１２０２〜１２０４上に作成した共有フォルダのフルパスが得られる。また、後述するように中央管理サーバ１２００、１２０１もファイルデータを保存するサーバとしてふるまうため、本ＤＢにファイルサーバと同等の情報が追加される。

図１３（Ｂ）は、パス管理ＤＢ部１６０４で管理する管理テーブルの例を示す。ファイルＩＤ２０１０は、ファイルサーバ１２０２〜１２０４でエンティティを一意に識別するための情報である。ファイルグループＩＤ２０１１は、各エンティティを関連するジョブでグループ化するための情報である。従って、同一ジョブによって生成されたエンティティは同一のファイルグループＩＤ２０１１を持つ。タスクＩＤ２０１２は各エンティティに関連するタスクのタスクＩＤ、フォルダを表す「Ｆｏｌｄｅｒ」、またはスキャンサーバ１０１からの要求により格納されたファイルを表す「ｉｎｉｔ」のいずれかの値が入る。本発明では、スキャンサーバ１０１からの要求により格納されたファイルを初期データと呼ぶ。Ｎｏ２０１３は、各タスクによって生成されたファイルのファイル番号を示す。パス２０１４はエンティティの格納先のフルパスを示し、Ｗｅｂアプリケーション部１９０１がバックエンド部１３１０を通じてエンティティにアクセスする際に使用する。ホスト名２０１５は、各エンティティの格納先のファイルサーバのホスト名を示す。作成日２０１６及び有効期限２０１７は、各エンティティの作成日及び有効期限を示す。

ファイルサーバ１２０２〜１２０４は、Ｗｅｂアプリケーション部１３００で管理するファイルを格納する格納装置として機能する。図１４は、ファイルサーバ１２０２〜１２０４のフォルダの階層構造を示す。フォルダ２１０１は共有フォルダであり、Ｗｅｂアプリケーション部１９０１がバックエンド部１３１０を通じてアクセス可能とする。共有フォルダ２１０１は、各サーバに少なくとも１つ存在し、ファイルサーバ管理ＤＢ部１６０３の共有フォルダ名２００４と一致する。本発明では共有フォルダ２１０１の深さを０とする。共有フォルダ２１０１の直下にある、深さ１のフォルダ群２１３１の各フォルダ２１１１、２１２１のフォルダ名はファイルグループＩＤ２０１１に対応する。また、２１１１および２１２１の直下にある深さ２のフォルダ群２１３２の各フォルダ２１１２、２１１３、２１２２、２１２４、２１２７のフォルダ名はタスクＩＤ２０１２に対応する。ファイル管理で管理されるファイルは、深さ３のフォルダ群２１３３に保存される。具体的には、「Ｉｎｉｔ」２１１２の直下のファイル２１１４は、スキャンサーバ１０１から送信された初期データである。Ｔａｓｋ１２１１３の直下のファイル２１１５、２１１６は、タスクサーバ１０３がタスク処理を行った結果データである。なお、このときのファイル名はＮｏ２０１３に対応する。

次に、ファイル取得処理を説明する。ファイル取得部１３０５は、タスクサーバ１０３、１０４のファイル取得要求に応じてファイルサーバ１２０２〜１２０４に保存されたファイルをタスクサーバ１０３、１０４に返す。具体的には、ファイル取得部１３０５は、タスクサーバ１０３、１０４のファイル取得要求に応じて、タスクＩＤに基づいてパス管理ＤＢ部１６０４に問い合わせ、タスクＩＤに紐付けられた格納先のファイルパスを取得する。ファイル取得部１３０５は、バックエンド部１３１０に対して格納先のファイパスを送信する。バックエンド部１３１０は、格納先のファイルサーバとの通信の可否を確認し、通信可能であった場合はファイルデータをファイル取得部１３０５に返す。ファイル取得部１３０５は、バックエンド部１３１０から返却されたファイルデータをタスクサーバ１０３、１０４に返す。

なお、中央管理サーバ１２００のファイル保存部１３０４がファイルデータを保存している場合は、中央管理サーバ１２００からファイルデータをタスクサーバ１０３、１０４に返せばよい。例えば、ファイル保存処理において、中央管理サーバ１２００とファイルサーバＡ１２０２にファイルが保存されている場合に、中央管理サーバ１２０１が該ファイルの取得要求をタスクサーバ１０３、１０４から受ける状況が想定される。この状況下では、中央管理サーバ１２０１のファイル取得部１３０５は、ファイル保存部１３０４がファイルを保存していない。そのため、中央管理サーバ１２０１のファイル取得部１３０５は、タスクサーバ１０３、１０４から要求されたファイルを保存しているファイルサーバＡ１２０２をデータベースサーバを介して特定する。そしてファイルサーバＡ１２０２からファイルを取得してタスクサーバ１０３、１０４に返す。

次に、ファイル削除処理を説明する。ファイル削除部３０６は、スキャンサーバ１０１、タスクサーバ１０３、１０４からの削除要求に応じて、ファイル保存部１３０４、ファイルサーバ１２０２〜１２０４に格納されたエンティティを削除する。ファイル削除部１３０６は、スキャンサーバ１０１、タスクサーバ１０３、１０４からリクエストを受信すると、リクエストに含まれるファイルグループＩＤ、タスクＩＤ、Ｎｏに基づいてパス管理ＤＢ１６０４に問い合わせる。ファイル削除部１３０６は、取得した格納先のエンティティに関する全てのファイルパスをバックエンド部１３１０に送信する。バックエンド部１３１０は、格納先のファイルサーバとの通信の可否を確認し、通信可能であった場合はエンティティを削除する。バックエンド部１３１０は、エンティティの削除が完了したら、ファイル削除部１３０６に結果を返す。エンティティの削除に成功したら、ファイル削除部１３０６は、パス管理ＤＢ部１６０４から削除したエンティティに関するエントリを削除する。

次に、ジョブ情報更新処理を説明する。ジョブ情報更新部１３０１は、タスクサーバ１０３、１０４から、外部Ｉ／Ｆ１３２０を通じて結果通知とともにジョブ情報更新リクエストを受信する。ジョブ情報更新部１３０１は、受信したジョブ情報を用いてデータベースサーバ１２０５のジョブ情報管理ＤＢ部１６０２が管理するジョブ情報を更新する。図１５は、データベースサーバ１２０５のジョブ情報管理ＤＢ１６０２が格納するジョブ情報の管理テーブルを示す。図１５に示すように、更新される情報は、カレントタスクＩＤ１７０４、ステータス１７０５、および最終更新時刻１７０６が挙げられる。カレントタスクＩＤ１７０４を更新する前に、ジョブ情報更新部１３０１は、データベースサーバ１２０５のルート情報管理ＤＢ部１６０５から、該ルートＩＤにおける次のタスクＩＤを取得する。取得したタスクＩＤを以て、カレントタスクＩＤ１７０４を更新する。また、ステータス１７０５は０、最終更新時刻１７０６は現在時刻で更新する。

図１６は、ルート情報管理ＤＢ部１６０５で管理されている情報の一例を示す。ルートＩＤ１４０１がルートを一意に識別するＩＤである。シーケンス番号１４０２はそのルートの何番目に実行するタスクであるかを保持する。タスクＩＤ１４０３はどのタスクを実行するかを保持する。例えば、データ１４１３、１４１４、１４１５、１４１６で、ルートＩＤ１４０１が００２のルートを定義している。１４１３が１番目に実行するタスクであり、タスクＩＤ１４０３がＴａｓｋ１のタスクを実行する。同様に、１４１４が２番目に実行するタスクであり、Ｔａｓｋ３のタスクを、１４１５は３番目に実行するタスクでＴａｓｋ５のタスクを実行するという定義となる。

図１５に戻り、ジョブ情報管理ＤＢ部１６０２に保持されるファイルデータについて説明する。ジョブＩＤ１７０１は、各ジョブ情報に一意に割り当てられるＩＤである。ルートＩＤ１７０２には、図６に示すチケット作成画面６０１にて選択したテンプレートに対応するルートＩＤが格納される。ファイルグループＩＤ１７０３は、Ｗｅｂアプリケーション部１３００から発行されるＩＤである。カレントタスクＩＤ１７０４は、そのジョブにおいて処理を行うべきタスクを示すタスクＩＤである。タスクサーバ１０３、１０４は、このカレントタスクＩＤ１７０４を確認し、自タスクサーバに割り当てられたタスクＩＤと等しい行を選択し処理を行う。本ＩＤは、該タスクの処理が完了した際には、ジョブ情報更新部１３０１が、該ルートＩＤの次のタスクのタスクＩＤに更新する。

ステータス１７０５には、処理待ち（０）、実行中（１）、エラー発生（２）を表す値が設定される。タスクサーバ１０３、１０４がジョブを選択する際には、ステータスが０となっている行を選択する。これにより、複数のタスクサーバが同一のタスクを処理するといった事態を防ぐことができる。タスクサーバ１０３、１０４が、ジョブを選択した後に、タスクサーバ１０３、１０４は、外部Ｉ／Ｆ１３２０を通じて、ジョブステータス変更部１６０５より、ステータス１７０５を１に変更する。最終更新時刻１７０６は、タスクサーバ１０３、１０４が該ジョブに対して、何らかの処理を実行した際に、更新される。ここで、何らかの処理とは、ステータスの更新処理や、ジョブの取得処理である。タスクサーバ１０３、１０４がジョブを取得する際に、自タスクＩＤと等しいジョブ情報が複数存在していた場合には、最終更新時刻１７０６が最も古いジョブを選択する。これにより、全てのジョブを平均的に処理することが可能となる。パラメータ１７０７には、詳細設定画面６０５にて設定した設定情報や、タスクサーバ１０３、１０４が、他のタスクサーバ１０３、１０４に渡す設定情報などを記載する。

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

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

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

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

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

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

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

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

次に、図１８と図１９を用いて、スキャンサーバ１０１とフローサーバ１０２が通信する詳細な仕組みを説明する。図１８は、スキャンサーバ１０１の通信部５１７がＷｅｂアプリケーション部１３００に対して通信を行う際の動作を表すフローチャートである。図１９は、フローサーバ１０２のＷｅｂアプリケーション部１３００がスキャンサーバ１０１からの通信を受けて行う動作を表すフローチャートである。

まず、図１８のＳ１８０１において、スキャンサーバ１０１の通信部５１７は、まずＷｅｂアプリケーション部１３００に送信するリクエストに含まれるメソッドのタイプを確認する。Ｓ１８０２で、通信部５１７は、ファイル転送以外のメソッド、つまりバイナリ転送を伴わないメソッドの場合、ＳＬＢ１２０６に対してメソッドの呼び出しを実行する。ここで、ＳＬＢ１２０６は、メソッドリクエストを中央管理サーバ１２００か１２０１へ適切に振り分けを行い、どちらかの中央管理サーバの外部Ｉ/Ｆ１３２０に対してメソッドリクエストを送信する。この時、中央管理サーバのファイル保存部１３０４は、図１９のＳ１９０１にてメソッドリクエストからメソッドのタイプを判定する。今回はファイル転送以外のメソッドなので、Ｓ１９０２にて、ファイル保存部１３０４から要求されたメソッドを実行し、Ｓ１９０３にてその結果をレスポンスとしてＳＬＢ１２０６経由でスキャンサーバ１０１へ返信する。

一方、Ｓ１８０１で通信部５１７は、ファイル転送メソッドであると判定した場合、Ｓ１８０３にて転送するファイルデータのサイズ確認を行う。この時、ファイルのサイズがある一定以下の大きさの場合、Ｓ１８０４で通信部５１７は、データを転送する転送手段として機能し、ＳＬＢ１２０６に対してメソッドの実行、すなわちファイル転送を行う。ここで、ＳＬＢ１２０６は、転送されたファイルデータを中央管理サーバ１２００か１２０１へ適切に振り分けを行い、中央管理サーバの外部Ｉ/Ｆ１３２０に対して送信する。この時、ファイル保存部１３０４は、Ｓ１９０１にてメソッドタイプを確認するが、ファイル転送メソッドのため、Ｓ１９０４にて外部Ｉ/Ｆ１３２０を介してファイルを受信する。

次に、ファイル保存部１３０４は、受信したファイルを保存する処理を実行する。このとき、ファイル保存部１３０４が特定のファイルサーバに保存しただけでは、該当サーバがクラッシュした場合、ファイルデータも取得できなくなり、それを必要とするタスクサーバ１０３がタスク／ジョブが実行できなくなるリスクがある。そこで、本実施形態においては、ファイル保存部１３０４は、受信したファイルデータを異なる２つのサーバに保存することで、上記リスクを回避する仕組みを組み込んでいる。ファイル保存部１３０４は、ファイル保存スレッドとしてＳ１９０５とＳ１９０６の２重書き込みを実行する。この時書き込み先として２つともネットワーク上のファイルサーバを指定すると、ネットワーク帯域を２倍使ってしまう。そこで、Ｓ１９０５では、Ｗｅｂアプリケーション部１３００のファイル保存部１３０４は、ネットワーク上のファイルサーバＡ／Ｂ／Ｃから任意のサーバを選択して、ファイルを保存する。一方、Ｓ１９０６ではメソッドを実行している中央管理サーバ１２００か１２０１のローカルディスク、つまりファイル保存部１３０４にファイルを保存する。またＳ１９０５、Ｓ１９０６では、Ｗｅｂアプリケーション部１３００がパス管理ＤＢ１６０４に対して管理対象として保存したファイルの情報を追加する（図１３（Ａ））。これによってネットワーク帯域を余計に使用することなく、ファイルの多重度を上げることができる。

また、Ｓ１８０３で、通信部５１７が、ファイルのサイズがある一定以上の大きさだと判定した場合に、Ｓ１８０５でファイル保存部１３０４は、ＳＬＢ１２０６に対してアドレス情報リクエストを送信する。ここで、ＳＬＢ１２０６は、アドレス情報リクエストを中央管理サーバ１２００か１２０１へ適切に振り分けを行い、Ｗｅｂアプリケーション部１３００のファイル保存部１３０４に対してアドレス情報を要求する。ここでアドレス情報とは、ＩＰアドレスやホスト名など、サーバ間の通信を実行する際、通信先サーバを一意に特定できる情報を意味する。

この時ファイル保存部１３０４は、Ｓ１９０１でファイル転送以外のメソッドであってアドレス情報リクエストと判定する。Ｓ１９０２でファイル保存部１３０４は、Ｗｅｂアプリケーション部１３００がホストされているサーバのアドレス情報を取得し、Ｓ１９０３でレスポンスとしてアドレス情報をＳＬＢ１２０６経由で通信部５１７に返信する。すなわち、ファイル保存部１３０４は、位置情報の取得要求を受付けてＳＬＢ１２０６に位置情報を送信する送信手段として機能する。Ｓ１８０６で、通信部５１７はアドレス情報を受信し、Ｓ１８０７にてそのアドレスに向けてファイル転送を実行する。すなわち、通信部５１７は、転送するファイルデータに応じてＳＬＢ１２０６にファイルデータを転送するか、ＳＬＢ１２０６を介さずＳＬＢ１２０６が決定した中央管理サーバにファイルデータを転送するか転送方法を決定する決定手段として機能する。この転送方法により、通信部５１７は、ＳＬＢ１２０６を経由せずに指定の中央管理サーバにファイルを直接転送するので、ＳＬＢ１２０６の性能制限を受けず、ネットワーク１２１０の帯域を十分に使った転送処理が可能となる。Ｗｅｂアプリケーション部１３００は、Ｓ１９０１でメソッドタイプをファイル転送メソッドと判定し、Ｓ１９０４にて転送されるファイルデータを受信する。受信したファイルに関しては、ファイル保存部１３０４は前述のとおりＳ１９０５、Ｓ１９０６にて２つの異なるサーバに保存する。

なお、Ｓ１８０３で「一定のサイズ」の判定基準は、動的に決定してもよい。例えば、同時期に存在するジョブの量から同時アクセス数は割り出せるので、ＳＬＢ１２０６の処理性能（一定時間に転送できるファイルサイズ）を同時アクセス数で割った値がＳＬＢ１２０６の転送可能な平均ファイルサイズになる。そこでこのサイズを前記「一定のサイズ」としてＳ１８０３の判定に利用するようにしてもよい。

以上により、ＳＬＢ１２０６によるサーバの負荷分散を行いつつも、ＳＬＢ１２０６の性能限界による帯域制約をうけないよう効率的な通信を行うことが可能となる。また、転送データがＳＬＢ１２０６の性能限界に影響をあたえないほど小さなデータの場合には無駄に呼び出し回数を増加させないようメソッドタイプと転送データの大きさによって動的にＳＬＢ１２０６経由で効率的な通信を行うことが可能となる。また、転送されたファイルデータを異なる２つのサーバに保持するに当たり、片方をローカルディスクに保存させることで、ファイルを２重保持しつつも、ネットワーク帯域を節約した効率的な通信を行うことができる。

（実施例２）
実施例１において、中央管理サーバは２つに限定する必要はなく、ジョブの流量が多い場合には、中央管理サーバをネットワークに新たに接続してスケールアウトさせることができる。もちろん、ジョブの流量が少ないときには、多くのサーバを立ち上げておくのは無駄なため、中央管理サーバを減らしてスケールインさせる仕組みも必要である。

しかし、スケールイン時に削減する中央管理サーバのローカルディスクにもファイルデータが存在する可能性があり、別のファイルサーバに退避させる必要がある。この時、特定のファイルサーバに全てのファイルを移動させてしまうと、同一ファイルサーバに同じファイルが複数存在するケースができてしまう。この場合、そのファイルサーバがクラッシュすると、２重保持した両方のファイルが同時に失われてしまい、２重保持した意味がない。そこで、中央管理サーバをスケールインする際には、削減する中央管理サーバが保持するファイルごとに、同一のファイルを保持しないファイルサーバを宛先に選んで退避させることが必要となる。

中央管理サーバの削減処理において、図１２に示すデータベースサーバ１２０５が管理装置として機能し、スケール調整部１６０７が、例えば、通信データの転送処理量が閾値以下である場合にネットワーク１２１０を通じて削減処理を実行する。図２０は、スケール調整部１６０７が実行する中央管理サーバ削減処理のフローチャートである。まずスケール調整部１６０７は禁止手段として機能し、Ｓ２４０１にて削減対象となる中央管理サーバを新規書き込みを禁止する状態にする。具体的には、ファイルサーバ管理ＤＢ１６０３にアクセスし、削減対象となる中央管理サーバのステータス２００３（図２０ Ａ参照）の値を−１に変更する。次にＳ２４０２にて、スケール調整部１６０７は、削減対象となる中央管理サーバに保存されているファイルデータが存在するかどうかをチェックする。ファイルデータが存在する場合、スケール調整部１６０７は、同一データを格納している格納装置以外の格納装置を抽出する抽出手段として機能する。つまり、スケール調整部１６０７は、Ｓ２４０３にて削減対象の中央管理サーバ上にある任意のファイルに関して、パス管理ＤＢ１６０４とファイルサーバ管理ＤＢ１６０３を参照して同一のファイルが存在しないファイルサーバを抽出する。これにより、削除対象の中央管理サーバにファイルデータが残っていた場合に、ファイルデータが削除されることを防止する。

具体的には、スケール調整部１６０７は、図１３（Ｂ）に示すファイルグループＩＤ２０１１、タスクＩＤ２０１２、Ｎｏ２０１３の３つが同一のファイルが存在するホスト名を抽出する。そして、スケール調整部１６０７は、そのホスト名以外のファイルサーバ１つ、図１３（Ａ）を参照して任意に選択する。Ｓ２４０４にてスケール調整部１６０７は、選択したファイルサーバに対して、前記ファイルのコピーを実行する。スケール調整部１６０７は、Ｓ２４０５にて管理パス変更を実施する。具体的には、対象のファイルに対して、図１３（Ｂ）のパス２０１４とホスト名２０１５をＳ２４０４でコピーした宛先へと変更を実施する。Ｓ２４０６では、スケール調整部１６０７は移動元のファイルを削除する。

その後、再度Ｓ２４０２に戻り、スケール調整部１６０７は、削減対象の中央管理サーバにファイルデータが存在するかどうかを再度確認する。以降、ファイルデータが存在する限り、このＳ２４０２〜Ｓ２４０６を繰り返す。Ｓ２４０２にて、削減対象の中央管理サーバにファイルが存在しないことが確認されると、Ｓ２４０７にてスケール調整部１６０７が管理手段として機能し、削減対象の中央管理サーバをシャットダウンし、本システムより削除する。同様の処理により、スケール調整部１６０７はファイルサーバを作成・削除することも可能である。

以上により、中央管理サーバをスケールインする際にも、同一ファイルを複数のファイルサーバで多重保持する構成を維持することが可能となる。

（実施例３）
実施例１では、スキャンサーバからのジョブ投入する構成において、ＳＬＢ１２０６経由でのメソッド実行か宛先サーバのアドレスに対する直接実行かを切り替えることで、ＳＬＢ１２０６による帯域制約を回避するか、呼び出し回数を減らすかを動的に切り替えた。しかし、前記実施例１では、ファイルデータの読み出しのシナリオが含まれていなかった。

図２１、図２２は、ファイルデータの読み出しも存在するシステムにおいてそれぞれ図１８、図１９を拡張したフローチャートである。具体的には、図２１はタスクサーバ１０３、１０４の通信部１０１６がＷｅｂアプリケーション部１３００に対して通信を行う際の動作を表すフローチャートである。図２２は、フローサーバ１０２のＷｅｂアプリケーション部１３００がタスクサーバ１０３、１０４からの通信を受けて行う動作を表すフローチャートである。

図２１のＳ１８０１からＳ１８０２は、図１８と同様で、実行主体がスキャンサーバ１０１からタスクサーバ１０３、１０４に変わっただけである。Ｓ１８０１にてメソッドタイプがファイル転送メソッドと判定された場合、通信部１０１６はＳ２２０１でファイル転送メソッドが書き込みメソッドなのか読み込みメソッドなのかを判定する。書き込みメソッドの場合、通信部１０１６は図１８と同様、Ｓ１８０３〜Ｓ１８０７を実行する。

一方、Ｓ２２０１でファイル読み込みメソッドだと判定された場合、Ｓ２２０２にて通信部１０１６は、ＳＬＢ１２０６宛てにメソッドの実行を指示する。これによりＳＬＢ１２０６を通じて適切な中央管理サーバにあるＷｅｂアプリケーション部１３００のＡＰＩの読み込みメソッドが呼び出される。

この時、Ｗｅｂアプリケーション部１３００のファイル取得部１３０５は、図２２のＳ１９０１でファイル転送メソッド、Ｓ２３０１で読み込みメソッドと判定する。すなわち、ファイル取得部１３０５は、ファイルデータを取得することを求める取得要求か、またはタスクサーバにより処理されたデータを中央管理サーバに転送することを求める転送要求かを特定する特定手段として機能する。またファイル取得部１３０５は、Ｓ２３０２にて対象ファイルが保存されているファイルサーバもしくは中央管理サーバにアクセスし、読み込み対象となるファイルのサイズ確認を行う。この時ファイルサイズがある一定の閾値よりも大きい場合、Ｓ２３０３にてファイル取得部１３０５は自サーバのアドレス情報を転送先として取得する。そしてファイル取得部１３０５は、例外を発生させた上で、その例外の属性としてアドレス情報を組み込み、通信部１０１６にＳＬＢ１２０６経由で返信する。通信をうけた通信部１０１６は、図２１のＳ２２０３で受信データがファイルデータか、アドレス情報を含む例外なのかを判定する。例外情報と判定した場合、Ｓ２２０４で通信部１０１６は取得したアドレス宛に再度読み込みメソッドを実行する。このとき、通信部１０１６は取得手段として機能し、ファイルデータが予め定められたデータ量を超える場合に、ＳＬＢ１２０６により決定される中央管理サーバからデータを直接取得する。ファイル取得部１３０５は、Ｓ２３０４にて目的のファイルをファイルサーバから取得し、Ｓ２３０５にて取得したファイルを通信部１０１６に転送する。Ｗｅｂアプリケーション部１３００では通信部１０１６が転送されてきたファイルデータを受信する。

一方、図２２のＳ２３０２で対象ファイルサイズがある一定の閾値よりも小さい場合、Ｗｅｂアプリケーション部１３００はＳ２３０４、Ｓ２３０５を実行し、前記同様ファイルを取得転送する。ただし、この場合は、ＳＬＢ１２０６経由で通信部１０１６へ転送される。さらにこの場合、通信部１０１６はＳ２２０３にて受信データを判定するが、ファイルデータであると判定し、そのままＳ２２０５でファイル受信を行う。

以上により、ファイル書き込み時だけでなくファイル読み込み時においても、転送ファイルサイズによってＳＬＢ経由の通信を回避するか、呼び出し回数を増加させないＳＬＢ経由の通信を実施するかを動的に切り替えて効率的な通信を行うことが可能となる。

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

１０１ スキャンサーバ
１０２ フローサーバ
１０３タスクサーバ
１２０６ ＳＬＢ
１２００，１２０１ 中央管理サーバ
１２０５ データベースサーバ

Claims (8)

1. データを転送する転送装置と、転送された前記データを保存する複数の保存装置と、前記転送装置からの転送要求を受信したことに応じて、前記保存装置の中から処理状況に応じて前記データの転送を受ける保存装置を決定する分散装置とを備える負荷分散システムであって、
   前記転送装置は、
   転送するデータに応じて、前記分散装置にデータを転送するか、前記分散装置を経由せず前記分散装置により決定される保存装置にデータを転送するか、転送方法を決定する決定手段と、
   前記決定された転送方法に従い、データを転送する転送手段とを備える
   ことを特徴とする負荷分散システム。
2. 前記決定手段は、前記データが予め定められたデータ量を超える場合に、前記分散装置を経由せず前記分散装置により決定される保存装置にデータを転送することを決定し、前記分散装置から前記保存装置の位置情報を取得し、前記データが予め定められたデータ量を超えない場合は、前記分散装置にデータを転送することを決定し、
   前記転送手段は、前記決定手段が前記分散装置を経由せず前記分散装置により決定される保存装置にデータを転送することを決定した場合に、前記取得された前記位置情報に基づいて前記データを前記保存装置に直接転送する
   ことを特徴とする請求項１に記載の負荷分散システム。
3. 前記保存装置は、
   前記分散装置から前記位置情報の取得要求を受付けて前記分散装置に前記位置情報を送信する送信手段と、
   前記分散装置または前記転送装置から前記データを受信し、受信された前記データを保存する保存手段とを備え、
   前記保存手段は、保存された前記データと同じデータをネットワークを介して格納装置に転送し、前記転送されるデータを保存することを指示する
   ことを特徴とする請求項２に記載の負荷分散システム。
4. 前記保存装置は、
   前記転送装置から前記分散装置を介して要求を受信し、前記要求がデータを取得することを求める取得要求か、または前記転送装置により処理されたデータを前記保存手段に転送することを求める転送要求かのいずれであるかを特定する特定手段をさらに備え、
   前記要求が前記取得要求である場合であって、前記データが予め定められたデータ量を超えるときは、前記送信手段が、前記保存装置の位置情報を前記分散装置を介して前記転送装置に送信し、前記転送装置が備える取得手段が、受信した前記位置情報に基づいて前記保存装置から前記データを直接取得し、前記データが予め定められたデータ量を超えないときは、前記取得手段が、前記分散装置を介して前記保存装置が備える前記送信手段から前記データを取得し、
   前記要求が前記転送要求である場合であって、前記処理されたデータが予め定められたデータ量を超えるときは、前記転送装置が備える前記決定手段が、前記処理されたデータの転送先の保存装置の位置情報を前記分散装置を介して取得し、取得した位置情報に基づいて前記保存装置に前記処理されたデータを直接転送し、前記処理されたデータが予め定められたデータ量を超えないときは、前記決定手段が、前記分散装置に前記処理されたデータを転送することを決定する
   ことを特徴とする請求項３に記載の負荷分散システム。
5. 前記保存手段は、複数の前記格納装置のうち保存しているデータ量が閾値以下である格納装置を抽出し、抽出された前記格納装置に対し前記保存手段が保存したデータと同じデータを保存することを指示し、
   前記送信手段は、前記取得要求された前記データを前記転送装置に送信する場合に、前記保存手段が該データを保存しているか否かを特定し、前記保存手段が前記データを保存していない場合に、前記データと同じデータを保存している格納装置から該データを取得して、前記転送装置に送信する
   ことを特徴とする請求項４に記載の負荷分散システム。
6. 前記保存装置および前記格納装置を管理する管理装置をさらに備え、
   前記管理装置は、
   前記データの転送処理の状況に応じて前記保存装置を作成または削除する管理手段と、
   前記データの転送処理量が閾値以下である場合に前記保存装置を削除することを決定し、削除対象の保存装置への前記データの転送を禁止する禁止手段と、
   前記削除対象の保存装置に前記データが保存されているか否かを確認し、該データが保存されている場合は、該データと同じデータを格納している格納装置以外の格納装置を抽出する抽出手段とを備え、
   前記管理手段は、抽出された格納装置に前記削除対象の保存装置に保存されている前記データを転送して該データの保存を指示するとともに、前記削除対象の保存装置を削除する
   ことを特徴とする請求項３乃至請求項５のいずれか一項に記載の負荷分散システム。
7. データを転送する転送装置と、転送された前記データを保存する複数の保存装置と、前記転送装置からの転送要求を受信したことに応じて、前記保存装置の中から処理状況に応じて前記データの転送を受ける保存装置を決定する分散装置とを備える負荷分散システムの制御方法であって、
   前記転送装置が、転送するデータに応じて、前記分散装置にデータを転送するか、前記分散装置を経由せず前記分散装置により決定される保存装置にデータを転送するか、転送方法を決定する決定工程と、
   前記決定された転送方法に従い、データを転送する転送工程とを含む
   ことを特徴とする制御方法。
8. 請求項７に記載の制御方法をコンピュータにより実行させることを特徴とするコンピュータプログラム。

Images