JP7135648B2 - 中継システム - Google Patents
中継システム Download PDFInfo
- Publication number
- JP7135648B2 JP7135648B2 JP2018176618A JP2018176618A JP7135648B2 JP 7135648 B2 JP7135648 B2 JP 7135648B2 JP 2018176618 A JP2018176618 A JP 2018176618A JP 2018176618 A JP2018176618 A JP 2018176618A JP 7135648 B2 JP7135648 B2 JP 7135648B2
- Authority
- JP
- Japan
- Prior art keywords
- request
- service
- plug
- failure
- state
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2023—Failover techniques
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3442—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for planning or managing the needed capacity
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0751—Error or fault detection not based on redundancy
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0733—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a data processing system embedded in an image processing device, e.g. printer, facsimile, scanner
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/85—Active fault masking without idle spares
Description
本発明は、中継システムに関する。
ジョブを処理する装置の動作状況を監視し、ジョブを処理する装置の処理数が基準を越える場合、いずれか１つのジョブ処理装置のタスクを増加させる機能を備えるシステムがある。
要求の状況に応じて、計算資源の増減を指示するシステムにおいて、要求の増加が障害に起因する場合でも、追加の計算資源が割り当てられることがある。
本発明は、要求の増加が障害に起因する場合であっても、追加の計算資源が割り当てられることを抑制することを目的とする。
請求項１に記載の発明は、記憶部から要求を読み出して処理する処理部に関する障害の発生を検知する検知手段と、前記記憶部に記憶された要求の状態を監視し、前記記憶部に記憶された要求の状態に応じて、計算資源の増減を指示する監視手段と、前記検知手段が前記処理部の動作の停止を伴う障害を検知した場合、前記記憶部の状態を、前記監視手段により計算資源の追加が不要であると判断される状態に制御する制御手段と、を有する中継システムである。
請求項２に記載の発明は、前記制御手段は、検知された前記障害に関連する前記処理部に対応付けられた処理中の要求に関する状態を、当該処理部が前記記憶部から当該処理中の要求を取り出せない状態に制御する、ことを特徴とする請求項１に記載の中継システムである。
請求項３に記載の発明は、前記制御手段は、前記障害が検知された前記処理部による実行に備えて前記記憶部に記憶された待機中の要求の状態を、当該記憶部から要求を取り出せない状態に制御する、請求項１又は２に記載の中継システムである。
請求項４に記載の発明は、前記制御手段は、前記障害が検知された場合に、前記記憶部に記憶された要求の数が、予め定めた値を超えていないようにみせる制御を実行する、請求項１に記載の中継システムである。
請求項５に記載の発明は、要求を前記記憶部に記憶する前に、要求を処理する前記処理部について前記障害が検知された場合に、前記制御手段は、当該記憶部に記憶する当該障害が検知された後に発生した要求の状態を、当該記憶部から前記処理部に取り出せない状態に設定する、請求項１～３のいずれか１項に記載の中継システムである。
請求項６に記載の発明は、要求を処理する前記処理部について前記障害が検知された場合に、前記制御手段は、当該障害が検知された後に発生した要求を前記記憶部に書き込まずに廃棄する、請求項１～３のいずれか１項に記載の中継システムである。
請求項７に記載の発明は、前記制御手段は、前記障害が発生していない状態になったことが前記検知手段によって検知された場合、前記記憶部に保持されている要求の状態を、当該記憶部から前記処理部が要求を取り出せない状態から当該記憶部から当該処理部が要求を取り出せる状態に変更する、請求項２に記載の中継システムである。
請求項２に記載の発明は、前記制御手段は、検知された前記障害に関連する前記処理部に対応付けられた処理中の要求に関する状態を、当該処理部が前記記憶部から当該処理中の要求を取り出せない状態に制御する、ことを特徴とする請求項１に記載の中継システムである。
請求項３に記載の発明は、前記制御手段は、前記障害が検知された前記処理部による実行に備えて前記記憶部に記憶された待機中の要求の状態を、当該記憶部から要求を取り出せない状態に制御する、請求項１又は２に記載の中継システムである。
請求項４に記載の発明は、前記制御手段は、前記障害が検知された場合に、前記記憶部に記憶された要求の数が、予め定めた値を超えていないようにみせる制御を実行する、請求項１に記載の中継システムである。
請求項５に記載の発明は、要求を前記記憶部に記憶する前に、要求を処理する前記処理部について前記障害が検知された場合に、前記制御手段は、当該記憶部に記憶する当該障害が検知された後に発生した要求の状態を、当該記憶部から前記処理部に取り出せない状態に設定する、請求項１～３のいずれか１項に記載の中継システムである。
請求項６に記載の発明は、要求を処理する前記処理部について前記障害が検知された場合に、前記制御手段は、当該障害が検知された後に発生した要求を前記記憶部に書き込まずに廃棄する、請求項１～３のいずれか１項に記載の中継システムである。
請求項７に記載の発明は、前記制御手段は、前記障害が発生していない状態になったことが前記検知手段によって検知された場合、前記記憶部に保持されている要求の状態を、当該記憶部から前記処理部が要求を取り出せない状態から当該記憶部から当該処理部が要求を取り出せる状態に変更する、請求項２に記載の中継システムである。
請求項１記載の発明によれば、要求の増加が障害に起因する場合であっても、追加の計算資源が割り当てられることを抑制できる。
請求項２記載の発明によれば、障害が検知された場合に処理中の要求を、障害に関連する処理部に取り出せないようにできる。
請求項３記載の発明によれば、障害の発生前に記憶部に記憶された待機中の要求を、障害に関連する処理部に取り出せないようにできる。
請求項４記載の発明によれば、障害が発生している間、追加の計算資源を必要としない状態にみせかけることができる。
請求項５記載の発明によれば、障害の発生が検知された後に記憶部に要求が記憶される場合でも、記憶された要求が障害に関連する処理部に取り出せないようにできる。
請求項６記載の発明によれば、障害の発生が検知された後は記憶部に新たな要求が記憶されないようにできる。
請求項７記載の発明によれば、要求の増加が障害に起因する場合であっても、追加の計算資源が割り当てられることを抑制できる。
請求項２記載の発明によれば、障害が検知された場合に処理中の要求を、障害に関連する処理部に取り出せないようにできる。
請求項３記載の発明によれば、障害の発生前に記憶部に記憶された待機中の要求を、障害に関連する処理部に取り出せないようにできる。
請求項４記載の発明によれば、障害が発生している間、追加の計算資源を必要としない状態にみせかけることができる。
請求項５記載の発明によれば、障害の発生が検知された後に記憶部に要求が記憶される場合でも、記憶された要求が障害に関連する処理部に取り出せないようにできる。
請求項６記載の発明によれば、障害の発生が検知された後は記憶部に新たな要求が記憶されないようにできる。
請求項７記載の発明によれば、要求の増加が障害に起因する場合であっても、追加の計算資源が割り当てられることを抑制できる。
以下、図面を参照して、本発明の実施の形態を説明する。
＜実施の形態１＞
＜システム構成＞
図１は、実施の形態１に係るクラウド連携システム１の構成例を示す。
クラウド連携システム１は、文書の処理を要求する入力装置１００と、入力装置１００から受信した要求を処理してクラウド上のサービス（以下「クラウドサービス」ともいう）との連携を実現する中継装置２００と、クラウドネットワーク３００と、クラウドサービスの一例であるストレージ型クラウドサーバ４００Ａと、業務支援型クラウドサーバ４００Ｂとを有している。
ここでの中継装置２００は、中継システムの一例であり、クラウドネットワーク３００に接続されている。
＜実施の形態１＞
＜システム構成＞
図１は、実施の形態１に係るクラウド連携システム１の構成例を示す。
クラウド連携システム１は、文書の処理を要求する入力装置１００と、入力装置１００から受信した要求を処理してクラウド上のサービス（以下「クラウドサービス」ともいう）との連携を実現する中継装置２００と、クラウドネットワーク３００と、クラウドサービスの一例であるストレージ型クラウドサーバ４００Ａと、業務支援型クラウドサーバ４００Ｂとを有している。
ここでの中継装置２００は、中継システムの一例であり、クラウドネットワーク３００に接続されている。
入力装置１００は、クラウドサービスに登録されているユーザが操作する端末である。本実施の形態では、入力装置１００として、例えば画像処理装置、スマートフォンを想定する。
ここでの画像処理装置には、ＦＡＸ文書を送受信するＦＡＸ機能の他、複製物を生成するコピー機能、原稿の画像を読み取るスキャン機能、用紙その他の記録媒体に画像を印刷する印刷機能等が設けられている。もっとも、画像処理装置は、これら全ての機能を備える必要はなく、いずれか１つの機能に特化した装置であってもよい。
本実施の形態の場合、ＦＡＸ文書は、ファクシミリによって送受信される写真、文字、図形などの文書の意味で使用する。
例えば入力装置１００は、スキャン文書をユーザが希望するクラウドサービスに直接登録するために使用される。また例えば入力装置１００は、ユーザが希望する文書を複数のクラウドサービスから検索してプリントアウトするために使用される。また例えば入力装置１００は、プリントドライバーやコンピュータを使用せずに文書ファイルや画像ファイル等をプリントするために使用される。
図１の場合には、入力装置１００と中継装置２００は独立した装置として描いているが、中継装置２００は、入力装置１００に内蔵されていてもよい。
ここでの画像処理装置には、ＦＡＸ文書を送受信するＦＡＸ機能の他、複製物を生成するコピー機能、原稿の画像を読み取るスキャン機能、用紙その他の記録媒体に画像を印刷する印刷機能等が設けられている。もっとも、画像処理装置は、これら全ての機能を備える必要はなく、いずれか１つの機能に特化した装置であってもよい。
本実施の形態の場合、ＦＡＸ文書は、ファクシミリによって送受信される写真、文字、図形などの文書の意味で使用する。
例えば入力装置１００は、スキャン文書をユーザが希望するクラウドサービスに直接登録するために使用される。また例えば入力装置１００は、ユーザが希望する文書を複数のクラウドサービスから検索してプリントアウトするために使用される。また例えば入力装置１００は、プリントドライバーやコンピュータを使用せずに文書ファイルや画像ファイル等をプリントするために使用される。
図１の場合には、入力装置１００と中継装置２００は独立した装置として描いているが、中継装置２００は、入力装置１００に内蔵されていてもよい。
＜中継装置の構成＞
図２は、実施の形態に係る中継装置２００のハードウェア構成の一例を示す図である。
図２に示す中継装置２００は、いわゆるコンピュータとしての構成を有している。
このため、中継装置２００は、プログラム（ファームウェアを含む）の実行を通じて装置全体を制御するＣＰＵ２０１と、ＢＩＯＳ（Basic Input Output System）等のプログラムを記憶するＲＯＭ２０２と、プログラムの実行領域として使用されるＲＡＭ２０３と、ＣＰＵ２０１で実行されるプログラム、画像データ、管理データ等が記憶されるハードディスク装置（ＨＤＤ）２０４と、外部との通信に用いられる通信インターフェース（通信ＩＦ）２０５と、を有している。
これらの各部は、バス２０６又は不図示の信号線を通じて互いに接続されている。
図２は、実施の形態に係る中継装置２００のハードウェア構成の一例を示す図である。
図２に示す中継装置２００は、いわゆるコンピュータとしての構成を有している。
このため、中継装置２００は、プログラム（ファームウェアを含む）の実行を通じて装置全体を制御するＣＰＵ２０１と、ＢＩＯＳ（Basic Input Output System）等のプログラムを記憶するＲＯＭ２０２と、プログラムの実行領域として使用されるＲＡＭ２０３と、ＣＰＵ２０１で実行されるプログラム、画像データ、管理データ等が記憶されるハードディスク装置（ＨＤＤ）２０４と、外部との通信に用いられる通信インターフェース（通信ＩＦ）２０５と、を有している。
これらの各部は、バス２０６又は不図示の信号線を通じて互いに接続されている。
図３は、中継装置２００の機能構成例を説明する図である。
図３に示す機能は、ＣＰＵ２０１（図２参照）によるプログラムの実行を通じて実現される。
図３に示す中継装置２００は、内部と外部の通信を管理するコアサービス２１１と、タスクの定義を格納するタスク定義モジュール２１２と、文書を処理するプラグインサービス２１４の呼び出し要求（リクエスト）を保持するキュー２１３と、要求に基づいて文書を処理するプラグインサービス２１４と、キュー２１３に保持されている要求の数に基づいてプラグインサービス２１４の起動と停止を管理するオートスケール管理部２１５と、キュー２１３に保持されている要求を処理するプラグインサービス２１４やクラウドサーバに起因する障害を検知する障害検知部２１６と、障害の発生に起因する未処理の要求の数の増加の場合にはオートスケール処理が実行されないようにキュー２１３の状態を制御するリクエスト制御部２１７とを有している。
プラグインサービス２１４の起動は、クラウドネットワーク上での計算資源の追加を伴い、プラグインサービス２１４の停止は、クラウドネットワーク上での計算資源の解放を伴う。前述したオートスケール管理部２１５は、この起動と停止を管理する。
ここでの計算資源は、例えばプラグインサービスなどのアプリケーションを動作させるための実行環境をいう。
図３に示す機能は、ＣＰＵ２０１（図２参照）によるプログラムの実行を通じて実現される。
図３に示す中継装置２００は、内部と外部の通信を管理するコアサービス２１１と、タスクの定義を格納するタスク定義モジュール２１２と、文書を処理するプラグインサービス２１４の呼び出し要求（リクエスト）を保持するキュー２１３と、要求に基づいて文書を処理するプラグインサービス２１４と、キュー２１３に保持されている要求の数に基づいてプラグインサービス２１４の起動と停止を管理するオートスケール管理部２１５と、キュー２１３に保持されている要求を処理するプラグインサービス２１４やクラウドサーバに起因する障害を検知する障害検知部２１６と、障害の発生に起因する未処理の要求の数の増加の場合にはオートスケール処理が実行されないようにキュー２１３の状態を制御するリクエスト制御部２１７とを有している。
プラグインサービス２１４の起動は、クラウドネットワーク上での計算資源の追加を伴い、プラグインサービス２１４の停止は、クラウドネットワーク上での計算資源の解放を伴う。前述したオートスケール管理部２１５は、この起動と停止を管理する。
ここでの計算資源は、例えばプラグインサービスなどのアプリケーションを動作させるための実行環境をいう。
本実施の形態では、図３に示す全ての機能が１台の中継装置２００によって実現されているが、これらの機能は複数の処理装置の協働によって実現されてもよい。その場合、互いに協働する複数台の処理装置は、中継システムの一例である。協働する複数台の処理装置は、図２に示すハードウェア構成を有してもよい。また、全ての機能がプログラムの実行を通じて実現されなくてもよい。すなわち、一部の機能は、論理回路として実現されてもよい。
＜コアサービス２１１＞
コアサービス２１１は、入力装置１００と通信するタスクサービス２１１Ａと、業務支援型クラウドサーバ４００Ｂと通信する通信サービス２１１Ｂと、ストレージ型クラウドサーバ４００Ａと通信する通信サービス２１１Ｃとを含んでいる。
タスクサービス２１１Ａは、入力装置１００（図１参照）から受信された通知又は要求に基づいて、タスク定義モジュール２１２のイベント処理モジュール２１２Ａを起動し、要求を実現するタスクを取得する。
「タスク」は、１つ又は複数のプラグインサービス２１４により実行される一連の作業である。タスク定義ライブラリ２１２Ｂには、タスク別に、呼び出しの対象となるプラグインサービス２１４の組み合わせが記録されている。
コアサービス２１１は、入力装置１００と通信するタスクサービス２１１Ａと、業務支援型クラウドサーバ４００Ｂと通信する通信サービス２１１Ｂと、ストレージ型クラウドサーバ４００Ａと通信する通信サービス２１１Ｃとを含んでいる。
タスクサービス２１１Ａは、入力装置１００（図１参照）から受信された通知又は要求に基づいて、タスク定義モジュール２１２のイベント処理モジュール２１２Ａを起動し、要求を実現するタスクを取得する。
「タスク」は、１つ又は複数のプラグインサービス２１４により実行される一連の作業である。タスク定義ライブラリ２１２Ｂには、タスク別に、呼び出しの対象となるプラグインサービス２１４の組み合わせが記録されている。
図４は、タスクサービス２１１Ａに設けられる機能の一例を説明する図である。
本実施の形態におけるタスクサービス２１１Ａは、プラグイン状態要求機能２１１Ａ１と取得不可リクエスト格納機能２１１Ａ２とを有する。
プラグイン状態要求機能２１１Ａ１は、入力装置１００（図１参照）からの要求およびタスクの定義に基づいて、リクエスト制御部２１７（図３参照）に対してプラグインサービス２１４（図３参照）の状態を要求する。
取得不可リクエスト格納機能２１１Ａ２は、リクエスト制御部２１７からの応答により確認されたプラグインサービス２１４の状態が非動作中（inactive）の場合に、キュー２１３（図３参照）に格納する要求の状態を、オートスケール管理部２１５から見えない状態（invisible）に設定する。以下では、この状態を不可視の状態ともいう。
換言すると、障害の検知後にキュー２１３に記憶される要求は、オートスケール管理部２１５から見えない状態に制御される。この結果、キュー２１３に保持されたまま滞留する未処理の要求が増加する場合でも、滞留が障害に起因するときには、オートスケール管理部２１５によって処理能力の不足が生じているとは誤判定されないようになる。すなわち、障害が検知されている間は、オートスケール管理部２１５によるプラグインサービス２１４（図３参照）の追加を予防できる。
図３の説明に戻る。
本実施の形態におけるタスクサービス２１１Ａは、プラグイン状態要求機能２１１Ａ１と取得不可リクエスト格納機能２１１Ａ２とを有する。
プラグイン状態要求機能２１１Ａ１は、入力装置１００（図１参照）からの要求およびタスクの定義に基づいて、リクエスト制御部２１７（図３参照）に対してプラグインサービス２１４（図３参照）の状態を要求する。
取得不可リクエスト格納機能２１１Ａ２は、リクエスト制御部２１７からの応答により確認されたプラグインサービス２１４の状態が非動作中（inactive）の場合に、キュー２１３（図３参照）に格納する要求の状態を、オートスケール管理部２１５から見えない状態（invisible）に設定する。以下では、この状態を不可視の状態ともいう。
換言すると、障害の検知後にキュー２１３に記憶される要求は、オートスケール管理部２１５から見えない状態に制御される。この結果、キュー２１３に保持されたまま滞留する未処理の要求が増加する場合でも、滞留が障害に起因するときには、オートスケール管理部２１５によって処理能力の不足が生じているとは誤判定されないようになる。すなわち、障害が検知されている間は、オートスケール管理部２１５によるプラグインサービス２１４（図３参照）の追加を予防できる。
図３の説明に戻る。
＜キュー２１３＞
キュー２１３は、プラグインサービス２１４を呼び出す要求を保持する記憶部の一例である。
本実施の形態の場合、キュー２１３は、プラグインサービス２１４毎に用意されている。もっとも、後述するように、キュー２１３は、複数のプラグインサービス２１４について共用されてもよい。
キュー２１３は、プラグインサービス２１４を呼び出す要求を保持する記憶部の一例である。
本実施の形態の場合、キュー２１３は、プラグインサービス２１４毎に用意されている。もっとも、後述するように、キュー２１３は、複数のプラグインサービス２１４について共用されてもよい。
＜プラグインサービス２１４＞
プラグインサービス２１４は、実行する処理の内容に応じて複数の種類がある。例えば文書の処理に用いられるプラグインサービス２１４Ａとストレージへの文書の登録に用いられるプラグインサービス２１４Ｂがある。
プラグインサービス２１４Ａは、文書処理プラグイン２１４Ａ１と、プラグインライブラリ２１４Ａ２と、リクエスト処理完了通知機能２１４Ａ３とを含んでいる。
プラグインサービス２１４Ｂは、ストレージ登録プラグイン２１４Ｂ１と、プラグインライブラリ２１４Ｂ２と、リクエスト処理完了通知機能２１４Ｂ３とを含んでいる。
ここでのリクエスト処理完了通知機能２１４Ａ３及び２１４Ｂ３は、要求に関する処理の完了をリクエスト制御部２１７に通知する。
ここでのプラグインサービス２１４は、キュー２１３から要求を読み出して処理する処理部の一例である。なお、要求を処理するストレージ型クラウドサーバ４００Ａ（図１参照）及び業務支援型クラウドサーバ４００Ｂ（図１参照）も処理部の一例である。
プラグインサービス２１４は、実行する処理の内容に応じて複数の種類がある。例えば文書の処理に用いられるプラグインサービス２１４Ａとストレージへの文書の登録に用いられるプラグインサービス２１４Ｂがある。
プラグインサービス２１４Ａは、文書処理プラグイン２１４Ａ１と、プラグインライブラリ２１４Ａ２と、リクエスト処理完了通知機能２１４Ａ３とを含んでいる。
プラグインサービス２１４Ｂは、ストレージ登録プラグイン２１４Ｂ１と、プラグインライブラリ２１４Ｂ２と、リクエスト処理完了通知機能２１４Ｂ３とを含んでいる。
ここでのリクエスト処理完了通知機能２１４Ａ３及び２１４Ｂ３は、要求に関する処理の完了をリクエスト制御部２１７に通知する。
ここでのプラグインサービス２１４は、キュー２１３から要求を読み出して処理する処理部の一例である。なお、要求を処理するストレージ型クラウドサーバ４００Ａ（図１参照）及び業務支援型クラウドサーバ４００Ｂ（図１参照）も処理部の一例である。
＜オートスケール管理部２１５＞
オートスケール管理部２１５は、キュー２１３に保持されている要求の数に基づいて、プラグインサービスの起動および停止を管理する。
オートスケール管理部２１５は、キュー２１３に保持されている要求の数が予め定めた値（第１の値）を上回る場合、計算資源の一例を追加で確保したのちに、新たなプラグインサービス２１４を起動し、キュー２１３に保持されている要求の数が予め定めた値（第２の値）を下回る場合、プラグインサービス２１４の一部を停止したのちに確保していた計算資源のうちの余剰となるものを解放する。すなわち、プラグインサービス２１４の数は、未処理の要求の数に応じて増減される。なお、第１の値は、第２の値より大きい値である。
オートスケール管理部２１５は、キュー２１３に保持されている要求の数に基づいて、プラグインサービスの起動および停止を管理する。
オートスケール管理部２１５は、キュー２１３に保持されている要求の数が予め定めた値（第１の値）を上回る場合、計算資源の一例を追加で確保したのちに、新たなプラグインサービス２１４を起動し、キュー２１３に保持されている要求の数が予め定めた値（第２の値）を下回る場合、プラグインサービス２１４の一部を停止したのちに確保していた計算資源のうちの余剰となるものを解放する。すなわち、プラグインサービス２１４の数は、未処理の要求の数に応じて増減される。なお、第１の値は、第２の値より大きい値である。
本実施の形態におけるオートスケール管理部２１５は、可視の状態（visible）にある要求の数を計数する。従って、見えない状態又は不可視の状態（invisible）に設定された要求は、オートスケール管理部２１５による計数の対象から除外される。
このため、プラグインサービス２１４やクラウドサーバの故障のために処理待ちの要求が増え続ける場合にも、これらの要求を計数の対象から除外でき、蓄積されている要求の数の低減に寄与しないプラグインサービス２１４の起動が回避される。ここでのクラウドサーバの故障は、プラグインサービス２１４の故障とは独立した故障である。
オートスケール管理部２１５は、キュー２１３に保持されている要求の状態を監視する監視手段の一例である。
このため、プラグインサービス２１４やクラウドサーバの故障のために処理待ちの要求が増え続ける場合にも、これらの要求を計数の対象から除外でき、蓄積されている要求の数の低減に寄与しないプラグインサービス２１４の起動が回避される。ここでのクラウドサーバの故障は、プラグインサービス２１４の故障とは独立した故障である。
オートスケール管理部２１５は、キュー２１３に保持されている要求の状態を監視する監視手段の一例である。
＜障害検知部２１６＞
障害検知部２１６は、プラグインサービス２１４のログなどを監視し、動作の停止を伴う障害（いわゆるfatal error）の発生と障害からの復旧を検知する。障害検知部２１６は、検知手段の一例である。
図５は、障害検知部２１６に設けられる機能の一例を説明する図である。
本実施の形態における障害検知部２１６は、障害検知機能２１６Ａと、障害復旧検知機能２１６Ｂと、プラグイン障害通知機能２１６Ｃと、プラグイン復旧通知機能２１６Ｄとを有する。
障害検知機能２１６Ａは、プラグインサービス２１４（図３参照）のログを監視し、障害メッセージを検知する。本実施の形態の場合、検知の対象とする障害は、プラグインサービス２１４の動作の停止を伴う障害である。従って、プラグインサービス２１４の動作の停止を伴わない障害メッセージは、検知の対象から除外されるようにしても良い。
障害検知部２１６は、プラグインサービス２１４のログなどを監視し、動作の停止を伴う障害（いわゆるfatal error）の発生と障害からの復旧を検知する。障害検知部２１６は、検知手段の一例である。
図５は、障害検知部２１６に設けられる機能の一例を説明する図である。
本実施の形態における障害検知部２１６は、障害検知機能２１６Ａと、障害復旧検知機能２１６Ｂと、プラグイン障害通知機能２１６Ｃと、プラグイン復旧通知機能２１６Ｄとを有する。
障害検知機能２１６Ａは、プラグインサービス２１４（図３参照）のログを監視し、障害メッセージを検知する。本実施の形態の場合、検知の対象とする障害は、プラグインサービス２１４の動作の停止を伴う障害である。従って、プラグインサービス２１４の動作の停止を伴わない障害メッセージは、検知の対象から除外されるようにしても良い。
障害復旧検知機能２１６Ｂは、プラグインサービス２１４のログを監視し、障害の復旧を検知する。本実施の形態では、プラグインサービス２１４の動作の停止を伴う障害を表すメッセージ（障害メッセージ）が検知されている状態から正常動作を表すメッセージ（正常動作メッセージ）が検知される状態に切り替わることを、障害からの復旧という。従って、障害復旧検知機能２１６Ｂは、正常動作メッセージを検知の対象とする。
プラグイン障害通知機能２１６Ｃは、動作の停止を伴うプラグインサービス２１４の情報のリクエスト制御部２１７（図３参照）への通知に用いられる。
プラグイン復旧通知機能２１６Ｄは、復旧が検知されたプラグインサービス２１４の情報のリクエスト制御部２１７への通知に用いられる。
図３の説明に戻る。
プラグイン障害通知機能２１６Ｃは、動作の停止を伴うプラグインサービス２１４の情報のリクエスト制御部２１７（図３参照）への通知に用いられる。
プラグイン復旧通知機能２１６Ｄは、復旧が検知されたプラグインサービス２１４の情報のリクエスト制御部２１７への通知に用いられる。
図３の説明に戻る。
＜リクエスト制御部２１７＞
リクエスト制御部２１７は、障害検知部２１６からの通知に基づいてキュー２１３に保持されている処理の要求（リクエスト）の状態を制御する。具体的には、リクエスト制御部２１７は、障害が通知されている特定のプラグインサービス２１４を呼び出す要求の状態を不可視の状態（invisible）に制御し、障害からの復旧が通知された特定のプラグインサービス２１４を呼び出す要求の状態を可視の状態（visible）に制御する。
ここでの不可視及び可視は、前述したように、オートスケール管理部２１５による計数の対象であるか否かによって定める。従って、不可視の状態（invisible）に制御された要求は、オートスケール管理部２１５においてはキュー２１３内に存在しないものとして扱われる。
リクエスト制御部２１７は、制御手段の一例である。
リクエスト制御部２１７は、障害検知部２１６からの通知に基づいてキュー２１３に保持されている処理の要求（リクエスト）の状態を制御する。具体的には、リクエスト制御部２１７は、障害が通知されている特定のプラグインサービス２１４を呼び出す要求の状態を不可視の状態（invisible）に制御し、障害からの復旧が通知された特定のプラグインサービス２１４を呼び出す要求の状態を可視の状態（visible）に制御する。
ここでの不可視及び可視は、前述したように、オートスケール管理部２１５による計数の対象であるか否かによって定める。従って、不可視の状態（invisible）に制御された要求は、オートスケール管理部２１５においてはキュー２１３内に存在しないものとして扱われる。
リクエスト制御部２１７は、制御手段の一例である。
図６は、リクエスト制御部２１７に設けられる機能の一例を説明する図である。
本実施の形態におけるリクエスト制御部２１７は、リクエスト取得不可機能２１７Ａと、プラグイン状態管理機能２１７Ｂと、プラグイン状態応答機能２１７Ｃと、リクエスト取得不可解除機能２１７Ｄとを有する。
リクエスト取得不可機能２１７Ａは、障害検知部２１６（図３参照）から特定のプラグインサービス２１４についての動作の停止を伴う障害が通知された場合、この特定のプラグインサービス２１４に関係する要求の状態を不可視の状態（invisible）に制御する。換言すると、不可視の状態に制御された要求は、キュー２１３から取り出せない状態に制御される。
リクエスト取得不可機能２１７Ａは、動作の停止を伴う障害が発生していないプラグインサービス２１４に関係する要求の状態については不可視の状態に変更しない。すなわち、リクエスト取得不可機能２１７Ａによる要求の状態の制御は選択的に実行される。
本実施の形態におけるリクエスト制御部２１７は、リクエスト取得不可機能２１７Ａと、プラグイン状態管理機能２１７Ｂと、プラグイン状態応答機能２１７Ｃと、リクエスト取得不可解除機能２１７Ｄとを有する。
リクエスト取得不可機能２１７Ａは、障害検知部２１６（図３参照）から特定のプラグインサービス２１４についての動作の停止を伴う障害が通知された場合、この特定のプラグインサービス２１４に関係する要求の状態を不可視の状態（invisible）に制御する。換言すると、不可視の状態に制御された要求は、キュー２１３から取り出せない状態に制御される。
リクエスト取得不可機能２１７Ａは、動作の停止を伴う障害が発生していないプラグインサービス２１４に関係する要求の状態については不可視の状態に変更しない。すなわち、リクエスト取得不可機能２１７Ａによる要求の状態の制御は選択的に実行される。
プラグイン状態管理機能２１７Ｂは、障害検知部２１６（図３参照）からの通知に基づいて、キュー２１３（図３参照）に保持されている要求についての管理情報のうち、プラグインサービス２１４の状態を動作中（active）又は非動作中（inactive）に管理する。管理情報には、要求が可視か不可視かを示す情報と、要求を処理するプラグインサービス２１４が動作中か非動作中かを示す情報とが含まれる。
障害検知部２１６（図３参照）からの通知が障害通知の場合、プラグイン状態管理機能２１７Ｂは、通知の対象である特定のプラグインサービス２１４に関する管理情報を非動作中（inactive）に変更する。
一方、障害検知部２１６（図３参照）からの通知が復旧通知の場合、プラグイン状態管理機能２１７Ｂは、通知の対象である特定のプラグインサービス２１４に関する管理情報を動作中（active）に変更する。
プラグイン状態応答機能２１７Ｃは、タスクサービス２１１Ａからの問い合わせに対し、問い合わせの対象であるプラグインサービス２１４が動作中（active）か非動作中（inactive）かを応答する。
リクエスト取得不可解除機能２１７Ｄは、障害検知部２１６からの通知が復旧通知の場合、キュー２１３に保持されている要求のうち、通知の対象である特定のプラグインサービス２１４が処理する要求の状態を見える状態又は可視の状態（visible）に制御する。換言すると、リクエスト取得不可解除機能２１７Ｄは、見えない状態又は不可視の状態（invisible）の解除を実行する。
障害検知部２１６（図３参照）からの通知が障害通知の場合、プラグイン状態管理機能２１７Ｂは、通知の対象である特定のプラグインサービス２１４に関する管理情報を非動作中（inactive）に変更する。
一方、障害検知部２１６（図３参照）からの通知が復旧通知の場合、プラグイン状態管理機能２１７Ｂは、通知の対象である特定のプラグインサービス２１４に関する管理情報を動作中（active）に変更する。
プラグイン状態応答機能２１７Ｃは、タスクサービス２１１Ａからの問い合わせに対し、問い合わせの対象であるプラグインサービス２１４が動作中（active）か非動作中（inactive）かを応答する。
リクエスト取得不可解除機能２１７Ｄは、障害検知部２１６からの通知が復旧通知の場合、キュー２１３に保持されている要求のうち、通知の対象である特定のプラグインサービス２１４が処理する要求の状態を見える状態又は可視の状態（visible）に制御する。換言すると、リクエスト取得不可解除機能２１７Ｄは、見えない状態又は不可視の状態（invisible）の解除を実行する。
＜中継装置２００の処理動作＞
以下、中継装置２００によって実行される処理動作をプラグインサービス２１４（図３参照）の動作状況に応じて説明する。
以下、中継装置２００によって実行される処理動作をプラグインサービス２１４（図３参照）の動作状況に応じて説明する。
＜障害が発生していない場合の動作＞
図７は、いずれのプラグインサービスにも障害が発生していない場合のシーケンス例を説明する図である。
図７に示すシーケンスは、タスクサービス２１１Ａ、キュー２１３、プラグインサービス２１４、障害検知部２１６、リクエスト制御部２１７の間におけるやり取りを示している。
なお、図中の記号Ｓはステップを表している。
図７は、いずれのプラグインサービスにも障害が発生していない場合のシーケンス例を説明する図である。
図７に示すシーケンスは、タスクサービス２１１Ａ、キュー２１３、プラグインサービス２１４、障害検知部２１６、リクエスト制御部２１７の間におけるやり取りを示している。
なお、図中の記号Ｓはステップを表している。
・ステップ１
入力装置１００（図３参照）から処理の要求を受信したタスクサービス２１１Ａは、タスク定義モジュール２１２を通じて、受信した要求の処理に使用するプラグインサービス２１４の情報を取得する。
次に、タスクサービス２１１Ａは、リクエスト制御部２１７に対し、要求の処理に使用するプラグインサービス２１４の動作の状態を問い合わせる。例えば要求が業務支援型のクラウドサービスの場合、タスクサービス２１１Ａは、プラグインサービス２１４Ａ（図３参照）の動作の状態を問い合わせる。
図７の場合、タスクサービス２１１Ａは、リクエスト制御部２１７からの状態の応答として、動作中（active）を受け取る。
入力装置１００（図３参照）から処理の要求を受信したタスクサービス２１１Ａは、タスク定義モジュール２１２を通じて、受信した要求の処理に使用するプラグインサービス２１４の情報を取得する。
次に、タスクサービス２１１Ａは、リクエスト制御部２１７に対し、要求の処理に使用するプラグインサービス２１４の動作の状態を問い合わせる。例えば要求が業務支援型のクラウドサービスの場合、タスクサービス２１１Ａは、プラグインサービス２１４Ａ（図３参照）の動作の状態を問い合わせる。
図７の場合、タスクサービス２１１Ａは、リクエスト制御部２１７からの状態の応答として、動作中（active）を受け取る。
・ステップ２
タスクサービス２１１Ａは、キュー２１３に処理の要求を記憶する。
図８は、要求の状態の管理に使用する状態表５００の例を説明する図である。状態表５００は、前述した管理情報に対応する。
状態表５００は、リクエストＩＤ５０１、リクエスト状態５０２、プラグインサービスＩＤ５０３、プラグインサービス状態５０４で構成される。
図８の場合、管理されている要求は、リクエストＩＤが「ＲＥＱ００００１」の１つだけであり、状態は可視の状態（visible）である。また、要求の処理に使用するプラグインサービスのＩＤは「ＰＬＵＧ００１」であり、その状態は動作中（active）である。
図７の説明に戻る。
タスクサービス２１１Ａは、キュー２１３に処理の要求を記憶する。
図８は、要求の状態の管理に使用する状態表５００の例を説明する図である。状態表５００は、前述した管理情報に対応する。
状態表５００は、リクエストＩＤ５０１、リクエスト状態５０２、プラグインサービスＩＤ５０３、プラグインサービス状態５０４で構成される。
図８の場合、管理されている要求は、リクエストＩＤが「ＲＥＱ００００１」の１つだけであり、状態は可視の状態（visible）である。また、要求の処理に使用するプラグインサービスのＩＤは「ＰＬＵＧ００１」であり、その状態は動作中（active）である。
図７の説明に戻る。
・ステップ３
キュー２１３は、要求を処理するプラグインサービス２１４を呼び出す。
呼び出されるプラグインサービス２１４は、プラグインサービスＩＤ５０３（図８参照）により特定される。
・ステップ４
プラグインサービス２１４は、要求を処理する。
・ステップ５
処理の完了を検知すると、プラグインサービス２１４は、リクエスト制御部２１７に対して要求の処理の完了を通知する。
この通知の受信により、リクエスト制御部２１７は、通知を送信したプラグインサービス２１４の正常動作を知る。
キュー２１３は、要求を処理するプラグインサービス２１４を呼び出す。
呼び出されるプラグインサービス２１４は、プラグインサービスＩＤ５０３（図８参照）により特定される。
・ステップ４
プラグインサービス２１４は、要求を処理する。
・ステップ５
処理の完了を検知すると、プラグインサービス２１４は、リクエスト制御部２１７に対して要求の処理の完了を通知する。
この通知の受信により、リクエスト制御部２１７は、通知を送信したプラグインサービス２１４の正常動作を知る。
＜プラグインサービスで障害が発生した場合の動作１＞
図９は、プラグインサービス２１４に障害が発生した場合のシーケンス例を説明する図である。
図９に示すシーケンスは、入力装置１００、タスクサービス２１１Ａ、キュー２１３、プラグインサービス２１４、障害検知部２１６、リクエスト制御部２１７の間におけるやり取りを示している。
なお、図中の記号Ｓはステップを表している。
図９は、プラグインサービス２１４に障害が発生した場合のシーケンス例を説明する図である。
図９に示すシーケンスは、入力装置１００、タスクサービス２１１Ａ、キュー２１３、プラグインサービス２１４、障害検知部２１６、リクエスト制御部２１７の間におけるやり取りを示している。
なお、図中の記号Ｓはステップを表している。
・ステップ１
障害検知部２１６は、動作の停止を伴う障害を検知する。
図１０は、障害が検知される前のキュー２１３（図３参照）に記憶されている要求の状態表５００の例である。図１０には、図８との対応部分に対応する符号を付して示している。
図１０の場合、キュー２１３に記憶されている要求は「ＲＥＱ００００１」、「ＲＥＱ００００２」、「ＲＥＱ００００３」、「ＲＥＱ００００４」の４つである。
４つのうち３つは、プラグインサービスＩＤ５０３が「ＰＬＵＧ００１」のプラグインサービス２１４で処理され、残り１つは、プラグインサービスＩＤ５０３が「ＰＬＵＧ００２」のプラグインサービス２１４で処理される。
障害が検知される前であるので、いずれの要求についてもリクエスト状態５０２は、可視の状態（visible）である。また、プラグインサービス状態５０４は、動作中（active）である。
図９の説明に戻る。
障害検知部２１６は、動作の停止を伴う障害を検知する。
図１０は、障害が検知される前のキュー２１３（図３参照）に記憶されている要求の状態表５００の例である。図１０には、図８との対応部分に対応する符号を付して示している。
図１０の場合、キュー２１３に記憶されている要求は「ＲＥＱ００００１」、「ＲＥＱ００００２」、「ＲＥＱ００００３」、「ＲＥＱ００００４」の４つである。
４つのうち３つは、プラグインサービスＩＤ５０３が「ＰＬＵＧ００１」のプラグインサービス２１４で処理され、残り１つは、プラグインサービスＩＤ５０３が「ＰＬＵＧ００２」のプラグインサービス２１４で処理される。
障害が検知される前であるので、いずれの要求についてもリクエスト状態５０２は、可視の状態（visible）である。また、プラグインサービス状態５０４は、動作中（active）である。
図９の説明に戻る。
・ステップ２
障害検知部２１６は、リクエスト制御部２１７に対し、プラグインサービス２１４の障害を通知する。
図１１は、障害通知のデータ構造の例を説明する図である。障害通知には、障害が発生したプラグインサービス２１４を特定するプラグインサービスＩＤ６０１と、プラグインサービス状態６０２が含まれる。
図１１の場合、プラグインサービスＩＤ６０１は「ＰＬＵＧ００１」であり、プラグインサービス状態６０２は非動作中（inactive）である。
・ステップ３
障害の通知を受け付けたリクエスト制御部２１７は、キュー２１３に記憶されている１個目の要求の状態を不可視の状態（invisible）に変更する。変更の成功は、キュー２１３からリクエスト制御部２１７に返送される。
障害検知部２１６は、リクエスト制御部２１７に対し、プラグインサービス２１４の障害を通知する。
図１１は、障害通知のデータ構造の例を説明する図である。障害通知には、障害が発生したプラグインサービス２１４を特定するプラグインサービスＩＤ６０１と、プラグインサービス状態６０２が含まれる。
図１１の場合、プラグインサービスＩＤ６０１は「ＰＬＵＧ００１」であり、プラグインサービス状態６０２は非動作中（inactive）である。
・ステップ３
障害の通知を受け付けたリクエスト制御部２１７は、キュー２１３に記憶されている１個目の要求の状態を不可視の状態（invisible）に変更する。変更の成功は、キュー２１３からリクエスト制御部２１７に返送される。
・ステップ４
リクエスト制御部２１７は、１個目の要求の処理の成功が確認されるまで、２個目以降の要求の状態を不可視の状態（invisible）に変更する。変更の成功は、キュー２１３からリクエスト制御部２１７に返送される。
図１２は、障害の検知後における状態表５００の例を示す図である。図１２には、図１０との対応部分に対応する符号を付して示している。
図１２の場合も、キュー２１３に記憶されている要求は４つのままであり、図１０に対して増減はない。
図１２では、プラグインサービスＩＤが「ＰＬＵＧ００１」のプラグインサービス２１４に障害が検知されているので、対応する要求の状態がいずれも不可視の状態（invisible）に変更されている。また、プラグインサービスＩＤが「ＰＬＵＧ００１」であるプラグインサービス２１４に対応するプラグインサービス状態５０４は、いずれも非動作中（inactive）に変更されている。
なお、動作の停止を伴う障害が検知されていないプラグインサービス２１４、すなわちプラグインサービスＩＤ５０３が「ＰＬＵＧ００２」のプラグインサービス２１４を使用する要求の状態は、可視の状態（visible）のままである。勿論、要求の処理に使用するプラグインサービス状態５０４は動作中（active）のままである。
図９の説明に戻る。
リクエスト制御部２１７は、１個目の要求の処理の成功が確認されるまで、２個目以降の要求の状態を不可視の状態（invisible）に変更する。変更の成功は、キュー２１３からリクエスト制御部２１７に返送される。
図１２は、障害の検知後における状態表５００の例を示す図である。図１２には、図１０との対応部分に対応する符号を付して示している。
図１２の場合も、キュー２１３に記憶されている要求は４つのままであり、図１０に対して増減はない。
図１２では、プラグインサービスＩＤが「ＰＬＵＧ００１」のプラグインサービス２１４に障害が検知されているので、対応する要求の状態がいずれも不可視の状態（invisible）に変更されている。また、プラグインサービスＩＤが「ＰＬＵＧ００１」であるプラグインサービス２１４に対応するプラグインサービス状態５０４は、いずれも非動作中（inactive）に変更されている。
なお、動作の停止を伴う障害が検知されていないプラグインサービス２１４、すなわちプラグインサービスＩＤ５０３が「ＰＬＵＧ００２」のプラグインサービス２１４を使用する要求の状態は、可視の状態（visible）のままである。勿論、要求の処理に使用するプラグインサービス状態５０４は動作中（active）のままである。
図９の説明に戻る。
・ステップ５
以下では、プラグインサービス２１４の障害が検知された後に、入力装置１００から新規の要求がタスクサービス２１１Ａに入力される場合の動作を説明する。
・ステップ６
入力装置１００から新規の要求を受信したタスクサービス２１１Ａは、タスク定義モジュール２１２を通じて、受信した要求の処理に使用するプラグインサービス２１４の情報を取得する。その後、タスクサービス２１１Ａは、リクエスト制御部２１７に対し、要求の処理に使用するプラグインサービス２１４の動作の状態を問い合わせる。
図９の例では、新たな要求は、動作の停止を伴う障害が検知されているプラグインサービス２１４の呼び出しを要する場合を想定する。このため、タスクサービス２１１Ａは、応答として、非動作中（inactive）を受け取っている。
以下では、プラグインサービス２１４の障害が検知された後に、入力装置１００から新規の要求がタスクサービス２１１Ａに入力される場合の動作を説明する。
・ステップ６
入力装置１００から新規の要求を受信したタスクサービス２１１Ａは、タスク定義モジュール２１２を通じて、受信した要求の処理に使用するプラグインサービス２１４の情報を取得する。その後、タスクサービス２１１Ａは、リクエスト制御部２１７に対し、要求の処理に使用するプラグインサービス２１４の動作の状態を問い合わせる。
図９の例では、新たな要求は、動作の停止を伴う障害が検知されているプラグインサービス２１４の呼び出しを要する場合を想定する。このため、タスクサービス２１１Ａは、応答として、非動作中（inactive）を受け取っている。
・ステップ７
図９の場合、タスクサービス２１１Ａは、新規の要求の状態を不可視（invisible）にしてキュー２１３に記憶する。
図１３は、障害の検知後に入力された新規の要求を含む状態表５００の例を説明する図である。
図１３には、図１２との対応部分に対応する符号を付して示している。
図１３の場合、新規の要求にはリクエストＩＤ５０１として「ＲＥＱ００００５」が付されており、その状態であるリクエスト状態５０２は不可視（invisible）に設定されている。
なお、要求の処理に用いるプラグインサービス２１４を特定するプラグインサービスＩＤは「ＰＬＵＧ００１」であるので、プラグインサービス状態５０４は非動作中（inactive）である。
図９の場合、タスクサービス２１１Ａは、新規の要求の状態を不可視（invisible）にしてキュー２１３に記憶する。
図１３は、障害の検知後に入力された新規の要求を含む状態表５００の例を説明する図である。
図１３には、図１２との対応部分に対応する符号を付して示している。
図１３の場合、新規の要求にはリクエストＩＤ５０１として「ＲＥＱ００００５」が付されており、その状態であるリクエスト状態５０２は不可視（invisible）に設定されている。
なお、要求の処理に用いるプラグインサービス２１４を特定するプラグインサービスＩＤは「ＰＬＵＧ００１」であるので、プラグインサービス状態５０４は非動作中（inactive）である。
図１３の例では、新規の要求がキュー２１３（図９参照）に記憶される時点で、動作中（active）のプラグインサービス２１４（図９参照）を使用する要求（ＲＥＱ００００３）がキュー２１３に保持されている場合を表しているが、処理の完了している場合には、要求（ＲＥＱ００００３）がキュー２１３から削除される。
図１３に示すように、キュー２１３内には、障害が復旧するまで、動作の停止を伴う障害が発生しているプラグインサービス２１４を使用する要求が増え続けることになるが、リクエスト状態５０２は不可視の状態（invisible）に設定されているので、オートスケール管理部２１５が、キュー２１３に滞留している要求の処理を促進するために、計算資源およびプラグインサービス２１４を追加することはない。
図１３に示すように、キュー２１３内には、障害が復旧するまで、動作の停止を伴う障害が発生しているプラグインサービス２１４を使用する要求が増え続けることになるが、リクエスト状態５０２は不可視の状態（invisible）に設定されているので、オートスケール管理部２１５が、キュー２１３に滞留している要求の処理を促進するために、計算資源およびプラグインサービス２１４を追加することはない。
＜プラグインサービスで障害が発生した場合の動作２＞
ここでは、プラグインサービス２１４に障害が発生した場合の他の動作例について説明する。
図１４は、プラグインサービス２１４に障害が発生した場合の他のシーケンス例を説明する図である。
図１４に示すシーケンスは、入力装置１００、タスクサービス２１１Ａ、キュー２１３、プラグインサービス２１４、障害検知部２１６、リクエスト制御部２１７の間におけるやり取りを示している。
なお、図中の記号Ｓはステップを表している。
ここでは、プラグインサービス２１４に障害が発生した場合の他の動作例について説明する。
図１４は、プラグインサービス２１４に障害が発生した場合の他のシーケンス例を説明する図である。
図１４に示すシーケンスは、入力装置１００、タスクサービス２１１Ａ、キュー２１３、プラグインサービス２１４、障害検知部２１６、リクエスト制御部２１７の間におけるやり取りを示している。
なお、図中の記号Ｓはステップを表している。
・ステップ１～ステップ４
図１４におけるステップ１からステップ４までの動作の内容と手順は、図９と同じである。すなわち、動作の停止を伴う障害の通知を受け付けたリクエスト制御部２１７は、キュー２１３に記憶されている要求のうち、障害が検知されたプラグインサービス２１４を使用する要求の状態をいずれも不可視（invisible）に変更する。
図１４におけるステップ１からステップ４までの動作の内容と手順は、図９と同じである。すなわち、動作の停止を伴う障害の通知を受け付けたリクエスト制御部２１７は、キュー２１３に記憶されている要求のうち、障害が検知されたプラグインサービス２１４を使用する要求の状態をいずれも不可視（invisible）に変更する。
・ステップ５～ステップ７
動作の停止を伴う障害が検知された後に、入力装置１００から新規の要求がタスクサービス２１１Ａに入力された場合、タスクサービス２１１Ａは、リクエスト制御部２１７に対して要求を処理するプラグインサービス２１４の状態を問い合わせる。
今回の場合、タスクサービス２１１Ａは、要求を処理するプラグインサービス２１４の状態が非動作中（inactive）であるとの応答を得る。ここまでは、図９で説明した動作の内容と同じである。
違いは、その後の動作である。タスクサービス２１１Ａは、受信した新規の要求をキュー２１３に記憶せずに廃棄し、要求を送信した入力装置１００にエラーを通知する。
動作の停止を伴う障害が検知された後に、入力装置１００から新規の要求がタスクサービス２１１Ａに入力された場合、タスクサービス２１１Ａは、リクエスト制御部２１７に対して要求を処理するプラグインサービス２１４の状態を問い合わせる。
今回の場合、タスクサービス２１１Ａは、要求を処理するプラグインサービス２１４の状態が非動作中（inactive）であるとの応答を得る。ここまでは、図９で説明した動作の内容と同じである。
違いは、その後の動作である。タスクサービス２１１Ａは、受信した新規の要求をキュー２１３に記憶せずに廃棄し、要求を送信した入力装置１００にエラーを通知する。
図１５は、障害の検知後に入力された新規の要求を含む状態表５００の例を説明する図である。
図１５には、図１３との対応部分に対応する符号を付して示している。
図１５の場合、新規の要求に対応するリクエストＩＤ５０１は「ＲＥＱ００００５」である。この例は、新規の要求について呼び出すプラグインサービス２１４に障害が発生している場合であるので、新規の要求は、キュー２１３に追加されずに廃棄されている。このため、キュー２１３の状態表５００には、図１３の場合のように、５個目の要求は記憶されていない。
勿論、新規の要求について呼び出すプラグインサービス２１４に障害が発生していない場合には、新規の要求は廃棄されずにキュー２１３に記憶される。例えば要求について読み出されたプラグインサービスＩＤ５０３が「ＰＬＵＧ００２」の場合である。
図１５には、図１３との対応部分に対応する符号を付して示している。
図１５の場合、新規の要求に対応するリクエストＩＤ５０１は「ＲＥＱ００００５」である。この例は、新規の要求について呼び出すプラグインサービス２１４に障害が発生している場合であるので、新規の要求は、キュー２１３に追加されずに廃棄されている。このため、キュー２１３の状態表５００には、図１３の場合のように、５個目の要求は記憶されていない。
勿論、新規の要求について呼び出すプラグインサービス２１４に障害が発生していない場合には、新規の要求は廃棄されずにキュー２１３に記憶される。例えば要求について読み出されたプラグインサービスＩＤ５０３が「ＰＬＵＧ００２」の場合である。
この動作例のように、障害が発生しているプラグインサービス２１４を使用する新規の要求をキュー２１３に記憶せずに廃棄する場合には、オートスケール管理部２１５が、キュー２１３に滞留している要求の処理を促進するために、計算資源およびプラグインサービス２１４を追加することはない。
また、入力装置１００に対しても、エラーを通知することにより、入力装置１００による同じ要求の出力が抑制される。
また、入力装置１００に対しても、エラーを通知することにより、入力装置１００による同じ要求の出力が抑制される。
＜障害が検知された後の動作１＞
ここでは、障害が検知された後の動作例について説明する。
前述したように、障害が検知された時点でキュー２１３に記憶されている障害が発生しているプラグインサービス２１４を使用する要求の状態はいずれも不可視の状態（invisible）に変更され、障害の検知後に入力された新規の要求は、不可視の状態（invisible）でキュー２１３に記憶されるか、キュー２１３に記憶されずに廃棄されている。
以下の説明は、その後の動作である。
ここでは、障害が検知された後の動作例について説明する。
前述したように、障害が検知された時点でキュー２１３に記憶されている障害が発生しているプラグインサービス２１４を使用する要求の状態はいずれも不可視の状態（invisible）に変更され、障害の検知後に入力された新規の要求は、不可視の状態（invisible）でキュー２１３に記憶されるか、キュー２１３に記憶されずに廃棄されている。
以下の説明は、その後の動作である。
図１６は、プラグインサービス２１４の障害が検知された後に実行されるシーケンス例を説明する図である。
図１６に示すシーケンスは、タスクサービス２１１Ａ、キュー２１３、プラグインサービス２１４、障害検知部２１６、リクエスト制御部２１７の間におけるやり取りを示している。
・ステップ１
障害が検知されてから予め定めた時間が経過すると、リクエスト制御部２１７は、状態表５００における１個目の要求を可視の状態（visible）に変更する。
図１７は、図１６におけるステップ１の処理前における状態表５００を説明する図である。
図１８は、図１６におけるステップ１の処理後における状態表５００を説明する図である。
図１７に示す状態表５００は、図１５に示す状態表５００に対応している。１個目の要求「ＲＥＱ００００１」の状態は不可視の状態（invisible）であり、その処理に使用されるプラグインサービス２１４の状態は非動作中（inactive）である。
この動作例の場合、リクエスト制御部２１７は、１個目の要求「ＲＥＱ００００１」の状態を可視の状態（visible）に変更する。図１８では、プラグインサービス２１４の状態も動作中（active）に変更されている。
図１６の説明に戻る。
図１６に示すシーケンスは、タスクサービス２１１Ａ、キュー２１３、プラグインサービス２１４、障害検知部２１６、リクエスト制御部２１７の間におけるやり取りを示している。
・ステップ１
障害が検知されてから予め定めた時間が経過すると、リクエスト制御部２１７は、状態表５００における１個目の要求を可視の状態（visible）に変更する。
図１７は、図１６におけるステップ１の処理前における状態表５００を説明する図である。
図１８は、図１６におけるステップ１の処理後における状態表５００を説明する図である。
図１７に示す状態表５００は、図１５に示す状態表５００に対応している。１個目の要求「ＲＥＱ００００１」の状態は不可視の状態（invisible）であり、その処理に使用されるプラグインサービス２１４の状態は非動作中（inactive）である。
この動作例の場合、リクエスト制御部２１７は、１個目の要求「ＲＥＱ００００１」の状態を可視の状態（visible）に変更する。図１８では、プラグインサービス２１４の状態も動作中（active）に変更されている。
図１６の説明に戻る。
・ステップ２
キュー２１３は、状態表５００における１個目の要求の状態が可視の状態（visible）に変更されたので、１個目の要求について記載されているプラグインサービス２１４を読み出す。ここでは、プラグインサービスＩＤが「ＰＬＵＧ００１」のプラグインサービス２１４を読み出す。
・ステップ３
読み出されたプラグインサービス２１４が要求を処理する。
キュー２１３は、状態表５００における１個目の要求の状態が可視の状態（visible）に変更されたので、１個目の要求について記載されているプラグインサービス２１４を読み出す。ここでは、プラグインサービスＩＤが「ＰＬＵＧ００１」のプラグインサービス２１４を読み出す。
・ステップ３
読み出されたプラグインサービス２１４が要求を処理する。
・ステップ４
ここでは、障害検知部２１６が、読み出されたプラグインサービス２１４について再び障害を検知する。
・ステップ５
障害検知部２１６は、リクエスト制御部２１７に対し、プラグインサービス２１４の障害を通知する。
・ステップ６
リクエスト制御部２１７は、キュー２１３に記憶されている１個目の要求の状態を不可視の状態（invisible）に変更する。
ここでは、障害検知部２１６が、読み出されたプラグインサービス２１４について再び障害を検知する。
・ステップ５
障害検知部２１６は、リクエスト制御部２１７に対し、プラグインサービス２１４の障害を通知する。
・ステップ６
リクエスト制御部２１７は、キュー２１３に記憶されている１個目の要求の状態を不可視の状態（invisible）に変更する。
図１９は、図１６におけるステップ６の時点におけるキュー２１３（図３参照）に記憶されている要求の状態表５００の例である。図１９には、図１８との対応部分に対応する符号を付して示している。
図１９の場合、呼び出されたプラグインサービス２１４は、障害から復旧していなかっ状態であるので、１個目の要求に対応するリクエスト状態５０２は、不可視の状態（invisible）に戻っている。また、対応するプラグインサービス２１４の状態も非動作中（inactive）に戻っている。
なお、このシーケンス例では、ステップ１の時点で１個目の要求の状態だけを不可視の状態(invisible)から可視の状態（visible）に変更しているが、１個目の要求と同じプラグインサービスＩＤ５０３を呼び出す全ての要求の状態についても不可視の状態(invisible)から可視の状態（visible）に変更してよい。
この場合でも、ステップ４で障害が検知されて要求の状態を不可視の状態（invisible）に戻すとき、他の要求の状態も不可視の状態（invisible）に戻せば良い。
図１９の場合、呼び出されたプラグインサービス２１４は、障害から復旧していなかっ状態であるので、１個目の要求に対応するリクエスト状態５０２は、不可視の状態（invisible）に戻っている。また、対応するプラグインサービス２１４の状態も非動作中（inactive）に戻っている。
なお、このシーケンス例では、ステップ１の時点で１個目の要求の状態だけを不可視の状態(invisible)から可視の状態（visible）に変更しているが、１個目の要求と同じプラグインサービスＩＤ５０３を呼び出す全ての要求の状態についても不可視の状態(invisible)から可視の状態（visible）に変更してよい。
この場合でも、ステップ４で障害が検知されて要求の状態を不可視の状態（invisible）に戻すとき、他の要求の状態も不可視の状態（invisible）に戻せば良い。
＜障害が検知された後の動作２＞
ここでは、復旧が通知される前に呼び出されたプラグインサービス２１４により要求の処理が完了する場合について説明する。
図２０は、プラグインサービス２１４の障害が検知された後に実行されるシーケンス例を説明する図である。
図２０に示すシーケンスは、入力装置１００、タスクサービス２１１Ａ、キュー２１３、プラグインサービス２１４、障害検知部２１６、リクエスト制御部２１７の間におけるやり取りを示している。
ここでは、復旧が通知される前に呼び出されたプラグインサービス２１４により要求の処理が完了する場合について説明する。
図２０は、プラグインサービス２１４の障害が検知された後に実行されるシーケンス例を説明する図である。
図２０に示すシーケンスは、入力装置１００、タスクサービス２１１Ａ、キュー２１３、プラグインサービス２１４、障害検知部２１６、リクエスト制御部２１７の間におけるやり取りを示している。
・ステップ１～ステップ３
図２０におけるステップ１からステップ３までの動作の内容と手順は、図１６と同じである。すなわち、障害が検知されてから予め定めた時間が経過すると、不可視の状態（invisible）として管理されている１個目の要求の状態が可視の状態（visible）に変更され、その後、対応するプラグインサービス２１４が読み出され、要求の処理が開始される。
図２０におけるステップ１からステップ３までの動作の内容と手順は、図１６と同じである。すなわち、障害が検知されてから予め定めた時間が経過すると、不可視の状態（invisible）として管理されている１個目の要求の状態が可視の状態（visible）に変更され、その後、対応するプラグインサービス２１４が読み出され、要求の処理が開始される。
・ステップ４
この例は、読み出されたプラグインサービス２１４が動作して要求を処理した場合であるので、プラグインサービス２１４は、リクエスト制御部２１７に対して要求の処理の完了を通知する。
図２１は、要求の処理の完了が通知された後における状態表５００を説明する図である。
図２１の場合、処理が完了したリクエストＩＤ「ＲＥＱ００００１」の要求が削除され、図１９に示す状態表５００では２個目に位置していたリクエストＩＤ「ＲＥＱ００００２」の要求が状態表５００の１個目に移動している。他の２つの要求についても状態表５００内における順位が１つずつ繰り上がっている。
この例は、読み出されたプラグインサービス２１４が動作して要求を処理した場合であるので、プラグインサービス２１４は、リクエスト制御部２１７に対して要求の処理の完了を通知する。
図２１は、要求の処理の完了が通知された後における状態表５００を説明する図である。
図２１の場合、処理が完了したリクエストＩＤ「ＲＥＱ００００１」の要求が削除され、図１９に示す状態表５００では２個目に位置していたリクエストＩＤ「ＲＥＱ００００２」の要求が状態表５００の１個目に移動している。他の２つの要求についても状態表５００内における順位が１つずつ繰り上がっている。
・ステップ５
次に、リクエスト制御部２１７は、２個目の要求の状態を可視の状態（visible）に変更するようにキュー２１３に指示する。
ここでの２個目とは、ステップ１の時点から見て２個目の意味である。
従って、リクエストＩＤ「ＲＥＱ００００１」の要求が状態表５００から削除された後は、状態表５００の１個目に対応する。
図２２は、図２０におけるステップ５の処理後の状態表５００を説明する図である。
図２２に示す状態表５００では、プラグインＩＤ「ＲＥＱ００００２」で管理される要求の状態が可視の状態（visible）に変更されている。なお、図２２の例では、プラグインＩＤ「ＲＥＱ００００２」で管理される要求に対応するプラグインサービス２１４の状態も非動作中（inactive）から動作中（active）に変更されている。
一方で、プラグインＩＤ「ＲＥＱ００００４」で管理される要求の状態は不可視の状態（invisible）のままである。
このシーケンス例は、障害検知部２１６による障害からの復旧が検知される前の動作であるので、１つずつ状態が変更される。
次に、リクエスト制御部２１７は、２個目の要求の状態を可視の状態（visible）に変更するようにキュー２１３に指示する。
ここでの２個目とは、ステップ１の時点から見て２個目の意味である。
従って、リクエストＩＤ「ＲＥＱ００００１」の要求が状態表５００から削除された後は、状態表５００の１個目に対応する。
図２２は、図２０におけるステップ５の処理後の状態表５００を説明する図である。
図２２に示す状態表５００では、プラグインＩＤ「ＲＥＱ００００２」で管理される要求の状態が可視の状態（visible）に変更されている。なお、図２２の例では、プラグインＩＤ「ＲＥＱ００００２」で管理される要求に対応するプラグインサービス２１４の状態も非動作中（inactive）から動作中（active）に変更されている。
一方で、プラグインＩＤ「ＲＥＱ００００４」で管理される要求の状態は不可視の状態（invisible）のままである。
このシーケンス例は、障害検知部２１６による障害からの復旧が検知される前の動作であるので、１つずつ状態が変更される。
・ステップ６
タスクサービス２１１Ａは、入力装置１００から新規の要求を受け付ける。
・ステップ７
タスクサービス２１１Ａは、受け付けた要求が使用するプラグインサービス２４の状態をリクエスト制御部２１７に問い合わせる。ここでは、非動作中（inactive）の応答が得られている。
タスクサービス２１１Ａは、入力装置１００から新規の要求を受け付ける。
・ステップ７
タスクサービス２１１Ａは、受け付けた要求が使用するプラグインサービス２４の状態をリクエスト制御部２１７に問い合わせる。ここでは、非動作中（inactive）の応答が得られている。
・ステップ８
タスクサービス２１１Ａは、新規の要求の状態を不可視（invisible）でキュー２１３に記憶する。
図２３は、図２０におけるステップ８の処理後の状態表５００を説明する図である。
図２３の場合、新たな要求は、「ＲＥＱ００００５」で管理される。「ＲＥＱ００００５」の処理に使用されるプラグインサービス２１４は「ＰＬＵＧ００１」である。リクエスト制御部２１７は、「ＰＬＵＧ００１」について障害からの復帰の通知を受けていない。このため、「ＲＥＱ００００５」で管理される要求の状態には不可視の状態（invisible）が記憶され、プラグインサービス２１４には非動作中（inactive）が記憶される。
このシーケンス例では、障害検知部２１６による復旧の検知前でも、１個ずつ確認しながら要求の処理が試みられる。
タスクサービス２１１Ａは、新規の要求の状態を不可視（invisible）でキュー２１３に記憶する。
図２３は、図２０におけるステップ８の処理後の状態表５００を説明する図である。
図２３の場合、新たな要求は、「ＲＥＱ００００５」で管理される。「ＲＥＱ００００５」の処理に使用されるプラグインサービス２１４は「ＰＬＵＧ００１」である。リクエスト制御部２１７は、「ＰＬＵＧ００１」について障害からの復帰の通知を受けていない。このため、「ＲＥＱ００００５」で管理される要求の状態には不可視の状態（invisible）が記憶され、プラグインサービス２１４には非動作中（inactive）が記憶される。
このシーケンス例では、障害検知部２１６による復旧の検知前でも、１個ずつ確認しながら要求の処理が試みられる。
＜障害からの復旧が検知された場合の動作＞
図２４は、障害からの復旧が検知された場合のシーケンス例を説明する図である。
図２４に示すシーケンスは、入力装置１００、タスクサービス２１１Ａ、キュー２１３、プラグインサービス２１４、障害検知部２１６、リクエスト制御部２１７の間におけるやり取りを示している。
・ステップ１
障害検知部２１６は、１個目の要求の正常終了を検知する。ここでの正常終了は、障害が検知されているプラグインサービス２１４における処理の正常終了に対応する。例えば障害検知部２１６は、図２０のステップ３で実行された処理の正常終了を検知する。
・ステップ２
障害検知部２１６は、リクエスト制御部２１７に対し、正常終了が検知されたプラグインサービスの障害からの復旧を通知する。
図２５は、復旧通知のデータ構造を説明する図である。復旧通知には、障害から復旧したプラグインサービス２１４を特定するプラグインサービスＩＤ７０１と、プラグインサービス状態７０２が含まれる。
図２５の場合、プラグインサービスＩＤ７０１は「ＰＬＵＧ００１」であり、プラグインサービス状態７０２は動作中（active）である。
図２４は、障害からの復旧が検知された場合のシーケンス例を説明する図である。
図２４に示すシーケンスは、入力装置１００、タスクサービス２１１Ａ、キュー２１３、プラグインサービス２１４、障害検知部２１６、リクエスト制御部２１７の間におけるやり取りを示している。
・ステップ１
障害検知部２１６は、１個目の要求の正常終了を検知する。ここでの正常終了は、障害が検知されているプラグインサービス２１４における処理の正常終了に対応する。例えば障害検知部２１６は、図２０のステップ３で実行された処理の正常終了を検知する。
・ステップ２
障害検知部２１６は、リクエスト制御部２１７に対し、正常終了が検知されたプラグインサービスの障害からの復旧を通知する。
図２５は、復旧通知のデータ構造を説明する図である。復旧通知には、障害から復旧したプラグインサービス２１４を特定するプラグインサービスＩＤ７０１と、プラグインサービス状態７０２が含まれる。
図２５の場合、プラグインサービスＩＤ７０１は「ＰＬＵＧ００１」であり、プラグインサービス状態７０２は動作中（active）である。
・ステップ３
障害からの復旧の通知を受けたリクエスト制御部２１７は、２個目以降の要求を可視の状態（visible）に変更する。
図２６は、図２４におけるステップ３の処理後における状態表５００の例を説明する図である。
図２６には、図２１との対応部分に対応する符号を付して示している。
図２６の場合、図２１では不可視の状態（invisible）であった「ＲＥＱ００００２」及び「ＲＥＱ００００４」で管理される要求の状態がいずれも可視の状態（visible）に変更されている。
なお、図２６の例では、これらの要求に対応するプラグインサービス２１４の状態も非動作中（inactive）から動作中（active）に変更されている。
障害からの復旧の通知を受けたリクエスト制御部２１７は、２個目以降の要求を可視の状態（visible）に変更する。
図２６は、図２４におけるステップ３の処理後における状態表５００の例を説明する図である。
図２６には、図２１との対応部分に対応する符号を付して示している。
図２６の場合、図２１では不可視の状態（invisible）であった「ＲＥＱ００００２」及び「ＲＥＱ００００４」で管理される要求の状態がいずれも可視の状態（visible）に変更されている。
なお、図２６の例では、これらの要求に対応するプラグインサービス２１４の状態も非動作中（inactive）から動作中（active）に変更されている。
・ステップ４
キュー２１３は、要求を処理するプラグインサービス２１４を呼び出す。
・ステップ５
呼び出されたプラグインサービス２１４は、要求を処理する。
・ステップ６
タスクサービス２１１Ａは、入力装置１００から新規の要求を受け付ける。
・ステップ７
タスクサービス２１１Ａは、受け付けた要求が使用するプラグインサービス２４の状態をリクエスト制御部２１７に問い合わせる。ここでは、動作中（active）の応答が得られる。
キュー２１３は、要求を処理するプラグインサービス２１４を呼び出す。
・ステップ５
呼び出されたプラグインサービス２１４は、要求を処理する。
・ステップ６
タスクサービス２１１Ａは、入力装置１００から新規の要求を受け付ける。
・ステップ７
タスクサービス２１１Ａは、受け付けた要求が使用するプラグインサービス２４の状態をリクエスト制御部２１７に問い合わせる。ここでは、動作中（active）の応答が得られる。
・ステップ８
タスクサービス２１１Ａが、新規の要求の状態を可視（visible）でキュー２１３に記憶する。
図２７は、図２４におけるステップ８の処理後における状態表５００の例を説明する図である。
図２７には、図２６との対応部分に対応する符号を付して示している。
図２７の場合、新たな要求は、「ＲＥＱ００００５」で管理される。「ＲＥＱ００００５」の処理に使用されるプラグインサービス２１４は「ＰＬＵＧ００１」である。動作中（active）である。
従って、「ＲＥＱ００００５」で管理される要求の状態には可視の状態（visible）が記憶され、プラグインサービス２１４には動作中（active）が記憶される。
タスクサービス２１１Ａが、新規の要求の状態を可視（visible）でキュー２１３に記憶する。
図２７は、図２４におけるステップ８の処理後における状態表５００の例を説明する図である。
図２７には、図２６との対応部分に対応する符号を付して示している。
図２７の場合、新たな要求は、「ＲＥＱ００００５」で管理される。「ＲＥＱ００００５」の処理に使用されるプラグインサービス２１４は「ＰＬＵＧ００１」である。動作中（active）である。
従って、「ＲＥＱ００００５」で管理される要求の状態には可視の状態（visible）が記憶され、プラグインサービス２１４には動作中（active）が記憶される。
＜他の実施形態＞
以上、本発明の実施の形態について説明したが、本発明の技術的範囲は上述の実施の形態に記載の範囲に限定されない。上述の実施の形態に、種々の変更又は改良を加えたものも、本発明の技術的範囲に含まれることは、特許請求の範囲の記載から明らかである。
以上、本発明の実施の形態について説明したが、本発明の技術的範囲は上述の実施の形態に記載の範囲に限定されない。上述の実施の形態に、種々の変更又は改良を加えたものも、本発明の技術的範囲に含まれることは、特許請求の範囲の記載から明らかである。
１…クラウド連携システム、１００…入力装置、２００…中継装置、２１１…コアサービス、２１１Ａ…タスクサービス、２１２…タスク定義モジュール、２１３…キュー、２１４、２１４Ａ、２１４Ｂ…プラグインサービス、２１５…オートスケール管理部、２１６…障害検知部、２１７…リクエスト制御部
３００…クラウドネットワーク、４００Ａ…ストレージ型クラウドサーバ、４００Ｂ…業務支援型クラウドサーバ
３００…クラウドネットワーク、４００Ａ…ストレージ型クラウドサーバ、４００Ｂ…業務支援型クラウドサーバ
Claims (7)
- 記憶部から要求を読み出して処理する処理部に関する障害の発生を検知する検知手段と、
前記記憶部に記憶された要求の状態を監視し、前記記憶部に記憶された要求の状態に応じて、計算資源の増減を指示する監視手段と、
前記検知手段が前記処理部の動作の停止を伴う障害を検知した場合、前記記憶部の状態を、前記監視手段により計算資源の追加が不要であると判断される状態に制御する制御手段と、
を有する中継システム。 - 前記制御手段は、検知された前記障害に関連する前記処理部に対応付けられた処理中の要求に関する状態を、当該処理部が前記記憶部から当該処理中の要求を取り出せない状態に制御する、ことを特徴とする請求項１に記載の中継システム。
- 前記制御手段は、前記障害が検知された前記処理部による実行に備えて前記記憶部に記憶された待機中の要求の状態を、当該記憶部から要求を取り出せない状態に制御する、請求項１又は２に記載の中継システム。
- 前記制御手段は、前記障害が検知された場合に、前記記憶部に記憶された要求の数が、予め定めた値を超えていないようにみせる制御を実行する、請求項１に記載の中継システム。
- 要求を前記記憶部に記憶する前に、要求を処理する前記処理部について前記障害が検知された場合に、前記制御手段は、当該記憶部に記憶する当該障害が検知された後に発生した要求の状態を、当該記憶部から前記処理部に取り出せない状態に設定する、請求項１～３のいずれか１項に記載の中継システム。
- 要求を処理する前記処理部について前記障害が検知された場合に、前記制御手段は、当該障害が検知された後に発生した要求を前記記憶部に書き込まずに廃棄する、請求項１～３のいずれか１項に記載の中継システム。
- 前記制御手段は、前記障害が発生していない状態になったことが前記検知手段によって検知された場合、前記記憶部に保持されている要求の状態を、当該記憶部から前記処理部が要求を取り出せない状態から当該記憶部から当該処理部が要求を取り出せる状態に変更する、請求項２に記載の中継システム。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2018176618A JP7135648B2 (ja) | 2018-09-20 | 2018-09-20 | 中継システム |
| US16/568,165 US11416355B2 (en) | 2018-09-20 | 2019-09-11 | Relay system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2018176618A JP7135648B2 (ja) | 2018-09-20 | 2018-09-20 | 中継システム |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2020048126A JP2020048126A (ja) | 2020-03-26 |
| JP2020048126A5 JP2020048126A5 (ja) | 2021-10-21 |
| JP7135648B2 true JP7135648B2 (ja) | 2022-09-13 |
Family
ID=69883396
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2018176618A Active JP7135648B2 (ja) | 2018-09-20 | 2018-09-20 | 中継システム |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US11416355B2 (ja) |
| JP (1) | JP7135648B2 (ja) |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2013251006A (ja) | 2013-09-04 | 2013-12-12 | Canon Inc | 情報処理システム、システム、情報処理システム制御方法、およびそのプログラム |
Family Cites Families (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7617292B2 (en) * | 2001-06-05 | 2009-11-10 | Silicon Graphics International | Multi-class heterogeneous clients in a clustered filesystem |
| US7324438B1 (en) * | 2003-02-13 | 2008-01-29 | Cisco Technology, Inc. | Technique for nondisruptively recovering from a processor failure in a multi-processor flow device |
| US9286075B2 (en) * | 2009-09-30 | 2016-03-15 | Oracle America, Inc. | Optimal deallocation of instructions from a unified pick queue |
| US9372735B2 (en) * | 2012-01-09 | 2016-06-21 | Microsoft Technology Licensing, Llc | Auto-scaling of pool of virtual machines based on auto-scaling rules of user associated with the pool |
| JP2013186745A (ja) * | 2012-03-08 | 2013-09-19 | Fuji Xerox Co Ltd | 処理システム及びプログラム |
| JP2014149690A (ja) | 2013-02-01 | 2014-08-21 | Canon Inc | 情報処理システム、監視装置、情報処理システムの制御方法およびコンピュータプログラム |
| US9471371B2 (en) * | 2014-02-27 | 2016-10-18 | International Business Machines Corporation | Dynamic prediction of concurrent hardware transactions resource requirements and allocation |
| US11010193B2 (en) * | 2017-04-17 | 2021-05-18 | Microsoft Technology Licensing, Llc | Efficient queue management for cluster scheduling |
| US10452436B2 (en) * | 2018-01-03 | 2019-10-22 | Cisco Technology, Inc. | System and method for scheduling workload based on a credit-based mechanism |
-
2018
- 2018-09-20 JP JP2018176618A patent/JP7135648B2/ja active Active
-
2019
- 2019-09-11 US US16/568,165 patent/US11416355B2/en active Active
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2013251006A (ja) | 2013-09-04 | 2013-12-12 | Canon Inc | 情報処理システム、システム、情報処理システム制御方法、およびそのプログラム |
Also Published As
| Publication number | Publication date |
|---|---|
| US20200097375A1 (en) | 2020-03-26 |
| US11416355B2 (en) | 2022-08-16 |
| JP2020048126A (ja) | 2020-03-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8826291B2 (en) | Processing system | |
| JP4458866B2 (ja) | 画像形成装置および自動リブート方法 | |
| JPH04505819A (ja) | 論理的事象の通知方法及び装置 | |
| JP4843372B2 (ja) | 画像処理装置 | |
| US7110131B2 (en) | Image forming system and image forming apparatus for transferring job data when an impaired image forming state is detected | |
| JP2008040841A (ja) | 出力管理サーバおよびデータ出力システム | |
| JP7135648B2 (ja) | 中継システム | |
| US20180173473A1 (en) | Method for operating a print server for digital high-capacity printing systems | |
| US10904399B2 (en) | Information processing apparatus and non-transitory computer readable medium | |
| KR20130071137A (ko) | 화상형성장치 및 화상형성장치에서 에러 알림 및 복구 기능을 수행하는 방법 | |
| CN115495030A (zh) | 作业异常处理方法、装置、图像形成设备及存储介质 | |
| US11233906B2 (en) | Electronic apparatus and non-transitory computer readable recording medium that records control program | |
| JP2016042338A (ja) | 情報処理システム、情報処理装置、情報処理装置の制御方法、及びプログラム | |
| JP3743183B2 (ja) | プリント・サーバ、ネットワーク・プリント・システム、及びネットワーク・プリント・システムにおけるプリント制御方法 | |
| JP2007122015A (ja) | 情報処理装置及び画像形成装置 | |
| JP2020014105A (ja) | 情報処理装置及びプログラム | |
| JP2005229210A (ja) | 画像形成装置および自動リブート方法 | |
| JP3270400B2 (ja) | 印刷処理クラスタシステム | |
| JP4158649B2 (ja) | 連携処理装置及びプログラム | |
| EP4303712A1 (en) | Printing apparatus, control method, and program | |
| US10740054B2 (en) | Image forming system, management server, and a non-transitory computer readable recording medium storing a server program | |
| JP2006268193A (ja) | 管理システム、管理センタ、管理方法 | |
| JP4429138B2 (ja) | 暗示アドレス発見を使用して画像形成ジョブを監視するシステム及び方法 | |
| US20050094185A1 (en) | Job managing apparatus, job managing method, and job managing program | |
| WO2008015730A1 (fr) | Procédé et programme pour éviter un échec d'exécution d'une tâche dans un système de calcul de grille et système de calcul de grille |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20210913 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20210913 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20220519 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20220531 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20220720 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20220802 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20220815 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 7135648 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |