【わずか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

Transcript

1. © 2022 Micoworks inc. 1 © 2023 Micoworks inc. 1 【わずか1ヶ月でリプレイスを実現！】 アジアNo.1を目指すマーケティングSaaSが NoSQLからNewSQLに移行した理由 2023/07/07 Micoworks 株式会社　 プロダクト統括本部 SREチーム 陳 瀚
2. © 2022 Micoworks inc. 2 © 2023 Micoworks inc. 2 • 自己紹介と会社紹介 • 私たちのサービスを紹介 • 旧アーキテクチャの概要紹介 • 旧アーキテクチャの課題 • TiDBの導入とサービスの改善 • 改善効果・知見のまとめ 今日のアジェンダ
3. © 2022 Micoworks inc. 3 © 2023 Micoworks inc. 3 自己紹介と会社紹介
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エンジニア
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
6. © 2022 Micoworks inc. 6 © 2023 Micoworks inc. 6 提供サービス 顧客を「見える化」し、見込み顧客を最大化する マーケティングプラットフォーム エンドユーザー 870万人 No.1 導入後の効果が 期待できる LINE顧客管理ツール 頭痛
 のどの痛み
 風邪

7. © 2022 Micoworks inc. 7 © 2023 Micoworks inc. 7 MicoCloudのサービス システムでお客様の属性情報と行動履歴を管理し、 見込み顧客のナーチャリングからロイヤルカスタマーの育成までを一気通貫して行う API連携 配信 反応を取得 反応をDBへ蓄積 LINEのCRM化 WEB行動履歴の活用 1toNでの配信 Botアンケート お客様の セグメントを分類 LINEで コミュニケーション 属性情報と 行動履歴を取得 適切な方法で コミュニケーション お客様の反応を 蓄積してさらに最適化 40代 男性 東京 会社員 30代 女性 大阪 主婦 就活中 10代 男性 神奈川 バイト • カゴ落ち後の後追い 配信 キャンプ好き ブランド好き • クーポン特典 • キャンペーン情報 • Botアンケートによる 詳細なヒアリング お客様属性に合わせてコミュニケーションを 最適化し反応率拡大
8. © 2022 Micoworks inc. 8 © 2023 Micoworks inc. 8 MicoCloudの主な特徴 配信キャパシティ 友だち同時流入数(webhook) 大規模な配信や友達登録にも耐えうる堅牢なシステムになっております。 300万 配信 30分あたりの一斉配信数 ※11月の地点では同時に6社まで可能想定 ※上記は負荷試験前のため理論値 10万件 時間あたりの友達流入許容数 特に、ピークタイムは、秒間100件を想定し、 スタンプ大規模流入も実施可能に WEBタグ サイト上に訪問したユーザーの 行動を可視化し、情報に合わ せた配信を行うことが可能 WEB上の行動可視化
9. © 2022 Micoworks inc. 9 © 2023 Micoworks inc. 9 旧アーキテクチャの紹介
10. © 2022 Micoworks inc. 10 © 2023 Micoworks inc. 10 旧アーキテクチャのDB構成 適切な方法でコミュニケーション 配信やアンケートなどのマスタデータ 属性情報と行動履歴を取得 また配信結果など大量データ の流入・更新 お客様のセグメントを分類 任意の属性やイベントを検索
11. © 2022 Micoworks inc. 11 © 2023 Micoworks inc. 11 なぜAuroraだけにしないか • データベースのパフォーマンスの最適化は難しい問題 ◦ 3000万ユーザー数想定として、データ設計の基準で考える ◦ 属性情報と行動履歴を取得する ▪ 大量な属性データや行動イベントデータが流入 ▪ お客様の反応を蓄積することでさらに膨大のデータ流入を見込む ▪ 全ての属性やイベントカラムにIndexを貼れない ◦ お客様のセグメントを分類を実現するために多くの属性やイベントデータを用いる ▪ カスタマーテーブルでは260カラムも存在している ▪ 非正規化を行うことで多くのJOINを削減した結果
12. © 2022 Micoworks inc. 12 © 2023 Micoworks inc. 12 DynamoDB スケーラビリティ パフォーマンス スキーマレス 主に大規模なデータストレージと高速なアクセ スが必要なアプリケーションに適しています NoSQLとOLAPを使ってみた Redshift 列指向 OLAP スキーマフル 主にビジネスインテリジェンス（BI）と大規模な データ分析に適しています
13. © 2022 Micoworks inc. 13 © 2023 Micoworks inc. 13 ユースーケースにて使い分け 属性情報と行動履歴を取得 ・属性データ ・イベントデータ ・配信の反応データ Redshiftが得意とするOLAPのデータ分析能 力から、任意の属性・任意のイベントを任意 の組み合わせで素早く検索できることを期待 DynamoDBの高性能・高可用性から、大量 データが一気に流入されたり、大量配信の結 果データを更新したり、などの高負荷に耐え られる お客様のセグメントを分類 ・網羅的な属性設計 ・網羅的なイベント設計
14. © 2022 Micoworks inc. 14 © 2023 Micoworks inc. 14 旧アーキテクチャの課題
15. © 2022 Micoworks inc. 15 © 2023 Micoworks inc. 15 旧アーキテクチャの課題 システムの複 雑度が高い 運用が手間を かかる Redshiftのパ フォーマンスを 引き出せない
16. © 2022 Micoworks inc. 16 © 2023 Micoworks inc. 16 システムの複雑度が高い DynamoDBとAuroraからRedshiftへの同期 DynamoDBはスキーマ レスのため、同期時にカラ ムごとの処理が必要 カラムの追加・変更・削除 は、各DBで揃えなければ ならない DB操作の抽象化レイヤが共通化しにくい RedshiftはPostgreSqlの完全互換ではないので ORMを使えず、実装に生 SQLが使われていた、 潜在 的なSQLInjectionを内部検査で見つけた
17. © 2022 Micoworks inc. 17 © 2023 Micoworks inc. 17 Redshiftのパフォーマンスを引き出せない QueryCacheやAutoAnalyzeを活用 できてない セグメントは毎回動的に検索条件を設定 対象データが時間とともに増加していく Redshiftのunique制約はクエリプランに 利用されるが、データ挿入時の重複レコード は除外されない アプリ側で重複のレコードを除外する一時 テーブルを作成して利用しなければならな い Redshiftは元々同時実行に向いてない Concurrency Scalingやserverless を検討したが、コストが高く付いてしまい そう
18. © 2022 Micoworks inc. 18 © 2023 Micoworks inc. 18 Redshiftのパフォーマンスを引き出せない 我々がRedshiftのことを理解不足してたのもありま すが、弊社サービスのユースケースとRedshiftの得 意とする部分はあまりマッチしていなかった その結果、Redshiftのパフォーマンスを引き出せな かった 列指向のデータベースであるため、従 来の行指向の検索が有利の場合は恩 恵を受けられない よく利用するカラムにIndexを追加し てパフォーマンスを上げることは難し い
19. © 2022 Micoworks inc. 19 © 2023 Micoworks inc. 19 運用は手間かかる 監視や通知をそれぞれ設定する。 大量データ流入時のモニタリングも三つ同時監視する。 モニタリング 問題発生時どこのデータが問題になっているのか、調査が難しい。 三つのDBを使い分けるのに開発者の負荷にもなっている。 開発と調査 バックアップとリストアを別々で行うため、整合性を取るには難しい バックアップとリストア
20. © 2022 Micoworks inc. 20 © 2023 Micoworks inc. 20 TiDBの導入
21. © 2022 Micoworks inc. 21 © 2023 Micoworks inc. 21 TiDB導入において見込んだ利点 システムの複 雑度の削減 運用性向上 性能の向上
22. © 2022 Micoworks inc. 22 © 2023 Micoworks inc. 22 TiDB導入後のDB構成 適切な方法でコミュニケーション 配信やアンケートなどのマスタデータ お客様のセグメントを分類 任意の属性やイベントを検索 属性情報と行動履歴を取得 また配信結果など大量データ の流入・更新
23. © 2022 Micoworks inc. 23 © 2023 Micoworks inc. 23 従来のノウハウは通用 Unique制約やIndexの活用は 今まで通りできる 抽象レイヤの共通化ができた 抽象レイヤによる生SQLの利用をなくし、 SQLIの予防ができる システムの複雑度の削減 DynomoDBとRedshiftの役 割をTiDBに一元化統合 無駄な処理の削減 DB間の同期処理自体をなくすことでメンテナンス が大変なカラムの変換処理を無くした MySql互換性が担保される
24. © 2022 Micoworks inc. 24 © 2023 Micoworks inc. 24 TiDBなら更新と検索を両立できる 分散型HTAP 行ストアとカラムストアを組 み合わせることによって、両 方の長所を備える TiKVとTiFlashで我々が求 めるパフォーマンスを実現で きる 属性情報と行動履歴を取得 分散型アーキテクチャによる高スケーラビリティで大量データの挿入・更 新などの高負荷を耐えてくれる お客様のセグメントを分類 ほどんとの場合、TiFlashは期待のパフォーマンスを発揮してくれる、よ く利用ケースをIndexなどでさらなる高速化もできる。
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
26. © 2022 Micoworks inc. 26 © 2023 Micoworks inc. 26 運用性向上：TiDBCloudの導入 TiDBのダッシュボードでCPUやメモリー以外にも、slow queryや key visualizerをリアルタイムに見れるのは非常に良い key visualizerでは、TiDBの使用状況のヒートマップが見れますの で、集中したアクセスがあるかどかは非常に分かりやすいので重宝し ている モニタリング TiDBにはWebGUIの自動バックアップ設定ができるので楽 データが統合されるので整合性も自然と取れる バックアップとリストア
27. © 2022 Micoworks inc. 27 © 2023 Micoworks inc. 27 Optimizierが適切な実行 プランを選べない時もある メモリーを大量に消費したり、速度が 遅くなったり 複雑のQueryやテーブル定義などで、DBエンジンが実行プランではTiKVとTiFlashの自 動選択が不適切のこともあったが、正しい実行プランの選択をDBエンジンに教えてあげれ ばメモリー利用と速度の問題を解消できたこと。 SQL Hint / MPPモードの手動適用 / Queryの最適化 TiDBの導入後で分かったこと ある規模のユーザー流入イ ベントが行った際に、特定 の処理が重くなった Key VisualizerでHot Spotの発生を素早く発見し、特定のテーブルに集中したアクセス が急増したことを検知でき、障害発生後数時間で対応することができた。
28. © 2022 Micoworks inc. 28 © 2023 Micoworks inc. 28 まとめ
29. © 2022 Micoworks inc. 29 © 2023 Micoworks inc. 29 • 我々のサービスでは高度の操作性とパフォーマンスの両立を求める ◦ 属性情報と行動履歴の取得による大量挿入と更新 ◦ お客様のセグメントを分類による検索の素早くレスポンス性能 • そのためにNoSQLとOLAPを活用したがうまくいかず ◦ システムの複雑性が高まった ◦ パフォーマンスも思うほど引き出せなかった • NewSQLのTiDBを導入することで我々が求めるパフォーマンスへ ◦ システムのシンプルさを維持しながらも ◦ HTAPで我々が求めたパフォーマンスも達成 なぜ我々がTiDBに移行したのか
30. © 2022 Micoworks inc. 30 © 2023 Micoworks inc. 30 我々がTiDBに移行して得た知見 TiFlashを利用し たデータベースの 最適化考え方 Key Visualizer を通して問題点を 特定する方法と改 善のヒントを得る 方法 複雑のクエリでメ モリー最適化方法
31. © 2022 Micoworks inc. 31 © 2023 Micoworks inc. 31 質問をどうぞ
32. © 2022 Micoworks inc. 32 © 2023 Micoworks inc. 32 ご清聴ありがとうございます