JP2008097111A - リソース分配方法、プログラム、及びリソース分配装置 - Google Patents

Abstract

【課題】プログラムにより実行される処理、例えば、ルール処理を実現するリソースを効率的に利用し、リソースが特定の機能に偏ることを防ぐことを課題とする。
【解決手段】リソース全体として実現すべき統合プログラムを指定するステップと、前記統合プログラムを分解した二以上の分解プログラムを算出するステップと、前記分解プログラムを実行する各種のプログラム処理体を単位として、前記各種のプログラム処理体にかかる負荷を算出するステップと、前記各種のプログラム処理体にかかる負荷の比率に基づいて、それぞれの種類のプログラム処理体に、前記リソースを割り当てるステップとを有するリソース分配方法によって解決する。
【選択図】図９

Description

本発明は、リソース分配方法、プログラム、及びリソース分配装置に関する。

図１に、従来のサーバの負荷分散システムを示す。図１において、クライアント１０３〜１０５は、サーバ１０１，１０２に対して、処理を要求するリクエストメッセージを送信する。振り分け器１００は、リクエストメッセージを受信して、受信したリクエストメッセージをいずれかのサーバ１０１，１０２に振り分ける。リクエストメッセージを、複数のサーバ１０１，１０２に振り分けることで、サーバ１０１，１０２における処理の分散化を実現している。サーバを追加することにより、クライアントから送信されるリクエストメッセージ数の増加にも対応できる。しかし、サーバの数を増加しても、振り分け器１００がボトルネックとなる可能性がある。

未公開の先願（特願２００５−３１４５３７号（特許文献１参照））では、アプリケーションから指定されるルールを基に、処理サーバとコンテキスト依存振り分け器にルールが設定される。ＣＰＵやメモリを含むリソースが限られている場合、処理サーバに多くのリソースを割り当てると、コンテキスト依存振り分け器がボトルネックとなり、システム全体としての性能が低下する可能性がある。その逆に、コンテキスト依存振り分け器に多くのリソースを割り当てると、処理サーバがボトルネックとなり、システム全体としての性能が低下する可能性がある。

特願２００５−３１４５３７号

本発明は、プログラムにより実行される処理、例えば、ルール処理を実現するリソースを効率的に利用し、リソースが特定の機能に偏ることを防ぐことを課題とする。

以下に、［発明を実施するための最良の形態］で使用される番号・符号を用いて、［課題を解決するための手段］を説明する。これらの番号・符号は、［特許請求の範囲］の記載と［発明を実施するための最良の形態］との対応関係を明らかにするために括弧付きで付加されたものである。ただし、それらの番号・符号を、［特許請求の範囲］に記載されている発明の技術的範囲の解釈に用いてはならない。

本発明によるリソース分配方法おいては、指定するステップは、リソース全体として実現すべき統合プログラムを指定する。分解プログラムを算出するステップは、前記統合プログラムを分解した二以上の分解プログラムを算出する。負荷を算出するステップは、前記分解プログラムを実行する各種のプログラム処理体を単位として、前記各種のプログラム処理体にかかる負荷を算出する。割り当てるステップは、前記各種のプログラム処理体にかかる負荷の比率に基づいて、それぞれの種類のプログラム処理体に、前記リソースを割り当てる。

本発明によるリソース分配方法おいては、指定するステップは、リソース全体として実現すべき統合ルールを指定する。分解ルールを算出するステップは、前記統合ルールを分解した二以上の分解ルールを算出する。負荷を算出するステップは、前記分解ルールを実行する各種のルール処理体を単位として、前記各種のルール処理体にかかる負荷を算出する。割り当てるステップは、前記各種のルール処理体にかかる負荷の比率に基づいて、それぞれの種類のルール処理体に、前記リソースを割り当てる。

