JP2022106619A - 情報処理システム、情報処理装置、および情報処理方法 - Google Patents

Abstract

【課題】エラーが発生したジョブを救済可能とする情報処理システム、情報処理装置および情報処理方法を提供する。【解決手段】情報処理装置は、メッセージキューから取得して実行した担当ジョブにエラーが発生した場合、ジョブ情報管理データベースに記憶されるステータスのうち担当ジョブのステータスにエラーを格納し、担当ジョブのステータスがエラーを示し、担当ジョブを実行した情報処理装置が、同じサーバが含む情報処理装置であり、かつ、担当ジョブのタイプがエラーが発生したジョブのタイプと同じである場合、担当ジョブを実行せず、キューに対して、担当ジョブを戻す。【選択図】図１Ｂ

Description

本発明は、情報処理システム、情報処理装置、および情報処理方法に関する。

Workerサーバが有する複数のワーカ計算機（以下、ワーカと言う。情報処理装置の一例。）において、画像をＰＤＦ（Portable Document Format）に変換するドキュメント処理等のジョブを分散処理させる技術が開発されている。

しかしながら、上記の技術では、ジョブで用いられるＰＤＦライブラリ等のライブラリに異常が発生し、メモリ，プロセス，スレッド等の問題で正常に動作しなくなった場合、当該ジョブをエラーとして処理し、当該エラーが発生したジョブに対する救済手段が考慮されていない。

本発明は、上記に鑑みてなされたものであって、ジョブの実行にエラーが発生した場合でも、エラーが発生したジョブを救済可能とする情報処理システム、情報処理装置、および情報処理方法を提供することを目的とする。

上述した課題を解決し、目的を達成するために、本発明は、ジョブの実行を依頼するフロントエンドアプリと、前記ジョブの処理対象ファイルおよび前記ジョブの処理結果ファイルを記憶する共有ファイルストレージと、前記ジョブがキューイングされるキューを有するメッセージキューと、前記ジョブのジョブ情報および前記ジョブのステータスを記憶するジョブ情報管理データベースと、前記ジョブの実行の依頼を受け付け、前記ジョブ情報管理データベースに対して、前記ジョブ情報を格納し、前記キューに前記ジョブをキューイングするドキュメント処理要求管理部と、前記メッセージキューから、担当する前記ジョブである担当ジョブを取得し、前記ジョブ情報管理データベースから、前記担当ジョブの前記ジョブ情報を取得し、前記共有ファイルストレージから、取得した前記ジョブ情報に基づいて、前記処理対象ファイルを取得し、取得した前記処理対象ファイルに対して前記担当ジョブを実行した後、当該担当ジョブの前記処理結果ファイルを前記共有ファイルストレージに格納する情報処理装置と、を備え、前記情報処理装置は、前記担当ジョブにエラーが発生した場合、前記ジョブ情報管理データベースに記憶される前記ステータスのうち前記担当ジョブの前記ステータスにエラーを格納し、前記担当ジョブの前記ステータスがエラーを示し、前記担当ジョブを実行した前記情報処理装置が、同じサーバが含む前記情報処理装置であり、かつ前記担当ジョブのタイプがエラーが発生した前記ジョブのタイプと同じである場合、前記担当ジョブを実行せず、前記キューに対して、前記担当ジョブを戻す。

本発明によれば、ジョブの実行でエラーが発生した場合でも、エラーが発生したジョブを救済可能とする、という効果を奏する。

図１Ａは、第１の実施の形態にかかる情報処理システムが有する各種サーバのハードウェア構成の一例を示すブロック図である。 図１Ｂは、第１の実施の形態にかかる情報処理システムの機能構成の一例を示すブロック図である。 図２は、第１の実施の形態にかかる情報処理システムのサーバ構成の一例を示す図である。 図３は、第１の実施の形態にかかる情報処理システムのジョブ情報テーブルのデータ構成の一例を示す図である。 図４は、第１の実施の形態にかかる情報処理システムのタスクステータステーブルのデータ構成の一例を示す図である。 図５は、第１の実施の形態にかかる情報処理システムにおけるジョブの実行処理の流れの一例を示すシーケンス図である。 図６は、第１の実施の形態にかかる情報処理システムにおいて担当ジョブのキューをメッセージキューに戻す処理の流れの一例を示すシーケンス図である。 図７は、第１の実施の形態にかかる情報処理システムにおけるワーカにおける担当ジョブの実行処理の流れの一例を示すシーケンス図である。 図８は、第２の実施の形態にかかる情報処理システムにおけるワーカがメッセージキューのキューに担当ジョブを戻す処理の一例を説明するための図である。 図９は、第３の実施の形態にかかる情報処理システムにおけるジョブの実行処理の流れの一例を示すシーケンス図である。 図１０は、第４の実施の形態にかかる情報処理システムのジョブ情報テーブルに含まれるエラー情報テーブルのデータ構成の一例を示す図である。 図１１は、第４の実施の形態にかかる情報処理システムにおけるジョブの実行処理の流れの一例を示すシーケンス図である。 図１２は、第５の実施の形態にかかる情報処理システムにおけるテキストファイルに対する担当ジョブの実行処理の流れの一例を示すシーケンス図である。

以下に添付図面を参照して、情報処理システム、情報処理装置、および情報処理方法の実施の形態を詳細に説明する。

（第１の実施の形態）
図１Ａは、第１の実施の形態にかかる情報処理システムが有する各種サーバのハードウェア構成の一例を示すブロック図である。まず、図１Ａを用いて、本実施の形態にかかる情報処理システムが有する各種サーバ５（図２に示すAppサーバ２０１、Fileサーバ２０２、Queueサーバ２０３、DBサーバ２０４、Frontサーバ２０５、WorkerサーバＷＳ１，ＷＳ２）のハードウェア構成の一例について説明する。

図１Ａに示されているように、サーバ５は、コンピュータによって構築されており、図１Ａに示されているように、ＣＰＵ５０１、ＲＯＭ５０２、ＲＡＭ５０３、ＨＤ５０４、ＨＤＤ(Hard Disk Drive)コントローラ５０５、ディスプレイ５０６、外部機器接続Ｉ／Ｆ(Interface)５０８、ネットワークＩ／Ｆ５０９、バスライン５１０、キーボード５１１、ポインティングデバイス５１２、ＤＶＤ－ＲＷ(Digital Versatile Disk Rewritable)ドライブ５１４、メディアＩ／Ｆ５１６を備える。

