この記事では、イベント処理の概念モデルを紹介します。基礎をなすイベント処理ネットワーク、および関連するイベント処理の概念アーキテクチャーを説明し、イベント処理アーキテクチャーの概念ビュー、および有用なイベント処理システムを構築するために必要となる主要なコンポーネントを明らかにします。

Mike Edwards, Strategist, IBM

Mike Edwardsは、英国 Hursley Lab を拠点とする Emerging Technologies に勤務するストラテジストです。OASIS SCA Assembly 技術委員会で共同議長を務める傍ら、Apache Tuscany のコミッターとして活躍しています。また、European PEPPOL プロジェクトの仕様にも貢献しています。



Opher Etzion, STSM, Event Processing Scientific Leader, IBM

Opher Etzion は、IBM Senior Technical Staff Member および Master Inventorです。イスラエルのハイファにある IBM Research Lab で Event Processing Scientific Leader を務め、Event Process Technical Society (EPTS) 運営委員会では議長を務めています。



Mamdouh Ibrahim, Distinguished Engineer, IBM

Dr. Ibrahim は、IBM Distinguished Engineer であり Enterprise Architecture and Technology プラクティスの CTO です。彼の任務には、EA および SOA アセットの開発、クライアントへのアーキテクチャーに関する専門知識の提供およびコンサルティングが含まれます。彼は電気工学と数学で 2 つの学士号を、数学、物性科学、コンピューター・サイエンスで 3 つの修士号を、そしてコンピューター・サイエンスで博士号を取得しました。現在、IEEE、ACM、そしてセントラル・ミシガン大学付属学部のメンバーです。



Sreekanth Iyer, Senior IT Architect, IBM

Sreekanth Iyer は Senior IT Architect として、カスタマーおよびパートナーのために IBM SOA ソリューションを構築する IBM India Software Lab Services and Solutions チームに所属しています。



Hubert Lalanne, Distinguished Engineer, IBM

Hubert Lalanne はフランスを拠点に活躍する IBM Distinguished Engineer であり、Software Information Technology Architect (SWITA) です。彼は、IBM Software Group WW Technical Leadership Council およびIBM Technical Expert Council France and NW Africa のメンバーでもあります。



Mweene Monze, Executive IT Architect, IBM

Mweene Monze は、南アフリカのヨハネスブルグにある IBM Software Group の Executive IT Architect として、Public Sector Technical Sales を担当しています。



Catherine Moxey, STSM, CICS Transaction Server for z/OS, IBM

Catherine Moxey は、英国ハースレイの CICS Transaction Server for z/OS チームに所属する IBM Senior Technical Staff Member で、CICS でのイベント処理サポートのアーキテクトとして働いています。彼女は Event Processing Technical Society のメンバーとして、Reference Architecture ワークグループで活躍しています。



Marc Peters, Senior IT Architect, IBM

Marc Peters は、ドイツのケルンを拠点とする Energy and Utility Customers の Senior Software IT Architect として、エネルギー公益事業の要件に関連する SOA、イベント処理および IoD でのビジネス機会とプロジェクトを先導しています。国際的プロジェクトでの IT に 17 年以上の経験を持つ彼は、社内およびカスタマーのイベントで頻繁に講演を行っています。



Yuri Rabinovich, Researcher, IBM

Yuri Rabinovich は、イスラエル IBM Haifa Research Lab の Event-based Middleware and Solutions グループに所属する研究者です。イスラエル工科大学で情報システム管理の修士号を取得した後、2006年に IBM Haifa Research Lab に入社し、表現力豊かな複合イベント処理ルール・エンジン AMIT (アクティブ・ミドルウェア技術) に取り組みました。スケーラブルな分散イベント処理の研究プロジェクを先導し、WebSphere Business Events エンジンをターゲットとしたイベント処理のパフォーマンスを改善する新たな手法を開発しました。



Guy Sharon, Manager Event Based Middleware, IBM

Guy Sharon は、イスラエル IBM Haifa Research Lab の Event-based Middleware and Solutions グループの管理者です。彼は、イスラエル工科大学で情報システム管理の修士号を取得しましたが、修士論文は、イベント処理ネットワークの概念モデルについてでした。2000年に、IBM Haifa Research Lab に入社してからは AMIT (Active Middleware Technology) Research and Development チームの 1 つに加わり、アクティブ技術である表現豊かな複合イベント処理ルール・エンジンに取り組みました。



Kristian Stewart, Architect, Tivoli Software, IBM

Kristian Stewart は、Tivoli Network Availability Management のアーキテクトです。



2010年 2月 09日

はじめに

多くの業界の企業は、これまで常にイベント主導型で行動してきましたが、処理しなければならないビジネス・イベントとトランザクションは日々増え続けています。イベント処理 (EP) は、主として企業が大量のビジネス・イベントと IT イベントに素早く対応する必要に迫られて生まれた分野です。この分野では、意思決定サイクルは、企業にとって重要なイベントをより効果的に処理することによってサポートされる必要があると認識されており、企業のサービス指向アーキテクチャー (SOA) 戦略にとって次第に重要な部分となってきています。

この記事で最初に説明するのは、イベント処理の必要性、さまざまなタイプのイベント処理、およびイベント処理を採用することによってビジネスにもたらされる価値です。次に、イベント駆動型アーキテクチャー (EDA) を実現するために使用できるイベント処理の概念モデルを詳説します。この記事では、意思決定を改善するためにイベント処理を実装した 3 つのビジネス・シナリオを取り上げて、これらの概念を詳しく説明します。


イベント処理の概要

イベントとは、発生したか、または発生していると考えられる、あらゆる重要な事象のことです。イベントは発生するか発生しないかのどちらかであり、何らかのアクションに影響を与える可能性があるため大変に重要です。イベントは、それが真実になっている事実でありえたか、または現実世界における実体の遷移でありえたときに発生していると考えられます。イベントがビジネス・プロセスの一環であることもあります。例えば、取引注文の発行、特定の航空便の到着、センサー・データの採取といったイベントや、あるいは IT インフラストラクチャー、ミドルウェア、アプリケーション、およびビジネス・プロセスに関する情報をモニターすることもイベントとなります。図 1 に、イベント処理の大まかな概要を示します。

図 1. イベント処理の概要
イベント処理の概要

イベント (ビジネスの内外で発生する重要な事象) が、サービスの呼び出し、ビジネス・プロセスの開始、またはさらに詳しい情報の公開あるいは配布のきっかけとなることがあります。イベント処理とは、そのような意味のあるイベントを無数のイベントの中から識別することを目的として、1 つのイベント、または多数のイベントを処理することです。ビジネス価値の点から見たイベント処理は、企業においてビジネスに影響を与える状況が発生していることを示すイベントを検出し、それに対処するための能力です。例えば、新規顧客の追加、製品の販売、積み荷の受け取り、セキュリティー・ドアの開放、および GPS による資産の現在位置の提供などは、イベント・メッセージで示すことができます。

イベントを生成するのはイベント・プロデューサー (つまり発信元) です。イベント・プロデューサーは、例えばアプリケーション、データ・ストア、サービス、ビジネス・プロセス、トランスミッター、またはセンサーであったり、インスタント・メッセージ・アプリケーションや電子メール・アプリケーションなどのコラボレーション・ツールであったりします。イベント・プロデューサーからイベントを受信した時点で、イベントが直接結果につながる場合も、イベントをイベント処理パターンと照らし合わせて評価する場合もあります。イベント処理パターンは、イベント・プロデューサーのニーズではなく、利害関係者のニーズに応じて定義されます。イベント処理の結果、例えばサービスの呼び出し、ビジネス・プロセスの開始、サブスクリプション・ハブへのイベントのパブリッシュ、人間またはシステムへの直接的な通知、新しいイベントの生成、および/または履歴を目的としたイベントの取得など、さまざまなアクションが行われます。このようなイベントとそのビジネス・サービスとの相互作用は、一般にイベント駆動型情報システム、またはイベント駆動型アーキテクチャーと呼ばれます。


概念的基盤

イベント処理をサポートするアーキテクチャーの概念的構成要素 (つまり、イベント処理システム) は、イベント処理ロジックなどのコア機能を提供し、イベントを介してイベント・プロデューサーとイベント・コンシューマーを結び付ける必要があります。このようなアーキテクチャーとシステムについて考える際に役立つモデルが、イベント処理ネットワーク (EPN) という構成概念です。EPN は定式化された概念であり、イベント処理システムの構造と、これらのシステムのすべてがサポートする必要がある共通の機能を記述します。EPN では、イベント処理システムは、相互に作用し合うイベント・プロデューサー、処理エージェント、およびコンシューマーの集まりであるとみなされます。このコンテキストでの EPN の主な役割は、プロデューサーからイベントを受信し、正しい組み合わせのイベント処理エージェントにイベントを渡して処理させ、処理済みのイベントを正しいコンシューマーに提供することです。イベント処理ネットワークの構成概念については、この記事のイベント処理の概念モデルについて解説するセクションで詳しく説明しますが、この概念モデルは、可視化、イベント・データベース、イベント駆動型ミドルウェア、イベント処理言語だけでなく、モデリングとプログラミングからモニタリングと応答に至るイベントのライフサイクル全体にわたる管理をサポートするあらゆる側面を網羅します。

イベント処理のタイプ

イベント処理の機能は、処理の複雑さと精巧さによって、単一イベント処理と複合イベント処理の 2 つに大きく分けることができます。

  • 単一イベント処理 (Simple Event Processing): 単純なイベント (他のイベントのセットを要約しない、表現しない、または意味しないイベント) はフィルタリングされ、変更されることなくそのままルーティングされます。したがって、重要なイベントが発生してダウンストリームのアクションが開始されると、各イベントの発生は独立して処理されることになります。「単純」と呼んではいるものの、このようなイベントが大きな価値をもたらし、重要なビジネス情報を提供することもあります。イベントの変換には、イベントの解釈と分割、および 1 つ以上のイベントのマージが伴います。単純なイベント処理の例には、あるイベント・スキーマから他のイベント・スキーマへの変更、データの追加によるイベント・ペイロードの増補、あるチャネルまたはストリームからのイベントのリダイレクト、および 1 つのイベントのペイロードを基にした複数のイベントの生成などがあります。このようなイベント処理は、必ずしも独立した処理タイプとして区別されるわけではありません。
  • 複合イベント処理 (Complex Event Processing): 新しい「複合イベント」を得るためには、複数の独立したイベントにまたがるパターンを検出します (複合イベントとは、他のイベントのセットを要約するか、表現するか、または意味するイベントです)。複合イベント処理では、ビジネスにとって重要な状況を検出することを目的に、一連のイベントが処理されます。一般に、このような処理には、一連の評価条件や制約のイベント・セットへの適用が伴います。イベント (注目に値するイベント、または通常のイベント) は、そのタイプが多岐にわたることも、特定の期間にわたって発生することもあります。また、イベントは複数の次元の利害 (原因次元、時間次元、空間次元やその他) で相関している場合もあります。複合イベント処理によって入手できる情報の複雑さと豊富さは、ユーザーにとっての情報の複雑さとは異なります。また、異なっていなければなりません。

イベント処理の構成概念はさまざまなプログラミング・モデルによって表現されますが、構成概念のモデリングおよび実装は、アプリケーション統合ミドルウェア、およびさまざまなネットワークおよびシステム管理プラットフォームによってサポートされます。ここ数年の間に、複合イベント処理用のツールとエンジンが登場してきており、イベント処理に分析手法を組み合わせると、イベントを予測し、パターンを探り出し、そしてルーティングの決定とイベントの派生にリアルタイムの分析性を盛り込むことができるようになります。このような手法を用いてリアルタイムのイベント分析を行うことで、意思決定のループ内でよりインテリジェントな決定を下せるようになります。

