JP5896140B2 - クラウド型システムにおけるサービス間依存の管理方法 - Google Patents

Description

本発明はサービスバス装置を使用してサービスを分散するクラウド型システムに関する。

従来、特許文献１に記載されているようなクラウド型のコンピューティングシステムが知られている。

図８は、従来のクラウド型システムの一例を示す図である。同図に示すシステムでは、複数のサービスバス装置１１、２１、３１の運用管理部１２、２２、３２が相互に連動しておらず、それぞれの運用管理を管理端末１０１、１０２などから実行するよう構成されている。

このような構成を有するクラウド型システムにおけるサービスの閉塞操作は次のように動作する。例えば、サービスＢ２０の閉塞を行う場合、まず、サービスバス装置１１側の運用者に連絡して、サービスＡ１０を閉塞するよう依頼する。サービスＡ１０が閉塞したことを確認できたのち、運用者はサービスＢ２０の閉塞を実行する。このとき、サービスＡ１０により受理されたメッセージがサービスＢ２０またはサービスＣ３０で処理中であるとそのメッセージがロストしてしまう危険性がある。また、閉塞する順序を間違えてはならない運用手順が発生するために、オペレーションミスによる障害が発生する可能性がある。

特開２０１１−５９８８４号公報

クラウド型システムにおいて個々のサービスは独立して運用されているが、システムが大規模になるにつれてサービス間の依存関係も複雑化し、動的な経路選択が行われるようにもなる。このようなシステムにおいて、サービス間の依存関係は複雑かつ動的になっており、依存関係を把握してサービスの活性化操作や閉塞を手動操作するのは困難である。具体的には、動的に宛先サービスが選択される経路において、宛先サービスが選択された直後に後段が閉塞されてメッセージをロストしてしまうといったケースが発生する。また、動的に決定される経路の一部のみを閉塞する場合でも、通常は前段のサービスを閉塞して全経路を停止してから後段のサービスの閉塞を行う。もし運用者が活性や閉塞の順番を間違えると、メッセージのロストといった重大な障害が発生する可能性がある。

本発明は、かかる実情に鑑み、閉塞の安全性を確保したクラウド型システムを提供しようとするものである。

本発明の一実施形態によれば、クラウド型システムにおいて、分散したサービスの依存関係を管理することにより、動的な経路の一部の閉塞と閉塞操作の安全性の確保を実現するものである。

本発明の一実施形態におけるサービスバス装置によれば、クラウド型システムにおいてサービスを管理又は仲介する役目を果たすサービスバス装置において、サービスを活性化する際に、サービスの定義情報から、他のサービスとの依存関係情報を抽出する依存抽出部と、依存関係情報に基づいて、活性化するサービスと依存関係を有するサービスを管理するサービスバス装置に依存情報を送信する運用管理部と、依存情報を登録する依存情報テーブルと、を備え、運用管理部は、サービスを閉塞する際に、依存情報テーブルを参照し、閉塞するサービス又は当該閉塞するサービスに依存するサービスのエントリを依存情報テーブルから削除する。

クラウド型システムにおいてサービスを管理・仲介する役目を果たすサービスバス装置においてサービス間の依存関係情報および動的な経路選択情報を管理する。サービスバスによるサービス間の依存関係および経路選択情報から必要な経路を自動で切り替えることにより、動的な経路の一部のみの閉塞を実現する。また必ず処理中のメッセージが全て掃けてから前段から順に閉塞を行うことでメッセージのロストを防ぐことができる。

本発明によれば、複雑になりがちなクラウド型システムにおける閉塞処理を十分な信頼性を得ることができるという優れた効果を奏し得る。その理由は、サービス間の依存を依存抽出器と依存情報テーブルにより管理することにより、適切な閉塞の順番を割り出し、その順番に従って閉塞処理が実施されるためである。

また、本発明によれば、動的に決まる経路の一部を閉塞できるという優れた効果を奏し得る。その理由は、メッセージカウンタにより動的経路決定部により振り分けられた経路毎にメッセージ処理状況を管理し、閉塞時には運用管理部と協調動作するためである。

