VoicyのTiDB移行とトラフィック量の変化に応じたリソース管理 (20241211_Findy_replace_Voicy_TiDB)

2024年12月11日のFindyさん主催の勉強会「そのリプレイスは最適解？ -コストから見るプロダクト開発Tips」での発表資料です。
https://findy.connpass.com/event/336975/

以下のスライドのQiita Conferenceでの内容に加えて、トラフィック量に応じたリソース管理によるコスト改善の話をしました。
https://speakerdeck.com/thousanda/20240418-qiita-conference-pingcap-voicy-tidb

Transcript

1. VoicyのTiDB移行とトラフィック量の 
 変化に応じたリソース管理 
 2024/12/11
 株式会社Voicy 千田 航己 

2. © Voicy, Inc. はじめに
 • Voicyが何に困ってデータベース移行を始めたか
 • どのような検証を経てTiDBの採用を決めたか
 • 本番運用開始後のコスト削減のためのリソース管理
 TiDBの「選定経緯」「検証内容」「本番運用」 
 TiDB : MySQLと互換性のあるNewSQLデータベース 
 Voicy : 音声コンテンツの総合プラットフォーム
 メインのデータベースとしてTiDBを採用

3. Voicyのサービス概要と 
 データベース改善の背景 

4. © Voicy, Inc. サービス概要 
 スマートフォン1台で音声発信や聴取を楽しめる音声プラットフォーム 
 会員登録者数 
 200万人超 
 チャンネル数 
 2000超 

5. © Voicy, Inc. システム的な観点からのVoicy 
 • トップパーソナリティの放送公開や生放送などのタイミング にアクセス集中
 • 通勤時間帯の朝7, 8時台 にアクティブユーザーが多い
 Voicyのトラフィック特性 

6. © Voicy, Inc. DB改善を検討した背景 
 • データベース改善を考えた背景
 ◦ データベースのコスト負担 
 ◦ サービス障害の原因がデータベースのパフォーマンスであることも多かった 
 ◦ サービス規模の拡大に対応する必要性 
 
 コスト削減 & パフォーマンス改善 
 会員登録者数
7. TiDBの検証 

8. © Voicy, Inc. 検証の観点 
 3つの指標で検証 
 パフォーマンス
 コスト
 ポータビリティ
 稼働中のサービス のワークロードに耐 えられるか
 予算目標を達成する
 ことができるか
 必要な機能や
 互換性が十分にあるか

9. © Voicy, Inc. 検証の観点 
 3つの指標で検証 
 パフォーマンス
 コスト
 ポータビリティ
 稼働中のサービス のワークロードに耐 えられるか
 予算目標を達成する
 ことができるか
 必要な機能や
 互換性が十分にあるか
 トレードオフ 

10. © Voicy, Inc. パフォーマンス 
 • VoicyのバックエンドAPIと併せて負荷試験
 ◦ エンドポイントごとのアクセス頻度がSQLの発行頻度に影響するため 
 
 稼働中のサービスのワークロードに耐えられるか 
 vegeta: 
 負荷試験ツール
 Voicyの
 バックエンドAPI

11. © Voicy, Inc. パフォーマンス 
 • 対象はAPIのピーク時の負荷が高いエンドポイントトップ10
 • 実際のreq/secを再現
 
 稼働中のサービスのワークロードに耐えられるか 
 エンドポイント req/sec /再生ログの記録 40 /チャンネル詳細情報の取得 10 /フォロー中のチャンネルの放送取得 10 /コメントの取得 5 ・・・ イメージ

12. © Voicy, Inc. パフォーマンス 
 • 対象はAPIのピーク時の負荷が高いエンドポイントトップ10
 • 実際のreq/secを再現
 
 稼働中のサービスのワークロードに耐えられるか 
 エンドポイント req/sec /再生ログの記録 40 /チャンネル詳細情報の取得 10 /フォロー中のチャンネルの放送取得 10 /コメントの取得 5 ・・・ イメージ
 結果
 
 チューニングを続ければ
 十分なパフォーマンスが出そう！

13. © Voicy, Inc. 検証結果
 • 加えて、PingCAP社のサポートが手厚い
 採用を決定 
 パフォーマンス
 コスト
 ポータビリティ

14. 本番運用

15. © Voicy, Inc. TiDBへの移行を完了 
 PoCで検証した指標がどう着地したか 
 パフォーマンス
 コスト
 ポータビリティ
 概ねOK
 パフォーマンスの不足を一時的にサーバースペックでカバー 
 したためコスト削減額が目標に届かず (移行前よりは安い) 

16. トラフィック量の変化に応じたリソース管理 

17. © Voicy, Inc. Voicyのトラフィック特性 
 • アクセスが通勤時間である朝に集中
 習慣化しやすいサービスのためトラフィック量のサイクルが安定 
 深夜
 深夜
 朝
 昼
 夕方
 夜
 少ない
 とても
 多い
 
 少ない
 そこそこ
 多い

18. © Voicy, Inc. 必要な量だけリソースだけを確保したい 
 • Amazon Aurora の Scheduled Scalingを使用
 • 例)
 ◦ 6:00 –
 ▪ min_capacity: 5
 ▪ max_capacity: 8
 ◦ 10:00 –
 ▪ min_capacity: 3
 ▪ max_capacity: 6
 TiDBに移行する前はどうしていたか？ 

19. © Voicy, Inc. 必要な量だけリソースだけを確保したい 
 • 負荷に応じたオートスケーリング
 ◦ → 未提供
 • Scheduled Scaling
 ◦ → 未提供
 TiDB Cloudで困った点 

20. © Voicy, Inc. 必要な量だけリソースだけを確保したい 
 • 負荷に応じたオートスケーリング
 ◦ → 未提供
 • Scheduled Scaling
 ◦ → 未提供
 TiDB Cloudで困った点 
 じゃあ、作るか

21. © Voicy, Inc. 必要な量だけリソースだけを確保したい 
 • EventBridge Schedulerで指定時刻にLambdaを起動
 • LambdaはTiDB CloudのAPIを呼んでクラスターのインスタンス数を変更
 Scheduled Scalingを作りました 

22. © Voicy, Inc. TiDBクラスターの概要と調整イメージ 
 クラスター内に異なる役割のサーバーが複数いる 
 「どれを何時に何台にするか」はサーバーのメトリクスを見ながら日々調整...
 クライアント
 受け付け
 ストレージ
 TiDBクラスター

23. © Voicy, Inc. むすび
 • Voicyではコスト面の負担/サービス成長からDBの改善を検討していた
 • 検証を経てTiDBの採用を決定
 ◦ パフォーマンス
 ◦ コスト
 ◦ ポータビリティ
 • ただし、移行時は以下の状態
 ◦ パフォーマンス
 ◦ コスト
 ◦ ポータビリティ
 • → Scheduled Scalingを自前で実装
 DB移行の背景から、行った検証までを紹介 

24. 音声×テクノロジーでワクワクする社会をつくる