JP5446405B2 - イベント検出制御方法及びシステム - Google Patents

Description

開示する技術は、イベント検出システムの冗長化技術に関する。

データ発生装置が発生する膨大なデータの中から、データがある条件を満たすことを、アプリケーションがリアルタイムに検知し、タイムリなサービスを実現することが望まれている。例えば、果物に貼付された温度センサが、随時温度情報を提供しており、その温度がある一定以上の状態が一定期間続くと果物が悪くなり、商品価値がなくなってしまうため、即座に保管業者に通知し、然るべき対処を促すといったサービスが考えられる。そのために、アプリケーションはイベント検出装置を利用する。

図１４は、一般的なイベント検出装置の構成例を示す図である。このようなイベント検出装置１４０１は、アプリケーション１４０２からイベント通知設定（イベント通知の条件）を受け付け、データ発生装置１４０３が発生する大量のデータから、通知条件にマッチするデータを検出すると、リアルタイムでアプリケーションにイベントとして通知する装置である。ここで、通知条件とは、データ発生装置１４０３が所定の状態になったことがアプリケーション１４０２に通知されるときにそのデータ発生装置１４０３が発生するデータが満たすべき条件をいう。

通常、サービス提供者は、サービスの可用性を向上させるために、アプリケーションを冗長構成で実行する。タイムリなサービスを実現する場合には、イベント通知が滞ってはタイムリなサービス実行ができなくなるので、イベント検出装置も冗長化し、１台のイベント検出装置に障害が発生しても、別のイベント検出装置を利用して、アプリケーションがイベントを受信できるようにすることが必要である。しかも、一方のイベント検出装置が他方のイベント検出装置のイベント検出処理を引き継ぐ際に、送信すべきイベントに漏れがないようにしなければならない。

一般的によく知られている冗長化方式は、ロードバランサを利用する方式である。図１５は、ロードバランサを用いた冗長化されたイベント検出システムの従来技術の構成図である。この構成では、ロードバランサ１５０２が、データ発生装置１５０３と２つのイベント検出装置１５０１（＃１）及び１５０１（＃２）間に配置され、イベント検出装置１５０１の生死状況をモニタする。そして通常は、＃１のイベント検出装置１５０１にデータを送信し、＃１のイベント検出装置１５０１がアプリケーション（図１５では「アプリ」と記載）１５０４に通知を行う。ここで、＃１のイベント検出装置１５０１に異常が発生した場合には、＃２のイベント検出装置１５０１にデータを送信するようにし、＃２のイベント検出装置１５０１がアプリケーション１５０４に通知を行って、イベント検出処理が継続される。

イベント検出装置１５０１は、検出・通知処理の高速化のために、内部状態持ち、受信したデータと通知条件との照合を行う場合がある。ここで内部状態とは、通知条件毎にイベント検出装置１５０１が管理するデータ発生装置１５０３からのデータの遷移状態をいう。その場合、図１５に示されるような冗長化方式は適用できない。例えば、２０℃以上の温度が２分以上持続するという条件を満たす時にイベントが通知されるような場合、過去２分間の状態を内部状態として保持している必要がある。しかし、＃１のイベント検出装置１５０１に異常が発生して＃２のイベント検出装置１５０１がイベント検出処理を引き継ごうとしても、内部状態が異なるため、そのままでは正しい通知判定を行うことができない。

検出・通知処理を引き継ぐ際に、内部状態をコピーする方法も考えられる。しかし、内部状態をコピーしている最中にも、データは継続して発生し、コピーが終了した時点でも内部状態が同じになるとは限らない。その上、イベント検出装置に異常が発生した場合に、内部状態をコピーできるとは限らない。

これを解決するために、図１６に示されるようなイベント検出システムが考えられる。データ発生装置１６０３は、２台のイベント検出装置に同じデータを送信し、２台のイベント検出装置１６０１（＃１）及び１６０１（＃２）の内部状態を常に同じに保つ。データ送信の手段としては、マルチキャストでもよいし、ユニキャストを繰り返してもよい。そして、実際にイベントをアプリケーション（図１６では「アプリ」と記載）１６０４に通知するのは、稼動状態にあるイベント検出装置１６０１のみとする。例えば、図１６（ａ）の例では、＃１のイベント検出装置１６０１が稼働状態即ち運用系である。そして、待機状態のイベント検出装置１６０１は、内部的にイベント生成処理を行い、その履歴を保持するが、アプリケーション１６０４への通知は行わない。図１６（ａ）の例では、＃２のイベント検出装置１６０１が待機状態即ち待機系である。通常は、運用系のイベント検出装置１６０１がイベント中継装置１６０２を介し、イベントをアプリケーション１６０４に通知し、イベント中継装置１６０２は、アプリケーション１６０４に通知できたイベントの履歴を残す。一方、待機系のイベント検出装置１６０１は、定期的に運用系のイベント検出装置１６０１が動作しているかを確認する。待機系のイベント検出装置１６０１は、図１６（ｂ）に示されるように、異常を検知すると、イベント中継装置１６０２に履歴を問合せ、待機系のイベント検出装置１６０１内に蓄積したイベント生成履歴と照合する。そして、待機系のイベント検出装置１６０１は、イベントとして生成されたが実際にアプリケーション１６０４に通知されていないイベントを特定し、それをアプリケーションに通知した後に、運用系に移行し、通常のイベント通知処理を開始する。そうすることで、イベント通知処理が運用系から待機系に移行する際に、運用系に異常が発生した時点に遡ってイベント通知を行い、イベントの通知漏れを防ぐことが可能である。

