JP6927552B2 - 情報処理装置、リソース管理方法及びリソース管理プログラム - Google Patents

Description

本発明は、情報処理装置、リソース管理方法及びリソース管理プログラムに関し、特に、サービスバスを介して提供されるサービスに用いられるリソースの管理を行う情報処理装置、リソース管理方法及びリソース管理プログラムに関する。

近年、ＳａａＳ（Software as a Service）やＰａａＳ（Platform as a Service）と呼ばれるクラウドコンピューティングを用いたサービスの利用が進んでいる。このようなサービスは仮想化技術を使用して構築されていることが多く、ユーザは利用したいときに利用したいだけのリソースを確保してサービスを利用することができる。クラウドコンピューティング環境のサービスは、ＣＰＵ（Central Processing Unit）時間やストレージの容量などの利用度に応じて課金を行う従量課金体系をとることがあり、課金額を極力抑えるために効率的なリソース利用が求められている。

特許文献１には、クラウド上のアプリケーション・リソース・マネージャに関する技術について開示されている。特許文献１にかかるアプリケーション・リソース・マネージャは、クラウド上で動作するアプリケーションに対する今後の需要の予測を取得し、予測に基づいてクラウドのリソースの拡張及び縮小を実行する。

特許文献２には、サービスバス装置内の負荷分散に関する技術が開示されている。特許文献２にかかるサービスバス装置は、外部サービスからのメッセージを受け付けるマスタと、マスタから転送されるメッセージを処理する複数のスレーブとを備える。特許文献２にかかる監視装置は、サービスバス装置におけるメッセージログを解析し、リソース制御装置が解析結果に基づいて、サービスバス装置のスレーブの有効化及び無効化を行う。

特表２０１４−５２７２２１号公報 特開２０１５−１４１５４７号公報

上述した特許文献１及び２では、クラウド上で提供される特定のサービスに対するアクセス制御を行うサービスバスにおいて、当該サービスに関するリソースの動的な管理に改善の余地がある。まず、その理由は、まず、特許文献１に記載の技術は、サービスバスを介した外部のサービスに対するアクセス制御ではないためである。また、特許文献２に記載の技術は、サービスバスから外部のサービスにおける特定のリソースへアクセスを制御するものではないためである。

本発明は、このような問題点を解決するためになされたものであり、クラウド上で提供される特定のサービスに対するアクセス制御を行うサービスバスにおいて、当該サービスに関するリソースの動的な管理を適切に行うための情報処理装置、リソース管理方法及びリソース管理プログラムを提供することを目的とする。

本発明の第１の態様にかかる情報処理装置は、
外部システムにおいて提供される特定のサービスに関するメッセージについて、当該サービスの要求元と当該外部システムとの間で転送を行うメッセージ転送部と、
前記メッセージ転送部から取得した前記メッセージにおける解析結果に基づいて、前記特定のサービスの提供に用いるリソースの増減を判定する判定部と、
前記判定部において前記リソースを増加すると判定された場合に、前記特定のサービスを提供する第１のサービス提供部の複製を前記外部システムに対して指示し、当該第１のサービス提供部に対するアクセスを行う第１のサービスアクセス部を生成し、かつ、前記メッセージ転送部において当該第１のサービスアクセス部を用いて前記転送を行わせる、リソース増加処理を行うリソース管理部と、
を備える。

本発明の第２の態様にかかるリソース管理方法は、
外部システムにおいて提供される特定のサービスに関するメッセージについて当該サービスの要求元と当該外部システムとの間で転送を行うメッセージ転送部から、前記メッセージを取得し、
前記取得したメッセージにおける解析結果に基づいて、前記特定のサービスの提供に用いるリソースの増減を判定し、
前記リソースを増加すると判定された場合に、前記特定のサービスを提供するサービス提供部の複製を前記外部システムに対して指示し、当該複製されるサービス提供部に対するアクセスを行うサービスアクセス部を生成し、かつ、前記メッセージ転送部において当該生成したサービスアクセス部を用いて前記転送を行わせる、リソース増加処理を行う。

本発明の第３の態様にかかるリソース管理プログラムは、
外部システムにおいて提供される特定のサービスに関するメッセージについて当該サービスの要求元と当該外部システムとの間で転送を行うメッセージ転送部から、前記メッセージを取得する処理と、
前記取得したメッセージにおける解析結果に基づいて、前記特定のサービスの提供に用いるリソースの増減を判定する処理と、
前記リソースを増加すると判定された場合に、前記特定のサービスを提供するサービス提供部の複製を前記外部システムに対して指示し、当該複製されるサービス提供部に対するアクセスを行うサービスアクセス部を生成し、かつ、前記メッセージ転送部において当該生成したサービスアクセス部を用いて前記転送を行わせる、リソース増加処理と、
をコンピュータに実行させる。

本発明により、クラウド上で提供される特定のサービスに対するアクセス制御を行うサービスバスにおいて、当該サービスに関するリソースの動的な管理を適切に行うための情報処理装置、リソース管理方法及びリソース管理プログラムを提供することができる。

本発明の実施の形態１にかかる情報処理装置の構成を示すブロック図である。 本発明の実施の形態１にかかるリソース管理方法の流れを説明するためのフローチャートである。 本発明の実施の形態２にかかるクラウドサービスシステムの全体構成を示すブロック図である。 本発明の実施の形態２にかかる宛先サービス情報の例を示す図である。 本発明の実施の形態２にかかるメッセージの例を示す図である。 本発明の実施の形態２にかかるメッセージ転送定義情報の例を示す図である。 本発明の実施の形態２にかかる通信経路制御装置の構成を示すブロック図である。 本発明の実施の形態２にかかる性能条件の例を示す図である。 本発明の実施の形態２にかかるメッセージ転送及び変換処理の流れを説明するためのフローチャートである。 本発明の実施の形態２にかかる通信経路制御処理の流れを説明するためのフローチャートである。 本発明の実施の形態２にかかる通信経路制御処理の流れを説明するためのフローチャートである。 本発明の実施の形態２にかかるリソース追加の概念を説明するための図である。 本発明の実施の形態２にかかるリソース追加後の宛先サービス情報の例を示す図である。 本発明の実施の形態２にかかるメッセージ転送定義情報の追加の例を示す図である。 本発明の実施の形態３にかかるクラウドサービスシステムの全体構成を示すブロック図である。 本発明の実施の形態３にかかるサービス復旧処理の流れを説明するためのフローチャートである。 本発明の実施の形態４にかかるサービス復旧処理の流れを説明するためのフローチャートである。

以下では、本発明を適用した具体的な実施の形態について、図面を参照しながら詳細に説明する。各図面において、同一要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略する。

