Tweet
Tweet

Slide 1

Slide 1 text

TiDBによる⼤規模ログデータ管理への挑戦！ LINE Database dept. MySQL1 Team Otsuka Tomoaki 2023.07.07 〜 シャーディング無しで⼤量インサートをさばくには？ 〜

Slide 2

Slide 2 text

⾃⼰紹介 • ⼤塚知亮 (@tom__bo) • 所属 • LINE株式会社 • データベース室 MySQL1チーム • 業務 • MySQLの運⽤, ⾃動化, 開発 • TiDBの検証, 導⼊, 運⽤ 2

Slide 3

Slide 3 text

⽬次 • MySQLチーム概要 • MySQL運⽤における課題 • TiDB初期導⼊検証 • ⼤規模案件でのTiDB検証 3

Slide 4

Slide 4 text

データベース室 MySQL1チーム • LINEのMySQLの運⽤と管理 • 社内クラウド上でMySQLサービスを提供 • サポートするMySQLはすべてオンプレ運⽤ (VM/PM) • 主な仕事 • スキーマ変更、トラブルシューティングや設計相談などのDBA業務 • 運⽤⾃動化, プラットフォーム改善のための開発業務 4

Slide 5

Slide 5 text

サポートするMySQLインスタンス 3000+ 3500+ 4000+ 5500+ 6500+ 0 1000 2000 3000 4000 5000 6000 7000 2018 2019 2020 2021 2022 5

Slide 6

Slide 6 text

運⽤上の課題 • スケーラビリティ • ディスクサイズ上限 3TB (社内VMの制限) • Single Primary構成によるCPU負荷上限 • Write量増加によるレプリケーション遅延 • シャーディングによる運⽤コスト増 • (垂直分割 5+, ⽔平分割 40+) • 社内HA構成ツールのマルチリージョン課題 6

Slide 7

Slide 7 text

MySQLシャーディングソリューション • Vitess • ShardingSphere • Percona MySQL, MariaDB for Spider Storage Engine 7

Slide 8

Slide 8 text

MySQL互換NewSQL !? 8

Slide 9

Slide 9 text

初期調査 • 基本的なアーキテクチャ把握 • ⾃前運⽤に必要なコンポーネント調査 • アプリ視点でのMySQLとの違い • 動作検証 9

Slide 10

Slide 10 text

基本的なアーキテクチャ(最⼩構成) 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

Slide 11

Slide 11 text

コンポーネント調査 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を除く)

Slide 12

Slide 12 text

コンポーネント調査 調査対象から除外したもの Component Description TiDB Operator • K8S上のTiDB運⽤ツール TiFlash • OLAP向けカラムナストレージエンジン TiSpark • Apache Sparkのthin layer TiDB Lightning • TB単位のデータインポートツール 12

Slide 13

Slide 13 text

アプリ視点での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

Slide 14

Slide 14 text

• 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

Slide 15

Slide 15 text

アプリ視点での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

Slide 16

Slide 16 text

動作検証 • デプロイ, ⼿動での動作検証 • sysbenchを使ったベンチマーク実⾏ • 各ツールの動作検証 • Grafanaの画像 • Dashboardのヒートマップ, ログなど 16

Slide 17

Slide 17 text

Grafana画⾯ 17

Slide 18

Slide 18 text

Dashboard画⾯ 18

Slide 19

Slide 19 text

Dashboard画⾯ 19

Slide 20

Slide 20 text

初期調査所感 • 速い！！ • rows_examinedが多いクエリで速度を体感 • レイテンシは数⼗~百ms程度は増える(環境依存, dev環境での感想) • エコシステムの充実度が⾼い • 監視, マイグレーション, リカバリなど充実している • 周辺ツールの開発も活発 • MySQLからの移⾏サポートが強い • DM, sync-diff-inspector, dumplingなど • DMのgh-ost/pt-osc対応など 20

Slide 21

Slide 21 text

DMのgh-ost/pt-osc対応 21 https://docs.pingcap.com/tidb/stable/migrate-with-pt-ghost より

Slide 22

Slide 22 text

⼤規模案件でのTiDB検証 22

Slide 23

Slide 23 text

⼤規模・⾼負荷案件発⽣ • 複数システムからKafkaにログ集約、分析⽤にRDBに格納 • 8⽇間で11TBのINSERT(MySQL換算) • MySQLで管理できないか？ MySQL system Kafka Consumer App 23 MySQL (DR zone)

Slide 24

Slide 24 text

パフォーマンス要件 • 1⽇12億レコード (1レコード約1KB) • ピーク時には秒間5万レコードのINSERT • ⼤半がINSERT, SELECTは⼿動実⾏のみ • 直近7⽇分のデータはいつでもSELECTできる必要あり • シャーディング対応不可！ 24

Slide 25

Slide 25 text

MySQLで対応する場合の課題 • ディスクサイズ • 社内の標準スペックでは対応不可 • SDS製品の選定, 検証も同時進⾏ (本発表では対象外) • 更新速度 • 感覚的に10k~20k records insert/s程度でレプリケーション遅延 • 運⽤難易度 • SELECTが現実的な時間で応答可能か • スキーマ変更(DDL)が必要になった場合に対応可能か 25

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

