JP5539017B2 - クラウドコンピューティングシステム、文書処理方法、及びコンピュータプログラム - Google Patents

Description

本発明は、クラウドコンピューティングシステム、文書処理方法、及びコンピュータプログラムに関する。

一つの処理要求を受けて、処理対象のデータを複数に分割して複数の処理モジュールで同時並行的に処理を行い、処理結果を結合して上記処理要求に対する結果として出力するシステムが提案されている。例えば、特許文献１は、端末装置から受けた印刷データを分割して各プリンタエンジンに割り当て、各プリンタエンジンが出力した印刷データをソートして出力するネットワークプリンタ装置を開示している。

一方、最近、クラウドコンピューティング（以下、クラウドと記述）というコンピュータの利用形態が提案されている。クラウド環境においては、ユーザがコンピュータ処理をネットワーク経由でサービスとして利用する。クラウド環境上にネットワークサービスシステムを構築することにより、サービス提供者は、ハードウェアの維持・管理といった問題から解放され、必要なコンピュータリソースを使用した分だけの料金をクラウド事業者に支払えば済むようになる。従って、コスト削減や柔軟なリソース増減を実現できる。

特開平１１−１９４９１０号公報

しかし、特許文献１が開示する技術では、処理に必要なコンピュータリソースは物理的に固定されており、柔軟に増減させることができない。また、クラウド環境において、コンピュータリソースを増減させる場合、従来は管理用のツールなどを介して人手で行うことがほとんどであった。従って、特に、前述したような、一つの処理要求を受けて、処理対象のデータを分割して処理し、処理結果を結合するシステムにおいて、コンピュータリソースを柔軟に増減させて有効に活用することはできなかった。

本発明は、文書データの処理要求を受けて、処理対象のデータを分割して処理し、処理結果を結合するシステムであって、処理の状況に応じて、処理の実行主体の数を増減することができるクラウドコンピューティングシステムの提供を目的とする。

本発明の一実施形態のクラウドコンピューティングシステムは、画像形成装置からジョブの処理依頼を受信したことに応じて、前記ジョブに対応するメッセージを記憶手段に格納する、要求受信プログラムを実行することにより実現される要求受信部と、前記記憶手段に対し前記メッセージの取得要求を定期的に行い、前記記憶手段から前記メッセージを取得した場合は、該取得したメッセージに基づく処理を行う、バックエンド処理プログラムを実行することにより実現されるバックエンド処理部とを有するクラウドコンピューティングシステムであって、前記処理依頼に対応する文書データを分割して分割文書データを生成するバックエンド処理部である分割処理バックエンド処理部と、前記分割文書データを文書処理するバックエンド処理部である文書処理バックエンド処理部と、前記文書処理された分割文書データを結合するバックエンド処理部である結合処理バックエンド処理部と、前記分割処理バックエンド処理部、前記文書処理バックエンド処理部、または前記結合処理バックエンド処理部の夫々の処理状況に応じて、該夫々のバックエンド処理部の数を増減させる管理部と、前記分割処理バックエンド処理部、前記文書処理バックエンド処理部、前記結合処理バックエンド処理部の夫々に対応する前記記憶手段を備える。前記管理部は、前記記憶手段に格納されている前記ジョブの数、または該記憶手段への前記ジョブの格納時間に基づいて、該記憶手段に対応するバックエンド処理部の数を増減させ、前記文書処理バックエンド処理部は、第１の処理性能を有する第１文書処理バックエンド処理部と、第１の処理性能より処理性能が高い第２の処理性能を有する第２文書処理バックエンド処理部とを含み、前記分割処理バックエンド処理部は、前記文書データを前記第１文書処理バックエンド処理部の数に分割した場合に生成される分割文書データのサイズが所定の閾値を超えるかを判断し、該分割文書データのサイズが該閾値を超える場合に、該第２文書処理バックエンド処理部に対応する記憶手段に、該第２文書処理バックエンド処理部の数の分のジョブを格納し、該分割文書データのサイズが該閾値を超えない場合に、該第１文書処理バックエンド処理部に対応するキューに、該第１文書処理バックエンド処理部の数の分のジョブを格納する。

本発明のクラウドコンピューティングシステムによれば、文書データの処理要求を受けて、処理対象のデータを分割して処理し、処理結果を結合することができるとともに、処理の状況に応じて、処理の実行主体の数を増減することができる。

本実施形態のシステムの構成例を示す図である。 サーバのハードウェア構成図の例である。 文書処理システムが備えるサーバ群が提供するプラットフォームシステムの例である。 ユーザ装置と文書処理システムの機能ブロックの例である。 リクエスト・テーブルと文書処理テーブルの例を示す図である。 受信処理部の動作処理を説明するフローチャートである。 分割処理部の動作処理を説明するフローチャートである。 文書処理部の動作処理を説明するフローチャートである。 結合処理部の動作処理を説明するフローチャートである。 リソース管理部の動作処理を説明するフローチャートである。 分割処理部の動作処理を説明するフローチャートである。 文書処理システムの機能ブロックと、初期インスタンス数管理テーブルの例を示す図である。 リソース管理部の動作処理を説明するフローチャートである。 初期インスタンス数管理テーブルの例を示す図である。 リソース管理部の動作処理を説明するフローチャートである。 文書処理システムの機能ブロックと、初期インスタンス数管理テーブルの例を示す図である。 分割処理部の動作処理を説明するフローチャートである。 リソース管理部の動作処理を説明するフローチャートである。 文書処理部の高性能ＶＭのインスタンス数の調節処理を説明するフローチャートである。

図１は、本実施形態のシステムの構成例を示す図である。図１に示すシステムは、文書処理システム１０１と、ＰＣ（Personal Computer ）１０３と、ＭＦＰ（Multi Function Peripheral ）１０２とを備える。文書処理システム１０１は、サーバ群を含んでおり、インターネット等のネットワーク１２０に接続されている。また、ユーザが操作するユーザ装置であるＰＣとＭＦＰ１０２は、ＬＡＮ１１０を介してネットワーク１２０に接続されている。

本実施形態においては、ＬＡＮ１１０は、ネットワーク１２０からファイアウォールで遮断されている。すなわち、ＭＦＰ１０２とＰＣ１０３は、外部からのアクセスが制限されたローカルエリアに配置されている。また、文書処理システム１０１は、クラウドに設けられているクラウドコンピューティングシステムである。クラウドとは、クラウドコンピューティング環境におけるサーバ群が配置される領域のことである。クラウドコンピューティング環境においては、ユーザはコンピュータ処理をネットワーク経由でサービスとして利用する。クラウドに設けられた文書処理システム１０１から発する要求によりファイアウォール内部にアクセスすることはできない。従って、文書処理システム１０１は、ＭＦＰ１０２又はＰＣ１０３からの要求の応答を返すことによって、ＭＦＰ１０２又はＰＣ１０３に対して通信を行う。本実施形態の文書処理方法は、図１に示すシステムによって実現される。また、本実施形態のコンピュータプログラムは、この文書処理方法をコンピュータに実行させる。

図２は、文書処理システムが備えるサーバ群に含まれるサーバのハードウェア構成図の例である。制御部２１０は、サーバの動作を制御する。制御部２１０は、ＣＰＵ（Central Processing Unit ）２１１、ＲＯＭ（Read Only Memory）２１２、ＲＡＭ（Random Access Memory）２１３を備える。また、制御部２１０は、ＨＤＤ（Hard Disk Drive ）２１４、ネットワークＩ／Ｆ（Interface ）２１５を備える。制御部２１０が備える各処理部は、バス２１６に接続されている。

ＣＰＵ２１１は、制御部２１０全体を制御する。ＣＰＵ２１１は、ＲＯＭ２１２やＨＤＤ２１４に予め記憶された制御プログラムを読み出して読取制御や送信制御などの各種制御処理を実行する。ＲＡＭ２１３は、ＣＰＵ２１１の主メモリ、ワークエリアなどの一時記憶領域として用いられる。ＨＤＤ２１４は、画像データや、各種プログラムを記憶する。ネットワークＩ／Ｆ２１５は、制御部２１０をネットワーク１２０に接続し、ネットワーク１２０上の外部装置との間で情報の送受信を行う。

図３は、文書処理システムが備えるサーバ群が提供するプラットフォームシステム（オペレーティングシステム）の例である。このプラットフォームシステムは、サーバ群を構成する各サーバのＣＰＵ２１１が、ＲＯＭ２１２またはＨＤＤ２１４に記憶されている制御プログラムを、ＲＡＭ２１３を一時記憶領域として使用しながら実行することにより実現される。また、このプラットフォームシステムは、記憶領域としてＲＡＭ２１３やＨＤＤ２１４を利用する。このプラットフォームの利用者は、サーバ群１０１内にある物理ハードウェア・リソースをコンピューティングリソースとして使用できる。

図３に示すプラットフォームシステムは、複数のＶＭ３０１、３０２、ファブリック・コントローラ３０３、ロード・バランサ３０４、キュー・サービス３１１、ブロブ・ストア３１２、テーブル・ストア３１３、管理ＶＭ３０７を有する。ＶＭは、Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅの略称である。ＶＭは、文書処理システム１０１が備える物理的なサーバ群１０１上において、仮想化技術によって独立したオペレーティングシステムで動作する論理的なコンピュータである。この論理的なコンピュータの単位をインスタンスという。本実施形態においては、１つのインスタンスは、サーバ群を構成する一つのサーバ上で動作する。

ＶＭ３０１は、要求受信部（Ｗｅｂ Ｒｏｌｅインスタンス）３０１１と要求受信部エージェント３０１２とを備える。要求受信部３０１１は、ロード・バランサ３０４を介してユーザ装置からの処理依頼を受信する。また、要求受信部３０１１は、キュー・サービス３１１を介してバックエンド処理部３０２１への処理依頼を送信する。要求受信部エージェント３０１２は、ＶＭ３０１の使用状況、要求受信部３０１１の稼動状態、ＶＭ３０１のリソースの使用状況および要求受信部３０１１のエラーを含む各種情報を収集して、ファブリック・コントローラ３０３に定期的に送信する。