ビジネス・イベント処理

ビジネス・イベント処理は、ビジネス・ユーザーがイベント処理を使用できるような形にすることによって、イベント処理を拡張し構築します。ビジネス・イベント処理では、イベント処理の機能とツールがビジネス・ユーザーに提供されるため、ビジネス・ユーザーはビジネスに貢献するイベント駆動型情報システムの構築にイベント処理技術を応用することができます。アクションを実行できるビジネス状況を示すイベントやイベント・パターンが発生したこと (または発生していないこと) を検知できるということは、ビジネスが機会や脅威に迅速に対応できるということです。

図 2. ビジネス・イベント処理: イベント処理機能にビジネスの視点を追加する
ビジネス・イベント処理: イベント処理機能にビジネスの視点を追加する

ビジネスの管理者とアナリストは、アクションを実行できる状況、つまり重要なイベントまたはイベントの組み合わせと、これらのイベントに対して取るべきアクションを理解しています。彼らは日々これらの状況に対処し、いつこの状況が発生したのかを把握し、その状況への対応を管理する直接的な責任を持ちます。しかし、彼らは状況そのものの規模と複雑さを識別して対処するためのソリューションを持っていません。それと同時に、現在、IT インフラストラチャーからはアクションを実行できるかもしれない何百万ものイベントが大量に押し寄せてきていますが、高度なイベント処理機能をサポートするためには、一連の専門的な機能が必要です。しかし、ほとんどの IT 組織にはこのような要件を効果的かつ効率的にサポートする技術がありません。ビジネス・イベント処理は、特にこの課題に対処するよう意図されています。つまりビジネス・イベント処理は、ビジネス・システムから送られてくる情報を活用して、ビジネスの意思決定プロセスをサポートします。

ビジネス・イベント処理とは、イベントを検知し、アクションを実行できるビジネス状況が発生したことを示し、正しいタイミングで正しい対応 (アクション) を行う機能のことです。ビジネス・イベント処理では、システムとインフラストラクチャーを統合し、企業全体でイベントの発生をモニターします。このタイプの処理では、重要なイベントが発生すると同時にそれを認識し、警報を出して、適切な対応を開始するためにイベントに関する情報を配信します。ビジネス・プロセス・マネジメント・ソリューションの一部としてビジネス・イベント処理を組み込むと、動的なビジネス・プロセス実行とタイムリーなイベント・パターン検出という強力な組み合わせとなります。ビジネス・イベント処理は IT に、ハイパフォーマンスで管理しやすく、スケーラブルな環境における高度なイベント処理要件をサポートする機能を提供します。さらに、ビジネス・イベント処理に非プロシージャー型のグラフィカル・ユーザー・インターフェースを組み込めば、ビジネス・ユーザー自身がイベント処理の相互作用とアクションを定義することもできます。

イベント処理がもたらす価値

イベント処理の基本原理はかねてから、アプリケーション統合ミドルウェア、ならびにオペレーティング・システム、ネットワーク管理ソフトウェア、およびシステム管理ソフトウェアなどのさまざまな形のシステム・ソフトウェアで幅広く使用されてきました。しかし、イベント処理によってさらにもたらされる価値は、イベントの重要性をビジネスのコンテキストから認識し、そのイベントに関連する正しい対応を識別するところにあります。それにより、いろいろなことがビジネスで可能になります。例えば、イベント処理によってビジネスが新しい機会や競争相手の脅威に迅速に対応したり、適切な人々にタイムリーに関連情報を広めたりできます。さらに、問題を素早く診断したり、ビジネス全体の現状をリアルタイムに把握したりできます。

イベント処理によりビジネスが、トレンドと脅威を識別したり、リスクを軽減する機会を捉えたり、価値実現までの時間を短縮したり、迅速な検出サイクルや対応サイクルを実現したりするのに役立ちます。このようなイベント処理の市場は、以下のようなさまざまな業界で拡大しつつあります。

  • 裁定機会に対応しなければならない、資本市場のトレーダー
  • 適切な攻撃措置や防御措置を判断するために、衛星とセンサーから絶え間なく送られてくるデータを評価している軍事アナリストや情報アナリスト
  • リアルタイムの車両テレメトリーを利用して、車両管理を効率化している運送業および物流業
  • 不正、マネー・ロンダリング、または金融規制に対する違反を見つけるために、常に取引をトレースしている銀行員
  • ネットワーク障害の平均修復時間を最小限にしようと努めている、通信サービス・プロバイダー
  • リアルタイムの操作データに基づいて、採掘の深さと幅を動的に決定している石油会社
  • 複雑な製造上の意思決定を活用して、「ジャスト・イン・タイム」生産用の部品を製造業者に供給している自動車部品の納入業者

上記の例に限らず、さまざまな業界には大量の複雑なデータをリアルタイムで処理しなければならない固有の要件があります。その機能を提供するのが、イベント処理です。また、企業が迅速な意思決定を行うために、バッチ処理からリアルタイム処理へ移行する必要性が高まっていることも、イベント処理の需要を後押ししている一因です。さらに、新たな作業負荷には、データ・イベントだけでなく、音声やビデオのような従来とは異なるソースから発生するイベントも含まれてきています。このような作業負荷の特性にも、リアルタイムに近い複合イベント処理が必要となります。

この見解は、単純なイベントから複雑なイベントまでさまざまな形態のイベントが、ビジネス・アプリケーションにおいて、より幅広く使用されていると指摘している業界アナリストの意見を裏付けています。イベント駆動型ビジネス・プロセスは、現実世界の多くの側面がそなえ持っているイベント駆動型という性質に適合していることから、イベント駆動型ビジネス・プロセスを実装することで、金銭的にも戦略的にも膨大な利益がもたらされます。

イベント駆動型ビジネス・プロセスは、従来のプロセスの実行時間を短縮したプロセスというだけではありません。むしろ、「通常のビジネス」とは一線を画した固有の特性を持っています。イベント駆動型アプリケーションでは、プロセスを迅速に変更することも、従来のプロセスであれば中断に至るようなエラーや例外的な条件に対応することも可能になります。企業がコストを削減しながら、顧客、供給業者、そして世界全体への応答性を改善しようとするなか、イベント駆動型設計の概念はますます広く使用されるようになっています。企業がイベント駆動型ビジネス・プロセスを実装することによって利益を求めるのは、ビジネスが備え持っているイベント駆動型の性質に適しているからだけでなく、価値実現までのコストと時間の点でも、企業に競争優位を与えるからです。


イベント処理のシナリオの概要

この記事で表明する概念を説明するために、以降のセクションでは以下に示す 3 つのイベント処理のシナリオを展開させます。これにより、概要セクションで示されたイベント処理の価値が明らかになります。

  • 車両管理のシナリオ
  • 公衆衛生警報のシナリオ
  • 通信サービス・プロバイダーのシナリオ

上記のシナリオを紹介した後、さまざまなイベント処理の概念を各シナリオにマッピングし、このようなシナリオに対してイベント処理がもたらす付加価値を説明します。最初のシナリオ (車両管理) については、他のシナリオにも共通する側面を紹介するので、より詳細なレベルにまで掘り下げて説明します。

最初に、各シナリオのビジネス・コンテキストの説明から始めます。そして、この記事の後半で、シナリオに関連するイベントと、そのイベントの概念モデルの各側面へのマッピングについて説明します。

車両管理のシナリオ

このシナリオで取り上げるのは、比較的短距離での小型荷物の配送を専門とする「Fast Delivers」という会社です。この会社が所有する車両のそれぞれには GPS が搭載されていて、車両の位置を常にブロードキャストしています。配送する荷物には RFID タグが付けられます。必要なサービス・レベルに準じて、荷物は 2 地点間でそのまま配送されるか、あるいはいったんハブに集荷され、そこから (おそらく) 別の車両で宛先に配達されるかのいずれかです。荷物ごとに配達保証期限があり、その期限までに配達されなかった場合にはペナルティーが課せられます。配送の中には、(月間スケジュールに基づく) 定期的なものもあれば、顧客からの電話 (または Web サイト) による注文によって発生するものもあります

図 3. 車両管理の概要
車両管理の概要

このシナリオは、IBM の車両最適化のソリューションを基に考案されています。トラックおよび自動車の管理者は、以下に示す目標を持ってビジネスを管理し、維持しています。

  • 燃料費を削減すること
  • 車両とドライバーをトラッキングすること
  • 顧客に最新の情報を提供すること
  • 荷物の積み降ろしと配送経路の計画プロセスを効率化するためのスイート・スポットを見つけること
  • 資産利用率を向上させること
  • 顧客サービスを改善すること
  • 運営費を削減すること
  • 予定外のメンテナンス費用を削減すること
  • リスクを緩和して保険費用を削減すること

時機を得た適切な車両管理を行うために、この会社は社内システムにイベント処理を導入することにしました。こうしてこの会社は、各顧客との契約を順守しながらも、顧客から新しく発生した需要に迅速に対応し、配送経路を割り当て直してその需要を満たせるようになりました。さらに、リスクが現実化するとすぐにそれに対応し、契約に違反する前に再割り当てを行うことによって、その状況を緩和することもできます。イベント処理では、車両、注文などが絶えずモニターされ、その現状がイベントという形で提示されるため、会社は機会やリスクが現実化するとすぐに対応し、(上記リストに示した指標を維持するために) どのように行動するかを決定できます。また、会社はシステムに変更を加えると、その変更をプロセスに迅速に自信を持ってデプロイすることもできるようになります。これは、長期間に及ぶ、エラーの種となりがちな開発プロセスを踏むことなしに、単にイベント処理のロジックまたはアプリケーションを変更するだけで済むからです。

後半のセクションで、このシナリオに関連するイベントとイベント処理の概念を検討します。

公衆衛生警報のシナリオ

この公衆衛生警報のシナリオで取り上げるのは、住民に危険をもたらす現実の、または潜在的なアウトブレーク (感染症の集団発生) の兆候が現れた場合の警報システムです。SARS や鳥インフルエンザ (H5N1)、あるいは生物兵器や化学物質を使ったテロ攻撃は、警報の対象となるアウトブレークのほんの一例に過ぎません。

このシナリオでは、鳥インフルエンザと新型鳥インフルエンザ (H5N1) のアウトブレークを取り上げますが、H1N1 などの他のアウトブレークにも同じく当てはまります。

世界保健機関で定義されたパンデミック (伝染病の世界的な流行) のステージ (状態) は、パンデミック間期 (ヒトではインフルエンザ・ウィルスが検出されていない状態) からパンデミック期 (一般住民で感染拡大が続いている状態) までの進行状態を表します。このシナリオでは主に 3 つのステージを検討します。ウィルスが検出されていない状態、エピデミック状態 (感染が拡大している状態)、そして最後のパンデミック状態の 3 つです。

図 4. 公衆衛生警報の概要
公衆衛生警報の概要

このシナリオの流れを説明すると、まず、ある研究所の血液分析でウィルスが検出されます。規則に従い、特定のウィルスが検出されたことがイベントとしてパブリッシュされます。イベントの受信者 (イベント処理の用語では、イベント・エミッター) は、イベントを正規化して基本的な品質および発生源をチェックしてからイベント処理エージェントにイベントを渡します。イベント処理エージェントによって情報が追加されたイベントは、パターン検出により、エピデミック・アウトブレーク警報を発するかどうかがチェックされます。エピデミック・アウトブレークと判断された場合、イベントにはさらに情報を追加し、詳細なパターン検出ロジックを適用してパンデミック・アウトブレークの有無をチェックする必要があります。エピデミックおよびパンデミック・アウトブレーク警報が発せられた場合、その通知はそれぞれに該当するイベントとして送信されます。国際的な健康管理機関や外国政府などの外部イベント・プロデューサーからのパンデミック・アウトブレーク警報も同じように扱われます。

