特開 2017-228007 サービス継続装置、サービス継続方法およびプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】特開2017-228007(P2017-228007A)

(43)【公開日】2017年12月28日

(54)【発明の名称】サービス継続装置、サービス継続方法およびプログラム

(51)【国際特許分類】

   G06F 11/07 20060101AFI20171201BHJP

   G06F 11/20 20060101ALI20171201BHJP

【ＦＩ】

   G06F11/07 193

   G06F11/07 140A

   G06F11/20 628

【審査請求】未請求

【請求項の数】5

【出願形態】ＯＬ

【全頁数】19

(21)【出願番号】特願2016-122265(P2016-122265)

(22)【出願日】2016年6月21日

(71)【出願人】

【識別番号】000004226

【氏名又は名称】日本電信電話株式会社

(74)【代理人】

【識別番号】110001807

【氏名又は名称】特許業務法人磯野国際特許商標事務所

(72)【発明者】

【氏名】北野 雄大

【テーマコード（参考）】

5B034

5B042

【Ｆターム（参考）】

5B034BB11

5B034BB15

5B034CC01

5B034DD02

5B034DD05

5B042GA05

5B042GA12

5B042JJ15

5B042KK04

5B042KK09

5B042KK20

5B042MA08

5B042MC09

5B042MC25

(57)【要約】

【課題】分割された複数のモジュールを組み合わせてサービスを提供するシステムにおいて、あるモジュールに障害が発生した場合においても、サービスを継続する。
【解決手段】サービス継続装置１０は、呼出元モジュール、呼出先モジュール、呼出内容、応答内容および応答した回数を示すスコア、が記録される履歴記録ＤＢ１３０を記憶する記憶部１３と、呼出先モジュールから応答を受け取り、その呼出における履歴情報を用いて、記録判断ロジックに基づき、履歴情報を記録するか否かを判定し、記録すると判定した履歴情報を履歴記録ＤＢに記録する履歴記録部１１２と、障害を検出したモジュールが呼出先モジュールとなる呼出を受け取った際に、履歴記録ＤＢを参照し、一致する履歴情報が記録されている場合であり、スコアが所定の閾値以上であるときに、履歴記録ＤＢの応答内容を呼出元モジュールに返却する代理応答部１１５とを備える。
【選択図】図２

【特許請求の範囲】

【請求項1】

分割された複数のモジュールを組み合わせてサービスを提供するシステムにおいて、呼出元となる前記モジュールを示す呼出元モジュールと、呼出先となる前記モジュールを示す呼出先モジュールとの間の呼出および応答の処理を仲介するサービス継続装置であって、
前記呼出元モジュール、前記呼出先モジュール、前記呼出元モジュールからの呼出に付された呼出内容、前記呼出先モジュールからの応答に付された応答内容、および、当該呼出に対し当該応答内容により応答した回数を示すスコア、が記録される履歴記録ＤＢ（DataBase）、並びに、前記応答を代理で実行するか否かを前記スコアを用いて判定するためのスコア閾値、を記憶する記憶部と、
前記呼出元モジュールからの前記呼出内容が付された呼出を受け取り、前記呼出先モジュールに通知する呼出内容通知部と、
前記呼出先モジュールから前記呼出に対する応答を受け取り、前記呼出元モジュール、前記呼出先モジュール、前記呼出内容、および、前記応答内容を示す履歴情報を用いて、記録判断ロジックに基づき、前記履歴情報を記録するか否かを判定し、記録すると判定した履歴情報を前記履歴記録ＤＢに記録する履歴記録部と、
複数の前記モジュールの障害を検出することにより前記モジュールの死活監視を行う死活監視部と、
前記障害を検出したモジュールが前記呼出先モジュールとなる呼出を受け取った際に、当該呼出についての、前記呼出元モジュール、前記呼出先モジュールおよび前記呼出内容を用いて前記履歴記録ＤＢを参照し、一致する履歴情報があるか否かを判定し、一致する履歴情報が記録されている場合であり、当該履歴情報の前記スコアが前記スコア閾値以上であるときに、前記履歴記録ＤＢの当該履歴情報で示される応答内容を、前記呼出元モジュールに返却する代理応答部と、を備え、
前記記録判断ロジックは、
前記呼出元モジュールから受け取った呼出についての、前記呼出元モジュール、前記呼出先モジュール、前記呼出内容、および、前記応答内容が前記履歴記録ＤＢに記録された履歴情報と一致する場合に、当該呼出元モジュール、当該呼出先モジュール、当該呼出内容、および、当該応答内容を、前記履歴記録ＤＢに記録するものとして、前記スコアをインクリメントし、前記呼出元モジュール、前記呼出先モジュールおよび前記呼出内容が一致しているが、前記応答内容が一致しない場合に、当該呼出についての、前記呼出元モジュール、前記呼出先モジュール、前記呼出内容、および、前記応答内容を、前記履歴記録ＤＢに記録しない、というロジックであること
を特徴とするサービス継続装置。

【請求項2】

前記記憶部には、前記呼出元モジュールに対応付けて、前記代理応答部が前記履歴記録ＤＢに記録された履歴情報で示される応答内容を前記呼出元モジュールに返却した応答回数が記録される課金ＤＢがさらに記憶されており、
前記代理応答部が、前記障害を検出したモジュールが前記呼出先モジュールとなる呼出を受け取った際に、前記履歴記録ＤＢに記録された履歴情報で示される応答内容を、前記呼出元モジュールに返却した場合に、応答をした回数を前記呼出元モジュールごとに前記課金ＤＢに記録する課金処理部を、をさらに備えること
を特徴とする請求項１に記載のサービス継続装置。

【請求項3】

前記システムは、前記複数のモジュールそれぞれに対応した同一の機能を備える複数の予備モジュールを備えており、
前記サービス継続装置の代理応答部は、
前記障害を検出したモジュールが前記呼出先モジュールとなる呼出を受け取った際に、当該呼出についての、前記呼出元モジュール、前記呼出先モジュールおよび前記呼出内容を用いて前記履歴記録ＤＢを参照し、一致する履歴情報があるか否かを判定し、一致する履歴情報が記録されていない場合、および、一致する履歴情報が記録されているが、当該履歴情報の前記スコアが前記スコア閾値未満である場合に、当該呼出を前記呼出先モジュールに対応した前記予備モジュールに通知し、当該予備モジュールから応答を受け取り、当該応答に付された応答内容を前記呼出元モジュールに返却すること
を特徴する請求項１に記載のサービス継続装置。

【請求項4】

