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

Slide 1

Slide 1 text

あらゆる商品を扱う商品データベースを再設計した話 2024/03/26 ＠Offers データ構造x技術負債LT vol.2 rince (@kazumax1218)

Slide 2

Slide 2 text

rince（@kazumax1218） ○ 2011- カカクコム（食べログ→キナリノ） ○ 2018- メルカリ（ソウゾウ→メルペイ） ○ 2020- マイベスト ○ 旅とキャンプとサウナが好き⛺ ○ 最近は育児に奮闘中👶 自己紹介

Slide 3

Slide 3 text

● 実例を通してデータベースやアーキテクチャを再設計をする際の進め方がわかる ○ 設計理論 ← 既に巷にいい資料がたくさん ○ 設計の進め方の一例 ● あらゆる商品を扱う商品データベースの仕組みが少しわかる ○ 時間の関係で詳細までは解説できず… この発表でわかること

Slide 4

Slide 4 text

マイベストについて目次 1 直面した課題 2 商品DB再設計をどう進めたか？ 3 結果と学び 4 まとめ 5

Slide 5

Slide 5 text

マイベストについて 1

Slide 6

Slide 6 text

月間利用者数 3,000 ユーザーの“選択”をサポートする商品比較サービス万人以上

Slide 7

Slide 7 text

雨傘の検証。送風機を使って「耐風性」を比較防水カメラの検証。プールを貸し切り、実際に潜って撮影縦型洗濯機の検証。主要メーカー7社の中から人気商品を購入して検証ヘアアイロンの検証。全商品を実際に使用して違いを検証チェーンソーの検証。片道2時間ほどかけて、山奥にこもって検証電子レンジの検証。実際の使い勝手などをリアルに検証商品を自社で購入し、専門性を持ったメンバーが徹底検証

Slide 8

Slide 8 text

● 自社で商品を購入して検証している ○ スペックやレーティングなど自社検証したどこにもないデータ ● あらゆるジャンルのあらゆる商品・サービスを扱っている ○ 商品テーブルのレコード数：約200万件 ○ スペックやレーティングのカラムが事前に定義できない ● ランキング内でスペックによる絞り込みやレーティングによる並び替えが可能マイベストのデータの特徴

Slide 9

Slide 9 text

直面した課題 2

Slide 10

Slide 10 text

いろんな人の声管理画面が重いです。カテゴリページの表示に 40秒以上かかります。ランキングでスペック情報での並び替えや範囲での絞り込みをしたいね。このサイトたまに重いなぁ。。（キャッシュが切れたタイミング）社内メンバーユーザー PO

Slide 11

Slide 11 text

● 当初の要件とは別の使われ方をすることによるデータの重複・大量増加 ● レコード数の増加やクエリの複雑化によるパフォーマンスの低下 ● ランキングでの絞り込みや並び替えで、より柔軟な検索を実現したいという要望自社検証の導入から数年経ち、従来の設計では難しい部分が出てきた

Slide 12

Slide 12 text

自社検証の開始から数年でサービスが大きく成長したサービスの成長

Slide 13

Slide 13 text

● データ量が増える ● トラフィックが増える ● 使われ方が変わる ● 機能が増えるリリース時は負債ではなかったがサービスの成長に伴い負債となった技術的負債リリース時に認知していた負債リリース時に認知していない負債そもそも負債だと思っていなかった環境変化により技術的負債になった ※1：mkitahara, 技術的負債の発生と返し方の判断基準未認知の技術的負債（※ 1）

Slide 14

Slide 14 text

● このままだとユーザーに継続して価値を届け続けられない ● 現状の課題や要望に合わせて商品データベースの設計を見直す商品DB再設計プロジェクト始動！

Slide 15

Slide 15 text

商品DB再設計をどのように進めたか？ 3

Slide 16

Slide 16 text

参考にした書籍

Slide 17

Slide 17 text

再設計の進め方 ①課題抽出 ②要件定義 ③技術調査・　設計 ④開発・　データ移行

Slide 18

