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

イベント・ストリーム処理（ESP）の重要な機能であるイベント・ストリーミングは、イベントや変更が発生したときにデータを処理することで、ITインフラストラクチャーがイベントの大規模かつ継続的なストリームを処理できるようにします。

イベント・ストリーミングは、多くの場合、大規模な静的データ・セット（または「保存データ」）を処理するバッチ処理の補完として機能します。ただし、イベント・ストリーミングはデータをバッチで処理するのではなく、単一のデータ・ポイントが発生したときに処理します。このアプローチにより、アーキテクチャー内のソフトウェアはデータ・ストリーム（「移動中のデータ」）をリアルタイムで解釈し、応答できるようになります。

高性能なイベント・ストリーミング・サービスは、株価や製品価格の変更時に通知を送信することから、疑わしいユーザー・アクティビティーを検知するリアルタイムの機械学習モデルを構築することまで、さまざまな単純なタスクと複雑なタスクの両方に対応できます。バッチ処理の場合でも、イベント・ストリーミングによりイベントをそれぞれのタイムスタンプと結び付けることで、データ分析に深みを与えることができます。また、過去の傾向を特定するのにも役立ち、長期にわたる貴重な洞察が提供されます。

イベント・ストリーミングは、「イベント」と呼ばれるシステムまたは環境内で発生したすべての出来事を記録する基本的なデータ構造であるデータ・レコードの無制限で連続したリアルタイムのフローを中心に展開されます。これは、基本的にシステム内のすべてのデータ・ポイントを指す用語です。したがって、「ストリーム」（データ・ストリームまたはストリーミング・データとも呼ばれる）は、これらのイベントの継続的な配信を指します。

各イベントは通常、イベントまたはそれに関連するエンティティーを識別するキーと、イベントの実際のデータを保持する値で構成されます。また、イベントがいつ発生したか、または記録されたかを示すタイムスタンプや、場合によってはデータ・ソース、スキーマのバージョン、その他の属性に関するメタデータも含まれます。

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

イベントは多くの場合、事業運営やユーザー・ナビゲーション・プロセスに関連付けられており、通常は別のアクション、プロセス、または一連のイベントをトリガーします。一例として、オンライン・バンキングを取り上げます。

ユーザーが「送金」をクリックしてある銀行口座から別の銀行口座に送金すると、資金が送金者の口座から引き出され、受信者の銀行口座に追加されます。EメールまたはSMS通知は一方（または両方）の当事者に送信され、必要に応じてセキュリティーおよび不正防止プロトコルがデプロイされます。

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

ブローカー、またはメッセージ・ブローカーは、イベント・ストリーミング・プラットフォームを実行するサーバーです。メッセージ・ブローカーにより、アプリケーション、システム、サービスが相互に通信し、情報を交換できるようになります。この機能は、正式なメッセージング・プロトコル間でメッセージを変換することによって実現します。これにより、サービスが異なる言語（JavaやPythonなど）で書かれていたり、異なるプラットフォームに実装されていたりする場合でも、相互に依存するサービスが直接「通信」できます。また、システム内のプロセスとサービスの分離も容易になります。

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

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

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

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

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

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

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

標準的なストリーミングや処理に加え、Amazon Kinesis、Google Pub/Sub、Azure Event Hubs、IBM® Event Automationなどのイベント・ストリーミングプラットフォームは、機能性を向上させる多様なストリーミング実践を促進します。特にIBM® Event Automationは、オープンソースのApache Kafkaプラットフォームの処理能力を使用して、イベント・ドリブンのワークフローを最適化します。

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

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

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

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

イベント・ストリーミングとは、多くの場合、時間的制約のある方法でのデータ処理を意味します。ウォーターマーキングにより、ストリーム処理システムでの進行状況の追跡（イベント時間を使用）が可能になります。これは、システムがイベント・データが完全に処理されたと見なせる時点を示す完全性のしきい値を適用します。ウォーターマークは、時間ベースの処理の精度を確保したり、順不同のイベントを調整したりするためにも役立ちます。

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

繰り返しになりますが、標準的なストリーミング・アーキテクチャーは通常、イベント・プロデューサー、イベント・ブローカー、消費者を分離しているため、コンポーネントを個別に拡張および保守できます。

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

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

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

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

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

イベント・ストリーミングは、イベント駆動型アーキテクチャーを構築するための基盤となるテクノロジーでもあります。

イベント駆動型アーキテクチャーにより、疎結合コンポーネントがイベントを通じて通信できるようになります。イベントのストリームをブローカーに公開する代わりに、別のアプリやサービスがアクションを実行するために使用できる単一目的のイベントを公開します。イベント駆動型アーキテクチャーによって提供されるインストリーム処理能力をイベント・ストリーミング機能と併用することで、企業は移動中のデータに対応し、すべての現在のデータと履歴データに基づいて迅速な意思決定を行うことができます。

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