ある統合ルールを処理するための分解した機能の接続パターンとしては、各種のパターンが考えられるが、図２の直列接続、図３の分岐接続、図４の集約接続に分類できる。図２〜図４においては、矢印にそって各機能６０〜６９が実行されることになるが、矢印がある場合に、必ず、各機能６０〜６９を実行してもよいし、途中の機能６０〜６９で処理を終了してもよい。例えば、図２の直列接続では、まず、［機能１］６０の処理が行われ、次に、［機能２］６１の処理が行われることになるが、例えば、図２の［機能１］６０を実行した結果、［機能２］６１を実行する必要がない場合には、［機能１］６０の実行後、［機能２］６１を実行せずに、処理を完了してもよい。また、図３の分岐接続では、まず、［機能１］６２の処理が行われ、次に、［機能２］６３、［機能３］６４、…、［機能ｎ］６５のいずれかの処理が行われるのが基本である。しかしながら、図３の例においても、［機能１］６２のみで処理を完了してもよいし、また、［機能１］６２の処理後、［機能２］６３、［機能３］６４、…、［機能ｎ］６５における２つ以上の機能を実施してもよい。図５は、図２の直列接続、図３の分岐接続、及び、図４の集約接続を組み合わせて、統合ルールを処理するための機能を表現したものである。図５では、［機能１］７１〜［機能５］７５が、５種類の分解ルールを実行し、全体として、統合ルールを処理している。

また、本発明によるリソース分配方法においては、前記指定するステップは、イベント発生源から送信されるイベントの中から、一定の条件に合致したイベントを抽出する処理と、当該イベントを所定のアプリケーションに届ける処理とを含む統合ルールを指定する。

また、本発明によるリソース分配方法においては、前記イベントは、属性と、値とを有する。前記一定の条件は、前記イベントの属性と、値とを判別する。前記イベントを抽出する処理は、前記一定の条件によって課される属性と、イベントにおける属性とが一致し、かつ、前記一定の条件によって課される値と、イベントにおける値とが一致した場合に、当該イベントを抽出する。

また、本発明によるリソース分配方法においては、前記分解ルールを算出するステップは、直列的に実行される第一の分解ルールと、第二の分解ルールとが算出されるように、前記統合ルールを分解する。前記第一の分解ルールとして、前記イベントの中から、前記イベントの属性と、前記一定の条件によって課される属性とが一致するイベントを抽出するルールを算出する。前記第二の分解ルールとして、前記イベントの中から、前記イベントの値と、前記一定の条件によって課される値とが一致するイベントを抽出するルールを算出する。

また、本発明によるリソース分配方法においては、前記負荷を算出するステップは、前記ルール処理体が実行する分解ルールについて、受信するイベント数と、一イベント当たりの処理コストとの積を算出し、当該積に基づいて、前記各種のルール処理体にかかる負荷を算出する。

また、本発明によるリソース分配方法においては、前記割り当てるステップは、前記各種のルール処理体にかかる負荷の比率に基づいて、負荷の大きな種類のルール処理体には多くのリソースを割り当て、負荷の小さな種類のルール処理体には少ないリソースを割り当てることによって、リソースの負荷が均一化されるように、それぞれの種類のルール処理体に、前記リソースを割り当てる。

また、本発明によるリソース分配方法においては、前記リソースのそれぞれに、前記分解ルールを設定するステップを有すると共に、前記設定するステップは、二以上の種類のルール処理体を組み合わせて成り、前記統合ルールを実現する第一のグループと、同じく、二以上の種類のルール処理体を組み合わせて成り、前記統合ルールを実現する第二のグループとの、独立したグループが少なくとも二つ形成されるように、前記リソースのそれぞれに、前記分解ルールを設定する。

また、本発明によるプログラムにおいては、以下の手順をコンピュータに実行させる。指定する手順は、リソース全体として実現すべき統合ルールを指定する。分解ルールを算出する手順は、前記統合ルールを分解した二以上の分解ルールを算出する。負荷を算出する手順は、前記分解ルールを実行する各種のルール処理体を単位として、前記各種のルール処理体にかかる負荷を算出する。割り当てる手順は、前記各種のルール処理体にかかる負荷の比率に基づいて、それぞれの種類のルール処理体に前記リソースを割り当てる。

