アソビュー！ Advent Calendar 2024の19日目（表面）です。
アソビューにて海外事業を担当している江部です。今年の前半まではCTOで、今年からは心機一転して海外事業責任者を拝命し、これまでの国内向けサービスを拡張して海外向けのサービスを新規事業として立ち上げることにチャレンジしています。
役割は事業責任者ですが、MVP開発フェーズ終盤においてはプロダクトチームと一緒に開発に取り組んでいます。 今日はこの海外事業を立ち上げるにあたって、アーキテクチャ上の責務分解とシステム全体の性能のトレードオフについて悩んだことがあったので、そのお話をネタにしていきたいと思います。
背景
前述の通り、アソビューでは海外のレジャーやアクティビティの取扱を開始し、アソビュー海外 www.asoview.com
というサイトを立ち上げています。 今後どんどん取扱を広げ、海外旅行に出かける人々に、手軽に現地でのアクティビティを予約してもらえるよう、サービスの改善を続けていきます！
本サイトを開発するにあたっては、プロダクト部門全体で以下の合意をしました。
- 既存の国内向けサービスとはサイト内の構成を分け、海外用のページツリーを新規に開発
- 商品データ、予約、在庫などのビジネスロジックは、モジュラモノリスの共通基盤上に構築 （モジュラモノリスについてのいろいろはこちらをみてね）
イメージとしては下の図のような構成になります。
ざっくりすぎて分かりづらいかもしれませんが、要はサイト部分は新規でつくって、裏側のロジックは既存を活用しよう、という感じです。 当社ではアソビュー！ をはじめ、アソビュー！ギフト や アソビュー！ふるさと納税、レジャー施設向けのウラカタ など、様々なプロダクトがありますが、レジャーやアクティビティを取扱うというテーマで一貫しているため、ドメインモデルもまた各サービス間で同じ概念を共有します。
よって、今回の海外サイトも同様の方針で共通基盤上に既存のアセットを活用してドメインを構築する方針としました。
起こった問題
こういった2段構成であることから、予約サイト側と共通基盤側とで責務分解をする必要があります。
開発開始当初は
- 共通基盤にドメインロジックを集約。なるべく利用側（＝予約サイト側）のナレッジを持つことがないようにしよう
- 予約サイト側は、必要なモデルを共通基盤から取得し、UI/UXの要件に基づいてサイト側でモデルを変換して利用しよう
という方向性で動きました。 共通基盤が共通のビジネスドメインの集約であるという考え方のため、疎結合を維持し利用側の個別の都合による実装はなるべく排除しようという考え方です。
その結果、残念ながら全体として処理パフォーマンスが悪く、当社で定めるSLOを達成できない状態になってしまいました。
問題の原因
理由は単純で、サイト側で必要な形と共通基盤からAPIで提供されるプレーンなドメインモデルの形が必ずしも一致しないからです。 サイト側の要件に沿うモデルを構築するために、時には異なる条件でおなじAPIを複数回呼び出したり、サイト側では必要のない部分までAPIに含まれていたりしたため、予約サイトと共通基盤アプリケーションおよびDB間の往復回数が無駄に肥大化したためでした。
対策の検討
この問題を打開する案として、いくつかあるうちの以下の2案に絞って対応を検討しました。
① キャッシュで対応
サイト→共通基盤の通信結果をキャッシュすることにより端的にパフォーマンスを改善しようという方向性です。
長所
- アップストリームへの通信をわかりやすく削減することができる
- ドメインモデルが利用側の個別要件の影響を受けなくなる（当初の思想を維持できる）
- サイト側と共通基盤で担当者を分ける場合においてその体制を維持しやすい
短所
- メモリやストレージなどのリソースが追加で必要
- キャッシュイン、キャッシュアウトのタイミングの調整や制約の考慮が必要になる
② 共通基盤のAPIをサイトに最適化
共通基盤でサイトの要件に沿う形のモデルを1発で返せるようにすることで、通信量、回数を減らす方向性です。
長所
- 通信回数とデータ量を最適化できるのでパフォーマンスが向上する
- 長期的に可用性の高いシステム体質を維持できる
- 担当がユーザストーリ軸にそって上から下まで担当する（サイトと共通基盤で担当者をわけない）場合には最適
短所
- サイト側と共通基盤が密結合化する
- 共通基盤がサイトのナレッジをもつ必要がある
今回の私達の選択
今回は 「②共通基盤のAPIをサイトに最適化」を優先しました。 理由は
- 今回の対象範囲だけでなく、当社のシステム全体として可用性を重要視するなかで、資源による解決ではなくなるべく処理効率のよいプログラムを是としたかった
- プロジェクト開始当初はサイト側とモノリス側で担当をわけていたが、今後はユーザストーリーを基軸に、アーキテクチャや技術軸によらずストーリー担当制を引く体制に以降したかったため、②のほうが相性がよいと考えた
- 既存事業とモデルを共存する範囲が比較的狭かったため、密結合化することによる他プロダクトへの影響は最低限に抑えられると判断したため
結果として当初大きく枯渇していたエラーバジェットの状況は改善されたと同時に、体感的にもシステムのパフォーマンス向上が実現できたことによりUXの向上にも繋がりました。
また、今後の進展として、共通基盤APIレスポンスのキャッシュをあわせて活用することによりさらなるパフォーマンス向上につなげる可能性もあると考えています。
最後に
こういった問題は様々な要素を勘案して決めるべきだし、今回の選択肢がすべての状況において正解であるとはなりませんが、 一長一短ある中で最も重要視するポイントを整理して判断する事が重要だと思います。 一つの事例として誰かの参考になれば幸いです。
今年は少し長めの年末年始ですね。 海外にお出かけの際は、ぜひアソビュー！海外をチェックしてみてね！
また、アソビューでは、「生きるに、遊びを。」を実現するための良いプロダクトを世の中に届けられるよう共に挑戦していく様々なエンジニアを随時募集しています！ カジュアル面談も可能ですのでお気軽にお問い合わせを！