本発明の一実施形態に係るサービスバス装置によりサービスが分散したクラウド型システムの概略構成を示すブロック図である。 本実施形態におけるサービスＡ１０の活性化操作のフローチャートを示す。 本実施形態におけるサービスＡ１０からのメッセージ処理のフローチャートを示す。 本実施形態におけるサービスＢの閉塞操作のフローチャートを示す。 本実施形態におけるサービスＡの定義情報の一例を示す。 本実施形態における依存情報テーブルの一例を示す。 本実施形態におけるメッセージカウンタの管理する情報の一例を示す。 従来のクラウド型システムの一例を示す図である。

以下、本発明の実施の形態について図面を参照しつつ詳細に説明する。なお、同一の要素には同一の符号を付し、重複する説明を省略する。

図１は、本発明の一実施形態に係るサービスバス装置によりサービスが分散したクラウド型システムの概略構成を示すブロック図である。同図に示すように、本実施形態では、サービスバス装置Ａ１１とサービスバス装置Ａ１１へメッセージを送信するサービスＡ１０、サービスバス装置Ｂ２１とサービスバス装置Ｂ２１からメッセージを受信するサービスＢ２０、および、サービスバス装置Ｃ３１とサービスバス装置Ｃ３１からメッセージを受信するサービスＣ３０が存在しており、それぞれのサービスバス装置はネットワーク１経由で相互にアクセス可能な状態に設置される。

サービスバス装置Ａ１１は、サービスの活性化・閉塞の運用操作を受け付ける運用管理部１２、サービスの定義から依存関係を抽出する依存抽出部１３、抽出したサービスの依存情報を管理する依存情報テーブル１４、外部からメッセージを受信するメッセージ受信部１５、処理中のメッセージ数をカウントするメッセージカウンタ１６、外部へメッセージを送信するメッセージ送信部１７、サービス定義から宛先サービスを計算する動的経路決定部１８を含む。サービスバス装置Ｂ２１、サービスバス装置Ｃ３１もサービスバス装置Ａ１１と同様の構成を含む。

さらに、運用者がサービスの活性化・閉塞の運用操作を実行するための管理端末１０１がサービスバス装置Ａ１１の運用管理部１２に接続され、同様に管理端末１０２はサービスバス装置Ｂ２１の運用管理部２２に接続されている。各運用管理部１２、２２、３２はネットワーク２により相互にアクセス可能な状態に設置される。

図１に示す実施形態では、サービスＡ１０はサービスＢ２０とサービス３０に依存しており、サービスＡ１０から入力されたメッセージはサービスＢ、サービスＣのどちらかがランダムに選択されて配信される。

次に、図１、５乃至７に示す図、並びに、図２乃至４のフローチャートを参照して、本実施形態の動作について詳細に説明する。なお、図５は、本実施形態におけるサービスＡの定義情報の一例を示す。図６は、本実施形態における依存情報テーブルの一例を示す。図７は、本実施形態におけるメッセージカウンタの管理する情報の一例を示す。

本実施形態における前提として、サービスＡ１０が活性化している間は複数のクライアントから絶えずメッセージが送信されている状態であり、これらのメッセージをサービスＢ２０かサービスＣ３０のどちらか一方にランダムに選択してメッセージを配信し、かつ、サービスＡ１０によりクライアントから受理されたメッセージはクライアントに返信するまでロストしてはならない条件であるとする。なお、本条件はあくまで本実施形態における一実施例を説明するためのものに過ぎず、本発明が本条件を備えることを要するものではない。

このような条件下で、本実施形態における動作を、順を追って説明する。まず、図２に示すフローチャートにより、サービスＡ１０を活性化しサービスを開始する処理の流れを示す。次に、図３に示すフローチャートにより、サービスＡ１０に入力したメッセージを入力する流れを示す。最後に、図４に示すフローチャートにより、サービスＢ２０をリプレースなどといった理由のためにサービスＢ２０を閉塞する処理の流れを示す。