ＶＭ３０２は、バックエンド処理部（Ｗｏｒｋｅｒ Ｒｏｌｅインスタンス）３０２１とバックエンド処理部エージェント３０２２とを備える。バックエンド処理部３０２１は、キュー・サービス３１１を介して要求受信部３０１１からの処理依頼を受信する。バックエンド処理部３０２１は、キュー・サービス３１１を介して要求受信部３０１１から受信した処理依頼を実行する。また、バックエンド処理部３０２１は、スケールアウトが可能である。スケールアウトとは、ＶＭ３０２が増加し、バックエンド処理部３０２１のインスタンスが増加することをいう。バックエンド処理部３０２１のインスタンスが増加することによって、処理能力が向上し、ユーザ装置からの複数の処理依頼に対する結果をより早く返すことができる。

ファブリック・コントローラ３０３は、要求受信部３０１１、バックエンド処理部３０２１の各インスタンスを管理している。これにより、各インスタンスの拡張性と可用性が保証される。例えば、要求受信部３０１１またはバックエンド処理部３０２１において、ある特定のインスタンスがサーバの故障によって停止した場合を想定する。この場合、ファブリック・コントローラ３０３が、停止したインスタンスに対応する要求受信部エージェント３０１２またはバックエンド処理部エージェント３０２２から定期通知を受け取らなくなる。これにより、ファブリック・コントローラ３０３は、停止したインスタンスに対応するＶＭに対して、新しいインスタンスに処理を委譲するように指示する。この結果、処理を実行しているインスタンス数が一定に保たれるため、処理の遅延を抑えることができる。

ロード・バランサ３０４は、外部ネットワークからの要求（ここではＨＴＴＰによる通信）を一元的に管理し、同等な要求受信部の機能を有する複数のＶＭに対し、選択的に要求を転送する。これによって、要求受信部３０１１の高い可用性が確保される。管理ＶＭ３０７は、要求受信部３０１１と要求受信部エージェント３０１２とを備える。ＶＭ３０１との違いは、管理ＶＭ３０７が、管理ユーザのみが利用できる要求受信部３０１１のインスタンスを持つＶＭである点である。

キュー・サービス３１１は、各インスタンスが非同期でデータ通信するためのサービスを提供する。例えば、要求受信部３０１１が、バックエンド処理部３０２１に実行させたいジョブに関する情報を、メッセージとしてキューに書き込みむ。バックエンド処理部３０２１は、キューに書き込まれたメッセージを読み出し、その読み出した情報に基づいて処理を実行する。ブロブ・ストア３１２は、バイナリ形式のデータを保存する機能を提供する。テーブル・ストア３１３は、表形式でデータを保存する機能を提供する。

図４は、実施例１のユーザ装置と文書処理システムの機能ブロックの例を示す図である。ユーザ装置１０２（１０３）は、ブラウザ部４５１と文書記憶部４５２とを備える。ブラウザ部４５１は、文書処理システム１０１にアクセスして、文書処理システム１０１にリクエスト（要求）すると共に、そのリクエストに対するレスポンスを受け取る。具体的には、ブラウザ部４５１は、文書処理システム１０１に対して、文書記憶部４５２に保存されている文書データの処理要求である文書処理リクエストを送信する。また、ブラウザ部４５１は、文書処理システム１０１に対して処理結果取得リクエストを送信して、処理された文書データを受信する。処理結果取得リクエストは、文書処理システム１０１が処理した文書データの送信を求める要求である。

文書記憶部４５２は、ユーザ装置が例えば記録メディアから読み込んだ文書データ、ブラウザ部４５１が文書サービス４００から受信した処理結果の文書データを保存する。なお、ユーザ装置がＭＦＰである場合には、ユーザ装置が、文書記憶部４５２に保存されている文書を印刷する処理部や、印刷物をスキャンして電子化し文書記憶部４５２に保存する処理部等を備えるようにしてもよい。

図４に示す文書処理システム１０１は、受信処理部４１１、分割処理部４１２、文書処理部４１３、結合処理部４１４、リソース管理部４１５、分割キュー４２１、文書処理キュー４２２、結合キュー４２３を備える。また、文書処理システム１０１は、処理データ記憶部４３１、リクエスト・テーブル４４１、文書処理テーブル４４２を備える。図４に示す文書処理システム１０１の機能は、図３を参照して説明したプラットフォームシステムによって実現される。

分割キュー４２１、文書処理キュー４２２、結合キュー４２３は、処理対象のジョブをメッセージとして格納するキューである。分割キュー４２１は、分割処理部４１２に対応するキューである。文書処理キュー４２２は、文書処理部４１３に対応するキューである。結合キュー４２３は、結合処理部４１４に対応するキューである。

受信処理部４１１は、ユーザ装置が備えるブラウザ部４５１から、文書処理リクエストまたは処理結果取得リクエストを受信する。受信処理部４１１は、図３に示すＷｅｂ Ｒｏｌｅインスタンス３０１１によって実現される。このＷｅｂ Ｒｏｌｅインスタンス３０１１は、ユーザ装置からジョブの処理依頼を受信したことに応じて、上記ジョブに対応するメッセージを記憶手段（キュー）に格納する。具体的には、受信処理部４１１は、文書処理リクエストを受信すると、分割処理部４１２に処理を行わせるために、リクエスト・テーブル４４１、処理データ記憶部４３１に必要な情報を書き込む。また、受信処理部４１１は、分割キュー４２１にリクエストが示すジョブに対応するメッセージを格納する。そして、受信処理部４１１は、リクエスト元に対してリクエストＩＤを返す。このリクエストＩＤは、受信処理部４１１が文書リクエスト毎に割り当てる識別子である。リクエストＩＤは、処理結果取得リクエストにおいて、結果を取得する処理の識別に使用される。受信処理部４１１が処理結果取得リクエストを受信した場合は、そのリクエストに含まれるリクエストＩＤの処理が完了していれば、その処理結果のデータを処理データ記憶部４３１から取得してリクエスト元に返す。すなわち、受信処理部４１１は、ユーザ装置（例えば画像形成装置１０２）からジョブの処理依頼を受信したことに応じて、上記ジョブに対応するメッセージを記憶手段（分割キュー４２１）に格納する要求受信部として機能する。この要求受信部は、要求受信プログラムを実行することにより実現される。

分割処理部４１２、文書処理部４１３、結合処理部４１４は、バックエンド処理部である。バックエンド処理部は、図３のＷｏｒｋｅｒ Ｒｏｌｅインスタンス３０２１によって実現される。バックエンド処理部は、Ｗｅｂ Ｒｏｌｌインスタンス３０１１によるメッセージの格納対象となる記憶手段に対しメッセージの取得要求を定期的に行う。バックエンド処理部は、この記憶手段からメッセージを取得した場合は、該取得したメッセージに基づく処理を行う。バックエンド処理部は、バックエンド処理プログラムを実行することにより実現される。

分割処理部４１２は、受信処理部４１１が受信した処理依頼（文書処理リクエスト）に対応する文書データを分割して分割文書データ（以下、ピースと記述）を生成する分割処理バックエンド処理部として機能する。分割処理部４１２の機能は、図３中のＷｏｒｋｅｒ Ｒｏｌｅインスタンス３０２１によって実現される。分割処理部４１２は、分割キュー４２１からメッセージを取り出し、さらに、リクエスト・テーブル４４１および処理データ記憶部４３１から必要な情報を取得して、処理対象となる文書データに対して分割処理を行う。そして、分割処理結果であるピースを文書処理部４１３に処理させるために、リクエスト・テーブル４４１、文書処理テーブル４４２、処理データ記憶部４３１、文書処理キュー４２２に必要な情報を書き込む。

文書処理部４１３は、ピースを文書処理する文書処理バックエンド処理部として機能する。文書処理部４１３の機能は、図３のＷｏｒｋｅｒ Ｒｏｌｅインスタンス３０２１によって実現される。文書処理部４１３は、文書処理キュー４２２からメッセージを取り出し、さらに、文書処理テーブル４４２および処理データ記憶部４３１から必要な情報を取得して、ピースに対して処理を実行する。そして、ピースに対する処理結果のデータ（以下、処理済みピースと呼ぶ）を結合処理部４１４に処理させるために、文書処理テーブル４４２および処理データ記憶部４３１に必要な情報を書き込む。なお、文書処理部４１３は、ピースを複数のインスタンスで一斉に処理することを想定している。従って、文書処理部４１３に対しては、通常、他の処理部よりも多くのインスタンスが割り当てられる。

結合処理部４１４は、文書処理された分割文書データすなわち処理済みピースを結合する結合処理バックエンド処理部として機能する。結合処理部４１４の機能は、図３中のＷｏｒｋｅｒ Ｒｏｌｅインスタンス３０２１によって実現される。結合処理部４１４は、結合キュー４２３からメッセージを取り出すと共に、リクエスト・テーブル４４１、文書処理テーブル４４２、処理データ記憶部４３１から必要な情報を取得する。そして、結合処理部４１４は、処理済みピースを、順番どおり１つに結合する処理を行う。また、結合処理部４１４は、結合結果を処理データ記憶部４３１に保存すると共に、リクエスト・テーブル４４１の内容を更新する。

リソース管理部４１５は、分割処理部４１２、文書処理部４１３、または結合処理部４１４の夫々の処理状況に応じて、該夫々の処理部（バックエンド処理部）の数を増減させる管理部として機能する。リソース管理部４１５の機能は、図３中のＷｏｒｋｅｒ Ｒｏｌｅインスタンス３０２１によって実現される。具体的には、リソース管理部４１５は、予め決められた時間間隔で、分割キュー４２１、文書処理キュー４２２、結合キュー４２３のそれぞれに格納されている未処理のメッセージ数（ジョブの数）またはキューへのメッセージの格納時間を監視する。リソース管理部４１５は、当該監視結果に応じて、分割処理部４１２、文書処理部４１３、又は結合処理部４１４に割り当てられているインスタンスの数を増減させる。すなわち、リソース管理部４１５は、キューに格納されているジョブの数、または該キューへのジョブの格納時間に基づいて、該キューに対応する処理部の数を増減させる。具体的には、リソース管理部４１５は、キューに格納されているジョブの数が所定の閾値以下（例えば０以下）である場合に、該キューに対応する処理部の数を減少させる。また、リソース管理部４１５は、キューに格納されているジョブの数が所定の閾値を超える場合に、該キューに対応する処理部の数を増加させる。リソース管理部４１５が、キューへのジョブの格納時間が所定の閾値以上であるかを判断し、該判断結果に基づいて、該キューに対応する処理部の数を減少させるかまたは増加させるかを決定するようにしてもよい。