＜実施の形態１＞
図１は、本発明の実施の形態１にかかる情報処理装置１の構成を示すブロック図である。情報処理装置１は、要求元２と外部システム３と接続されている。外部システム３は、１以上のサービスを提供する情報システムであり、例えば、クラウドシステムである。外部システム３は、複数のサービスを提供可能であり、特定のサービスを提供するサービス提供部３１が稼働している。尚、サービス提供部３２は、サービス提供部３１と同種類のサービスを提供するものであるが、初期状態では、稼働していないものとする。尚、サービス提供部３１及び３２は、同一のサービスを提供するための同一の処理モジュールから生成された異なるインスタンスやプロセス等である。

要求元２は、特定のサービスを要求し、サービスの処理結果を受信するクライアント端末等である。また、要求元２は、サービスの要求であるメッセージを情報処理装置１へ送信し、サービスの応答をメッセージとして情報処理装置１から受信する。

情報処理装置１は、要求元２からのサービス要求を外部システム３内の特定のサービスに対応するサービス提供部３１へ転送し、その応答を要求元２へ転送する、サービスバス装置である。情報処理装置１は、メッセージ転送部１１と、判定部１２と、リソース管理部１３と、サービスアクセス部１４とを備える。尚、サービス提供部１５は、初期状態では生成されていないものとする。

メッセージ転送部１１は、外部システム３において提供される特定のサービスに関するメッセージについて、当該サービスの要求元２と外部システム３との間で転送を行う。ここで、「特定のサービスに関するメッセージ」とは、例えば、要求元２から特定のサービスに対する処理要求であるか、当該処理要求に対する外部システム３からの応答であるものとする。また、「応答」には、サービス提供部３１等からの処理結果（処理の成功又は失敗を含む処理後のデータ）や、情報処理装置１からサービス提供部３１等への接続エラー等を含むものとする。尚、メッセージ転送部１１は、メッセージについて所定の変換を行い、変換後のメッセージを転送しても構わない。

また、サービスアクセス部１４は、サービス提供部３１に対するアクセスを行う処理モジュールである。そのため、メッセージ転送部１１は、要求元２から受信したメッセージを、サービスアクセス部１４を用いてサービス提供部３１へ転送する。

判定部１２は、メッセージ転送部１１から取得したメッセージにおける解析結果に基づいて、特定のサービスの提供に用いるリソースの増減を判定する。ここで、解析結果とは、特定のサービスについての情報処理装置１におけるスループットや、ターンアラウンドタイム（ＴＡＴ）等の性能情報であるか、上述した処理結果であってもよい。そのため、判定部１２は、メッセージにおける解析を行い、解析結果を生成してもよい。

リソース管理部１３は、判定部１２においてリソースを増加すると判定された場合に、次のリソース増加処理を行う。ここで、リソース増加処理は、特定のサービスを提供するサービス提供部３２の複製を外部システム２に対して指示し、サービス提供部３２に対するアクセスを行うサービスアクセス部１５を生成し、かつ、メッセージ転送部１１においてサービスアクセス部１５を用いてサービス提供部３２へメッセージの転送を行わせる処理である。

図２は、本発明の実施の形態１にかかるリソース管理方法の流れを説明するためのフローチャートである。まず、判定部１２は、メッセージ転送部１１からメッセージを取得する（Ｓ１１）。ここで、取得されるメッセージは、要求元２からサービス提供部３１への処理要求か、当該処理要求に対するサービス提供部３１からの応答である。

次に、判定部１２は、取得したメッセージに対して解析を行い、その解析結果に基づいて、前記特定のサービスの提供に用いるリソースを増加するか削減するかを判定する（Ｓ１２）。

そして、リソース管理部１３は、判定部１２においてリソースを増加すると判定された場合に、リソース増加処理を行う（Ｓ１３）。ここで、リソース増加処理としては、特定のサービスを提供するサービス提供部３２の複製を外部システムに対する指示する処理、当該複製されるサービス提供部３２に対するアクセスを行うサービスアクセス部１５を生成する処理、及び、メッセージ転送部１１において当該生成したサービスアクセス部１５を用いて転送を行わせる処理を含む。

このように、本実施の形態１では、特定のサービスに関して、要求元２と外部システム３の間で転送されるメッセージを用いて、当該特定のサービスを処理するためのリソースの増加を行うものである。特に、リソース管理部１３により複製を指示されるサービス提供部３２は、３は、既に稼働しているサービス提供部３１と同種類のサービスを提供することができ、サービス提供部３１とは別のリソースが割り当てられるものである。つまり、リソース管理部１３は、特定のサービスを処理するために、外部システム３におけるリソースの確保を行う。併せて、リソース管理部１３は、サービス提供部３２とのメッセージの送受信を行うためのサービス提供部１５を、情報処理装置１内に生成する。つまり、特定のサービスを処理するために、情報処理装置１のリソースの確保も行う。さらに、リソース管理部１３は、メッセージ転送部１１が特定のサービスの今後の処理要求を転送する際に、サービスアクセス部１４に加えてサービス提供部１５も選択肢として追加する。これにより、特定のサービスを処理するためのサービス提供部及びサービスアクセス部のリソースを適切に、増加することができる。すなわち、クラウド上で提供される特定のサービスに対するアクセス制御を行うサービスバスにおいて、当該サービスに関するリソースの動的な管理を適切に行うことができる。

尚、リソースとは、一般的にはメモリやＣＰＵ等のサービスの稼働及び処理に必要とされる物理的な資源全般を指すが、本実施の形態では、サービスを処理するサービス提供部やサービスアクセス部といったソフトウェアリソースを指すものとする。そのため、本実施の形態の外部システム３及び情報処理装置１においては、物理的なリソースについては十分に搭載されており、本実施の形態にかかるリソース管理方法の実施時点では、物理的なリソースに空きがあるものとする。そのため、リソース増加処理によりソフトウェアリソースを増加する際には、必要な物理リソースも割り当てられるものとする。

＜実施の形態２＞
本実施の形態２は、上述した実施の形態１の具体的な実施例である。
図３は、本発明の実施の形態２にかかるクラウドサービスシステム１０００の全体構成を示すブロック図である。クラウドサービスシステム１０００は、クライアント１２０と、サービスバス装置１００と、サービス管理装置２００とを備える。ここで、クライアント１２０は上述した要求元２の一例であり、サービスバス装置１００は上述した情報処理装置１の一例であり、サービス管理装置２００は上述した外部システム３の一例である。

また、クライアント１２０は、サービス管理装置２００において提供されるサービスにアクセスするために、サービスバス装置１００に対して処理要求を送信し、処理結果をサービスバス装置１００から受信する。尚、クライアント１２０は、通常、複数存在するが、説明を容易にするために、１つのみを図示している。

サービス管理装置２００は、サービス管理部２１０と、サービスＡ１６０とを備える。サービス管理部２１０は、複数のサービス提供部（サービスＡ１６０等）を管理する管理モジュールであり、例えば、アプリケーションサーバ等である。また、サービスＡ１６０は、サービスＡのサービス提供部の一例である。サービス提供部は、サービス管理部２１０により特定のサービス提供モジュールをインスタンス化することにより、サービス管理装置２００上で稼働する。または、サービス提供部は、特定のサービスの処理を行うプロセスであってもよい。