分割された複数のモジュールを組み合わせてサービスを提供するシステムにおいて、呼出元となる前記モジュールを示す呼出元モジュールと、呼出先となる前記モジュールを示す呼出先モジュールとの間の呼出および応答の処理を仲介するサービス継続装置のサービス継続方法であって、
前記サービス継続装置は、
前記呼出元モジュール、前記呼出先モジュール、前記呼出元モジュールからの呼出に付された呼出内容、前記呼出先モジュールからの応答に付された応答内容、および、当該呼出に対し当該応答内容により応答した回数を示すスコア、が記録される履歴記録ＤＢ、並びに、前記応答を代理で実行するか否かを前記スコアを用いて判定するためのスコア閾値、を記憶部に記憶しており、
前記呼出元モジュールからの前記呼出内容が付された呼出を受け取り、前記呼出先モジュールに通知するステップと、
前記呼出先モジュールから前記呼出に対する応答を受け取り、前記呼出元モジュール、前記呼出先モジュール、前記呼出内容、および、前記応答内容を示す履歴情報を用いて、記録判断ロジックに基づき、前記履歴情報を記録するか否かを判定し、記録すると判定した履歴情報を前記履歴記録ＤＢに記録するステップと、
複数の前記モジュールの障害を検出することにより前記モジュールの死活監視を行うステップと、
前記障害を検出したモジュールが前記呼出先モジュールとなる呼出を受け取った際に、当該呼出についての、前記呼出元モジュール、前記呼出先モジュールおよび前記呼出内容を用いて前記履歴記録ＤＢを参照し、一致する履歴情報があるか否かを判定し、一致する履歴情報が記録されている場合であり、当該履歴情報の前記スコアが前記スコア閾値以上であるときに、前記履歴記録ＤＢの当該履歴情報で示される応答内容を、前記呼出元モジュールに返却するステップと、を実行し、
前記記録判断ロジックは、
前記呼出元モジュールから受け取った呼出についての、前記呼出元モジュール、前記呼出先モジュール、前記呼出内容、および、前記応答内容が前記履歴記録ＤＢに記録された履歴情報と一致する場合に、当該呼出元モジュール、当該呼出先モジュール、当該呼出内容、および、当該応答内容を、前記履歴記録ＤＢに記録するものとして、前記スコアをインクリメントし、前記呼出元モジュール、前記呼出先モジュールおよび前記呼出内容が一致しているが、前記応答内容が一致しない場合に、当該呼出についての、前記呼出元モジュール、前記呼出先モジュール、前記呼出内容、および、前記応答内容を、前記履歴記録ＤＢに記録しない、というロジックであること
を特徴とするサービス継続方法。

【請求項5】

分割された複数のモジュールを組み合わせてサービスを提供するシステムにおいて、呼出元となる前記モジュールを示す呼出元モジュールと、呼出先となる前記モジュールを示す呼出先モジュールとの間の呼出および応答の処理を仲介するサービス継続装置としてのコンピュータを、
前記呼出元モジュール、前記呼出先モジュール、前記呼出元モジュールからの呼出に付された呼出内容、前記呼出先モジュールからの応答に付された応答内容、および、当該呼出に対し当該応答内容により応答した回数を示すスコア、が記録される履歴記録ＤＢ、並びに、前記応答を代理で実行するか否かを前記スコアを用いて判定するためのスコア閾値、を記憶する手段、
前記呼出元モジュールからの前記呼出内容が付された呼出を受け取り、前記呼出先モジュールに通知する手段、
前記呼出先モジュールから前記呼出に対する応答を受け取り、前記呼出元モジュール、前記呼出先モジュール、前記呼出内容、および、前記応答内容を示す履歴情報を用いて、記録判断ロジックに基づき、前記履歴情報を記録するか否かを判定し、記録すると判定した履歴情報を前記履歴記録ＤＢに記録する手段、
複数の前記モジュールの障害を検出することにより前記モジュールの死活監視を行う手段、
前記障害を検出したモジュールが前記呼出先モジュールとなる呼出を受け取った際に、当該呼出についての、前記呼出元モジュール、前記呼出先モジュールおよび前記呼出内容を用いて前記履歴記録ＤＢを参照し、一致する履歴情報があるか否かを判定し、一致する履歴情報が記録されている場合であり、当該履歴情報の前記スコアが前記スコア閾値以上であるときに、前記履歴記録ＤＢの当該履歴情報で示される応答内容を、前記呼出元モジュールに返却する手段、として機能させ、
前記記録判断ロジックは、
前記呼出元モジュールから受け取った呼出についての、前記呼出元モジュール、前記呼出先モジュール、前記呼出内容、および、前記応答内容が前記履歴記録ＤＢに記録された履歴情報と一致する場合に、当該呼出元モジュール、当該呼出先モジュール、当該呼出内容、および、当該応答内容を、前記履歴記録ＤＢに記録するものとして、前記スコアをインクリメントし、前記呼出元モジュール、前記呼出先モジュールおよび前記呼出内容が一致しているが、前記応答内容が一致しない場合に、当該呼出についての、前記呼出元モジュール、前記呼出先モジュール、前記呼出内容、および、前記応答内容を、前記履歴記録ＤＢに記録しない、というロジックであること
として機能させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、モジュール化されたソフトウェアを組み合わせたアプリケーションによりサービスを提供する、サービス継続装置、サービス継続方法およびプログラムに関する。

【背景技術】

【0002】

ソフトウェア開発に関するスピードの迅速化についての要望がますます強まる中、ソフトウェアを小さな単位に分割してモジュール化し、それらのモジュール化されたソフトウェアを組み合わせてアプリケーションを作り出す手法が一般的になり始めている。
例えば、非特許文献１では、単一のアプリケーションを小さなサービス群の組み合わせとして構築する手法を開示している。ただし、この手法では、アプリケーションが複数のモジュールから構成されるため、ある１つのモジュールの不具合がアプリケーション全体に影響を及ぼすことが問題となる。

【0003】

この問題を解決するため、非特許文献２に記載されたサーキットブレーカを用いた技術が知られている。この技術は、モジュール間を仲介するためのモジュール（サーキットブレーカ）を用意し、定期的に各モジュールの死活監視を行い、無応答などの不具合を検知すると、当該不具合が起こったモジュールへの呼出があった場合に、サーキットブレーカが代理でＮＧ応答を行う技術である。

【先行技術文献】

【非特許文献】

【0004】

【非特許文献1】James Lewis, “Microservices,”［online］，25 March 2014，［平成28年6月8日検索］，インターネット＜ＵＲＬ：http://martinfowler.com/articles/microservices.html＞

【非特許文献2】Martin Fowler，“CircuitBreaker,” ［online］，6 March 2014，［平成28年6月8日検索］，インターネット＜ＵＲＬ：http://martinfowler.com/bliki/CircuitBreaker.html＞

【発明の概要】

【発明が解決しようとする課題】

【0005】

非特許文献２に記載のサーキットブレーカ技術では、モジュールの不具合を発見した際に、代理でＮＧ応答をするため、不具合時の影響を全体に波及させないようにすること（フェールセーフ）が可能である。例えば、あるモジュールが不具合の発生したモジュールを呼び出した際、応答を待ち続けることで、他のモジュールの処理も遅延し、サービスが予期しないエラーに陥るといった事象を回避できる。しかしながら、このサーキットブレーカ技術では、単純にＮＧ応答を行うだけであるので、サービスを継続することは難しい。

【0006】

