TiDBを活用して分散システムで抱えてた課題を解決

ツール導入前の課題

• DBのリソース・管理効率が低下していた
  • 開発組織に対してRDSやAuroraのクラスターが多くなってしまった
    • 約80人の開発組織に対して約50個のインスタンス
  • SREにかなり負担がかかってしまっている状態
    • DB運用に問題が発生した際にSREの工数が取られてしまう
    • それぞれのクラスターごとに最適なスペック調整が必要
• RDSやAuroraの可用性には限界がある
  • DDL反映やアップグレード時にはメンテナンスが必要となってしまう
  • メンテナンスによる様々な弊害も発生
    • 関係者の調整コストが高い状態
      • サービスやシステムが増え、関係者も多くなり、サービス・広告の停止の調整コストが高い
    • 開発者体験の低下してしまう
      • サービス・広告の停止はできる限り利用者が少ない早朝や夜間に行う必要があり、開発者の負担になってしまう
• MySQL 5.7互換であるAurora MySQL 2のサポートが2024年10月で終了してしまう
  • 利用しているRDSのほとんどがAurora MySQL 2
    • リザーブドインスタンス（RI）を購入するかも判断に迷っていた

どのような状態を目指していたか

• SREが課題としていたDBのリソース・管理効率を改善
  • クラスターを一元管理化し、リソース・管理効率を向上
• DB起因によるメンテナンスを削減して幸せな開発者体験を構築
  • ゼロダウンタイムの実現と計画停止（メンテナンス）の脱却
  • 可用性を向上させて、DDLもオンラインで反映可能な状態

• MySQL互換でNew SQLとして導入事例が多かったのがTiDBしかなかったため比較したサービスはありません。
• 強いて言うなら、既存のRDS・Auroraと可用性・互換性・パフォーマンス・コストの観点で比較しました。

• 移行可能性の検証
  • MySQLの互換性テスト
  • 既存アプリケーションにおける動作テスト
  • SQLパフォーマンステスト
• TiDB機能テスト
  • GUIやデータパイラライン等のツール連携テスト
  • 可用性（ゼロダウンタイム）の動作テスト
  • リソースコントロール機能の検証
• その他
  • AWSとGCPのコスト比較

• MySQLの互換性
  • 既存のアプリケーションやGUIが問題なく利用できる
• 可用性の大幅な向上
  • ゼロダウンタイムの実現
  • オンラインでのDDL反映
• TiFlashによるHTAPの実現
  • 列指向での演算も可能になり、既存のパフォーマンスが懸念となっている部分も解消可能
  • 現在、BigQueryを利用しているが、BigQueryに連携せずに分析基盤を構築することができる
• Vector Searchの機能追加
  • 現在、Public Beta版でServerlessのみ利用可能
  • 検索機能のUX改善等に活用できる

現在、移行中のため割愛させていただきます。

• パフォーマンス検証時に期待しているパフォーマンスが出なかったこと
  • 既存の環境でスロークエリとなっているSQLとの相性がとても悪い
    • 参考記事：TiDBにおけるパフォーマンス検証の進め方とつまづきポイント
• 現在利用しているSQLがTiDBでは利用できないこともあったこと
  • サブクエリを利用したクエリ等
• データ移行に向けて既存のRDSにおけるbinlog_formatがMIXEDになっていたこと
  • binlog_formatがMIXEDになっていると、TiDB DMやDMSにて差分（cdc）でのデータ移行ができない
  • そのため、すべてのRDSにおけるbinlog_formatをROWに移行した

TiDBは銀の弾丸ではありません笑
まずは既存のDBにおける設計や課題と向き合うことが大事だと思います。

• 各システムのDBをTiDBへの移行
• TIDB Serverlessの活用
• TiFlashの活用
• Vector SearchによるUX改善