JP2013105237A - ジョブ処理システム、ジョブ処理装置、負荷分散装置、ジョブ処理プログラムおよび負荷分散プログラム - Google Patents

Abstract

【課題】 要求されたジョブを複数のジョブ処理装置へ振り分けて処理すること。
【解決手段】 本ジョブ処理システム１７０は、複数のジョブ処理装置１５０と、負荷分散装置１１０とを含む。負荷分散装置１１０は、順序を規定する順序規定手段１１６と、ジョブ振り分け先のジョブ処理装置に対し、順序で先行する先行ジョブを特定するためのジョブ識別情報と、先行ジョブの振り分け先のジョブ処理装置を識別する装置識別情報とを送信する送信手段１１８とを含む。ジョブ処理装置１５０は、受信した装置識別情報で特定されるジョブ処理装置のログを監視し、先行ジョブの完了を検知する監視手段１６４と、先行ジョブの完了が検知され、かつ、振り分けられた担当ジョブの処理が終了したことに応答して、該担当ジョブを完了させて、振り分けられた次のジョブの処理を開始する処理開始手段１５４と、担当ジョブの完了をログに書き込む書き込み手段１６０とを含む。
【選択図】 図３

Description

本発明は、負荷分散技術に関し、より詳細には、要求されたジョブを複数のジョブ処理装置へ振り分けて処理する、ジョブ処理システム、ジョブ処理装置、負荷分散装置、ジョブ処理プログラムおよび負荷分散プログラムに関する。

近年、ネットワーク環境の変化やユーザのニーズの変化により、ソフトウェア開発において、大規模対応およびクラウド環境対応が求められている。従来、大規模対応やクラウド環境対応のための種々の技術が知られており、クライアントからのリクエストを多重化した処理サーバへ振り分ける、負荷分散技術が知られている。

上記負荷分散技術は、ウェブ・アプリケーションなどにおいて好適に利用されている。しかしながら、従来の負荷分散技術では、負荷分散装置によりクライアントからのリクエストが各処理サーバに振り分けられた後は、各処理サーバが独立にリクエストを処理することになり、用途によっては不具合が生じる場合があった。例えば、印刷ジョブ処理においては、同一プリンタに対する印刷ジョブを要求順に処理することが望ましいなど、処理の順序が意味を有する。印刷ジョブのような処理の順序が意味を持つ用途においては、上記従来技術では、負荷分散装置により処理サーバへ処理を振り分ける前の処理の順序を保証することが難しかった。

特開２００９−０５４０４４号公報（特許文献１）は、複数のサーバの夫々が出力装置に投入する印刷ジョブを制御する環境において、同一の出力装置に対するジョブをユーザからの要求順にその出力装置に投入できるようにすることを目的とした技術を開示する。

特許文献１が開示するジョブ投入依頼装置は、ジョブの投入処理を実行しているジョブ投入装置の情報と、当該ジョブの投入先となる出力装置の情報とが対応付けられて登録されるデータベースを備える。上記ジョブ投入依頼装置は、上記データベースの登録内容に基づいてジョブ投入装置を探索し、クライアントから出力が要求されたジョブの投入先出力装置にジョブ投入処理を実行しているジョブ投入装置に対し、該要求されたジョブの投入を依頼する。これにより、クライアントからの要求順にその出力装置に印刷ジョブが投入される。

しかしながら、上記特許文献１の従来技術では、要求順に出力装置に投入するために、ジョブ投入装置の情報と出力装置の情報とが対応付けられて登録されるデータベースを設けている。このため、データベースを格納するための小さくない記憶リソースを消費し、データベース参照のための小さくない計算リソースを消費してしまい、負荷分散のメリットが減少してしまう観点から、充分なものではなかった。また、複数のジョブ投入装置にジョブ投入処理を振り分けるジョブ投入依頼装置に負荷が集中している点でも改善の余地があった。

上述した背景から、処理の順序を保証しながら、要求されたジョブを複数のジョブ処理装置へ振り分け、システム全体として負荷分散を行うことが可能なジョブ処理システムの開発が依然として望まれていた。

本発明は、上記従来技術の不充分な点に鑑みてなされたものであり、本発明は、クライアントから要求されたジョブを負荷分散装置により複数のジョブ処理装置に分散する構成において、小さなリソースのコストで、システム全体としてのジョブに関連する順序を管理しながら負荷分散することが可能なジョブ処理システム、ジョブ処理装置、負荷分散装置、ジョブ処理プログラム、および負荷分散プログラムを提供することを目的とする。

本発明では、上記課題を解決するために、以下の特徴を有するジョブ処理システムを提供する。本ジョブ処理システムは、複数のジョブ処理装置と、複数のジョブ処理装置に接続される負荷分散装置とを含む。上記負荷分散装置は、ジョブに関する順序を規定する順序規定手段と、ジョブ振り分け先のジョブ処理装置に対し、上記順序で先行する先行ジョブを特定するためのジョブ識別情報と、該先行ジョブの振り分け先のジョブ処理装置を識別する装置識別情報とを送信する送信手段とを含む。

上記ジョブ処理装置は、それぞれ、受信した装置識別情報で特定されるジョブ処理装置のログを監視し、受信したジョブ識別情報で特定される先行ジョブの完了を検知する監視手段と、上記先行ジョブの完了が検知され、かつ、振り分けられた担当ジョブの処理が終了したことに応答して、該担当ジョブを完了させて、振り分けられた次のジョブの処理を開始する処理開始手段と、上記担当ジョブの完了をログに書き込む書き込み手段とを含む。

上記構成によれば、クライアントから要求されたジョブを負荷分散装置により複数のジョブ処理装置に分散する構成において、小さなリソースのコストで、システム全体としてのジョブに関連する順序を可能なぎり維持することができる。

第１の実施形態による印刷ジョブ処理システムのネットワーク環境を示す概略図。 物理ホストのハードウェア構成図。 第１の実施形態によるロードバランス・サーバおよび複数のアプリケーション・サーバ上で実現される機能ブロック図。 本実施形態によるログ監視部が実行するログ監視処理を示すフローチャート。 本実施形態によるジョブ処理終了検知部が実行するジョブ処理の終了検知処理を示すフローチャート。 本実施形態による処理開始トリガー部が実行する、振り分けられた担当ジョブにかかる処理の進行を管理する処理を示すフローチャート。 第５の実施形態における（Ａ，Ｃ）ログ情報および（Ｂ）リクエスト情報のデータ構造を例示する図。 複数のアプリケーション・サーバに振り分けられた複数のリクエストが処理される様子を表す図。 他の実施形態において、複数の部分処理からなるジョブ処理において特定の部分処理の待ち合わせを行う構成を説明する図。 第２の実施形態によるログ監視部が実行するログ監視処理を示すフローチャート。 第２の実施形態による処理開始トリガー部が実行する、振り分けられた担当ジョブにかかる処理の進行を管理する処理を示すフローチャート。 第３の実施形態によるログ監視部が実行するログ監視処理を示すフローチャート。 第４の実施形態によるロードバランス・サーバおよび複数のアプリケーション・サーバ上で実現される機能ブロック図。 第５の実施形態によるロードバランス・サーバおよび複数のアプリケーション・サーバ上で実現される機能ブロック図。 第５の実施形態によるログ監視部が実行する、ログ監視処理を示すフローチャート。 第５の実施形態による処理開始トリガー部が実行する、振り分けられた担当ジョブにかかる処理の進行を管理する処理を示すフローチャート。 第５の実施形態における（Ａ，Ｃ）ログ情報および（Ｂ）リクエスト情報のデータ構造を例示する図。

以下、本発明について実施形態をもって説明するが、本発明は、後述する実施形態に限定されるものではない。なお、以下に説明する実施形態では、複数のジョブ処理装置と負荷分散装置とを含むジョブ処理システムの一例として、複数のアプリケーション・サーバとロードバランス・サーバとを含む印刷ジョブ処理システムを用いて説明する。

図１は、第１の実施形態による印刷ジョブ処理システムのネットワーク環境１００を示す概略図である。図１に示すネットワーク環境１００は、要求されるリクエストにかかる印刷ジョブを処理する印刷ジョブ処理システム１７０を構成する要素として、ロードバランス・サーバ１１０と、複数のアプリケーション・サーバ１５０とを含む。なお、図１では、４つのアプリケーション・サーバ１５０が例示されている。

ネットワーク環境１００は、さらに、印刷ジョブ処理システム１７０により提供されるサービスを利用する、１以上のクライアント１８０を含む。クライアント１８０は、インターネットやＬＡＮ（Local Area Network）などのネットワークを介して印刷ジョブ処理システム１７０に接続され、該システム１７０が提供する印刷ジョブ処理サービスを利用する端末装置である。上記クライアント１８０は、当該クライアント１８０の操作者からの指示に応答して、所定のドキュメントの印刷を指令する印刷ジョブのリクエストを印刷ジョブ処理システム１７０に対し送信する。