サービス管理部２１０は、外部（サービスバス装置１００等）からのサービスの複製又は削除の指示を受け付け、サービスＡ１６０等の複製又は削除を行う。ここで、サービスの複製又は削除は、サービス管理部２１０が特定のＡＰＩ（Application Programming Interface）を実行することで実現する。そして、サービスの複製又は削除を行うＡＰＩは、サービスバス装置１００に対して公開されているものとする。そのため、サービス管理部２１０は、サービスバス装置１００から当該ＡＰＩの呼び出しを受け付けて実行することで、サービスのインスタンスの生成や削除を行う。
また、サービスは常に利用可能な状態にあるわけではなく、クラウドサービス上に構築したサービスのように、必要に応じてサービスの複製・削除が可能な環境上に構築されるものとする。そして、本実施の形態では、サービス管理装置２００上にサービスを構築する場合を示すが、サービスの構築の仕方はこれに限定されない。

尚、サービス管理装置２００は、複数台のサーバ装置によるクラウドサーバ群であってもよい。また、サービス管理装置２００内には、複数のサービスの夫々を提供するためのサービス（提供部）が稼働している。これらについても、説明を容易にするために、１つのみを図示している。

サービスバス装置１００は、メッセージ受信部Ａ１３０と、メッセージ変換部１４０と、メッセージ送信部Ａ１５０と、通信経路制御装置１１０とを備える。尚、サービスバス装置１００内には、複数のサービスの夫々に対応するメッセージ受信部及びメッセージ送信部の組が稼働している。但し、説明を容易にするために、一組のみを図示している。

尚、以下の説明では、クライアント１２０からサービスＡ１６０への方向のデータの流れについて説明するが、メッセージ受信部Ａ１３０とメッセージ送信部Ａ１５０とは、それぞれメッセージ送受信部として双方向のメッセージを処理することができるものである。

メッセージ受信部Ａ１３０は、クライアント１２０から特定のサービスに対する処理要求として所定のフォーマットのメッセージを受信する。メッセージ送信部Ａ１５０は、上述したサービスアクセス部１４の一例であり、サービスＡ１６０へメッセージを送信する。メッセージ送信部Ａ１５０は、宛先サービス情報１５１を保持する。

図４は、本発明の実施の形態２にかかる宛先サービス情報の例を示す図である。つまり、メッセージ送信部Ａ１５０は、宛先サービス情報１５１として「サービスＡの宛先」が設定され、保持されているものとする。そして、メッセージ送信部Ａ１５０は、宛先サービス情報１５１により特定される宛先であるサービスＡ１６０に対してメッセージを送信する。

メッセージ変換部１４０は、上述したメッセージ転送部１１の一例である。メッセージ変換部１４０は、メッセージを宛先のサービスに対応する他のフォーマットへの変換やプロトコルの変換等を行い、変換後のメッセージを転送する。ここで、図５は、本発明の実施の形態２にかかるメッセージの例を示す図である。図５に示すメッセージは、サービスＡに対する処理要求を示す。

また、メッセージ変換部１４０は、メッセージ転送定義情報１４１を保持する。メッセージ転送定義情報１４１は、転送元であるメッセージ受信部と転送先であるメッセージ送信部の組について定義した情報である。尚、メッセージ転送定義情報１４１は、少なくともメッセージの転送に用いるサービスアクセス部の情報を管理するものである。図６は、本発明の実施の形態２にかかるメッセージ転送定義情報の例を示す図である。尚、メッセージ受信部Ａ及びメッセージ送信部Ａは、サービスＡについてのメッセージをサービスバス装置１００内で転送するための定義である。

そのため、メッセージ変換部１４０は、メッセージ転送定義情報１４１を参照して、メッセージの転送先を特定し、特定した転送先へメッセージを転送する。言い換えると、メッセージ変換部１４０は、特定した転送先であるメッセージ送信部を用いて、要求されたサービス提供部へメッセージを転送する。

通信経路制御装置１１０は、メッセージ変換部１４０を通過するメッセージを読み取って、メッセージの通信経路の制御を行う。図７は、本発明の実施の形態２にかかる通信経路制御装置１１０の構成を示すブロック図である。通信経路制御装置１１０は、データ取得部１１１と、制御部１１２と、性能計測部１１３と、設定保管部１１４と、リソース管理部１１５とを備える。

データ取得部１１１は、メッセージ変換部１４０を監視、通過するメッセージを読み出して、つまり取得して、制御部１１２へ通知する。制御部１１２は、上述した判定部１２の一例であり、データ取得部１１１から受け付けたメッセージを保持し、性能計測部１１３及びリソース管理部１１５の動作を制御する。特に、制御部１１２は、性能計測結果に基づいてリソースの増減を判定し、リソース管理部１１５に対してリソース追加命令又はリソース削除命令を通知する。

性能計測部１１３は、制御部１１２からの命令に応じて特定のサービスに対するメッセージ処理の性能計測を行う。設定保管部１１４は、予め設定された、各サービスについての要求される性能条件やリソース管理対象を示す設定情報を保管する。

図８は、本発明の実施の形態２にかかる性能条件の例を示す図である。ここでは、リソース追加条件及びリソース削除条件が性能条件であり、それぞれサービスバス装置１００内の管理対象リソースである送信部名と、対応するサービス名とが対応付けされていることを示す。

リソース管理部１１５は、上述したリソース管理部１３の一例であり、制御部１１２からの命令に応じて、リソース追加処理又はリソース削減処理を行う。リソース追加処理は、制御部１１２においてリソースを増加すると判定された場合に、例えば、サービスＡの複製（後述するサービスＡ‘１８０）をサービス管理部２１０に対して指示すること、サービスＡ‘１８０に対するアクセスを行う（後述の）メッセージ送信部Ａ’１７０を生成すること、及び、メッセージ変換部１４０においてメッセージ送信部Ａ’１７０を用いてメッセージの転送を行わせること、を含む。

また、リソース削減処理は、制御部１１２においてリソースを削減すると判定された場合に、例えば、サービスＡに対するリソースがなくならない範囲で、つまり、サービスＡに対して複数のサービス提供部が生成済みである場合に、その一部であるサービスＡ１６０の削除をサービス管理部２１０に対して指示すること、サービスＡ１６０に対してアクセスを行うメッセージ送信部Ａ１５０を削除すること、及び、サービスＡにおける残されたメッセージ送信部を用いてサービスＡ（削除されたサービスＡ１６０とは異なるインスタンス）に対して転送を行わせること、を含む。これにより、特定のサービスに対するリソースを抑制しつつ、最低限のサービスレベルを維持することができる。

