参考記事
本記事は以下の二冊をもとに作成しています。アーキテクトを目指す人に対しておすすめの二冊です。
気になった方はこのページから購入していただけると自分に少しお小遣いが入るので差し入れとしてお願いいたします!
なぜイベント駆動アーキテクチャを採用するのか?
イベント駆動型アーキテクチャスタイルは、非同期通信のみに依存するという点で、他のアーキテクチャスタイルに比べて独自の特徴を提供します。
非同期通信は、システムの全体的な応答性を向上させるための強力な手法 です。
著作:「イベント駆動アーキテクチャ」より
イベント駆動アーキテクチャは高度にスケーラブル(弾力性が高い)で高パフォーマンスなアプリケーションを実現できるアーキテクチャです。
また、適応性に優れており、小規模なアプリにも大規模なアプリにも使うことができるのも特徴です。
非同期通信とは?
非同期通信は、ユーザー側から見た応答速度を上げるための手法です。
処理を開始した後、その処理を待たずに次の処理を開始するのが特徴。 処理の完了を待たないため、ロジックは複雑になるが、アプリケーションの軽快な動作を実現することができます。
https://codezine.jp/article/detail/11815
イベント駆動アーキテクチャの使用例
応答速度が旨となるシステムでリクエストベースかつ、複雑な仕様を持つ場合に使用される。
オンラインオークションでの入札システム
ECサイト(注文後から決済を経て発送やメール通知などをイベント通知として処理する)
コメント投稿サイト(アプリケーションで軽快な動作を実現したい場合)
イベント駆動アーキテクチャの構成
イベント駆動アーキテクチャは分散非同期型のアーキテクチャスタイルです。 このアーキテクチャを実装したアプリケーションは、いわゆる要求ベースのモデルに従います。
まずこのモデルではシステムに対して行われたリクエストは全て、要求オーケストレーターに送信されます。
リクエストオーケストレーターはユーザーインターフェイスですが、APIレイヤーとして実装することもできます。(ブローカータイプには存在しません) 主な役割はさまざまなリクエストプロセッサーにリクエストを送信することです。
イベントプロセッサは、データベース内の情報を取得または更新して要求を処理し、どんな処理を行ったかを載せたメッセージ(イベント)を再び全体に通知します。(イベントのブロードキャスト)
各イベントプロセッサは、「これは自分が処理するべきイベントだな」と判断した場合には、イベントを処理して再度どんな処理を行ったかを全体に通知します。
受け取るプロセッサがいなくなるまで、処理を行います。
以下にその図を示します。
著作:「イベント駆動アーキテクチャ」より
イベント駆動アーキテクチャの概要
イベント駆動アーキテクチャには、メディエータートポロジとブローカートポロジの2タイプがあります。
- メディエータートポロジは、イベントプロセスのワークフローを制御する必要がある場合に一般的に使用されます。(メディエイターとは、調停者という意味でワークフローを調節する役割を持ちます。)
- ブローカートポロジは、イベントの処理に対して高度な応答性と動的制御を必要とする場合に使用されます。全体を管理するメディエイターという存在がいません。
イベント駆動アーキテクチャの「イベント」について
イベント駆動アーキテクチャを理解するために必要なのは、イベントという考え方を理解することです。
イベント駆動アーキテクチャの「イベント」とは次の二つの解釈が可能です。
- イベント通知
このイベントとは「何かが発生したこと」を意味します。
- コマンド
この「コマンド」とは「何か命令がある」という意味で、「メッセージ」とも受け取ることができます。
イベント駆動アーキテクチャにおけるイベントとは、この二つの側面があり、ある意味でこのイベントこそがイベント駆動アーキテクチャの強みとなっているのです。
イベントを発生される側から見た場合。イベントを処理した後の結果は、「産まれてしまったもの」なので通知です。
イベントを受け取る側から見た場合。イベントを処理するためのメッセージは、「どんな処理をするべきか書いてある」のでコマンドです。
いずれにせよ、イベントアーキテクチャにおけるイベントとは、メッセージであり、コマンドなのです。
イベント駆動アーキテクチャ - ブローカータイプ -
ブローカートポロジは、中央イベントメディエーターがないという点でメディエータートポロジとは異なります。
よく使われるのは、
- オンラインオークションに入札するような単純なイベント
- 転職や結婚などの健康給付システムにおけるより複雑なイベント
などです。
とにかく高速な処理を行いたい場合に採用されます。メディエイターなどの調停者を挟まない方が早くなるからです。
メディエイターがあっても全体の応答速度は悪くないですが、ブローカータイプには及びません。
イベント駆動アーキテクチャのブローカータイプの実装方法
イベント駆動アーキテクチャでは、軽量のメッセージブローカーと呼ばれるものを介して、チェーン状のブロードキャスト方式で処理を行う。
RabbitMQ
HornetQ
https://activemq.apache.org/clustering
ブローカータイプの構造
リクエストを受け付けた後、開始イベントは、メッセージブローカーに送られます。
イベントを管理および制御するブローカー・トポロジーでは、単一のイベント・プロセッサーがイベント・ブローカーからの開始イベントを受け入れ、そのイベントの処理を開始します。
開始イベントを受け入れたイベントプロセッサは、そのイベントの処理に関連する特定のタスクを実行します。
その後、再度処理イベントと呼ばれるものを作成することによって、システムの残りの部分にそれが行ったことを非同期的に連絡します。
イベント通知は再度、メッセージブローカに送られます。
このプロセスは、最終的なイベントプロセッサが何をしたかに誰も興味がなくなるまで続きます。
ブローカータイプのメリット
このアーキテクチャにおいてイベントプロセッサがイベント通知を発火する際、他のイベントプロセッサがどう受け取るかを考えずにイベント通知をブロードキャストします。
これはとても良い設計です。 なぜならこの方法は、システム改修時点でそのイベントの処理に追加の機能が必要な場合に、アーキテクチャの拡張性を提供します。
ブローカータイプの開発事例例
たとえば、複雑なイベントプロセスの一部として、電子メールが生成され、実行された特定のアクションを顧客に通知するとします。
通知イベントプロセッサは、
電子メールを生成して送信し
通知のブロードキャストを通じて、そのアクションをシステムの残りの部分に連絡します。
この場合、他のイベントプロセッサはそのトピックに関するイベントをリッスンしていないため、メッセージは単に消えます。
これは、アーキテクチャの拡張性の良い例です。
無視されるメッセージを送信するリソースの浪費のように見えるかもしれませんが、そうではありません。
ex) 例えばここで、顧客に送信された電子メールを分析するための新しい要件が発生したとします。
この新しいイベントプロセッサは、インフラストラクチャを追加したり、他のイベントプロセッサを変更を適用したりする必要がないのです。
電子メールトピックを介して新しいアナライザに電子メール情報を提供できるため、最小限の労力でシステム全体に追加できます。
あたかも、プラレールのレールの出っ張りが、現時点で途切れていてもいつか来る接続に必要であるように。
イベント駆動アーキテクチャ メディエイターパターンとは
イベントメディエーターは前節で説明したブローカートポロジーの欠点をいくつか解消できる。
イベントメディエーターパターンの中心には常に「イベントメディエーター」というコンポーネントが存在する。
このイベントメディエーターは、イベント処理に必要なステップを知っており、対応する処理イベントを生成してP2Pのメッセージング方式でイベントチャネルに送信する。
イベントチャネルは受け取ったメッセージをもとに処理を実施するが、完了した報告をイベントメディエーターに行う。
イベントメディエイターの実装方法
イベントメディエーターは次のいくつかの候補がある
これらのOSSソフトウェアは、単純なエラー処理とオーケストレーションが可能になっている。
(Spring Intergration)https://spring.pleiades.io/spring-integration/docs/current/reference/html/samples.html
しかし、さらに複雑な処理が必要な場合、次の二つのイベントメディエーターが候補に上がる。
多くの条件付きの処理や複雑なエラー処理の指示を伴う複数の動的パスが発生する場合には、これらのメディエーターが候補になるだろう。
(Oracle BPEL Process Manager)https://docs.oracle.com/cd/E18355_01/integrate.1013/B31876-01/intro.htm
これらのメディエーターは Business Process Execution Language(BPEL)に基づいたかなり高レベルなビジネスプログラミングが可能になっている。
BPELとは、イベント処理のステップを記述したXMLライクな構文である。 その中には、エラー処理、リダイレクション、マルチキャストなどに使用される構造化要素も含まれる。 BPELの習得は困難なため、通常は製品に含まれるBPELエンジンで自動生成される。
イベント駆動アーキテクチャのエラー処理
コンポーネント同士で意思の疎通が取れない場合はどうすれば良いか。
それは以下のように、エラー時に通常のコンポーネントではなく、エラーを処理するコンポーネントに送ることで対応が可能である。
エラーを処理するコンポーネントでは、通常GUIとしてダッシュボードなどに表示される。
ダッシュボードにはエラーメッセージと、エラーを起こした処理が表示される。
このエラーを人間が手で修正し、再度エラーを起こしたコンポーネントに送信することで処理が可能である。
(ソフトウェアアーキテクチャの基礎)https://www.amazon.co.jp/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%81%E3%83%A3%E3%81%AE%E5%9F%BA%E7%A4%8E-%E2%80%95%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%83%AA%E3%83%B3%E3%82%B0%E3%81%AB%E5%9F%BA%E3%81%A5%E3%81%8F%E4%BD%93%E7%B3%BB%E7%9A%84%E3%82%A2%E3%83%97%E3%83%AD%E3%83%BC%E3%83%81-Mark-Richards/dp/4873119820/ref=sr_1_1?adgrpid=131625207761&gclid=Cj0KCQiA1NebBhDDARIsAANiDD2t3qdCpELaQBYWcwVkCNTRj_WZlDhp3HAMMRjFvIZR_EtRgQRvu0EaArxhEALw_wcB&hvadid=611338421233&hvdev=c&hvlocphy=1009310&hvnetw=g&hvqmt=e&hvrand=8686801961371880672&hvtargid=kwd-1637204896522&hydadcr=21901_13398700&jp-ad-ap=0&keywords=%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%81%E3%83%A3+%E3%81%AE+%E5%9F%BA%E7%A4%8E&qid=1668749043&qu=eyJxc2MiOiIwLjcyIiwicXNhIjoiMC4wMCIsInFzcCI6IjAuMDAifQ%3D%3D&sr=8-1
AWSでイベント駆動アーキテクチャを実装すると...
Qiitaで良い記事が見つかった。
じゃあイベントドリブンアーキテクチャを構築するためにはどうすればいいのか? 調べていたところ、DynamoDB Streamを活用した例をよく見かけました。 DynamoDBStreamとは、テーブル操作が行われた際にキャプチャができる機能で、 これを活用するとテーブル操作を検出しLambdaを発火させることができます。 下図はDynamoDB Streamを活用したイベントドリブンアーキテクチャの構成図です。
https://qiita.com/Suzuki_Cecil/items/a51d353c73e9277f46d8
イベント駆動アーキテクチャの総評
ワークフローの確実性と制御が必要な場合は、適切に構造化されたデータ駆動型のリクエスト(顧客プロファイルデータの取得など)に対してリクエストベースのモデルを選択することをお勧めします。
例えば、ECの注文処理など。
複雑で動的なユーザー処理を伴う、高レベルの応答性とスケールを必要とする柔軟なアクションベースのイベントには、イベントベースのモデルを選択しましょう。
備考
title:イベント駆動アーキテクチャのメリットとデメリットと使用例
description:イベント駆動型アーキテクチャスタイルは、非同期通信のみに依存するという点で、他のアーキテクチャスタイルに比べて独自の特徴を提供します。非同期通信は、システムの全体的な応答性を向上させるための強力な手法です。
category_script:(page_name.startswith("2") or page_name.startswith("1"))
参考資料:https://qiita.com/Suzuki_Cecil/items/a51d353c73e9277f46d8