【わずか1ヶ月でリプレイスを実現！】アジアNo.1のマーケティングSaaSを目指すMicoworksがNoSQLからNewSQLに移行した理由 - Micoworks株式会社 - TiDB User Day 2023

by PingCAP-Japan

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

© 2022 Micoworks inc. 4 © 2023 Micoworks inc. 4 自己紹介 Chen Han 陳瀚 github: gpgkd906 中国四川 2005年留学来日 2022年末MicoworksにJoin SRE サービスの安定稼働 PHP, JavaScript, Rust, C#, LISP, Swift, Nginx, MySql, Redis, Azure, Git, Docker, Kubernetes, etc… ・チーム1人でサイト構築・50万/日PVの掲示板システムの開発・大規模ECサイト構築・大規模予約サイト設計・大規模予約サイト構築・ラズパイのIOT案件・炎上案件の鎮火・社内開発基盤・Hardening Project etc.. 関西 webエンジニア

Slide 5

Slide 5 text

© 2022 Micoworks inc. 5 © 2023 Micoworks inc. 5 会社紹介 Micoworks株式会社設立 93名 (2022年10月1日現在) 資本金従業員数大阪府大阪市北区曽根崎新地1-13-22 WeWork 御堂筋フロンティア大阪本社東京オフィス東京都千代田区麹町6-6-2 WeWork 麴町 1億円 (累計資金調達額：28億円) 2017年10月30日チャットを活用したマーケティングツール「MicoCloud」事業内容認証取得プライバシーマーク登録番号：20002452 ISO/IEC 27001 登録番号：IS 767462 LINE Technology Partner 2021 LINE Sales Partner 2022

Slide 6

Slide 6 text

Slide 7

Slide 7 text

© 2022 Micoworks inc. 7 © 2023 Micoworks inc. 7 MicoCloudのサービスシステムでお客様の属性情報と行動履歴を管理し、見込み顧客のナーチャリングからロイヤルカスタマーの育成までを一気通貫して行う API連携配信反応を取得反応をDBへ蓄積 LINEのCRM化 WEB行動履歴の活用 1toNでの配信 Botアンケートお客様のセグメントを分類 LINEでコミュニケーション属性情報と行動履歴を取得適切な方法でコミュニケーションお客様の反応を蓄積してさらに最適化 40代男性東京会社員 30代女性大阪主婦就活中 10代男性神奈川バイト • カゴ落ち後の後追い配信キャンプ好きブランド好き • クーポン特典 • キャンペーン情報 • Botアンケートによる詳細なヒアリングお客様属性に合わせてコミュニケーションを最適化し反応率拡大

Slide 8

Slide 8 text

© 2022 Micoworks inc. 8 © 2023 Micoworks inc. 8 MicoCloudの主な特徴配信キャパシティ友だち同時流入数(webhook) 大規模な配信や友達登録にも耐えうる堅牢なシステムになっております。 300万配信 30分あたりの一斉配信数 ※11月の地点では同時に6社まで可能想定 ※上記は負荷試験前のため理論値 10万件時間あたりの友達流入許容数特に、ピークタイムは、秒間100件を想定し、スタンプ大規模流入も実施可能に WEBタグサイト上に訪問したユーザーの行動を可視化し、情報に合わせた配信を行うことが可能 WEB上の行動可視化

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

© 2022 Micoworks inc. 11 © 2023 Micoworks inc. 11 なぜAuroraだけにしないか ● データベースのパフォーマンスの最適化は難しい問題 ○ 3000万ユーザー数想定として、データ設計の基準で考える ○ 属性情報と行動履歴を取得する ■ 大量な属性データや行動イベントデータが流入 ■ お客様の反応を蓄積することでさらに膨大のデータ流入を見込む ■ 全ての属性やイベントカラムにIndexを貼れない ○ お客様のセグメントを分類を実現するために多くの属性やイベントデータを用いる ■ カスタマーテーブルでは260カラムも存在している ■ 非正規化を行うことで多くのJOINを削減した結果

Slide 12

Slide 12 text

Slide 13

Slide 13 text

© 2022 Micoworks inc. 13 © 2023 Micoworks inc. 13 ユースーケースにて使い分け属性情報と行動履歴を取得・属性データ・イベントデータ・配信の反応データ Redshiftが得意とするOLAPのデータ分析能力から、任意の属性・任意のイベントを任意の組み合わせで素早く検索できることを期待 DynamoDBの高性能・高可用性から、大量データが一気に流入されたり、大量配信の結果データを更新したり、などの高負荷に耐えられるお客様のセグメントを分類・網羅的な属性設計・網羅的なイベント設計

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

© 2022 Micoworks inc. 16 © 2023 Micoworks inc. 16 システムの複雑度が高い DynamoDBとAuroraからRedshiftへの同期 DynamoDBはスキーマレスのため、同期時にカラムごとの処理が必要カラムの追加・変更・削除は、各DBで揃えなければならない DB操作の抽象化レイヤが共通化しにくい RedshiftはPostgreSqlの完全互換ではないので ORMを使えず、実装に生 SQLが使われていた、潜在的なSQLInjectionを内部検査で見つけた

Slide 17

Slide 17 text

