イベント ドリブン アーキテクチャのスタイルEvent-driven architecture style

イベント ドリブン アーキテクチャは、イベントのストリームを生成するイベント プロデューサーと、イベントをリッスンするイベント コンシューマーで構成されます。An event-driven architecture consists of event producers that generate a stream of events, and event consumers that listen for the events.

イベント ドリブン アーキテクチャのスタイルの図

イベントはほぼリアルタイムで配信されるため、イベントが発生するとコンシューマーはすぐに応答できます。Events are delivered in near real time, so consumers can respond immediately to events as they occur. プロデューサーはコンシューマーから分離されており、—プロデューサーにはどのコンシューマーがリッスンしているのかがわかりません。Producers are decoupled from consumers — a producer doesn't know which consumers are listening. コンシューマーも互いに分離されており、すべてのコンシューマーがすべてのイベントを見ることができます。Consumers are also decoupled from each other, and every consumer sees all of the events. これは競合コンシューマー パターンとは異なり、コンシューマーがキューからメッセージを取得し、メッセージは一度だけ処理されます (エラーは想定されません)。This differs from a Competing Consumers pattern, where consumers pull messages from a queue and a message is processed just once (assuming no errors). IoT などの一部のシステムでは、イベントを大量に取り込む必要があります。In some systems, such as IoT, events must be ingested at very high volumes.

イベント ドリブン アーキテクチャでは、パブリッシュ/サブスクライブ モデルやイベント ストリーム モデルを使用できます。An event driven architecture can use a pub/sub model or an event stream model.

  • パブリッシュ/サブスクライブ:メッセージング インフラストラクチャではサブスクリプションを追跡します。Pub/sub: The messaging infrastructure keeps track of subscriptions. イベントが発行されると、各サブスクライバーにイベントが送信されます。When an event is published, it sends the event to each subscriber. イベントの受信後は、イベントを再生することはできません。また、そのイベントは新しいサブスクライバーに表示されません。After an event is received, it cannot be replayed, and new subscribers do not see the event.

  • イベント ストリーミング:イベントがログに書き込まれます。Event streaming: Events are written to a log. イベントは (パーティション内で) 厳密に順序付けされ、持続します。Events are strictly ordered (within a partition) and durable. クライアントはストリームにサブスクライブしませんが、その代わり、ストリームのどの部分からでも読み取ることができます。Clients don't subscribe to the stream, instead a client can read from any part of the stream. ストリーム内でクライアントの位置を進めるのは、クライアントの役割です。The client is responsible for advancing its position in the stream. つまりクライアントはいつでも参加でき、イベントを再生できます。That means a client can join at any time, and can replay events.

コンシューマー側には、いくつかの一般的なバリエーションがあります。On the consumer side, there are some common variations:

  • 簡単なイベント処理Simple event processing. イベントがコンシューマーのアクションを即時トリガーします。An event immediately triggers an action in the consumer. たとえば、お客様は Service Bus トリガーを備えた Azure Functions を使用でき、それにより、Service Bus トピックにメッセージが発行されるたびに関数が実行されます。For example, you could use Azure Functions with a Service Bus trigger, so that a function executes whenever a message is published to a Service Bus topic.

  • 複合イベント処理Complex event processing. コンシューマーは一連のイベントを処理し、Azure Stream Analytics または Apache Storm などのテクノロジを使用してイベント データのパターンを検索します。A consumer processes a series of events, looking for patterns in the event data, using a technology such as Azure Stream Analytics or Apache Storm. たとえば、組み込みデバイスからの測定値を時間枠で集計し、移動平均が特定のしきい値を超えた場合に通知を生成することができます。For example, you could aggregate readings from an embedded device over a time window, and generate a notification if the moving average crosses a certain threshold.

  • イベント ストリーム処理.Event stream processing. Azure IoT Hub や Apache Kafka などのデータ ストリーミング プラットフォームを、イベントを取り込んでストリーム プロセッサにフィードするパイプラインとして使用します。Use a data streaming platform, such as Azure IoT Hub or Apache Kafka, as a pipeline to ingest events and feed them to stream processors. ストリーム プロセッサは、ストリームの処理や変換を行います。The stream processors act to process or transform the stream. アプリケーションの異なるサブシステムに対して、複数のストリーム プロセッサが存在する場合があります。There may be multiple stream processors for different subsystems of the application. この手法は IoT ワークロードに適しています。This approach is a good fit for IoT workloads.

イベントのソースはシステムの外部にある場合があります。たとえば、IoT ソリューションの物理デバイスなどです。The source of the events may be external to the system, such as physical devices in an IoT solution. その場合、システムはデータ ソースで必要なボリュームとスループットでデータを取り込むことができる必要があります。In that case, the system must be able to ingest the data at the volume and throughput that is required by the data source.

上記の図では、コンシューマーが種類ごとに 1 つのボックスで表示されています。In the logical diagram above, each type of consumer is shown as a single box. 実際には、1 つのコンシューマーに複数のインスタンスがあるのが一般的ですが、それはコンシューマーがシステムの単一障害点にならないようにするためです。In practice, it's common to have multiple instances of a consumer, to avoid having the consumer become a single point of failure in system. イベントのボリュームと頻度を制御するのに、複数のインスタンスが必要になることもあります。Multiple instances might also be necessary to handle the volume and frequency of events. また、1 つのコンシューマーが複数のスレッドのイベントを処理することもあります。Also, a single consumer might process events on multiple threads. イベントを順番に処理しなければならない、または正確に 1 回のセマンティクスが必要な場合には、このために課題が発生することがあります。This can create challenges if events must be processed in order or require exactly-once semantics. 「Minimize Coordination (調整を最小限に抑える)」をご覧ください。See Minimize Coordination.

このアーキテクチャを使用する状況When to use this architecture

  • 複数のサブシステムで同じイベントを処理する必要がある。Multiple subsystems must process the same events.
  • 最小のタイム ラグのリアルタイム処理。Real-time processing with minimum time lag.
  • パターン マッチングや時間枠での集計などの複合イベント処理。Complex event processing, such as pattern matching or aggregation over time windows.
  • IoT などの高ボリューム、高ベロシティのデータ。High volume and high velocity of data, such as IoT.

メリットBenefits

  • プロデューサーとコンシューマーが分離。Producers and consumers are decoupled.
  • ポイント ツー ポイント統合でない。No point-to point-integrations. システムに新しいコンシューマーを追加するのが簡単。It's easy to add new consumers to the system.
  • コンシューマーは、イベントが到着するとすぐに応答可能。Consumers can respond to events immediately as they arrive.
  • 高い拡張性と分散。Highly scalable and distributed.
  • サブシステムにイベント ストリームの独立したビューがある。Subsystems have independent views of the event stream.

課題Challenges

  • 保証された配信。Guaranteed delivery. 一部のシステムでは (特に IoT シナリオで)、イベントが配信されたことを保証することが重要です。In some systems, especially in IoT scenarios, it's crucial to guarantee that events are delivered.
  • イベントを順番に、または正確に 1 回処理。Processing events in order or exactly once. 各コンシューマー タイプは通常、回復性とスケーラビリティのために複数のインスタンスで実行されます。Each consumer type typically runs in multiple instances, for resiliency and scalability. (コンシューマー タイプ内で) 順番にイベントを処理する必要がある場合や、処理ロジックがべき等でない場合は、このために課題が発生することがあります。This can create a challenge if the events must be processed in order (within a consumer type), or if the processing logic is not idempotent.