アイテムレビュー基盤構築で行った取り組みと課題に対するアプローチ

はじめに

こんにちは、マイグレーションブロックの寺嶋です。

11/29、ZOZOTOWNで購入した商品の口コミやレビューを投稿、閲覧する機能をリリースしました¹（以下、アイテムレビューと記載）。ZOZOTOWNで購入をしたことがある方は投稿できますので、ぜひ使用感などの声を投稿してください。

なお、この記事はZOZO Advent Calendar 2023 #1の8日目の記事です。

アイテムレビューとは

まずは、アイテムレビューの概要について紹介します。

アイテムレビューという命名の通り、ご購入いただいた商品のレビューを投稿したり、他に購入した方のレビューを参照したりできるようになります。また、レビュー投稿の際には星による5段階評価が行われるので、ひと目で評価を判断できます。特徴的なのは、マックスくんスタンプによるリアクションが行えるところで他のECサイトにはないZOZOらしさを感じる機能かと思います。

次の図のように、商品詳細画面からレビューを見ることができるようになりました。すべてのレビューを見るリンクからレビューモーダルを表示でき、全レビューの参照や星評価での絞り込み、投稿日による並び替えができます。

レビューに対してスタンプでリアクションを取ることができます。

注文履歴のレビュータブで投稿可能な商品一覧が表示され、新規投稿・編集・削除ができます。商品カテゴリ毎にアンケートがあるので年代や性別、サイズや肌の悩みなど購入者の意見を参考にできます。

昨今のECサイトには必ずといっていいほど導入されていたアイテムレビュー機能がZOZOTOWNにも導入され、別サイトで口コミを確認するといった煩わしさが解消されます。ぜひ、多くの皆様にご活用いただけると幸いです。

そんなアイテムレビュー基盤を構築するにあたり行った工夫、発生した課題とその対策をご紹介します。

データベース選定

新規基盤マイクロサービスを作成するにあたり、いくつかの技術的課題がありました。

1つ目がデータベースの選定です。アイテムレビューはレビューの検索のような読み込み処理以外に、レビュー書き込み、スタンプによるリアクション、通報などといった書き込み処理が多く高負荷になることが予想されます。そのため、データベースの選定が重要であり、SREチームとも相談し次の候補で検討しました。

Amazon Aurora MySQL
PingCAP TiDB

Aurora MySQLはご存知の通り、AWSが提供するフルマネージドでMySQL互換のリレーショナルデータベースです。一方、TiDBはPingCAP社が開発した分散型データベースでRDBMSとNoSQLの機能を組み合わせたNewDBと呼ばれる新しいカテゴリのデータベースです。MySQL互換のSQL解析機能を持っているためアプリケーションからはMySQLと同等の利用が可能で、水平方向のスケーラビリティ・強力な一貫性・高可用性を兼ね備えたデータベースです。

SREチームと次の項目で比較検討しました。

項目
スケールアウト・イン（性能・サイズ）
スケールアップ・ダウン
マスタ障害 / フェイルオーバー
データ（シャード）分割と結合
基本Read / Writeクエリ性能（ベンチマーク結果）
ネットワーク連携（VPC）
構成管理（Iac）
監視・メトリクス・ログ
バックアップ＆リカバリ
監査ログ
SQL Serverとの同期（ニアリアルタイム）
可用性
エコシステムとのインテグレーション
サポート体制
コスト
OLAP
アプリケーション視点からの機能比較

アイテムレビューの特性を考慮し、次の理由から現時点ではTiDBはアイテムレビューにはマッチしないと判断しAurora MySQLを採用しました。

スケーラビリティ優位性をあまり活かせなそう

想定するWrite TPSとデータ量を考慮するとシャード分割によるスケールアウトを要するレベルではなく、インスタンスに十分収まりそうだと考えました。また、データ量的にもAuroraストレージ格納機能で補えるものと判断しました。TiDBの強力な自動リバランスによる書き込み水平スケール能力は残念ながらあまり活かすことはできなさそうでした。

利用できないデータベース機能がある