これらのうち、ＣＰＵ５０１は、サーバ５全体の動作を制御する。ＲＯＭ５０２は、ＩＰＬ等のＣＰＵ５０１の駆動に用いられるプログラムを記憶する。ＲＡＭ５０３は、ＣＰＵ５０１のワークエリアとして使用される。ＨＤ５０４は、プログラム等の各種データを記憶する。ＨＤＤコントローラ５０５は、ＣＰＵ５０１の制御にしたがってＨＤ５０４に対する各種データの読み出しまたは書き込みを制御する。ディスプレイ５０６は、カーソル、メニュー、ウィンドウ、文字、または画像等の各種情報を表示する。外部機器接続Ｉ／Ｆ５０８は、各種の外部機器を接続するためのインターフェースである。この場合の外部機器は、例えば、ＵＳＢ(Universal Serial Bus)メモリやプリンタ等である。ネットワークＩ／Ｆ５０９は、通信ネットワーク１００を利用してデータ通信をするためのインターフェースである。バスライン５１０は、図５に示されているＣＰＵ５０１等の各構成要素を電気的に接続するためのアドレスバスやデータバス等である。

また、キーボード５１１は、文字、数値、各種指示等の入力のための複数のキーを備えた入力手段の一種である。ポインティングデバイス５１２は、各種指示の選択や実行、処理対象の選択、カーソルの移動等を行う入力手段の一種である。ＤＶＤ－ＲＷドライブ５１４は、着脱可能な記録媒体の一例としてのＤＶＤ－ＲＷ５１３に対する各種データの読み出しまたは書き込みを制御する。なお、ＤＶＤ－ＲＷに限らず、ＤＶＤ－Ｒ等であってもよい。メディアＩ／Ｆ５１６は、フラッシュメモリ等の記録メディア５１５に対するデータの読み出し又は書き込み（記憶）を制御する。

図１Ｂは、第１の実施の形態にかかる情報処理システムの機能構成の一例を示すブロック図である。本実施の形態にかかる情報処理システムは、フロントエンドアプリ１０１、共有ファイルストレージ１０２、メッセージキュー１０３、ジョブ情報管理データベース１０４、ドキュメント処理要求管理部１０５、および複数のワーカ計算機（以下、ワーカと言う。情報処理装置の一例。）Ｗ１－１，Ｗ１－２，Ｗ２－１，Ｗ２－２を有する。以下の説明では、ワーカＷ１－１，Ｗ１－２，Ｗ２－１，Ｗ２－２を区別しない場合には、ワーカＷと記載する。

フロントエンドアプリ１０１は、ジョブの実行を依頼するアプリケーションである。共有ファイルストレージ１０２は、ジョブの処理対象のファイル（以下、処理対象ファイルと言う）および当該ジョブの処理結果のファイル（以下、処理結果ファイルと言う）を記憶するストレージである。メッセージキュー１０３は、ジョブがキューイングされるキューを有する。

ジョブ情報管理データベース１０４は、ジョブ情報テーブル１０４Ａおよびタスクステータステーブル１０４Ｂを記憶するデータベースである。ジョブ情報テーブル１０４Ａは、メッセージキュー１０３のキューにキューイングされたジョブを示すジョブ情報を記憶する。タスクステータステーブル１０４Ｂは、ジョブ情報が示すジョブのステータス（進捗）を記憶するテーブルである。ドキュメント処理要求管理部１０５は、フロントエンドアプリ１０１からジョブの実行の依頼を受け付け、ジョブ情報テーブル１０４Ａに対して、実行の依頼を受け付けたジョブのジョブ情報を格納する。また、ドキュメント処理要求管理部１０５は、メッセージキュー１０３のキューに対して、フロントエンドアプリ１０１から実行の依頼を受け付けたジョブを入れる（キューイングする）。

ワーカＷは、メッセージキュー１０３から、担当ジョブを取得する。ここで、担当ジョブは、ワーカＷにおいて担当するジョブである。また、ワーカＷは、ジョブ情報テーブル１０４Ａから、担当ジョブのジョブ情報を取得する。また、ワーカＷは、共有ファイルストレージ１０２から、取得したジョブ情報に基づいて、処理対象ファイルを取得する。そして、ワーカＷは、処理対象ファイルに対して担当ジョブを実行した後、当該担当ジョブ処理結果ファイルを、共有ファイルストレージ１０２に格納する。

ここで、本実施の形態にかかる情報処理システムにおける担当ジョブの実行処理の流れの一例の概略について説明する。まず、フロントエンドアプリ１０１に対してジョブが投入されると、フロントエンドアプリ１０１は、共有ファイルストレージ１０２に対して、処理対象ファイルを格納し、その処理対象ファイルのＵＲＬ（Uniform Resource Locator）を、ドキュメント処理要求管理部１０５に対して、ジョブを投入する。

ドキュメント処理要求管理部１０５は、ジョブ情報管理データベース１０４に対して、フロントエンドアプリ１０１から投入されたジョブのジョブ情報を格納し、かつ、メッセージキュー１０３のキューに対して、当該ジョブをキューイングする。例えば、ドキュメント処理要求管理部１０５は、フロントエンドアプリ１０１から投入されたジョブのタイプ（以下、ジョブタイプと言う）が、画像をＰＤＦに変換するジョブタイプ（image2pdf）である場合、メッセージキュー１０３が有するキューのうち、当該ジョブタイプ（image2pdf）のキューに対して、ジョブをキューイングする。

ワーカＷは、メッセージキュー１０３のキューのうち、当該ワーカＷ自身が担当するタイプのジョブ（以下、担当ジョブと言う）のキューを監視（ポーリング）している。そして、ワーカＷは、担当ジョブのキューがメッセージキュー１０３に存在する場合、ジョブ情報テーブル１０４Ａから、担当ジョブのジョブ情報を取得する。次に、ワーカＷは、共有ファイルストレージ１０２から、取得したジョブ情報に基づいて、処理対象ファイルを取得し、取得した処理対象ファイルに対して担当ジョブを実行する。その際、ワーカＷは、タスクステータステーブル１０４Ｂに対して、担当ジョブのステータス（例えば、ワーカＷが何の処理を、いつから実行しているか等）を格納する。担当ジョブが終了すると、ワーカＷは、タスクステータステーブル１０４Ｂから、担当ジョブのステータスを削除する。さらに、ワーカＷは、共有ファイルストレージ１０２に対して、担当ジョブの処理結果ファイルを格納し、ジョブ情報テーブル１０４Ａに対して、当該処理結果ファイルのＵＲＬと共に、担当ジョブが終了したことを示すジョブ情報を格納する。

