Tweet
Tweet

Slide 1

Slide 1 text

1 TiDB Cloud における大規模 PoC の話 本田 恭

Slide 2

Slide 2 text

2 2021 年メルカリ入社 DBRE として古いシステムや巨大な MySQL を運用中 https://engineering.mercari.com/blog/entry/20220218-3c7faca4cc/ 本田 恭

Slide 3

Slide 3 text

3 PoC の背景 Agenda 準備 & 計画 実行 まとめ 02 03 04 01

Slide 4

Slide 4 text

4 PoC の背景 Agenda 準備 & 計画 実行 まとめ 02 03 04 01

Slide 5

Slide 5 text

5 　　 あらゆる価値を循環させ、あらゆる人の可能性を広げる “Circulate all forms of value to unleash the potential in all people” 5 グループミッション

Slide 6

Slide 6 text

6 　　 6 利用実績推移（Marketplace） ＜GMV1 /MAU2 の推移＞ 単位：億円 単位：万人 2 1 1. FY2022.6からCtoCとBtoCを合算し遡及開示 2. 1か月に1回以上アプリ又はWEBサイトをブラウジングした登録ユーザの四半期平均の数 YoY +11% YoY +15% 億円 万人

Slide 7

Slide 7 text

7 巨大な MySQL 群の運用課題 PoC の背景

Slide 8

Slide 8 text

8 Size Servers On-premise 40+ TB 5x 5x 50+ PoC の背景

Slide 9

Slide 9 text

9 Development Scalability Elasticity PoC の背景

Slide 10

Slide 10 text

10 ● DDL の適応に時間がかかる ○ データサイズが多い ● 垂直分割が microservice やアプリケーションのロジックと結びついていない Development PoC の背景

Slide 11

Slide 11 text

11 ● Writer は ScaleUp しかできない ● サイズが大きすぎてセットアップに時間かかる ○ 24h 以上 ○ 急なトラフィックに備えられない Scalability PoC の背景

Slide 12

Slide 12 text

12 ● DC なので柔軟じゃない ● 調達に時間かかる Elasticity PoC の背景

Slide 13

Slide 13 text

13 PoC の背景

Slide 14

Slide 14 text

14 PoC の背景 ● Scale の速さと柔軟性 ○ Cost Optimization ○ Writer も Scale 可能 ● サービスの成長促進 ○ MySQL との互換性が高い ○ Capacity に上限がない ● DC 固有の問題の解決 ○ 運用工数 ○ セキュリティ TiDB Cloud の選定

Slide 15

Slide 15 text

15 TiDB Cloud が Mercari の workload に耐えうるか PoC の背景

Slide 16

Slide 16 text

16 PoC の背景 Agenda 準備 & 計画 実行 まとめ 02 03 04 01

Slide 17

Slide 17 text

17 準備 & 計画 性能要件 Throughput Latency Replication 機能要件 Failover Backup/Recovery DR CDC …

Slide 18

Slide 18 text

18 準備 & 計画 性能要件 Throughput Latency Replication 機能要件 Failover Backup/Recovery DR CDC …

Slide 19

Slide 19 text

19 ● 機能を満たしても結局 Mercari のトラフィックに耐えられるか が重要 ● 性能要件を満たさなければ移行の実現性はほとんどない なぜ性能要件をやるか 準備 & 計画

Slide 20

Slide 20 text

20 準備 & 計画 TiDB Cloud が性能面において Mercari の workload に耐えうるか

Slide 21

Slide 21 text

21 準備 & 計画 Latency Throughput Replication ● 処理性能 ● QPS ● Query の Latency ● サービス, お客さまに直接影 響する ● データ同期が完了するまで にかかる時間 ● 切り替えにかかる時間 , 再挑 戦可能数などを図る

Slide 22

Slide 22 text

22 準備 & 計画 Latency Throughput ● 本番データを使って実際の Query を流す ● 現行, 未来(N 年後)の QPS をさばけるかを評価 ● 本番データを使って実際の Query を流す ● Throughput では測れな い best/middle な Latency を計測し評価 ● 本番 DB と replication し てデータの移行/整合性確認 を取るまでの時間 ● 本番移行にかかる時間を評 価 Replication

Slide 23

Slide 23 text

23 準備 & 計画 Latency Throughput ● 本番データを使って実際の Query を流す ● 現行, 未来(N 年後)の QPS をさばけるかを評価 ● 本番データを使って実際の Query を流す ● Throughput では測れな い best/middle な Latency を計測し評価 ● 本番 DB と replication し てデータの移行/整合性確認 を取るまでの時間 ● 本番移行にかかる時間を評 価 Replication

Slide 24