また、本発明によるリソース分配装置においては、ルール指定部（１０）は、リソース全体として実現すべき統合ルールを指定する。ルール設定サーバ（１１）は、前記統合ルールを分解した二以上の分解ルールを算出すると共に、前記リソースのそれぞれに、前記分解ルールを設定する。リソース分配サーバ（１２）は、前記分解ルールを実行する各種のルール処理体を単位として、前記各種のルール処理体にかかる負荷を算出すると共に、前記各種のルール処理体にかかる負荷の比率に基づいて、それぞれの種類のルール処理体に、前記リソースを割り当てる。

本発明によれば、プログラムにより実行される処理、例えば、ルール処理を実現するリソースを効率的に利用し、リソースが特定の機能に偏ることを防ぐことができる。

図６に、本発明によるリソース分配方法を実施したシステムの一例を示す。図６において、ルール指定部１０は、コンピュータ上で動作する機能ブロックであり、例えば、ユーザによって入力されたデータに基づき、リソース２１〜２６が実現すべき統合ルールを指定する。ルール設定サーバ１１は、指定された統合ルールに基づき、統合ルールを分解した複数の分解ルールを算出する。リソース分配サーバ１２は、各分解ルールの処理コストを算出し、当該処理コストの関係に基づいて、リソース２１〜２６を分配し、どの分解ルールに、どのリソースを割り当てるかを決定する。ルール設定サーバ１１は、リソース２１〜２６の分配結果に基づき、それぞれのリソース２１〜２６に分解ルールを設定する。各リソースに、それぞれの分解ルールを設定することによって、リソースは、全体として、メッセージ発生源１５から発生するメッセージのルール処理を行い、統合ルールを処理する装置として動作する。

図７に、本発明によるリソース分配方法によって、リソース２１〜２６を分配した結果の一例を示す。図７において、ルール指定部１０は、メッセージ発生源１５から発生するメッセージに所定の処理を加える統合ルールを指定している。ルール設定サーバ１１は、統合ルールを、二つの分解ルールに分解している。第一の分解ルールは、メッセージ発生源１５から発生するメッセージをいずれかの処理サーバに振り分ける振り分け器が実行するものである。第二の分解ルールは、メッセージに所定の処理を加える処理サーバが実行するものである。リソース分配サーバ１２は、第一の分解ルールの処理コストと、第二の分解ルールの処理コストとを算出して、その比率が１対２であることを求めている。そして、振り分け器に［リソース１］２１と［リソース２］２２とを割り当て、処理サーバに［リソース３］２３と［リソース４］２４と［リソース５］２５と［リソース６］２６とを割り当てている。このように、処理コストの比率に基づいて、リソース２１〜２６を１対２に分配し、１／３のリソースを振り分け器に、２／３のリソースを処理サーバに割り当てることによって、リソース２１〜２６の処理コストを均一化することができる。メッセージ発生源１５から［リソース１］２１に送信されるメッセージは、［リソース３］２３又は［リソース４］２４に振り分けられ、メッセージ発生源１５から［リソース２］２２に送信されるメッセージは、［リソース５］２５又は［リソース６］２６に振り分けられる。メッセージを受け取る［リソース３］２３〜［リソース６］２６が、メッセージに所定の処理を加えることによって、リソース２１〜２６は、全体として統合ルールを実現する。

図６及び７において、破線は矢印の方向へ進むルールの流れを表している。リソース分配サーバ１２から出ている太い矢印は、リソース配置を行う制御メッセージの流れを表す。メッセージ発生源１５から出ている矢印は、メッセージの流れを表す。ルール設定サーバ１１、リソース分配サーバ１２、メッセージ発生源１５は、クラウド内部のいずれのリソース２１〜２６とも通信できる。

