イベント駆動アーキテクチャでドレスレンタルサービスを爆速でローンチできた話

みなさまこんにちは、こんにちは！エアークローゼットCTOの辻です。この記事はエアークローゼットのアドベントカレンダー2024の1日目の記事となってますので、ぜひ他の記事も読んでいただけたらと思います！エアークローゼットではイベント駆動アーキテクチャへの移行を徐々に進めていますが、今回はその基盤を用いてドレスレンタルサービス「airCloset Dress」を爆速でローンチできたので、その概要を紹介していきます。
また、こちらの記事で具体的なアーキテクチャの紹介をしてますので、アーキテクチャ自体に興味がある方はこちらもみていただけたら嬉しいです。

開発期間

開発開始からリリースまで、およそ3ヶ月ほどでリリースしています。
また、人数もそんなにかけておらず、昨年リリースしたDisney FASHION CLOSETと比べて、およそ20%程度のリソースでローンチできています。

実装されている機能

実装されている機能は主に下記になります。
見ての通り普通に実装していたら到底数ヶ月で実装できるような機能数ではないので、今すすめているシステム戦略が間違っていないことがわかって良かったです！
また前提としてレンタルサービスの場合、レンタル中の管理や返却の機能がエンドユーザ側にも倉庫側にも必要になるので、EC-CUBEやshopifyのようなEC向けパッケージ製品は素のままでは利用できません。

エンドユーザ向けWeb

• 会員登録・ログイン機能
• カート機能
• 商品一覧及び商品詳細
• 注文機能
• 注文中アイテム管理
• 返却機能

アイテム管理機能

• 発注情報登録
• アイテム情報登録・更新

倉庫連携機能

• 配送連携
• 発注情報連携
• 入庫アイテム連携
• 返却アイテム連携

どうやったのか

冒頭でも書いた通り、エアークローゼットではレンタルサービスを支える共通基盤のシステムをイベント駆動アーキテクチャで実装しています。
詳しくは昨年に記事に書いてますが、それらの昨年開発したシステムは想定通りほぼそのまま利用することができ、いくつか機能追加しただけなのと、エンドユーザー向けのWebはデザインが異なるので、開発の大部分はそのあたりでした。

イベント駆動アーキテクチャがもたらした効果

スケーラビリティの確保

イベント駆動アーキテクチャは、各処理を独立したイベントとして扱うため、システムの負荷が集中した場合でも、柔軟にスケールアウトすることができます。ドレスレンタルサービスのような、需要が変動しやすいサービスにおいて、このスケーラビリティは非常に重要です。

システムの拡張性

それぞれのシステムが疎結合で動作しているため、あるシステムへの機能追加が他のシステムへ影響を与える可能性がAPI駆動と比べて低く、容易にシステムを拡張していくことができます。

複数システム間の連携

1:1のシステム連携しかないのであればAPI駆動の方が取り回しやすいですが、1:2以上になったり、1:1:1のように連携先のその先にも別のシステムが絡んでいる場合、エラーハンドリングが非常に複雑になっていきますが、イベント駆動の場合はエラーイベントとして別で処理をつくる実装になるので、比較的シンプルに実装をすることができます。

このあたりは2022年の記事も見ていただけたら、より伝わるのではと思っています。

今後の展望

今回のドレスレンタルサービスのローンチは、イベント駆動アーキテクチャの共通基盤の有効性を改めて証明するものでした。今後もこの基盤をさらに強化し、新たなサービスの開発に積極的に取り組んでいきます。
エンドユーザ向けのWebアプリケーションに関しても、サービスの形態が同じであれば必要な機能はかなり似てくるので、UI部分についてもある程度共通基盤化できないか考えています。

また、イベント駆動アーキテクチャに挑戦したいエンジニアも積極的に募集中ですので、興味のある方は、エアークローゼットのエンジニア採用サイト -エアクロクエスト-の方もご覧いただけたら嬉しいです！
それではここまで読んでいただきありがとうございました。
今後もエアークローゼットのアドベントカレンダー続いていきますので、今後の記事もお楽しみに！