上記ロードバランス・サーバ１１０は、所定方式に従って、複数のアプリケーション・サーバ１５０ａ〜１５０ｄに対し、クライアント１８０からのリクエストを振り分けて、各リクエストの印刷ジョブ処理を実行させる負荷分散装置である。上記ロードバランス・サーバ１１０の負荷分散方式としては、特に限定されるものではないが、ラウンドロビン方式、通信量やコネクション数などを負荷の指標とした最小負荷分散方式など、これまで知られた如何なる負荷分散方式を採用することができる。本実施形態によるロードバランス・サーバ１１０は、さらに、上記リクエストの振り分けを行う際には、各リクエストの印刷ジョブに対し全体としての順序を規定する。そして、ロードバランス・サーバ１１０は、アプリケーション・サーバ１５０に対し、上記全体としての順序を保証するべく、詳細を後述するリクエスト情報を送信する。

複数のアプリケーション・サーバ１５０ａ〜１５０ｄは、それぞれ、ロードバランス・サーバ１１０から振り分けられたリクエストにかかる印刷ジョブ処理を実行する、互いに同等の機能を備えたジョブ処理装置である。本実施形態によるアプリケーション・サーバ１５０は、ロードバランス・サーバ１１０から受信したリクエスト情報を用いて、上記全体としての順序を保証しながら、要求されたリクエストにかかる印刷ジョブを処理することができる。リクエストに付随して送信されるリクエスト情報は、リクエスト情報の送信先のアプリケーション・サーバ１５０に対し、上記リクエストに先行するジョブの振り分け先のアプリケーション・サーバ１５０を通知するための情報である。

上記ロードバランス・サーバ１１０およびアプリケーション・サーバ１５０は、それぞれ、物理的に独立した汎用コンピュータ装置（物理マシン）として構成されてもよいし、物理マシン上に実現される仮想マシンとして構成されてもよい。印刷ジョブ処理システム１７０は、好適には、クラウド印刷サービスを提供するクラウド・システムとして実装することができ、説明する実施形態は、クラウド・システムとして実装された場合を例示する。ここで、クラウド印刷サービスとは、利用者がインターネットを介して、所望の時および場所から印刷を指示し、所望の場所で印刷物を得ることを可能とする、クラウド・コンピューティング方式によって提供されるサービスをいう。

ネットワーク環境１００では、図示はしないが、複合機、レーザプリンタ、インクジェットプリンタなどの１以上の画像形成装置が、クライアント１８０と同じまたは異なるロケーションに配置されている。クライアント１８０から、画像形成装置を指定して印刷ジョブのリクエストが行われると、振り分けられたアプリケーション・サーバ１５０でリクエストにかかる印刷ジョブの処理が完了した後、所定の画像形成装置に印刷ジョブ・データが送信され、印刷出力される。このときの印刷ジョブ・データの送信経路は、特に限定されるものではなく、アプリケーション・サーバ１５０から、ネットワークを介して直接、またはクライアント１８０を一旦経由して、指定の画像形成装置へと送信される。

以下、図２を参照して、本実施形態によるロードバランス・サーバ１１０およびアプリケーション・サーバ１５０のハードウェア構成について説明する。図２は、本実施形態によるロードバランス・サーバ１１０およびアプリケーション・サーバ１５０として稼働させる物理ホスト１０のハードウェア構成を示す図である。物理ホスト１０は、マイクロプロセッサ・ユニット（ＭＰＵ)１２と、ＢＩＯＳ（Basic Input Output System）を格納する不揮発性メモリ１４と、ＭＰＵ１２によるプログラム処理を可能とする実行記憶空間を提供するメモリ１６とを含む。ＭＰＵ１２は、起動時に、不揮発性メモリ１４からＢＩＯＳを読み出し、システム診断を行う。

ＭＰＵ１２は、内部バス２２を介して記憶制御用インタフェース１８に接続され、ハードディスク２０が、ＭＰＵ１２からの入出力要求に応答してデータの書込または読み出しを実行する。記憶制御用インタフェース１８としては、ＩＤＥ（Integrated Device Electronics）、ＡＴＡ（AT Attachment）、ＳＡＴＡ（Serial ATA）、ｅＳＡＴＡ（external ATA）などの規格により、ハードディスク２０の入出力を管理するインタフェースを使用することができる。ＭＰＵ１２は、また、内部バス２２を介して、ＵＳＢ、ＩＥＥＥ１１６４などのシリアルまたはパラレル・インタフェース２４を制御して、キーボード、マウスなどの入出力装置２６と通信し、ユーザからの入力を受け取ることができる。

物理ホスト１０は、さらにＶＲＡＭ２８とグラフィック・チップ３０とを含むことができる。グラフィック・チップ３０は、ＭＰＵ１２からの指令に応答してビデオ信号を処理し、ディスプレイ装置３２へと表示させている。ＭＰＵ１２は、また、内部バス２２を介してネットワークＩ／Ｆ（ＮＩＣ；Network Interface Card）３４と接続する。これにより、物理ホスト１０を外部の装置と通信させている。

物理ホスト１０は、不揮発性メモリ１４やハードディスク２０、その他ＮＶ−ＲＡＭ（図示せず）やＳＤカード（図示せず）などの記憶装置に格納されたプログラム（図示せず）を読み出し、メモリ１６のメモリ領域に展開する。これにより、物理ホスト１０は、適切なオペレーティング・システム（ＯＳ）のもとで、後述する各機能手段および各処理を実現する。上記ＯＳとしては、Ｗｉｎｄｏｗｓ（登録商標）、ＵＮＩＸ（登録商標）またはＬＩＮＵＸ（登録商標）など、如何なるアーキテクチャを有するＯＳを採用することができる。また、物理ホスト１０は、上記ロードバランス・サーバ１１０およびアプリケーション・サーバ１５０を仮想マシンとして実現する実施形態では、適切なハイパーバイザまたはホストＯＳ上にゲストＯＳを稼働させて、ＯＳの制御のもとで、後述する各機能手段および各処理を実現することができる。

なお、詳細な説明は割愛するが、本実施形態のクライアント１８０についても、図２に示すハードウェア構成と同様の構成とすることができる。クライアント１８０としては、パーソナル・コンピュータやワークステーションなどの汎用コンピュータ装置、および携帯電話やスマートフォン、タブレット端末、ＰＤＡ（Personal Digital Assistance）などの携帯情報端末を挙げることができる。

以下、図３〜図８を参照しながら、本実施形態による印刷ジョブ処理システム１７０上で実現され、全体としての順序を保証しながら、負荷分散のためリクエストを振り分ける、負荷分散印刷ジョブ処理機能について説明する。

図３は、第１の実施形態によるロードバランス・サーバ１１０および複数のアプリケーション・サーバ１５０上で実現される機能ブロックを示す図である。図３に示すロードバランス・サーバ１１０は、振り分け部１１２を備え、振り分け部１１２は、所与の負荷分散方式により、クライアント１８０から受信したリクエストを、負荷分散先として登録された複数のアプリケーション・サーバ１５０に振り分ける処理を実行する。振り分け部１１２は、より詳細には、上述したリクエスト情報を送信するタイミングを検知する送信タイミング検知部１１４と、送信するためのリクエスト情報を生成する採番部１１６と、上述したリクエスト情報の送信処理を実行する送信部１１８とを含み構成される。

送信タイミング検知部１１４は、アプリケーション・サーバ１５０にリクエストを振り分けた後、所定のアプリケーション・サーバ１５０を識別する装置識別情報と、所定のジョブを識別するジョブ識別情報とを採番部１１６に対し通知して、送信処理を開始させる。上記所定の装置識別情報は、全体としての順序において、振り分けた当該リクエストに先行するジョブ（以下、先行ジョブと参照する。）の振り分け先のアプリケーション・サーバ（以下、先行サーバと参照する。）を識別する情報であり、上記所定のジョブ識別情報は、上記先行ジョブを識別する情報である。

採番部１１６は、振り分けたリクエストに対し、全体における処理の順序を規定するとともに、該リクエストにかかる印刷ジョブ処理の順序を識別する処理番号と、上記送信タイミング検知部１１４から通知された先行サーバの装置識別情報と、上記先行ジョブのジョブ識別情報とをセットにして、リクエスト情報を生成する。送信部１１８は、振り分け先のジョブ処理装置に対し、採番部１１６により生成されたリクエスト情報を送信する。採番部１１６は、本実施形態における順序規定手段を構成し、送信部１１８は、本実施形態における送信手段を構成する。