この時、ポイントになるのは、イベントの識別方法である。通常考えられるのは、イベント検出装置に入力されたデータの順番を識別子として利用する方法と、イベントを生成した順番を識別子として利用する方法である。しかし、イベント通知の場合は、以下のような問題がある。

入力データの順番を識別子として利用する方法の場合
１つの入力データに対して、複数のイベントが発生する場合があり、入力データの順番を利用して、イベントを識別することができない。

例えば、図１７（ａ）において、アプリケーション（図１７では「アプリ」と記載）１７０３（＃１）及び１７０３（＃２）「温度が２０℃以上が１分以上持続」という同じ通知条件で、それぞれイベント通知設定を行っていたとする。そして、イベント検出装置１７０１の内部状態として、１２：００に１７℃、１２：０１に２１℃のデータを受け取っていたとする。その後、イベント検出装置１７０１が１２：０２に２０℃のデータを受け取ると、＃１と＃２の両方のアプリケーション１７０３の通知条件が満たされるため、両方のアプリケーションに同じイベントが通知される。そのため、イベント検出装置１７０１への入力データの順番を識別するだけでは、イベントを識別することはできず、異常発生時にどちらのイベント通知が失敗したかを判定できない。

イベントを生成した順番を利用する方法
イベント通知処理をマルチスレッドで実行するため、複数のイベント検出装置において、全く同じ順番でイベント通知メッセージが生成されるとは限らない。

例えば、図１７（ｂ）において、＃３のアプリケーション１７０６は「温度が２０℃以上が１分以上持続」という通知条件で、イベント通知設定を行っていたとする。イベント検出装置１７０４（＃１）及び１７０４（＃２）、データ発生装置１７０５から同じデータを受け取っており、内部状態は、センサ＃１に関しては、１２：００に１７℃、１２：０１に２１℃、センサ＃２に関しては、１２：００に１８℃、１２：０１に２０℃であるとする。そこに、１２：０２の情報として、センサ＃１は２０℃、センサ＃２は２１℃というデータが、ほぼ同時刻でイベント検出装置１７０４に送信されると、両方のイベント検出装置１７０４において、センサ＃１とセンサ＃２に関する温度異常イベントが生成される。その際、センサ＃１とセンサ＃２のデータは並列に処理されるので、どちらが先にイベント生成が完了するかは、イベント検出装置１７０４の状態によって変わり得る。そのため、イベントの生成した順番でも、イベントを識別することはできない。

イベントの識別に関連して、２重化ボリュームと複製ボリュームを備えるストレージシステムにおいて、正系マスタボリュームが障害により、複製処理を中断した場合に、副系マスタボリュームが速やかに複製処理を継続できる従来技術が知られている。この従来技術は、正副マスタボリュームが独立しているために副系にて正系がどこまで複製を行ったかがわからず正系が中断したデータ複製を引き継げない、という問題を解決する。そのために、サーバは、正系と副系それぞれに、同じ書込みデータを送る。正系と副系とも、サーバからの書込み要求に番号を付け、自身の論理ディスクの中身を更新し、更新履歴を保持する。そして、正系のみ、複製ボリュームに複製処理を実施し、複製ボリュームに何番まで完了したかを記憶させる。正系に障害が発生し、副系が処理を引き継ぐ際には、複製ボリュームに、何番目まで処理を行ったかを問合せ、最後の番号の直後から複製処理を開始する。この方式は、同じデータを両方のマスタボリュームに送るので、内部状態を同一に保つことが可能で、処理の引継ぎ時に、複製ボリュームの履歴とマスタボリュームの履歴を照合することで、未処理の複製処理を実施することが可能である。

この従来技術は、ストレージへの書込み要求を入力、複製ボリュームへの書込み要求を出力としており、両者は１対１に対応し、出力の順番は必ず入力の順番通りであることが想定される。このため、書込み要求受信時の採番により、複製ボリュームへの書込み要求を識別することが可能である。

しかし、前述したイベント通知の場合には、データ発生装置からのデータとアプリケーションへのデータは必ずしも１対１には対応していないため、上述の従来技術を適用することはできない。

本出願が開示する技術に関連する従来技術として、下記先行技術文献が開示されている。

特開２００６-２８５３３６号公報 特開２００１−０４５０２１号公報

開示する技術が解決しようとする課題は、イベント検出装置が異なっていても生成されるイベントを一意に識別可能とし、それにより複数のイベント検出装置間でイベント通知の漏れなくイベント通知処理を引き継ぐことを可能にすることにある。

上記課題を解決するために、開示する技術は、データ発生装置からの発生データを、アプリケーションから予め設定される通知条件と通知内容を含むイベント通知設定情報と比較し、その発生データが通知条件を満たした場合に通知内容を表示するイベントメッセージをアプリケーションに通知する処理を、運用系と待機系からなる複数台のイベント検出装置による冗長構成で実行するイベント検出制御方法又はシステムとして実現され、例えば方法として実現される場合には以下の構成を有する。

データ識別子割り当てステップは、データ発生装置にて、発生データに、その発生データの発生順を識別するためのデータ識別子を割り当てる。
イベントメッセージ作成制御ステップは、イベント通知設定情報と発生データとの組合せによって定まる内部状態毎に、発生データがその内部状態に対応するイベント通知設定情報の通知条件を満たすか否かを判定し、満たす場合に、その内部状態とその発生データのデータ識別子とから一意に決定したイベント識別子を含むイベントメッセージを作成し、その作成履歴を保持する動作を、各イベント検出装置で冗長に実行する。

イベントメッセージ送信制御ステップは、運用系のイベント検出装置から、イベントメッセージをアプリケーションに送信すると共に、その送信履歴をその運用系のイベント検出装置とは別の装置にて保持する。