次に、別の例により、本発明の実施の形態について詳述する。例えば、各リソースが同等の処理能力を有する処理装置であるとする。また、統合ルールは、異なるサービスを提供するサーバＡとサーバＢの処理を直列的に行うことにより実現されるものとし、いくつでも指定できるとする。ある統合ルールは、サーバＡが実行するサーバＡ分解ルールと、サーバＢが実行するサーバＢ分解ルールとに分解することができる。統合ルールが複数指定される場合、一の統合ルールは、一のサーバＡ分解ルールと、一のサーバＢ分解ルールとに分解され、他の統合ルールは、他のサーバＡ分解ルールと、他のサーバＢ分解ルールとに分解される。このとき、サーバＡは、一のサーバＡ分解ルールと、他のサーバＡ分解ルールとを実行し、サーバＢは、一のサーバＢ分解ルールと、他のサーバＢ分解ルールとを実行する。異なる統合ルールから算出される二以上のサーバＡ分解ルールが同一の場合には、一のサーバＡ分解ルールにまとめることができる。同様に、異なる統合ルールから算出される二以上のサーバＢ分解ルールが同一の場合には、一のサーバＢ分解ルールにまとめることができる。

図８に、本実施の形態におけるシステム構成例を示し、図９に、図８のシステム構成におけるリソース分配方法の処理ステップを示す。図８及び図９において、［ＡＰ１］５０と［ＡＰ２］５１とは、要求するイベント条件として、［マシン１］４１〜［マシン６］４６が実現すべき統合ルールをルール設定サーバ３１に指定している。ルール設定サーバ３１は、受信した統合ルールに基づいて、サーバＡが実現するサーバＡ分解ルールと、サーバＢが実現するサーバＢ分解ルールとを算出している。算出したサーバＡ分解ルールと、サーバＢ分解ルールとは、リソース分配サーバ３２に通知される。リソース分配サーバ３２は、サーバＡ分解ルールを実行するサーバＡの処理コストと、サーバＢ分解ルールを実行するサーバＢの処理コストとを算出し、サーバＡに割り当てるマシンと、サーバＢに割り当てるマシンとを決定する。この決定に従い、リソース分配サーバ３２は、サーバＡに［マシン１］４１と［マシン２］４２とを割り当て、サーバＢに［マシン３］４３〜［マシン６］４６を割り当てている。ここで、リソース分配サーバ３２は、必要に応じて、［マシン１］４１〜［マシン６］４６に、サーバＡのプログラム又はサーバＢのプログラムをインストールする。リソースの割り当て結果は、リソース分配サーバ３２からルール設定サーバ３１へ通知される。ルール設定サーバ３１は、マシンごとに適用する分解ルールを算出し、各マシン４１〜４６にルール設定を行う。これにより、イベント発生源３５〜３７から発生するイベントは、統合ルールを実現するサーバＡとサーバＢとを直列的に経由して処理され、［ＡＰ１］５０又は［ＡＰ２］５１に届けられる。

具体例に則して、図８のシステム構成及び図９の処理ステップについて詳述する。図１０に、［ＡＰ１］５０と［ＡＰ２］５１とが指定する統合ルールの一例を示す。理解を容易にするため、図１０では、条件と通知先のみからなる単純な構成の統合ルールを例示している。図１０において、［ＡＰ１］５０は、四つの統合ルールを指定している。最初の統合ルールは、”温度が１０℃であれば、ＡＰ１に通知する。”というものである。［マシン１］４１〜［マシン６］４６は、全体として、温度が１０℃であるというイベントが発生したら、そのイベントを［ＡＰ１］５０に通知するように動作すべきことになる。［ＡＰ１］５０が指定する二つ目の統合ルールは、”温度が２０℃であれば、ＡＰ１に通知する。”というものであり、三つ目の統合ルールは、”温度が３０℃であれば、ＡＰ１に通知する。”というものであり、四つ目の統合ルールは、”湿度が５０％であれば、ＡＰ１に通知する。”というものである。結局、ＡＰ１に通知するイベントは、温度が、１０℃、２０℃、又は３０℃のもの、若しくは湿度が５０％のものとなる。図１０において、［ＡＰ２］５１も、［ＡＰ１］５０と同数の四つの統合ルールを指定している。最初の統合ルールは、”温度が１５℃であれば、ＡＰ２に通知する。”というものであり、二つ目の統合ルールは、”湿度が７０％であれば、ＡＰ２に通知する。”というものであり、三つ目の統合ルールは、”湿度が８０％であれば、ＡＰ２に通知する。”というものであり、四つ目の統合ルールは、”湿度が９０％であれば、ＡＰ２に通知する。”というものである。結局、ＡＰ２に通知するイベントは、温度が、１５℃のもの、若しくは湿度が、７０％、８０％、又は９０％のものとなる。