このシナリオに関係するイベント、およびこのシナリオがどのようにイベント処理概念モデルと関連しているかについては、後半のセクションで取り上げます。

通信サービス・プロバイダーのシナリオ

このシナリオでは、架空の通信サービス・プロバイダー (CSP) 会社を取り上げます。この会社は国内の個人顧客と中小企業向けに、ブロードバンド・インターネット・アクセスから VOIP および仮想専用ネットワーク・サービスにまで至るさまざまな有線通信サービスを提供しています。会社のコア MPLS (MultiProtocol Label Switching) ネットワークは、さまざまな製造業者のネットワーク要素で構成されており、一連の EMS (Element Management System) によってサポートされています。顧客施設との接続には、ダイアルアップ、DSL、およびレイヤー 2 とレイヤー 3 の VPN に対応する技術など、広範なネットワーク技術を採用しています。

顧客が購入するサービス・パッケージに応じて、この会社はさまざまなサービス・レベル・アグリーメント (SLA) を用意しています。これら SLA は、指定されたメトリック (例えば、サービスの継続、使用可能なネットワーク帯域幅など) を使用して合意されたサービス・レベルを保証する契約で構成されています。SLA が履行されない場合、会社には金銭的ペナルティーが課せられるだけでなく、会社の評判を損ねることにもなります。この会社では、顧客をそれぞれが合意したサービス・レベルに応じてレベル分けしています。

あらゆる CSP の例に洩れず、この会社もネットワーク運営センターを利用しています。ネットワーク運営センターを構成するのは、従業員、会社のコア・ネットワークの円滑な運営に使用されるハードウェア資産とソフトウェア資産、およびこのセンターが提供するサービスです。このネットワーク運営センターには以下の目標があります。

  • 法人顧客に提供するサービスの停止または劣化につながる可能性のある、ネットワーク障害の平均修復時間を最小限にすること
  • 停止および障害によって影響を受ける顧客と取り決めた SLA に応じて、修復の優先順位を付けることにより、会社の金銭的損害を最小限に抑えること
  • ネットワーク資産を最大限利用すること
  • 人員やエネルギー消費などの運営コストを最小限にすること
  • サービスに影響する障害発生時に、顧客と積極的に連絡を取り、障害修復の進行状況に関する最新情報を提供すること

この会社のネットワーク運営センターでは上記の目標を達成するために、ネットワーク管理技術とイベント処理技術を使用しています。これらのシステムは、以下に示すような多種多様なイベントを処理します。

  • ネットワーク内での障害検出
  • ネットワーク要素の状態変化
  • ネットワーク装置を収容する施設およびネットワーク装置自体の環境状態
  • イベントに対する自動応答の結果
  • ネットワーク・イベントに対応する (人間の) オペレーターのアクション
  • 障害の解決の自動検出

このイベント・データへのアクセス、およびイベント・データを処理するツールによって、ネットワーク運営センターでは以下の作業を行うことができます。

  • コア・ネットワークを構成する要素のヘルス、可用性、およびパフォーマンスをモニターする
  • 一貫性のある可視化および処理のために、ネットワーク・イベントを共通フォーマットに正規化する
  • ネットワーク運営センターのオペレーターに、ネットワークで発生したイベントの最新の対話式ビューを提供する
  • 以下の目的のために、コア・ネットワークの最新モデルを自動的に検出して維持する
    • デプロイされた資産の可視性の維持
    • 物理的および論理的ネットワーク・トポロジーのモデル、およびこれらのモデルとプロビジョニングされたネットワーク・サービスとの関係の維持
    • 問題の診断およびトラブルシューティングを担当する運営スタッフへの、ネットワーク・マップ・ダッシュボートの提供
    • ネットワーク・トポロジーに基づく、ネットワーク・イベントおよびサービス停止の根本原因となっているイベントの分析
    • 新しいサービスのプロビジョニング・プロセスのサポート
  • 多数のネットワーク障害シナリオの自動対応、診断、および修復を実行する
  • イベントのパターン分析を行い、ネットワーク・イベントの原因とビジネスへの影響を推測する
  • 技術、トポロジー、およびビジネスのコンテキストに基づき、ネットワーク・イベントに情報を追加する
  • サービス・デスク・アプリケーションでのトラブル・チケットの自動作成に対するポリシーを規定し、物理的保守アクティビティーの推進につなげる

この架空の CSP 会社がある中堅企業と結んでいる契約は、その企業が所有する各地の施設間に VPN サービスを提供するというものです。この契約では、関連する SLA に従った高度な可用性を提供することが条件となります。そこで、この CSP 会社ではこの中堅企業の各施設に CSP のコア・ネットワークと接続するための専用カスタマー・エッジ (CE) ルーターを提供して管理しています。各 CE ルーターは、CSP の施設にあるプロバイダー・エッジ (PE) ルーターに接続されています。

PE ルーターで障害 (例えば、カードの故障) が発生した場合、イベント処理システムは物理的障害および論理的障害を意味する多数のイベントを受信することになります。これらのイベントは、障害が発生した装置とその周辺にあるネットワークの EMS から送信されますが、これには ICMP (Internet Control Message Protocol) ping 失敗、リンク・ダウン・アラーム、およびルーティング・プロトコル隣接障害などが含まれます。この状況では、イベント処理システムは以下のことに対処する必要があります。

  • 根本原因となっているイベントを識別し、ネットワーク運営センターのオペレーターにそのイベント (この例ではカードの故障) を強調表示する
  • 顧客サービスに影響があるかどうか (この例では、この中堅企業の VPN サービスが停止に至るかどうか) を推測する
  • 該当する SLA をネットワーク内の他の機能停止と照らし合わせて、サービス停止の相対的な重要度を決定し、それに応じて問題解決の優先順位を決定する (この例では意欲的な SLA が設定されているため、解決の優先順位は高くなります)。
  • 影響を受ける顧客に障害が識別されたことを通報し、障害に対処する技術者を派遣するために作業項目要求を提起する
  • 障害の解決を検出し、オペレーターと顧客に通常のサービスが再開されたことを通報する

このシナリオに関係するイベントと、イベント処理概念モデルとのマッピングについては、後半のセクションで検討します。


概念モデル

この記事の概念モデルでは、イベント処理システムの 2 つの異なる見方を提示しますが、技術的な枝葉末節とは切り離して、抽象的なレベルでのイベント処理システムの重要な概念、および概念間の関係を説明することを目的とします。イベント処理システムの入力要素、処理要素、出力要素の本質的特徴は、イベント処理ネットワーク (EPN) によって概念化されます。この EPN の概念を指針とすることで、ビジネス価値をもたらすために、イベント処理システムの実現に必要となる可能性がある抽象的なアーキテクチャー要素 (つまりコンポーネント) と、これらのコンポーネント間の相互関係が、概念アーキテクチャーによって特定されます。これは抽象的なレベルでの概念アーキテクチャーなので、コンポーネントを提供するために使用される可能性のある技術、プロトコル、および製品には依存しません。

概念アーキテクチャーの目標は、イベント処理システムとイベント駆動型アプリケーションを実装する基盤を形成し、イベント処理ソリューションのアーキテクチャーと実装を特定して、比較対照するための共通フレームワークを提供することです。

ここで意図しているのは、この概念アーキテクチャーが概念レベルで十分なコンポーネントを提供し、これらのコンポーネントからイベント処理システムの実装を組み立てられるようにすることですが、いずれのコンポーネントにしても、必ず実装しなければならないというわけではありません。コンポーネントによっては、対象のシステムで必要ない場合もあります。また、このモデルに準拠しなければならないことを暗示しているわけでもありません。


イベント処理ネットワーク

イベント処理システムの高度な抽象化には、イベント処理ネットワークの構成概念 (図 5 を参照) から引用した概念が当てはまります。前述のとおり、イベント処理ネットワークとは、イベント処理システムの構造と、イベント処理システムのすべてがサポートしなければならない共通の機能を表す定式化された概念です。

図 5. イベント処理ネットワーク
イベント処理ネットワーク

EPN を構成する 4 つのコンポーネントは、イベント・プロデューサー、イベント・コンシューマー、イベント処理エージェント (ここでは EPA と略称)、およびイベント・チャネルと呼ばれる接続コンポーネントです。EPN は、プロデューサーから受信したイベントが、エージェントで処理 (例えば、変換、検証、または情報追加) されて、コンシューマーに送信される仕組みを表現します。図 5 に、イベント・チャネル、コンシューマー、プロデューサー、および処理エージェントの関係を示します。この図に示されているように、あるコンポーネントから別のコンポーネントに渡されるイベントは、イベント・チャネルを経由しなければなりません。イベント・チャネルはノードであり、このノードによってイベント・プロデューサーを EPN 内の EPA に接続し、必要な場合には EPA を相互接続し、そして EPA をコンシューマーに接続します。結果的に、イベントはイベント・プロデューサーから EPN を介して最終的にイベント・コンシューマーに渡されることになります。この図からわかるように、EPN 内では、イベント・プロデューサーによって生成されたさまざまなイベントが、チャネルで相互に接続された EPA の集合によって処理される場合もあります。これは、イベント (またはイベントから派生されたイベント) を EPN 内のさまざまなイベント・コンシューマーで使用できるようにするためです。

イベント・チャネル

イベント・チャネルは、イベント・プロデューサーおよび EPA からのイベントまたはイベントのストリームを、イベント・コンシューマーおよび EPA に渡すためのメカニズムです。このレベルで抽象化されていれば、イベント・チャネルのプロパティーに課される制約 (各チャネルが複数のイベント・タイプを搬送できるかどうかなど) も、イベントを動かすメカニズムに課される制約もありません。

イベント・チャネルは、異なるイベント・プロデューサーおよび EPA からの複数のイベントを受信することも、複数のソースから組み合わせたイベントを、複数の EPA およびコンシューマーに転送することもできます。複合イベントを作成するために、複数の EPA およびイベント・プロデューサーからのイベントを結合する場合のイベントの順序付けは、それぞれの実装に固有なので、概念モデルでは扱いません。また、特定の順序付けが必要ない場合もあります。ただし、イベント・プロデューサーまたは EPA、あるいはその両方からイベントを受け取り、順序付け (必要な場合) と結合を行ってから適切なイベント・コンシューマーまたは EPA、あるいはその両方に提供するのは、イベント・チャネルの責任で行われます。

イベント・チャネルは、遡及的イベント処理のためにネットワーク内で受け渡しされるイベントの履歴を保存するという役割を担う場合もあります。この場合、イベント・チャネルは、保存されるイベントの期間とフィルタリング条件を決定する保存ポリシーに準拠してイベントを保存します。遡及的イベント処理とは、オンライン・イベント処理とは対照的に、イベントの履歴に基づいてイベント・パターンを発見することです。オンライン・イベント処理では新しいイベントが使用可能になった時点で、すでに定義されているイベント・パターンを検出します。

イベント・チャネルは EPN 内で、入力エッジと出力エッジを持つノードとして表されます。入力エッジは、イベントをそのチャネルに配置したイベント・プロデューサーまたはイベント処理エージェントからのイベントを意味します。出力エッジは、そのチャネルからイベントを受信するイベント・コンシューマーまたはイベント処理エージェントへのイベントを意味します。

イベント・プロデューサーおよびイベント・コンシューマー

