(57)【要約】【課題】リトライにかかる情報を用いて、処理の優先順位の決定を容易に行える仕組みを提供すること【解決するための手段】複数の情報処理装置を含む情報処理システムであって、実行するタスクのリトライ原因を特定し、特定されたリトライ原因が前記タスクを実行する情報処理装置自体と連携する別の情報処理装置にかかる問題であるタスクに比べて、特定されたリトライ原因が前記タスクを実行する情報処理装置自体にかかる問題である前記タスクの実行の優先順位を下げることを決定する【選択図】図７
2018106387.tif 000002
【特許請求の範囲】
【請求項１】
複数の情報処理装置を含む情報処理システムであって、
実行するタスクのリトライ原因を特定する特定手段と、
前記特定手段により特定されたリトライ原因が前記タスクを実行する情報処理装置自体と連携する別の情報処理装置にかかる問題であるタスクに比べて、前記特定手段により特定されたリトライ原因が前記タスクを実行する情報処理装置自体にかかる問題である前記タスクの実行の優先順位を下げることを決定する決定手段と、
を備えることを特徴とする情報処理システム。
【請求項２】
前記特定手段は、前記情報処理システムにおける処理リソースの減少にあたり消える処理リソースを用いて実行するタスクのリトライ原因を特定することを特徴とする請求項１に記載の情報処理システム。
【請求項３】
前記特定手段により特定されたリトライ原因が、前記タスクを実行する情報処理装置自体と連携する別の情報処理装置にかかる問題であるタスクに比べて、前記特定手段により特定されたリトライ原因が、前記タスクを実行する情報処理装置自体にかかる問題である前記タスクの実行の優先順位を下げることにより、前記リトライ原因が前記タスクを実行する情報処理装置自体と連携する別の情報処理装置にかかる問題であるタスクを実行しない決定をすることを特徴とする請求項１又は２に記載の情報処理システム。
【請求項４】
前記特定手段は、実行中のタスクのリトライ原因を特定し、
前記決定手段は、前記特定手段により特定されたリトライ原因が前記タスクを実行する情報処理装置自体にかかる問題である前記タスクを中断する決定をすることを特徴とする請求項１乃至３のいずれか１項に記載の情報処理システム。
【請求項５】
複数の情報処理装置を含む情報処理システムの制御方法であって、
実行するタスクのリトライ原因を特定する特定工程と、
前記特定工程により特定されたリトライ原因が前記タスクを実行する情報処理装置自体と連携する別の情報処理装置にかかる問題であるタスクに比べて、前記特定工程により特定されたリトライ原因が前記タスクを実行する情報処理装置自体にかかる問題である前記タスクの実行の優先順位を下げることを決定する決定工程と、
を含むことを特徴とする制御方法。
【請求項６】
複数の情報処理装置を含む情報処理システムを制御するプログラムであって、
前記情報処理システムを、
実行するタスクのリトライ原因を特定する特定手段と、
前記特定手段により特定されたリトライ原因が前記タスクを実行する情報処理装置自体と連携する別の情報処理装置にかかる問題であるタスクに比べて、前記特定手段により特定されたリトライ原因が前記タスクを実行する情報処理装置自体にかかる問題である前記タスクの実行の優先順位を下げることを決定する決定手段として機能させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理システム、その制御方法及びプログラムに関する。
【背景技術】
【０００２】
クラウド・コンピューティング（以下、クラウド）の仕組みにおいては、スケールイン／スケールアウトに伴いサーバのシャットダウンが頻繁に行われる。よって、あるサービスが他のサービスと連携する際には、他のサービスのサーバが一時的にダウンしている等の事情で、実行中の処理が中断したり、リトライされたりすることがある。
【０００３】
サーバのシャットダウンは「１０分後にシャットダウンすること」というように時間が指定されることが多い。
【０００４】
例えば特許文献１には、処理の進捗度合を監視し、残りの処理にどの程度時間がかかるか特定することや、処理の残り時間に応じてマシンをシャットダウンするか否か判断することが記載されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１５−００５２０３号公報
【特許文献２】特開２０１３−２５７７８９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
クラウドの場合、例えば特許文献２に記載されているように、サーバの利用数、利用時間、サーバのリソースの使用量などに応じて利用料金が加算されていくのが一般的である。シャットダウンされるサーバで行われていた処理が、別のサーバが最初から実行しなおすことになれば、クラウド利用の課金額が嵩んでしまう。
【０００７】
また、クラウドの場合、高スペックなサーバ装置を１台利用するのではなく、例えば低スペックのサーバを複数台利用することで、サーバのうちの１つがエラーを起こしてシャットダウンしたとしても処理を継続できるよう構成されていることがある。所謂Ｄｅｓｉｇｎ  ｆｏｒ  Ｆａｉｌｕｒｅの考え方に基づいて設計されたような仕組みがこれにあたる。装置が低スペックな分だけトラブルが起こるか確率も上がり、処理が一時停止したりリトライされたりすることも多い。リトライ回数の上限も１０回等多めに設定されているのが一般的である。
【０００８】
特許文献１によれば、シャットダウン指示の受付に伴って、その後所定時間内に終わるだろう処理のみ継続することはできるが、継続した処理が中断・リトライされることとなった場合、その処理に使ったリソースが無駄になってしまう。
【０００９】
本発明は、リトライにかかる情報を用いて、処理の優先順位の決定を容易に行える仕組みを提供することを目的とする。
【課題を解決するための手段】
【００１０】
本発明は、複数の情報処理装置を含む情報処理システムであって、実行するタスクのリトライ原因を特定する特定手段と、前記特定手段により特定されたリトライ原因が前記タスクを実行する情報処理装置自体と連携する別の情報処理装置にかかる問題であるタスクに比べて、前記特定手段により特定されたリトライ原因が前記タスクを実行する情報処理装置自体にかかる問題である前記タスクの実行の優先順位を下げることを決定する決定手段と、を備えることを特徴とする。
【発明の効果】
【００１１】
本発明によれば、リトライにかかる情報を用いて、処理の優先順位の決定を容易に行える仕組みを提供することができる。
【図面の簡単な説明】
【００１２】
【図１】本発明の実施形態における、情報処理システムの構成の一例を示す図である。
【図２】本発明の実施形態における、各種装置のハードウェア構成の一例を示す図である。
【図３】本発明の実施形態における、各種装置の機能構成の一例を示す図である。
【図４】本発明の実施形態における、装置のシャットダウン処理の流れを示すフローチャートである。
【図５】本発明の実施形態における、待機キューへのメッセージ記憶処理の流れを示すフローチャートである。
【図６】本発明の実施形態における、タスク実行処理の流れを示すフローチャートである。
【図７】本発明の実施形態における、タスクの優先順位決定処理の流れを示すフローチャートである。
【図８】本発明の実施形態における、各種データ構成の一例を示す図である。
【図９】本発明の実施形態における、各装置のタスク実行の様子とシャットダウン指示の様子の一例を示した図である。
【図１０】本発明の実施形態における、タスクの優先順位決定について説明する図である。
【図１１】本発明の実施形態における、課題の一例を説明する図である。
【図１２】本名発明の実施形態におけるメッセージファイルの構成の一例を示す図である。
【発明を実施するための形態】
【００１３】
本発明では、処理のリトライの原因に応じて、処理の優先度を決定する。
【００１４】
しかし、例えばクラウドのように、処理が一時停止したりリトライされたりすることが多いシステムにおいて、常に全ての処理からリトライ中のものを特定し、原因究明して優先順位付けしようとするとそれだけで相当のリソースを消費してしまうため現実的ではない。
【００１５】
一方で、装置のシャットダウンや、使用するメモリ領域・計算リソースの利用制限等により処理リソースが減少する場合、処理リソースの減少が行われる時刻（例えばシャットダウンが行われる時刻）までに使える処理リソース、そのリソースを用いて実行する処理は限られる。また、処理を実行したが失敗したという場合、その処理はリソースが減った後も再実行しなければならない処理として残ることとなる。
【００１６】
例えば、図１１に示すように、一時的な処理数の増加で、２００Ａ、２００Ｂに、高スペックな２００Ｃというサーバを増設させていたとする（スケールアウトしていたとする）。１０分後までに予定している処理が完了すれば１１０１のように元のスケールに戻せると想定し、１０分後にサーバ２００Ｃのシャットダウンを予定したとする。しかし、サーバＣで完了を予定していた処理が失敗した場合、１１０２に示すように、失敗した処理５、６と、元々残る予定だった処理７、８が両方残ることとなる。結果としてせっかくスケールインしたにも関わらず、再度サーバＤを追加するスケールアウトを行わなければならなくなり、サーバＤの利用のイニシャルコストが余分にかかることとなってしまう。
【００１７】
つまり、将来失われる処理リソースを使って実行する処理が失敗すると、単なる処理の失敗によるリソースの浪費だけでなく、無駄な料金や、処理を振りなおす、また、受け入れて当該リソースを記憶する処理のリソースが必要となる。
【００１８】
よって、本発明では、処理リソースの減少に際し、減じる処理リソースを使って実行する処理のリトライ状況に応じて、当該処理の実行にかかる決定をすることとする。
【００１９】
失敗しそうな処理に将来消えるリソースを割くくらいなら、他の処理にリソースを明け渡すことで、消えるまでに処理に費やした時間・課金額が無駄にならずに済む。また、余分に残った処理を振りなおす、当該処理を受け入れて保持する処理リソースを削減できる。
【００２０】
以下、図面を参照して、本発明の実施の形態の一例について説明する。
【００２１】
まず図１を参照して、本発明の実施形態における、情報処理システムの構成の一例について説明する。
【００２２】
本発明の情報処理システムにおける各種装置は、図１に示すように、それぞれネットワーク１０１（ＷＡＮ／ワイドエリアネットワーク）、ネットワーク１０２（ＬＡＮ／ローカルエリアネットワーク）で通信可能に接続されている。ネットワークの種類はあくまで一例である。
【００２３】
ＰＣ１００は、サーバ２００で実行する処理の実行要求メッセージを、例えばユーザ操作に応じて作成して、キューサーバ２５０に送信する機能を備える。
【００２４】
キューサーバ２５０には、受信したメッセージを順次記憶する。キューサーバ２５０により提供されているこのメッセージを記憶する機能をタスクの実行要求メッセージのキューサービスという。
【００２５】
各サーバ２００は、キューサービスにより蓄積されているメッセージを取得して、そのメッセージに従って処理を実行する。サーバ２００は、図１に示すように、例えば２００Ａ、２００Ｂ、２００Ｃというように複数存在し、それぞれの装置が複数の処理を並列で実行している。本実施形態において、メッセージに応じて実行される処理＝タスクである。タスクの実行状況の一例を図９に示す。
【００２６】
監視サーバは、各サーバ２００に搭載されているメトリクス計測機能部により計測され数値化される各サーバ２００の稼動状態を監視し、必要に応じて対象のサーバ２００をシャットダウンすることでシステムをスケールインしたり、未起動のサーバ２００を起動することでシステムをスケールアウトしたりする機能を備える。
【００２７】
外部サーバ２７０は、サーバ２００等の外部装置からの要求に応じて、所定の機能を提供しているサーバである。例えば画像解析機能等を提供している。
【００２８】
本実施形態においては、例えばＰＣ１００から要求を受けたサーバ２００Ｃの人物特定アプリケーション（プロセス）が、外部サーバ２７０の画像解析アプリケーションの機能を用いて顔画像を解析して顔認識を行わせ、人物特定アプリケーションがその結果をＰＣ１００に返す。以上が図１の説明である。
【００２９】
以下、図２を用いて、本発明の実施形態における各種装置のハードウェア構成の一例について説明する。
【００３０】
図２において、２０１はＣＰＵで、システムバス２０４に接続される各デバイスやコントローラを統括的に制御する。また、ＲＯＭ２０２あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるＢＩＯＳ（Ｂａｓｉｃ  Ｉｎｐｕｔ  ／  Ｏｕｔｐｕｔ  Ｓｙｓｔｅｍ）やオペレーティングシステムプログラム（以下、ＯＳ）や、各サーバ或いは各ＰＣの実行する機能を実現するために必要な後述する各種プログラム等が記憶されている。
【００３１】
２０３はＲＡＭで、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＯＭ２０２あるいは外部メモリ２１１からＲＡＭ２０３にロードして、該ロードしたプログラムを実行することで各種動作を実現するものである。
【００３２】
また、２０５は入力コントローラで、キーボード（ＫＢ）２０９や不図示のマウス等のポインティングデバイス等からの入力を制御する。２０６はビデオコントローラで、ディスプレイ２１０（例えばＣＲＴディスプレイ）等の表示器への表示を制御する。なお、表示器はＣＲＴディスプレイだけでなく、液晶ディスプレイ等の他の表示器であってもよい。これらは必要に応じてユーザが使用するものである。
【００３３】
２０７はメモリコントローラで、ブートプログラム，各種のアプリケーション，フォントデータ，ユーザファイル，編集ファイル，各種データ等を記憶するハードディスク（ＨＤ）や、フレキシブルディスク（ＦＤ）、或いはＰＣＭＣＩＡカードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）メモリ等の外部メモリ２１１へのアクセスを制御する。
【００３４】
２０８は通信Ｉ／Ｆコントローラで、ネットワーク（例えば、図１に示したネットワーク１０１）を介して外部機器と接続・通信するものであり、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰを用いた通信等が可能である。
【００３５】
なお、ＣＰＵ２０１は、例えばＲＡＭ２０３内の表示情報用領域へアウトラインフォントの展開（ラスタライズ）処理を実行することにより、ディスプレイ２１０上での表示を可能としている。また、ＣＰＵ２０１は、ディスプレイ２１０上の不図示のマウスカーソル等でのユーザ指示を可能とする。
【００３６】
本発明を実現するための後述する各種プログラムは、外部メモリ２１１に記録されており、必要に応じてＲＡＭ２０３にロードされることによりＣＰＵ２０１によって実行されるものである。さらに、上記プログラムの実行時に用いられる定義ファイル及び各種情報テーブル等も、外部メモリ２１１に格納されており、これらについての詳細な説明も後述する。以上が図２の説明である。
【００３７】
次に図３を参照して、本発明の実施形態における、各種装置の機能構成の一例について説明する。
【００３８】
メッセージ送信部３１１は、サーバ２００で実行する処理の実行要求メッセージを、例えばユーザ操作に応じて作成してキューサーバ２５０に送信する。
【００３９】
メッセージ受信部３５１、メッセージ記憶部３５２、メッセージ送信部３５３は、それぞれ、ＰＣ１００からメッセージを受信し、記憶し、サーバ２００からの要求に応じて当該メッセージをサーバ２００に送信する処理部である。
【００４０】
タスク管理部３２１は、キューサーバ２５０よりメッセージを取得し、メッセージから特定される処理（タスク）を記憶管理する。また、実行中のタスクの進捗状況や実行履歴を記憶管理する。
【００４１】
タスク実行部３２２は、タスク管理部３２１で管理されているタスクを並列で実行する処理部である。
【００４２】
シャットダウン処理部３２３は、ＰＣ１００からの要求に従って、対象の装置をシャットダウンする。例えば自機をシャットダウンする。また、シャットダウンを実行する時刻を管理する。
【００４３】
リトライタスク特定部３２４は、タスクの中でリトライ中のタスクを特定する。
【００４４】
リトライ原因特定部３２５は、リトライしているタスクのリトライ原因を、タスクの実行履歴から特定する。
【００４５】
判定部３２６は、タスクを実行するか否かを判定する判定部である。例えば、リトライ中のタスクについては、タスクのリトライ原因が論理例外の場合にはタスクを実行せず、システム例外の場合にはタスクを実行することを決定する。
【００４６】
論理例外とは、対象のタスクを実行しているアプリケーション自体で論理的に発生しうる例外であり、例えばアプリケーション自体のプログラムに問題があることを示す（例えば図１０の１０００における１００１でエラーが起こっている場合等）。そのため、当該問題が自動的に解決する見込みは薄い。
【００４７】
システム例外とは、例えば対象のタスクを実行しているアプリケーションと連携する外部アプリケーション（例えば外部サーバ２７０の画像解析アプリケ−ションが提供している顔認識機能）のエラーに起因する例外であり、外部アプリケーション自体の状態や連携に際してのやり取りに問題があることを示す（例えば図１０の１０００における１００２や１００３でエラーが起こっている場合等）。
【００４８】
システム例外の場合、例えば連携先のアプリケーションにタスクの一部を委託すべく要求を送信した際に、たまたま連携先のアプリケーションがビジー状態で要求を受け取れなかっただけ等、状況が変われば問題が解決されていることが見込まれる。以上が図３の説明である。
【００４９】
次に図４を参照して、本発明の実施形態における、装置のシャットダウン処理の流れについて説明する。
【００５０】
ステップＳ４０１では、サーバ２００は、外部装置からのシャットダウン要求を検知する。なお、本実施形態の説明においては、シャットダウン要求は、スケールインを決定した監視サーバ２６０からサーバ２００Ｃに対して行われるものとする。
【００５１】
しかしこれはあくまで一例であり、場合によっては、例えばユーザ操作に応じてＰＣ１００等の端末からサーバ２００Ｃにシャットダウン要求がされることもある。
【００５２】
ステップＳ４０２では、サーバ２００は、シャットダウン要求の中にシャットダウン時間の指定があるか判定する。例えば今から１０分後等の指定である。
【００５３】
シャットダウン時間の指定がない場合は、ステップＳ４０４で、現在実行中のタスクの完了時刻を特定する。シャットダウン時間の指定がある場合は、ステップＳ４０３で、指定された時間後の時刻を特定する。
【００５４】
ステップＳ４０５では、サーバ２００は、ステップＳ４０３又はＳ４０４で特定された時刻を自機のシャットダウン時刻（シャットダウン予定時刻８５０／図８に図示）に設定して記憶する。本実施形態の説明においては、現在時刻が１２：００であり、シャットダウン予定時刻が１２：１０であるものとする。
【００５５】
ステップＳ４０６では、サーバ２００は、現在時刻がシャットダウン時刻に達しているか判定し、達している場合に処理をステップＳ４０７に移行して、自機のシャットダウン処理を実行する。以上が図４の説明である。
【００５６】
図５は、本発明の実施形態における、待機キューへのメッセージ記憶処理の流れについて説明する。
【００５７】
ステップＳ５０１では、サーバ２００は、キューサービス（例：キューサーバ２５０の記憶部）から、キューサービスがＰＣ１００から受信して記憶している処理要求のメッセージの一覧（処理要求キュー８００／図８に図示）よりメッセージを１つ取得する。
【００５８】
当該メッセージには、メッセージＩＤ（つまり処理の識別情報）と、処理の実行要求、実行する処理のパラメータが含まれている。メッセージの一例を図１２に示す。
【００５９】
図１２の１２００はメッセージの中の文字列の定義である。当該定義の情報は各サーバ２００の外部メモリに予め記憶されている。
【００６０】
メッセージ１２１０は、図５のステップＳ５０１でサーバ２００が取得する処理要求メッセージの一例である。
【００６１】
メッセージ１２２０は、処理を実行した結果を示す、当該メッセージによる処理を実行した主体（例えば外部サーバ２７０の画像解析アプリケーション）からの応答メッセージである。
【００６２】
メッセージ１２３０では、応答メッセージ（メッセージ１２２０）においてタスクが失敗に終わった場合にリトライカウント（ｒｅｔｒｙＣｏｕｎｔ）を１カウントアップした様子を示す。メッセージ１２３０はリトライ中のタスクのメッセージとして、再度キューサービスの処理要求キュー８００に記憶される。
【００６３】
なお、リトライカウントと処理結果（ｒｅｓｕｌｔ（ｅｒｒｏｒｃｏｄｅ、ｅｒｒｏｒｉｎｆｏを含む））の項目はそれぞれリトライ回数とエラーのパラメータが書き込まれる領域であり、リトライ、エラーが発生した段階で書き込まれるため、１２１０に示すように、現時点では存在しないものとする。図５の説明に戻る。
【００６４】
ステップＳ５０２では、サーバ２００は、取得したメッセージを、実行中のタスク及び実行前の待機中のタスクを記憶管理する待機キュー８１０に追加して記憶する。待機キュー８１０は、図５の処理を実行しているサーバ２００自身の外部メモリ２１１に作成・記憶されている。
【００６５】
待機キュー８１０は、メッセージＩＤ８２１と、当該メッセージによるタスクの開始から終了までの予定時間８２２から構成される。
【００６６】
ステップＳ５０３では、サーバ２００は、サーバ２００自身がシャットダウン待ちの状態か判定する。シャットダウン予定時刻８５０が記憶されている場合、シャットダウン待ちの状態であると判定する。
【００６７】
自機がシャットダウン待ちの状態であると判定した場合処理をステップＳ５０４に移行する。自機がシャットダウン待ちの状態でないと判定した場合は図５の処理を一旦終了し、自機のリソースの空き状況が所定値以上になっている場合に再度図５の処理を実行する。
【００６８】
ステップＳ５０４で、サーバ２００は、メッセージに基づくタスク実行の優先順位決定処理を行う。優先順位決定処理の詳細は図７の説明で後述する。以上が図５の説明である。
【００６９】
次に図６を参照して、本発明の実施形態における、タスク実行処理の流れについて説明する。
【００７０】
ステップＳ６０１で、サーバ２００は、待機キュー８１０の中の未実行のメッセージの中で優先順位が最も高いメッセージ（例：データ行の先頭のメッセージ）を取得する。
【００７１】
ステップＳ６０２で、サーバ２００は、当該取得したメッセージに従ってタスクを実行する。具体的には、図８に示す実行主体管理情報８３０を参照し、メッセージ内のｔａｓｋと一致するｔａｓｋ名８３１に対応するアプリケーションＩＤ８３２のアプリケーション（８３３のサーバＩＤに示すサーバで稼動中のアプリケーション）に対して当該メッセージを送信し、メッセージ内のパラメータに従ったタスクを実行するよう依頼する。
【００７２】
つまりタスクの実行を開始する。サーバ２００は、タスク実行開始に伴い、当該タスクのメッセージを待機キュー８１０から、実行中のタスクのメッセージを記憶する実行キュー８２０に移動して記憶する。実行キュー８２０は各サーバ２００のメモリに予め作成・記憶されている。キューの構成（８２１、８２２）は８１０の８１１及び８１２と同じであるため説明は割愛する。構成は
【００７３】
当該要求と共にメッセージ１２１０を受け取ったアプリケーション（ここでは外部サーバ２７０の画像解析アプリケーション）は、パラメータに従ったタスクを実行する。そして、メッセージ１２１０にｒｅｓｕｌｔの欄を追加し、図１２の１２２１に示すようにタスクの処理結果を追記して、応答メッセージとして依頼元（ここではサーバ２００）に送信する。図１２の１２２０は応答メッセージの一例である。
【００７４】
処理失敗の場合には、ｒｅｓｕｌｔ欄にｅｒｒｏｒｃｏｄｅとｅｒｒｏｒｉｎｆｏが記載される。処理成功の場合には、例えばｓｕｃｓｅｓｓが記載される。
【００７５】
なお、タスクを実行したのが自分自身（例えば、サーバ２００自身の人物特定アプリケーション）の場合には、自分自身が当該メッセージのｒｅｓｕｌｔ欄にタスクの実行結果を書き込むこととなる。
【００７６】
ステップＳ６０３で、サーバ２００は、ステップＳ６０２での要求に対する応答メッセージ（処理結果）を、タスクの依頼先のアプリケーションから受信し、当該タスクが正常に完了したか判定する。例えばｒｅｓｕｌｔにエラーが記載されている場合にはタスクが正常に完了しなかったと判定する。タスクが正常に完了しなかった場合には処理をステップＳ６０４に移行する。
【００７７】
ステップＳ６０４で、サーバ２００は、待機キュー８１０内の、当該タスクのメッセージのリトライカウントの項目を参照し、リトライ回数を１カウントアップする。カウントアップ後のメッセージの一例を図１２の１２３０（特に１２３１）に示す。
【００７８】
その後、サーバ２００は、処理失敗の情報と共に当該メッセージ１２３０を実行結果メッセージとしてキューサーバ２５０に送信する。キューサーバ２５０はこれを受信し、当該メッセージを処理要求キュー８００に格納しなおす。つまりリトライタスクとして記憶しなおす。以上が図６の説明である。
【００７９】
次に図７を参照して、本発明の実施形態における、タスクの優先順位決定処理の流れについて説明する。
【００８０】
ステップＳ７０１で、サーバ２００は、実行可能なタスクを全て取得する。具体的には、待機キューの中のメッセージ（実行中でないタスクのメッセージ）を全て取得する。
【００８１】
サーバ２００は、取得した全てのメッセージに対してステップＳ７０２〜Ｓ７１１の処理を適用する。全てのメッセージに対して処理を適用した場合に、図７の処理を終了する。
【００８２】
ステップＳ７０２で、サーバ２００は、図７の処理を未適用のメッセージを１つ取得する。そして、当該メッセージに基づくタスクの処理開始から終了までの予定時間を特定し、予定時間８２２に記憶する。予定時間は、当該メッセージと同様のメッセージに基づくタスクの過去の実行履歴を読み出して算出する、処理の開始から完了までにかかった平均時間である。
【００８３】
また、サーバ２００は、当該タスクの完了予定時刻を特定する。完了予定時刻は、現在時刻から予定時間８２２だけ後の時刻である。
【００８４】
ステップＳ７０３で、サーバ２００は、タスクの完了予定時刻が、シャットダウン予定時刻に達しているか判定する。つまり、シャットダウンまでに完了するタスクのメッセージか判定する。
【００８５】
シャットダウンまでに完了しないタスクのメッセージである場合、処理をステップＳ７１０に移行して、当該メッセージを、実行しないタスクのメッセージ一覧（非実施タスク一覧／不図示）に移動して記憶する。当該非実施タスクとしての記憶処理は、タスクの優先度を下げる処理である。シャットダウンまでに完了するタスクのメッセージである場合、処理をステップＳ７０４に移行する。
【００８６】
ステップＳ７０４で、サーバ２００は、当該メッセージによるタスクがリトライ中か判定する。つまり、リトライによる実行を待機している状態か判定する。
【００８７】
具体的には、当該メッセージの本文（図１２の１２１０〜１２３０に例示）をサーバ２００の外部メモリ２１１から取得する。そして、当該メッセージの中のリトライカウントの項目に１以上の値が挿入されている場合にリトライ中と判定する。０の場合には初回の処理と判定する。
【００８８】
リトライ中である場合には処理をステップＳ７０５に移行する。リトライ中でない場合には処理をステップＳ７１１に移行する。
【００８９】
ステップＳ７０５で、サーバ２００は、リトライの原因を特定する。具体的には、まず当該メッセージの本文（図１２に例示）におけるｒｅｓｕｌｔの記載を読み出し、エラーコードを特定する。
【００９０】
そして予め外部メモリに記憶されている例外判定基準情報８４０を読み出して、読み出したエラーコード（ｅｒｒｏｒｃｏｄｅ８４１）に対応する例外種別８４３を特定する。なお、エラーコードが記載されていない場合は、ｅｒｒｏｒｉｎｆｏを読み出して（ｅｒｒｏｒｉｎｆｏ８４２）に対応する例外種別８４３を特定するものとする。
【００９１】
対応する例外種別８４３が「論理例外」となっている場合に、当該メッセージのタスクのエラーは論理例外であると判定する。つまり、そのタスクを実行している自機のアプリケーション自体（例えばサーバ２００の人物特定アプリケーション）で論理的に発生しうる例外（論理例外）が原因でリトライがされていると判定する。
【００９２】
一方、対応する例外種別８４３が「システム例外」となっている場合には、当該メッセージのタスクのエラーはシステム例外であると判定する。つまり、そのタスクを実行しているアプリケーションと連携する外部アプリケーション（例えば外部サーバ２７０の画像解析アプリケーション）のエラーに起因する例外（システム例外）が原因でリトライがされていると判定する。
【００９３】
ステップＳ７０６で、サーバ２００は、リトライの原因が論理例外かシステム例外か判定する。
【００９４】
なお、１つのサーバ２００につき１つのアプリケーションの機能を提供している場合、論理例外である場合とは、ステップＳ７０６の判定を行った自機自身に問題があると判定した場合である。また、システム例外である場合とは、ステップＳ７０６の判定を行った自機と連携している他のサーバ２００（他機）に問題があると判定した場合である。
【００９５】
論理例外の場合には、そのタスクを実行しているアプリケーション自体に問題があり、自動的に問題が解決する見込みは薄いと判断し、処理をステップＳ７１０に移行する。
【００９６】
システム例外の場合には、例えば連携先のアプリケーションにタスクの一部を委託すべく要求を送信した際に、たまたま連携先のアプリケーションがビジー状態で要求を受け取れなかっただけ等、状況が変われば問題が解決されていることが見込まれるため、処理をステップＳ７１０に移行する。
【００９７】
ステップＳ７０７で、サーバ２００は、リトライの原因となったアプリケーションのヘルスチェックプログラムを動作させる。ヘルスチェックプログラムは、ヘルスチェックの結果、対象のアプリケーションが正常に動作していないと結論付けた場合には動作を正常化するよう試行する。
【００９８】
ステップＳ７０８で、サーバ２００は、ヘルスチェックプログラムによるヘルスチェックの最終結果を取得し、リトライの原因となったアプリケーションが正常に動作しているか判定する。
【００９９】
正常に動作していない場合は処理をステップＳ７１０に移行する。正常に動作している場合には処理をステップＳ７０９に移行する。
【０１００】
ステップＳ７０９で、サーバ２００は、リトライの原因がシステム例外であると判定された対象のメッセージの、待機キュー８１０における順位を、予定時間８２２が当該対象のメッセージの次に短いメッセージの前に移動する。優先順位の変更の様子を図８の８６０に示す。
【０１０１】
ステップＳ７１１で、サーバ２００は、リトライ中でないと判定されたメッセージの、待機キュー８１０における順位を変更しないことを決定し、順位をそのままとする。以上が図７の説明である。
【０１０２】
以上説明したように、本発明によれば、リトライにかかる情報を用いて、処理の優先順位の決定を容易に行える仕組みを提供することができる。
【０１０３】
また、処理リソースの減少に際し、減じる処理リソースを使って実行する処理のリトライ状況に応じて、当該処理の実行にかかる決定をすることができる。
【０１０４】
なお、上述した実施形態においては、リトライの原因が論理例外である未実行のタスクを、処理しないタスクとして決定して実行優先度を下げるものとしたが、例えば実行中の処理の優先度を変更するようにしてもよい。具体的には、ステップＳ７０２以下の処理を実行中のタスクにも適用する。実行中のタスクの場合、ステップＳ７１０では、当該タスクの実行を中断する。これにより、リトライされる可能性が高いタスクが既に実行中でも、今までのタスク実行に使った以上の処理リソースを浪費することがないよう、タスクの優先度を決定することができる。
【０１０５】
なお、図７の優先順位決定処理の処理タイミングは、例えばステップＳ５０１とＳ５０２の間とし、ステップＳ５０１で取得したメッセージを対象にして図７のステップＳ７０２以降の処理を適用するようにしてもよい。これにより、論理例外でリトライ中のタスクのメッセージを待機キューに一度記憶する処理を省略することができる。
【０１０６】
尚、本発明は、例えば、システム、装置、方法、プログラム若しくは記憶媒体等としての実施形態も可能であり、具体的には、複数の機器から構成されるシステムに適用してもよいし、また、１つの機器からなる装置に適用してもよい。
【０１０７】
具体的には、キューサーバ２５０とサーバ２００が一体であってもよい。また、監視サーバ２６０とキューサーバ２５０が一体であってもよい。また、外部サーバ２７０の機能をサーバ２００Ａ〜Ｃのうちいずれかのサーバが保持するようにしてもよい。
【０１０８】
なお、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラムを、システム或いは装置に直接、或いは遠隔から供給するものを含む。そして、そのシステム或いは装置のコンピュータが前記供給されたプログラムコードを読み出して実行することによっても達成される場合も本発明に含まれる。
【０１０９】
したがって、本発明の機能処理をコンピュータで実現するために、前記コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。
【０１１０】
プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷなどがある。また、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などもある。
【０１１１】
その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続する。そして、前記ホームページから本発明のコンピュータプログラムそのもの、若しくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。
【０１１２】
また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。
【０１１３】
また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせる。そして、ダウンロードした鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。
【０１１４】
また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される。その他、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部又は全部を行い、その処理によっても前述した実施形態の機能が実現され得る。
【０１１５】
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれる。その後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部又は全部を行い、その処理によっても前述した実施形態の機能が実現される。
【０１１６】
尚、前述した実施形態は、本発明を実施するにあたっての具体化の例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。
即ち、本発明はその技術思想、又はその主要な特徴から逸脱することなく、様々な形で実施することができる。
【符号の説明】
【０１１７】
１００    ＰＣ
１０１    ネットワーク
２００Ａ  サーバ
２００Ｂ  サーバ
２００Ｃ  サーバ
２５０    キューサーバ
２６０    監視サーバ
２７０    外部サーバ
【図１】
2018106387.tif 000003
【図２】
2018106387.tif 000004
【図３】
2018106387.tif 000005
【図４】
2018106387.tif 000006
【図５】
2018106387.tif 000007
【図６】
2018106387.tif 000008
【図７】
2018106387.tif 000009
【図８】
2018106387.tif 000010
【図９】
2018106387.tif 000011
【図１０】
2018106387.tif 000012
【図１１】
2018106387.tif 000013
【図１２】
2018106387.tif 000014