サービスを停止させないために、そのモジュールへの呼出内容とそのモジュールからの応答内容の記録をとっておいて、同じ呼出内容であれば記録されている応答内容を返却する方法が考えられる。しかしながら、モジュールによっては自身が保持している状態によって、同じ呼出内容でも異なる応答を返却する場合がある。このような状態を持つモジュール（ステートフルなモジュール）への呼出の場合、同じ呼出内容で異なる応答を返却する可能性があるため、単純に呼出内容と応答内容の記録をとって、記録されている応答内容を返却するだけでは誤った応答を返却してしまう可能性がある。

【0007】

このような点を鑑みて本発明がなされたのであり、本発明は、分割された複数のモジュールを組み合わせてサービスを提供するシステムにおいて、あるモジュールに障害が発生した場合においても、サービスを継続することができる、サービス継続装置、サービス継続方法およびプログラムを提供することを課題とする。

【課題を解決するための手段】

【0008】

前記した課題を解決するため、請求項１に記載の発明は、分割された複数のモジュールを組み合わせてサービスを提供するシステムにおいて、呼出元となる前記モジュールを示す呼出元モジュールと、呼出先となる前記モジュールを示す呼出先モジュールとの間の呼出および応答の処理を仲介するサービス継続装置であって、前記呼出元モジュール、前記呼出先モジュール、前記呼出元モジュールからの呼出に付された呼出内容、前記呼出先モジュールからの応答に付された応答内容、および、当該呼出に対し当該応答内容により応答した回数を示すスコア、が記録される履歴記録ＤＢ（DataBase）、並びに、前記応答を代理で実行するか否かを前記スコアを用いて判定するためのスコア閾値、を記憶する記憶部と、前記呼出元モジュールからの前記呼出内容が付された呼出を受け取り、前記呼出先モジュールに通知する呼出内容通知部と、前記呼出先モジュールから前記呼出に対する応答を受け取り、前記呼出元モジュール、前記呼出先モジュール、前記呼出内容、および、前記応答内容を示す履歴情報を用いて、記録判断ロジックに基づき、前記履歴情報を記録するか否かを判定し、記録すると判定した履歴情報を前記履歴記録ＤＢに記録する履歴記録部と、複数の前記モジュールの障害を検出することにより前記モジュールの死活監視を行う死活監視部と、前記障害を検出したモジュールが前記呼出先モジュールとなる呼出を受け取った際に、当該呼出についての、前記呼出元モジュール、前記呼出先モジュールおよび前記呼出内容を用いて前記履歴記録ＤＢを参照し、一致する履歴情報があるか否かを判定し、一致する履歴情報が記録されている場合であり、当該履歴情報の前記スコアが前記スコア閾値以上であるときに、前記履歴記録ＤＢの当該履歴情報で示される応答内容を、前記呼出元モジュールに返却する代理応答部と、を備え、前記記録判断ロジックは、前記呼出元モジュールから受け取った呼出についての、前記呼出元モジュール、前記呼出先モジュール、前記呼出内容、および、前記応答内容が前記履歴記録ＤＢに記録された履歴情報と一致する場合に、当該呼出元モジュール、当該呼出先モジュール、当該呼出内容、および、当該応答内容を、前記履歴記録ＤＢに記録するものとして、前記スコアをインクリメントし、前記呼出元モジュール、前記呼出先モジュールおよび前記呼出内容が一致しているが、前記応答内容が一致しない場合に、当該呼出についての、前記呼出元モジュール、前記呼出先モジュール、前記呼出内容、および、前記応答内容を、前記履歴記録ＤＢに記録しない、というロジックであることを特徴とするサービス継続装置とした。

【0009】

請求項４に記載の発明は、分割された複数のモジュールを組み合わせてサービスを提供するシステムにおいて、呼出元となる前記モジュールを示す呼出元モジュールと、呼出先となる前記モジュールを示す呼出先モジュールとの間の呼出および応答の処理を仲介するサービス継続装置のサービス継続方法であって、前記サービス継続装置が、前記呼出元モジュール、前記呼出先モジュール、前記呼出元モジュールからの呼出に付された呼出内容、前記呼出先モジュールからの応答に付された応答内容、および、当該呼出に対し当該応答内容により応答した回数を示すスコア、が記録される履歴記録ＤＢ、並びに、前記応答を代理で実行するか否かを前記スコアを用いて判定するためのスコア閾値、を記憶部に記憶しており、前記呼出元モジュールからの前記呼出内容が付された呼出を受け取り、前記呼出先モジュールに通知するステップと、前記呼出先モジュールから前記呼出に対する応答を受け取り、前記呼出元モジュール、前記呼出先モジュール、前記呼出内容、および、前記応答内容を示す履歴情報を用いて、記録判断ロジックに基づき、前記履歴情報を記録するか否かを判定し、記録すると判定した履歴情報を前記履歴記録ＤＢに記録するステップと、複数の前記モジュールの障害を検出することにより前記モジュールの死活監視を行うステップと、前記障害を検出したモジュールが前記呼出先モジュールとなる呼出を受け取った際に、当該呼出についての、前記呼出元モジュール、前記呼出先モジュールおよび前記呼出内容を用いて前記履歴記録ＤＢを参照し、一致する履歴情報があるか否かを判定し、一致する履歴情報が記録されている場合であり、当該履歴情報の前記スコアが前記スコア閾値以上であるときに、前記履歴記録ＤＢの当該履歴情報で示される応答内容を、前記呼出元モジュールに返却するステップと、を実行し、前記記録判断ロジックは、前記呼出元モジュールから受け取った呼出についての、前記呼出元モジュール、前記呼出先モジュール、前記呼出内容、および、前記応答内容が前記履歴記録ＤＢに記録された履歴情報と一致する場合に、当該呼出元モジュール、当該呼出先モジュール、当該呼出内容、および、当該応答内容を、前記履歴記録ＤＢに記録するものとして、前記スコアをインクリメントし、前記呼出元モジュール、前記呼出先モジュールおよび前記呼出内容が一致しているが、前記応答内容が一致しない場合に、当該呼出についての、前記呼出元モジュール、前記呼出先モジュール、前記呼出内容、および、前記応答内容を、前記履歴記録ＤＢに記録しない、というロジックであることを特徴とするサービス継続方法とした。

【0010】