MySQL互換とはいえまだ利用できない機能がありました（外部キー制約、auto incrementなど²）。その中でも外部キー制約を使えないのは大きな課題でした。ソフトウェアを安全に運用するためにはデータの整合性が不可欠と考えていたため、TiDBを選定するのは難しいと判断しました。ただ、最新のTiDBでは外部キー制約も解決されているので、更新系処理でスループットが出ないといった問題が起きた際は移行を検討してもいいかもしれません。

先行開発

新マイクロサービス基盤の設計・実装を先行して行い、構築が終わったころにWebフロントエンドやアプリ、BFF層が開発することになりました。基盤・後発に関わらず、開発が進めば想定外の事象が起きたり、辻褄が合わないなどで仕様変更が入ったりしやすくなります。もちろん、ソフトウェア開発で仕様変更が入ることは当然起こりえることです。

ただ、他チームが開発を始める頃にはアイテムレビュー基盤としては開発を終えているので、作り終えたあとに変更が入ることとなります。そうなった際に、いかに手早く修正し利用チームに対して機能を提供するか、そして品質を担保するのかが課題となります。言い換えると以下を意識することで課題解決ができると考えました。

変更容易性を高める
複雑なドメイン知識を集約し凝集度を高める

そこでアイテムレビュー基盤開発では、ドメイン駆動設計（以降DDD）の手法を取り入れました。

ドメイン駆動設計（DDD）

DDDとはエリック・エヴァンスが提唱したソフトウェア設計のプラクティスの1つです。DDDの細かい説明は他のサイトにまかせますが、以下がWikipediaからの抜粋³です。

ドメイン駆動設計（英語: domain-driven design、DDD）とは、ドメインの専門家からの入力に従ってドメインに一致するようにソフトウェアをモデル化することに焦点を当てるソフトウェア設計手法である。オブジェクト指向プログラミングに関しては、ソースコード（クラス名・クラスメソッド・クラス変数）の構造と名称がビジネスドメインと一致させる必要があることを意味する。ドメイン駆動設計では、開発者は通常モデルを純粋で有用な構造として維持するために大量の分離とカプセル化を実装する必要があると批判されているが、ドメイン駆動型設計は保守性などの利点を提供する。

以上のことから、ドメイン（解決したい領域）の専門家の知識をソフトウェア設計にドメインモデルでそのまま反映させることを目的としています。正式なDDDを実践するためにはアイテムレビューを理解しているメンバーにドメイン知識を提供してもらい設計を進める必要がありますが、チームに専門家がいないためいわゆる戦術的DDDを取り組むこととなります。戦術的DDDとはドメイン駆動設計で語られる技術的要素のみを取り入れた手法です。課題となっている仕様変更を受け入れやすくする観点では、技術要素のみであっても十分にメリットがある戦略だと思います。

設計フェーズ

最初に行ったのがユースケースの整理による必要な操作の可視化でした。基盤側の実装だけではなくアプリやフロントエンドも含めた全体像の整理を目的としており、全チームの認識を合わせるために作成しました。ユースケース単位で各チーム工数見積りをしたり、機能や仕様調整もユースケース単位で行えたり、コミュニケーションを取るための共通認識となったり大変役に立ちました。また、利用者や行うアクションも記述することでよりイメージを膨らませることができました。

ユースケースで関係者との合意が取れたらユースケース単位でシーケンス図を作成しました。ユースケース単位でどのマイクロサービスが利用されるのか、今回開発するAPIやデータの粒度、API呼び出しの回数などの可視化をおこないました。各チームとのコミュニケーションツールとなりAPIが明確になることでAPIのI/F設計、負荷テストの際にどのような経路でどのようなAPIが利用されているのかが分かるようになりました。また、APIの経路を明確にすることで負荷試験時に必要となるデータや必要となる環境が可視化されるメリットにもつながりました。

マイグレーションブロックではドメインモデル図をモブプログラミング形式で作成する会を行い、ドメイン知識の共有を図りました。機能要求から制約を書き表したり、集約の区分け、データの関係性を可視化したりすることが目的で実装時にはドメインモデル図がとても重宝しました。メンバーとワイワイ話しながらドメインモデル図を書くというのもとても楽しく新鮮な経験となりました。

