JP2007249373A - 分散型プログラムの監視システム - Google Patents

Abstract

【課題】分散型プログラムの信頼性の向上と、故障時の自動的かつ迅速な復旧処理を実現すること。
【解決手段】複数のモジュール実行部（エージェント）が互いに所定の依存関係を有して通信を行いながら動作する分散型プログラムの監視システムであって、各エージェントの動作状態を監視する複数の監視実行部と、すべての監視実行部と通信を行い、監視実行部を介してエージェントの動作を管理するホスト監視部を備える。ホスト監視部は、各エージェントごとの監視データを監視実行部から取得し、各エージェント間の重みを測定し、各エージェントごとに分散型プログラムにおける重要度を算出し、算出された重要度に対応させた個数のレプリカを生成し、各エージェントが所定の故障診断基準を満たす動作をしているか否かを確認し、エージェントが故障と判断された場合、そのエージェントのレプリカを起動させ、故障したエージェントの特定の機能を継続させる。
【選択図】図４

Description

この発明は、分散型プログラムの監視システムに関し、特に、複数のモジュールプログラムの相互依存の監視と、問題点が発生した場合のシステム動作の自動復旧を可能とする監視システムに関する。

今日、文書作成，画像編集，通信制御，オペレーティングシステムなどのアプリケーションプログラムが１つのコンピュータ上で多数利用されている。また、インターネットの普及に伴い、ネットワークを介して多数のコンピュータ間で電子商取引が実現されており、電子商取引のホストコンピュータでは一度に大量のデータが処理される。

アプリケーションプログラムの信頼性の向上，機能の追加・更新等への対応、さらにシステムのパフォーマンスの向上と最適化等の観点から、多数のモジュールプログラム（サブプログラム）に分けて作成され、多数のモジュールプログラムの相互作用により、１つのアプリケーションプログラムの機能が実現されている。
すなわち、１つの機能を実現するアプリケーションプログラムは、１つのプログラムではなく、分散したモジュールプログラムの集合体として作成されている。

たとえば、１つのアプリケーションプログラムが、１０個のモジュールプログラム（Ａ１，Ａ２，……Ａ１０）から構成されている場合、１０個のモジュールプログラムの相互の依存関係を定義しておき、その依存関係に従って各モジュールプログラムが動作することにより、そのアプリケーションプログラムの機能が実行される。

しかし、従来は、アプリケーションプログラムが実行中の場合に、どのモジュールプログラムとどのモジュールプログラムとの依存関係が最も強く、最も頻繁に利用されているとか、どのモジュールプログラムの利用頻度が最も高いとか、アプリケーションプログラムのパフォーマンスはどのモジュールプログラムの処理速度に依存するかとか、動作の不具合はどのモジュールプログラムで発生しやすいとかを監視しているものはなかった。

また、動作の不具合が生じるとシステム全体の停止となるような重要なモジュールプログラムについて、同じ内容の複製（レプリカ）をあらかじめ複数作成してコンピュータの作業空間に分散配置しておき、不具合発生時にすぐにレプリカに置きかえることにより耐故障性を向上させることも考えられる。しかし、多数の複製をあらかじめ準備しておくことは製造コストの増大を招き、好ましくない。

一方、電子商取引システムでも、その機能を実現するために、多数の分散型モジュールプログラムを作成しておき、各モジュールプログラムが所定の依存関係に従って協働しながら動作するように構成されている。このような電子商取引システムにおいて、各モジュールプログラムの利用頻度はそれぞれ異なり、たとえば多数のモジュールプログラムとの依存関係のあるモジュールプログラムが故障した場合、その影響がシステム全体に及び、電子商取引システム全体が停止してしまうこともあり得る。

ところで、各モジュールプログラムは、当初の設計仕様どおりに作成され、設計時に考えられた条件に従えば正常に動作するはずであるが、設計時には想定していなかった異常なデータが入力されたり、想定されたデータ量を超える膨大な数のデータが一時に入出力されたために過負荷状態となった場合などでは、システムがダウンしてしまうこともあり得る。

このようなシステムダウンは避けられないにしても、システムの十分な信頼性を確保するためには、迅速なシステムの復旧ができることが望まれる。
システムの迅速な復旧をするためには、少なくとも各モジュールプログラムの現在の動作状態などを監視するモニタリングシステムの導入が不可欠である。たとえば、次の３つの非特許文献にモニタリングシステムが記載されている。
Y. Ishida："An immune network approach to sensor-based diagnosis by self-organization,"Complex Systems, Vol.10, No.1, pp.73-90(1996). G. A. Kaminka, D. V. Pynadath, and M. Tambe："Monitoring teams by overhearing：A muti-agent plan-recognition approach,"Intelligence Artificial Research, Vol. 17, pp. 83-135(2002). B. Holing, B. Benyo, and V. Lesser："Using self-diagnosis to adapt organizational structures,"Proc. Of 5th International Conference on Autonomous Agents, pp. 529-536(2001).

しかし、このようなモニタリングを導入したとしても、モジュールプログラムの追加や削除などシステムの環境変化への適応が難しく、監視にかかるオーバヘッド等のためシステム全体の動作の効率化には直接結びつかず、また、モニタリングにより問題点の分析や不良モジュールプログラムの抽出ができても、迅速な復旧処理をすることはできない。
たとえば、モニタリングシステムで不具合の生じたモジュールプログラムが特定できたとしても、そのモジュールプログラムを正常なものに置きかえるためには、人間の介在が必要であり、迅速な復旧はできない。

そこで、この発明は、以上のような事情を考慮してなされたものであり、監視エージェントプログラムを設け、多数のモジュールプログラムから構成された分散型プログラムの相互依存の監視と、問題点の発生可能性の分析と迅速な復旧処理等が可能な分散型プログラムの監視システムを提供することを課題とする。

この発明は、それぞれ特定の機能を実行する複数のモジュール実行部を監視する分散型プログラムの監視システムであって、各モジュール実行部の動作状態を特定する監視データをそれぞれ収集する複数の監視実行部と、収集された監視データをすべての監視実行部から取得し、前記監視データを用いて各モジュール実行部間の依存関係の深さを示す重みを測定し、重みを用いて各モジュール実行部の重要度を算出し、算出された重要度に対応させた個数のレプリカを各モジュール実行部ごとに生成し、モジュール実行部が故障した場合に、その故障したモジュール実行部のレプリカを起動させ、起動したレプリカに、故障したモジュール実行部の特定の機能を継続して行わせるホスト監視部とを備えたことを特徴とする分散型プログラムの監視システムを提供するものである。

この発明は、それぞれ特定の機能を実行する複数のモジュール実行部が、互いに所定の依存関係を有してデータ通信を行いながら動作する分散型プログラムの監視システムであって、各モジュール実行部の動作状態をそれぞれ監視する複数の監視実行部と、すべての監視実行部とデータ通信を行い、監視実行部を介してモジュール実行部の動作を管理するホスト監視部とからなり、前記監視実行部が、監視対象のモジュール実行部の動作状態を特定する監視データを収集するエージェント通信部を備え、前記ホスト監視部が、エージェント通信部によって収集された各モジュール実行部ごとの監視データを所定のタイミングですべての監視実行部から取得する情報取得部と、取得した監視データを用いて、各モジュール実行部間の依存関係の深さを示す重みを測定する依存関係測定部と、測定された重みを用いて、各モジュール実行部ごとに、分散型プログラムの動作に寄与する程度を示す重要度を算出する重要度判定部と、各モジュール実行部の特定の機能と同じ機能を実行することが可能なレプリカであって、算出された重要度に対応させた個数のレプリカを生成するレプリカ生成部と、各モジュール実行部が予め設定された故障診断基準を満たす動作をしているか否かを確認し、モジュール実行部が故障診断基準を満たさない動作をした場合に、そのモジュール実行部が故障していると判断する故障診断部と、あるモジュール実行部が故障と判断された場合、レプリカ生成部によって生成されたそのモジュール実行部のレプリカを起動させ、故障したモジュール実行部の代わりに、起動されたレプリカに故障したモジュール実行部の特定の機能を継続して行わせる復旧制御部とを備えたことを特徴とする分散型プログラムの監視システムを提供するものである。
これによれば、分散型プログラムの信頼性を向上させ、動的に生成するレプリカの数を決定することによるレプリカのための記憶容量を削減させ，故障復旧時の人間の介在をできるだけ排除し、復旧処理の迅速化をすることができる。

また、前記依存関係測定部は、２つのモジュール実行部の間で送受信されるデータの通信量およびパケット数に基づいて、その２つのモジュール実行部間の重みを測定することを特徴とする。

