こんにちは。

株式会社エアークローゼットの藤川です。

エアークローゼットを支えるシステムについてご紹介している最後となる今回は、『イベント駆動アーキテクチャへの変革』についてCTOの辻がまとめた記事をご紹介します。

エアークローゼットにご興味がある方、イベント駆動アーキテクチャについてご興味のある方はぜひご覧ください！

Profile

辻 亮佑 RYOSUKE TSUJI　1986年生まれ
ニックネーム：Ryan(ライアン)

上智大学卒業後、IT開発会社にシステムエンジニアとして入社。2012年に楽天にフロントエンドエンジニアとして入社し、2013年からはリードフロントエンドエンジニアとして活躍。2015年に株式会社ノイエジーク(後の株式会社エアークローゼット)に入社し執行役員CTOに就任。

はじめに

みなさまこんにちは。エアークローゼットCTOの辻です。

前回のエアークローゼットが目指しているアーキテクチャについて を元に2023年の取り組みと今後の展望をご紹介します。

2023年の成果

結論からいうと、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で実際に使っています。
気持ちとしては既存サービスも含めて移行したいと考えていますが、移行にかかる開発コストや、全てを移行させる際のリスクが大きいため、まずは新規サービスを運用していく中で使い勝手を向上させて、来年以降で既存のサービスも移行していきたいと考えてます！

今後の展望

イベント駆動アーキテクチャに移行していきたいと考えていた中で、まずは基盤となる部分の開発ができたことは非常に大きな成果だと感じています。

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

また、イベント駆動アーキテクチャに挑戦したいエンジニアも積極的に募集中です。
興味がある方は是非カジュアルにお話しできればと思いますので、「話を聞きに行きたい」からご連絡をお待ちしております。

ここまで読んでいただきありがとうございました！