Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

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

PingCAP-Japan

July 11, 2023
Tweet

More Decks by PingCAP-Japan

Other Decks in Technology

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. 55

    View Slide