Zenn
😺

エアクロが目指しているアーキテクチャ

2022/12/25に公開
#
アーキテクチャ
#
アドベントカレンダー
#
イベント駆動
tech

みなさまこんにちは、こんばんは！エアークローゼットCTOの辻です。
この記事はエアークローゼットのアドベントカレンダー2022の25日目の記事となってますので、ぜひ他の記事も読んでいただけたらと思います！
今回はタイトルのとおり、今後エアークローゼットが目指していくアーキテクチャについて書いていきますので、ぜひ最後までお読みいただけたら嬉しいです。

前提

当たり前といえば当たり前なのですがどんなアーキテクチャにもメリット・デメリットがあるのと、サービス内容やそこにいるメンバーによっても相性が変わってくるので最強のアーキテクチャはないと考えています。
参考までに1日目の記事でエアークローゼットのシステム構成について書いてますので、こういう構成のときにこんなアーキテクチャを目指しているんだなと考えてもらえたら幸いです。

イベント駆動アーキテクチャ

というわけで、エアークローゼットが目指しているアーキテクチャは「イベント駆動アーキテクチャ」になります。
みなさんイベント駆動アーキテクチャについて知っていますか？まずはイベント駆動アーキテクチャ自体について説明していきます。
また今回はあくまでシステム間の連携部分のおけるイベント駆動のことを扱っており、EventEmitter等を用いたアプリケーションレベルでのイベント駆動アーキテクチャについては扱っていません。

イベント駆動アーキテクチャとは

イベント駆動アーキテクチャとは、その名の通りイベントやメッセージを受け取り、それに応じて処理を実行するという形をシステムで実現するアーキテクチャです。
例えばフロントエンドをイメージすると一番わかりやすいですが、

  • Clickイベントに受け取りデータ登録を実行する。
  • scrollイベントを受け取り要素を表示/非表示させる。
    などなどがいわゆるイベントを使った連携で、これをシステムの基盤として組み込むのがイベント駆動アーキテクチャです。

API駆動とイベント駆動の違い

「イベントを受け取ってそれに応じた処理を実行する」というとそれってAPI駆動と何が違うの？って思われるかもしれません。確かにここだけ見ると似てますよね。この２つの一番の大きな違いは責務分離です。

責務分離の具体例

例えばECサービスのシステムを構築することをイメージしてみてください。そしてこのシステムの中にはユーザからの注文を受け付ける注文システムと、発送などの管理を行う倉庫システムがあるとします。
このとき、注文システムと倉庫システムの連携をAPI駆動で構築するとどうなるでしょうか。
API駆動とイベント駆動イメージ

まずAPI駆動の方を見てみましょう。この図にあるようにAPI駆動の方では注文システムから倉庫システムに発送の"指示"を行っています。これは上司と部下との関係でも同じですが、この場合指示を受けた側、つまり倉庫システムで何らかの障害が発生した場合、注文システム側でそのエラーについての処理を実行しないといけません。つまり倉庫システムの処理の責務まで注文システム側が負っていることになります。また、倉庫システムの先に別のシステムがあったりした場合、そこまで注文システムで管理するのは非常につらいですよね。
これに対してイベント駆動の方ではいかがでしょうか。見てわかるように注文システムは注文が入ったイベントを発火させているだけでそれに関連してどんな処理が実行されるのかは見ていません。
逆に倉庫システム側が注文イベントを"観察"を行い、それが発火されたら倉庫システムの処理を実行しています。そのためこの場合倉庫システムの処理は倉庫システムが責務を負っているといえます。

イベント駆動アーキテクチャを目指す理由

エアークローゼットのサービスは非常に多くのサービスを連携させて実現させており、大きく分けても

  • お客様向けシステム
  • 認証管理システム
  • 社内管理システム
  • スタイリングシステム
  • 在庫管理システム
  • 倉庫連携システム
  • 倉庫システム
  • 返却システム
  • 決済管理システム
  • 会計管理システム
    といったものがあります（これはあくまで一部です）。

これらシステムをAPIを使ったり、バッチを使ったりして連携させているのが現在の状況なのですが、
例えばAPIの方では倉庫連携システムが失敗したことによってスタイリングシステムがエラーになってしまったり、バッチシステムではある処理が失敗したが後続の処理は実行されてしまい不整合なデータが生まれてしまう。
といったトラブルが起こることがあります。これらをなくしたいというのがまずひとつ。
それにプラスして現在の多くのシステムはairClosetのサービスを利用する前提で開発されていますが、今後の事業展開を踏まえるとそれらシステムを機能ごとに切り出し、様々なサービスから利用可能な状態にしたほうが、開発においても運用においても大きなメリットがあります。
さらにもうひとつ、イベント駆動アーキテクチャは現実の人の動きと近いためです。例えばエアークローゼットの組織にはユーザを獲得するマーケティンググループ、スタイリングを統括しているパーソナルスタイリンググループ、倉庫やクリーニングといったサービス運用を統括しているサプライチェーンマネジメントグループといったグループなどがありますが、これらのグループはお互いの責務を担っているのであって、上流のグループが指示を出すような連携はしていません。その意味でシステムも同様にイベント駆動になっていた方が、その現実に近い形のシステムになります。基本的にシステムは現実の動きに寄せた方が実用性や弾力性に優れるため、その意味でもイベント駆動アーキテクチャに寄せていきたいと考えています。