さらに、リソース管理部１１５は、上記の例では、リソース増加処理において、メッセージ転送定義情報１４１にメッセージ送信部Ａ‘１７０の情報を追加し、リソース削減処理において、メッセージ転送定義情報１４１からメッセージ送信部Ａ１５０の情報を削除する。この場合、メッセージ変換部１４０は、追加又は削除後のメッセージ転送定義情報１４１の中から任意のメッセージ送信部の情報を選択し、当該選択したメッセージ送信部を用いてメッセージを当該メッセージ送信部に対応するサービス提供部へ転送する。このように、メッセージ転送定義情報１４１を用いることで、追加又は削除したメッセージ送信部を踏まえて適切に転送先のリソースを制御できる。

リソース管理部１１５は、サービス管理部２１０に対して特定のサービス提供部の複製又は削除を行うＡＰＩを呼び出し、複製又は削除にかかるサービス提供部に対応するメッセージ送信部の生成又は削除を行い、さらに、メッセージ変換部１４０に対してメッセージ転送定義情報１４１の更新（メッセージ転送先追加命令又はメッセージ転送先削除命令）を行う。

図９は、本発明の実施の形態２にかかるメッセージ転送及び変換処理の流れを説明するためのフローチャートである。まず、クライアント１２０は、サービスＡに対するリクエスト（メッセージ）をサービスバス装置１００へ送信する。そして、サービスバス装置１００内のメッセージ受信部Ａ１３０は、クライアント１２０からのメッセージを受信する（ステップＡ１）。次に、メッセージ変換部１４０は、メッセージ受信部Ａ１３０からのメッセージを取得する（ステップＡ２）。

ここで、メッセージ変換部１４０は、取得したメッセージを変換する（ステップＡ３）。すなわち、メッセージ変換部１４０は、メッセージのヘッダ等から宛先のサービスＡを特定し、サービスＡに対応するフォーマットやプロトコルにメッセージを変換する。

また、このとき、通信経路制御装置１１０は、メッセージ変換部１４０からメッセージを取得する（ステップＡ４）。尚、ここで取得されるメッセージは、変換前後のいずれでも構わない。

そして、メッセージ変換部１４０は、メッセージ転送定義情報１４１を参照し、転送に用いるメッセージ送信部Ａ１５０を選択し、メッセージ送信部Ａ１５０へ変換後のメッセージを転送する（ステップＡ５）。続いて、メッセージ送信部Ａ１５０は、宛先サービス情報１５１を参照し、宛先をサービスＡ１６０と特定し、特定したサービスＡ１６０へメッセージを送信する（ステップＡ６）。

図１０及び図１１は、本発明の実施の形態２にかかる通信経路制御処理の流れを説明するためのフローチャートである。すなわち、通信経路制御装置１１０における上述したステップＡ４以降の処理について説明する。

まず、データ取得部１１１は、メッセージ変換部１４０を通過するメッセージに関するデータを読み取る（ステップＢ１）。次に、データ取得部１１１は、読み取ったデータを制御部１１２に渡す（ステップＢ２）。そして、制御部１１２は、データの内容を性能計測部１１３に渡す（ステップＢ３）。そこで、性能計測部１１３は、受け取ったデータを元に、メッセージ送信部ごと（つまり、サービスごと）のスループットやターンアラウンドタイムといった性能計測を行う（ステップＢ４）。

その後、制御部１１２は、性能計測部１１３の計測結果と設定保管部１１４から読み取った設定値を比較する（ステップＢ５）。図８の場合、制御部１１２は、設定保管部１１４からメッセージ送信部Ａに対応付けられたリソース追加条件及びリソース削除条件を読み出し、これらと計測結果とを比較する。

そして、制御部１１２は、適用される条件が存在するか否かを判定する（ステップＢ５１）。適用される条件が存在しなければ、リソース追加もリソース削除も行わずに次の処理（ステップＢ１）に遷移する。

一方、適用される条件が存在する場合、制御部１１２は、リソースの追加（増加）であるか否かを判定する（ステップＢ５２）。リソースの追加である場合、つまり、性能比較結果がリソース追加条件に合致している場合、制御部１１２は、リソース管理部１１５へリソース追加の命令を通知する（ステップＢ６）。

そして、リソース管理部１１５は、リソース追加の対象となるメッセージ送信部及びサービスの複製を作成する（ステップＢ７）。すなわち、リソース管理部１１５は、サービス管理部２１０に対して、サービスＡを複製するためのＡＰＩを呼び出す。これにより、サービス管理部２１０は、ＡＰＩに基づいてサービスＡ１６０の複製としてサービスＡ‘１８０を生成（インスタンス化）する。ここで、サービスＡ‘１８０は、サービスＡ１６０と共通のサービスＡのサービスを提供可能であり、かつ、サービス管理装置２００上で異なるリソースが割り当てられたものである。そのため、サービスＡ１６０とサービスＡ‘１８０とは、並列処理が可能である。ここで、図１２は、本発明の実施の形態２にかかるリソース追加の概念を説明するための図である。

また、リソース管理部１１５は、メッセージ送信部Ａ’１７０を生成する。すなわち、リソース管理部１１５は、メッセージ送信部Ａ１５０の複製としてメッセージ送信部Ａ’１７０を生成（インスタンス化）する。ここで、メッセージ送信部Ａ’１７０は、サービスＡ‘１８０に対するアクセスを行うサービスアクセス部である。具体的には、メッセージ送信部Ａ’１７０は、内部で保持する宛先サービス情報として「サービスＡ‘１８０」が設定されているものとする。図１３は、本発明の実施の形態２にかかるリソース追加後の宛先サービス情報の例を示す図である。尚、サービスバス装置１００からサービスＡ‘１８０へのアクセスは、メッセージ送信部Ａ’１７０以外では行えないものとする。尚、メッセージ送信部Ａ１５０とメッセージ送信部Ａ‘１７０は、メッセージ送信部を識別するためのメッセージ送信部名と宛先サービスの設定以外は同じ設定とする。

その後、リソース管理部１１５は、メッセージ変換部１４０に対してメッセージ転送先追加の命令を通知する（ステップＢ８）。このとき、リソース管理部１１５は、メッセージ転送先追加命令に追加対象のメッセージ送信部を指定する。メッセージ変換部１４０は、リソース管理部１１５からのメッセージ転送先追加命令に応じてメッセージ転送定義情報１４１を更新する（メッセージ転送定義情報１４１ａに更新される）。ステップＢ８は、追加したメッセージ送信部をメッセージ転送先として有効化するための処理といえる。

図１４は、本発明の実施の形態２にかかるメッセージ転送定義情報１４１ａの追加の例を示す図である。ここでは、メッセージ受信部Ａに対応付けられたメッセージ転送先として、メッセージ送信部Ａと共にメッセージ送信部Ａ‘が追加されたことを示す。これにより、以後、メッセージ変換部１４０は、サービスＡ宛のメッセージについて、メッセージ転送定義情報１４１ａに基づいて、メッセージ送信部Ａ１５０又はメッセージ送信部Ａ‘１７０のいずれかを特定して、特定したメッセージ送信部を用いてメッセージを転送できる。いずれが特定されたとしても、インスタンスは異なるものの同内容のサービスＡの処理がなされ、処理結果を得ることができる。例えば、メッセージ転送定義情報１４１ａのように一つのメッセージ受信部Ａ１３０（サービスＡ）に対して複数のメッセージ送信部Ａ１５０及びメッセージ送信部Ａ‘１７０が対応付けられている場合、メッセージ変換部１４０は、ロードバランシングにより負荷分散を行うことができる。よって、サービスＡについて負荷分散した通信経路の制御を実現できる。