Slide 24 text

24 ● Mercari は microservice 化が進められたため単純に Web/DB/client を用意するのは困難 ● Query Replay tool は現行負荷はかけられるが未来の負荷をかけるのは困難 ● すべての Query を適切な割合で再現するのは難しい 本番データ/Query の再現 準備 & 計画

Slide 25

Slide 25 text

25 ● Mercari は microservice 化が進められたため単純に Web/DB/client を用意するのは困難 ● Query Replay tool は現行負荷はかけられるが未来の負荷をかけるのは困難 ● すべての Query を適切な割合で再現するのは難しい 本番データ/Query の再現 主要な microservice の Query を使って sysbench のシナリオを作成 準備 & 計画

Slide 26

Slide 26 text

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] 準備 & 計画

Slide 27

Slide 27 text

27 ● Query のシナリオは Throughput のものを利用 ● Latency の目標値は Query 部分のみ値を参考に目標値を設定 ○ 各 microservice の SLO ○ API の Trace 目標値の設定[Latency] 準備 & 計画

Slide 28

Slide 28 text

28 準備 & 計画 Latency Throughput ● 本番データを使って実際の Query を流す ● 現行, 未来(N 年後)の QPS をさばけるかを評価 ● 本番データを使って実際の Query を流す ● Throughput では測れな い best/middle な Latency を計測し評価 ● 本番 DB と replication し てデータの移行/整合性確認 を取るまでの時間 ● 本番移行にかかる時間を評 価 Replication

Slide 29

Slide 29 text

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] 準備 & 計画

Slide 30

Slide 30 text

30 Primary Relay Fallback TiCDC 整合性確認 準備 & 計画

Slide 31

Slide 31 text

31 準備 & 計画 Latency Throughput ● 本番データを使って実際の Query を流す ● 現行, 未来(N 年後)の QPS をさばけるかを評価 ● 本番データを使って実際の Query を流す ● Throughput では測れな い best/middle な Latency を計測し評価 ● 本番 DB と replication し てデータの移行/整合性確認 を取るまでの時間 ● 本番移行にかかる時間を評 価 Replication

Slide 32

Slide 32 text

32 準備 & 計画 Latency Throughput ● 実際の Query で sysbench シナリオを作成 ● GMV から算出 ● 実際の Query で sysbench シナリオを作成 ● sysbench シナリオを低負 荷で流す ● 本番 DB と replication す る ● 同期完了後に整合性確認 Replication

Slide 33

Slide 33 text

33 準備 & 計画 Latency Throughput ● 実際の Query で sysbench シナリオを作成 ● GMV から算出 ● 実際の Query で sysbench シナリオを作成 ● sysbench シナリオを低負 荷で流す ● 本番 DB と replication す る ● 同期完了後に整合性確認 Replication 1,500,000 QPS 7 日以内に完了 目標値未満か

Slide 34

Slide 34 text

34 PoC の背景 Agenda 準備 & 計画 実行 まとめ 02 03 04 01

Slide 35

Slide 35 text

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 作成

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

38 準備 & 計画 Latency Throughput ● 実際の Query で sysbench シナリオを作成 ● GMV から算出 ● 実際の Query で sysbench シナリオを作成 ● sysbench シナリオを低負 荷で流す ● 本番 DB と replication す る ● 同期完了後に整合性確認 Replication 1,500,000 QPS 7 日以内に完了 目標値未満か

Slide 39

Slide 39 text

39 実行 ● 実際の Query の割合を維持するようにして threads を調整 ○ アイテムの取得: 50 threads ○ コメントの削除: 1 threads ● 1 sysbench サーバ辺りで Query の割合を決めて sysbench サーバを ScaleOut する ● TiDB 側のリソースが足りない場合は ScaleOut/ScaleUp する ● 想定通りの負荷となるまで Scale させる Throughput

Slide 40

Slide 40 text

40 実行 1,500,000 QPS

Slide 41

Slide 41 text

41 実行 1,500,000 QPS

Slide 42

Slide 42 text

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 以上

Slide 43

Slide 43 text

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 以上

Slide 44

Slide 44 text

44 実行 Throughput 達成の裏側(Follower Read) ● 想像: TiKV の Follower node でも Query を実行して Throughput 向上 ● 実際: ReadIndex を実行し最新のデータの場合に Follwer がデータを返す ○ 最新じゃなかった場合にはデータの更新を待つ ○ Hotspot などで Leader が高負荷かつ十分データ更新が少ないケースで有用 ○ tidb_replica_read で Follower の選出方法を指定可能 ■ ランダム, 負荷状況, 同 Zone など ● Hotspot はほとんどなく負荷が偏っていないため採用せず