図２は、第１の実施の形態にかかる情報処理システムのサーバ構成の一例を示す図である。次に、図２を用いて、本実施の形態にかかる情報処理システムのサーバ構成の一例について説明する。

本実施の形態にかかる情報処理システムは、フロントエンドアプリ１０１を有するAppサーバ２０１、ドキュメント処理要求管理部１０５を有するFrontサーバ２０５、メッセージキュー１０３を有するQueueサーバ２０３、ジョブ情報管理ＤＢ１０４を有するDBサーバ２０４、共有ファイルストレージ１０２を有するFileサーバ２０２、ワーカＷ１－１，Ｗ１－２を有するWorkerサーバＷＳ１、およびワーカＷ２－１，Ｗ２－２を有するWorkerサーバＷＳ２を有する。以下の説明では、WorkerサーバＷＳ１，ＷＳ２を区別しない場合には、WorkerサーバＷＳと記載する。

ここで、本実施の形態にかかる情報処理システムが、２つのWorkerサーバＷＳ１，ＷＳ２を有するのは、片方のWorkerサーバＷＳに異常が発生しても、他方のWorkerサーバＷＳによってジョブを継続可能とするためであり、所謂、冗長構成というシステム構成である。勿論、Appサーバ２０１、Frontサーバ２０５、Queueサーバ２０３、DBサーバ２０４、およびFileサーバ２０２のそれぞれも、同様に、複数のサーバにより構成しても良い。本実施の形態では、Appサーバ２０１、Frontサーバ２０５、Queueサーバ２０３、DBサーバ２０４、Fileサーバ２０２、およびWorkerサーバＷＳは、クラウドサービス上に、仮想サーバとして存在するが、物理サーバとして構成しても良い。各WorkerサーバＷＳでは、複数のワーカＷのそれぞれがプロセスとして起動している。１つのWorkerサーバＷＳに、複数のワーカＷが存在しても良い。

図３は、第１の実施の形態にかかる情報処理システムのジョブ情報テーブルのデータ構成の一例を示す図である。次に、図３を用いて、ジョブ情報テーブル１０４Ａのデータ構成の一例について説明する。

本実施の形態では、ジョブ情報テーブル１０４Ａは、図３に示すように、ジョブＩＤ、ユーザＩＤ、ステータス、投入日時、ジョブタイプ、およびパラメータ等を対応付けて記憶する。ここで、ジョブＩＤは、ジョブを識別可能とする情報である。ユーザＩＤは、ジョブを依頼したユーザを識別可能とする情報である。ステータスは、ジョブのステータスである。投入日時は、ジョブが依頼された日時である。ジョブタイプは、ジョブの種類（タイプ）である。パラメータは、ジョブを実行する際に用いるパラメータである。

図４は、第１の実施の形態にかかる情報処理システムのタスクステータステーブルのデータ構成の一例を示す図である。次に、図４を用いて、タスクステータステーブル１０４Ｂのデータ構成の一例について説明する。

本実施の形態では、タスクステータステーブル１０４Ｂは、図４に示すように、担当サーバ、担当ワーカ、ジョブＩＤ、ジョブタイプ、ステータス、開始日時、およびユーザＩＤ等を対応付けて記憶する。担当サーバは、担当ジョブを実行するワーカＷを有するWorkerサーバＷＳを示す。担当ワーカは、担当ジョブを実行するワーカＷを示す。ジョブＩＤは、担当ジョブを識別可能とする情報である。ジョブタイプは、担当ジョブのタイプ（種類）である。ステータスは、担当ジョブのステータスである。開始日時は、担当ジョブが開始された日時である。ユーザＩＤは、担当ジョブを依頼したユーザを識別可能とする情報である。

本実施の形態にかかる情報処理システムは、ワーカＷが担当ジョブの実行に使用しているライブラリがメモリ，プロセス，スレッド等の不具合により正常に動作しなくなったり、ライブラリがフリーズしてしまったりした場合に、正常なライブラリを有するワーカＷによって担当ジョブを無事に完了させる。言い換えると、本実施の形態にかかる情報処理システムは、新たなジョブが、異常なライブラリを有するワーカＷにおいて実行されないようにする。これにより、これまで失敗してしまい救済手段がなかったジョブを成功させることができる。

具体的には、ワーカＷは、担当ジョブにエラーが発生した場合、タスクステータステーブル１０４Ｂに記憶されるステータスのうち、担当ジョブのステータスにエラーを格納する。また、ワーカＷは、タスクステータステーブル１０４Ｂに記憶される担当ジョブのステータスがエラーを示し、担当ジョブを実行したワーカＷが同じWorkerサーバＷＳが有するワーカＷであり、かつ担当ジョブのジョブタイプが、エラーが発生したジョブのジョブタイプと同じである場合、担当ジョブを実行せず、メッセージキュー１０３のキューに対して、担当ジョブを戻す。これにより、あるワーカＷによって担当ジョブを実行できない場合でも、担当ジョブを成功させることができる他のワーカＷによって、担当ジョブが実行される。その結果、担当ジョブの実行でエラーが発生した場合でも、エラーが発生した担当ジョブを救済可能となる。

図５は、第１の実施の形態にかかる情報処理システムにおけるジョブの実行処理の流れの一例を示すシーケンス図である。次に、図５を用いて、本実施の形態にかかる情報処理システムのワーカＷ２－１におけるジョブの実行処理の流れの一例について説明する。

例えば、ワーカＷ２－１が、メッセージキュー１０３のキューから、担当ジョブ（例えば、ジョブタイプがimage2pdfの担当ジョブ）を取得する（ステップＳ５２１）。また、ワーカＷ２－１は、タスクステータステーブル１０４Ｂに記憶されるステータスのうち、取得した担当ジョブのステータスがエラーとなっていないか否かをチェックする（ステップＳ５２２）。取得した担当ジョブのステータスがエラーとなっていない場合、ワーカＷ２－１は、ジョブ情報テーブル１０４Ａから、担当ジョブのジョブ情報を取得する（ステップＳ５２３）。

