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

イベント・ストリーム処理（ESP）の重要な機能であるイベント・ストリーミングは、イベントや変更が発生したときにデータを処理することで、ITインフラストラクチャーがイベントの大規模かつ継続的なストリームを処理できるようにします。イベント・ストリーミングは、ストリーム処理とは異なります。イベント・ストリーミングは、イベントを移動および保管するインフラストラクチャーを提供します。ストリーム処理では、これらのイベントにフィルタリング、集約、またはエンリッチメントが適用される場合があります。

イベント・ストリーミングは、多くの場合、大規模な静的データ・セット（または「保存データ」）を処理するバッチ処理を補完します。ただし、イベント・ストリーミングでは、境界されたデータをバッチで処理する代わりに、無制限のデータを到着時に処理できます。このアプローチにより、アーキテクチャー内のソフトウェアはデータ・ストリーム（「移動中のデータ」）をリアルタイムで解釈し、応答できるようになります。

高性能なイベント・ストリーミング・サービスは、株価や製品価格の変更時に通知を送信するといった単純な機能から、より複雑なワークロードまで、さまざまなタスクに対応できます。また、不審なユーザーアクティビティを検知する人工知能（AI）やリアルタイムの機械学習モデルもサポートします。

バッチ処理の場合でも、イベント・ストリーミングによりイベントをそれぞれのタイムスタンプと結び付けることで、データ分析に深みを与えることができます。また、過去の傾向を特定するのにも役立ち、長期にわたる貴重な洞察が提供されます。

イベント・ストリーミングは、「イベント」と呼ばれるシステムまたは環境内で発生したすべての出来事を記録する基本的なデータ構造であるデータ・レコードの継続的で潜在的に無制限のフローを中心に展開されます。イベントとは、何かが起こった（注文の実施や支払いの承認など）という変更不可能な記録です。「ストリーム」（データ・ストリームまたはストリーミング・データとも呼ばれる）は、これらのイベントの継続的な配信です。

各イベントは通常、イベントまたはそれに関連するエンティティーを識別するキー、イベントの実際のデータを保持する値、イベントが発生または記録された日時を示すタイムスタンプを含み、データ・ソース、スキーマ・バージョン、またはその他の属性に関するメタデータが含まれることもあります。

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

組織は大量のイベント・データを生成するため、リアルタイム分析を使用して、パターン、異常、傾向が発生したときにそれを特定する場合があります。AIは、イベント・ストリーム内の複雑な関係を検出し、予測を生成し、アクションを推奨することで、こうしたリアルタイムの洞察を活用します。

この機能はAIシステムの前提条件となりつつあります。IDCによると、エージェント型AIのユースケースの80%は、リアルタイムで文脈的かつ広くアクセス可能なデータを必要としています。分析、AI、自動化されたワークフローをサポートするかどうかにかかわらず、これらのシステムは、組織全体のアクティビティーを表すイベントの継続的なフローに依存しています。

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

イベントはイベント・ストリーミングの中心的なコンポーネントです。ただし、他の一連のコンポーネントにより、ストリーミング・サービスはイベントを同じくらい迅速かつ効果的に処理できます。その他の重要なコンポーネントは次のとおりです。

ブローカーはプロデューサーからイベントを受け取り、整理して保管し、消費者が利用できるようにします。ブローカーは仲介者として機能することで、生産者と消費者が直接接続することなく通信できるようにし、それぞれが独立して動作し、拡張できるようにします。 

分散型イベント・ストリーミング・システムでは、ブローカーが複数のノード間でイベントを複製することで、低遅延と高可用性を確保します。ブローカーはクラスターを形成することもできます。クラスターとは、ロード・バランシングと拡張性を容易にするために連携して動作するブローカーのセットです。

トピックは、イベントが公開される分類またはフィードの名前です。プラットフォーム内でイベントの整理およびフィルタリングする方法を提供します。イベントの「主体」として機能することで、消費者はトピックにサブスクライブし、関連するイベントのみを受け取ることができます。

トピックはさらにパーティションに分割できるため、各パーティションの順序を乱すことなく、複数の消費者がトピックから同時に読み取ることができます。

オフセットは、パーティション内の各イベントの一意の識別子です。シーケンス内のイベントの位置を示します。消費者はオフセットを使用して、処理したイベントを整理します。たとえば、消費者がイベントから切断し、後で再接続すると、最後の既知のオフセットから処理を再開できます。

