JP5602592B2 - ネットワークシステム、サーバ、ログ登録方法、及び、プログラム - Google Patents

Description

本発明は、画像形成装置におけるログをインターネット上で登録するための制御に関する。

従来より、プリンタ、スキャナ、ファクシミリ、複写機、及びこれらを統合したマルチファンクションプリンタ（ＭＦＰ）等の画像形成装置で実行されたジョブの履歴（ジョブログ）を効率的に管理するためのジョブ管理方法が開発されている。ジョブログの収集方法は、画像形成装置にジョブログの送信が可能となるアプリケーションを導入し、画像形成装置自身がジョブログを送る方法がある（特許文献１）。

また、ジョブログの収集方法には、ネットワーク上のサーバコンピュータ等が各種画像形成装置で実行された各ジョブのジョブログを当該画像形成装置から取得する方法がある。

従来では、ジョブログを登録する際、ジョブログを送信する画像形成装置側とジョブログを登録するサーバ側が通信を維持（同期）した状態で、登録の処理が行われていた。
近年、サーバコンピュータ側で各種処理を行う形態として、クラウドコンピューティングシステムやＳａａＳ（Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）という技術が利用され始めている。

クラウドコンピューティングでは、多くのコンピューティング・リソースを利用し、データ処理を分散実行することで、多くの要求を同時に処理することが可能となる。以下、コンピューティング・リソースを利用し機能を提供する、１つの処理の実態を「インスタンス」と総称する。

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

画像形成装置からジョブログを収集するジョブログ収集サーバや画像形成装置などから、クラウドを構成するサーバコンピュータ群にジョブログを登録する形態を考える。以下、ジョブログをサーバコンピュータ群へ登録するジョブログ収集サーバや画像形成装置のことを「クライアント」と総称する。

従来のジョブログ登録方法のように、同期した状態でジョブログを登録すると、登録の処理が開始されてから完了するまでインスタンスが占有されてしまう。また、従来のジョブログ登録はイントラネットで行われていたため、システム側は、クライアントの数を把握することができた。このため、登録のタイミングをスケージューリングすることで、ストレスの少ない、ジョブログの登録を実現していた。

しかしながら、インターネット環境でジョブログ登録を行うようになると、システム側は、どのタイミングでどれくらいの数のクライアントからアクセスされるか把握することができなくなってしまった。このため、多くのクライアントから同時に登録要求を受ける可能性が生じてしまう。なお、クラウドコンピューティングでは、多くのインスタンスを利用し、データ処理を分散実行することで、多くのクライアントからの要求を同時に処理することが可能である。

しかしながら、クラウドコンピューティングでジョブログ収集システムを実現させるには、複数のクライアントから同時アクセスされても安定した運用を行うため多くのインスタンスを長時間起動させておく必要がある。クラウドコンピューティングは、インスタンスの数を自由に設定することで、多くのリソースを自由に利用できることを特徴とするが、インスタンスの起動時間に応じて課金が行われ、数を増やせば増やすほど運用コストが増加してしまうという問題があった。

本発明は、上記の問題点を解決するためになされたものである。本発明の目的は、クラウドコンピューティングでのインスタンスの総起動時間を減らしログ登録の運用コストを削減する仕組みを提供することである。

本発明は、クライアントと、前記クライアントと通信可能な１台以上のサーバコンピュータからなるサーバコンピュータ群で構成されるサーバとを有するネットワークシステムであって、前記サーバは、前記クライアントから取得したログを保存するための保存手段と、前記クライアントから送信されるログの登録予約要求を受け付けて、前記クライアントから前記保存手段に最後に登録されたログの識別情報を、前記クライアントに返信する１又は複数の登録予約要求受付手段と、前記クライアントから送信されるログの登録要求を受け付けて、前記ログを一時保存手段に保存し、前記登録要求を処理するための実行命令データを登録命令保存手段に登録する１又は複数の登録要求受付手段と、前記登録命令保存手段への実行命令データの登録とは非同期で前記登録命令保存手段から前記実行命令データを取得して前記一時保存手段に保存された前記ログを前記保存手段に登録処理する１又は複数の登録処理手段とを有し、前記クライアントは、ログを保持する保持手段と、前記保持手段に保持されるログの登録予約要求を前記登録予約要求受付手段に送信する登録予約要求送信手段と、前記登録予約要求の送信に応じて返信されるログの識別情報に基づいて登録要求するログを前記保持手段に保持されるログから選択する選択手段と、前記選択手段により選択されたログを前記登録要求受付手段に送信して登録要求する登録要求送信手段とを有する、ことを特徴とする。

本発明によれば、クラウドコンピューティングでのインスタンスの総起動時間を減らしログ登録の運用コストを削減することができる。

本発明のネットワークシステムの一実施例を示すログ登録システムの構成の一例を示す図である。 サーバコンピュータ群１０２を構成する各サーバコンピュータやジョブログ収集サーバ１０３を構成する情報処理装置の内部構成の一例を示すブロック図である。 画像形成装置１０４の内部構成の一例を示すブロック図である。 本実施例のジョブログ登録システムにおける各装置の機能ブロック図である。 サーバコンピュータ群１０２内の各種機能を示した図である。 本実施例におけるジョブログの一例を示す図である。 本実施例におけるサーバコンピュータ群１０２内で保存されるデータを示す図である。 実施例１におけるサービスが実装すべきインタフェースの構造図である。 実施例１のジョブログ登録システムにおける処理の流れの一例を示すシーケンス図である。 第１実施例におけるジョブログ収集サーバ１０３のジョブログ登録処理の一例を示すフローチャートである。 第１実施例におけるサーバコンピュータ群１０２のジョブログ登録処理の一例を示すフローチャートである。 実施例２におけるサービスが実装すべきインタフェースの構造図である。 実施例２のジョブログ登録システムにおける処理の流れの一例を示すシーケンス図である。 実施例２におけるジョブログ収集サーバ１０３のジョブログ登録処理に一例を示すフローチャートである。

以下、本発明を実施するための形態について図面を用いて説明する。

本発明のネットワークシステムの一実施例としてのログ登録システムの構成について、図１を参照して詳細に説明する。
図１は、本発明のネットワークシステムの一実施例を示すログ登録システムの構成の一例を示す図である。
図１に示すように、本実施例のログ登録システムでは、ネットワークシステムを構成している各装置が、ネットワーク１００、インターネット１０１を介して接続されている。ネットワークシステムを構成している各装置とは、サーバコンピュータ群１０２、ジョブログ収集サーバ１０３、画像形成装置１０４などである。

ネットワーク１００は、上述の各装置の間で情報をやり取りするための通信回線である。インターネット１０１は、ファイアウォールを越えて上述の各装置間で情報をやり取りするための通信回線である。インターネット１０１を介して、ジョブログ収集サーバ１０３と画像形成装置１０４が属するネットワーク１００から、サーバコンピュータ群１０２などが属するネットワーク１００と、ファイアウォールを越えて通信が可能である。ネットワーク１００、インターネット１０１は、例えば、ＴＣＰ／ＩＰプロトコルなどをサポートする通信回線網であり有線・無線は問わない。

サーバコンピュータ群１０２は、１台以上のサーバコンピュータで構成されている。サーバコンピュータ群１０２にジョブログを送信するジョブログ収集サーバ１０３や画像形成装置１０４などを、以下、「クライアント」と総称する。
なお、本発明の各実施例では、本発明のネットワークシステムの一実施例を示すログ登録システムにおいて、ジョブログ（ジョブの履歴）を登録する例を説明する。しかし、本発明のネットワークシステムにおいて登録するログはジョブログに限定されるものではなく、画像形成装置１０４のログ、収集サーバ１０３で収集可能なログであればどのような種類のログでもよい。

以下、図１のプリントシステムを構成している各装置の内部構成について詳細に説明する。

まず、サーバコンピュータ群１０２を構成する各サーバコンピュータやジョブログ収集サーバ１０３の内部構成について図２を用いて説明する。