ここで、ステップＢ５２において、リソースの追加ではない、つまりリソースの削除である場合、制御部１１２は、該当するサービスＡについて追加されたリソースが存在するか否かを判定する（ステップＢ５３）。すなわち、制御部１１２は、該当するサービスＡについて複数のメッセージ送信部が存在するか否かを判定する。具体的には、制御部１１２は、メッセージ転送定義情報１４１を参照し、メッセージ受信部Ａ１３０に対応付けられたメッセージ転送先が２以上であるか否かを判定する。

性能比較結果がリソース削除条件に合致しており、追加されたリソースが存在する場合、つまりリソースの削除（削減）である場合、制御部１１２は、リソース管理部１１５へリソース削除の命令を通知する（ステップＢ９）。次に、リソース管理部１１５は、メッセージ変換部１４０に対してメッセージ転送先削除の命令を通知する（ステップＢ１０）。このとき、リソース管理部１１５は、メッセージ転送先削除命令に削除対象のメッセージ送信部を指定する。メッセージ変換部１４０は、リソース管理部１１５からのメッセージ転送先削除命令に応じてメッセージ転送定義情報を更新する。すなわち、メッセージ変換部１４０は、指定されたメッセージ送信部の情報をメッセージ転送定義情報から削除する。例えば、図１４の場合、メッセージ転送先からメッセージ送信部Ａ又はメッセージ送信部Ａ‘の情報を削除する。このように、リソース（メッセージ送信部及びサービス提供部）の削除前にメッセージ転送定義情報からメッセージ転送先の情報を削除することにより、既に存在しない転送先にメッセージが転送されることを防止できる。

転送先情報の削除後、リソース管理部１１５がリソース削除の対象となるサービスの複製と、対応するメッセージ送信部を削除する（Ｂ１１）。リソース管理部１１５は、リソース削除の対象となるメッセージ送信部及びサービスの複製を削除する（ステップＢ１１）。例えば、リソース管理部１１５は、サービスバス装置１００内のメッセージ送信部Ａ‘１７０のインスタンスを削除し、サービス管理部２１０に対してサービスＡ‘１８０を削除するためのＡＰＩを呼び出す。これにより、サービス管理部２１０は、サービスＡ‘１８０のインスタンスを削除する。

尚、ステップＢ９において、追加されたリソースが存在しない場合、削除するリソースが無いので、何もせずに次の処理（ステップＢ１）に遷移する。

以降、図１０及び図１１の処理を一定間隔ごとに実施し、必要に応じてリソースの追加及び削除と通信経路の制御を行う。

ここで、本実施の形態について改めて説明する。まず、元々、サービスバスを介して通信を行うシステムにおいて要求される性能を満たすためには、必要なリソースの見積もりを行い、予め十分なリソースを確保しておく必要がある。また、サービスバスと接続する外部システムにより提供されるサービスについても、要求性能を満たすために多重化構成をとることがあり、実際のリクエスト量にかかわらず最大限のリソースが確保される。しかし、実運用では、リクエスト量は常に一定ではなく、時間帯や状況によって増減するため、予測よりもリクエスト量が少ないときはリソースが無駄になり、予測よりも多いときはリソース不足となる。

そこで、本実施の形態では、サービスバスに対するリクエストの発生状況や負荷状況に応じて、動的にリソースを確保し、通信経路を制御するサービスバスにおける動的な通信路制御手段を提供する。これにより、予めサイジングを手動で行うことなく、自動的に効率的なリソースの利用が可能になる。その理由は、サービスバスからリソースの追加及び削除を行う機構を設け、動的にサービスバス上の通信経路を制御することで、通信状況に応じたリソース管理が可能になったためである。

＜実施の形態３＞
本実施の形態３は、上述した実施の形態１の具体的な他の実施例である。実施の形態３では、上述した解析結果としてメッセージに含まれる処理結果を用いる場合を示す。すなわち、本実施の形態３にかかる判定部は、前記解析結果が前記特定のサービスの処理結果を示す場合に、当該特定のサービスの復旧の要否を判定し、前記リソース管理部は、前記判定部において前記特定のサービスの復旧が必要と判定された場合に、前記第１のサービス提供部及び前記第１のサービスアクセス部に対する前記リソース増加処理と、前記処理結果に対応する前記第２のサービス提供部及び前記第２のサービスアクセス部に対する前記リソース削減処理とを行うものである。これにより、外部の監視システムを必要とせず、自動復旧が可能となる。また、待機系のサービスを余分に起動しておく必要がなく、リソースのさらなる効率化を実現できる。

また、本実施の形態では、予め待機系システムを用意することなく、サービスダウン時にシステムの自動復旧が可能になることにある。その理由は、サービスダウンをサービスバスが検知し、自動でサービスの複製と通信経路の制御を行うことで、ダウンしたサービスの代替となるサービスを構築できるためである。

図１５は、本発明の実施の形態３にかかるクラウドサービスシステム１０００ａの全体構成を示すブロック図である。尚、図３と同等の構成については、説明を省略する。クラウドサービスシステム１０００ａは、図３のサービスバス装置１００の代わりにサービスバス装置１００ａを備え、サービスバス装置１００ａは、図３の通信経路制御装置１１０の代わりに通信経路制御装置１１０ａを備える。また、メッセージ送信部Ａ１５０は、サービスＡ１６０からメッセージに対する処理結果ＭＲ、つまり処理の成功又は失敗に関する情報（Ｄｏｎｅ／Ｅｒｒｏｒ）を受け付ける。そして、メッセージ変換部１４０は、メッセージ送信部Ａ１５０から処理結果ＭＲを取得する。さらに、通信経路制御装置１１０ａ内のデータ取得部１１１は、メッセージ変換部１４０から処理結果ＭＲを取得する。通信経路制御装置１１０ａ内の制御部１１２は、処理結果ＭＲを解析して、Ｄｏｎｅ又はＥｒｒｏｒを抽出し、サービスの復旧の要否を判定する。そして、制御部１１２は、サービスの復旧が必要と判定した場合、リソース管理部１１５に対してサービス復旧命令を通知する。通信経路制御装置１１０ａ内のリソース管理部１１５は、サービス復旧命令に応じてリソース追加処理及びリソース削除処理を行い、メッセージ変換部１４０に対してメッセージ転送の保留及び再開を指示する。

図１６は、本発明の実施の形態３にかかるサービス復旧処理の流れを説明するためのフローチャートである。まず、データ取得部１１１は、メッセージ変換部１４０を通過するＤｏｎｅ／Ｅｒｒｏｒを読み取る（ステップＣ１）。次に、データ取得部１１１は、読み取ったデータを制御部１１２に渡す（ステップＣ２）。

