イベント・ドリブンのアーキテクチャーとは？

これにより、チームはシステム・イベント（基本的にはシステム内で発生した変更やアクション）を特定し、リアルタイム（またはほぼリアルタイム）で対応および対処できます。

クラウドネイティブ環境全体にわたるEDAの多さは、データレイクのようなリポジトリに静的データを蓄積することに焦点を当てた従来のコンピューティング・アーキテクチャー（サービス指向アーキテクチャーなど）から、アーキテクチャーを通過するデータを追跡する動的なアプローチへの大幅な移行を表しています。イベント駆動型システムではデータは依然として価値がありますが、EDAでは、イベントの価値が時間の経過とともに低下する可能性があることを認識し、イベントへのタイムリーな対応を重視します。

イベント駆動型アーキテクチャーでは、イベント・プロデューサー（マイクロサービス、API 、IoTデバイスなど）がイベント・コンシューマーにリアルタイムのイベント通知を送信し、特定の処理ルーチンをアクティブ化します。たとえば、Netflixが新しいオリジナル・シリーズをリリースすると、複数のEDAサービスがリリース通知を待機し、その通知を受けて、一連のアップデートがトリガーされてユーザーに通知されます。

イベント駆動型アーキテクチャーの主な利点の1つは、フロントエンド・コンポーネントとバックエンド・コンポーネント間の分離されていることです。これにより、システム同士が互いの情報を知ることなく情報を共有できます。プロデューサーは、どのコンシューマーがイベントを受信するかを知らずにイベントを送信できます。一方コンシューマーは、プロデューサーにリクエストを送信せずにイベントを受信できます。つまり、EDAを使用することでシステムが独立して動作し、イベントを非同期に処理できるようになります。

現代の先進的な企業は膨大なデジタル・フットプリントを有しており、イベント駆動型システムのリアルタイム機能により、企業はアイドル状態になることなく運用の準備を整え、イベントのブロードキャストに迅速に対応できます。このように、EDAは、サプライチェーンの最適化から品質問題のプロアクティブな特定まで、企業がさまざまな組織プロセスを自動化し、最終的にはトップラインとボトムラインの両方を改善するのに役立ちます。

イベント・ストリーミングは、システムや環境でのあらゆる事象または変化を記録する基本的なデータ構造である、「イベント」と呼ばれるデータ・レコードの無制限で連続的なリアルタイム・フローを中心に展開します。このような変更の例としては、ユーザーがEコマース・サイトでショッピングカートに商品を追加したり、パスワードのリセットやアプリケーションの状態変更を要求したりすることが挙げられます。これは、基本的にシステム内のすべてのデータ・ポイントを指す用語です。したがって、「ストリーム」（データ・ストリームまたはストリーミング・データとも呼ばれる）は、これらのイベントの継続的な配信を指します。

各イベントは通常、イベントまたはそれに関連するエンティティを識別するキー、イベントの実際のデータを保持する値、イベントが発生または記録された日時を示すタイムスタンプで構成され、イベント・ソース、スキーマ・バージョン、またはその他の属性に関するメタデータが含まれることもあります。メタデータは、状態データ（購入商品、価格、配送先住所など）を伝達したり、識別子（発送通知）として機能したりします。

特殊なストリーム処理エンジンの助けを借りて、イベントはストリーム内でいくつかの異なるプロセスを経ます。「集計」では、平均、合計、標準偏差などのデータ計算を実行します。「取り込み」では、ストリーミング・データをデータベースに追加します。分析処理では、ストリーミング・データのパターンを使用して将来のイベントを予測し、エンリッチメント処理では、データ・ポイントと他のデータ・ソースを組み合わせてコンテキストを提供し、意味を生み出します。

イベントは多くの場合、事業運営やユーザー・ナビゲーション・プロセスに関連付けられており、通常は別のアクション、プロセス、または一連のイベントをトリガーします。一例として、オンライン・バンキングを取り上げます。 ユーザーが「送金」をクリックしてある銀行口座から別の銀行口座に送金すると、その資金が送金者の口座から引き出されて受信者の口座に追加され、EメールまたはSMS通知が一方（または両方）に送信されます。また、必要に応じて、セキュリティーおよび不正防止プロトコルが導入されます。

イベントに加え、EDAは3つの主要なコンポーネントに依拠して、アーキテクチャー内でイベント・データを動かします。

• イベント・プロデューサー（またはパブリッシャー）：プロデューサーはイベントの情報源としての役割を果たします。イベントを生成し、システムの他の部分に情報を送信します。プロデューサーは、ユーザー・インターフェース、センサー、サービス、またはシステムの他の部分にとって重要な状態変化を検出または生成できるその他のシステムとして機能する場合があります。プロデューサーはイベントを作成する役割を担いますが、イベントの処理機能はありません。