Slide 18 text

再設計の進め方 ①課題抽出 ②要件定義 ③技術調査・　設計 ④開発・　データ移行

Slide 19

Slide 19 text

①課題抽出ステークホルダーを整理するコンテンツ制作チームユーザー PO 機能要望サービス利用開発チーム A, B, C 機能追加商品DB 品質管理チーム・オペチーム検証データの登録項目の定義スペック情報の登録

Slide 20

Slide 20 text

● 関係各所にヒアリングして現状の課題を洗い出す ○ 各30-60minのMTGをセット ● 表面上の課題・ニーズだけでなく、コンテキストを掘り下げることが重要 ①課題抽出ステークホルダーにヒアリングする

Slide 21

Slide 21 text

● 挙がった問題を吟味し、解決すべき課題を絞る ○ ユーザー・ビジネス・技術においてサービス上ボトルネックとなる箇所 ○ 解決可能な問題か ● 今回のケースでは ○ 範囲による絞り込みなど柔軟な商品検索の実現 ○ 重くなっているページのパフォーマンス向上 ①課題抽出今回解決すべき課題を特定する

Slide 22

Slide 22 text

再設計の進め方 ①課題抽出 ②要件定義 ③技術調査・　設計 ④開発・　データ移行

Slide 23

Slide 23 text

● 技術的な制約 ● ビジネス上の制約 ● 影響力のある機能要求 ● 品質特性の要求 ASR: Architecturally Signiﬁcant Requirement ②要件定義アーキテクチャ上重要な要求（ASR）を明らかにする

Slide 24

Slide 24 text

● 技術的な制約 ● ビジネス上の制約 ● 影響力のある機能要求 ● 品質特性の要求 ○ パフォーマンス：キャッシュが切れても1秒以内にレスポンスを返す ○ パフォーマンス：Adminで40秒かかっているページを数秒以内にする ○ 可用性：検索の仕組みが応答しない場合でも数十秒以内に復旧する ○ スケーラビリティ：商品数が今のペースで3年増えても耐えうる ②要件定義アーキテクチャ上重要な要求（ASR）を明らかにする品質特性についての一例（他の項目は時間の関係で割愛）

Slide 25

Slide 25 text

● インセプションデッキやPRDを作成して、関係者で共通認識をとる ○ 再設計には一定のリソースが必要なので関係者の理解と協力が必須 ○ 関係者へのメリットを提示する ○ 期待値調整が大事！ ● 機能要求は継続的に関係者にヒアリングして詰めていく ②要件定義インセプションデッキ、PRDを作成する

Slide 26

Slide 26 text

再設計の進め方 ①課題抽出 ②要件定義 ③技術調査・　設計 ④開発・　データ移行

Slide 27

Slide 27 text

● 課題を解決するための実現方法について各種技術を調査 ○ MUST ■ 検索性・パフォーマンス ■ 動的なフィールド追加 ■ スケーラビリティ ○ WANT ■ ファセット検索 ■ 各フィールドでの並び替え ③技術調査・設計実現方法について技術調査する

Slide 28

Slide 28 text

③技術調査・設計選択肢を比較するそれぞれの方法について MUST/WANTの要件を満たせるかや各種コストなどを評価

Slide 29

Slide 29 text

● MUSTの要件を満たすものの中でさらに詳細にPros/Consを比較し決定する ○ 今の状況に必要十分な設計・アーキテクチャを選ぶ ● 今回のケースでは ○ ElasticsearchとAlgoliaがともにMUST要件を満たしたが、WANT要件や今後の拡張性を考え、Elasticsearchを選択 ● 設計方針 ○ ボトルネックとなっているテーブル構造を見直す ○ Elasticsearchを導入し、絞り込みや並び替えはElasticsearchに任せる ③技術調査・設計設計・アーキテクチャを決定する

Slide 30

Slide 30 text

