顧客は、イベントが発生したときにそれを認識することを好みます。顧客が新しい靴を注文し、購入品が発送されたという通知を受け取った後、商品が到着する前に最新の配送状況の更新情報を入手できると、全体的なカスタマー エクスペリエンスが向上します。
注文に関する更新は、イベント駆動型アーキテクチャ(EDA) での応答をトリガーするイベントです。 EDA は、状態の変化 (イベント) に反応し、分離されたアーキテクチャを使用してこれらのイベントを送信するソフトウェア設計です。この分離されたアーキテクチャでは、パブリッシュ - サブスクライブ (pub-sub) パターンなどのいくつかの設計パターンを採用できます。このパターンでは、プロデューサーがイベントをパブリッシュし、サブスクライバーがイベントを監視しますが、どちらも他方に依存しません。
イベント ストリーミングとイベント ソーシングは、組織が EDA を強化できる 2 つの方法を表します。
イベント ストリーミングでは、システム間を流れるデータの継続的なストリームがあり、データは pub-sub パターンを使用してブロードキャストされるイベントの新しい状態を表します。一方、イベント ソーシングでは、すべての新しいイベントが追加ログに保存されます。これは、出来事と背景の時系列順を含む真実の情報源として機能します。
イベント ソーシングとイベント ストリーミングは EDA で並行して使用されることがよくありますが、動作が大きく異なるため、この 2 つを区別することが重要です。イベント ストリームはシステム間の通信をよりアクセスしやすくしますが、イベント ソーシングは新しいイベントを追加専用のログに保存することでイベント履歴を提供します。
ここでは、両方のイベント調整方法について説明し、それぞれの使用例をいくつか紹介します。
イベント ストリーミングでは、pub-sub アプローチを採用して、システム間の通信をよりアクセスしやすくします。パブリッシュ/サブスクライブ アーキテクチャ パターンでは、コンシューマはトピックまたはイベントをサブスクライブし、プロデューサはコンシューマが利用できるようにこれらのトピックに投稿します。パブリッシャー/サブスクライブの設計により、パブリッシャー システムとサブスクライバー システムが分離され、各システムを個別に拡張することが容易になります。
パブリッシャーとサブスクライバーのシステムは、次のようなメッセージ ブローカーを介して通信します。
イベント ストリーミングには、アプリケーション、データベース、センサー、IoT デバイスなどのソースからのデータの継続的なフローが含まれます。イベント ストリームはストリーム処理を採用しており、生成中にデータの処理と分析が行われます。この迅速な処理により、より迅速な結果が得られます。これは、他のリアルタイム アプリケーションと同様に、アクションを実行するための時間枠が限られている企業にとって価値があります。
イベント ストリーミングは、企業にいくつかの利点をもたらします。ここにいくつかあります:
イベントのストリーミングと処理により、組織は顧客エクスペリエンスを豊かにすることができます。たとえば、ディナーを注文した顧客は、ステータスの最新情報を即座に受け取り、配送車両が自分の場所に向かっているときや到着したときに通知を受け取ることができます。この顧客エクスペリエンスの向上は、信頼性の向上、レビューの向上、収益の向上につながります。
PayPal やその他の金融テクノロジー アプリケーションなどのアプリケーションは、イベント ストリーミングを使用してオンライン詐欺検出を提供し、リアルタイム監視を使用してセキュリティを強化できます。不正アルゴリズムは、予測分析を使用してイベント (購入または取引) の状況をテストし、標準からの逸脱 (外れ値) を検出します。システムが外れ値または異常なイベントを検出すると、トランザクションを停止するか、カードの完了をブロックします。
イベント ストリームを分析することで、産業用ツールはパフォーマンスと健全性のメトリクスをログに記録し、機器の健全性を評価できます。この機能を使用すると、組織はマシンが完全に故障し、修理費用が高くなる前に予知メンテナンスを実行できます。たとえば製造業では、組織はパルサー ストリームを使用して、温度や圧力などの機械パラメータからのデータを集約して処理できます。エンジニアはマシンの最高温度を設定し、その温度を超えた場合にトリガーされるアラートを設定できます。機械オペレータは、よりコストのかかる問題が発生する前に、チェックとメンテナンスを実行できます。
イベント ストリーミングは、大量のデータをストリーミングし、迅速で実用的な洞察に依存するビジネスやアプリケーションにとって不可欠です。これらのアプリケーションには、電子商取引、金融取引、IoT デバイスが含まれます。
金融取引アプリケーションでは、イベント ストリーミングを使用して、顧客がすぐに行動したい場合に時間制限のあるイベントを発行します。たとえば、ユーザーはタイムリーな意思決定を可能にするために、株価の変動などの特定のイベントに関する最新情報を送信するバックエンド サービスに登録できます。
イベント ストリーミングには、支払いやその他のトランザクションを処理する (および不正なトランザクションをブロックする) 金融システムのリスク検出および不正検出アプリケーションもあります。定義された不正アルゴリズムは、データが生成された直後に分析することで、疑わしい取引をブロックできます。
イベント ソーシングでは、データをイベントとして追加ログに保存します。このプロセスは、アプリケーションの状態に対するすべての変更をイベント オブジェクトにキャプチャし、これらのイベント オブジェクトをログとして時系列に保存します。イベント ソーシングを使用すると、イベント ストアはビジネス エンティティの状態をシーケンス内のイベントとしてコンパイルし、新しい注文や注文のキャンセルなどの状態の変化により、最新の状態がイベントのリストに追加されます。
イベント ソーシングが効率的に機能し、リソースの消費を最小限にするには、各イベント オブジェクトに必要な詳細のみを含める必要があります。これにより、ストレージ容量が最小限に抑えられ、実用的ではない洞察につながるデータ処理における貴重なリソースの使用が防止されます。
イベント ストアはビジネス イベントとコンテキストをコンパイルします。長いストリームをイベント ログに追加すると、データベース ストレージがすぐに消費されます。必要なイベント コンテキストのみをイベント オブジェクトの一部として保持すると、複数のイベント ログを追加するためのストレージ スペースが解放され、実用的な洞察が得られます。
このような場合、組織はパフォーマンスの最適化に役立つ「スナップショット」の使用を選択する場合があります。スナップショットにより、エンティティの現在の状態を保存できます。現在の状態を知るには、スナップショットを取得し、タイムラインを再作成して最新の状態を知るだけで済みます。
これを図解してみましょう。電子商取引ストアの最近の商品の在庫を取得するデータベースがあるとします。
ほとんどのデータベースは現在の状態のみを保存します。最終的な株価 91 に到達するまでの過程を説明するとしたら、どのようにしてそこに到達したかについての確実性も明確性もありません。イベント ソーシングは、すべての状態変化をログに記録し、根本原因の分析と監査のためのイベント履歴の追跡を可能にします。
医療機関は最も厳しく規制されている業界の 1 つであり、顧客情報を保護するための規制は常に変化しています。レガシー システムから新しいテクノロジーへの簡単な移行を維持しながら、増大するデータ ニーズに適応する柔軟なストレージ ソリューションが必要です。
イベント ストアを唯一の信頼できる情報源として採用することで、医療システムはデータの実際の状態についてイベント ログの不変の状態に依存し、リアルタイム ストリーム処理を採用して価値のある予測を行うことができます。小売業や電子商取引企業は、大規模で耐久性のあるイベント ストアを分析することで、顧客に関するより深い知識を得ることができ、よりパーソナライズされた顧客エクスペリエンスを作成するのに役立ちます。
イベント ストリーミングとイベント ソーシングにはいくつかの類似点があります。 1 つは、各イベント調整方法で分離されたマイクロサービス アーキテクチャが採用されており、これによりスケーラビリティとパフォーマンスが向上します。
イベント ストアとストリームは状態の耐久性が異なりますが、分析やビジネス上の意思決定に使用するアプリケーションの現在のイベント状態を提供するためには不可欠です。また、どちらのイベント調整方法も耐久性のあるストレージ機能を備えていますが、イベント ストアは通常、イベント ストリームよりも長い拡張ストレージを提供します。
ここでは、イベント ストリーミングとイベント ソーシングの主な違いをさらに詳しく見てみましょう。
イベント ストリーミングは、パブリッシャーとサブスクライバーを切り離し、数百万のメッセージを高パフォーマンスで簡単にパブリッシュできるようにすることで、移動中のデータ間の通信をよりアクセスしやすくするのに最適です。一方、イベント ソーシングは、エンティティのすべての新しい状態を追加専用ログに保存することで、イベント履歴を確立するのに役立ちます。
イベント ソーシングの場合、イベントは不変であるため、データは保存された状態で存在します。ただし、イベント ストリームには、データベース、センサー、アプリケーションなどの複数のストレージ システム間を通過する、常に転送中のデータが含まれます。
イベント ストリーミングとイベント ソーシングは、イベント駆動型アーキテクチャでのイベントの調整に役立ちます。これらの用途と価値は異なりますが、相互に連携して耐久性とパフォーマンスの高いアプリケーションを構築するのに役立ちます。
イベント ストリーミングは、分離されたパブリッシュとサブスクのパターンを採用して、さまざまなソースからデータを継続的にストリーミングします。これは、ビジネス上の意思決定の促進に役立ちます。残念ながら、イベント ストリーミング ツールは耐久性のあるストレージを備えている可能性がありますが、耐久性のあるストレージ機能は耐障害性と復元力を高めるのに十分な期間だけ持続するため、メッセージを長期間保存するようには設計されていません。
イベント ソーシングをイベント ストリーミングのサブセットまたはコンポーネントとして見ることができます。イベント ソーシングは、新しいイベントを現在のイベント リストに順序付けられた方法で追加します。また、信頼できる監査のための信頼できる情報源として機能し、イベントの現在の状態をいつでも取得できます。イベントソーシングは、厳しい規制要件と監査要件があり、イベントの現状を追跡および構築するための信頼できるストアがある金融業界にとって非常に重要です。対照的に、イベント ストリーミングは、アクションに時間制限があり、即時のアクションが必要な金融取引アプリケーションでは非常に重要です。
EDA は必ずしも目的地ではありません。これは、特定のシステムのパフォーマンスと特性を推進するために従うべき道です。たとえば、イベント ソーシングはマイクロサービスのコレクションを分離するため、相互の依存度が低くなります。これにより、復元力が向上し、繰り返しが容易になるなどの利点が得られます。イベント ソーシングと組み合わせることで、マイクロサービスはイベントを再生できるだけでなく、ユーザーのプロファイルなどの特定の機能の変更の完全なログを再生できるようになります。この種のアーキテクチャは、既存のシステム内に新たな可能性をもたらします。