さらに、前記重要度判定部は、測定された重みのうち注目するモジュール実行部に関連する重みを抽出し、抽出された重みに対して相加平均を含む集合演算を行うことにより、その注目したモジュール実行部の重要度を算出することを特徴とする。

また、前記故障診断基準は、注目しているモジュール実行部が通信停止状態にないこと、注目しているモジュール実行部が単位時間当たりの所定のデータ受信数およびデータ送信数を超える通信過負荷状態にないこと、モジュール実行部が停止状態にないこと，およびモジュール実行部間でやり取りされるメッセージの一部または全部が脱落しないことを少なくとも含むことを特徴とする。

また、前記レプリカ生成部は、注目するモジュール実行部ｉのレプリカを生成する場合、次式で与えられる数repiのレプリカを生成することを特徴とする。
repi＝round〔r₀+rmax＊（wi／W）〕
ここで、repi：生成されるレプリカの数，round〔ｘ〕：数値ｘを超えない整数，ｒ₀：レプリカの数の初期値，rmax：レプリカ総数，ｗｉ：重み，Ｗ：全モジュール実行部の重みの合計値，ｉ：注目するモジュール実行部の識別番号である。

この発明において、モジュール実行部とは、分散型プログラムにおける１つのモジュールプログラムに相当し、以下の実施例では、モジュールプログラムあるいはエージェント（Ａ１等）と呼ぶ。
モジュール実行部が互いに依存関係を有するとは、２つのモジュール実行部の間にデータ通信が行われていることを意味する。この依存関係には、モジュール実行部Ａからモジュール実行部Ｂへの一方向通信、モジュール実行部Ｂからモジュール実行部Ａへの一方向通信、およびモジュール実行部ＡおよびＢ間での双方向通信の３つのケースが存在する。

監視実行部とは、監視目的の１つのモジュールプログラムであり、１つのモジュール実行部に対応させて必ず１つの監視実行部が設けられる。監視実行部は、以下の実施例では、監視エージェントプログラムあるいはモニタプログラム（ＭＰ）と呼ぶ。

ホスト監視部とは、分散型プログラムそのものの動作を管理するためのプログラムに相当し、具体的には分散型プログラムを形成するすべてのモジュール実行部の監視および制御を行うプログラムである。以下の実施例では、ホスト監視部は、ホストモニタエージェントプログラムあるいはホストプログラム（ＨＰ）と呼ぶ。

この発明の監視データとは、モジュール実行部に入出力されるデータの通信量などに関する情報であるが、詳細は後述する。このような監視データは、定期的あるいは監視実行部からの監視要求に対する応答として不定期のタイミングで収集される。

この発明の重みとは、モジュール実行部間の依存関係の深さを示す数値指標であるが、重みの数値が大きいほど２つのモジュール実行部間の依存関係が深いこと、言いかえれば結びつきが強いことを意味する。
具体的には、重みの数値が大きい場合とは、たとえば、２つのモジュール実行部間の一定時間当りのデータ通信量あるいは通信頻度が相対的に多いこと、または送受信されるパケット数が相対的に多いことを意味する。
逆に、２つのモジュール実行部の間の重みの数値がゼロの場合、その２つのモジュール実行部どおしは依存関係がないこと、すなわち直接的なデータ通信が全くないことを意味する。

この発明の重要度とは、分散型プログラムの動作に寄与する程度を示す数値指標であるが、重要度が大きいほど、そのモジュール実行部の寄与程度が大きいことを意味する。言いかえれば、重要度の大きいモジュール実行部は、相対的に稼働率が高く、もし動作が停止すると他のモジュール実行部への影響が大きく、分散型プログラム全体の動作速度の低下や動作不良の原因となりやすいという性質があることを意味する。
具体的には、たとえば、重要度の大きいモジュール実行部は、他のモジュール実行部よりも相対的にデータ通信量や送受信パケット数が大きく、そのモジュール実行部の停止故障は、直接的な依存関係にあるモジュール実行部のみならず、直接的な依存関係にないモジュール実行部の動作速度の低下の原因となりうることを意味する。また、重要度は、生成するレプリカの数（配置数）を動的に決定するために用いられる指標である。

また、監視データの取得，重みの測定，重要度の算出，およびレプリカの生成などの一連の処理は、定期的にあるいは監視要求に対して不定期に行われる。そして重みや重要度の数値は動的に更新され、生成すべきレプリカの数も動的に更新される。
この発明では、レプリカのために設計時に予め用意される記憶容量には上限があるので、レプリカの総数（rmax）は固定値として与えられる。したがって、このレプリカ総数の範囲内で、算出された重要度に基づいて各モジュール実行部に割り当てるべきレプリカの数が動的に決定される。

なお、上記したエージェント通信部，情報取得部，依存関係測定部，重要度判定部，レプリカ生成部，故障診断部，復旧制御部などは、それぞれ特有のロジック素子を用いたハードウェアモジュールとして構成することもできるが、ＣＰＵ，ＲＯＭ，ＲＡＭ，Ｉ／Ｏコントローラ，タイマー等からなるマイクロコンピュータと、それぞれの特定の機能を実現させるプログラムとによって構成することもできる。

また、複数のモジュール実行部が１つのコンピュータ装置にすべて含まれている場合、この発明の監視システムの監視実行部およびホスト監視部も同じ装置に含めてもよく、あるいは、監視システム自体は別の筐体の装置に実装し、通信回線でコンピュータ装置と接続する構成としてもよい。
さらに、複数のモジュール実行部がそれぞれ異なる場所に配置されたコンピュータ装置に実装され、これらのコンピュータ装置がネットワークで接続されている場合、監視実行部およびホスト監視部は、上記のコンピュータ装置のうちいずれかあるいは別の筐体として、上記ネットワーク上に実装することができる。

この発明によれば、各モジュール実行部の動作状態をそれぞれ監視する監視実行部と、全体動作を管理するホスト監視部とを設けて、モジュール実行部相互間の依存関係を動的に監視し、動的に求められた重みなどの指標を用いて故障発生時の復旧処理をしているので、分散型プログラムにおける全体動作の信頼性の向上と、故障復旧時の人間の介在をできるだけ排除して復旧処理の迅速化が可能である。
また、各モジュール実行部から取得した監視データをもとにして動的にレプリカを生成しているので、レプリカ総数が比較的少なくても、復旧動作が正常に迅速に実行でき、レプリカのために用意される記憶容量を削減でき、資源の有効利用ができる。

以下、図に示す実施例に基づいて本発明を詳述する。なお、本発明はこれによって限定されるものではない。
＜この発明の監視システムの概要＞
図１および図２を用いて、この発明の監視システムの動作の概要を説明する。
図１は、分散型プログラムの一実施例の監視状態（相互依存グラフ）を示している。ここで、分散型プログラム１００は、たとえば１つのアプリケーションプログラムであり、その機能は、７つのモジュールプログラム（Ａ１〜Ａ７）によって実現されるものとする。
１つのモジュールプログラム（たとえばＡ１）を、以下、エージェントとも呼ぶことにする。

図１では、これら７つのモジュールプログラムの相互依存関係を、矢印つきの直線で示している。
たとえば、エージェントＡ１は、エージェントＡ２およびＡ５と依存関係があり、Ａ１とＡ２の間では、相互にデータが送受信されることを示している。また、エージェントＡ１とＡ５との間では、Ａ１からＡ５に対してデータが送信されるが、Ａ５からＡ１へのデータの送信はなく、Ａ１からＡ５へ向かっての一方向の依存関係があることを示している。
また、図１の「Ｗ１２」や「Ｗ２１」という記号（Ｗｉｊ：ｉ＝１〜７）は、その矢印方向のデータ送信の重みを示している。すなわち、２つのエージェント間の重みは、データ通信の方向ごとに与えられ、そのデータ通信による２つのエージェント間の依存関係の深さ（結びつきの強さ）が、重みとして表される。

図３に、各エージェントどおしの重み（Ｗｉｊ）の具体例を示す。
たとえば、図３では、エージェントＡ１からＡ５へのデータ送信については、Ａ１が影響を与える側（送信側）であり、Ａ５が影響を受ける側（受信側）であり、その重みはＷ₁₅＝０.２である。言いかえると、エージェントＡ１からＡ５へのデータ送信による２つのエージェント（Ａ１とＡ５）間の依存関係の深さを表す数値がＷ₁₅＝０.２である。
逆に、図１にはＡ５からＡ１へ向かうデータ送信はないので、図３では、Ｗ₅₁＝０である。
同様に、図３においては、Ａ１からＡ２へのデータ送信の重みＷ₁₂は０.１であり、Ａ２からＡ１へのデータ送信の重みはＷ₂₁は０.２である。

