特開2017-228007(P2017-228007A)IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 日本電信電話株式会社の特許一覧
特開2017-228007サービス継続装置、サービス継続方法およびプログラム
<>
  • 特開2017228007-サービス継続装置、サービス継続方法およびプログラム 図000003
  • 特開2017228007-サービス継続装置、サービス継続方法およびプログラム 図000004
  • 特開2017228007-サービス継続装置、サービス継続方法およびプログラム 図000005
  • 特開2017228007-サービス継続装置、サービス継続方法およびプログラム 図000006
  • 特開2017228007-サービス継続装置、サービス継続方法およびプログラム 図000007
  • 特開2017228007-サービス継続装置、サービス継続方法およびプログラム 図000008
  • 特開2017228007-サービス継続装置、サービス継続方法およびプログラム 図000009
  • 特開2017228007-サービス継続装置、サービス継続方法およびプログラム 図000010
  • 特開2017228007-サービス継続装置、サービス継続方法およびプログラム 図000011
  • 特開2017228007-サービス継続装置、サービス継続方法およびプログラム 図000012
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】特開2017-228007(P2017-228007A)
(43)【公開日】2017年12月28日
(54)【発明の名称】サービス継続装置、サービス継続方法およびプログラム
(51)【国際特許分類】
   G06F 11/07 20060101AFI20171201BHJP
   G06F 11/20 20060101ALI20171201BHJP
【FI】
   G06F11/07 193
   G06F11/07 140A
   G06F11/20 628