そして、制御部１１２は、受け取ったデータからメッセージの処理結果ＭＲを抽出し、Ｅｒｒｏｒ又はＤｏｎｅのいずれであるかを判定する（ステップＣ２１）。処理結果ＭＲがＤｏｎｅである場合、メッセージ送信部での処理が正常に行われたため、復旧処理は不要となり、次の処理（ステップＣ１）へ進む。一方、処理結果ＭＲがＥｒｒｏｒである場合、メッセージ送信部での処理が正常に実行できなかったことを示すため、通信経路制御装置１１０ａは、リソース増加処理とリソース削減処理を行うことでサービスの復旧を行う。

つまり、この場合、制御部１１２は、リソース管理部１１５へリソース追加の命令を通知する（ステップＣ３）。そして、リソース管理部１１５は、リソース追加の対象となるメッセージ送信部及びサービスの複製する（ステップＣ４）。その後、リソース管理部１１５は、メッセージ変換部１４０に対してメッセージ転送先追加の命令を通知する（ステップＣ５）。

続いて、制御部１１２は、リソース管理部１１５へリソース削除の命令を通知する（ステップＣ６）。そして、リソース管理部１１５は、メッセージ変換部１４０に対してメッセージ転送先削除の命令を通知する（ステップＣ７）。その後、リソース管理部１１５は、リソース削減の対象となるメッセージ送信部及びサービスの複製を削除する（ステップＣ８）。

尚、上記では、処理結果ＭＲがＥｒｒｏｒであることをトリガにサービスを復旧する方法を述べたが、処理結果ＭＲをサービスの復旧の判定に用いる方法はこれに限定されない。例えば、上記では、一度Ｅｒｒｏｒになると直ちにサービスの復旧を行うため、たまたま処理に失敗しただけで、後続のメッセージは正常に処理できる可能性がある場合もサービス復旧の対象となってしまう。これを防ぐために、処理結果ＭＲの判定条件として、例えば、「ある回数以上連続してＥｒｒｏｒになった場合」や、「サービスに接続できない旨のＥｒｒｏｒが返却された場合」などをサービス復旧の判定条件を追加してもよい。すなわち、前記判定部は、前記特定のサービスの処理結果が所定の条件を満たす場合に、当該特定のサービスの復旧が必要と判定するとよい。これによりサービスを復旧する判定の精度が向上する。また、処理結果ＭＲとしてＤｏｎｅ及びＥｒｒｏｒのみでなく、「サービスにリクエスト送信後、レスポンスが一定時間返却されない」など性能面での指標をサービス復旧の判定として使用してもよい。

＜実施の形態４＞
本実施の形態４は、上述した実施の形態３の変形例である。実施の形態３では、処理結果ＭＲがＥｒｒｏｒと判定された後、ステップＣ７によりＥｒｒｏｒに該当するメッセージ送信部が転送先から削除されるまでの間に、問題のあるメッセージ送信部（及び対応するサービス）が転送先の候補として残されている。そのため、エラー検出後であっても後続のメッセージを問題のあるメッセージ送信部を用いて転送してしまい、エラーの連鎖が起こり得る。

そこで、本実施の形態４では、先に、リソース削減処理により、問題のあるメッセージ送信部を転送先から削除した上で、その後にリソース増加処理を行うものである。すなわち、前記リソース管理部は、前記判定部において前記特定のサービスの復旧が必要と判定され、かつ、前記第２のサービスアクセス部以外に前記特定のサービスにおける他のサービスアクセス部が存在しない場合に、前記メッセージの前記第２のサービスアクセス部への転送を保留した上で、前記リソース削減処理を行い、前記リソース増加処理を行った後に、前記第１のサービスアクセス部を用いて当該転送を保留したメッセージの転送を再開する。これにより、エラーの検出後に、連鎖的なエラーの発生を抑止することができる。

図１７は、本発明の実施の形態４にかかるサービス復旧処理の流れを説明するためのフローチャートである。まず、ステップＣ１、Ｃ２及びＣ２１は、図１６と同等であり、説明を省略する。そして、ステップＣ２１において処理結果ＭＲがＥｒｒｏｒである場合、制御部１１２は、リソース管理部１１５へサービス復旧の命令を通知する（ステップＤ１）。そして、リソース管理部１１５は、先にリソース削減処理を行い、その後、リソース増加処理を行う。特に、転送先の削除を先に行う。

具体的には、Ｅｒｒｏｒが発生したサービス送信部へのメッセージ転送を停止するために、リソース管理部１１５は、メッセージ変換部１４０に対してメッセージ転送先削除の命令を通知する（ステップＤ２）。そして、メッセージ変換部１４０は、メッセージ転送先が１つ以上あるか否かを判定する（ステップＤ３）。ここで、メッセージ転送先が１つのみである場合、メッセージ変換部１４０は、メッセージの転送を保留する（ステップＤ４）。その理由は、処理対象のサービスへのメッセージの転送先が空になってしまった場合、サービス復旧までメッセージ転送することができなくなり、さらなるエラーが発生し得るためである。

ステップＤ４の後、又は、ステップＤ３においてメッセージ転送先が１つ以上ある場合、リソース管理部１１５は、リソース削減の対象となるメッセージ送信部及びサービスの複製を削除する（ステップＤ５）。続いて、リソース管理部１１５は、リソース追加の対象となるメッセージ送信部及びサービスの複製を生成する（ステップＤ６）。その後、リソース管理部１１５は、メッセージ変換部１４０に対してメッセージ転送先追加の命令を通知する（ステップＤ７）。

そして、メッセージ変換部１４０は、メッセージの転送が保留されているか否かを判定する（ステップＤ８）。ステップＤ４において保留されている場合、メッセージ変換部１４０は、保留されていたメッセージの転送を再開する（ステップＤ９）。

このように、本実施の形態により、エラーの原因となるメッセージ送信部及びサービスへの転送先の定義を先に削除しておくことで、エラーの検出後に、連鎖的なエラーの発生を抑止することができる。

＜実施の形態５＞
本実施の形態５は、上述した実施の形態３又は４の変形例である。実施の形態３又は４では、サービス異常時に検出したエラーについて特に処理をせずに、クライアントにエラーが返信されることになる。しかし、同一のサービスについて複数のサービス提供部やサービスアクセス部が生成済みの場合、エラーとなっていないサービス提供部及びサービスアクセス部に対して、処理要求のメッセージを再送することで、正常に処理がされ、クライアントへは正常応答を返信できる場合がある。

そこで、本実施の形態５では、サービス異常によってエラーとしてレスポンスが返却された際に、エラーになった処理のリクエストを、再度、同種のサービスの正常な他のメッセージ送信部（インスタンス）宛に転送（リトライ）するものである。すなわち、前記リソース管理部は、前記判定部において前記特定のサービスの復旧が必要と判定され、かつ、前記第２のサービスアクセス部以外に前記特定のサービスにおける他のサービスアクセス部が存在する場合に、前記第２のサービスアクセス部に代えて、当該他のサービスアクセス部を用いて前記メッセージの転送を行う。これにより、サービスレベルを維持できる。