データの急増とその結果としてのデータ・トラフィックの急増を考えると、イベント・ストリーミングは最新のデータ・アーキテクチャーの不可欠なコンポーネントです。これは、超高速の意思決定能力を必要とする環境や、意思決定責任の自動化を目指す組織では価値があります。

イベント・ストリーミング・サービスがイベント・データを管理する方法は次のとおりです。

1. イベントの生成。イベント・ストリーミングは、プロデューサー（マイクロサービス バックエンド・システム、IoT（モノのインターネット）エコシステム、イベント駆動型APIなど）がイベント・ストリーミング・プラットフォームにイベントを送信したときに開始されます。
   
   
2. イベントの公開。クライアント・ライブラリを使用して、プロデューサーはプラットフォーム内の特定のトピックにイベントを公開し、その時点で消費者は（トピックにサブスクライブするアプリやサービスを）利用できるようになります。
   
   
3. イベント・ストレージ。プラットフォームは所定の期間イベントを保管し、ブローカーがイベントのストレージと取得プロセスを管理します。
   
   
4. イベントの消費。消費者はイベント・データを処理して、他のイベントを開始します。目的や設定に応じて、イベントが到着するとすぐに処理したり（リアルタイム処理）、後で処理するために保管したり、バッチ処理用にコンパイルしたりできます。消費者はオフセットを使用してデータ・パイプライン内の位置も追跡するため、障害や再起動が発生した場合でも、中断したところから処理を再開できます。
   
   
5. イベントの配信。イベント・ブローカーは、消費者がイベントを利用できるようにします。「少なくとも1回」というセマンティックに基づいてイベント配信を保証し、重複が発生した場合でも、すべてのイベントが宛先に到達できるようにします。このプロセスには「完全に1回だけ」配信することもあり、各イベントが一度だけ配信されるか、別のタイプのセマンティクスを使用して配信されるようにします。
   
   
6. イベント処理。最初のイベントが消費または配信されると、イベント・データは、データの変換、集約、複雑なイベント処理（CEP）ワークフローのトリガーなど、いくつかのダウンストリーム・アクションのために処理されます。組織では一般に、Apache Flink、Apache Spark Structured Streaming、Kafka Streamsなどのストリーム処理テクノロジーを使用して、分散型イベント駆動型システム全体でこれらの操作をリアルタイムで実行します。結果として得られるリアルタイムのデータ・ストリームは、AIシステムがリアルタイムの意思決定をサポートするために使用するデータの継続的なフローも提供できます。

イベント・ストリーミングは通常、複数のシステムにわたるイベント・データの連続したストリームをキャプチャ、保管、処理、配布するために設計された分散アーキテクチャーとして実装されます。イベント・ストリーミング・アーキテクチャーは、ポイントツーポイントでの直接接続に頼るのではなく、データ・プロデューサーとコンシューマーを切り離す共有インフラストラクチャーを使用します。これにより、アプリケーションは独立して拡張し、リアルタイムで情報を交換できます。いくつかのコア・アーキテクチャー・コンポーネントが、このフレームワークを可能にしています。

ほとんどのイベント・ストリーミング・アーキテクチャーの主要なコンポーネントは、イベント・データの耐久性とスケーラブルなバックボーンとして機能するイベント・ブローカーです。 イベントは分散ログ内のトピックに書き込まれ、受信した順序で保管され、後で使用できるようになります。

このアーキテクチャーにより、データを生成したシステムと直接統合することなく、複数のアプリケーションが同じイベント・ストリームに独立してアクセスできます。Apache Kafka、Amazon Kinesis、Apache Pulsarなどのテクノロジーは、一般的にこの機能を提供します。

イベント・ストリームをサポートするために、大規模なワークロードをサポートするために、イベント・ストリームは通常、トピックに整理され、複数のサーバーに分散できるパーティションに分割されます。パーティショニングにより並列処理とより高いスループットが可能になり、複製によりさまざまなノード間でデータのコピーが作成され、個々のコンポーネントに障害が発生した場合のフォールト・トレランスと可用性が向上します。

イベント・ストリーミング・アーキテクチャーは、データを生成するシステムとデータを使用するシステムを分離します。プロデューサーはトピックにイベントを公開し、コンシューマーはそれらのトピックをサブスクライブし、イベントを独自に処理します。この分離された設計により、データを生成するシステムを変更することなく、新しいアプリケーションやサービスを追加できます。