【審査請求】未請求
【請求項の数】5
【出願形態】OL
【全頁数】19
(21)【出願番号】特願2016-122265(P2016-122265)
(22)【出願日】2016年6月21日
(71)【出願人】
【識別番号】000004226
【氏名又は名称】日本電信電話株式会社
(74)【代理人】
【識別番号】110001807
【氏名又は名称】特許業務法人磯野国際特許商標事務所
(72)【発明者】
【氏名】北野 雄大
【テーマコード(参考)】
5B034
5B042
【Fターム(参考)】
5B034BB11
5B034BB15
5B034CC01
5B034DD02
5B034DD05
5B042GA05
5B042GA12
5B042JJ15
5B042KK04
5B042KK09
5B042KK20
5B042MA08
5B042MC09
5B042MC25
(57)【要約】
【課題】分割された複数のモジュールを組み合わせてサービスを提供するシステムにおいて、あるモジュールに障害が発生した場合においても、サービスを継続する。
【解決手段】サービス継続装置10は、呼出元モジュール、呼出先モジュール、呼出内容、応答内容および応答した回数を示すスコア、が記録される履歴記録DB130を記憶する記憶部13と、呼出先モジュールから応答を受け取り、その呼出における履歴情報を用いて、記録判断ロジックに基づき、履歴情報を記録するか否かを判定し、記録すると判定した履歴情報を履歴記録DBに記録する履歴記録部112と、障害を検出したモジュールが呼出先モジュールとなる呼出を受け取った際に、履歴記録DBを参照し、一致する履歴情報が記録されている場合であり、スコアが所定の閾値以上であるときに、履歴記録DBの応答内容を呼出元モジュールに返却する代理応答部115とを備える。
【選択図】図2
【特許請求の範囲】
【請求項1】
分割された複数のモジュールを組み合わせてサービスを提供するシステムにおいて、呼出元となる前記モジュールを示す呼出元モジュールと、呼出先となる前記モジュールを示す呼出先モジュールとの間の呼出および応答の処理を仲介するサービス継続装置であって、
前記呼出元モジュール、前記呼出先モジュール、前記呼出元モジュールからの呼出に付された呼出内容、前記呼出先モジュールからの応答に付された応答内容、および、当該呼出に対し当該応答内容により応答した回数を示すスコア、が記録される履歴記録DB(DataBase)、並びに、前記応答を代理で実行するか否かを前記スコアを用いて判定するためのスコア閾値、を記憶する記憶部と、
前記呼出元モジュールからの前記呼出内容が付された呼出を受け取り、前記呼出先モジュールに通知する呼出内容通知部と、
前記呼出先モジュールから前記呼出に対する応答を受け取り、前記呼出元モジュール、前記呼出先モジュール、前記呼出内容、および、前記応答内容を示す履歴情報を用いて、記録判断ロジックに基づき、前記履歴情報を記録するか否かを判定し、記録すると判定した履歴情報を前記履歴記録DBに記録する履歴記録部と、
複数の前記モジュールの障害を検出することにより前記モジュールの死活監視を行う死活監視部と、
前記障害を検出したモジュールが前記呼出先モジュールとなる呼出を受け取った際に、当該呼出についての、前記呼出元モジュール、前記呼出先モジュールおよび前記呼出内容を用いて前記履歴記録DBを参照し、一致する履歴情報があるか否かを判定し、一致する履歴情報が記録されている場合であり、当該履歴情報の前記スコアが前記スコア閾値以上であるときに、前記履歴記録DBの当該履歴情報で示される応答内容を、前記呼出元モジュールに返却する代理応答部と、を備え、
前記記録判断ロジックは、
前記呼出元モジュールから受け取った呼出についての、前記呼出元モジュール、前記呼出先モジュール、前記呼出内容、および、前記応答内容が前記履歴記録DBに記録された履歴情報と一致する場合に、当該呼出元モジュール、当該呼出先モジュール、当該呼出内容、および、当該応答内容を、前記履歴記録DBに記録するものとして、前記スコアをインクリメントし、前記呼出元モジュール、前記呼出先モジュールおよび前記呼出内容が一致しているが、前記応答内容が一致しない場合に、当該呼出についての、前記呼出元モジュール、前記呼出先モジュール、前記呼出内容、および、前記応答内容を、前記履歴記録DBに記録しない、というロジックであること
を特徴とするサービス継続装置。
【請求項2】
前記記憶部には、前記呼出元モジュールに対応付けて、前記代理応答部が前記履歴記録DBに記録された履歴情報で示される応答内容を前記呼出元モジュールに返却した応答回数が記録される課金DBがさらに記憶されており、
前記代理応答部が、前記障害を検出したモジュールが前記呼出先モジュールとなる呼出を受け取った際に、前記履歴記録DBに記録された履歴情報で示される応答内容を、前記呼出元モジュールに返却した場合に、応答をした回数を前記呼出元モジュールごとに前記課金DBに記録する課金処理部を、をさらに備えること
を特徴とする請求項1に記載のサービス継続装置。
【請求項3】
前記システムは、前記複数のモジュールそれぞれに対応した同一の機能を備える複数の予備モジュールを備えており、
前記サービス継続装置の代理応答部は、
前記障害を検出したモジュールが前記呼出先モジュールとなる呼出を受け取った際に、当該呼出についての、前記呼出元モジュール、前記呼出先モジュールおよび前記呼出内容を用いて前記履歴記録DBを参照し、一致する履歴情報があるか否かを判定し、一致する履歴情報が記録されていない場合、および、一致する履歴情報が記録されているが、当該履歴情報の前記スコアが前記スコア閾値未満である場合に、当該呼出を前記呼出先モジュールに対応した前記予備モジュールに通知し、当該予備モジュールから応答を受け取り、当該応答に付された応答内容を前記呼出元モジュールに返却すること
を特徴する請求項1に記載のサービス継続装置。
【請求項4】
分割された複数のモジュールを組み合わせてサービスを提供するシステムにおいて、呼出元となる前記モジュールを示す呼出元モジュールと、呼出先となる前記モジュールを示す呼出先モジュールとの間の呼出および応答の処理を仲介するサービス継続装置のサービス継続方法であって、
前記サービス継続装置は、
前記呼出元モジュール、前記呼出先モジュール、前記呼出元モジュールからの呼出に付された呼出内容、前記呼出先モジュールからの応答に付された応答内容、および、当該呼出に対し当該応答内容により応答した回数を示すスコア、が記録される履歴記録DB、並びに、前記応答を代理で実行するか否かを前記スコアを用いて判定するためのスコア閾値、を記憶部に記憶しており、
前記呼出元モジュールからの前記呼出内容が付された呼出を受け取り、前記呼出先モジュールに通知するステップと、
前記呼出先モジュールから前記呼出に対する応答を受け取り、前記呼出元モジュール、前記呼出先モジュール、前記呼出内容、および、前記応答内容を示す履歴情報を用いて、記録判断ロジックに基づき、前記履歴情報を記録するか否かを判定し、記録すると判定した履歴情報を前記履歴記録DBに記録するステップと、
複数の前記モジュールの障害を検出することにより前記モジュールの死活監視を行うステップと、
前記障害を検出したモジュールが前記呼出先モジュールとなる呼出を受け取った際に、当該呼出についての、前記呼出元モジュール、前記呼出先モジュールおよび前記呼出内容を用いて前記履歴記録DBを参照し、一致する履歴情報があるか否かを判定し、一致する履歴情報が記録されている場合であり、当該履歴情報の前記スコアが前記スコア閾値以上であるときに、前記履歴記録DBの当該履歴情報で示される応答内容を、前記呼出元モジュールに返却するステップと、を実行し、
前記記録判断ロジックは、
前記呼出元モジュールから受け取った呼出についての、前記呼出元モジュール、前記呼出先モジュール、前記呼出内容、および、前記応答内容が前記履歴記録DBに記録された履歴情報と一致する場合に、当該呼出元モジュール、当該呼出先モジュール、当該呼出内容、および、当該応答内容を、前記履歴記録DBに記録するものとして、前記スコアをインクリメントし、前記呼出元モジュール、前記呼出先モジュールおよび前記呼出内容が一致しているが、前記応答内容が一致しない場合に、当該呼出についての、前記呼出元モジュール、前記呼出先モジュール、前記呼出内容、および、前記応答内容を、前記履歴記録DBに記録しない、というロジックであること
を特徴とするサービス継続方法。
【請求項5】
分割された複数のモジュールを組み合わせてサービスを提供するシステムにおいて、呼出元となる前記モジュールを示す呼出元モジュールと、呼出先となる前記モジュールを示す呼出先モジュールとの間の呼出および応答の処理を仲介するサービス継続装置としてのコンピュータを、
前記呼出元モジュール、前記呼出先モジュール、前記呼出元モジュールからの呼出に付された呼出内容、前記呼出先モジュールからの応答に付された応答内容、および、当該呼出に対し当該応答内容により応答した回数を示すスコア、が記録される履歴記録DB、並びに、前記応答を代理で実行するか否かを前記スコアを用いて判定するためのスコア閾値、を記憶する手段、
前記呼出元モジュールからの前記呼出内容が付された呼出を受け取り、前記呼出先モジュールに通知する手段、
前記呼出先モジュールから前記呼出に対する応答を受け取り、前記呼出元モジュール、前記呼出先モジュール、前記呼出内容、および、前記応答内容を示す履歴情報を用いて、記録判断ロジックに基づき、前記履歴情報を記録するか否かを判定し、記録すると判定した履歴情報を前記履歴記録DBに記録する手段、
複数の前記モジュールの障害を検出することにより前記モジュールの死活監視を行う手段、
前記障害を検出したモジュールが前記呼出先モジュールとなる呼出を受け取った際に、当該呼出についての、前記呼出元モジュール、前記呼出先モジュールおよび前記呼出内容を用いて前記履歴記録DBを参照し、一致する履歴情報があるか否かを判定し、一致する履歴情報が記録されている場合であり、当該履歴情報の前記スコアが前記スコア閾値以上であるときに、前記履歴記録DBの当該履歴情報で示される応答内容を、前記呼出元モジュールに返却する手段、として機能させ、
前記記録判断ロジックは、
前記呼出元モジュールから受け取った呼出についての、前記呼出元モジュール、前記呼出先モジュール、前記呼出内容、および、前記応答内容が前記履歴記録DBに記録された履歴情報と一致する場合に、当該呼出元モジュール、当該呼出先モジュール、当該呼出内容、および、当該応答内容を、前記履歴記録DBに記録するものとして、前記スコアをインクリメントし、前記呼出元モジュール、前記呼出先モジュールおよび前記呼出内容が一致しているが、前記応答内容が一致しない場合に、当該呼出についての、前記呼出元モジュール、前記呼出先モジュール、前記呼出内容、および、前記応答内容を、前記履歴記録DBに記録しない、というロジックであること
として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、モジュール化されたソフトウェアを組み合わせたアプリケーションによりサービスを提供する、サービス継続装置、サービス継続方法およびプログラムに関する。
【背景技術】
【0002】
ソフトウェア開発に関するスピードの迅速化についての要望がますます強まる中、ソフトウェアを小さな単位に分割してモジュール化し、それらのモジュール化されたソフトウェアを組み合わせてアプリケーションを作り出す手法が一般的になり始めている。
例えば、非特許文献1では、単一のアプリケーションを小さなサービス群の組み合わせとして構築する手法を開示している。ただし、この手法では、アプリケーションが複数のモジュールから構成されるため、ある1つのモジュールの不具合がアプリケーション全体に影響を及ぼすことが問題となる。
【0003】
この問題を解決するため、非特許文献2に記載されたサーキットブレーカを用いた技術が知られている。この技術は、モジュール間を仲介するためのモジュール(サーキットブレーカ)を用意し、定期的に各モジュールの死活監視を行い、無応答などの不具合を検知すると、当該不具合が起こったモジュールへの呼出があった場合に、サーキットブレーカが代理でNG応答を行う技術である。
【先行技術文献】
【非特許文献】
【0004】
【非特許文献1】James Lewis, “Microservices,”[online],25 March 2014,[平成28年6月8日検索],インターネット<URL:http://martinfowler.com/articles/microservices.html>
【非特許文献2】Martin Fowler,“CircuitBreaker,” [online],6 March 2014,[平成28年6月8日検索],インターネット<URL:http://martinfowler.com/bliki/CircuitBreaker.html>
【発明の概要】
【発明が解決しようとする課題】
【0005】
非特許文献2に記載のサーキットブレーカ技術では、モジュールの不具合を発見した際に、代理でNG応答をするため、不具合時の影響を全体に波及させないようにすること(フェールセーフ)が可能である。例えば、あるモジュールが不具合の発生したモジュールを呼び出した際、応答を待ち続けることで、他のモジュールの処理も遅延し、サービスが予期しないエラーに陥るといった事象を回避できる。しかしながら、このサーキットブレーカ技術では、単純にNG応答を行うだけであるので、サービスを継続することは難しい。
【0006】
サービスを停止させないために、そのモジュールへの呼出内容とそのモジュールからの応答内容の記録をとっておいて、同じ呼出内容であれば記録されている応答内容を返却する方法が考えられる。しかしながら、モジュールによっては自身が保持している状態によって、同じ呼出内容でも異なる応答を返却する場合がある。このような状態を持つモジュール(ステートフルなモジュール)への呼出の場合、同じ呼出内容で異なる応答を返却する可能性があるため、単純に呼出内容と応答内容の記録をとって、記録されている応答内容を返却するだけでは誤った応答を返却してしまう可能性がある。
【0007】
このような点を鑑みて本発明がなされたのであり、本発明は、分割された複数のモジュールを組み合わせてサービスを提供するシステムにおいて、あるモジュールに障害が発生した場合においても、サービスを継続することができる、サービス継続装置、サービス継続方法およびプログラムを提供することを課題とする。
【課題を解決するための手段】
【0008】
前記した課題を解決するため、請求項1に記載の発明は、分割された複数のモジュールを組み合わせてサービスを提供するシステムにおいて、呼出元となる前記モジュールを示す呼出元モジュールと、呼出先となる前記モジュールを示す呼出先モジュールとの間の呼出および応答の処理を仲介するサービス継続装置であって、前記呼出元モジュール、前記呼出先モジュール、前記呼出元モジュールからの呼出に付された呼出内容、前記呼出先モジュールからの応答に付された応答内容、および、当該呼出に対し当該応答内容により応答した回数を示すスコア、が記録される履歴記録DB(DataBase)、並びに、前記応答を代理で実行するか否かを前記スコアを用いて判定するためのスコア閾値、を記憶する記憶部と、前記呼出元モジュールからの前記呼出内容が付された呼出を受け取り、前記呼出先モジュールに通知する呼出内容通知部と、前記呼出先モジュールから前記呼出に対する応答を受け取り、前記呼出元モジュール、前記呼出先モジュール、前記呼出内容、および、前記応答内容を示す履歴情報を用いて、記録判断ロジックに基づき、前記履歴情報を記録するか否かを判定し、記録すると判定した履歴情報を前記履歴記録DBに記録する履歴記録部と、複数の前記モジュールの障害を検出することにより前記モジュールの死活監視を行う死活監視部と、前記障害を検出したモジュールが前記呼出先モジュールとなる呼出を受け取った際に、当該呼出についての、前記呼出元モジュール、前記呼出先モジュールおよび前記呼出内容を用いて前記履歴記録DBを参照し、一致する履歴情報があるか否かを判定し、一致する履歴情報が記録されている場合であり、当該履歴情報の前記スコアが前記スコア閾値以上であるときに、前記履歴記録DBの当該履歴情報で示される応答内容を、前記呼出元モジュールに返却する代理応答部と、を備え、前記記録判断ロジックは、前記呼出元モジュールから受け取った呼出についての、前記呼出元モジュール、前記呼出先モジュール、前記呼出内容、および、前記応答内容が前記履歴記録DBに記録された履歴情報と一致する場合に、当該呼出元モジュール、当該呼出先モジュール、当該呼出内容、および、当該応答内容を、前記履歴記録DBに記録するものとして、前記スコアをインクリメントし、前記呼出元モジュール、前記呼出先モジュールおよび前記呼出内容が一致しているが、前記応答内容が一致しない場合に、当該呼出についての、前記呼出元モジュール、前記呼出先モジュール、前記呼出内容、および、前記応答内容を、前記履歴記録DBに記録しない、というロジックであることを特徴とするサービス継続装置とした。
【0009】
請求項4に記載の発明は、分割された複数のモジュールを組み合わせてサービスを提供するシステムにおいて、呼出元となる前記モジュールを示す呼出元モジュールと、呼出先となる前記モジュールを示す呼出先モジュールとの間の呼出および応答の処理を仲介するサービス継続装置のサービス継続方法であって、前記サービス継続装置が、前記呼出元モジュール、前記呼出先モジュール、前記呼出元モジュールからの呼出に付された呼出内容、前記呼出先モジュールからの応答に付された応答内容、および、当該呼出に対し当該応答内容により応答した回数を示すスコア、が記録される履歴記録DB、並びに、前記応答を代理で実行するか否かを前記スコアを用いて判定するためのスコア閾値、を記憶部に記憶しており、前記呼出元モジュールからの前記呼出内容が付された呼出を受け取り、前記呼出先モジュールに通知するステップと、前記呼出先モジュールから前記呼出に対する応答を受け取り、前記呼出元モジュール、前記呼出先モジュール、前記呼出内容、および、前記応答内容を示す履歴情報を用いて、記録判断ロジックに基づき、前記履歴情報を記録するか否かを判定し、記録すると判定した履歴情報を前記履歴記録DBに記録するステップと、複数の前記モジュールの障害を検出することにより前記モジュールの死活監視を行うステップと、前記障害を検出したモジュールが前記呼出先モジュールとなる呼出を受け取った際に、当該呼出についての、前記呼出元モジュール、前記呼出先モジュールおよび前記呼出内容を用いて前記履歴記録DBを参照し、一致する履歴情報があるか否かを判定し、一致する履歴情報が記録されている場合であり、当該履歴情報の前記スコアが前記スコア閾値以上であるときに、前記履歴記録DBの当該履歴情報で示される応答内容を、前記呼出元モジュールに返却するステップと、を実行し、前記記録判断ロジックは、前記呼出元モジュールから受け取った呼出についての、前記呼出元モジュール、前記呼出先モジュール、前記呼出内容、および、前記応答内容が前記履歴記録DBに記録された履歴情報と一致する場合に、当該呼出元モジュール、当該呼出先モジュール、当該呼出内容、および、当該応答内容を、前記履歴記録DBに記録するものとして、前記スコアをインクリメントし、前記呼出元モジュール、前記呼出先モジュールおよび前記呼出内容が一致しているが、前記応答内容が一致しない場合に、当該呼出についての、前記呼出元モジュール、前記呼出先モジュール、前記呼出内容、および、前記応答内容を、前記履歴記録DBに記録しない、というロジックであることを特徴とするサービス継続方法とした。
【0010】
請求項5に記載の発明は、分割された複数のモジュールを組み合わせてサービスを提供するシステムにおいて、呼出元となる前記モジュールを示す呼出元モジュールと、呼出先となる前記モジュールを示す呼出先モジュールとの間の呼出および応答の処理を仲介するサービス継続装置としてのコンピュータを、前記呼出元モジュール、前記呼出先モジュール、前記呼出元モジュールからの呼出に付された呼出内容、前記呼出先モジュールからの応答に付された応答内容、および、当該呼出に対し当該応答内容により応答した回数を示すスコア、が記録される履歴記録DB、並びに、前記応答を代理で実行するか否かを前記スコアを用いて判定するためのスコア閾値、を記憶する手段、前記呼出元モジュールからの前記呼出内容が付された呼出を受け取り、前記呼出先モジュールに通知する手段、前記呼出先モジュールから前記呼出に対する応答を受け取り、前記呼出元モジュール、前記呼出先モジュール、前記呼出内容、および、前記応答内容を示す履歴情報を用いて、記録判断ロジックに基づき、前記履歴情報を記録するか否かを判定し、記録すると判定した履歴情報を前記履歴記録DBに記録する手段、複数の前記モジュールの障害を検出することにより前記モジュールの死活監視を行う手段、前記障害を検出したモジュールが前記呼出先モジュールとなる呼出を受け取った際に、当該呼出についての、前記呼出元モジュール、前記呼出先モジュールおよび前記呼出内容を用いて前記履歴記録DBを参照し、一致する履歴情報があるか否かを判定し、一致する履歴情報が記録されている場合であり、当該履歴情報の前記スコアが前記スコア閾値以上であるときに、前記履歴記録DBの当該履歴情報で示される応答内容を、前記呼出元モジュールに返却する手段、として機能させ、前記記録判断ロジックは、前記呼出元モジュールから受け取った呼出についての、前記呼出元モジュール、前記呼出先モジュール、前記呼出内容、および、前記応答内容が前記履歴記録DBに記録された履歴情報と一致する場合に、当該呼出元モジュール、当該呼出先モジュール、当該呼出内容、および、当該応答内容を、前記履歴記録DBに記録するものとして、前記スコアをインクリメントし、前記呼出元モジュール、前記呼出先モジュールおよび前記呼出内容が一致しているが、前記応答内容が一致しない場合に、当該呼出についての、前記呼出元モジュール、前記呼出先モジュール、前記呼出内容、および、前記応答内容を、前記履歴記録DBに記録しない、というロジックであること、として機能させるためのプログラムとした。
【0011】
このようにすることで、サービス継続装置等によれば、記録判定ロジックにより、呼出元モジュール、呼出先モジュールおよび呼出内容が一致していても、応答内容が異なる履歴情報については、履歴記録DBに記録しないようにすることができる。つまり、ステートフルなモジュールからの応答については、履歴記録DBに記録しないようにする。一方、状態を持たないモジュール(ステートレスなモジュール)に障害が発生した場合においては、サービス継続装置の履歴記録DBに記録された応答内容を用いて代理で応答することが可能となり、サービスを継続することが可能となる。
【0012】
また、請求項2に記載の発明は、前記記憶部には、前記呼出元モジュールに対応付けて、前記代理応答部が前記履歴記録DBに記録された履歴情報で示される応答内容を前記呼出元モジュールに返却した応答回数が記録される課金DBがさらに記憶されており、前記代理応答部が、前記障害を検出したモジュールが前記呼出先モジュールとなる呼出を受け取った際に、前記履歴記録DBに記録された履歴情報で示される応答内容を、前記呼出元モジュールに返却した場合に、応答をした回数を前記呼出元モジュールごとに前記課金DBに記録する課金処理部を、をさらに備えることを特徴とする請求項1に記載のサービス継続装置とした。
【0013】
このように、サービス継続装置によれば、障害が発生した呼出先モジュールの代わりに応答した回数を課金DBに記録することができる。よって、課金DBに記録された応答回数に応じて、各モジュールの管理者に課金することができる。
【0014】
また、請求項3に記載の発明は、前記システムは、前記複数のモジュールそれぞれに対応した同一の機能を備える複数の予備モジュールを備えており、前記サービス継続装置の代理応答部が、前記障害を検出したモジュールが前記呼出先モジュールとなる呼出を受け取った際に、当該呼出についての、前記呼出元モジュール、前記呼出先モジュールおよび前記呼出内容を用いて前記履歴記録DBを参照し、一致する履歴情報があるか否かを判定し、一致する履歴情報が記録されていない場合、および、一致する履歴情報が記録されているが、当該履歴情報の前記スコアが前記スコア閾値未満である場合に、当該呼出を前記呼出先モジュールに対応した前記予備モジュールに通知し、当該予備モジュールから応答を受け取り、当該応答に付された応答内容を前記呼出元モジュールに返却することを特徴する請求項1に記載のサービス継続装置とした。
【0015】
このようにすることで、サービス継続装置によれば、記録判定ロジックにより、呼出元モジュール、呼出先モジュールおよび呼出内容が一致していても、応答内容が異なる履歴情報については、予備モジュールにその呼出を通知して応答を取得し、呼出元モジュールに返却することができる。よって、ステートフルなモジュールに障害が発生した場合においても、確実にサービスを継続することが可能となる。
【発明の効果】
【0016】
本発明によれば、分割された複数のモジュールを組み合わせてサービスを提供するシステムにおいて、あるモジュールに障害が発生した場合においても、サービスを継続する、サービス継続装置、サービス継続方法およびプログラムを提供することができる。
【図面の簡単な説明】
【0017】
図1】本実施形態に係るサービス継続装置を含むサービスシステムの構成を示す図である。
図2】本実施形態に係るサービス継続装置の構成例を示す機能ブロック図である。
図3】本実施形態に係る履歴記録DBに記録される履歴情報のデータ構成を示す図である。
図4】記録判断ロジックにより設定される処理の流れを示すフローチャートである。
図5】本実施形態に係るサービス継続装置を含むサービスシステムの処理を示すシーケンス図である。
図6】本実施形態の変形例1に係るサービス継続装置の構成例を示す機能ブロック図である。
図7】本実施形態の変形例1に係る課金DBに記録される課金情報のデータ構成を示す図である。
図8】本実施形態の変形例2に係るサービス継続装置を含むサービスシステムの構成を示す図である。
図9】本実施形態の変形例2に係るサービス継続装置の構成例を示す機能ブロック図である。
図10】本実施形態の変形例2に係るサービス継続装置を含むサービスシステムの処理を示すシーケンス図である。
【発明を実施するための形態】
【0018】
次に、本発明を実施するための形態(以下、「本実施形態」と称する。)における、サービス継続装置10等について説明する。
【0019】
<概要>
まず、本実施形態に係るサービス継続装置10(後記する図1図2参照)が実行する処理の概要について説明する。
本実施形態に係るサービス継続装置10は、複数のモジュールによる処理を実行してサービスを提供する際に、そのモジュール間を仲介する処理を実行する。具体的には、各モジュール間では、呼出・応答に関する送受信は直接には行わず、サービス継続装置10を介して行う。また、サービス継続装置10は、モジュール間の呼出内容および応答内容に関する情報を、記録判断ロジック(後記する図4参照)に従い、キャッシュとして記録するか判断した上で、履歴情報として記録しておく(後記する図3の「履歴記録DB(DataBase)130」)。この記録判断ロジックは、状態を持つモジュール「以下、「ステートフルなモジュール」と称する。)と、状態を持たないモジュール(以下、「ステートレスなモジュール」と称する。)とを区別するための判断ロジックであり、ステートレスなモジュールからの呼出・応答に関する履歴情報を記録する。
そして、サービス継続装置10は、あるモジュールについて障害の発生を検知した場合に、そのモジュールについて呼出があったときには、記録されている履歴情報の中に、同じ呼出内容が記録されているか否かを確認し、記録されている場合において、後記する所定の条件(「スコアが所定の閾値以上」の場合)を満たすときに、履歴情報で示される応答内容を返却する。
【0020】
このようにすることで、本実施形態に係るサービス継続装置10によれば、ステートフルなモジュールとステートレスなモジュールとが混在する場合であっても、記録判断ロジックに基づき判定することにより、ステートフルなモジュールからの応答内容は記録せず、ステートレスなモジュールからの応答内容を記録する可能性を高めることができる。そのため、モジュールに障害が発生したときにも、誤った応答内容を返却することなく、サービスを継続することができる。
【0021】
<システム構成>
次に、本実施形態に係るサービス継続装置10を含むサービスシステムの構成について説明する。
図1は、本実施形態に係るサービス継続装置10を含むサービスシステムの構成を示す図である。
本実施形態に係るサービスシステムでは、複数のデータセンタ100(「1」…「N」)がネットワークを介して接続される。また、各データセンタ100には、サーバ20が設置される。サーバ20は、ソフトウェアを小さな単位に分割したモジュール2を備える。図1においては、データセンタ「1」内に、サーバ「1」,「2」が設置され、サーバ「1」がモジュール「1」,「2」を備え、サーバ「2」がモジュール「3」を備える例を示している。なお、以後、モジュール2の総称として符号「2」を付し、個別のモジュール2を識別する場合は、モジュール「1」、モジュール「2」、モジュール「3」等として表記する。
【0022】
また、サービスシステム内には、サービス継続装置10が備えられる。このサービス継続装置10は、ネットワークを介して、各サーバ20と接続される。図1において、サービス継続装置10は、データセンタ「1」内に設置される例を示しているが、これに限定されず、他のデータセンタ100の何れかに設置されてもよいし、データセンタ100の外部に、ネットワークに接続された上で、単独で設置されてもよい。
【0023】
このサービスシステムにおけるサービスの提供は、各サーバ20内のモジュール2の処理を組み合わせることにより行われる。その際に、複数のモジュール2間の呼出・応答に関する送受信は、サービス継続装置10を介して行う。
【0024】
サービス継続装置10は、複数のモジュール2間の呼出・応答に関する仲介を行うモジュール仲介部11を備え、モジュール間の呼出内容および応答内容に関する情報を、記録判断ロジックに従い履歴記録DB130(図3参照)に記録しておく。そして、サービス継続装置10は、障害が発生したモジュール2への呼出があった場合には、履歴記録DB130を参照し、記録されている履歴情報の中に、同じ呼出内容が記録されているか否かを確認し、記録されている場合において、所定の条件(「スコアが所定の閾値以上」)を満たすときに、履歴情報で示される応答内容を返却する。
以下、サービス継続装置10について詳細に説明する。
【0025】
<サービス継続装置の構成>
次に、本実施形態に係るサービス継続装置10の構成について説明する。
図2は、本実施形態に係るサービス継続装置10の構成例を示す機能ブロック図である。
サービス継続装置10は、図2に示すように、モジュール仲介部11の機能を含む制御部(図示省略)と、入出力部12と、記憶部13とを含んで構成される。
【0026】
入出力部12は、ネットワークを介して通信接続される、各サーバ20に備わるモジュール2等との間の情報の入出力を行う。また、入出力部12は、通信回線を介して情報の送受信を行う不図示の通信インタフェースと、キーボード等の入力手段やモニタ等の出力手段(いずれも不図省略)との間で入出力を行う入出力インタフェースとから構成される。
【0027】
記憶部13は、ハードディスクやフラッシュメモリ、RAM(Random Access Memory)等により構成される。
この記憶部13には、後記する履歴記録DB130(図3)や、スコア閾値140等が記憶されるとともに、制御部(モジュール仲介部11)の各機能を実行させるためのプログラムや、制御部の処理に必要な情報が一時的に記憶される。
【0028】
制御部(モジュール仲介部11)は、サービス継続装置10全体の制御を司り、呼出内容通知部111と、履歴記録部112と、応答内容返却部113と、死活監視部114と、代理応答部115とを含んで構成される。
また、この制御部は、例えば、記憶部13に格納されたプログラムを不図示のCPU(Central Processing Unit)がRAMに展開し実行することで実現される。
【0029】
呼出内容通知部111は、あるモジュール2(呼出元モジュール)から他のモジュール2(呼出先モジュール)への要求(呼出内容が付された呼出)を受け取る。そして、呼出内容通知部111は、その要求(呼出)を、呼出先となるモジュール2へ通知する。
また、呼出内容通知部111は、呼出元モジュールから呼出先モジュールへの要求(呼出)を受け取った際に、その呼出先モジュールに障害が発生している旨の情報を、死活監視部114から受け取っていた場合には、その要求(呼出)を代理応答部115に出力する。
【0030】
履歴記録部112は、呼出内容通知部111が要求を通知した呼出先モジュールからの応答を受け取る。この呼出先モジュールからの応答には、どの要求(呼出)に対する応答であるのかを紐付けるために、シーケンス番号や、呼出元モジュールのID・呼出内容などの要求(呼出)を識別する情報が、その応答内容に含まれる。そして、履歴記録部112は、呼出先モジュールからの応答に対応する要求(呼出)を特定した上で、記録判断ロジックに従い、その応答に付された応答内容を含む情報を履歴情報として履歴記録DB130に記録するか否かを判定する。そして、履歴記録部112は、記録すべきと判定した場合には、図3に示す履歴記録DB130に、履歴情報として記録する。
【0031】
図3は、本実施形態に係る履歴記録DB130に記録される履歴情報のデータ構成を示す図である。
図3に示すように、履歴記録DB130には、呼出元モジュール131、呼出先モジュール132、呼出内容133、応答内容134、スコア135の各項目が履歴情報として格納される。
【0032】
呼出元モジュール131には、サービス継続装置10が受信した要求の呼出元のモジュール2の識別子が格納される。例えば、図3に示すように、呼出元モジュール131に、呼出元であるモジュール2の識別子「3」が格納される。
呼出先モジュール132には、受信した要求の呼出先となるモジュール2の識別子が格納される。例えば、図3に示すように、呼出先モジュール132に、呼出先となるモジュール2の識別子「1」が格納される。
【0033】
呼出内容133には、呼出元モジュールからの要求に付された呼出内容が格納される。例えば、図3に示すように、呼出内容133として「GET/index.html」が格納される。
応答内容134には、呼出先モジュールからの応答に付された応答内容が格納される。
例えば、図3に示すように、応答内容134として「HTTP/1.1 200OK hoge」が格納される。
【0034】
スコア135には、呼出元モジュール131、その呼出元モジュールからの要求に付された呼出内容133、呼出先モジュール132、その呼出先モジュールからの応答に付された応答内容134の各情報について、履歴記録部112が記録判断ロジックに基づき、同一の履歴情報であると判断した回数が格納される。
図3に示す例では、呼出元モジュール131が「3」、呼出先モジュール132が「1」、呼出内容133が「GET/index.html」、応答内容134が「HTTP/1.1 200OK hoge」である処理が「323(回)」あったことを示している。
【0035】
次に、履歴記録部112が、履歴記録DB130に記録するか否かの判定に用いる記録判断ロジックについて説明する。
図4は、記録判断ロジックにより設定される処理の流れを示すフローチャートである。
履歴記録部112は、呼出内容通知部111が呼出先モジュールへの要求の通知に際して取得した、呼出元モジュールと呼出内容の情報と、呼出先モジュールから受信した応答に付された、呼出先モジュールと応答内容の情報とに基づき、当該応答を受信した際に、以下の記録判断ロジックに基づく処理(ステップS1〜S5)を実行する。
【0036】
まず、履歴記録部112は、呼出先モジュールから受信した応答に関する、呼出元モジュール、呼出先モジュール、呼出内容について、履歴記録DB130(図3)の中に、これらの情報のすべてが一致するレコード(履歴情報)があるか否かを判定する(ステップS1)。
そして、履歴記録部112は、これらの情報のすべてが一致するレコードがない場合に(ステップS1→No)、新たなレコード(履歴情報)として、呼出先モジュール、呼出元モジュール、呼出内容、および、その応答内容を、履歴記録DB130に格納した上で、スコア135を「1」とする(ステップS2)。
一方、ステップS1において、すべて一致するレコードがある場合には(ステップS1→Yes)、履歴記録部112は、ステップS3に進む。
【0037】
ステップS3において、履歴記録部112は、履歴記録DB130の中に、呼出元モジュール、呼出先モジュール、呼出内容、応答内容のすべてが一致するレコードがあるか否かを判定する。そして、すべてが一致するレコードがない場合には(ステップS3→No)、ステップS4に進む。
【0038】
ステップS4において、履歴記録部112は、判定対象とした情報である、呼出元モジュール、呼出先モジュール、呼出内容、応答内容について履歴記録DB130にレコードとして記録しないことを決定する。また、履歴記録部112は、ステップS1において、呼出元モジュール、呼出先モジュール、呼出内容が一致したレコードについて、履歴記録DB130から削除する処理を実行する。
【0039】
一方、ステップS3において、すべてが一致するレコードがある場合には(ステップS3→Yes)、履歴記録部112は、当該レコードのスコア135をインクリメントする(ステップS5)。そして、記録判断ロジックの処理を終了する。
【0040】
図2に戻り、応答内容返却部113は、履歴記録部112による記録判断ロジックの処理が終了すると、呼出先モジュールから受信した応答を、呼出元モジュールに返却する。
【0041】
死活監視部114は、所定の時間間隔で、各モジュール2に対し、死活確認要求を送信し、その応答情報を受信する等により、各モジュール2の死活監視を行う。
死活監視部114は、各モジュール2の死活監視により、あるモジュール2についての障害の発生を検出した場合には、その障害発生情報を呼出内容通知部111に出力する。
【0042】
代理応答部115は、呼出内容通知部111からの出力に基づく、障害が発生した呼出先モジュールに向けての要求から、その呼出元モジュールおよび呼出内容を抽出し、履歴記録DB130(図3)の中で、その呼出元モジュール、呼出先モジュール、呼出内容が一致するレコードが記録されているか否かを確認する。そして、代理応答部115は、記録されている場合、そのレコードのスコア135が、記憶部13に予め設定されているスコア閾値140以上であるか否かを判定する。代理応答部115は、スコア135の値がスコア閾値140以上である場合には、そのレコードで示される応答内容134を、呼出元モジュールに返却する。
一方、代理応答部115は、履歴記録DB130に、呼出元モジュール、呼出先モジュール、呼出内容が一致するレコードが記録されていない場合、記録されている場合であっても、スコア135の値がスコア閾値140未満であるときには、NG応答を呼出元モジュールに返却する。
【0043】
≪処理の流れ≫
次に、本実施形態に係るサービス継続装置10を含むサービスシステムが実行する処理の流れについて説明する。
図5は、本実施形態に係るサービス継続装置10を含むサービスシステムの処理を示すシーケンス図である。なお、サービス継続装置10の記憶部13には、予めスコア閾値140(ここでは、「300」とする。)が登録されているものとする。
【0044】
まず、各モジュール2に障害が発生する前(通常時)における処理(ステップS10〜S14)を説明する。
図5に示すように、例えば、モジュール「3」(呼出元モジュール)からの要求(GET/index.html)をサービス継続装置10が受信する(ステップS10)。
続いて、サービス継続装置10の呼出内容通知部111が、その要求(GET/index.html)を、呼出先モジュールであるモジュール「1」に通知する(ステップS11)。
【0045】
次に、サービス継続装置10は、呼出先モジュールであるモジュール「1」からの応答(HTTP/1.1 200OK hoge)を受信する(ステップS12)。
サービス継続装置10の履歴記録部112は、呼出先モジュール(モジュール「1」)からの応答(HTTP/1.1 200OK hoge)を受け取ると、図4に示した記録判断ロジックに従い、その応答に付された応答内容を含む情報を履歴情報として履歴記録DB130に記録するか否かを判定する(ステップS13)。
【0046】
ここでは、図4に示す記録判断ロジックの処理において、ステップS1において、呼出元モジュール、呼出先モジュール、呼出内容が、モジュール「3」、モジュール「1」、(GET/index.html)であるものと一致するレコード(履歴情報)が履歴記録DB130に記録されており(図4のステップS1→Yes)、さらに、図4のステップS3において、応答内容も(HTTP/1.1 200OK hoge)と一致するレコードが履歴記録DB130にあるものとする(図4のステップS3→Yes)。この場合、履歴記録部112は、一致するレコードのスコア135をインクリメントする(図4のステップS5)。このインクリメントした結果の状態が、図3に示す状態であるとして、以下において説明する。
【0047】
次に、サービス継続装置10の応答内容返却部113は、呼出先モジュール(モジュール「1」)から受信した応答(HTTP/1.1 200OK hoge)を、呼出元モジュールに返却する(ステップS14)。
【0048】
上記の通常時の処理において、サービス継続装置10は、モジュール2間の呼出・応答に伴い、随時、履歴記録DB130を更新する。また、サービス継続装置10は、各モジュール2の死活監視を実行する。
サービス継続装置10の死活監視部114は、所定の時間間隔で、各モジュール2に対し、死活確認要求を送信する(ステップS20)。なお、ここでは、モジュール「1」に障害が発生したものとする。
死活監視部114は、モジュール「2」,「3」からは死活確認要求に対する応答情報を受信するが(ステップS21)、モジュール「1」からは応答情報を受信することができない。これにより、死活監視部114は、モジュール「1」に障害が発生したことを検出する(ステップS22)。そして、死活監視部114は、モジュール「1」に障害が発生した旨を呼出内容通知部111に出力する。
【0049】
この状態において、サービス継続装置10がモジュール「3」(呼出元モジュール)からモジュール「1」への要求(GET/index.html)を受信する(ステップS30)。
この場合、サービス継続装置10の呼出内容通知部111は、モジュール「1」に障害が発生しているため、その要求を、代理応答部115に出力する。
【0050】
サービス継続装置10の代理応答部115は、その要求に付された、送信元モジュール(モジュール「3」)、送信先モジュール(モジュール「1」)、呼出内容(GET/index.html)を用いて、履歴記録DB130を検索し、これらの情報が一致するレコードが記録されているか否かを確認する(ステップS31)。
そして、代理応答部115は、記録されている場合には、そのレコードのスコア135の値が、スコア閾値140(「300」)以上であるか否かを判定する。
ここでは、図3に示す履歴記録DB130の1行目に示すレコードのスコア135の値が「323」であるので、代理応答部115は、スコア閾値140(「300」)以上であると判定する。
そして、代理応答部115は、当該レコードに記録された応答内容134(ここでは、「HTTP/1.1 200OK hoge」)を、送信元モジュール(モジュール「3」)に返却する(ステップS32:代理応答)。
【0051】
次に、サービス継続装置10がモジュール「2」(呼出元モジュール)からモジュール「1」への要求(GETID user1)を受信する(ステップS40)。
この場合も、サービス継続装置10の呼出内容通知部111は、モジュール「1」に障害が発生しているため、その要求を、代理応答部115に出力する。
【0052】
サービス継続装置10の代理応答部115は、その要求に付された、送信元モジュール(モジュール「2」)、送信先モジュール(モジュール「1」)、呼出内容(GETID user1)を用いて、履歴記録DB130を検索し、これらの情報が一致するレコードが記録されているか否かを確認する(ステップS41)。
そして、代理応答部115は、記録されている場合には、そのレコードのスコア135の値が、スコア閾値140(「300」)以上であるか否かを判定する。
ここでは、図3に示す履歴記録DB130の2行目に示すレコードのスコア135の値が「5」であるので、代理応答部115は、スコア閾値140(「300」)以上ではないと判定する。
そして、代理応答部115は、送信元モジュール(モジュール「2」)にNG応答を返却する(ステップS42)。
【0053】
このようにすることで、本実施形態に係るサービス継続装置10等によれば、記録判定ロジックにより、ステートレスなモジュール2からの応答内容を履歴記録DB130に確実に記録しておくことができる。よって、ステートレスなモジュール2に障害が発生した場合において、サービス継続装置10が代理で応答することができるため、サービスを継続することが可能となる。
【0054】
<本実施形態の変形例1>
次に、本実施形態に係るサービス継続装置10の変形例1について説明する。
本実施形態の変形例1に係るサービス継続装置10A(10)は、課金DB150(後記する、図6図7参照)を備える。そして、サービス継続装置10A(10)が、履歴記録DB130に記録されている情報を用いて、送信元モジュールに代理で応答した場合に、課金DBへの記録を行うことを特徴とする。
【0055】
図6は、本実施形態の変形例1に係るサービス継続装置10A(10)の構成例を示す機能ブロック図である。
図2に示した本実施形態に係るサービス継続装置10と比べ、記憶部13に課金DB150を備えるとともに、制御部(モジュール仲介部11)内に、課金処理部116を備える点が異なる。なお、図2で示す構成と同じ機能を備える構成については、同一の名称と符号を付し、説明を省略する。
【0056】
課金処理部116は、代理応答部115の処理を監視し、代理応答部115が、障害が発生した呼出先モジュールについて、履歴記録DB130を検索し、スコア135の値がスコア閾値140以上の履歴情報について、応答内容を代理で返却した場合に、課金DB150に記録を行う。
【0057】
図7は、本実施形態の変形例1に係る課金DB150に記録される課金情報のデータ構成を示す図である。
図7に示すように、課金DB150には、呼出元モジュール151、管理者ID152および応答回数153の各項目が課金情報として格納される。
【0058】
呼出元モジュール151には、サービス継続装置10が受信した要求の呼出元のモジュール2の識別子が格納される。この呼出元モジュール151は、図3の履歴記録DB130における呼出元モジュール131と同様の情報である。
管理者ID152には、呼出元モジュール151を管理する管理者の識別子が格納される。例えば、呼出元モジュール151が「3」のモジュール2を管理する管理者の管理者ID152として「#0003」が格納される。
【0059】
応答回数153には、代理応答部115が、履歴記録DB130に記録された応答内容134を用いて、障害が発生した呼出先モジュールの代わりに応答した回数が格納される。例えば、図7に示す例では、呼出元モジュール151に対して、障害が発生した呼出先モジュールの代わりに「45(回)」応答したことが格納される。
【0060】
このように、本実施形態の変形例1に係るサービス継続装置10A(10)によれば、代理応答部115が、障害が発生した呼出先モジュールの代わりに応答した回数を課金DB150に記録することができる。よって、サービス継続装置10A(10)の課金DB150に記録された応答回数153に応じて、各モジュール2の管理者に課金することができる。
【0061】
<本実施形態の変形例2>
次に、本実施形態に係るサービス継続装置10の変形例2について説明する。
図8は、本実施形態の変形例2に係るサービス継続装置10B(10)を含むサービスシステムの構成を示す図である。
図8に示すサービスシステムでは、図1に示したサービスシステムに加え、データセンタ「2」内に、予備モジュール2B(2)を備えることを特徴する。この予備モジュール2B(2)は、データセンタ「1」等に備わるモジュール2それぞれに対応する予備のモジュールである。つまり、モジュール2と予備モジュール2B(2)とは、同一の処理を実行する機能を有する。図8では、モジュール「1」「2」「3」のそれぞれに対応する予備モジュール「1」「2」「3」が、データセンタ「2」のサーバ「3」に備わる例を示している。ただし、この予備モジュール2B(2)それぞれは、1つのデータセンタ100内に備わることに限定されず、複数のデータセンタ100内に備わる構成でもよい。また、図8に示すように、1つのサーバ20(ここでは、サーバ「3」)内にすべての予備モジュール2B(2)が格納されることに限定されず、複数のサーバ20に分散して格納されていてもよい。
【0062】
本実施形態の変形例2に係るサービス継続装置10B(10)は、図9に示すように、モジュール仲介部11B(11)を備える。このモジュール仲介部11B(11)は、図2に示すサービス継続装置10の代理応答部115とは異なる代理応答部115B(115)を有する。なお、図2で示す構成と同じ機能を備える構成については、図9においても、同一の名称と符号を付し、説明を省略する。
【0063】
代理応答部115B(115)は、図2に示す本実施形態の代理応答部115と同様に、障害が発生した呼出先モジュールに向けての要求に基づき、その呼出元モジュールおよび呼出内容を抽出し、履歴記録DB130(図3参照)の中で、その呼出元モジュール、呼出先モジュール、呼出内容が一致するレコードが格納されているか否かを確認する。そして、代理応答部115B(115)は、記録されている場合、そのレコードのスコア135が、記憶部13に予め設定されているスコア閾値140以上であるか否かを判定する。代理応答部115は、スコア135の値がスコア閾値140以上である場合には、そのレコードで示される応答内容134を、呼出元モジュールに返却する。
【0064】
一方、代理応答部115B(115)は、履歴記録DB130に、呼出元モジュール、呼出先モジュール、呼出内容が一致するレコードが記録されていない場合、記録されている場合であっても、スコア135の値がスコア閾値140未満であるときには、障害が発生した呼出先モジュールに対応する予備モジュール2B(2)に対して、要求を送信する。そして、代理応答部115B(115)は、呼出先モジュールに対応する予備モジュール2B(2)から応答を取得し、その応答を呼出元モジュールに返却する。
【0065】
≪処理の流れ≫
次に、本実施形態の変形例2に係るサービス継続装置10B(10)を含むサービスシステムが実行する処理の流れについて説明する。
図10は、本実施形態の変形例2に係るサービス継続装置10B(10)を含むサービスシステムの処理を示すシーケンス図である。なお、サービス継続装置10B(10)の記憶部13には、予めスコア閾値140(ここでは、「300」とする。)が登録されているものとする。また、図5のステップS10〜S14に示す通常時の処理により、サービス継続装置10B(10)は、モジュール2間の呼出・応答に伴い、随時、履歴記録DB130を更新している。そして、サービス継続装置10B(10)は、各モジュール2の死活監視を実行することにより(ステップS20〜S22)、モジュール「1」の障害を検出したものとする。ここでは、ステップS22でのモジュール「1」の障害発生の検出後に、サービス継続装置10B(10)の履歴記録DB130に記録されている履歴情報が、図3に示す状態であるとして説明する。
【0066】
ステップS22の後、サービス継続装置10B(10)が、モジュール「2」(呼出元モジュール)からモジュール「1」(送信先モジュール)への要求(GETID user1)を受信する(ステップS50)。
この場合、サービス継続装置10B(10)の呼出内容通知部111は、モジュール「1」に障害が発生しているため、その要求を、代理応答部115B(115)に出力する。
【0067】
サービス継続装置10B(10)の代理応答部115B(115)は、その要求に付された、送信元モジュール(モジュール「2」)、送信先モジュール(モジュール「1」)、呼出内容(GETID user1)を用いて、履歴記録DB130(図3)を検索し、これらの情報が一致するレコードが記録されているか否かを確認する(ステップS51)。
【0068】
そして、代理応答部115B(115)は、記録されている場合には、そのレコードのスコア135の値が、スコア閾値140(「300」)以上であるか否かを判定する。
ここでは、図3に示す履歴記録DB130の2行目に示すレコードのスコア135の値が「5」であるので、代理応答部115B(115)は、スコア閾値140(「300」)以上ではないと判定する。
【0069】
続いて、代理応答部115B(115)は、障害が発生した呼出先モジュールに対応する予備モジュール2B(2)に対して、要求を送信する(ステップS52)。ここでは、代理応答部115B(115)は、障害が発生した呼出先となるモジュール「1」に対応する予備モジュール「1」に、要求(GETID user1)を送信する。
【0070】
そして、サービス継続装置10B(10)の代理応答部115B(115)は、予備モジュール「1」から応答(「1018714」)を受信する(ステップS53)。
次に、代理応答部115B(115)は、受信した応答(「1018714」)を、呼出元モジュール(モジュール「2」)に返却する(ステップS54)。
【0071】
このようにすることで、本実施形態の変形例2に係るサービス継続装置10B(10)は、ステートフルなモジュール2とステートレスなモジュール2とが混在する場合であっても、記録判定ロジックにより、ステートレスなモジュール2からの応答内容を履歴記録DB130に確実に記録しておくことができる。よって、ステートレスなモジュール2に障害が発生した場合においては、サービス継続装置10B(10)が代理で応答することができる。また、サービス継続装置10B(10)は、ステートフルなモジュール2に障害が発生した場合において、予備モジュール2B(2)から応答を取得して、呼出元モジュールに返却することができる。よって、本実施形態の変形例2に係るサービス継続装置10B(10)によれば、モジュール2に障害が発生した場合において、より確実にサービスを継続することが可能となる。
【符号の説明】
【0072】
2 モジュール
2B 予備モジュール
10,10A,10B サービス継続装置
11,11B モジュール仲介部
12 入出力部
13 記憶部
100 データセンタ
111 呼出内容通知部
112 履歴記録部
113 応答内容返却部
114 死活監視部
115,115B 代理応答部
116 課金処理部
130 履歴記録DB
140 スコア閾値
150 課金DB
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10