図２は、サーバコンピュータ群１０２を構成する各サーバコンピュータやジョブログ収集サーバ１０３を構成する情報処理装置の内部構成の一例を示すブロック図である。
図２において、２００はコンピュータ全体（ＰＣ）である。ＰＣ２００において、２０１はＣＰＵである。ＣＰＵ２０１は、ＲＯＭ２０２あるいは大規模記憶装置（例えばハードディスク（ＨＤ）２１１）に記憶されたソフトウェア（プログラム）を実行して、システムバス２０５に接続される各装置を総括的に制御する。なお、大規模記憶装置は、ＨＤ以外の媒体（例えば、フラッシュメモリ等）で実現されても良い。

２０３はＲＡＭで、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。２０４はネットワークインタフェースカード（ＮＩＣ）で、ネットワーク１００を介して、他のノードと双方向にデータをやりとりする。

２０６はキーボードコントローラ（ＫＢＤＣ）で、ＰＣ２００に備えられたキーボード（ＫＢＤ）２０９や不図示のポインティングデバイスからの指示入力を制御する。２０７はディスプレイコントローラ（ＤＩＳＰＣ）で、例えば液晶ディスプレイなどで構成される表示モジュール（ＤＩＳＰＬＡＹ）２１０の表示を制御する。２０８はディスクコントローラ（ＤＫＣ）で、大容量記憶画像形成装置としてのハードディスク（ＨＤ）２１１を制御する。

次に、画像形成装置１０４の内部構成について図３を用いて説明する。
図３は、画像形成装置１０４の内部構成の一例を示すブロック図である。
図３において、３００は画像形成装置全体である。画像形成装置３００において、３０１はＣＰＵである。ＣＰＵ３０１は、ＲＯＭ３０２あるいは大規模記憶装置（例えばハードディスク（ＨＤ）３１３）に記憶されたソフトウェア（プログラム）を実行して、システムバス３０５に接続される各装置を総括的に制御する。なお、大規模記憶装置は、ＨＤ以外の媒体（例えば、フラッシュメモリ等）で実現されても良い。

３０３はＲＡＭで、ＣＰＵ３０１の主メモリ、ワークエリア等として機能する。３０４はネットワークインタフェースカード（ＮＩＣ）で、ネットワーク１００を介して、他のノードとデータをやりとりする。

３０６はパネルコントローラ（ＰＡＮＥＬＣ）で、画像形成装置に備えられたオペレーションパネル（ＰＡＮＥＬ）３１１からの指示入力を制御する。３０７はディスプレイコントローラ（ＤＩＳＰＣ）で、例えば液晶ディスプレイなどで構成される表示モジュール（ＤＩＳＰＬＡＹ）３１２の表示を制御する。３０８はディスクコントローラ（ＤＫＣ）であり、大容量記憶画像形成装置であるハードディスク（ＨＤ）３１３を制御する。

３０９はスキャナコントローラ（ＳＣＡＮＣ）で、画像形成装置に備えられた光学式スキャナ装置（スキャナ）３１４を制御し、紙原稿の読み取りを行う。３１０はプリンタコントローラ（ＰＲＮＣ）で、画像形成装置に備えられたプリンタ装置（プリンタ）３１５を制御し、電子写真技術やインクジェット技術などの既知の印刷技術を利用して実際の用紙に印刷を行う。

なお、画像形成装置１０４の内部構成は、図３に示した画像形成装置３００よりスキャナコントローラ３０９及び光学式スキャナ装置３１４を除いたものであってもよい。さらに、画像形成装置１０４の内部構成は、画像形成装置３００よりパネルコントローラ（ＰＡＮＥＬＣ）３０６、オペレーションパネル３１１、ディスプレイコントローラ（ＤＩＳＰＣ）３０７、表示モジュール（ＤＩＳＰＬＡＹ）３１２などを取り除いた構成でもよい。

以下、本実施例のジョブログ登録システムにおいて各装置が持つ機能について、図４を参照しながら詳細に説明する。
図４は、本実施例のジョブログ登録システムにおける各装置の機能ブロック図である。
始めに、サーバコンピュータ群１０２の機能について説明する。
サーバコンピュータ群１０２には、要求受信部４０１、バックエンド処理部４０２、テーブルストレージサービス４０３、ブロブストレージサービス４０４、キューストレージサービス４０５の機能がある。

本実施例では、要求受信部４０１を持つサーバコンピュータが少なくとも１台以上は存在する。また、バックエンド処理部４０２を持つサーバコンピュータが少なくとも１台以上は存在する。また、テーブルストレージサービス４０３、ブロブストレージサービス４０４、キューストレージサービス４０５の各機能を持つサーバコンピュータが少なくとも１台以上は存在する。

要求受信部４０１は、ジョブログ収集サーバ１０３、又は画像形成装置１０４から送られてきた処理依頼を受け付ける機能を持つ。バックエンド処理部４０２は、処理プログラムを用いて処理依頼に対する処理を行う機能を持つ。具体的には、バックエンド処理部４０２は、バックエンド処理部４０２を実行しているサーバコンピュータのメモリに処理プログラムをロードし処理依頼に対する処理を行う。

要求受信部４０１は、サーバコンピュータ群１０２を構成する情報処理装置（図２）のＲＯＭ２０２又はＨＤ２１１に保存されている要求受信プログラムが、ＲＡＭ２０３にロードされて、ＣＰＵ２０１により実行されることで実現される。また、バックエンド処理部４０２は、サーバコンピュータ群１０２を構成する情報処理装置（図２）のＲＯＭ２０２又はＨＤ２１１に保存されているバックエンド処理プログラムが、ＲＡＭ２０３にロードされて、ＣＰＵ２０１により実行されることで実現される。なお、要求受付部４０１とバックエンド処理部４０２はそれぞれ、サーバコンピュータ群１０２内に１つではなく、複数存在しても良い。なお、要求受信部４０１は、後述する図８、図１２に示す登録要求受付部８０１、登録確認要求受付部８０９、登録予約要求受付部１２０１に対応する。また、バックエンド処理部４０２は、後述する図８、図１２に示す登録処理部８０５、登録確認処理部８０８、登録インスタンス作成部１２０３に対応する。

テーブルストレージサービス４０３は、ジョブログの格納を行う機能を持つ。ジョブログの登録は、バックエンド処理部４０２の登録処理により行われる。テーブルストレージサービス４０３は、サーバコンピュータ群１０２を構成する情報処理装置（図２）のＲＯＭ２０２又はＨＤ２１１に保存されているテーブルストレージサービスプログラムが、ＲＡＭ２０３にロードされて、ＣＰＵ２０１により実行されることで実現される。また、テーブルストレージサービス４０３で格納したデータはＲＯＭ２０２又はＨＤ２１１によって保管される。なお、テーブルストレージサービス４０３は、後述する図８、図１２に示すジョブログ保存部８０４、登録情報保存部８０７に対応する。

ブロブストレージサービス４０４は、要求受信部４０１によりクライアントから受け付けたジョブログを一時的に保存しておく機能を持つ。ブロブストレージサービス４０４は、サーバコンピュータ群１０２を構成する情報処理装置（図２）のＲＯＭ２０２又はＨＤ２１１に保存されているブロブストレージサービスプログラムが、ＲＡＭ２０３にロードされて、ＣＰＵ２０１により実行されることで実現される。また、ブロブストレージサービス４０４で保存したデータは、ＲＯＭ３０２またはＨＤ３１３によって保管される。なお、ブロブストレージサービス４０４は、後述する図８、図１２に示す圧縮データ一時保存部８０３に対応する。

キューストレージサービス４０５は、次のような機能を持つ。１つ目は、要求受信部４０１とバックエンド処理部４０２とが非同期でデータ通信するための機能を持つ。２つ目は、キューに追加されているキューメッセージを不可視、または可視にする機能を持つ。

１つ目の機能について説明する。要求受信部４０１とバックエンド処理部４０２は次のような方法で通信する。始めに、ユーザからの処理依頼を受けた要求受信部４０１は、ユーザからの処理依頼に応じたキューメッセージと呼ばれるチケットを作成する。キューメッセージは要求受信部４０１によってキューに格納される。バックエンド処理部４０２はキューからキューメッセージを取得する。バックエンド処理部４０２は、キューメッセージを取得し、キューメッセージを参照してユーザからの処理依頼を処理する。これにより、ユーザからの処理依頼を解決することになる。このように、キューストレージサービス４０５を利用することで要求受信部４０１とバックエンド処理部４０２は非同期で通信を行うことが可能になる。１つ目の機能のさらに詳細な説明と２つ目の機能の説明については後述する。