イベント・プロデューサーはイベント・チャネルを介して、イベントの使用に関心のある任意の関係者のためにイベントを生成します。関係者に該当するのは、イベント・コンシューマーまたは EPA です。概念モデルでは、イベント・プロデューサーまたは EPA からイベントを取得するためのメカニズムには何の制約も設定しません。取得メカニズムには「プッシュ」モデルまたは「プル」モデルが関係することがあります。

ノードとエッジで構成されるネットワーク内では、イベント・プロデューサーはソース・ノードとして表されます。つまり、このノードには出力エッジしかありません。ノードの出力エッジの数は、イベントがプロデューサーから受信先の EPA またはコンシューマーに到達するまでに関与するイベント・チャネルの数です。イベント・プロデューサーは、同じ 1 つのイベントを複数のイベント・チャネルにパブリッシュしたり使用可能にしたりできますが、設計する際には、ルーティングの決定は EPA に任せるのが賢明です。その方が、より制御しやすい優れた設計となり、イベント処理全体のニーズを理解するにも役立ちます。

イベント・コンシューマーが関心を持つイベントは、そのコンシューマーの役割を果たすために必要なイベントです。対象のイベントを受信すると、イベント・コンシューマーは特定のタスク、またはそのイベントに関連付けられたタスクを実行します。

イベント・コンシューマーは受信側ポイントとして表されます。つまり、コンシューマーには入力エッジしかありません。入力エッジの数は、そのコンシューマーにイベントが到達するまでに関与するイベント・チャネルの数です。複数のイベント・チャネルから同じイベントを受信することもできますが、イベント処理全体のニーズを制御、設計、理解するには、イベントをどこで、いつ、どのように受信するかのロジックを EPA に任せるのが最善の策となります。

イベント・コンシューマーがイベント・プロデューサーを兼ねることも可能ですが、後者の役割も果たす場合は、イベント・コンシューマーは EPN 内のイベント・プロデューサーとして表現されることになります。

イベント処理エージェント

分散された異種混合システムでは、イベント・プロデューサーがイベント・コンシューマーの期待するイベントを生成しない場合があります。イベントによって、期待される構文 (構造)、または意味論的な意味、あるいはその両方が異なる可能性があるためです。また、単一のイベントがイベント・コンシューマーのアクションをトリガーするのではなく、異なるタイミングや異なるコンテキストで発生するイベントの複合体がアクションをトリガーする場合もあります。未加工のイベントにおいてパターンを検出し、これらのイベントに情報の追加、変換、および検証の処理を施し、最終的に新しいイベントを派生させるためには、イベント・メディエーターとしても知られる EPA が必要です。EPA は、このような派生イベントを生成し、派生イベントをどこで、どのように使用できるようにするかを決定します。

EPA が取り得るステージは、以下の 3 つです。

  • パターン・マッチング: 必要な場合、このステージでは指定のパターンに従って処理対象のイベントを選択します。パターン・マッチングを実行する EPA は、「パターン検出 EPA」と呼ばれます。
  • 処理: 必要な場合、このステージではパターンに適合して選択されたイベントに処理機能を適用し、新しいイベントを派生させます。
  • 発行: このステージでは、イベントまたはそこから派生したイベントをチャネルに発行します。

イベント・コンシューマーが、イベント・チャネルから受信したイベントに基づいて、アクションを実行するのと同様に、EPA はイベント・チャネルからイベントを受信すると、パターン検出やその他の処理を行います。また、イベント・プロデューサーが、イベント・チャネルを介して生成したイベントを送信するのと同じように、EPA もイベントを発行する際は、イベント・チャネルを介してイベントを送信します。ノードおよびエッジで構成されるネットワーク内では、EPA は入力エッジと出力エッジを持つノードとして表されます。入力エッジの数は、イベント・エージェントがパターン検出などの機能に使用するイベント・チャネルの数です。出力エッジの数は、エージェントが処理および発行の定義に基づいて、イベントを送信するために使用するイベント・チャネルの数です。

要するに、イベント処理ネットワーク (EPN) とは、イベント・チャネルで接続されたイベント処理操作の有向グラフのことです。ネットワーク内では EPA がイベント処理サービスおよびメディエーションを提供します。つまり、1 つまたは複数のイベントを入力として取得し、何らかの処理を実行し、そして (おそらく新しい) 複数のイベントを出力として返すか、またはまったく何も返しません。EPN の主な役割は、プロデューサーからイベントを受け取り、そのイベントを一連のイベント処理エージェントに渡してイベントを処理させてから、適切なコンシューマーにイベントを提供することです。


イベント処理ネットワークのシナリオ

このセクションでは、イベント処理ネットワークの定義とコンポーネントを、「イベント処理のシナリオの概要」セクションで説明したシナリオにマッピングします。

車両管理のシナリオ

以下の表に、イベント処理ネットワークのコンポーネント (プロデューサー、コンシューマー、イベント・チャネル、イベント処理エージェント、およびイベント) の一覧を示します。ここに記載されているのは、前のセクションで目標として述べた車両とドライバーのトラッキングの 1 つの側面に過ぎません。この会社では、ドライバーの安全を守り、事故を防ぐために規則を設けており、ドライバーのシフトが 8 時間を超えることは禁止されています。勤務時間が 8 時間を超えたドライバーは休憩しなければならないので、顧客への配達が遅れてペナルティーを支払わなくても済むように、配送物は他のドライバーに割り当て直さなければなりません。この再割り当てプロセスには、会社が所有するいずれかの施設に適切な集合場所を設定すること、当初の車両から別の 1 台の車両 (または複数の車両) に荷物を移すこと、そして遅延 (発生する場合) が最小限になるように経路を再計算することが必要です。ドライバーのシフト開始イベントと終了イベントは、ドライバーの報告システムから生成されます。再割り当てプロセスは、これらのイベント、および車両位置の継続的な認識を基にして実行することができます。さらに、イベントの情報追加、「運転時間超過」パターンの検出、およびルーティングに関する要件もあります。これらの要件は、イベント処理エージェントとして記載されます。

表 1. イベント・プロデューサー
イベント・プロデューサー説明
車両GPS がブロードキャストする位置、車両搭載センサー (燃料、排気、重量など)
ドライバー報告システム電子パンチ・カード
配送システム注文管理、荷物の仕分けと割り当ておよび配車システム
パッケージ RFID システムハブに配置された読み取り装置と社員用のモバイル読み取り装置 (例えば、荷物の集荷、配送、および配達時にドライバーが使用) を使用した荷物追跡システム
表 2. イベント・コンシューマー
イベント・コンシューマー説明
ドライバー用ディスプレイ経路、配送の変更、および警報をドライバーに知らせるために車両に搭載されたディスプレイとモバイル・ディスプレイ
配送管理ダッシュボード業務全体のビュー (車両の位置、経路、注文、荷物など)
クライアント荷物の発送者または受領者であり、通知を受け取ったり、注文を調べたりできます
表 3. イベント・タイプ
イベント・タイプ IDイベント・タイプ属性注釈
E1ドライバーの勤務開始タイムスタンプ、ドライバー ID-
E2ドライバーの勤務開始情報の追加タイムスタンプ、ドライバー ID、車両 ID、ドライバーの名前-
E3ドライバーの勤務終了タイムスタンプ、ドライバー IDE1 の構造に準拠可能
E4ドライバーの運転時間超過タイムスタンプ、ドライバー ID、車両 ID、ドライバーの名前-
E5配送の変更タイムスタンプ、ドライバー 1 の ID、車両 1 の ID、ドライバー 2 の ID、車両 2 の ID、送信者 ID、受信者 ID-
表 4. イベント・チャネル
イベント・チャネル IDイベント・タイププロデューサーコンシューマー保存ポリシー
EC1E1 ドライバー報告システムA1 -
EC2E2A1A2-
EC3E3ドライバー報告システムA2-
EC4E4A2A3、配送管理ダッシュボード-
EC5E5A3A4-
EC6E5A4クライアント、ドライバー用ディスプレイ、配送管理ダッシュボード1 週間
表 5. イベント処理エージェントの例 1
エージェントのプロパティー仕様
エージェント IDA1
エージェント名ドライバーの勤務開始情報の追加
エージェント・タイプ情報追加
エージェントのコンテキスト-
入力イベントE1
エージェント仕様ドライバー ID ごとにドライバー詳細から車両 ID およびドライバー名を追加
出力イベントE2
エージェントの注釈イベントにドライバー詳細 (車両 ID など) を追加
表 6. イベント処理エージェントの例 2
エージェントのプロパティー仕様
エージェント IDA2
エージェント名運転時間を超過したドライバー
エージェント・タイプパターン検出
エージェントのコンテキストドライバー ID ごとの間隔 (E2 に 8時間を追加)
入力イベントE3
エージェント仕様E3 の欠如
出力イベント-
表 7. イベント処理エージェントの例 3
エージェントのプロパティー仕様
エージェント IDA3
エージェント名配送再割り当て
エージェント・タイプパターン検出
エージェントのコンテキスト-
入力イベントE4, Ex
エージェント仕様ドライバー ID ごとにドライバー詳細から車両 ID およびドライバー名を追加
出力イベントE5
エージェントの注釈このエージェントは、配送変更の要件を推測するために、異なるタイプのイベントを受け取ります。どの車両が配送を引き継ぐかを決定し、どのように 2 台の車両をハブ、または別の場所で合流させるのかを決定するのは、このエージェントの役割です。
表 8. イベント処理エージェントの例 4
エージェントのプロパティー仕様
エージェント IDA4
エージェント名必要なコンシューマーへの再割り当て通知のルーティング
エージェント・タイプルーター
エージェントのコンテキスト-
入力イベントE5
エージェント仕様-
出力イベントE5
エージェントの注釈配送の変更をさまざまなコンシューマーにルーティングします。クライアントは通知を受けることができます (1 週間、再試行されます)。ドライバーは新しい指示を受けます。会社はこれらの新しい指示をトラッキングすることができます。

以下の図 6 に、この EPN のコンポーネントを図示します。ドライバーが勤務を開始すると、ドライバー報告システムがイベント E1 を生成し、そのイベントをチャネル EC1 にパブリッシュします。イベント E1 にはイベント処理エージェント A1 によって情報が追加され、派生イベント E2 となります。8 時間が経過すると、ドライバーのシフトが終了する前に運転時間が超過してしまったため、エージェント A2 がイベント E4 を生成します。イベント E4 は、配送管理ダッシュボードで受信されて管理されます。エージェント A3 も、チャネル EC4 からこのイベントを受け取ります。A3 は、別のドライバーが注文を期限内に配達し、しかもそのドライバーの運転時間を超過しないように、注文を割り当て直します。再割り当ての指示がイベント E5 によって通知されると、エージェント A4 は通知を必要とする複数のコンシューマーにその通知をルーティングおよびリダイレクトします。通知を受けるコンシューマーは、運転時間を超過したドライバー、そのドライバーの注文を引き継いで配送する (1 人または複数の) ドライバー、配送経路と配達予定時刻の変更を知らせるクライアント、そして管理を行う配送管理ダッシュボードです。ドライバーが配送物を別のドライバーに引き渡すまでは、そのドライバーのシフトが終了しないため、イベント E3 は生成されません (このイベントがエージェントに及ぼす影響はありません)。

図 6. 車両管理のシナリオの EPN の図示
車両管理のシナリオの EPN の図示

公衆衛生警報のシナリオ

以下の表に、「イベント処理のシナリオの概要」のセクションで説明した公衆衛生警報のシナリオに必要なイベント処理ネットワークのコンポーネントの一覧を示します。このシナリオの EPA については詳しく説明しません。

