TiDB Cloud における大規模 PoC の話 - db tech showcase 2023 Tokyo

イベント開催日：2023年12月07日

現在運用している巨大な MySQL サーバの移行先の候補の一つとして TiDB があります。TiDB Cloud がこれらの MySQL の移行先として可能性があるかどうかについて、特に性能面で大規模 PoC を実施しました。今回はその PoC についての内容や方法、またその結果についてお話します。

Transcript

1. 1 TiDB Cloud における大規模 PoC の話 本田 恭
2. 2 2021 年メルカリ入社 DBRE として古いシステムや巨大な MySQL を運用中 https://engineering.mercari.com/blog/entry/20220218-3c7faca4cc/ 本田 恭
3. 3 PoC の背景 Agenda 準備 & 計画 実行 まとめ 02 03 04 01
4. 4 PoC の背景 Agenda 準備 & 計画 実行 まとめ 02 03 04 01
5. 5 　　 あらゆる価値を循環させ、あらゆる人の可能性を広げる “Circulate all forms of value to unleash the potential in all people” 5 グループミッション
6. 6 　　 6 利用実績推移（Marketplace） ＜GMV1 /MAU2 の推移＞ 単位：億円 単位：万人 2 1 1. FY2022.6からCtoCとBtoCを合算し遡及開示 2. 1か月に1回以上アプリ又はWEBサイトをブラウジングした登録ユーザの四半期平均の数 YoY +11% YoY +15% 億円 万人
7. 7 巨大な MySQL 群の運用課題 PoC の背景
8. 8 Size Servers On-premise 40+ TB 5x 5x 50+ PoC の背景
9. 9 Development Scalability Elasticity PoC の背景
10. 10 • DDL の適応に時間がかかる ◦ データサイズが多い • 垂直分割が microservice やアプリケーションのロジックと結びついていない Development PoC の背景
11. 11 • Writer は ScaleUp しかできない • サイズが大きすぎてセットアップに時間かかる ◦ 24h 以上 ◦ 急なトラフィックに備えられない Scalability PoC の背景
12. 12 • DC なので柔軟じゃない • 調達に時間かかる Elasticity PoC の背景
13. 13 PoC の背景
14. 14 PoC の背景 • Scale の速さと柔軟性 ◦ Cost Optimization ◦ Writer も Scale 可能 • サービスの成長促進 ◦ MySQL との互換性が高い ◦ Capacity に上限がない • DC 固有の問題の解決 ◦ 運用工数 ◦ セキュリティ TiDB Cloud の選定
15. 15 TiDB Cloud が Mercari の workload に耐えうるか PoC の背景
16. 16 PoC の背景 Agenda 準備 & 計画 実行 まとめ 02 03 04 01
17. 17 準備 & 計画 性能要件 Throughput Latency Replication 機能要件 Failover Backup/Recovery DR CDC …
18. 18 準備 & 計画 性能要件 Throughput Latency Replication 機能要件 Failover Backup/Recovery DR CDC …
19. 19 • 機能を満たしても結局 Mercari のトラフィックに耐えられるか が重要 • 性能要件を満たさなければ移行の実現性はほとんどない なぜ性能要件をやるか 準備 & 計画
20. 20 準備 & 計画 TiDB Cloud が性能面において Mercari の workload に耐えうるか
21. 21 準備 & 計画 Latency Throughput Replication • 処理性能 • QPS • Query の Latency • サービス, お客さまに直接影 響する • データ同期が完了するまで にかかる時間 • 切り替えにかかる時間 , 再挑 戦可能数などを図る
22. 22 準備 & 計画 Latency Throughput • 本番データを使って実際の Query を流す • 現行, 未来(N 年後)の QPS をさばけるかを評価 • 本番データを使って実際の Query を流す • Throughput では測れな い best/middle な Latency を計測し評価 • 本番 DB と replication し てデータの移行/整合性確認 を取るまでの時間 • 本番移行にかかる時間を評 価 Replication
23. 23 準備 & 計画 Latency Throughput • 本番データを使って実際の Query を流す • 現行, 未来(N 年後)の QPS をさばけるかを評価 • 本番データを使って実際の Query を流す • Throughput では測れな い best/middle な Latency を計測し評価 • 本番 DB と replication し てデータの移行/整合性確認 を取るまでの時間 • 本番移行にかかる時間を評 価 Replication
24. 24 • Mercari は microservice 化が進められたため単純に Web/DB/client を用意するのは困難 • Query Replay tool は現行負荷はかけられるが未来の負荷をかけるのは困難 • すべての Query を適切な割合で再現するのは難しい 本番データ/Query の再現 準備 & 計画
25. 25 • Mercari は microservice 化が進められたため単純に Web/DB/client を用意するのは困難 • Query Replay tool は現行負荷はかけられるが未来の負荷をかけるのは困難 • すべての Query を適切な割合で再現するのは難しい 本番データ/Query の再現 主要な microservice の Query を使って sysbench のシナリオを作成 準備 & 計画
26. 26 • 低 Latency で実行回数の多い Query ◦ アイテムの取得 ◦ ユーザー情報の取得 • 高 Latency で実行回数の少ない Query ◦ いいねの削除 • ピーク時の QPS で選んだ Query の割合を算出し • 足りない分は sysbench の組み込みシナリオでカバー ◦ すべての Query を網羅することは不可能 • 未来の QPS は GMV から N 年後の QPS を算出 ◦ GMV: 130%, QPS(現在): 1000, 5 年後とすると ▪ 1000 * 1.3^5 = 3712.93[QPS] 目標値の設定[Throughput] 準備 & 計画
27. 27 • Query のシナリオは Throughput のものを利用 • Latency の目標値は Query 部分のみ値を参考に目標値を設定 ◦ 各 microservice の SLO ◦ API の Trace 目標値の設定[Latency] 準備 & 計画
28. 28 準備 & 計画 Latency Throughput • 本番データを使って実際の Query を流す • 現行, 未来(N 年後)の QPS をさばけるかを評価 • 本番データを使って実際の Query を流す • Throughput では測れな い best/middle な Latency を計測し評価 • 本番 DB と replication し てデータの移行/整合性確認 を取るまでの時間 • 本番移行にかかる時間を評 価 Replication
29. 29 • 実際に本番の DB の replica 一台と同期 • 本番の切り替えを想定して切り戻し用 DB(fallback)も用意する • 同期の完了, 整合性の確認が取れるまでの時間が想定内かどうか • 整合性は下記を確認 a. TiDB へと import されたデータ b. import 後に更新されたデータ c. TiCDC 経由で更新されたデータ • 整合性確認は sync-diff-inspector を利用 a. https://docs.pingcap.com/tidb/stable/sync-diff-inspector-overview 目標値の設定[Replication] 準備 & 計画
30. 30 Primary Relay Fallback TiCDC 整合性確認 準備 & 計画
31. 31 準備 & 計画 Latency Throughput • 本番データを使って実際の Query を流す • 現行, 未来(N 年後)の QPS をさばけるかを評価 • 本番データを使って実際の Query を流す • Throughput では測れな い best/middle な Latency を計測し評価 • 本番 DB と replication し てデータの移行/整合性確認 を取るまでの時間 • 本番移行にかかる時間を評 価 Replication
32. 32 準備 & 計画 Latency Throughput • 実際の Query で sysbench シナリオを作成 • GMV から算出 • 実際の Query で sysbench シナリオを作成 • sysbench シナリオを低負 荷で流す • 本番 DB と replication す る • 同期完了後に整合性確認 Replication
33. 33 準備 & 計画 Latency Throughput • 実際の Query で sysbench シナリオを作成 • GMV から算出 • 実際の Query で sysbench シナリオを作成 • sysbench シナリオを低負 荷で流す • 本番 DB と replication す る • 同期完了後に整合性確認 Replication 1,500,000 QPS 7 日以内に完了 目標値未満か
34. 34 PoC の背景 Agenda 準備 & 計画 実行 まとめ 02 03 04 01
35. 35 実行 • 今回の対象 DB のデータ量は 10+ TB • 一度 S3 に CSV で書き出して TiDB Cloud から import a. tiup dumpling でデータを CSV に書き出す b. S3 にアップロード c. MySQL の DDL を変換し CREATE TABLE だけ実行 ▪ AUTO_ID_CACHE/CLUSTERED などの TiDB 固有オプションを付与 ▪ github.com/pingcap/tidb/parser d. TiDB Cloud でデータのみ import • 予備用で Backup を作成 a. TiDB Cluster から Backup を作成 b. Cluster を削除 c. Recycle Bin から再度 Import Cluster 作成
36. 36 実行 • 今回の対象 DB のデータ量は 10+ TB • 一度 S3 に CSV で書き出して TiDB Cloud から import a. tiup dumpling でデータを CSV に書き出す b. S3 にアップロード c. MySQL の DDL を変換し CREATE TABLE だけ実行 ▪ AUTO_ID_CACHE/CLUSTERED などの TiDB 固有オプションを付与 ▪ github.com/pingcap/tidb/parser d. TiDB Cloud でデータのみ import • 予備用で Backup を作成 a. TiDB Cluster から Backup を作成 b. Cluster を削除 c. Recycle Bin から再度 Import Cluster 作成 40h 30h
37. 37 実行 • tidb-lightning による import が超爆速 • データサイズ ◦ MySQL: 10+ TB ◦ dumpling: 7+ TB • TiDB/TiKV のスペックと台数 ◦ TiDB: 8 vCPU/16GB/1 ◦ TiKV: 8 vCPU/32GB/10+ ◦ データサイズを満たす最低構成 • 約 24h で import が完了 ◦ TiKV の CPU Util は約 30% 程度(もっと性能が出せる？ ) ▪ 低リソース/高 throughput 爆速 import
38. 38 準備 & 計画 Latency Throughput • 実際の Query で sysbench シナリオを作成 • GMV から算出 • 実際の Query で sysbench シナリオを作成 • sysbench シナリオを低負 荷で流す • 本番 DB と replication す る • 同期完了後に整合性確認 Replication 1,500,000 QPS 7 日以内に完了 目標値未満か
39. 39 実行 • 実際の Query の割合を維持するようにして threads を調整 ◦ アイテムの取得: 50 threads ◦ コメントの削除: 1 threads • 1 sysbench サーバ辺りで Query の割合を決めて sysbench サーバを ScaleOut する • TiDB 側のリソースが足りない場合は ScaleOut/ScaleUp する • 想定通りの負荷となるまで Scale させる Throughput
40. 40 実行 1,500,000 QPS
41. 41 実行 1,500,000 QPS
42. 42 実行 Throughput 達成の裏側(CLUSTERED vs NONCLUSTERED) • CLUSTERED ◦ Primary Key(key)- row data(value) ◦ +Throughput / -Hotspot の可能性 ◦ AutoIncrement 発番が 30000 QPS 未満 • NONCLUSTERED ◦ Primary Key(key)- _tidb_rowid / _tidb_rowid - row data(value) ◦ -Throughput / +Hotspot の可能性 ◦ AutoIncrement 発番が 30000 QPS 以上
43. 43 実行 Throughput 達成の裏側(CLUSTERED vs NONCLUSTERED) • CLUSTERED ◦ Primary Key(key)- row data(value) ◦ +Throughput / -Hotspot の可能性 ◦ AutoIncrement 発番が 30000 QPS 未満 • NONCLUSTERED ◦ Primary Key(key)- _tidb_rowid / _tidb_rowid - row data(value) ◦ -Throughput / +Hotspot の可能性 ◦ AutoIncrement 発番が 30000 QPS 以上
44. 44 実行 Throughput 達成の裏側(Follower Read) • 想像: TiKV の Follower node でも Query を実行して Throughput 向上 • 実際: ReadIndex を実行し最新のデータの場合に Follwer がデータを返す ◦ 最新じゃなかった場合にはデータの更新を待つ ◦ Hotspot などで Leader が高負荷かつ十分データ更新が少ないケースで有用 ◦ tidb_replica_read で Follower の選出方法を指定可能 ▪ ランダム, 負荷状況, 同 Zone など • Hotspot はほとんどなく負荷が偏っていないため採用せず
45. 45 実行 Throughput 達成の裏側(Stale Read) • Stale(一定時間前な)データも返せるようにする , そのためすべての Follwer は Read Query を処 理できるようになる ◦ サービス的に古いデータを返してもいいかどうかは要確認 • 下記が問題となっているときに性能向上が期待される ◦ Three copy の Latency ◦ Follower から Leader への ReadIndex の Latency • Follower Read と同様に偏りがなく Three copy の Latency が問題ではないため不採用
46. 46 実行 Throughput 達成の裏側(Plan Cache) • PREPARE と EXECUTE が指定された Query の実行計画をキャッシュする • キャッシュは TiDB Node 単位で保持される ◦ 互いに共有はできない • キャッシュされるには条件が多々ある ◦ SELECT, UPDATE, INSERT, DELETE, UNION, INTERSECT, EXCEPT 以外を含まない ◦ 非相関 SubQuery を含まない ▪ SELECT * FROM t1 WHERE t1.a > (SELECT a FROM t2 WHERE t2.b < 1) ◦ Partition/Tmp table を利用しない ◦ LIMIT 句が 10,000 より大きくない ◦ … • TiDB 7.1 系では PointGet 系の Query には有効化されていなかったが Patch を作ってもらった
47. 47 実行 Throughput 達成の裏側(Copro Cache) • Push-down(TiKV 側で処理をする)された結果を TiDB Node 単位でキャッシュする ◦ TiDB ではなく TiKV 側で処理をなるべくして , TiDB では結果だけを返すようにしたい • Push-down request( Query の内容)が完全に一致する場合のみキャッシュされる • キャッシュは Region 単位で更新された場合キャッシュは Invalid となる ◦ 更新の多い Region に対してはあまり有効に働かない • 特に Mercari では PointGet(BatchPointGet)な Query が多数だが, CoproCache はこれらに は適応されない • 今回の PoC では有効に働かせることはできなかった
48. 48 実行 Throughput 達成の裏側(tidb_enable_tso_follower_proxy) • Transaction 時の TSO(Time Stamp Oracle) Request を PD Leader ではなく PD Follower にも送るパラメータ • PD Leader の負荷を軽減することで全体の Throughput 向上を見込んだ • 高負荷時でも PD Leader は限界ではなかったため , 有効化することによる overhead が影響し効 果を得られなかった ◦ Off: TiDB => PD(L) で TSO 発行 ◦ On: TiDB => PD(L) で TSO 発行, PD(F) => PD(L) で TSO 発行
49. 49 実行 Throughput 達成の裏側(tidb_slow_log_threshold) • long-query-time と同様で slow-log に出力するためのしきい値 • Query の量が多く slow log も多いため, 出力に関する負荷を削減しようとした • TiDB Cloud Console の Diagnosis で結果が表示されるのは早くなった • しかし TiDB 自体の Throughput に効果はなかった
50. 50 実行 Throughput 達成の裏側(max-batch-wait-time) • TiDB から TiKV にリクエストする際に指定した時間待つことでリクエストをまとめて送る • 多少の Latency を犠牲にして TiKV へのリクエスト数(通信回数)を減らして全体の Throughput 向 上を図る • 軽いが量が多い Query によるリクエストが支配的なためこれを削減しようとした • 後述の grpc-connection-count と組み合わせる事によって更に効果が得られた
51. 51 実行 Throughput 達成の裏側(grpc-connection-count) • TiDB と TiKV 間の gRPC 接続数の上限 • 1,500,000 QPS では TiDB Node の台数が多く TiKV へのリクエストが分散しすぎたため , max-batch-wait-time で十分な効果が得られなかった • 接続数を意図的に減らすことで BatchRequest の効果をより得ようとした • 台数が十分多いときに max-batch-wait-time と組み合わせることで Throughput が向上した
52. 52 実行 Throughput 達成の裏側(grpc-concurrency) • gRPC worker のスレッド数 • Mercari の workload は Read が圧倒的に多い • 多数の Read Query を並列でさばけるよう並列数を上げて全体の Throughput 向上を見込んだ • TiKV の CPU Usage は上がったが全体としての Throughput は向上した
53. 53 実行 Throughput 達成の裏側(raftstore.store-io-pool-size) • TiKV の RocksDB へ書き込む thread 数 • = 0 (default)の場合は Raftstore thread がすぐにディスク(RocksDB)にログを書き出す • > 0 の場合は Raftstore thread が StoreWrite thread に一時的に書き出して一定数溜まったあ とに RocksDB に書き出す • 更新系の Commit log duration が長いためこれを減らすためのアプローチ • Latency の軽減には寄与した ◦ Read Query の比率が高いため全体の Throughput 向上には寄与しなかった
54. 54 実行 Parameter 採用可否 効果 CLUSTERED INDEX ✅ 😊 Follower Read ❌ Stale Read ❌ Plan Cache ✅ 😊 tidb_enable_tso_follower_read ❌ tidb_log_threshold ❌ max-batch-wait-time/grpc-connection-count ✅ 😐 grpc-concurrency ✅ 😐 raftstore.store-io-pool-size ✅ 😐
55. 55 TiDB TiKV PD 80~ 80~ 80+ 16 vCPU/32 GB 16 vCPU/64 GB 100+ 100+ 100+ 16 vCPU/32 GB 実行 100+ 100+ 3
56. 56 実行 QPS…
57. 57 実行 🎉 4,500,000 🎉
58. 58 準備 & 計画 Latency Throughput • 実際の Query で sysbench シナリオを作成 • GMV から算出 • 実際の Query で sysbench シナリオを作成 • sysbench シナリオを低負 荷で流す • 本番 DB と replication す る • 同期完了後に整合性確認 Replication 1,500,000 QPS 7 日以内に完了 目標値未満か
59. 59 実行 Latency • Throughput 達成時のパラメータを流用し計測 • TiDB にとってベストな Latency と通常時の Latency を計測する ◦ ベスト: sysbench の --threads=1 ◦ 通常時: CPU Util 30 ~ 50% 程度を目指す • 一般的に PD/TiKV へのリクエストや Zone をまたぐ可能性があるため MySQL より遅いはず • 今回の検証環境では TiDB Cloud との Network Latency は MySQL よりも大きかった ◦ MySQL: 0.x ms ◦ TiDB: 3 ~ 4 ms • この Latency が Mercari にとって許容可能かを議論する • PoC では SLO をベースに目標値を再設定
60. 60 実行
61. 61 Best Mid High x10 x1.5 x1.5 実行
62. 62 50% slowdown 実行
63. 63 50% slowdown 実行
64. 64 準備 & 計画 Latency Throughput • 実際の Query で sysbench シナリオを作成 • GMV から算出 • 実際の Query で sysbench シナリオを作成 • sysbench シナリオを低負 荷で流す • 本番 DB と replication す る • 同期完了後に整合性確認 Replication 1,500,000 QPS 7 日以内に完了 目標値未満か
65. 65 Primary Relay Fallback TiCDC 整合性確認 準備 & 計画
66. 66 実行 Primary Relay Fallback CREATE TABLE DDL 実行
67. 67 実行 Primary Relay Fallback 初期同期 export import
68. 68 実行 Primary Relay Fallback 更新同期 Incremental
69. 69 実行 Primary Relay Fallback STOP REPLI 静止点作成
70. 70 実行 Primary Relay Fallback TiCDC Set start-ts STOP REPLI TiCDC 設定
71. 71 実行 Primary Relay Fallback TiCDC START REPLI 同期再開
72. 72 実行 Primary Relay Fallback TiCDC STOP REPLI (再)静止点作成
73. 73 実行 Primary Relay Fallback TiCDC sync-diff-inspector STOP REPLI sync-diff-inspector
74. 74 実行 Primary Relay Fallback TiCDC START REPLI 同期再開
75. 75 実行 Task 内容 時間 DDL 実行 予め TiDB 用の DDL 実行にかかる時間 0 初期同期 Relay から export したデータを TiDB へと import にかかる時間 35h 更新差分同期 export/import 中の差分を同期し追いつくまでにかかる時間 45h 静止点作成 TiCDC 起動前に Relay/Fallback で断面を揃える時間 0 TiCDC 設定 TiCDC を起動 0 同期再開 Fallback が TiDB(TiCDC) 経由で同期されて追いつくまでの時間 1h (再)静止点作成 差分チェックのために静止点を作成 (Fallback と TiDB のが同じ断面となる )する時間 0 sync-diff-inspector 差分チェックにかかる時間 6h 同期再開 差分チェックで止まっていた分 Fallback が Primary に追いつくまでの時間 10h
76. 76 < 100h 実行
77. 77 < 100h 実行
78. 78 準備 & 計画 Latency Throughput • 実際の Query で sysbench シナリオを作成 • GMV から算出 • 実際の Query で sysbench シナリオを作成 • sysbench シナリオを低負 荷で流す • 本番 DB と replication す る • 同期完了後に整合性確認 Replication 1,500,000 QPS 7 日以内に完了 目標値未満か
79. 79 準備 & 計画 Latency Throughput • 実際の Query で sysbench シナリオを作成 • GMV から算出 • 実際の Query で sysbench シナリオを作成 • sysbench シナリオを低負 荷で流す • 本番 DB と replication す る • 同期完了後に整合性確認 Replication 1,500,000 QPS 7 日以内に完了 目標値未満か +50% 4,500,000 < 100h
80. 80 準備 & 計画 Latency Throughput • 実際の Query で sysbench シナリオを作成 • GMV から算出 • 実際の Query で sysbench シナリオを作成 • sysbench シナリオを低負 荷で流す • 本番 DB と replication す る • 同期完了後に整合性確認 Replication 1,500,000 QPS 7 日以内に完了 目標値未満か +50% 4,500,000 < 100h
81. 81 PoC の背景 Agenda 準備 & 計画 実行 まとめ 02 03 04 01
82. 82 まとめ
83. 83 まとめ TiDB Cloud が Mercari の workload に耐えうるか
84. 84 まとめ 性能要件 Throughput Latency Replication 機能要件 Failover Backup/Recovery DR CDC …
85. 85 まとめ Latency Throughput • 実際の Query で sysbench シナリオを作成 • GMV から算出 • 実際の Query で sysbench シナリオを作成 • sysbench シナリオを低負 荷で流す • 本番 DB と replication す る • 同期完了後に整合性確認 Replication
86. 86 まとめ Latency Throughput • 本番データを使って実際の Query を流す • 現行, 未来(N 年後)の QPS をさばけるかを評価 • 本番データを使って実際の Query を流す • Throughput では測れな い best/middle な Latency を計測し評価 • 本番 DB と replication し てデータの移行/整合性確認 を取るまでの時間 • 本番移行にかかる時間を評 価 Replication
87. 87 まとめ Latency Throughput • 実際の Query で sysbench シナリオを作成 • GMV から算出 • 実際の Query で sysbench シナリオを作成 • sysbench シナリオを低負 荷で流す • 本番 DB と replication す る • 同期完了後に整合性確認 Replication 1,500,000 QPS 7 日以内に完了 目標値未満か
88. 88 準備 & 計画 Latency Throughput • 実際の Query で sysbench シナリオを作成 • GMV から算出 • 実際の Query で sysbench シナリオを作成 • sysbench シナリオを低負 荷で流す • 本番 DB と replication す る • 同期完了後に整合性確認 Replication 1,500,000 QPS 7 日以内に完了 目標値未満か +50% 4,500,000 < 100h
89. 89 準備 & 計画 Latency Throughput • 実際の Query で sysbench シナリオを作成 • GMV から算出 • 実際の Query で sysbench シナリオを作成 • sysbench シナリオを低負 荷で流す • 本番 DB と replication す る • 同期完了後に整合性確認 Replication 1,500,000 QPS 7 日以内に完了 目標値未満か +50% 4,500,000 < 100h
90. 90 TiDB Cloud を使ってみて • TiDB の Scalability の限界は見えなかった ◦ ScaleOut すれば(お金はかかるが) Throughput が得られる • tidb-lightning の import は想像以上に速い ◦ Cluster 準備が 3, 4 日で完了 • TiDB Cloud を本番で使うには... ◦ いくつか Bug に遭遇した ▪ https://github.com/pingcap/tidb/issues/46093 ◦ DBRE にやさしく ▪ TiKV/PD は全く触れない ▪ PD は Metrics も見えない • Latency については課題が残る まとめ
91. 91 Thanks to
92. 92 PoC を完了して • 現地開発チームを巻き込んだサポート • 迅速な対応/回答 ◦ Patch や Bug 修正 ◦ 数時間以内の返答 • それぞれのフェーズでの効果測定 ◦ TiDB への理解が深まる • QPS 達成後により効率的にリソースを使うための検証 Thanks to PingCAP
93. 93 We are hiring ! Traffic Large data Business impact ! https://careers.mercari.com
94. 94 We are hiring ! https://apply.workable.com/mercari/j/CBEAB3A15B/
95. 95 Thank you for your attention !!