図１１に、ルール設定サーバ３１が、図１０の統合ルールを基に算出するサーバＡ分解ルール、サーバＢ分解ルールの例を示す。イベント発生源３５〜３７から発生するイベントは、属性と値とを有している。図１１の例では、ルール設定サーバ３１には、サーバＡ分解ルールとして、イベントの属性を参照して、イベントを振り分けるルールを算出すべきこと、かつ、サーバＢ分解ルールとして、イベントの値を参照して、イベントを振り分けるルールを算出すべきことがプログラミングされている。まず、サーバＡ分解ルールを算出する。図１０に示されるように、［ＡＰ１］５０及び［ＡＰ２］５１が指定した統合ルールは、全て、条件において、イベントの属性を参照し、その属性が、”温度”又は”湿度”のものを抽出している。従って、サーバＡ分解ルールは、図１１に示すように、ｉｎｃｌｕｄｅｓ”温度”という条件を含む分解ルールと、ｉｎｃｌｕｄｅｓ”湿度”という条件を含む分解ルールとなる。ただし、通知すべきサーバＢが未だ決まっていないため、通知先を”ｎｏｔｉｆｙ ｔｏ ？”としている。このサーバＡ分解ルールによって、例えば、”温度”＝２５℃というイベントは抽出されるが、”風向き”＝東というイベントは破棄され、” 湿度”＝３０％というイベントは抽出されるが、”降水量”＝１０ｍｍというイベントは破棄されることになる。次に、サーバＢ分解ルールを算出する。図１０に示されるように、［ＡＰ１］５０及び［ＡＰ２］５１が指定した統合ルールは、条件の属性が”温度”の場合には、条件の値が、１０℃、１５℃、２０℃、又は３０℃のものを抽出し、条件の属性が”湿度”の場合には、条件の値が、５０％、７０％、８０％、又は９０％のものを抽出している。従って、サーバＢルールは、図１１に示すように、”温度”＝１０℃という条件を含む分解ルール、”温度”＝２０℃という条件を含む分解ルール、”温度”＝３０℃という条件を含む分解ルール、”湿度”＝５０％という条件を含む分解ルール、”温度”＝１５℃という条件を含む分解ルール、”湿度”＝７０％という条件を含む分解ルール、”湿度”＝８０％という条件を含む分解ルール、”湿度”＝９０％という条件を含む分解ルールとなる。なお、サーバＢ分解ルールでは、与えられた統合ルールから通知すべきアプリケーション（ＡＰ１又はＡＰ２）が決まってしまうため、通知先を、”ｎｏｔｉｆｙ ｔｏ ＡＰ１”又は”ｎｏｔｉｆｙ ｔｏ ＡＰ２”としている。このサーバＢ分解ルールによって、例えば、”温度”＝３０℃というイベントは抽出されるが、”温度”＝４０℃というイベントは破棄され、”湿度”＝５０％というイベントは抽出されるが、”湿度”＝６０％というイベントは破棄されることになる。

