あらゆる商品を扱う商品データベースを再設計した話 / product db re-architecture

2024/3/26 ＠Offers 各社事例で振り返る データ構造x技術負債LT vol.2

マイベストの商品データベースを再設計した実例を通して、データベースやアーキテクチャを再設計をする際の進め方について発表しました。

Transcript

1. あらゆる商品を扱う商品データベースを 再設計した話 2024/03/26 ＠Offers データ構造x技術負債LT vol.2 rince (@kazumax1218)
2. rince（@kazumax1218） ◦ 2011- カカクコム（食べログ→キナリノ） ◦ 2018- メルカリ（ソウゾウ→メルペイ） ◦ 2020- マイベスト ◦ 旅とキャンプとサウナが好き⛺ ◦ 最近は育児に奮闘中👶 自己紹介
3. • 実例を通してデータベースやアーキテクチャを再設計をする際の進め方が わかる ◦ 設計理論 ← 既に巷にいい資料がたくさん ◦ 設計の進め方の一例 • あらゆる商品を扱う商品データベースの仕組みが少しわかる ◦ 時間の関係で詳細までは解説できず… この発表でわかること
4. マイベストについて 目次 1 直面した課題 2 商品DB再設計をどう進めたか？ 3 結果と学び 4 まとめ 5
5. マイベストについて 1
6. 月間利用者数 3,000 ユーザーの“選択”を サポートする 商品比較サービス 万人以上
7. 雨傘の検証。送風機を使って「耐風性」を比較 防水カメラの検証。プールを貸し切り、実際に潜って撮影 縦型洗濯機の検証。主要メーカー7社の中から人気商品を購入して検証 ヘアアイロンの検証。全商品を実際に使用して違いを検証 チェーンソーの検証。片道2時間ほどかけて、山奥にこもって検証 電子レンジの検証。実際の使い勝手などをリアルに検証 商品を自社で購入し、専門性を持ったメンバーが徹底検証
8. • 自社で商品を購入して検証している ◦ スペックやレーティングなど自社検証したどこにもないデータ • あらゆるジャンルのあらゆる商品・サービスを扱っている ◦ 商品テーブルのレコード数：約200万件 ◦ スペックやレーティングのカラムが 事前に定義できない • ランキング内でスペックによる絞り込みや レーティングによる並び替えが可能 マイベストのデータの特徴
9. 直面した課題 2
10. いろんな人の声 管理画面が重いです。 カテゴリページの表示に 40秒以上かかります。 ランキングでスペック情報での並び替えや 範囲での絞り込みをしたいね。 このサイトたまに重いなぁ。。 （キャッシュが切れたタイミング） 社内メンバー ユーザー PO
11. • 当初の要件とは別の使われ方をすることによるデータの重複・大量増加 • レコード数の増加やクエリの複雑化によるパフォーマンスの低下 • ランキングでの絞り込みや並び替えで、より柔軟な検索を実現したい という要望 自社検証の導入から数年経ち、従来の設計では難しい部分が出てきた
12. 自社検証の開始から数年でサービスが大きく成長した サービスの成長
13. • データ量が増える • トラフィックが増える • 使われ方が変わる • 機能が増える リリース時は負債ではなかったがサービスの成長に伴い負債となった 技術的負債 リリース時に 認知していた負債 リリース時に 認知していない負債 そもそも負債だと 思っていなかった 環境変化により 技術的負債になった ※1：mkitahara, 技術的負債の発生と返し方の判断基準 未認知の技術的負債（※ 1）
14. • このままだとユーザーに継続して価値を届け続けられない • 現状の課題や要望に合わせて商品データベースの設計を見直す 商品DB再設計プロジェクト始動！
15. 商品DB再設計をどのように進めたか？ 3
16. 参考にした書籍
17. 再設計の進め方 ①課題抽出 ②要件定義 ③技術調査・ 　設計 ④開発・ 　データ移行
18. 再設計の進め方 ①課題抽出 ②要件定義 ③技術調査・　 設計 ④開発・ 　データ移行
19. ①課題抽出 ステークホルダーを整理する コンテンツ制作チーム ユーザー PO 機能要望 サービス利用 開発チーム A, B, C 機能追加 商品DB 品質管理チーム・オペチーム 検証データの登録 項目の定義 スペック情報の登録
20. • 関係各所にヒアリングして現状の 課題を洗い出す ◦ 各30-60minのMTGをセット • 表面上の課題・ニーズだけでなく、 コンテキストを掘り下げることが重要 ①課題抽出 ステークホルダーにヒアリングする
21. • 挙がった問題を吟味し、解決すべき課題を絞る ◦ ユーザー・ビジネス・技術においてサービス上ボトルネックとなる箇所 ◦ 解決可能な問題か • 今回のケースでは ◦ 範囲による絞り込みなど柔軟な商品検索の実現 ◦ 重くなっているページのパフォーマンス向上 ①課題抽出 今回解決すべき課題を特定する
22. 再設計の進め方 ①課題抽出 ②要件定義 ③技術調査・　 設計 ④開発・ 　データ移行
23. • 技術的な制約 • ビジネス上の制約 • 影響力のある機能要求 • 品質特性の要求 ASR: Architecturally Significant Requirement ②要件定義 アーキテクチャ上重要な要求（ASR）を明らかにする
24. • 技術的な制約 • ビジネス上の制約 • 影響力のある機能要求 • 品質特性の要求 ◦ パフォーマンス：キャッシュが切れても1秒以内にレスポンスを返す ◦ パフォーマンス：Adminで40秒かかっているページを数秒以内にする ◦ 可用性：検索の仕組みが応答しない場合でも数十秒以内に復旧する ◦ スケーラビリティ：商品数が今のペースで3年増えても耐えうる ②要件定義 アーキテクチャ上重要な要求（ASR）を明らかにする 品質特性についての一例（他の項目は時間の関係で割愛）
25. • インセプションデッキやPRDを作成して、関係者で共通認識をとる ◦ 再設計には一定のリソースが必要 なので関係者の理解と協力が必須 ◦ 関係者へのメリットを提示する ◦ 期待値調整が大事！ • 機能要求は継続的に関係者にヒアリング して詰めていく ②要件定義 インセプションデッキ、PRDを作成する
26. 再設計の進め方 ①課題抽出 ②要件定義 ③技術調査・　 設計 ④開発・ 　データ移行
27. • 課題を解決するための実現方法について各種技術を調査 ◦ MUST ▪ 検索性・パフォーマンス ▪ 動的なフィールド追加 ▪ スケーラビリティ ◦ WANT ▪ ファセット検索 ▪ 各フィールドでの並び替え ③技術調査・設計 実現方法について技術調査する
28. ③技術調査・設計 選択肢を比較する それぞれの方法について MUST/WANTの要件を満たせるかや各種コストなどを評価
29. • MUSTの要件を満たすものの中でさらに詳細にPros/Consを比較し決定する ◦ 今の状況に必要十分な設計・アーキテクチャを選ぶ • 今回のケースでは ◦ ElasticsearchとAlgoliaがともにMUST要件を満たしたが、WANT要件や今後 の拡張性を考え、Elasticsearchを選択 • 設計方針 ◦ ボトルネックとなっているテーブル構造を見直す ◦ Elasticsearchを導入し、絞り込みや並び替えはElasticsearchに任せる ③技術調査・設計 設計・アーキテクチャを決定する
30. • 設計の内容をDesign Docsにまとめる ◦ プロジェクトの背景・目的・設計・検討した代替案などを書く ◦ 関係者と共有・議論することで、事前に全体を考察し、精度を高め、 開発後の手戻りを防ぐ • 特に検討した代替案が重要 ◦ ADR（Architecture Decision Record）でも可 ◦ 他にどんな選択肢があり、なぜこの設計を選んだのかをコンテキスト とともに記録する ③技術調査・設計 設計・アーキテクチャを共有する
31. ③技術調査・設計 今回の設計の概略図 ・スペック情報の「管理用の値」を扱うテーブルが 2,000万レコードありボトルネックに ・既存の「検索タグ」の仕組みだと範囲による検索などができない
32. ③技術調査・設計 今回の設計の概略図 ・テーブル構造を見直し、ボトルネックになっている「管理用の値」をなくす ・Elasticsearchを導入することで、パフォーマンス向上と柔軟な絞り込みを実現
33. 再設計の進め方 ①課題抽出 ②要件定義 ③技術調査・　 設計 ④開発・ 　データ移行
34. • リスクの高い部分から取り掛かる ◦ Elasticsearchのフィールドの動的な追加 ◦ フィールド数が増えた場合のパフォーマンス • 実際に実装してみてフィードバックを設計に反映する ◦ Elasticsearchのインデックスの持ち方 ◦ テーブル設計の見直し ④開発・データ移行 リスクの高い部分から開発に取り掛かる
35. • 並行稼働するためにテーブルに新形式かどうかのフラグを追加 ◦ フラグがONなら新形式 ◦ 新旧両方のテーブルに書き込みを行い、サービスを止めずにデータ移行 ◦ 影響の少ないカテゴリから実施 ◦ フラグをOFFにすれば切り戻せる • 本番と同じデータのレビュー環境で移行を試し、 担当者に使ってみてもらって問題ないことを確認 ④開発・データ移行 サービスを止めずに既存データを安全に新形式に移行する
36. 結果と学び 4
37. • 範囲による検索など柔軟な絞り込みが可能になった • 2,000万レコードの巨大なテーブルを削除できた • 重かった編集画面のレスポンスタイムが 40s → 1.6s に改善した（96%削減） • Admin全体のレイテンシが約2倍改善した 商品DB再設計の結果
38. • 最適な設計・アーキテクチャを選択するには 技術だけでなく、ビジネスやユーザーなど 幅広い視野で考える必要がある • 頭の中に答えはない ◦ ステークホルダーにヒアリングして 現状の課題や要求を明らかにする 技術だけではなく広い視野を持ってシステム全体を考える ビジネス 技術 ユーザー ソフトウェア アーキテクト ソフトウェアアーキテクトの立ち位置（※ 2） ※2：Michael Keeling, Design It! 学び①
39. • アーキテクチャは絶対的な正解があるわけではなく、すべて「場合による」 ◦ トレードオフを分析して、複数の選択肢の中から自分たちの状況に 最適な選択肢を選ぶ必要がある ◦ 状況が変われば正解も変わる • 今見えていないものを見通すことは難しいが、今見えているものは把握し、 その中で必要十分な設計・アーキテクチャを選ぶ ◦ 「見通すことは難しい＝考えない」ということではない ◦ 今見えているものを把握することを怠らない 学び② ソフトウェアアーキテクチャはトレードオフである
40. まとめ 5
41. • リリース時には負債でなくともサービスが成長すると環境が変化し、技術的負債は 必ず発生する • 技術だけではなく広い視野を持ってシステム全体を考えることが大事 ◦ ステークホルダーにヒアリングして現状の課題や要求を明らかにする • ソフトウェアアーキテクチャはトレードオフであり、絶対的な正解はない ◦ 自分たちの状況を正しく把握した上で、その時点での必要十分な設計・アー キテクチャを選択する • 状況が変われば正解も変わるので継続的にリアーキテクティングしていく まとめ