イベント・ドリブンのアーキテクチャーとは？

クラウドネイティブ環境全体でEDAが多用されていることは、データレイクのようなリポジトリに静的データを蓄積することに重点を置く従来のアーキテクチャーからの大きな転換を示しています。その代わりに、組織は環境内を通過するデータを追跡する動的アプローチへと移行しつつあります。イベント駆動型システムにおいて、データ自体は本質的に価値がありますが、EDAは、時間の経過とともにイベントの価値が低下する可能性があることを認識しています。

EDAでは、イベント・プロデューサー（APIやIoTデバイスなど）がイベント・コンシューマーにリアルタイムのイベント通知を送信し、イベント・コンシューマーが特定の処理ルーチンをアクティブ化します。顧客がオンラインで注文すると、在庫システムの更新、確認のEメールの送信、倉庫でのピッキングリストの取得、出荷ラベルのキューへの登録を、1つのアクションで連鎖的にトリガーします。これらはすべて進行中のイベントです。

データ・ストリーミングは、システムや環境でのあらゆる出来事や変化を記録するデータ構造であるイベントのリアルタイムフローを中心に展開します。例としては、ユーザーによるショッピングカートへの商品の追加や、パスワードのリセットのリクエストが挙げられます。ストリーム（データストリームまたはイベント・ストリームとも呼ばれる）は、これらのイベントの継続的な配信です。

各イベントは通常、イベントまたはエンティティを識別するキー、実際のデータを保持する値、発生日時を示すタイムスタンプ、場合によってはイベント・ソースまたはスキーマ・バージョンに関するメタデータの4つの要素で構成されます。これらの要素を組み合わせることで、下流のシステムには動作に必要なものがすべて与えられます。

組織が膨大なデジタルフットプリントを管理しているのは、スペースがかなり大きいというようなものです。世界中で生成されるデータの量は1日あたり約4億テラバイトで、これは観測可能な宇宙の星に匹敵する規模です。

その数の背後には、組織を流れる何十億もの個別のビジネス・イベントがあります。データを取り込んで対処するための適切なアーキテクチャーがなければ、そのデータはすぐに古くなってしまう可能性があります。EDAこそがリアルタイム処理を運用可能なものにしています。

イベント駆動型アーキテクチャーの決定的な利点の1つは、疎結合です。イベント・プロデューサーとイベント・コンシューマーは、直接的なAPI呼び出しではなくイベントを介してやり取りするため、分散システムは互いの存在を知らなくても情報を共有できます。プロデューサーは、どのコンシューマーがイベントを受信するかを知らずにイベントを送信します。コンシューマーはリクエストを送り返さずに反応します。この分離された関係により、EDAシステムは独立して拡張することができます。場合によっては失敗しても、システム全体を停止することはありません。

マイクロサービス・アーキテクチャーはこのパターンに依存しています。各サービスは独立して動作するように設計されているため、イベント・メッセージを経由する非同期通信により、モジュール性を損なう緊密な依存関係を生み出すことなく、分散システム間で調整が可能になります。このEDAとマイクロサービスの組み合わせは、プログラムのフローが順次実行ではなくイベントによって決定されるというパラダイムであるイベント駆動型プログラミングを支えています。

EDAは、イベント・プロデューサー、イベント・コンシューマー、イベント・ブローカーという3つの主要コンポーネントに依存して、アーキテクチャーを経由してイベント・データを動かします。

アプリまたはサービスが、システムの別の部分が認識する必要があるアクションを実行すると、ブローカーに新しいイベントを公開します。ブローカーは、イベントの順序をストリーム内の他のブローカーと比較して維持します。イベント・コンシューマーは、リアルタイムまたは後続する関連インスタンスでメッセージを取り込み、別のアクションをトリガーするために処理します。

EDAにはいくつかのアーキテクチャー・パターンが含まれますが、最も一般的なのは出版-購読モデルとイベント・ストリーミングの2つです。

出版-購読モデル（Pub/Sub）では、パブリッシャーはサブスクライバーについて知る必要はありません。イベントは共有イベントチャンネルに公開され、サブスクライバーがリアルタイムで独立して視聴し、反応することができます。一般的なブローカー実装には、イベントバス、メッセージキュー、出版-購読チャンネルなどがあり、それぞれが異なるメッセージング・パターンやオーケストレーションのニーズに適しています。