図１２に、リソース分配サーバ３２が行う処理コスト算出方法の一例を示す。当例では、リソースが処理を実行するマシン４１〜４６となっているため、各マシン４１〜４６が等しい処理コストを負担することになるように、リソースを分配することが望ましい。図１１に示されるように、ルール設定サーバ３１によって、統合ルールから分解ルールを算出することができた。リソース分配サーバ３２では、まず、この分解ルールに基づいて、サーバＡ及びサーバＢの処理コストを算出する。一般に、処理コストは、受信イベント数と、１イベント当たりの処理コストとの積として算出できる。図１２の例では、理解を容易にするため、どの分解ルールも、全て、１イベント当たりの処理コストが”１”であるとしている。また、イベント発生源から送信されるイベント数については、イベントの属性が、”温度”であるもの、 ”湿度”であるもの、 ”風向き”であるもの、”降水量”であるものの比率は、１：１：１：１であるとし、その他の属性のイベントは無いものとする。まず、サーバＡの処理コストを計算する。サーバＡが受信するイベントは、ｉｎｃｌｕｄｅｓ”温度”という条件を含む分解ルールと、ｉｎｃｌｕｄｅｓ”湿度”という条件を含む分解ルールとの二つの分解ルールによる処理を経る。各分解ルールの１イベント当たりの処理コストは”１”と定めてあるので、サーバＡの１イベント当たりの処理コストは”２”となる。また、サーバＡは、イベント発生源から発生するイベントの１００％を受信するので、サーバＡの処理コストは”２”と求めることができる。次に、サーバＢの処理コストを計算する。サーバＢが受信するイベントは、”温度”条件を含む四つの分解ルールと、”湿度”条件を含む四つの分解ルールとの合計八つの分解ルールによる処理を経る。各分解ルールの１イベント当たりの処理コストは”１”と定めてあるので、サーバＢの１イベント当たりの処理コストは”８”となる。また、イベント数に関しては、イベント発生源から発生するイベントの中で、条件の属性が”風向き”であるもの、”降水量”であるものは、サーバＡにおいて破棄されてしまう。従って、サーバＢは、イベント発生源から発生するイベントの５０％を受信する。よって、サーバＢの処理コストは８×１／２=”４”と求めることができる。最後に、サーバＡの処理コストとサーバＢの処理コストとの比率を求める。この比率は、２：４＝１：２である。この場合、リソース分配比率を、サーバＡ：サーバＢ＝１：２とすることができる。

図１３に、ルール設定サーバ３１が算出する、各マシン４１〜４６に設定するルールの例を示す。図１３は、サーバＡのイベント通知先となるサーバＢを制限した例である。図１３において、［マシン１］４１と、［マシン２］４２とは、サーバＡに割り当てられている。通知先を制限する図１３の例では、ルール設定サーバ３１には、サーバＡの通知先となるサーバＢが、必ず、いずれか一つのサーバＡからイベントの通知を受けるように、サーバＡ分解ルールを算出すべきこと、並びに、サーバＡの通知先となるサーバＢの数が、サーバＡ間で同数になるように、サーバＡ分解ルールを算出すべきこと、がプログラミングされているとする。このプログラムによって、ルール設定サーバ３１は、［マシン１］４１に設定するサーバＡ分解ルールの通知先を、”ｎｏｔｉｆｙ ｔｏ マシン３ ｏｒ マシン４”とし、［マシン２］４２に設定するサーバＡ分解ルールの通知先を、”ｎｏｔｉｆｙ ｔｏ マシン５ ｏｒ マシン６”として、各分解ルールを算出している。これにより、［マシン１］４１、［マシン３］４３、及び［マシン４］４４からなる第一のグループと、［マシン２］４２、［マシン５］４５、及び［マシン６］４６からなる第二のグループとの、独立した二つのグループが形成されることになる。なお、［マシン３］４３〜［マシン６］４６に設定する分解ルールの通知先は、図１１に示したように、統合ルールより、［ＡＰ１］５０又は［ＡＰ２］５１に定まっていた。ルール設定サーバ３１は、各［マシン１］４１〜［マシン６］４６に、算出した分解ルールを設定する。以上、図１３の例では、サーバＡの処理結果を通知するサーバＢを制限したが、サーバＡの処理結果をどのサーバＢに通知するかに関しては特に制限しなくてもよい。［マシン１］４１と［マシン２］４２は、処理結果を［マシン３］４３から［マシン６］４６までのいずれのマシンへも通知できることとし、サーバＡは、ラウンドロビン方式で、イベント通知先のサーバＢを選択するようにしてもよい。