分割キュー４２１、文書処理キュー４２２、結合キュー４２３は、図３中のキュー・サービス３１１上に実装される。分割キュー４２１は、受信処理部４１１から分割処理部４１２に処理を受け渡すために利用される。キューに入れられるメッセージは、リクエストＩＤを含む。リクエストＩＤは、リクエスト・テーブル４４１から情報を取り出すために用いられる。文書処理キュー４２２は、分割処理部４１２から文書処理部４１３に処理を受け渡すのに利用される。キューに入れられるメッセージは、リクエストＩＤおよびピース番号を含む。このリクエストＩＤ及びピース番号は、文書処理テーブル４４２から情報を取り出すために用いられる。結合キュー４２３は、分割処理部４１２が分割処理を行ったことを結合処理部４１４に伝達するために使用される。この伝達により、結合処理部４１４は、ピースに対する処理が完了したかを確認できる。結合キュー４２３に入れられるメッセージは、リクエストＩＤを含む。このリクエストＩＤは、後述するステータスを確認するために用いられる。

処理データ記憶部４３１の機能は、図３中のブロブ・ストア３１２によって実現される。処理データ記憶部４３１は、受信処理部４１１が受け取った文書データや、分割処理部４１２が分割したデータ（ピース）、文書処理部４１３が処理したデータ（処理済みピース）、結合処理部４１４が結合したデータを保存する。リクエスト・テーブル４４１は、図３中のテーブル・ストア３１３上に実装される。リクエスト・テーブル４４１は、受信処理部４１１が受信した文書処理リクエストの情報を保持する。文書処理テーブル４４２は、テーブル・ストア３１３上に実装される。文書処理テーブル４４２は、分割処理部４１２による文書データの分割処理状況を示す情報を保持する。

図５は、リクエスト・テーブルと文書処理テーブルの例を示す図である。図５（Ａ）は、リクエスト・テーブル４４１の例を示す。リクエスト・テーブル４４１は、リクエストＩＤ、文書データＵＲＩ（Uniform Resource Identifier ）、ステータス、ピース数といったデータ項目を有する。リクエストＩＤは、受信処理部４１１が受信した文書処理リクエストを一意に識別するための識別子である。受信処理部４１１がリクエストＩＤを発行する。文書データＵＲＩは、受信処理部４１１が受信した文書処理リクエストに含まれている文書データの、処理データ記憶部４３１上での保存場所を示す。ステータスは、文書処理リクエストが、文書処理システム上でどのような処理状態にあるかを示す。ステータスの初期値は「分割前」であり、分割処理部４１２が分割処理を行うと分割処理部４１２によって「分割済み」に更新される。結合処理部４１４が分割データの処理結果を結合すると、ステータスの値が「完了」に更新される。ピース数は、分割処理部４１２が文書データを何個のデータに分割したかを示す。ピース数の値は、分割処理部４１２が分割処理を行った際に、分割処理部４１２によって書き込まれる。

図５（Ｂ）は、文書処理テーブル４４２の例である。文書処理テーブル４４２は、リクエストＩＤ、ピース番号、ピースＵＲＩ、ステータスといった項目を持つ。リクエストＩＤは、リクエスト・テーブル４４１の同名の項目と親子関係にあり、分割処理対象のリクエストを示す。ピース番号は、分割処理部４１２がピースに対して順番に割り当てる自然数である。文書処理テーブル４４２の各レコードは、リクエストＩＤおよびピース番号によって一意に識別される。ピースＵＲＩは、処理データ記憶部４３１上におけるピースの保存場所を示す。文書処理部４１３は、ピースに対して処理を実行した後に、ピースＵＲＩが示すデータを処理済みピースに上書き更新する。ステータスは、ピースに対する文書処理部４１３の処理が完了しているか否かを示す。ステータスの初期値は、「未完」であり、文書処理部４１３によって処理が完了すると、文書処理部４１３によって「完了」に更新される。

図６は、実施例１の文書処理システムが備える受信処理部の動作処理を説明するフローチャートである。図６のフローチャートに示す各ステップの処理は、文書処理システム１０１が備えるサーバ群のＣＰＵ２１１がＷｅｂ Ｒｏｌｅインスタンス３０１１を稼動させて制御プログラムを実行することにより実現される。

まず、受信処理部４１１が、文書処理リクエストを受信したかを判断する（ステップＳ１）。受信処理部４１１が、文書処理リクエストを受信したと判断した場合は、ステップＳ２に進む。受信処理部４１１が、文書処理リクエストを受信していないと判断した場合は、ステップＳ７に進む。

次に、受信処理部４１１が、受信したリクエストを一意に識別するリクエストＩＤを発行する（ステップＳ２）。続いて、受信処理部４１１が、文書処理リクエストに含まれる処理対象となる文書データを、処理データ記憶部４３１に保存する（ステップＳ３）。保存時に指定するＵＲＩ（文書データＵＲＩ）は、リクエストＩＤに対応付けられる。次に、受信処理部４１１が、リクエスト・テーブル４４１にレコード（１行分のデータ）を挿入する（ステップＳ４）。レコードの各項目のうち、リクエストＩＤの値は、ステップＳ２で発行されたリクエストＩＤである。文書データＵＲＩの値は、ステップＳ３でリクエストＩＤに対応付けられたＵＲＩである。ステータスの値は、「分割前」である。ピース数はこの時点では空である。

次に、受信処理部４１１が、分割処理部４１２に処理を受け渡すために、分割キュー４２１にメッセージを投入する（ステップＳ５）。分割処理部４１２が、処理に必要な情報にアクセスできるように、メッセージにはリクエストＩＤを入れる。続いて、受信処理部４１１が、文書処理リクエストの送信元に対して、発行したリクエストＩＤを返送し（ステップＳ６）、ステップＳ１に戻る。文書処理リクエストの送信元は、返送されたリクエストＩＤを用いることで、処理結果を取得するためのリクエスト（処理結果取得リクエスト）を、文書処理システム１０１に対して送信することができる。

ステップＳ７においては、受信処理部４１１が、処理結果取得リクエストを受信したかを判断する（ステップＳ７）。受信処理部４１１が、処理結果取得リクエストを受信していないと判断した場合は、ステップＳ１に戻る。受信処理部４１１が、処理結果取得リクエストを受信したと判断した場合は、受信処理部４１１が、処理結果取得リクエストに含まれるリクエストＩＤを抽出する。そして、受信処理部４１１が、リクエスト・テーブル４４１の当該リクエストＩＤに対応するレコードのステータスを確認し、対象リクエストの処理が完了しているかを判断する（ステップＳ８）。ステータスが「完了」である場合、受信処理部４１１が、対象リクエストの処理が完了していると判断して、ステップＳ９に進む。ステータスが「完了」でない場合、受信処理部４１１が、対象リクエストの処理が完了していないと判断して、ステップＳ１０に進む。

次に、受信処理部４１１が、リクエスト・テーブル４４１の当該リクエストＩＤに対応するレコードに含まれる文書データＵＲＩに基づいて、処理データ記憶部４３１から処理結果のデータを取り出す。そして、受信処理部４１１が、処理結果のデータを処理結果取得リクエストのリクエスト元に返送し（ステップＳ９）、ステップＳ１に戻る。ステップＳ１０においては、受信処理部４１１が、処理結果取得リクエストのリクエスト元に、処理中であることを示すメッセージを返送し（ステップＳ１０）、ステップＳ１に戻る。

図７は、実施例１の文書処理システムが備える分割処理部の動作処理を説明するフローチャートである。図７のフローチャートに示す各ステップの処理は、文書処理システム１０１が備えるサーバ群のＣＰＵ２１１がＷｏｒｋｅｒ Ｒｏｌｅインスタンス３０２１を稼動させて制御プログラムを実行することにより実現される。

まず、分割処理部４１２が、分割キュー４２１にメッセージがあるかを判断する（ステップＳ２１）。分割処理部４１２が、分割キュー４２１にメッセージがないと判断した場合は、ステップＳ２１に戻る。分割処理部４１２が、分割キュー４２１にメッセージがあると判断した場合は、分割処理部４１２が、分割キュー４２１からメッセージを一つ取得する（ステップＳ２２）。そして、分割処理部４１２が、メッセージに含まれるリクエストＩＤを処理対象のリクエストに対応するリクエストＩＤとして抽出する。

次に、分割処理部４１２が、抽出したリクエストＩＤに基づいて、リクエスト・テーブル４４１および処理データ記憶部４３１から、文書データを含む分割処理に必要な情報を取得する。そして、取得した情報に基づき、文書データをピースに分割する（ステップＳ２３）。本実施例では、分割処理部４１２は、文書データを予め定められたデータ単位（例えばページ毎）に分割するものとする。

次に、分割処理部４１２が、ピースを処理データ記憶部４３１に保存する（ステップＳ２４）。ステップＳ２４においては、分割処理部４１２は、各ピースに対して１から順番に番号（ピース番号）を割り当てる。そして、分割処理部４１２が、例えばリクエストＩＤとピース番号とを組み合わせてピースを識別する一意のＵＲＩ（ピースＵＲＩ）を生成し、生成したＵＲＩを各ピースの保存場所として指定する。

次に、分割処理部４１２が、文書処理テーブル４４２にレコードを挿入する（ステップＳ２５）。レコードのデータ項目のうち、リクエストＩＤの値は、ステップＳ２２で抽出されたリクエストＩＤである。ピース番号は、ステップＳ２４においてピースに対して割り当てられた番号である。ピースＵＲＩの値は、ステップＳ２４で生成されたＵＲＩである。ステータスの値は、「未完」である。

次に、分割処理部４１２が、リクエスト・テーブル４４１における処理対象のリクエストに対応するリクエストＩＤを持つレコードを更新する。具体的には、当該レコードのステータスを「分割済み」に変更し、ピース数に、文書データを何個のピースに分割したかを書き込む。続いて、分割処理部４１２が、文書処理部４１３に処理を受け渡すため、ピースに対応する、ピースと同数のメッセージを文書処理キュー４２２に投入する（ステップＳ２７）。文書処理部４１３が処理に必要な情報にアクセスできるように、分割処理部４１２は、メッセージにリクエストＩＤとピース番号を入れる。

次に、分割処理部４１２が、結合処理部４１４に処理を受け渡すため、結合キュー４２３にメッセージを投入する（ステップＳ２８）。結合処理部４１４が処理に必要な情報にアクセスできるように、分割処理部４１２は、メッセージにリクエストＩＤを入れる。そして、処理がステップＳ２１に戻る。