異常時制御ステップは、待機系のイベント検出装置が運用系のイベント検出装置の異常を検知した場合に、その待機系のイベント検出装置が保持する前述の作成履歴中のイベントメッセージのイベント識別子及びタイムスタンプと、前述の送信履歴中のイベントメッセージのイベント識別子及びタイムスタンプとを比較することにより、運用系のイベント検出装置が送信できなかったイベントメッセージをその待機系のイベント検出装置から送信した上で、その待機系のイベント検出装置を運用系に移行させる。

開示する技術によれば、イベント検出装置の冗長化を行う際に、イベント検出装置が異なっていても生成されるイベントがイベント識別子によって一意に識別可能となる。これにより、複数のイベント検出装置間でイベント通知の漏れなくイベント通知処理を運用系から待機系へ引き継ぐことが可能となる。その結果、イベント検出の信頼性が向上する。

イベント検出システムの第１の実施形態の構成図である。 第１の実施形態におけるイベント検出動作の説明図である。 イベント検出システムの第２の実施形態の構成図である。 イベント通知設定処理を示す動作シーケンス図である。 イベント検出・通知処理を示す動作シーケンス図である。 異常検知・運用系への移行処理を示す動作シーケンス図である。 復帰処理を示す動作シーケンス図である。 イベント通知履歴情報管理テーブルのデータ構成例を示す図である。 イベント通知設定情報管理テーブルのデータ構成例を示す図である。 内部状態管理テーブルの例である。 イベント生成履歴情報管理テーブルの例である。 ３台以上のイベント検出装置の冗長化構成の例を示す図である。 イベント検出システムの第３の実施形態の構成図である。 一般的なイベント検出装置の構成例を示す図である。 ロードバランサを用いた従来のイベント検出システムの構成図である。 他の従来のイベント検出システムの構成図である。 イベント通知におけるイベント識別の問題点の説明図である。

以下、実施形態について詳細に説明する。
図１は、イベント検出システムの第１の実施形態の構成図である。
図１のデータ発生装置１０４において、データ生成部１０４−１は、イベント検出装置１０１に送信するデータを生成する。

データ識別子割り当て部１０４−２は、データ生成部１０４−１で生成されたデータを一意に識別可能な識別子を作成し、データに埋め込む。
データ送信部１０４−３は、２台のイベント検出装置１０１（＃１）及び１０１（＃２）識別子付きのデータを送信する。

図１のイベント検出装置１０１において、データ受信部１０１−１は、データ発生装置１０４が送信するデータを受信し、データの識別子を取得する。
イベント通知判定部１０１−２は、イベント通知判定のための内部状態を管理し、データの中身とアプリケーションが設定したイベント通知条件との照合を行う。

イベント生成部１０１−３は、内部状態の識別子と、イベントを発生させたデータの識別子から、イベントの識別子を作成し、そのイベントの識別子を埋め込んだイベントメッセージを作成する。

イベント生成履歴管理部１０１−４は、イベント生成部１０１−３が作成したイベントの履歴を管理する。
イベント送信部１０１−５は、イベント生成部１０１−３が生成したイベントメッセージをイベント中継装置１０２経由で、アプリケーション（図１では「アプリ」と記載）１０３に送信する。

イベント検出制御部１０１−６は、イベント検出装置１０１の動作モード（運用系或いは待機系）を管理したり、待機系動作時には、運用系の異常検知の際にイベント通知履歴の照合を行い、通知し損なったイベントの通知を指示したりする。
状態問合せ部１０１−７は、イベント検出装置１０１が待機系として動作している場合に、運用系の生死状態を確認する。

図１のイベント中継装置１０２において、イベント中継部１０２−１は、イベント検出装置１０１からのイベント通知を受け付け、イベントメッセージから識別子を抽出し、アプリケーション１０３にイベントメッセージを中継する。イベント通知履歴管理部１０２−２は、イベント中継装置１０２が中継したイベントの履歴を、識別子と共に保存する。

上述の第１の実施形態の構成において、運用系と待機系とで、イベント検出装置１０１の構成要素の配置と構成要素間の関係は異なるが、動作の説明上、便宜的に変えてあるだけで、実際の構成要素は同一である。

上述の第１の実施形態の構成において、データ識別子割り当て部１０４−２による動作は、特許請求の範囲のデータ識別子割り当てステップ又はデータ識別子割り当て部の一実施例に対応する。また、イベント通知判定部１０１−２、イベント生成部１０１−３、及びイベント生成履歴管理部１０１−４による動作は、特許請求の範囲のイベントメッセージ作成制御ステップ又はイベントメッセージ作成制御部の一実施例に対応する。また、イベント送信部１０１−５、イベント中継部１０２−１、及びイベント通知履歴管理部１０２−２の動作は、特許請求の範囲のイベントメッセージ送信制御ステップ又はイベントメッセージ送信制御部の一実施例に対応する。また、イベント検出制御部１０１−６及び状態問合せ部１０１−７による動作は、特許請求の範囲の異常時制御ステップ又は異常時制御部、及び復帰ステップ又は復帰部の一実施例に対応する。

上述の構成を有する第１の実施形態の通常の動作は以下の通りである。
データ発生装置１０４は、データ生成部１０４−１が、随時送信用データを生成し、データ識別子割り当て部１０４−２に渡す。データ識別子割り当て部１０４−２は、識別子を作成し、それを送信用データに付与し、データ送信部１０４−３を通じて、運用系である＃１のイベント検出装置１０１及び待機系である＃２のイベント検出装置１０１に送信する。