なお、キューストレージサービス４０５は、サーバコンピュータ群１０２を構成する情報処理装置（図２）のＲＯＭ２０２又はＨＤ２１１に保存されているキューストレージサービスプログラムが、ＲＡＭ２０３にロードされて、ＣＰＵ２０１により実行されることで実現される。また、キューストレージサービス４０５が保持するデータは、ＲＯＭ３０２またはＨＤ３１３によって保管される。なお、キューストレージサービス４０５は、後述する図８、図１２に示す第一実行命令データ保存部８０２、第二実行命令データ保存部８０６、第三実行命令データ保存部１２０２に対応する。

次に、ジョブログ収集サーバ１０３について、詳細に説明する。
ジョブログ収集サーバ１０３は、ジョブログ送信部４０６、及び、登録情報通信部４０７の機能を有する。ジョブログ送信部４０６は、ネットワーク１００を介して接続されているデバイス内に保存されているジョブログを収集して保持部（不図示）に一旦保持し、要求受信部４０１に送信することができる機能を持つ。登録情報通信部４０７は、前回の登録処理で何番までのジョブログが登録できたという情報を受け付けることができる。また、登録情報通信部４０７は、前回ジョブログを何番まで送ったかという情報を送信することができても良い。

ジョブログ送信部４０６は、ジョブログ収集サーバ１０３を構成する情報処理装置（図２）のＲＯＭ２０２又はＨＤ２１１に保存されているジョブログ送信プログラムが、ＲＡＭ２０３にロードされて、ＣＰＵ２０１により実行されることで実現される。また、登録情報通信部４０７は、ジョブログ収集サーバ１０３を構成する情報処理装置（図２）のＲＯＭ２０２又はＨＤ２１１に保存されている登録情報通信プログラムが、ＲＡＭ２０３にロードされて、ＣＰＵ２０１により実行されることで実現される。

次に、画像形成装置１０４について詳細に説明する。
画像形成装置１０４は、ジョブログ送信部４０８、登録情報通信部４０９の機能を有する。ジョブログ送信部４０８は、画像形成装置１０４内の保持部（不図示）に保存されているジョブログを要求受信部４０１に送信することができる機能を持つ。登録情報通信部４０９は、前回の登録処理で何番までのジョブログが登録できたという情報を受け付けることができる。また、登録情報通信部４０９は、前回ジョブログを何番まで送ったかという情報を送信することができても良い。

ジョブログ送信部４０８は、画像形成装置（図３）のＲＯＭ３０２又はＨＤ３１３に保存されているジョブログ送信プログラムが、ＲＡＭ３０３にロードされて、ＣＰＵ３０１により実行されることで実現される。また、登録情報通信部４０９は、画像形成装置（図３）のＲＯＭ３０２又はＨＤ３１３に保存されている登録情報通信プログラムが、ＲＡＭ３０３にロードされて、ＣＰＵ３０１により実行されることで実現される。

以上が、本実施例のジョブログ登録システムにおける各装置が持つ機能の説明になる。
次に、サーバコンピュータ群１０２のプラットフォームシステムについて図５を参照しながら詳細に説明する。
図５は、サーバコンピュータ群１０２内の各種機能を示した図である。
図５において、サーバコンピュータ群１０２内にある物理ハードウェア・リソースは、サーバコンピュータ群１０２のプラットフォームに使用される。サーバコンピュータ群１０２のプラットフォーム利用者は、このサーバコンピュータ群１０２内にある物理ハードウェア・リソースをコンピューティング・リソースとして使用できる。

サーバコンピュータ群１０２のプラットフォームシステム（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）は、次のような機能（５０１〜５０７）を持つ。５０１及び５０２は、ヴァーチャルマシン（Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅｓ）である。５０３は、ファブリックコントローラ（Ｆａｂｒｉｃ Ｃｏｎｔｒｏｌｌｅｒ）である。５０４は、ロードバランサー（Ｌｏａｄ Ｂａｌａｎｃｅｒ）である。５０５は、キューストレージサービス（Ｑｕｅｕｅ）である。５０６は、テーブルストレージサービス（Ｔａｂｌｅ）である。５０７は、ブロブストレージサービス（Ｂｌｏｂ）である。

サーバコンピュータ群１０２上で動作するプラットフォームシステムの内部には、ヴァーチャルマシン５０１、５０２が複数存在する。ヴァーチャルマシンとは、仮想化技術によって物理的なサーバコンピュータ群１０２を論理的なコンピュータに分割し、分割された中で独立したオペレーティングシステムをもって動作する論理的なコンピュータのことである。この論理的なコンピュータの単位は、インスタンスとして数えられる。本実施例では、１つのインスタンスは、サーバコンピュータ群１０２内の１台のサーバコンピュータ上で動作する。

ヴァーチャルマシン５０１は、要求受信部（Ｗｅｂ Ｒｏｌｅ Ｉｎｓｔａｎｃｅ）５０９、要求受信部エージェント（Ａｇｅｎｔ）５１０で構成される。要求受信部５０９は、図４の要求受信部４０１に対応する。要求受信部５０９は、後述するロードバランサー５０４を介してユーザからの処理依頼を受信する。また、要求受信部５０９は、キューストレージサービス５０５を介してバックエンド処理部５１１への処理依頼を送信する。

要求受信部５０９の高い可用性を確保するために、外部ネットワークからの要求（ここではＨＴＴＰによる通信）は、ヴァーチャルマシン５０１の外部にあるロードバランサー５０４を通じて行われる。ロードバランサー５０４は、外部ネットワークからの要求を一元的に管理し、同等な要求受信部の機能を有する複数のヴァーチャルマシンに対し、選択的に要求を転送するものである。要求受信部エージェント５１０は、ヴァーチャルマシン５０１の使用状況、要求受信部５０９の稼動状態、ヴァーチャルマシン５０１のリソースの使用状況、及び要求受信部５０９のエラーを含む各種情報を収集する。要求受信部エージェント５１０は、収集した各種情報をファブリックコントローラ５０３に定期的に送信する。

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

ヴァーチャルマシン５０２は、バックエンド処理部（Ｗｏｒｋｅｒ Ｒｏｌｅ Ｉｎｓｔａｎｃｅ）５１１、バックエンド処理部エージェント（Ａｇｅｎｔ）５１２で構成される。バックエンド処理部５１１は、図４のバックエンド処理部４０２に対応する。バックエンド処理部５０２は、キューテーブル５０５を介して要求受信部５０９からの処理依頼を受信する。バックエンド処理部５１１は、キューストレージサービス５０５を介して要求受信部５０９から受信した処理依頼を実行する。また、バックエンド処理部５１１は、スケールアウトする。スケールアウトとは、ヴァーチャルマシン５０２が増加し、バックエンド処理部５１１のインスタンスが増加すること指す。バックエンド処理部５１１のインスタンスが増加すると、バックエンド処理部１つ当たりのデータ処理量が減少する。これにより、ユーザからの処理依頼に対する結果をより早く返すことができる。

キューストレージサービス５０５は、要求受信部５０９とバックエンド処理部５１１とが非同期でデータ通信するためのサービスを提供する。なお、キューストレージサービス５０５は、図４のキューストレージサービス４０５に対応する。要求受信部５０９、及びバックエンド処理部５１１は、キューストレージサービス５０５に対し各種指示を出すことで、非同期でデータ通信する。これについて、具体的に説明する。要求受信部５０９がキューストレージサービス５０５に対して行う指示とは、キューメッセージの追加指示である。バックエンド処理部５１１がキューストレージサービス５０５に対して行う指示とは、キューメッセージの取得指示、キューメッセージの削除指示である。

要求受信部５０９とバックエンド処理部５１１が非同期でデータ通信する一連の動作について説明する。
要求受信部５０９は、ユーザからの処理依頼に応じたキューメッセージを作成し、キューメッセージをキューに追加するようにキューストレージサービス５０５に追加指示を送信する。追加指示を受信したキューストレージサービス５０５は、キューにキューメッセージを追加する。

