Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

イベント開催日:2023年7月7日
講演者:Micoworks株式会社 プロダクト統括本部
    SREチーム Senior Specialist 陳 瀚 (Chen Han) 氏

Micoworks株式会社では、マーケティングSaaS「MicoCloud」の新バージョンリリースにおいて、データベースアーキテクチャの変更を実施しました。当初NoSQL技術を採用しましたがパフォーマンスや複雑性等の課題が発生したため、NewSQL技術である「TiDB Cloud」への移行を決定しました。本スライドでは、開発チームが直面した課題に対してなぜNewSQL技術への移行を決定し、どの様な改善効果・知見が得られたのか、エンジニアリング観点からデータベース技術の選択や移行プロセスの事例としてご紹介いたします。

アーカイブ動画:https://youtu.be/ve27Y_eqHA4

PingCAP-Japan

July 11, 2023
Tweet

More Decks by PingCAP-Japan

Other Decks in Technology

Transcript

  1. © 2022 Micoworks inc.
    1
    © 2023 Micoworks inc.
    1
    【わずか1ヶ月でリプレイスを実現!】
    アジアNo.1を目指すマーケティングSaaSが
    NoSQLからNewSQLに移行した理由
    2023/07/07
    Micoworks 株式会社 
    プロダクト統括本部 SREチーム
    陳 瀚

    View full-size slide

  2. © 2022 Micoworks inc.
    2
    © 2023 Micoworks inc.
    2
    ● 自己紹介と会社紹介
    ● 私たちのサービスを紹介
    ● 旧アーキテクチャの概要紹介
    ● 旧アーキテクチャの課題
    ● TiDBの導入とサービスの改善
    ● 改善効果・知見のまとめ
    今日のアジェンダ

    View full-size slide

  3. © 2022 Micoworks inc.
    3
    © 2023 Micoworks inc.
    3
    自己紹介と会社紹介

    View full-size slide

  4. © 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エンジニア

    View full-size slide

  5. © 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

    View full-size slide

  6. © 2022 Micoworks inc.
    6
    © 2023 Micoworks inc.
    6
    提供サービス
    顧客を「見える化」し、見込み顧客を最大化する
    マーケティングプラットフォーム
    エンドユーザー
    870万人 No.1
    導入後の効果が
    期待できる
    LINE顧客管理ツール
    頭痛

    のどの痛み

    風邪


    View full-size slide

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

    View full-size slide

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

    View full-size slide

  9. © 2022 Micoworks inc.
    9
    © 2023 Micoworks inc.
    9
    旧アーキテクチャの紹介

    View full-size slide

  10. © 2022 Micoworks inc.
    10
    © 2023 Micoworks inc.
    10
    旧アーキテクチャのDB構成
    適切な方法でコミュニケーション
    配信やアンケートなどのマスタデータ
    属性情報と行動履歴を取得
    また配信結果など大量データ
    の流入・更新
    お客様のセグメントを分類
    任意の属性やイベントを検索

    View full-size slide

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

    View full-size slide

  12. © 2022 Micoworks inc.
    12
    © 2023 Micoworks inc.
    12
    DynamoDB
    スケーラビリティ
    パフォーマンス
    スキーマレス
    主に大規模なデータストレージと高速なアクセ
    スが必要なアプリケーションに適しています
    NoSQLとOLAPを使ってみた
    Redshift
    列指向
    OLAP
    スキーマフル
    主にビジネスインテリジェンス(BI)と大規模な
    データ分析に適しています

    View full-size slide

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

    View full-size slide

  14. © 2022 Micoworks inc.
    14
    © 2023 Micoworks inc.
    14
    旧アーキテクチャの課題

    View full-size slide

  15. © 2022 Micoworks inc.
    15
    © 2023 Micoworks inc.
    15
    旧アーキテクチャの課題
    システムの複
    雑度が高い
    運用が手間を
    かかる
    Redshiftのパ
    フォーマンスを
    引き出せない

    View full-size slide

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

    View full-size slide

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

    Redshiftは元々同時実行に向いてない
    Concurrency Scalingやserverless
    を検討したが、コストが高く付いてしまい
    そう

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  20. © 2022 Micoworks inc.
    20
    © 2023 Micoworks inc.
    20
    TiDBの導入

    View full-size slide

  21. © 2022 Micoworks inc.
    21
    © 2023 Micoworks inc.
    21
    TiDB導入において見込んだ利点
    システムの複
    雑度の削減
    運用性向上
    性能の向上

    View full-size slide

  22. © 2022 Micoworks inc.
    22
    © 2023 Micoworks inc.
    22
    TiDB導入後のDB構成
    適切な方法でコミュニケーション
    配信やアンケートなどのマスタデータ
    お客様のセグメントを分類
    任意の属性やイベントを検索
    属性情報と行動履歴を取得
    また配信結果など大量データ
    の流入・更新

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  25. © 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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  28. © 2022 Micoworks inc.
    28
    © 2023 Micoworks inc.
    28
    まとめ

    View full-size slide

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

    View full-size slide

  30. © 2022 Micoworks inc.
    30
    © 2023 Micoworks inc.
    30
    我々がTiDBに移行して得た知見
    TiFlashを利用し
    たデータベースの
    最適化考え方
    Key Visualizer
    を通して問題点を
    特定する方法と改
    善のヒントを得る
    方法
    複雑のクエリでメ
    モリー最適化方法

    View full-size slide

  31. © 2022 Micoworks inc.
    31
    © 2023 Micoworks inc.
    31
    質問をどうぞ

    View full-size slide

  32. © 2022 Micoworks inc.
    32
    © 2023 Micoworks inc.
    32
    ご清聴ありがとうございます

    View full-size slide