イベント駆動アーキテクチャのデメリット

ここまでイベント駆動アーキテクチャのメリットばかりを書いてきましたが、もちろんAPI駆動に比べてデメリットもあります。

デメリット1 処理が追いづらい

責務分離のところに書いた図を見てもらうとわかるのですが、API駆動では指示を伝えて処理を連携させていくので、この例でいうと注文システムから処理を追っていけばすべての処理を追うことができます。これに対してイベント駆動では、イベントを発火するシステムからはイベントを観察しているシステムは見えないためソースを追うことが難しいです。

デメリット2 ログが見づらい

1にも関連しますが、イベント駆動ではそれぞれのシステムが独立して動作するため、システム間でどの処理どおしが連携して動いたかが非常に見えづらいです。API駆動では別システムからのレスポンスをログとして残しておけばよいだけなのでここも大きなデメリットになりえます。

デメリット3 構築が難しい

難しいというと語弊がありますが、実装面とノウハウ面からAPI駆動に比べて構築が難しいと考えています。
まず実装面でいうとAPI駆動アーキテクチャほどまだまだこなれたフレームワークがあるわけではありません。もちろん現時点でも相当な数のフレームワークやツールがありますが、いわゆるrailsやexpressといった非常に簡単にAPIサーバを建てられるバックエンドフレームワークレベルのものはない印象です。
またイベント駆動アーキテクチャで開発しているエンジニアの数も多くはないため、実現方法はあってもノウハウがないため実装のイメージが沸きづらいといった難しさもあります。

イベント駆動アーキテクチャを実現する方法

そういったデメリットを踏まえた上で、現在どんなフレームワークやツールがあるのか簡単に見ていきましょう。

  • AWSのサービス
    AWSにはイベント駆動を実現できるサービスがいくつかありますので、それらを紹介します。AWS系の特徴としてはAWSサービス側で呼び出し先の設定を持っているため、イベントの観察側の処理を見てもどこから実行されるのかわからない点はデメリットかもしれません。

    • SNS + SQS
      非常にシンプルにイベント駆動を実装するのがこの組み合わせ。ただイベントごとに独立したSNS TopicやSQSのqueueが作られ、横の関連は全く見えない状態になるため大規模なシステム基盤として採用するのは難しいです。CDK等でうまく作れれば大規模にも耐えうるとは思いますが、それならこのあと紹介するEventBridgeの方がおすすめです。
    • EventBridge
      SNS + SQSの機能に加えてEventBusによってイベントのまとまりも定義することができます。また現在はCloudWatchイベントもEventBridgeの一部になっているので、それも横並びで扱えるのも強みのひとつです。さらに外部のSaasアプリケーションのイベントも扱える点も魅力です。
    • StepFunctions
      StepFunctionsはイベント駆動型のサーバレスワークフローシステムです。AWSコンソールからGUIで触るとイメージしやすいのですが、各種AWSのサービスや自分のアプリケーションをワークフロー管理することができます。上記EventBridgeと組み合わせて使うことも可能です。

  • Redis Pub/Sub
    RedisにはPub / Subの機能が内蔵されており、これを利用することでイベント駆動アーキテクチャの基盤とすることが可能です。PubはPublishのことでイベントの通知を、SubはSubscribeのことでイベントの監視を意味していて、任意のイベントをpublishすることであらかじめsubscribeしている処理が実行されることになります。

  • Google Cloud Pub/Sub
    Google Cloud版のSNSとSQSです。

  • Kafka等のMessage queue
    各種Message Queue型のフレームワークもイベント駆動アーキテクチャに利用することができますね。

まとめ

以上、イベント駆動アーキテクチャについて説明してきましたが、エアークローゼットでは今後少しずつイベント駆動アーキテクチャに移行していく計画になっています。
また、そのためにもイベント駆動アーキテクチャに挑戦したいエンジニアも積極的に募集中ですので、興味のある方は、エアークローゼットのエンジニア採用サイト -エアクロクエスト-の方もご覧いただけたら嬉しいです！
それではここまで読んでいただきありがとうございました！この記事でエアークローゼットアドベントカレンダー2022も最後になります。
それではみなさま良いお年を！

Discussion