なお、説明する実施形態では、便宜上、リクエストを振り分けた直後に、該リクエストを振り分けたサーバに対し、その処理番号、先行サーバの装置識別情報および先行ジョブのジョブ識別情報を含むリクエスト情報を送信する態様として説明する。この場合、アプリケーション・サーバ１５０では、振り分けられたリクエストと、その直後に受信したリクエスト情報とがセットとなる。しかしながら、リクエスト情報のタイミングは、特に限定されるものではない。例えば、他の実施形態では、リクエストを振り分けた直後に、次に予定されるアプリケーション・サーバ１５０に対し、本リクエストの処理番号、本リクエストの振り分け先サーバの装置識別情報および本リクエストのジョブ識別情報を含むリクエスト情報を送信する態様としてもよい。この場合、アプリケーション・サーバ１５０では、振り分けられたリクエストと、その直前に受信したリクエスト情報とがセットとなる。

図３に示すアプリケーション・サーバ１５０は、受信部１５２と、処理開始トリガー部１５４と、ジョブ処理部１５６と、ログ書き込み部１６０と、ログ格納部１６２と、ログ監視部１６４とを含む。図３には、２つのアプリケーション・サーバ１５０ａおよび１５０ｂが示されているが、第１のサーバ１５０ａは、第２のサーバ１５０ｂよりも先行する印刷ジョブを処理する先行サーバに対応する。

受信部１５２は、ロードバランス・サーバ１１０から振り分けられたリクエストと、このリクエストに先行する先行ジョブが振り分けられた先行サーバを特定するためのリクエスト情報とを受信する。ここでは、リクエストが第２のサーバ１５０ｂに振り分けられ、該リクエストに先行する先行ジョブが振り分けられた第１のサーバ１５０ａを識別するリクエスト情報が第２のサーバ１５０ｂに対し送信された場合を例に説明する。

ログ監視部１６４は、受信部１５２が受信したリクエスト情報を受け取り、装置識別情報で特定されるアプリケーション・サーバ１５０ａのログを監視する。そして、ログ監視部１６４は、上記ジョブ識別情報で特定される先行ジョブの完了を検知した場合には、処理開始トリガー部１５４に対し、先行ジョブの完了を通知する。図３に示す例では、第２のサーバ１５０ｂのログ監視部１６４ｂは、装置識別情報で特定される第１のサーバ１５０ａのログ監視を行う。

処理開始トリガー部１５４は、受信部１５２が受信した自機に振り分けられたリクエストにかかる印刷ジョブ（以下、担当ジョブと参照する。）の処理の進行を管理し、ジョブ処理部１５６を呼び出して、担当ジョブの処理を開始させる。ジョブ処理部１５６は、処理開始トリガー部１５４により呼び出され、開始された担当ジョブの処理を実行する。ジョブ処理部１５６は、より詳細には、ジョブ処理終了検知部１５８を備える。ジョブ処理終了検知部１５８は、担当ジョブの処理を監視しており、担当ジョブの処理の終了を検知すると、処理開始トリガー部１５４に対し、担当ジョブの処理の終了を通知する。

処理開始トリガー部１５４は、上述したように担当ジョブの処理の進行を管理しており、先行ジョブの完了と、振り分けられた担当ジョブの処理の終了とを待ち合わせて、次の担当ジョブの処理へ進める。なお、説明する実施形態において、「ジョブの処理の終了」は、要求された実体としての印刷ジョブ処理の終了を意味し、「ジョブの完了」は、上記印刷ジョブ処理を終え、さらに次ぎの処理に移行できる段階になったことを意味する。すなわち、ジョブは、該ジョブの処理が終了し、かつ、該ジョブに先行する先行ジョブが完了したことをもって、完了することになる。

処理開始トリガー部１５４は、上記担当ジョブの完了に伴い、ログ書き込み部１６０に対し、担当ジョブの完了と、該担当ジョブのジョブ識別情報とを通知する。ログ書き込み部１６０は、担当ジョブの完了およびジョブ識別情報の通知を受けて、上記担当ジョブの完了を記録するログ情報をログ格納部１６２に対し書き込む。

ログ格納部１６２は、ログ書き込み部１６０により書き込まれたログ情報を格納し、外部のアプリケーション・サーバ１５０のログ監視部１６４からの問い合わせに応答して、対応するログ情報を提供する。図３に示す例では、第１のサーバ１５０ａのログ格納部１６２ａは、後続するジョブが振り分けられる第２のサーバ１５０ｂのログ監視部１６４ｂからの問い合わせを受けて、対応するログ情報を送信する。

上記ログ監視部１６４、処理開始トリガー部１５４およびログ書き込み部１６０は、それぞれ、本実施形態における監視手段、処理開始手段および書き込み手段を構成する。なお、上述した説明では、リクエスト情報は、処理番号およびジョブ識別情報を別個に含むものとして説明した。しかしながら、リクエスト情報は、先行サーバおよび先行ジョブを特定できる限り、特に限定されるものではない。例えば、全体としての処理番号が連番で与えられる前提においては、振り分けられたリクエストの処理番号をデクリメントすることにより先行ジョブを特定できるので、処理番号をそのまま、先行ジョブを識別するジョブ識別情報として使用してもよい。

以下、図４〜図６に示すフローチャートを参照しながら、本実施形態による負荷分散印刷ジョブ処理機能の流れについて説明する。図４は、本実施形態によるログ監視部１６４が実行する、ログ監視処理を示すフローチャートである。図４に示す処理は、受信部１５２がリクエスト情報を受信したことに対応して、ステップＳ１００から開始される。

ステップＳ１０１では、ログ監視部１６４は、受信部１５２から渡されたリクエスト情報を読み取る。ステップＳ１０２では、ログ監視部１６４は、リクエスト情報から特定される、先行ジョブを処理しているアプリケーション・サーバ（先行サーバ）のログ情報を読み込む。リクエスト情報に含まれる装置識別情報は、対応するアプリケーション・サーバ１５０のログを格納する装置（例えばアプリケーション・サーバ１５０自身）の通信情報に関連付けられており、ログ監視部１６４は、装置識別情報を用いて装置との通信を確立させて、監視対象のログ情報を取得することができる。上記通信情報としては、ＭＡＣ（Media Access Control）アドレス、ＩＰ（Internet Protocol）などの通信アドレス、ドメインサーバ名などを挙げることができる。

また、ステップＳ１０２で読み込まれるログ情報は、先行ジョブに関するレコードを含む。ステップＳ１０３では、ログ監視部１６４は、取得したログ情報のうち、リクエスト情報から特定される先行ジョブのログを確認する。ステップＳ１０４では、ログ監視部１６４は、先行ジョブのログを確認した結果、先行ジョブが完了しているか否かを判定する。ステップＳ１０４で、先行ジョブが未だ完了していないと判定された場合（ＮＯ）は、ステップＳ１０２へ処理をループさせ、先行ジョブの完了がログ書き込みされるのを待ち受ける。一方、ステップＳ１０４で、先行ジョブのログに完了が記録されており、先行ジョブの完了が検知された場合（ＹＥＳ）は、ステップＳ１０５へ処理が進められる。

ステップＳ１０５では、ログ監視部１６４は、処理開始トリガー部１５４に対し、先行ジョブの完了が検知された旨を通知し、ステップＳ１０６で、リクエスト情報の受信に対応して行われた本処理を終了する。

図５は、本実施形態によるジョブ処理終了検知部１５８が実行する、ジョブ処理の終了検知処理をフローチャートである。図５に示す処理は、受信部１５２がリクエストを受信し、処理開始トリガー部１５４により該リクエストの担当ジョブにかかる処理が開始されたことに応答して、ステップＳ２００から開始される。

ステップＳ２０１では、ジョブ処理終了検知部１５８は、クライアントから受信したリクエストにかかる担当ジョブの処理の監視を開始する。ステップＳ２０２では、ジョブ処理終了検知部１５８は、担当ジョブの処理が終了したか否かを判定する。ステップＳ２０２で、担当ジョブの処理がまだ終了していないと判定された場合（ＮＯ）は、ステップＳ２０２へ処理をループさせて、担当ジョブの処理が終了するのを待ち受ける。

一方、ステップＳ２０２で、担当ジョブの処理の終了を検知したと判定された場合（ＹＥＳ）は、ステップＳ２０３へ処理を分岐させる。ステップＳ２０３では、ジョブ処理終了検知部１５８は、処理開始トリガー部１５４に対し、担当ジョブの処理の終了を通知し、ステップＳ２０４で、本処理を終了させる。