図８は、実施例１の文書処理システムが備える文書処理部の動作処理を説明するフローチャートである。図８のフローチャートに示す各ステップの処理は、文書処理システム１０１が備えるサーバ群のＣＰＵ２１１がＷｏｒｋｅｒ Ｒｏｌｅインスタンス３０２１を稼動させて制御プログラムを実行することにより実現される。

まず、文書処理部４１３が、文書処理キュー４２２にメッセージがあるかを判断する（ステップＳ３１）。文書処理部４１３が、文書処理キュー４２２にメッセージがないと判断した場合は、ステップＳ３１に戻る。文書処理部４１３が、文書処理キュー４２２にメッセージがあると判断した場合は、文書処理部４１３が、文書処理キュー４２２からメッセージを一つ取得し（ステップＳ３２）、メッセージに含まれるリクエストＩＤとピース番号を抽出する。

次に、文書処理部４１３が、抽出したリクエストＩＤとピース番号に基づき、文書処理テーブル４４２、処理データ記憶部４３１から、ピースを含む処理に必要な情報を取得する。そして、取得した情報に基づき、ピースに対して所定の処理を実行する（ステップＳ３３）。続いて、文書処理部４１３が、処理結果のデータ（処理済みピース）を、処理前のデータが保存されていたピースＵＲＩに上書き保存する（ステップＳ３４）。そして、文書処理部４１３が、処理対象のピースに対応する、文書処理テーブル４４２のレコードを更新する（ステップＳ３５）。具体的には、当該レコードのステータスを「完了」に変更する。そして、処理がステップＳ３１に戻る。

図９は、実施例１の文書処理システムが備える結合処理部の動作処理を説明するフローチャートである。図９のフローチャートに示す各ステップの処理は、文書処理システム１０１が備えるサーバ群のＣＰＵ２１１がＷｏｒｋｅｒ Ｒｏｌｅインスタンス３０２１を稼動させて制御プログラムを実行することにより実現される。

まず、結合処理部４１４が、結合キュー４２３にメッセージがあるかを判断する（ステップＳ４１）。結合処理部４１４が、結合キュー４２３にメッセージがないと判断した場合は、ステップＳ４１に戻る。結合処理部４１４が、結合キュー４２３にメッセージがあると判断した場合、結合処理部４１４が、結合キュー４２３からメッセージを一つ取得し（ステップＳ４２）、メッセージに含まれるリクエストＩＤを抽出する。

次に、結合処理部４１４が、抽出したリクエストＩＤに基づき、文書処理テーブル４４２の当該リクエストＩＤを持つ全レコード（対象レコード）のステータスが「完了」となっているかを判断する（ステップＳ４３）。結合処理部４１４が、対象レコードのうち、ステータスが「完了」となっていないレコードがあると判断した場合は、ステップＳ４３に戻る。結合処理部４１４が、対象レコードのステータスが「完了」となっていると判断した場合は、以下の処理を行う。結合処理部４１４は、上記ステップＳ４２において抽出したリクエストＩＤに対応するピース番号を文書処理テーブル４４２から抽出する。結合処理部４１４は、抽出したピース番号に対応するピース（処理済みピース）を処理データ記憶部４３１から取得し、ピース番号順に結合する（ステップＳ４４）。

次に、結合処理部４１４が、結合したデータを、リクエスト・テーブル４４１における当該リクエストＩＤに対応する文書データＵＲＩに上書き保存する（ステップＳ４５）。そして、結合処理部４１４が、リクエスト・テーブル４４１における、上記リクエストＩＤに対応するレコードに含まれるステータスを「完了」に更新し（ステップＳ４６）、ステップＳ４１に戻る。

図１０は、実施例１の文書処理システムが備えるリソース管理部の動作処理を説明するフローチャートである。図１０のフローチャートに示す各ステップの処理は、文書処理システム１０１が備えるサーバ群のＣＰＵ２１１がＷｏｒｋｅｒ Ｒｏｌｅインスタンス３０２１を稼動させて制御プログラムを実行することにより実現される。

まず、リソース管理部４１５が、予め定められた監視間隔時間待機する。監視間隔時間経過後、リソース管理部４１５が、分割キュー４２１、文書処理キュー４２２、結合キュー４２３のそれぞれに入っている未処理のメッセージ数を取得する（ステップＳ５１）。リソース管理部４１５は、所定の取得回数分のメッセージ数をキュー毎に記憶する。続いて、リソース管理部４１５が、所定の取得回数の間、メッセージ数が０であったキューがあるかを判断する（ステップＳ５２）。

所定の取得回数の間、メッセージ数が０であったキューがない場合は、ステップＳ５６に進む。所定の取得回数の間、メッセージ数が０であったキューがある場合は、リソース管理部４１５が、所定の取得回数の間、メッセージ数が０であったキューに対応する処理部のインスタンス数をファブリック・コントローラ３０３から取得する（ステップＳ５３）。具体的には、リソース管理部４１５は、メッセージ数が０であったキューが分割キュー４２１の場合は分割処理部４１２のインスタンス数を取得する。リソース管理部４１５は、メッセージ数が０であったキューが文書処理キュー４２２の場合は文書処理部４１３のインスタンス数を取得する。また、リソース管理部４１５は、メッセージ数が０であったキューが結合キュー４２３の場合は結合処理部４１４のインスタンス数を取得する。なお、上記ステップＳ５２において、所定取得回数の間、メッセージ数が０であったと判断されたキューが複数あった場合は、リソース管理部４１５は、メッセージ数が０であったと判断されたキューの数に応じてインスタンス数を複数取得する。

次に、リソース管理部４１５が、ステップＳ５３において取得されたインスタンス数が２以上であるかを判断する（ステップＳ５４）。ステップＳ５３において取得されたインスタンス数が２以上でない場合は、ステップＳ５６に進む。ステップＳ５３において取得されたインスタンス数が２以上である場合は、ステップＳ５５に進む。続いて、リソース管理部４１５が、ファブリック・コントローラ３０３に対して、インスタンス数が２以上あると判断された全ての処理部のインスタンスを１に削減するように指示する（ステップＳ５５）。

次に、リソース管理部４１５が、所定取得回数の間、メッセージ数が１以上であったキューがあるかを判断する（ステップＳ５６）。所定取得回数の間、メッセージ数が１以上であったキューがない場合は、ステップＳ５１に戻る。所定取得回数の間、メッセージ数が１以上であったキューがある場合は、リソース管理部４１５が、各処理部のインスタンス数をファブリック・コントローラ３０３から取得する（ステップＳ５７）。

続いて、リソース管理部４１５が、起動可能なインスタンス数に余裕があるかを判断する（ステップＳ５８）。具体的には、リソース管理部４１５が、ステップＳ５７において取得した各処理部のインスタンス数の合計が、処理部全体で起動可能なインスタンス数より少ないかを判断する。各処理部のインスタンス数の合計が、処理部全体で起動可能なインスタンス数より少なくない場合は、リソース管理部４１５が、起動可能なインスタンス数に余裕がないと判断して、ステップＳ５１に戻る。各処理部のインスタンス数の合計が、処理部全体で起動可能なインスタンス数より少ない場合、リソース管理部４１５が、起動可能なインスタンス数に余裕があると判断して、ステップＳ５９に進む。そして、リソース管理部４１５が、ステップＳ５６において所定取得回数の間、メッセージ数が１以上であったと判断されたキューに対応する処理部のインスタンスを一つ増加させるように、ファブリック・コントローラ３０３に指示する（ステップＳ５９）。そして、処理がステップＳ５１に戻る。

実施例１の文書処理システムによれば、予め定められた、文書処理システム内で起動可能なインスタンス数の範囲で、各処理部の遅滞状況や遊休状況に応じて、各処理部のインスタンスを増減することができる。これにより、無駄にインスタンス数を多く起動してしまうことを避けながら、効率良くインスタンスを配分させることが可能となる。従って、起動しているＶＭのインスタンス数に応じた課金形態のクラウド環境を利用する際には特に有益である。

なお、本実施例では、リソース管理部４１５の処理をＷｏｒｋｅｒ Ｒｏｌｅインスタンス３０２１が実行するが、リソース管理部４１５の処理をＷｅｂ Ｒｏｌｅインスタンス３０１１が実行するようにしてもよい。この場合、リソース管理部４１５が、図３に示すプラットフォームシステムの外部のプログラムから一定間隔で監視用のリクエストを受信することで、図１０に示すフローチャートの動作を実現することができる。このリソース管理部４１５の機能は、管理ＶＭ３０７に持たせても良いし、ＶＭ３０１に持たせても良い。

また、図１０のステップＳ５５におけるインスタンスの削減数やステップＳ５９におけるインスタンスの増加数を、起動しているインスタンス数などに応じて可変にしてもよい。また、インスタンス増減の条件として、メッセージがキューに格納されている期間または時間を用いてもよい（後述する実施例２乃至５においても同様である）。また、各処理部はキューにメッセージを入れるタイミングについても、上述したタイミングでなくてもよい。例えば、分割処理部４１２が分割直後に結合キュー４２３にメッセージを入れるのではなく、各ピースの処理が完了した（文書処理テーブル４４２の各ピースのステータスが完了となった）時点で、結合キュー４２３にメッセージを入れるようにしてもよい。この場合、結合処理部４１４は、結合キュー４２３からメッセージを取り出した後、即座に結合処理を開始する。

また、各キューに入れるメッセージの内容についても、リクエスト・テーブル４４１や文書処理テーブル４４２の内容を、より多く含めるようにしてもよい。これにより、キューを取得した処理部によるテーブル参照の処理を削減することができる。また、各インスタンスが、複数の処理部の機能を実行するようにしてもよい。例えば、受信処理部４１１が分割処理部４１２の役割を果たしてもよい。この場合、分割キュー４２１を不要とすることができる。また、文書データのデータ量に応じて、分割処理部４１２が文書データを分割しないようにしてもよい。

また、処理の設定情報をリクエスト・テーブル４４１に持っていてもよい。その場合、文書処理部４１３がリクエスト・テーブル４４１にアクセスしてその情報を参照し、自身の処理に反映する。また、結合処理部４１４による処理データ記憶部４３１への上書き保存は、エラー時のデータ消失を避けるために、別名保存でもよい。その場合、テーブルに結果データＵＲＩの項目を持つことで、結果データを受け渡すことが可能となる。

