TiDB移行によりスケーラビリティの改善とコストダウン / 株式会社Voicy

ツール導入前の課題

• データベースにかかる金銭的なコストが高かった
• 効果的な負荷軽減を実施できておらず、インスタンスのスペックを上げることでトラフィックを捌いていた

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

• 移行前よりもデータベースのコストが下がっている状態
• かつ、適正コストで十分なデパフォーマンスが出ている状態

タイムライン

• 2023年4月 PoCを開始
• 2023年6月 PoCを終え、採用を決定
• 2023年8月 移行設計開始
• 2023年10月 移行作業開始
• 2024年4月 移行完了

• 強いて言えば移行前に使っていたAmazon Aurora MySQL
  • ツールの特性で苦労していただけでなく、弊社の使い方が悪いために性能を出しきれていなかった側面もあったため、Auroraのまま改善を実施する案もあった

• コスト
  • どれくらい料金を下げられるか
• パフォーマンス
  • 現在、そしてサービス規模拡大後のトラフィックに耐えられるだけの性能が出せるか
• ポータビリティ
  • 移行は容易か

一番の選定理由は、PoCを実施し、現実的なチューニング工数で目標とするコスト/パフォーマンスを実現できると判断できたことです。

PoC内容

• コストとパフォーマンス
  • 目標とするコストをベースにクラスターのスペックを決定
  • そのスペックでのパフォーマンスを測定
    • バックエンドAPIとデータベースを統合した状態で負荷試験を実施しました
    • まず本番環境における高トラフィックなタイミングでのAPIリクエストの種類とRPS (Request Per Second) を特定
    • その後、試験環境でそれを再現するように、同程度の負荷をかけました
  • パフォーマンスが出ないSQLについてはチューニングを実施
• ポータビリティ
  • 開発環境のバックエンドAPIをTiDBに接続した状態で、普段から継続的に実施されているリグレッションテストを実施

また、TiDB Cloudを提供するPingCAP社のサポートの手厚さを実感したことも挙げられます。性能が出ていない原因と、実施するべきチューニング内容について明快にご説明いただきました。

• コスト
  • 移行前よりコストを下げることができた
  • 目標としていた削減規模までは導入直後の時点では達成していなかったが、チューニングとスケールイン/アウトによって達成できる見込み (本レビューを執筆している 2024年7月現在、TiDB CloudのDedicated Tierのクラスターにはオートスケーリング機能が未実装)
• パフォーマンス
  • 切り替えによって性能が悪化した一部のクエリをチューニングすることで、現行のトラフィックに耐えられる性能を出すことができた

また、副次的な効果として、PingCAPの方々のチューニングに関する知見の一部を、社内に取り入れることができました。

• 周辺ツールが未成熟

  • TiDB Data Migration使用中にバグに遭遇
  • Terraformへの対応が部分的
  • など

• 社内の知見の少なさ

  • データベースに精通した人がいなかった