表 9. イベント・プロデューサー
イベント・プロデューサー説明
病院
研究所研究所が潜在的ウィルスまたはその兆候を検出して、イベントを発行する場合があります
医者医者が潜在的ウィルスまたはその兆候を検出して、イベントを発行する場合があります
外国政府機関外国政府機関がイベントを発行します
表 10. イベント・コンシューマー
イベント・コンシューマー説明
製薬会社製薬会社は健康警報のイベントをサブスクライブします。
政府機関政府機関は健康警報のイベントをサブスクライブします。
一般開業医一般開業医は健康警報のイベントをサブスクライブします。イベントにはおそらく、特徴および検出パターンに関する詳細情報が追加されます。
医療保険会社医療保険会社は健康警報のイベントをサブスクライブします。
報道機関報道機関は健康警報のイベントをサブスクライブします。
米国国土安全保障省 (United States Department of Homeland Security)米国国土安全保障省は健康警報のイベントをサブスクライブします。イベントにはおそらく、具体的な予防措置と検出パターンに関する情報が追加されています。

ある種の仲介者がイベント処理ネットワーク (EPN) を実装して、イベント・プロデューサー (誰がイベントを使用するのかも、イベントで何が行われるかも知りません) とイベント・コンシューマー (イベントの送信元や初期イベントの元の形や意味を無視します) とを分離するという考えもあります。

このようなイベント・プロデューサーと EPN との関係、およびイベント・コンシューマーと EPN との関係の他に、プロデューサーがイベントを (Web ページやフィードで) 一般公開し、EPN がイベントを取得するという場合も考えられます。その一方、EPN もイベントをそのコンシューマー向けに (おそらく同じメカニズムを使用して) 一般公開します。このような場合には、プロデューサーと EPN が分離され、コンシューマーと EPN も分離されるため、仲介者なしで分離されたシナリオというものも想定することができます。

表 11. イベントのタイプ
イベント・タイプ IDイベント・タイプ属性注釈
E1潜在的エピデミック・アウトブレーク警報ID、詳細逆のイベントは、潜在的エピデミック・アウトブレーク無し
E2潜在的エピデミック・アウトブレークの正規化ID、タイムスタンプ、場所、詳細元のイベントから正規化/変換されたイベント
E3潜在的エピデミック・アウトブレークの情報追加ID、タイムスタンプ、場所、追加詳細イベントに情報が追加されます
E4エピデミック・アウトブレーク検出警報ID、タイムスタンプ、場所、詳細エピデミック・アウトブレークは検出済みです (パターン検出)
E5エピデミック・アウトブレーク警報ID、タイムスタンプ、場所、詳細-
E6潜在的パンデミック・アウトブレーク警報ID、タイムスタンプ、場所、詳細-
E7潜在的パンデミック・アウトブレークの正規化ID、タイムスタンプ、場所、詳細エピデミック・アウトブレークは検出済みです (パターン検出)
E8潜在的パンデミック・アウトブレークの情報追加ID、タイムスタンプ、場所、追加詳細イベントに情報が追加されます
E9パンデミック・アウトブレーク検出警報ID、タイムスタンプ、場所、詳細パンデミック・アウトブレークは検出済みです (パターン検出)
E10パンデミック・アウトブレーク警報ID、タイムスタンプ、場所、詳細-

図 7 に、この EPN を図示します。

図 7. 公衆衛生警報のシナリオの EPN
公衆衛生警報のシナリオの EPN

通信サービス・プロバイダーのシナリオ

以下の表に記載するのは、「イベント処理のシナリオの概要」セクションで説明した通信サービス・プロバイダーのシナリオを対象としたイベント処理ネットワークのコンポーネントの一部 (イベント・プロデューサー、イベント処理エージェント、イベント・コンシューマー、およびイベント) です。

表 12. イベント・プロデューサー
イベント・プロデューサー説明
ネットワーク・モニターネットワーク装置をポーリングし (通常は ICMPや SNMP などのプロトコルを使用)、可用性とパフォーマンス・データをチェックするソフトウェア。ネットワーク要素での重要な変更を表すイベント、および通常の動作に対する例外を表すイベントを生成します。
ネットワーク要素のプローブネットワーク要素から警報を受信し、ネットワーク要素とその物理的および論理的隣接要素での重要な変更および障害を表すイベントを生成します。警報のリッスンには、一般に SNMP などのプロトコルを使用します。
EMS のプローブ管理対象のネットワーク要素での障害および重要な変更を表す警報を、EMS から受信します。SNMP、SOAP、CORBA、フラット・ファイルなどのいろいろな標準または独自仕様のプロトコルで、標準または独自仕様のイベント・フォーマットを使用できます。
イベント・オペレーター用ダッシュボードオペレーターのアクションに基づきイベントを生成します。これらのアクションには、ネットワーク装置およびサービスの停止によって生成されたイベントの確認応答、解決、および消去が含まれます。
表 13. イベント・コンシューマー
イベント・コンシューマー説明
オペレーター用ダッシュボードネットワーク運営センターのオペレーターに重要なイベントを対話式ビューで示します。カスタマイズ可能な診断ツールおよびフィルタリング機能が組み込まれています。
ネットワーク・エンジニアの携帯電話および電子メール・システムシステムによって上位レベルの処理事項とされた重要なイベントの結果として送信される SMS メッセージおよび電子メールを受信します。
顧客のビュー検出されたサービス停止は、影響を受ける顧客向けにフィルタリングされて、最新の情報が読み取り専用ビューに表示されます。
トラブル・チケット・システムネットワーク技術管理チームによるアクションが必要なイベントを、システムから受信します。
表 14. イベント・タイプ
タイプ IDイベント・タイプ属性注釈
E1ping 失敗タイムスタンプ、到達不可能なアドレス-
E2リンク・ダウンタイムスタンプ、リンク・ダウンが発生している PE ルーターのポート名、PE ルーターのアドレス-
E3カード故障タイムスタンプ、PE ルーターのアドレス、カード ID-
E4根本原因のイベントE3 と同じ属性根本原因として識別された E3 のコピー
E5症状に関するイベントE1 および E2 と同じ属性に加え、関連する根本原因症状として識別された E1 および E2 のコピー
E6影響された VPN サービスタイムスタンプ、VPN ID-
E7影響された VPN サービスの情報追加E6 と同じ属性に加え、顧客の連絡先情報-
E8技術者の派遣タイムスタンプ、技術者の連絡先情報-
E9ping 成功タイムスタンプ、ping を行ったアドレス-
E10リンク・アップタイムスタンプ、リンクが再確立された PE ルーターのポート名、PE ルーターのアドレス-
E11カード作動中タイムスタンプ、PE ルーターのアドレス、カード ID-
E12VPN サービス・アクティブタイムスタンプ、VPN ID-
表 15. イベント処理エージェントの例 1
エージェントのプロパティー仕様
エージェント IDA2
エージェント名サービスへの影響アナライザー
エージェント・タイプパターン検出
エージェントのコンテキスト-
入力イベントE4, E5
エージェント仕様顧客のネットワーク・サービスが中断される場合、サービスの影響を受けるイベントを生成する
出力イベントE6
エージェントの注釈ネットワーク要素とプロビジョニングされたサービスとの間のモデル化された関係を使用して、サービスが影響を受けるかどうかを判断します
表 16. イベント処理エージェントの例 2
エージェントのプロパティー仕様
エージェント IDA3
エージェント名顧客への影響アナライザー
エージェント・タイプルーティング、情報追加
エージェントのコンテキスト-
入力イベントE6
エージェント仕様SLA に関連付けられたポリシーに従って、サービスの影響を受けるイベントを上位レベルの処理事項とする。顧客の連絡先情報を追加する。
出力イベントE7
エージェントの注釈-
表 17. イベント処理エージェントの例 3
エージェントのプロパティー仕様
エージェント IDA4
エージェント名優先順位決定モジュール
エージェント・タイプルーティング、情報追加
エージェントのコンテキスト-
入力イベントE7
エージェント仕様イベントに相対的優先順位を追加する
優先順位に基づく顧客へのイベントのルーティング-
トラブル・チケット・システムを使用した是正措置の推進-
出力イベントE4, E5, E7, E8
エージェントの注釈-

図 8 に、このシナリオで使用するイベント処理ネットワークの一部 (技術者を派遣するところまで) を図示します。

図 8. 通信サービス・プロバイダーのシナリオの EPN
通信サービス・プロバイダーのシナリオの EPN

概念アーキテクチャー

概念アーキテクチャーは、イベント処理ソリューションに必要となる可能性のある各種コンポーネントを定義している EPN の概念を基礎にしています。これらのコンポーネントの中には、EPN レベルでの 1 つの EPA または相互に接続された一連の EPA に相当するコンポーネントもあれば、イベントのフローにより深く関連した EPN 内のチャネルに相当するコンポーネントもあります。このセクションの後半に記載する図 11 に、概念アーキテクチャーと EPN とのマッピングを示します。

ビジネス・イベント処理をサポートするシステム・アーキテクチャーでは、イベント処理ロジック (規定のビジネス・ロジックに基づいた柔軟なイベント・パターンの検出、新しいイベントの派生、変換、およびプロデューサーからコンシューマーへのイベントのルーティング) は柔軟に定義できる必要があります。これによって、ビジネスは変更に反応して、関連するプロセスを実行し、進行中のプロセスの変更に基づいて影響を与えることができるようになります。さらに、イベント処理の定義は、ビジネスのニーズ (ビジネス・プロセスの変更やポリシーの変更など) に応じて容易に変更でき、迅速にデプロイ可能である必要があります。

イベント処理システムからこのビジネス価値を引き出す方法を理解するためには、イベント処理ネットワークよりさらに細分化したレイヤー、つまりイベント処理システムを構築するために使用できるコンポーネント、そしてコンポーネント間の相互作用に目を向けることが重要です。これらのレイヤーを検討した結果が、私たちがイベント処理システムの概念アーキテクチャーと呼ぶものです。また、イベント・プロデューサーと関連コンポーネント、イベント・コンシューマーと関連コンポーネント、および中間のイベント・バスというイベント駆動型システムの 3 つの典型的なレイヤーに加え、概念アーキテクチャーにはイベントとイベント・フローのセキュリティー、モニタリング、分析、および管理に対応するためのコンポーネントを組み込む必要があります。

最も単純なレベルでは、イベント処理システムに最低限必要な概念コンポーネントは、イベント・プロデューサーからイベントを送信するイベント発行レイヤー、イベント・バス、およびイベント・コンシューマーが使用できるようにイベントを処理するイベント・ハンドラー・レイヤーです。これらの必要最小限のコンポーネントを図 9 に示します。この図には、イベント・プロデューサーとイベント・コンシューマーの例もいくつか示されています。

図 9. 最小限のイベント処理概念アーキテクチャー
最小限のイベント処理概念アーキテクチャー

イベント・エミッター・レイヤー、イベント・バス、およびイベント・ハンドラー (またはレシーバー) レイヤーには、追加の機能が必要になる可能性があります。現実には、イベント・プロデューサーによって生成されたイベントを、すぐにイベント・コンシューマーと共有できるとは限りません。イベント・プロデューサーがイベント処理システム内のイベント・コンシューマーを認識しなくても済むように、プロデューサーとコンシューマーの間にはミドルウェア・レイヤーが必要となるのが通例です。このミドルウェア・レイヤーはイベントに関連した追加のタスクを行うとともに、コンシューマーが対象とするイベント、またはそこから派生したイベントをコンシューマーが受信できるようにします。また、すべてのイベントが所定のフォーマットでプロデューサーによって生成されるわけではないので、このような場合には、イベントを所定の (企業の標準) フォーマットに変換してから、中間レイヤーにパブリッシュする必要があります。場合によっては、通常のイベントの重要性をイベント・プリプロセッサー (ルーター、フィルター) で評価することによって、新しい重要なイベントを生成することもあります。さらに、イベント・プロデューサーがすべてのイベントを発行することはしないと選択する場合もあります。このような場合には、イベント処理エージェントがプロデューサーのドメイン内で未加工のイベントをフィルタリングし、メディエーションを行います。