バックエンド処理部５１１は、キューメッセージを取得するために、キューストレージサービス５０５に取得指示を出す。取得指示を受けたキューストレージサービス４０５は、キューメッセージと、キューメッセージ毎に固有に割り振られたメッセージＩＤと、ジョブＩＤとを取得指示に対するレスポンスとしてバックエンド処理部５１１に返す。メッセージＩＤとは、キューメッセージを一意に定めるためにキューメッセージごとに割り振られた固有の情報であり、処理が終了したバックエンド処理部５１１がキューメッセージを削除指示する際に使用する。ジョブＩＤは、実際に処理する内容を一意に決定するＩＤである。

バックエンド処理部５１１は、処理依頼の実行を完了すると、受取ＩＤに対応するキューメッセージの削除指示をキューストレージサービス５０５に対して行う。削除指示を受けたキューストレージサービス５０５は、バックエンド処理部５１１が指示した受取ＩＤに対応するキュースメッセージをキューから削除する。これにより、削除指示を出したバックエンド処理部５１１以外のバックエンド処理部５１１が同じキューメッセージを処理するという冗長な処理を防ぐことができる。

また、キューストレージサービス５０５は、キューに追加されているキューメッセージを可視、又は、不可視にする機能を持つ。可視とは、バックエンド処理部５１１がキューに追加されているキューメッセージの取得要求した場合に、キューストレージサービス５０５がバックエンド処理部５１１に対してキューメッセージを渡すことを指す。不可視とは、バックエンド処理部５１１がキューに追加されているキューメッセージの取得要求をした場合に、キューストレージサービス５０５はバックエンド処理部５１１に対してキューメッセージを渡さないことを示す。

バックエンド処理部５１１がキューからキューメッセージを取得すると、取得されたキューメッセージはキュースストレージサービス５０５によって不可視になる。バックエンド処理部５１１に取得され不可視になっているキューメッセージは、処理を行っているバックエンド処理部５１１から処理結果が一定時間返ってこない場合にキューストレージサービス５０５によって可視になる。これにより、バックエンド処理部５１１が異常終了し処理を継続できない場合でも自動的に処理がリトライされることになる。

テーブルストレージサービス５０６は、データ保存に利用されるストレージを提供する。テーブルストレージサービス５０６では、データをエンティティと型情報のプロパティを組み合わせた単純な形式でデータを保管する。なお、テーブルストレージサービス５０６は、図４のテーブルストレージサービス４０３に対応する。

ブロブストレージサービス５０７は、データ保存に利用されるストレージを提供する。ブロブストレージサービス５０７は、バイナリーデータの集合を保存する機能を提供する。なお、ブロブストレージサービス５０７は、図４のブロブストレージサービス４０４に対応する。

次に、図６を用いて本実地例におけるジョブログについて説明する。なお、ジョブログとは、画像形成装置が実行したジョブ履歴のことを言う。ジョブ履歴には、誰がいつ何をしたのかという情報が記録されている。

図６は、本実施例におけるジョブログの一例を示す図である。
図６に示すように、ジョブログは、Ｃｌｉｅｎｔ ＩＤ６０１、Ｓｅｎｄ ＩＤ６０２、Ｌｏｇ ＩＤ６０３、及び、ジョブログ内容６０４（例えば、印刷日時、印刷枚数、カラー／モノクロ、プリンタ名、印刷を行ったユーザ名等）を含む。

Ｃｌｉｅｎｔ ＩＤ６０１は、ジョブログをサーバへ送ってきたクライアントを識別するＩＤ（クライアントの識別する情報）である。ジョブログにＣｌｉｅｎｔ ＩＤ６０１を保持することで複数の画像形成装置を導入するようなクライアントにおいてもジョブログを一元的に管理することが可能である。

Ｓｅｎｄ ＩＤ６０２は、誰がいつ送ったジョブログなのか、という情報が保持される。Ｓｅｎｄ ＩＤ６０２をキーにすることで、ジョブログ収集サーバ１０３毎、若しくはデバイス（画像形成装置１０４）毎のジョブログの登録の成否の確認が行なうことができる。

Ｌｏｇ ＩＤ６０３は、送信元であるジョブログ収集サーバ１０３や画像形成装置１０４が自動的に割り振る値であり、ジョブが発生すると自動的に設定される。ジョブログの送信元であるクライアント側で一意の値になる（クライアント側でのジョブログの識別情報）。クライアント側では、Ｌｏｇ ＩＤ６０３がどこまで登録されているか見ることで、次に何番のＬｏｇ ＩＤ６０３からジョブログを登録すればいいのか認識することができる。

ジョブログは、本実施例ではクライアントから圧縮された状態でサーバコンピュータ群１０２へ送信される。圧縮されたジョブログはサーバコンピュータ群１０２内で解凍され、サーバコンピュータ郡１０２内のテーブルストレージサービス４０３に登録される。

次に、図７を用いてクラウドのストレージに保持される情報の構成についての説明を行う。
図７は、本実施例におけるサーバコンピュータ群１０２内で保存されるデータを示す図であり、図６と同一のものには同一の符号を付してある。
ジョブログ保存部７０１は、クライアントから登録要求のあったジョブログを登録するストレージであって、図６で説明したジョブログがクライアントから圧縮された状態で渡され、バックエンド処理部４０２で解凍されたものが登録される。なお、ジョブログ保存部７０１は、後述する図８、図１２に示すジョブログ保存部８０４に対応する。

圧縮データ一時保存部７０２では、クライアントから送られてきた圧縮されたジョブログを一時的に保存するストレージである。圧縮データ一時保存部７０２では、ジョブログのＣｌｉｅｎｔ ＩＤ６０１とＳｅｎｄ ＩＤ６０２と圧縮データ（圧縮されたジョブログ）７１０を持つ。なお、圧縮データ７１０は、Ｌｏｇ ＩＤ６０３とジョブログ内容６０４が圧縮されたものである。クライアントより送られてきた圧縮されたジョブログは要求受付部で受け取り、圧縮データ一時保存部で一時的に保存され、バックエンド処理部で取り出されジョブログの登録が行われる。なお、圧縮データ一時保存部７０２は、後述する図８、図１２に示す圧縮データ一時保存部８０３に対応する。

登録情報保持部７０３では、クライアントから受け渡されたジョブログの登録の成否が登録される。登録情報保存部７０３では、Ｃｌｉｅｎｔ ＩＤ６０１、Ｓｅｎｄ ＩＤ６０２、Ｌｏｇ ＩＤ６０３、Ｓｔａｔｅ７１１のカラムを持つ。

Ｓｔａｔｅ７１１は、ジョブログ登録の進行状況について設定される。ジョブログ登録の進行状況は、「Ｅｎｔｒｙ」、「Ｔｒｕｅ」、「Ｆａｌｓｅ」で管理される。なお、「Ｅｎｔｒｙ」は、登録処理中（登録要求を受け付けてから登録処理が終わるまでの間）を示す。また、「Ｔｒｕｅ」は登録の成功を示し、「Ｆａｌｓｅ」は登録の失敗を示す。Ｓｔａｔｅ７１１により、クライアントからのジョブログ登録結果取得要求時に登録処理は成功したのか、失敗したのか、まだ登録処理中なのか判断することができる。ジョブログが登録処理中であった場合、クライアントは再度登録結果を取得して、登録の成功／失敗を確認する必要がある。

［本発明の実地例におけるサービスが実装すべきインタフェースの構造］
次に、図８を用いて本発明の実施例におけるサービスが実装すべきインタフェースの構造図について説明する。本実施例では、ジョブログの送信元がジョブログ収集サーバ１０３として説明を行う。なお、ジョブログ収集サーバ１０３が画像形成装置１０４であっても処理の流れは変わらない。

図８は、実施例１におけるサービスが実装すべきインタフェースの構造図である。
図８に示すように、本実施例では、サーバコンピュータ群１０２は、フロントエンドに、登録要求受付部８０１と、登録確認要求受付部８０９を持つ。また、サーバコンピュータ群１０２は、バックエンドに、登録処理部８０５と、登録確認処理部８０８を持つ。サーバコンピュータ群１０２のストレージは、第一実行命令データ保存部８０２と、第二実行命令データ保存部８０６と、圧縮データ一時保存部８０３、ジョブログ保存部８０４、登録情報保存部８０７で構成される。