また、処理部が、テーブルのレコードを削除するようにしても良い。例えば、文書処理テーブル４４２のレコードについては、結合処理部４１４が結合処理を完了した後で結合したデータに関連するレコードを削除してもよい。また、定期的に起動するバッチ処理を用意し、その中で、所定の処理部が、リクエスト・テーブル４４１のステータスが完了となっているリクエストＩＤを持つレコードを削除するようにしてもよい。これにより、保存しているデータ量に応じた課金形態のクラウド環境を利用する際のコストを削減することができる。

次に、本発明の第２の実施例について説明する。実施例２では、分割処理部４１２の動作のみが実施例１と異なる。従って、以下では分割処理部４１２の動作についてのみ説明する。実施例２の文書処理システムが備える分割処理部４１２は、稼動している文書処理部４１３のインスタンスの数や文書処理キューのメッセージ残数に応じて、分割サイズ、分割個数を決定する。

図１１は、実施例２の文書処理システムが備える分割処理部の動作処理を説明するフローチャートである。図１１のステップＳ６１、Ｓ６２は、図７のステップＳ２１、Ｓ２２と同様である。また、図１１のステップＳ６９乃至Ｓ７３は、図７のステップＳ２４乃至Ｓ２８と同様である。

実施例２では、ステップＳ６３において、分割処理部４１２が、リクエスト・テーブル４４１および処理データ記憶部４３１から、文書データを含む分割処理に必要な情報を取得する（ステップＳ６３）。続いて、分割処理部４１２が、図３に示すプラットフォームシステムのファブリック・コントローラ３０３から、文書処理部４１３として稼動しているＷｏｒｋｅｒ Ｒｏｌｅインスタンスの数を取得する（ステップＳ６４）。分割処理部４１２が、分割キュー４２１と文書処理キュー４２２に入っているメッセージのうち、未処理のメッセージの数を取得する（ステップＳ６５）。

次に、分割処理部４１２が、ステップＳ６５において取得された各キューのメッセージ数が、閾値を超えているかを判断する（ステップＳ６６）。閾値は、予め定義した固定値であってもよいし、ステップＳ６４において取得された文書処理部４１３のＷｏｒｋｅｒ Ｒｏｌｅのインスタンス数に応じて変動するようにしてもよい。いずれかのキューのメッセージ数が閾値を超えていた場合、ステップＳ６７に進む。各キューのメッセージ数が閾値を超えていない場合は、ステップＳ６８に進む。

ステップＳ６７において、分割処理部４１２が、文書データを不均等なサイズで分割し（ステップＳ６７）、ステップＳ６９に進む。具体的には、分割処理部４１２が、ピース数がステップＳ６４において取得された文書処理部４１３のＷｏｒｋｅｒ Ｒｏｌｅのインスタンス数を超えないように、文書データをピースに分割する。分割処理部４１２は、ピースのサイズに差をつける（あるピースは他のピースよりもデータ量が小さくなる）ようにし、文書処理部４１３での処理が短時間で済むようなピースを作る。分割処理部４１２が、文書データを、文書処理部４１３のインスタンス数よりも少ない数に分割するようにしてもよい。ステップＳ６８においては、分割処理部４１２が、文書データをステップＳ６４において取得された文書処理部４１３のＷｏｒｋｅｒ Ｒｏｌｅのインスタンス数と同数に均等分割して（ステップＳ６８）、ステップＳ６９に進む。

実施例２の文書処理システムは、キューの状態（すなわち処理の遅滞状況）に応じてピースのデータサイズを不均等にすることで、あるリクエストの処理については、早く処理を終えることのできるインスタンスを生じさせる。これによって、複数のリクエストを早く文書処理開始状態にさせることができるため、特に、短時間で処理できるような文書データのサイズが小さいリクエストの処理の遅滞を軽減することができる。

次に、本発明の実施例３について説明する。実施例３は、実施例１の変形例である。従って、以下では実施例１との違いについて説明する。

図１２は、実施例３の文書処理システムの機能ブロックと、初期インスタンス数管理テーブルの例を示す図である。図１２（Ａ）は、実施例３の文書処理システムの機能ブロックの例を示す。図１２（Ａ）に示す文書処理システム１０４は、図４に示す文書処理システム１０１が備えるリソース管理部４１５に代えて、リソース管理部４１６を備える。また、文書処理システム１０４は、初期インスタンス数管理テーブル４４３を備える。初期インスタンス数管理テーブル４４３は、各処理部のＶＭのタイプ（Ｗｅｂ Ｒｏｌｅか、またはＷｏｒｋｅｒ Ｒｏｌｅ）と、初期インスタンス数の情報を有する。初期インスタンス数は、文書処理システム１０４を開始した直後に起動するインスタンスの数である。

図１２（Ｂ）は、初期インスタンス数管理テーブル４４３の例を示す。初期インスタンス数管理テーブル４４３は、処理部、ＶＭのタイプ、初期インスタンス数といったデータ項目を有する。処理部は、文書処理システム１０４が備える処理部である。ＶＭのタイプは、処理部に割り当てられているＶＭのタイプである。初期インスタンス数は、処理部に対応する初期インスタンス数である。各処理部のインスタンスは、インスタンスが起動した際に、自分の処理部のレコードがあるかどうかを確認し、レコードがない場合は自身の処理部のレコードを生成する。初期インスタンス数は、各々の処理部が所有している設定ファイルに記述されている。各々の処理部のインスタンスは起動時に上記設定情報を読み込んで保持しているものとする。

図１３は、実施例３の文書処理システムが備えるリソース管理部の動作処理を説明するフローチャートである。図１３のステップＳ８１乃至Ｓ８９は、図１０のステップＳ５１乃至５９と同様である。実施例３では、ステップＳ８８における判断処理の結果、リソース管理部４１６が、起動可能なインスタンス数に余裕がないと判断した場合に、以下の処理を行う。リソース管理部４１６は、各処理部の初期インスタンス数を、初期インスタンス数管理テーブル４４３から取得する（ステップＳ９０）。リソース管理部４１６が、ステップＳ８７において取得された各処理部のインスタンス数と、ステップＳ９０において取得された各処理部の初期インスタンス数とを比較して、以下の処理を行う。リソース管理部４１６が、対応するインスタンス数が初期インスタンス数を超えている処理部があるかを判断する（ステップＳ９１）。

対応するインスタンス数が初期インスタンス数を超えている処理部がない場合は、ステップＳ８１に戻る。対応するインスタンス数が初期インスタンス数を超えている処理部がある場合は、ステップＳ９２に進む。そして、リソース管理部４１６が、対応するインスタンス数が初期インスタンス数を超えていると判断された処理部のインスタンスを一つ削減するように、ファブリック・コントローラ３０３に指示して（ステップＳ９２）、ステップＳ８９に進む。なお、ステップＳ９２におけるインスタンスの削減数は、複数であってもよいし、起動しているインスタンス数などに応じて可変であってもよい。

実施例３の文書処理システム１０４によれば、起動可能なインスタンス数がない状況において、初期インスタンス数を超えてインスタンスが起動している処理部のインスタンスを減じて、処理が遅滞している処理部のインスタンスを起動させることができる。これにより、インスタンスが特定の処理部に偏ってしまうことを抑制できる。

次に、本発明の実施例４について説明する。実施例４の文書処理システムは、図１２（Ａ）に示す実施例３の文書処理システムの構成と同様の構成を有する。実施例４の文書処理システムは、リソース管理部の動作と初期インスタンス数管理テーブル４４３のデータ構成が実施例３の文書処理システム１０４と異なる。なお、本実施例では、ＶＭの種類は、ＶＭの性能に応じて異なる低性能ＶＭと高性能ＶＭという２種類があるものとする。

図１４は、実施例３における初期インスタンス数管理テーブルの例を示す図である。図１４に示す初期インスタンス数管理テーブル４４３は、図１２（Ｂ）に示す初期インスタンス数管理テーブル４４３が有するデータ項目に加えて、性能というデータ項目を有する。性能は、ＶＭの性能が低性能であるか、または高性能であるかを示す。

図１５は、実施例４の文書処理システムが備えるリソース管理部の動作処理を説明するフローチャートである。図１５のステップＳ１０１乃至Ｓ１０４は、図１３のステップＳ８１乃至Ｓ８４と同様である。実施例４では、リソース管理部４１６が、ファブリック・コントローラ３０３に対して、インスタンス数が２以上あると判断された全ての処理部（ステップＳ１０４を参照）のインスタンス数の削減を指示する。本実施例では、リソース管理部４１６が、高性能ＶＭのインスタンス数を０、低性能ＶＭのインスタンス数を１に削減するように指示する（ステップＳ１０５）。

次に、リソース管理部４１６が、所定の取得回数の間、メッセージ数が１以上であったキューがあるかを判断する（ステップＳ１０６）。所定の取得回数の間、メッセージ数が１以上であったキューがない場合は、ステップＳ１０１に戻る。所定の取得回数の間、メッセージ数が１以上であったキューがある場合は、ステップＳ１０７に進む。続いて、リソース管理部４１６が、全処理部の低性能ＶＭおよび高性能ＶＭのインスタンス数をファブリック・コントローラ３０３から取得する（ステップＳ１０７）。

次に、リソース管理部４１６が、起動可能な低性能ＶＭのインスタンス数に余裕があるかを判断する（ステップＳ１０８）。具体的には、リソース管理部４１６が、ステップＳ１０７で取得された各処理部の低性能ＶＭのインスタンス数の合計が、処理部全体で起動可能な低性能ＶＭインスタンス数より少ないかを判断する。各処理部の低性能ＶＭのインスタンス数の合計が、処理部全体で起動可能な低性能ＶＭインスタンス数より少ない場合、リソース管理部４１６は、起動可能な低性能ＶＭのインスタンス数に余裕があると判断して、ステップＳ１０９に進む。各処理部の低性能ＶＭのインスタンス数の合計が、処理部全体で起動可能な低性能ＶＭインスタンス数より少なくない場合、リソース管理部４１６は、起動可能な低性能ＶＭのインスタンス数に余裕がないと判断して、ステップＳ１１０に進む。

ステップＳ１０９において、リソース管理部４１６が、ファブリック・コントローラ３０３に対して、以下のように指示する。リソース管理部４１６は、所定の取得回数の間、メッセージ数が１以上であったと判断されたキュー（ステップＳ１０６を参照）に対応する処理部の低性能ＶＭのインスタンスを一つ増加させるように指示する。そして、処理がステップＳ１０１に戻る。