メッセージ・ブローカーは、パブリッシャーとサブスクライバー間の伝送を処理します。各イベントメッセージの受信、必要に応じて変換、順序の維持、サブスクリプションによる利用可能化を行い、消費された後は再処理できないように削除します。

Pub/Subメッセージングは、大規模なコードベースや、複数のコンシューマーに情報を放送する場合に最適です。このような場合、メッセージの永続性よりも、低遅延とファンアウト（単一のイベントを複数のコンシューマーに配信すること）が重要になります。

Pub/Subと同様に、イベント・ストリーミングはパブリッシャーとコンシューマーを切り離して非同期通信を可能にします。しかし、イベント・ストリーミング・モデルでは、コンシューマーはストリームのサブスクリプションを必要としません。プロデューサーはブローカー・ログに公開し、コンシューマーは任意の時点で介入して、（公開されたすべてのイベントを受信するのではなく）必要なイベントのみを消費できます。新聞の到着を待つのではなく、図書館に行くようなものだとお考えください。

Pub/Subとは異なり、イベント・ストリーミング・ブローカーはコンシューマーがイベントを受信した後もイベントを保持します。レコードは永続的であるため、設定可能な期間（1秒未満から永遠まで）維持されます。

コンシューマーは最近のメッセージを読んだり、最後にストリームにアクセスしたときのシリーズをバッチ処理したり、直近の関連メッセージを参照したりできます。このためイベント・ストリーミングは、不正検出システムなどの、リアルタイムのイベント更新や過去のイベントへのアクセスを必要とするアプリに最も役立ちます。

イベント・ストリーミング・テクノロジーは、対象範囲と専門分野が異なります。

• Apache Kafkaは、高スループットのイベント・ストリーミングの事実上の標準となり、耐久性のあるログ・ストレージ、パーティションベースの順序付け、豊富なコネクターやストリーム・プロセッサーのエコシステムを提供しています。

• Apache Flinkは、その基盤をステートフルなストリーム処理機能で拡張し、ライブのイベントストリーム間の複雑なトランスフォーメーションや集約を可能にします。

• IBM Event Automationはこれらの業界標準技術を基盤として構築し、IBMの広範なデータおよび 人工知能（AI）プラットフォームと並行して、企業にマネージド・イベント・ストリーミングおよび処理機能を提供します。

• Confluent Schema Registryは、イベントスキーマの管理と検証を行うための集中リポジトリを提供し、システムが進化してもプロデューサーとコンシューマーが常に同期を維持することを保証します。

これらのテクノロジーは、コンシューマーが自分のスケジュールでイベントをリクエストするプルモデルと、イベント・ブローカーが配信を決定するプッシュモデルの2つの配信モデルもサポートしています。

以前のアーキテクチャー・モデルはイベントがシステム内でどのように動くかを定義しますが、処理パターンはイベントが到達したときに何が起こるかを定義します。3つの主要なパターンは以下のとおりです。

• シンプルなイベント処理（SEP）：コンシューマーは受信したとおりにイベントを処理し、即座にアクションを実行します。ここで優先されるのは、低遅延とフォールト・トレランスです。

• イベント・ストリーム処理（ESP）：データ・ストリーミング・プラットフォームはイベントを取り込み、ストリーム・プロセッサーへのパイプラインを構築します。ストリーム・プロセッサーはストリームを処理および変換します。これにより、複雑なワークフロー全体のコレオグラフィーが可能になります。

• 複雑なイベント処理（CEP）：コンシューマーは一連のイベントを分析して傾向とパターンを特定し、予知保全や疑わしいアクティビティの検出などのユースケースをサポートします。

分散システムで働くチームはイベント・ソーシングなどの補完的なパターンも適用して、状態の変化を変更不可能なイベントのシーケンスとして保管します。この手法を用いることで、任意の時点におけるシステムの状態を再構築することが可能になります。コマンド・クエリ責任分離（CQRS）は、読み取りモデルと書き込みモデルを分離することで、データの一貫性を向上させて競合を大規模に減らす、もう1つのパターンです。

オペレーターの粒度は、これらのパターンを実装する際に重要な設計上の決定になります。イベント・ハンドラー（イベントがコンシューマーに到達したときに実行される機能）は、ワークフロー全体を処理する単一の機能を使用する場合もあれば、単一のアクションを担当する各機能に限定して表示する場合もあります。

