エアークローゼットが目指しているアーキテクチャについて

こんにちは。

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

3回にわたり『エアークローゼットを支えるシステムについて』をご紹介している第2弾として、今回は『エアークローゼットが目指しているアーキテクチャについて』CTOの辻がまとめた記事をご紹介します。

前回のファッションレンタルサービスairClosetのシステム構成について でご説明したシステム構成は、airClosetの事業単体を最速で実現する上では良かったものの、今後の事業拡大を考慮すると、システムが横展開可能な形になっていないなど、いくつか課題がありました。一般的にはこれを解決するためにAPI駆動でマイクロサービス化していくことが多いと思いますが、エアークローゼットではAPI駆動ではなくイベント駆動アーキテクチャを採用していく方針です。

今回の記事では、そもそもイベント駆動アーキテクチャとはなにか、そしてなぜそれを目指すのかについてご紹介していきます。

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

Profile

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

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

前提

今回はエアークローゼットがどんなアーキテクチャを目指しているのかについてご紹介します。

どんなアーキテクチャにもメリット・デメリットがあります。サービス内容やそこにいるメンバーによっても相性が変わってくるため、最強のアーキテクチャはないと考えています。
第１弾のairClosetのシステム構成について で書いた内容をふまえ、こういう構成の時にこんなアーキテクチャを目指しているんだな。と考えてもらえたら幸いです。

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

エアークローゼットが目指しているアーキテクチャは「イベント駆動アーキテクチャ」になります。

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

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

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

例えば一番わかりやすい例としてフロントエンドをイメージして下さい。

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

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

「イベントを受け取ってそれに応じた処理を実行する」というと「API駆動と何が違うの？」と思われるかもしれません。

確かにここだけ見ると似てますよね。この２つの一番の大きな違いは責務分離です。

責務分離の具体例

ECサービスのシステムをイメージしてみてください。このシステムの中にはユーザからの注文を受け付ける注文システムと、発送などの管理を行う倉庫システムがあると仮定します。

まず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型のフレームワークもイベント駆動アーキテクチャに利用することができます。

まとめ

以上、イベント駆動アーキテクチャについて説明してきた事をふまえてエアークローゼットでは今後イベント駆動アーキテクチャへ移行していきます。その詳細は第三弾でご紹介します！

現在エアークローゼットではイベント駆動アーキテクチャに挑戦したいエンジニアも積極的に募集中ですので、ご興味のある方はぜひ「話を聞きに行きたい」からご連絡をお待ちしております！