• イベント・コンシューマー（またはサブスクライバー）：コンシューマーはEDAのイベント処理タスクを担います。彼らはイベント・チャネルを視聴し、関心のあるイベントが公開されると反応します。この反応は、データベースの更新、ダウンストリーム・プロセスの開始、または単に情報のロギングなど、さまざまな形をとる可能性があります。

• イベント・ルーター（またはイベント・オーケストレーター）：ルーターまたはオーケストレーターは、フロントエンドのイベント・プロデューサーとバックエンドのイベント・コンシューマーを切り離すブローカーです。イベントが配信される経路として機能し、エンティティ間の直接接続を必要とせずに確実にデータを送信します。ルーターは、従来のコンポーネント（SaaSなどのメッセージ指向ミドルウェア）に基づいており、さまざまなメッセージング・システム（ メッセージ・キュー、モデルの発行/購読、イベント・ストリームなど）で役立ちます。

EDAでは、イベント駆動型アプリケーションがプロデューサーまたはコンシューマー（場合によっては両方）として機能します。

アプリまたはサービスが、別のアプリまたはサービスが認識する必要があると思われるアクションを実行すると、そのアクションまたは変更の記録として新規イベントが公開されます。そこで、別のサービスがその新規イベントを使用して処理し、他のアクションを実行できるようになります。

次に、イベント・プロデューサーは、イベントをメッセージ形式でブローカーまたは別のタイプのイベント・ルーターに送信し、他のイベントに対するイベントの時系列を維持します。イベント・コンシューマーは、リアルタイム（発生時）または後続する関連インスタンスでメッセージを取り込み、メッセージを処理して、独自のアクション、ワークフロー、またはイベントをトリガーします。

シンプルな例として、銀行サービスが「入金」イベントを送信する場合、別の銀行サービスが該当のイベントを使用して顧客の取引明細書に入金情報を書き込むことで応答します。

ただし、イベント駆動型の統合では、顧客がEコマース・サイトで商品をクリックすると、システムが即座に他の顧客の購入情報に基づいて商品の推奨事項を生成するなど、膨大な量のデータの複雑な分析に基づいてリアルタイムの応答をトリガーすることもできます。

イベント駆動型アーキテクチャーは、クラウドネイティブ・アプリケーションの可能性を最大限に引き出し、リアルタイム分析などの強力なアプリ・テクノロジーを実現します。全体として、あるアプリが別のアプリに特定の情報を要求し、次のタスクに進む前に応答を待つ必要がある従来の「要求/応答」型のアーキテクチャーに取って代わるものです。

ただし、「EDA」とは複数のアーキテクチャー・パターンを含む用語で、そのすべてがそれぞれ異なる目的に役立ちます。

オブジェクト間の1対多の依存関係と、パブリッシャー（イベント・プロデューサー）とコンシューマー間の分離された非同期関係によって定義されるpub/subモデルでは、パブリッシャーはサブスクライバーについて知る必要はありません。イベントを共有イベント・チャネルに公開するだけで、サブスクライバーはそのイベントをリアルタイムで個別に視聴し、反応することができます。

通常、メッセージ・ブローカー（ルーター）は、パブリッシャーとサブスクライバー間のイベント・メッセージの送信を処理します。ブローカーは各イベント・メッセージを受信し、（必要に応じて）変換し、他のメッセージに関連する順序を維持し、サブスクライバーが使用できるようにした後、一度使用されたメッセージを削除します（そのため、再度消費することはできません）。

pub/subメッセージング・パターンは、大規模なコードベースを持つ企業や、複数のコンシューマーに情報をブロードキャストする場合（通知システムやリアルタイムのデータ・フィードなど）に最適です。

pub/subと同様に、イベント・ストリーミングはパブリッシャーとコンシューマーを切り離し、非同期通信を可能にします。ただし、イベント・ストリーミング・モデルでは、イベント・コンシューマーはストリームを購読する必要はありません。プロデューサーがイベント・ストリームをブローカー・ログに公開し、コンシューマーは任意の時点で各ストリームにステップインして、必要なイベントのみを使用できます（公開されたすべてのイベントを受信して使用する必要なし）。

ただし、pub/subとは異なり、イベント・ストリーミング・ブローカーは、コンシューマーがイベントを受信した後もイベントを保持します。

コンシューマーはイベントが公開された後いつでも処理できるため、イベント・ストリーミングの記録は永続的に残ります。つまり、これらは設定可能な時間（ほんの数秒から永久まで）維持されます。コンシューマーはいつでもストリームにアクセスして、最近のメッセージを読んだり、最後にストリームにアクセスしたときの一連のメッセージをバッチ処理したり、直近の過去の関連メッセージを参照したりできます。