登録要求受付部８０１は、ジョブログ収集サーバ１０３から圧縮されたジョブログを受け取り、圧縮データ一時保存部８０３へ登録を行い、第一実行命令データ保存部８０２へメッセージの登録を行う。なお、圧縮データ一時保存部８０３は、ジョブログ収集サーバ１０３から受け渡された圧縮されたジョブログを一時的に保存しておくストレージである。また、第一実行命令データ保存部８０２は、登録要求受付部８０１からのＱｕｅｕｅのメッセージの格納が行われるストレージである。

登録処理部８０５は、第一実行命令データ保存部８０２からメッセージを取得し、取得したメッセージを基に圧縮されたジョブログの取得を行う。さらに、登録処理部８０５は、取得した圧縮されたジョブログの解凍処理を行い、解凍したジョブログをジョブログ保存部８０４へ登録し、第二実行命令データ保存部８０６へ登録確認処理部８０８へのメッセージの登録を行う。なお、ジョブログ保存部８０４は、登録処理部８０５により解凍されたジョブログが登録されるストレージである。また、第二実行命令データ保存部８０６は、登録処理部からのＱｕｅｕｅのメッセージの格納が行われるストレージである。

登録確認処理部８０８は、第二実行命令データ保存部８０６からメッセージを取得し、ジョブログ登録結果を登録情報保存部８０７への登録を行う。なお、登録情報保存部８０７は、登録確認処理部８０８によりジョブログの登録結果が格納されるストレージである。
登録確認要求受付部８０９は、登録情報保存部８０７からジョブログの登録結果を取得しジョブログ収集サーバ１０３へ結果を返す。

以下、図９のシーケンス図を用いて、図８の構成における処理の流れを説明する。
図９は、実施例１のジョブログ登録システムにおける処理の流れの一例を示すシーケンス図である。
登録要求受付部８０１は、ジョブログ収集サーバ１０３からジョブログ登録要求（圧縮されたジョブログを含む）を受け取ると（Ｓ９０１）、圧縮データ一時保存部８０３にジョブログ収集サーバ１０３から受け取った圧縮されたジョブログの登録を行う（Ｓ９０２）。

次に、登録要求受付部８０１は、第一実行命令データ保存部８０２（登録命令保存部）にメッセージの追加を行う（Ｓ９０３）。このメッセージは、上記受け付けた登録要求を処理するための実行命令データであり、上記受け付けた登録要求のＣｌｉｅｎｔ ＩＤとＳｅｎｄ ＩＤを含む。

さらに、登録要求受付部８０１は、ジョブログ収集サーバ１０３へ登録受付正常終了通知（Ｓｅｎｄ ＩＤと受付成功を示す情報の通知）を行う（Ｓ９０４）。なお、圧縮されたジョブログの登録に失敗した場合は、登録要求受付部８０１は、上記Ｓ９０４の登録受付正常終了通知の代わりに、ジョブログ収集サーバ１０３へ登録受付異常終了通知（Ｓｅｎｄ ＩＤと受付失敗を示す情報の通知）を行う。

また、上記Ｓ９０３の後、登録要求受付部８０１は、受け付けたジョブログ登録要求に対応する登録情報を登録情報保存部８０７へ登録する（Ｓ９０３'）。この場合、Ｓｔａｔｅ７１１には「Ｅｎｔｒｙ」、Ｌｏｇ ＩＤ６０３にはＮｕｌｌが登録される。

登録処理部８０５は、第一実行命令データ保存部８０２を監視しており、第一実行命令データ保存部８０２にメッセージが積まれたら、第一実行命令データ保存部８０２にメッセージ取得要求を出し（Ｓ９０５）、メッセージの取得を行う。

メッセージを受け取った登録処理部８０５は、取得したメッセージをもとに、圧縮データ一時保存部８０３に、圧縮されたジョブログの取得要求を出し（Ｓ９０６）、圧縮データ一時保存部から圧縮されたジョブログの取得を行う（Ｓ９０７）。

次に、登録処理部８０５は、取得した圧縮されたジョブログの解凍処理を行い、ジョブログ保存部８０４に、解凍したジョブログの登録を行う（Ｓ９０８）。
ジョブログの登録終了後、登録処理部８０５は、第二実行命令データ保存部８０６（確認命令保存部）にメッセージの追加を行う。このメッセージは、上記登録処理したジョブログの登録確認を行うための実行命令データであり、上記登録処理したジョブログのＣｌｉｅｎｔ ＩＤとＳｅｎｄ ＩＤを含む。

さらに、登録処理部８０５は、第二実行命令データ保存部８０６へのメッセージの追加後、第一実行命令データ保存部８０２へメッセージ削除要求を出し（Ｓ９１０）、処理の終わった第一実行命令データ保存部８０２のメッセージの削除を行う。なお、圧縮されたジョブログの解凍の失敗した場合、登録処理部８０５は、上記Ｓ９０８〜Ｓ９１０の処理を実行する代わりに、解凍に失敗したジョブログのＣｌｉｅｎｔ ＩＤ及びＳｅｎｄ ＩＤに対応する登録情報保存部８０７の登録情報のＳｔａｔｅ７１１を「Ｆａｌｓｅ」、Ｌｏｇ ＩＤ６０３を上記圧縮されたジョブログのＬｏｇ ＩＤに更新する。

登録確認処理部８０８は、第二実行命令データ保存部８０６を監視しており、第二実行命令データ保存部８０６にメッセージが積まれたら、第二実行命令データ保存部８０６にメッセージ取得要求を出し（Ｓ９１１）、メッセージの取得を行う（Ｓ９１２）。

メッセージを受け取った登録確認処理部８０８は、取得したメッセージに対応するジョブログがジョブログ保存部８０４に登録されているか確認を行い（Ｓ９１３）、登録されている場合、そのジョブログのＬｏｇ ＩＤ６０３を取得する。登録確認処理部８０８は、取得した登録されているジョブログのＬｏｇ ＩＤ６０３を登録情報保存部８０７へ登録する（Ｓ９１４）。詳細には、登録確認したジョブログのＣｌｉｅｎｔ ＩＤ及びＳｅｎｄ ＩＤに対応する登録情報保存部８０７の登録情報のＳｔａｔｅ７１１を「Ｔｒｕｅ」、Ｌｏｇ ＩＤ６０３を上記取得した登録されているジョブログのＬｏｇ ＩＤに更新する。

さらに、登録確認処理部８０８は、第二実行命令データ保存部８０６へメッセージ削除要求を出し（Ｓ９１５）、処理の終わった第二実行命令データ保存部８０６のメッセージの削除を行う。なお、上記Ｓ９１３の確認処理の結果、ジョブログの登録に失敗していた場合、登録確認処理部８０８は、失敗と確認されたジョブログのＣｌｉｅｎｔ ＩＤ及びＳｅｎｄ ＩＤに対応する登録情報保存部８０７の登録情報のＳｔａｔｅ７１１を「Ｆａｌｓｅ」に更新する。

登録確認要求受付部８０９は、ジョブログ収集サーバ１０３からジョブログ登録確認要求（Ｃｌｉｅｎｔ ＩＤとＳｅｎｄ ＩＤを含む）を受け取ると（Ｓ９１６）、登録情報保存部８０７に、ジョブログ登録結果取得要求を出す（Ｓ９１７）。そして、登録確認要求受付部８０９は、登録情報保存部８０７からジョブログ登録結果を取得し（Ｓ９１８）、ジョブログ収集サーバ１０３へ登録結果（Ｃｌｉｅｎｔ ＩＤ６０１，Ｓｅｎｄ ＩＤ６０２，Ｓｔａｔｅ７１１を含む）の通知を行う（Ｓ９１９）。

図１０は、第１実施例におけるジョブログ収集サーバ１０３のジョブログ登録処理の一例を示すフローチャートである。なお、この処理は、ジョブログ収集サーバ１０３がサーバコンピュータ群１０２に圧縮したジョブログを送り、リカバリーを含めた登録が完了するまでの処理に対応する。なお、このフローチャートの処理は、ジョブログ収集サーバ１０３を構成する情報処理装置（図２）のＲＯＭ２０２又はＨＤ２１１に保存されているプログラムが、ＲＡＭ２０３にロードされて、ＣＰＵ２０１により実行されることで実現される。

