JP5664098B2 - 複合イベント分散装置、複合イベント分散方法および複合イベント分散プログラム - Google Patents

Description

本発明は、複合イベント分散装置、複合イベント分散方法および複合イベント分散プログラムに関する。

近年、システム上で発生するデータなどをストリームとしてリアルタイムにモニタリングし、発生したデータパターンに応じて特定の処理を実行する複合イベント処理（ＣＥＰ（Complex Event Processing））が広まっている。なお、複合イベント処理は、ＥＳＰ（Event Stream Processing）と呼ぶ場合もあるが、ここでは、ＥＳＰも包含してＣＥＰと総称する。

例えば、複合イベント処理として、株価や為替の変動をストリームとして受信し、変動パターンに応じて自動的に取引を実行することなどがある。また、屋内外に設置された温度センサが検知した温度をストリームとして受信し、温度変化に応じて自動的にスクリンプラーを作動させることなどがある。

複合イベント処理では、受信したストリームと、クエリやルールなどと呼ばれる条件式とを突合させてイベントを検出し、検出したイベントが実行される。一例として、複合イベント処理を実行するサーバは、事象Ａ、事象Ｂ、事象Ｃを連続して検出した場合にイベントＸを実行するルールＸと、事象Ａ、事象Ｂ、事象Ｄを所定時間内に受信した場合にはイベントＹを実行するルールＹとを記憶する。

そして、サーバは、受信したストリームから事象を検出してメモリ等に中間データとして格納する。その後、サーバは、中間データとして事象Ａ、事象Ｂ、事象Ｃが連続して格納された場合には、イベントＸを実行する。また、サーバは、中間データとして事象Ａ、事象Ｂ、事象Ｄが所定時間内に格納された場合には、イベントＹを実行する。

「ITアーキテクト Vol.25」、p128-p132、ＩＤＧジャパン、２００９年

しかしながら、従来の技術では、処理性能が劣化する場合があるという課題があった。

例えば、複数のルールを有する複合イベント処理では、処理負荷を軽減し、ストリームからリアルタイムにイベントを検出するために、複数のサーバ又は仮想マシン（ＶＭ：Virtual Machine）を用いて実行される。また、サーバ間又はＶＭ間では、メモリ又は仮想メモリを共有しないので、中間データ等を共有で管理できない。このため、従来の技術では、関連するルールを同一サーバ又はＶＭ上に割り当てて、複合イベント処理を開始していた。

ところが、複合イベント処理を開始した後、あるルールで検出されるイベントが多発した場合、又はストリーム負荷が高くなった場合、このルールが割り当てられたサーバでは、イベントの実行処理が多発して処理負荷が高くなる。この結果、イベントが多発したサーバでは、ストリームからイベントを検出する処理が遅延し、リアルタイムにイベントを実行できない事象が発生する。つまり、特定のイベントの検出が多発した場合、複合イベント処理全体の処理性能が劣化することとなる。

１つの側面では、処理性能の劣化を防止することができる複合イベント分散装置、複合イベント分散方法および複合イベント分散プログラムを提供することを目的とする。

第１の案では、複合イベント分散装置は、複数の情報処理手段それぞれが実行する、イベントを特定する条件式にそれぞれ基づいてストリームから検出されたイベントへの、複数の複合イベント処理に対し、前記複数の複合イベント処理間の関連度を、前記複数の複合イベント処理それぞれに対応づけられた前記条件式の実行実績に基づき算出する算出部を有する。複合イベント分散装置は、前記複数の情報処理手段それぞれが動作するサーバにおける、前記複数の情報処理手段それぞれの前記サーバの資源の使用状況に基づき算出される処理負荷状況を取得する取得部を有する。複合イベント分散装置は、前記取得部によって取得された処理負荷状況に基づいて、処理分散対象の情報処理手段を検出する検出部を有する。複合イベント分散装置は、前記検出部によって処理分散対象の情報処理手段が検出された場合、前記算出部によって算出された前記複数の複合イベント処理間の関連度に基づいて、前記複数の情報処理手段の少なくとも１つに前記複合イベント処理を分散させる分散部を有する。

処理性能の劣化を防止することができる。

図１は、実施例１に係るサーバの構成を示すブロック図である。 図２は、ＣＥＰの動作について説明する図である。 図３は、実施例１に係る複合イベント処理の分散化を説明する図である。 図４は、実施例２に係る複合イベント処理の分散化を説明する図である。 図５は、実施例２に係るサーバの構成を示すブロック図である。 図６は、ＶＭのルール管理簿に記憶される情報の例を示す図である。 図７は、ＶＭのＣＥＰ状態管理簿に記憶される中間データの例を示す図である。 図８は、ルール関連度管理簿に記憶される情報の例を示す図である。 図９は、配信リスト／ストリーム負荷管理簿に記憶される情報の例を示す図である。 図１０は、資源負荷管理簿に記憶される情報の例を示す図である。 図１１は、実施例２に係るサーバにおける分散化処理の流れを示すフローチャートである。 図１２は、実施例２に係る移動元ＶＭにおける分散化処理の流れを示すフローチャートである。 図１３は、実施例２に係る移動先ＶＭにおける分散化処理の流れを示すフローチャートである。 図１４は、実施例３に係る複合イベント処理の分散化を説明する図である。 図１５は、実施例３に係るルール関連度管理簿に記憶される情報の例を示す図である。 図１６は、実施例３に係る配信リスト／ストリーム負荷管理簿に記憶される情報の例を示す図である。 図１７は、実施例３に係る資源負荷管理簿に記憶される情報の例を示す図である。 図１８は、物理サーバごとにＣＥＰエンジンを搭載したシステム構成図である。 図１９は、複合イベント分散プログラムを実行するコンピュータシステムの例を示す図である。

以下に、本願の開示する複合イベント分散装置、複合イベント分散方法および複合イベント分散プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。

図１は、実施例１に係るサーバの構成を示すブロック図である。図１に示すサーバ１は、システム上で発生するデータなどをストリームとしてリアルタイムにモニタリングし、発生したデータパターンに応じて特定の処理を実行する複合イベント処理（ＣＥＰ（Complex Event Processing））を実行するコンピュータである。なお、後述する実施例において例示したサーバの数、ＶＭの数、ルールの数、要素の数は、あくまで例示であり、これに限定されるものではない。

例えば、サーバ１は、株価や為替の変動、各種センサにより検出されたデータ、Ｗｅｂサーバ上でＨＴＴＰ（HyperText Transfer Protocol）トラフィックなどをデータストリームとして受信する。そして、サーバ１は、受信したデータストリームから事象を検出し、検出した事象の組み合わせによってイベントを特定し、特定したイベントを実行する。一例として、サーバ１は、株価や為替のデータストリームから、株価が所定値以上となったことや為替が所定値安となったことを連続して検出した場合に、取引を自動的に実行する。

ここで、図２を用いてＣＥＰ処理を具体的に説明する。図２は、ＣＥＰの動作について説明する図である。各種センサから受信されたデータストリームは、前処理を施され、時間やイベント数等の所定幅を示すウインドウの範囲内で各種条件が成立するかを判定される。図２においてＥ１〜Ｅｎは、各種の条件を示しており、Ｅ１〜Ｅｎのうち、いくつかの条件の成立状態の組み合わせが複合イベント条件（ルール）となる。そして、ルールが満たされた場合には、対応するイベント処理が発生する。

ルールが有する条件とその条件の組み合わせは、メモリ等に登録されている。また、ある時点において複合イベント条件が有する条件がどれだけ満たされているかは、中間状態管理として管理されている。この中間状態管理は、各ＶＭの仮想メモリ上に展開しておけばよい。また、サーバ１は、各ＶＭなどの性能、資源量、制約を管理する。具体的には、ＣＰＵ、メモリ、ネットワーク、リアルタイム性などを管理する。

このようなサーバ１は、算出部１ａと取得部１ｂと検出部１ｃと分散部１ｄとを有し、仮想マシン１（ＶＭ１）でＣＥＰ処理を実行する。具体的には、図３の左図のように、ＶＭ１は、イベントを検出する事象の組み合わせで形成される条件式として、ルール１とルール２、ルール３を保持する。つまり、ＶＭ１は、サーバ１に入力されるデータストリームから検出した事象からルール１を特定できた場合には、ルール１によって特定されるイベントを実行する。また、ＶＭ１は、サーバ１に入力されるデータストリームから検出した事象からルール２を特定できた場合には、ルール２によって特定されるイベントを実行する。同様に、ＶＭ１は、サーバ１に入力されるデータストリームから検出した事象からルール３を特定できた場合には、ルール３によって特定されるイベントを実行する。

このような状態において、サーバ１の算出部１ａは、ＶＭ各々が実行する、イベントを特定する条件式に基づいてストリームからイベントを検出するＣＥＰ処理の関連度を算出する。続いて、取得部１ｂは、ＶＭ各々の負荷状況を取得する。続いて、検出部１ｃは、取得部１ｂによって取得された負荷状況に基づいて、処理負荷が所定値を超えるＶＭを検出する。そして、分散部１ｄは、算出部１ａによって算出されたＣＥＰ処理の関連度に基づいて、ＶＭ各々にＣＥＰ処理を分散させる。