運用系と待機系の両イベント検出装置１０１（＃１）及び１０１（＃２）は、データ受信部１０１−１が、データ発生装置１０４からのデータを受信し、データの識別子を抽出し、受け取ったデータをイベント通知判定部１０１−２に渡す。

イベント通知判定部１０１−２は、受信したデータに応じて、内部状態を更新し、アプリケーションが指定した通知条件とを照合する。そして、イベント通知判定部１０１−２は、照合に成功した場合は、イベント生成部１０１−３に対して、イベントを生成しアプリケーションに通知するように指示する。

イベント生成部１０１−３は、内部状態と受信データそれぞれの識別子から、イベントの識別子を作成し、識別子込みのイベントメッセージを作成し、識別子とイベントメッセージを含む履歴を、イベント生成履歴管理部１０１−４に登録する。

ここで、図２に示されるように、このイベントメッセージの識別子は、イベント通知判定に利用する内部状態の識別子と、イベント生成の契機になったデータの識別子の組で表す。内部状態は、アプリケーション１０３からのイベント通知設定と、イベントの主体となるもの（例えばセンサ）に付けられた識別子の組ごとに生成される。それは、イベント通知条件とイベントの主体の組ごとに、データの発生状況と通知判定処理が異なるので、それぞれで状態遷移が異なるためである。各イベントメッセージは、内部状態から生成されるので、異なる内部状態から生成されるイベントは、内部状態の識別子で区別することが可能である。そして、１つの内部状態から生成されるイベントは、イベントの契機になったデータの識別子により、生成される順番によらず区別可能である。従って、内部状態の識別子とイベントの生成契機になったデータの識別子の組合せにより、イベントは完全に識別可能である。

その後、イベント生成部１０１−３は、生成したイベントをイベント中継装置１０２経由でアプリケーション１０３に送信するように、イベント送信部１０１−５に指示する。
イベント検出制御部１０１−６は、自装置が運用系として動作しているか待機系として動作しているかを管理する。イベントの送信指示を受けたイベント送信部１０１−５は、イベントを送信する前に、イベント検出制御部１０１−６に動作モードを問い合わせる。その問合せの結果が運用系である場合は、実際にイベント中継装置１０２を介してアプリケーション１０３にイベントを通知し、待機系である場合は、イベントを通知せずに処理を終える。

運用系のイベント検出装置１０１からイベントを受信したイベント中継装置１０２では、イベント中継部１０２−１が、イベントの識別子を取得し、イベント通知履歴管理部１０２−２に識別子を履歴として登録する。

一方、待機系（図１の例では＃２）のイベント検出装置１０１は、状態問合せ部１０１−７が、定期的に運用系（図１の例では＃１）のイベント検出装置１０１の生死状態を確認する。そして、待機系のイベント検出装置１０１の状態問合せ部１０１−７は、もし運用系のイベント検出装置１０１が正常に動作していない場合には、イベント検出制御部１０１−６に運用系の異常を通知する。

それを受けて待機系のイベント検出制御部１０１−６は、イベント中継装置１０２のイベント通知履歴管理部１０２−２からイベント通知履歴を取得し、その履歴と自装置のイベント生成履歴管理部１０１−４が管理しているイベント通知履歴とを照合する。この時、イベント検出制御部１０１−６は、イベントメッセージの識別子で両者の同一性を判断し、自装置内のイベント通知履歴によると通知したことになっているがイベント中継装置１０２の履歴にはないイベント通知を洗い出す。

そして、イベント検出制御部１０１−６は、洗い出したイベント通知を順に、イベント送信部１０１−５を介してイベント中継装置１０２に送信する。その後、イベント検出制御部１０１−６は、動作モードを運用系に変更し、自装置を運用系として動作させる。

前述したように、第１の実施形態では、データ識別子割り当て部１０４−２が、データ発生装置１０４が送信するデータに識別子を含ませる。そして、イベント検出装置１０１内のイベント生成部１０１−３が、イベント生成時にそのデータの識別子を利用して、完全にイベントを区別できる識別子を作成することが可能である。

そして、イベント検出装置１０１内では、イベント生成履歴管理部１０１−４にてイベント生成の履歴が作成され、イベント中継装置１０２では、イベント通知履歴管理部１０２−２にて実際にアプリケーションに通知できたイベントの履歴が記録される。そして、待機系による運用系の異常検知時には、上記両者の履歴が比較されることで、実際に運用系に異常が発生した時点に遡って運用系が通知し損なったイベントを送信する。

このため、第１の実施形態では、イベント通知の漏れが発生せず、イベント通知の可用性・信頼性を向上させることが可能となる。
図３は、イベント検出システムの第２の実施形態の構成図である。図３において、第１の実施形態における図１に示される処理部と同じ部分には、同じ番号が付されている。

図３の構成では、図１の構成に加えて、イベント中継装置１０２内にイベント通知設定中継部１０２−３が備えられる。また、＃１及び＃２の各イベント検出装置１０１内に、イベント通知設定受付部１０１−８及びタイマ１０１−９が備えられる。

図３に示される構成を有する第２の実施形態の通常の動作は、以下の４つの処理からなる。

（１）アプリケーションによるイベント通知設定処理
（２）運用系及び待機系のイベント検出装置１０１によるイベント検出・通知処理
（３）待機系のイベント検出装置１０１による異常検知・運用系への移行処理
（４）異常が発生したイベント検出装置１０１の復帰処理

