Tweet
Tweet

Slide 1

Slide 1 text

ほ し い と 出 会 え る イ ン テ ン ト セ ー ル ス 急成長スタートアップを支える データ基盤の裏側 2024-03-13 Sales Marker CTO チン シン X @ShinChen03

Slide 2

Slide 2 text

INDEX © Sales Marker Co., Ltd. 2 01 自己紹介 02 事業紹介 03 要求の変化とデータ構造の変化 04 どう設計すれば良かった？ 05 最後に

Slide 3

Slide 3 text

株式会社SalesMarker 取締役CTO 陳 晨（チン シン） / @ShinChen03 アメリカワシントン大学セントルイス校修士課程終了後、 LINE株式会社に新卒入社。全社横断ビッグデータプラット フォーム構築プロジェクトに従事後、日本マイクロソフトに転 職し、AI＆ビッグデータ部門にて世界中のお客様に対しシステ ム設計から開発、運用までシステム全般をサポート。その後株 式会社スタンバイにてリアルタイム分析基盤の構築をリードす る。 テクノロジーで社会の効率化に貢献したい想いにより、 CrossBorder株式会社（現：株式会社Sales Marker）を共同 創業。 ex 自己紹介

Slide 4

Slide 4 text

© CrossBorder. inc 4 ※自社調べ

Slide 5

Slide 5 text

5 © Sales Marker Co., Ltd. ※出所： 2019 Gartner End-User Buyer Surveyより 自社の課題を解決するツールを 導入したいとき、何をしますか？

Slide 6

Slide 6 text

% Webで検索をした経験がある

Slide 7

Slide 7 text

購買意思決定の60%を占める事前調査部分に直接アプローチできないことで 取りこぼしが起きているため、事前調査時点でアプローチを行うことが必要 購買プロセスの60%がWeb上で終了している 7 © Sales Marker Co., Ltd. BtoBビジネスにおいては購買プロセスのうち約60%が、ベンダーの営業担当者に会う前に 終了していると言われており、企業へのコンタクト段階ではほとんど意思決定が行われています。 事前調査 60% 営業担当 40% BtoBビジネスにおける購買プロセス ※出所： 2019 Gartner End-User Buyer Surveyより

Slide 8

Slide 8 text

© CrossBorder. inc 8 ※自社調べ

Slide 9

Slide 9 text

9 © Sales Marker Co., Ltd. ※出所： 2019 Gartner End-User Buyer Surveyより Sales Markerは、 2年でARR15億円 YoY 900% 成長

Slide 10

Slide 10 text

10 © Sales Marker Co., Ltd. ※出所： 2019 Gartner End-User Buyer Surveyより ユニコーン企業 “T2D3”の 2倍の成長速度

Slide 11

Slide 11 text

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人

Slide 12

Slide 12 text

エンジニアチームは 世界トップレベルのメンバーが集まっています

Slide 13

Slide 13 text

米Googleを始め、世界から優秀な人材が集結

Slide 14

Slide 14 text

14 © Sales Marker Co., Ltd. ※出所： 2019 Gartner End-User Buyer Surveyより Sales Markerは「インテントセールス」を実現します 国内最大500万件の法人データ、370万件の人物データ、50億レコードのインテントデータを保有 インテント 50億件 法人データ 500万件 人物データ 370万人 インテントセールスの仕組み 国内最大のデータ量

Slide 15

Slide 15 text

15 © Sales Marker Co., Ltd. ※出所： 2019 Gartner End-User Buyer Surveyより Sales Markerは「インテントセールス」を実現します 国内最大500万件の法人データ、370万件の人物データ、50億レコードのインテントデータを保有 インテント 50億件 法人データ 500万件 人物データ 370万人 インテントセールスの仕組み 国内最大のデータ量

Slide 16

Slide 16 text

事業成長にと共に変化する要件 急成長の裏側で、データに関する アーキテクチャはどう変化してきたのか？

Slide 17

Slide 17 text

事業成長にと共に変化する要件 フェーズ１（サービス開始初期） インテントデータ x 法人データ x 部署データ x 人物データ x 部分検索 要件 データ構造 3 index Daily 要件 データ構造 法人データ: 500万 インテントデータ: 2千 インテントデータ × 法人データ