図６は、本実施形態による処理開始トリガー部１５４が実行する、振り分けられた担当ジョブにかかる処理の進行を管理する処理を示すフローチャートである。図６に示す処理は、ステップＳ３００から開始される。

ステップＳ３０１では、処理開始トリガー部１５４は、ステップＳ２０３で行われる担当ジョブの処理終了通知、およびステップＳ１０５で行われる、担当ジョブに先行する先行ジョブの完了通知の有無を確認する。ステップＳ３０２では、処理開始トリガー部１５４は、担当ジョブの処理終了通知および先行ジョブの完了通知の両方があったか否かを判定する。ステップＳ３０２で、担当ジョブの処理終了通知および先行ジョブの完了通知の両方、またはいずれかが行われていないと判定された場合（ＮＯ）は、ステップＳ３０１へ処理をループさせて、両方の通知が行われるのを待ち受ける。

一方、ステップＳ３０２で、担当ジョブの処理終了通知および先行ジョブの完了通知の両方が既に行われたと判定された場合（ＹＥＳ）は、ステップＳ３０３へ処理を分岐させる。ステップＳ３０３では、処理開始トリガー部１５４は、次の担当ジョブに処理を移行し、ジョブ処理部１５６を呼び出して、次の担当ジョブに対する処理を開始させる。ステップＳ３０４では、処理開始トリガー部１５４は、ログ書き込み部１６０に対し、終了した担当ジョブの処理の完了と該担当ジョブの処理番号とを通知し、終了ログを書き込ませる。

以下、図７に例示するログ情報を参照して、全体としての順序を保証しながらリクエストを振り分ける負荷分散印刷ジョブ処理について、事例をもって説明する。図７（Ａ）は、図３に示した第１のサーバ１５０ａのログ格納部１６２に格納されるログ情報のデータ構造を例示する。図７（Ｂ）は、第１のサーバ１５０ａに後続する第２のサーバ１５０ｂへ送信されるリクエスト情報のデータ構造を例示する。図７（Ｃ）は、リクエスト情報を受信した後における第２のサーバ１５０ｂのログ格納部１６２に格納されるログ情報のデータ構造を例示する。

ロードバランス・サーバ１１０は、第１のサーバ１５０ａにリクエストを振り分けると、該リクエストの振り分け先である第１のサーバ１５０ａを識別する装置識別情報と、該リクエストのジョブを識別するジョブ識別情報とを記録する。続いて、ロードバランス・サーバ１１０は、第１のサーバ１５０ａに後続する第２のサーバ１５０ｂに対しリクエストを振り分けた際に、第２のサーバ１５０ｂに対し、図７（Ｂ）に示すリクエスト情報を送信する。

図７（Ｂ）に示すリクエスト情報は、装置識別情報「server0001」で識別される第１のサーバ１５０ａに対し先行ジョブが振り分けられたことを示し、かつ、振り分けたリクエストにかかるジョブ処理が終了した場合の全体の処理順序を意味する終了番号「51」を含む。なお、図７（Ｂ）に示すリクエスト情報においては、終了番号は、全体における処理順番を与えるとともに、先行ジョブを識別させるジョブ識別情報を与える。

第２のサーバ１５０ｂは、図７（Ｂ）に示すリクエスト情報を受信すると、振り分けられたリクエストのログ・レコードにおけるログ番号のカラムを埋め、確認先サーバのカラムに装置識別情報「server0001」を書き込む。第２のサーバ１５０ｂは、装置識別情報「server0001」で特定される第１のサーバ１５０ａのログを監視し、終了番号「50」（終了番号「51」をデクリメントした値である。）のログ・レコードが書き込まれるのを待ち受ける。第１のサーバ１５０ａが、先行ジョブの処理を完了させると、図７（Ａ）に示すように、終了フラグのカラムに「true」が書き込まれ、終了番号のカラムに「50」が書き込まれる。

第２のサーバ１５０ｂは、第１のサーバ１５０ａのログに終了番号「50」のログ・レコードが書き込まれたことを検知し、かつ、終了番号「51」で識別される担当ジョブの処理が終了したことを検知すると、次の担当ジョブの処理に移る。第２のサーバ１５０ｂは、上記移行とともに、自身のログ・レコードの終了フラグに「true」を書き込んで、終了番号のカラムに終了番号「51」を書き込む。このログ・レコードの書き込みにより、第２のサーバ１５０ｂに後続する他のアプリケーション・サーバ１５０がある場合に、第２のサーバ１５０ｂが終了番号「50」で識別されるジョブを完了させたことを後続サーバに知らしめることができる。

図７（Ａ）および（Ｃ）に示すログ情報には、ジョブ処理後の送信先のカラムが設けられている。このジョブ処理後送信先のカラムには、担当ジョブの処理により生成された印刷ジョブ・データの送信先の画像形成装置を識別するプリンタ識別情報が入力される。説明する実施形態では、ジョブ処理後送信先のカラムを特に使用しないが、他の実施形態では、上記負荷分散印刷ジョブ処理機能を適用するジョブを判断する際に、ジョブ処理後送信先の入力値を好適に利用することもできる。

上述したように、同一の画像形成装置に送信される印刷ジョブの処理順序は重要であるが、異なる画像形成装置に送信される印刷ジョブ間での処理の前後は、同一の画像形成装置に送信される場合と比較して重要度が低く、必ずしも順序を保証することを要しない場合もある。そこで、他の実施形態では、図７に示したジョブ処理後送信先のカラムを設けて、先行ジョブと送信先の画像形成装置が一致しない担当ジョブについては、上記待ち合わせを行わずに、次のジョブへ処理対象を進めることができる。

以下、図８を参照して、上述した第１の実施形態による印刷ジョブ処理システム１７０が有する利点について説明する。図８は、複数のアプリケーション・サーバ１５０に振り分けられた複数のリクエストが処理される様子を表す図である。

図８に示す横軸は、時間経過を表し、各行における軸上のバーは、各サーバＡ〜Ｄに振り分けられたリクエストのジョブ処理の進捗状況を表す。図８に示すジョブ処理のアクティブな区間は、ジョブが処理されていることを表し、非アクティブな区間は、ジョブの処理が終了して先行ジョブの完了を待ち合わせていることを表す。図８中のバーに付された番号は、印刷ジョブに対し採番された処理番号を示す。図８中の「次へ」の吹き出しは、吹き出しで示す時点で、次の担当ジョブの処理が開始されたことを表す。図８中の「次へ」の吹き出しの箇所に示される矢印は、前の担当ジョブの完了ログが書き込みされ、上記ログ監視により、先行するサーバから後続するサーバへ、ジョブ完了が伝達されたことを表す。

図８に示す例では、クライアント１８０からの複数のリクエストは、ロードバランス・サーバ１１０によりラウンドロビン方式で、サーバＡ、サーバＢ、サーバＣおよびサーバＤの順に、巡回して振り分けられる。図８の例示では、ロードバランス・サーバ１１０の処理の流れは、以下の通りとなる。
（１）サーバＡに対し、１番目のリクエストを振り分ける。
（２）サーバＢに対し、２番目のリクエストを振り分けるとともに、１番目のリクエストをサーバＡに振り分けたことを通知するリクエスト情報を送信する。
（３）サーバＣに対し、３番目のリクエストを振り分けるとともに、２番目のリクエストをサーバＢに振り分けたことを通知するリクエスト情報を送信する。
（４）サーバＤに対し、４番目のリクエストを振り分けるとともに、３番目のリクエストをサーバＣに振り分けたことを通知するリクエスト情報を送信する。
（５）サーバＡに対し、５番目のリクエストを振り分けるとともに、４番目のリクエストをサーバＤに振り分けたことを通知するリクエスト情報を送信する。
（６）サーバＢに対し、６番目のリクエストを振り分けるとともに、５番目のリクエストをサーバＡに振り分けたことを通知するリクエスト情報を送信する。
（以下省略）