図１のような状態を示す図を、エージェントの相互依存グラフと呼ぶ。
相互依存グラフは、後述するような監視エージェントプログラムおよびホストモニタエージェントプログラムを備えることにより作成される。
このような相互依存グラフは、利用者が現在のプログラムモジュールの動作状態を確認するために、図１のままＣＲＴなどの表示装置に表示してもよい。また、このようなグラフは、定期的（たとえば１秒ごとに）に更新し、ほぼリアルタイムで動作状態を把握できるようにしてもよい。
また、エージェント間の重みＷｉｊは、初期値として固定的に与えてもよいが、そのまま固定値として使用するのではなく、各エージェント間で送信されるデータ量やデータの種類などの情報を収集して、実際の動作状況に応じて動的に更新することが好ましい。

監視エージェントプログラムとは、分散型プログラムのモジュールプログラムの現在の動作状態を監視するプログラムであり、モジュールプログラムと１対１に対応させて設けられる。たとえば、図１の場合、７つの監視エージェントプログラムが設けられ、それぞれ１つのモジュールプログラムの監視を行う。
また、モジュールプログラムＡ１を監視する監視エージェントプログラムは、モジュールプログラムＡ１の単位時間当たりのデータ通信パケット数などの情報を、モジュールプログラムＡ１から収集する。監視エージェントプログラムは、以下、モニタプログラム（ＭＰ）とも呼ぶ。

ホストモニタエージェントプログラムは、この発明の監視システム内で唯一存在し、すべての監視エージェントプログラムに接続され、監視エージェントプログラムで収集されたすべての監視データを受信し、この監視データに基づいて後述する一連の処理（相互依存測定，重要度判定，レプリカ生成，故障診断，復旧処理）を実行するものである。
ホストモニタエージェントプログラムは、以下、ホストプログラム（ＨＰ）とも呼ぶ。

図１のグラフから、システムの十分な信頼性を確保するためにどのエージェントが重要であるかを判断できる。
たとえば、図１のグラフを見ると、直感的には、エージェントＡ５は、他の多くのエージェントとの結びつきがあるので、このエージェントＡ５が故障すると、分散型プログラムのシステム全体が大きな影響を受けることが予想される。
一方、エージェントＡ７が故障した場合、エージェントＡ５からのデータの受信に影響が出るだけで、エージェントＡ１からＡ６までの動作はそれほど大きな影響を受けないことが予想される。

そこで、後述するような重要度を定義し、図１のグラフを基にして、各エージェント間のデータ通信量，相互依頼関係にあるエージェント数，送信メッセージ数，データセット数（データの種類の数）などを用いて各エージェントの重要度を求める。この重要度は、後述するエージェントの複製（レプリカ）の生成処理や復旧処理に利用される。
ここで、エージェントの重要度とは、エージェントが分散型プログラムの動作に寄与する程度を示す数値であり、そのエージェントが故障した場合にシステム全体に及ぼす影響の大きさを表す指標である。言いかえれば、故障した場合に復旧すべき優先順位に相当し、レプリカを準備しておくべき順位に相当する。

図１の場合、エージェントＡ５の優先度が最も高いと判断されると、エージェントＡ５が故障する前に、エージェントＡ５の複数個のレプリカを予め作成（複製）しておく。
そして、エージェントＡ５が故障したと判断された場合には、すぐに自動的にエージェントＡ５を、予め作成されていたレプリカに置き換えて、動作を継続させる。
レプリカとは、各エージェントが実行する特定の機能と同じ機能を実行することが可能なモジュールプログラムをいう。
また、レプリカは、算出された重要度に対応させた個数だけ、動的に生成される。

システムの安定性の観点からは、すべてのエージェントについてシステムの動作前に、それぞれ少なくとも１つのレプリカを予め作成し記憶しておくことが好ましい。しかし、数千というような多数のエージェントが存在する場合には、レプリカのために膨大な記録容量を予め用意しておく必要があり、コストがかかりすぎ経済的でない。
また、実際のシステムの動作時においては、年に数回程度しか故障が発生しないというような故障の頻度がかなり少ない場合もあり、そのような場合にまで、一律に、すべてのエージェントのレプリカを予め準備しておくのは、やはりコストがかかりすぎる。

そこで、この発明では、重要度というパラメータを用いて比較的重要と判断されたエージェントに対して多くのレプリカを予め作成するようにし、重要でないと判断されるエージェントに対してはレプリカは作成しないかあるいは高々１つ作成する。これにより、レプリカ用の記憶容量を削減してシステムの低コストを図る。すなわち、エージェントの重要度に対応させてレプリカを生成する数を制御することにより、レプリカのために準備する記憶容量をできるだけ抑制させる。

図２に、一実施例として、プログラムモジュール（エージェント）Ａ６−１が故障した場合を示した相互依存グラフを示す。
図２において、エージェントＡ６−１が起動中であったが、何らかの原因（たとえば過負荷）により、故障したとする。故障とは、たとえば、過負荷のため、そのモジュールプログラム（エージェント）の動作が非常に遅くなった場合、本来出力すべきデータを送信しなくなった場合、想定外の動作（誤動作）をした場合など、その機能を停止した状態や、停止状態とみなされる状態をいう。一般的には、エージェントが、予め設定された故障診断基準を満たす動作をしているか否かを確認し、エージェントがその基準を満たさない動作をした場合に、そのエージェントが故障していると判断する。

故障診断基準としては、次のようなものが考えられる。
（ａ）現在注目しているエージェントが通信停止状態にないこと。
（ｂ）現在注目しているエージェントが単位時間当たりの最大データ受信可能数およびデータ送信可能数を超える通信過負荷状態にないこと。
（ｃ）現在注目しているエージェントが動作停止状態にないこと。
このような基準を満たさない場合に、エージェントが故障したと判断する。

エージェントが故障したか否かの判断の具体例としては、たとえば、モニタプログラム（ＭＰ）が常時エージェントの一定時間内の受信データ量を測定しておき、予め決められた最大受信量を超えるデータがその時間内に受信された場合に過負荷による故障と判断する。あるいは、データが送信されたときにタイマーをリセットするようなウォッチドックタイマーを起動させておいて、一定時間経過してもデータ送信がなく、ウォッチドッグタイマーがタイムアウトした場合に、送信不能による故障と判断する。

図２に示した実施例では、エージェントＡ６−１が故障すると、相互依存関係にあるエージェントＡ３とＡ５に対するデータ通信が不能となる。この場合、エージェントＡ６−１を監視していたモニタプログラム（ＭＰ）が、データ通信量の異常を検知することによりＡ６−１が故障したと判断する。あるいは、エージェントＡ３またはＡ５を監視しているモニタプログラム（ＭＰ）が、エージェントＡ６−１に対する通信状態を監視することにより、エージェントＡ６−１の故障を判断することもできる。
また、ホストプログラム（ＨＰ）が、エージェントＡ３，Ａ５およびＡ６をそれぞれ監視するモニタプログラム（ＭＰ）から取得した情報（データ通信量，送信パケット数など）に基づいて、予め定めた診断基準を満たさなくなったときにエージェントＡ６−１が故障したと判断してもよい。
なお、モニタプログラム（ＭＰ）が、エージェントＡ６−１が故障であると判断した場合は、そのモニタプログラム（ＭＰ）がＡ６−１が故障したという情報を、ホストプログラム（ＨＰ）に送ればよい。

エージェントＡ６−１が故障したと判断した場合、ホストプログラム（ＨＰ）は、予め準備していたエージェントＡ６−１のレプリカ（Ａ６−２）を呼び出し、エージェントＡ６−１の現在の全機能をエージェントＡ６−２に引き継ぐように制御し、エージェントＡ６−１を監視していたモニタプログラム（ＭＰ）に対して、新しいエージェントＡ６−２を監視するよう制御する。
すなわち、エージェントＡ６−１の代わりに、予め生成されていたレプリカＡ６−２を新しいエージェントとして起動させ、起動されたレプリカＡ６−２に、故障したエージェントの特定の機能と同じ機能を継続して行わせる。以後、エージェントＡ３およびＡ５は、この新エージェントＡ６−２とデータ通信を行うように制御する。故障したエージェントＡ６−１は他のエージェントから切り離され停止させられる。