次に、ワーカＷ２－１は、共有ファイルストレージ１０２から、取得したジョブ情報に基づいて、担当ジョブを実行する処理対象ファイルを取得する（ステップＳ５２４）。そして、ワーカＷ２－１は、取得した処理対象ファイルに対するジョブ（例えば、画像からＰＤＦへの変換処理）を開始する（ステップＳ５２５）。その際、ＰＤＦライブラリにメモリアクセス違反等によって担当ジョブにエラーが発生した場合、ワーカＷ２－１は、タスクステータステーブル１０４Ｂに記憶されるステータスのうち、WorkerサーバＷＳ２のワーカＷによる担当ジョブのステータス（例えば、図４に示すタスクステータステーブル１０４Ｂにおいて、ジョブＩＤ：３と対応付けられるステータス）にエラーになったことを記録する（ステップＳ５２６）。また、ワーカＷ２－１は、ジョブ情報テーブル１０４Ａに記憶されるステータスのうち、担当ジョブのステータス（例えば、図４に示すジョブ情報テーブル１０４ＡのジョブＩＤ：３と対応付けられるステータス）にエラーを記録する（ステップＳ５２７）。また、ワーカＷ２－１は、実行中の担当ジョブを、メッセージキュー１０３のキューに戻す（ステップＳ５２８）。

図６は、第１の実施の形態にかかる情報処理システムにおいて担当ジョブのキューをメッセージキューに戻す処理の流れの一例を示すシーケンス図である。次に、図６を用いて、本実施の形態にかかる情報処理システムにおいて担当ジョブのキューをメッセージキュー１０３に戻す処理の流れの一例について説明する。

ワーカＷ２－１は、メッセージキュー１０３のキューのうち、担当ジョブのキューをポーリングする。そして、エラーが発生した担当ジョブのキュー（例えば、ジョブＩＤ：３のキュー）を取得してしまった場合（ステップＳ６０１）、ワーカＷ２－１は、タスクステータステーブル１０４Ｂにおいて、取得したキューの担当ジョブのジョブＩＤと対応付けられるステータスがエラーであるか否かをチェックする（ステップＳ６０２）。

従来の情報処理システムでは、ワーカＷ２－１のＰＤＦライブラリにエラーが発生した状態のため、ワーカＷ２－１がジョブＩＤ：３の担当ジョブを実行しても、同じエラーが発生してしまう可能性が高い。そのため、従来の情報処理システムは、ワーカＷ２－１は無限に担当ジョブの実行を繰り返してしまうため、同じ担当ジョブの実行を繰り返す回数を２回までと決めておき、担当ジョブがエラーになったことをユーザに伝えて、担当ジョブの実行を終了させる。

これに対して、本実施の形態では、ワーカＷ２－１は、ステップＳ６０２においてチェックしたステータスがエラーを示している場合、タスクステータステーブル１０４Ｂにおいて、エラーを示すステータスと対応付けられるワーカＷを有するWorkerサーバＷＳが、ワーカＷ２－１を有するWorkerサーバＷＳ２であるか否かを判断する。すなわち、ワーカＷ２－１は、ステータスがエラーとなっている担当ジョブを実行したWorkerサーバＷＳが、当該ワーカＷ２－１を有するWorkerサーバＷＳ２と同じであるか否かを判断する。そして、エラーを示すステータスと対応付けられるワーカＷを有するWorkerサーバＷＳが、ワーカＷ２－１を有するWorkerサーバＷＳである場合、ワーカＷ２－１は、担当ジョブを実行せず、取得した担当ジョブを、メッセージキュー１０３のキューに戻す（ステップＳ６０３）。

図７は、第１の実施の形態にかかる情報処理システムにおけるワーカにおける担当ジョブの実行処理の流れの一例を示すシーケンス図である。次に、図７を用いて、本実施の形態にかかる情報処理システムにおけるワーカＷ１－１における担当ジョブの実行処理の流れの一例について説明する。

ワーカＷ１－１は、メッセージキュー１０３のキューから、担当ジョブ（例えば、ジョブタイプがimage2pdfの担当ジョブ）を取得する（ステップＳ７１１）。また、ワーカＷ１－１は、タスクステータステーブル１０４Ｂに記憶されるステータスのうち、取得した担当ジョブのステータスがエラーとなっているか否かをチェックする（ステップＳ７１２）。

取得した担当ジョブのステータスがエラーとなっているが、タスクステータステーブル１０４Ｂにおいて、当該ステータスと対応付けられるWorkerサーバＷＳが、ワーカＷ１－１を有するWorkerサーバＷＳ１ではないので、ワーカＷ１－１は、ジョブ情報テーブル１０４Ａから、担当ジョブのジョブ情報を取得する（ステップＳ７１３）。また、ワーカＷ１－１は、共有ファイルストレージ１０２から、取得したジョブ情報に基づいて、処理対象ファイルを取得する（ステップＳ７１４）。

そして、ワーカＷ１－１は、取得した処理対象ファイルに対して担当ジョブ（例えば、画像からＰＤＦへの変換処理）を実行する（ステップＳ７１５）。担当ジョブが完了すると、ワーカＷ１－１は、担当ジョブの処理結果ファイルを、共有ファイルストレージ１０２に格納（保存）する（ステップＳ７１６）。また、ワーカＷ１－１は、ジョブ情報テーブル１０４Ａにおいて、担当ジョブと対応付けられるステータスに完了を記録する（ステップＳ７１７）。

このように、第１の実施の形態にかかる情報処理システムによれば、あるワーカＷによって担当ジョブを実行できない場合でも、担当ジョブを成功させることができる他のワーカＷによって、担当ジョブが実行される。その結果、担当ジョブの実行でエラーが発生した場合でも、エラーが発生した担当ジョブを救済可能となる。

（第２の実施の形態）
本実施の形態は、ワーカが、メッセージキューのキューに対して、担当ジョブを戻す際、メッセージキューの先頭のキューに、担当ジョブを戻す例である。以下の説明では、第１の実施の形態と同様の構成については説明を省略する。