同じように、コンシューマー側で受信するすべてのイベントがすぐに使用できる形になっているとは限りません。したがって、コンシューマー側で何らかの処理とメディエーションが必要になる場合があります。コンシューマー側で詳細な処理を行う前に、通常のイベントの重要性をイベント・プリプロセッサー (フィルター) によって評価することもあります。また、コンシューマーが受信したイベントの一部を無視すると決めることもあります。このようなパブリッシュ前および受信前のイベント処理の要件を実行するのは、イベント・ハンドラー・レイヤーのイベント処理サービスです。

図 10 に、イベント処理概念アーキテクチャーを構成するすべてのコンポーネントを示します。これらの概念レベルでのコンポーネントを基本セットとして使用すれば、あらゆるイベント処理を実装できるはずです。しかし、各実装でこれらすべてのコンポーネントが必要になるわけではありません。同様に、シナリオによっても、一部のコンポーネントが不要になる場合があります。後ほど、前述のシナリオと概念アーキテクチャーとのマッピングについて説明するときに理解できると思いますが、すべてのコンポーネントが必要というわけではない場合の方が、より一般的です。

図 10. イベント処理概念アーキテクチャー – イベント処理システムで必要になる可能性のあるコンポーネント
イベント処理概念アーキテクチャー – イベント処理システムで必要になる可能性のあるコンポーネント

アーキテクチャーのコンポーネント

概念アーキテクチャーでのイベント・フローは、プロデューサーから始まり、コンシューマーへと進みます。上記の概念アーキテクチャー図に示されているコンポーネントは、この順序でまとめられています。概念モデルでの処理のフローについては、次のセクションで詳しく説明します。実装レベルでは、イベント・コンシューマーがイベントのプロデューサーとなることがよくありますが、概念レベルでは以下に説明するように、コンシューマーとプロデューサーの役割は分離されています。

  • イベント・プロデューサー。イベント・プロデューサーは、重要な出来事が発生すると (または発生しないと)、イベントを発行します。イベント・プロデューサーには、イベントを操作するためのロジックも、何をいつ発行するかを決定するロジックも組み込まれていません。そのため、生成されるイベントが重複していたり、関連性がなかったりする場合もあります。イベント・プロデューサーの典型的な例を以下に示します。
    • イベント・センサー。状況 (発生した事象) を検出して未加工のイベントを生成します。あるいは、データ・ストリームまたはビジネス・フローからイベントを発生させます (温度データの送信はその一例です)。
    • モニターおよびプローブ。システムの可用性および問題に関するイベントを生成します (IT ネットワーク内の障害など)。
    • ビジネス・プロセス。処理の重要なポイント (マイルストーンやチェック・ポイントなど) または、特定のプロセス・タスクに到達した時、もしくは開始された時にイベントを生成します。
    • サービスおよびアプリケーション。処理における重要な時点 (例えばサービスの開始時、完了時、または失敗時) でイベントを生成します。
    • ステート・マシン。状態が変化するとイベントを生成します。
  • イベント・エミッター。イベント・プロデューサーと論理的に (必ずしも物理的にではなく) 関連付けられるイベント・エミッターは、プロデューサーからのイベントをイベント・バスに配信できるように変換およびパッケージ化します。イベント・エミッターには、イベント・インスタンシエーター (イベントのインスタンスを作成する機能)、単一イベント処理サービス (単一のプロデューサーが発行したイベントのフィルタリングとメディエーションや、イベント発生時に使用可能な情報の追加など)、およびイベント・アダプターを組む込むことができます。イベント・インスタンシエーターはプロデューサーからイベントを受け取り、それ以降のイベント処理または配信に使用できるようにするために必要なあらゆる処理 (もしあれば) を行います。このような処理には、イベントの集約、キャッシング、および直列化などが含まれます。イベント・イニシエーターが必要となるのは、イベント・ヘッダーを操作して「セマンティック・メタデータ」をイベント・メッセージ自体に埋め込み、(時刻、日付、機器タイプ、プロセス ID などの情報によって) 自己記述的なイベントにする場合です。イベントがイベント・バスに到達してからではなく、この段階でイベント・エミッターが単一イベント処理を行うことで、最適化することができます。イベント・アダプターは、イベントのフォーマットおよびプロトコル変換を行って、イベント処理ネットワークが受信する形式にすることができます。例えば、イベント・アダプターは、イベント・レコードをイベント・メッセージとしてラッピングし、そのイベント・メッセージをイベント・バスに送信します。
  • イベント・バス。イベント・バスは、イベント・エミッターからイベント (おそらく膨大な量のイベント) を受信し、これらのイベントの結果として、イベント・ハンドラーを介してコンシューマーを呼び出します。イベント・バスの機能には、着信イベントの中から情報量の多いイベントを抽出してより少ない量にする機能も含まれます。イベント・バスのコンポーネントが同じ場所に配置されている必要はありません。イベント・バスについては、次のサブセクションでさらに詳しく説明します。
  • イベント・ハンドラー。このコンポーネントは、イベント・バスからイベントを受信し、イベントへの対処方法を決定して、イベント・コンシューマーが使用できるようにイベントを準備します。イベント・ハンドラーはイベント・アダプターを使用して、イベント・バスからイベント・メッセージを受信し、ラッピングを取り除いてイベント・レコードを取得します。イベント・ハンドラーも単一イベント処理サービスを提供することができます。この場合の単一イベント処理サービスでは、イベント・バスから受信したイベントのフィルタリングおよびメディエーションのためにコンシューマー側の処理を実行します。イベント・ハンドラーはまた、イベントに反応すべきコンシューマーを判断し、イベントから抽出したコンテキストでそのコンシューマーを呼び出すことができます。最終的に、イベント・ハンドラーはコンシューマーへのイベントの配布を管理するために、イベント・オーケストレーション・サービスを提供できます。
  • イベント・コンシューマー。イベント・コンシューマーは、イベントに反応してタスクを実行します。イベントの発生源に関するイベント・コンシューマーの関心は限られており、そのイベントに関するコンテキストと協調してイベントの結果として呼び出されていることを認識するだけです。イベント・コンシューマーの典型的な例を以下に示します。
    • イベント・アクチュエーター。バルブ、スイッチ、アラームの操作といった物理的タスクを実行するために呼び出されます。
    • オペレーター用ダッシュボード。IT システムの振る舞いと影響を受けるサービスに関する情報を表示します。
    • ビジネス・ダッシュボード。ビジネス・プロセスの振る舞いに関する情報を表示します。
    • ビジネス・プロセス。イベントへの応答として開始または再開することができます。
    • サービスおよびアプリケーション。イベントに対する応答として呼び出すことができます。また、外部コンテンツ・マネジメント・システムやイベント・リポジトリーを組み込むことができます。
    • ステート・マシン。イベントに対応してその状態を変更することが可能です。

この概念アーキテクチャーの見方は、各コンポーネントの役割を基にしていますが、アーキテクチャーに参加する特定のコンポーネントが複数の役割を果たせないわけではありません。例えば、イベント・プロデューサーがイベント処理を実行したり、イベント・コンシューマーとして機能したりすることも可能です。特に、パブリッシュ/サブスクライブ式のモデルを使用する場合には、パブリッシュ・サービスとサブスクリプション・サービスだけが必要となります。

概念アーキテクチャーは、任意の参加コンポーネントの中に、さらに別のコンポーネントのネットワークを含めることができるという点で、「ネスト型」と見なすことができます。例えば、イベント・プロデューサーはメインのイベント・バスにイベントを発行しますが、そのイベントの生成プロセスでは、モデル全体の「小型」バージョンが存在する可能性が考えられます。つまり、プロデューサーが最初の単純なイベントと他のイベントとのパターン・マッチングを行うために、イベント・プロデューサー内部に論理的に常駐する「小型」イベント・バスにイベントを発行するということです。

イベント・バスのコンポーネント

プロデューサーからのイベントをコンシューマーに送信するイベント・バスは、イベントを処理およびルーティングするための追加サービスを提供できます。イベント・バスは、関連したイベント・レジストリーを持つことができ、このイベント・レジストリーを使用することで、送信中イベントの (一時的または永続的) トランザクション・ストレージの実行機能を備えることができます。

イベント・バスはローカル・イベント・バスにすることも、エンタープライズ・レベルで実装されることもできますが、受信したイベントはビジネス要件に基づいて処理される必要があります。そのための手段は、単一イベント処理サービスと複合イベント処理サービスです。これらのサービスは、イベント・チャネルで接続されたイベント処理エージェントによって提供されます。

イベント・バスが提供できるサービス (構成要素) を以下に示します。

  • イベント・チャネル。イベント・エミッターからのイベントをイベント・バス、イベント・バスのコンポーネントの間、およびイベント・ハンドラーに送信します。
  • パブリッシュ・サービス。プロデューサーがイベントを適切なチャネルに送信できるようにします。
  • サブスクライブ・サービス。プロデューサーとコンシューマーを動的に登録するためのサービスです。例えば、イベント・ハンドラーが適切なチャネルを見つけて、これらのチャネルからのイベント受信をサブスクライブできるようにします。
  • 通知サービス。イベントが使用可能になると、サブスクライブしたイベント・ハンドラーに通知し、イベントのプッシュおよびプルをサポートします。
  • クエリー・サービス。リポジトリーに対してイベント (およびメタデータ) のクエリーを実行できるようにします。
  • イベント・セキュリティー・サービス。イベントへのアクセスおよび権限を管理します。例えば、イベント・バスに対するイベントの追加および削除の許可、ならびにイベント・コンテンツのプライバシーと非否認を制御します。
  • イベント処理サービス。イベントのフィルタリング、変換、および情報追加を実行します。また、パターン・マッチングとイベントの派生を提供することもできます。イベント処理サービスに、複数のソースからのイベントを処理する複合イベント処理を組み込み、イベント間のパターン・マッチングを長期間実行することも可能です。
  • イベント情報サービス。管理者がチャネルを追加、作成、および編成したり、イベント・タイプのメタデータ (構文とセマンティック) を編成したりできるようにするためのサービスです。また、イベント・メッセージ (つまりアトミック) ベースのパーシスタンスを使用する代わりに、イベント・データをリレーショナル・フォーマットで保管することもできます。
  • イベント・レジストリー。イベント・タイプの分類法、およびイベントの相互関係のオントロジーを提供します。
  • イベント・リポジトリー。中期から長期のイベント・パーシスタンスを目的にイベントを保管します。

イベント・バス内での処理によって提供される必要がある最も重要な機能タイプを以下に示します。

  • 変換。着信イベントを解釈または分割することによって変換する機能です。
  • 情報追加。イベントのコンテンツに、複数の考えられるソースから参照データを追加する機能です。
  • 検証。要求される基準に照らし合わせて検証する機能です。
  • パターン検出。実パターンおよび遡及的パターン (重要なビジネス状況を明らかにする、おそらく複数のイベントの組み合わせ) を認識する機能です。
  • フィルタリング。イベントのコンテンツ (つまり、イベント発生時に生成されたメッセージが伝搬する情報) を基にしてイベントをフィルタリングするステートレスな機能です。
  • 集約。必要に応じてイベントをグループ化する機能です。
  • ルーティング。さまざまな取り得るルーティング・パターン (事前設定されたルート、カレンダー・ベース、サブスクリプション、または「インテリジェント」なルーティング決定など) を基に、イベントを目的地にルーティングする機能です。