図１４に、リソース分配後のシステム構成例を示す。図１４に示すように、サーバＡとして動作する［マシン１］４１及び［マシン２］４２と、サーバＢとして動作する［マシン３］４３〜［マシン６］４６とは、階層構造に配置されている。イベント発生源３５，３７〜３９から送信されるイベントは、まず、サーバＡとして動作する［マシン１］４１又は［マシン２］４２によって処理され、次に、サーバＢとして動作する［マシン３］４３〜［マシン６］４６によって処理され、最終的に、［ＡＰ１］５０又は［ＡＰ２］５１に届けられる。図１４において、［マシン１］４１〜［マシン６］４６が実現するルール処理は、［マシン１］４１、［マシン３］４３、［マシン４］４４による第一のグループと、［マシン２］４２、［マシン５］４５、［マシン６］４６による第二のグループとに分割されている。これに伴い、イベント発生源３５，３７〜３９も分割され、第一のグループへイベントを送信するイベント発生源３５，３８と、第二のグループへイベントを送信するイベント発生源３７，３９とに分割されている。イベントは、どちらのグループによるルール処理を経ても、正しい［ＡＰ１］５０又は［ＡＰ２］５１に届けられる。

図１５に、各マシン４１〜４６に分解ルールを設定した後に、イベント発生源３５からイベントが発生した場合の処理の流れを示す。例えば、図１５のイベントは、イベント発生源３５から発生し、属性が”湿度”、値が８０％であるとする。当該イベントは、［マシン１］４１が受信する。［マシン１］４１においては、サーバＡ分解ルールが実行され、イベントの属性である”湿度”が参照される。図１３に示したように、属性が”湿度”であるイベントは、［マシン３］４３又は［マシン４］４４に通知されることになる。ここでは、ラウンドロビン方式で、イベントは、［マシン４］４４に通知されることとする。［マシン４］４４においては、サーバＢ分解ルールが実行され、イベントの値である８０％が参照される。図１３に示したように、値が８０％であるイベントは、［ＡＰ２］５１に通知されることになる。

以上、サーバＡとサーバＢとを直列的に処理することでルール処理を実現する例を挙げた。しかし、本発明は、上例に限られるものではなく、ルール処理を複数の機能に分解できる場合に、広く適用することができる。また、ルール設定サーバに指定する統合ルールは、随時、追加することができ、また、削除することができる。統合ルールの追加又は削除により、新たな分解ルールが算出され、リソースの再分配が行われる。

図１は、従来のサーバの負荷分散システムを示す図である。 図２は、直列接続の接続パターンを示す図である。 図３は、分岐接続の接続パターンを示す図である。 図４は、集約接続の接続パターンを示す図である。 図５は、図２〜図４の接続パターンを組み合わせた例を示す図である。 図６は、本発明によるリソース分配方法を実施したシステムの一例を示す図である。 図７は、本発明によるリソース分配方法によって、リソースを分配した結果の一例を示す図である。 図８は、本実施の形態におけるシステム構成例を示す図である。 図９は、図８のシステム構成におけるリソース分配方法の処理ステップを示す図である。 図１０は、ＡＰ１とＡＰ２とが指定するルールの一例を示す図である。 図１１は、図１０の統合ルールを基に算出するサーバＡルール、サーバＢルールの例を示す図である。 図１２は、リソース分配サーバが行う処理コスト算出方法の一例を示す図である。 図１３は、ルール設定サーバが算出する、各マシンに設定するルールの例を示す図である。 図１４は、リソース分配後のシステム構成例を示す図である。 図１５は、イベント発生源からイベントが発生した場合の処理の流れを示す図である。

符号の説明

１０ ルール指定部
１１，３１ ルール設定サーバ
１２，３２ リソース分配サーバ
１５ メッセージ発生源
２１〜２６ リソース
３５〜３９ イベント発生源
４１〜４６ マシン
５０，５１ アプリケーション
６０〜６９，７１〜７５ 機能
１００ 振り分け器
１０１，１０２ サーバ
１０３〜１０５ クライアント

Claims (10)

1. リソース全体として実現すべき統合プログラムを指定するステップと、
   前記統合プログラムを分解した二以上の分解プログラムを算出するステップと、
   前記分解プログラムを実行する各種のプログラム処理体を単位として、前記各種のプログラム処理体にかかる負荷を算出するステップと、
   前記各種のプログラム処理体にかかる負荷の比率に基づいて、それぞれの種類のプログラム処理体に、前記リソースを割り当てるステップと
   を有するリソース分配方法。