図３を用いて一例を説明する。図３は、実施例１に係る複合イベント処理の分散化を説明する図である。図３に示すように、サーバ１では、ＶＭ１においてルール１およびルール２、ルール３を用いたＣＥＰ処理が実行されており、ＶＭ２においてはＣＥＰ処理が実行されていない。このような状態において、サーバ１は、ＶＭ１のＣＰＵ（Central Processing Unit）使用率が閾値以上になったことを検出する。なお、ＶＭ２は、動作している状態であってもよく、動作可能に設定された未動作のＶＭであってもよい。

すると、サーバ１は、ＶＭ１で実行されるＣＥＰ処理間の関連度を算出する。例えば、サーバ１は、各ルールの実行回数／全データストリーム、又は、データストリームから検出された全事象の数、各ルール間の通信回数、各ルール間の通信率などを算出する。そして、サーバ１は、ルール１とルール２の関連度よりも、ルール２とルール３の関連度の方が、関連度が大きいと算出したとする。

この場合、サーバ１は、図３に示すように、ＶＭ１が保持しているルール２とルール３をＶＭ２に移動させる。つまり、サーバ１は、ＶＭ１で実行されるルール２に基づくＣＥＰ処理と、ルール２に基づくＣＥＰ処理と関係の強いルール３に基づくＣＥＰ処理とをＶＭ２に移動させる。なお、ＶＭ２が未動作の場合には、ルールの移行の前処理として、動作させる。

この結果、サーバ１は、ＣＥＰ処理を実行するＶＭの処理負荷が許容範囲を超えた場合に、関係性の強いＣＥＰ処理を集約することができ、また、ＣＥＰ処理を集約することでルール間を跨った通信処理を低減することができる。したがって、実施例１に係るサーバ１は、ＣＥＰ処理性能の劣化を防止できる。

実施例２では、複合イベント処理の関連度として、各ＶＭが保持するルール間の関連度に基づいて、ルールを動的に移動させて複合イベント処理を分散化する例について説明する。ここでは、実施例２の全体構成、サーバの構成、処理の流れ、実施例２による効果を順に説明する。

［全体構成］
図４は、実施例２に係る複合イベント処理の分散化を説明する図である。図４の（ａ）に示すように、実施例２に係るサーバ１０は、ＶＭ１とＶＭ２とのそれぞれでＣＥＰ処理を実行する。具体的には、ＶＭ１は、条件式として、ルール１とルール２を保持する。ＶＭ２は、条件式としてルール３とルール４を保持する。なお、初期段階で、各ＶＭにルールを割り振る手法としては、ルールの関係性等に基づいて、管理者が手動で割り振ることができる。例えば、関連度の強い２つのルールを予め選択してＶＭに格納し、各ＶＭが２つのルールを用いてＣＥＰ処理を実行させるようにする。また、初期段階でどのＶＭにどのルールを割り振るかについては、管理者等により、任意に設定できる。

つまり、ＶＭ１は、サーバ１０に入力されるデータストリームから検出した事象からルール１を特定できた場合には、ルール１によって特定されるイベントを実行する。また、ＶＭ１は、サーバ１０に入力されるデータストリームから検出した事象からルール２を特定できた場合には、ルール２によって特定されるイベントを実行する。

同様に、ＶＭ２は、サーバ１０に入力されるデータストリームから検出した事象からルール３を特定できた場合には、ルール３によって特定されるイベントを実行する。また、ＶＭ２は、サーバ１０に入力されるデータストリームから検出した事象からルール４を特定できた場合には、ルール４によって特定されるイベントを実行する。

このような状態において、サーバ１０は、例えばＶＭ１とＶＭ２との間でやり取りされる通信量が閾値以上になったなどＶＭの負荷が許容範囲を超えたことを検出する。すると、サーバ１０は、算出してある関連度から、ルール１〜ルール４の各ルール間の関連度を確認する。そして、サーバ１０は、ルール１とルール２の関連度が他のルール間よりも強いと算出したとする。

この場合、図４の（ｂ）に示すように、サーバ１０は、ＶＭ２が保持するルール３をＶＭ１に移動させる。つまり、サーバ１０は、ＶＭ２で実行されるルール３に基づくＣＥＰ処理をＶＭ１に移動させる。このようにして、ＣＥＰ処理を分散させて、処理性能の劣化を防止する。

［サーバの構成］
図５は、実施例２に係るサーバの構成を示すブロック図である。図５に示すように、サーバ１０は、通信制御Ｉ／Ｆ部１１と仮想領域１２とメモリ１７とプロセッサ１８とを有する。

通信制御Ｉ／Ｆ部１１は、サーバ１０と他の装置との間の通信を制御するインタフェースである。例えば、通信制御Ｉ／Ｆ部１１は、株価や為替の変動、各種センサにより検出されたデータ、Ｗｅｂサーバ上でＨＴＴＰトラフィックなどをデータストリームとして受信してプロセッサ１８に出力する。

仮想領域１２は、プロセッサ１８によって作成された複数のＶＭを起動する領域であり、任意な数のＶＭを起動することができる。実施例２では、図５に示すように、仮想領域１２では、ＶＭ１とＶＭ２が実行されている。

ＶＭ１は、仮想メモリ１３と仮想プロセッサ１４とを有し、仮想マシンを動作制御する。仮想メモリ１３は、ＶＭ１を実行するために、サーバ１０のメモリ１７における所定領域を仮想的に割り当てた領域であり、ルール管理簿１３ａとＣＥＰ状態管理簿１３ｂとを有する。

ルール管理簿１３ａは、ＶＭ１が実行するＣＥＰ処理、言い換えると、ＶＭ１がイベントの検出に用いるルールを記憶するデータベースである。図６は、ＶＭのルール管理簿に記憶される情報の例を示す図である。図６に示すように、ルール管理簿１３ａは、「ルール名、要素リスト、イベント」を対応付けて記憶する。ここで記憶される「ルール名」は、ルールを一意に識別するルールの名称であり、「要素リスト」は、ルールを構成する要素を示し、「イベント」は、実行されるイベントを示す。

一例として、図６の場合、「ルール１」は、事象Ａを検出する「要素Ａ」と事象Ｂを検出する「要素Ｂ」と事象Ｃを検出する「要素Ｃ」で構成される。そして、ルール１は、事象Ａ、事象Ｂ、事象Ｃが順番に検出された場合に、「イベント１」を実行することを示している。なお、実施例２では、ＶＭ１のルール管理簿１３ａは、「ルール１、要素Ａ→要素Ｂ→要素Ｃ、イベント１」と、「ルール２、要素Ａ→要素Ｂ→要素Ｄ、イベント２」を保持しているものとする。

ＣＥＰ状態管理簿１３ｂは、実行中のＣＥＰ処理の状態を記憶するデータベースであり、サーバ１０が通知されたウインドウサイズと中間データを記憶する。図７は、ＶＭのＣＥＰ状態管理簿に記憶される中間データの例を示す図である。図７に示すように、ＣＥＰ状態管理簿１３ｂは、「項番、中間データ、関連ルール」を対応付けて記憶する。ここで記憶される「項番」は、記憶されるデータに一意に割り振られた番号であり、「中間データ」は、現時点で検出されている事象（要素）示し、「関連ルール」は、現時点での中間データが含まれるルールを示す。

一例として、図７の場合、「項番＝１」として、「ルール１」の要素の１つである「要素Ａ」が検出されており、「項番＝２」として、「ルール１」と「ルール２」の要素である「要素Ａ」と「要素Ｂ」が連続して検出されていることを示している。なお、ここでは中間データをテーブルで管理する場合について説明したが、これに限定されるものではなく、例えばツリー構造等で管理することもできる。

仮想プロセッサ１４は、ＶＭ１を実行するために、サーバ１０のプロセッサ１８における所定処理能力を仮想的に割り当てたプロセッサであり、ＣＥＰエンジン１４ａとルール転送部１４ｂとを有する。

ＣＥＰエンジン１４ａは、ＣＥＰ処理を実行する処理部である。例えば、ＣＥＰエンジン１４ａは、サーバ１０に入力されたデータストリームを、プロセッサ１８を介して受信して仮想メモリ１３等に格納する。続いて、ＣＥＰエンジン１４ａは、仮想メモリ１３に格納されるデータストリームからウインドウサイズのデータを読み出す。そして、ＣＥＰエンジン１４ａは、読み出したデータのうち、ルール管理簿１３ａに記憶されるルールを構成する各要素と一致するデータを中間データとしてＣＥＰ状態管理簿１３ｂに格納する。このようにして、ＣＥＰエンジン１４ａは、データストリームから事象を検出して、中間データを生成する。