上記ロードバランス・サーバ１１０によるリクエストの振り分けを受けて各アプリケーション・サーバ１５０は、以下に説明するような処理を行う。なお、以下には、サーバＢが実行する処理を代表して例示する。
（サーバＢの処理）
（２．１）上記ロードバランサによる（２）の処理に対応して、２番目のリクエストにかかる担当ジョブの処理を開始する。なお、これ以前の担当ジョブは、既に完了しているものとする。
（２．２）２番目のリクエストに先行する先行ジョブが振り分けられたサーバＡのログの監視を開始し、先行ジョブ（１番目のリクエストにかかるジョブ）が完了するのを待ち受ける。
（２．３）２番目のリクエストにかかる担当ジョブの処理の終了を検知し、かつ、上記先行ジョブ（１番目のリクエストにかかるジョブ）の完了を検知したことをもって、２番目のリクエストにかかる担当ジョブを完了させて、次の担当ジョブに処理を移す。
（２．４）上記完了に伴い、２番目のリクエストにかかる担当ジョブの完了ログを書き込む。
（６．１）上記ロードバランサによる（６）の処理に対応して、さらに上記（２．３）を待って、６番目のリクエストにかかる担当ジョブの処理を開始する。
（６．２）６番目のリクエストに先行する先行ジョブが振り分けられたサーバＡのログの監視を開始し、先行ジョブ（５番目のリクエストにかかるジョブ）が完了するのを待ち受ける。
（６．３）６番目のリクエストにかかる担当ジョブの処理の終了を検知し、かつ、先行ジョブ（５番目のリクエストにかかるジョブ）の完了を検知したことをもって、６番目のリクエストにかかる担当ジョブを完了させ、次の担当ジョブに処理を移す。
（６．４）上記完了に伴い、６番目のリクエストにかかる担当ジョブの完了ログを書き込む。
（以下省略）

図８に示す６番目のジョブを参照すると、６番目のジョブの処理をサーバＢが終了させる前に、サーバＡが先行する５番目のジョブを完了させていることが示されている。したがって、６番目のリクエストのジョブは、当該６番目のジョブの処理が終了すると同時に完了する。一方、図８に示すサーバＤに振り分けられた８番目のジョブを参照すると、サーバＤが８番目のジョブの処理を終了させた後に、その先行サーバＣが７番目の先行ジョブを完了させていることが示されている。したがって、８番目のリクエストのジョブは、先行する７番目のジョブが完了するのを待ち合わせた上で完了することになる。

上述したように、第１の実施形態の負荷分散印刷ジョブ処理によれば、先行ジョブの完了前に自己の担当ジョブが終了した場合であっても、先行ジョブの完了を待ち合わせた上で次の担当ジョブへ処理が移されることになる。このため、各アプリケーション・サーバ１５０は、先行サーバが次ぎのジョブを開始させる前に自身の次の担当ジョブを開始することはなく、待ち合わせ時点におけるジョブの処理順序が保証される。

また、上記ジョブの処理順序を保証するための追加の通信は、主としてアプリケーション・サーバ１５０が先行サーバに対し対して行うログの問い合わせの通信である。このため、アプリケーション・サーバ間で同期を取るためにタイミング信号を送受信するような実装と比較しても、小さな通信コストを発生させるのみであり、負荷分散の目的とも整合する。

さらに、上記ジョブの処理順序を保証するための追加の情報は、主として各ジョブのログ・レコードに付随する確認先サーバおよび終了番号または終了フラグである。確認先サーバは、また、ログ情報として記憶されるものを流用することができる。このため、順序を保証するためにデータベース等の管理手段を設ける実装と比較しても、小さなリソースのコストを発生させるのみである。また、上記終了番号は、後続するアプリケーション・サーバ１５０が完了ログを読み取った時点で不要となるため、上記ログ情報をキャッシュに格納することにより、リソースの使用量をさらに縮小することができる。

なお、上述した実施形態では、担当ジョブ全体を待ち合わせが必要な処理として、先行ジョブの完了を待ち合わせた上で次の担当ジョブへ処理が移行されるものとして説明してきた。しかしながら、担当ジョブの処理中には、待ち合わせを要しない箇所がある場合もある。そこで、他の実施形態では、担当ジョブにかかる処理のうち、特定箇所からの処理を待ち合わせ、特定箇所までの処理については、待ち合わせを行うことなく処理を進めることができる。

図９は、複数の部分処理からなるジョブ処理において特定の部分処理を待ち合わせを行う構成を説明する図である。図９に示す例では、リクエスト毎に各アプリケーション・サーバ１５０に対し、ジョブ処理が要求されるが、各ジョブの処理が、図中Ａ、ＢおよびＣで参照される３つの部分から構成されている。上記の場合において、最初から最後までの全ての部分処理Ａ，Ｂ，Ｃの待ち合わせを行う設定においては、図９（Ａ）に示すように、待つ側のサーバは、先行サーバによる先行ジョブの処理Ｃが終了し、完了ログが書き込まれたことを待ち合わせた上で、次の担当ジョブを、最初の部分処理Ａから開始させる。

一方、上記の場合において、部分処理Ｃの待ち合わせを行う設定においては、待つ側のサーバは、先行サーバによる先行ジョブの処理Ｃが終了し、完了ログが書き込まれたことを少なくとも待ち合わせた上で、次の担当ジョブのうちの部分処理Ｃを開始させる。このとき、待つ側のサーバは、処理Ｃよりも前の処理Ａおよび処理Ｂについては、待ち合わせを行わずに、先んじて実行することができる。図９（Ｂ）に示すように、次の担当ジョブ６の部分処理Ａ，Ｂは、先行ジョブの完了を待たずに先んじて実行されるが、次の担当ジョブ６の部分処理Ｃは、先行ジョブの完了を待ち合わせて行われ、その順番が保証される。同様に、上記の場合において、処理Ｂの待ち合わせを行う設定では、待つ側のサーバは、先行サーバによる先行ジョブの処理Ｃが完了することを待ち合わせた上で、次の担当ジョブの部分処理Ｂ，Ｃを開始させる。このとき、待つ側のサーバは、処理Ｂより前の処理Ａを先んじて実行することができる。

例えば、リクエストに待ち合わせしたい処理の箇所を指定したり、待ち合わせしたい処理の箇所を事前設定しておくことにより、先行サーバによる先行ジョブが完了するまで、待ち合わせを必要とする部分処理のみの開始を待ち合わせることができる。上記他の実施形態においては、「ジョブの完了」は、上記印刷ジョブ処理を終え、次ぎの印刷ジョブの処理のうち、少なくとも待ち合わせを要する部分処理に移行できる段階になったことを意味することとなる。

以上、第１の実施形態による印刷ジョブ処理システムを説明してきた。以下、第２の実施形態による印刷ジョブ処理システムについて説明する。第２の実施形態による印刷ジョブ処理システムでは、ネットワーク環境、ハードウェア構成および機能ブロックは、概ね第１の実施形態のものと同様であるため、以下、相違点を中心に説明する。

第２の実施形態によるログ監視部１６４は、第１の実施形態と同様に、先行サーバのログを監視し、上記ジョブ識別情報で特定される先行ジョブの完了が検知することを待ち受ける。本実施形態のログ監視部１６４は、さらに、上記先行ジョブの完了が検知されないまま規定時間経過した場合に、先行ジョブが失敗したものとして、処理開始トリガー部１５４に対し先行ジョブの失敗を通知する。処理開始トリガー部１５４は、上述したように担当ジョブの処理の進行を管理しており、先行ジョブの完了または失敗と、振り分けられた担当ジョブの処理の終了とを待ち合わせて、次の担当ジョブの処理へ進める。

以下、図１０、図５および図１１を参照しながら、第２の実施形態による印刷ジョブ処理システム１７０上で実現される、負荷分散印刷ジョブ処理機能について説明する。図１０は、第２の実施形態によるログ監視部１６４が実行する、ログ監視処理を示すフローチャートである。図１１は、第２の実施形態による処理開始トリガー部１５４が実行する、振り分けられた担当ジョブにかかる処理の進行を管理する処理を示すフローチャートである。ジョブ処理終了検知部１５８が実行する処理は、図５に示す処理と同様であるため、詳細は割愛する。

図１０に示す処理は、第１の実施形態と同様に、受信部１５２がリクエスト情報を受信したことに対応して、ステップＳ４００から開始される。ステップＳ４０１では、ログ監視部１６４は、受信部１５２から渡されたリクエスト情報を読み取る。ステップＳ４０２では、ログ監視部１６４は、リクエスト情報から特定される、先行サーバのログ情報を読み込む。ステップＳ４０３では、ログ監視部１６４は、取得したログ情報のうち、リクエスト情報から特定される先行ジョブのログを確認する。

ステップＳ４０４では、ログ監視部１６４は、先行ジョブのログを確認した結果、先行ジョブが完了しているか否かを判定する。ステップＳ４０４で、先行ジョブのログに完了が記録されており、先行ジョブの完了が検知された場合（ＹＥＳ）は、ステップＳ４０５へ処理が進められる。ステップＳ４０５では、ログ監視部１６４は、処理開始トリガー部１５４に対し、先行ジョブの完了が検知された旨を通知し、ステップＳ４０６で本処理を終了する。

