Breaking Down LIVE をはじめとするライブ配信サービスでの TiDB Serverless の導入事例

ツール導入前の課題

• データベースへの負荷予測が困難
  • 興行(Breaking DownやRIZINなど）や同じ興行でも時期の異なる別のイベントによって、注目度が毎回異なるためトラフィック量が大きく変動することがある
  • アプリケーションの機能により不定期にアクセスが集中しスパイクが発生することがある
• インフラコスト
  • 上記の課題は高いスペックで事前に設定しておくことで対処可能ではあるが、インフラコストが跳ね上がってしまう
  • ライブ配信という特性上、イベントが開催されていない期間はほぼ未使用の状態になる
    • 常に立ち上げた状態にしておくとコスト面では無駄が発生してしまう
    • DBを毎回止めてしまうとデータを確認したいだけでも立ち上げ直す必要が出てしまい不便
• 開発リソース
  • スタートアップということもあり専任のインフラエンジニアがいない
    • 複雑なアーキテクチャを採用すると保守が難しくなってしまう懸念がある
  • NoSQLはスケーラビリティに優れているが、特有の扱い方や設計パターンを習得するのに学習コストがかかってしまうので、慣れているSQLを利用して開発を行いたい

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

• 高い専門性や複雑なアーキテクチャなしに負荷状況に応じて柔軟なオートスケーリングが可能
• インフラコストの最適化

• Aurora Serverless v2
• Cloud Spanner
• Neon
• AlloyDB
• Cloud SQL
• Cloud Firestore

※ 現時点でまだ比較できていないが、おそらく検討候補にあげられるサービス

• CockroachDB Serverless

• コンピューティングリソースのオートスケール対応
• コスト
  • 使用時に発生する費用
  • 未使用時（アクセスがない期間）に発生する費用
• SQLを使用できる
• 学習コストが高すぎない
• レイテンシーの低さ

• コンピューティングリソースのオートスケール対応
  • 対応している
• コスト
  • 使用時に発生する費用の低減を見込めた
  • 未使用時（アクセスがない期間）に発生する費用がストレージ費用のみで運用可能だった
• SQLを使用できる
• 学習コストが高すぎない
  • MySQL互換
  • 元々MySQLで開発を進めていたところもあったが、ほぼ手を加えることなく向き先を変える程度で移行することができた
• レイテンシーの低さ
  • 日本リージョンが提供されている
  • アプリケーションサーバーにはCloud Runを使用していたため、Cloud SQLと比較するとレイテンシーは増加してしまうものの、数十ms以内で許容範囲であった

改善したかった課題はどれくらい解決されたか

• 事前のスペック調整なしで運用可能になった
• コスト面も当初の想定より低く抑えられている

どのような成果が得られたか

• 何度か本番で利用しているが今のところトラブルなく安定して運用できている

• 外部キー制約が実験的なサポートであったこと

  • パフォーマンス劣化の可能性があるとのことだったので、負荷テストを実施し問題ないことを確認
  • foreign_key_checks の設定を無効にすることで、問題が起きてもすぐに対処可能ということがわかったので現在は有効にして運用

• Google Cloud では Private Endpointが未サポート

  • AWSではPrivate Endpointを使用できるが、Google Cloud では Public接続をする必要がある
  • セキュリティ面を考えるとできれば、Google CloudでもPrivate Endpointを使用したい

• メトリクスが見れる期間が短い

  • 最大７日間しか見ることができず、もう少し過去のものを参照したいケースが多々あり不便に感じた

リソースの限られているスタートアップに特に向いているサービスだと感じました。