Slide 18

Slide 18 text

事業成長にと共に変化する要件 フェーズ2（サービス開始2ヶ月後） インテントデータ x 法人データ x 部署データ x 人物データ x 部分検索 要件 データ構造 3 index Daily 課題：顧客のデータと突合する為、大量に名寄せを走らせる必要がある 法 人データの母数が多い為Aurora mysqlでは負荷が高い 要件 データ構造 法人データ: 500万 インテントデータ: 1万 インテントデータ × 法人データ × 部分検索

Slide 19

Slide 19 text

事業成長にと共に変化する要件 フェーズ2（サービス開始2ヶ月後） インテントデータ x 法人データ x 部署データ x 人物データ x 部分検索 要件 データ構造 3 index Daily 解決方法：Opensearchを導入し、検索用にデータを同期させる事で解決 要件 データ構造 法人データ: 500万 インテントデータ: 1万 1 index Daily インテントデータ × 法人データ × 部分検索

Slide 20

Slide 20 text

事業成長にと共に変化する要件 フェーズ3 インテントデータ x 法人データ x 部署データ x 人物データ x 部分検索 要件 データ構造 3 index Daily 課題：法人だけでは課題解決できず、部署や人物のデータを導入する必要 が新たに出てきた。 要件 データ構造 1 index Daily 法人データ: 500万 部署データ: 150万 人物データ: 300万 インテントデータ: 100万 インテントデータ × 法人データ インテントデータ × 部署データ インテントデータ × 人物データ × 部分検索

Slide 21

Slide 21 text

事業成長にと共に変化する要件 フェーズ3 インテントデータ x 法人データ x 部署データ x 人物データ x 部分検索 要件 データ構造 3 index Daily 解決方法：開発期間が2週間の為Indexを追加する事で対応 要件 データ構造 法人データ: 500万 部署データ: 150万 人物データ: 300万 インテントデータ: 100万 3 index Daily インテントデータ × 法人データ インテントデータ × 部署データ インテントデータ × 人物データ × 部分検索

Slide 22

Slide 22 text

事業成長にと共に変化する要件 フェーズ4 インテントデータ x 法人データ x 部署データ x 人物データ x 部分検索 要件 データ構造 3 index Daily 課題：OpensearchはJoin出来ず、Index間の横断的な検索が出来ない 要件 データ構造 法人データ: 500万 部署データ: 150万 人物データ: 300万 インテントデータ: 1000万 3 index Daily インテントデータ × 法人データ × 部署データ × 人物データ × 部分検索

Slide 23

Slide 23 text

事業成長にと共に変化する要件 フェーズ4 インテントデータ x 法人データ x 部署データ x 人物データ x 部分検索 要件 データ構造 3 index Daily 解決方法：新たなIndex設計をし、一定冗長させることで横断検索を可能に 要件 データ構造 法人データ: 500万 部署データ: 150万 人物データ: 300万 インテントデータ: 1000万 Unified index Daily インテントデータ × 法人データ × 部署データ × 人物データ × 部分検索

Slide 24

Slide 24 text

事業成長にと共に変化する要件 フェーズ5 インテントデータ x 法人データ x 部署データ x 人物データ x 部分検索 要件 データ構造 3 index Daily 課題：インテントデータが増えすぎてしまい、過去データを検索する際に パフォーマスが著しく落ちてしまう 要件 データ構造 法人データ: 500万 部署データ: 150万 人物データ: 300万 インテントデータ: 2億 Unified index Daily インテントデータ × 法人データ × 部署データ × 人物データ × 部分検索

Slide 25

Slide 25 text

事業成長にと共に変化する要件 フェーズ5 インテントデータ x 法人データ x 部署データ x 人物データ x 部分検索 要件 解決方法：Athenaを新規に立ち上げ、定期的に古いデータをアーカイブす る仕組みを作り、Hot/Coldデータの振り分けを実施 要件 法人データ: 500万 部署データ: 150万 人物データ: 300万 インテントデータ: 2億 インテントデータ × 法人データ × 部署データ × 人物データ × 部分検索 データ構造 3 index Daily データ構造 Unified index Daily Daily