（１）アプリケーションによるイベント通知設定処理
アプリケーション１０３によるイベント通知設定処理の動作について、図４の動作シーケンス図に基づいて説明する。
イベント中継装置１０２のイベント通知設定中継部１０２−３が、アプリケーション１０３からのイベント通知設定要求を受け取る（ステップＳ４０１）。イベント通知設定中継部１０２−３は、イベント通知履歴管理部１０２−２を参照して（ステップＳ４０２）、現在運用系として動作しているイベント検出装置１０１を判定し（ステップＳ４０３）、そちらにイベント通知設定要求を送信する（ステップＳ４０４）。イベント通知履歴管理部１０２−２は、図８に示されるようなイベント通知履歴情報管理テーブルを管理している。即ち、このテーブルの各エントリは、イベントメッセージを中継した日時であるタイムスタンプ、イベントを通知したイベント検出装置１０１の識別子である送信元識別子、送信されたイベントメッセージの識別子であるイベント識別子の情報組から構成される。イベント通知設定中継部１０２−３は、イベント通知履歴管理部１０２−２内の上記テーブルの各エントリのタイムスタンプと送信元識別子を参照することで、＃１と＃２のイベント検出装置１０１のうち最近イベント通知が行われたほうを現在の運用系と判断する。そして、イベント通知設定中継部１０２−３は、運用系と判断したイベント検出装置１０１に対して、イベント通知設定要求を送信する。

運用系のイベント検出装置１０１のイベント通知設定受付部１０１−８は、受け取ったイベント通知設定要求をイベント通知判定部１０１−２に通知する（ステップＳ４０４）。

イベント通知判定部１０１−２は、イベント通知設定要求の内容を確認し、識別子である通知設定ＩＤを生成した上で（ステップＳ４０５）、イベント通知設定情報管理テーブルのエントリ、即ちイベント通知設定情報を生成する（ステップＳ４０６）。図９は、イベント通知判定部１０１−２が保有するイベント通知設定情報管理テーブルのデータ構成例を示す図である。図９に示されるように、このテーブルの各エントリは、通知設定ＩＤと、通知条件と、通知先アプリケーション（通知先アプリ）と、通知内容とからなるイベント通知設定情報を保持する。通知条件は、どのようなデータが発生した場合に通知が行われるかという条件を示す情報である。また、通知内容は、通知先のアプリケーション１０３に対して表示される警報値である。

また、イベント通知判定部１０１−２は、上述のイベント通知設定情報管理テーブルのエントリと共に、イベント検出のための内部状態管理テーブルのエントリも生成する（ステップＳ４０７）。図１０は、イベント通知判定部１０１−２が管理する内部状態を保持するための内部状態管理テーブルのデータ構成例を示す図である。このテーブルの各エントリ即ち内部状態は、イベント通知設定（上述の通知設定ＩＤ）とイベントを発生させる主体（イベント主体）との組合せ毎に１組ずつ生成される。通知設定ＩＤとイベント主体との組合せが内部状態識別子となる。また各エントリは、データ発生状態を保持する。このデータ発生状態は、現在どのようなデータが発生しているかを示す内部状態である。このデータ発生状態は、通知設定ＩＤに対応するイベント通知設定情報管理テーブルのエントリの通知条件が満たされ、そのエントリに設定されている通知先のアプリケーション１０３にこの内部状態が通知された時点で、その内部状態はリセットされる。

運用系のイベント通知判定部１０１−２は、ステップＳ４０６にて生成したイベント通知設定情報を、待機系のイベント通知判定部１０１−２に通知する（ステップＳ４０８）。この結果、待機系側でも同様の処理が行われて（ステップＳ４０９）、イベント通知設定情報管理テーブルにイベント通知設定情報が設定されると共に、内部状態管理テーブルに内部状態が設定され、イベント検出・通知を行うための準備がなされる。

その後、運用系のイベント通知判定部１０１−２は、自装置でのイベント検出・通知処理を開始すると共に、待機系のイベント通知判定部１０１−２にも開始命令を送ってイベント検出・通知処理を開始させる（ステップＳ４１０）。

最後に、運用系のイベント通知判定部１０１−２は、イベント通知設定受付部１０１−８及びイベント中継装置１０２のイベント通知設定中継部１０２−３を経由して、アプリケーション１０３に通知設定ＩＤを返信する（ステップＳ４１１、Ｓ４１２）。

以上のイベント通知設定処理により、各イベント検出装置１０１において、アプリケーション１０３から設定されたイベント検出・通知処理の準備が整う。

２）運用系及び待機系のイベント検出装置１０１によるイベント検出・通知処理
運用系及び待機系のイベント検出装置１０１によるイベント検出・通知処理の動作について、図５の動作シーケンス図に基づいて説明する。
データ発生装置１０４のデータ生成部１０４−１が、送信データ（発生データ）を作成し、データ識別子割り当て部１０４−２に渡す（ステップＳ５０１）。
データ識別子割り当て部１０４−２は、データ発生装置１０４のホスト名や時刻を組み合わせてデータ識別子を作成し、それを発生データに埋め込み、データ送信部１０４−３に渡す（ステップＳ５０２）。

データ送信部１０４−３は、その発生データを＃１及び＃２の２台のイベント検出装置１０１に送信する（ステップＳ５０３）。送信方法は、ユニキャストを繰り返しても良いし、既存のマルチキャスト網を利用しても構わない。

運用系・待機系の両イベント検出装置１０１のデータ受信部１０１−１は、発生データを受け付け、その発生データに埋め込まれているデータ識別子を取り出し、イベント通知判定部１０１−２に渡す（ステップＳ５０４）。