2. リソース全体として実現すべき統合ルールを指定するステップと、
   前記統合ルールを分解した二以上の分解ルールを算出するステップと、
   前記分解ルールを実行する各種のルール処理体を単位として、前記各種のルール処理体にかかる負荷を算出するステップと、
   前記各種のルール処理体にかかる負荷の比率に基づいて、それぞれの種類のルール処理体に、前記リソースを割り当てるステップと
   を有するリソース分配方法。
3. 前記指定するステップは、
   イベント発生源から送信されるイベントの中から、一定の条件に合致したイベントを抽出する処理と、当該イベントを所定のアプリケーションに届ける処理とを含む統合ルールを指定する
   請求項２記載のリソース分配方法。
4. 前記イベントは、属性と、値とを有し、
   前記一定の条件は、前記イベントの属性と、値とを判別し、
   前記イベントを抽出する処理は、前記一定の条件によって課される属性と、イベントにおける属性とが一致し、かつ、前記一定の条件によって課される値と、イベントにおける値とが一致した場合に、当該イベントを抽出する
   請求項３記載のリソース分配方法。
5. 前記分解ルールを算出するステップは、
   直列的に実行される第一の分解ルールと、第二の分解ルールとが算出されるように、前記統合ルールを分解すると共に、
   前記第一の分解ルールとして、前記イベントの中から、前記イベントの属性と、前記一定の条件によって課される属性とが一致するイベントを抽出するルールを算出し、
   前記第二の分解ルールとして、前記イベントの中から、前記イベントの値と、前記一定の条件によって課される値とが一致するイベントを抽出するルールを算出する
   請求項４記載のリソース分配方法。
6. 前記負荷を算出するステップは、
   前記ルール処理体が実行する分解ルールについて、受信するイベント数と、一イベント当たりの処理コストとの積を算出し、当該積に基づいて、前記各種のルール処理体にかかる負荷を算出する
   請求項２〜５いずれか１項に記載のリソース分配方法。
7. 前記割り当てるステップは、
   前記各種のルール処理体にかかる負荷の比率に基づいて、負荷の大きな種類のルール処理体には多くのリソースを割り当て、負荷の小さな種類のルール処理体には少ないリソースを割り当てることによって、リソースの負荷が均一化されるように、それぞれの種類のルール処理体に、前記リソースを割り当てる
   請求項２〜６いずれか１項に記載のリソース分配方法。
8. 前記リソースのそれぞれに、前記分解ルールを設定するステップを有すると共に、
   前記設定するステップは、
   二以上の種類のルール処理体を組み合わせて成り、前記統合ルールを実現する第一のグループと、同じく、二以上の種類のルール処理体を組み合わせて成り、前記統合ルールを実現する第二のグループとの、独立したグループが少なくとも二つ形成されるように、前記リソースのそれぞれに、前記分解ルールを設定する
   請求項２〜７いずれか１項に記載のリソース分配方法。
9. リソース全体として実現すべき統合ルールを指定する手順と、
   前記統合ルールを分解した二以上の分解ルールを算出する手順と、
   前記分解ルールを実行する各種のルール処理体を単位として、前記各種のルール処理体にかかる負荷を算出する手順と、
   前記各種のルール処理体にかかる負荷の比率に基づいて、それぞれの種類のルール処理体に前記リソースを割り当てる手順と
   をコンピュータに実行させるためのプログラム。
10. リソース全体として実現すべき統合ルールを指定するルール指定部と、
    前記統合ルールを分解した二以上の分解ルールを算出すると共に、前記リソースのそれぞれに、前記分解ルールを設定するルール設定サーバと、
    前記分解ルールを実行する各種のルール処理体を単位として、前記各種のルール処理体にかかる負荷を算出すると共に、前記各種のルール処理体にかかる負荷の比率に基づいて、それぞれの種類のルール処理体に、前記リソースを割り当てるリソース分配サーバと
    を有するリソース分配装置。

Images