TiDB User Day 2024 大規模データ処理基盤におけるHBaseからTiDBへの移行事例

https://pingcap.co.jp/tidb-user-day/jul-2024/

株式会社サイバーエージェントでは、様々なサービスから取得したデータをリアルタイムに分析するための大規模データ処理基盤を開発・運用しています。そして運用負担を軽減するため、OLTPクエリに使用していたHBaseをTiDBに置き換えて約半年運用しています。本発表では、まずHBaseの課題とTiDBの選定理由を説明します。次にHBaseからTiDBへの移行方法を紹介し、移行後の性能と運用面での変化について報告します。また、移行後に発生した大規模データのバッチ書き込みにおける性能問題と、その改善方法についても解説します。

Transcript

1. 大規模データ処理基盤における HBaseからTiDBへの移行事例 株式会社サイバーエージェント 渡邉 敬之 1
2. 自己紹介 渡邉 敬之 / Watanabe Noriyuki 株式会社サイバーエージェント グループIT推進本部 DPU (Data Product Unit)
3. 1.部署の紹介 2.HBaseの運用者・利用者視点の課題 3.TiDBの選定理由 4.HBaseからTiDBへの移行 5.移行後の状況 6.今後の課題とまとめ 3
4. 部署の紹介 4
5. DPU(ﾃﾞｰﾀﾌﾟﾛﾀﾞｸﾄﾕﾆｯﾄ)とは？ 5 『データの力で事業成長を加速させる』 ミッション
6. 大規模データ処理基盤 6 旧データ処理基盤 現在DPUでは大規模データ処理基盤の 刷新に取り組んでいます
7. プライベートクラウドとKubernetes環境の紹介 7 • Cycloud サイバーエージェントのプライベートクラウド • Kubernetesクラスタ - DPUが管理しているクラスタがCycloud内で動いている - 部署内の様々なサービスが動いている • 旧データ処理基盤 Cycloudが提供しているVM上に構築 • 新データ処理基盤 Kubernetesクラスタに構築することで基盤運用者の負 荷を減らす HBase 旧データ処理基盤 DPUが管理しているk8sクラスタ 新データ処理基盤 TiDB
8. HBaseの運用者・利用者視点の課題 8
9. HBaseとは？ 9 Wide Column (key-key-value) NoSQL Databaseの一種 Region - データをkeyのRangeで論理的に分割したもの Region Server - Regionという単位でデータを管理して、クライアントに サービングする HMaster - Regionサーバーに対する Region管理・割り当て Zookeeper - クラスタ全体の障害検知・メタデータ管理 Client - ZookeeperとHMasterと連携して直接 Region Serverからデータを 読み込む TiKVはHBaseを元に開発されたためアーキテクチャが似ている HBaseアーキテクチャ TiKVのような役割 PDのような役割 TiKVのRegionのような役 割
10. HBaseとTiDBの比較 10 HBaseアーキテクチャ 項目 HBase TiDB データモデル Wide-Column Relational トランザクション ❌ ✅ Snapshot Isolation セカンダリインデッ クス ❌ ✅ 柔軟なクエリ ❌ ✅ 一貫性 ✅ ✅ 水平スケーリング ✅ ✅ 低レイテンシ ✅ ❌ 1桁msが要求されるような 場合には不向き
11. HBaseの課題 11 運用負荷 • Hadoopエコシステムへの依存から設定やチューニングが複雑 • HBaseを理解している人材が少なく 、運用と開発が困難 • RegionServerが停止すると長時間のダウンタイムが発生 する可能性がある • ユーザー毎のデータ管理が難しく、アクセス制御やリソース使用量の計測と費用按分が困難 クラウドネイティブへの適応 • HBaseをk8s上で運用するのは困難であり、VM管理とデータベース管理の負担が大きい • HBaseはクラウド間やデータセンター間の移行が困難であり、環境の変化に柔軟に対応できな い 開発効率性 • アプリ側でスキーマ管理 やトランザクション を意識する必要がある • 主にJavaクライアントが公式にサポートされており、他の言語向けクライアントはサポートや 機能が限定的
12. TiDBの選定理由 12
13. 選定理由 1. HBaseと同等の性能を提供できる - スケーラビリティ：HBaseと同様に手動でシャーディングすることなく、リードとライトの両方でスケールア ウトが可能 - レイテンシ：シンプルなクエリではHBaseに比べて遅延があるが、妥当な性能を提供 13
14. 選定理由 1. HBaseと同等の性能を提供できる - スケーラビリティ：HBaseと同様に手動でシャーディングすることなく、リードとライトの両方でスケールア ウトが可能 - レイテンシ：シンプルなクエリではHBaseに比べて遅延があるが、妥当な性能を提供 2. HBaseの課題を解決できる - クラウドネイティブへの適応 - 運用負荷の軽減 - 開発効率性 14
15. クラウドネイティブへの適応 TiDB OperatorによりKubernetesクラスタへ簡単にデプロイ可能 15 https://download.pingcap.com/images/tidb-in-kubernetes/tidb-operator-c ontrol-flow-1.1.png https://github.com/pingcap/tidb-operator/blob/master/examples/ba sic/tidb-cluster.yaml TidbClusterのマニフェスト例
16. クラウドネイティブへの適応 16 構築 監視 バックアップ TidbCluster - TiDBクラスタの設定や状態を管理 - Auto Failoverも実施 TidbDashboard - TiDB Dashboardの状態を管理 BackupSchedule - 定期的なバックアップジョブをスケ ジュール - クラスター全体のバックアップや差分 バックアップが可能 TidbInitializer - TiDB構築時の初期設定が可能（初期 ユーザ作成等） TidbMonitor/TidbNGMonitoring - Prometheusベースの監視スタックをデプロ イ - 定期的に各コンポーネントのプロファイリ ングを実行（CPU使用量、ヒープ使用量、 Goroutineの状態、Mutexの状態を監視） Restore - クラスターをリストア - PITRも可能 TiDB Operatorにより提供される Custom Resources
17. 運用負荷の軽減：可観測性の高さ - 利用者向けのハイレベルな TiDBダッシュボード - 運用者向けの細かい Grafanaダッシュボードやプロファイリング 17 SQLステートメントの実行状況、Slow Query, Top SQL, QPS, レイテンシーなど
18. 運用負荷の軽減：可観測性の高さ - 利用者向けのハイレベルな TiDBダッシュボード - 運用者向けの細かい Grafanaダッシュボードやプロファイリング 188種の表 586種の表 124種の表 18 1分毎に自動でプロファイリングを取 得
19. 運用負荷の軽減：耐障害性 ※1 QPSの低下 次のリーダー選出にraft-base-tick-interval * raft-election-timeout-ticks 秒（デフォルトだと 1 * 10秒）かかるため約10秒間QPSが低下 failoverやスケールイン時にtikv内のリージョンの移動が発生するため負荷がかかりQPSが低下する ※2 コネクションエラー DownしたTiDBと接続しているクライアントのコネクションは切断され、エラーとなる クライアントからの再接続で解消可能（障害でダウンした場合はTiProxyでは解消できない） ※3 パッチ ノード復旧後に、追加されたtikvを削除するために手動でパッチ（recoverFailover）を当てる必要がある 自動削除されない理由はtikv削除時のリージョン移動の負荷が発生するため 19 コンポーネント サービス影響 復旧手順 Automatic Failover PD(Leader) 〇　問題なし 〇　特に不要 〇　期待通り動作 TiKV △　QPSの低下有※１ 〇　復旧後にパッチを当て　 　 るだけ※３ 〇　期待通り動作 TiDB △　Down時にコネクショ　 　 ンエラー発生※２ 〇　特に不要 〇　期待通り動作 ノードがダウンしたときの影響 - 多少のサービス影響はあるが、概ね許容範囲 - HBaseよりも運用負担が軽くダウンタイムも少ない
20. 運用負荷の軽減：ユーザ管理機能 1. 強力で柔軟なセキュリティとアクセス制御 スキーマ毎に権限を付与したユーザを作成できる 2. 特定のユーザがリソースを使いすぎる事を防 止 ユーザ毎にレートリミットや優先度を設定できる 暴走クエリを検知でき、負荷をかけているクエリをkillできる 3. 費用請求が容易にできる ユーザ毎に使用したリソース量を把握できる 20 MySQLのほとんどのRBACと互換性があ る ユーザごとの詳細な権限設定 様々な認証方式に対応
21. 運用負荷の軽減：ユーザ管理機能 1. 強力で柔軟なセキュリティとアクセス制御 スキーマ毎に権限を付与したユーザを作成できる 2. 特定のユーザがリソースを使いすぎる事を防 止 ユーザ毎にレートリミットや優先度を設定できる 暴走クエリを検知でき、負荷をかけているクエリをkillできる 3. 費用請求が容易にできる ユーザ毎に使用したリソース量を把握できる 21
22. 運用負荷の軽減：ユーザ管理機能 1. 強力で柔軟なセキュリティとアクセス制御 スキーマ毎に権限を付与したユーザを作成できる 2. 特定のユーザがリソースを使いすぎる事を防 止 ユーザ毎にレートリミットや優先度を設定できる 暴走クエリを検知でき、負荷をかけているクエリをkillできる 3. 費用請求が容易にできる ユーザ毎に使用したリソース量を把握できる 22 ダッシュボードからス テートメント毎のリソー ス消費量がわかる 日毎のリソース消費量が テーブルに保存される
23. 開発効率性：ユーザ側の実装負荷が低い • MySQL互換である - 学習コストが低く理解している人材が多い - ORMなど既存のツールを利用できる • 複雑なクエリが実行できる • TiFlashの利用で分析クエリも高速に実行できる • データの一貫性がデータベース側で確保されるため、アプリケーション側での処理が単純 化される • スキーマがあるため、データの意味や型が明確になる 23 アプリ開発者は本来の機能実装に専念できる
24. HBaseからTiDBへの移行 24
25. 移行の概要 • HBaseからの移行の場合、 MySQLからの移行のような公式ツールが存在しない • 大規模なデータを高速にインポートする必要がある 25 Sparkを利用することに決定 - Hadoop InputFormatが利用可能 - JDBC Datasourceを利用できる - TiSparkは最新のTiDBのバージョンには 対応していないため利用していない HBaseのSnapshotテーブルを読むことができる TiDBへ書き込むことができる
26. HBaseからTiDBへの移行 1.初期状態 2.移行先のTiDBテーブルを作成し、ダブルライトする 3.移行元のHBaseテーブルのスナップショットを作成し、 Sparkを利用して移行先の TiDBテーブルへ書き込む 4.最終状態：ダブルライトを終了し TiDBのみに書き込む Service HBase Source Table 26
27. HBaseからTiDBへの移行 1.初期状態 2.移行先のTiDBテーブルを作成し、ダブルライトする 3.移行元のHBaseテーブルのスナップショットを作成し、 Sparkを利用して移行先の TiDBテーブルへ書き込む 4.最終状態：ダブルライトを終了し TiDBのみに書き込む HBase Source Table Service TiDB Target Table 27 - 基本的にはRDBの設計原則に従い正規化 - （クラスター化インデックスを利用する場 合）HBase同様、主キーの順序でデータを格 納するためホットスポットの発生に注意
28. HBaseからTiDBへの移行 1.初期状態 2.移行先のTiDBテーブルを作成し、ダブルライトする 3.移行元のHBaseテーブルのスナップショットを作成し、 Sparkを利用して移行先の TiDBテーブルへ書き込む 4.最終状態：ダブルライトを終了し TiDBのみに書き込む HBase Source Table Service TiDB Target Table 28 - 一貫性のために事前にダブルライトしておく - 書き込みが片方のみ失敗した場合のリトライ やエラーハンドリングを考慮する
29. HBaseからTiDBへの移行 1.初期状態 2.移行先のTiDBテーブルを作成し、ダブルライトする 3.移行元のHBaseテーブルのスナップショットを作成し、 Sparkを利用して移行先の TiDBテーブルへ書き込む 4.最終状態：ダブルライトを終了し TiDBのみに書き込む HBase Source Table TiDB Target Table HBase Snapshot Table Spark Job スナップショットを作成するのは元 のHBaseテーブルに負荷がかからな いようにするため 29 スナップショット を作成 スナップショットを読んでTiDBの テーブルへ書き込む
30. HBaseからTiDBへの移行 1.初期状態 2.移行先のTiDBテーブルを作成し、ダブルライトする 3.移行元のHBaseテーブルのスナップショットを作成し、 Sparkを利用して移行先の TiDBテーブルへ書き込む 4.最終状態：ダブルライトを終了し TiDBのみに書き込む HBase Source Table TiDB Target Table HBase Snapshot Table Spark Job スナップショット を作成 スナップショットを読んでTiDBの テーブルへ書き込む 30
31. Spark Job実装の工夫 1. Sparkのカスタムデータソースを作成 • Insert Ignoreなど特定のInsertオプションが使用できないため 2. HBaseデータのマッピング • HBaseからデータ取得時にスキーマ変換を手動で行う必要があり、時間と労力がかかる 31
32. Spark Job実装の工夫 1. Sparkのカスタムデータソースを作成 • Insert Ignoreなど特定のInsertオプションが使用できないため 2. HBaseデータのマッピング • HBaseからデータ取得時にスキーマ変換を手動で行う必要があり、時間と労力がかかる 32
33. 1 - Sparkのカスタムデータソースを作成 • 課題 - SparkのJDBC Datasourceでは、TiDBへの書き込み機能が限られている JDBC Datasourceでは、INSERT INTO t ("name", "age", "gender") VALUES (?, ?, ?)のような構文しか利用できない - データ移行時の書き込みは基本的には既にデータが書き込まれている場合は上書きせずに無視した い（Insert Ignore） - 移行時以外でもUPSERTなど様々な書き込み方式を行いたい • 解決策 カスタムデータソースの作成 Sparkの既存JDBC Datasourceをラップすることで、必要な機能を追加 33
34. Spark Job実装の工夫 1. Sparkのカスタムデータソースを作成 • Insert Ignoreなど特定のInsertオプションが使用できないため 2. HBaseデータのマッピング • HBaseからデータ取得時にスキーマ変換を手動で行う必要があり、時間と労力がかかる 34
35. 2 - HBaseデータのマッピング • 課題 - データ取得時にスキーマ変換を手動で実装する必要があり、時間と労力がかかる - HBase-Spark Connectorに似たような機能があるが今回の要件では機能不足 - Snapshotからの読み取りができない - rowkeyにソルトが先頭に付与されていたり、区切り文字で複数のキーが連結されている場合などに対応できない • 解決策 スキーママッピングツールの導入 - HBaseの物理スキーマとアプリの論理スキーマをマッピング - JSON形式でマッピング方法を記述 - 社内で利用されている様々なマッピングを柔軟に設定可能 35
36. 2 - HBaseデータのマッピング 36 { “key1”: “aaaa”, “key2”: “bbb”, “value1”: “3”, “value2”: “12” } RowKey ColumnFamily Qualifier Value aaaa,bbb f 3,12 Spark DataFrame key-value マッピング方法の定義 TiDB Target Table HBase
37. HBaseからTiDBへの移行 1.初期状態 2.移行先のTiDBテーブルを作成し、ダブルライトする 3.移行元のHBaseテーブルのスナップショットを作成し、 Sparkを利用して移行先の TiDBテーブルへ書き込む 4.最終状態：ダブルライトを終了し TiDBのみに書き込む HBase Source Table Service TiDB Target Table 37
38. 移行のまとめ •ダウンタイムなしで HBaseテーブルから TiDBへデータを移行できる • 設定や性能にもよるが 20~30GB/hourで書き込める より高速に書き込みたい場合はTiDB Lightningの物理インポートを利用するとよさそう 物理インポートはテーブルが空の場合にしか利用できないため、HBaseテーブルのスナップショット後に書かれたデータを後から入れる 必要があり大変 38
39. 移行後の状況 39
40. 移行による効果と課題 運用負荷軽減 • ノードに障害が発生し何回かダウンしているが、自動で復旧し負荷はかかっていない • Resource Groupによる管理でマルチテナントでユーザー管理ができている 利用負荷軽減 • MySQL互換であるためORMや様々な互換性のあるツールを利用可能になった • アプリ側でトランザクションやスキーマの管理が不要になり、システムが簡素化した 性能 • スループット：並列数を上げることで移行前と変わらない性能が出ている • レイテンシ：悪化したが、許容範囲内（全体で100ms以内）に収まっている • サイズが大きいデータをバッチで書き込む際にTiKVのStore Slow Scoreが上昇しアラートが発 生する 40
41. 移行による効果と課題 運用負荷軽減 • ノードに障害が発生し何回かダウンしているが、自動で復旧し負荷はかかっていない • Resource Groupによる管理でマルチテナントでユーザー管理ができている 利用負荷軽減 • MySQL互換であるためORMや様々な互換性のあるツールを利用可能になった • アプリ側でトランザクションやスキーマの管理が不要になり、システムが簡素化した 性能 • スループット：並列数を上げることで移行前と変わらない性能が出ている • レイテンシ ：悪化したが、許容範囲内（全体で 100ms以内）に収まっている • サイズが大きいデータをバッチで書き込む際にTiKVのStore Slow Scoreが上昇しアラートが発 生する 41
42. 移行前後のレイテンシの詳細 • シンプルなクエリを 実行した時のレイテ ンシ • 移行前後でリファク タリングや取得アル ゴリズムを変更して いるので厳密な比 較はできていない 42 Hbase - Read 2ms 20ms TiDB - Read 20ms Hbase - Read TiDB - Read 6ms 99%ile ~3x 🔺 99%ile ~1.7x 🔺 複数行まとめて取得するように変更した のでそのレイテンシも含まれている
43. レイテンシ悪化の原因 1. TiDBコンポーネントによるステップの増加 HBase クライアントは直接RegionServerにアクセス するため、中間ステップが少なく、レイテンシーが低い TiDB クライアントがTiDBサーバーにクエリを送信し、TiDBサーバーがPDサーバーと通信してタイムスタンプを取得し、TiKVからデータを取得す るため複数のホップが発生 2. 追加の処理によるコスト - クエリのパース、最適化、プランニング - 分散トランザクション 43 RegionServerはTiKVと同じ役割
44. 移行による効果と課題 運用負荷軽減 • ノードに障害が発生し何回かダウンしているが、自動で復旧し負荷はかかっていない • Resource Groupによる管理でマルチテナントでユーザー管理ができている 利用負荷軽減 • MySQL互換であるためORMや様々な互換性のあるツールを利用可能になった • アプリ側でトランザクションやスキーマの管理が不要になり、システムが簡素化した 性能 • スループット：並列数を上げることで移行前と変わらない性能が出ている • レイテンシ：悪化したが、許容範囲内（全体で100ms以内）に収まっている • サイズが大きいデータをバッチで書き込む際に TiKVのStore Slow Scoreが上昇しアラートが 発生する 44
45. Store Slow Scoreについて • inspect-interval 一定の間隔 (100ms) で、TiKV はRaftstoreコンポーネ ントのレイテンシーを検査 • Store Slow Scoreの判定 - inspect-intervalのタイムアウト検査の比率に基づい て、TiKV ノードが遅いかどうかを判断 - AIMDアルゴリズムでスコアを算出 - （raftstoreのスレッドのcpu使用率が40%を超えても slow nodeと判定される） • タイムアウトの原因 - RocksDBでディスク I/Oの遅延 - ネットワークの遅延 45 TiKV Raftstore概要 Raft (分散合意アルゴリズム) でデータの複製を行っている
46. RocksDBでディスクI/Oの遅延 • アラートが発生するワークロード write: 150 ops/s データサイズ：最大2MB • RocksDBではLSM-Treeが利用されている • LSM-Treeでは、大量のデータが書き込まれると コンパクションが頻発し、書き込み増幅が発生 • 書き込み増幅によりディスク I/Oの遅延が発生し ている 46 RocksDBアーキテクチャ 各レベルのストレージ容量は前のレベルの10 倍になり、閾値を超えるとコンパクションが 実行される
47. Titanの概要 • RocksDBのプラグイン • LSM-Treeからvalueを分離し、Blobファイルと して別で保存する • コンパクション時の 書き込み増幅を減少させ る • 値を分離するかどうかの閾値は min-blob-size で設定（デフォルトは 16KB） • 効果 - 値のサイズが大きい場合 (1KBより大きい)、書き 込み、更新、ポイント読み取りのシナリオで、 RocksDB よりもパフォーマンスが向上 - storageスペースと範囲クエリのパフォーマンスが 犠牲 47 - valueがmin-blob-sizeより大きけれ ばvalueを分離 - LSMにはkey-indexのペアを、Blob にはkey-valueのペアを保存 Titanアーキテクチャ 16KBではYSCBのscanワークロードでも性能劣化しない
48. Titan導入効果 • inspected durationが大幅に低下し、 Store Slow Scoreが上昇する 100msを下回るようになっ た • QPSは約30%上昇 48 Titan導入前 Titan導入後 100ms 100ms 最大でレイテンシが 90%削減 アラートが解消
49. 移行による効果と課題 運用負荷軽減 • ノードに障害が発生し何回かダウンしているが、自動で復旧し負荷はかかっていない • Resource Groupによる管理でマルチテナントでユーザー管理ができている 利用負荷軽減 • MySQL互換であるためORMや様々な互換性のあるツールを利用可能になった • アプリ側でトランザクションやスキーマの管理が不要になり、システムが簡素化した 性能 • スループット：並列数を上げることで移行前と変わらない性能が出ている • レイテンシ：悪化したが、許容範囲内（全体で100ms以内）に収まっている • サイズが大きいデータをバッチで書き込む際に TiKVのStore Slow Scoreが上昇しアラートが 発生する 49 Titan導入で解決
50. 今後の課題とまとめ 50
51. 今後の課題 •クエリエンジン（ Spark, Trinoなど）との接続 - クエリエンジンからバッチ書き込みを実施する場合は、追加の実装やチューニングが必要 - OLTPワークロードへの影響 - 次世代TiSparkで解決するかも（リプレイスされる計画がある） •大きなデータを書き込むと TiDBのメモリ制限 (tidb_mem_quota_query)に引っかかる - 上限を上げることでクエリは成功するが、根本的な解決にはならない - v8.0.0から導入されたバルクDML実行モード（実験的な機能）を利用すれば解決するかも •ベクトル探索機能の導入 - ベクトル型で格納したいという要求は多い (現状はJSON型で格納しているが非効率) - ベクトル探索機能も需要が多い 51
52. まとめ • HBaseからTiDBへの移行は可能 移行ツールは存在しないので工夫する必要がある • TiDBに移行することで HBaseが抱えている様々な課題を解決できる • サイズが大きいデータを大量に書き込む場合は Titanがおすすめ 52