広範囲にわたるハンドラーは管理が簡単ですが、全体に影響を与えずに変更するのは困難です。ナロー・ハンドラーはより柔軟ですが、調整にはより多くのオーケストレーションが必要です。適切なバランスを見つけることが、最終的にシステムが時間の経過とともにどのように維持可能になるかを判断する決め手となります。

EDAは、特に大規模で複雑なIT環境を持つ企業にとって、変化に対応していく上で不可欠なものになりつつあります。異なる技術スタック間でシステムを統合する企業は、イベント・データ・システムに依存しない状態を保ち、相互運用性を向上させるために疎結合を用いています。

多国籍企業は、EDAを使用してアカウントや地域の間でシステムを調整し、ファンアウトによって、新たなコードなしでのシステム全体の並列処理を可能にします。EDAプラットフォームは、業界を超えてこれを可能にし、以下を含むさまざまなユースケースにおいて、高スループットかつ低遅延のプロセス・オートメーションを実現します。

イベント駆動型アーキテクチャーは、ユーザーが新たな状況を検知し、リアルタイムで対処し、意思決定を自動化し、収益機会を最大化できるようにすることで、ビジネス・イベントを活用します。EDAはまた、以下のような機能を提供することで、企業の成長の維持と加速に役立ちます。

• 拡張性：EDAは、増加したワークロードを処理するサービスを増やすことで、システムを拡張できます。

• 非同期メッセージング：プロデューサーはコンシューマーの受信を待たずに自らのスケジュールでイベント・メッセージを公開し、統合とユーザー・エクスペリエンスの両方を簡素化します。

• 柔軟性と俊敏性：サービスは個別に追加、削除、変更できるため、アジャイル開発とデプロイメントの実践が容易になります。

• 疎結合：イベント・プロデューサーとコンシューマーが直接APIを呼び出すのではなく、イベントを通じてやり取りするため、依存関係が軽減され、システム全体のレジリエンスが向上します。

• 応答性：EDAは本質的にリアルタイムの処理と応答を目的として設計されているため、チームはよりスマートなアクションと自動化を促進すると同時に、より事前対応的に行動することができます。

イベント駆動型アーキテクチャーには真の利点があります。また、このパターンを採用する前にチームが理解しておくべき運用上および設計上の考慮事項についても、個別に紹介しています。

EDAでは、プロデューサーはデータを送信して忘れてしまうため、システムの異なる部分が、異なる信頼できる情報源を一時的に保持する可能性があります。チームは、どのオペレーションが一時的な乖離を許容できるか、どのオペレーションが許容できないかを慎重に考察する必要があります。例えば金融取引は、レコメンデーション・エンジンよりも厳格な保証を必要とします。

大規模になると、イベント・シーケンスを維持することは本当に困難です。顧客が配送先住所を更新した後ですぐ注文を行った場合、これらのイベントが到着した注文が、正しい住所を使用するかどうかを決定します。分散した消費者全体で正しいシーケンスを設計するには、大幅なアーキテクチャーに関する規律が必要です。

プロデューサがコンシューマが処理できるよりも早くイベントを生成する場合、システムにはオーバーフローを処理するためのストラテジーが必要です。バックプレッシャーとは、まさにその目的のために設計されたフロー制御メカニズムです。バックプレッシャーの管理には、通常、 レート制限の実施、消費者の水平スケーリング、 バッファリング戦略の活用が含まれます。

従来のシステムでは、障害の原因が明確です。EDAでは、イベントが複数のコンシューマーとルーティング・ステップを通過した後に、処理エラーがはるか下流で表面化する可能性があります。この遅延により、根本原因の分析がかなり困難になり、専用のオブザーバビリティー・ツールが不可欠になります。

ネットワークが障害を起こし、コンシューマーがクラッシュし、イベントが再配信されます。EDAシステムは、同じイベントを２回処理しても誤った成果が得られないように設計する必要があります。これはべき等性と呼ばれる性質です。デッドレターキューや再試行ポリシー などの中断復旧ストラテジーは、システムが障害を円滑に処理し、何か問題が起きた際にイベントが静かに失われることがないようにします。これを意図的に構築しないと、微妙で検知が困難なデータ一貫性の問題が発生する可能性があります。