● 設計の内容をDesign Docsにまとめる ○ プロジェクトの背景・目的・設計・検討した代替案などを書く ○ 関係者と共有・議論することで、事前に全体を考察し、精度を高め、開発後の手戻りを防ぐ ● 特に検討した代替案が重要 ○ ADR（Architecture Decision Record）でも可 ○ 他にどんな選択肢があり、なぜこの設計を選んだのかをコンテキストとともに記録する ③技術調査・設計設計・アーキテクチャを共有する

Slide 31

Slide 31 text

③技術調査・設計今回の設計の概略図・スペック情報の「管理用の値」を扱うテーブルが 2,000万レコードありボトルネックに・既存の「検索タグ」の仕組みだと範囲による検索などができない

Slide 32

Slide 32 text

③技術調査・設計今回の設計の概略図・テーブル構造を見直し、ボトルネックになっている「管理用の値」をなくす・Elasticsearchを導入することで、パフォーマンス向上と柔軟な絞り込みを実現

Slide 33

Slide 33 text

再設計の進め方 ①課題抽出 ②要件定義 ③技術調査・　設計 ④開発・　データ移行

Slide 34

Slide 34 text

● リスクの高い部分から取り掛かる ○ Elasticsearchのフィールドの動的な追加 ○ フィールド数が増えた場合のパフォーマンス ● 実際に実装してみてフィードバックを設計に反映する ○ Elasticsearchのインデックスの持ち方 ○ テーブル設計の見直し ④開発・データ移行リスクの高い部分から開発に取り掛かる

Slide 35

Slide 35 text

● 並行稼働するためにテーブルに新形式かどうかのフラグを追加 ○ フラグがONなら新形式 ○ 新旧両方のテーブルに書き込みを行い、サービスを止めずにデータ移行 ○ 影響の少ないカテゴリから実施 ○ フラグをOFFにすれば切り戻せる ● 本番と同じデータのレビュー環境で移行を試し、担当者に使ってみてもらって問題ないことを確認 ④開発・データ移行サービスを止めずに既存データを安全に新形式に移行する

Slide 36

Slide 36 text

結果と学び 4

Slide 37

Slide 37 text

● 範囲による検索など柔軟な絞り込みが可能になった ● 2,000万レコードの巨大なテーブルを削除できた ● 重かった編集画面のレスポンスタイムが 40s → 1.6s に改善した（96%削減） ● Admin全体のレイテンシが約2倍改善した商品DB再設計の結果

Slide 38

Slide 38 text

● 最適な設計・アーキテクチャを選択するには技術だけでなく、ビジネスやユーザーなど幅広い視野で考える必要がある ● 頭の中に答えはない ○ ステークホルダーにヒアリングして現状の課題や要求を明らかにする技術だけではなく広い視野を持ってシステム全体を考えるビジネス技術ユーザーソフトウェアアーキテクトソフトウェアアーキテクトの立ち位置（※ 2） ※2：Michael Keeling, Design It! 学び①

Slide 39

Slide 39 text

● アーキテクチャは絶対的な正解があるわけではなく、すべて「場合による」 ○ トレードオフを分析して、複数の選択肢の中から自分たちの状況に最適な選択肢を選ぶ必要がある ○ 状況が変われば正解も変わる ● 今見えていないものを見通すことは難しいが、今見えているものは把握し、その中で必要十分な設計・アーキテクチャを選ぶ ○ 「見通すことは難しい＝考えない」ということではない ○ 今見えているものを把握することを怠らない学び② ソフトウェアアーキテクチャはトレードオフである

Slide 40

Slide 40 text

まとめ 5

Slide 41

Slide 41 text

● リリース時には負債でなくともサービスが成長すると環境が変化し、技術的負債は必ず発生する ● 技術だけではなく広い視野を持ってシステム全体を考えることが大事 ○ ステークホルダーにヒアリングして現状の課題や要求を明らかにする ● ソフトウェアアーキテクチャはトレードオフであり、絶対的な正解はない ○ 自分たちの状況を正しく把握した上で、その時点での必要十分な設計・アーキテクチャを選択する ● 状況が変われば正解も変わるので継続的にリアーキテクティングしていくまとめ