＜監視システムの概略動作の説明＞
図４に、この発明の監視システムの概略動作のフローチャートを示す。
まず、ステップＳ１（監視処理）において、各監視エージェントプログラム（ＭＰ）が予め対応づけられたモジュールプログラム（エージェント）と通信を行い、そのエージェントの監視データを収集する。
監視データとは、たとえば、通信負荷量，プロセス実行時間の数値的な指標，相互作用を実行するためのプロトコル，送受信メッセージ数，データセット数等を意味する。

ステップＳ２（依存関係測定）において、ホストモニタエージェントプログラム（ＨＰ）が、各監視エージェントプログラム（ＭＰ）によって収集された監視データを受信し、エージェントどおしの依存関係を測定し、重みを求めて、図１のような依存関係グラフを作成する。
ステップＳ３（重要度判定）において、ホストモニタエージェントプログラム（ＨＰ）が、各エージェント間の重みと依存関係グラフから、各エージェントの重要度を判定する。

ステップＳ４（レプリカ生成）において、ホストモニタエージェントプログラム（ＨＰ）が、重要度に対応させて、各エージェントごとの適切なレプリカの数を算出し、その数に相当するレプリカを生成する。
ステップＳ５（故障診断処理）において、ホストモニタエージェントプログラム（ＨＰ）が、所定の故障診断基準を参照してリアルタイムで収集された監視データを分析することにより、各エージェントが故障していないかどうかを診断する。
ステップＳ６において、故障していない場合は、ステップＳ１へ戻り、一連の処理（Ｓ１〜Ｓ５）を繰り返す。一方、あるエージェントが故障と判断された場合は、ステップＳ７（復旧処理）へ進み、そのエージェントの復旧処理、すなわち、エージェントを新しいレプリカへ切替える処理を行う。

以上のように、この発明では、各モジュールプログラムの動作状態を監視し（監視処理）、相互依存関係をグラフ化して（依存関係測定処理）、各モジュールプログラムの重要度をリアルタイムで算出し（重要度判定処理）、その重要度に応じて動的にレプリカを生成させ（レプリカ生成処理）、所定の故障診断基準に基づいてリアルタイムで故障診断をし（故障診断処理）、その結果、故障と判断されたモジュールプログラムを予め生成されていたレプリカに置きかえる（復旧処理）。
これにより、分散型プログラムの信頼性を向上させ、モジュールプログラムの追加，削除，変更等があった場合でも相互依存の監視が可能で、故障発生時に迅速に自動的に復旧処理が可能な低コストの監視システムを実現することができる。

＜この発明の機能ブロックの説明＞
図５に、この発明の監視システムの一実施例の機能ブロック図を示す。
図５に示すこの発明の監視システムは、監視対象である分散型プログラム１００と、監視プログラム群（１０１，１３０）とからなる。
分散型プログラム１００は、たとえば１つのアプリケーションプログラムに相当し、その機能を実現するために、多数のモジュールプログラム群１４０（Ａ１〜Ａ７）から構成される。図５では、７つのモジュールプログラム（Ａ１〜Ａ７）からなる分散型プログラムを示しているが、これに限るのではなく、一般にｎ個（ｎ≧１の整数）のモジュールプログラムから構成される。

これらの７つのモジュールプログラムが有機的に相互にデータ通信を行うことにより、アプリケーションプログラムの機能が実現される。
これらのモジュールプログラム（Ａ１〜Ａ７）は、１つのコンピュータに内蔵されてもよく、あるいは、それぞれ別々のコンピュータに配置され、ネットワークを介して相互に接続されるような構成でもよい。

また、レプリカを格納したレプリカデータベース１５０が備えられる。レプリカとは、前記したようにエージェントが実行する特定の機能と同じ機能を実行することが可能なモジュールプログラムであるが、分散型プログラム１００の通常の起動時には動作はしていないが、復旧処理によって代替されるモジュールプログラムとなるべきものである。レプリカデータベース１５０の中のレプリカは、分散型プログラム１００の中に含まれるものであるが、モニタプログラムＭＰ１３０によって活性化されることにより１つのモジュールプログラムとして機能するものである。この観点からレプリカデータベース１５０は、分散型プログラム１００とモニタプログラムＭＰ１３０との中間位置に存在すると言える。レプリカデータベース１５０は、たとえばハードディスク内に設けられる。

監視プログラム群は、２つの階層（レベル）からなり、上位レベルに位置するホストモニタエージェントプログラム１０１（ホストプログラム：ＨＰ）と、下位レベルに位置する監視エージェントプログラム１３０（モニタプログラム：ＭＰ）とから構成される。
モニタプログラムＭＰ１３０は、予め１つのモジュールプログラム１４０と対応づけられて配置され、その対応づけられたモジュールプログラム（エージェント）１４０の動作状態を監視するものである。
したがって、モニタプログラム１３０（ＭＰ１〜ＭＰ７）は、モジュールプログラム１４０（Ａ１〜Ａ７）の数と同数設けられる。
ホストプログラムＨＰ１０１は、１つだけ設けられ、すべてのモニタプログラム（ＭＰ）１３０に接続され、各モニタプログラムＭＰの動作制御と、モニタプログラムＭＰ１３０を介して、分散型プログラム１００の監視と復旧処理を行うものである。
モニタプログラムＭＰ１３０は、主として監視部１３１，ホスト通信部１３２，エージェント通信部１３３，情報記憶部１３４，故障診断部１３５から構成される。

モニタプログラムＭＰ１３０とエージェント１４０とは、エージェント通信部１３３を介して、一定時間ごと、あるいはモニタプログラムＭＰからの監視要求とその応答によって、データ通信を行う。たとえば、モニタプログラムＭＰ２からエージェントＡ２への監視データ要求信号の送信により、これに対する応答としてエージェントＡ２からモニタプログラムＭＰ２へ監視データが送られる。
この監視データとは、たとえば、エージェントの通信負荷量（たとえば、一定時間当りの送信パケット数，バイト数），監視対象のエージェントから他のエージェントへ送信されたメッセージ数，監視対象のエージェントが他のエージェントから受信したメッセージ数），相互依存関係にあるエージェント数，データセット数，単位時間当たりの実行時間などを意味する。
これらの監視データは、情報記憶部１３４に記憶され、定期的に更新される。

ホスト通信部１３２は、ホストプログラム（ＨＰ）１０１の情報取得部１１３および復旧制御部１１６と通信を行う部分である。たとえば、情報取得部１３４に記憶された監視データを、ホストプログラムＨＰからの要求に基づいて情報取得部１１３へ送信する。また、復旧制御部１１６からレプリカ更新やレプリカの切替のための要求信号を受信する。
故障診断部１３５は、エージェント１４０から受信した監視データを用いて、そのエージェント１４０が正常かあるいは故障しているかを診断する部分である。ただし、ホストプログラムＨＰが故障診断部１１５を備えているので、モニタプログラム１３０の故障診断部１３５はなくてもよい。
監視部１３１は、上記ホスト通信部１３２などの各機能ブロックの動作を制御する部分である。

ホストプログラムＨＰ１０１は、主として、情報取得部１１１，依存関係測定部１１２，グラフ生成部１１３，重要度判定部１１４，レプリカ生成部１１５，故障診断部１１６，復旧制御部１１７，監視データ記憶部１１８，およびシステム制御部１１９とから構成される。
情報取得部１１１は、モニタプログラムＭＰ１３０から監視データなどを受信する部分である。
依存関係測定部１１２は、取得した監視データを用いて各エージェント間の依存関係を測定する部分である。すなわち、どのエージェントとどのエージェントとがデータ通信を行っているかを判断し、そのデータ通信が一方向かあるいは両方向なのか、データ通信でやりとりされている通信メッセージ数はどのくらいあるか，データセット数はどのくらいあるかなどを検出する部分である。さらに、ここでは、図１や図３に示した重みＷｉｊを算出する。この依存関係や重みは、所定のタイミング（たとえば、定期的に）で、動的に更新される。

グラフ生成部１１３は、依存関係測定部１１２で検出した情報を用いて、図１のような分散型プログラム全体の相互依存グラフを作成する部分である。
重要度判定部１１４は、依存関係測定部１１２で検出した情報や重みを用いて所定の演算を行い、各エージェントの重要度を算出する部分である。この重要度は、主としてエージェントのデータ通信量の大きさ（通信負荷，バイト数）と、送信メッセージの数とから求められるパラメータである。この重要度が大きいエージェントは、相対的に重要であり故障により停止した場合、分散型プログラム全体への影響が大きいものであり、分散型プログラム全体は、その重要度の大きなエージェントに依存する割合が高いと言うことができる。エージェント相互間の依存関係や重みは時間の経過とともに変化する場合があるので、重要度も動的に変化する。