ステップＳ１１０においては、リソース管理部４１６が、起動可能な高性能ＶＭのインスタンス数に余裕があるかを判断する（ステップＳ１１０）。具体的には、リソース管理部４１６が、ステップＳ１０７で取得された各処理部の高性能ＶＭのインスタンス数の合計が、処理部全体で起動可能な高性能ＶＭインスタンス数より少ないかを判断する。各処理部の高性能ＶＭのインスタンス数の合計が、処理部全体で起動可能な高性能ＶＭインスタンス数より少ない場合、リソース管理部４１６は、起動可能な高性能ＶＭのインスタンス数に余裕があると判断して、ステップＳ１１１に進む。各処理部の高性能ＶＭのインスタンス数の合計が、処理部全体で起動可能な高性能ＶＭインスタンス数より少なくない場合、リソース管理部４１６は、起動可能な高性能ＶＭのインスタンス数に余裕がないと判断して、ステップＳ１１２に進む。

ステップＳ１１１において、リソース管理部４１６が、ファブリック・コントローラ３０３に対して、以下のように指示する。リソース管理部４１６が、所定の取得回数の間、メッセージ数が１以上であったと判断されたキュー（ステップＳ１０６を参照）に対応する処理部の高性能ＶＭのインスタンスを一つ増加させるように指示する。そして、処理がステップＳ１０１に戻る。

ステップＳ１１２においては、リソース管理部４１６が、各処理部の低性能ＶＭおよび高性能ＶＭの初期インスタンス数を、初期インスタンス数管理テーブル４４３から取得する（ステップＳ１１２）。続いて、リソース管理部４１６が、ステップＳ１０７で取得された各処理部の高性能ＶＭのインスタンス数と、ステップＳ１１２で取得された各処理部の高性能ＶＭの初期インスタンス数とを比較する。そして、リソース管理部４１６が、対応する高性能ＶＭのインスタンス数が、高性能ＶＭの初期インスタンス数を超えている処理部があるかを判断する（ステップＳ１１３）。対応する高性能ＶＭのインスタンス数が、高性能ＶＭの初期インスタンス数を超えている処理部がある場合は、ステップＳ１１４に進む。対応する高性能ＶＭのインスタンス数が、高性能ＶＭの初期インスタンス数を超えている処理部がない場合は、ステップＳ１１５に進む。ステップＳ１１４において、リソース管理部４１６が、ファブリック・コントローラ３０３に対して、以下のように指示する。リソース管理部４１６が、対応する高性能ＶＭのインスタンス数が初期インスタンス数を超えていると判断された処理部（ステップＳ１１３を参照）の高性能ＶＭのインスタンスを一つ削減するように指示する。そして、処理がステップＳ１１１に進む。

ステップＳ１１５においては、リソース管理部４１６が、ステップＳ１０７で取得された各処理部の低性能ＶＭのインスタンス数と、ステップＳ１１２で取得された各処理部の低性能ＶＭの初期インスタンス数とを比較する。そして、リソース管理部４１６が、対応する低性能ＶＭのインスタンス数が、低性能ＶＭの初期インスタンス数を超えている処理部があるかを判断する（ステップＳ１１５）。対応する低性能ＶＭのインスタンス数が、低性能ＶＭの初期インスタンス数を超えている処理部がない場合は、ステップＳ１０１に戻る。対応する低性能ＶＭのインスタンス数が、低性能ＶＭの初期インスタンス数を超えている処理部がある場合は、ステップＳ１１６に進む。そして、リソース管理部４１６が、ファブリック・コントローラ３０３に対して、対応する低性能ＶＭのインスタンス数が初期インスタンス数を超えていると判断された処理部（ステップＳ１１５を参照）の低性能ＶＭのインスタンスを一つ削減するように指示する。そして、処理がステップＳ１０９の処理に進む。

本実施例の文書処理システムは、起動可能なインスタンスの数に余裕がある場合に、低性能ＶＭの起動を優先するようにしている。これは、通常、低性能のＶＭを稼動するほうが安価であることを考慮したためである。ただし、処理速度を重視する場合には、文書処理システムが、高性能ＶＭの起動を優先するようにしてもよい。また、文書処理システムが、キューのメッセージ数の数に応じてどの能力のＶＭを起動するかを判断するようにしてもよい。また、本実施例では、ＶＭの性能が２種類である場合を例にとって説明したが、ＶＭが２以上の種類であってもよい。実施例４の文書処理システムによれば、起動可能な低性能ＶＭのインスタンス数、高性能ＶＭのインスタンス数に余裕があるか否かについての判断結果に基づいて、ＶＭのインスタンス数を増減させることができる。

次に、本発明の実施例５について説明する。実施例５においては、高性能ＶＭは文書処理部４１３でのみ稼動する。また、低性能ＶＭは全処理部で稼動する。すなわち、文書処理部４１３が、第１の処理性能を有する第１文書処理バックエンド処理部（低性能ＶＭ）と、第１の処理性能より処理性能が高い第２の処理性能を有する第２文書処理バックエンド処理部（高性能ＶＭ）とを含む。実施例５では、分割処理部４１２が、ＶＭの能力を考慮して分割処理を行う。

図１６は、実施例５の文書処理システムの機能ブロックと、初期インスタンス数管理テーブルの例を示す図である。図１６（Ａ）は、実施例５の文書処理システム１０５の機能ブロックを示す。文書処理システム１０５は、図１２（Ａ）に示す文書処理システム１０４が備える文書処理キュー４２２に代えて、低性能ＶＭ用文書処理キュー４２２１と、高性能ＶＭ用文書処理キュー４２２２とを備える。低性能ＶＭ用文書処理キュー４２２１は、文書処理部４１３として稼動している低性能ＶＭのインスタンスに対応するキューである。低性能ＶＭ用文書処理キュー４２２１には、この低性能ＶＭのインスタンスに処理させるピースの情報を含むメッセージが格納される。高性能ＶＭ用文書処理キュー４２２２は、文書処理部４１３として稼動している高性能ＶＭのインスタンスに対応するキューである。高性能ＶＭ用文書処理キュー４２２２には、この高性能ＶＭのインスタンスに処理させるピースの情報を含むメッセージが格納される。

図１６（Ｂ）は、文書処理システム１０５が備える初期インスタンス数管理テーブル４４３の例を示す。この初期インスタンス数管理テーブル４４３には、文書処理部４１３に対応するレコード（一行分のデータ）にのみ高性能ＶＭのレコードが存在する。

図１７は、実施例５の文書処理システムが備える分割処理部の動作処理を説明するフローチャートである。図１７（Ａ）のステップＳ１２１乃至Ｓ１２３は、図１１のステップＳ６１乃至Ｓ６３と同様である。実施例５では、図１７（Ａ）のステップＳ１２４において、分割処理部４１２が、文書処理部４１３として稼動しているＷｏｒｋｅｒ Ｒｏｌｅの低性能ＶＭと高性能ＶＭのインスタンス数をファブリック・コントローラ３０３から取得する（ステップＳ１２４）。続いて、分割処理部４１２が、文書データをステップＳ１２４で取得された低性能ＶＭのインスタンス数と同数に分割した場合のピースのサイズを算出する（ステップＳ１２５）。そして、分割処理部４１２が、ステップＳ１２５で算出されたピースのサイズが予め定められた閾値より大きいかを判断する（ステップＳ１２６）。ステップＳ１２５で算出されたピースのサイズが予め定められた閾値より大きい場合、分割処理部４１２が、文書データをステップＳ１２４で取得された高性能ＶＭのインスタンス数と同数のピースに分割する（ステップＳ１２７）。そして、分割処理部４１２が、各ピースに対し、順番にピース番号を割り当てる。

次に、分割処理部４１２が、必要な情報の保存処理を行う（ステップＳ１２８）。必要な情報の保存処理については、図１７（Ｂ）を参照して後述する。続いて、分割処理部４１２が、文書処理部４１３の高性能ＶＭのインスタンスに処理を受け渡すため、ピースに対応する、ピースと同数のメッセージを高性能ＶＭ用文書処理キュー４２２２に投入し（ステップＳ１２９）、ステップＳ１３３に進む。ステップＳ１２９において高性能ＶＭ用文書処理キュー４２２２に投入されるメッセージは、リクエストＩＤとピース番号とを含む。このリクエストＩＤとピース番号は、文書処理部４１３が処理に必要な情報にアクセスするために用いられる。

ステップＳ１２５で算出されたピースのサイズが予め定められた閾値より大きくない場合、分割処理部４１２が、文書データをステップＳ１２４で取得された低性能ＶＭのインスタンス数と同数のピースに分割する（ステップＳ１３０）。そして、分割処理部４１２が、各ピースに対し、順番にピース番号を割り当てる。続いて、分割処理部４１２が、必要な情報の保存処理を行う（ステップＳ１３１）。続いて、分割処理部４１２が、文書処理部４１３の低性能ＶＭのインスタンスに処理を受け渡すため、ピースに対応する、ピースと同数のメッセージを低性能ＶＭ用文書処理キュー４２２１に投入し（ステップＳ１３２）、ステップＳ１３３に進む。ステップＳ１３２において低性能ＶＭ用文書処理キュー４２２１に投入されるメッセージは、リクエストＩＤとピース番号とを含む。このリクエストＩＤとピース番号は、文書処理部４１３が処理に必要な情報にアクセスするために用いられる。

次に、分割処理部４１２が、結合処理部４１４に処理を受け渡すため、結合キュー４２３にメッセージを投入し（ステップＳ１３３）、ステップＳ１２１に戻る。ステップＳ１３３において投入されるメッセージは、リクエストＩＤを含む。このリクエストＩＤは、結合処理部４１４が処理に必要な情報にアクセスするために用いられる。

図１７（Ｂ）は、図１７（Ａ）のステップＳ１２８、Ｓ１３１における必要情報の保存処理を説明するフローチャートである。まず、分割処理部４１２が、ピースを処理データ記憶部４３１に保存する（ステップＳ２０１）。ステップＳ２０１においては、分割処理部４１２は、例えばリクエストＩＤとピース番号とを組み合わせて、各ピースの保存場所を一意に識別するＵＲＩ（ピースＵＲＩ）を生成し、生成したピースＵＲＩを各ピースの保存場所として指定する。

次に、分割処理部４１２が、文書処理テーブル４４２（図５（Ｂ）を参照）にレコードを挿入する（ステップＳ２０２）。分割処理部４１２は、挿入するレコードのリクエストＩＤの項目に、図１７（Ａ）のステップＳ１２２において取得されたメッセージに含まれるリクエストＩＤ（処理対象のリクエストＩＤ）を格納する。また、分割処理部４１２は、挿入するレコードのピース番号の項目に、ステップＳ１２７またはステップＳ１３０において各ピースに対して割り当てたピース番号を格納する。また、分割処理部４１２は、挿入するレコードのピースＵＲＩの項目に、ステップＳ２０１で指定したピースＵＲＩを格納する。また、分割処理部４１２は、挿入するレコードのステータスの項目に、「未完」を格納する。