イベント・ストリーミング・テクノロジー（Apache Kafka、Amazon Web Services (AWS) Kinesis、IBM Event Automationなど）にも、プル・モデル（コンシューマーがイベントを受け入れることを示した場合にのみブローカーがコンシューマー・データを送信する）とプッシュ・モデル（ブローカーのビジネス・ロジックによってどのコンシューマーがイベントを受信するかが決まる）の2つのモデルが含まれます。

イベント・ストリーミングのパターンは、リアルタイムのイベント更新と過去イベントへのアクセスの両方を必要とするアプリ（金融機関向けの不正アクセス検知システムなど）に最も役立ちます。

2つの主要なEDAアーキテクチャー・パターンに加え、3つの設計パターンが、イベントがサブスクライバーに到達した後のイベントの処理方法を制御します。

• シンプルなイベント処理：コンシューマーはパブリッシャーから受信したイベントをそのまま処理し、即座にアクションをトリガーします。

• イベント・ストリーム処理（ESP）：データ・ストリーム・プラットフォームがイベントを取り込み、ストリーム・プロセッサーへのパイプラインを構築し、ストリームを処理および変換します。
  
  
• 複合イベント処理（CEP）：コンシューマが一連のイベントを処理し、データの傾向やパターンを特定します。

特にこれら3つの処理パターンはすべて、公開/購読およびイベント・ストリーミング・アーキテクチャー・パターンの両方で使用できますが、ESPは当然ながらイベント・ストリーミング・アーキテクチャー・パターンの使用が最も一般的です。

EDAはさまざまな分野で事業を展開する企業にとって役立ちますが、特に大規模で複雑なIT環境を有する企業にとって価値があります。

例えば、異なる技術スタックで実行されているシステムの統合を測っている企業は、イベント駆動型アーキテクチャーの主要な分離機能を使用して、イベント・データをシステムに依存しない状態に保ち、相互運用性を向上させることができます。多国籍企業は、EDAを使用してアカウントや地域間でシステムを調整し、アーキテクチャーのさまざまな部分の独立したスケーリングを容易にできます。また、イベントのそれぞれ異なる部分を処理するシステムを実行している企業では、EDAのファンアウト機能により、新しいコードを必要とせずにイベントを各コンシューマーにプッシュし、システム全体で並列処理を行うことができます。

Eコマースでは、イベント駆動型アーキテクチャーにより、イベントをリアルタイムでフィルタリングしてルーティングし、データに関心のあるサブスクライバーにのみイベントが送信されるようにできます。新規購入は注文処理コンシューマーに直接送信され、注文に関する問題はカスタマー・サービス・チャネルに直接ルーティングされます。

イベント駆動型アーキテクチャーは、今日の企業が市場の動向に対応し、将来へと進むために不可欠になりつつあります。実際、組織の26％がビジネス・ニーズを満たすためにEDAを導入することを計画しており、すでに導入している企業は37％近くに上ります。¹ また、EDAソフトウェア業界は、2027年までに規模が2倍になり、収益は165億ドルを超えると予想されています。 ²

毎日、何千ものビジネス・イベントが組織のあらゆる部分で発生し、これらのイベントは、ビジネス全体でいつ何が起こっているかに関する豊富な情報を提供します。しかし、適切なテクノロジーがなければ、多くの企業はこのデータを処理して活用し、顧客、製品、またはビジネスについて十分な情報に基づいた意思決定を行うことができません。

そこでEDAプラットフォームが非常に重要になり、高スループット、低遅延プロセスのオートメーションを可能にし、次のようなさまざまなユースケースに高度なツールを提供します。

イベント駆動型アーキテクチャーは、ユーザーが新たな状況を検知し、リアルタイムで対処し、意思決定を自動化し、収益機会を最大化できるようにすることで、ビジネス・イベントを活用します。EDAはまた、次のような機能を提供することで、企業の成長の維持と加速に役立ちます。

EDAを使用すると、増大したワークロードを処理するためにサービスのインスタンスを追加することで、システムを拡張できます。

EDAにより、コンポーネントが非同期で通信できるようになります。プロデューサーは、コンシューマーの受信を待たずに（あるいはコンシューマーがイベント・メッセージを受信したかどうかさえ知らずに）独自のスケジュールでイベント・メッセージを公開できるため、統合とユーザー・エクスペリエンスの両方を簡素化できます。

サービスは個別に追加、削除、変更できるため、アジャイル開発とデプロイメントの実践が容易になります。

EDAは時間と同期の範囲内で分離されるため、イベント・プロデューサーとコンシューマーは（直接APIを呼び出すのではなく）イベントを通じてやり取りし、依存関係が減少し、システム全体のレジリエンスが向上します。

EDAは本質的にリアルタイムの処理と応答を目的として設計されているため、チームはよりプロアクティブに対応し、よりスマートなアクションとオートメーションを促進できます。