レプリカ生成部１１５は、重要度判定部１１４により算出した重要度を用いて、各エージェントごとにレプリカを生成する部分である。レプリカは、エージェントの重要度に基づいて、動的に各エージェントに配分される。
一般にハードディスクなどの記録容量には上限があるので、レプリカデータベース１５０の中に予め準備しておくレプリカの総数は設計時に固定的に決められる。
そこでレプリカ総数（最大値）の範囲内で、重要度判定部で算出した重要度に基づいて、どのエージェントにどれだけの数のレプリカを割り当てるべきかを動的に決定する。たとえば、レプリカの総数が１０個の場合、初期値として７つの各エージェント（Ａ１〜Ａ７）に１つずつレプリカを配分するものとすると、残りの３つのレプリカは、比較的重要度の高いエージェントに優先的に割り当てる。

たとえば、重要度の最も高いエージェントＡ５に３つのレプリカが配分されたとすると、代替するレプリカが３つ存在するので、動作中のエージェントＡ５が３回故障しても、容易に復旧が可能であり、継続的な正常な動作が保証される。逆に、レプリカが１つしかないエージェントは、１つのレプリカを使用した後２回目の故障が発生すると、動作不能となり、自動復旧ができなくなる。

故障診断部１１６は、情報取得部１１１が取得した監視データを調査し、予め定められた診断基準に基づいて、各エージェントが故障していないか否かを判断する部分である。たとえば、通常１０秒間に１００００パケット以上のデータ送信を行っているエージェントＡ４が、ある一定時間（１０秒）経過しても送信パケット数がゼロであったとすると、そのエージェントＡ４を故障と判断する。
復旧制御部１１７は、故障診断部１１６によって故障と判断されたエージェントを、レプリカ生成部１１５で予め生成されていたレプリカに置きかえる処理を行う部分である。
この復旧処理により選択されたレプリカが新しいモジュールプログラムとして起動され、故障したエージェントに置きかわり、故障したエージェントと同じ機能を継続して行う。

監視データ記憶部１１８は、情報取得部１１１で取得された監視データ，生成されたグラフ，算出された重みＷｉｊ，重要度などのデータを保存する部分である。
また、重要度の判定基準となるルールや条件および，重要度の算出式，故障診断のための診断基準などを予め記憶しておく部分である。
システム制御部１１９は、上記の各機能ブロック（１１１〜１１８）を有機的に結合させて、この発明の監視システムの全体の動作をコントロールする部分である。

以下に、図４および図５に示した各機能ブロックの具体的処理内容の実施例について説明する。
＜情報取得，監視処理＞
図６に、この発明の情報取得および監視処理の一実施例の説明図を示す。
この処理は、図４のエージェントの監視処理（ステップＳ１）に相当する。
図６では、３つのエージェント（Ａ１，Ａ２，Ａ３）と、これらをそれぞれ監視する監視エージェントプログラム（モニタプログラム：ＭＰ１，ＭＰ２，ＭＰ３）と、監視エージェントプログラムから監視情報を取得するホストモニタエージェントプログラム（ＨＰ）とからなる監視システムを示している。ただし、エージェントとモニタプログラムの数は３つに限られるものではなく、設計時のモジュールプログラム（エージェント）の数によって決定される。
また、稼動後に設計変更や修理・改良があった場合、エージェントの追加，削除により、エージェントの数は増減する場合もある。

図６において、エージェントＡ１は、エージェントＡ２に対して相互にデータ通信を行い、エージェントＡ３に対してはデータ送信を行うがエージェントＡ３からのデータ受信はないものとする。また、エージェントＡ３からＡ２へデータ送信はあるが、逆のデータ送信はないものとする。
このような相互依存関係にある各エージェント（Ａ１，Ａ２，Ａ３）は、それぞれモニタプログラム（ＭＰ１，ＭＰ２，ＭＰ３）により監視される。たとえばモニタプログラムＭＰ３からの監視要求を受信することにより、エージェントＡ３は、現在のデータ通信状態を示すデータ（監視データ）をモニタプログラムＭＰ３へ送信する。あるいは監視要求がなくても、定期的に監視データをモニタプログラムへ送信する。

ここで、監視要求とは、たとえば、各エージェントに監視データをモニタプログラムに送信するよう要求するプロトコルのデータをいう。
監視データは、監視要求に対する応答データであり、前記したように、「通信負荷量」，「プロセス実行時間等の数値的な指標」，「相互作用を実行するためのプロトコル」などをいう。
「通信負荷量」とは、具体的には、たとえば、一定時間当たりの送信パケット数やバイト数を意味する。
「プロセス実行時間等の数値的な指標」とは、具体的には、単位時間当たりのＣＰＵ実行時間などを意味する。
「相互作用を実行するためのプロトコル」とは、具体的には、どのエージェントからどのようなメッセージがどのエージェントに送られるかという指示内容を意味する。

モニタプログラム（ＭＰ）のエージェント通信部１３３が、それぞれ監視対象のエージェント（Ａ１〜Ａ３）から監視データを受信すると、監視部１３１は、情報記憶部１３４に監視データを一時的に保存する。
たとえば、モニタプログラムＭＰ２が、エージェントＡ２に対して監視要求を送信すると、エージェントＡ２は、エージェントＡ１から受信したデータのパケット数，バイト数，送信メッセージ数などからなる監視データを、モニタプログラムＭＰ２へ送信する。

一方モニタプログラム（ＭＰ１，ＭＰ２，ＭＰ３）どおしは、相互にデータ通信することはなく、各モニタプログラムが取得した監視データは、ホストプログラムＨＰへ送られる。すなわちホスト通信部１３２と情報取得部１１１との間でデータ通信が行われる。
モニタプログラムＭＰは、個々の監視データをそのままホストプログラムＨＰへ送信してもよいが、監視対象エージェントの依存関係の深さなどを算出した後に、監視情報としてホストプログラムＨＰへ送信してもよい。

また、ホストプログラムＨＰとモニタプログラムＭＰの間の通信はさまざまなタイミングで実行されるが、たとえば、ホストプログラムからのポーリングによる要求信号の送信に対する応答として監視情報を送信すればよい。
ホストプログラムＨＰからモニタプログラムＭＰへ送信される情報としては、たとえば、監視データの収集指令，復旧制御指令のようなデータがある。
逆に、モニタプログラムＭＰからホストプログラムＨＰへ送信される情報としては、たとえば、エージェントの監視データ，レプリケーションの状況，レプリケーションの成否などののようなデータがある。

このように、ホストプログラムＨＰは、モニタプログラムＭＰを介して、すべてのエージェントの状態を示す監視データを取得し、監視データ記憶部１１８に保存する。
ホストプログラムＨＰに収集された監視データはシステム起動時からすべて保存しておいてもよいが、リアルタイムでできるだけ現状に対応した故障診断や復旧処理をするために、所定の基準に基づいて古いデータは削除し、蓄積する情報を動的に更新するようにしてもよい。

＜依存関係の測定、グラフの作成処理＞
次に、ホストプログラムＨＰの依存関係測定部１１２が、監視データ記憶部１１８に保存された監視データを用いて、エージェント（Ａ１，Ａ２，Ａ３）相互間の依存関係を示すパラメータを算出する。
具体的には、図１，図３に示した「重みＷｉｊ」を算出する。さらに、算出された重みＷｉｊを用いて、グラフ生成部１１３が図１のような依存関係グラフを生成するか、あるいは更新する。生成されたグラフは、必要に応じて、図示しないＣＲＴ，ＬＣＤなどの表示部に表示し、ユーザに提供される。

図７に、この発明の依存関係の測定処理の一実施例の概略フローチャートを示す。
ここでは、取得された「通信負荷データ(Qtemp)」と、「送信メッセージ数(NMtemp)」とを用いて、各エージェントごとに、重みＷｉｊを算出するフローチャートを示している。
ステップＳ１１において、変数ｉ，ｊ，ｍなどに初期値をセットする。
ステップＳ１２において、ある監視時間間隔（Δｔ）における通信負荷Qtempを求める。ここでＱｉ，ｊ（Δｔ）は、ある時間間隔Δｔにおけるエージェントｉからエージェントｊへの方向の通信負荷量であり、Ｑ（Δｔ）は、あるエージェントの時間Δｔにおけるすべての通信負荷量の平均値である。

ステップＳ１３において、同じ監視時間間隔（Δｔ）における送信メッセージ数NMtempを求める。ここで、ＮＭｉ，ｊ（Δｔ）は、ある時間間隔Δｔにおけるエージェントｉからエージェントｊへの送信メッセージ数であり、ＮＭ（Δｔ）はあるエージェントの時間Δｔにおけるすべての送信メッセージ数の平均値である。