対応⽅針 • 8⽇分(11TB)のみ保持 • ⽇時でパーティションを切る • ⽇時で8⽇前のデータをダンプしたらDROP PARTITION • ダンプしたデータは必要になったらリストア • (MySQL)ピーク時はレプリケーション遅延を許容 • Kafka, Consumer Appでキューイングが可能 • Sourceの障害時にキューから溢れる前に遅延が収束すれば良い 27

Slide 28

Slide 28 text

もしくは... 28

Slide 29

Slide 29 text

簡易⽐較実験 • 実験⽅法 • mysqlslapコマンドで1⾏INSERTを⼀定時間実⾏ • 1⾏1KB程度 • MySQL 検証環境 • MySQL 8.0.x (最新メジャーバージョン) • Semi-sync replication • VM, 20core vCPU, Memory 240GB, 2TB SSD • mysqlslapの並列度は1000 29

Slide 30

Slide 30 text

簡易⽐較実験 • 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

Slide 31

Slide 31 text

MySQL結果(QPS) 31

Slide 32

Slide 32 text

MySQLレプリケーション遅延 32

Slide 33

Slide 33 text

TiDB結果(QPS) 33

Slide 34

Slide 34 text

検証項⽬ • ⾮互換な仕様を回避が可能か • ディスクサイズ⽐較 • パフォーマンス • インサート速度の限界 • データ量増加によるパフォーマンス影響 • DDL実⾏によるパフォーマンス影響 • インスタンス障害時のパフォーマンス影響 • 安定性 • 実際に10TB以上のデータを投⼊して動作するか？ • 復旧⼿順の確認 34

Slide 35

Slide 35 text

ディスクサイズ⽐較 • 負荷試験データを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

Slide 36

Slide 36 text

検証⽅法 • システムの統合負荷テスト • アプリケーション含めシステム全体での統合テスト • 継続テスト/ピーク時再現テスト • 独⾃負荷再現ツールによるテスト • システム統合ベンチマークテスト時に実⾏されたクエリを抽出 • 負荷再現, ベンチマークツールを開発 36

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

安定性の検証 • 本番同等のデータ量で継続的に負荷をかける • 以下のパフォーマンス影響を調査 • データ量増加によるパフォーマンス影響 • DDL実⾏によるパフォーマンス影響 • インスタンス障害時のパフォーマンス影響 38

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

10TBデータ検証結果 (BULK INSERT量調整) • BULK INSERTによるINSERT量を10から50, 100と上げること でパフォーマンス上昇を確認 • BULK INSERT(50): 78k records/sec • BULK INSERT(100): 85k records/sec 40

Slide 41

Slide 41 text

DDL(DROP PARTITION)影響 41 • ALTER実⾏から10分後のGCでパフォーマンス低下 • 8%程度のQPS低下 • ただし通常のブレの範囲内

Slide 42

Slide 42 text

インスタンス障害による影響 • TiKV 1ノードでプロセスのkill • 数秒間クエリの実⾏が停⽌ • プロセスは数秒後に⾃動起動 42

Slide 43

Slide 43 text

インスタンス障害による影響 • TiKVノードの強制停⽌ • 数秒間クエリの実⾏が停⽌ • 復旧しない場合90%程度のパフォーマンスで稼働 43

Slide 44

Slide 44 text

インスタンス障害による影響 • PDリーダノードの強制停⽌ • 数秒間クエリの実⾏が停⽌ • リーダ選出後は2台でもパフォーマンス影響なし 44

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

課題 • ⾼負荷環境で利⽤できるPITR⼿法がない • max-replicas=3での多重故障 • 障害時リシャードの挙動理解 • Storage 4TB制限 46

Slide 47

Slide 47 text

PITR検討 • TiDB Binlog • DrainerがSPOF, 故障した場合バックアップからやり直し • 変更分を受け取るためにTiDBクラスタ全体のパフォーマンスに影響 • TiCDC • TiCDCにPITR機能はない • ダウンストリームのMySQLでPITR • MySQLが⾼負荷に耐えられない&完全なPITRはできない 47

Slide 48

Slide 48 text

PITR検討 • gc-timeを伸ばして復旧時点のデータを抽出(Historical Read) • gc-timeの時間内に抽出が必須 • v6.2以降はBRで可能 48 https://docs-archive.pingcap.com/tidb/v6.2/point-in-time-recovery より

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

障害時リシャードの挙動理解 • 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 より

Slide 51

Slide 51 text

Storage 4TB制限 • TiKV 1インスタンス中のregion数が30kを超えるとCPU利⽤率 が跳ねる現象 • (PingCAPさんとのMTGで共有いただいた) • 実際に本番同様の環境でテストする重要性を再確認 • v5.0で追加されたHibenate region機能により緩和 51

Slide 52

Slide 52 text

最終的な構成 • データ容量の要件が変わり... • 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

Slide 53

Slide 53 text

TiDBの運⽤の現状 • MultiAZ対応が必要な社内システムで運⽤中 • DR構成への導⼊に向け調査中 53

Slide 54

Slide 54 text

Big Thanks • PingCAP Japanさんに導⼊に向けた調査への協⼒を頂きました • TiDB理解のための説明会開催 • 仕様理解や設計段階での疑問解消のためのMTGを毎週開催 54

Slide 55

Slide 55 text

55