図２は、本実施形態におけるサービスＡ１０の活性化操作のフローチャートを示す。まず、同図に示すとおり、運用者はサービスＡ１０を活性化するために管理端末１０１から運用管理部１２へ活性化操作を実行する（ステップＡ１）。活性化対象であるサービスＡ１０を入力とする定義情報の一例を、図５に示す。この定義情報はサービスバス装置により解釈され、メッセージの呼び出し順序などのルールを定めるものである。サービスＢは、サービスＢおよびサービスＣの抽象名とし、図５の経路はサービスＡから入力されたメッセージをサービスＢかサービスＣに送信し、処理結果を受け取るという意味である。次に、運用管理部１２は活性化されたサービスＡの定義情報を依存抽出部１３に送信し、経路情報から依存するサービスのリストを抽出し依存情報メッセージを生成する。ここではサービスＢとサービスＣがリストされる（ステップＡ２）。次に、運用管理部１２は、サービスＢ２０とサービスＣ３０を管理する各サービスバス装置２１、３１の運用管理部２２、３２に向けて依存情報メッセージを送信する（ステップＡ３）。各サービスバス装置２１、３１の運用管理部２２、３２は依存情報メッセージを受信し、依存情報を依存情報テーブル２４、３４に登録する（ステップＡ４）。このとき登録された依存情報テーブル２４、３４の内容の一例を、図６に示す。活性化操作の最後に、運用管理部１２はメッセージ受信部１５に通知し、サービスＡ１０からのメッセージ受付を開始する（ステップＡ５）。

図３は、本実施形態におけるサービスＡ１０からのメッセージ処理のフローチャートを示す。同図に示すように、まず、サービスＡ１０はメッセージ受信部１５に対してメッセージを送信する（ステップＢ１）。メッセージ受信部１５は動的経路決定部１８に問い合わせ、宛先サービスを決定した後、メッセージ送信部１７にメッセージを渡す。動的経路決定部はここで、図５のサービスＡ１０のサービス定義から、サービスＢ２０かサービスＣ３０のいずれかをから選ぶことになるが、ここではサービスＢ２０を選択したこととする（ステップＢ２）。メッセージ送信部１７は、メッセージカウンタ１６に通知してサービスＢのエントリのカウンタを＋１した後、サービスＢ２０を管理するサービスバス装置２１のメッセージ受信部２５に向けてメッセージを送信する（ステップＢ３）。このとき登録されるメッセージカウンタ１６の内容の一例を、図７に示す。メッセージ受信部２５はメッセージ送信部２７にメッセージを渡す（ステップＢ４）。メッセージ送信部２７はサービスＢ２０にメッセージを送信する（ステップＢ５）。最後に、メッセージ処理がすべて終わったのを受けて、メッセージ送信部１７はメッセージカウンタ１６に通知しカウンタを−１する（ステップＢ６）。このフローにより現在処理中のメッセージを計測することができる。また、このメッセージ処理時のフローは、多数のクライアントからのメッセージ送信を起点にして、同時並行的に連続して実行される。

図４は、本実施形態におけるサービスＢの閉塞操作のフローチャートを示す。同図に示すように、このフローにより、動的な経路により依存されるサービスＡ１０に通知し前段の動的経路の一部から閉塞することで、メッセージ処理が同時並行で連続した動作の最中にサービスＢ２０を安全に停止する。まず運用者が管理端末１０２から運用管理部２２に対してサービスＢ２０の閉塞操作を行う（ステップＣ１）。運用管理部２２は依存情報テーブル２４を参照し、閉塞対象であるサービスＢ２０に依存するサービスのリストを得る。ここではサービスＡ１０が得られる（ステップＣ２）。運用管理部２２はサービスＢ２０に依存するサービスのリスト中のサービスを管理するサービスバス装置にサービスＢ２０が閉塞することを通知する。ここではリスト中にサービスＡ１０を閉塞するのでサービスバス装置１１の運用管理部１２に対して通知する（ステップＣ３）。運用管理部１２は動的経路決定部１８に通知し、サービスＢ２０へのメッセージ振り分けを停止する。その後、メッセージカウンタ１６を参照し、サービスＢ２０に対するカウンタが０になるまで待つ（ステップＣ４）。カウンタが０になったら、サービスＢ２０を管理する運用管理部２２にメッセージ処理がすべて完了した旨を通知する（ステップＣ５）。ここからサービスバス装置２１とサービスバス装置３１で処理が並行で実施される。サービスバス装置２１の運用管理部２２はサービスＢ２０を閉塞する。同時に依存情報テーブル２４からサービスＡ１０のエントリを削除する（ステップＣ６）。