ステップＳ１４において、所定の計算式を用いて、重みWi,j(t+Δt)を算出する。
ここで、Wi,j(t)は、ある時刻ｔにおいて算出された重みの値であり、Wi,j(t+Δt)はΔｔだけ時間が経過した後の重みの値を意味する。
また、αとは、既存の重みに対して新しく算出した重みをどれくらいの割合で反映させるかを決める割引率を意味し、たとえば、０以上１以下の数値であり、具体的には一例としてその数値はα＝１に設定される。
また、operator３とは、集合演算子であり、たとえば相加平均，相乗平均などを用いることができる。どの演算を用いるかは、Qtemp，NMtempで用いる指標の内容などによって決められる。具体例としては、ステップＳ１２で算出されたQtempと、ステップＳ１３で算出されたNMtempに対して、相加平均演算を行う。

ステップＳ１４において、ある２つのエージェント（ｉとｊ）間の重みＷｉｊが求められるが、すべてのエージェント相互間の重みＷｉｊを求めるために、変数ｉ，ｊをインクリメントとして、上記ステップＳ１１からＳ１４までの処理を繰り返す（ステップＳ１５）。
以上の処理により、図３に示したような重みＷｉｊがすべて算出される。また、どのエージェントとどのエージェントとがデータ通信の依存関係にあるかは、予め監視データ記憶部１１８に記録しておけばよい。あるいは、取得されたメッセージ通信のプロトコルなどの情報をもとに、リアルタイムで、どのエージェントとどのエージェントとが依存関係にあるかの情報を更新してもよい。
なお、図７では、監視データとして、通信負荷Ｑ（Δｔ）と、送信メッセージ数（ＮＭ（Δｔ））とを示したが、これに限るものではなく、メッセージのタイプ（たとえば、データ要求，処理依頼），メッセージの優先度（たとえば、復旧制御，例外処理）などの監視データを取得して、重みＷｉｊを算出してもよい。
以上のようにすべての重みＷｉｊが算出された後は、既存のグラフィックソフトを用いれば、図１に示したようなエージェントの相互依存グラフを作成し、表示させることができる。

＜エージェントの重要度判定処理＞
ここでは、各エージェントの重要度ｗｉを算出する処理（ステップＳ３）について説明する。
この重要度ｗｉとは、あるエージェントｉのレプリカ数を決めるために用いられる指標である。

図８に、この発明におけるエージェントの重要度の算出処理の概略説明図を示す。
図８（ａ）は、ステップＳ２で求めた依存関係グラフの一実施例を示している。エージェント間を結ぶ矢印つきの実線および破線はデータ通信の方向を示し、その近傍の数字は重みＷｉｊを示している。
ここで、エージェントｉに注目し、エージェントｉの重要度ｗｉを算出することにする。
まず、図８（ｂ）に示すように、エージェントｉに直接関係する部分のグラフ（サブグラフと呼ぶ）を切り出す。図８（ａ）では、エージェントｉは、３つのエージェントＡ３，Ａ５およびＡ６とデータ通信をする関係にあるので、実線部分のグラフ（図８（ｂ））を切り出す。

図８（ｂ）のサブグラフでは、エージェントｉにリンクしラベル付けされている５つの重みＷｉｊが存在する。
ここで、５つの重みＷｉｊを用いて、所定の演算（operator４）を行い、エージェントｉの重要度ｗｉを算出する。
wi＝operator4（Wi，j j＝1，m）
ここで、operator４は集合演算子を意味し、重要度の判定基準に相当する。
ｍは、エージェントｉにつながっているリンクの数（次数）を意味する。図８（ｂ）の場合は、ｍ＝３である。

operator４は種々の計算式が考えられるが、たとえば、具体例としては、相加平均，相乗平均のような演算式を用いることができる。
図８（ｂ）の具体例を考えると、３つの重みＷｉｊ（０.２(Ｗｉ₃)，０.７(Ｗｉ₆)，０.７(Ｗｉ₅)）に対して、相加平均の演算を行うと、重要度ｗｉ＝(０.２＋０.７＋０.７)／３＝１.６／３＝０.５３３となる。
すなわち、エージェントｉの重要度ｗｉは０.５３３と判定される。

同様にして同じ演算を図８（ａ）の他のエージェント（Ａ１など）に適用して、すべてのエージェントの重要度を求める。
図８（ａ）の場合は、ｗ₁＝０.８，ｗ₂＝０.３，ｗ₃＝０.４５，ｗ₅＝０.３，ｗ₆＝０.４，ｗ₇＝０.９となる。この場合、エージェントＡ７の重要度が最も高く、エージェントＡ２とＡ５の重要度が最も低いことになる。
この重要度は、次のレプリカ生成処理（ステップＳ４）で、エージェントごとに、レプリカの数を動的に設定するのに用いられる。

＜レプリカの生成処理＞
ここでは、各エージェントごとに、レプリカを生成する処理（ステップＳ４）について説明する。
図９に、この発明のレプリカ生成処理の説明図を示す。
まず上記したように、予めレプリカの総数rmaxが決められており、監視データ記憶部１１８に格納されているものとする。レプリカの数の上限値であるレプリカの総数rmaxは、システムの記録容量に関係するので、システム設計時に決められる。
また、このレプリカ総数rmaxに相当する記録容量を持つレプリカデータベース１５０が、設計時に予め用意される。

あるエージェントｉについてのレプリカの数（repi）は、図９に示すように次式で与えられる。
repi＝round〔r₀+rmax＊（wi／W）〕
ここで、repiは、エージェントｉのレプリカの数，ｒ₀は生成すべきレプリカの初期値，ｗｉはエージェントｉの重要度，Ｗはすべてのエージェントの重要度ｗｉの合計値である。
また、round〔ｘ〕は演算子であり、ｘを越えない最大の整数を意味する。

上記演算式において、ｒ₀，rmax，およびＷは固定値なので、各エージェントごとの重要度ｗｉが与えられると、そのエージェントｉのために準備すべきレプリカの数repiが求められる。
これにより、すべてのエージェントのレプリカの数が求められるが、総数rmaxのレプリカが、エージェントの重要度に応じて各エージェントに分配されることになる。

図１０に、この発明のレプリカ生成処理におけるレプリカデータベースと重要度の一実施例の説明図を示す。
図１０では、初期値ｒ₀＝０，重要度の合計値Ｗ＝４０，レプリカデータベースのレプリカ総数rmax＝４０とする。
また、エージェントは７つとし、各エージェントのそれぞれの重要度ｗｉは図示したとおりであったとする。この場合、上記した式により、４０個のレプリカが、各エージェントの重要度に応じて分配される。

たとえば、エージェントＡ１の重要度ｗｉは４なので、エージェントＡ１に割り当てられるレプリカ数rep１は４となる。すなわち、エージェントＡ１には、４つのレプリカ（Ｒ１１−Ｒ１４）が割り当てられる。
同様に、重要度が１２のエージェントＡ５では、rep５＝１２となり、１２個のレプリカ（Ｒ５１−Ｒ５１２）が割り当てられ、重要度２のエージェントＡ７では、rep７＝２となり、２個のレプリカ（Ｒ７１−Ｒ７２）が割り当てられる。
このレプリカ数（repi）は監視データ記憶部１１８に保存され、復旧処理で使用される。

＜故障診断処理＞
ここでは、エージェントの動作不良や動作停止などを検出して、エージェントの故障を自動的に発見する故障診断処理（ステップＳ５）について説明する。
まず、この発明の分散型のマルチエージェントシステムにおいて、発生する故障形態としては次のような３種類の故障が考えられる。
（１）停止故障（crash failure）
（２）ビザンチン故障（Byzantine failure）
（３）通信故障（communication failure）
（１）の停止故障は、プロセッサの故障やシステムリソースの不足によりエージェントが停止する故障である。
（２）のビザンチン故障は、故障エージェントの振る舞いを仮定しない故障であり、主に予期しない状態への遷移やプログラムバグが原因となる。
いずれも単体レベルのテストでは検出できず、再現性の低い故障である。
（３）の通信故障は、エージェント間通信の接続を確立できない故障、もしくはメッセージの全体や一部が脱落する故障である。

これらの故障が複数のエージェントに同時発生した場合、分散型マルチエージェントシステムではエージェント間に相互作用が存在するため、結果的に協調してシステム全体として誤った処理を行ってしまう。つまり、故障エージェントがシステム内に存在する場合、その故障エージェントを検出し、適切かつ迅速に処理しない限りシステム全体の信頼性を維持することはできない。
そこで、たとえば、次のような処理を行うことにより、故障したエージェントを検出する。