多くのイベント・ストリーミング・アーキテクチャーには、システム内を移動するイベントを分析して変換するストリーム処理層が含まれています。一般的なストリーム処理テクノロジーには、Apache Flink、Kafka Streams、ksqlDB、Apache Spark Structured Streamingなどがあります。これらのテクノロジーは、継続的に到着するデータに対するフィルタリング、エンリッチメント、結合、集約などのオペレーションをサポートします。

一部のストリーミング・ワークロードでは、過去のイベントに関する情報を維持することがアプリケーションに必要です。例えば、Eコマース・プラットフォームでは、過去1時間に行われたすべての購入を分析して、トレンド商品を特定し、おすすめをほぼリアルタイムで更新する場合があります。状態管理により、システムはこの情報を長期にわたって保持および更新できます。一方、ウィンドウ化では、継続的なデータ・ストリームを時間ベースまたはイベントベースの間隔に整理して分析します。

イベント・ストリーミング・アーキテクチャーには通常、データ損失を防ぎ、障害からの回復をサポートするメカニズムが含まれています。アプリケーションの要件に応じて、システムは最大1回、最小1回、または1回のみの処理保証を提供できます。チェックポイント、複製、コンシューマー・オフセット追跡により、中断やシステムの再起動時にデータの一貫性を維持できます。

処理されたイベントは通常、データベース、データウェアハウス、データレイク、検索インデックス、機械学習システム、またはその他のイベント・ストリームなどのダウンストリームの宛先に配信されます。これらの統合により、イベント・データはリアルタイム分析、運用アプリケーション、自動化ワークフロー、AIアプリケーションをサポートできます。

標準的なストリーミングや処理に加え、Amazon Kinesis、Google クラウド Pub/Sub、Azure Event Hubs、 IBM® Event Automationなどのイベント・ストリーミング・プラットフォームは、機能性を向上させる多様なストリーミング実践を促進します。特にIBM® Event Automationは、オープンソースのApache Kafkaプラットフォームの処理能力を使用して、イベント・ドリブンのワークフローを最適化します。これらの機能は、組織が分析およびAIシステムに依存するリアルタイムデータパイプラインを提供するのにも役立ちます。

1回限りの配信セマンティックにより、ストリーム内の各イベントが正確に1回のみ確実に処理されることが保証されます。これは、ストリーム・イベントの重複や損失を防ぐために不可欠な機能です。ほとんどのイベント・ストリーミング・システムには、システム内の他の場所での障害に関係なく、1回限りのセマンティックを提供するメカニズムが搭載されています。

ダウンストリーム・コンポーネントが受信イベント速度に追いつけない場合、バックプレッシャーによってストリームがシステムを圧迫するのを防ぎます。データ・フロー制御メカニズムであるバックプレッシャーにより、消費者は、データ処理に圧迫された場合や、受信するイベントに追いつけなくなった場合に、データ生成を調整したり停止したりするようにプロデューサーに指示することができます。

このプロセスにより、システムは、システム全体を中断するのではなく、着信イベントをバッファリングまたはドロップすることでワークロードを適切に処理できるため、ワークロードが変動してもイベント処理が安定した状態を維持できます。

イベントの消費者は多くの場合、消費者グループの一員としてイベントの消費を加速させます。消費者グループにいる各消費者はパーティションのサブセットに割り当てられ、並列消費が可能になることで効率が向上します。グループ内の消費者の一人に障害が発生したり、消費者の追加または削除が必要になったりした場合、プラットフォームは動的にパーティションを再割り当てして、バランスとフォールト・トレランスを維持できます。

イベント・ストリーミングとは、多くの場合、時間的制約のある方法でのデータ処理を意味します。ウォーターマークとは、イベント時間がどれだけ進んだかをシステムが推定したものです。ウォーターマーク処理により、システムがイベント・データを完全に処理済みとみなせるタイミングを示す完全性閾値が設定されます。また、ウォーターマークは、時間ベースの処理における正確性を確保したり、順序が乱れたイベントを整合させたりする際にも役立ちます。

ほとんどのイベント・ストリーミング・プラットフォームは、カスタマイズ可能なデータ保持ポリシーを提供しており、開発者はイベントを利用できる期間を制御することができます。一方で、データ圧縮とは、重要なデータを維持しながらストレージのフットプリントを最小限に抑え、トピックから冗長なデータや古いデータを削除するプロセスです。