Slide 26

Slide 26 text

事業成長にと共に変化する要件 フェーズ6 インテントデータ x 法人データ x 部署データ x 人物データ x 部分検索 要件 データ構造 3 index Daily 課題：ユーザーデータを混ぜた検索がしたいが、検索エンジンへのSyncが Dailyの為、不可能だった 要件 データ構造 インテントデータ × 法人データ × 部署データ × 人物データ × 部分検索 × ユーサーデータ 法人データ: 500万 部署データ: 150万 人物データ: 300万 インテントデータ: 2億 Unified index Daily Daily

Slide 27

Slide 27 text

事業成長にと共に変化する要件 フェーズ6 インテントデータ x 法人データ x 部署データ x 人物データ x 部分検索 要件 データ構造 3 index Daily 解決方法：Opensearchの更新をリアルタイムに 要件 データ構造 インテントデータ × 法人データ × 部署データ × 人物データ × 部分検索 × ユーサーデータ 法人データ: 500万 部署データ: 150万 人物データ: 300万 インテントデータ: 20億 Unified index Daily Realtime

Slide 28

Slide 28 text

要件の発生時間軸とデータ構造の変化 3月 2022年 サービス開始 2023年 2024年 7月 5月 データ構造フェーズ2 10月 データ構造フェーズ3 2月 データ構造フェーズ4 データ構造フェーズ5 データ構造フェーズ6 1月

Slide 29

Slide 29 text

要件の発生時間軸とデータ構造の変化 3月 2022年 サービス開始 2023年 2024年 7月 5月 データ構造フェーズ2 10月 データ構造フェーズ3 2月 データ構造フェーズ4 データ構造フェーズ5 データ構造フェーズ6 1月 全ての変更は2〜3週間内で行う必要があった 新規機能の開発も止められなかった

Slide 30

Slide 30 text

要件の発生時間軸とデータ構造の変化 3月 2022年 サービス開始 2023年 2024年 7月 5月 データ構造フェーズ2 10月 データ構造フェーズ3 2月 データ構造フェーズ4 データ構造フェーズ5 データ構造フェーズ6 1月 エンジニアの人数は常に不足、顧客数は増え続けるので 必須開発要件もどんどん増える

Slide 31

Slide 31 text

どう設計しておけば良かった？ そもそもサービス開始から要件が大幅に変わっている 短期間での修正が要求される

Slide 32

Slide 32 text

どう設計しておけば良かった？ そもそもサービス開始から要件が大幅に変わっている 短期間での修正が要求される 完全に負債を避けることは不可能

Slide 33

Slide 33 text

どう設計しておけば良かった？ よかった点 要件が変わった時点で無理に対応せず、 アーキテクチャレベルで素早く変更することで 大きな負債を作らずに済んだ

Slide 34

Slide 34 text

どう設計しておけば良かった？ よかった点 もしOpensearchを導入せず、 Auroraで無理に進めていたら、 全ての検索がAurora依存になってしまい、 大きな負債になっていた可能性が高い

Slide 35

Slide 35 text

どう設計しておけば良かった？ 反省点 もう少し未来を見据えれば良かった

Slide 36

Slide 36 text

どう設計しておけば良かった？ もう一度やるなら 半年後確実に起こる事を 常に思い浮かべながら設計する

Slide 37

Slide 37 text

どう設計しておけば良かった？ もう一度やるなら 半年後確実に起こる事を 常に思い浮かべながら設計する 例：顧客が増える、データが増える、エンプラのユーザーが増え 、顧客データとの連携等は予測できた

Slide 38

Slide 38 text

どう設計しておけば良かった？ もう一度やるなら データ構造の特性を理解し、 ボトルネックがある場合は システムレベルで負債返済に取り組む

Slide 39

Slide 39 text

どう設計しておけば良かった？ もう一度やるなら 構造レベルのボトルネックがある場合、 コードレベルで無理して頑張らない

Slide 40

Slide 40 text

どう設計しておけば良かった？ もう一度やるなら 逆に変数に関しては無理に考える必要がない 例：新たなデータと連携する可能性 新たな機能開発で既存の構造では対応できなくなる可能性

Slide 41

Slide 41 text

最後に