急成長スタートアップを支える データ基盤の裏側

Transcript

1. ほ し い と 出 会 え る イ ン テ ン ト セ ー ル ス 急成長スタートアップを支える データ基盤の裏側 2024-03-13 Sales Marker CTO チン シン X @ShinChen03
2. INDEX © Sales Marker Co., Ltd. 2 01 自己紹介 02 事業紹介 03 要求の変化とデータ構造の変化 04 どう設計すれば良かった？ 05 最後に
3. 株式会社SalesMarker 取締役CTO 陳 晨（チン シン） / @ShinChen03 アメリカワシントン大学セントルイス校修士課程終了後、 LINE株式会社に新卒入社。全社横断ビッグデータプラット フォーム構築プロジェクトに従事後、日本マイクロソフトに転 職し、AI＆ビッグデータ部門にて世界中のお客様に対しシステ ム設計から開発、運用までシステム全般をサポート。その後株 式会社スタンバイにてリアルタイム分析基盤の構築をリードす る。 テクノロジーで社会の効率化に貢献したい想いにより、 CrossBorder株式会社（現：株式会社Sales Marker）を共同 創業。 ex 自己紹介
4. © CrossBorder. inc 4 ※自社調べ
5. 5 © Sales Marker Co., Ltd. ※出所： 2019 Gartner End-User Buyer Surveyより 自社の課題を解決するツールを 導入したいとき、何をしますか？
6. % Webで検索をした経験がある
7. 購買意思決定の60%を占める事前調査部分に直接アプローチできないことで 取りこぼしが起きているため、事前調査時点でアプローチを行うことが必要 購買プロセスの60%がWeb上で終了している 7 © Sales Marker Co., Ltd. BtoBビジネスにおいては購買プロセスのうち約60%が、ベンダーの営業担当者に会う前に 終了していると言われており、企業へのコンタクト段階ではほとんど意思決定が行われています。 事前調査 60% 営業担当 40% BtoBビジネスにおける購買プロセス ※出所： 2019 Gartner End-User Buyer Surveyより
8. © CrossBorder. inc 8 ※自社調べ
9. 9 © Sales Marker Co., Ltd. ※出所： 2019 Gartner End-User Buyer Surveyより Sales Markerは、 2年でARR15億円 YoY 900% 成長
10. 10 © Sales Marker Co., Ltd. ※出所： 2019 Gartner End-User Buyer Surveyより ユニコーン企業 “T2D3”の 2倍の成長速度
11. 11 © Sales Marker Co., Ltd. ※出所： 2019 Gartner End-User Buyer Surveyより 組織人数: 2023/2 20人 → 2024/2 150人 エンジニア数: 2023/2 3人 → 2024/2 25人 40人 80人 120人 150人 100人 80人 40人
12. エンジニアチームは 世界トップレベルのメンバーが集まっています
13. 米Googleを始め、世界から優秀な人材が集結
14. 14 © Sales Marker Co., Ltd. ※出所： 2019 Gartner End-User Buyer Surveyより Sales Markerは「インテントセールス」を実現します 国内最大500万件の法人データ、370万件の人物データ、50億レコードのインテントデータを保有 インテント 50億件 法人データ 500万件 人物データ 370万人 インテントセールスの仕組み 国内最大のデータ量
15. 15 © Sales Marker Co., Ltd. ※出所： 2019 Gartner End-User Buyer Surveyより Sales Markerは「インテントセールス」を実現します 国内最大500万件の法人データ、370万件の人物データ、50億レコードのインテントデータを保有 インテント 50億件 法人データ 500万件 人物データ 370万人 インテントセールスの仕組み 国内最大のデータ量
16. 事業成長にと共に変化する要件 急成長の裏側で、データに関する アーキテクチャはどう変化してきたのか？
17. 事業成長にと共に変化する要件 フェーズ１（サービス開始初期） インテントデータ x 法人データ x 部署データ x 人物データ x 部分検索 要件 データ構造 3 index Daily 要件 データ構造 法人データ: 500万 インテントデータ: 2千 インテントデータ × 法人データ
18. 事業成長にと共に変化する要件 フェーズ2（サービス開始2ヶ月後） インテントデータ x 法人データ x 部署データ x 人物データ x 部分検索 要件 データ構造 3 index Daily 課題：顧客のデータと突合する為、大量に名寄せを走らせる必要がある 法 人データの母数が多い為Aurora mysqlでは負荷が高い 要件 データ構造 法人データ: 500万 インテントデータ: 1万 インテントデータ × 法人データ × 部分検索
19. 事業成長にと共に変化する要件 フェーズ2（サービス開始2ヶ月後） インテントデータ x 法人データ x 部署データ x 人物データ x 部分検索 要件 データ構造 3 index Daily 解決方法：Opensearchを導入し、検索用にデータを同期させる事で解決 要件 データ構造 法人データ: 500万 インテントデータ: 1万 1 index Daily インテントデータ × 法人データ × 部分検索
20. 事業成長にと共に変化する要件 フェーズ3 インテントデータ x 法人データ x 部署データ x 人物データ x 部分検索 要件 データ構造 3 index Daily 課題：法人だけでは課題解決できず、部署や人物のデータを導入する必要 が新たに出てきた。 要件 データ構造 1 index Daily 法人データ: 500万 部署データ: 150万 人物データ: 300万 インテントデータ: 100万 インテントデータ × 法人データ インテントデータ × 部署データ インテントデータ × 人物データ × 部分検索
21. 事業成長にと共に変化する要件 フェーズ3 インテントデータ x 法人データ x 部署データ x 人物データ x 部分検索 要件 データ構造 3 index Daily 解決方法：開発期間が2週間の為Indexを追加する事で対応 要件 データ構造 法人データ: 500万 部署データ: 150万 人物データ: 300万 インテントデータ: 100万 3 index Daily インテントデータ × 法人データ インテントデータ × 部署データ インテントデータ × 人物データ × 部分検索
22. 事業成長にと共に変化する要件 フェーズ4 インテントデータ x 法人データ x 部署データ x 人物データ x 部分検索 要件 データ構造 3 index Daily 課題：OpensearchはJoin出来ず、Index間の横断的な検索が出来ない 要件 データ構造 法人データ: 500万 部署データ: 150万 人物データ: 300万 インテントデータ: 1000万 3 index Daily インテントデータ × 法人データ × 部署データ × 人物データ × 部分検索
23. 事業成長にと共に変化する要件 フェーズ4 インテントデータ x 法人データ x 部署データ x 人物データ x 部分検索 要件 データ構造 3 index Daily 解決方法：新たなIndex設計をし、一定冗長させることで横断検索を可能に 要件 データ構造 法人データ: 500万 部署データ: 150万 人物データ: 300万 インテントデータ: 1000万 Unified index Daily インテントデータ × 法人データ × 部署データ × 人物データ × 部分検索
24. 事業成長にと共に変化する要件 フェーズ5 インテントデータ x 法人データ x 部署データ x 人物データ x 部分検索 要件 データ構造 3 index Daily 課題：インテントデータが増えすぎてしまい、過去データを検索する際に パフォーマスが著しく落ちてしまう 要件 データ構造 法人データ: 500万 部署データ: 150万 人物データ: 300万 インテントデータ: 2億 Unified index Daily インテントデータ × 法人データ × 部署データ × 人物データ × 部分検索
25. 事業成長にと共に変化する要件 フェーズ5 インテントデータ x 法人データ x 部署データ x 人物データ x 部分検索 要件 解決方法：Athenaを新規に立ち上げ、定期的に古いデータをアーカイブす る仕組みを作り、Hot/Coldデータの振り分けを実施 要件 法人データ: 500万 部署データ: 150万 人物データ: 300万 インテントデータ: 2億 インテントデータ × 法人データ × 部署データ × 人物データ × 部分検索 データ構造 3 index Daily データ構造 Unified index Daily Daily
26. 事業成長にと共に変化する要件 フェーズ6 インテントデータ x 法人データ x 部署データ x 人物データ x 部分検索 要件 データ構造 3 index Daily 課題：ユーザーデータを混ぜた検索がしたいが、検索エンジンへのSyncが Dailyの為、不可能だった 要件 データ構造 インテントデータ × 法人データ × 部署データ × 人物データ × 部分検索 × ユーサーデータ 法人データ: 500万 部署データ: 150万 人物データ: 300万 インテントデータ: 2億 Unified index Daily Daily
27. 事業成長にと共に変化する要件 フェーズ6 インテントデータ x 法人データ x 部署データ x 人物データ x 部分検索 要件 データ構造 3 index Daily 解決方法：Opensearchの更新をリアルタイムに 要件 データ構造 インテントデータ × 法人データ × 部署データ × 人物データ × 部分検索 × ユーサーデータ 法人データ: 500万 部署データ: 150万 人物データ: 300万 インテントデータ: 20億 Unified index Daily Realtime
28. 要件の発生時間軸とデータ構造の変化 3月 2022年 サービス開始 2023年 2024年 7月 5月 データ構造フェーズ2 10月 データ構造フェーズ3 2月 データ構造フェーズ4 データ構造フェーズ5 データ構造フェーズ6 1月
29. 要件の発生時間軸とデータ構造の変化 3月 2022年 サービス開始 2023年 2024年 7月 5月 データ構造フェーズ2 10月 データ構造フェーズ3 2月 データ構造フェーズ4 データ構造フェーズ5 データ構造フェーズ6 1月 全ての変更は2〜3週間内で行う必要があった 新規機能の開発も止められなかった
30. 要件の発生時間軸とデータ構造の変化 3月 2022年 サービス開始 2023年 2024年 7月 5月 データ構造フェーズ2 10月 データ構造フェーズ3 2月 データ構造フェーズ4 データ構造フェーズ5 データ構造フェーズ6 1月 エンジニアの人数は常に不足、顧客数は増え続けるので 必須開発要件もどんどん増える
31. どう設計しておけば良かった？ そもそもサービス開始から要件が大幅に変わっている 短期間での修正が要求される
32. どう設計しておけば良かった？ そもそもサービス開始から要件が大幅に変わっている 短期間での修正が要求される 完全に負債を避けることは不可能
33. どう設計しておけば良かった？ よかった点 要件が変わった時点で無理に対応せず、 アーキテクチャレベルで素早く変更することで 大きな負債を作らずに済んだ
34. どう設計しておけば良かった？ よかった点 もしOpensearchを導入せず、 Auroraで無理に進めていたら、 全ての検索がAurora依存になってしまい、 大きな負債になっていた可能性が高い
35. どう設計しておけば良かった？ 反省点 もう少し未来を見据えれば良かった
36. どう設計しておけば良かった？ もう一度やるなら 半年後確実に起こる事を 常に思い浮かべながら設計する
37. どう設計しておけば良かった？ もう一度やるなら 半年後確実に起こる事を 常に思い浮かべながら設計する 例：顧客が増える、データが増える、エンプラのユーザーが増え 、顧客データとの連携等は予測できた
38. どう設計しておけば良かった？ もう一度やるなら データ構造の特性を理解し、 ボトルネックがある場合は システムレベルで負債返済に取り組む
39. どう設計しておけば良かった？ もう一度やるなら 構造レベルのボトルネックがある場合、 コードレベルで無理して頑張らない
40. どう設計しておけば良かった？ もう一度やるなら 逆に変数に関しては無理に考える必要がない 例：新たなデータと連携する可能性 新たな機能開発で既存の構造では対応できなくなる可能性
41. 最後に