本実施の形態では、ワーカＷは、メッセージキュー１０３のキューに対して、担当ジョブを戻す際、メッセージキュー１０３の先頭のキューに、担当ジョブを戻す。これにより、担当ジョブにエラーが発生して、メッセージキュー１０３のキューに対して担当ジョブが戻された際に、当該担当ジョブの実行が後回しになり、当該担当ジョブが完了するのに時間がかかることを軽減できる。

図８は、第２の実施の形態にかかる情報処理システムにおけるワーカがメッセージキューのキューに担当ジョブを戻す処理の一例を説明するための図である。例えば、図６のステップＳ６０４において、ジョブＩＤ：３の担当ジョブを、メッセージキュー１０３（例えば、ジョブタイプがimage2pdfのメッセージキュー１０３）に対して戻す際、従来の情報処理システムでは、図８（１）に示すように、メッセージキュー１０３のキューのうち、ジョブＩＤ:４，６のジョブのキューの後に、ジョブＩＤ：３の担当ジョブが戻される。そのため、ジョブＩＤ：３の担当ジョブは、ジョブＩＤ：４，６のジョブの後に処理されることになり、ジョブＩＤ：３の担当ジョブが完了するのに時間がかかる。

そこで、本実施の形態では、図６のステップＳ６０４において、ジョブＩＤ：３の担当ジョブを、メッセージキュー１０３（例えば、ジョブタイプがimage2pdfのメッセージキュー１０３）のキューに対して戻す際、ワーカＷ２－１は、図８（２）に示すように、メッセージキュー１０３のキューのうち、ジョブＩＤ：４，６のジョブのキューの前、すなわち、メッセージキュー１０３の先頭のキューに、ジョブＩＤ：３の担当ジョブを戻す。

このように、第２の実施の形態にかかる情報処理システムによれば、担当ジョブにエラーが発生して、メッセージキュー１０３のキューに対して担当ジョブが戻された際に、当該担当ジョブの実行が後回しになり、当該担当ジョブが完了するのに時間がかかることを軽減できる。

（第３の実施の形態）
本実施の形態では、ワーカが、ジョブ情報管理データベースに記憶される担当ジョブのステータスに基づいて、当該担当ジョブ以外に実行可能なジョブが無い場合、同じWorkerサーバが含むワーカによってエラーとなったジョブであっても、担当ジョブを実行する例である。以下の説明では、上述の実施の形態と同様の構成については説明を省略する。

本実施の形態では、ワーカＷは、タスクステータステーブル１０４Ｂに記憶される担当ジョブのステータスに基づいて、当該担当ジョブ以外に実行可能なジョブが無い場合、担当ジョブを実行したワーカＷが同じWorkerサーバＷＳが含むワーカＷによってエラーとなった担当ジョブであっても、当該担当ジョブを実行する。これにより、ワーカＷにおいて担当ジョブのエラーの原因が解消していれば、正常に担当ジョブが実行されて、より早く担当ジョブを実行で、ユーザを待たせる時間を短縮することができる。

図９は、第３の実施の形態にかかる情報処理システムにおけるジョブの実行処理の流れの一例を示すシーケンス図である。次に、図９を用いて、本実施の形態にかかる情報処理システムにおけるジョブの実行処理の流れの一例について説明する。以下の説明では、図６および図７に示す処理と同様の処理については説明を省略する。

図６のステップＳ６０３においては、タスクステータステーブル１０４Ｂから取得した担当ジョブ（ジョブタイプがimage2pdfの担当ジョブ）のステータスがエラーとなっており、当該担当ジョブを実行したワーカＷが、ワーカＷ２－１を有するWorkerサーバＷＳと同じWorkerサーバＷＳである場合、ワーカＷ２－１は、担当ジョブを実行せず、取得した担当ジョブを、メッセージキュー１０３のキューに戻している。しかしながら、ワーカＷ２－１が担当可能な他のジョブ（例えば、ＯＣＲ：Optical Character Recognition）のキューが存在せず、エラーとなった担当ジョブ以外のジョブ（例えば、ジョブタイプがimage2pdfのジョブ）のキューがメッセージキュー１０３に存在しない場合、ワーカＷ２－１は、メッセージキュー１０３に対して担当ジョブのキューを戻す処理のみを実施する状態となり、ジョブの処理効率が下がる可能性がある。また、ワーカＷ２－１のライブラリが一時的な不調で担当ジョブがエラーとなっていたとすると、当該ライブラリが復旧している可能性もある。

そこで、本実施の形態では、タスクステータステーブル１０４Ｂから取得した担当ジョブ（image2pdf）のステータスがエラーとなっており、当該担当ジョブを実行したワーカＷが、ワーカＷ１－１を有するWorkerサーバＷＳと同じWorkerサーバＷＳであり、ワーカＷ１－１が担当可能な他のジョブのキューがメッセージキュー１０３に存在しない場合、ワーカＷ１－１は、当該ワーカＷ１－１が担当可能な他の担当ジョブ（ジョブタイプがimage2pdfのジョブ）のキューがメッセージキュー１０３に存在するか否かをチェックする（ステップＳ９０１）。

そして、ワーカＷ２－１が担当可能な他の担当ジョブのキューがメッセージキュー１０３に存在する場合には、ワーカＷ２－１は、図６のステップＳ６０３と同様に、担当ジョブを実行せず、取得した担当ジョブを、メッセージキュー１０３のキューに戻す。一方、ワーカＷ２－１が担当可能な他の担当ジョブがメッセージキュー１０３のキューに存在しない場合、ワーカＷ２－１は、図７のステップＳ７１３～Ｓ７１７と同様にして、担当ジョブを試しに実行する。

このように、第３の実施の形態にかかる情報処理システムによれば、ワーカＷにおいて担当ジョブのエラーの原因が解消していれば、正常に担当ジョブが実行されて、より早く担当ジョブを実行で、ユーザを待たせる時間を短縮することができる。

（第４の実施の形態）
本実施の形態は、ワーカが、ジョブ情報管理データベースに記憶されるエラー情報に基づいて、再実行が成功するジョブを再実行する例である。以下の説明では、上述の実施の形態と同様の構成については説明を省略する。

本実施の形態では、ジョブ情報テーブル１０４Ａは、再実行が成功するジョブのエラーおよび再実行しても失敗するジョブのエラーを示すエラー情報テーブル（エラー情報の一例）を含む。そして、ワーカＷは、エラー情報テーブルに基づいて、再実行が成功するジョブのみを再実行する。これにより、再実行してもエラーとなるジョブが再実行されることを防止できる。

