弊社ではECサイトアソビュー！を運営していますが、並行してアソビュー！ギフトというサービスも展開しています。 本記事では、アソビュー！ギフトとはそもそもどんなサービスなのか、そして現状のシステム構成における課題と将来的にどうしていきたいかについて、それぞれお話ししたいと思います。
アソビュー！ギフトとは？
アソビュー！ギフトとは、アソビュー！に掲載されている遊びの中から厳選した体験を、家族や友人にプレゼントできる仕組みです。
現在、大きく２つの商品群を展開しています。
- カタログギフト
- アソビュー！ギフトカード
カタログギフトは、我々が厳選した体験カタログの中から、お好きなプランを選んで体験していただける形の商品です。 アソビュー！ギフトカードは、ECサイトアソビュー！で使えるポイントをギフトとしてプレゼントできる形の商品です。 これらの商品は全てアソビュー！ギフトで販売中ですので、興味のある方はぜひ！
アソビュー！ギフトのシステム構成の今と未来
ECサイトアソビュー！はこちらの記事でもご紹介している通り、マイクロサービス->モジュラモノリスへとアーキテクチャを変更してきた歴史があるため、ある程度細かく分離した複数のアプリケーションの組み合わせによって構成されています。
ところがアソビュー！ギフトは、新規事業として数年前に立ち上げてから今に至るまで、マーケットでの販売規模拡大を最優先としてきたためシステムの基礎となるアーキテクチャの改善が進んでおらず、アソビュー！に追いつけていません。
そこで、今回はアソビュー！ギフトのサービス群の中から、予約サイトを例に、現状のシステム構成と課題についてまず説明します。 そして現状のアソビュー！のシステム構成に近づけることでどう改善したいのかについて続けてお話しします。
予約サイトシステム構成の今
ここで言う「予約サイト」とは、アソビュー！ギフトをプレゼントとしていただいたゲストの方が利用するためのサイトです。 もう少し具体的にご説明すると、シリアルコードを入力してログインすることで、カタログに掲載されているアクティビティやチケットの中から好きなものを検索・選択してを予約・購入することができるサイトです。
この予約サイトの構成はざっくり図で書くと以下のようになっています。
アクティビティとチケットは、システム的にはそれぞれ別々の概念となっており、関係するサービス群もわかれています。 また予約サイトではアクティビティ/チケットに加え、「おうち体験キット」と言うShopifyで掲載されている商品に交換することもできるため、Shopifyとも連携しています。 予約サイトを利用するためにはアソビュー！の会員である必要があるため、会員情報を取り扱う会員サービスも連携しています。
このサービス構成には以下の問題があります。
APIの載せ替えが大変
過去にサービス構成変更に伴い、アクティビティに関するAPIを全て別アプリケーションに移管する対応を行なったことがありました。アプリケーションによってURIの定義ルールが違ったため、呼び出し元の定義も、もちろんホスト名も全て変更する必要がありました。API呼び出しの実装が大変
APIを呼び出す場合、どのAPIがどのサービスに実装されているのか把握しておく必要があります。また、レスポンスの仕様もサービスによって異なるので、レスポンスのハンドリングもアプリケーションごとに考える必要があります。HttpClientの設定もサービスごとに異なるのでrestTemplateも分けています。セキュリティの仕様がアプリケーションによって違う
アプリケーションが異なると、APIのセキュリティに関する制御の仕様も異なります。例えばSPA化する場合にフロントから呼び出せるAPIを作るとなると新たなセキュリティルールが必要となりますが、アプリケーションごとに制御機能を実装する必要が出てきてしまいます。
予約サイトシステム構成の今後
では、先ほどの予約サイトを、アソビュー！のシステム構成に近づけるとどうなるでしょうか。
まずは図で見てみると下図のようになります。
この構成にすることで、前述の課題の多くを解決することができます。
APIの載せ替えが大変
APIのアクセス先をGatewayに集約することで、ホスト名が統一されています。各アプリケーションのAPIもほとんどがProtocol Buffersを用いたインタフェース定義に統一されているため、サービスを変えてもURIを変えない設計が可能です。API呼び出しの実装が大変
前述の通り、各サービスのAPIはほとんどがProtocol Buffersを用いてインタフェース定義しており、Gatewayによってレスポンスの仕様(2xx/4xx/5xx)やエラーフォーマットも統一されているため、呼び出し元のエラーハンドリングが簡単になります。セキュリティのルールがアプリケーションによって違う
セキュリティの仕様もGatewayで統一的に処理が実装されているため、アプリケーションが違うAPI同士でも同じ処理で同じセキュリティレベルを実現できます。
アソビュー！とアソビュー！ギフトは同じプラットフォームを共有する別サービスです。 開発体制が異なるこの２つのサービスを、どちらかが置いてけぼりにならないようグロースしていくことが今後の課題です
最後に
アソビュー！では、ギフトのような新規事業立ち上げや、最近リリースしたばかりのアプリのような新規開発は、少人数で一気に開発を進めてPMFが確認できたら改善、拡張していくケースがよくあります。 そういったグロースの過程を楽しめる方にはぴったりな開発現場だと思います。
こういった分野や事業に興味があれば、アソビューでは一緒に働くメンバーを大募集しています！ カジュアル面談もありますので、少しでも興味があればお気軽にご応募いただければと思います！