また、ＣＥＰエンジン１４ａは、ＣＥＰ状態管理簿１３ｂに記憶される中間データがルール管理簿１３ａに記憶されるルールと一致した場合には、一致したルールによって指定されるイベントを実行する。例えば、ＣＥＰエンジン１４ａは、ＣＥＰ状態管理簿１３ｂに記憶される中間データとして事象Ａ〜事象Ｃが連続して検出されたことを示す「要素Ａ→要素Ｂ→要素Ｃ」が格納される場合、ルール１と一致するので、ルール１によって指定されたイベント１を実行する。そして、ＣＥＰエンジン１４ａは、当該中間データをＣＥＰ状態管理簿１３ｂから削除する。

ルール転送部１４ｂは、プロセッサ１８からルールの移動指示を受信した場合、対象ルールおよび対象ルールに関する各種情報を移動先ＶＭに移動させる。例えば、ルール転送部１４ｂは、ルール１をＶＭ２に移動させる転送指示をプロセッサ１８から受信したとする。この場合、ルール転送部１４ｂは、ルール管理簿１３ａに記憶されるルール１をＶＭ２のルール管理簿１５ａにコピーするとともに、ＣＥＰ状態管理簿１３ｂの「関連ルール」が「ルール１」となっている情報をＶＭ２のＣＥＰ状態管理簿１５ｂにコピーする。その後、ルール転送部１４ｂは、コピー先とコピー元でコピーした各情報の同期を取った後に、コピー元の情報を削除する。

ＶＭ２は、ＶＭ１と同様、仮想メモリ１５と仮想プロセッサ１６とを有する。なお、仮想メモリ１５は、ＶＭ１の仮想メモリ１３と同様の機能を有し、仮想プロセッサ１６は、ＶＭ１の仮想プロセッサ１４と同様の機能を有するので、ここでは詳細な説明は省略する。ただし、実施例２では、ＶＭ２のルール管理簿１５ａは、「ルール３、要素Ｅ→要素Ｆ→要素Ｃ、イベント３」と、「ルール４、要素Ｇ→要素Ｈ→要素Ｉ、イベント４」を保持しているものとする。

図５に戻り、メモリ１７は、プロセッサ１８による各種処理に必要なデータおよびプログラム、指定されたウインドウサイズ等を格納するメモリであり、ルール関連度管理簿１７ａと配信リスト／ストリーム負荷管理簿１７ｂと資源負荷管理簿１７ｃとを有する。なお、メモリ１７は、必ずしもメモリである必要はなく、半導体メモリ素子、または、ハードディスクなどの記憶装置であってもよい。

ルール関連度管理簿１７ａは、ルール間の関連度を記憶するデータベースである。図８は、ルール関連度管理簿に記憶される情報の例を示す図である。図８に示すように、ルール関連度管理簿１７ａは、「ルール名、要素リスト／イベント、ルール関連度、関連度の強さ、資源負荷状況（ＣＰＵ使用率、メモリ使用率、ネットワーク使用率）」を対応付けて記憶する。

ここで記憶される「ルール名」は、ルールを一意に識別するルールの名称であり、「要素リスト／イベント」は、ルールを構成する事象と実行対象となるイベントを示す。「ルール関連度」には、関連性の強さとして、ルール内の要素の重複数を基に算出された＜関連ルール数（関連要素数）＞が格納される。「関連度の強さ」は、関連する全てのルールを、関連度の低い順にリストした情報である。「ＣＰＵ使用率」は、当該ルールを実行するのに使用された仮想プロセッサの使用率であり、「メモリ使用率」は、当該ルールを実行するのに使用された仮想メモリの使用率である。「ネットワーク使用率」は、当該ルールの実行時に使用されたネットワークの使用率である。

一例として、図８の場合、「要素Ａ→要素Ｂ→要素Ｃ／イベント１」である「ルール１」は、「要素Ａ、要素Ｂ、要素Ｃ」のいずれかを要素とする他ルールが＜２＞つあり、他ルールと重複している要素（事象）が（３）つあることを示す。また、「ルール１」は、ルール２と最も関連度が強く、次にルール３と関連度が強い。ルール１のＣＰＵ使用率が「４３％」であり、メモリ使用率が「４０％」であり、ネットワーク使用率が「７０％」であることを示している。

また、「要素Ａ→要素Ｂ→要素Ｄ／イベント２」である「ルール２」は、「要素Ａ、要素Ｂ、要素Ｄ」のいずれかを要素とする他ルールが＜１＞つあり、他ルールと重複している要素（事象）が（２）つあることを示す。また、「ルール２」は、ルール１と最も関連度が強い。また、ルール２のＣＰＵ使用率が「６０％」であり、メモリ使用率が「５０％」であり、ネットワーク使用率が「４０％」であることを示している。

また、「要素Ｅ→要素Ｆ→要素Ｃ／イベント３」である「ルール３」は、「要素Ｅ、要素Ｄ、要素Ｃ」のいずれかを要素とする他ルールが＜１＞つあり、他ルールと重複している要素（事象）が（１）つあることを示す。また、「ルール３」は、ルール１と最も関連度が強い。また、ルール３のＣＰＵ使用率が「１０％」であり、メモリ使用率が「１２％」であり、ネットワーク使用率が「３０％」であることを示している。

また、「要素Ｇ→要素Ｈ→要素Ｉ／イベント４」である「ルール４」は、「要素Ｇ、要素Ｈ、要素Ｉ」のいずれかを要素とする他ルールが＜０＞であり、他ルールと重複している要素（事象）が（０）であることを示す。また、ルール４のＣＰＵ使用率が「２０％」であり、メモリ使用率が「３５％」であり、ネットワーク使用率が「１０％」であることを示している。

なお、ルール関連度管理簿１７ａに記憶される「ルール名、要素リスト／イベント」は、管理者等によって設定される値である。「ルール関連度」は、システム起動時に、後述する関連度算出部１８ａが算出した値であり、ルールが変更された場合に更新される。「資源負荷状況」は、システム起動時は空白であり、システム起動後に、後述する資源負荷計測部１８ｃによって計測された値であり、随時更新される。

図５に戻り、配信リスト／ストリーム負荷管理簿１７ｂは、ルールの配信先ＶＭや配信されたルールの全ストリームに対する割合等を記憶するデータベースである。図９は、配信リスト／ストリーム負荷管理簿に記憶される情報の例を示す図である。図９に示すように、配信リスト／ストリーム負荷管理簿１７ｂは、「ルール名、配信先リスト、ストリーム負荷」を対応付けて記憶する。

ここで記憶される「ルール名」は、ルールを一意に識別するルールの名称であり、「配信先リスト」は、当該ルールを保持する、当該ルールに基づいてＣＥＰ処理を実行するＶＭを示す。「ストリーム負荷」は、全ストリームにおいて当該ルールが適合した割合や頻度を示す。なお、「ルール名」と「配信先リスト」は、後述する分散実行部１８ｆによって格納および更新される。「ストリーム負荷」は、システム起動時は空白であり、システム起動後に、後述するストリーム負荷計測部１８ｄによって計測された値であり、随時更新される。

一例として、図９の場合、「ルール１」は、「ＶＭ１」に保持され、全ストリームに対して「４０％」の割合で適合していることを示す。「ルール２」は、「ＶＭ１」に保持され、全ストリームに対して「１０％」の割合で適合していることを示す。「ルール３」は、「ＶＭ２」に保持され、全ストリームに対して「３０％」の割合で適合していることを示す。

資源負荷管理簿１７ｃは、ルールが配信されてＣＥＰ処理を実行するＶＭの処理負荷を記憶するデータベースである。図１０は、資源負荷管理簿に記憶される情報の例を示す図である。図１０に示すように、資源負荷管理簿１７ｃは、「ＶＭ名、ルールリスト、資源負荷状況（ＣＰＵ使用率、メモリ使用率、ネットワーク使用率）」を対応付けて記憶する。

ここで記憶される「ＶＭ名」は、サーバ１０の仮想領域１２で稼動するＶＭを識別するＶＭの名称であり、「ルールリスト」は、ＶＭが保持するルールのリストを示す。「ＣＰＵ使用率」は、ＶＭにおける仮想プロセッサの使用率であり、「メモリ使用率」は、ＶＭにおける仮想メモリの使用率である。「ネットワーク使用率」は、ＶＭ間のネットワークの使用率である。なお、「ＶＭ名」と「ルールリスト」は、後述する分散実行部１８ｆによって格納および更新される。「資源負荷状況」は、システム起動時は空白であり、システム起動後に、後述する資源負荷計測部１８ｃによって計測された値であり、随時更新される。

一例として、図１０の場合、「ＶＭ１」は、「ルール１」と「ルール２」とを保持してＣＥＰ処理を実行し、現時点の「ＣＰＵ負荷率」が「３０％」、「メモリ使用率」が「３１％」、「ネットワーク使用率」が「８０％」であることを示す。また、「ＶＭ２」は、「ルール３」と「ルール４」とを保持してＣＥＰ処理を実行し、現時点の「ＣＰＵ負荷率」が「５５％」、「メモリ使用率」が「４５％」、「ネットワーク使用率」が「４０％」であることを示す。

図５に戻り、プロセッサ１８は、ＯＳ（Operating System）などの制御プログラム、各種の処理手順などを規定したプログラムおよび所要データを格納するための内部メモリを有するＣＰＵなどである。プロセッサ１８は、関連度算出部１８ａとストリーム受信部１８ｂと資源負荷計測部１８ｃとストリーム負荷計測部１８ｄと分散決定部１８ｅと分散実行部１８ｆとを有し、これらによって各種処理を実行する。