Slide 45

Slide 45 text

45 実行 Throughput 達成の裏側(Stale Read) ● Stale(一定時間前な)データも返せるようにする , そのためすべての Follwer は Read Query を処 理できるようになる ○ サービス的に古いデータを返してもいいかどうかは要確認 ● 下記が問題となっているときに性能向上が期待される ○ Three copy の Latency ○ Follower から Leader への ReadIndex の Latency ● Follower Read と同様に偏りがなく Three copy の Latency が問題ではないため不採用

Slide 46

Slide 46 text

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 を作ってもらった

Slide 47

Slide 47 text

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 では有効に働かせることはできなかった

Slide 48

Slide 48 text

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 発行

Slide 49

Slide 49 text

49 実行 Throughput 達成の裏側(tidb_slow_log_threshold) ● long-query-time と同様で slow-log に出力するためのしきい値 ● Query の量が多く slow log も多いため, 出力に関する負荷を削減しようとした ● TiDB Cloud Console の Diagnosis で結果が表示されるのは早くなった ● しかし TiDB 自体の Throughput に効果はなかった

Slide 50

Slide 50 text

50 実行 Throughput 達成の裏側(max-batch-wait-time) ● TiDB から TiKV にリクエストする際に指定した時間待つことでリクエストをまとめて送る ● 多少の Latency を犠牲にして TiKV へのリクエスト数(通信回数)を減らして全体の Throughput 向 上を図る ● 軽いが量が多い Query によるリクエストが支配的なためこれを削減しようとした ● 後述の grpc-connection-count と組み合わせる事によって更に効果が得られた

Slide 51

Slide 51 text

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 が向上した

Slide 52

Slide 52 text

52 実行 Throughput 達成の裏側(grpc-concurrency) ● gRPC worker のスレッド数 ● Mercari の workload は Read が圧倒的に多い ● 多数の Read Query を並列でさばけるよう並列数を上げて全体の Throughput 向上を見込んだ ● TiKV の CPU Usage は上がったが全体としての Throughput は向上した

Slide 53

Slide 53 text

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 向上には寄与しなかった

Slide 54

Slide 54 text

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 ✅ 😐

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

56 実行 QPS…

Slide 57

Slide 57 text

57 実行 🎉 4,500,000 🎉

Slide 58

Slide 58 text

58 準備 & 計画 Latency Throughput ● 実際の Query で sysbench シナリオを作成 ● GMV から算出 ● 実際の Query で sysbench シナリオを作成 ● sysbench シナリオを低負 荷で流す ● 本番 DB と replication す る ● 同期完了後に整合性確認 Replication 1,500,000 QPS 7 日以内に完了 目標値未満か

Slide 59

Slide 59 text

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 をベースに目標値を再設定

Slide 60

Slide 60 text

60 実行

Slide 61

Slide 61 text

61 Best Mid High x10 x1.5 x1.5 実行

Slide 62

Slide 62 text

62 50% slowdown 実行

Slide 63

Slide 63 text

63 50% slowdown 実行

Slide 64

Slide 64 text

64 準備 & 計画 Latency Throughput ● 実際の Query で sysbench シナリオを作成 ● GMV から算出 ● 実際の Query で sysbench シナリオを作成 ● sysbench シナリオを低負 荷で流す ● 本番 DB と replication す る ● 同期完了後に整合性確認 Replication 1,500,000 QPS 7 日以内に完了 目標値未満か

Slide 65

Slide 65 text

65 Primary Relay Fallback TiCDC 整合性確認 準備 & 計画

Slide 66

Slide 66 text

66 実行 Primary Relay Fallback CREATE TABLE DDL 実行

Slide 67

Slide 67 text

67 実行 Primary Relay Fallback 初期同期 export import

Slide 68

Slide 68 text

68 実行 Primary Relay Fallback 更新同期 Incremental

Slide 69

Slide 69 text

69 実行 Primary Relay Fallback STOP REPLI 静止点作成

Slide 70

Slide 70 text

70 実行 Primary Relay Fallback TiCDC Set start-ts STOP REPLI TiCDC 設定

Slide 71

Slide 71 text

71 実行 Primary Relay Fallback TiCDC START REPLI 同期再開

Slide 72

Slide 72 text

72 実行 Primary Relay Fallback TiCDC STOP REPLI (再)静止点作成

Slide 73

Slide 73 text

73 実行 Primary Relay Fallback TiCDC sync-diff-inspector STOP REPLI sync-diff-inspector

Slide 74

Slide 74 text

74 実行 Primary Relay Fallback TiCDC START REPLI 同期再開

Slide 75

Slide 75 text

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

Slide 76