繰り返しになりますが、標準的なストリーミング・アーキテクチャーは通常、イベント・プロデューサー、イベント・ブローカー、消費者を分離しているため、コンポーネントを個別に拡張および保守できます。この柔軟性により、企業はリアルタイム分析、AI搭載の意思決定、自動化ワークフローなど、多くの下流アプリケーションをサポートすることができます。この柔軟性により、企業はリアルタイム分析、AI搭載の意思決定、自動化ワークフローなど、多くの下流アプリケーションをサポートすることができます。

イベント・ストリーミングとバッチ処理の違いは、イベント・ストリーミングはイベントが発生すると継続的にデータを処理するのに対し、バッチ処理は定期的またはトリガー時に蓄積されたデータを処理することです。

イベント・ストリーミングとバッチ処理はどちらもデータの移動と処理を行いますが、主にデータの処理タイミングと方法が異なります。イベント・ストリーミングは、アプリケーション、データベース、IoT（モノのインターネット）デバイスなどのソースからイベントが発生すると継続的にキャプチャして転送します。完全なデータ・セットを待つ代わりに、システムは個々のイベントまたは小さなイベントのグループを受信するとすぐに処理し、低遅延の分析と応答をサポートします。

このアプローチは、データの価値がその鮮度によって決まるユースケースに適しています。例としては、不正アクセス検知、運用監視、リアルタイムの推奨事項、最新の情報に依存するAIシステムなどが挙げられます。

バッチ処理は、定義された期間のデータを収集し、それを個別のワークロードとしてまとめて処理します。成果をすぐに出す必要がないため、バッチ処理は、日次レポートの作成、口座の照合、分析ダッシュボードの更新などのタスクに適しています。

さらに、2つのアプローチは相互に排他的ではなく補完的です。組織は、イベント・ストリーミングを使用してアクティビティーを発生時に検知して対応し、バッチ処理を使用して蓄積されたデータについて包括的な履歴分析を実行する場合があります。

イベント・ストリーミングは、生成されたデータを組織が使用して、より応答性が高くインテリジェントなシステムを作成できるようにする強力な概念です。データ駆動型の意思決定の台頭により、イベント・ストリーミングは最新のソフトウェア・アーキテクチャーにおいてますます重要なコンポーネントとなっています。

そのため、イベント・ストリーミング・テクノロジーには、次のようなさまざまなビジネス・セクターのユースケースがあります。

特定の業種以外にも、イベント・ストリーミングは他のテクノロジーやアーキテクチャーと組み合わせて導入すると便利です。例えば、イベント・ストリーミングは、イベント・ソーシングやコマンド・クエリ責任分離（CQRS）などのパターンに関連付けられていることがあります。

イベント・ソーシングは、アプリの状態に対する変更が一連のイベントとして格納されるアーキテクチャーのパターンです。イベント・ストリームと並行して使用されるイベント・ソーシングにより、ストリーミング・システムは、これらのイベントを再生して、任意の時点でエンティティーの状態を再構築したり、システムの他のコンポーネントを動かしたりすることができます。

CQRSアーキテクチャー・パターンでは、システムは、コマンドを処理するモデル（書き込み）とクエリを処理するモデル（読み取り）の2つの異なるモデルに分割されます。CQRSでイベント・ストリーミングを使用すると、書き込みモデルから読み取りモデルに変更をリアルタイムで伝播し、2つの間の非同期統合を可能にします。

イベント・ストリーミングは、イベント駆動型アーキテクチャーを構築するための基盤となるテクノロジーでもあります。イベント駆動型アーキテクチャーでは、疎結合されたコンポーネントがイベントを介して通信できるようになります。イベントのストリームをブローカーに公開する代わりに、別のアプリやサービスがアクションを実行するために使用できる単一目的のイベントを公開します。

イベント駆動型アーキテクチャーによって提供されるインストリーム処理能力をイベント・ストリーミング機能と併用することで、企業は移動中のデータに対応し、現在および履歴データに基づいて迅速な意思決定を行うことができます。このリアルタイムの応答性は、継続的に更新されるデータに依存する分析やAIアプリケーションもサポートします。

近年、クラウド・プロバイダーは、イベント・ストリーミングの原理をサービスとして提供し始めています。サービスとしてのイベント・ストリーミングにより、企業は基盤となるインフラストラクチャー全体を管理しなくてもイベント・ストリーミングを簡単に採用できるようになり、イベント・ストリーミングのユースケースがさらに広がります。