[イベント駆動型アーキテクチャ] まとめ
前回は、わたしの考えたイベント駆動型アーキテクチャ例を紹介しました。
今回は最終回です。さみしいです。もっと詳細化して、一冊の本にしたい気持ちを抑えての最終回です。今回の内容は、イベント駆動にすると、どんな良いことがあるのかのまとめです。
イベント駆動型アーキテクチャの良さ
大きく三つの利点が生まれます
疎結合でシンプル
たとえば、イベントバスとなる"Apache Kafka" は複雑なソフトウェア構成ですが、それを利用して開発されるアプリケーションはシンプルです。何がシンプルかというと、相手を知る必要がないからです。
通常、後続のプロセスへ連携する場合には、そのプロセスがどのように処理されるかを知らなければ連携ができません。
相手先とはどのように接続するのか。認証や認可の方式はどうなっているのか。必要なデータをどのように渡すか。データのフォーマットや文字コードはきまっているか。返ってくる値はどのようなフォーマットで、何が返ってくるのか。障害が起きた場合、どのようなリアクションをしてくるのか。などなど…。
一つ一つの相手先に対して、具体的な連携の仕組みを考える必要があります。「RESTfulだからカンタンだろ」みたいになると思ったら大間違いです。データフォーマットや文字コードの規定はないです。まぁ、ちゃんとガバナンス利かせておきましょうと言うことです。が、全ての仕組みにガバナンスが利くとは限りません。このような傾向にあるので、非常に連携が密結合に陥りやすいのです。プロトコルだけではダメなんです。
しかし、"Apache Kafka" などの Pub/Sub で連携する場合、イベントを放り込むだけです。後続のプロセス(受け側)はイベントを受け取るだけです。イベントのフォーマットが決まってさえいれば、それだけです。しかも後続にどのようなプロセスがあるかどうかは気にしません。だって、それらは彼らが責任を持って実行するのだから。
n対m 連携が可能
多くのイベント駆動型処理は、一般的なシステム連携での困りごととしての 1 対 1、Point-to-Point ではありません。"Apache Kafka" へイベントを放り込むプロセスは多種多様で問題ありません。それらを受け取って実行する後続のプロセス側も、多種多様で構いません。複数のソースから流れてくるイベントを１つのプロセスが受けても良いです。一つのソースが流してくるイベントを複数の後続プロセスが受け取ってバラバラに処理しても問題ありません。
このように、複雑怪奇に陥りがちな連携をシンプルにして、かつ多くのプロセスから集信、多くのプロセスへ配信できます。連携の幅が広がりますね。
拡張が容易
このイベントバスへはいつでも好きなときにアタッチできます。
特定の連携システムのように「xx月〇〇日 12:00 から連携開始です」のようなメンテでの切り替えは不要です。新機能のプロセスが、イベントバスへアタッチした瞬間に新しい機能が稼働します。
疎結合で、かつイベントは配信型です。そのため、あらたな機能もオンラインで好きなときにアタッチしてサービスが開始できます。なんなら、知らぬ間に新しい基幹系のシステムもアタッチして、並行稼働させることもできるでしょう。そして、安全性が確認できたら、古い方をシャットダウンすれば良いのです。
これはスゴイ。
そんなイベント駆動型の特徴をまとめたのがこちらのスライドでした。
イベント駆動型アーキテクチャのススメ
最後のまとめです。
ぜひ、イベント駆動型アーキテクチャへチャレンジしてください。
そして、その結果を私に教えてください!!1
以前の話を振り返る
いいなと思ったら応援しよう！
