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
   〜 シャーディング無しで⼤量インサートをさばくには？ 〜
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

8. MySQL互換NewSQL !?
   8
   

   View Slide

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

   View Slide

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
    

    View Slide

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を除く)
    

    View Slide

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

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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

    View Slide

17. Grafana画⾯
    17
    

    View Slide

18. Dashboard画⾯
    18
    

    View Slide

19. Dashboard画⾯
    19
    

    View Slide

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

    View Slide

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

    View Slide

22. ⼤規模案件でのTiDB検証
    22
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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

    View Slide

28. もしくは...
    28
    

    View Slide

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

    View Slide

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
    

    View Slide

31. MySQL結果(QPS)
    31
    

    View Slide

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

    View Slide

33. TiDB結果(QPS)
    33
    

    View Slide

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

    View Slide

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
    

    View Slide

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

    View Slide

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
    

    View Slide

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

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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 より
    

    View Slide

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

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

55. View Slide