スタートアップにおけるTiDB Serverless の導入

スタートアップにおける TiDB Serverless の導入 TiDB User Day 2024 BACKSTAGE, Inc. Yuto Akiba (@akkey0222) © 2024 BACKSTAGE Inc.

自己紹介 秋葉 祐人 / Yuto Akiba @akkey0222 @touyu 2018年にスタートアップを共同創業し、クリエーター支援プラットフォームを開発。 2022年から株式会社BACKSTAGEにジョイン。 複数の事業を横断しつつ、バックエンドをメインに担当。 © 2024 BACKSTAGE Inc.

会社紹介 アプリ事業 etc... © 2024 BACKSTAGE Inc. ライブ配信事業

ライブ配信システムの課題 データベースへの負荷予測が困難 • 各興行やイベントごとでのトラフィック量の大きな変動 • 不定期で発生するスパイク • ユーザの投票（イベントの流れによって有無が変わるため予測が困難） • PPVの購入 • 専任のインフラエンジニアがいない 最大約50倍の 秒間リクエスト数 © 2024 BACKSTAGE Inc.

ライブ配信システムの課題 オーバースペックによるインフラコスト増加 • ピーク時よりバッファをもたせたスペックで対処する • 通常時はオーバースペックになってしまう • 見積もりのズレの懸念 レプリケーションやシャーディングで実装コスト増加 • レプリケーションでは読み取りの負荷は減らせるものの、書き込み負荷は減らせない • シャーディングはシステムが複雑になる & コスト面はあまり改善されない © 2024 BACKSTAGE Inc.

様々なフルマネージドなDBサービスを探すものの、、 オートスケール未対応 ストレージのみ対応 コンピューティングリソースは未対応 高レイテンシー 高いレイテンシー 日本リージョンが提供されておらず、 数百msのレイテンシーが発生することも © 2024 BACKSTAGE Inc. 高いコスト スタートアップからすると利用料が高い 未使用の期間にもコストが掛かってしまう NoSQL NoSQL用の設計を求められるため できれば慣れているSQLを使用したい

TiDB Serverlessの選定理由 オートスケール 手動での設定なしに自動でコンピューティ ングリソースもスケール可能 高レイテンシー レイテンシー Cloud SQLを使用したときと比較して少し レイテンシーは上がってしまうものの約数 十ms以内で許容できる © 2024 BACKSTAGE Inc. コスト 未使用の期間のコストがストレージ分の 費用のみ MySQL互換 使い慣れているSQLをそのまま使用できる ので追加の学習コストが低い

TiDB Serverless導入してみてどうだったか？ 移行の容易さ 当初MySQLを使用して開発を進めていたがほぼ労力なしに切り替え可能 安定した運用 すでに何度かイベントの配信を実施、トラブルなく不定期のスパイクにも対応 運用してから気づいた点 スペック調整によるダウンタイム等なく、機会損失を抑えられている © 2024 BACKSTAGE Inc.

TiDB Serverlessの懸念点 外部キー制約が実験的なサポート 負荷テストで問題ないこと確認し、現在は有効にして運用 問題が発生しても foreign̲key̲checks を無効にすることですぐに対処可能 Public接続 AWSを使用している場合は、Private Endpointを使用できるが、 Cloud RunなどGCPをメインで使用している場合はPublic接続を使用することになる © 2024 BACKSTAGE Inc.

まとめ 実装コストの低下 • レプリケーションやシャーディングを自前で用意する必要がない • 事前のスペック調整が必要ない • MySQL互換でエンジニアの学習コストも低い インフラコストの低下 • オートスケーリングでオーバースペックになることなく、使用料に応じた費用で済む • 未使用時はストレージ料金のみで維持可能 © 2024 BACKSTAGE Inc.

We are hiring! バックエンドエンジニア Go, TypeScript Webフロントエンジニア Next.js(TypeScript) x.com/akkey0222 モバイルエンジニア Flutter © 2024 BACKSTAGE Inc. https://bit.ly/4cFLtlM

• https://bit.ly/4cFLtlM