関連度算出部１８ａは、ルール間の関連度を算出してルール関連度管理簿１７ａに格納する。例えば、関連度算出部１８ａは、システムが起動された場合や管理者等から関連度を算出する指示を受信した場合に、ルール間の関連度を算出する。

一例として、ルール１〜ルール４が図８に示す要素で形成される場合について説明する。この場合、関連度算出部１８ａは、ルール１を形成する要素Ａがルール２に含まれ、要素Ｂがルール２に含まれ、要素Ｃがルール３に含まれることにより、ルール関連度の「関連要素数」を「３」とする。また、関連度算出部１８ａは、ルール１における「要素Ａ→要素Ｂ」とする要素間の繋がりが、ルール２に含まれていることを検出する。さらに、関連度算出部１８ａは、ルール１では「要素Ｃ」が３番目の要素であり、このことがルール３でも同様であることを検出する。この結果、関連度算出部１８ａは、「関連ルール数」を「２」とする。したがって、関連度算出部１８ａは、ルール１のルール関連度として、図８に示すように、＜関連ルール数（関連要素数）＞に＜２（３）＞と格納する。また、関連度算出部１８ａは、要素Ａと要素Ｂの２つがルール２に含まれおり、要素Ｃの１つがルール３に含まれていることより、「関連度の強さ」として「ルール３→ルール２」を格納する。つまり、ルール１は、ルール２、ルール３の順番で関連度が強い。

また、関連度算出部１８ａは、ルール２を形成する要素Ａがルール１に含まれ、要素Ｂもルール１に含まれ、要素Ｄがいずれのルールにも含まれていないことにより、ルール関連度の「関連要素数」を「２」とする。また、関連度算出部１８ａは、ルール２における「要素Ａ→要素Ｂ」とする要素間の繋がりが、ルール１に含まれていることを検出する。この結果、関連度算出部１８ａは、「関連ルール数」を「１」とする。したがって、関連度算出部１８ａは、ルール２のルール関連度として、図８に示すように、＜関連ルール数（関連要素数）＞に＜１（２）＞と格納する。また、関連度算出部１８ａは、要素Ａと要素Ｂの２つがルール１に含まれていることより、「関連度の強さ」として「ルール１」を格納する。

また、関連度算出部１８ａは、ルール３を形成する要素Ｃがルール１に含まれ、要素Ｅと要素Ｆがいずれのルールにも含まれていないことにより、ルール関連度の「関連要素数」を「１」とする。また、関連度算出部１８ａは、ルール３において「要素Ｃ」が３番目の要素であり、このことがルール１にも含まれていることを検出する。この結果、関連度算出部１８ａは、「関連ルール数」を「１」とする。したがって、関連度算出部１８ａは、ルール３のルール関連度として、図８に示すように、＜関連ルール数（関連要素数）＞に＜１（１）＞と格納する。また、関連度算出部１８ａは、要素Ｃがルール１に含まれていることより、「関連度の強さ」として「ルール１」を格納する。

また、関連度算出部１８ａは、ルール４を形成するいずれの要素もいずれのルールに含まれていないことにより、ルール関連度の「関連要素数」を「０」とする。また、関連度算出部１８ａは、ルール４の要素の順番や要素間の繋がりもいずれのルールにも含まれていないと検出する。この結果、関連度算出部１８ａは、「関連ルール数」を「０」とする。したがって、関連度算出部１８ａは、ルール４のルール関連度として、図８に示すように、＜関連ルール数（関連要素数）＞に＜０（０）＞と格納する。

図５に戻り、ストリーム受信部１８ｂは、通信制御Ｉ／Ｆ部１１を介して受信したデータストリームをメモリ１７に格納するとともに、当該データストリームを複製して、ＶＭ１とＶＭ２のそれぞれに送信する。別の手法としては、ストリーム受信部１８ｂは、配信リスト／ストリーム負荷管理簿１７ｂを参照し、ルール１またはルール３に関するデータストリームをＶＭ１に送信し、ルール２またはルール４に関するデータストリームをＶＭ２に送信することもできる。つまり、ストリーム受信部１８ｂは、各ＶＭに対して、ＶＭが保持するルールに関係するデータのみを送信することもできる。

資源負荷計測部１８ｃは、各ＶＭの資源負荷状況と各ルールの資源負荷状況とを計測して、ルール関連度管理簿１７ａと資源負荷管理簿１７ｃに格納する。例えば、資源負荷計測部１８ｃは、５分ごとなど予め指定されたタイミングで、ＶＭ１とＶＭ２のそれぞれから「ＣＰＵ使用率」と「メモリ使用率」と「ネットワーク使用率」とを取得して資源負荷管理簿１７ｃに格納する。

つまり、資源負荷計測部１８ｃは、サーバ１０内のプロセッサ１８における処理性能の数十％ずつが割り当てられた仮想プロセッサ１４と仮想プロセッサ１６のそれぞれが、割り当てられたプロセッサ処理性能のうちどのくらいを使用しているかを取得する。同様に、資源負荷計測部１８ｃは、サーバ１０内のメモリ１７の領域の数十％ずつが割り当てられた仮想メモリ１３と仮想メモリ１５のそれぞれが、割り当てられた領域のうちどのくらいを使用しているかを取得する。また、資源負荷計測部１８ｃは、ＶＭ１またはＶＭ２が使用しているネットワーク帯域の割合を取得する。

また、資源負荷計測部１８ｃは、５分ごとなど予め指定されたタイミングで、ＶＭ１の仮想プロセッサ１４が各ルールをどのくらい保持しているか、言い換えると、各ルールを処理対象として処理を実行しているかを取得してルール関連度管理簿１７ａに格納する。同様に、資源負荷計測部１８ｃは、５分ごとなど予め指定されたタイミングで、ＶＭ２の仮想プロセッサ１６が各ルールをどのくらい保持しているかを取得してルール関連度管理簿１７ａに格納する。

なお、資源負荷計測部１８ｃが資源負荷状況を取得する手法としては、既知の様々な手法を用いることができ、例えば監視ソフトウエア等を用いることもできる。また、資源負荷計測部１８ｃは、各ＶＭから資源負荷状況を取得することもでき、各ＶＭが定期的に収集した資源負荷状況を取得するようにしてもよい。

図５に戻り、ストリーム負荷計測部１８ｄは、配信されたルールの全ストリームに対する割合等を計測して、配信リスト／ストリーム負荷管理簿１７ｂに格納する。例えば、ストリーム負荷計測部１８ｄは、「ルール１が実行された回数／ストリームから検出された全事象の数」や「ルール１が実行された回数／全ルールの実行回数」等から、各ルールごとに「ストリーム負荷」を算出する。なお、各ルールの実行回数は、ＶＭ等で計数して各仮想メモリ等に格納しておいてもよく、ストリーム負荷計測部１８ｄが計測してメモリ１７に格納しておいてもよい。

分散決定部１８ｅは、処理負荷が所定値を超えるＶＭが検出された場合、ルール間の関連度に基づいて、ＶＭ各々にルールを移動させる。例えば、分散決定部１８ｅは、ルール関連度管理簿１７ａまたは資源負荷管理簿１７ｃに記憶される資源負荷状況が閾値超えるＶＭが存在する場合に、当該ＶＭを処理負荷が所定値を超えるＶＭとして検出する。また、分散決定部１８ｅは、配信リスト／ストリーム負荷管理簿１７ｂに記憶されるストリーム負荷が閾値を超えるルールが検出された場合、当該ルールを保持するＶＭを処理負荷が所定値を超えるＶＭとして検出する。例えば、分散決定部１８ｅは、ネットワーク使用率が７０％以上であるＶＭを検出した場合、処理負荷が高いＶＭが検出されたとする。

続いて、分散決定部１８ｅは、ルール関連度管理簿１７ａに記憶される「ルール関連度」に基づいてルールの移動先を決定する。一例として、分散決定部１８ｅは、「ルール関連度」における「関連ルール数」または「関連要素数」の最大値が２以上となるルールをＶＭ１に集約し、２未満となるルールをＶＭ２に集約するなどと決定する。別の例としては、分散決定部１８ｅは、「ルール関連度」における『「関連ルール数」×「関連要素数」』が１以上となるルールをＶＭ１に集約し、１未満となるルールをＶＭ２に集約するなどと決定する。別例としては、分散決定部１８ｅは、「ルール関連度」における『「関連ルール数」×「関連要素数」』が２以上となるルールのうち、関連度の強さを参照して、関連し合うルール（例えば、ルール１とルール２）をＶＭ１に集約し、その他のルールをＶＭ２に集約するなどと決定する。

ここで、分散決定部１８ｅは、上述した手法等により、ルール１とルール２とルール３をＶＭ１に集約し、ルール４をＶＭ２に集約すると決定したとする。この場合、分散決定部１８ｅは、図１０に示した資源負荷管理簿１７ｃを参照して、ＶＭ１にはルール１とルール２が保持されており、ＶＭ２にはルール３とルール４が保持されていることにより、ルール３を移動対象と決定する。そして、分散決定部１８ｅは、移動対象としてルール３が決定されたことを分散実行部１８ｆに通知する。

