TiDBによる大規模ログデータ管理の挑戦！シャーディングなしで大量インサートをさばくには？ - LINE株式会社 - TiDB User Day 2023

イベント開催日：2023年7月7日
講演者：LINE株式会社　ITSC データベース室　MySQL 1チーム
　　　　ソフトウェアエンジニア　大塚 知亮 氏

本スライドでは、TiDBで大量のログデータを管理するRDBとして、MySQL及びTiDBを検証した過程と結果、そしてオンプレでの運用方法について発表します。通常、超大量のデータ挿入や更新が発生するアプリケーションにMySQLを利用する場合、適切なデータ量や負荷を基準にシャーディングを行って対応します。しかし、それによってシャードを意識したクエリの発行が必要になるだけでなく、シャードをまたいだデータのジョインや整合性の担保に頭を悩ませることになります。この一つの解決策として、MySQL互換の分散データベースであるTiDBは魅力的な選択肢です。このスライドでは、LINEでシャーディングなしで高負荷案件に対応するために、どのように検証し、オンプレでの安定運用に向けてどのような構成にしたのかを共有します。

Transcript

1. TiDBによる⼤規模ログデータ管理への挑戦！ LINE Database dept. MySQL1 Team Otsuka Tomoaki 2023.07.07 〜 シャーディング無しで⼤量インサートをさばくには？ 〜
2. ⾃⼰紹介 • ⼤塚知亮 (@tom__bo) • 所属 • LINE株式会社 • データベース室 MySQL1チーム • 業務 • MySQLの運⽤, ⾃動化, 開発 • TiDBの検証, 導⼊, 運⽤ 2
3. ⽬次 • MySQLチーム概要 • MySQL運⽤における課題 • TiDB初期導⼊検証 • ⼤規模案件でのTiDB検証 3
4. データベース室 MySQL1チーム • LINEのMySQLの運⽤と管理 • 社内クラウド上でMySQLサービスを提供 • サポートするMySQLはすべてオンプレ運⽤ (VM/PM) • 主な仕事 • スキーマ変更、トラブルシューティングや設計相談などのDBA業務 • 運⽤⾃動化, プラットフォーム改善のための開発業務 4
5. サポートするMySQLインスタンス 3000+ 3500+ 4000+ 5500+ 6500+ 0 1000 2000 3000 4000 5000 6000 7000 2018 2019 2020 2021 2022 5
6. 運⽤上の課題 • スケーラビリティ • ディスクサイズ上限 3TB (社内VMの制限) • Single Primary構成によるCPU負荷上限 • Write量増加によるレプリケーション遅延 • シャーディングによる運⽤コスト増 • (垂直分割 5+, ⽔平分割 40+) • 社内HA構成ツールのマルチリージョン課題 6
7. MySQLシャーディングソリューション • Vitess • ShardingSphere • Percona MySQL, MariaDB for Spider Storage Engine 7
8. MySQL互換NewSQL !? 8
9. 初期調査 • 基本的なアーキテクチャ把握 • ⾃前運⽤に必要なコンポーネント調査 • アプリ視点でのMySQLとの違い • 動作検証 9
10. 基本的なアーキテクチャ(最⼩構成) Placement Driver (PD) TiDB Server TiDB Server TiDB Server Placement Driver (PD) Placement Driver (PD) TiKV (RocksDB) TiKV (RocksDB) TiKV (RocksDB) TiKV (RocksDB) TiKV (RocksDB) PD cluster TiDB servers TiKV cluster Raft Region Region Region Region Region Region Region Region Region Region Region Region Data Access Query Data Placement Acquire Transaction ID Control Data Placement Heartbeat 10
11. コンポーネント調査 Component Description TiUP • クラスタデプロイ・管理ツール TiDB Binlog • CDCツール(MySQLのbinlogとは完全に別物) • 増分バックアップ, PITRの実現 • 現在はTiCDCが推奨されている TiCDC • TiKVの増分データをレプリケートするツール Backup&Restore(BR) • バックアップ, リストアツール • (v6.2よりPITRが可能) dumpling • データエクスポートツール TiDB Data Migration(DM) • データマイグレーションツール sync-diff-inspector • TiDB, MySQL間のデータ差分検査ツール Monitoring • Grafana: モニタリング, アラート • PD Dashboard: モニタリング, 統計情報管理 11 (TiDB, TiKV, PDを除く)
12. コンポーネント調査 調査対象から除外したもの Component Description TiDB Operator • K8S上のTiDB運⽤ツール TiFlash • OLAP向けカラムナストレージエンジン TiSpark • Apache Sparkのthin layer TiDB Lightning • TB単位のデータインポートツール 12
13. アプリ視点でのMySQLとの違い • ストアドプロシージャ, ストアドファンクション • トリガー, イベント, UDF, チェック制約 • FULLTEXTインデックス • SPATIAL型, SPATIAL関数/インデックス • ascii, latin1, binary, utf8, utf8mb4, and gbk以外のcharset • utf8mb4だとcollationはunicode_ci, general_ci, binのみ • Column単位の権限 • CREATE TABLE {tblName} AS SELECT構⽂ Unsupported features (影響度が⼤きいものを抜粋) ※ 詳しくはドキュメントを参照してください 13
14. • PDからTiDB Serverにauto_inc値の範囲を割当てる • AUTO_ID_CACHE = 1にすることでMySQLと同様の動きにする ことも可能 • ただしパフォーマンスと相談 アプリ視点でのMySQLとの違い Auto Increment TiDB Server TiDB Server TiDB Server TiDB servers Placement Driver (PD) Placement Driver (PD) Placement Driver (PD) PD cluster Raft Query auto_inc range [1, 30000] [30001, 60000] [60001, 90000] 14
15. アプリ視点でのMySQLとの違い • 基本的にDDLはオンラインで 実⾏される • 並⾏するDMLはエラー • DDL前後でcast可能な場合は 実⾏可能 • 6.3(DMR)からメタデータロックあり DDL https://github.com/pingcap/tidb/blob/master/docs/design/2018-10-08-online-DDL.md 参照 ERROR 8028 (HY000): Information schema is changed during the execution of the statement 15
16. 動作検証 • デプロイ, ⼿動での動作検証 • sysbenchを使ったベンチマーク実⾏ • 各ツールの動作検証 • Grafanaの画像 • Dashboardのヒートマップ, ログなど 16
17. Grafana画⾯ 17
18. Dashboard画⾯ 18
19. Dashboard画⾯ 19
20. 初期調査所感 • 速い！！ • rows_examinedが多いクエリで速度を体感 • レイテンシは数⼗~百ms程度は増える(環境依存, dev環境での感想) • エコシステムの充実度が⾼い • 監視, マイグレーション, リカバリなど充実している • 周辺ツールの開発も活発 • MySQLからの移⾏サポートが強い • DM, sync-diff-inspector, dumplingなど • DMのgh-ost/pt-osc対応など 20
21. DMのgh-ost/pt-osc対応 21 https://docs.pingcap.com/tidb/stable/migrate-with-pt-ghost より
22. ⼤規模案件でのTiDB検証 22
23. ⼤規模・⾼負荷案件発⽣ • 複数システムからKafkaにログ集約、分析⽤にRDBに格納 • 8⽇間で11TBのINSERT(MySQL換算) • MySQLで管理できないか？ MySQL system Kafka Consumer App 23 MySQL (DR zone)
24. パフォーマンス要件 • 1⽇12億レコード (1レコード約1KB) • ピーク時には秒間5万レコードのINSERT • ⼤半がINSERT, SELECTは⼿動実⾏のみ • 直近7⽇分のデータはいつでもSELECTできる必要あり • シャーディング対応不可！ 24
25. MySQLで対応する場合の課題 • ディスクサイズ • 社内の標準スペックでは対応不可 • SDS製品の選定, 検証も同時進⾏ (本発表では対象外) • 更新速度 • 感覚的に10k~20k records insert/s程度でレプリケーション遅延 • 運⽤難易度 • SELECTが現実的な時間で応答可能か • スキーマ変更(DDL)が必要になった場合に対応可能か 25
26. MySQLのレプリケーションの仕組み Tx1 insert insert commit Tx2 insert commit Binlog Tx2 update commit insert commit insert insert commit update commit Source MySQL Replica MySQL Binlog insert commit insert insert commit update commit (Replicate) (※ Multi Thread Replica) 26
27. 対応⽅針 • 8⽇分(11TB)のみ保持 • ⽇時でパーティションを切る • ⽇時で8⽇前のデータをダンプしたらDROP PARTITION • ダンプしたデータは必要になったらリストア • (MySQL)ピーク時はレプリケーション遅延を許容 • Kafka, Consumer Appでキューイングが可能 • Sourceの障害時にキューから溢れる前に遅延が収束すれば良い 27
28. もしくは... 28
29. 簡易⽐較実験 • 実験⽅法 • mysqlslapコマンドで1⾏INSERTを⼀定時間実⾏ • 1⾏1KB程度 • MySQL 検証環境 • MySQL 8.0.x (最新メジャーバージョン) • Semi-sync replication • VM, 20core vCPU, Memory 240GB, 2TB SSD • mysqlslapの並列度は1000 29
30. 簡易⽐較実験 • TiDB 検証環境 • v6.1 • TiDB (x3): VM, 20core vCPU, Memory 240GB, 500GB SSD • PD (x3): VM, 12core vCPU, Memory 60GB, 500GB SSD • TiKV (x9): VM, 20core vCPU, Memory 240GB, 2TB SSD • mysqlslapの並列度は3000 30
31. MySQL結果(QPS) 31
32. MySQLレプリケーション遅延 32
33. TiDB結果(QPS) 33
34. 検証項⽬ • ⾮互換な仕様を回避が可能か • ディスクサイズ⽐較 • パフォーマンス • インサート速度の限界 • データ量増加によるパフォーマンス影響 • DDL実⾏によるパフォーマンス影響 • インスタンス障害時のパフォーマンス影響 • 安定性 • 実際に10TB以上のデータを投⼊して動作するか？ • 復旧⼿順の確認 34
35. ディスクサイズ⽐較 • 負荷試験データを1億⾏ずつ⽣成 • 1record 1KB (レコードの⼤半はランダムな⽂字列を詰めたtext) • MySQLは1インスタンスのdatadirサイズ(binlog除く) • TiDBはTiKV9台のdatadirサイズ(max-replicas = 3) Tx count (million) MySQL (GB) TiDB (GB) 100 104 145 200 208 267 300 312 389 ... (約100GBずつ増加) (約120GBずつ増加) 35
36. 検証⽅法 • システムの統合負荷テスト • アプリケーション含めシステム全体での統合テスト • 継続テスト/ピーク時再現テスト • 独⾃負荷再現ツールによるテスト • システム統合ベンチマークテスト時に実⾏されたクエリを抽出 • 負荷再現, ベンチマークツールを開発 36
37. TiDB負荷再現環境 • ベンチマークツール • 複数ホストからLB経由でTiDB Serversに接続 • 同時接続最⼤300 • TiDBスペック • v6.1 • TiDB (x3): VM, 20core vCPU, Memory 240GB, 500GB SSD • PD (x3): VM, 12core vCPU, Memory 60GB, 500GB SSD • TiKV (x9): VM, 20core vCPU, Memory 240GB, 2TB SSD 37
38. 安定性の検証 • 本番同等のデータ量で継続的に負荷をかける • 以下のパフォーマンス影響を調査 • データ量増加によるパフォーマンス影響 • DDL実⾏によるパフォーマンス影響 • インスタンス障害時のパフォーマンス影響 38
39. 10TBデータ検証結果 (QPS) • BULK INSERT 60%, UPDATE 40% • BULK INSERT: 10 records • 5分ごとに10並列度ずつ増加 • 最⼤8.8k QPS, insert 48k rows/sec, update 5k rows/sec 39
40. 10TBデータ検証結果 (BULK INSERT量調整) • BULK INSERTによるINSERT量を10から50, 100と上げること でパフォーマンス上昇を確認 • BULK INSERT(50): 78k records/sec • BULK INSERT(100): 85k records/sec 40
41. DDL(DROP PARTITION)影響 41 • ALTER実⾏から10分後のGCでパフォーマンス低下 • 8%程度のQPS低下 • ただし通常のブレの範囲内
42. インスタンス障害による影響 • TiKV 1ノードでプロセスのkill • 数秒間クエリの実⾏が停⽌ • プロセスは数秒後に⾃動起動 42
43. インスタンス障害による影響 • TiKVノードの強制停⽌ • 数秒間クエリの実⾏が停⽌ • 復旧しない場合90%程度のパフォーマンスで稼働 43
44. インスタンス障害による影響 • PDリーダノードの強制停⽌ • 数秒間クエリの実⾏が停⽌ • リーダ選出後は2台でもパフォーマンス影響なし 44
45. TiDBでの想定構成 Placement Driver (PD) TiDB Server TiDB Server TiDB Server Placement Driver (PD) Placement Driver (PD) TiKV (RocksDB) TiKV (RocksDB) TiKV (RocksDB) TiKV (RocksDB) TiKV (RocksDB) PD cluster TiDB servers TiKV cluster Raft Region Region Region Region Region Region Region Region Region Region Region Region Data Access Query Data Placement Acquire Transaction ID Control Data Placement Heartbeat Pump Drainer Pump Pump TiDB-Binlog cluster Modified Data 45
46. 課題 • ⾼負荷環境で利⽤できるPITR⼿法がない • max-replicas=3での多重故障 • 障害時リシャードの挙動理解 • Storage 4TB制限 46
47. PITR検討 • TiDB Binlog • DrainerがSPOF, 故障した場合バックアップからやり直し • 変更分を受け取るためにTiDBクラスタ全体のパフォーマンスに影響 • TiCDC • TiCDCにPITR機能はない • ダウンストリームのMySQLでPITR • MySQLが⾼負荷に耐えられない&完全なPITRはできない 47
48. PITR検討 • gc-timeを伸ばして復旧時点のデータを抽出(Historical Read) • gc-timeの時間内に抽出が必須 • v6.2以降はBRで可能 48 https://docs-archive.pingcap.com/tidb/v6.2/point-in-time-recovery より
49. max-replicas=3での多重故障対応 • TiKVのmax-replicas変数のデフォルトは3 • TiKV内でregionごとのデータは3つに冗⻑化される • regionの過半数に満たないとそのregionのデータにはアクセスできない • 故障したノードのデータリシャード • リシャード中に他のノードが落ちると全体停⽌の可能性 • 対策 • max-replicasを5にする(2台までの同時故障対応) • placement-ruleの活⽤(DCリージョンやラック単位の故障の影響低減) • max-store-down-timeを最⼩の10分にする(早急にリシャードを開始) 49
50. 障害時リシャードの挙動理解 • TiKVのステータスに”Pending Offline”がある • “Offline”から”Tombstone”に遷移する間 • 異常があるとこのステートでスタックしがち • 他のノードのディスク容量がlow-space-ratioを超えている • 1 node down後, ノード追加前にtiup cluster scale-inの実⾏ • 対策 • ディスク容量に余裕をもたせる • max-replicas+1以上のTiKVノードで運⽤する 50 https://docs.pingcap.com/tidb/stable/tidb-scheduling より
51. Storage 4TB制限 • TiKV 1インスタンス中のregion数が30kを超えるとCPU利⽤率 が跳ねる現象 • (PingCAPさんとのMTGで共有いただいた) • 実際に本番同様の環境でテストする重要性を再確認 • v5.0で追加されたHibenate region機能により緩和 51
52. 最終的な構成 • データ容量の要件が変わり... • 1⽇あたり7.2TBのデータINSERT • 8⽇分で57.6TB • オペミスなどに備え+αの容量 tidb-gc-life-time = 24h • インスタンスタイプと台数 52 Role # Disk Size (GB) vCPU Memory(GB) TiDB Server 3(+1) 200 4 16 PD 5 480 20 256 TiKV 35(+2) 1920 10 64
53. TiDBの運⽤の現状 • MultiAZ対応が必要な社内システムで運⽤中 • DR構成への導⼊に向け調査中 53
54. Big Thanks • PingCAP Japanさんに導⼊に向けた調査への協⼒を頂きました • TiDB理解のための説明会開催 • 仕様理解や設計段階での疑問解消のためのMTGを毎週開催 54