ジョブログ収集サーバ１０３は、ジョブログ送信部４０６を用いて、サーバコンピュータ群１０２の登録要求受付部８０１に対して登録要求を送信する（登録要求送信処理）（Ｓ１００１）。ここでジョブログ収集サーバ１０３は、サーバコンピュータ群１０２のジョブログの登録要求として、Ｃｌｉｅｎｔ ＩＤ、Ｓｅｎｄ ＩＤ、圧縮されたジョブログを、登録要求受付部８０１に送信する。

次に、ジョブログ収集サーバ１０３は、登録要求受付部８０１からの返信結果に基づいて、ジョブログ登録要求の受付に成功したか失敗したかを判定する（Ｓ１００２）。返信結果よりジョブログ登録要求の受付に失敗したと判定した場合（Ｓ１００２でＮｏ）、ジョブログ収集サーバ１０３は、再度、サーバコンピュータ群１０２への登録要求送信処理を行う（Ｓ１００１）。

一方、登録要求受付部８０１からの返信結果からジョブログ登録要求の受付に成功したと判定した場合（Ｓ１００２でＹｅｓ）、ジョブログ収集サーバ１０３は、Ｓ１００３に処理を進める。

Ｓ１００３では、ジョブログ収集サーバ１０３は、登録情報通信部４０７を用いて、サーバコンピュータ群１０２の登録確認要求受付部８０９に対してジョブログ登録結果要求を行う（登録結果確認処理）。ここでジョブログ収集サーバ１０３は、ジョブログの登録結果要求として、登録要求を出したジョブログのＣｌｉｅｎｔ ＩＤ、Ｓｅｎｄ ＩＤの情報を登録確認要求受付部８０９に送信し、登録要求を出したジョブログが登録に成功したか、失敗したか、又は、登録処理中かの確認結果の返信を受け取る。

そして、ジョブログ収集サーバ１０３は、返信結果を判定し（Ｓ１００４）、登録処理中（Ｅｎｔｒｙ）であると判定した場合、まだ登録の処理が行われているということであるので時間を空けて再度登録結果確認処理を行う（Ｓ１００３）。
また、登録が失敗（Ｆａｌｓｅ）であったと判定した場合、ジョブログ収集サーバ１０３は、再度、登録要求送信処理から処理を行う（Ｓ１００１）。
また、登録が成功（Ｔｒｕｅ）であったと判定した場合、ジョブログ収集サーバ１０３は、ジョブログ登録処理を終了する。

図１１は、第１実施例におけるサーバコンピュータ群１０２のジョブログ登録処理の一例を示すフローチャートである。なお、この処理は、サーバコンピュータ群１０２の登録処理部８０５が、圧縮データ一時保存部８０３から圧縮されたジョブログを取得し、ジョブログの登録を行うまでのフローチャートである。なお、このフローチャートの処理は、サーバコンピュータ群１０２の登録処理部８０５及び登録確認処理部８０８により実行される。即ち、サーバコンピュータ群１０２を構成する情報処理装置（図２）のＲＯＭ２０２又はＨＤ２１１に保存されているプログラムが、ＲＡＭ２０３にロードされて、ＣＰＵ２０１により実行されることで実現される。

サーバコンピュータ群１０２の登録処理部８０５は、第一実行命令データ保存部８０２からメッセージを取得し、その情報をもとに圧縮データ一時保存部８０３（ブロブストレージサービス）から圧縮されたジョブログを取得する（Ｓ１１０１）。

次に、登録処理部８０５は、圧縮されたジョブログの解凍処理を行い、解凍に成功すると、ジョブログ保存部８０４へジョブログの登録を行い（Ｓ１１０３）、第二実行命令データ保存部８０６へメッセージを追加する。そして、第二実行命令データ保存部８０６からメッセージを受け取った登録確認処理部８０８は、ジョブログ保存部８０４に確認を行い、登録成功の場合には登録情報保存部８０７に成功（Ｔｒｕｅ）と登録する（Ｓ１１０４）。なお、登録失敗の場合、登録確認処理部８０８は登録情報保存部８０７に失敗（Ｆａｌｓｅ）と登録する。

一方、ジョブログの解凍に失敗した場合、登録処理部８０５は、登録情報保存部８０７に失敗（Ｆａｌｓｅ）と登録する（Ｓ１１０４）。
本実施例のように、ジョブログを含む各種ログの登録を非同期で行うことで１つのインスタンスの処理時間を短くすることで、１つのインスタンスでより多くのクライアントからの要求を受け付けることができる。これにより、予め用意しておくインスタンスの数を削減することができ、インスタンスの総起動時間を減らすことが可能となり運用コストも削減することができる。

上記実施例１では、非同期処理でログを登録することで１つのクライアントからの受付を短時間で処理することが可能となり、少ないインスタンスで、多くのクライアントからの受付を処理することができるようになった。

しかしながら、上記実施例１の構成は、クライアントからのアクセスに対し、安定した運用を行う為に余裕を持ってインスタンスを用意しておかなければならないという点や、非同期処理にしたことで確認処理をするインスタンスが必要になってしまったという課題を含む。

本実施例では、ログ登録のリカバリーを次回登録のタイミングで行うという点と、クライアントからの要求に応じてインスタンスを作成し、ログの登録が終了したら該インスタンスを削除するという点を特徴とする。

本実施例のように、ログ登録のリカバリーを次のクライアントからの要求があったときに行うことで、リカバリーの為に何回もサーバコンピュータ群１０２にアクセスする必要がなくなる。また、クライアントから要求を受け付けてからログ登録に必要なインスタンスを作成することで、必要最低限のインスタンスを準備しておくだけで良くなるので、インスタンスの総起動時間を減らすことが可能となり、運用コストを削減することが可能となる。以下、本発明のネットワークシステムにおいて、ジョブログを登録する例を説明するが、本発明のネットワークシステムにおいて登録するログはジョブログに限定されるものではなく、どのような種類のログでもよい。

以下、実施例２について詳細に説明する。なお、図１〜図７で示した構成については、実施例１と同様である。
ただし、図４において、ジョブログ収集サーバ１０３は、登録情報通信部４０７を備えていない。また、画像形成装置１０４も同様に、登録情報通信部４０９を備えていない。
図１２は、実施例２におけるサービスが実装すべきインタフェースの構造図であり、図８と同一のものには同一の符号を付してある。
実施例２のサーバコンピュータ群１０２は、フロントエンドに登録予約要求受付部１２０１と、登録要求受付部８０１を持つ。また、実施例２のサーバコンピュータ群１０２は、バックエンドに、登録インスタンス作成部１２０３と、登録処理部８０５を持つ。さらに、実施例２のサーバコンピュータ群１０２のストレージは、第三実行命令データ保存部１２０２、第一実行命令データ保存部８０２と、圧縮データ一時保存部８０３と、ジョブログ保存部８０４で構成される。

登録予約要求受付部１２０１は、ジョブログ収集サーバ１０３からジョブログ登録予約要求を受け取ると、ジョブログ登録予約要求元のクライアントからジョブログ保存部８０４に最後に登録されたジョブログのＬｏｇ ＩＤ６０３を取得し、ジョブログ収集サーバ１０３に返信する。そして、登録予約要求受付部１２０１は、登録要求受付部８０１と登録処理部８０５の作成要求メッセージを第三実行命令データ保存部１２０２へ登録する。なお、第三実行命令データ保存部１２０２は、登録予約要求受付部１２０１からのＱｕｅｕｅのメッセージの格納が行われるストレージである。

登録インスタンス作成部１２０３は、第三実行命令データ保存部１２０２からメッセージを取得し、登録要求受付部８０１と登録処理部８０５を作成する。即ち、登録要求受付部８０１及び登録処理部８０５はそれぞれ、登録インスタンス作成部１２０３により必要時に、作成された（サーバコンピュータ群１０２上で仮想コンピュータとして実体化された）インスタンスである。

登録要求受付部８０１は、ジョブログ収集サーバ１０３から圧縮されたジョブログを受け取り、圧縮データ一時保存部８０３へ登録を行い、第一実行命令データ保存部８０２へメッセージの登録を行う。なお、圧縮データ一時保存部８０３は、ジョブログ収集サーバ１０３から受け渡された圧縮されたジョブログを一時的に保存しておくストレージである。また、第一実行命令データ保存部８０２は、登録要求受付部８０１からのＱｕｅｕｅのメッセージの格納が行われるストレージである。