なお、分散決定部１８ｅが分散させるルールを決定する手法が上述した手法以外にも、例えば、ストリーム負荷や資源負荷等を用いる手法など様々な手法を用いることができるが、他の手法については実施例４等で説明するので、ここでは省略する。

図５に戻り、分散実行部１８ｆは、分散決定部１８ｅによって決定された分散ルールに基づいてルールを移動させる。例えば、分散実行部１８ｆは、分散ルールとして、ルール３をＶＭ２からＶＭ１に移動させることを受信したとする。この場合、分散実行部１８ｆは、ＶＭ２のルール転送部１６ｂに対して、ルール３およびルール３に関する各種情報をＶＭ１に移動させる指示を送信する。

そして、分散実行部１８ｆは、ＶＭ１のルール転送部１４ｂまたはＶＭ２のルール転送部１６ｂから、移動が正常に完了した通知を受信すると、配信リスト／ストリーム負荷管理簿１７ｂの配信リストや資源負荷管理簿１７ｃのルールリストを更新する。

［処理の流れ］
次に、図１１〜図１３を用いて、実施例２に係るサーバにおける各種処理を説明する。図１１は、実施例２に係るサーバにおける分散化処理の流れを示すフローチャートである。図１２は、実施例２に係る移動元ＶＭにおける分散化処理の流れを示すフローチャートであり、図１３は、実施例２に係る移動先ＶＭにおける分散化処理の流れを示すフローチャートである。

（サーバにおける分散化処理の流れ）
図１１に示すように、サーバ１０の関連度算出部１８ａは、システムが起動されると（ステップＳ１０１Ｙｅｓ）、各ルール間の関連度を算出して、ルール関連度管理簿１７ａに格納する（ステップＳ１０２）。

その後、資源負荷計測部１８ｃやストリーム負荷計測部１８ｄは、各ＶＭの負荷状況や各ルールの負荷状況を取得して、負荷状況を監視する（ステップＳ１０３）。そして、分散決定部１８ｅは、処理負荷が所定値を超えるＶＭが検出された場合（ステップＳ１０４Ｙｅｓ）、選択論理を決定する（ステップＳ１０５）。

つまり、分散決定部１８ｅは、ルールを分散させる選択条件を管理者等から受け付けて、受け付けた選択条件に基づいて、ルールの分散を決定する。なお、上述した例では、「ルール関連度」に基づいて決定する手法を例示したが、ここでは、「負荷状況」と「ルール関連度」に基づいて決定する例で説明する。

そして、分散決定部１８ｅは、閾値越え資源を多く消費するルールを複数選択する（ステップＳ１０６）。続いて、分散決定部１８ｅは、選択したルールの関連度から、比重を用いて分散効率を計算する（ステップＳ１０７）。

その後、分散決定部１８ｅは、計算した分散効率が最大であった場合（ステップＳ１０８Ｙｅｓ）、計算した分散効率となる分散化ルールを決定する（ステップＳ１０９）。続いて、分散決定部１８ｅは、決定した分散化ルールに基づいて、移動対象となるルールと移動先ＶＭと移動元ＶＭとを決定する（ステップＳ１１０）。

そして、分散実行部１８ｆは、分散決定部１８ｅによって決定された分散ルールに基づいて、移動元ＶＭに対して移動資源の切り離しを指示する（ステップＳ１１１）。つまり、分散実行部１８ｆは、移動元ＶＭに対して、移動対象のルールを移動先ＶＭに移動させる指示を送信する。

また、分散実行部１８ｆは、分散決定部１８ｅによって決定された分散ルールに基づいて、移動先ＶＭに対して移動資源の受け入れを指示する（ステップＳ１１２）。つまり、分散実行部１８ｆは、移動先ＶＭに対して、移動対象のルールを移動元ＶＭから受信する指示を送信する。

その後、ルールの移動、つまり、ＣＥＰ処理の分散化が終了すると（ステップＳ１１３Ｙｅｓ）、ステップＳ１０３以降の処理を実行する。

（移動元ＶＭにおける分散化処理の流れ）
図１２に示すように、移動元ＶＭのルール転送部は、サーバ１０からルールの資源切り離し指示を受信すると、指定されたルールの資源を分離する（ステップＳ２０１）。例えば、ルール転送部は、移動対象ルールをＣＥＰ処理対象外として、仮想メモリ等から分離する。

続いて、移動元ＶＭのルール転送部は、排他／同期処理を開始し（ステップＳ２０２）、移動先ＶＭに指定されたルールおよび管理資源を転送する（ステップＳ２０３）。例えば、ルール転送部は、移動対象ルールによるＣＥＰ処理を停止する排他制御を実行し、ルール管理簿に記憶される移動対象のルールおよびＣＥＰ状態管理簿に記憶される「関連ルール」が移動対象ルールとなっている情報を移動先ＶＭにコピーする。

そして、移動元ＶＭのルール転送部は、移動先ＶＭへのルールおよび管理資源の転送が終了すると（ステップＳ２０４Ｙｅｓ）、排他／同期処理を終了する（ステップＳ２０５）。

（移動先ＶＭにおける分散化処理の流れ）
図１３に示すように、移動先ＶＭのルール転送部は、サーバ１０からルールの資源受け入れ指示を受信すると、排他／同期処理を開始する（ステップＳ３０１）。例えば、ルール転送部は、移動実行中のルールに対するＣＥＰ処理を停止する排他制御を実行する。

そして、移動先ＶＭのルール転送部は、指定されたルールおよび管理資源を移動先ＶＭから授受する（ステップＳ３０２）。例えば、ルール転送部は、受信したルールをルール管理簿に格納するとともに、受信した関連ルール等をＣＥＰ状態管理簿に格納する。

そして、移動先ＶＭのルール転送部は、移動先ＶＭからのルールおよび管理資源の転送が終了すると（ステップＳ３０３Ｙｅｓ）、排他／同期処理を解除し（ステップＳ３０４）、サーバ１０のプロセッサ１８に完了通知を送信する（ステップＳ３０５）。

［実施例２による効果］
このように、実施例２によれば、資源負荷状況に基づき、ＣＥＰのルール単位に、別ＶＭに動的に移動することができ、同一ＶＭ上のＣＥＰ処理が資源的に厳しくなった場合、動的に負荷分散することができる。また、ＣＥＰ処理負荷が増大した場合、ルール間の関連性と、ＣＥＰ処理負荷割合を基に、最も分離オーバヘッドが少なくかつ負荷を分散できる組合せを選択し、それらを別ＶＭに移動することができる。

実施例３では、複合イベント処理の関連度として、各ルールを形成する要素間の関連度に基づいて、ルールを要素に分割して動的に移動させて複合イベント処理を分散化する例について説明する。

図１４は、実施例３に係る複合イベント処理の分散化を説明する図である。図１４の（ａ）に示すように、実施例３に係るサーバ１０は、ＶＭ１とＶＭ２を動作させており、ＶＭ１でＣＥＰ処理を実行する。具体的には、ＶＭ１は、条件式として、要素Ａ→要素Ｂ→要素Ｃで形成されるルール１と、要素Ａ→要素Ｂ→要素Ｄで形成されるルール２とを保持する。また、ＶＭ１は、条件式として、要素Ｅ→要素Ｆ→要素Ｃで形成されるルール３と、要素Ｇ→要素Ｈ→要素Ｉで形成されるルール４を保持する。なお、要素間の矢印は、要素の連続性を示し、例えば要素Ａ→要素Ｂ→要素Ｃの場合、要素Ａ、要素Ｂ、要素Ｃが連続して実行された場合にルール１に適合することを示す。

つまり、ＶＭ１は、サーバ１０に入力されるデータストリームから検出した事象からルール１を特定できた場合には、ルール１によって特定されるイベントを実行する。また、ＶＭ１は、サーバ１０に入力されるデータストリームから検出した事象からルール２を特定できた場合には、ルール２によって特定されるイベントを実行する。

同様に、ＶＭ１は、サーバ１０に入力されるデータストリームから検出した事象からルール２を特定できた場合には、ルール３によって特定されるイベントを実行する。また、ＶＭ１は、サーバ１０に入力されるデータストリームから検出した事象からルール４を特定できた場合には、ルール４によって特定されるイベントを実行する。

このような状態において、サーバ１０は、例えばＶＭ１のＣＰＵ使用率等が所定値以上となったなどＶＭ１の負荷が許容範囲を超えたことを検出する。すると、サーバ１０は、ルール１〜ルール４の各ルールを形成する要素の組み合わせ数および／またはルールにおける要素間の繋がりに基づいて、要素間の関連度を算出する。

そして、例えば図１４の（ｂ）に示すように、サーバ１０は、関連度の強い要素Ａと要素ＢをＶＭ１で動作させ、他の要素と特に関連度が強くない要素Ｃ〜要素ＩをＶＭ２で動作させるように、要素を移動させる。