シーケンス図でAPIの種類まで認識合わせをしましたが、認識をあわせたAPIのI/Fを設計する必要があります。実装前であったのでドキュメントにHTTPメソッドやURL、パラメータやリクエスト・レスポンスを記載し利用チームにレビューを依頼する方法で行いました。その後、実装が進むとOpenAPI（Swagger）を介して仕様を調整していく形となり、よりスピーディーになったと思います。

アーキテクチャの選定

モブモデリングをしたドメインモデル図を活かすためのアーキテクチャ選定として、オニオンアーキテクチャを採用しました。オニオンアーキテクチャを採用した理由は次の通りです。

他マイクロサービスでも採用されており馴染みがある
ドメイン層を中心として設計するのに一番理解しやすい

DDDが推奨するアーキテクチャの思想は本質的に同じであるものの、複数のマイクロサービスを運営・管理するのに異なるアーキテクチャの採用はデメリットだと考えました。また、ドメインモデルに知識を集約させることを考えていたのでドメインを中心とするオニオンアーキテクチャが理解しやすく適していると判断しました。各層の目的・責務は次のようにしました。

domain層：ビジネスロジックの表現。集約単位で整合性を担保したデータ郡
infrastructure層：外部サービスへのアクセス（他層から直接参照はNG）
presentation層：APIの公開やリクエスト・レスポンスへの変換
usecase層：操作（ユースケース）の組み立て、トランザクションの制御

仕様変更が入って実際どうだったか？

それほど大きな変更は入らなかったものの、修正の際は責務が明確になっていることで対象箇所が限定的となり修正・ユニットテストが書きやすく、スピーディーな対応ができました。影響箇所の調査で疲弊することはなく、修正後のテストは断定的になりました。他チームの方々からも対応が早いといった感謝の声をいただくことができ、結果としてとても効果があったと感じています。

テストデータ

開発が中盤に差し掛かる頃には各マイクロサービスを結合させることが増えてきたり、テストケース毎にいろいろなパターンのレビューが必要となったりしてきます。我々基盤チームがデータを管理しているので各チームからレビュー作成や、状態変更などの依頼が来ます。簡単な依頼であれば直接SQLを実行したり対象のAPIで操作したりもできますが、星評価の希望した平均点や負荷試験で数百万件のレビューデータを作成する必要もあったためこれらの方法だと非効率でした。

そこでよくある方法ですが、作成する件数や回答パターンを指定できるMySQLストアドプロシージャを作成しました。正規手順によるデータ作成ではありませんが、ストアドプロシージャがあることで大量のデータや依頼に応じたデータを容易に作成できとても重宝しました。それでも数百万単位のレコードを作成するのに数日かかってしまったりしたので、まだ改善の余地はありそうです。

データベース選定時点ではテストデータ作成にMySQLストアドプロシージャを利用することは想定できていませんでしたが、TiDBでは残念ながらストアドプロシージャはサポートされていません。⁴別の方法を模索する必要があり、もっと複雑な方法で時間がかかったかもしれません。

基盤技術の共有

ZOZOTOWNのリプレイスはこれからも続き新たな基盤が作られていきます。アイテムレビューで培ったノウハウを次の基盤を作る際に活かすためSpring Bootとオニオンアーキテクチャをベースにしたテンプレートリポジトリを作成しました。今回アイテムレビュー基盤を作るにあたり議論した設計方針やユーティリティ、ユニットテスト環境などをテンプレートリポジトリにまとめたものです。

盛り込まれている内容を1部ご紹介します。

オニオンアーキテクチャのパッケージ構成とサンプル実装
DockerによるMySQLとSchemaSpyによるテーブル定義
ArchUnitによる依存関係の整合性テスト
TestContainersによるユニットテスト

同じ設計思想で新たな基盤を作成するときはこのリポジトリをテンプレートとして作成すれば必要な環境が整った状態で着手できるようになり立ち上げ時の工数削減に役立つものと考えております。早速こちらのリポジトリを勉強の題材にしたり、新規基盤をこのリポジトリから作成したりと活用されています。これからも随時更新を続けていければと考えています。