請求項５に記載の発明は、分割された複数のモジュールを組み合わせてサービスを提供するシステムにおいて、呼出元となる前記モジュールを示す呼出元モジュールと、呼出先となる前記モジュールを示す呼出先モジュールとの間の呼出および応答の処理を仲介するサービス継続装置としてのコンピュータを、前記呼出元モジュール、前記呼出先モジュール、前記呼出元モジュールからの呼出に付された呼出内容、前記呼出先モジュールからの応答に付された応答内容、および、当該呼出に対し当該応答内容により応答した回数を示すスコア、が記録される履歴記録ＤＢ、並びに、前記応答を代理で実行するか否かを前記スコアを用いて判定するためのスコア閾値、を記憶する手段、前記呼出元モジュールからの前記呼出内容が付された呼出を受け取り、前記呼出先モジュールに通知する手段、前記呼出先モジュールから前記呼出に対する応答を受け取り、前記呼出元モジュール、前記呼出先モジュール、前記呼出内容、および、前記応答内容を示す履歴情報を用いて、記録判断ロジックに基づき、前記履歴情報を記録するか否かを判定し、記録すると判定した履歴情報を前記履歴記録ＤＢに記録する手段、複数の前記モジュールの障害を検出することにより前記モジュールの死活監視を行う手段、前記障害を検出したモジュールが前記呼出先モジュールとなる呼出を受け取った際に、当該呼出についての、前記呼出元モジュール、前記呼出先モジュールおよび前記呼出内容を用いて前記履歴記録ＤＢを参照し、一致する履歴情報があるか否かを判定し、一致する履歴情報が記録されている場合であり、当該履歴情報の前記スコアが前記スコア閾値以上であるときに、前記履歴記録ＤＢの当該履歴情報で示される応答内容を、前記呼出元モジュールに返却する手段、として機能させ、前記記録判断ロジックは、前記呼出元モジュールから受け取った呼出についての、前記呼出元モジュール、前記呼出先モジュール、前記呼出内容、および、前記応答内容が前記履歴記録ＤＢに記録された履歴情報と一致する場合に、当該呼出元モジュール、当該呼出先モジュール、当該呼出内容、および、当該応答内容を、前記履歴記録ＤＢに記録するものとして、前記スコアをインクリメントし、前記呼出元モジュール、前記呼出先モジュールおよび前記呼出内容が一致しているが、前記応答内容が一致しない場合に、当該呼出についての、前記呼出元モジュール、前記呼出先モジュール、前記呼出内容、および、前記応答内容を、前記履歴記録ＤＢに記録しない、というロジックであること、として機能させるためのプログラムとした。

【0011】

このようにすることで、サービス継続装置等によれば、記録判定ロジックにより、呼出元モジュール、呼出先モジュールおよび呼出内容が一致していても、応答内容が異なる履歴情報については、履歴記録ＤＢに記録しないようにすることができる。つまり、ステートフルなモジュールからの応答については、履歴記録ＤＢに記録しないようにする。一方、状態を持たないモジュール（ステートレスなモジュール）に障害が発生した場合においては、サービス継続装置の履歴記録ＤＢに記録された応答内容を用いて代理で応答することが可能となり、サービスを継続することが可能となる。

【0012】

また、請求項２に記載の発明は、前記記憶部には、前記呼出元モジュールに対応付けて、前記代理応答部が前記履歴記録ＤＢに記録された履歴情報で示される応答内容を前記呼出元モジュールに返却した応答回数が記録される課金ＤＢがさらに記憶されており、前記代理応答部が、前記障害を検出したモジュールが前記呼出先モジュールとなる呼出を受け取った際に、前記履歴記録ＤＢに記録された履歴情報で示される応答内容を、前記呼出元モジュールに返却した場合に、応答をした回数を前記呼出元モジュールごとに前記課金ＤＢに記録する課金処理部を、をさらに備えることを特徴とする請求項１に記載のサービス継続装置とした。

【0013】

このように、サービス継続装置によれば、障害が発生した呼出先モジュールの代わりに応答した回数を課金ＤＢに記録することができる。よって、課金ＤＢに記録された応答回数に応じて、各モジュールの管理者に課金することができる。

【0014】

また、請求項３に記載の発明は、前記システムは、前記複数のモジュールそれぞれに対応した同一の機能を備える複数の予備モジュールを備えており、前記サービス継続装置の代理応答部が、前記障害を検出したモジュールが前記呼出先モジュールとなる呼出を受け取った際に、当該呼出についての、前記呼出元モジュール、前記呼出先モジュールおよび前記呼出内容を用いて前記履歴記録ＤＢを参照し、一致する履歴情報があるか否かを判定し、一致する履歴情報が記録されていない場合、および、一致する履歴情報が記録されているが、当該履歴情報の前記スコアが前記スコア閾値未満である場合に、当該呼出を前記呼出先モジュールに対応した前記予備モジュールに通知し、当該予備モジュールから応答を受け取り、当該応答に付された応答内容を前記呼出元モジュールに返却することを特徴する請求項１に記載のサービス継続装置とした。

【0015】

このようにすることで、サービス継続装置によれば、記録判定ロジックにより、呼出元モジュール、呼出先モジュールおよび呼出内容が一致していても、応答内容が異なる履歴情報については、予備モジュールにその呼出を通知して応答を取得し、呼出元モジュールに返却することができる。よって、ステートフルなモジュールに障害が発生した場合においても、確実にサービスを継続することが可能となる。

【発明の効果】

【0016】

本発明によれば、分割された複数のモジュールを組み合わせてサービスを提供するシステムにおいて、あるモジュールに障害が発生した場合においても、サービスを継続する、サービス継続装置、サービス継続方法およびプログラムを提供することができる。

【図面の簡単な説明】

【0017】

【図1】本実施形態に係るサービス継続装置を含むサービスシステムの構成を示す図である。

【図2】本実施形態に係るサービス継続装置の構成例を示す機能ブロック図である。

【図3】本実施形態に係る履歴記録ＤＢに記録される履歴情報のデータ構成を示す図である。

【図4】記録判断ロジックにより設定される処理の流れを示すフローチャートである。

【図5】本実施形態に係るサービス継続装置を含むサービスシステムの処理を示すシーケンス図である。

【図6】本実施形態の変形例１に係るサービス継続装置の構成例を示す機能ブロック図である。

【図7】本実施形態の変形例１に係る課金ＤＢに記録される課金情報のデータ構成を示す図である。

【図8】本実施形態の変形例２に係るサービス継続装置を含むサービスシステムの構成を示す図である。

【図9】本実施形態の変形例２に係るサービス継続装置の構成例を示す機能ブロック図である。

【図10】本実施形態の変形例２に係るサービス継続装置を含むサービスシステムの処理を示すシーケンス図である。

【発明を実施するための形態】

【0018】

次に、本発明を実施するための形態（以下、「本実施形態」と称する。）における、サービス継続装置１０等について説明する。

【0019】

＜概要＞
まず、本実施形態に係るサービス継続装置１０（後記する図１，図２参照）が実行する処理の概要について説明する。
本実施形態に係るサービス継続装置１０は、複数のモジュールによる処理を実行してサービスを提供する際に、そのモジュール間を仲介する処理を実行する。具体的には、各モジュール間では、呼出・応答に関する送受信は直接には行わず、サービス継続装置１０を介して行う。また、サービス継続装置１０は、モジュール間の呼出内容および応答内容に関する情報を、記録判断ロジック（後記する図４参照）に従い、キャッシュとして記録するか判断した上で、履歴情報として記録しておく（後記する図３の「履歴記録ＤＢ（DataBase）１３０」）。この記録判断ロジックは、状態を持つモジュール「以下、「ステートフルなモジュール」と称する。）と、状態を持たないモジュール（以下、「ステートレスなモジュール」と称する。）とを区別するための判断ロジックであり、ステートレスなモジュールからの呼出・応答に関する履歴情報を記録する。
そして、サービス継続装置１０は、あるモジュールについて障害の発生を検知した場合に、そのモジュールについて呼出があったときには、記録されている履歴情報の中に、同じ呼出内容が記録されているか否かを確認し、記録されている場合において、後記する所定の条件（「スコアが所定の閾値以上」の場合）を満たすときに、履歴情報で示される応答内容を返却する。

