🫠
TiDB User Day 2024 に参加なぅ
今年も TiDB User Day に参加しています！
とりあえずライブブログ頑張るｗ
hashtag: #TiUD2024
全体さくっと
- PingCAPのTiDBは、高スケーラビリティとAI活用が評価され、成長中。
- LinkedInは、TiDBのスケーリングとオペレーションで課題と改善点を発見。
- Pinterestは、HBaseからTiDBに移行し、パフォーマンス向上と運用効率を実現。
- レバテックは、リソース・管理効率向上とゼロダウンタイムを目指しTiDBに移行。
- サイバーエージェントは、旧データ基盤からTiDBを含む新基盤へ移行し、運用負荷を軽減。
- Voicyは、TiDB Cloud導入でコスト削減と運用効率を向上させた。
- Orbは、ETL障害と遅延解消のため、CassandraとMySQLからTiDBに移行。
- DMMは、クラウド化とGo書き直しを機にTiDB Cloudを採用し、運用効率を改善。
- 各企業は、TiDBの高スケーラビリティ、クラウドネイティブ対応、MySQL互換を評価。
- 課題として、学習コスト、監視ツールの限界、オートスケーリングとマルチテナント運用の改善が必要。
ご挨拶
PingCAP株式会社
代表取締役社長 Eric Han
- dbtech showcase 2024 使用したい Database No.1
- サービス
- Fintech
- Game
- インターネットサービスなどなど広がっている
- 事例紹介
- 心の絆創膏
- ゲートキーパー研修
- なごや食育広場
- TiDB Serverless と Docker を組み合わせて事例化
- サポートサービスも無償提供で行っている
- イオングループ TiDB 導入に向けての共同検証開始を共同発表
- 国内パートナーリレーション
- クラスメソッド株式会社とアイレット株式会社とパートナー契約を締結
- 日本に根ざして技術普及活動
- 日本語ドキュメントの整備
- 公式トレーニングの提供
- 認定プログラム
- ２日間オンサイトワークショップ
- コミュニティの始動
-
dbtech showcase 2024
- PingCap 関連セッション多数
- スケーラビリティの再定義：TiDBで実現するサービスプラットフォーム
- 【TIS】止められない決済システムを支える技術として TiDB はふさわしいのか？
- 【ELESTYLE】キャッシュレス決済SaaSがAurora MySQLからNewSQLデータベース「TiDB」に移行した背景と運用
- 【SBペイメントサービス】TiDBで私達は幸せになれたのか? ~止められない決済システムにTiDB Cloudを導入した理由~
- PingCap 関連セッション多数
まとめ
- PingCAP株式会社は、Fintech、ゲーム、インターネットサービスなどで使用されるデータベース「TiDB」を提供。
- クラスメソッド株式会社やアイレット株式会社とパートナー契約を締結。
- 事例紹介：心の絆創膏、なごや食育広場（TiDB ServerlessとDockerの事例化）。
- 日本語ドキュメントの整備、公式トレーニングの提供、コミュニティの始動で技術普及活動を推進。
- dbtech showcase 2024では、TiDB関連のセッションが多数開催。
Beyond the Scalability：PingCAP is dedicated to building TiDB, an Open Source, Cloud Native, distributed, MySQL compatible database [同時通訳]
PingCAP (USA) Inc.
共同創業者 兼 CEO Max Liu
- 9年前
- 参加者3名だった
- TIDB の最初のバージョン
- ラズパイで動かした
- かっこいいから
- TiDB がどこでも動くことを確認したかった
- ラズパイで動かした
- 現在
- ガートナーの調査結果によると最も急成長を挙げた会社になった
- Managed Cloud Clusters: 37,820+
- 成長率: 230%
- マイルストーン
- データボリューム: 1.2PB / 単一クラスタ (FinTech)
- Cloud Single Customer
- 14,600 vCPU (Gaming)
- Throughput
- 2.3MBps
- ガートナーの調査結果によると最も急成長を挙げた会社になった
- Why TiDB?
- Scalability
- 非常に複雑な定義を持つ
- データ量
- PB データ
- スループット (Read)
- 数百万QPS
- Connections
- 数百万のコネクションを扱えるようになる必要がある
- データ量
- その先は？
- 大規模なビジネス、大量の顧客を抱えている
- SaaS だとテナント使っているとかそれをシングルとして扱えるようになる
- システムとして数百万のスキーマやテーブルに対応しなければならない
- 従来型の DB ではそのように設計されていないから難しい部分がある
- Database の種類はたくさんあるが常に最適なクエリプランを提供することは非常に難しい
- INDEX ルールを付ける (Force INDEX)
- 毎回設定してたらそれは難しい
- TiDB は universal bind コマンドを提供することでクエリプランをスケーラブルに解決できる
- INDEX ルールを付ける (Force INDEX)
- SaaS 提供者だったと仮定したら
- 大量のバッチ処理が発生する
- 分散した形でバッチ処理を行いたい
- Server の数を増やしてスケーラブルを確保
- 分散した形でバッチ処理を行いたい
- Backup / Restore
- スケーラビリティの観点からも必要不可欠
- PB 級の Backup / Restore にかかる時間
- ビジネスのボトムラインであり、必要不可欠なものだから短期間で行えなければならない
- TiDB は分散型の仕組みを提供しているため、サーバを増やせば増やすだけ早くなる
- Dashboard
- リアルタイムダッシュボードの必要性
- Row Format と Analysis Format を気にせず見れる
- リアルタイムダッシュボードの必要性
- Cloud
- AWS, Google Cloud は提供している
- Azure を今年度中に提供予定
- 大量のバッチ処理が発生する
- Scalability の第一原則
- あらゆるものがスケールしていく
- が、不変なものもある
-
コードを変えず、０から多数に変えることができる
- コードを変えなくても拡大できることが重要
- Database だけで実現することは難しいが 9年間かけてこれを実現している
- まだ道半ばのものもある
-
コードを変えず、０から多数に変えることができる
- 非常に複雑な定義を持つ
- Scalability
-
TiDB の AI 活用
- Vector-Search に対応
- TiDB Serverless はさまざまなモデルに適用できる
- これはまだ First Step
- TiDB を使わなければ
- APP (example)
- Write →Vector Store
- → Chat Store
- Query → Vector Store
- → Chat Store
- Data Sync → Vectore Store
- → Chat Store
- Write →Vector Store
- APP (example)
- TiDB を使えば
- APP
- Write → TiDB
- Query → TiDB
- 超シンプルになる
- APP
- TiDB を使わなければ
- TiDB Future APP Hackathon
- Vector-Search に対応
まとめ
- 9年前、参加者3名でTiDBの最初のバージョンをラズパイで動かす。
- 現在、ガートナー調査で最も急成長した会社、Managed Cloud Clusters: 37,820+、成長率: 230%。
- データボリューム1.2PB/クラスタ、Cloud Single Customer: 14,600 vCPU、Throughput: 2.3MBps。
- TiDBは高いスケーラビリティを持ち、大規模なビジネスや大量のデータ、コネクションに対応。
- AI活用のVector-Search対応、シンプルなAPP構造実現、TiDB Future APP Hackathon開催。
Learnings from Experimenting with TiDB at Scale [同時通訳]
LinkedIn Corporation
SW Engineering Director Ashish Singhai 氏
-
PingCap とは 1年以上にわたって一緒にやってきた
- LinkedIn
- 2024年 1月時点で
- PeakTime: 2.55M req/sec
- 45T Kafka messages sent/ day
- 100PB のデータ
- Datalake hosts Exabytes of Data
- Multiple, geo-distributed data centers
- hundreds of thousands of servers
- 2024年 1月時点で
- LinkedIn
-
さまざまな調査を行ってきた
- 大規模なデータセットのロードとクエリ
- 500万 QPS、5PB データ
- 個別にスケールしなければならない
- Routine
- クラスタをスケールさせるためにはリージョンを超える必要がある
- 高速なバルクロード
- 全てがパフォーマンスに影響を与えないことが大事
-
継続したオペレーション
- 50万を超えるサーバがあった場合
- ハード故障が起こったとしたら
- ファームアップデートがあったら
- データ破損や欠損があってはならない
- 計画メンテがユーザーに伝えられることなく実行されなければならない
- 一部が失敗する可能性はあるかもしれないが全体に影響をしてはいけない
- 50万を超えるサーバがあった場合
-
Cluster Scaling
- 現在のクラスタのスケーリングボトルネックは PD だと考えている
- クラスタのハートビート
- リージョンを超えたハートビート
- TSO の生成
- クラスタのハートビート
- TSO 生成
- TimeStamp Oracle
- 20万 QPS が最大だった
- PD への限界だったのでそこは問題ではないかもしれない
- TSO のバッチ量はタイミング等によっても変わってくる
- TSO Request QPS
- いくつか実行した
- 10万リクエスト
- latency や CPU の使用率は順調
- 20万リクエスト
- latency は遅くなりCPU の使用率は高め水位
- 10万リクエスト
- いくつか実行した
- Lock Contention がヒントを与えてくれた
- スケールアップ
- もっとパワフルなマシンを使えば QPS 改善できた
- TSO Follower PD Proxy
- TSO Batch Max Waite Time
- 待てばいいｗ
- 今後への期待
- PD のワークロードを分離するマイクロサービス化が改善につながることを期待している
- スケールアップ
- リージョンハートビート
- 実験によると 1000万 / 分 ハートビートまでは処理できた
- Lock 競合がボトルネックになっている
- 1000万 / 分 を超えられない
- 対策
- リソースを増やす
- リージョンサイズを増やしてリージョンの数を減らす
- ハートビートの間隔を増やす
- リージョンの Hibernation を有効にする
- あまり使ってないところに対して実行
- 10% , 20% くらい改善することが見えている
- あまり使ってないところに対して実行
- Golang のパフォーマンス
- Bulk Load
- マルチテナントで新しいデータセットが常に入ってきている状態
- SLA として 24時間以内に有効化することを挙げている
- 数十億のデータセットがある
- 既存に対しても再処理がされる必要がある
- アプローチ
- SQL ステートメント
- バッチステートメント
- latency が1.6倍 上がってしまった
- フィジカルモードでやってみた
- 早くなったが latency がかなり上がった
- ビジネスに影響を与えてしまった
- 256000QPS 、2 ~ 2.5 倍の影響
- 100TB 単位のデータに対応できるようになることが必要となるが解決はしていない
- クラスタを別に構築し、レプリケーション
- 現在検証中
- async replication
- Active-Active のデータセンターがある
- 世界中にある
- 複数のリージョンに同じデータが入っていく
- データセンター間の Latency が高くなってしまうので非同期レプリケーションを実施
- 同じ列が同時にアップデートされる可能性はある
- その場合にはコンフリクトしてしまう
- 一貫性を一部妥協している
- Last Writer Wins としている
- クライアントのデータセットを一つのデータリージョンに置くことでユーザーエクスペリエンスを担保
- 重要なのは優れたユーザーエクスペリエンス
- TiCDC
- オペレーション
- 最大スループット
- Lag build up
- 数秒単位に抑えたい
- Stalls
- ユーザー体験的にいくつか課題がある
- メタデータがユーザーに見えてしまう
- カスタムクライアントがないとメンテナンスができない
- スキーマが必要となる
- オペレーション
- Active-Active のデータセンターがある
- スケーラビリティとオペラビリティ
- メンテナンス
- レプリケーションの数を変える、リージョンサイズを変更する
- 異なるタイプの SKU
- いくつかのマシンが障害を起こして他のマシンに置き換えたらパフォーマンスの問題が出てしまった
- 一つのマシンによって50万台のサーバがスローダウンしてしまった
- Rebalancing
- すごくいいが、頻度は低い方がいい、さらにコントロールできる方がいい
- マルチテナンシー
- まだやってない
- もしかしたら次にはこの話ができるかも
- まだやってない
- トラブルシューティング
- システムをマネージするために多くの人が必要という状態は避けたい
- 自動化と簡略化をしていきたい
- ファッションではなく不可欠なもの
- どのようにトラブルシューティングするのか、まだ学んでいる途上
- リージョンの不均衡
- Heuristics がアップデートできてなかったり
- リバランス中
- 自動化と簡略化をしていきたい
- システムをマネージするために多くの人が必要という状態は避けたい
- こういったところに関心があるということを言いたい
- メンテナンス
- 20万 QPS が最大だった
- TimeStamp Oracle
まとめ
- PingCapと1年以上協力、LinkedInでピーク2.55M req/sec、45T Kafkaメッセージ/日、100PBのデータを扱う。
- 大規模データセットのロードとクエリ、500万QPS、5PBデータを個別にスケール。
- 継続オペレーションで50万以上のサーバ管理、ハード故障やファームアップデートに対応。
- クラスタスケーリングのボトルネックをPDと考え、TSO生成やリージョンハートビートを改善中。
- TiDBのスケーラビリティ、メンテナンスの自動化と簡略化に注力、マルチテナンシーやトラブルシューティングを継続して関心を持って取り組んでいる
- 現在のクラスタのスケーリングボトルネックは PD だと考えている
How Pinterest Leverages TiDB to Deprecate HBase [同時通訳]
Ex-Pinterest, Inc.
VP Data Engineering Dr. Dave Burgess 氏
- 脱 HBase にTiDB を採用している
- Pinterest について
- 月5億人以上、30億ドルを超える収益
- 検索、画像、フィード、買い物、広告システム
- Data Engineering
- 地球規模のデータプラットフォームを活用している
- システムは信頼性の高いものでなければならない
- 効率よくできなければならい
- 6億5千万ドルクラウドインフラにかけている
- ML Platform
- 4億くらいのインスタンス
- ビックデータプラットフォーム
- 8000万イベント / sec
- エクサデータ級のデータ量
- オンラインシステム
- KVS
- 数十億のユーザーに対して低 Latency で提供
- KVS
- Storage & Caching
- ここを一部 TiDB に移行
- 99.99% の SLO
- オンラインシステムの進化
- 2012 年
- 当初は MySQL を利用
- 現在も使用中
- 当初は MySQL を利用
- 2013 年
- HBase
- Columnar Store
- HBase
- 2015 年
- RocksDB
- KV Store, ML Serving
- RocksDB
- 2017 年
- HBase + Middleware
- 2021 年
- Distributed SQLNeeds
- HBase → TiDB
- 2012 年
- HBase at Pinterest
- 50 クラスタ
- 10PB 以上のデータ
- 100000000以上 / sec
- HBase Ecosystem
- Zen: グラフサービス
- カラムナーストアー
- トランザクショナルデータベース
- セカンダリインデクス
- データ量が大きすぎたので CDC を使って Kafka に送って Consumer に送ることで一貫性をなんとか担保
- 課題もあった
- さまざまなユースケースがあった
- 基本機能は HBase で処理していた
- 月5億人以上、30億ドルを超える収益
- Key Challenges
- 機能上の制約
- 一貫性を強化したい
- セカンダリインデクス
- データの不整合
- 自動的に解決する仕組みを導入したが、難しかった
- トランザクションをサポートしていないため
- メンテナンスコストの増加
- 古いバージョンからのアップデート
- 大量のアラート
- インフラコスト
- ＄10M
- Zen
- インハウスグラフサービス
- node/edge CRUD
- index : unique / non-unique / edge query / edge local indexes
- 課題
- 多くのバグ
- クエリサポートの制限
- 複雑なクエリに対応できない
- インハウスグラフサービス
- Ixia
- セカンダリインデクスの機能
- HBase + Muse (Index Engine)
- CDC async index
- ここでも課題はたくさんあった
- セカンダリインデクスの機能
- 新しいソリューションを検討
- 要求
- 分散トランザクション
- 強力な一貫性
- NoSQL にスケールできること
- さまざまなクエリとの互換性
- 15以上のシステムを検証
- オペレーション上の負荷
- マイグレーションコスト
- 言語
- コミュニティのサポート
- コスト
- 最終的な候補
- YugaByteDB
- CockroachDB
- TiDB
- 結果
- 要求
- 機能上の制約
- Why TiDB
- TiDB
- 複雑性を大幅に改善できることができた
- 一貫性も担保
- 3〜5倍のパフォーマンス向上
- インフラコストの削減
- オペレーションのオーバーヘッドも削減できた
- グラフ DB 含めいくつかの機能は TiDB 上で構築した
- 強力な整合性
- 結果生合成を達成できた
- 開発の速度も上がった
- 本番環境の運用がシンプルになった
- バージョンアップ
- 1年くらいかかっていたが 1日、2日でできるようになった
- アラートが実質0になった
- バージョンアップ
- 99.999% データ生合成を達成できた
- 4TB データ移行を 9時間でできた
- 照合に 8時間かかったので実質1日程度
- サポートもバッチリ
- MySQL 互換性
- データセット感のトランザクション保証
- 分析プロセスも可能になった (HTAP)
- マルチリージョンの展開
- オンラインスキーマ変更
- 負荷ベースを分割できる
- 分析とオンライントランザクションの共存
- オープンソースコミュニティ
- TiDB
- Key Takeaways
- 脱 HBase
- かなり減らすことができた
- 今後のビジョン
- 一つのストレージで全部を対応できるわけではない
- オンラインストレージリクエスト
- KVS
- Rockstore
- SDS (Structed Data storage)
- TiDB
- MySQL
- KVS
- オンラインストレージリクエスト
- あらゆるケースに一つのソリューションではない
- それぞれにメリットがある
- 適したところに適したストレージを適用していく
- それぞれにメリットがある
- 一つのストレージで全部を対応できるわけではない
- TiDB の上に新たな API を構築していく
- 脱 HBase
まとめ
- PingCapはHBaseからTiDBへの移行をサポート。
- Pinterestのデータエンジニアリングでは、TiDBを一部ストレージ＆キャッシングに採用し、99.99%のSLOを実現。
- 主要な課題は、一貫性、セカンダリインデックス、メンテナンスコスト、インフラコスト（$10M）など。
- TiDB採用の理由は、3〜5倍のパフォーマンス向上、一貫性確保、インフラコスト削減、オペレーションの簡略化。
- 将来的には、TiDB上に新たなAPIを構築し、オンラインストレージリクエストやデータベースの柔軟な使用を目指す。
TiDBは銀の弾丸になるのか？ ~ レバテックの課題と新たな挑戦 ~
レバテック株式会社
CTO室 テックリード 河村 勇樹 氏
レバレジーズ株式会社
レバテック開発部 中下 拓也 氏
- 資料
- TiDB に移行を決めた背景
- リソース・管理効率の向上
- マイクロサービス化で80人の開発組織に対して50くらいのインスタンス数
- SRE が工数とコストに追われてしまった
- DB 運用に SRE の工数が奪われる状態
- クラスタごとに最適なスペック調整
- 可溶性には限界がある
- ゼロダウンタイムは難しい
- メンテナンス調整コスト
- 開発者体験の低下
- (余談) 止められないサービスではない
- ができる限りサービスやユーザーに影響が起きないようにメンテナンスすべき
- 努力目標としてメンテナンスはできる限り発生しない状態にしたい
- (余談) 止められないサービスではない
- 2024 年は Aurora MySQL のサポート期限が切れる
- 選定ポイント
- MySQL互換
- ゼロダウンタイムの実現
- オンラインスケールアウトイン
- ダウンタイムが基本的には発生しない
- クラスタ一元管理化、リソース・管理効率を向上
- 可用性向上、DDL もオンライン反映
- ここまでのまとめ
- DB に関連した課題解決チャンス到来
- リソース管理効率
- メンテナンス弊害
- サポート切れ
- TiDB で課題解決に挑戦
- クラスタの一元管理
- ゼロダウンタイムの実現
- DB に関連した課題解決チャンス到来
- リソース・管理効率の向上
- PoC の概要とつまづいたこと
- 移行検証
- MySQL 互換テスト
- アプリケーション動作テスト
- SQL パフォーマンステスト
- ツール連携
- 機能検証
- 可用性の確認
- リソースコントロール検証
- その他
- AWS, Google Cloud とのコスト比較
- つまづいたこと
- 期待していたパフォーマンスが出なかった
- クエリ比較
- 実行される頻度の高いクエリ
- ほぼ Aurora と同じくらいの速度か速いくらいだった
- 実行速度が遅いクエリ
- Aurora ではちゃんと返ってきた
- TiDB だと計測不能
- 実行される頻度の高いクエリ
- テーブルフルスキャンの発生頻度が多かった
- Like 検索を使っていた
- TiDB がそこに弱い？
- Aurora だとインメモリキャッシュだからかも？
- TiDB でなんとかならない？
- クエリ比較
- 対応
- スペックを上げてみる
- 効果なし
- TiFlash を導入
- 大幅な改善
- 2.8s → 160ms
- 大幅な改善
- スペックを上げてみる
- 期待していたパフォーマンスが出なかった
- アプリケーションでの動作検証
- いくつか動かないものもあった
- サブクエリの中で別のテーブルを呼び出すことができなかった
- TiDB バージョンアップ時の可用性検証
- アップデートの実施を行いながらアプリケーション動作を並行して実施
- エラーやきになる遅延は発生しなかった
- アップデートの実施を行いながらアプリケーション動作を並行して実施
- データ移行
- binlog format = MIXED
- DMS で CDC データ移行ができなかった
- ダウンタイムは最小6時間
- binlog format を ROW に変更
- DMS でできるようにした
- ダウンタイムは最小 15分
- TiDB にもマイグレーション機能の提供はある
- マイクロサービスだったためいくつかのスキーマで競合が発生してしまったため DMS を採用
- binlog format = MIXED
- 工夫したこと
- Resource Control 作成の自動化
- DB User の作成
- リソースグループの作成
- 開発環境の定期起動停止の自動化
- 開発環境のコストが半分くらいまで抑えられた
- phpmyadmin で DB アクセスする環境の統一
- Chat2Query は現状ユーザー単位で制限負荷
- 統制観点から個別にアクセスさせない
- Resource Control 作成の自動化
- TiDB Serverless の活用
- 社内ツール
- Four Keys の可視化
- Wordpress
- Collation が違ったため、変更する必要があった
- 関数が利用できなかったので SET GLOBAL tidb_enable_noop_functions を true にする必要があった
- コスト上限は多めに設定しつつ徐々に最適化予定
- 小規模や新規プロダクトには良さそう
- 初回の応答速度が速い
- 無料枠やコストの上限設定
- 社内ツール
- いくつか動かないものもあった
- 今後
- 2024年
- 2月くらいから PoC
- 6月移行順次移行中
- 10月のサポート期限切れまでになんとか対応したい
- TiFlash の活用
- 分析基盤としての TiDB
- 現在は BigQuery を利用中
- データ連携が不要になる
- Aurora → BigQuery
- 連携に Fivetran を利用
- 懸念
- Google スプレッドシートとの連携
- データ加工レイヤーをどうするか
- 分析基盤としての TiDB
- ベクトル検索
- 現在
- Public Beta
- Serverless のみ
- 検討
- 案件検索などの検索UX向上
- 検索パフォーマンスの向上
- Amazon Bedrock を活用していく
- 現在
- 2024年
- TiDB への移行を決めた3つのポイント
- リソース・管理効率の向上
- DBの可用性向上
- 2024年はDBを載せ替えるチャンス
- TiDB への移行はそう簡単ではない
- パフォーマンスも場合によっては低下
- 今まで利用していたMySQLクエリが使えないこともある
- binlog_format を変更したり準備が必要
- 移行検証
まとめ
- TiDB移行の背景：リソース・管理効率向上、SRE工数削減、クラスタ一元管理、ゼロダウンタイム、MySQL互換。
- PoCの課題：パフォーマンス不足、テーブルフルスキャン多発、TiFlash導入で解決、一部アプリの動作問題。
- データ移行：binlog形式変更でダウンタイム短縮。
- 工夫と改善：Resource Control自動化、開発環境コスト削減、phpmyadminでDBアクセス統一、TiDB Serverless活用。
- 今後の展望：2024年2月からPoC開始、10月サポート期限までに移行完了目標。
大規模データ処理基盤におけるHBaseからTiDBへの移行事例
株式会社サイバーエージェント
グループIT推進本部 データプロダクトユニット 渡邉 敬之 氏
- 大規模データ基盤の刷新
- 旧データ基盤 Patriot
- 新データ基盤
- BigQuery + Snowflake + Spark
- TiDB (← HBase からの移行)
- プライベートクラウドと k8s
- Cycloud
- サイバーエージェントのプライベートクラウド
- k8s クラスタ
- Cycloud内で動いている
- Cycloud
- 課題
- HBase
- Wide Column NoSQL Database の一種
- TiKV は HBase を元に開発されたためアーキテクチャがにている
- 運用負荷
- 設定やチューニングが複雑
- 人材が少ない
- 長時間ダウンタイムが発生
- アクセス制御やリソース使用量の計測と費用按分が困難
- クラウドネイティブへの適用
- VM管理とデータベース管理の負担が大きい
- 環境の変化に柔軟に対応できない
- 開発効率性
- アプリ側でスキーマ管理やトランザクションを意識する必要がある
- 主に Java クライアントが公式にサポートされており、他の言語向けクライアントではサポートや機能が限定的
- HBase
- TiDB 選定理由
- HBase と同等の性能を提供できる
- スケーラビリティ
- レイテンシー
- HBase の課題を解決できる
- クラウドネイティブへの適用
- TiDB Operator により k8s クラスタへ簡単にデプロイ可能
- 提供される Custom Resource
- 構築
- TiDB Cluster
- TiDB Initializer
- 監視
- TiDB Dashboard
- TiDB Monitor/ NGMonitoring
- backup
- Backup Schedule
- Restore
- 構築
- 運用負荷の軽減
- 可観測性の低さ
- 利用者向けのハイレベルなダッシュボード
- 運用者向けの細かい Grafana ダッシュボードやプロファイリング
- 耐障害性
- ノードダウンした時の影響
- 多少のサービス影響はあるが概ね許容範囲
- HBase よりも運用負担が軽くダウンタイムも少ない
- ノードダウンした時の影響
- ユーザー管理機能
- 強力で柔軟なセキュリティとアクセス制御
- 特定のユーザーがリソースを使いすぎることを防止できる
- ユーザーごとの LateLimitや優先度
- 暴走クエリを検知、KILL など
- 費用請求が容易
- ユーザーごとに使用したリソース量を把握できる
- 開発効率性
- ユーザー側の実装負荷が低い
- MySQL 互換
- 複雑なクエリの実行
- TiFlash の利用で分析クエリもできる
- データ一貫性
- スキーマがあることでデータの意味がわかる
- ユーザー側の実装負荷が低い
- 可観測性の低さ
- クラウドネイティブへの適用
- HBase と同等の性能を提供できる
- 移行方法
- HBase からの移行の場合公式ツールが存在しない
- 大規模なデータを高速にインポートする必要がある
- Spark を利用することに決定
- Hadoop InputFormat が利用可能
- JDBC Datasource を利用可能
- Spark を利用することに決定
- 初期状態
- 移行先の TiDB テーブルを作成し、ダブルライトする
- 移行元のHBase テーブルのスナップショットを作成し、Spark を利用して移行先の TiDB テーブルへの書き込み
- ダブルライトを修了し、TiDB のみに書き込む
- Spark Job の工夫
- カスタムデータソースを作成
- TiDB への書き込み機能が限定されている
- データ移行時の書き込みは基本的に上書きせずに無視する
- 移行時以外でも UPSERT など
- HBase データのマッピング
- 課題
- スキーマ変換を手動で実装する必要がある
- 解決策
- マップングツールの導入
- JSON 形式でマッピング方法を記述
- マップングツールの導入
- 課題
- カスタムデータソースを作成
- ダウンタイムなしで TiDB に移行できた
- 設定や性能にもよるが、20~30GB/h で書き込める
- より高速に書き込みたい場合は TiDB Lightning を使うことも考えられる
- 効果と課題
- 運用負荷軽減⚪︎
- 利用負荷軽減⚪︎
- 性能
- 以前と変わらない性能が出ている⚪︎
- レイテンシーは多少悪化したが許容範囲内△
- TiDB コンポーネントによるステップの増加
- HBase は直接 RegionServer にアクセスする
- TiDB コンポーネントによるステップの増加
- サイズの大きいデータをバッチで書き込む場合にアラートが発生
- Store Slow Store
- Raft でデータの複製を行っている
- 原因
- RocksDB でディスクI/O の遅延
- write: 150 ops/s
- LSM-Tree が利用されている
- 大量のデータが書き込まれるとコンパクションが頻発し、書き込み増幅が発生
- 書き込み増幅によりディスク I/O の遅延が発生
- Titan を導入で解決
- ネットワーク遅延
- RocksDB でディスクI/O の遅延
- Store Slow Store
- 課題
- クエリエンジンとの接続
- 大きなデータを書き込むと TiDB のメモリ制限に引っかかる
- 上限を上げることでクエリは成功するが、根本的な解決にはならない
- バルク DML 実行モードを利用すれば解決するかも？
- ベクトル探索機能の導入
まとめ
- 旧データ基盤Patriotから、新基盤BigQuery、Snowflake、Spark、TiDBに刷新。
- Cycloud内でk8sクラスタを稼働、プライベートクラウドを活用。
- HBaseの運用負荷やクラウドネイティブ適用の課題をTiDBで解決。
- 移行はSparkを利用し、ダウンタイムなしで成功。
- 運用負荷軽減、性能維持、レイテンシー許容範囲内、書き込み時のディスクI/O遅延は Titan を使って解決。
音声プラットフォームVoicyがTiDB Cloudを本番運用してみた結果
株式会社 Voicy
エンジニアDivision エンジニア部門責任者 山元 亮典 氏
- 資料
- パンチライン
- TiDB Cloud 導入でコスト、運用、ブランディングでメリットがあった
- ただし、銀の弾丸ではなくメリットを出し切る覚悟と地道な取り組みが必要
- 移行対象
- Aurora からの移行
- 特徴
- Read Heavy
- トラフィックの読みづらさ
- MySQL 互換
- 規模
- 数千 QPS
- 1TB 未満
- 特徴
- Aurora からの移行
- 移行までの道のり
- 2023-01
- 初回打ち合わせ
- 2023-03
- PoC 開始
- 品川さんから突然の DM
- からの
- コスト削減 & 副次的な効果を見込んで
- DB コスト削減
- 書き込み負荷のスケール
- 運用容易性
- HTAP サービスの相性の良さ
- 業界の事例を作りブランディング
- スコープを絞って最低限確認
- Must 要件
- ⚪︎コスト
- ⚪︎パフォーマンス
- ⭐️ポータビリティ
- Should 要件
- ⚪︎運用や機能面で必要な項目、満たさない場合は代替案の検討
- MySQL との設定の差、運用機能の存在、外部サービス連携等 Voicy での運用観点における事項を30項目程度洗い出して評価
- Node のオートスケールや時間指定のスケールがないところがもうちょっと
- ⚪︎運用や機能面で必要な項目、満たさない場合は代替案の検討
- Must 要件
- PoC 開始
- 2023-06
- 移行意思決定
- サポートの手厚さから「本気度」が伝わった
-
TiDBチューニング手法の透明性が高かったので限界とポテンシャルを知ることもできた
- パフォーマンス問題も工夫で乗り切れると感じた
- チューニング専門チームができたと錯覚するくらいコミットしてくれた
- 社内にもいいナレッジを伝搬できると感じた
-
TiDBチューニング手法の透明性が高かったので限界とポテンシャルを知ることもできた
- サポートの手厚さから「本気度」が伝わった
- 移行意思決定
- 2024-04
- 移行完了、運用開始
- 設計
- Aurora (旧DB) → (TiDB Data Migration) → TiDB → (TiDB Cloud Change Feed) → Aurora (Backup DB, ロールバック用)
- Read 処理を少しずつ TiDB に向けて DB チューニング
- メンテナンスタイムを設けて Write / Read 処理を全て移行
- TiDB への一本化
- Aurora (旧DB) → (TiDB Data Migration) → TiDB → (TiDB Cloud Change Feed) → Aurora (Backup DB, ロールバック用)
- 設計のポイント
- 移行時のリードタイムを重要視
- メンテナンスタイムを許容
- API から2つの DB に書き込む Dual Write 形式を実装すればゼロダウンタイム移行も可能だったが工数的に断念
- 本番ワークロード再現した負荷試験は実施しなかった
- 本番にリリースしてみるスタンス
- Read はカナリアリリース
- Write はバックアップ DB でのロールバック手段を準備してリスクコントロール
- メンテナンスタイムを許容
- 移行時のリードタイムを重要視
- 移行時の障害
- Read 負荷の高い API を TiDB にリリース時、負荷がかかりサービスダウン
- チューニングとクラスタのスケールアウト・スケールアップで解決
- 長時間ジョブ稼働中に遅延発生
- 一度旧DBにロールバック後、DMジョブ実行から移行完了までの期間を短縮
- Read 負荷の高い API を TiDB にリリース時、負荷がかかりサービスダウン
- 移行完了
- 設計
- 移行完了、運用開始
- 運用
- チューニングによりコスト安定もしてきてさまざまなメリット
- コスト
- サービスイン時は強いクラスタ構成でリリースをしてパフォーマンスチューニングやクラスタ構成の最適化を実施
- 目標コスト達成見込み
- サービスイン時は強いクラスタ構成でリリースをしてパフォーマンスチューニングやクラスタ構成の最適化を実施
- 運用
- AWS から TiDB Cloud に変更したことで困ることは今のところはない
- 今のところメリットの方が多い
- AWS から TiDB Cloud に変更したことで困ることは今のところはない
- ブランディング
- モダンな技術を取り入れると一定の注目を得られる
- コスト
- チューニングによりコスト安定もしてきてさまざまなメリット
- 2023-01
- 100点満点の DB は存在しないが 100点に近づけるポテンシャルとサポートが TiDB および PingCap にはある
まとめ
- パンチライン: TiDB Cloud導入でコスト、運用、ブランディングのメリット。ただし、効果を最大限にするには地道な取り組みが必要。
- 移行対象: Auroraからの移行、Read Heavy、MySQL互換、数千QPS、1TB未満。
- 移行の道のり: 2023年1月に初回打ち合わせ、3月にPoC開始、6月に移行決定、2024年4月に移行完了。
- 設計と移行: AuroraからTiDBへの移行、Read処理を徐々にTiDBにシフト、Write処理を全移行、障害発生時にチューニングとスケールアウトで解決。
- 運用: チューニングによりコスト安定、AWSからTiDB Cloudに変更、モダン技術の採用で注目度向上
デジタル通貨に特化した独自分散台帳技術Orb DLTの高度化：CassandraからTiDBへの移行
株式会社Orb
CTO 岸本 吉勝 氏
- サービスの課題
- MySQL 5 → 8系へ移行検討
- JSON 関連の問題で移行が難しいと判断し別DB検討
- 4つの ETLコンポーネントによる障害点の多さ
- ETL 起因の MySQL への反映遅延
- 現在
- MySQL + ETL
- 未来
- TiDB + TiFlash (OLTP + OLAP)
- 外せない要件
- トランザクションを安全かつ高並列に実行可能
- 分散アーキテクチャによる高トランザクション性能
- 非中央管理型
- NewSQL がもつ構成合成、オンラインでのスケーラビリティ
- 可用性
- 分析性能の維持・向上
- トランザクションを安全かつ高並列に実行可能
- MySQL 5 → 8系へ移行検討
- データ移行
- あるお客様の総レコード数
- Cassandra 2億
- MySQL 4億
- 課題
- サービスの停止時間を短くする
- Cassandra への影響と性能
- 全権データ取得前提のアーキテクチャではない
- 取得中の既存サービスへの影響
- データ構造の違い
- NoSQL→ NewSQL へ
- 設計と流れ
- 同期・移行時にデータ構造を変換
- 新規データ。更新データ
- Dual Write 方式
- MySQL に入れると同時に Kafka に入れて TiDB に同期
- Dual Write 方式
- 既存データ
- スナップショットから同期
- 変換ロジックを書いて実施
- スナップショットから同期
- まだ同期されていない既存データに対する更新
- 対象レコードの updated_at やバージョン情報を確認し、既存データよりも新しければスキップすることで整合性を担保
- 同期が取れているか確認
- TiDB と MySQL, Cassandra 間
- Snapshot から起こして1行単位で確認するようなスクリプトを組んだ
- TiDB と MySQL, Cassandra 間
- 移行検証で見つかった課題
- Migration Script で 2000qps Insert したら性能劣化
- レコードサイズがでかいことが原因
- 500qps に落として対応
- ディスクサイズは １ノードあたり4TB 制限がある
- Migration Script で 2000qps Insert したら性能劣化
- 期間
- 移行開始まで2ヶ月
- 移行可能状態になるまで 10日
- Migration Script 6日
- Check Script 4日
- 切り替え作業 3時間
- 移行データのレコード数 6億
- あるお客様の総レコード数
- 期待通りと期待と違ったこと
- 当初の課題は解決できた
- ETL が排除でき遅延もなくなった
- トランザクション分析性能
- 基本的には想定通りの性能
- INDEX が適切なら TiFlash は選択されないことが多い
- オンラインスケール・バージョンアップ
- サービスに影響せずに実施できた
- リソース逼迫が TiDB 全体に影響し性能劣化が起こる
- 移行検証時でかいデータのINSERTが影響することは確認していた
- リリース後、重いSELECTクエリがアクセス集中によりスパイク
- TiKV の CPU/Memory が逼迫
- 読み取りだけじゃなく書き込みも影響
- 一気に20秒程度落ちた
- 当初の課題は解決できた
- TiFlash Tips
- TiFlash は大量データ・重いクエリを素早く検索してくれる
- 逆に軽いクエリを大量に捌くのは苦手
- TiDB Optimizer が TiKV と TiFlash の判断をするが、TiFlash よりも TiKV の方がパフォーマンスがいいことがある
- ヒントをつけることで選択可能
- クエリの自由度が求められるサービスならリリース付近だけでも TiFlash を設置し、様子見すると保険になる
- 検証しなくても TiFlash がなんとかしてくれる可能性がある
- TiFlash は大量データ・重いクエリを素早く検索してくれる
まとめ
- サービス課題: MySQL 5→8系移行が難しく、ETLの障害点と遅延、TiDB+TiFlashを採用。
- データ移行: Cassandra2億、MySQL4億レコード、Dual Write方式、スナップショットからの同期。
- 移行検証課題: 2000qps Insertで性能劣化、500qpsに調整、ディスクサイズ4TB制限。
- 結果: ETL排除で遅延解消、トランザクション性能向上、オンラインスケール・バージョンアップ成功。
- TiFlash Tips: 重いクエリに適し、軽いクエリは苦手、Optimizerの判断でTiKVが選ばれる場合も、リリース時に保険として設置推奨。
DMMプラットフォームにおけるTiDBの導入から運用まで
合同会社DMM.com
プラットフォーム開発本部 アーキテクト pospome 氏
- NewSQL を採用した背景
- レガシーシステムのリプレイスプロジェクト
- インフラのクラウド化
- Go への rewrite
- オンプレの MySQL 運用
- MySQL をクラウドでも使うのか？
- マスターノードが単一障害点
- 認証認可が止まると DMM が止まる
- バージョンアップ時のダウンタイム
- メンテを入れるのが面倒
- 60以上のサービスの承認を取るのが。。。
- メンテを入れるのが面倒
- Write が水平スケールしない
- 各種サービスの都合でリクエストが増える
- マスターノードが単一障害点
- NoSQL の検討
- 現実的に厳しい
- MySQL のデータ構造を NoSQL 向けに変えるのは難しい
- 現実的に厳しい
- NewSQL の特徴
- RDBに比べるとレイテンシーは高くなる
- 費用が高くなる傾向にある
- MySQL, NoSQL の上位５日間ではない
- 適材適所である
- TiDB の特徴
- Spanner の論文を参考に開発された OSS の NewSQL
- MySQL互換
- とはいえ完全に互換性があるわけではない
- 独自使用
- コメント構文で定義することで MySQL でも有効な構文を扱うことができる
- MySQL 互換を徹底している
- コメント構文で定義することで MySQL でも有効な構文を扱うことができる
- TiDB Cloud
- PingCap が提供する DBaaS
- これを採用
- DevOps を実現するため
- 認証チーム、認可チームだけでインフラ運用が解決する
- レガシーシステムのリプレイスプロジェクト
- Google Spanner vs TiDB/TiDB Cloud
- アーキテクチャについて
- 似ている
- コンピューティングとストレージを分割
- Placement Driver によってデータ配置を調整している
- が、同じ基準で比較することは難しい
- クラウドサービスとソフトウェア (OSS)
- 似ている
- パフォーマンス
- なんともいえない
- TiDB はオンプレにもホスティングできる
- レプリカ
- TiDB
- TiDBはレプリカとして TiKV ノードに複製する
- クエリはリーダーにのみ向けられる
- フォロワーはあくまでもバックアップ
- Spanner
- TiDB でいうフォロワーにもアクセスできる
- 自身が持つデータが最新かどうかをリーダーに問い合わせる
- TiDB
- JOIN
- Spanner
- インターリーブという機能を備えている
- 親子関係にあるデータを物理的に同じ場所に配置する
- 分散しないのでJoin に強くなる
- インターリーブという機能を備えている
- Spanner
- なんともいえない
- 既存DBとの互換性
- TiDB は MySQL 互換
- Spanner は PostgreSQL 互換
- PGAdapter を利用しなければならない
- CloudRun でホスティングさせたりサイドカーとして利用しないといけない
- PostgreSQL 移行にそれなりに工数がかかる
- PGAdapter と向き合わないといけない
- OLAP
- NewSQL はデータが複数のノードに散るので苦手
- TiDB は HTAP で分析処理をサポートしている
- TiKV のデータをTiFlash にも持つことになるので二重で持つことになる
- MySQL 互換のクエリを投下的に利用することができる
- TiFlash か TiKV かは自動的に振り分けられるが、明示的に指定することもできる
- コスパ
- 微妙
- Spanner は HTAP をサポートしていないので BQ にコピーする必要がある
- クエリ連携
- データコピーの必要がない
- ネイティブに比べるとパフォーマンスが落ちる可能性がある
- Spanner の Data Boost
- 既存の OLTP に影響を与えない
- クエリ実行にかかったリソースにのみ課金される
- ローカル開発
- TiDB は tiup というツールを使うことで TiDB を立ち上げられる
- Spanner はエミュレーターを提供
- クラウド費用
- どちらが安いかは一概に言えない
- パフォーマンス次第になってしまう
- EDP のような割引も絡んでくる
- どちらが安いかは一概に言えない
- Google Cloud との連携
- 微妙
- 結論
- Spanner の方が完成度が高い
- Google の資金力や開発力に勝つのは難しい
- クラウドサービスとしての品質も
- 競合？
- 意外と棲み分けできているのでは？
- オンプレのホスティング
- MySQL互換
- AWS
- 最終的に TiDB Cloud を採用
- Spanner ほどではないが十分実用に耐えうる
- レガシーシステムをリプレイスするという目的を達成するのは OK
- だいたい半年くらいで実施
- 移行に必要な処理はダブルライトくらい
- パフォーマンス劣化もほとんどない
- アーキテクチャについて
- 実際に運用してみてどうか？
- 安定して動くのか？
- 半年くらい動かしている感じ安定している
- QPS 4500程度
- 過去にあったトラブル
- キャパプラミスった
- TiKV のバグを踏んだ
- CPU 利用率は 80％くらいが境目
- リプレイスが完了すると 15000QPS くらい
- Write がスケールするのは嬉しい
- コスパ
- Aurora と同等の QPS を出そうとするとインフラ費用が 2倍以上かかる
- NewSQL は RDB の上位互換ではない
- バージョンアップ戦略
- TiDB はロールバック戦略がない
- 一発勝負
- リリースノートを確認する
- tiup で立ち上げて E2E
- 最新バージョンの1つ前のマイナーバージョン
- 開発用のクラスタで様子見
- TiDB はロールバック戦略がない
- MySQL 互換が嬉しい
- 既存の運用に影響ない
- GitOps で任意の SQL を実行できる仕組み
- goose を使用
- そんなに甘くない
- MySQL とは別物である
- 学習コストがかかる
- キャパプラやトラブルシューティングは試行錯誤
- エンプラサポートは重要
- TTL 機能
- TiDB はテーブルに TTL 属性を持たせることができる
- 監視
- Datadog, NewRelic と連携可能
- が、あまり使い物にならない
- メトリクスは１週間
- 通知はメールのみ
- ちょっと課題がある
- Datadog, NewRelic と連携可能
- Redis 廃止したい
- TiDB に寄せられる可能性を考えている
- 費用が高くなりそうなので要検討
- オートスケーラーが欲しい
- マルチテナント型クラスター
- 複数アプリケーションのサーバを一つのクラスターに乗せる
- 特定のアクセスによって全部が影響を受ける
- リソース制御機能によってノイジーネイバーを防ぐことができる
- バックアップとの相性が悪い
- バックアップリストアすると他のアプリケーションのデータも一緒にリストアされてしまう。。
- 複数アプリケーションのサーバを一つのクラスターに乗せる
- 安定して動くのか？
- まとめ
- プロダクトとしての完成度は Spanner に群杯
- 棲み分け可能
- 安定して動くが管理画面が使いづらい
まとめ
- 背景: レガシーシステムのリプレイスで、クラウド化とGoへの書き直し、MySQLからTiDB Cloudへ移行。
- 理由: TiDBの分散アーキテクチャ、MySQL互換、クラウドでの運用容易性。
- 比較: TiDBはSpannerと似たアーキテクチャだが、性能やコスパで一長一短。
- 運用: 安定稼働、QPS4500程度、キャパシティプランニングとバグ対応。
- 課題: 学習コスト、監視ツールの限界、オートスケーリングとマルチテナント運用の改善が必要。
Discussion