(57)【要約】【課題】ユーザーの負担を軽減して、負荷分散を柔軟に且つ簡単に実現する情報処理装置を提供する。【解決手段】保持された分散先識別情報を取得し、受け付けられたリクエストに含まれる処理データのデータ量に基づき、ネットワークを介して接続された他の情報処理装置に対してリクエストを分散すると判定された場合に、そのリクエストを、取得された分散先識別情報に基づいて識別された第２の情報処理装置へ転送し、他の情報処理装置に対してリクエストを分散すると判定された場合に、リクエストが要求した、リクエストに含まれる処理データに対する処理を実行しないように制御し、他の情報処理装置に対してリクエストを分散しないと判定された場合に、リクエストが要求した、リクエストに含まれる処理データに対する処理を実行するように制御する。【選択図】図１
2016045802.tif 000002
【特許請求の範囲】
【請求項１】
クライアントから送信されたリクエストを受け付けるリクエスト受付手段と、
前記リクエスト受付手段により受け付けられた前記リクエストが要求した処理の実行を制御する制御手段と、
前記リクエスト受付手段により受け付けられた前記リクエストを分散する分散先である第２の情報処理装置を識別する分散先識別情報であって、分散処理情報保持手段により保持された前記分散先識別情報を取得する分散処理情報取得手段と、
前記リクエスト受付手段により受け付けられた前記リクエストに含まれる処理データのデータ量に基づき、ネットワークを介して接続された他の情報処理装置に対して当該リクエストを分散するか否かを判定する分散判定手段と、
前記分散判定手段により前記他の情報処理装置に対して前記リクエストを分散すると判定された場合に、当該リクエストを、前記分散処理情報取得手段により取得された前記分散先識別情報に基づいて識別された前記第２の情報処理装置へ転送する転送手段と、を備え、
前記制御手段は、
前記分散判定手段により、前記他の情報処理装置に対して前記リクエストを分散すると判定された場合に、当該リクエストが要求した、当該リクエストに含まれる前記処理データに対する処理を実行しないように制御し、前記分散判定手段により、前記他の情報処理装置に対して前記リクエストを分散しないと判定された場合に、当該リクエストが要求した、当該リクエストに含まれる前記処理データに対する処理を実行するように制御する
ことを特徴とする第１の情報処理装置。
【請求項２】
前記分散判定手段は、
前記データ量が予め設定されたデータ量閾値以上である場合に、前記他の情報処理装置に対して前記リクエストを分散すると判定することを特徴とする請求項１記載の第１の情報処理装置。
【請求項３】
前記分散判定手段は、前記リクエストに含まれる属性情報に基づいて前記データ量を取得し、
取得した前記データ量に基づき、前記他の情報処理装置に対して当該リクエストを分散するか否かを判定し、
前記転送手段は、
前記分散判定手段により前記他の情報処理装置に対して当該リクエストを分散すると判定された場合に、当該リクエストに含まれる前記処理データを、前記第１の情報処理装置と、前記分散処理情報取得手段により取得された前記分散先識別情報に基づいて識別された前記第２の情報処理装置とがアクセス可能な記憶手段に送信し、
送信した当該処理データの取得に用いるアクセス情報を当該第２の情報処理装置に送信することを特徴とする請求項１又は２記載の第１の情報処理装置。
【請求項４】
リソースの使用状況を前記データ量に換算する換算手段とを備え、
前記分散判定手段は、
前記リクエスト受付手段により受け付けられた前記リクエストに含まれる処理データのデータ量と、前記換算手段により前記リソースの使用状況が換算されたデータ量である換算データ量とに基づき、前記他の情報処理装置に対して当該リクエストを分散するか否かを判定することを特徴とする請求項１から３の何れか１項に記載の第１の情報処理装置。
【請求項５】
前記分散処理情報取得手段は、
分散処理情報保持手段により保持された前記他の情報処理装置に対して前記リクエストを分散する回数の上限である分散上限値を前記分散処理情報保持手段から取得し、
前記分散判定手段は、
前記他の情報処理装置に対して前記リクエストを分散するか否かを判定する際、当該リクエストに含まれる当該リクエストが分散された回数を示す分散回数情報と、前記分散処理情報取得手段により取得された前記分散上限値とに基づいて判定することを特徴とする請求項１から４の何れか１項に記載の第１の情報処理装置。
【請求項６】
前記分散判定手段は、
前記分散回数情報が前記分散上限値に達した場合に、前記他の情報処理装置に対して前記リクエストを分散しないと判定することを特徴とする請求項５に記載の第１の情報処理装置。
【請求項７】
前記転送手段により前記第２の情報処理装置に転送された前記リクエストに応じて、当該第２の情報処理装置から応答されたレスポンスを受け付けるレスポンス受付手段と、
前記レスポンス受付手段により受け付けられた前記レスポンスに基づき、前記リクエストを送信した前記クライアントに当該リクエストを応答する応答手段と、
前記リクエスト受付手段が前記リクエストを受け付けてから起算される計測時間が予め設定された時間を超過したか否かを判定するタイムアウトチェック手段と、を備え、
前記制御手段は、
前記分散判定手段により、前記タイムアウトチェック手段により前記計測時間が予め設定された時間を超過したと判定された場合に、前記リクエストの分散を中止するように制御し、当該リクエストが要求した、当該リクエストに含まれる前記処理データに対する処理を実行するように制御し、
前記応答手段は、
実行するように制御された当該処理の実行結果に基づき、当該リクエストを送信した前記クライアントに当該リクエストを応答することを特徴とする請求項１から６の何れか１項に記載の第１の情報処理装置。
【請求項８】
前記リクエスト受付手段は、
前記タイムアウトチェック手段により前記計測時間が予め設定された時間を超過したと判定された場合に、前記クライアントへエラーを通知することを特徴とする請求項７記載の第１の情報処理装置。
【請求項９】
前記リクエスト受付手段により受け付けられた前記リクエストが要求した処理は、当該リクエストに含まれる印刷ジョブデータに対する処理であって、
前記分散判定手段は、
当該処理が、前記印刷ジョブデータのページ記述言語に対する処理でない場合に、前記他の情報処理装置に対して当該リクエストを分散しないと判定する請求項１から８の何れかに記載の第１の情報処理装置。
【請求項１０】
前記分散判定手段は、
当該処理が、前記印刷ジョブデータのプリンタジョブランゲージに対する処理であった場合に、前記他の情報処理装置に対して当該リクエストを分散しないと判定する請求項９に記載の第１の情報処理装置。
【請求項１１】
２以上の情報処理装置がネットワークにより接続された負荷分散システムであって、
第１の情報処理装置は、
クライアントから送信されたリクエストを受け付ける第１のリクエスト受付手段と、
前記第１のリクエスト受付手段により受け付けられた前記リクエストが要求した処理の実行を制御する第１の制御手段と、
前記第１のリクエスト受付手段により受け付けられた前記リクエストを分散する分散先である第２の情報処理装置を識別する分散先識別情報であって、第１の分散処理情報保持手段により保持された前記分散先識別情報を取得する第１の分散処理情報取得手段と、
前記第１のリクエスト受付手段により受け付けられた前記リクエストに含まれる処理データのデータ量に基づき、ネットワークを介して接続された他の情報処理装置に対して当該リクエストを分散するか否かを判定する第１の分散判定手段と、
前記第１の分散判定手段により前記他の情報処理装置に対して前記リクエストを分散すると判定された場合に、当該リクエストを、前記第１の分散処理情報取得手段により取得された前記分散先識別情報に基づいて識別された前記第２の情報処理装置へ転送する第１の転送手段と、を備え、
前記第１の制御手段は、
前記第１の分散判定手段により、前記他の情報処理装置に対して前記リクエストを分散すると判定された場合に、当該リクエストが要求した、当該リクエストに含まれる前記処理データに対する処理を実行しないように制御し、前記第１の分散判定手段により、前記他の情報処理装置に対して前記リクエストを分散しないと判定された場合に、当該リクエストが要求した、当該リクエストに含まれる前記処理データに対する処理を実行するように制御し、
前記第２の情報処理装置は、
前記第１の情報処理装置から転送されたリクエストを受け付ける第２のリクエスト受付手段と、
前記第２のリクエスト受付手段により受け付けられた前記リクエストが要求した処理の実行を制御する第２の制御手段と、
前記第２のリクエスト受付手段により受け付けられた前記リクエストを分散する分散先である第３の情報処理装置を識別する分散先識別情報であって、第２の分散処理情報保持手段により保持された前記分散先識別情報を取得する第２の分散処理情報取得手段と、
前記第２のリクエスト受付手段により受け付けられた前記リクエストに含まれる処理データのデータ量に基づき、ネットワークを介して接続された他の情報処理装置に対して当該リクエストを分散するか否かを判定する第２の分散判定手段と、
前記第２の分散判定手段により前記他の情報処理装置に対して前記リクエストを分散すると判定された場合に、当該リクエストを、前記第２の分散処理情報取得手段により取得された前記分散先識別情報に基づいて識別された前記第３の情報処理装置へ転送する第２の転送手段と、を備え、
前記第２の制御手段は、
前記第２の分散判定手段により、前記他の情報処理装置に対して前記リクエストを分散すると判定された場合に、当該リクエストが要求した、当該リクエストに含まれる前記処理データに対する処理を実行しないように制御し、前記第２の分散判定手段により、前記他の情報処理装置に対して前記リクエストを分散しないと判定された場合に、当該リクエストが要求した、当該リクエストに含まれる前記処理データに対する処理を実行するように制御する
ことを特徴とする負荷分散システム。
【請求項１２】
２以上の情報処理装置がネットワークにより接続されたシステムの負荷分散方法であって、
第１の情報処理装置は、
クライアントから送信されたリクエストを受け付けて第１の記憶部に記憶するステップと、
前記第１の記憶部に記憶された前記リクエストが要求した処理の実行を制御するステップと、
前記第１の記憶部に記憶された前記リクエストを分散する分散先である第２の情報処理装置を識別する分散先識別情報であって、第１の分散処理情報保持部に保持された前記分散先識別情報を取得して前記第１の記憶部に記憶するステップと、
前記第１の記憶部に記憶された前記リクエストに含まれる処理データのデータ量に基づき、ネットワークを介して接続された他の情報処理装置に対して当該リクエストを分散するか否かを判定するステップと、
前記他の情報処理装置に対して前記リクエストを分散すると判定された場合に、当該リクエストを、前記第１の記憶部に記憶された前記分散先識別情報に基づいて識別された前記第２の情報処理装置へ転送するステップと、
前記他の情報処理装置に対して前記リクエストを分散すると判定された場合に、当該リクエストが要求した、当該リクエストに含まれる前記処理データに対する処理を実行しないように制御するステップと、
前記他の情報処理装置に対して前記リクエストを分散しないと判定された場合に、当該リクエストが要求した、当該リクエストに含まれる前記処理データに対する処理を実行するように制御するステップと、を備え、
前記第２の情報処理装置は、
前記第１の情報処理装置から転送されたリクエストを受け付けて第２の記憶部に記憶するステップと、
前記第２の記憶部に記憶された前記リクエストが要求した処理の実行を制御するステップと、
前記第２の記憶部に記憶された前記リクエストを分散する分散先である第３の情報処理装置を識別する分散先識別情報であって、第２の分散処理情報保持部に保持された前記分散先識別情報を取得して前記第２の記憶部に記憶するステップと、
前記第２の記憶部に記憶された前記リクエストに含まれる処理データのデータ量に基づき、ネットワークを介して接続された他の情報処理装置に対して当該リクエストを分散するか否かを判定するステップと、
前記他の情報処理装置に対して前記リクエストを分散すると判定された場合に、当該リクエストを、前記第２の記憶部に記憶された前記分散先識別情報に基づいて識別された前記第３の情報処理装置へ転送するステップと、
前記他の情報処理装置に対して前記リクエストを分散すると判定された場合に、当該リクエストが要求した、当該リクエストに含まれる前記処理データに対する処理を実行しないように制御するステップと、
前記他の情報処理装置に対して前記リクエストを分散しないと判定された場合に、当該リクエストが要求した、当該リクエストに含まれる前記処理データに対する処理を実行するように制御するステップと、
を備えることを特徴とする負荷分散方法。
【請求項１３】
第１の情報処理装置のプログラムであって、
クライアントから送信されたリクエストを受け付けて記憶部に記憶する処理と、
前記記憶部に記憶された前記リクエストが要求した処理の実行を制御する処理と、
前記記憶部に記憶された前記リクエストを分散する分散先である第２の情報処理装置を識別する分散先識別情報であって、分散処理情報保持部により保持された前記分散先識別情報を取得して前記記憶部に記憶する処理と、
前記記憶部に記憶された前記リクエストに含まれる処理データのデータ量に基づき、ネットワークを介して接続された他の情報処理装置に対して当該リクエストを分散するか否かを判定する処理と、
前記他の情報処理装置に対して前記リクエストを分散すると判定された場合に、当該リクエストを前記記憶部に記憶された前記分散先識別情報に基づいて識別された前記第２の情報処理装置へ転送する処理と、
前記他の情報処理装置に対して前記リクエストを分散すると判定された場合に、当該リクエストが要求した、当該リクエストに含まれる前記処理データに対する処理を実行しないように制御する処理と、
前記他の情報処理装置に対して前記リクエストを分散しないと判定された場合に、当該リクエストが要求した、当該リクエストに含まれる前記処理データに対する処理を実行するように制御する処理と、
をコンピュータに実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、負荷分散システム、負荷分散方法、及び、プログラムに関する。
【背景技術】
【０００２】
近年、クライアントから要求された処理を所定のネットワークを介して接続された外部のサーバに実行させるシステムが知られている。このようなシステムにおいて、クライアントから、例えば画像データの生成等の処理負荷の高い要求がされると、要求されたサーバ側のリソースを多く消費することになる。
【０００３】
加えて、上記のような処理負荷の高い要求が、複数のクライアントから一斉にされた場合、サーバのリソースは有限であるため、サーバの処理能力が追いつかず、処理に時間がかかり、各クライアントへの応答が遅くなってしまう。
【０００４】
そこで、近年、サーバを複数配置し、複数のサーバ間でクライアントからの要求を振り分けて負荷を分散する負荷分散システムが知られている。一般的な分散構成の例としては、フロントエンドのサーバがリクエストを受けて、ラウンドロビン方式で処理を振り分ける方法、各サーバの負荷状況を監視して、負荷の少ないサーバに処理を振り分ける方法などが知られている。
【０００５】
例えば、特許文献１には、複数のクライアントと複数のサーバとの間にいわゆるロードバランサーのような負荷分散装置を設ける技術が開示されている。当該負荷分散装置が、サービス要求パケットのヘッダー情報から当該サービス要求がサーバに与える負荷の大きさを見積り、その見積り値を、振り分けられたサーバ毎に管理することにより、サーバのリアルタイムな負荷状態に基づく負荷分散を実行している。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ところで、特許文献１に開示されたような負荷分散システムは、実際に処理を行うサーバとは別に負荷分散のため上述した負荷分散装置のような専用のサーバが必要となる。
【０００７】
しかし、後から負荷分散用のサーバを別体として設けるような場合、例えば、負荷分散用のサーバ自体の設定はもとより、これと接続される各サーバ側においても分散処理用の設定等を行う必要が出てくる。よって、このような場合、システムを停止して、大掛かりなシステム変更を要する等、導入に手間がかかってしまう。また、必要に応じて、負荷分散する、負荷分散しないといった切り替えを行うことは困難である。
【０００８】
本発明は、このような実情に鑑みてなされたものであって、ユーザーの負担を軽減して、負荷分散を柔軟に且つ簡単に実現することを目的とする。
【課題を解決するための手段】
【０００９】
上記の課題を解決するため、本発明の第１の情報処理装置は、クライアントから送信されたリクエストを受け付けるリクエスト受付手段と、リクエスト受付手段により受け付けられたリクエストが要求した処理の実行を制御する制御手段と、リクエスト受付手段により受け付けられたリクエストを分散する分散先である第２の情報処理装置を識別する分散先識別情報であって、分散処理情報保持手段により保持された分散先識別情報を取得する分散処理情報取得手段と、リクエスト受付手段により受け付けられたリクエストに含まれる処理データのデータ量に基づき、ネットワークを介して接続された他の情報処理装置に対してリクエストを分散するか否かを判定する分散判定手段と、分散判定手段により他の情報処理装置に対してリクエストを分散すると判定された場合に、リクエストを、分散処理情報取得手段により取得された分散先識別情報に基づいて識別された第２の情報処理装置へ転送する転送手段と、を備え、制御手段は、分散判定手段により、他の情報処理装置に対してリクエストを分散すると判定された場合に、リクエストが要求した、リクエストに含まれる処理データに対する処理を実行しないように制御し、分散判定手段により、他の情報処理装置に対してリクエストを分散しないと判定された場合に、リクエストが要求した、リクエストに含まれる処理データに対する処理を実行するように制御することを特徴とする。
【発明の効果】
【００１０】
本発明によれば、ユーザーの負担を軽減して、負荷分散を柔軟に且つ簡単に実現することが可能となる。
【図面の簡単な説明】
【００１１】
【図１】本発明の実施形態における情報処理装置を含む負荷分散システムの概略図である。
【図２】本発明の実施形態における情報処理装置の機能ブロック図である。
【図３】本発明の第１実施形態における分散判定処理手順について説明するシーケンス図である。
【図４】本発明の第２実施形態における分散判定処理手順について説明するシーケンス図である。
【図５】本発明の第３実施形態における分散判定処理手順について説明するシーケンス図である。
【図６】本発明の第３実施形態における分散判定処理手順について説明するシーケンス図である。
【図７】本発明の第４実施形態における分散判定処理手順について説明するシーケンス図である。
【図８】本発明の第５実施形態における情報処理装置の機能ブロック図である。
【図９】本発明の第５実施形態における分散判定処理手順について説明するシーケンス図である。
【図１０】本発明の第６実施形態における分散判定処理手順について説明するシーケンス図である。
【図１１】本発明の実施形態を適用させた具体例としてプリントサーバを用いたシステムの概略図である。
【発明を実施するための形態】
【００１２】
本発明の実施形態における情報処理装置に関し以下図面を用いて説明するが、本発明の趣旨を越えない限り、何ら本実施形態に限定されるものではない。なお、各図中、同一又は相当する部分には同一の符号を付しており、その重複説明は適宜に簡略化乃至省略する。
【００１３】
本発明の実施形態における情報処理装置を含む負荷分散システムの概略について図１を参照して説明する。本実施形態における負荷分散システムは、例えば、クライアント１０と、サーバ２０と、サーバ３０と、ストレージ３１を含み、構成されている。なお、本実施形態において、各サーバは、それぞれ、ユーザー端末からリクエストを受け付ける役割と、分散先である他のサーバに対してリクエストを分散する役割の両方の役割を持つものであってよい。つまり、サーバは、分散先である他のサーバに対してリクエストを分散する場合に、この分散元となるサーバをクライアントと呼んでも良い。また、本実施形態において、「リクエストを分散する」とは、受け付けたリクエストを他の装置に転送し、リクエストが要求した処理を他の装置に実行させることをいうものとする。
【００１４】
クライアント１０、サーバ２０、サーバ３０、ストレージ３１は、ネットワーク５１、ネットワーク５２、ネットワーク５３によって接続されている。なお、これらのネットワークは、例えばＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）やＷＡＮ（Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）等で構築されるものであってよく、また、有線ネットワークに限らず無線ネットワークであってもよい。
【００１５】
クライアント１０は、例えば、ユーザーがサーバ２０に処理要求（以下「リクエスト」という。）を行うために使用するパーソナルコンピュータ（以下「ＰＣ」という。）等の情報端末である。よって、クライアント１０は、ＰＣに限定されず、情報処理機能を有するスマートフォン、携帯電話、あるいはＰＤＡ（Ｐｅｒｓｏｎａｌ  Ｄｉｇｉｔａｌ  Ａｓｓｉｓｔａｎｔ）等の携帯情報端末であっても、情報処理機能を有するテレビジョン等の情報家電であってもよい。
【００１６】
なお、本実施形態においては、クライアント１０は１つとしているが、図示上の便宜のためであり、システム上、複数のクライアントからリクエストが送られることは言うまでもない。
【００１７】
サーバ２０は、ネットワーク５１を介したｈｔｔｐ通信などの手段により、クライアント１０からリクエストを受け付けるＰＣ等の情報処理装置であり、例えばクライアント１０等のコンピュータに対し、自身の持つ機能やサービス、データを提供するハードウェアである。
【００１８】
サーバ３０は、サーバ２０と略同一構成のＰＣ等であるため説明を省略するが、本実施形態においては、サーバ２０を分散元、サーバ３０を分散先として以下に説明する。なお、本発明において、サーバ２０を第１の情報処理装置、サーバ３０を第２の情報処理装置とするが、説明の便宜のために形式的に定義したものである。つまり、いずれの装置も略同一構成であるため、区別のために定義したものである。すなわち、本実施形態における情報処理装置としての例えばサーバ２０やサーバ３０は、いずれも分散判定のための構成を必要十分に備えているものであってよい。
【００１９】
また、本実施形態においては、サーバ２０とサーバ３０の２台が設けられているが、本発明の負荷分散システムとして、情報処理装置としてのサーバが２台に限定されるものではなく、３台以上であっても成立することは言うまでもない。また、本発明を負荷分散システムとして表現する場合は、例えば、分散元のサーバを「第１の情報処理装置」とし、分散先のサーバを「第２の情報処理装置」とし、以降、分散先のサーバの数に応じて「第３の情報処理装置」、・・・、「第ｎの情報処理装置」と形式的に定義することとする。
【００２０】
なお、例えば、本実施形態においては、サーバ２０においてサーバ３０への処理分散が判定されると、クライアント１０からサーバ２０に送られたリクエストは、サーバ３０へアクセスするためのアクセスデータやクロック等を除き、ネットワーク５２を介し、そのままサーバ３０へ転送される。
【００２１】
ストレージ３１は、例えば、サーバ３０において、クライアント１０からサーバ２０を介して送られてきたリクエストに含まれる処理データや書誌情報等を記憶する、例えばハードディスク等の記憶装置である。なお、処理データや書誌情報等を所定のデータベースに直接記憶することとしてもよい。
【００２２】
本実施形態においては、ストレージ３１とサーバ３０とがネットワーク５３を介して接続されているが、ストレージ３１にサーバ３０のみがアクセス可能であることに限定されるものでなく、サーバ２０からもアクセス可能であってもよいことは言うまでもない。なお、本実施形態においては、ストレージ３１は、サーバ２０やサーバ３０とは独立した構成となっているが、例えばサーバ３０にストレージ３１が内蔵されている構成であってもよい。
【００２３】
次に、本実施形態における情報処理装置としての、例えばサーバ２０の機能ブロックについて図２を参照して説明する。なお、サーバ３０についても、サーバ２０と略同一構成であるため、本図は、サーバ３０についても適用されるものである。
【００２４】
本実施形態におけるサーバ２０は、管理部２１と、分散判定部２２と、転送部２３と、分散処理情報保持部２４と、リクエスト解析部２５と、レスポンス解析部２６と、リクエスト処理部２７と、制御部２８を備える。
【００２５】
管理部２１は、リクエスト受付部２１１と、分散処理情報取得部２１２、レスポンス受付部２１３と、応答部２１４を備える。リクエスト受付部２１１はクライアント１０から送信されたリクエストを受け付けるリクエスト受付手段である。分散処理情報取得部２１２は、リクエスト受付部２１１により受け付けられたリクエストを分散する分散先であるサーバ３０を識別する分散先識別情報であって、分散処理情報保持部２４により保持された分散先識別情報を取得する分散処理情報取得手段である。レスポンス受付部２１３は、転送部２３によりサーバ３０に転送されたリクエストに応じて、当該第２の情報処理装置から応答されたレスポンスを受け付けるレスポンス受付手段である。応答部２１４は、レスポンス受付部２１３により受け付けられたレスポンスに基づき、リクエストを送信したクライアント１０にリクエストを応答する応答手段である。
【００２６】
分散判定部２２は、リクエスト受付部２１１により受け付けられたリクエストに含まれる処理データのデータ量に基づき、ネットワークを介して接続された他の情報処理装置に対して当該リクエストを分散するか否かを判定する分散判定手段である。また、データ量に代えて、例えば、ＣＰＵ使用率やメモリ使用率を用いて分散判定を行ってもよい。つまり、上記のＣＰＵ使用率を含むＣＰＵ使用状況や、メモリ使用率を含むメモリ使用状況や、ネットワーク使用量を含むネットワーク使用状況等のリソースの使用状況等、装置負荷を定量的に測定可能なものを利用して分散判定を行ってよい。本実施形態では、ネットワーク使用量を、例えば、サーバと、ストレージ又はデータベース間のネットワークを伝送される単位時間あたりのデータ量で示している。
【００２７】
そして、例えば、分散判定部２２は、リソースの使用状況が予め設定された閾値以上であるとき、他の情報処理装置にリクエストを分散すると判定してもよい。本実施形態においては、分散判定部２２は、所定の閾値として下記の表に示すテーブルデータを内部に備え、分散判定に際し、このテーブルデータを参照するものであってよい。
【００２８】
【表１】
2016045802.tif 000003
【００２９】
表１を参照して説明すると、例えば、分散判定部２２は、ＣＰＵ使用状況としての「ＣＰＵ使用率」を分散判定のキーとして用いる場合、表１のテーブルデータにおける閾値に基づき、ＣＰＵ使用率が９０％以上であるとき、分散処理を行うと判定する。また、同様に、メモリ使用状況としての「メモリ使用率」を分散判定のキーとして用いる場合、表１のテーブルデータにおける閾値に基づき、メモリ使用率が９０％以上であるとき、分散処理を行うと判定する。
【００３０】
さらに、同様に、ネットワーク使用状況としての「ネットワーク使用量」を分散判定のキーとして用いる場合、表１のテーブルデータにおける閾値に基づき、ネットワーク使用量が１０ＭＢｐｓ以上であるとき、分散処理を行うと判定する。つまり、本実施形態においては、分散判定部２２は、リソースの使用状況が予め設定された閾値以上であるとき、サーバ２０が高負荷であると判断し、サーバ３０へ負荷を分散する。
【００３１】
また、分散判定部２２は、リクエストに含まれる処理データのデータ量が所定のデータ量閾値以上であるとき、サーバ３０にリクエストを分散すると判定してもよい。「リクエストに含まれる処理データのデータ量」とは、例えば、リクエストに含まれるヘッダー情報内のデータ量情報等である。本実施形態においては、分散判定部２２は、分散判定に際し、上述のリソース使用状況とともに、又は、リソース使用状況に代えて、データ量閾値として下記の表に示すテーブルデータを参照してもよい。
【００３２】
【表２】
2016045802.tif 000004
【００３３】
表２を参照して説明すると、例えば、分散判定部２２は、データ量としての「ヘッダー内データ量情報」を分散判定のキーとして用いる場合、表２のテーブルデータにおけるデータ量閾値に基づき、ヘッダー内データ量情報が５ＭＢｙｔｅｓ以上であるとき、分散処理を行うと判定する。
【００３４】
なお、仮に、分散先の情報処理装置全てにおいて、同一のデータ量閾値を設定しておけば、データ量閾値以上のデータ量情報を持つリクエストが全ての分散先を通過して永久に処理されない事象が発生する。この事象を避けるため、本実施形態では、例えば、分散毎に、分散先において保持されるデータ量閾値において１ＭＢｙｔｅｓ加算することとしてもよい。
【００３５】
転送部２３は、分散判定部２２により他の情報処理装置に対してリクエストを分散すると判定された場合に、リクエストを分散処理情報取得部２１２により取得された分散先識別情報に基づいて識別されたサーバ３０へ転送する転送手段である。リクエストを受け付けたサーバ３０においても、サーバ２０同様の分散判定が行われ、リソース状況等に基づいて分散を行うか否かを判定し、負荷が軽ければ、サーバ３０自身でリクエスト処理を実行すればよい。一方、負荷が重ければ、さらに例えばサーバ３０に代わる分散先へリクエストを転送すればよい。
【００３６】
分散処理情報保持部２４は、分散先識別情報としてのサーバのＩＰアドレス等を保持・記憶する分散処理情報保持手段である。
【００３７】
リクエスト解析部２５は、受け付けたリクエスト内容を解析し、例えばヘッダー情報に分散先のサーバ３０のＩＰアドレス等を付加して、サーバ２０からサーバ３０へのリクエストとして再構成を行う。
【００３８】
レスポンス解析部２６は、サーバ３０から送られたレスポンス内容を解析し、例えばヘッダー情報を編集してクライアント１０に対するサーバ２０自身のレスポンスとして再構成を行う。リクエスト処理部２７は、受け付けたリクエストが要求した処理を行い、レスポンスを生成する。
【００３９】
制御部２８は、分散判定部２２により、他の情報処理装置に対してリクエストを分散すると判定された場合に、当該リクエストが要求した、当該リクエストに含まれる処理データに対する処理を実行しないように制御する制御手段である。また、制御部２８は、分散判定部２２により、他の情報処理装置に対してリクエストを分散しないと判定された場合に、当該リクエストが要求した、当該リクエストに含まれる処理データに対する処理を実行するように制御する。
【００４０】
以上を踏まえ、本実施形態におけるサーバ２０の動作概略について説明する。管理部２１は、クライアント又はサーバからのリクエスト依頼を受けて、分散判定部２２に対し分散判定依頼を行う。分散処理を行う場合は、リクエスト解析部２５に対してリクエスト内容と分散先情報を送信し、新たに作成されたリクエストを受け取る。
【００４１】
管理部２１は、そのリクエストを、分散処理情報保持部２４から得た分散先のサーバ３０に生存確認をした後、生存を確認したらサーバ３０に送る。管理部２１は、生存を確認できない場合は、リクエスト処理部２７に対して、処理を依頼する。管理部２１は、受け取ったレスポンスをレスポンス解析部２６に送り、新たに作成したレスポンスを受け取り、クライアント又はサーバに送信する。
【００４２】
なお、サーバ３０が「生存」しているか否かは、サーバ３０の稼動状態に基づいて確認する。例えば、稼動状態として、サーバ３０の電源が入っており、リクエストの分散を受けることが可能な程度に動作している場合、管理部２１は、サーバ３０が「生存」していると判断すればよい。例えば、サーバ２０からサーバ３０に対してテスト用のリクエストを送信し、応答されたレスポンスに基づいてサーバ３０の生存を判断することとしてもよい。また、サーバ３０の生存確認につき、Ｐｉｎｇコマンドを利用してもよい。また、「生存」していると判断するため、サーバ２０とサーバ３０とがネットワークにより接続されていること、分散処理プログラムが正常に動作していることを条件としてもよい。
【００４３】
他方、サーバ３０の電源が切断されている場合、サーバ３０が故障している場合、又は、本発明における分散処理プログラムがそもそもインストールされていないような場合等においては、管理部２１は、サーバ３０が「生存していない」と判断する。そして、例えば、サーバ３０が生存していないと管理部２１が判断した場合、管理部２１は分散判定を行わないこととしてもよい。なお、上述の例に対応して、例えば、サーバ３０からレスポンス応答が無い場合、Ｐｉｎｇが返ってこない場合に、サーバ３０が生存していないと判断してもよい。さらに、サーバ２０とサーバ３０とがネットワークにより接続されていないこと、分散処理プログラムが正常に動作していないことを「生存していない」ことの判断条件としてもよい。
【００４４】
［第１実施形態］
次に、本発明の第１実施形態における分散判定処理手順について図３を参照して説明する。まず、クライアント１０は、管理部２１に対してＨｔｔｐなどのプロトコルを用いて、リクエストを送り、管理部２１からレスポンスを受け取る［１］。
【００４５】
次に、管理部２１は、分散判定部２２に対し分散判定を依頼する［１．１］。そして、分散判定部２２は、リクエストに含まれる処理データのデータ量に基づいて他の情報処理装置に対して当該リクエストの分散処理を行うか否かの判定を行う［１．１．１］。
【００４６】
分散判定部２２により分散処理を行わないと判定されたとき、管理部２１はリクエスト処理部２７に対して、リクエスト処理を依頼する［１．２］。
【００４７】
一方、分散判定部２２により分散処理を行うと判定されたとき、管理部２１は分散処理情報保持部２４に対して、分散先のサーバ３０の情報の取得を依頼する。分散先のサーバ３０の情報は、例えば、下記の表に示すような、ＩＰアドレスを用いるものであってよい。
【００４８】
【表３】
2016045802.tif 000005
【００４９】
管理部２１は、取得したＩＰアドレスに基づいてサーバ３０にアクセスし、サーバ３０が生存しているか否か確認する［１．４］。生存が確認されたときは、分散処理を継続する。
【００５０】
次に、管理部２１は、リクエスト解析部２５に対して、クライアント１０からのリクエスト内容と、分散処理情報保持部２４により取得した分散先のサーバ３０の情報を送り、リクエスト作成を依頼する［１．５］。リクエスト解析部２５は、リクエストを解析し［１．５．１］、サーバ２０におけるリクエストとして作成し［１．５．２］、管理部２１に返却する。
【００５１】
管理部２１は、返却されたリクエスト内容に基づいて、分散先のサーバ３０に対してリクエストを実行する［１．６］。
【００５２】
その後、管理部２１は、サーバ３０からレスポンスを受信すると、レスポンス解析部２６に対してレスポンスの作成を依頼する［１．７］。レスポンス解析部２６は、サーバ３０からのレスポンスを解析し［１．７．１］、サーバ２０のレスポンスとして再構成する［１．７．２］。
【００５３】
以上のように、第１実施形態によれば、分散処理を要する場合に、例えば、分散先であるサーバ２０と略同一構成のサーバ３０をサーバ２０の分散先として設定するだけでよいため、ユーザーの負担を軽減して、負荷分散を柔軟に且つ簡単に実現することが可能となる。なお、略同一構成といっても、本実施形態における分散処理を実行するソフトウェアが各サーバ上で動作するものであれば足り、その他のソフトウェア構成やハードウェア構成が異なることを妨げるものではない。一方、便宜上、装置のハードウェア構成やソフトウェア構成が同一であってもよい。
【００５４】
［第２実施形態］
次に、本発明の第２実施形態における分散判定処理手順について図４を参照して説明する。なお、第１実施形態と同様の手順については説明を省略する。第２実施形態においては、リソース状況とともに、又は、別個に、表２で示したリクエストに含まれる属性情報としてのヘッダー内データ量情報を参照して、分散判定を行う。なお、属性情報としては、例えば、時刻情報や、処理指定情報等もあるが、ここでは説明を省略する。
【００５５】
分散判定部２２は、管理部２１から分散判定の依頼を受けたとき［１．１］、分散判定処理を開始する[１．１．１]。分散判定部２２は、リソースの使用状況に加えて、例えば５ＭＢｙｔｅｓ等のデータ量閾値を分散処理情報保持部２４から取得する［１．１．１．１］。その後、分散判定部２２は、リクエストに含まれるヘッダー内データ量情報をリクエスト解析部２５から取得する［１．１．１．２］。そして、分散判定部２２は、ヘッダー内情報におけるデータ量とデータ量閾値とを比較し、ヘッダー内情報におけるデータ量がデータ量閾値以上であるとき、分散を行うと判定する［１．１．１．３］。
【００５６】
なお、リソース状況と、ヘッダー内情報におけるデータ量とを組み合わせて分散判定を行ってもよい。例えば、ＣＰＵ使用率の１０％がデータ量の１ＭＢに相当するような対応関係を予め設定しておく。そして、不図示の換算手段が、リソースの使用状況とデータ量を組み合わせて判定する際に、まず、ＣＰＵ使用率を上記対応関係に基づいてデータ量に換算する。続いて、換算結果である換算データ量を、実際のデータ量に加算し、加算後のデータ量がデータ量閾値以上か否かにより分散判定を行う。例えば、リソース状況が５０％以上であるとき、これだけで判定を行う場合は、分散判定は行われない。一方、ヘッダー内情報におけるデータ量を組み合わせることにより、データ量が閾値以上であるときは、処理を行うサーバで処理し切れないことが未然に確認できるため、より効率的に負荷を分散することが可能となる。他方、例えば１ＭＢのデータ量をＣＰＵ使用率１ＭＢ等に換算して、実際のＣＰＵ使用率に加算し、加算後のＣＰＵ使用率が表１に示した閾値以上か否かにより分散判定を行ってもよい。
【００５７】
［第３実施形態］
次に、本発明の第３実施形態における分散判定処理手順について図５を参照して説明する。なお、第１実施形態及び第２実施形態と同様の手順については説明を省略する。
【００５８】
第３実施形態においては、分散判定部２２は、リクエストに含まれる属性情報に基づいてデータ量を取得する。つまり、第２実施形態において説明した属性情報としてのヘッダー内データ量情報（以下「コンテンツｌｅｎｇｔｈ」という。）によりデータ量を取得する。取得したコンテンツｌｅｎｇｔｈから分散すると判定された場合、リクエストからそのコンテンツｌｅｎｇｔｈに係る処理データ（以下「コンテンツデータ」という。）を削除し、転送部２３が、例えば図１で示したストレージ３１に送信する。そして、転送部２３は、ストレージ３１から記憶された処理データを読み込むアクセス情報をサーバ３０に送信する。アクセス情報とは、例えば、ストレージ３１における処理データの格納場所を示すＵＲＬ（以下「コンテンツＵＲＬ」という。）等をいう。
【００５９】
分散判定部２２は、管理部２１から分散判定の依頼を受け付けたとき［１．１］、判定処理を行う［１．１．１］。その際、分散判定部２２は、リクエストに含まれるコンテンツｌｅｎｇｔｈをリクエスト解析部２５を通じて取得する［１．１．１．１］。分散判定部２２は、コンテンツｌｅｎｇｔｈに基づいて分散判定を行うと判断した場合、リクエスト解析部２５を通じてリクエストからコンテンツデータを取得し、リクエストからコンテンツデータを削除する［１．１．１．２］。なお、図５においては、図示上の便宜のため、コンテンツｌｅｎｇｔｈを「ｃ−ｌｅｎｇｔｈ」と、コンテンツデータを「ｃ−データ」と略記する。
【００６０】
コンテンツデータをリクエストから削除することで、コンテンツｌｅｎｇｔｈが減少するため、分散先においては、変更後のコンテンツｌｅｎｇｔｈに基づいてさらに分散を行うか否かが判断される。
【００６１】
分散判定部２２により、分散判定を行うと判断された場合、管理部２１は、転送部２３を介してストレージ３１にコンテンツデータを送信するとともに、ストレージ３１からコンテンツＵＲＬを取得する［２．２］。なお、図５においては、図示上の便宜のため、コンテンツＵＲＬを「ｃ−ＵＲＬ」と略記する。
【００６２】
管理部２１は、リクエスト解析部２５にリクエスト作成を依頼する［２．３］。リクエスト解析部２５は、管理部２１が取得したコンテンツＵＲＬを分散用リクエストヘッダーのコンテンツＵＲＬとして設定する[２．３．２]。管理部２１は、転送部２３を介して、第１実施形態と同様にサーバ３０にリクエストを転送する際、コンテンツＵＲＬを送信する[１．６]。一方、分散判定部２２により分散を行わないと判定された場合、管理部２１は、リクエスト処理部２７に対しリクエスト処理を依頼する［２．１］。
【００６３】
以上は、分散サーバがプライマリ機である場合の処理について説明したものであるが、分散サーバがプライマリ機でなく、分散元がコンテンツデータをストレージ又はデータベースに保存した場合の処理について図６を参照して説明する。
【００６４】
分散サーバは、自身の分散判定部２２により分散判定を行わないと判定した場合、コンテンツデータに対する処理を自身で行うことになる。そのため、コンテンツデータを取得するためのアクセス情報をリクエストヘッダーのコンテンツＵＲＬから取得する［１．１．１．２］。一方、分散判定部２２により分散すると判定した場合、コンテンツデータは既にストレージ等に保存され、リクエストに含まれていないため、取得する必要がない。また、コンテンツデータは、分散しないで処理を行うサーバが取得することになる。そして、分散サーバの管理部２１は取得したコンテンツＵＲＬから、ストレージ３１にコンテンツデータが保存されていると判定することができる。このため、取得したコンテンツＵＲＬを用いてストレージ３１からコンテンツデータを取得し［２．１］、自身のリクエスト処理部２７において処理を行う［２．２］。
【００６５】
以上、第３実施形態によれば、データ容量が大きく処理が重い、つまり装置負荷が大きいデータをストレージ３１等の外部記憶装置に保存し、分散先のサーバへはコンテンツデータを除き、コンテンツＵＲＬをリクエストヘッダーにセットしてリクエストを実行する。これにより、例えば、分散先のサーバにおいても高負荷であるため、さらにその先へ分散される等、何度も分散処理が行われるたびに、装置負荷の大きいデータまで分散先へ分散されることを回避することが可能となる。
【００６６】
［第４実施形態］
次に、本発明の第４実施形態における分散判定処理手順について図７を参照して説明する。なお、上述した各実施形態と同様の手順については説明を省略する。本実施形態においては、分散処理情報保持部２４が、分散システムにおいてトータルで分散可能な回数、つまり、リクエストが転送される回数の上限である分散上限値を保持する。分散上限値としては、例えば下記の表に示すものを用いるものであればよい。
【００６７】
【表４】
2016045802.tif 000006
【００６８】
そして、分散判定部２２は、サーバ３０にリクエストを分散する判定を行う際、リクエストに含まれる分散回数に対して例えば「１」を加算し、加算された分散回数が分散上限値と一致するとき、サーバ３０にリクエストを分散しないと判定する。
【００６９】
分散判定部２２は、管理部２１から分散判定依頼を受け付けると［１．１］、分散処理情報保持部２４から分散上限値、例えば表２における「５」を取得する［１．１．２］。
【００７０】
分散判定部２２は、分散先のサーバにリクエストする際に、ヘッダーに含まれる分散回数に分散数を付加して、取得した分散上限値と比較する［１．１．５］。このとき、分散判定部２２は、分散回数が分散上限値と一致するのであれば分散を行わないと判定し、リクエスト処理部２７がリクエストを自装置において処理する。他方、分散判定部２２は、分散回数が分散上限値以下であれば、分散処理を行うと判定する。
【００７１】
第４実施形態によれば、ヘッダーを確認することで自装置がクライアントからリクエストを受け付けているのか、分散処理先としてリクエストを受け付けているのかを判定することが可能となる。例えば、分散回数が０の場合は、クライアントからリクエストを受け付けていると判定してもよい。また、クライアントからリクエストを受け付けるプライマリ機として機能する場合、全てのサーバにその機能を持たせて、プライマリ機であるか否かの判定をさせるようにしてもよい。例えば、リクエストが、リクエストに含まれるサイズの大きいデータをストレージに保存する処理を要求する場合に、サイズの大きいデータを含むリクエストを分散すれば、却ってネットワークに負荷を増加する可能性があるため、このような処理はプライマリ機で行うこととすればよい。より具体的には、例えばリクエストが、リクエストに含まれるサイズがデータ量閾値以上のデータをストレージに保存する処理を要求する場合に、リクエストを分散せずに、プライマリ機で実行することとすればよい。
【００７２】
［第５実施形態］
次に、本発明の第５実施形態における分散判定処理手順について図８、９を参照して説明する。なお、上述した各実施形態と同様の構成及び同様の手順については説明を省略する。本実施形態においては、図２に示したブロック図に加え、タイムアウトチェック部３２を設けている。タイムアウトチェック部３２は、管理部２１がリクエストを受け付けてから起算される計測時間が所定時間を経過したか否かを判定するタイムアウトチェック手段である。所定時間とは、タイムアウト判定を行うための閾値時間であり、例えば１０秒等のタイムアウト値を設定するものであってもよい。
【００７３】
そして、タイムアウトチェック部３２により計測時間が所定時間を経過したと判定されたとき、管理部２１は、分散処理を中止する。つまり、分散先に転送したリクエストの応答を待っている状態を中止する。
【００７４】
まず、管理部２１は、クライアント１０からのリクエスト内容から、リクエスト投入時間を抽出し、例えば不図示のタイマーによってリクエスト投入からの計測時間を計測する。そして、管理部２１は、タイムアウトチェック部３２に対してタイムアウトチェックを依頼する［１．８］。タイムアウトチェック部３２は、装置内等に保持されたタイムアウト値をチェックし、計測時間がタイムアウト値を超過しているか否かを判定する［１．８．１］。
【００７５】
そして、管理部２１は、タイムアウトチェック部３２により、タイムアウト値を超過しているとの判定を受け取った場合、分散処理を中止し、応答待ち状態を中止する［１．９］。そして、管理部２１は、リクエスト処理部２７にリクエスト処理を依頼する［１．１０］。
【００７６】
第５実施形態によれば、分散先において処理を行う際に、例えば、何らかのエラーが発生し、処理が終わらない、又は分散元に応答できない場合に、一定時間を経過すると、分散元が、応答待ち状態を中止し処理を行うことにより、応答性を改善することができる。つまり、第５実施形態によれば、このような場合でも、タイムアウト値を参照して、分散処理における計測時間がタイムアウト値を超えたら、その時点で分散を行わず、いずれかのサーバにおいて処理を実行するものとしてよい。
【００７７】
［変形例］
次に、本発明の第５実施形態の変形例について図１０を参照して説明する。なお、上述した各実施形態と同様の手順については説明を省略する。本変形例において、第５実施形態と異なり、タイムアウト判定の際、管理部２１がクライアント１０にエラーを通知するものとしてもよい。
【００７８】
つまり、管理部２１は、計測時間がタイムアウト値を超過していると判定されたとき、エラー通知をクライアント１０に返却する［１．１１］。これにより、ユーザーはサーバによる分散処理ができない状態であることを認識することが可能となる。
【００７９】
なお、上述する各実施の形態は、本発明の好適な実施の形態であり、本発明の要旨を逸脱しない範囲内において種々変更実施が可能である。例えば、上述した本実施形態の情報処理装置における各処理を、ハードウェア、又は、ソフトウェア、あるいは、両者の複合構成を用いて実行することも可能である。
【００８０】
なお、ソフトウェアを用いて処理を実行する場合には、処理シーケンスを記録したプログラムを、専用のハードウェアに組み込まれているコンピュータ内のメモリにインストールして実行させることが可能である。あるいは、各種処理が実行可能な汎用コンピュータにプログラムをインストールして実行させることが可能である。
【００８１】
また、上述した各実施形態においては、分散処理情報保持部２４において、分散先のサーバのＩＰアドレス等を保持し、分散処理を行う場合等に分散処理情報保持部２４を参照することとしていたが、ＩＰアドレス等の分散先情報を、別途、分散先のサーバと異なる外部サーバに記憶させておくものとしてもよい。これにより、例えばＩＰアドレス等の分散先の情報を一元管理することが可能となる。
【００８２】
また、分散先のサーバが複数設定されているような場合は、例えばそれら全てのサーバのＩＰアドレス等を外部サーバで一括管理し、分散処理を行う場合で、外部サーバを参照する際に、例えばラウンドロビン方式を用いて分散先のサーバ情報としてＩＰアドレスを取得することとしてもよい。
【００８３】
また、各サーバのリソース状況を外部サーバにて一元管理し、分散判定の際、外部サーバに格納されたリソース状況を参照して、分散先のサーバを判定することとしてもよい。
【００８４】
さらに、上述してきた本実施形態は、分散先のサーバとして、例えば図１１に示すようなプリントサーバを用いたプルプリントシステム等に適用することが好ましい。本システムは、クライアント１００と、プリントサーバ２００と、プリントサーバ３００と、ストレージ３１０と、ストレージ３２０とが、それぞれ、ネットワーク５１０、ネットワーク５２０、ネットワーク５３０、ネットワーク５４０により接続されて構成されている。
【００８５】
本例の場合、クライアント１００からのリクエストとしては、例えば、「印刷ジョブの保存」、「印刷ジョブリストの取得」、「印刷設定の変更」、「プレビュー画像の生成」、「印刷ジョブの取得」などがある。
【００８６】
また、プリントサーバで実行される内部処理としては、例えば「印刷ジョブ、印刷ジョブ属性の保存」、「印刷ジョブのパース、又は編集」、「印刷ジョブのパースと画像データの生成」、「印刷ジョブリストの取得」、「印刷ジョブの取得」などがある。そして、例えば、印刷ジョブの属性情報等の書誌情報をストレージ３１０に保存し、印刷ジョブやプレビュー画像データをストレージ３２０に保存しておく。プリントサーバは、これらの情報を必要なときに取得して処理を実行する。
【００８７】
このような場合、各プリントサーバが処理をスムーズに行えるクライアントの上限数を決める際に、サーバ内部でのＣＰＵ負荷の高い処理となる印刷ジョブのパース、編集と画像データの生成を、どれだけ並行に行えるかという点が重要である。
【００８８】
例えば、上記のような処理を１００処理分、並行で処理させた場合に、プリントサーバのＣＰＵ使用率が常に１００パーセントになると、レスポンスが遅くなることが懸念される。そこで、このことが誘因となる例えば処理の停止等を回避し、クライアント数を増やす対策を講じる必要がある。
【００８９】
例えば、キューに処理をためて、一定数以上は並行処理ができないようにする等の対策もあるが、この場合ユーザーの待ち時間が長くなる。他方、本実施形態を適用すれば、プリントサーバ内部でのＣＰＵへの負荷を分散でき、クライアントの上限数を簡単に増やすことが可能となる。
【００９０】
例えば、クライアント１００からのリクエストとしての印刷ジョブがｒａｗデータ形式でプリントサーバ２００へ投入されると、プリントサーバ２００は本実施形態を適用した分散判定を行う。
【００９１】
プリントサーバ２００は、分散判定により印刷ジョブに対する処理の分散を行うと判定すると、次にプリントサーバ３００の生存を確認する。プリントサーバ２００は、プリントサーバ３００の生存を確認すると、プリントサーバ３００へ印刷ジョブを投入する。
【００９２】
プリントサーバ３００も、本実施形態を適用した分散判定処理を行い、分散を行わないと判定すると、印刷ジョブからプレビュー画像を生成し、プレビュー画像と印刷ジョブをストレージ３２０に保存する処理を実行する。また、プリントサーバ３００は、ジョブの書誌情報をクライアントが印刷ジョブ投入時に呼び出したＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）のパラメータや印刷ジョブから抽出しストレージ３１０に保存する処理を実行する。そして、処理結果をプリントサーバ２００を介してクライアント１００に応答する。
【００９３】
一方、プリントサーバ２００は、実行される内部処理によって、分散判定により印刷ジョブに対する処理の分散を行わないと判定することとしてもよい。ここで、ジョブデータは一般的に、印刷ジョブを制御するプリンタジョブランゲージ（以下、「ＰＪＬ」という。）コマンド等のジョブ制御言語コマンドの部分と、ポストスクリプトやプリンター制御言語などのページ記述言語形式の印刷データ本体とを含む。
【００９４】
例えば、印刷ジョブの部数、カラー、両面などの属性を編集する内部処理が実行される際に、ジョブデータのＰＪＬ部分に対して編集を行う一方、印刷データ本体に対する編集は行わないようにしてもよい。
【００９５】
また、ジョブデータのＰＪＬ部分は、ジョブデータ本体に比べて、データ量が著しく少ないのが一般的である。ジョブデータのＰＪＬ部分に対する処理は、ジョブデータ本体に対する処理に比べて、リソースの消費量が少なく、短時間で処理できるため、プリントサーバに大きな負荷がかからない。
【００９６】
さらに、ジョブデータ本体のデータ量が大きい場合に、リクエストと共にジョブデータ本体が分散先に送信されるため、リクエストの送信による分散元に対する負荷、リクエストの受信による分散先に対する負荷、又はデータ転送によるネットワークに対する負荷が大きくなる可能性がある。従って、印刷ジョブの属性を編集する内部処理が実行される際に、分散判定により分散処理を行わずに、自装置で処理を実行するのが望ましい。
【符号の説明】
【００９７】
１０、１００    クライアント
２０、３０    サーバ
２１    管理部
２２    分散判定部
２３    通信部
２４    分散処理情報保持部
２５    リクエスト解析部
２６    レスポンス解析部
２７    リクエスト処理部
３１、３１０、３２０    ストレージ
３２    タイムアウトチェック部
５１、５２、５３、５１０、５２０、５３０、５４０    ネットワーク
２００、３００    プリントサーバ
【先行技術文献】
【特許文献】
【００９８】
【特許文献１】特開２００２−９１９３６号公報
【図１】
2016045802.tif 000007
【図２】
2016045802.tif 000008
【図３】
2016045802.tif 000009
【図４】
2016045802.tif 000010
【図５】
2016045802.tif 000011
【図６】
2016045802.tif 000012
【図７】
2016045802.tif 000013
【図８】
2016045802.tif 000014
【図９】
2016045802.tif 000015
【図１０】
2016045802.tif 000016
【図１１】
2016045802.tif 000017