イベント駆動型アーキテクチャーとは?
イベント駆動型アーキテクチャーに基づく統合モデルは、重要な「イベント」をリアルタイムで検出して処理します。
default
{}
default
{}
primary
default
{}
secondary
イベント駆動型アーキテクチャーの定義とその重要性
イベント駆動型アーキテクチャーは、重要な状態変化に対する即時対応を可能にするソフトウェア設計アプローチです。重要な出来事が起きた瞬間、例えば、顧客がオンラインショッピングしたとき、センサーが故障の危険を知らせたとき、株価が下落したとき、セキュリティアラートが作動したときに、即座に対応が取れるに越したことはありません。このような変化を「イベント」と呼びますが、イベントはあらゆる組織、あらゆる業界で常に起こっています。そして企業の成功は、イベントにどれだけ迅速に対応できるかにかかっています。
そこで、イベント駆動型アーキテクチャー (EDA) の出番となります。イベント駆動型アーキテクチャーでは、スケジュールされた更新を待ったり、緊密に接続された硬直的なシステムに依存したりするのではなく、緩やかに結合するコンポーネントを通じて、アプリケーション間で非同期通信を行うことができます。つまり、システムの各部分は、他の部分の内部で何をしているかを意識しなくても独立して動作できるため、スケーリング、改修、イノベーションが容易になります。
その結果、企業はイベント駆動型アーキテクチャーを使用する最新のシステムを活用して、パーソナライズされたエクスペリエンスを迅速に提供し、業務を自動化し、ニーズやデータ量が増加しても俊敏性を維持することができます。イベント駆動型アーキテクチャーの導入によって事後対応から事前対応に移行した組織は、絶えず変化するデジタル世界で成功するために必要なスピード、柔軟性、レジリエンスを獲得しています。
イベントとは
イベントとは、ビジネスに影響を及ぼすアクションや状態変化のことを言います。例えば、顧客がクレジットカードをスワイプしたとき、乗客がフライトのチェックインをしたとき、ユーザーがパスワードをリセットしたとき、倉庫の在庫が更新されたときなどです。つまりイベントとは、「今何が起こったのか」を示して、システムの他の部分がすぐに対応できるようにする小さなメッセージです。
発生したイベントを常に把握し、それに対応できる企業は、イベント駆動型と呼ばれます。イベントの一般的な例をいくつかご紹介しましょう。
- 決済の失敗または成功
- ユーザーのログインまたはログアウト
- 在庫がしきい値を下回る
- 倉庫からの出荷または仕向地への到着
- セキュリティ侵害によるアラートのトリガー
- ロイヤルティプログラムによるポイント残高の更新
- サポートチームのチケット作成
- 顧客による出荷先住所の更新
- 新規ユーザーによるアカウントの作成
- 買い物客による製品レビューの投稿
- 加入者によるサブスクリプションの更新または解約
イベント駆動型アーキテクチャーのコアコンポーネント
イベントスキーマでは、構造の一貫性を保つために、イベントに含まれるフィールド、データ型、解釈のルールなど、イベントの構造と形式を定義します。
イベント駆動型アーキテクチャーでは、アプリケーションは、イベントを生成するか取得するイベントプロデューサー、またはイベントを処理して、それに基づいて対応するイベントコンシューマーとして機能します。プロデューサーは、イベントブローカー(メッセージング指向のミドルウェア)を介して、コンシューマーにリアルタイムでイベントを送信します。その後、コンシューマーはイベントを処理し、他のアクションやワークフロー、イベントをトリガーすることができます。このような設計により、データストリームの入力に対してリアルタイムの対応やスマートな意思決定が可能になります。
イベントブローカーは、プロデューサーとコンシューマーを接続するイベントチャネルを管理し、確実にイベントを配信するとともに、多くの場合、フィルタリング、永続化、リプレイなどの機能を提供します。イベントブローカーは、プロデューサーとコンシューマーの分離によって、システムの回復力と拡張性を向上させます。
単一のプロデューサーと単一のコンシューマーが互いに直接通信する非常に単純なアーキテクチャーの場合、イベントブローカーは任意になります。しかし、ほとんどの企業では、複数のソースが複数のコンシューマーにイベントを送信するため、ブローカー、あるいはブローカーのネットワーク(「イベントメッシュ」とも呼ばれる)が必要です。イベントブローカーやイベントメッシュを使用すると、アプリケーションの「疎結合」が生まれます。
同期通信と非同期通信
イベント駆動型アーキテクチャーで同期通信が行われると、イベントプロデューサーは次の処理に進む前に、受け手の処理と応答を待機します。例として、Web クライアントが HTTP リクエストを送信し、サーバーの応答を待機する場合が挙げられます。通常、同期通信の各コンポーネントは密結合されており、負荷が大きければ処理速度は低下します。このため、コンシューマーから応答を受信するまで、プロデューサーは次のタスクの実行を「ブロック」されます。
イベント駆動型アーキテクチャーで非同期通信が行われると、プロデューサーは即時応答を待たずに処理を続行し、イベントコンシューマーは後でメッセージを処理することができます。例として、システムがイベントをイベントブローカーに公開し、各コンシューマーが個別にイベントを処理する場合が挙げられます。非同期通信では、タスクはブロックされず、各コンポーネントは疎結合されています。拡張性が高く、リアルタイムシステムや分散システムがうまく機能します。
イベント駆動型アーキテクチャーにおけるリクエスト駆動型モデルとイベント駆動型モデルの比較
リクエスト駆動型モデルでは、イベントコンシューマーからサーバーへのリクエストによってインタラクションが開始され、これにサーバーが応答します。このモデルはプルベースです。つまり、コンシューマーは自動更新を受信するのではなく、サーバーからのデータやサービスが必要になったときに主体的に要求します。同期式の場合も非同期式の場合もあります。リクエスト駆動型モデルは、従来の Web アプリケーションや API で一般的です。
イベント駆動型モデルでは、インタラクションはイベント(処理をトリガーする状態変化やアクション)によって開始され、公開/購読などのイベントが発生すると、コンポーネントが自動的に対応します。このモデルは典型的なプッシュベースです。つまり、コンシューマーが要求するのを待たず、イベントや更新が発生するとすぐに、コンシューマーに自動的に送信(「プッシュ」)されます。イベント駆動型モデルは非同期式かつ分離型で、リアルタイムの対応に最適です。
モデル間の主な違いは、リクエスト駆動型モデルでは、ユーザーは必要なときにデータを要求しますが、イベント駆動型モデルでは、何かが発生したときに自動的に対応する点です。
一般的なイベント駆動型アーキテクチャーのパターン
イベント駆動型アーキテクチャーのパターンとは、イベント駆動型システムがイベントを取得して、処理および消費する方法を定義する一般的な設計アプローチです。パターンは、拡張性に優れた分離方式で通信や状態変化を処理するための再利用可能な方法を示します。システムの設計時や導入時にイベント駆動型アーキテクチャーのパターンを適用して、一般的な課題を解決できます。例えば、非同期式かつ疎結合の環境におけるイベント配信、データの一貫性、拡張性などの課題があります。
イベント駆動型アーキテクチャーにおけるイベントの送信には、主に 4 つのパターンがあります。
- 公開/購読(別名「pub/sub」):pub/sub では、イベントコンシューマーがイベントプロデューサーによって公開されたメッセージおよびチャネルを購読します。イベントが公開されると、イベントブローカーを使用してすべてのサブスクライバーに直接送信されます。重複を避けるため、一度消費されたイベントはリプレイしたり、アクセスしたりすることはできません。ブローカーがこれらのイベントを削除するからです。
- イベントストリーミング:イベントストリーミングでは、プロデューサーがイベントのストリーム全体をブローカーに公開します。コンシューマーはストリームを購読し、ストリームのどの部分からでも読むことができ、関連するイベントだけを消費することができます。イベントストリーミングでは、イベントは消費された後もブローカーによって保持されます。
- コマンドクエリ責任分離 (CQRS):CQRS パターンでは、アプリケーションの設計とアーキテクチャーのレイヤーによって、読込操作と書込操作が別々のモデルに分離されます。コマンドは状態を更新し、クエリは状態を読み込みます。イベント駆動型アーキテクチャーでは、CQRS パターンがイベントと連携して変更を非同期式で伝播することが多く、複雑なシステムの拡張性と性能が向上します。
- イベントソーシング:イベントソーシングでは、エンティティの現在の状態のみを保存するのではなく、すべての状態変化が追加専用ログにイベントとして記録されます。現在の状態は、これらのイベントをリプレイして再現できます。これにより、完全な監査証跡が提供され、タイムトラベルシナリオやリカバリシナリオがサポートされます。
イベント処理スタイル
イベント処理スタイルとは、イベントの検出、解釈、および処理の方法を示します。これにより、ロジックの複雑さ、タイミング、およびシステムで認識されるイベント間の関係が定義されます。コンシューマーに到達したイベントを処理するには、単純なイベント処理、複雑なイベント処理、イベントストリーム処理の 3 つの異なるアプローチがあります。
1. 単純なイベント処理:コンシューマーは各イベントを受信時に処理します。以下に例を示します。
- 顧客が発注を行うと、確認メールの送信と在庫の更新がシステムに指示されます。
- パスワードリセットのリクエストによって、セキュアリンク付きのメールが即座にトリガーされます。
- 決済が正常に終了すると、領収書が作成され、顧客に送信されます。
- ユーザーログインが、セキュリティ追跡用に即時記録されます。
2. 複雑なイベント処理:コンシューマーは一連のイベントを処理してパターンを検出し、結果に基づいてアクションを実行します。以下に例を示します。
- 複数の高額取引がたて続けに発生すると、不正アラートが通知されます。
- 温度の上昇と振動の増加が同時に起こると、機器が故障する危険が示されます。
- 数分の間にさまざまな国からログインが試行された場合、セキュリティ警告がトリガーされます。
- 1 人のユーザーがカート放棄を繰り返した場合に、パーソナライズされた割引オファーが表示されます。
3. イベントストリーム処理:コンシューマーはデータストリーミングプラットフォームを使用して、絶え間なく流れるデータ(移動中のデータ)をリアルタイムで処理し、それに基づいて動作します。以下に例を示します。
- 株価が変動すると、事前定義されたルールに基づいた取引が即時実行されます。
- ソーシャルメディアのメンションが急増すると、センチメントダッシュボードが即座に更新されます。
- コネクテッドカーからのテレメトリーにより、交通信号が動的に調整されます。
- e コマースサイトから収集したクリックストリームデータにより、リアルタイムの製品おすすめ機能が強化されます。
企業は、それぞれのニーズとユースケースに基づいて、イベント処理スタイルを選択します。
イベント駆動型アーキテクチャーの仕組み
イベント駆動型アーキテクチャーは、分散システムを横断してイベントをリアルタイムに公開、取得、処理、さらにこれに応答するための統合モデルです。あるアプリケーションでイベントが発生すると、それを把握する必要がある他のすべてのアプリケーションにメッセージが自動的に送信されるため、順番に処理を行うことができます。
以下に、イベント駆動型アーキテクチャーの仕組みを順を追って示します。
- イベントの発生:例えば、顧客が発注を行った、センサーが温度スパイクを検出した、決済できなかった、などの重要な状態変化が発生します。
- イベントプロデューサーによるイベントの発行:イベントが発生したアプリケーションはプロデューサーとして機能し、イベントをイベントブローカーに公開します。
- イベントブローカーによるイベントのルーティング:イベントブローカーは、イベントチャネルを管理し、関連するすべてのイベントコンシューマーにイベントを配信する仲介者として機能します。これにより、通信の信頼性と拡張性を保証し、分離を確実に行います。
- イベントコンシューマーによるイベントへの対応:イベントチャネルを購読したアプリケーションやサービスがイベントを処理し、在庫の更新、確認メールの送信、アラートのトリガーなどの適切なアクションを実行します。
イベントベースのアーキテクチャーは、非同期式かつ分離型です。つまり、アプリケーションはリアルタイムで情報を共有してタスクを完了するために、相互に認識する必要がありません。イベント情報(メッセージ)は、アプリケーション間で自由かつ自動的に行き来することが可能です。その結果、イベント駆動型アーキテクチャーモデルは、従来のリクエスト駆動型モデルおよびレスポンス駆動型モデルよりもはるかに高速で、高い回復力を備えています。従来のモデルでは、あるアプリケーションが必要とする特定の情報を別のアプリケーションに要求し、応答を待ってから次のタスクに進む必要がありました。また、イベント駆動型アーキテクチャーは分離型であるため、マイクロサービス通信のベストプラクティスであると広く考えられています。
ユースケースと実際の例
イベント駆動型アーキテクチャーは、銀行、小売、製造、物流など、幅広い業種で最新のデジタルエクスペリエンスに活用されています。AI を活用した自動化、イベントインテリジェンス、リアルタイムの応答性を実現するイベント駆動型アーキテクチャーにより、IT のモダナイゼーション、レガシーシステムの分離、マルチクラウド環境全体のシームレスな運用が可能になります。
以下の例は、イベント駆動型アーキテクチャーの実際の機能を示しています。
レストラン業界
- 大学生がフードデリバリーアプリケーションを使用してピザを注文します。このアプリケーションでは、大学生の基本情報(名前、住所、支払情報、注文)が取得され、「ピザ注文」イベントが公開されます。
- ピザレストランはイベントを購読し、注文を遂行し、自らの「注文準備完了」イベントをフードデリバリーサービスに公開します。
- 次に、フードデリバリーサービスは、配達ドライバーを割り当て、ETA をスケジュールし、顧客にピザが配達中であることを通知します。
e コマース
- オンラインショッピングの利用者が e コマースサイトにクレジットカード情報を入力すると、「支払送信済み」イベントが公開されます。
- 支払システムはイベントを購読し、支払を処理し、成功または失敗を示す自らの「支払処理済み」イベントを発行し、それをウェブサイト UI に送り返します。
- UI は顧客に支払状況を表示し、次のステップを促します。
さらに、イベント駆動型アーキテクチャーの例を示します。
IoT テレメトリー
- スマートファクトリーは、センサーデータをストリーミングして温度スパイクを検出し、設備の故障を防ぎます。
- コネクテッドカーは、テレメトリーを送信して、交通の流れを動的に最適化します。
- スマートホームデバイスは、エネルギー使用イベントを公開して、コスト削減に関する提案をトリガーします。
アナリティクスおよびイベントインテリジェンス
- 小売企業では、クリックストリームデータをリアルタイムで分析して、おすすめ製品をパーソナライズします。
- 銀行では、取引パターンをモニタリングして、不正が発生する前に検出します。
- 物流企業では、ストリーミングデータを用いて納入遅延を予測し、出荷の経路を再設定します。
自動化
- 人事システムでは、ライセンスや権限の割当など、新入社員のソフトウェアアクセスが自動的にプロビジョニングされます。
- 医療システムでは、患者のバイタルが重大なしきい値を超えると、自動アラートがトリガーされます。
- クラウドプラットフォームは、ワークロードイベントに基づいてリソースを動的にスケーリングします。
財務トランザクジョン
- 決済ゲートウェイによって「支払送信済み」イベントが公開され、承認前の不正チェックがトリガーされます。
- 取引プラットフォームは、株価の変動に応じて即座に売買注文を実行します。
- 銀行は、預金を転記し、口座残高をリアルタイムで更新します。
サプライチェーン
- 倉庫で在庫レベルが更新されると、補充指図が自動的にトリガーされます。
- 配送サービスでは、交通および気象イベントに基づいてリアルタイムでドライバーの経路を再設定します。
- 製造企業では、リアルタイムの需要シグナルに基づいて生産日程計画を調整します。
IT のモダナイゼーションとレガシーの分離
- 主要機能向けの最新クラウドサービスにビジネスイベントを公開して、メインフレームの作業負荷を軽減します。
- 従来の ERP に関連するリアルタイムのイベントインターフェースを公開すると、新しいアプリケーションはバックエンドに接触することなく即座に対応できます。
- 旧式の CRM から最新の SaaS プラットフォームにイベントをミラーリングして、段階的な移行の際に両システムの同期を取ります。
通知
- 公益事業者では、停電が検出された地域の顧客に瞬時に状況を知らせ、復旧担当者の進捗に応じて通知を更新します。
- 出張アプリケーションでは、フライトのゲート割り当てが変更されるとアラートをリアルタイムで乗客に送信するため、乗客はすぐに計画を調整できます。
- ユーザーが番組を見終わると、ストリーミングサービスがパーソナライズされたおすすめを送信します。
- 疑わしいログインアクティビティが検出されると、セキュリティシステムからアラートがプッシュされます。
一般的なイベント駆動型アーキテクチャーのユースケースには、以下が挙げられます。
- オンラインショッピングの利用者が商品をクリックし、システムが類似商品に基づいて推奨商品を生成して応答します。
- 小売業者がグローバルな取引において不正行為の有無を審査し、疑わしい購入があればクレジットカード会社に報告します。
- リアルタイムのカスタマーエンゲージメントでは、ユーザーの行動データをストリーミングして、買い物をしている間にパーソナライズされたオファーや動的な価格設定をトリガーします。
- 医療モニタリングでは、コネクテッドデバイスから患者のバイタルサインを公開し、しきい値を超えたらすぐに臨床医にアラートを送信します。
- スマートシティのオペレーションでは、リアルタイムの交通および気象イベントに基づいて、交通信号や公共交通機関のスケジュールを管理します。
- サイバーセキュリティの脅威検出では、疑わしいネットワークアクティビティや不正なアクセスの試行をリアルタイムで特定し、対応します。
- クラウドリソースの最適化では、ワークロードが急増すると、マルチクラウド環境全体でコンピューティングリソースが自動的にスケーリングされます。
SAP 製品
回復力に優れたイベント統合
プロデューサーとコンシューマーを分離するブローカーの分散メッシュを使用して、独立したスケーリング、障害分離、および継続的なアップタイム(トラフィックやユースケースの増加時も含む)を実現します。
イベント駆動型アーキテクチャーのメリット
組織は、イベント駆動型アーキテクチャーの利点を最新のシステムに適用することができます。イベント駆動型アーキテクチャーの主なメリットは以下のとおりです。
- リアルタイムの応答性とインテリジェントなワークフロー:イベント駆動型アーキテクチャーにより、イベント発生時にシステムが即座に対応し、自動化されたワークフローと意思決定をリアルタイムでトリガーすることができます。これは、需要ピーク時、例えば、大きな販売イベントや祝祭日には特に重要です。組織は、このような応答性を日常の業務に適用し、サプライチェーンの自動化や不正検知からパーソナライズされたカスタマーエンゲージメントまで、あらゆる業務を改善することができます。
- 非同期通信を用いたスピードと効率:イベント駆動型アーキテクチャーのアプリケーションは非同期で通信します。つまり、プロデューサーはイベントメッセージを公開すると、コンシューマーによるイベントメッセージの受信を待つことはありません。このノンブロッキングアプローチにより、パフォーマンスが向上し、遅延時間が短縮され、ボトルネックなしで大量のイベントを処理できるようになります。
- 分離と疎結合による柔軟性と拡張性:イベント駆動型アーキテクチャーの各コンポーネントは分離または疎結合しているため、互いの可用性や内部ロジックに依存せず、独立して動作します。これにより、システム全体を中断することなく、サービスを簡単に更新、テスト、およびデプロイすることができます。また、分離によって、必要に応じてプロデューサーやコンシューマーを追加することが容易になり、ビジネスニーズの拡大に合わせてシームレスな拡張が可能です。
- 回復力と障害分離:サービスが分離されていれば、1 つのコンポーネントで障害が発生してもシステム全体に波及しません。また、サービスの障害は個別に発生するため、従来の密結合のモデルよりも耐久性と耐障害性に優れたアーキテクチャーになっています。
- 将来を見据えた統合:疎結合および非同期式で設計されたイベント駆動型アーキテクチャーは、IT のモダナイゼーション、レガシーシステムの分離、マルチクラウド運用に最適です。コアシステムを書き換えることなく、AI を活用した自動化やイベントインテリジェンスなどの新しいテクノロジーを柔軟に統合できます。
課題、制限、ベストプラクティス
イベント駆動型アーキテクチャーには大きな利点がありますが、設計上および運用上の新たな課題も生じるため、組織は対策を講じる必要があります。イベント駆動型アーキテクチャーを導入する場合は、以下のイベント駆動型アーキテクチャーの課題、制限、ベストプラクティスを考慮して、拡張性が高く回復力があり、適切に管理されたイベント駆動型システムとします。
課題
- 複雑な分散システム:複数の環境を横断するイベントブローカーのメッシュを管理すると、アーキテクチャーが複雑になります。イベントフローを設計し、スキーマの一貫性を確保して、非同期通信を処理するには、高度な計画と専門知識が必要です。設計を適切に管理しなければ、イベントの量、プロデューサー、コンシューマーが増加するにつれて、イベントの混乱に直面する可能性があります。
- ガバナンスとコンプライアンス:ハイブリッド環境やマルチクラウド環境でイベントが行き来すると、データプライバシー、セキュリティ、法規制コンプライアンスなどのガバナンスポリシーの適用は困難になります。データ漏えいや不正アクセスを防止し、急速に拡大するイベントランドスケープの統制を維持するには、堅牢なガバナンスフレームワークが必要です。
- デバッグと可観測性:非同期の疎結合システムでトラブルシューティングを行うのは、従来のアーキテクチャーで実施するよりも複雑です。障害や遅延の根本原因を特定するには、高度なモニタリング、トレース、およびイベントのリプレイ機能が必要です。このことは特に、複雑なイベントチェーンから生じた問題をチームがトラブルシューティングしたり、イベントが混乱する兆候を解決したりする場合に当てはまります。
イベントメッシュの適合性
イベントメッシュは、さまざまなハイパースケーラーを横断して、また、プライベート環境、ハイブリッド環境、およびマルチクラウド環境で、複数のイベントブローカーを接続するアーキテクチャー機能です。イベントメッシュは、イベントストリーミング、イベント管理、モニタリング、動的メッセージルーティング、きめ細かなフィルタリングのような、高度なイベントサービスの万能セットを提供します。イベントブローカーを分散メッシュに接続することで、組織は以下のことが可能になります。
- イベントのルーティングと管理を一元化して、複雑さを軽減します。
- イベントのカタログ、スキーマ適用、モニタリングによって、ガバナンスをサポートします。
- イベントのトレース、リプレイ、高度なアナリティクスによって、可観測性を向上させます。
- ハイブリッド環境やマルチクラウド環境で 拡張性と回復力を実現 します。
イベントメッシュは、最新システムのバックボーンとして、拡張性が高くリアルタイム対応の可能なイベント駆動型アーキテクチャーの基本レイヤーを構成します。これにより、リアルタイムの応答性を確保しながら、統合を簡素化し、イベントの混乱を減らし、分散環境全体のトラブルシューティング機能を強化することができます。
イベント駆動型アーキテクチャーの制限
- 運用のオーバーヘッド:イベント駆動型システムには、イベント管理、スキーマ検証、およびモニタリングのための特別なツールが必要です。これにより、運用が複雑になる可能性があります。
- スキル要件:イベントメッシュとイベント駆動型アーキテクチャーのパターンを導入して維持するには、分散システム、イベントブローカー、および統合プラットフォームの専門知識が必要です。
- 遅延リスク:イベント駆動型アーキテクチャーはリアルタイムの応答性を目的に設計されていますが、イベントルーティングの設定が不十分であったり、ブローカーに過度な負荷がかかっていたりすると、遅延が生じる可能性があります。
イベント駆動型アーキテクチャーのベストプラクティス
- スキーマおよびイベント契約の標準化:スキーマレジストリを使用し、検証を実施して、プロデューサーとコンシューマー間の一貫性を維持します。
- 強力なガバナンスの導入:イベントのオーナーシップ、セキュリティ、およびコンプライアンスに関する明確なポリシーを定義します。監査とアクセス制御のためのツールを活用します。
- 可観測性の強化:モニタリングおよびトレースソリューションを導入して、イベントフローの追跡や異常の検出を行い、デバッグを簡素化します。
- 拡張性と回復力を確保する設計:動的ルーティングやきめ細かいフィルタリングなどのイベントメッシュ機能を使用して、性能と耐障害性を最適化します。
- AI とイベントインテリジェンスによる自動化:AI を活用したアナリティクスと自動化を組み込んで、問題の予測、ルーティングの最適化、意思決定の改善にリアルタイムで対応します。
イベント駆動型アーキテクチャーの特性
本質的に、イベント駆動型アーキテクチャーが分散環境、ハイブリッド環境、マルチクラウド環境に適しているのは、複数の決定的な特性を持っているからです。
- 非同期通信:イベント駆動型アーキテクチャーの基本特性。アプリケーションは従来のリクエスト駆動型モデルのように直接の応答を待つことなく、イベントを公開して遅延なく動作を続けます。このノンブロッキングスタイルにより、分散システムを横断したリアルタイムインタラクションが可能になり、負荷が高い場合でも応答性が向上します。
- 疎結合:アプリケーションは、互いの可用性、API 構造、または内部ロジックを意識する必要はありません。単にイベントブローカーまたはイベントメッシュによってルーティングされたイベントを介して通信します。イベントのプロデューサーとコンシューマーが独立して動作することで、チームは広範なシステムを中断することなく、サービスの追加、更新、または置換を行い、俊敏性と耐障害性を高めることができます。
- 独立したスケーリング:各コンポーネントが分離されているため、上流または下流のアプリケーションを変更しなくても、個々のサービスを需要に基づいて拡大または縮小できます。SAP はこの点が、特にピーク負荷と分散ワークロードを効率的に管理する必要があるハイブリッド環境およびマルチクラウド環境において、イベント駆動型の統合の主なメリットであると考えています。
これらの特性を組み合わせることで、イベント駆動型アーキテクチャーは、マイクロサービスのサポートやクラウド環境の統合、イベント駆動型のビジネスプロセスアプリケーションの有効化などを行う場合に、回復力、適応性、成長に向けた準備を整えたリアルタイムシステムを構築するための強力なアプローチになります。
FAQ(よくある質問)
イベント駆動型アーキテクチャーとリクエスト駆動型アーキテクチャーの主な違いは、システムが通信し、変化に対応する方法です。リクエスト駆動型モデルでは、コンシューマーがサーバーに対してデータまたはアクションを要求するとインタラクションが開始され、これにサーバーが応答します。このモデルは通常、同期式です。つまり、リクエスト側が応答を受信するまで待機(ブロック)する、プルベースです。アプリケーションは、更新を要求した場合のみ更新を受信します。
イベント駆動型モデルでは、イベントの発生時(ビジネスシステムにおける重要な状態変化)にインタラクションが開始され、アプリケーションが自動的に対応します。イベント駆動型システムは非同期式であるため、プロデューサーはイベントを公開すると、コンシューマーの応答を待つことはありません。このようなプッシュベースの疎結合モデルにより、アプリケーションは独立して動作し、分散環境、ハイブリッド環境、およびマルチクラウド環境でリアルタイムでイベントを処理することができます。
イベント駆動型アーキテクチャの主なコンポーネントは、プロデューサー、コンシューマー、イベントブローカー、およびイベントチャネルです。これらのコンポーネントを組み合わせることで、非同期式で結合のゆるやかなイベントフローが作成され、分散環境、およびハイブリッド環境、マルチクラウド環境で、拡張性の高いリアルタイムインタラクションが可能になります。
- プロデューサー:オーダーの更新、決済、センサーの読取などのイベントを生成または取得し、イベント駆動型システムに公開するアプリケーション。
- コンシューマー:ワークフローのトリガー、データの更新、通知の送信、または下流プロセスの開始など、イベントの購読、処理、および対応を行うアプリケーション。
- イベントブローカー:プロデューサーからコンシューマーにイベントをルーティングするメッセージングミドルウェア。信頼性の高い配信、フィルタリング、動的ルーティング、永続化、リプレイなどの機能を提供します。
- イベントチャネル:プロデューサーとコンシューマーを接続するイベントブローカーが管理する経路。プロデューサーはイベントをチャネルに公開し、コンシューマーは関連するチャネルを購読します。
イベント駆動型アーキテクチャーのパターンとは、イベント駆動型システムにおけるイベントの取得、ルーティング、保存、および消費方法を定義する、再利用可能な設計アプローチです。イベント駆動型アーキテクチャーの主なパターンは以下のとおりです。
- 公開/購読 (pub/sub):プロデューサーはイベントをチャネルに公開し、複数のコンシューマーが自動的に購読および対応します。
- イベントストリーミング:プロデューサーはイベントの連続ストリームをブローカーに公開し、コンシューマーはストリーム内の任意の箇所でイベントの読込、リプレイ、または処理を行うことができます。
- コマンドクエリ責任分離 (CQRS):読込操作と書込操作は異なるモデルに分割され、更新は非同期式で伝播されます。
- イベントソーシング:すべての状態変化が不変のイベントとして追加専用ログに保存されており、イベントのリプレイによって現在の状態を再現します。
イベント駆動型アーキテクチャーを使用する主なメリットは以下のとおりです。
- 疎結合:アプリケーションは互いの内部を意識せず独立して動作するため、更新、統合、拡張が容易になります。
- 拡張性:新しいプロデューサーとコンシューマーをシームレスに追加できます。ワークロードは、ハイブリッド環境やマルチクラウド環境でスケーリングできます。
- 回復力:分離型のサービスにより障害が分離されるため、1 つのコンポーネントがダウンしてもシステム全体に影響が及びません。
- スピードとリアルタイムの応答性:非同期式のノンブロッキング通信により、システムはビジネスイベントに即座に対応し、大量のデータを低遅延で処理することができます。