図１０は、第４の実施の形態にかかる情報処理システムのジョブ情報テーブルに含まれるエラー情報テーブルのデータ構成の一例を示す図である。再実行してもエラーとなるジョブは、再実行しても成功する可能性が低い。例えば、ワーカＷのライブラリが固有に有するデータファイルが壊れてしまっている場合、ユーザがデータファイルを再インストールしない限り、データファイルが自然に復旧することは期待できない。

そこで、本実施の形態では、ジョブ情報テーブル１０４Ａは、図１０に示すように、エラー情報テーブル１０４Ｃを有する。エラー情報テーブル１０４Ｃは、再実行（リトライ）して成功するエラーと、再実行しても失敗するエラーと、を示すテーブルである。例えば、エラー情報テーブル１０４Ｃは、図１０に示すように、ジョブの実行において発生するエラーのコードであるエラーコードと、リトライ可否と、を対応付けるテーブルである。ここで、リトライ可否は、リトライして成功するエラーの場合には「可」を示し、リトライして失敗するエラーの場合には「不可」を示す。そして、ワーカＷは、エラー情報テーブル１０４Ｃに基づいて、再実行して成功するエラーが発生した担当ジョブは再実行し、再実行しても失敗するエラーが発生した担当ジョブは再実行しない。

図１１は、第４の実施の形態にかかる情報処理システムにおけるジョブの実行処理の流れの一例を示すシーケンス図である。次に、図１１を用いて、本実施の形態にかかる情報処理システムにおけるジョブの実行処理の流れの一例について説明する。以下の説明では、図５に示すジョブの実行処理の流れと異なる処理について説明する。

図５に示すジョブの実行処理においては、ＰＤＦライブラリがメモリアクセス違反等により担当ジョブにエラーが発生した場合（ステップＳ５２５）、ワーカＷ２－１は、タスクステータステーブル１０４Ｂにおいて、担当ジョブのジョブＩＤ：３と対応付けられるステータスにエラーを記録している（ステップＳ５２６）。これに対して、本実施の形態では、担当ジョブにエラーが発生した場合（ステップＳ５２５）、ワーカＷ２－１は、ジョブ情報テーブル１０４Ａが有するエラー情報テーブル１０４Ｃを参照して、発生したエラーのエラーコードと対応付けられるリトライ可否が「可」であるか否かを判断する（ステップＳ１１０１）。

そして、発生したエラーのエラーコード（例えば、エラーコード：４９７）と対応付けられるリトライ可否が「可」である場合、すなわち、発生したエラーが再実行により成功するエラーである場合、ワーカＷ２－１は、取得した担当ジョブを再実行すれば成功する可能性があるため、タスクステータステーブル１０４Ｂにおいて、担当ジョブのジョブＩＤ：３と対応付けられるステータスにエラーを記録する（ステップＳ１１０２）。さらに、ワーカＷ２－１は、実行中の担当ジョブをメッセージキュー１０３のキューに戻す（ステップＳ１１０３）。

一方、発生したエラーのエラーコード（例えば、エラーコード：５１５）と対応付けられるリトライ可否が「不可」である場合、すなわち、発生したエラーが再実行しても失敗するエラーである場合、ワーカＷ２－１は、取得した担当ジョブを再実行しても成功する可能性が無いため、タスクステータステーブル１０４Ｂへのステータスの記録、およびメッセージキュー１０３へ担当ジョブのキューを戻す処理を実行しない。そして、ワーカＷ２－１は、ジョブ情報テーブル１０４Ａにおいて担当ジョブのジョブＩＤと対応付けられるステータスにエラーを記録する（ステップＳ１１０４）。これにより、他のワーカＷが当該担当ジョブを実行することを防止できる。

このように、第４の実施の形態にかかる情報処理システムによれば、再実行してもエラーとなるジョブが再実行されることを防止できる。

（第５の実施の形態）
本実施の形態は、ワーカが、メッセージキューに記憶されるキューをポーリング中、ステータスがエラーのジョブ以外に実行可能なジョブが無い場合、予め設定されたテキストファイルに対して、エラーが発生したジョブを実行し、当該ジョブが成功した場合、当該ジョブのステータスからエラーを消去する例である。以下の説明では、上述の実施の形態と同様の構成については説明を省略する。

本実施の形態では、メッセージキュー１０３のキューをポーリング中に、ステータスがエラーのジョブ以外に実行可能なジョブが無い場合、ワーカＷは、予め設定されたテキストファイルに対して、エラーが発生したジョブを実行する。そして、予め設定されたテキストファイルに対して実行したジョブが成功した場合、ワーカＷは、タスクステータステーブル１０４Ｂにおいて当該ジョブのジョブＩＤと対応付けられるステータスからエラーを消去する。これにより、ワーカＷにおいて担当ジョブにエラーが発生したとしても、当該ワーカＷを有するWorkerサーバＷＳにおいて、当該担当ジョブを実行することができる。

図１２は、第５の実施の形態にかかる情報処理システムにおけるテキストファイルに対する担当ジョブの実行処理の流れの一例を示すシーケンス図である。メッセージキュー１０３のキューのうち、担当ジョブ（例えば、ＯＣＲ）のキューをポーリングしたが、当該担当ジョブが無い場合、ワーカＷ１－１は、他のジョブタイプの担当ジョブ（例えば、ジョブタイプがimage2pdfの担当ジョブ）を取得する（ステップＳ１２０１）。次いで、ワーカＷ１－１は、タスクステータステーブル１０４Ｂにおいて、取得した担当ジョブ（例えば、image2pdf）のジョブＩＤと対応付けられるステータスがエラーであるか否かをチェックする（ステップＳ１２０２）。

取得した担当ジョブのステータスがエラーである場合、ワーカＷ１－１は、予め設定されるテキストファイル（例えば、ワーカＷのリリース時にインストールされる、ファイルサイズが小さいテキストファイル）に対して担当ジョブ（例えば、ジョブタイプがimage2pdfのジョブ）を実行する（ステップＳ１２０３）。そして、予め設定されるテキストファイルに対する担当ジョブが成功した場合、ワーカＷ１－１は、担当ジョブ（例えば、ジョブタイプがimage2pdfのジョブ）に用いるＰＤＦライブラリが正常化したと判断し、タスクステータステーブル１０４Ｂにおいて、担当ジョブと対応付けられるステータスを、リトライを待つ状態（retry_waiting）に変更する（ステップＳ１２０４）。