まず、停止故障を検出する場合について説明する。
ここでは、その検出のために、ＣＰＵ動作停止，メモリ不足のような診断基準を利用する。
具体的には、モニタプログラムによるＣＰＵ実行時間の増加ナシ，メッセージの送受信を全く行わないパケット内のプロトコルの未処理などを確認することによりエージェントが停止故障したと判断する。

また、ビザンチン故障の検出は、次のようにして行う。
たとえば、異常メッセージの発生，例外処理の実行，与えられた正常範囲を越えた状態の発生等の検知を行う。これにより、エージェントがビザンチン故障したことを検出できる。

また、通信故障の検出は、次のようにして行う。
具体的には、一部の通信経路について全くメッセージが送受信されないとか、受信したメッセージがプロトコルの規約に違反している等の検知を行うことによりエージェントが通信故障したことが検出できる。

以上のような故障診断を行うことにより、故障エージェントが検出できなかったときは、すべてのエージェントは正常に動作していると考え、ステップＳ１へ戻り、エージェントの監視処理をはじめとする一連の処理を継続する（ステップＳ６）。
一方、故障エージェントが１つでも検出された場合は、そのエージェントの復旧処理を実行する（ステップＳ７）。

＜エージェントの復旧処理＞
ここでは、故障と診断されたエージェントをレプリカに置きかえて、そのエージェントの機能を継続させる処理について説明する。
図１１に、この発明の復旧処理の一実施例の概略説明図を示す。
図１１（ａ）では、３つのエージェント（Ａ１，Ａ２，Ａ３）の間で正常にデータ通信が行われている場合を示している。
ここで、図４のステップＳ１からＳ４の処理によって、エージェントＡ２の重要度が算出され、エージェントＡ２のレプリカとして３つのレプリカが生成されていたとする。
図１１（ａ）に示すように、現在動作中のエージェントＡ２を含めて、３つのレプリカは、１つのレプリケーショングループを形成する。

１つのレプリケーショングループに属するモジュールプログラム（エージェント，レプリカ）は、同一の機能を実行するものであり、外部のエージェントから見れば、１つのエージェントとして認識される。
また、１つのレプリケーショングループの内部では、唯一の動作中のエージェントが存在する。グループ内の他のモジュールプログラムは単なるレプリカであり、通常は静的に存在しているだけであるが、動作中のエージェントに故障等が発生した場合には、１つのレプリカが選択されてそのエージェントに代わり、新しいエージェントとなる。
ただし、レプリカは、いつでもエージェントの代わりとして起動できるようにするために、エージェントと同期されていることが好ましい。
ここで、同期とは、動作中のエージェントとそのレプリカのエージェントとで、状態や送受信メッセージを共有し、バックアップすることを意味し、エージェントとレプリカとの間には、アクティブ型，パッシブ型，セミアクティブ型などの同期をとる方式が成立するように管理される。
具体的には、アクティブ型は、他のエージェントから受信したメッセージを連続して全レプリカに送信する。パッシブ型は、レプリカに対して一定の周期ごとに状態を送信する。セミアクティブ型は、レプリカのうち１つ（これをリーダレプリカという）を選び、そのリータレプリカが動作中のエージェントから受信したメッセージをアクティブ型と同様に他のレプリカに連続して送信することにより同期をとる。

図１１（ｂ）は、エージェントＡ２が故障した場合を示している。この場合、１つのレプリカが選択されて、そのレプリカがエージェントＡ２として起動できるように切替処理が行われる。レプリカが複数ある場合は、たとえばバックアップデータの一致度や生成日時に基づいて、１つのレプリカが選択される。
また、切替処理はたとえば、次のような一連の処理を行うことにより実行される。

処理Ａ：
レプリカの生成日時、およびバックアップデータの一致度を算出する。
処理Ｂ：
ドメインのエージェントまたはリーダーレプリカが故障した場合、一致度が高いレプリカを新しいリーダーレプリカとして選択する。
処理Ｃ：
レプリカの生成や削除を監視システムの指示で行い、レプリケーショングループをリスト形式で表現して管理する。
処理Ｄ：
レプリカのデータの一致度が高い順にリストの要素（レプリカ名）を並べ替える。

上記処理Ａにおいて、バックアップデータとは、エージェントの状態や送受信されたメッセージを意味する。
また、バックアップデータの一致度とは、同期をとった時点の新しさを意味し、たとえば、同期をとるためにバックアップデータが送信された時刻などのデータがどれだけ新しいか否かをチェックする。
そして、これらのデータの一致度を数値化し、所定の数式を用いてすべてのレプリカの一致度を算出する。
たとえば、図１１のように、３つのレプリカが存在する場合、それぞれバックアップデータの一致度、生成日時を検出し、故障したエージェントのデータと比較することにより、一致度を示す数値を求める。

処理Ｂにおいて、たとえば３つのレプリカＡ１，Ａ２，Ａ３の一致度がそれぞれ１０ｓｅｃ差，２０ｓｅｃ差，２０ｓｅｃ差であったとすると、一致度の最も高いレプリカＡ１が選択される。
また、処理Ｃにおいて、リスト形式で表現して管理するとは、まず一致度が高いものから順に、もし一致度が同じであれば生成日時の古いものから順にリストの形で並べる。上の例では（Ａ１，Ａ２，Ａ３）のようになる。

さらに、処理Ｄにおいて、レプリカが並べ替えられた後は、最も一致度の高いレプリカ、すなわち、リストの先頭にあるレプリカが自動的に選択される。

このように選択されたレプリカが、故障したエージェントに完全に置きかえられ正常なエージェントとして動作するためには、具体的にはパッシブ型の場合には、バックアップされている時点から故障時点までのメッセージを他のエージェントから再送してもらうような処理が行われる。
以上のようにエージェントの復旧処理を行うことにより、ある故障エージェントが存在していたために不良あるいは停止していたシステム全体の動作を、正常な動作に戻すことができる。

＜監視システムの応用例＞
この発明の監視システムは種々の分散型のアプリケーションプログラムに適用できる。
たとえば、多数のパソコンがネットワークに接続され、各パソコンに対応づけられた機能をそれぞれ実行するような電子商取引システムに適用できる。
あるいは、その他に、インターネットの検索エンジン，監視制御システム，知能ロボットなどにも適用できる。

図１２に、電子商取引システムにおいて２つの市場を有する商品流通のしくみの事例の説明図を示す。
図１２では、３つの層のエージェントから構成される電子商取引システムを示しており、ここでは、２つの市場（Ａ，Ｂ）が存在する。最上層の部品工場には、製造した部品を販売する部品販売エージェントが存在するものとする。ここで部品販売エージェントとは、部品販売のために作られた１つのモジュールプログラムを意味し、図１のエージェントに対応する。
また、中間層の製品工場では、２つのエージェント（部品購入，製品販売）が存在し、最下層の小売業者では、製品工場で作られた製品を購入する小売業者エージェントが存在するものとする。ここでも各エージェントは、１つのモジュールプログラムであり、図１のエージェントに対応する。

ここで、市場Ａとは、部品工場の部品販売エージェントと、製品工場の部品購入エージェントとの間で取引きされる部品の流通市場である。
一方、市場Ｂとは、製品工場の製品販売エージェントと、小売業者エージェントとの間で取引きされる製品の流通市場である。
この場合に、図１２の各エージェントを図１のエージェントに対応させ、さらに市場ごとに市場管理エージェントを設け、これらのエージェントをそれぞれ監視するモニタプログラム（ＭＰ）と、複数のモニタプログラムと接続される１つのホストプログラム（ＨＰ）とをこのシステムに導入する。

図１３は、図１２の商品流通の説明図を、２つの市場別に表現した市場モデル図である。
２つの市場（Ａ，Ｂ）が重複する部分の「購入／販売エージェント」は製品工場の部品購入エージェントと製品販売エージェントとを含むエージェントを意味する。
また、市場管理エージェントとは、それぞれの市場ごとに設けられ、その市場に含まれる購入エージェントと販売エージェントを管理するエージェントであり、たとえば、入札情報を取りまとめ、購入価格を決定し、成立させる取引を決定するなどの処理をするエージェントである。市場管理エージェントも、図１のエージェントに対応する。

