モノタロウがGCPで挑戦するデータドリブン・ECプラットフォーム〜持続的成長の舞台裏

作成: 2020-02-14

概要

モノタロウは間接資材をECで販売し、継続して成長をしてきました。それを牽引しているのが徹底的なデータ活用によるデータマーケティングです。その一方で成長重視の開発を続けてきたことによりシステムの負債が増加が問題となっていました。既存システムを刷新とモダナイズを果たすと同時により高度なデータ活用を行うためのECプラットフォームをGCPを活用し、どう構築しているのかその現在進行形の舞台裏を発表します。

https://event.shoeisha.jp/devsumi/20200213/session/2344/

スピーカー

普川泰如[MonotaRO]
- エンジニアリングマネージャー
藤本洋一[MonotaRO]

スライド

https://speakerdeck.com/fpt/monotaro-devsumi2020winter

Togetter

https://togetter.com/li/1467928

内容

モノタロウとは

間接資材を売っているECサイト
原材料以外は間接資材
ビジネスモデル
- 以前の購買では見積→営業に交渉して納期指定をして、、、と手がかかりまくってた
- モノタロウでは価格交渉なしですぐに届く
- モノタロウ自体は購買に関わるコストを下げている
この購買プロセスのコストを下げているためにやってる3つのポイント
- 価格の透明性がある
- 必要なモノ全部ある
- すぐみつかる、買える
20％以上の成長を10年継続
- データマーケティングで成長を牽引
- システムは常にキャパシティの戦い
どんなデータ基盤しているの？
- あらゆる顧客接点をデータ活用して最適化
  - 誰：業種別最適化・パーソナライズ
  - 何を：SEO・SEM・検索・レコメンド
  - いつ：プッシュ型マーケティング
  - どのくらい：特化・クーポン
- 最適化の事例
  - ユーザーの業種を検索の表示順を最適化する
    - 手袋→ 医療系の人には、医療用手袋、製造業の人には軍手
- エンジニアリングドリブンナカルチャー
  - 自動倉庫
  - ピッキング
  - AI無人店舗

データマーケティングを支えるデータ基盤

旧データの問題点（〜2017）
- データの保存場所が分散→データの移動が大変
- オンプレデータ基盤のサーバースペックが足りない
- 分析に必要なデータが揃っていない
- →データが集約されていて
成果
- 扱えるデータ量：100テーブルから1000テーブル以上に
- 作成されたレポート数：30レポートから300レポート
- SQL業務利用者人数：10人から50人へ

活用のポイント1：あらゆるデータを一つにまとめた

基本はBigQuery
BigQueryにした理由
- フルマネージド
- シンプル
- 圧倒的スケーラビリティ
- GSuite連携
- Google Analytics連携

活用のポイント2：CDCによるデータ連携

データの変更情報のみを取得、処理を行うCDCを行い疑似的にSlaveDBを作成
MySQL BinLog Connector
- データ基盤にできるだけリアルタイムに近いデータ利用のニーズがあった
- 従来の方法だと
  - 物理削除に対応できないケースがある
  - 差分更新できないケースがある

活用のポイント3 業務担当者外のSQL

業務担当者にニーズがあった
分析依頼を行っているとスピードが遅い
業務担当者が直接クエリを流せば的確な分析ができる
BQの場合、同時実行クエリの増加における遅延が起きづらい

どうやって組織的にSQLを浸透させたのか？

定期的なSQL・BigQuery・DataStudio研修
もともとデータ分析を行う社風
SlackでHelpチャンネルでQAをキャッチアップできる

基盤の運用で気を配っていること

IAM管理

マスキング管理
Authorized View

コスト管理

あらゆる人にアドホックなクエリを許可
ハイコストなSQLについてはアラートが飛ぶように

データ基盤が整ってきたけど、ECアプリケーション刷新したい...ということで次はECサイトのリアーキテクチャの話に。

ECサイトのリアーキテクチャ

セッション：数千万/月
注文：数十万/月
ECサイトを取り巻く状況
- セキュリティ
  - Chrome SameSie
  - AppleITP
- システム関係
  - 既存コードのリファクタ
  - APIエンドポイント・リクエスト数増加
  - リアルタイムマーケティング施策増
マーケティング施策
- SEM/リスティング広告
- 業種別リコメンド
- 検索結果最適化
- キャンペーン
- プッシュマーケティング
- などをリアルタイムに最適化していきたい

現在のアーキテクチャの課題点

非対称なマルチクラウド
- AWSにECサイト（たまにS3にデータ転送したり...
- GCPにデータ基盤
- オンプレに基幹システム
ReadMode、更新頻度のばらつき
- DBスキーマ
- フロントエンド
- マーケターのダッシュボード
データ活用に適したアーキテクチャへ
- REST APIにしたが問題も増えてきた
  - エンドポイント増加
  - コール数の増加・依存関係の複雑化
  - ロジックの属人化
  - DBのスケーラビリティ
  - 検索インデックスへの負荷集中
  - データモデルのばらつき

リニューアル後のアーキテクチャ

MySQLのスター型でスケールしにくかった
リニューアル後は「データの流れのスパイラルに埋め込んだイメージ」
データ活用に適したアーキテクチャ
- リリースが簡単でスケーラブルなAPI
- 常に最新のデータが反映されたストレージ
- 持続的な成長をさせるインフラ
- システムとデータ基盤が共通のアーキテクチャになっていることがポイントではないか
既存API群のMicroService化
- サイでの活用とスケーリングのため
- one database per one micro service
巨大バッチのEvent-Driven化
- 購入、出荷などUXに関わるイベントでビューを逐次更新したい、マーケティングもリアルタイム化したい
- バッチで一定時間待たなければできなかったことをリアルタイムで
- ポイントはCDC
CDCによるパイプライン
- ある商品が更新されると、蓄積されているデータにも反映される
運用のデータドリブン化
- ユーザー数・売り上げの伸び
- アラタナ遺作やトラフィックへの変鼓動
- A/Bテスト・カナリアリリース
- SLO/SLIによるデータドリブンな運用
  - BigQuery
  - Kubernetes
  - Spinaker
  - DATADOG
  - Stackdriver

まとめ

アーキテクチャ的な概念はデータ基盤とシステムで統合
リファクタリング＋リアーキテクチャリング
SREも強化していきたい

感想

MySQL binlogが使ったことがないので気になった
今の案件で長期でデータ基盤を開発しているものがあるが、次の課題としては同じようにIAM問題とか出てきたり、本体となっているWebサービスのアーキテクチャを変えていくような話になるんだろうかと、案件について思いを馳せた（大変だ...