【0020】

このようにすることで、本実施形態に係るサービス継続装置１０によれば、ステートフルなモジュールとステートレスなモジュールとが混在する場合であっても、記録判断ロジックに基づき判定することにより、ステートフルなモジュールからの応答内容は記録せず、ステートレスなモジュールからの応答内容を記録する可能性を高めることができる。そのため、モジュールに障害が発生したときにも、誤った応答内容を返却することなく、サービスを継続することができる。

【0021】

＜システム構成＞
次に、本実施形態に係るサービス継続装置１０を含むサービスシステムの構成について説明する。
図１は、本実施形態に係るサービス継続装置１０を含むサービスシステムの構成を示す図である。
本実施形態に係るサービスシステムでは、複数のデータセンタ１００（「１」…「Ｎ」）がネットワークを介して接続される。また、各データセンタ１００には、サーバ２０が設置される。サーバ２０は、ソフトウェアを小さな単位に分割したモジュール２を備える。図１においては、データセンタ「１」内に、サーバ「１」，「２」が設置され、サーバ「１」がモジュール「１」，「２」を備え、サーバ「２」がモジュール「３」を備える例を示している。なお、以後、モジュール２の総称として符号「２」を付し、個別のモジュール２を識別する場合は、モジュール「１」、モジュール「２」、モジュール「３」等として表記する。

【0022】

また、サービスシステム内には、サービス継続装置１０が備えられる。このサービス継続装置１０は、ネットワークを介して、各サーバ２０と接続される。図１において、サービス継続装置１０は、データセンタ「１」内に設置される例を示しているが、これに限定されず、他のデータセンタ１００の何れかに設置されてもよいし、データセンタ１００の外部に、ネットワークに接続された上で、単独で設置されてもよい。

【0023】

このサービスシステムにおけるサービスの提供は、各サーバ２０内のモジュール２の処理を組み合わせることにより行われる。その際に、複数のモジュール２間の呼出・応答に関する送受信は、サービス継続装置１０を介して行う。

【0024】

サービス継続装置１０は、複数のモジュール２間の呼出・応答に関する仲介を行うモジュール仲介部１１を備え、モジュール間の呼出内容および応答内容に関する情報を、記録判断ロジックに従い履歴記録ＤＢ１３０（図３参照）に記録しておく。そして、サービス継続装置１０は、障害が発生したモジュール２への呼出があった場合には、履歴記録ＤＢ１３０を参照し、記録されている履歴情報の中に、同じ呼出内容が記録されているか否かを確認し、記録されている場合において、所定の条件（「スコアが所定の閾値以上」）を満たすときに、履歴情報で示される応答内容を返却する。
以下、サービス継続装置１０について詳細に説明する。

【0025】

＜サービス継続装置の構成＞
次に、本実施形態に係るサービス継続装置１０の構成について説明する。
図２は、本実施形態に係るサービス継続装置１０の構成例を示す機能ブロック図である。
サービス継続装置１０は、図２に示すように、モジュール仲介部１１の機能を含む制御部（図示省略）と、入出力部１２と、記憶部１３とを含んで構成される。

【0026】

入出力部１２は、ネットワークを介して通信接続される、各サーバ２０に備わるモジュール２等との間の情報の入出力を行う。また、入出力部１２は、通信回線を介して情報の送受信を行う不図示の通信インタフェースと、キーボード等の入力手段やモニタ等の出力手段（いずれも不図省略）との間で入出力を行う入出力インタフェースとから構成される。

【0027】

記憶部１３は、ハードディスクやフラッシュメモリ、ＲＡＭ（Random Access Memory）等により構成される。
この記憶部１３には、後記する履歴記録ＤＢ１３０（図３）や、スコア閾値１４０等が記憶されるとともに、制御部（モジュール仲介部１１）の各機能を実行させるためのプログラムや、制御部の処理に必要な情報が一時的に記憶される。

【0028】

制御部（モジュール仲介部１１）は、サービス継続装置１０全体の制御を司り、呼出内容通知部１１１と、履歴記録部１１２と、応答内容返却部１１３と、死活監視部１１４と、代理応答部１１５とを含んで構成される。
また、この制御部は、例えば、記憶部１３に格納されたプログラムを不図示のＣＰＵ（Central Processing Unit）がＲＡＭに展開し実行することで実現される。

【0029】

呼出内容通知部１１１は、あるモジュール２（呼出元モジュール）から他のモジュール２（呼出先モジュール）への要求（呼出内容が付された呼出）を受け取る。そして、呼出内容通知部１１１は、その要求（呼出）を、呼出先となるモジュール２へ通知する。
また、呼出内容通知部１１１は、呼出元モジュールから呼出先モジュールへの要求（呼出）を受け取った際に、その呼出先モジュールに障害が発生している旨の情報を、死活監視部１１４から受け取っていた場合には、その要求（呼出）を代理応答部１１５に出力する。

【0030】

履歴記録部１１２は、呼出内容通知部１１１が要求を通知した呼出先モジュールからの応答を受け取る。この呼出先モジュールからの応答には、どの要求（呼出）に対する応答であるのかを紐付けるために、シーケンス番号や、呼出元モジュールのＩＤ・呼出内容などの要求（呼出）を識別する情報が、その応答内容に含まれる。そして、履歴記録部１１２は、呼出先モジュールからの応答に対応する要求（呼出）を特定した上で、記録判断ロジックに従い、その応答に付された応答内容を含む情報を履歴情報として履歴記録ＤＢ１３０に記録するか否かを判定する。そして、履歴記録部１１２は、記録すべきと判定した場合には、図３に示す履歴記録ＤＢ１３０に、履歴情報として記録する。

【0031】

図３は、本実施形態に係る履歴記録ＤＢ１３０に記録される履歴情報のデータ構成を示す図である。
図３に示すように、履歴記録ＤＢ１３０には、呼出元モジュール１３１、呼出先モジュール１３２、呼出内容１３３、応答内容１３４、スコア１３５の各項目が履歴情報として格納される。

【0032】

呼出元モジュール１３１には、サービス継続装置１０が受信した要求の呼出元のモジュール２の識別子が格納される。例えば、図３に示すように、呼出元モジュール１３１に、呼出元であるモジュール２の識別子「３」が格納される。
呼出先モジュール１３２には、受信した要求の呼出先となるモジュール２の識別子が格納される。例えば、図３に示すように、呼出先モジュール１３２に、呼出先となるモジュール２の識別子「１」が格納される。

【0033】

呼出内容１３３には、呼出元モジュールからの要求に付された呼出内容が格納される。例えば、図３に示すように、呼出内容１３３として「GET/index.html」が格納される。
応答内容１３４には、呼出先モジュールからの応答に付された応答内容が格納される。
例えば、図３に示すように、応答内容１３４として「HTTP/1.1 200OK hoge」が格納される。

【0034】