一方、ステップＳ４０４で、先行ジョブが未だ完了していないと判定された場合（ＮＯ）は、ステップＳ４０７へ処理を分岐させる。ステップＳ４０７では、ログ監視部１６４は、本処理を開始してから一定時間経過したか否かを判定する。上記一定時間の経過は、例えば、本処理開始と共に作動させるタイマによって検出することができる。ステップＳ４０７で、一定時間が未だ経過していないと判定された場合（ＮＯ）は、ステップＳ４０２へ処理をループさせる。

一方、ステップＳ４０７で、先行ジョブの完了ログを検知しないまま一定時間経過したと判定された場合（ＹＥＳ）は、ステップＳ４０８へ処理を分岐させる。ステップＳ４０８では、ログ監視部１６４は、処理開始トリガー部１５４に対し、先行ジョブの失敗が検知された旨を通知し、ステップＳ４０６で本処理を終了する。

図１１に示す処理は、ステップＳ５００から開始される。ステップＳ５０１では、処理開始トリガー部１５４は、図５に示したステップＳ２０３で行われる担当ジョブの処理終了通知、および図１０に示したステップＳ４０５またはＳ４０８で行われる、担当ジョブに先行する先行ジョブの完了通知または失敗通知の有無を確認する。ステップＳ５０２では、処理開始トリガー部１５４は、担当ジョブの処理終了通知および先行ジョブの通知（完了通知または失敗通知）の両方があったか否かを判定する。ステップＳ５０２で、担当ジョブの処理終了通知および先行ジョブの通知（完了通知または失敗通知）の両方、またはいずれかが行われていないと判定された場合（ＮＯ）は、ステップＳ５０１へ処理をループさせて、両方の通知が行われるのを待ち受ける。

一方、ステップＳ５０２で、担当ジョブの処理終了通知および先行ジョブの通知（完了通知または失敗通知）の両方が既に行われたと判定された場合（ＹＥＳ）は、ステップＳ５０３へ処理を分岐させる。ステップＳ５０３以降は、図６に示したステップＳ３０３以降の処理と同様であるため説明は割愛する。

以上説明した第２の実施形態によれば、先行ジョブの完了を待ち合わせる場合において、何らかの障害により先行ジョブの完了を検知することができなかった場合でも、一定期間の待ち合わせの後に次の担当ジョブへ処理が移される。このため、何らかの障害により先行ジョブの完了を検知することができなかった場合でも、ジョブ処理の進行が妨げられない。

以下、さらに、第３の実施形態による印刷ジョブ処理システムについて説明する。第３の実施形態による印刷ジョブ処理システムにおけるネットワーク環境、ハードウェア構成および機能ブロックは、概ね第１の実施形態のものと同様であるため、以下、相違点を中心に説明する。

ログ監視部１６４は、第１の実施形態と同様に、先行サーバのログを監視し、先行ジョブの完了が検知することを待ち受ける。第３の実施形態のログ監視部１６４は、さらに、先行ジョブの完了が検知されないまま一定時間経過した場合に、上記先行ジョブにさらに先行するジョブが振り分けられたサーバのログを監視する。ログ監視部１６４は、上記先行ジョブの完了が検知されないまま一定時間経過し、かつ、先行ジョブに先行するジョブの完了が検知された場合に、先行ジョブが失敗したものとして、処理開始トリガー部１５４に対し先行ジョブの失敗を通知する。

以下、先行ジョブにさらに先行するジョブを「２つ前の先行ジョブ」と参照し、先行ジョブを「１つ前の先行ジョブ」と参照し、区別する。また、１つ前の先行ジョブが振り分けられたサーバを「１つ前の先行サーバ」と参照し、２つ前の先行ジョブが振り分けられたサーバを「２つ前の先行サーバ」と参照する。

以下、図１２、図５および図１１を参照しながら、第３の実施形態による印刷ジョブ処理システム１７０上で実現される、負荷分散印刷ジョブ処理機能について説明する。図１２は、第３の実施形態によるログ監視部１６４が実行する、ログ監視処理を示すフローチャートである。なお、ジョブ処理終了検知部１５８および処理開始トリガー部１５４が実行する処理は、それぞれ、図５および図１１に示す処理と同様である。

図１２に示す処理は、第１の実施形態と同様に、受信部１５２がリクエスト情報を受信したことに対応して、ステップＳ６００から開始される。ステップＳ６０１では、ログ監視部１６４は、対応するリクエスト情報を読み取る。なお、説明する実施形態においては、リクエスト情報は、１つ前の先行サーバを識別する装置識別情報と、２つ前の先行サーバを識別する装置識別情報とを含んでいるものとする。または他の実施形態では、１つ前の先行サーバを識別する装置識別情報を含む第１のリクエスト情報と、２つ前の先行サーバを識別する装置識別情報を含む第２のリクエスト情報とを受信し、２つ前の先行サーバおよび２つ前の先行ジョブを特定する態様としてもよい。

ステップＳ６０２では、ログ監視部１６４は、１つ前の先行サーバのログ情報を読み込む。ステップＳ６０３では、ログ監視部１６４は、１つ前の先行ジョブのログを確認する。ステップＳ６０４では、ログ監視部１６４は、ログ確認の結果、１つ前の先行ジョブが完了しているか否かを判定する。ステップＳ６０４で、１つ前の先行ジョブの完了が検知された場合（ＹＥＳ）は、ステップＳ６０５へ処理が進められる。ステップＳ６０５では、ログ監視部１６４は、処理開始トリガー部１５４に対し、１つ前の先行ジョブの完了が検知された旨を通知し、ステップＳ６０６で本処理を終了する。

一方、ステップＳ６０４で、１つ前の先行ジョブが未だ完了していないと判定された場合（ＮＯ）は、ステップＳ６０７へ処理を分岐させる。ステップＳ６０７では、ログ監視部１６４は、本処理を開始してから一定時間経過したか否かを判定する。ステップＳ６０７で、一定時間が未だ経過していないと判定された場合（ＮＯ）は、ステップＳ６０２へ処理をループさせる。一方、ステップＳ６０７で、完了ログを検知しないまま一定時間経過したと判定された場合（ＹＥＳ）は、ステップＳ６０８へ処理を分岐させる。

ステップＳ６０８では、ログ監視部１６４は、リクエスト情報から特定される２つ前の先行サーバのログ情報を読み込む。ステップＳ６０９では、ログ監視部１６４は、取得したログ情報のうち、リクエスト情報から特定される２つ前の先行ジョブのログを確認する。ステップＳ６１０では、ログ監視部１６４は、ログ確認の結果、２つ前の先行ジョブが完了しているか否かを判定する。

ステップＳ６１０で、２つ前の先行ジョブの完了が検知された場合（ＹＥＳ）は、ステップＳ６１１へ処理が進められる。ステップＳ６１１では、ログ監視部１６４は、処理開始トリガー部１５４に対し、１つ前の先行ジョブの失敗が検知された旨を通知し、ステップＳ６０６で本処理を終了する。一方、ステップＳ６１０で、２つ前の先行ジョブの完了が検知されなかった場合（ＮＯ）は、ステップＳ６０９へループさせて、２つ前の先行ジョブの完了を待ち受ける。

以上説明した第３の実施形態の処理によれば、先行ジョブの完了を待ち合わせる場合において、何らかの障害により先行ジョブの完了を一定期間の検知できない場合に、２つ前の先行ジョブの完了をもって、１つ前の先行ジョブの失敗を検知し、次の担当ジョブへ処理を進めることができる。２つ前の先行ジョブが完了しているにも関わらず、一定時間内に１つ前の先行ジョブが完了していないということは、２つ前の先行ジョブも完了していない場合に比較して１つ前の先行ジョブに障害があった可能性が高いことを意味している。このため、第２の実施形態と比較して高い精度で１つ前の先行ジョブの失敗を検知することが可能となる。

以下、さらに、第４の実施形態による印刷ジョブ処理システムについて説明する。第４の実施形態による印刷ジョブ処理システムにおけるネットワーク環境およびハードウェア構成は、概ね第１の実施形態のものと同様であるため、以下、図１３を参照して、機能ブロックにおける相違点を中心に説明する。

図１３は、第４の実施形態によるロードバランス・サーバ１１０および複数のアプリケーション・サーバ１５０上で実現される機能ブロックを示す図である。図１３に示すロードバランス・サーバ１１０は、図３に示す構成と概ね同じであるため、詳細な説明は割愛する。図１３に示すアプリケーション・サーバ１５０は、第１の実施形態と同様の構成１５２〜１６４（待ち合わせジョブ処理部１５６は、第１の実施形態のジョブ処理部１５６に相当する。）を備える他、さらに、待ち合わせ処理分離部１６６と、通常処理部１６８とを備える。

