イベント駆動型アーキテクチャーとは、イベントの公開、取得、処理、保存（または持続）を中心に構築された、統合モデルです。 具体的には、アプリケーションやサービスが、別のアプリケーションやサービスが知りたいと考えるようなアクションを実行する際、または変化する際に、イベント（そのようなアクションや変化の記録）を公開します。別のアプリケーションやサービスは、これを取り込んで処理することにより、1つ以上のアクションを実行できます。

イベント駆動型アーキテクチャーは、接続されたアプリケーションやサービス間の疎結合を実現します。これらは、イベント形式以外に互いに何も知らなくても、イベントを公開して取り込むことにより、相互に通信できます。 このモデルからは、要求/応答型のアーキテクチャー（または統合モデル）よりも大きなメリットが得られます。要求/応答型のアーキテクチャーでは、1つのアプリケーションまたはサービスが、特定の要求を期待する別の特定のアプリケーションまたはサービスから、特定の情報を要求する必要があります。

イベント駆動型アーキテクチャーは、クラウド・ネイティブ・アプリケーションの可能性を最大限に高め、リアルタイム分析や意思決定支援などの強力なアプリケーション・テクノロジーを実現します。

イベント駆動型アーキテクチャーでは、アプリケーションはイベント・プロデューサーまたはイベント・コンシューマー（そしてしばしばその両方）として機能します。

イベント・プロデューサーは、ブローカーや他の何らかの形式のイベント・ルーターに、メッセージ形式でイベントを送信します。これには、他のイベントと関連させた、イベントの時系列も含まれます。 イベント・コンシューマーは、（発生時に）リアルタイムで、または希望する別の時点で、メッセージを取り込みます。その後、メッセージを処理して、別のアクション、ワークフロー、または自身のイベントを発生させます。

簡単な例では、バンキング・サービスが「預金」イベントを送信し、その銀行の別のサービスがこれを取り込んで応答し、顧客の取引明細書に預入金を記入する場合などがあります。 しかし、イベント駆動型統合は、膨大な量のデータの複雑な分析に基づいて、リアルタイムの応答を発生させることもできます。例えば、e-コマース・サイトで顧客が製品をクリックするという「イベント」は、他の顧客の購入に基づく製品の推奨を即時に生成します。

イベント駆動型アーキテクチャーでイベントを送信する基本モデルは、2つあります

イベント・メッセージングまたはパブリッシュ/サブスクライブ

イベント・メッセージングまたはパブリッシュ/サブスクライブ・モデルでは、イベント・コンシューマーは、イベント・プロデューサーが公開したメッセージのクラスをサブスクライブします。 イベント・プロデューサーがイベントを公開すると、その取り込みを希望するすべてのサブスクライバーにメッセージが直接送信されます。

通常は、メッセージ・ブローカーがパブリッシャーとサブスクライバー間のイベント・メッセージの送信を処理します。 ブローカーは、各イベント・メッセージを受信し、必要に応じて変換し、他のメッセージに対する順序を維持し、サブスクライバーが取り込める状態にして、取り込まれた時点でこれらを削除します（再度取り込まれないようにするため）。

イベント・ストリーミング

イベント・ストリーミング・モデルでは、イベント・プロデューサーがブローカーにイベント・ストリームを公開します。 イベント・コンシューマーはストリームをサブスクライブしますが、公開されたすべてのイベントを受信して取り込む代わりに、各ストリームを任意の時点でステップインし、取り込みたいイベントだけを取り込むことができます。 ここでの主な違いは、コンシューマーが受信した後もブローカーがイベントを保持していることです。

Apache Kafkaなどのデータ・ストリーミング・プラットフォームは、非常に高いスループットで、膨大な量のイベントのロギングや送信を管理します（文字通り、1日あたり何兆ものイベント・レコードを、リアルタイムで、パフォーマンス・ラグを発生させることなく管理します）。 ストリーミング・プラットフォームは、メッセージ・ブローカーにはない、特定の特性を備えています。

• イベントの永続性：イベント公開後、コンシューマーが任意の時点でイベントを取り込む可能性があるため、イベント・ストリーミングの記録は永続的です。その維持される期間は、数分の1秒から無期限まで、構成可能です。 これにより、イベント・ストリーム・アプリケーションによる履歴データやリアルタイム・データの処理が可能となります。
  
  
• 複雑なイベント処理：イベント・メッセージングと同様に、イベント・ストリーミングは、単一のイベント処理のために使用できます。その場合、公開された各イベントは、1以上の特定のコンシューマーによる送信と処理を発生させます。 ただし、これは複雑なイベント処理にも使用できます。その場合、イベント・コンシューマーは、イベント全体を処理し、その結果に基づいてアクションを実行します。

要求/応答型の アプリケーション・アーキテクチャーと比較して、イベント駆動型アーキテクチャーには、開発者や組織にとって、いくつかの利点や機会があります。

強力なリアルタイムでの対応と分析：イベント・ストリーミングは、ビジネス状況の変化に対応し、すべての利用可能な現在と過去のデータに基づいてリアルタイムで予測と意思決定を行うアプリケーションを実現します。 これは、無数のIoTデバイスによって生成されたデータ・ストリームの処理、セキュリティー上の脅威の迅速な予測と鎮圧、最適な効率性を目的としたサプライ・チェーンの自動化など、多くの分野にメリットをもたらします。

フォールト・トレランス、拡張性、簡素化された保守、汎用性、およびその他の疎結合のメリット：イベント駆動型におけるアプリケーションとコンポーネントは、互いの可用性に依存していません。これらは、サービスを中断することなく、独立して更新、テスト、導入することができます。また、1つのコンポーネントがダウンした場合には、オンラインでバックアップを復元することができます。 イベントの永続性は、過去のイベントの「再生」を可能にします。これにより、イベント・コンシューマーの障害が発生しているデータや機能の復旧を支援できます。 コンポーネントは、ネットワーク全体で互いに独立して、容易に拡張できます。また開発者は、イベント・プロデューサーやイベント・コンシューマーの追加や削除によって、アプリケーションやシステムを修正したり強化したりできます。

非同期メッセージング：イベント駆動型アーキテクチャーにより、コンポーネントは、非同期的に通信できます。プロデューサーは、自身のスケジュールでイベント・メッセージを公開し、コンシューマーがこれらを受信するのを待つことはありません（コンシューマーがこれらを受信したか知らない場合もあります）。 これは、統合の簡素化に加えて、ユーザーのアプリケーション体験を向上させます。 1つのコンポーネントでタスクを完了させているユーザーは、そのコンポーネントとシステム内の他のコンポーネントとの間のダウンストリーム統合に関係なく、待たずに次のタスクに移行できます。

基盤となるクラウド・ネイティブなアプリケーション・アークテクチャーであるマイクロサービスでは、アプリケーションは、独立して導入可能なサービスが疎結合されて構成されています。 マイクロサービスの主なメリットは、基本的に、容易な保守、導入の柔軟性、独立した拡張性、フォールト・トレランスといった、疎結合のメリットです。

当然、イベント駆動型アーキテクチャーは、マイクロサービスの導入に対するベスト・プラクティスであると広く考えられています。 マイクロサービスは、REST APIを使用して、相互に通信できます。 ただし、要求/応答型の統合モデルであるRESTは、 マイクロサービス間の同期した密結合を強いるため、疎結合されたマイクロサービス・アーキテクチャーの多くのメリットを低減させます。