スコア１３５には、呼出元モジュール１３１、その呼出元モジュールからの要求に付された呼出内容１３３、呼出先モジュール１３２、その呼出先モジュールからの応答に付された応答内容１３４の各情報について、履歴記録部１１２が記録判断ロジックに基づき、同一の履歴情報であると判断した回数が格納される。
図３に示す例では、呼出元モジュール１３１が「３」、呼出先モジュール１３２が「１」、呼出内容１３３が「GET/index.html」、応答内容１３４が「HTTP/1.1 200OK hoge」である処理が「３２３（回）」あったことを示している。

【0035】

次に、履歴記録部１１２が、履歴記録ＤＢ１３０に記録するか否かの判定に用いる記録判断ロジックについて説明する。
図４は、記録判断ロジックにより設定される処理の流れを示すフローチャートである。
履歴記録部１１２は、呼出内容通知部１１１が呼出先モジュールへの要求の通知に際して取得した、呼出元モジュールと呼出内容の情報と、呼出先モジュールから受信した応答に付された、呼出先モジュールと応答内容の情報とに基づき、当該応答を受信した際に、以下の記録判断ロジックに基づく処理（ステップＳ１〜Ｓ５）を実行する。

【0036】

まず、履歴記録部１１２は、呼出先モジュールから受信した応答に関する、呼出元モジュール、呼出先モジュール、呼出内容について、履歴記録ＤＢ１３０（図３）の中に、これらの情報のすべてが一致するレコード（履歴情報）があるか否かを判定する（ステップＳ１）。
そして、履歴記録部１１２は、これらの情報のすべてが一致するレコードがない場合に（ステップＳ１→Ｎｏ）、新たなレコード（履歴情報）として、呼出先モジュール、呼出元モジュール、呼出内容、および、その応答内容を、履歴記録ＤＢ１３０に格納した上で、スコア１３５を「１」とする（ステップＳ２）。
一方、ステップＳ１において、すべて一致するレコードがある場合には（ステップＳ１→Ｙｅｓ）、履歴記録部１１２は、ステップＳ３に進む。

【0037】

ステップＳ３において、履歴記録部１１２は、履歴記録ＤＢ１３０の中に、呼出元モジュール、呼出先モジュール、呼出内容、応答内容のすべてが一致するレコードがあるか否かを判定する。そして、すべてが一致するレコードがない場合には（ステップＳ３→Ｎｏ）、ステップＳ４に進む。

【0038】

ステップＳ４において、履歴記録部１１２は、判定対象とした情報である、呼出元モジュール、呼出先モジュール、呼出内容、応答内容について履歴記録ＤＢ１３０にレコードとして記録しないことを決定する。また、履歴記録部１１２は、ステップＳ１において、呼出元モジュール、呼出先モジュール、呼出内容が一致したレコードについて、履歴記録ＤＢ１３０から削除する処理を実行する。

【0039】

一方、ステップＳ３において、すべてが一致するレコードがある場合には（ステップＳ３→Ｙｅｓ）、履歴記録部１１２は、当該レコードのスコア１３５をインクリメントする（ステップＳ５）。そして、記録判断ロジックの処理を終了する。

【0040】

図２に戻り、応答内容返却部１１３は、履歴記録部１１２による記録判断ロジックの処理が終了すると、呼出先モジュールから受信した応答を、呼出元モジュールに返却する。

【0041】

死活監視部１１４は、所定の時間間隔で、各モジュール２に対し、死活確認要求を送信し、その応答情報を受信する等により、各モジュール２の死活監視を行う。
死活監視部１１４は、各モジュール２の死活監視により、あるモジュール２についての障害の発生を検出した場合には、その障害発生情報を呼出内容通知部１１１に出力する。

【0042】

代理応答部１１５は、呼出内容通知部１１１からの出力に基づく、障害が発生した呼出先モジュールに向けての要求から、その呼出元モジュールおよび呼出内容を抽出し、履歴記録ＤＢ１３０（図３）の中で、その呼出元モジュール、呼出先モジュール、呼出内容が一致するレコードが記録されているか否かを確認する。そして、代理応答部１１５は、記録されている場合、そのレコードのスコア１３５が、記憶部１３に予め設定されているスコア閾値１４０以上であるか否かを判定する。代理応答部１１５は、スコア１３５の値がスコア閾値１４０以上である場合には、そのレコードで示される応答内容１３４を、呼出元モジュールに返却する。
一方、代理応答部１１５は、履歴記録ＤＢ１３０に、呼出元モジュール、呼出先モジュール、呼出内容が一致するレコードが記録されていない場合、記録されている場合であっても、スコア１３５の値がスコア閾値１４０未満であるときには、ＮＧ応答を呼出元モジュールに返却する。

【0043】

≪処理の流れ≫
次に、本実施形態に係るサービス継続装置１０を含むサービスシステムが実行する処理の流れについて説明する。
図５は、本実施形態に係るサービス継続装置１０を含むサービスシステムの処理を示すシーケンス図である。なお、サービス継続装置１０の記憶部１３には、予めスコア閾値１４０（ここでは、「３００」とする。）が登録されているものとする。

【0044】

まず、各モジュール２に障害が発生する前（通常時）における処理（ステップＳ１０〜Ｓ１４）を説明する。
図５に示すように、例えば、モジュール「３」（呼出元モジュール）からの要求（GET/index.html）をサービス継続装置１０が受信する（ステップＳ１０）。
続いて、サービス継続装置１０の呼出内容通知部１１１が、その要求（GET/index.html）を、呼出先モジュールであるモジュール「１」に通知する（ステップＳ１１）。

【0045】

次に、サービス継続装置１０は、呼出先モジュールであるモジュール「１」からの応答（HTTP/1.1 200OK hoge）を受信する（ステップＳ１２）。
サービス継続装置１０の履歴記録部１１２は、呼出先モジュール（モジュール「１」）からの応答（HTTP/1.1 200OK hoge）を受け取ると、図４に示した記録判断ロジックに従い、その応答に付された応答内容を含む情報を履歴情報として履歴記録ＤＢ１３０に記録するか否かを判定する（ステップＳ１３）。

【0046】

ここでは、図４に示す記録判断ロジックの処理において、ステップＳ１において、呼出元モジュール、呼出先モジュール、呼出内容が、モジュール「３」、モジュール「１」、（GET/index.html）であるものと一致するレコード（履歴情報）が履歴記録ＤＢ１３０に記録されており（図４のステップＳ１→Ｙｅｓ）、さらに、図４のステップＳ３において、応答内容も（HTTP/1.1 200OK hoge）と一致するレコードが履歴記録ＤＢ１３０にあるものとする（図４のステップＳ３→Ｙｅｓ）。この場合、履歴記録部１１２は、一致するレコードのスコア１３５をインクリメントする（図４のステップＳ５）。このインクリメントした結果の状態が、図３に示す状態であるとして、以下において説明する。

【0047】

次に、サービス継続装置１０の応答内容返却部１１３は、呼出先モジュール（モジュール「１」）から受信した応答（HTTP/1.1 200OK hoge）を、呼出元モジュールに返却する（ステップＳ１４）。

【0048】