図１３の市場モデル図において、各エージェントごとに、１対１に対応した監視エージェントプログラム（モニタプログラム：ＭＰ）を設け、さらにこのモニタプログラムＭＰに接続されるホストプログラムＨＰを設ける。
図１３では、７つのエージェント（Ａ１〜Ａ７）と、７つのモニタプログラム（ＭＰ１〜ＭＰ７）が設けられ、モニタプログラム（ＭＰ）とホストプログラム（ＨＰ）によって、図４に示したようなエージェントの監視，グラフの作成，重要度判定，レプリカの生成および故障診断という一連の処理が実行される。

以下に、このような市場モデルにおいてネットワーク接続されたコンピュータを用いて、耐故障性のシミュレーションを行った結果を示す。
ここで、シミュレーションのパラメータとして次のような数値を設定した。
市場管理エージェント数＝２
購入／販売エージェント数＝５０
小売業者（購入）エージェント数＝２４
部品販売エージェント数＝２４
レプリカ総数rmax＝３０
レプリカ初期値ｒ₀＝１
割引率α＝１.０
シミュレーション回数＝４０回

上記エージェントの総数は１００であり、rmax＝３０個のうち、１００個は各エージェントごとに１つずつレプリカとして準備しておくものとする（ｒ₀＝１）。
したがって、この実施例では、予め用意された１３０個のレプリカのうち、残りの３０個のレプリカをシステム動作時に算出される重要度に対応させて、動的に各エージェントに配置することになる。たとえば、最も高い重要度となった購入エージェントには、５つのレプリカを割り当てるというような処理が行われる。

このようなパラメータを設定した上で、すべてのエージェントを動作させ、所定の購入および販売の取引データを送受信させる。そして１０分間のシミュレーションを行い、この１０分間に、各エージェントに対してランダムに、合計１００個の停止故障を順次発生させた。
また、比較のために、ホストプログラムＨＰは設けず、モニタプログラムＭＰのみを設けて、モニタプログラムによる監視し、免疫型ネットワークにより診断をして、故障したエージェントを全てのエージェントに対して一様になるようにランダムに割り振ったレプリカに置き換える比較例のシミュレーションも行った。この場合、本発明と比較例で用意するレプリカの総数は、エージェント総数＋３０個である。

この結果、この発明の監視システムでは、エージェントの総数が１００個の場合すべての取引が完了するのに１１.０secの時間がかかったのに対して、比較例では１３.５secの時間がかかった。
すなわち、この発明の監視システムは、１０分間に１００個のエージェント故障が発生しても、比較例よりも２０％程度短い時間で取引が完了できた。
このように、短時間で取引が完了したのは、比較例では免疫型ネットワーク主要により、モニタプログラム間で故障診断する必要があるため時間がかかるが、本発明ではホストプログラムを用意することで早期に診断が行えるためと考えられる。
また、エージェントの総数を２００，３００，あるいは４００のように増加させてシミュレーションした場合も、同様に本願発明の方が比較例よりも短時間で取引が完了できた。また、本発明ではエージェントの総数を３００に増加させても、エージェント総数が１００の場合に比べて取引完了時間は１０％程度増加するだけであったが、比較例においてエージェントの総数を３００に増加させると取引完了時間は３０％程度増加した。この差異はエージェント総数が増えれば、さらに顕著となる。このことより、エージェントの数が膨大な大規模の商取引システムほど、本発明の監視システムを適用することが有効であると言うことができる。

この発明の分散型プログラムの一実施例の相互依存グラフである。 この発明の分散型プログラムの一実施例の相互依存グラフである。 この発明のエージェントの重みの一実施例の説明図である。 この発明の監視システムの概略フローチャートである。 この発明の監視システムの一実施例の機能ブロック図である。 この発明の監視システムの情報取得と監視処理の説明図である。 この発明の相互依存関係の測定処理のフローチャートである。 この発明のエージェントの重要度の算出処理の説明図である。 この発明のレプリカ生成処理の説明図である。 この発明のレプリカデータベースと重要度の一実施例の説明図である。 この発明の復旧処理の一実施例の概略説明図である。 この発明の監視システムの一応用例である電子商取引システムの説明図である。 この発明の監視システムの一応用例である電子商取引システムの市場モデル図である。

符号の説明

１００ 分散型プログラム
１０１ ホストモニタエージェントプログラム（ホストプログラム：ＨＰ）
１１１ 情報取得部
１１２ 依存関係測定部
１１３ グラフ生成部
１１４ 重要度判定部
１１５ レプリカ生成部
１１６ 故障診断部
１１７ 復旧制御部
１１８ 監視データ記憶部
１３０ 監視エージェントプログラム（モニタプログラム：ＭＰ）
１３１ 監視部
１３２ ホスト通信部
１３３ エージェント通信部
１３４ 情報記憶部
１３５ 故障診断部
１４０ エージェント（モジュールプログラム）
１５０ レプリカデータベース

Claims (6)

1. それぞれ特定の機能を実行する複数のモジュール実行部を監視する分散型プログラムの監視システムであって、
   各モジュール実行部の動作状態を特定する監視データをそれぞれ収集する複数の監視実行部と、
   収集された監視データをすべての監視実行部から取得し、前記監視データを用いて各モジュール実行部間の依存関係の深さを示す重みを測定し、重みを用いて各モジュール実行部の重要度を算出し、算出された重要度に対応させた個数のレプリカを各モジュール実行部ごとに生成し、モジュール実行部が故障した場合に、その故障したモジュール実行部のレプリカを起動させ、起動したレプリカに、故障したモジュール実行部の特定の機能を継続して行わせるホスト監視部とを備えたことを特徴とする分散型プログラムの監視システム。
2. それぞれ特定の機能を実行する複数のモジュール実行部が、互いに所定の依存関係を有してデータ通信を行いながら動作する分散型プログラムの監視システムであって、
   各モジュール実行部の動作状態をそれぞれ監視する複数の監視実行部と、すべての監視実行部とデータ通信を行い前記監視実行部を介して前記モジュール実行部の動作を管理するホスト監視部とからなり、
   前記監視実行部が、監視対象のモジュール実行部の動作状態を特定する監視データを収集するエージェント通信部を備え、
   前記ホスト監視部が、エージェント通信部によって収集された各モジュール実行部ごとの監視データを所定のタイミングですべての監視実行部から取得する情報取得部と、取得した監視データを用いて、各モジュール実行部間の依存関係の深さを示す重みを測定する依存関係測定部と、測定された重みを用いて、各モジュール実行部ごとに、分散型プログラムの動作に寄与する程度を示す重要度を算出する重要度判定部と、各モジュール実行部の特定の機能と同じ機能を実行することが可能なレプリカであって、算出された重要度に対応させた個数のレプリカを生成するレプリカ生成部と、各モジュール実行部が予め設定された故障診断基準を満たす動作をしているか否かを確認し、モジュール実行部が故障診断基準を満たさない動作をした場合に、そのモジュール実行部が故障していると判断する故障診断部と、あるモジュール実行部が故障と判断された場合、レプリカ生成部によって生成されたそのモジュール実行部のレプリカを起動させ、故障したモジュール実行部の代わりに、起動されたレプリカに故障したモジュール実行部の特定の機能を継続して行わせる復旧制御部とを備えたことを特徴とする分散型プログラムの監視システム。
3. 前記依存関係測定部は、２つのモジュール実行部の間で送受信されるデータの通信量およびパケット数に基づいて、その２つのモジュール実行部間の重みを測定することを特徴とする請求項２の監視システム。
4. 前記重要度判定部は、測定された重みのうち注目するモジュール実行部に関連する重みを抽出し、抽出された重みに対して相加平均を含む集合演算を行うことにより、その注目したモジュール実行部の重要度を算出することを特徴とする請求項２の監視システム。
5. 前記故障診断基準は、注目しているモジュール実行部が通信停止状態にないこと、注目しているモジュール実行部が単位時間当たりの所定のデータ受信数およびデータ送信数を超える通信過負荷状態にないこと、およびモジュール実行部間でやり取りされるメッセージの一部または全部が脱落しないことを少なくとも含むことを特徴とする請求項２の監視システム。
6. 前記レプリカ生成部は、モジュール実行部ｉのレプリカを生成する場合、次式
   repi＝round〔r₀+rmax＊（wi／W）〕
   （ただし、repi：生成されるレプリカの数，round〔ｘ〕：数値ｘを超えない整数，ｒ₀：レプリカの数の初期値，rmax：レプリカ総数，ｗｉ：重み，Ｗ：全モジュール実行部の重みの合計値，ｉ：注目するモジュール実行部の識別番号）
   で与えられる数repiのレプリカを生成することを特徴とする請求項２の監視システム。