次に、図１５〜図１７を用いて、要素間の関連度に基づいて、ルールを要素に分割して動的に移動させる具体例を説明する。図１５は、実施例３に係るルール関連度管理簿に記憶される情報の例を示す図である。図１６は、実施例３に係る配信リスト／ストリーム負荷管理簿に記憶される情報の例を示す図である。図１７は、実施例３に係る資源負荷管理簿に記憶される情報の例を示す図である。

図１５に示すように、サーバ１０のルール関連度管理簿１７ａは、「要素名、要素関連度、ルール関連度、資源負荷状況（ＣＰＵ使用率、メモリ使用率、ネットワーク使用率）」を対応付けて記憶する。

ここで記憶される「要素名」は、ルールを形成する要素を識別する要素の名称である。「要素関連度」は、関連性の強さとして、ルール内の要素の重複数を基に算出された＜要素組み合わせ数＆（要素の「入」＋「出」数）＞が格納される。なお、要素の「入」＋「出」とは、「要素Ａ→要素Ｂ→要素Ｃ」の「要素Ｂ」に着目した場合、「入」が「要素Ａ」側で「出」が「要素Ｃ」側となる。

「ルール関連度」は、当該要素を構成要素とするルールを示し、「ＣＰＵ使用率」は、当該要素を実行するのに使用された仮想プロセッサの使用率であり、「メモリ使用率」は、当該要素を実行するのに使用された仮想メモリの使用率である。「ネットワーク使用率」は、当該要素の実行時に使用されたネットワークの使用率である。

ここで、関連度算出部１８ａが図１５を生成する処理を具体的に説明する。ここでは、実施例２と同様のルール１〜ルール４を用いることとする。つまり、「ルール１」は、「要素Ａ→要素Ｂ→要素Ｃ」で形成され、「ルール２」は、「要素Ａ→要素Ｂ→要素Ｄ」で形成されるものとする。また、「ルール３」は、「要素Ｅ→要素Ｆ→要素Ｃ」で形成され、「ルール４」は、「要素Ｇ→要素Ｈ→要素Ｉ」で形成されるものとする。

まず、要素Ａについて説明する。関連度算出部１８ａは、「要素Ａ→要素Ｂ」の組み合わせがルール１とルール２に含まれ、さらに、「要素Ａ→要素Ｂ」において要素Ａの「入」が１つあることを検出する。この結果、関連度算出部１８ａは、「要素Ａ」の「要素関連度」に＜２＆１：（Ａ→Ｂ）＞を格納するとともに、＜２＆１：（Ａ→Ｂ）＞に対応付けて「ルール関連度」に「ルール１／２」を格納する。

続いて、関連度算出部１８ａは、「要素Ａ→要素Ｂ→要素Ｃ」の組み合わせがルール１に含まれ、さらに、「要素Ａ→要素Ｂ→要素Ｃ」において要素Ａの「入」が１つあることを検出する。この結果、関連度算出部１８ａは、「要素Ａ」の「要素関連度」に＜１＆１：（Ａ→Ｂ）→Ｃ＞を格納するとともに、＜１＆１：（Ａ→Ｂ）→Ｃ＞に対応付けて「ルール関連度」に「ルール１」を格納する。

続いて、関連度算出部１８ａは、「要素Ａ→要素Ｂ→要素Ｄ」の組み合わせがルール２に含まれ、さらに、「要素Ａ→要素Ｂ→要素Ｃ」において要素Ａの「入」が１つあることを検出する。この結果、関連度算出部１８ａは、「要素Ａ」の「要素関連度」に＜１＆１：（Ａ→Ｂ）→Ｄ＞を格納するとともに、＜１＆１：（Ａ→Ｂ）→Ｄ＞に対応付けて「ルール関連度」に「ルール２」を格納する。

次に、要素Ｂについて説明する。関連度算出部１８ａは、「要素Ａ→要素Ｂ」の組み合わせがルール１とルール２に含まれ、さらに、「要素Ａ→要素Ｂ」において要素Ｂの「出」が１つあることを検出する。この結果、関連度算出部１８ａは、「要素Ｂ」の「要素関連度」に＜２＆１：（Ａ→Ｂ）＞を格納するとともに、＜２＆１：（Ａ→Ｂ）＞に対応付けて「ルール関連度」に「ルール１／２」を格納する。

続いて、関連度算出部１８ａは、「要素Ａ→要素Ｂ→要素Ｃ」の組み合わせがルール１に含まれ、さらに、「要素Ａ→要素Ｂ→要素Ｃ」において要素Ｂの「入」が１つかつ「出」が１つであることを検出する。この結果、関連度算出部１８ａは、「要素Ｂ」の「要素関連度」に＜１＆２：Ａ→Ｂ→Ｃ＞を格納するとともに、＜１＆２：Ａ→Ｂ→Ｃ＞に対応付けて「ルール関連度」に「ルール１」を格納する。

続いて、関連度算出部１８ａは、「要素Ａ→要素Ｂ→要素Ｄ」の組み合わせがルール２に含まれ、さらに、「要素Ａ→要素Ｂ→要素Ｄ」において要素Ｂの「入」が１つかつ「出」が１つであることを検出する。この結果、関連度算出部１８ａは、「要素Ｂ」の「要素関連度」に＜１＆２：Ａ→Ｂ→Ｄ＞を格納するとともに、＜１＆２：Ａ→Ｂ→Ｄ＞に対応付けて「ルール関連度」に「ルール２」を格納する。

次に、要素Ｃについて説明する。関連度算出部１８ａは、「要素Ａ→要素Ｂ→要素Ｃ」の組み合わせがルール１に含まれ、さらに、「要素Ａ→要素Ｂ→要素Ｃ」において要素Ｃの「入」が１つあることを検出する。この結果、関連度算出部１８ａは、「要素Ｃ」の「要素関連度」に＜１＆１：Ａ→（Ｂ→Ｃ）＞を格納するとともに、＜１＆１：Ａ→（Ｂ→Ｃ）＞に対応付けて「ルール関連度」に「ルール１」を格納する。

続いて、関連度算出部１８ａは、「要素Ｅ→要素Ｆ→要素Ｃ」の組み合わせがルール３に含まれ、さらに、「要素Ｅ→要素Ｆ→要素Ｃ」において要素Ｃの「入」が１つあることを検出する。この結果、関連度算出部１８ａは、「要素Ｃ」の「要素関連度」に＜１＆１：Ｅ→（Ｆ→Ｃ）＞を格納するとともに、＜１＆１：Ｅ→（Ｆ→Ｃ）＞に対応付けて「ルール関連度」に「ルール３」を格納する。

次に、要素Ｄについて説明する。関連度算出部１８ａは、「要素Ａ→要素Ｂ→要素Ｄ」の組み合わせがルール２に含まれ、さらに、「要素Ａ→要素Ｂ→要素Ｄ」において要素Ｄの「入」が１つあることを検出する。この結果、関連度算出部１８ａは、「要素Ｄ」の「要素関連度」に＜１＆１：Ａ→（Ｂ→Ｄ）＞を格納するとともに、＜１＆１：Ａ→（Ｂ→Ｄ）＞に対応付けて「ルール関連度」に「ルール２」を格納する。

上述した手法を用いて、関連度算出部１８ａは、ルール１〜ルール４が有する要素Ａ〜要素Ｉについて、要素関連度およびルール関連度を算出して、ルール関連度管理簿１７ａを生成する。なお、「資源負荷状況」は、システム起動時は空白であり、システム起動後に、資源負荷計測部１８ｃによって計測された値であり、随時更新される。

また、サーバ１０の配信リスト／ストリーム負荷管理簿１７ｂは、図１６に示すように、「要素名、配信先リスト、ストリーム負荷」を対応付けて記憶する。ここで記憶される「要素名」は、ルールを形成する要素を一意に識別する要素の名称であり、「配信先リスト」は、当該要素を保持するＶＭを示す。「ストリーム負荷」は、全ストリームにおいて当該要素（事象）が適合した割合や頻度を示す。なお、「要素名」と「配信先リスト」は、分散実行部１８ｆによって格納および更新される。「ストリーム負荷」は、システム起動時は空白であり、システム起動後に、ストリーム負荷計測部１８ｄによって計測された値であり、随時更新される。

一例として、図１６の場合、「要素Ａ」は、「ＶＭ１」に保持され、全ストリームに対して「４０％」の割合で適合していることを示す。「要素Ｂ」は、「ＶＭ１」に保持され、全ストリームに対して「１０％」の割合で適合していることを示す。「要素Ｃ」は、「ＶＭ１」に保持され、全ストリームに対して「３０％」の割合で適合していることを示す。