上記の通常時の処理において、サービス継続装置１０は、モジュール２間の呼出・応答に伴い、随時、履歴記録ＤＢ１３０を更新する。また、サービス継続装置１０は、各モジュール２の死活監視を実行する。
サービス継続装置１０の死活監視部１１４は、所定の時間間隔で、各モジュール２に対し、死活確認要求を送信する（ステップＳ２０）。なお、ここでは、モジュール「１」に障害が発生したものとする。
死活監視部１１４は、モジュール「２」，「３」からは死活確認要求に対する応答情報を受信するが（ステップＳ２１）、モジュール「１」からは応答情報を受信することができない。これにより、死活監視部１１４は、モジュール「１」に障害が発生したことを検出する（ステップＳ２２）。そして、死活監視部１１４は、モジュール「１」に障害が発生した旨を呼出内容通知部１１１に出力する。

【0049】

この状態において、サービス継続装置１０がモジュール「３」（呼出元モジュール）からモジュール「１」への要求（GET/index.html）を受信する（ステップＳ３０）。
この場合、サービス継続装置１０の呼出内容通知部１１１は、モジュール「１」に障害が発生しているため、その要求を、代理応答部１１５に出力する。

【0050】

サービス継続装置１０の代理応答部１１５は、その要求に付された、送信元モジュール（モジュール「３」）、送信先モジュール（モジュール「１」）、呼出内容（GET/index.html）を用いて、履歴記録ＤＢ１３０を検索し、これらの情報が一致するレコードが記録されているか否かを確認する（ステップＳ３１）。
そして、代理応答部１１５は、記録されている場合には、そのレコードのスコア１３５の値が、スコア閾値１４０（「３００」）以上であるか否かを判定する。
ここでは、図３に示す履歴記録ＤＢ１３０の１行目に示すレコードのスコア１３５の値が「３２３」であるので、代理応答部１１５は、スコア閾値１４０（「３００」）以上であると判定する。
そして、代理応答部１１５は、当該レコードに記録された応答内容１３４（ここでは、「HTTP/1.1 200OK hoge」）を、送信元モジュール（モジュール「３」）に返却する（ステップＳ３２：代理応答）。

【0051】

次に、サービス継続装置１０がモジュール「２」（呼出元モジュール）からモジュール「１」への要求（GETID user1）を受信する（ステップＳ４０）。
この場合も、サービス継続装置１０の呼出内容通知部１１１は、モジュール「１」に障害が発生しているため、その要求を、代理応答部１１５に出力する。

【0052】

サービス継続装置１０の代理応答部１１５は、その要求に付された、送信元モジュール（モジュール「２」）、送信先モジュール（モジュール「１」）、呼出内容（GETID user1）を用いて、履歴記録ＤＢ１３０を検索し、これらの情報が一致するレコードが記録されているか否かを確認する（ステップＳ４１）。
そして、代理応答部１１５は、記録されている場合には、そのレコードのスコア１３５の値が、スコア閾値１４０（「３００」）以上であるか否かを判定する。
ここでは、図３に示す履歴記録ＤＢ１３０の２行目に示すレコードのスコア１３５の値が「５」であるので、代理応答部１１５は、スコア閾値１４０（「３００」）以上ではないと判定する。
そして、代理応答部１１５は、送信元モジュール（モジュール「２」）にＮＧ応答を返却する（ステップＳ４２）。

【0053】

このようにすることで、本実施形態に係るサービス継続装置１０等によれば、記録判定ロジックにより、ステートレスなモジュール２からの応答内容を履歴記録ＤＢ１３０に確実に記録しておくことができる。よって、ステートレスなモジュール２に障害が発生した場合において、サービス継続装置１０が代理で応答することができるため、サービスを継続することが可能となる。

【0054】

＜本実施形態の変形例１＞
次に、本実施形態に係るサービス継続装置１０の変形例１について説明する。
本実施形態の変形例１に係るサービス継続装置１０Ａ（１０）は、課金ＤＢ１５０（後記する、図６，図７参照）を備える。そして、サービス継続装置１０Ａ（１０）が、履歴記録ＤＢ１３０に記録されている情報を用いて、送信元モジュールに代理で応答した場合に、課金ＤＢへの記録を行うことを特徴とする。

【0055】

図６は、本実施形態の変形例１に係るサービス継続装置１０Ａ（１０）の構成例を示す機能ブロック図である。
図２に示した本実施形態に係るサービス継続装置１０と比べ、記憶部１３に課金ＤＢ１５０を備えるとともに、制御部（モジュール仲介部１１）内に、課金処理部１１６を備える点が異なる。なお、図２で示す構成と同じ機能を備える構成については、同一の名称と符号を付し、説明を省略する。

【0056】

課金処理部１１６は、代理応答部１１５の処理を監視し、代理応答部１１５が、障害が発生した呼出先モジュールについて、履歴記録ＤＢ１３０を検索し、スコア１３５の値がスコア閾値１４０以上の履歴情報について、応答内容を代理で返却した場合に、課金ＤＢ１５０に記録を行う。

【0057】

図７は、本実施形態の変形例１に係る課金ＤＢ１５０に記録される課金情報のデータ構成を示す図である。
図７に示すように、課金ＤＢ１５０には、呼出元モジュール１５１、管理者ＩＤ１５２および応答回数１５３の各項目が課金情報として格納される。

【0058】

呼出元モジュール１５１には、サービス継続装置１０が受信した要求の呼出元のモジュール２の識別子が格納される。この呼出元モジュール１５１は、図３の履歴記録ＤＢ１３０における呼出元モジュール１３１と同様の情報である。
管理者ＩＤ１５２には、呼出元モジュール１５１を管理する管理者の識別子が格納される。例えば、呼出元モジュール１５１が「３」のモジュール２を管理する管理者の管理者ＩＤ１５２として「＃０００３」が格納される。

【0059】

応答回数１５３には、代理応答部１１５が、履歴記録ＤＢ１３０に記録された応答内容１３４を用いて、障害が発生した呼出先モジュールの代わりに応答した回数が格納される。例えば、図７に示す例では、呼出元モジュール１５１に対して、障害が発生した呼出先モジュールの代わりに「４５（回）」応答したことが格納される。

【0060】

このように、本実施形態の変形例１に係るサービス継続装置１０Ａ（１０）によれば、代理応答部１１５が、障害が発生した呼出先モジュールの代わりに応答した回数を課金ＤＢ１５０に記録することができる。よって、サービス継続装置１０Ａ（１０）の課金ＤＢ１５０に記録された応答回数１５３に応じて、各モジュール２の管理者に課金することができる。

【0061】

