目次
TiDBを活用して分散システムで抱えてた課題を解決
参考になった
6
レビュー投稿日の情報になります
レバテック株式会社 / かわうそ
テックリード / テックリード / 従業員規模: 501名〜1,000名 / エンジニア組織: 51名〜100名
最終更新日投稿日
| 利用プラン | 利用機能 | ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
|---|---|---|---|---|
コミットメントプラン | TiDB Cloud | 51名〜100名 | 2024年2月 | B to B |
| 利用プラン | コミットメントプラン |
|---|---|
| 利用機能 | TiDB Cloud |
| ツールの利用規模 | 51名〜100名 |
| ツールの利用開始時期 | 2024年2月 |
| 事業形態 | B to B |
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
- DBのリソース・管理効率が低下していた
- 開発組織に対してRDSやAuroraのクラスターが多くなってしまった
- 約80人の開発組織に対して約50個のインスタンス
- SREにかなり負担がかかってしまっている状態
- DB運用に問題が発生した際にSREの工数が取られてしまう
- それぞれのクラスターごとに最適なスペック調整が必要
- 開発組織に対してRDSやAuroraのクラスターが多くなってしまった
- RDSやAuroraの可用性には限界がある
- DDL反映やアップグレード時にはメンテナンスが必要となってしまう
- メンテナンスによる様々な弊害も発生
- 関係者の調整コストが高い状態
- サービスやシステムが増え、関係者も多くなり、サービス・広告の停止の調整コストが高い
- 開発者体験の低下してしまう
- サービス・広告の停止はできる限り利用者が少ない早朝や夜間に行う必要があり、開発者の負担になってしまう
- 関係者の調整コストが高い状態
- MySQL 5.7互換であるAurora MySQL 2のサポートが2024年10月で終了してしまう
- 利用しているRDSのほとんどがAurora MySQL 2
- リザーブドインスタンス（RI）を購入するかも判断に迷っていた
- 利用しているRDSのほとんどがAurora MySQL 2
どのような状態を目指していたか
- 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との相性がとても悪い
- 現在利用しているSQLがTiDBでは利用できないこともあったこと
- サブクエリを利用したクエリ等
- データ移行に向けて既存のRDSにおけるbinlog_formatがMIXEDになっていたこと
- binlog_formatがMIXEDになっていると、TiDB DMやDMSにて差分（cdc）でのデータ移行ができない
- そのため、すべてのRDSにおけるbinlog_formatをROWに移行した
導入に向けた社内への説明
上長・チームへの説明
上長に対して
TiDBの特段大きなコスト増加につながっておらず、PoCでもMySQLの互換性の検証でもそこまで懸念がなかったため、説明はそこまで必要なかったです。
また、AWS Marketplaceでの支払いも可能なので、追加で必要な稟議申請も進めやすかったです。
チームに対して
各チームに対して、TiDBとはどんなDBなのか、なぜ移行するのかなどを説明する場は設けました。また、各チームのアプリケーション開発している側からすると、MySQLの互換性が高いため、正直、裏側のDBが変わったぐらいの感覚で利用してもらえるため、メンバーへの負荷も少なく進められました。
活用方法
よく使う機能
- TiDB Cloud
- TiDB Serverless
- TiDB Cloud Built-in Metrics
- TiDB Dashboard Cluster Diagnostics
ツールの良い点
- MySQL互換性のサポート
- ゼロダウンタイムの実現
- TiFlashによるHTAPの実現
- Vector Search
ツールの課題点
- メトリクス期間
- 最大７日間しか取得できない
- アラート通知
- メールでの通知しか対応していない
- Slack連携するには仕組みを作る必要がある
- Auto Scaling機能
- TiDB Cloud上では設定できない（TiDB Cloud APIを利用する必要がある）
- ただし、QPSやスパイクに応じて設定する手段がない
- バックアップ機能
- クラスター単位のバックアップのみ対応
- DB・スキーマ単位のバックアップに対応していない
- Terraform対応
- TiDB Cloud用のProviderが用意されているが、できることが限られている（クラスター作成等しかできない）
ツールを検討されている方へ
TiDBは銀の弾丸ではありません笑
まずは既存のDBにおける設計や課題と向き合うことが大事だと思います。
今後の展望
- 各システムのDBをTiDBへの移行
- TIDB Serverlessの活用
- TiFlashの活用
- Vector SearchによるUX改善
レバテック株式会社 / かわうそ
テックリード / テックリード / 従業員規模: 501名〜1,000名 / エンジニア組織: 51名〜100名
よく見られているレビュー
ツールの比較記事Pickup
記事の追加・取り下げを希望の場合はこちらのフォームより申請をお願いします。
レバテック株式会社 / かわうそ
テックリード / テックリード / 従業員規模: 501名〜1,000名 / エンジニア組織: 51名〜100名