© 2022 Micoworks inc. 17 © 2023 Micoworks inc. 17 Redshiftのパフォーマンスを引き出せない QueryCacheやAutoAnalyzeを活用できてないセグメントは毎回動的に検索条件を設定対象データが時間とともに増加していく Redshiftのunique制約はクエリプランに利用されるが、データ挿入時の重複レコードは除外されないアプリ側で重複のレコードを除外する一時テーブルを作成して利用しなければならない Redshiftは元々同時実行に向いてない Concurrency Scalingやserverless を検討したが、コストが高く付いてしまいそう

Slide 18

Slide 18 text

© 2022 Micoworks inc. 18 © 2023 Micoworks inc. 18 Redshiftのパフォーマンスを引き出せない我々がRedshiftのことを理解不足してたのもありますが、弊社サービスのユースケースとRedshiftの得意とする部分はあまりマッチしていなかったその結果、Redshiftのパフォーマンスを引き出せなかった列指向のデータベースであるため、従来の行指向の検索が有利の場合は恩恵を受けられないよく利用するカラムにIndexを追加してパフォーマンスを上げることは難しい

Slide 19

Slide 19 text

© 2022 Micoworks inc. 19 © 2023 Micoworks inc. 19 運用は手間かかる監視や通知をそれぞれ設定する。大量データ流入時のモニタリングも三つ同時監視する。モニタリング問題発生時どこのデータが問題になっているのか、調査が難しい。三つのDBを使い分けるのに開発者の負荷にもなっている。開発と調査バックアップとリストアを別々で行うため、整合性を取るには難しいバックアップとリストア

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

© 2022 Micoworks inc. 23 © 2023 Micoworks inc. 23 従来のノウハウは通用 Unique制約やIndexの活用は今まで通りできる抽象レイヤの共通化ができた抽象レイヤによる生SQLの利用をなくし、 SQLIの予防ができるシステムの複雑度の削減 DynomoDBとRedshiftの役割をTiDBに一元化統合無駄な処理の削減 DB間の同期処理自体をなくすことでメンテナンスが大変なカラムの変換処理を無くした MySql互換性が担保される

Slide 24

Slide 24 text

© 2022 Micoworks inc. 24 © 2023 Micoworks inc. 24 TiDBなら更新と検索を両立できる分散型HTAP 行ストアとカラムストアを組み合わせることによって、両方の長所を備える TiKVとTiFlashで我々が求めるパフォーマンスを実現できる属性情報と行動履歴を取得分散型アーキテクチャによる高スケーラビリティで大量データの挿入・更新などの高負荷を耐えてくれるお客様のセグメントを分類ほどんとの場合、TiFlashは期待のパフォーマンスを発揮してくれる、よく利用ケースをIndexなどでさらなる高速化もできる。

Slide 25

Slide 25 text

© 2022 Micoworks inc. 25 © 2023 Micoworks inc. 25 3000万ユーザーを用いてベンチマークを行った結果性能の向上：TiKVとTiFlashのベンチマーククエリタイプ TiFlash実行時間 TiKV実行時間自動選択実行時間 count 136ms 2.51s 129ms indexなし検索(full table scan) 991ms 56.1s 984ms カラム指定indexなし検索 187ms 6.93s 193ms index利用検索 3.28s 76ms 82.1ms カラム指定index利用検索 153ms 43.2ms 43.3ms

Slide 26

Slide 26 text

© 2022 Micoworks inc. 26 © 2023 Micoworks inc. 26 運用性向上：TiDBCloudの導入 TiDBのダッシュボードでCPUやメモリー以外にも、slow queryや key visualizerをリアルタイムに見れるのは非常に良い key visualizerでは、TiDBの使用状況のヒートマップが見れますので、集中したアクセスがあるかどかは非常に分かりやすいので重宝しているモニタリング TiDBにはWebGUIの自動バックアップ設定ができるので楽データが統合されるので整合性も自然と取れるバックアップとリストア

Slide 27

Slide 27 text

© 2022 Micoworks inc. 27 © 2023 Micoworks inc. 27 Optimizierが適切な実行プランを選べない時もあるメモリーを大量に消費したり、速度が遅くなったり複雑のQueryやテーブル定義などで、DBエンジンが実行プランではTiKVとTiFlashの自動選択が不適切のこともあったが、正しい実行プランの選択をDBエンジンに教えてあげればメモリー利用と速度の問題を解消できたこと。 SQL Hint / MPPモードの手動適用 / Queryの最適化 TiDBの導入後で分かったことある規模のユーザー流入イベントが行った際に、特定の処理が重くなった Key VisualizerでHot Spotの発生を素早く発見し、特定のテーブルに集中したアクセスが急増したことを検知でき、障害発生後数時間で対応することができた。

Slide 28

Slide 28 text

Slide 29

Slide 29 text

© 2022 Micoworks inc. 29 © 2023 Micoworks inc. 29 ● 我々のサービスでは高度の操作性とパフォーマンスの両立を求める ○ 属性情報と行動履歴の取得による大量挿入と更新 ○ お客様のセグメントを分類による検索の素早くレスポンス性能 ● そのためにNoSQLとOLAPを活用したがうまくいかず ○ システムの複雑性が高まった ○ パフォーマンスも思うほど引き出せなかった ● NewSQLのTiDBを導入することで我々が求めるパフォーマンスへ ○ システムのシンプルさを維持しながらも ○ HTAPで我々が求めたパフォーマンスも達成なぜ我々がTiDBに移行したのか