＜本実施形態の変形例２＞
次に、本実施形態に係るサービス継続装置１０の変形例２について説明する。
図８は、本実施形態の変形例２に係るサービス継続装置１０Ｂ（１０）を含むサービスシステムの構成を示す図である。
図８に示すサービスシステムでは、図１に示したサービスシステムに加え、データセンタ「２」内に、予備モジュール２Ｂ（２）を備えることを特徴する。この予備モジュール２Ｂ（２）は、データセンタ「１」等に備わるモジュール２それぞれに対応する予備のモジュールである。つまり、モジュール２と予備モジュール２Ｂ（２）とは、同一の処理を実行する機能を有する。図８では、モジュール「１」「２」「３」のそれぞれに対応する予備モジュール「１」「２」「３」が、データセンタ「２」のサーバ「３」に備わる例を示している。ただし、この予備モジュール２Ｂ（２）それぞれは、１つのデータセンタ１００内に備わることに限定されず、複数のデータセンタ１００内に備わる構成でもよい。また、図８に示すように、１つのサーバ２０（ここでは、サーバ「３」）内にすべての予備モジュール２Ｂ（２）が格納されることに限定されず、複数のサーバ２０に分散して格納されていてもよい。

【0062】

本実施形態の変形例２に係るサービス継続装置１０Ｂ（１０）は、図９に示すように、モジュール仲介部１１Ｂ（１１）を備える。このモジュール仲介部１１Ｂ（１１）は、図２に示すサービス継続装置１０の代理応答部１１５とは異なる代理応答部１１５Ｂ（１１５）を有する。なお、図２で示す構成と同じ機能を備える構成については、図９においても、同一の名称と符号を付し、説明を省略する。

【0063】

代理応答部１１５Ｂ（１１５）は、図２に示す本実施形態の代理応答部１１５と同様に、障害が発生した呼出先モジュールに向けての要求に基づき、その呼出元モジュールおよび呼出内容を抽出し、履歴記録ＤＢ１３０（図３参照）の中で、その呼出元モジュール、呼出先モジュール、呼出内容が一致するレコードが格納されているか否かを確認する。そして、代理応答部１１５Ｂ（１１５）は、記録されている場合、そのレコードのスコア１３５が、記憶部１３に予め設定されているスコア閾値１４０以上であるか否かを判定する。代理応答部１１５は、スコア１３５の値がスコア閾値１４０以上である場合には、そのレコードで示される応答内容１３４を、呼出元モジュールに返却する。

【0064】

一方、代理応答部１１５Ｂ（１１５）は、履歴記録ＤＢ１３０に、呼出元モジュール、呼出先モジュール、呼出内容が一致するレコードが記録されていない場合、記録されている場合であっても、スコア１３５の値がスコア閾値１４０未満であるときには、障害が発生した呼出先モジュールに対応する予備モジュール２Ｂ（２）に対して、要求を送信する。そして、代理応答部１１５Ｂ（１１５）は、呼出先モジュールに対応する予備モジュール２Ｂ（２）から応答を取得し、その応答を呼出元モジュールに返却する。

【0065】

≪処理の流れ≫
次に、本実施形態の変形例２に係るサービス継続装置１０Ｂ（１０）を含むサービスシステムが実行する処理の流れについて説明する。
図１０は、本実施形態の変形例２に係るサービス継続装置１０Ｂ（１０）を含むサービスシステムの処理を示すシーケンス図である。なお、サービス継続装置１０Ｂ（１０）の記憶部１３には、予めスコア閾値１４０（ここでは、「３００」とする。）が登録されているものとする。また、図５のステップＳ１０〜Ｓ１４に示す通常時の処理により、サービス継続装置１０Ｂ（１０）は、モジュール２間の呼出・応答に伴い、随時、履歴記録ＤＢ１３０を更新している。そして、サービス継続装置１０Ｂ（１０）は、各モジュール２の死活監視を実行することにより（ステップＳ２０〜Ｓ２２）、モジュール「１」の障害を検出したものとする。ここでは、ステップＳ２２でのモジュール「１」の障害発生の検出後に、サービス継続装置１０Ｂ（１０）の履歴記録ＤＢ１３０に記録されている履歴情報が、図３に示す状態であるとして説明する。

【0066】

ステップＳ２２の後、サービス継続装置１０Ｂ（１０）が、モジュール「２」（呼出元モジュール）からモジュール「１」（送信先モジュール）への要求（GETID user1）を受信する（ステップＳ５０）。
この場合、サービス継続装置１０Ｂ（１０）の呼出内容通知部１１１は、モジュール「１」に障害が発生しているため、その要求を、代理応答部１１５Ｂ（１１５）に出力する。

【0067】

サービス継続装置１０Ｂ（１０）の代理応答部１１５Ｂ（１１５）は、その要求に付された、送信元モジュール（モジュール「２」）、送信先モジュール（モジュール「１」）、呼出内容（GETID user1）を用いて、履歴記録ＤＢ１３０（図３）を検索し、これらの情報が一致するレコードが記録されているか否かを確認する（ステップＳ５１）。

【0068】

そして、代理応答部１１５Ｂ（１１５）は、記録されている場合には、そのレコードのスコア１３５の値が、スコア閾値１４０（「３００」）以上であるか否かを判定する。
ここでは、図３に示す履歴記録ＤＢ１３０の２行目に示すレコードのスコア１３５の値が「５」であるので、代理応答部１１５Ｂ（１１５）は、スコア閾値１４０（「３００」）以上ではないと判定する。

【0069】

続いて、代理応答部１１５Ｂ（１１５）は、障害が発生した呼出先モジュールに対応する予備モジュール２Ｂ（２）に対して、要求を送信する（ステップＳ５２）。ここでは、代理応答部１１５Ｂ（１１５）は、障害が発生した呼出先となるモジュール「１」に対応する予備モジュール「１」に、要求（GETID user1）を送信する。

【0070】

そして、サービス継続装置１０Ｂ（１０）の代理応答部１１５Ｂ（１１５）は、予備モジュール「１」から応答（「1018714」）を受信する（ステップＳ５３）。
次に、代理応答部１１５Ｂ（１１５）は、受信した応答（「1018714」）を、呼出元モジュール（モジュール「２」）に返却する（ステップＳ５４）。

【0071】

このようにすることで、本実施形態の変形例２に係るサービス継続装置１０Ｂ（１０）は、ステートフルなモジュール２とステートレスなモジュール２とが混在する場合であっても、記録判定ロジックにより、ステートレスなモジュール２からの応答内容を履歴記録ＤＢ１３０に確実に記録しておくことができる。よって、ステートレスなモジュール２に障害が発生した場合においては、サービス継続装置１０Ｂ（１０）が代理で応答することができる。また、サービス継続装置１０Ｂ（１０）は、ステートフルなモジュール２に障害が発生した場合において、予備モジュール２Ｂ（２）から応答を取得して、呼出元モジュールに返却することができる。よって、本実施形態の変形例２に係るサービス継続装置１０Ｂ（１０）によれば、モジュール２に障害が発生した場合において、より確実にサービスを継続することが可能となる。

【符号の説明】

【0072】

２ モジュール
２Ｂ 予備モジュール
１０，１０Ａ，１０Ｂ サービス継続装置
１１，１１Ｂ モジュール仲介部
１２ 入出力部
１３ 記憶部
１００ データセンタ
１１１ 呼出内容通知部
１１２ 履歴記録部
１１３ 応答内容返却部
１１４ 死活監視部
１１５，１１５Ｂ 代理応答部
１１６ 課金処理部
１３０ 履歴記録ＤＢ
１４０ スコア閾値
１５０ 課金ＤＢ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】