次に、分割処理部４１２が、リクエスト・テーブル４４１（図５（Ａ）を参照）における処理対象のリクエストＩＤを持つレコードを更新する（ステップＳ２０３）。具体的には、分割処理部４１２は、当該レコードのステータスを「分割済み」に変更し、ピース数に文書データを何個に分割したかを書き込む。実施例５における分割処理部４１２は、ピースのサイズが閾値を超えるか否かに応じて、処理させるＶＭを変更する。これは、サイズが大きいピースを高性能ＶＭで処理させるためである。

図１７（Ａ）、（Ｂ）を参照して説明したように、分割処理部４１２は文書データを第１文書処理バックエンド処理部（低性能ＶＭ）の数に分割した場合に生成される分割文書データ（ピース）のサイズが所定の閾値を超えるかを判断する（ステップＳ１２６）。分割処理部４１２は、該分割文書データのサイズが該閾値を超える場合に、第２文書処理バックエンド処理部（高性能ＶＭ）に対応するキューに、高性能ＶＭの数の分のジョブを格納する（ステップＳ１２９を参照）。分割処理部４１２は、分割文書データのサイズが閾値を超えない場合に、低性能ＶＭに対応するキューに、低性能ＶＭの数の分のジョブを格納する（ステップＳ１３２を参照）。

図１８は、実施例５の文書処理システムが備えるリソース管理部の動作処理を説明するフローチャートである。まず、リソース管理部４１６が、予め定められた監視間隔時間待機する。監視間隔時間経過後、リソース管理部４１６が、分割キュー４２１、低性能ＶＭ用文書処理キュー４２２１、高性能ＶＭ用文書処理キュー４２２２、結合キュー４２３のそれぞれに入っている未処理のメッセージ数を取得する（ステップＳ３０１）。リソース管理部４１６は、所定の取得回数分のメッセージ数をキュー毎に記憶する。続いて、リソース管理部４１６が、所定の取得回数の間、メッセージ数が０であったキューがあるかを判断する（ステップＳ３０２）。所定の取得回数の間、メッセージ数が０であったキューがない場合は、ステップＳ３０６に進む。所定の取得回数の間、メッセージ数が０であったキューがある場合は、リソース管理部４１６が、所定の取得回数の間、メッセージ数が０であったキューに対応する処理部のインスタンス数をファブリック・コントローラ３０３から取得する（ステップＳ３０３）。具体的には、リソース管理部４１６は、メッセージ数が０であったキューが分割キュー４２１の場合は分割処理部４１２のＶＭのインスタンス数を取得する。リソース管理部４１６は、メッセージ数が０であったキューが低性能ＶＭ用文書処理キュー４２２１の場合は文書処理部４１３の低性能ＶＭのインスタンス数を取得する。リソース管理部４１６は、メッセージ数が０であったキューが高性能ＶＭ用文書処理キュー４２２２の場合は文書処理部４１３の高性能ＶＭのインスタンス数を取得する。また、リソース管理部４１６は、メッセージ数が０であったキューが結合キュー４２３の場合は結合処理部４１４のＶＭのインスタンス数を取得する。

次に、リソース管理部４１６が、ステップＳ３０３において取得されたＶＭのインスタンス数が２以上であるかを判断する（ステップＳ３０４）。ステップＳ３０４の判断処理においては、リソース管理部４１６は、文書処理部４１３の低性能ＶＭと高性能ＶＭとを別々のものとして扱う。ステップＳ３０３において取得されたＶＭのインスタンス数が２以上でない場合は、ステップＳ３０６に進む。ステップＳ３０３において取得されたＶＭのインスタンス数が２以上である場合は、ステップＳ３０５に進む。続いて、リソース管理部４１６が、ファブリック・コントローラ３０３に対して、インスタンス数が２以上あると判断されたＶＭのインスタンスを１に削減するように指示する（ステップＳ３０５）。

次に、リソース管理部４１６が、所定取得回数の間、メッセージ数が１以上であったキューがあるかを判断する（ステップＳ３０６）。所定取得回数の間、メッセージ数が１以上であったキューがない場合は、ステップＳ３０１に戻る。所定取得回数の間、メッセージ数が１以上であったキューがある場合は、ステップＳ３０７に進む。

次に、リソース管理部４１６が、所定取得回数の間、メッセージ数が１以上であったと判断されたキュー（ステップＳ３０６を参照）の中に、高性能ＶＭ用文書処理キュー４２２２が含まれるかを判断する（ステップＳ３０７）。所定取得回数の間、メッセージ数が１以上であったと判断されたキューの中に、高性能ＶＭ用文書処理キュー４２２２が含まれる場合は、ステップＳ３１４に進む。所定取得回数の間、メッセージ数が１以上であったと判断されたキューの中に、高性能ＶＭ用文書処理キュー４２２２が含まれない場合は、ステップＳ３０８に進む。

ステップＳ３０８において、リソース管理部４１６が、全処理部の低性能ＶＭのインスタンス数をファブリック・コントローラ３０３から取得する（ステップＳ３０８）。続いて、リソース管理部４１６が、起動可能な低性能ＶＭのインスタンス数に余裕があるかを判断する（ステップＳ３０９）。具体的には、リソース管理部４１６が、ステップＳ３０８において取得した低性能ＶＭのインスタンス数の合計が、処理部全体で起動可能な低性能ＶＭのインスタンス数より少ないかを判断する。取得した低性能ＶＭのインスタンス数の合計が、処理部全体で起動可能な低性能ＶＭのインスタンス数より少なくない場合は、リソース管理部４１６が、起動可能な低性能ＶＭのインスタンス数に余裕がないと判断して、ステップＳ３１０に進む。

取得した低性能ＶＭのインスタンス数の合計が、処理部全体で起動可能な低性能インスタンス数より少ない場合は、リソース管理部４１６が、起動可能な低性能ＶＭのインスタンス数に余裕があると判断して、ステップＳ３１３に進み、以下の処理を行う。リソース管理部４１６が、所定取得回数の間、メッセージ数が１以上であったと判断されたキュー（ステップＳ３０６）に対応する処理部の低性能ＶＭのインスタンスを一つ増加させるように、ファブリック・コントローラ３０３に指示する。そして、処理がステップＳ３０１に戻る。

ステップＳ３１０においては、リソース管理部４１６が、各処理部の低性能ＶＭの初期インスタンス数をファブリック・コントローラ３０３から取得する（ステップＳ３１０）。続いて、リソース管理部４１６が、ステップＳ３０８で取得された各処理部の低性能ＶＭのインスタンス数と、ステップＳ３１０で取得された各処理部の低性能ＶＭの初期インスタンス数とを比較する。そして、リソース管理部４１６が、対応する低性能ＶＭのインスタンス数が、低性能ＶＭの初期インスタンス数を超えている処理部があるかを判断する（ステップＳ３１１）。対応する低性能ＶＭのインスタンス数が、低性能ＶＭの初期インスタンス数を超えている処理部がない場合は、ステップＳ３０１に進む。対応する低性能ＶＭのインスタンス数が、低性能ＶＭの初期インスタンス数を超えている処理部がある場合は、ステップＳ３１２に進む。リソース管理部４１６が、ファブリック・コントローラ３０３に対して、対応する低性能ＶＭのインスタンス数が低性能ＶＭの初期インスタンス数を超えている処理部の低性能ＶＭのインスタンスを一つ削減するように指示する（ステップＳ３１２）。そして、処理がステップＳ３１３に進む。

ステップＳ３１４においては、リソース管理部４１６が、文書処理部４１３の高性能ＶＭのインスタンス数の調節処理を行う（ステップＳ３１４）。そして、リソース管理部４１７が、所定取得回数の間、メッセージ数が１以上であったキュー（ステップＳ３０６を参照）の中に、高性能ＶＭ用文書処理キュー４２２２以外のキューが含まれるかを判断する（ステップＳ３１５）。所定取得回数の間、メッセージ数が１以上であったキューの中に、高性能ＶＭ用文書処理キュー４２２２以外のキューが含まれる場合は、ステップＳ３０８に進む。所定取得回数の間、メッセージ数が１以上であったキューの中に、高性能ＶＭ用文書処理キュー４２２２以外のキューが含まれない場合は、ステップＳ３０１に戻る。

図１９は、図１８のステップＳ３１４における文書処理部の高性能ＶＭのインスタンス数の調節処理を説明するフローチャートである。まず、リソース管理部４１６が、文書処理部４１３の高性能ＶＭのインスタンス数をファブリック・コントローラ３０３から取得する（ステップＳ４０１）。続いて、リソース管理部４１６が、起動可能な高性能ＶＭのインスタンス数に余裕があるかを判断する（ステップＳ４０２）。具体的には、リソース管理部４１６が、ステップＳ４０１で取得された高性能ＶＭのインスタンス数が、起動可能な高性能ＶＭのインスタンス数より少ないかを判断する。取得された高性能ＶＭのインスタンス数が、起動可能な高性能ＶＭのインスタンス数より少ない場合、リソース管理部４１６が、起動可能な高性能ＶＭのインスタンス数に余裕があると判断して、ステップＳ４０３に進む。取得された高性能ＶＭのインスタンス数が、起動可能な高性能ＶＭのインスタンス数より少なくない場合、リソース管理部４１６が、起動可能な高性能ＶＭのインスタンス数に余裕がないと判断して、ステップＳ４０４に進む。

