【概要】
筆者はイベントドリブンアーキテクチャ(Event Driven Architecture)およびサーバーレスアーキテクチャに関して無知でした。そんな筆者がイベントドリブンアーキテクチャについて学習した過程を記事に残しますので、今後イベントドリブンアーキテクチャについて学習を始める方の参考になればと思います。
【対象読者】
概要にも記載してありますが当記事の対象読者は今後イベントドリブンアーキテクチャについて学習を始める方です。
【参考資料】
サーバーレスのポテンシャルとシステム表現
Microsoft Azure イベント ドリブン アーキテクチャのスタイル
サーバーレスがアプリケーションにもたらす本当のメリットとは？
Think IT ビジネスプロセスの形態
DynamoDB StreamをトリガーにしてLambdaを実行する
【そもそもイベントドリブンアーキテクチャって何？】
まずイベントドリブンアーキテクチャとは何かを調べるために参考資料を漁っていたところリクエスト・リプライ方式とイベントドリブンがあることを知りました。なのでイベントドリブンだけでなくリクエスト・リプライ方式それぞれの違いを調べることになりました。と言っても、リクエスト・リプライ方式はよく見かける設計だったのですぐに理解しました（というか概念は理解していて名前だけ知りませんでした）。
[リクエスト・リプライ方式]
まずは下図をご覧ください。
これは受注処理を簡略的に表したものでユーザーが注文を行うと受注管理サービスにリクエストが送られ、受注管理サービスから配送予約サービス、在庫管理サービスにリクエストが送られるようになっています。サービス間の連携はRESTが一般的でしょうか。この方式をリクエスト・リプライ方式と言います。
売上集計を行いたいという要件が発生し、新たに売上集計サービスを実装しなければならなくなったとします。その場合が下図です。
リクエスト・リプライ方式の場合は要件に対応するために売上集計サービスを実行しましたが、売上集計サービスにリクエストを送るために受注管理サービスも改修する必要があります。
[イベントドリブン]
次は下図をご覧ください。
受注管理サービスは配送予約サービス・在庫管理サービスにリクエストを送るのではなくイベントを配信するのみで、配送予約サービス・在庫管理サービスはイベントをサブスクライブして処理を行います。イベントを配信するサービスのことを イベント プロデューサー 、イベントをサブスクライブするサービスのことを イベント コンシューマー と言います。リクエストリプライ方式では配送予約サービス・在庫管理サービスが受動的（passive）だったのに対して、イベントドリブンでは能動的（active）であるという違いがあります。
さて、イベントドリブンにおいても売上集計サービスを実装しなければならなくなったとします。その場合が下図です。
先述の通り受注管理サービスはイベントを公開するのみで売上集計サービスがイベントをサブスクライブして処理を行うため、売上集計サービスの実装に伴い受注管理サービスを改修する必要はありません。
要約するとイベントドリブンアーキテクチャはサービス間にイベントを挟むことでサービス同士の依存を排除できるというメリットがあるということです。ジョブキューなんかもこれに当たるんですかね。
【AWSでイベントドリブンアーキテクチャを構築する】
さてイベントドリブンアーキテクチャが何かはわかりました。じゃあイベントドリブンアーキテクチャを構築するためにはどうすればいいのか？
調べていたところ、DynamoDB Streamを活用した例をよく見かけました。
DynamoDBStreamとは、テーブル操作が行われた際にキャプチャができる昨日で、これを活用するとテーブル操作を検出しLambdaを発火させることができます。下図はDynamoDB Streamを活用したイベントドリブンアーキテクチャの構成図です。
受注管理サービスはテーブルに受注情報を挿入し、DynamoDB Streamが挿入を検出およびLambdaを発火し、それぞれのLambdaが配送予約・売上集計・在庫管理を行います。
ここの詳細は実践編を追って投稿予定です。
【イベントドリブンアーキテクチャの課題】
ここまで調べてみたところイベントドリブンアーキテクチャが非常に魅力的に見えてきました。しかしデメリット、課題は無いのだろうか？それを調べてみたところ、やはり課題もあるようです。それはイベントが配信されたことに対する保証です。
イベントドリブンアーキテクチャではイベントが配信できなかった場合サービスが実行されないので、その点を留意して設計・技術選定を行う必要があるようです。
【まとめ】
ここまで調査した内容を私なりにまとめたいと思います。
分散型システムにおいてサービス間の連携を行う方法はリクエスト・リプライ方式とイベントドリブンがあり、イベントドリブンはサービスとサービスの間にイベントを挟むことでイベント同士を疎結合にできるメリットがあります。一方でイベントが配信出来なかった場合にイベントプロヂューサーは、そのことを察知することが出来ないためイベントの配信を保障しなければならないという課題もあるようです。
またイベントドリブンアーキテクチャを構築はDynamoDB StreamによりLambdaを発火させるという構築が主流のようです。「AWSでイベントドリブンアーキテクチャを構築する」のくだりでも記載しましたが、実践編としてDynamoDB StreamおよびLambdaは掘り下げようかと思います。
=> 実践編公開しました！
https://qiita.com/Suzuki_Cecil/items/b9a1faaab7e225d29efc
以上が無知な私がイベントドリブンアーキテクチャを学習した過程と、学習を通してのまとめです。誤りがありましたらスポンジ製のマサカリを投下していただけると幸いです。