概念アーキテクチャーには、イベントとイベント・メタデータのライフサイクルを管理、制御するために、イベント・ガバナンスおよびセキュリティー・サービスも組み込まれます。また、イベント・インフラストラクチャーでの障害を通知し、イベント・フローに関する統計を収集して表示するためには、管理を主な目的とするイベントのモニタリングおよび分析インフラストラチャーも必要となります。これらの機能はイベント・フロー全体に及ぶ必要があるので、概念モデル図 (図 11) の右側に示されています。

したがって、概念アーキテクチャーでは、イベントはイベント・プロデューサーからイベント・バスに発行され、場合によってはイベント・バスで処理されてから、最終的にイベント・コンシューマーで使用されることになります。コンシューマーは、イベントの結果として別のイベントを生成する場合もあれば、別のコンポーネントを使用した他の手段で対応し、そのコンポーネント自体が結果的にイベントを生成する場合もあります。

図 11 に、概念アーキテクチャーが、どのように EPN の概念に基づいているかを示す 1 つの例として、EPA (または相互に接続された EPA 一式) に相当するコンポーネントと、イベント・チャネル・サービスを提供するその他のコンポーネントを示します。

図 11. イベント処理概念アーキテクチャーが使用する EPN
イベント処理概念アーキテクチャーが使用する EPN の例

概念アーキテクチャーでの処理のフロー

このサブセクションでは、概念モデルの動作を説明します。検討対象となる 3 つのフェーズを以下に示します。

  • イベント発行フェーズ
  • イベント処理フェーズ
  • イベント使用フェーズ

これは単一の一貫した処理フローではありません。3 つのフェーズの結合度は非常に低く、特に複合イベント処理が関わってくると顕著になり、この場合、3 つのフェーズはまったく異なる期間に発生し、発行されたイベントと使用されるイベントの間には、原因と影響の関係しかありません。

具体的な例で説明するため、このセクションでは「イベント処理のシナリオの概要」と「イベント処理ネットワークのシナリオ」セクションで詳しく説明したシナリオを参照します。

イベント発行フェーズ

このフェーズに主に関与する概念アーキテクチャーのコンポーネントは、イベント・エミッターのコンポーネントです。これらのコンポーネントがイベント発行において果たす役割はかなり技術的なもので、それは、イベント・プロデューサーとイベント・バスとの間に技術的接続性のレイヤーを提供するという役割です。その一方、このレイヤーにはビジネス向けのイベント処理ロジックやローカル・イベント処理エージェントを実装できることから、ビジネス指向の役割を果たすこともあります。

技術的観点

重要な意味を持つ可能性のあるビジネス・イベントが発生すると、イベント・プロデューサーはローカル・イベント・エミッター・レイヤーを使用してイベント・メッセージをイベント・バスに送信します。イベント・インスタンシエーター・サブレイヤーは技術コンポーネントとして、この特定のビジネス状況を検出し、必要な情報をすべて収集します。そして、ローカル・イベント処理サービスがその情報を処理してイベント・メッセージを作成します。例えば、イベント・レジストリー内でパブリッシュされる汎用フォーマットに準拠したフォーマットにするなどです。作成されたイベント・メッセージは、次にイベント・アダプター・サブレイヤーによってイベント・バスに送信されます。イベント・アダプター・サブレイヤーの役割は、イベント・メッセージをイベント・バスがサポートするトランスポート・プロトコルに準拠させることです。

例: ここでは車両管理のシナリオでの配送システムを例に取り上げ、特にイベント・プロバイダーとしての配車サブシステムに注目します。この配車サブシステムは、データをリレーショナル・データベースに保管するビジネス・アプリケーションであるとします。このアプリケーションでは、特定の配送を担当するドライバーまたは車両が変更されるたびに、「配送変更」というビジネス・イベントを発行します。配送データを保管するテーブルにはイベント・インスタンシエーターがトリガーとして実装され、テーブルに保管された配送のインスタンスが更新されるたびに、このトリガーが起動されます。そして、トリガーが実装するローカル・イベント処理サービスによって、配送インスタンスの更新が、その配送を担当する車両またはドライバーの変更に関連しているかどうかが検証されます。このテストが成功すると、トリガー・ロジックが必要なすべての情報 (ドライバー 1 の ID、車両 1 の ID、ドライバー 2 の ID、車両 2 の ID、発送者 ID、受領者 ID) を収集し、配送変更専用のイベント・テーブルに「配送変更」イベント・メッセージのインスタンスを作成します。イベント・アダプター・サブレイヤーは、JDBC アダプターを使用して実装され、このテーブルのポーリングと、イベント・バス・レベルでの外部イベント処理ロジックの開始を担当します。

ビジネス上の観点

さらに高度な実装になると、イベント・エミッター・レイヤーがより高度なプロデューサー側のイベント検出パターンをサポートして、ローカル・イベント処理エージェントを実装できるようになります。貴重なビジネス・イベントの発生を特徴づける単一のイベントのメッセージをイベント・バスで送信するために、基本イベントのフィルタリング、集約、情報追加、さらには検証までをローカル・イベント処理サブレイヤーで対処することができます。

例: 公衆衛生警報のシナリオで、「病院」がイベント・プロバイダーとして「潜在的エピデミック・アウトブレーク警報」のイベントを生成するとします。病院情報システムには、多くの患者の状況が報告されます。報告された状況の中には、特定の感染につながるため、詳しくモニターする必要があるものがあります。このような状況の発生は、基本イベントです。潜在的エピデミック・アウトブレークを検出するには、病院内部で一定期間、多数の患者に影響を及ぼしている同様の基本イベントを突き合わせる必要があります。したがって、イベント・インスタンシエーターとローカル・イベント処理サービスは、以下を担当するイベント処理エージェントを実装します。

  • 基本イベントの発生源および性質の検証
  • 基本イベント相互の関連付け
  • イベント処理ネットワークの関係者が期待する「正規化された潜在的エピデミック・アウトブレーク」イベントの生成

イベント処理フェーズ

このフェーズはイベント・バスで行われます。処理するイベントの数によって処理のフローも、関与するイベント・バスのコンポーネントも異なってきます。ここでは、2 つの異なる振る舞いを説明します。1 つは単一のイベントを処理する場合、もう 1 つは複数のイベントを処理する場合です。

1 つの着信イベントを処理する場合

基本的な処理パターンの 1 つとして考えられるのは、パブリッシュ/サブスクライブのパターンです。イベント・バス・レベルでイベント・メッセージを受信すると、そのメッセージはパブリッシュ・サービス・サブレイヤーによって代行受信され、イベント・バス管理者が構成したさまざまなチャネルに配信されます。これらのチャネルは、イベント・コンシューマーまたはサブスクライブ・サービス・コンポーネントが使用できるようにイベント・レジストリーにパブリッシュされます。イベント・コンシューマーはイベント・レジストリーにアクセスして、関心のあるイベント・タイプに関連付けられたチャネルの情報を取得します。これらの該当するチャネルを直接リッスンすることによって、イベント・コンシューマーはイベント・メッセージを受信します。

例: 車両管理のシナリオでの配送変更イベントと、そのコンシューマーである配送管理ダッシュボードを例に検討してみましょう。イベント・バスによって配送変更イベントが検出されるたびに、関連するイベント・メッセージが特定のイベント・チャネルで使用可能になります。配送管理ダッシュボードはこのチャネルをリッスンし、新しいイベント・メッセージが受信されると、ローカル・イベント・ハンドラーを使用して、そのイベント・メッセージを処理します (「イベント使用フェーズ」を参照)。

単一のインバウンド・イベントが、そのペイロードとそれにより表されるサブスクライブ要求に応じて、フォーマットの異なる複数のアウトバウンド・イベントを生成する場合も考えられます。イベント・コンシューマーは、サブスクリプト・サービスを使用して、特定のイベント・タイプに関心があることを提示することができます。また、関連するイベントの通知方法を指定するために、追加パラメーターを設定することもできます。追加パラメーターの例を以下に示します (すべてのパラメーターが網羅されているわけではありません)。

  • 通知で受け取るイベント・メッセージのフォーマット
  • メッセージを受信するために使用するチャネル
  • イベントのフィルタリング基準

イベント・バスでイベント・メッセージを受信すると、パブリッシュ・サービス・サブレイヤーがイベント・タイプを得るために個々のサブスクリプト・リクエストを処理します。イベント・メッセージのメディエーションのために必要なイベント処理サービス (主に、フィルタリング、情報追加、および変換のためのサービス) が行われた後、通知サービスが、処理済みのイベント・メッセージをイベント・コンシューマーへ、要求されたチャネルを使用してプッシュします。

例: 公衆衛生警報のシナリオで、「一般開業医」がイベント・コンシューマーとして、「潜在的エピデミック・アウトブレーク警報」イベントを受信するとします。健康警報イベントをサブスクライブしている一般開業医は、彼の専門分野で潜在的エピデミック・アウトブレーク警報が起動された場合には、常に電子メールで通知を受け、関連する病気についての追加情報を入手したいと思っています。この場合、イベント・バスのサブスクライブ・サービスは、この一般開業医が有効な警報の一覧をブラウズし、地理的な位置でフィルタリングし、そして関心のある追加情報と希望の配信チャネルを選択できるようにする必要があります。イベント・バスはこれらのパラメーターを使用して、送信されてくる潜在的エピデミック・アウトブレーク警報のイベントをフィルタリングし、要求された追加情報でイベントを増補し、さらにイベントを電子メールとして通知サービスでコンシューマーにプッシュできるようにフォーマット設定します。

複数の着信イベントを処理する場合

複数の着信イベントがある場合は、おそらくタイプがさまざまに異なり、一定期間に複数のソースから発行される複数のイベント (ここではイベント・セットと呼びます) が検討されます。重要なビジネス状況は、イベント・プロデューサー・レベルでは検出されず、イベント・バス内でイベント・セットに含まれる複数のイベントを突き合わせることによって検出されます。そのために、イベント・バスは 1 つ以上のイベント処理エージェントを実装し、イベント・バス管理者が (おそらくサブスクリプト・サービスまたはイベント情報管理サービスを使用して) 1 つ以上のパターンを事前に設定してイベント・レジストリーに保管することになります。これらのパターンには、因果関係、時間、場所、その他多くの次元を含めることができます。イベントを受信すると、イベント・クエリー・サービスを使用してイベント・レジストリー内をチェックし、有効なパターン・マッチング・ルールが関連付けられたイベント・セットに属するイベントであるかどうかを調べます。ルールに関連付けられている場合には、イベント処理サービス・サブレイヤーがルールを受信イベントに適用します。

この場合のイベント・バスは、イベント・セットのイベントを少なくとも 1 つ受信したことから、同じタイプのイベントを待機中の状態になるはずです。もしくは、イベント・セットのイベントを 1 つも受信していなければ、新しい処理フローが開始される可能性があります。

このパターン・マッチング・ルールの処理によって生成されたイベントは、以下のように処理することができます。

  • 関連チャネルに直接パブリッシュする
  • メディエーションを行ってから、関連チャネルを介して該当するサブスクライバーに送信する
  • このイベント・タイプが関連付けられた別の処理ルールを担当する別の EPA に送信する

これは再帰的な振る舞いになる可能性があり、このパターン・マッチングが連鎖した処理がイベント処理フローとなります。期間がイベント・セットの顕著な特性となることは珍しくありません。したがって、イベント・バスでのイベント処理サービスの実装を検討する際には、時間も重要な要因です。