また、サーバ１０の資源負荷管理簿１７ｃは、図１７の（ａ）に示すように、「ＶＭ名、リスト、資源負荷状況（ＣＰＵ使用率、メモリ使用率、ネットワーク使用率）」を対応付けて記憶する。ここで記憶される「ＶＭ名」は、サーバ１０の仮想領域１２で稼動するＶＭを識別するＶＭの名称であり、「リスト」は、ＶＭが保持するルール又は要素のリストを示す。「ＣＰＵ使用率」は、ＶＭにおける仮想プロセッサの使用率であり、「メモリ使用率」は、ＶＭにおける仮想メモリの使用率である。「ネットワーク使用率」は、ＶＭ間のネットワークの使用率である。なお、「ＶＭ名」と「リスト」は、分散実行部１８ｆによって格納および更新される。「資源負荷状況」は、システム起動時は空白であり、システム起動後に、資源負荷計測部１８ｃによって計測された値であり、随時更新される。

そして、資源負荷管理簿１７ｃが図１７の（ａ）の状態で、分散決定部１８ｅは、処理負荷が所定値を超えるＶＭが検出された場合、要素間の関連度に基づいて、ＶＭ各々に要素を移動させる。例えば、分散決定部１８ｅは、ルール関連度管理簿１７ａの＜要素組み合わせ数＆（要素の「入」＋「出」数）＞の最大値が２以上である要素を１つのＶＭに移動させると決定したとする。この場合、分散決定部１８ｅは、要素Ａと要素ＢとをＶＭ１に移動させ、他の要素をＶＭ２に移動させる指示を分散実行部１８ｆに通知する。例えば、分散決定部１８ｅは、関連度が小さい方を選択する。

別例としては、分散決定部１８ｅは、ルール関連度管理簿１７ａの「要素組み合わせ数と（要素の「入」＋「出」数）との乗算結果が２以上」である要素を１つのＶＭに移動させると決定したとする。この場合、分散決定部１８ｅは、＜２＆１＞を有する要素Ａと要素ＢとをＶＭ１に移動させ、他の要素をＶＭ２に移動させる指示を分散実行部１８ｆに通知する。例えば、関連度が強い要素は、出来るだけ一つのＶＭで実行させるよう処理を行う。つまり、負荷が大きいものの中で、関連度が小さい方を選択する。

このようして、分散決定部１８ｅは、要素Ａと要素ＢとをＶＭ１に移動させ、他の要素をＶＭ２に移動させると決定したとする。この場合、分散実行部１８ｆは、ＶＭ１とＶＭ２のそれぞれに対して、要素Ａと要素ＢをＶＭ１に集約し、要素Ｃ〜要素ＩをＶＭ２に集約する指示を送信する。すると、ＶＭ１およびＶＭ２は、要素Ａと要素Ｂと要素Ａに関連する情報と要素Ｂに関連する情報とをＶＭ１に移動させ、要素Ｃ〜要素Ｉと要素Ｃ〜要素Ｉに関連する情報をＶＭ２に移動させる。

そして、分散実行部１８ｆは、ＶＭ１またはＶＭ２から移動完了通知を受信した場合、図１７の（ｂ）に示すように、ＶＭ１のリスト「ルール１／ルール２／ルール３／ルール４」から「要素Ａ、要素Ｂ」に更新する。同様に、分散実行部１８ｆは、ＶＭ２のリストとして「要素Ｃ〜要素Ｉ」を生成する。さらに、分散実行部１８ｆは、図１６に示した要素ごとの「配信先リスト」を更新する。

このように、実施例３によれば、ＣＥＰ処理負荷が増大した場合、要素間の関連性と、ＣＥＰ処理負荷割合を基に、最も分離オーバヘッドが少なく、かつ負荷を分散できる要素の組合せを選択し、各ＶＭに移動させることができる。

さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下に異なる実施例を説明する。

（サーバへの適用）
実施例１〜３では、サーバ内のＶＭでＣＥＰ処理を実行する例で説明したが、これに限定されるものではなく、物理サーバでＣＥＰ処理を実行する場合でも同様に処理することができる。図１８は、物理サーバごとにＣＥＰエンジンを搭載したシステム構成図である。図１８に示すように、このシステムは、サーバＡとサーバＢとサーバＣとサーバＤとサーバ（マネージャ）とが相互に通信可能に接続されている。

このうち、サーバＡとサーバＢとサーバＣとサーバＤは、ＣＥＰ処理を実行するサーバである。つまり、サーバＡとサーバＢとサーバＣとサーバＤは、図５に示したＶＭ１やＶＭ２と同様の機能を有し、保持するルール又は要素に基づいてイベントを実行するサーバである。また、サーバ（マネージャ）は、各サーバのＣＥＰ処理を管理するサーバである。つまり、サーバ（マネージャ）は、図５に示したプロセッサ１８の各機能部とメモリ１７の各データベースを有する。そして、サーバ（マネージャ）は、サーバＡとサーバＢとサーバＣとサーバＤの少なくとも１台の負荷が所定値以上になった場合に、実施例１〜３と同様の手法を用いて、ルール又は要素の分散を実行する。

（分散ルールの決定手法）
実施例１〜３で説明した分散ルール、言い換えると、移動対象となるルール又は要素の決定手法以外にも様々な手法を用いることができる。ここでは、移動対象となるルールを決定する例について説明するが、要素の場合も同様に実行できる。一例としては、実施例２と実施例３とを併用することもできる。

例えば、「ルール関連度」、「資源負荷状況」、「ストリーム負荷状況」各々の比重を与えて、分散値を算出し、算出した分散値が大きいものから順に、一つ、又は複数を１つのＶＭに移動させることもできる。一例として、「ルール関連度」の比重を３、「資源負荷状況」の比重を２、「ストリーム負荷状況」の比重１とする。

この場合、分散決定部１８ｅは、「ルール関連度」として「関連ルール数×関連要素数×３」を算出する。また、分散決定部１８ｅは、「資源負荷状況」として、『「ＣＰＵ使用率、メモリ使用率、ネットワーク使用率」のうち閾値を越えるものの数×２』を算出する。また、分散決定部１８ｅは、「ストリーム負荷状況」として、『閾値を超える「ストリーム負荷状況」の数×１』を算出する。そして、分散決定部１８ｅは、算出した各値を加算した結果を分散値と算出し、算出した分散値に基づいて、ルールの分散を決定する。

また、別の手法としては、「ルール関連度」、「資源負荷状況」、「ストリーム負荷状況」のうち、どの値を優先させるのか、どの値を用いるのかを管理者から受け付けた上で、上述した処理を実行することもできる。つまり、「ルール関連度」、「資源負荷状況」、「ストリーム負荷状況」の組み合わせ、比重の値等は、任意に設定することができる。

また、分散決定部１８ｅは、算出されたＣＰＵなどの資源の消費状況に基づいて、資源の消費が所定値以上である条件式のうち、ルール間の関連度が低いルール各々を別々のＶＭに移動させることで、ＣＥＰ処理を負荷分散させることもできる。同様に、分散決定部１８ｅは、算出されたＣＰＵなどの資源の消費状況に基づいて、資源の消費が所定値以上である要素のうち、要素間の関連度が低い条件式各々を別々のＶＭに移動させることで、ＣＥＰ処理を負荷分散させることもできる。なお、資源の消費としては、図８や図１５に示したルールごとの消費量または要素ごとの消費量を用いることができる。

なお、閾値越え資源を多く消費するルールで、かつ、ルール関連性が低い（＜＊（＊）＞が小さい）ルールを選択するのが負荷分散上、優位である。同様に、要素間関連性が最も低く（＜？＆？＞が最も小さく）、閾値越え資源を最も消費する要素を選択するのが、負荷分散上、優位である。

（負荷削減時の戻し）
例えば、実施例２や実施例３で説明したルールや要素を分散させた後、処理負荷が正常に戻った場合には、分散前の状態に戻すこともできる。なお、分散前の状態は、メモリ等に格納しておけばよい。一例としては、統合と分散化で「閾値」は別々に設定し、過去の実績をフィードバックして、起動タイミングを決定する。例えば、移動前の情報をメモリ等に格納しておき、処理が高くなったＶＭの処理負荷が所定値まで軽減した場合に、移動前の状態にルールを移動させたり、要素を組み合わせてルールに戻したりすることもできる。また、図８に示した関連度の強さに基づいて、例えば、分散させたルールを関連度の強いルールと弱いルールとに分けて、それぞれを別々のＶＭで実行させるようにしてもよい。

（システム）
また、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともできる。あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、例えば図６〜図１０、図１５〜図１７等に示した各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、例えば分散決定部１８ｅと分散実行部１８ｆとを統合するなど各装置の分散・統合の具体的形態は図示のものに限られない。つまり、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

（プログラム）
ところで、上記の実施例で説明した各種の処理は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータシステムで実行することによって実現することができる。そこで、以下では、上記の実施例と同様の機能を有するプログラムを実行するコンピュータシステムの一例を説明する。

図１９は、複合イベント分散プログラムを実行するコンピュータシステムの例を示す図である。図１９に示すように、コンピュータシステム１００は、バス１００ａにＣＰＵ１０５、ＲＯＭ（Read Only Memory）１０４、ＲＡＭ（Random Access Memory）１０１が接続される。また、コンピュータシステム１００は、バス１００ａにＮＩＣ（Network Interface Card）１０２、ＨＤＤ（Hard Disk Drive）１０３が接続されている。