登録処理部８０５は、第一実行命令データ保存部８０２からメッセージを取得し、取得したメッセージを基に圧縮されたジョブログの取得を行う。さらに、登録処理部８０５は、取得した圧縮されたジョブログの解凍処理を行い、解凍したジョブログをジョブログ保存部８０４へ登録する。また、ジョブログ保存部８０４は、登録処理部８０５により解凍されたジョブログが登録されるストレージである。

以下、図１３のシーケンス図を用いて、図１２の構成における処理の流れを説明する。
図１３は、実施例２のジョブログ登録システムにおける処理の流れの一例を示すシーケンス図である。
登録予約要求受付部１２０１は、ジョブログ収集サーバ１０２からジョブログ登録予約要求を受け取ると（Ｓ１３０１）、ジョブログ登録予約要求元のクライアントから最後にジョブログ保存部８０４に登録されたジョブログのＬｏｇ ＩＤ６０３の取得要求を行う（Ｓ１３０２）。そして、登録予約要求受付部１２０１は、ジョブログ登録予約要求元のクライアントから最後に登録されたジョブログのＬｏｇ ＩＤ６０３の取得を行う（Ｓ１３０３）。

次に、登録予約要求受付部１２０１は、第三実行命令データ保存部１２０２（作成命令保存部）にメッセージの追加を行い（Ｓ１３０４）、ジョブログ収集サーバ１０２へジョブログ登録予約受付正常終了通知を行う（Ｓ１３０５）。このメッセージは、登録要求受付部８０１と登録処理部８０５を作成するための実行命令データである。

登録インスタンス作成部１２０３は、第三実行命令データ保存部１２０２を監視しており、第三実行命令データ保存部１２０２にメッセージが積まれたら、第三実行命令データ保存部１２０２にメッセージ取得要求を出し（Ｓ１３０６）、メッセージの取得を行う。

メッセージを受け取った登録インスタンス作成部１２０３は、取得したメッセージをもとに、登録要求受付部８０１と登録処理部８０５を作成する（Ｓ１３０７）。登録要求受付部８０１と登録処理部８０５の生成が終了した後、登録インスタンス作成部１２０３は、第三実行命令データ保存部１２０２へメッセージ削除要求を出し（Ｓ１３０８）、処理の終わった第三実行命令データ保存部１２０２のメッセージの削除を行う。

登録インスタンス作成部１２０３によって作成された登録要求受付部８０１は、ジョブログ収集サーバ１０３からジョブログ登録要求（圧縮されたジョブログを含む）を受け取ると（Ｓ１３０９）、圧縮データ一時保存部８０３にジョブログ収集サーバ１０３から受け取った圧縮されたジョブログの登録を行う（Ｓ１３１０）。

次に、登録要求受付部８０１は、第一実行命令データ保存部８０２（登録命令保存部）にメッセージの追加を行う（Ｓ１３１１）。このメッセージは、上記受け付けた登録要求を処理するための実行命令データであり、上記受け付けた登録要求のＣｌｉｅｎｔ ＩＤとＳｅｎｄ ＩＤを含む。さらに、登録要求受付部８０１は、ジョブログ収集サーバ１０３へ登録受付正常終了通知（Ｓｅｎｄ ＩＤと受付成功を示す情報の通知）を行う（Ｓ１３１２）。なお、圧縮されたジョブログの登録に失敗した場合は、登録要求受付部８０１は、上記Ｓ１３１２の登録受付正常終了通知の代わりに、ジョブログ収集サーバ１０３へ登録受付異常終了通知（Ｓｅｎｄ ＩＤと受付失敗を示す情報の通知）を行う。

登録処理部８０５は、第一実行命令データ保存部８０２を監視しており、第一実行命令データ保存部８０２にメッセージが積まれたら、第一実行命令データ保存部８０２にメッセージ取得要求を出し（Ｓ１３１３）、メッセージの取得を行う（Ｓ１３１４）。

メッセージを受け取った登録処理部８０５は、取得したメッセージをもとに、圧縮データ一時保存部８０３に、圧縮されたジョブログの取得要求を出し（Ｓ１３１５）、圧縮データ一時保存部から圧縮されたジョブログの取得を行う（Ｓ１３１６）。

次に、登録処理部８０５は、取得した圧縮されたジョブログの解凍を行い、ジョブログ保存部８０４に、解凍したジョブログの登録を行う（Ｓ１３１７）。
ジョブログの登録終了後、登録処理部８０５は、第一実行命令データ保存部８０２へメッセージ削除要求を出し（Ｓ１３１８）、処理の終わった第一実行命令データ保存部８０２のメッセージの削除を行う。

第一実行命令データ保存部８０２のメッセージ削除後、登録処理部８０５は、使用したインスタンス（登録要求受付部８０１、登録処理部８０５）の削除を行う（Ｓ１３１９）。

図１４は、実施例２におけるジョブログ収集サーバ１０３のジョブログ登録処理に一例を示すフローチャートである。なお、この処理は、ジョブログ収集サーバ１０３がサーバコンピュータ群１０２にジョブログの登録予約要求を行い、圧縮したジョブログの送信が完了するまでの処理に対応する。なお、このフローチャートの処理は、ジョブログ収集サーバ１０３を構成する情報処理装置（図２）のＲＯＭ２０２又はＨＤ２１１に保存されているプログラムが、ＲＡＭ２０３にロードされて、ＣＰＵ２０１により実行されることで実現される。

ジョブログ収集サーバ１０３は、サーバコンピュータ群１０２の登録予約要求受付部１２０１に対してジョブログ登録予約要求を送信する（登録予約要求送信処理）（Ｓ１４０１）。ジョブログ登録予約要求とは、ネットワーク１００を介して通信可能な画像形成装置から収集し内部に保持するジョブログの登録の予約の受け付けを、登録予約要求受付部１２０１に対して要求するものである。

なお、ジョブログの登録予約の受付に成功した場合は、サーバコンピュータ群１０２から登録予約受付正常終了通知として、当該ジョブログ収集サーバ１０３から最後に登録されたジョブログのＬｏｇ ＩＤ６０３の情報が返信される。一方、ジョブログの登録予約受付に失敗した場合は、サーバコンピュータ群１０２から登録予約受付異常終了通知が返信される。

次に、ジョブログ収集サーバ１０３は、登録予約要求受付部１２０１からの返信結果に基づいて、ジョブログ登録予約の受付に成功したか失敗したか判定する（Ｓ１４０２）。登録予約要求受付部１２０１から登録予約受付異常通知が返信され、ジョブログ登録予約の受付に失敗したと判定した場合（Ｓ１４０２でＮｏ）、ジョブログ収集サーバ１０３は、再度、サーバコンピュータ群１０２への登録予約要求送信処理を行う（Ｓ１４０１）。

一方、登録予約要求受付部１２０１から登録予約受付正常通知（Ｌｏｇ ＩＤ）が返信され、ジョブログ登録予約の受付に成功したと判定した場合（Ｓ１４０２でＹｅｓ）、Ｓ１４０３に処理を進める。

Ｓ１４０３では、ジョブログ収集サーバ１０３は、登録予約要求受付部１２０１から返信されたＬｏｇ ＩＤ６０３を基に登録要求するジョブログを選択する。即ち、上記返信されたＬｏｇ ＩＤの次のＬｏｇ ＩＤのジョブログを、登録要求するジョブログとして選択する。そして、上記選択したジョブログを圧縮する。

次に、ジョブログ収集サーバ１０３は、ジョブログ送信部４０６を用いて、サーバコンピュータ群１０２の登録要求受付部８０１に対して登録要求を送信する（登録要求送信処理）（Ｓ１４０４）。ここでジョブログ収集サーバ１０３は、ジョブログの登録要求として、Ｃｌｉｅｎｔ ＩＤ、Ｓｅｎｄ ＩＤ、上記Ｓ１４０３で選択されて圧縮されたジョブログを、登録要求受付部８０１に送信する。