イベント通知判定部１０１−２は、発生データに関係する内部状態をそれぞれ更新し、イベント通知設定情報の通知条件と照合する（ステップＳ５０５）。より具体的には、イベント通知判定部１０１−２は、図１０に例示される内部状態管理テーブルにおいて、ステップＳ５０４で認識された通知元のデータ発生装置１０４に対応する「イベント主体」項目を検索する。そして、イベント通知判定部１０１−２は、該当する１つ又は複数のエントリの「データ発生状態」項目に、データ受信部１０１−１から通知された発生データ（データ識別子を含む）を追加する。続いて、イベント通知判定部１０１−２は、上記エントリの「通知設定ＩＤ」項目の値で図９に例示されるイベント通知設定情報管理テーブルを検索し、該当するエントリの「通知条件」と上記発生データとを照合する。この照合の結果、通知条件が満たされるイベント通知設定情報が存在する場合、イベント通知判定部１０１−２は、その照合情報をイベント生成部１０１−３に渡す。この照合情報には、通知設定ＩＤと、イベント主体と、通知先アプリケーションと、通知内容と、発生データ（データ識別子を含む）とが含まれる。通知設定ＩＤ及びイベント主体は、上記発生データが追加された図１０に例示される内部状態管理テーブルのエントリから取得できる。通知先アプリケーション（通知先アプリ）及び通知内容は、上記照合でヒットしたイベント通知設定情報管理テーブルのエントリから取得できる。発生データ（データ識別子を含む）は、データ受信部１０１−１から通知されたものである。

イベント生成部１０１−３は、通知設定ＩＤ＋イベント主体とからなる内部状態識別子と、発生データ内のデータ識別子とから、イベント識別子を生成する。そして、イベント生成部１０１−３は、そのイベント識別子と、通知内容、及び発生データとからなるイベントメッセージを作成する（ステップＳ５０６）。

イベント生成部１０１−３は、上述のイベントメッセージを、イベント生成履歴管理部１０１−４に送る（ステップＳ５０７）。イベント生成履歴管理部１０１−４は、上記イベントメッセージを、図１１に示されるデータ構成例を有するイベント生成履歴情報管理テーブルに追加する。このテーブルのエントリは、タイムスタンプ、イベント識別子、通知先アプリケーション（通知先アプリ）、及び通知内容からなる情報組である。タイムスタンプは登録時点の日時である。イベント識別子は、上記イベントメッセージに含まれる情報である。通知先アプリケーションは、イベント通知判定部１０１−２からイベント生成部１０１−３へ渡された情報である。通知内容は、上記イベントメッセージに含まれる情報である。

続いて、イベント生成部１０１−３は、上述のイベントメッセージを、イベント通知判定部１０１−２から渡された通知先アプリケーションに通知するように、イベント送信部１０１−５に指示する。イベント送信部１０１−５は、イベント検出制御部１０１−６に、自身の動作モード（運用系又は待機系）を問い合わせる。もし、動作モードが待機系である場合は、イベント送信部１０１−５は、そのまま処理を終了する。動作モードが運用系の場合は、イベント送信部１０１−５は、イベント中継装置１０２のイベント中継部１０２−１に、イベントを通知するように命令する（ステップＳ５０８）。

イベント中継部１０２−１は、受信したイベントメッセージから、イベント識別子を取り出す（ステップＳ５０９）。そして、イベント中継部１０２−１は、受信したイベントメッセージを、通知先のアプリケーション１０３に通知する（ステップＳ５１０）。そして、イベント中継部１０２−１は、タイムスタンプ、送信元識別子、及びイベント識別子を、イベント通知履歴管理部１０２−２内の図８に例示したイベント通知履歴情報管理テーブルに、履歴として登録させる（ステップＳ５１１）。タイムスタンプは、登録時の日時である。送信元識別子は、イベントメッセージを送信したイベント検出装置１０１の識別子である。

（３）待機系のイベント検出装置１０１による異常検知・運用系への移行処理
待機系のイベント検出装置１０１による異常検知・運用系への移行処理の動作につき、図６の動作シーケンス図に基づいて説明する。

待機系のイベント検出装置１０１のタイマ１０１−９が、一定時間おきに、状態問合せ部１０１−７に対して運用系のイベント検出装置１０１の稼動状態を問い合わせるように指示する（ステップＳ６０１）。

状態問合せ部１０１−７は、前回の問合せ時刻を記憶しておき、運用系の異常を検知すると（運用系が応答しない、あるいはＮＧを応答する）、イベント検出制御部１０１−６に対して、前回の問合せ時刻を付けて、引継ぎ処理を実行するように命令する。イベント検出制御部１０１−６は、イベント中継装置１０２のイベント通知履歴管理部１０２−２内のイベント通知履歴情報管理テーブル（図８参照）から、前回の問合せ時刻以降のタイムスタンプを有するイベント通知履歴を取得する（ステップＳ６０２）。

イベント検出制御部１０１−６は、イベント中継装置１０２から取得したイベント通知履歴を、自装置のイベント生成履歴管理部１０１−４内のイベント生成履歴情報管理テーブルに登録されているイベント生成履歴と照合する（ステップＳ６０３）。そして、イベント検出制御部１０１−６は、前回の問合せ時刻以降で、イベント生成履歴には存在するがイベント通知履歴には存在しない、イベント通知情報を取得する。そして、イベント検出制御部１０１−６は、取得した各イベント通知情報に対応するイベントメッセージを通知するよう、イベント送信部１０１−５に指示する。この結果、前述したステップＳ５０８からＳ５１１までの一連の処理と同様にして、待機系のイベント検出装置１０１からのイベント通知が実行される（ステップＳ６０４からＳ６０７）。
その後、待機系のイベント検出装置１０１のイベント検出制御部１０１−６は、動作モードを運用系に変更し、自装置を運用系として動作させる。