第４の実施形態の受信部１５２は、ロードバランス・サーバ１１０から振り分けられたリクエストと、先行ジョブおよび先行サーバを特定するためのリクエスト情報とを受信し、振り分けられたリクエストを待ち合わせ処理分離部１６６へ渡す。

待ち合わせ処理分離部１６６は、振り分けられた担当ジョブの処理のうち、先行ジョブの完了を待ち合わせる必要のある処理を分離し、処理開始トリガー部１５４に通知し、担当ジョブの終了およびその先行ジョブの完了の待ち合わせを開始させる。リクエスト自体に待ち合わせの要否を指定する処理を規定する情報を含めることができる。通常処理部１６８は、振り分けられた担当ジョブの処理のうち、先行ジョブの完了を待ち合わせる必要のない分離された処理を実行する。

待ち合わせジョブ処理部１５６は、第１の実施形態と同様に、処理開始トリガー部１５４により呼び出され、待ち合わせる必要のあるとされる処理を実行する。待ち合わせジョブ処理部１５６のジョブ処理終了検知部１５８は、待ち合わせが必要とされる処理を監視しており、該処理の終了を検知すると、処理開始トリガー部１５４に対し、その終了を通知する。処理開始トリガー部１５４は、待ち合わせが必要とされる処理の終了と先行ジョブの完了とを待ち合わせて、次の担当ジョブの処理へ進める。

以上説明した第４の実施形態の処理によれば、リクエストされたジョブの処理のうち、待ち合わせが不要な処理については、先行ジョブの完了および担当ジョブの処理の終了を待ち合わせずに順次処理することができる。例えば、アプリケーション・サーバ１５０に対して要求されたリクエストのジョブ処理が、処理Ａ、Ｂという処理の後、処理Ｃおよび処理Ｄに分離される場合に適用することができる。このとき、処理Ｃについては、待ち合わせが行われ、処理Ｄについては、待ち合わせを行わずに通常処理部１６８が処理を実行することができる。

以下、さらに、第５の実施形態による印刷ジョブ処理システムについて説明する。第５の実施形態による印刷ジョブ処理システムにおけるネットワーク環境およびハードウェア構成は、概ね第１の実施形態のものと同様であるため、以下、図１４〜図１７を参照して、相違点を中心に説明する。

図１４は、第５の実施形態によるロードバランス・サーバ１１０および複数のアプリケーション・サーバ１５０上で実現される機能ブロックを示す図である。図１４に示すロードバランス・サーバ１１０の振り分け部１１２は、第１の実施形態と同様の構成１１４〜１１８に加えて、さらにリクエスト内フラグ検知部１２０を備える。

リクエスト内フラグ検知部１２０は、クライアント１８０から受信したリクエストにおけるユーザが印刷設定として設定された待ち合わせが不要であることを示すフラグの値を参照し、先行ジョブの完了を待ち合わせることが必要であるか否かを検知する。送信タイミング検知部１１４は、アプリケーション・サーバ１５０にリクエストを振り分けた後、採番部１１６に通知を行い、送信処理を開始させる。

採番部１１６は、リクエスト内フラグ検知部１２０よりフラグが立っていないことが確認された場合は、振り分けたリクエストに対し、処理番号と、先行サーバの装置識別情報と、先行ジョブのジョブ識別情報とをセットにしてリクエスト情報を生成する。採番部１１６は、リクエスト内フラグ検知部１２０よりフラグが立っていることが確認された場合は、待ち合わせ不要を指定する専用のリクエスト情報を生成する。送信部１１８は、振り分け先のジョブ処理装置に対し、採番部１１６により生成されたリクエスト情報を送信する。

第５の実施形態のログ監視部１６４は、待ち合わせ不要を示す専用のリクエスト情報を受信した場合は、監視を行わずに、処理開始トリガー部１５４に対し、待ち合わせが不要である旨を通知する。処理開始トリガー部１５４は、第１の実施形態と同様に、担当ジョブの処理の進行を管理しており、先行ジョブの完了と、振り分けられた担当ジョブの処理の終了とを待ち合わせて、次の担当ジョブの処理へ進める。第５の実施形態の処理開始トリガー部１５４は、さらに、待ち合わせが不要である旨の通知と、振り分けられた担当ジョブの処理の終了の通知があった場合にも、次の担当ジョブの処理へ進める。

以下、図１５、図５および図１６を参照しながら、第５の実施形態による印刷ジョブ処理システム１７０上で実現される、負荷分散印刷ジョブ処理機能について説明する。図１５は、第５の実施形態によるログ監視部１６４が実行する、ログ監視処理を示すフローチャートである。図１６は、第５の実施形態による処理開始トリガー部１５４が実行する、振り分けられた担当ジョブにかかる処理の進行を管理する処理を示すフローチャートである。ジョブ処理終了検知部１５８が実行する処理は、図５に示す処理と同様であるため、詳細は割愛する。

図１５に示す処理は、第１の実施形態と同様に、受信部１５２がリクエスト情報を受信したことに対応して、ステップＳ７００から開始される。ステップＳ７０１では、ログ監視部１６４は、リクエスト情報を確認し、待ち合わせの要否を判定する。ステップＳ７０２で、待ち合わせ不要が指定された専用のリクエスト情報であり、待ち合わせが不要であると判定された場合は、ステップＳ７０８へ処理を進める。ステップＳ７０８では、ログ監視部１６４は、処理開始トリガー部１５４に対し、待ち合わせが不要である旨を通知し、ステップＳ７０７で本処理を終了する。ステップＳ７０２で、待ち合わせが必要であると判定された場合は、ステップＳ７０３へ処理を分岐させる。ステップＳ７０３〜Ｓ７０７の処理は、図３に示したステップＳ１０２〜Ｓ１０６の処理と同様であるため、説明を割愛する。

図１６に示す処理は、ステップＳ８００から開始される。ステップＳ８０１では、処理開始トリガー部１５４は、図５に示したステップＳ２０３で行われる担当ジョブの処理終了通知と、図１５に示したステップＳ７０６またはＳ７０８で行われる通知との両方の有無を確認する。ステップＳ８０２では、処理開始トリガー部１５４は、担当ジョブの処理終了通知および上記通知（先行ジョブの完了通知または待ち合わせ不要の旨の通知）の両方があったか否かを判定する。ステップＳ８０２で、上記通知のうちの両方またはいずれかが行われていないと判定された場合（ＮＯ）は、ステップＳ８０１へ処理をループさせて、両方の通知が行われるのを待ち受ける。一方、ステップＳ８０２で、両方の通知が既に行われたと判定された場合（ＹＥＳ）は、ステップＳ８０３へ処理を分岐させる。ステップＳ８０３以降は、図６に示したステップＳ３０３以降の処理と同様であるため説明は割愛する。

図１７（Ａ）は、第５の実施形態において先行する第１のサーバ１５０ａのログ格納部１６２に格納されるログ情報のデータ構造を例示する。図１７（Ｂ）は、第５の実施形態において第１のサーバ１５０ａに後続する第２のサーバ１５０ｂへ送信されるリクエスト情報のデータ構造を例示する。図１７（Ｃ）は、第５の実施形態においてリクエスト情報を受信した後における第２のサーバ１５０ｂのログ格納部１６２に格納されるログ情報のデータ構造を例示する。

ユーザにより待ち合わせが不要である旨の指定がなされる場合は、ロードバランス・サーバ１１０は、図１７（Ｂ）に示すように、アプリケーション・サーバ１５０に対し、待ち合わせ不要を示す値（false）が設定されたフラグが立てられたリクエスト情報を送信する。アプリケーション・サーバ１５０は、図１７（Ｂ）に示すリクエスト情報を受信すると、振り分けられたリクエストのログ・レコードにおけるログ番号および確認先サーバのカラムを埋めて、さらに、待ち合わせの要否を格納するカラムに値「false」を書き込む。この場合、アプリケーション・サーバ１５０は、ログ監視を行わず、終了番号「51」で識別される担当ジョブの処理の終了をまって、次の担当ジョブの処理に移る。

以上説明した第５の実施形態の処理によれば、第４の実施形態と同様に、処理順序の重要度に応じて、待ち合わせが不要なジョブについては、先行ジョブの完了および担当ジョブの処理の終了を待ち合わせずに順次処理することができる。

以上説明したように、本実施形態によれば、クライアントから要求されたジョブを負荷分散装置により複数のジョブ処理装置に分散する構成において、小さなリソースのコストで、システム全体としてのジョブに関連する順序を可能な限り維持しながらの負荷分散が可能なジョブ処理システム、ジョブ処理装置、負荷分散装置、ジョブ処理プログラム、および負荷分散プログラムを提供することができる。