本実施形態では、サービスＢ２０を閉塞するときに、前段であるサービスＡ１０での処理がすべて完了してから前段から順に閉塞することが実現できるように構成されているため、サービス閉塞操作に十分な信頼性を得ることができる。さらに、運用者は単にサービスＢ２０を閉塞するオペレーションを実施するのみであり、簡潔な操作で安全に閉塞操作を実施することができる。

本実施形態において、サービスＢ２０の閉塞に続いてサービスＣ３０を閉塞する場合は、サービスＡ１０で有効な経路が残らないため、同時にサービスＡ１０も自動的に閉塞する。また、本実施形態では、サービスＢ２０に対する前段のサービスはサービスＡ１０の一つのみであったが、前段のサービスが複数ある場合にも適用可能である。

なお、本発明は、上記した実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲内において、他の様々な形で実施することができる。このため、上記実施形態はあらゆる点で単なる例示にすぎず、限定的に解釈されるものではない。例えば、上述の各処理ステップは処理内容に矛盾を生じない範囲で任意に順番を変更して又は並列に実行することができる。

上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限
られない。

（付記１）クラウド型システムにおいてサービスを管理又は仲介する役目を果たすサービスバス装置において、サービスを活性化する際に、前記サービスの定義情報から、他のサービスとの依存関係情報を抽出する依存抽出部と、前記依存関係情報に基づいて、前記活性化するサービスと依存関係を有するサービスを管理するサービスバス装置に依存情報を送信する運用管理部と、前記依存情報を登録する依存情報テーブルと、を備え、前記運用管理部は、サービスを閉塞する際に、前記依存情報テーブルを参照し、閉塞するサービス又は当該閉塞するサービスに依存するサービスのエントリを前記依存情報テーブルから削除する、サービスバス装置。

（付記２）前記運用管理部は、サービスを閉塞する際に、前記依存情報テーブルを参照し、閉塞するサービスに依存するサービスを管理するサービスバス装置に、サービスが閉塞することを通知することを特徴とする付記１記載のサービスバス装置。

（付記３）処理中のタスクの数をカウントするカウンタをさらに備え、前記運用管理部は、サービスを閉塞する際に、前記カウンタを参照し、閉塞するサービスに関連するタスクがなくなったとき、前記依存情報テーブルから、閉塞するサービス及び当該閉塞するサービスに依存するサービスのエントリを削除することを特徴とする付記１又は２記載のサービスバス装置。

（付記４）前記サービスはメッセージの送受信であり、外部からメッセージを受信するメッセージ受信部と、外部へメッセージを送信するメッセージ送信部と、前記定義情報から宛先サービスを計算する動的経路決定部と、を備え、前記カウンタは、処理中のメッセージの数をカウントすることを特徴とする付記３記載のサービスバス装置。

（付記５）クラウド型システムのサービスバス装置においてサービスを管理する方法であって、第１のサービスバス装置が、サービスの活性化操作を受け付けるステップと、前記第１のサービスバス装置が、前記サービスの定義情報から、他のサービスとの依存関係情報を抽出するステップと、前記依存関係情報に基づいて、前記第１のサービスバス装置が、前記活性化するサービスと依存関係を有するサービスを管理する第２のサービスバス装置に依存情報を送信するステップと、前記第２のサービスバス装置が、前記依存情報を依存情報テーブルに登録するステップと、を備えるサービス管理方法。

（付記６）クラウド型システムのサービスバス装置においてサービスを管理する方法であって、第１のサービスバス装置が、サービスの閉塞操作を受け付けるステップと、前記第１のサービスバス装置が、依存情報テーブルを参照し、閉塞するサービスに異存するサービスを管理する第２のサービスバス装置に、サービスが閉塞することを通知するステップと、前記第２のサービスバス装置は、前記通知を受信した後、依存情報テーブルを参照し、閉塞するサービス又は当該閉塞するサービスに依存するサービスのエントリを前記依存情報テーブルから削除するステップと、を備えるサービス管理方法。