Slide 76 text

76 < 100h 実行

Slide 77

Slide 77 text

77 < 100h 実行

Slide 78

Slide 78 text

78 準備 & 計画 Latency Throughput ● 実際の Query で sysbench シナリオを作成 ● GMV から算出 ● 実際の Query で sysbench シナリオを作成 ● sysbench シナリオを低負 荷で流す ● 本番 DB と replication す る ● 同期完了後に整合性確認 Replication 1,500,000 QPS 7 日以内に完了 目標値未満か

Slide 79

Slide 79 text

79 準備 & 計画 Latency Throughput ● 実際の Query で sysbench シナリオを作成 ● GMV から算出 ● 実際の Query で sysbench シナリオを作成 ● sysbench シナリオを低負 荷で流す ● 本番 DB と replication す る ● 同期完了後に整合性確認 Replication 1,500,000 QPS 7 日以内に完了 目標値未満か +50% 4,500,000 < 100h

Slide 80

Slide 80 text

80 準備 & 計画 Latency Throughput ● 実際の Query で sysbench シナリオを作成 ● GMV から算出 ● 実際の Query で sysbench シナリオを作成 ● sysbench シナリオを低負 荷で流す ● 本番 DB と replication す る ● 同期完了後に整合性確認 Replication 1,500,000 QPS 7 日以内に完了 目標値未満か +50% 4,500,000 < 100h

Slide 81

Slide 81 text

81 PoC の背景 Agenda 準備 & 計画 実行 まとめ 02 03 04 01

Slide 82

Slide 82 text

82 まとめ

Slide 83

Slide 83 text

83 まとめ TiDB Cloud が Mercari の workload に耐えうるか

Slide 84

Slide 84 text

84 まとめ 性能要件 Throughput Latency Replication 機能要件 Failover Backup/Recovery DR CDC …

Slide 85

Slide 85 text

85 まとめ Latency Throughput ● 実際の Query で sysbench シナリオを作成 ● GMV から算出 ● 実際の Query で sysbench シナリオを作成 ● sysbench シナリオを低負 荷で流す ● 本番 DB と replication す る ● 同期完了後に整合性確認 Replication

Slide 86

Slide 86 text

86 まとめ Latency Throughput ● 本番データを使って実際の Query を流す ● 現行, 未来(N 年後)の QPS をさばけるかを評価 ● 本番データを使って実際の Query を流す ● Throughput では測れな い best/middle な Latency を計測し評価 ● 本番 DB と replication し てデータの移行/整合性確認 を取るまでの時間 ● 本番移行にかかる時間を評 価 Replication

Slide 87

Slide 87 text

87 まとめ Latency Throughput ● 実際の Query で sysbench シナリオを作成 ● GMV から算出 ● 実際の Query で sysbench シナリオを作成 ● sysbench シナリオを低負 荷で流す ● 本番 DB と replication す る ● 同期完了後に整合性確認 Replication 1,500,000 QPS 7 日以内に完了 目標値未満か

Slide 88

Slide 88 text

88 準備 & 計画 Latency Throughput ● 実際の Query で sysbench シナリオを作成 ● GMV から算出 ● 実際の Query で sysbench シナリオを作成 ● sysbench シナリオを低負 荷で流す ● 本番 DB と replication す る ● 同期完了後に整合性確認 Replication 1,500,000 QPS 7 日以内に完了 目標値未満か +50% 4,500,000 < 100h

Slide 89

Slide 89 text

89 準備 & 計画 Latency Throughput ● 実際の Query で sysbench シナリオを作成 ● GMV から算出 ● 実際の Query で sysbench シナリオを作成 ● sysbench シナリオを低負 荷で流す ● 本番 DB と replication す る ● 同期完了後に整合性確認 Replication 1,500,000 QPS 7 日以内に完了 目標値未満か +50% 4,500,000 < 100h

Slide 90

Slide 90 text

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 については課題が残る まとめ

Slide 91

Slide 91 text

91 Thanks to

Slide 92

Slide 92 text

92 PoC を完了して ● 現地開発チームを巻き込んだサポート ● 迅速な対応/回答 ○ Patch や Bug 修正 ○ 数時間以内の返答 ● それぞれのフェーズでの効果測定 ○ TiDB への理解が深まる ● QPS 達成後により効率的にリソースを使うための検証 Thanks to PingCAP

Slide 93

Slide 93 text

93 We are hiring ! Traffic Large data Business impact ! https://careers.mercari.com

Slide 94

Slide 94 text

94 We are hiring ! https://apply.workable.com/mercari/j/CBEAB3A15B/

Slide 95

Slide 95 text

95 Thank you for your attention !!