（４）異常が発生したイベント検出装置１０１の復帰処理
最後に、異常が発生したイベント検出装置の復帰処理の動作につき、図７の動作シーケンス図に基づいて説明する。

異常が発生したイベント検出装置１０１が再起動されると、イベント検出制御部１０１−６がイベント通知判定部１０１−２に対して、復帰時の初期化処理を行うように指示する。イベント通知判定部１０１−２は、運用系のイベント検出装置１０１のイベント通知判定部１０１−２から、イベント通知設定情報と内部状態を取得し、その状態を内部に復元する（ステップＳ７０１、Ｓ７０２）。

その間も、データ発生装置１０４から発生データが送信されて来るので、イベント通知判定部１０１−２が、その発生データをバッファリングしておく。そして、イベント通知判定部１０１−２は、イベント通知設定情報と内部状態が復元された後に、それらの発生データを順次処理させる（ステップＳ７０３）。
その後は、待機系のイベント検出装置１０１として、動作を継続する（ステップＳ７０４）。

以上の第２の実施形態の説明は、＃１及び＃２の２台のイベント検出装置１０１を想定したが、３台以上であっても同様の動作が可能である。

その場合、例えば図１２に示されるように、イベント検出管理装置１２０２が、各イベント検出装置１２０１（図１２では＃１〜＃３の３台）の状態を、イベント検出装置状態管理テーブルを用いて管理する。このテーブルの各エントリは、イベント検出装置ＩＤ、エンドポイント、状態（運用系又は待機系）、及びタイムスタンプである。

運用系のイベント検出装置１２０１は、一定時間おきにイベント検出管理装置１２０２にアクセスして、イベント検出装置状態管理テーブルの自装置に対応するエントリの「タイムスタンプ」項目を更新する。待機系のイベント検出装置１２０１は、定期的にイベント検出管理装置１２０２にアクセスして、「状態」項目が「運用系」となっているエントリのタイムスタンプが更新されていることを確認する。

更新が滞っていることを検知した待機系のイベント検出装置１２０１は、運用系のイベント検出装置１２０１に異常が発生したと判断し、前述した運用系への移行処理を実行する。そして、イベント検出管理装置１２０２にアクセスして、イベント検出装置状態管理テーブルの、異常が発生したイベント検出装置１２０１の「状態」項目を「待機系」に、自装置の「状態」項目を「運用系」に変更する。これ以後、運用系となったイベント検出装置１２０１は、定期的に上記タイムスタンプを更新する。

全ての待機系のイベント検出装置１２０１は、運用系のイベント検出装置１２０１の状態を知ることができる。
また、運用系のイベント検出装置１２０１は、アプリケーションからイベント通知設定要求を受けた場合には、このイベント検出装置状態管理テーブルを参照して他の待機系のイベント検出装置１２０１のエンドポイントを取得する。そして、運用系のイベント検出装置１２０１は、各待機計のイベント検出装置１２０１に、イベント通知設定情報を送信する。

異常が発生したイベント検出装置１２０１が復帰する場合も、このイベント検出装置状態管理テーブルを参照して、運用系のイベント検出装置１２０１のエンドポイントを取得し、イベント通知設定情報と内部状態を取得することが可能である。

上述した第１又は第２の実施形態において、運用系のイベント検出装置１０１は全てのイベントメッセージの送信を行い、待機系のイベント検出装置１０１は一切のイベントメッセージの送信を行わないように制御される。

しかし、アプリケーション１０３からのイベント通知設定が増えるに従って、イベントメッセージを送信する負荷も大きくなる。このため、イベントメッセージの送信処理を運用系と待機系とで分担することで、それぞれの送信負荷を軽減させることが可能である。なお、前述したように、イベントの検出処理自体は、内部状態を同一に保つために、運用系・待機系共に同様に実行される。

図１３は、上述の機能を実現するためのイベント検出システムの第３の実施形態の構成図である。図１３において、図１又は図３に示される処理部と同じ部分には、同じ番号が付されている。

図１３の構成では、図１又は図３の構成に加えて、イベント検出装置１０１内にイベント送信頻度集計部１０１−１０が備えられ、ここでの集計結果に基づいて、各イベント検出装置１０１内のイベント検出制御部１０１−６が連携して動作する。

イベント送信頻度集計部１０１−１０は、イベント送信部１０１−５が実際に実行したイベント送信の頻度を、イベント通知設定毎に集計する機能を持つ。そして、イベント送信頻度集計部１０１−１０は、トータルの送信頻度が所定の閾値を超えると、そのことをイベント検出制御部１０１−６に通知する。

イベント検出制御部１０１−６は、どのイベント通知を行うかを管理しており、送信頻度の増加を通知されると、他方のイベント検出装置１０１のイベント検出制御部１０１−６に、一部のイベント送信を分担するように依頼する。それを受けた他方のイベント検出装置１０１のイベント検出制御部１０１−６は、自装置内のイベント送信頻度集計部１０１−１０から自身のイベント送信頻度の状況を取得し、受け持つイベント通知を決定し、引き受ける旨を依頼元のイベント検出制御部１０１−６に回答する。

イベント送信部１０１−５がイベントメッセージを送信する際には、第１又は第２の実施形態では、イベント検出制御部１０１−６に対して自装置が運用系か待機系かを問い合わせていた。これに対して、第３の実施形態では、イベント送信部１０１−５がイベント検出制御部１０１−６にイベント通知設定ＩＤを示して、現在のイベントメッセージを送信すべきか否を問い合わせる。

一方のイベント検出装置１０１に異常が発生し、他方のイベント検出装置１０１が一方のイベント検出・通知処理を引き継ぐ場合の処理は、第１又は第２の実施形態の場合と同様である。