ステップＳ４０３において、リソース管理部４１６が、ファブリック・コントローラ３０３に対して、文書処理部４１３の高性能ＶＭのインスタンス数を一つ増加するように指示して（ステップＳ４０３）、処理を終了する。ステップＳ４０４においては、リソース管理部４１６が、全処理部の低性能ＶＭのインスタンス数と、処理部全体で起動可能な低性能ＶＭのインスタンス数とを、ファブリック・コントローラ３０３から取得する（ステップＳ４０４）。続いて、リソース管理部４１６が、未起動の低性能ＶＭを振替えて高性能ＶＭを起動可能であるかを判断する（ステップＳ４０５）。具体的には、リソース管理部４１６が、処理部全体で起動可能な低性能ＶＭのインスタンス数から、ステップＳ４０４で取得された全処理部の低性能ＶＭのインスタンス数を引いた結果得られる低性能ＶＭのインスタンス数の値を第１の基準値として算出する。そして、リソース管理部４１６が、予め決められた高性能ＶＭのインスタンスに対して要求されるコスト（例えば料金）と、予め決められた低性能ＶＭに対して要求されるコストと、第１の基準値とに基づいて、以下の処理を行う。リソース管理部４１６が、第１の基準値が高性能ＶＭのインスタンスを起動するのに必要な低性能ＶＭのインスタンス数以上であるかを判断する。第１の基準値が高性能ＶＭのインスタンスを起動するのに必要な低性能ＶＭのインスタンス数以上でない場合、リソース管理部４１６が、未起動の低性能ＶＭを振替えて高性能ＶＭを起動可能でないと判断して、ステップＳ４０７に進む。第１の基準値が高性能ＶＭのインスタンスを起動するのに必要な低性能ＶＭのインスタンス数以上である場合、リソース管理部４１６が、未起動の低性能ＶＭを振替えて高性能ＶＭを起動可能であると判断して、ステップＳ４０６に進む。

ステップＳ４０６において、リソース管理部４１６が、ファブリック・コントローラ３０３に対して、起動可能な高性能ＶＭのインスタンス数を一つ増やすように指示し（ステップＳ４０６）、ステップＳ４０３に進む。ステップＳ４０６においては、リソース管理部４１６は、更に、増やす高性能ＶＭのインスタンスの数に応じた数だけ起動可能な低性能ＶＭのインスタンスを削減するように指示する。

ステップＳ４０７においては、リソース管理部４１６が、各処理部の低性能ＶＭの初期インスタンス数をファブリック・コントローラ３０３から取得する（ステップＳ４０７）。続いて、リソース管理部４１６が、初期インスタンス数を超過して起動している低性能ＶＭのインスタンスを振替えて高性能ＶＭのインスタンスを起動できるかを判断する（ステップＳ４０８）。具体的には、リソース管理部４１６が、各々の処理部について、初期インスタンスを超過して起動している低性能ＶＭのインスタンスの数を算出する。リソース管理部４１６が、各々の処理部について算出した上記低性能ＶＭのインスタンスの数の合計値を算出する。また、リソース管理部４１６が、算出された低性能ＶＭのインスタンスの数の合計値と、未起動の低性能ＶＭインスタンス数とを足し合わせた値を第２の基準値として算出する。そして、リソース管理部４１６が、第２の基準値が高性能ＶＭのインスタンスを起動するのに必要な低性能ＶＭのインスタンス数以上であるかを判断する。

第２の基準値が高性能ＶＭのインスタンスを起動するのに必要な低性能ＶＭのインスタンス数以上である場合、リソース管理部４１６が、以下の処理を行う。リソース管理部４１６が、初期インスタンス数を超過して起動している低性能ＶＭのインスタンスを振替えて高性能ＶＭのインスタンスを起動できると判断し、ステップＳ４０９に進む。第２の基準値が高性能ＶＭのインスタンスを起動するのに必要な低性能ＶＭのインスタンス数以上でない場合、リソース管理部４１６が、以下の処理を行う。リソース管理部４１６が、初期インスタンス数を超過して起動している低性能ＶＭのインスタンスを振替えて高性能ＶＭのインスタンスを起動できないと判断し、処理を終了する。

ステップＳ４０９において、リソース管理部４１６が、ファブリック・コントローラ３０３に対して、初期インスタンス数を最も多く超過している低性能ＶＭインスタンスに対応する処理部を特定する。リソース管理部４１６が、ファブリック・コントローラ３０３に対して、起動可能な高性能ＶＭのインスタンス数を一つ増やし、増やした分に対応する低性能ＶＭインスタンスの数だけ上記特定した処理部の低性能ＶＭインスタンスを停止するように指示する。リソース管理部４１６は、停止した低性能ＶＭのインスタンスの数と上記第１の基準値とを足し合わせて得られる値が、高性能ＶＭのインスタンスを起動するのに必要な低性能ＶＭのインスタンス数になるまで指示を繰り返す。そして、処理がステップＳ４０３に進む。

なお、実施例５では、文書処理部４１３についてのみ、性能差があるＶＭを持たせたが、分割処理部４１２や結合処理部４１４についても、性能差があるＶＭを持たせてもよい。分割処理部４１２や結合処理部４１４について性能差があるＶＭを持たせる場合には、キュー（分割キュー４２１や結合キュー４２３）をＶＭの性能毎に分け、キューに対応する処理部の処理を変更する。実施例５によれば、ＶＭの能力の違いに応じた文書データの分割処理を行うことができる。また、能力の異なるＶＭのコスト（例えば料金）に応じて、当該能力の異なるＶＭのインスタンス数を調整することができる。

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

１０１ 文書処理システム
１０２ ＭＦＰ
１０３ ＰＣ
１１０ ＬＡＮ
１２０ ネットワーク

Claims (5)

1. 画像形成装置からジョブの処理依頼を受信したことに応じて、前記ジョブに対応するメッセージを記憶手段に格納する、要求受信プログラムを実行することにより実現される要求受信部と、
   前記記憶手段に対し前記メッセージの取得要求を定期的に行い、前記記憶手段から前記メッセージを取得した場合は、該取得したメッセージに基づく処理を行う、バックエンド処理プログラムを実行することにより実現されるバックエンド処理部とを有するクラウドコンピューティングシステムであって、
   前記処理依頼に対応する文書データを分割して分割文書データを生成するバックエンド処理部である分割処理バックエンド処理部と、
   前記分割文書データを文書処理するバックエンド処理部である文書処理バックエンド処理部と、
   前記文書処理された分割文書データを結合するバックエンド処理部である結合処理バックエンド処理部と、
   前記分割処理バックエンド処理部、前記文書処理バックエンド処理部、または前記結合処理バックエンド処理部の夫々の処理状況に応じて、該夫々のバックエンド処理部の数を増減させる管理部と、
   前記分割処理バックエンド処理部、前記文書処理バックエンド処理部、前記結合処理バックエンド処理部の夫々に対応する前記記憶手段を備え、
   前記管理部は、前記記憶手段に格納されている前記ジョブの数、または該記憶手段への前記ジョブの格納時間に基づいて、該記憶手段に対応するバックエンド処理部の数を増減させ、
   前記文書処理バックエンド処理部は、第１の処理性能を有する第１文書処理バックエンド処理部と、第１の処理性能より処理性能が高い第２の処理性能を有する第２文書処理バックエンド処理部とを含み、
   前記分割処理バックエンド処理部は、前記文書データを前記第１文書処理バックエンド処理部の数に分割した場合に生成される分割文書データのサイズが所定の閾値を超えるかを判断し、該分割文書データのサイズが該閾値を超える場合に、該第２文書処理バックエンド処理部に対応する記憶手段に、該第２文書処理バックエンド処理部の数の分のジョブを格納し、該分割文書データのサイズが該閾値を超えない場合に、該第１文書処理バックエンド処理部に対応するキューに、該第１文書処理バックエンド処理部の数の分のジョブを格納する
   ことを特徴とするクラウドコンピューティングシステム。
2. 前記管理部は、前記記憶手段に格納されている前記ジョブの数が所定の閾値以下である場合に、該記憶手段に対応するバックエンド処理部の数を減少させ、前記記憶手段に格納されている前記ジョブの数が所定の閾値を超える場合に、該記憶手段に対応するバックエンド処理部の数を増加させる
   ことを特徴とする請求項１に記載のクラウドコンピューティングシステム。
3. 画像形成装置からジョブの処理依頼を受信したことに応じて、前記ジョブに対応するメッセージを記憶手段に格納する、要求受信プログラムを実行することにより実現される要求受信部と、前記記憶手段に対し前記メッセージの取得要求を定期的に行い、前記記憶手段から前記メッセージを取得した場合は、該取得したメッセージに基づく処理を行う、バックエンド処理プログラムを実行することにより実現されるバックエンド処理部とを有するクラウドコンピューティングシステムにおける文書処理方法であって、
   前記バックエンド処理部である分割処理バックエンド処理部が、前記処理依頼に対応する文書データを分割して分割文書データを生成する生成工程と、
   前記バックエンド処理部である文書処理バックエンド処理部が、前記分割文書データを文書処理する文書処理工程と、
   前記バックエンド処理部である結合処理バックエンド処理部が、前記文書処理された分割文書データを結合する結合工程と、
   前記分割処理バックエンド処理部、前記文書処理バックエンド処理部、または前記結合処理バックエンド処理部の夫々の処理状況に応じて、該各々のバックエンド処理部の数を増減させる管理工程とを有し、
   前記クラウドコンピューティングシステムは、前記分割処理バックエンド処理部、前記文書処理バックエンド処理部、前記結合処理バックエンド処理部の夫々に対応する前記記憶手段を備えており、
   前記管理工程では、前記記憶手段に格納されている前記ジョブの数、または該記憶手段への前記ジョブの格納時間に基づいて、該記憶手段に対応するバックエンド処理部の数を増減させ、
   前記文書処理バックエンド処理部は、第１の処理性能を有する第１文書処理バックエンド処理部と、第１の処理性能より処理性能が高い第２の処理性能を有する第２文書処理バックエンド処理部とを含み、
   前記分割処理バックエンド処理部は、前記文書データを前記第１文書処理バックエンド処理部の数に分割した場合に生成される分割文書データのサイズが所定の閾値を超えるかを判断し、該分割文書データのサイズが該閾値を超える場合に、該第２文書処理バックエンド処理部に対応する記憶手段に、該第２文書処理バックエンド処理部の数の分のジョブを格納し、該分割文書データのサイズが該閾値を超えない場合に、該第１文書処理バックエンド処理部に対応するキューに、該第１文書処理バックエンド処理部の数の分のジョブを格納する
   ことを特徴とする文書処理方法。
4. 前記管理工程では、前記記憶手段に格納されている前記ジョブの数が所定の閾値以下である場合に、該記憶手段に対応するバックエンド処理部の数を減少させ、前記記憶手段に格納されている前記ジョブの数が所定の閾値を超える場合に、該記憶手段に対応するバックエンド処理部の数を増加させる
   ことを特徴とする請求項３に記載の文書処理方法。
5. 請求項３または請求項４に記載の文書処理方法をコンピュータに実行させることを特徴とするコンピュータプログラム。

Images