このように、第５の実施の形態にかかる情報処理システムによれば、ワーカＷにおいて担当ジョブにエラーが発生したとしても、当該ワーカＷを有するWorkerサーバＷＳにおいて、当該担当ジョブを実行することができる。

（第６の実施の形態）
本実施の形態は、ワーカは、担当ジョブにエラーが発生した場合に、ワーカ自身のプロセスを再起動する例である。以下の説明では、上述の実施の形態と同様の構成については説明を省略する。

ワーカＷが実行する担当ジョブの一例であるimage2pdfのジョブに用いるＰＤＦライブラリのエラーの多くは、ワーカＷにおいて実行されるプロセスの一時的な停止やメモリの枯渇等、自然回復やＯＳ（Operating System）が回復しくれるエラーである。しかし、ＰＤＦライブラリのエラーの中には、ワーカＷにおいて実行されるプロセスが存続してしまったり、メモリが使用され続けられたりすることによるエラーも存在する。

そこで、本実施の形態では、ワーカＷは、担当ジョブにエラーが発生する場合、ワーカＷ自身のプロセスを再起動させる。これにより、ワーカＷにおいて発生する担当ジョブのエラーを早期に正常化することができる。ワーカＷにおけるプロセスを再起動する方法は、様々用意されているが、ワーカＷ自身が、ＰＤＦライブラリの異常を検知し、再起動用スクリプトに対してプロセスの再起動を依頼して、当該プロセスを終了させる方法が一般的である。または、ワーカＷに予めインストールされるプロセス監視プログラムがプロセスを監視し、当該プロセスにエラーが発生した場合に当該プロセスを再起動させる方法であっても良い。

本実施の形態では、情報処理システムは、ワーカＷ自身のプロセスを再起動させても、担当ジョブにエラーが発生する場合、当該ワーカＷ自身が存在するWorkerサーバＷＳを再起動させる。例えば、ワーカＷは、Zabbix運用等で用いる監視スクリプトによって、ワーカＷの異常が予め設定された時間経過しても解消されない場合に、WorkerサーバＷＳのＯＳを再起動させる指示を行う。

本実施の形態では、情報処理システムは、WorkerサーバＷＳを再起動させても、担当ジョブにエラーが発生する場合、すなわち、担当ジョブにエラーが発生したワーカＷが含まれるWorkerサーバＷＳの全てのワーカＷにおいて担当ジョブのエラーが解消しなかった場合、新たなサーバインスタンスを起動させて、当該ワーカＷが存在するWorkerサーバＷＳシャットダウンする。例えば、WorkerサーバＷＳを再起動させてもＰＤＦライブラリを正常化することができない場合、当該ＰＤＦライブラリそのもののデータの一部が破損している可能性が高い。この場合、ワーカＷにＰＤＦライブラリを再インストールすることにより、ワーカＷを正常化することができるが、クラウドシステムにおいて夜間にエラーが発生した場合には、その対応が困難である。

ＡＷＳやAzure等のクラウド基盤には、正常な状態のサーバインスタンスが残されており、そのサーバインスタンスを複製して立ち上げる機能が備わっている。そこで、Zabbix等の監視によってワーカＷのエラーを検出した場合には、ワーカＷは、サーバインスタンスを複製して立ち上げる機能を用いて、WorkerサーバＷＳのサーバインスタンスを新しく立ち上げ、古いWorkerサーバＷＳのサーバインスタンスを停止させる。これにより、夜間に異常が発生した場合でも、担当ジョブの実行を継続できる。

このように、第６の実施の形態にかかる情報処理システムによれば、ワーカＷにおいて発生する担当ジョブのエラーを早期に正常化することができる。

上記で説明した実施の形態の各機能は、一又は複数の処理回路によって実現することが可能である。ここで、本明細書における「処理回路」とは、電子回路により実装されるプロセッサのようにソフトウェアによって各機能を実行するようプログラミングされたプロセッサや、上記で説明した各機能を実行するよう設計されたＡＳＩＣ（Application Specific Integrated Circuit）、ＤＳＰ（Digital Signal Processor）、ＦＰＧＡ（Field Programmable Gate Array）や従来の回路モジュール等のデバイスを含むものとする。

本実施の形態に記載された装置群は、本明細書に開示された実施形態を実施するための複数のコンピューティング環境のうちの１つを示すものにすぎない。ある実施の形態では、Appサーバ２０１、Fileサーバ２０２、Queueサーバ２０３、DBサーバ２０４、およびFrontサーバ２０５は、サーバクラスタといった複数のコンピューティングデバイスを含む。複数のコンピューティングデバイスは、ネットワークや共有メモリなどを含む任意のタイプの通信リンクを介して互いに通信するように構成されており、本明細書に開示された処理を実施する。同様に、WorkerサーバＷＳ１，ＷＳ２は、互いに通信するように構成された複数のコンピューティングデバイスを含むことができる。

なお、各種サーバ５は、通信機能を備えた装置であれば、画像形成装置に限られない。各種サーバ５は、例えば、ＰＪ（Projector：プロジェクタ）、ＩＷＢ（Interactive White Board：相互通信が可能な電子式の黒板機能を有する白板）、デジタルサイネージ等の出力装置、ＨＵＤ（Head Up Display）装置、産業機械、撮像装置、集音装置、医療機器、ネットワーク家電、自動車（Connected Car）、ノートＰＣ（Personal Computer）、携帯電話、スマートフォン、タブレット端末、ゲーム機、ＰＤＡ（Personal Digital Assistant）、デジタルカメラ、ウェアラブルＰＣまたはデスクトップＰＣ等であってもよい。

１０１ フロントエンドアプリ
１０２ 共有ファイルストレージ
１０３ メッセージキュー
１０４ ジョブ情報管理ＤＢ
１０５ ドキュメント処理要求管理部
２０１ Appサーバ
２０２ Fileサーバ
２０３ Queueサーバ
２０４ DBサーバ
２０５ Frontサーバ
Ｗ１－１，Ｗ１－２，Ｗ２－１，Ｗ２－２ ワーカ
ＷＳ１，ＷＳ２ Workerサーバ

特開２０２０－１４４６０６号公報