上記機能部は、アセンブラ、Ｃ、Ｃ＋＋、Ｃ＃、Ｊａｖａ（登録商標）、などのレガシープログラミング言語やオブジェクト指向プログラミング言語などで記述されたコンピュータ実行可能なプログラムにより実現でき、ＲＯＭ、ＥＥＰＲＯＭ、ＥＰＲＯＭ、フラッシュメモリ、フレキシブルディスク、ＣＤ−ＲＯＭ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＤＶＤ−ＲＷ、ブルーレイディスク、ＳＤカード、ＭＯなど装置可読な記録媒体に格納して、あるいは電気通信回線を通じて頒布することができる。

これまで本発明の実施形態について説明してきたが、本発明の実施形態は上述した実施形態に限定されるものではなく、他の実施形態、追加、変更、削除など、当業者が想到することができる範囲内で変更することができ、いずれの態様においても本発明の作用・効果を奏する限り、本発明の範囲に含まれるものである。

１０…物理ホスト、１２…ＭＰＵ、１４…不揮発性メモリ、１６…メモリ、１８…記憶制御用インタフェース、２０…ハードディスク、２２…バス、２４…インタフェース、２６…入出力装置、２８…ＶＲＡＭ、３０…グラフィック・チップ、３２…ディスプレイ装置、３４…ネットワークＩ／Ｆ、１００…ネットワーク環境、１１０…ロードバランス・サーバ、１１２…振り分け部、１１４…送信タイミング検知部、１１６…採番部、１１８…送信部、１２０…リクエスト内フラグ検知部、１５０…アプリケーション・サーバ、１５２…受信部、１５４…処理開始トリガー部、１５６…ジョブ処理部、１５８…ジョブ処理終了検知部、１６０…ログ書き込み部、１６２…ログ格納部、１６４…ログ監視部、１６６…待ち合わせ処理分離部、１６８…通常ジョブ処理部、１７０…印刷ジョブ処理システム、１８０…クライアント

特開２００９−０５４０４４号公報

Claims (14)

1. 複数のジョブ処理装置と、前記複数のジョブ処理装置に接続される負荷分散装置とを含むジョブ処理システムであって、前記負荷分散装置は、
   ジョブに関する順序を規定する順序規定手段と、
   ジョブ振り分け先のジョブ処理装置に対し、前記順序で先行する先行ジョブを特定するためのジョブ識別情報と、前記先行ジョブの振り分け先のジョブ処理装置を識別する装置識別情報とを送信する送信手段と
   を含み、前記ジョブ処理装置は、それぞれ、
   受信した前記装置識別情報で特定されるジョブ処理装置のログを監視し、前記ジョブ識別情報で特定される先行ジョブの完了を検知する監視手段と、
   前記先行ジョブの完了が検知され、かつ、振り分けられた担当ジョブの処理が終了したことに応答して、該担当ジョブを完了させて、振り分けられた次のジョブの処理を開始する処理開始手段と、
   前記担当ジョブの完了をログに書き込む書き込み手段と
   を含む、ジョブ処理システム。
2. 前記監視手段は、前記先行ジョブの完了が検知されないまま規定時間経過した場合には、前記先行ジョブが失敗したものとし、前記処理開始手段は、前記先行ジョブが完了するかまたは失敗し、かつ、前記担当ジョブが終了したことに応答して、前記次のジョブの処理を開始する、請求項１に記載のジョブ処理システム。
3. 前記監視手段は、前記先行ジョブの完了が検知されないまま規定時間経過した場合には、前記先行ジョブにさらに先行するジョブが振り分けられたジョブ処理装置のログを監視し、該ジョブの完了を検知した場合に、前記先行ジョブが失敗したものとし、前記処理開始手段は、前記先行ジョブが完了するかまたは失敗し、かつ、前記担当ジョブが終了したことに応答して、前記次のジョブの処理を開始する、請求項１に記載のジョブ処理システム。
4. 前記ジョブ処理装置は、それぞれ、振り分けられた１以上の担当ジョブの処理うち、先行ジョブの完了を待ち合わせる必要のある処理を分離し、該先行ジョブの完了および担当ジョブの終了の待ち合わせを開始する分離手段をさらに含む、請求項１〜３のいずれか１項に記載のジョブ処理システム。
5. 前記負荷分散装置は、クライアントから受信したリクエスト内の指定から、先行するリクエストにかかる先行ジョブの完了を待ち合わせることが必要であるか否かを検知する要否検知手段をさらに含み、前記送信手段は、前記待ち合わせることが不要である場合は、待ち合わせが不要であることを示す情報をジョブの振り分け先のジョブ処理装置に対し送信する、請求項１〜４のいずれか１項に記載のジョブ処理システム。
6. 前記監視手段は、それぞれ、振り分けられた１以上の担当ジョブのうち、先行ジョブの完了を待ち合わせる必要のある担当ジョブについては、前記ログの監視を行わず、先行ジョブの完了を待ち合わせる必要が無い旨を前記処理開始手段に通知し、前記処理開始手段は、前記先行ジョブの完了を待ち合わせる必要が無い旨の通知を受け、かつ、前記担当ジョブの終了が検知されたことに応答して、前記次のジョブの処理を開始する、請求項５に記載のジョブ処理システム。
7. 前記処理開始手段は、前記振り分けられた次のジョブの処理として、該振り分けられた次のジョブの処理のうちの少なくとも待ち合わせを要する処理とする、請求項１〜６のいずれか１項に記載のジョブ処理システム。
8. 負荷分散装置および１以上の他のジョブ処理装置に接続されるジョブ処理装置であって、当該ジョブ処理装置は、
   前記負荷分散装置から、定義された順序において振り分けられた担当ジョブに先行する先行ジョブを特定するためのジョブ識別情報と、前記先行ジョブの振り分け先のジョブ処理装置を識別する装置識別情報とを受信する受信手段と、
   前記装置識別情報で特定される他のジョブ処理装置のログを監視し、前記ジョブ識別情報で特定される先行ジョブの完了を検知する監視手段と、
   前記先行ジョブの完了が検知され、かつ、振り分けられた担当ジョブの処理が終了したことに応答して、該担当ジョブを完了させて、振り分けられた次のジョブの処理を開始する処理開始手段と、
   前記担当ジョブの完了をログに書き込む書き込み手段と
   を含む、ジョブ処理装置。
9. 前記監視手段は、前記先行ジョブの完了が検知されないまま規定時間経過した場合には、前記先行ジョブが失敗したものとし、前記処理開始手段は、前記先行ジョブが完了するかまたは失敗し、かつ、前記担当ジョブが終了したことに応答して、前記次のジョブの処理を開始する、請求項８に記載のジョブ処理装置。
10. 前記監視手段は、前記先行ジョブの完了が検知されないまま規定時間経過した場合には、前記先行ジョブにさらに先行するジョブが振り分けられた他のジョブ処理装置のログを監視し、該ジョブの完了を検知した場合に、前記先行ジョブが失敗したものとし、前記処理開始手段は、前記先行ジョブが完了するかまたは失敗し、かつ、前記担当ジョブが終了したことに応答して、前記次のジョブの処理を開始する、請求項８に記載のジョブ処理装置。
11. 複数のジョブ処理装置に接続される負荷分散装置であって、前記負荷分散装置は、
    ジョブに関する順序を規定する順序規定手段と、
    振り分け先のジョブ処理装置に対し、前記順序で先行する先行ジョブを特定するためのジョブ識別情報と、前記先行ジョブの振り分け先のジョブ処理装置を識別する装置識別情報とを送信する送信手段とを含み、
    前記ジョブ処理装置は、それぞれ、前記装置識別情報で特定されるジョブ処理装置のログを監視して、前記ジョブ識別情報で特定される先行ジョブの完了が検知され、かつ、自機に振り分けられた担当ジョブの処理が終了したことに応答して、該担当ジョブを完了させて、自機に振り分けられた次のジョブの処理を開始し、前記担当ジョブの完了をログに書き込むことを特徴とする、
    負荷分散装置。
12. 前記負荷分散装置は、クライアントから受信したリクエスト内の指定から、先行するリクエストにかかる先行ジョブの完了を待ち合わせることが必要であるか否かを検知する要否検知手段をさらに含み、前記送信手段は、前記待ち合わせることが不要である場合は、待ち合わせ不要を示す情報をジョブの振り分け先のジョブ処理装置に対し送信する、請求項１１に記載の負荷分散装置。
13. コンピュータを、請求項８〜１０のいずれか１項に記載のジョブ処理装置の各手段として機能させるためのジョブ処理プログラム。
14. コンピュータを、請求項１１または１２に記載の負荷分散装置の各手段として機能させるための負荷分散プログラム。