例えば、図１７のステップＤ３においてメッセージ転送先が１つ以上ある場合に、ステップＤ５以降と並行して、メッセージ変換部１４０は、メッセージ転送定義情報１４１の中からエラーに該当するメッセージ送信部以外の（同一のサービスにおける）メッセージ送信部を選択し、選択したメッセージ送信部を用いて、当該エラーとなったメッセージを転送することで実現できる。

＜その他の実施の形態＞
尚、上述した各実施の形態は、サービスバス装置を介して通信を行うシステムに適用できる。また、Ｗｅｂサービス間での通信やモバイルデバイス及び各種センサなどの端末からデータを受信するようなシステムにも適用できる。

なお、本発明は上記実施の形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変更することが可能である。

また、上述の実施の形態では、本発明をハードウェアの構成として説明したが、本発明は、これに限定されるものではない。本発明は、任意の処理を、ＣＰＵ（Central Processing Unit）にコンピュータプログラムを実行させることにより実現することも可能である。

上述の例において、プログラムは、様々なタイプの非一時的なコンピュータ可読媒体（non-transitory computer readable medium）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（tangible storage medium）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、ＣＤ−ＲＯＭ（Read Only Memory）、ＣＤ−Ｒ、ＣＤ−Ｒ／Ｗ、ＤＶＤ（Digital Versatile Disc）、ＢＤ（Blu-ray（登録商標） Disc）、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ（Programmable ROM）、ＥＰＲＯＭ（Erasable PROM）、フラッシュＲＯＭ、ＲＡＭ（Random Access Memory））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable medium）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。
（付記１）
外部システムにおいて提供される特定のサービスに関するメッセージについて、当該サービスの要求元と当該外部システムとの間で転送を行うメッセージ転送部と、
前記メッセージ転送部から取得した前記メッセージにおける解析結果に基づいて、前記特定のサービスの提供に用いるリソースの増減を判定する判定部と、
前記判定部において前記リソースを増加すると判定された場合に、前記特定のサービスを提供する第１のサービス提供部の複製を前記外部システムに対して指示し、当該第１のサービス提供部に対するアクセスを行う第１のサービスアクセス部を生成し、かつ、前記メッセージ転送部において当該第１のサービスアクセス部を用いて前記転送を行わせる、リソース増加処理を行うリソース管理部と、
を備える情報処理装置。
（付記２）
前記リソース管理部は、
前記判定部において前記リソースを削減すると判定され、かつ、前記特定のサービスを提供する複数のサービス提供部が生成済みである場合に、前記複数のサービス提供部の一部である第２のサービス提供部の削除を前記外部システムに対して指示し、当該第２のサービス提供部に対してアクセスを行う第２のサービスアクセス部を削除し、かつ、当該複数のサービス提供部のうち残されたサービスアクセス部を用いて前記転送を行わせる、リソース削減処理を行う
付記１に記載の情報処理装置。
（付記３）
前記メッセージ転送部は、
前記メッセージの転送に用いる前記サービスアクセス部の情報を管理する転送定義情報を保持し、
前記リソース管理部は、
前記リソース増加処理において、前記転送定義情報に前記第１のサービスアクセス部の情報を追加し、
前記リソース削減処理において、前記転送定義情報から前記第２のサービスアクセス部の情報を削除し、
前記メッセージ転送部は、
前記追加又は削除後の転送定義情報の中から任意のサービスアクセス部の情報を選択し、当該選択したサービスアクセス部を用いて前記メッセージを当該サービスアクセス部に対応するサービス提供部へ転送する
付記２に記載の情報処理装置。
（付記４）
前記判定部は、前記解析結果が前記特定のサービスの処理結果を示す場合に、当該特定のサービスの復旧の要否を判定し、
前記リソース管理部は、前記判定部において前記特定のサービスの復旧が必要と判定された場合に、前記第１のサービス提供部及び前記第１のサービスアクセス部に対する前記リソース増加処理と、前記処理結果に対応する前記第２のサービス提供部及び前記第２のサービスアクセス部に対する前記リソース削減処理とを行う
付記２又は３に記載の情報処理装置。
（付記５）
前記リソース管理部は、
前記判定部において前記特定のサービスの復旧が必要と判定され、かつ、前記第２のサービスアクセス部以外に前記特定のサービスにおける他のサービスアクセス部が存在しない場合に、前記メッセージの前記第２のサービスアクセス部への転送を保留した上で、前記リソース削減処理を行い、前記リソース増加処理を行った後に、前記第１のサービスアクセス部を用いて当該転送を保留したメッセージの転送を再開する
付記４に記載の情報処理装置。
（付記６）
前記判定部は、前記特定のサービスの処理結果が所定の条件を満たす場合に、当該特定のサービスの復旧が必要と判定する
付記４又は５に記載の情報処理装置。
（付記７）
前記リソース管理部は、
前記判定部において前記特定のサービスの復旧が必要と判定され、かつ、前記第２のサービスアクセス部以外に前記特定のサービスにおける他のサービスアクセス部が存在する場合に、前記第２のサービスアクセス部に代えて、当該他のサービスアクセス部を用いて前記メッセージの転送を行う
付記４乃至６のいずれか１項に記載の情報処理装置。
（付記８）
外部システムにおいて提供される特定のサービスに関するメッセージについて当該サービスの要求元と当該外部システムとの間で転送を行うメッセージ転送部から、前記メッセージを取得し、
前記取得したメッセージにおける解析結果に基づいて、前記特定のサービスの提供に用いるリソースの増減を判定し、
前記リソースを増加すると判定された場合に、前記特定のサービスを提供するサービス提供部の複製を前記外部システムに対して指示し、当該複製されるサービス提供部に対するアクセスを行うサービスアクセス部を生成し、かつ、前記メッセージ転送部において当該生成したサービスアクセス部を用いて前記転送を行わせる、リソース増加処理を行う
リソース管理方法。
（付記９）
外部システムにおいて提供される特定のサービスに関するメッセージについて当該サービスの要求元と当該外部システムとの間で転送を行うメッセージ転送部から、前記メッセージを取得する処理と、
前記取得したメッセージにおける解析結果に基づいて、前記特定のサービスの提供に用いるリソースの増減を判定する処理と、
前記リソースを増加すると判定された場合に、前記特定のサービスを提供するサービス提供部の複製を前記外部システムに対して指示し、当該複製されるサービス提供部に対するアクセスを行うサービスアクセス部を生成し、かつ、前記メッセージ転送部において当該生成したサービスアクセス部を用いて前記転送を行わせる、リソース増加処理と、
をコンピュータに実行させるリソース管理プログラム。