開示する技術は、インターネットなどのネットワークを介して接続されるデータ発生装置から様々なセンサデータをイベントとして収集して、遠隔監視するシステムに利用することができる。

１０１ イベント検出装置
１０１−１ データ受信部
１０１−２ イベント通知判定部
１０１−３ イベント生成部
１０１−４ イベント生成履歴管理部
１０１−５ イベント送信部
１０１−６ イベント検出制御部
１０１−７ 状態問合せ部
１０１−８ イベント通知設定受付部
１０１−９ タイマ
１０１−１０ イベント送信頻度集計部
１０２ イベント中継装置
１０２−１ イベント中継部
１０２−２ イベント通知履歴管理部
１０２−３ イベント通知設定中継部
１０３ アプリケーション（アプリ）
１０４ データ発生装置
１０４−１ データ生成部
１０４−２ データ識別子割り当て部
１０４−３ データ送信部

Claims (6)

1. データ発生装置からの発生データを、アプリケーションから予め設定され通知条件と通知内容を含むイベント通知設定情報と比較し、該発生データが前記通知条件を満たした場合に前記通知内容を表示するイベントメッセージを前記アプリケーションに通知する処理を、運用系と待機系からなる複数台のイベント検出装置による冗長構成で実行するイベント検出制御方法において、
   前記データ発生装置にて、前記発生データに、該発生データの発生順を識別するためのデータ識別子を割り当てるデータ識別子割り当てステップと、
   前記イベント通知設定情報と前記発生データとの組合せによって定まる内部状態毎に、前記発生データが該内部状態に対応するイベント通知設定情報の通知条件を満たすか否かを判定し、満たす場合に、該内部状態と該発生データのデータ識別子とから一意に決定したイベント識別子を含むイベントメッセージを作成し、該作成履歴を保持する動作を、前記各イベント検出装置で冗長に実行するイベントメッセージ作成制御ステップと、
   運用系のイベント検出装置から、前記イベントメッセージをイベント中継装置を介して前記アプリケーションに送信すると共に、該送信履歴を前記イベント中継装置にて保持するイベントメッセージ送信制御ステップと、
   待機系のイベント検出装置が前記運用系のイベント検出装置の異常を検知した場合に、該待機系のイベント検出装置が保持する前記作成履歴中のイベントメッセージのイベント識別子及びタイムスタンプと、前記送信履歴中のイベントメッセージのイベント識別子及びタイムスタンプとを比較することにより、前記運用系のイベント検出装置が送信できなかったイベントメッセージを該待機系のイベント検出装置から送信した上で、該待機系のイベント検出装置を運用系に移行させる異常時制御ステップと、
   を含むことを特徴とするイベント検出制御方法。
2. 新たに運用系になった前記イベント検出装置は、前記異常が検出されたイベント検出装置の再起動時に、前記新たに運用系になった前記イベント検出装置の内部状態を該再起動したイベント検出装置にコピーし、該再起動したイベント検出装置を待機系として動作開始させる復帰ステップを更に含む、
   ことを特徴とする請求項１に記載のイベント検出制御方法。
3. 複数の前記イベント検出装置のいずれか１つが前記運用系のイベント検出装置として協調して動作する、
   ことを特徴とする請求項１又は２の何れか１項に記載のイベント検出制御方法。
4. データ発生装置からの発生データを、アプリケーションから予め設定され通知条件と通知内容を含むイベント通知設定情報と比較し、該発生データが前記通知条件を満たした場合に前記通知内容を表示するイベントメッセージを前記アプリケーションに通知する処理を、運用系と待機系からなる複数台のイベント検出装置による冗長構成で実行するイベント検出制御システムにおいて、
   前記データ発生装置内に具備され、前記発生データに、該発生データの発生順を識別するためのデータ識別子を割り当てるデータ識別子割り当て部と、
   前記各イベント検出装置内に具備され、前記イベント通知設定情報と前記発生データとの組合せによって定まる内部状態毎に、前記発生データが該内部状態に対応するイベント通知設定情報の通知条件を満たすか否かを判定し、満たす場合に、該内部状態と該発生データのデータ識別子とから一意に決定したイベント識別子を含むイベントメッセージを作成し、該作成履歴を保持する動作を、前記各イベント検出装置で冗長に実行するイベントメッセージ作成制御部と、
   運用系のイベント検出装置から、前記イベントメッセージをイベント中継装置を介して前記アプリケーションに送信すると共に、該送信履歴を前記イベント中継装置にて保持するイベントメッセージ送信制御部と、
   待機系のイベント検出装置が前記運用系のイベント検出装置の異常を検知した場合に、該待機系のイベント検出装置が保持する前記作成履歴中のイベントメッセージのイベント識別子及びタイムスタンプと、前記送信履歴中のイベントメッセージのイベント識別子及びタイムスタンプとを比較することにより、前記運用系のイベント検出装置が送信できなかったイベントメッセージを該待機系のイベント検出装置から送信した上で、該待機系のイベント検出装置を運用系に移行させる異常時制御部と、
   を含むことを特徴とするイベント検出制御システム。
5. 新たに運用系になった前記イベント検出装置の復帰部は、前記異常が検出されたイベント検出装置の再起動時に、前記新たに運用系になった前記イベント検出装置の内部状態を該再起動したイベント検出装置にコピーし、該再起動したイベント検出装置を待機系として動作開始させる、
   ことを特徴とする請求項４に記載のイベント検出制御システム。
6. 複数の前記イベント検出装置のいずれか１つが前記運用系のイベント検出装置として協調して動作する、
   ことを特徴とする請求項４又は５の何れか１項に記載のイベント検出制御システム。