また、ＨＤＤ１０３には、図５に示したルール関連度管理簿１７ａに対応するルール関連度管理テーブル１０３ａが設けられる。同様に、ＨＤＤ１０３には、配信リスト／ストリーム負荷管理簿１７ｂに対応する配信リスト／ストリーム負荷管理テーブル１０３ｂが設けられる。同様に、ＨＤＤ１０３には、資源負荷管理簿１７ｃに対応する資源負荷管理テーブル１０３ｃが設けられる。

ＲＯＭ１０４は、関連度算出プログラム１０４ａ、ストリーム受信プログラム１０４ｂ、資源負荷計測プログラム１０４ｃ、ストリーム負荷計測プログラム１０４ｄ、分散決定プログラム１０４ｅ、分散実行プログラム１０４ｆを保持する。タンジブル（tangible）な記録媒体の例としてＲＯＭ１０４を例に挙げたが、ＨＤＤ、ＲＡＭ、ＣＤＲＯＭ等の他のタンジブルなコンピュータ読み取り可能な記録媒体に各種プログラムを格納しておき、コンピュータに読み取らせることとしてもよい。なお、タンジブルな記憶媒体を遠隔地に配置し、コンピュータが、そのタンジブルな記憶媒体にアクセスすることでプログラムを取得して利用してもよい。また、その際、取得したプログラムをそのコンピュータ自身のタンジブルな記録媒体に格納して用いてもよい。

ＣＰＵ１０５は、関連度算出プログラム１０４ａを読み出して実行することで、関連度算出部１８ａと同様の動作を関連度算出プロセス１０５ａとして実現する。また、ＣＰＵ１０５は、ストリーム受信プログラム１０４ｂを読み出して実行することで、ストリーム受信部１８ｂと同様の動作をストリーム受信プロセス１０５ｂとして実現する。ＣＰＵ１０５は、資源負荷計測プログラム１０４ｃを読み出して実行することで、資源負荷計測部１８ｃと同様の動作を資源負荷計測プロセス１０５ｃとして実現する。

ＣＰＵ１０５は、ストリーム負荷計測プログラム１０４ｄを読み出して実行することで、ストリーム負荷計測部１８ｄと同様の動作をストリーム負荷計測プロセス１０５ｄとして実現する。ＣＰＵ１０５は、分散決定プログラム１０４ｅを読み出して実行することで、分散決定部１８ｅと同様の動作を分散決定プロセス１０５ｅとして実現する。ＣＰＵ１０５は、分散実行プログラム１０４ｆを読み出して実行することで、分散実行部１８ｆと同様の動作を分散実行プロセス１０５ｆとして実現する。このようにＲＯＭ１０４に保持した各種プログラムは、複合イベント分散プログラムの一部として機能し、コンピュータ１００は、ＲＯＭ１０４から各種プログラムを読み出して実行すること複合イベント分散方法を実行する複合イベント分散装置として動作する。

１ サーバ
１ａ 算出部
１ｂ 取得部
１ｃ 検出部
１ｄ 分散部
１０ サーバ
１１ 通信制御Ｉ／Ｆ部
１２ 仮想領域
１３、１５ 仮想メモリ
１３ａ、１５ａ ルール管理簿
１３ｂ、１５ｂ ＣＥＰ状態管理簿
１４、１６ 仮想プロセッサ
１４ａ、１６ａ ＣＥＰエンジン
１４ｂ、１６ｂ ルール転送部
１７ メモリ
１７ａ ルール関連度管理簿
１７ｂ 配信リスト／ストリーム負荷管理簿
１７ｃ 資源負荷管理簿
１８ プロセッサ
１８ａ 関連度算出部
１８ｂ ストリーム受信部
１８ｃ 資源負荷計測部
１８ｄ ストリーム負荷計測部
１８ｅ 分散決定部
１８ｆ 分散実行部

Claims (9)

1. 複数の情報処理手段それぞれが実行する、イベントを特定する条件式にそれぞれ基づいてストリームから検出されたイベントへの、複数の複合イベント処理に対し、前記複数の複合イベント処理間の関連度を、前記複数の複合イベント処理それぞれに対応づけられた前記条件式の実行実績に基づき算出する算出部と、
   前記複数の情報処理手段それぞれが動作するサーバにおける、前記複数の情報処理手段それぞれの前記サーバの資源の使用状況に基づき算出される処理負荷状況をそれぞれ取得する取得部と、
   前記取得部によって取得された処理負荷状況に基づいて、処理分散対象の情報処理手段を検出する検出部と、
   前記検出部によって処理分散対象の情報処理手段が検出された場合、前記算出部によって算出された前記複数の複合イベント処理間の関連度に基づいて、前記複数の情報処理手段の少なくとも１つに前記複合イベント処理を分散させる分散部と、
   を有することを特徴とする複合イベント分散装置。
2. 前記算出部は、前記複数の複合イベント処理間の関連度として、前記条件式を構成する要素の重複数に基づいて、前記条件式間の関連度を算出し、
   前記分散部は、前記算出部によって算出された前記条件式間の関連度に基づいて、前記複数の情報処理手段の少なくとも１つに前記条件式によりイベントを特定させて、前記複合イベント処理を分散させることを特徴とする請求項１に記載の複合イベント分散装置。
3. 前記算出部は、前記複数の複合イベント処理間の関連度として、要素の順番が規定される前記条件式を構成する前記要素の重複数および／または前記条件式における前記要素の順番の重複数に基づいて、前記要素間の関連度を算出し、
   前記分散部は、前記条件式各々を要素に分割し、前記算出部によって算出された前記要素間の関連度に基づいて、前記情報処理手段の少なくとも１つに前記分割した要素によりイベントを特定させて、前記複合イベント処理を分散させることを特徴とする請求項１または２に記載の複合イベント分散装置。
4. 前記分散部は、前記算出部によって算出された前記条件式間の関連度が第１の閾値以上である条件式または前記算出部によって算出された前記要素間の関連度が第２の閾値以上である要素が集約するように、前記条件式または要素を前記情報処理手段いずれか１つに移動させて、前記複合イベント処理を分散させることを特徴とする請求項２または３に記載の複合イベント分散装置。
5. 前記算出部は、前記条件式ごとに、各条件式により前記複合イベント処理を実行する各情報処理手段について前記処理負荷状況を算出し、
   前記分散部は、前記算出部によって算出された各処理負荷状況が所定値以上の条件式のうち、前記算出部によって算出された前記条件式間の関連度が第１の閾値未満である条件式各々に対応する複合イベント処理を異なる情報処理手段で実行させて、前記複合イベント処理を分散させることを特徴とする請求項１に記載の複合イベント分散装置。
6. 前記算出部は、前記条件式を構成する要素ごとに、当該要素によって特定される事象の検出処理を実行する各情報処理手段について前記処理負荷状況を算出し、
   前記分散部は、前記算出部によって算出された資源の消費状況が所定値以上の要素のうち、前記算出部によって算出された前記要素間の関連度が第２の閾値未満である要素各々に対応する複合イベント処理を異なる情報処理手段で実行させて、前記複合イベント処理を分散させることを特徴とする請求項１に記載の複合イベント分散装置。
7. 前記分散部は、前記検出部によって検出された情報処理手段の前記処理負荷状況が所定値未満となった場合には、分散させた複合イベント処理を分散前の状態に戻すことを特徴とする請求項５に記載の複合イベント分散装置。
8. コンピュータが実行する制御方法であって、
   複数の情報処理手段それぞれが実行する、イベントを特定する条件式にそれぞれ基づいてストリームから検出されたイベントへの、複数の複合イベント処理に対し、前記複数の複合イベント処理間の関連度を、前記複数の複合イベント処理それぞれに対応づけられた前記条件式の実行実績に基づき算出し、
   前記複数の情報処理手段それぞれが動作するサーバにおける、前記複数の情報処理手段それぞれの前記サーバの資源の使用状況に基づき算出される処理負荷状況をそれぞれ取得し、
   前記取得した処理負荷状況に基づいて、処理分散対象の情報処理手段を検出し、
   前記処理分散対象の情報処理手段を検出した場合、前記算出した前記複数の複合イベント処理間の関連度に基づいて、前記複数の情報処理手段の少なくとも１つに前記複合イベント処理を分散させることを特徴とする複合イベント分散方法。
9. コンピュータに、
   複数の情報処理手段それぞれが実行する、イベントを特定する条件式にそれぞれ基づいてストリームから検出されたイベントへの、複数の複合イベント処理に対し、前記複数の複合イベント処理間の関連度を、前記複数の複合イベント処理それぞれに対応づけられた前記条件式の実行実績に基づき算出し、
   前記複数の情報処理手段それぞれが動作するサーバにおける、前記複数の情報処理手段それぞれの前記サーバの資源の使用状況に基づき算出される処理負荷状況をそれぞれ取得し、
   前記取得した処理負荷状況に基づいて、処理分散対象の情報処理手段を検出し、
   前記処理分散対象の情報処理手段を検出した場合、前記算出した前記複数の複合イベント処理間の関連度に基づいて、前記複数の情報処理手段の少なくとも１つに前記複合イベント処理を分散させることを特徴とする複合イベント分散プログラム。

Images