特に複合イベント処理の場合には、イベント・リポジトリーがイベント処理で重要な役割を果たすことがあります。着信イベント、生成されたイベント、あるいは処理済みのイベントのいずれにしても、イベント・フローで処理されたイベントはイベント・リポジトリーに記録されます。

  • 第一に、イベント・リポジトリーはモニタリングに非常に役立ちます。イベント・リポジトリーにより、例えば特定の結果をもたらしたのが、どの着信イベントの組み合わせであるのか、またはどのイベント処理エージェントのシーケンスであるのかを突き止めることができます。
  • 第二に、イベント・セットは長期間にわたって検討されることがあるため、関連するイベントを永続化しなければならない場合があります。

例: 車両管理のシナリオでの「ドライバーの運転時間超過」エージェントと、これに関連する「ドライバーの勤務開始」および「ドライバーの勤務終了」という 2 つのイベントを考えてみてください。このイベント・セットを特徴づけるのは、この 2 つのイベント・タイプと 8 時間を超える時間です。イベント・バス・レベルで特定のドライバー ID に対応する「ドライバーの勤務開始」イベントが受信されるたびに、EPA が開始され、このドライバー ID に対応する「ドライバーの勤務終了」イベントを待ちます。前者のイベントから 8 時間経過しても後者のイベントが発生しない場合、その結果として「ドライバーの運転時間超過」イベントが発行されるはずです。

公衆衛生警報のシナリオで考えると、「潜在的エピデミック・アウトブレーク警報」イベントの、イベント・コンシューマーは「潜在的エピデミック・アウトブレーク警報のマッチング」エージェントです。潜在的エピデミック・アウトブレーク警報のイベント・タイプと 2 週間という期間が、イベント・セットを特徴づけます。イベント・バスでこのタイプのイベント・メッセージを受信するたびに、イベントはエージェントのパターン・マッチング・ロジックを実装する EPA に転送されます。その後、2 週間以内に潜在的エピデミック・アウトブレーク警報を 10 個の異なるソースから受信した場合、パンデミック・アウトブレーク警報が発動されることになります。

イベント使用フェーズ

このフェーズは主に、イベント・コンシューマーに関連付けられたイベント・ハンドラー・レイヤーで行われます。イベント発行フェーズと同様に、このレイヤーは技術的役割を果たすこともあれば、よりビジネス指向の役割を果たすこともあります。

技術的観点

このフェーズでは、イベント・コンシューマーがイベント・バスからイベント・メッセージを受信し、受信したイベント・メッセージを処理しますが、この処理はローカル・イベント・ハンドラー・レイヤーに依存しています。イベント・メッセージを受信し、イベント・バスでサポートされるトランスポート・プロトコルとインターフェースを取るのが、イベント・アダプター・サブレイヤーの役目です。イベント・メッセージの事前処理は、ローカル・イベント処理サブレイヤーに実装することができます。事前処理の例には、イベント・コンシューマーに固有の入力フォーマットに準拠するために、イベント・メッセージのペイロードに技術的な準拠処理を加えるなどがあります。特定のイベント・メッセージの受信に関連付けられたアクションを実装するビジネス・ロジックは、イベント・オーケストレーション・サブレイヤーが識別します。このイベント・オーケストレーション・サブレイヤーは、オプションで変換したイベント・メッセージのペイロードを入力パラメーターとして、ロジックの実行を開始します。

例: 車両管理のシナリオの配送変更イベントと、そのコンシューマーである配送管理ダッシュボードを例にすると、配送管理ダッシュボードはポータルとして実装されます。新しい配送変更イベント・メッセージは、イベント・バスとのインターフェースである WebSphere MQ メッセージ・キュー接続 (ローカル・イベント・アダプター) を介してローカル・イベント・ハンドラーで受信されます。ポートレットとして実装されたローカル・イベント処理ロジックがイベントのペイロードを取得すると、指標のいくつかを更新するため、そしてエンド・ユーザーに表示するグラフを変更するためにペイロードを処理します。

ビジネス上の観点

より高度な実装では、イベント・ハンドラー・レイヤーは、複数の基本イベント・メッセージの収束点として振る舞うことができます。これらの基本イベント・メッセージは、ローカル・イベント処理サブレイヤーで突き合わせられます。これにより、イベント・コンシューマーでのアクションと関連付けられたローカルなイベントが生成されます。生成されたイベントはイベント・オーケストレーション・サブレイヤーに送信され、関連するビジネス・ロジックをイベント・コンシューマーで開始します。その一方、単一のイベント・メッセージが複数のローカル処理を発生させることもあります。イベント・コンシューマー側の多くの関係者はそれぞれに異なる形でイベントに関心を持つからです。

例: 公衆衛生警報のシナリオで、「病院」がイベント・コンシューマーとして「パンデミック・アウトブレーク警報」イベントを使用するとします。このイベントが病院に通知されると、極めて危機的な状況が提起されるため、例えば以下のような複数のローカル処理が並行してこのイベントを処理することになります。

  • ニュース・チャネルを介して情報を病院のイントラネット・ポータルに直接プッシュする
  • SMS メッセージで主要な専門家を呼び戻す

緊急健康状況を管理する特定のプロセスを開始するために、イベント・メッセージがロジスティックス・アプリケーションに送信される可能性があります。


シナリオと概念モデルのマッピング

このセクションではイベント処理のシナリオに戻り、それぞれのシナリオが概念アーキテクチャーのコンポーネントとどのようにマッピングされるのかについて説明します。

車両管理のシナリオ

さまざまなアクター (イベント・プロデューサーとイベント・コンシューマー)、イベント、およびイベント処理エージェントは以前のセクションですでに定義されているので、ここでは車両管理のシナリオをイベント処理の概念アーキテクチャーにマッピングします (図 12 を参照)。イベント・プロデューサーとイベント・コンシューマーとの関連は至って明快です。A4 (ルーティング・エージェント) を除くすべてのエージェントが、イベント・バス内のイベント処理コンポーネントにマッピングされます。ドライバー報告システムが生成する 2 つのイベント、E1 と E3 には特殊な処理が必要ないので、エージェント A1 と A2 がそのまま処理できます。また、E5 もすべてのコンシューマーがそのまま使用できるため、概念モデルのイベント・エミッターおよびイベント・ハンドラーの部分にマッピングされるものはありません。

図 12. 車両管理のシナリオでの概念アーキテクチャーのコンポーネント
車両管理のシナリオでの概念アーキテクチャーのコンポーネント

車両管理のシナリオでは、イベント処理が重要となります。それは、イベント処理によって、ドライバーの場所、運転時間、および配送経路に関する異なる情報のすべてにタイミング良く対応することが可能になるからです。また、イベント処理により、許容運転時間、配送変更の処理などに関する規則も簡単に変更できるようになります。

公衆衛生警報のシナリオ

さまざまなアクター (イベント・プロデューサーとイベント・コンシューマー)、イベント、およびイベント処理エージェントはすでに定義済みですので、ここでは公衆衛生警報のシナリオをイベント処理の概念アーキテクチャーにマッピングします (図 13 を参照)。イベント・プロデューサーとイベント・コンシューマーとの関連は明らかです。イベント処理エージェントとイベント・エミッターはある程度マッピングされており、主要な処理はイベント・バス内の特定のコンポーネントにリンクされています。概念モデルのイベント・ハンドラーの部分へのマッピングはありません。すでに詳しく説明したこのシナリオの局面には、イベント・ハンドラーは必要ないためです。

図 13. 公衆衛生警報のシナリオでの概念アーキテクチャーのコンポーネント
公衆衛生警報のシナリオでの概念アーキテクチャーのコンポーネント

これでこのシナリオについての説明はすべて終了したので、公衆衛生警報の例を使用してイベント処理が重要となる理由を考えてみましょう。

このシナリオは公衆衛生に関連するため、時間が重要な要因となるとともに、イベントの履歴、イベント・プロデューサーとイベント・コンシューマーの数も重要となります。この 3 つの主要な要因を理解することが肝心であり、これらの要因は、以下に示すようにイベント処理システムで明確に示されています。

  • イベント・プロデューサーとイベント・コンシューマーは疎結合となります。イベントの発生源は重要ではないからです (ただし、イベント・コンシューマーがイベントの性質とソースを識別できることが前提となります)。
  • イベントが検出されると同時にイベント処理を開始し、エピデミック・アウトブレークやパンデミック・アウトブレークが識別されたら即時に通知することが非常に重要な要素となります。
  • イベント処理システムはイベント・コンシューマー側のビジネス・プロセスには依存しません。したがって、多数の潜在的イベント・コンシューマーに価値を提供する、極めて柔軟かつ動的なイベント処理ネットワークを実現できます。

通信サービス・プロバイダーのシナリオ

図 14 に、通信サービス・プロバイダーのシナリオとイベント処理概念アーキテクチャーのコンポーネントとのマッピングを示します。

図 14. 通信サービス・プロバイダーのシナリオでの概念アーキテクチャーのコンポーネント
通信サービス・プロバイダーのシナリオでの概念アーキテクチャーのコンポーネント

まとめ

この記事で紹介したビジネス・イベント処理の概念モデルは、イベント処理ネットワークの概念に基づく概念アーキテクチャーから構成されます。この概念アーキテクチャーが示しているのは、イベント・プロデューサーが生成したイベントをイベント・コンシューマーが使用できるように準備し、処理するために、中間のイベント・バスで必要に応じてイベントのフィルタリング、情報追加、フォーマット設定、ルーティング、集約、または分割などを行うサービスを提供する方法です。また、この概念アーキテクチャーでは、プロデューサー側とコンシューマー側で必要になる可能性のある機能 (単一イベント処理機能やイベント・アダプターなど) を掘り下げるとともに、イベント・バスで必要となる可能性があるさまざまなサービスも示しています。この概念アーキテクチャーの目的は、イベント処理の実装を実現するために必要となる可能性のある、あらゆるコンポーネントを識別することですが、特定の実装またはシナリオには、そのコンポーネントの一部だけが必要になります。

この記事では、イベント駆動型処理によってビジネスに価値がもたらされることを示す多数のシナリオを紹介し、これらのシナリオを概念モデル (イベント処理ネットワークおよび概念アーキテクチャー) にマッピングして、この概念モデルを現実のさまざまな状況にどのように適用することができるかを明らかにしました。各シナリオの内容を説明し、そのシナリオにイベント処理が重要となる理由を解説するとともに、シナリオを実現するために必要なプロデューサー、コンシューマー、イベント、およびイベント処理を列挙し、実際に概念アーキテクチャーにマッピングすることでわかりやすく示しました。

ビジネス・イベント処理がもたらすビジネスの価値と機会がより広く認識されつつあるなか、ビジネス・イベント処理ソリューションの実装に使用する、論理的アーキテクチャーと物理的アーキテクチャーの基礎となる、概念モデルと概念アーキテクチャーを持つことが重要になるでしょう。


謝辞

概念モデルおよびこの記事に多大な協力をいただいた、Christopher Ahrendt、Kyle Brown、Koteswara R Chejarla、Norman Cohen、John Dinger、Greg Flurry、Paul Giangarra、Kevin Hall、Robert Heuchert、Beth Hutchison、David H Janson、Jojo Joseph、Chung-Sheng Li、Rahul Narain、Peter Niblett、Dave Russell、Robert Sawyer、Boris Shulman、Michael Spicer、Bobby Woolf の各氏に、著者一同から感謝の意を表します。

参考文献

学ぶために

製品や技術を入手するために

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=SOA and web services
ArticleID=607130
ArticleTitle=イベント処理システムの概念モデル
publish-date=02092010