次に、ジョブログ収集サーバ１０３は、登録要求受付部８０１からの返信結果を受け取り、該返信結果に基づいて、ジョブログ登録要求の受付に成功したか失敗したかを判定する（Ｓ１４０５）。返信結果よりジョブログ登録要求の受付に失敗したと判定した場合（Ｓ１４０５でＮｏ）、ジョブログ収集サーバ１０３は、再度、サーバコンピュータ群１０２への登録要求送信処理を行う（Ｓ１４０４）。

一方、登録要求受付部８０１からの返信結果からジョブログ登録要求の受付に成功したと判定した場合（Ｓ１４０５でＹｅｓ）、リカバリーは次回の登録予約要求送信処理のタイミングで行うので、登録の成否に関係なく、処理を終了する。

本実施例のように、ジョブログの登録のリカバリーを後で行う（次の予約受付時に行う）ことによって、登録確認用のインスタンス（実施例１の登録確認要求受付部８０９、登録確認処理部８０８）が不要になる。

さらに、クライアントからの要求（登録予約要求）に応じてインスタンスを作成することで、必要最低限の起動時間でインスタンスを運用できるようになり、インスタンスの総起動時間が減少し、運用コストの削減が可能となる。

以上示したように、本実施例によれば、クラウドコンピューティングでのインスタンスの総起動時間を減らしジョブログを含む各種ログの登録の運用コストを削減可能な優れたクラウドコンピューティングシステムを構築することができる。

なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能である。具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
また、上記各実施例を組み合わせた構成も全て本発明に含まれるものである。

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

また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。
本発明は上記実施例に限定されるものではなく、本発明の趣旨に基づき種々の変形（各実施例の有機的な組合せを含む）が可能であり、それらを本発明の範囲から除外するものではない。即ち、上述した各実施例及びその変形例を組み合わせた構成も全て本発明に含まれるものである。

１００ ネットワーク
１０１ インターネット
１０２ サーバコンピュータ群
１０３ ジョブログ収集サーバ
１０４ 画像形成装置

Claims (8)

1. クライアントと、前記クライアントと通信可能な１台以上のサーバコンピュータからなるサーバコンピュータ群で構成されるサーバとを有するネットワークシステムであって、
   前記サーバは、
   前記クライアントから取得したログを保存するための保存手段と、
   前記クライアントから送信されるログの登録予約要求を受け付けて、前記クライアントから前記保存手段に最後に登録されたログの識別情報を、前記クライアントに返信する１又は複数の登録予約要求受付手段と、
   前記クライアントから送信されるログの登録要求を受け付けて、前記ログを一時保存手段に保存し、前記登録要求を処理するための実行命令データを登録命令保存手段に登録する１又は複数の登録要求受付手段と、
   前記登録命令保存手段への実行命令データの登録とは非同期で前記登録命令保存手段から前記実行命令データを取得して前記一時保存手段に保存された前記ログを前記保存手段に登録処理する１又は複数の登録処理手段とを有し、
   前記クライアントは、
   ログを保持する保持手段と、
   前記保持手段に保持されるログの登録予約要求を前記登録予約要求受付手段に送信する登録予約要求送信手段と、
   前記登録予約要求の送信に応じて返信されるログの識別情報に基づいて登録要求するログを前記保持手段に保持されるログから選択する選択手段と、
   前記選択手段により選択されたログを前記登録要求受付手段に送信して登録要求する登録要求送信手段とを有する、
   ことを特徴とするネットワークシステム。
2. 画像形成装置と通信可能な１台以上のサーバコンピュータからなるサーバコンピュータ群で構成されるサーバであって、
   前記画像形成装置から取得したジョブログを保存するための保存手段と、
   前記画像形成装置から送信されるジョブログの登録予約要求を受け付けて、前記画像形成装置から前記保存手段に最後に登録されたジョブログの識別情報を、前記画像形成装置に返信する１又は複数の登録予約要求受付手段と、
   前記画像形成装置から送信されるジョブログの登録要求を受け付けて、前記ジョブログを一時保存手段に保存し、前記登録要求を処理するための実行命令データを登録命令保存手段に登録する１又は複数の登録要求受付手段と、
   前記登録命令保存手段への実行命令データの登録とは非同期で前記登録命令保存手段から前記実行命令データを取得して前記一時保存手段に保存された前記ジョブログを前記保存手段に登録処理する１又は複数の登録処理手段と、
   を有することを特徴とするサーバ。
3. 前記登録要求受付手段及び前記登録処理手段はそれぞれ、前記サーバコンピュータ群上で仮想コンピュータとして実体化されたインスタンスであり、
   前記登録予約要求受付手段は、前記画像形成装置から送信されるジョブログの登録予約要求を受け付けて、前記登録要求受付手段及び前記登録処理手段を作成するための実行命令データを作成命令保存手段に登録するものであり、
   前記作成命令保存手段への実行命令データの登録とは非同期で前記作成命令保存手段から前記実行命令データを取得して前記登録要求受付手段及び前記登録処理手段を作成する作成手段を有することを特徴とする請求項２に記載のサーバ。
4. 前記登録処理手段は、ジョブログの前記保存手段への登録の後に、前記登録要求受付手段及び前記登録処理手段自身を削除することを特徴とする請求項３に記載のサーバ。
5. 前記登録要求受付手段が前記画像形成装置から受け取るジョブログは、圧縮された状態のジョブログであり、
   前記登録処理手段は、前記一時保存手段に保存された前記圧縮された状態のジョブログを解凍し、該解凍したジョブログを前記保存手段に登録処理することを特徴とする請求項２乃至４のいずれか１項に記載のサーバ。
6. クライアントと、前記クライアントと通信可能な１台以上のサーバコンピュータからなるサーバコンピュータ群で構成されるサーバとを有するネットワークシステムにおけるログ登録方法であって、
   前記クライアントの登録予約要求送信手段が、保持手段に保持されるログの登録予約要求を前記サーバに送信する登録予約要求送信ステップと、
   前記サーバの１又は複数の登録予約要求受付手段が、前記クライアントから送信されるログの登録予約要求を受け付けて、前記クライアントから取得したログ を保存するための保存手段に対して、前記クライアントから最後に登録されたログの識別情報を、前記クライアントに返信する登録予約要求受付ステップと、
   前記クライアントの選択手段が、前記登録予約要求の送信に応じて返信されるログの識別情報に基づいて前記サーバに登録要求すべきログを前記保持手段に保持されるログから選択する選択ステップと、
   前記クライアントの登録要求送信手段が、前記選択ステップにより選択されたログを前記サーバに送信して登録要求する登録要求送信ステップと、
   前記サーバの１又は複数の登録要求受付手段が、前記クライアントから送信されるログの登録要求を受け付けて、前記ログを一時保存手段に保存し、前記登録要求を処理するための実行命令データを登録命令保存手段に登録する登録要求受付ステップと、
   前記サーバの１又は複数の登録処理手段が、前記登録命令保存手段への実行命令データの登録とは非同期で前記登録命令保存手段から前記実行命令データを取得して前記一時保存手段に保存された前記ログを前記保存手段に登録処理する登録処理ステップと、
   を有することを特徴とするログ登録方法。
7. 画像形成装置と通信可能な１台以上のサーバコンピュータからなるサーバコンピュータ群から構成されるサーバにおけるログ登録方法であって、
   １又は複数の登録予約要求受付手段が、前記画像形成装置から送信されるジョブログの登録予約要求を受け付けて、前記画像形成装置から取得したジョブログ を保存するための保存手段に対して、前記画像形成装置から最後に登録されたジョブログの識別情報を、前記画像形成装置に返信する登録予約要求受付ステップ と、
   １又は複数の登録要求受付手段が、前記画像形成装置から送信されるジョブログの登録要求を受け付けて、前記ジョブログを一時保存手段に保存し、前記登録要求を処理するための実行命令データを登録命令保存手段に登録する登録要求受付ステップと、
   １又は複数の登録処理手段が、前記登録命令保存手段への実行命令データの登録とは非同期で前記登録命令保存手段から前記実行命令データを取得して前記一時保存手段に保存された前記ジョブログを前記保存手段に登録処理する登録処理ステップと、
   を有することを特徴とするログ登録方法。
8. コンピュータを、請求項２乃至５のいずれか１項に記載された手段として機能させるためのプログラム。

Images