１ 情報処理装置
１１ メッセージ転送部
１２ 判定部
１３ リソース管理部
１４ サービスアクセス部
１５ サービス提供部
２ 要求元
３ 外部システム
３１ サービス提供部
３２ サービス提供部
１０００ クラウドサービスシステム
１０００ａ クラウドサービスシステム
１２０ クライアント
１００ サービスバス装置
１００ａ サービスバス装置
１１０ 通信経路制御装置
１１０ａ 通信経路制御装置
１１１ データ取得部
１１２ 制御部
１１３ 性能計測部
１１４ 設定保管部
１１５ リソース管理部
１３０ メッセージ受信部Ａ
１４０ メッセージ変換部
１４１ メッセージ転送定義情報
１４１ａ メッセージ転送定義情報
１５０ メッセージ送信部Ａ
１５１ 宛先サービス情報
１７０ メッセージ送信部Ａ‘
２００ サービス管理装置
２１０ サービス管理部
１６０ サービスＡ
１８０ サービスＡ‘
ＭＲ 処理結果

Claims (9)

1. 外部クラウドサービスシステムにおいて提供される特定のサービスに対する、当該サービスの要求元のアクセス制御を行う情報処理装置であって、当該特定のサービスに関するメッセージについて、当該サービスの要求元と当該外部クラウドサービスシステムとの間で転送を行うメッセージ転送部と、
   前記メッセージ転送部から取得した前記メッセージにおける解析結果に基づいて、前記特定のサービスの提供に用いるソフトウェアリソースの増減を判定する判定部と、
   前記判定部において前記ソフトウェアリソースを増加すると判定された場合に、前記外部クラウドサービスシステムにおいて前記特定のサービスを提供する第１のサービス提供部の複製を前記外部クラウドサービスシステムに対して指示し、前記外部クラウドサービスシステムの当該第１のサービス提供部に対するアクセスを行う第１のサービスアクセス部を生成し、リソース増加処理を行うリソース管理部と、
   を備え、
   前記複製された第１のサービス提供部と前記要求元との間のメッセージの転送は、前記生成された第１のサービスアクセス部に行わせる、情報処理装置。
2. 前記リソース管理部は、
   前記判定部において前記ソフトウェアリソースを削減すると判定され、かつ、前記特定のサービスを提供する複数のサービス提供部が生成済みである場合に、前記外部クラウドサービスシステムの前記複数のサービス提供部の一部である第２のサービス提供部の削除を前記外部クラウドサービスシステムに対して指示し、当該第２のサービス提供部に対してアクセスを行う第２のサービスアクセス部を削除する、リソース削減処理を行い、それによって、
   前記転送は、当該複数のサービス提供部のうち残されたサービスアクセス部に行わせる、
   請求項１に記載の情報処理装置。
3. 前記メッセージ転送部は、
   前記メッセージの転送に用いる前記サービスアクセス部の情報を管理する転送定義情報を保持し、
   前記リソース管理部は、
   前記リソース増加処理において、前記転送定義情報に前記第１のサービスアクセス部の情報を追加し、
   前記リソース削減処理において、前記転送定義情報から前記第２のサービスアクセス部の情報を削除し、
   前記メッセージ転送部は、
   前記追加又は削除後の転送定義情報の中から任意のサービスアクセス部の情報を選択し、当該選択したサービスアクセス部を用いて前記メッセージを当該サービスアクセス部に対応するサービス提供部へ転送する
   請求項２に記載の情報処理装置。
4. 前記判定部は、前記解析結果が前記特定のサービスの処理結果を示す場合に、当該特定のサービスの復旧の要否を判定し、
   前記リソース管理部は、前記判定部において前記特定のサービスの復旧が必要と判定された場合に、前記第１のサービス提供部及び前記第１のサービスアクセス部に対する前記リソース増加処理と、前記処理結果に対応する前記第２のサービス提供部及び前記第２のサービスアクセス部に対する前記リソース削減処理とを行う
   請求項２又は３に記載の情報処理装置。
5. 前記リソース管理部は、
   前記判定部において前記特定のサービスの復旧が必要と判定され、かつ、前記第２のサービスアクセス部以外に前記特定のサービスにおける他のサービスアクセス部が存在しない場合に、前記メッセージの前記第２のサービスアクセス部への転送を保留した上で、前記リソース削減処理を行い、前記リソース増加処理を行った後に、前記第１のサービスアクセス部を用いて当該転送を保留したメッセージの転送を再開する
   請求項４に記載の情報処理装置。
6. 前記判定部は、前記特定のサービスの処理結果が所定の条件を満たす場合に、当該特定のサービスの復旧が必要と判定する
   請求項４又は５に記載の情報処理装置。
7. 前記リソース管理部は、
   前記判定部において前記特定のサービスの復旧が必要と判定され、かつ、前記第２のサービスアクセス部以外に前記特定のサービスにおける他のサービスアクセス部が存在する場合に、前記第２のサービスアクセス部に代えて、当該他のサービスアクセス部を用いて前記メッセージの転送を行う
   請求項４乃至６のいずれか１項に記載の情報処理装置。
8. 外部クラウドサービスシステムにおいて提供される特定のサービスに対する、当該サービスの要求元のアクセス制御を行うリソース管理方法であって、当該特定のサービスに関するメッセージについて当該サービスの要求元と当該外部クラウドサービスシステムとの間で転送を行うメッセージ転送部から、前記メッセージを取得し、
   前記取得したメッセージにおける解析結果に基づいて、前記特定のサービスの提供に用いるソフトウェアリソースの増減を判定し、
   前記ソフトウェアリソースを増加すると判定された場合に、前記外部クラウドサービスシステムにおいて前記特定のサービスを提供するサービス提供部の複製を前記外部クラウドサービスシステムに対して指示し、前記外部クラウドサービスシステムの当該複製されるサービス提供部に対するアクセスを行うサービスアクセス部を生成する、リソース増加処理を行い、
   前記複製された第１のサービス提供部と前記要求元との間のメッセージの転送は、前記生成したサービスアクセス部に行わせる
   リソース管理方法。
9. 外部クラウドサービスシステムにおいて提供される特定のサービスに対する、当該サービスの要求元のアクセス制御を行うリソース管理プログラムであって、当該特定のサービスに関するメッセージについて当該サービスの要求元と当該外部クラウドサービスシステムとの間で転送を行うメッセージ転送部から、前記メッセージを取得する処理と、
   前記取得したメッセージにおける解析結果に基づいて、前記特定のサービスの提供に用いるソフトウェアリソースの増減を判定する処理と、
   前記ソフトウェアリソースを増加すると判定された場合に、前記外部クラウドサービスシステムにおいて前記特定のサービスを提供するサービス提供部の複製を前記外部クラウドサービスシステムに対して指示し、前記外部クラウドサービスシステムの当該複製されるサービス提供部に対するアクセスを行うサービスアクセス部を生成するリソース増加処理と、
   前記生成したサービスアクセス部に、前記複製された第１のサービス提供部と前記要求元との間のメッセージの転送を行わせる転送処理と、
   をコンピュータに実行させるリソース管理プログラム。

Images