イベント処理とは、発生した事象(イベント)に関する情報(データ)の流れを追跡および分析(処理)し、そこから結論を導き出す方法です[ 1 ] 。複雑イベント処理(CEP)は、1990年代初頭に開発された、リアルタイムのイベントを処理し、イベントの流れから到着時に情報を抽出する一連の概念と技術で構成されています。複雑イベント処理の目標は、リアルタイムの状況で意味のあるイベント(機会や脅威など)[ 2 ]を特定し、可能な限り迅速に対応することです。
これらのイベントは、営業リード、注文、顧客サービスコールなど、組織のさまざまな階層で発生する可能性があります。また、ニュース記事[ 3 ] 、テキストメッセージ、ソーシャルメディアの投稿、ビジネスプロセス(サプライチェーンなど)、交通レポート、天気予報、その他の種類のデータである場合もあります[ 1 ] 。イベントは、測定値が時間、温度、またはその他の値の事前定義されたしきい値を超えたときの「状態の変化」として定義することもできます。
アナリストは、CEP によって組織がリアルタイムでパターンを分析する新しい方法が得られ、ビジネス側が IT 部門やサービス部門とより良くコミュニケーションできるようになると示唆しています。[ 4 ] CEP はその後、イベントのストリームが流入するのに応じて即座に対応するために使用される多くのシステムで、イネーブリング テクノロジーとなっています。現在 (2018 年)、株式市場取引システム、モバイル デバイス、インターネット オペレーション、不正検出、運輸業界、政府の情報収集など、多くのビジネス セクターでアプリケーションが見られます。
イベントに関する膨大な量の情報は、イベントクラウドと呼ばれることがあります。[ 1 ]
監視システムは、数千件の受信イベントの中から、例えば同じソースから以下の3つのイベントを受信する可能性がある。
これらのイベントから、監視システムは複雑なイベント、つまり結婚式を推測することができます。CEP という技術は、鐘、結婚式の衣装を着た男性と女性、空中に舞う米など、他のイベントを分析して相関させることで、複雑なイベントを発見するのに役立ちます。 [ 5 ]
CEPは、以下のような多くの技術に依存している[ 6 ]。
CEPの商用アプリケーションはさまざまな業界に存在し、クレジットカード詐欺の検出、ビジネス活動の監視、セキュリティ監視などが含まれます。[ 7 ]
CEP 分野は、離散イベントシミュレーション、アクティブデータベース分野、およびいくつかのプログラミング言語にルーツを持っています。業界での活動は、1990 年代の研究プロジェクトの波に先行していました。[ 8 ]によると、汎用 CEP 言語と実行モデルへの道を開いた最初のプロジェクトは、スタンフォード大学のDavid Luckhamが指揮したRapide プロジェクトでした。並行して、カリフォルニア工科大学のK. Mani Chandyが指揮したInfospheresと、ケンブリッジ大学のJohn Bates が指揮したApamaという 2 つの研究プロジェクトがありました。商用製品は、これらの研究プロジェクトと、その後のいくつかの研究プロジェクトで開発された概念に依存していました。コミュニティの取り組みは、イベント処理技術協会が主催する一連のイベント処理シンポジウム、そして後に ACM DEBS 会議シリーズで始まりました。コミュニティの取り組みの 1 つは、イベント処理マニフェストを作成することでした。[ 9 ]
CEPは、運用インテリジェンス(OI)製品において、ライブフィードやイベントデータに対してクエリ分析を実行することで、業務運営に関する洞察を提供するために使用されます。OIはリアルタイムデータを収集し、過去のデータと相関させることで、洞察と分析を提供します。複数のデータソースを組み合わせることで、最新の情報に基づいた共通の運用状況図を作成できます。
ネットワーク管理、システム管理、アプリケーション管理、サービス管理では、通常、イベント相関という用語が使われます。CEPエンジンとして、イベント相関エンジン(イベントコレレータ)は大量のイベントを分析し、最も重要なイベントを特定してアクションをトリガーします。ただし、それらのほとんどは新しい推論イベントを生成しません。代わりに、高レベルのイベントと低レベルのイベントを関連付けます。[ 10 ]
推論エンジン(例えば、ルールベース推論エンジン)は、人工知能において推論された情報を生成するのが一般的です。しかし、それらは通常、複雑な(つまり、推論された)イベントの形で新しい情報を生成するわけではありません。
CEPのより体系的な例として、車、いくつかのセンサー、そして様々な出来事や反応が挙げられます。車に複数のセンサーが搭載されていると想像してみてください。1つはタイヤの空気圧を測定し、1つは速度を測定し、もう1つは誰かが座席に座ったか、座席から降りたかを検出するセンサーです。
最初のシナリオでは、車が走行中に、タイヤの1つの空気圧が15分かけて45psiから41psiに低下します。タイヤの空気圧が低下するにつれて、タイヤ空気圧に関する一連のイベントが生成されます。さらに、車の速度に関する一連のイベントも生成されます。車のイベントプロセッサは、比較的長い期間にわたってタイヤ空気圧が低下した結果として「lossOfTirePressure」イベントが生成される状況を検出する場合があります。この新しいイベントによって、空気圧の低下を車のメンテナンスログに記録し、車のポータルを介してドライバーにタイヤ空気圧が低下したことを通知する反応プロセスがトリガーされる場合があります。
2つ目の状況では、車が走行中にタイヤの1本の空気圧が5秒間で45psiから20psiに低下します。異なる状況が検出されます。これは、空気圧の低下がより短い時間で発生したため、または各イベント間の値の差が事前に定義された制限値よりも大きかったためと考えられます。この異なる状況により、「タイヤ破裂」という新しいイベントが生成されます。この新しいイベントは、ドライバーに即座に警告を発し、車載コンピューターのルーチンを開始して、スリップによる制御不能を防ぎながら車を停止させるためのドライバーのサポートを行う、異なる反応プロセスをトリガーします。
さらに、検出された状況を表すイベントは、より複雑な状況を検出するために他のイベントと組み合わせることもできます。たとえば、最後の状況では、車は正常に走行中にタイヤがパンクし、その結果、車は道路から外れて木に衝突し、運転手が車外に投げ出されます。一連の異なる状況が迅速に検出されます。「タイヤのパンク」、「速度ゼロ」、「運転手が左側の座席に」というイベントが非常に短い時間内に組み合わさることで、「乗員が投げ出される事故」という新しい状況が検出されます。運転手が投げ出されたこと、または事故が発生したことを決定的に判断できる直接的な測定はありませんが、イベントの組み合わせによって状況が検出され、検出された状況を示す新しいイベントが作成されます。これが複合イベント(または複合イベント)の本質です。状況を直接検出できないため、他のイベントの組み合わせから状況が発生したことを推測または推論する必要があるため、複雑なのです。
CEPにとって自然な組み合わせは、ビジネスプロセス管理(BPM)である。 [ 11 ] BPMは、運用環境に合わせて継続的に最適化および整合するために、エンドツーエンドのビジネスプロセスに焦点を当てている。
しかし、ビジネスの最適化は、個々のエンドツーエンドのプロセスだけに依存するものではありません。一見無関係に見えるプロセス同士でも、互いに大きな影響を及ぼし合うことがあります。次のシナリオを考えてみましょう。航空宇宙産業では、車両の故障を監視して傾向を把握する(製造プロセスや材料などの潜在的な弱点を特定する)ことが推奨されています。別のプロセスでは、現在稼働中の車両のライフサイクルを監視し、適切な時期に廃止措置を行います。CEPの用途の一つは、これらの別々のプロセスを連携させることです。例えば、最初のプロセス(故障監視)で金属疲労による不具合(重大な事象)が発見された場合、2番目のプロセス(ライフサイクル)を活用して、最初のプロセスで欠陥が発見されたのと同じバッチの金属を使用している車両のリコールを実施するアクションを作成できます。
CEPとBPMの統合は、ビジネス認識レベル(ユーザーは個々のプロセスの潜在的な全体的なメリットを理解する必要がある)と技術レベル(CEPがBPM実装と相互作用できる方法が必要である)の両方のレベルで実現されなければなりません。イベント駆動型ビジネスプロセス管理と呼ばれることが多いCEPとBPMの統合に関する最新のレビューについては、[ 12 ]を参照してください。
計算指向のCEPの役割は、ビジネスルール技術と重複する部分があると言えるだろう。
例えば、カスタマーサービスセンターでは、クリックストリーム分析や顧客体験管理にCEPを使用しています。CEPソフトウェアは、毎秒数百万件のイベント(クリックやその他のインタラクション)に関するリアルタイム情報をビジネスインテリジェンスやその他の意思決定支援アプリケーションに組み込むことができます。これらの「推奨アプリケーション」は、エージェントが各顧客の体験に基づいてパーソナライズされたサービスを提供するのに役立ちます。CEPアプリケーションは、電話中の顧客が現在何をしているか、または支店内やWeb上のセルフサービス機能、インスタントメッセージ、電子メールなど、他のさまざまなチャネルで最近企業とどのようにやり取りしたかに関するデータを収集する場合があります。アプリケーションは、顧客体験全体を分析し、電話中のエージェントをガイドし、顧客満足度を維持するのに役立つスクリプトや次のステップを推奨します。[ 13 ]
時系列データベースとは、時間軸に沿って整理されたデータの処理に最適化されたソフトウェアシステムです。時系列とは、データ項目の有限または無限のシーケンスであり、各項目にはタイムスタンプが関連付けられ、タイムスタンプのシーケンスは非減少です。時系列の要素は、しばしばティックと呼ばれます。タイムスタンプは必ずしも増加(非減少)である必要はありません。なぜなら、金融データソースなどの一部のシステムの時間分解能は、実際には非常に低い(ミリ秒、マイクロ秒、あるいはナノ秒単位)場合があるため、連続するイベントが同じタイムスタンプを持つ可能性があるからです。
時系列データは、複雑なイベント処理に通常関連付けられる分析に歴史的な文脈を提供する。これは、金融[ 14 ]などのあらゆる垂直産業に適用でき、BPMなどの他のテクノロジーと連携して使用できる。
CEP分析の理想的なケースは、過去の時系列データとリアルタイムのストリーミングデータを単一の時間軸として捉えることです。昨日、先週、あるいは先月に起こったことは、今日起こっていること、そして将来起こりうることの単なる延長線上にあると考えます。例えば、取引執行ロジックのために、現在の市場取引量を過去の取引量、価格、ボラティリティと比較することが考えられます。また、リアルタイムの市場価格に基づいて行動する必要がある場合、セクターや指数の動きを含むベンチマークと比較することが考えられます。これらのベンチマークの日中および過去のトレンドは、ボラティリティを測定し、外れ値を平滑化するのに役立ちます。
複雑イベント処理は、モノのインターネット(IoT) 環境やスマートなサイバーフィジカルシステム(CPS) においても重要なイネーブラーです。このような場合、さまざまなセンサーからの高密度で異質なストリームを処理し、それらのストリームに対してパターンを照合することが典型的なタスクです。 [ 15 ]これらの技術の大部分は、IoT システムの状態とその変化を静的な具体化モデルではなく、データストリームの形式で表現する方が効率的であるという事実に依存しています。このようなストリームベースのモデルに対する推論は、従来の推論技術とは根本的に異なり、通常はモデル変換と CEP の組み合わせが必要です。[ 16 ]