Zenn
👕

イベント駆動アーキテクチャへの変革

2023/12/01に公開
Node.js
CQRS
Step Functions
EventBridge
イベント駆動
tech

みなさまこんにちは、こんばんは！エアークローゼットCTOの辻です。この記事はエアークローゼットのアドベントカレンダー2023の1日目の記事となってますので、ぜひ他の記事も読んでいただけたらと思います！今回は昨年のアドベントカレンダーに書いた、エアクロが目指しているイベント駆動アーキテクチャについて、今年の取り組みと今後の展望を書いていきます。

2023年の成果

結論からいうと、今年はレンタルサービスの屋台骨になる下記の5つのシステム、

  • 認証管理システム
  • 在庫管理システム
  • 受注管理システム
  • 決済管理システム
  • 通知管理システム
    を抽象化し、イベント駆動アーキテクチャでの実装を行っています。
    それぞれで利用している技術については後述していきます。

利用しているサービス

  • AWS EventBridge
  • AWS StepFunctions
  • MongoDB Atlas
  • AWS API Gateway + Cognito
  • AWS ECS
  • AWS Lambda

それぞれ、下記の用途で利用してます。

EventBridge

各種イベント管理をやってくれるサービス。主にEventBusとRuleを利用している。
RuleはCloudWatch Eventsが移行したもので、スケジュールに乗せて実行したいバッチ処理の実行で利用。
EventBusはイベント駆動を実現する肝になるサービスで、イベントをn:nでつなげるのに便利。イベント駆動ではSNS+SQSも選択肢に入るが、そちらは全てのイベントを個別に管理しなければならないのに対し、EventBusでは任意のドメインごと管理を任せられるので見通しが良くなる。そのため一定以上の規模のシステムであればEventBusはおすすめ。

StepFunctions

その名のごとく、条件分岐やループで各処理をつないで管理してくれるサービス。めっちゃ便利。
ただ今回はどちらかというとECS TaskをEventBusから実行するときに、StepFunctionsで包んで管理しやすくする用途で利用。
業務ロジックと切り分けたいエラーハンドリングやログの管理など、あとからなにか処理追加するのも非常に楽になるので、stepが1つしかない状態から入れておくのも良いと思ってます。

MongoDB

今回エンドユーザ向けのシステムでCQRSを採用していて、MongoDBのaggregateが便利だったので採用。
コマンド結果の格納、格納した結果のaggregate、aggregateした結果をクエリ向けに格納とCQRSに必要なことを全て任せている。ReadStreamもあるのでCQRSで実装したい！って人はMongoDBも検討してみたらよいかも。

AWS API Gateway + Cognito

これはイベント駆動の部分ではない、クライアントから実行される同期APIの部分で利用。イベント駆動アーキテクチャといってもほんとに全てが非同期ではかなり使いづらいものになってしまうので、同期APIと非同期イベントを併用している。

AWS ECS

業務ロジックを担っていて、言語としてはNodejs（typescript）で実装。同期API経由で呼ばれることもあれば、EventBridge RuleからTaskとして呼ばれることもあるので、DDDを採用しどちらのパターンでもpresentation層で吸収できるように設計。

Lambda

EC2で実装されている既存の処理とEventBridgeをつなぐ部分と、通知管理システムに利用。
各種制限があるのでシンプルな処理や、業務ロジックが存在しない部分に使っている。

システムの移行について

上記のシステムについては現在運用している、airCloset及びairCloset Mallでも使われることを想定して設計をしつつ、2023年10月からスタートしている新規サービスDisney FASHION CLOSETで実際に使っています。
気持ちとしては既存サービスも含めて移行したい気持ちもありますが、移行にかかる開発コストだけでなく、全てを移行させるのはそもそもリスクも大きいので、まずは新規サービスを運用していく中で使い勝手を向上させて、来年以降で既存のサービスも移行していきたいと考えてます！

今後の展望

イベント駆動アーキテクチャに移行していきたいと考えていた中で、まずは基盤となる部分の開発ができたことは非常に大きな成果だと感じています。
一方でまだまだやりたいことは残っていて、まずはエアクロの共通基盤として必須となるスタイリング機能の抽象化、そして既存サービスの基盤部分の移行を進めたいのはもちろん、新しくサービスをつくるときに、今回開発した基盤に楽に乗っかれることも非常に重要なので、そういった運用を見据えた開発を進めていきたいと思ってます。
また、イベント駆動アーキテクチャを採用したシステムの事例はまだまだ少ないと感じているので、今後サービスを運用していく中で実際に生じた課題や利点など、ある程度実績が溜まったタイミングで発信していきたいと思っています。
イベント駆動に興味あります！って人はぜひ情報交換したいので、 @RyanAirclosetまでご連絡ください！

また、イベント駆動アーキテクチャに挑戦したいエンジニアも積極的に募集中ですので、興味のある方は、エアークローゼットのエンジニア採用サイト -エアクロクエスト-の方もご覧いただけたら嬉しいです！
それではここまで読んでいただきありがとうございました。
それぞれのシステムで利用した具体的な技術等の話はこれからメンバーの記事にバシバシ入って来ますのでそちらもお楽しみに！
みなさま良いお年を！

Discussion