イベント駆動型アーキテクチャ（イベントくどうがたアーキテクチャ、、EDA）は、イベントの生成・検知・消費と、それによって引き起こされる応答を軸にシステムの挙動を組み立てるソフトウェアの枠組みである。ここでイベントとは、システムのハードウェアまたはソフトウェアにとって意味を持つ、識別可能な出来事を指す。イベントを生み出す生成者と、それを受け取る消費者から構成される。
概要 TechTargetは、生成者はイベントが起きたことだけを知っており、消費者はイベントが起きたことを知る必要のある実体で、そのイベントの処理に関与する場合と単に影響を受ける場合とがあると説明している。同媒体によれば、消費者は通常ミドルウェアのイベントマネージャに購読を登録し、マネージャは生成者から通知を受け取ると登録済みのすべての消費者にそのイベントを転送する。
Computerworldが伝えるガートナーの説明では、イベント駆動型アーキテクチャにおいてメッセージは通常、複数の宛先への同時配送を可能にする出版-購読型モデル（パブリッシュ/サブスクライブ）の方式で送られる。Eugsterらは2003年の調査論文で、出版-購読の通信では、購読者があるイベントまたはイベントのパターンに対する関心を登録し、以後、出版者が生成したイベントを非同期に通知されるとし、この方式が大規模なアプリケーションにおける分散した相互作用の疎結合な性質に適合しているとしている。同論文は、多くの変種に共通する特徴として、通信する実体が時間・空間・同期という3つの次元で完全に分離されることを挙げている。
主な要素 Cloud Native Computing Foundation（CNCF）のCloudEvents仕様は、イベントデータの形式を定める仕様であり、次の用語を定めている。
イベント（event） 出来事（occurrence）とその文脈を表すデータレコード。出来事とは、ソフトウェアシステムの稼働中に起きた事実（状態の変化やタイマーの満了など）を記録したものを指す。イベントは生成者から関心を持つ消費者へ転送（ルーティング）されるが、イベント自体は特定の宛先を指定しない。 生成者（producer）と発生源（source） 生成者は、イベント（CloudEvent）を記述するデータ構造を作るインスタンス・プロセス・デバイスである。発生源は出来事が起きた文脈を指し、分散システムでは1つの発生源が複数の生成者からなることがある。 消費者（consumer） イベントを受け取って作用するもの。文脈とデータを使って何らかのロジックを実行し、それが新たな出来事の発生につながることがある。 仲介者（intermediary） 次の受信者へ転送する目的でイベントを含むメッセージを受け取るもの。
パターンと処理の様式 マーティン・ファウラー（Martin Fowler）は2017年、人が「イベント」と言うとき実際には異なるものを指しているとし、同僚とともに切り分けたパターンのうち主なものとして、次を含む4つを挙げた。
イベント通知（event notification） システムが自らの担当領域（ドメイン）の変化を他のシステムに知らせるためにイベントメッセージを送る形。ファウラーは、発信元は応答をあまり気にしないとし、この形がシステム間の結合度が低いことを含意するとしている。 イベントによる状態転送（event-carried state transfer） 受信側が以後の処理のために発信元へ問い合わせなくてよいよう、変わったデータの詳細をイベントに載せる形。ファウラーは、データの複製が多く生じる一方、発信元が利用できなくなっても受信側が機能でき、待ち時間が下がるとしている。 イベントソーシング（event sourcing） 状態を変えるたびにその変化をイベントとして記録し、以後いつでもイベントを再処理して状態を再構築できるようにする形。ファウラーは、イベントストアが正となる情報源となり、システムの状態はそこから導かれるとしている。
TechTargetは、イベントストリーム処理（event stream processing、ESP）を、デバイスのデータの連続的なストリームを処理し、リアルタイムにそれに対応するためのプログラミング技法とし、ESPがイベント駆動型アーキテクチャの実装を支えるとしている。同媒体は複合イベント処理（complex event processing、CEP）を、データのストリームを追跡・分析してイベントに関するリアルタイムの情報を得る方法とし、複数のデータストリームを処理して一見無関係なイベントの間の関連を見いだすものと説明している。
歴史 TechTargetは、複合イベント処理がスタンフォード大学のデビッド・ラッカム（David Luckham）の仕事に始まるとしている。同媒体によれば、ラッカムは1990年代にイベントによって通信する分散プログラミング言語に取り組み、一連の低位のイベントから相関付けられた高位のイベントを表すために「複合イベント」（complex events）の語を作った。
Computerworldは2003年5月、ガートナーのアナリストであるロイ・シュルテ（Roy Schulte）が同社の会議で、それまで一部の高度な開発者しか試みてこなかった種類の複合イベント処理のために、4年後には「並みの人々（mere mortals）」もイベント駆動型アーキテクチャを採り入れ始めると予測したと報じた。同記事は、この手法が、再利用可能な業務機能である「サービス」を組み合わせてアプリケーションを構築するサービス指向アーキテクチャ（SOA）と補完的であるとし、シュルテは、サービスをつなぐことは線形で予測可能な順序で起きるのに対し、イベント駆動型アーキテクチャでは予測しにくい複数の非同期のイベントが並行して起き、単一の動作を引き起こし得ると述べたと伝えている。
CNCFによれば、イベントデータの形式を標準化するCloudEventsは、2018年5月15日に同財団に受理され、2019年10月24日に成熟度がインキュベーティング（Incubating）に、2024年1月25日に卒業（Graduated）に移行した。同仕様は自らを、複数のサービス・プラットフォーム・システムの間で相互運用できるよう、共通の形式でイベントデータを記述するためのものとし、イベントの記述に共通の方法がないことが、SDK・イベントルーター・トレーシングのシステムといった道具や基盤がイベントデータの配送を助ける可能性を制限しているとしている。
監視上の特性 ファウラーは、イベント通知によって疎結合なシステムを作れる一方、複数のイベント通知にまたがる論理的な流れがある場合、その流れはプログラムの記述に明示されないため見て取りにくく、把握する方法が稼働中のシステムの監視に限られることが多いとしている。
関連項目 イベント駆動型プログラミング メッセージキュー マイクロサービス 分散トレーシング オブザーバビリティ
脚注
外部リンク CloudEvents