モノタロウがGCPで挑戦するデータドリブン ECプラットフォーム

モノタロウがGCPで挑戦するデータドリブン ECプラットフォーム

  • devsumiの記録です

紹介

​

モノタロウ

  • CM紹介
  • BtoBで関節資材の販売会社
  • モノタロウが入る前は時間と人的コストがかかるものだった
  • 見積もりー＞価格交渉と納期確定ー＞配送
  • 価格交渉なしで翌日届く ​

    モノタロウの価値

  • 関節資材の調達プロセスをテクノロジーとデータで圧倒的に簡単にする
  • 価格透明性、必要なものを全て、すぐ見つかる買えるを提供する
  • １８００万SKU（ストック・キーピング・ユニット）ー＞（単品管理） ​

    データマーケティング

  • 顧客接点でデータを活用
  • 業種別最適化、SEO /SEM、プッシュ型マーケテイィング、特価クーポン ​

    検索最適化一例

  • ユーザの業種で、手袋にしても、医療系か、製造業を絞る
  • 「涙目」ー＞業界用語　等の検索結果で商品マスタのない専門ワード業界用語も検索可能にする ​

    エンジニアリングドリブンなカルチャー

  • AI無人店舗を佐賀県でやっている ​

    モノタロウのデータマーケティングの基盤説明

    ​

    古いデータ基盤

  • データ基盤の分散
  • オンプレデータ基盤
  • 分析にひつようなデータがそろっていない
  • データが集約されスケールできる基盤がほしかった
  • そこであたらしい基盤 ​

    あたらしい基盤の成果

  • 全てが１０倍に。1000テーブル、Biが３００レポート、SQL業務利用者人数が50人 ​

    新しい基盤紹介

  • BigQuery RqwData、DWHを活用
  • Oracleから移行-> Digdog,embulk->DWHへ
  • Mysql から移行-> BinlogConnectorでDWHへ
  • BiqQueryにしたのは、圧倒的スケーラビリティ ​

    CDCによるデータ連携

  • 変更情報を取得して、擬似的にSlaveDB作成
  • BinlogConnectorで実現 ​

    BinlogConnector

  • 変更情報ををSchemalizerでDDL作成
  • 変更情報をPubSubni経由でProcesseorにわたしRowDataへ渡した（DML作成） ​

    BinlogConnector

  • データ基盤にできるだけリアルタイムに近いデータ利用のニーズ
  • マスタDBに負荷をかけない ​

    非エンジニアにDB基盤を提供

  • BiqQueryだと業務担当が直接SQLかける
  • 同時にクエリ流してもBiqQueryなら問題ない ​

    どうやってSQL学んだか

  • 定期的に研修
  • もともとクエリを使う非エンジニアがいた
  • Slackのチャンネルで質問答えた
  • アドホックにクエリをなげて活用して慣れた ​

    管理ポイント

  • AuthorizedViewでみせない
  • 秘密情報はマスキング
  • あらゆる人にアドホッックにクリ強化 ​

    ECアプリケーションの活用

  • パーソナライズ化したデータをAPI化して、ECアプリに活用
  • ECアプリのデータ基盤を今後刷新したい ​

    ECアプリの刷新のアーキテグクト

    ​

    モノタロウ

  • セッション数千万/月
  • 数十万/月 ​

    ECサイトの構成要素説明

  • 検索が専門用語対応している
  • ただ機能は他のECサイトとほぼ同じ
  • ただ資材の専門知識がいる ​

    今まで

  • 倉庫や部門によって商品在庫の管理がバラバラだった ​

    セキュティ問題

  • Chrome Samesite
  • AppleITp2.1 ​

    コード管理の問題

  • API のエンドポイント増加
  • リクエスト増加
  • APIのコール元の管理が大変
  • そのためスケーラビリティトアジリティーが必要 ​

    モノタロウの

  • SEMとリスティング
  • 業種別リコメンド
  • システム全体像説明 ​

    課題

  • データ活用がしにくい
  • 非対称なアーキテクト
  • データがAwSとGCPとオンプレに別れた ​

    READMODELのばらつき

  • DBスキーマ(店舗で在庫データがばらばらとか避けるニーズ)
  • フロントエンド
  • マーケターダッシュボード
  • RESTAPIによる改善をしてきた ​

    REST API化で改善したが

  • １００近いエンドポイントで依存関係がつよくなってきた
  • APIの属人化 ​

    DBスケーラビリティ

  • 商品、価格、納期をJOINしているとDBに負荷かかる
  • そこでインデックス使うと、検索インデックス増加で負荷集中した
  • そこで改善したい ​

    スター型からスパイラル型へ

  • MYSQLに集中した形がスター型でから、GCPを用いたAPIのスパイラル型へ ​

    データ活用をしたリコメンドのために

  • リリスースが用意でスケーラブルなAPI
  • 常に最新データが反映されたストレージ
  • 持続的な成長を支えるインフラ ​

    そのための改善点

  • 既存APIのマイクロサービス化
  • 巨大バッチのイベントドリブン化
  • UXに関わるイベントでビューを逐次更新したい
  • マーケティングもリアルタイム化したい ​

    どうやって実現->CahgeDataCapturerする

  • BinLogとPUBSUBで、MYSQLテーブルデータを、そのままBigTable（KVS）へレプリケート ​

    CDCによるデータパイプライン

  • CloudDataFlowを使ってBigTableへいれる ​

    運用のデータドリブン化

    変化への柔軟な対応のための以下への指標と予測

  • ユーザ数売り上げの伸び
  • 新たな施策やトラフィックの変動 ​

    対策

  • A/Bテスト・カナリアリリースー＞SLO/SLIによるデータ・ドリブン運用
  • BigQuery,GKE,Spinnaker,DataDoG,StackDriverを活用