本発明によれば、サービスバス装置を使用してサービスを分散するクラウド型システムに適用できる。特にサービスの数が多い大規模なシステムになるほど有用である。

１、２ ネットワーク、１０、２０、３０ サービス、１１、２１、３１ サービスバス装置、１２、２２、３２ 運用管理部、１３、２３，３３ 依存抽出部、１４、２４、３４ 依存情報テーブル、１５、２５、３５ メッセージ受信部、１６、２６、３６ メッセージカウンタ、１７、２７、３７ メッセージ送信部、１８ 動的経路決定部、１０１、１０２ 管理端末

Claims (4)

1. クラウド型システムにおいてサービスを管理又は仲介する役目を果たすサービスバス装置において、
   サービスを活性化する際に、前記サービスの定義情報から、他のサービスとの依存関係情報を抽出する依存抽出部と、
   前記依存関係情報に基づいて、前記活性化するサービスと依存関係を有するサービスを管理するサービスバス装置に依存情報を送信する運用管理部と、
   前記依存情報を登録する依存情報テーブルと、
   処理中のタスクの数をカウントするカウンタと、
   を備え、
   前記運用管理部は、サービスを閉塞する際に、前記カウンタを参照し、閉塞するサービスに関連するタスクがなくなったとき、閉塞するサービス及び当該閉塞するサービスに依存するサービスのエントリを前記依存情報テーブルから削除する、サービスバス装置。
2. 前記運用管理部は、サービスを閉塞する際に、前記依存情報テーブルを参照し、閉塞するサービスに依存するサービスを管理するサービスバス装置に、サービスが閉塞することを通知することを特徴とする請求項１記載のサービスバス装置。
3. 前記サービスはメッセージの送受信であり、
   外部からメッセージを受信するメッセージ受信部と、
   外部へメッセージを送信するメッセージ送信部と、
   前記定義情報から宛先サービスを計算する動的経路決定部と、
   を備え、
   前記カウンタは、前記処理中のタスクの数として、処理中のメッセージの数をカウントし、
   前記運用管理部は、サービスを閉塞する際に、前記カウンタを参照し、閉塞するサービスに関連するタスクとして、閉塞するサービスに関連するメッセージがなくなったとき、閉塞するサービス及び当該閉塞するサービスに依存するサービスのエントリを前記依存情報テーブルから削除することを特徴とする請求項１又は２に記載のサービスバス装置。
4. クラウド型システムのサービスバス装置においてサービスを管理する方法であって、
   第１のサービスバス装置が、サービスの活性化操作を受け付けるステップと、
   前記第１のサービスバス装置が、前記サービスの定義情報から、他のサービスとの依存関係情報を抽出するステップと、
   前記依存関係情報に基づいて、前記第１のサービスバス装置が、前記活性化するサービスと依存関係を有するサービスを管理する第２のサービスバス装置に依存情報を送信するステップと、
   前記第２のサービスバス装置が、前記依存情報を依存情報テーブルに登録するステップと、
   前記第１のサービスバス装置のカウンタが、処理中のタスクの数をカウントするステップと、
   第２のサービスバス装置が、サービスの閉塞操作を受け付けるステップと、
   前記第２のサービスバス装置が、依存情報テーブルを参照し、閉塞するサービスに依存するサービスを管理する第１のサービスバス装置に、サービスが閉塞することを通知するステップと、
   前記第１のサービスバス装置が、前記サービスが閉塞することの通知を受信した後、前記カウンタを参照し、閉塞するサービスに関連するタスクがなくなったとき、前記第２のサービスバス装置に閉塞するサービスに関連するタスクがなくなったことを通知するステップと、
   前記第２のサービスバス装置が、前記閉塞するサービスに関連するタスクがなくなったことの通知を受信した後、閉塞するサービス及び当該閉塞するサービスに依存するサービスのエントリを前記依存情報テーブルから削除するステップと、
   を備えるサービス管理方法。