Claims (10)

1. ジョブの実行を依頼するフロントエンドアプリと、
   前記ジョブの処理対象ファイルおよび前記ジョブの処理結果ファイルを記憶する共有ファイルストレージと、
   前記ジョブがキューイングされるキューを有するメッセージキューと、
   前記ジョブのジョブ情報および前記ジョブのステータスを記憶するジョブ情報管理データベースと、
   前記ジョブの実行の依頼を受け付け、前記ジョブ情報管理データベースに対して、前記ジョブ情報を格納し、前記キューに前記ジョブをキューイングするドキュメント処理要求管理部と、
   前記メッセージキューから、担当する前記ジョブである担当ジョブを取得し、前記ジョブ情報管理データベースから、前記担当ジョブの前記ジョブ情報を取得し、前記共有ファイルストレージから、取得した前記ジョブ情報に基づいて、前記処理対象ファイルを取得し、取得した前記処理対象ファイルに対して前記担当ジョブを実行した後、当該担当ジョブの前記処理結果ファイルを前記共有ファイルストレージに格納する情報処理装置と、を備え、
   前記情報処理装置は、
   前記担当ジョブにエラーが発生した場合、前記ジョブ情報管理データベースに記憶される前記ステータスのうち前記担当ジョブの前記ステータスにエラーを格納し、
   前記担当ジョブの前記ステータスがエラーを示し、前記担当ジョブを実行した前記情報処理装置が、同じサーバが含む前記情報処理装置であり、かつ前記担当ジョブのタイプがエラーが発生した前記ジョブのタイプと同じである場合、前記担当ジョブを実行せず、前記キューに対して、前記担当ジョブを戻す、情報処理システム。
2. 前記情報処理装置は、前記キューに対して、前記担当ジョブを戻す際、前記メッセージキューの先頭の前記キューに、前記担当ジョブを戻す、請求項１に記載の情報処理システム。
3. 前記情報処理装置は、前記ジョブ情報管理データベースに記憶される前記ステータスに基づいて、前記担当ジョブ以外に担当可能な前記ジョブが無い場合、同じサーバが含む前記情報処理装置によってエラーとなった前記ジョブであっても、前記担当ジョブを実行する、請求項１または２に記載の情報処理システム。
4. 前記ジョブ情報管理データベースは、さらに、再実行が成功する前記ジョブのエラーおよび再実行しても失敗する前記ジョブのエラーを示すエラー情報を記憶し、
   前記情報処理装置は、前記ジョブ情報管理データベースに記憶される前記エラー情報に基づいて、再実行が成功する前記担当ジョブを再実行する、請求項１から３のいずれか一つに記載の情報処理システム。
5. 前記情報処理装置は、前記メッセージキューに記憶される前記キューのポーリング中、前記ステータスがエラーの前記ジョブ以外に実行可能な前記ジョブが無い場合、予め設定されたテキストファイルに対して、エラーが発生した前記ジョブを実行し、当該ジョブが成功した場合、当該ジョブの前記ステータスからエラーを消去する、請求項１から４のいずれか一つに記載の情報処理システム。
6. 前記情報処理装置は、前記担当ジョブにエラーが発生した場合、当該情報処理装置自身のプロセスを再起動する、請求項１から５のいずれか一つに記載の情報処理システム。
7. 前記情報処理システムは、前記担当ジョブにエラーが発生した場合、前記情報処理装置を含むサーバを再起動する、請求項１から６のいずれか一つに記載の情報処理システム。
8. 前記担当ジョブにエラーが発生した前記情報処理装置が含まれるサーバの全ての前記情報処理装置においても前記担当ジョブのエラーが解消しなかった場合、新たなサーバインスタンスを起動させ、前記サーバをシャットダウンする、請求項１から７のいずれか一つに記載の情報処理システム。
9. ジョブがキューイングされるキューを有するメッセージキューから、担当する前記ジョブである担当ジョブを取得し、前記ジョブのジョブ情報および前記ジョブのステータスを記憶するジョブ情報管理データベースから、前記担当ジョブの前記ジョブ情報を取得し、前記ジョブの処理対象ファイルおよび前記ジョブの処理結果ファイルを記憶する共有ファイルストレージから、取得した前記ジョブ情報に基づいて、前記処理対象ファイルを取得し、取得した前記処理対象ファイルに対して前記担当ジョブを実行した後、当該担当ジョブの前記処理結果ファイルを前記共有ファイルストレージに格納する情報処理装置であって、
   前記担当ジョブにエラーが発生した場合、前記ジョブ情報管理データベースに記憶される前記ステータスのうち前記担当ジョブの前記ステータスにエラーを格納し、
   前記担当ジョブの前記ステータスがエラーを示し、前記担当ジョブを実行した前記情報処理装置が、同じサーバが含む前記情報処理装置であり、かつ前記担当ジョブのタイプがエラーが発生した前記ジョブのタイプと同じである場合、前記担当ジョブを実行せず、前記キューに対して、前記担当ジョブを戻す、情報処理装置。
10. 情報処理装置で実行される情報処理方法であって、
    ジョブがキューイングされるキューを有するメッセージキューから、担当する前記ジョブである担当ジョブを取得する工程と、
    前記ジョブのジョブ情報および前記ジョブのステータスを記憶するジョブ情報管理データベースから、前記担当ジョブの前記ジョブ情報を取得する工程と、
    前記ジョブの処理対象ファイルおよび前記ジョブの処理結果ファイルを記憶する共有ファイルストレージから、取得した前記ジョブ情報に基づいて、前記処理対象ファイルを取得する工程と、
    取得した前記処理対象ファイルに対して前記担当ジョブを実行した後、当該担当ジョブの前記処理結果ファイルを前記共有ファイルストレージに格納する工程と、
    前記担当ジョブにエラーが発生した場合、前記ジョブ情報管理データベースに記憶される前記ステータスのうち前記担当ジョブの前記ステータスにエラーを格納する工程と、
    前記担当ジョブの前記ステータスがエラーを示し、前記担当ジョブを実行した前記情報処理装置が、同じサーバが含む前記情報処理装置であり、かつ前記担当ジョブのタイプがエラーが発生した前記ジョブのタイプと同じである場合、前記担当ジョブを実行せず、前記キューに対して、前記担当ジョブを戻す工程と、
    を含む情報処理方法。

Images