[Qiita Conference 2024] 音声プラットフォームVoicyがTiDBを検証し採用に至るまで (20240418_Qiita_Conference_PingCAP_Voicy_TiDB)

2024年4月18日にQiita Conference 2024にて、音声プラットフォームであるVoicyが自社の基幹データベースをTiDBに移行するにあたり、どのような検証を行ったのか紹介した際のスライドです。

https://qiita.com/official-columns/event/202405-qiitaconference-pingcap/

Transcript

1. 音声プラットフォームVoicyがTiDBを 
 検証し採用に至るまで 
 2024/4/18
 株式会社Voicy 千田 航己 

2. © Voicy, Inc. はじめに
 • 選定の経緯
 ◦ Voicyは何に困っていたか？ 
 • どのような検証を経て採用に至ったか
 ◦ 互換性は十分か？
 ◦ 負荷に耐えられるか？ 
 ◦ コストは予算内に収まるか？ 
 VoicyによるTiDBの「選定経緯」と「検証内容」を紹介 
 TiDB : MySQLと互換性のあるNewSQLデータベース 
 Voicy : 音声コンテンツの総合プラットフォーム
 メインのデータベースとしてTiDBを採用

3. Voicyのサービス概要 

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

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

8. TiDBの概要 

9. © Voicy, Inc. NewSQLとは 
 RDBが持つ特性を保持しながらスケーラブルなデータベース 
 特徴
 • ACID特性を持つ 
 • SQLで操作 
 • スケールしづらい
 RDB (SQL) 
 特徴
 • ACID特性が不十分
 • SQL使用不可
 • スケールしやすい 
 NoSQL 
 特徴
 • ACID特性を持つ 
 • SQLで操作 
 • スケールしやすい 
 NewSQL 
 昔
 最近
 トレードオフ 

10. © Voicy, Inc. TiDBの特徴 
 MySQL互換のNewSQLデータベース 
 
 • パフォーマンス要求の拡大に応じたスケーリングが容易 
 
 • 無停止でスケーリング 
 • 無停止でノード障害から復旧 
 
 (Hybrid Transactional/Analytical Processing) 
 • 通常処理用/データ分析的な処理用の 
 コンポーネントを併せ持つ 
 スケーラブルな分散DB 
 高い可用性
 HTAP
 アプリケーション
 目線での使い心地は 
 ほぼMySQL

11. © Voicy, Inc. TiDBのアーキテクチャ 
 TiKV TiFlash TiDB TiDB TiFlash TiKV TiKV PD TSO / Data Location Metadata column型
 　row型
 PD PD クエリ増加 ->ノード追加 容量拡張 ->ノード追加 • SQL解析を⾏う *MySQLプロトコルをKVに変換 • ParserやOptimizerを担う • HTAPではTiKV(row型)かTiFlash(column型)か判断 コンピューティング  TiKV • OLTP⽤途の分散Key-Value Store※Rocks DB利⽤ • パーティショニングによるデータ分散管理 • Raftや2PCにより整合性担保  TiFlash *optional • HTAP利⽤時の追加コンポーネント • OLAP⽤途のカラム型ストア • データ配置場所の管理（Region管理） • 分散トランザクションで利⽤するTSOを発⾏ 司令塔 PD TiDB TiFlash TiKV ストレージ
12. © Voicy, Inc. データレイアウトとI/O 
 • Regionという単位でデータを管理（⾃動シャーディング）各TiKVノードに3⾯コピー（冗⻑構成） • 各RegionのLeaderに対してI/O ※１つの読込/書込ポイントと2つのバックアップ Follower バックアップ Leader 読み書き可能 Follower バックアップ Follower バックアップ Follower バックアップ Leader 読み書き可能 Leader 読み書き可能 Follower バックアップ Follower バックアップ 例：ユーザーテーブル 各Regionはデフォルト96MB ->柔軟性を確保 TiKV TiKV TiKV TiDB TiDB ：Region

13. VoicyがDB改善を検討した背景 

14. © Voicy, Inc. DB改善を検討した背景 
 • データベース改善を考えた背景
 ◦ データベースのコスト負担 
 ◦ サービス規模の拡大に対応する必要性 
 
 コスト削減 & サービス規模拡大 
 会員登録者数
15. © Voicy, Inc. サービス規模拡大への対応 
 • 書き込み負荷に対応しやすい
 ◦ writer/readerエンドポイントの区別がない 
 ◦ 書き込みに対してスケールアウトで対応可能 
 • HTAPにより効率化する処理があるのではという期待
 ◦ 例) リスナーの再生ログから再生数を集計 
 NewSQLは他にもあるがTiDBは MySQL互換 
 TiDBを使う利点と期待 
 移行前のVoicyのメインDBはAmazon Aurora MySQL 

16. TiDBの検証 

17. © Voicy, Inc. 検証の観点 
 3つの指標で検証 
 パフォーマンス
 コスト
 ポータビリティ

18. © Voicy, Inc. コスト
 • まず予算目標を設定
 • 予算を決めることで、クラスター構成が決まる 
 → 「コスト」と「パフォーマンス」はトレードオフ
 予算目標を達成することができるか 
 両方を変数として
 扱うのは難しいので、 
 コストを仮決め

19. © Voicy, Inc. パフォーマンス 
 • VoicyのバックエンドAPIと併せて負荷試験
 ◦ 発行されるSQLが多様 
 ◦ 発行頻度もSQLごとに異なる 
 
 稼働中のサービスのワークロードに耐えられるか 
 vegeta: 
 負荷試験ツール
 Voicyの
 バックエンドAPI

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

21. © Voicy, Inc. パフォーマンス 
 • 初回実行時の結果
 ◦ req/secを本番同等まで上げると複数のスロークエリが発生 
 ▪ 現行DBでパフォーマンスが出るように実装しているので当然 
 → チューニングを実施 
 稼働中のサービスのワークロードに耐えられるか 

22. © Voicy, Inc. 
 • 絞り込みや結合の効率が悪い 
 ◦ インデックスの追加
 • 結合が遅い
 ◦ ヒント句による結合アルゴリズムの指 定
 など
 
 • 実行計画をキャッシュ 
 • 変更が少ないテーブルのキャッシュ化 
 • SQL bindingで実行計画を矯正する 
 • 指定した領域のregion分割 
 ◦ ホットスポット問題に対応
 ◦ ホーム画面など同じ情報にアクセスが集中
 ◦ → TiKVの同じregionにアクセスが集中
 • スケールアウト
 ◦ 予算側を調整
 など
 パフォーマンス 
 稼働中のサービスのワークロードに耐えられるか 
 SQLチューニング
 その他の対応

23. © Voicy, Inc. パフォーマンス 
 • 最終結果
 ◦ チューニングを続けることで十分なパフォーマンス 
 • 考察
 ◦ NewSQLは魔法の技術ではない 
 ◦ 魔法ではないが十分に高性能 
 ◦ チューニングに際して「TiDBだから特別」なことの比重は小さい 
 ◦ より大規模かつ高負荷な環境でより真価を発揮しそう 
 稼働中のサービスのワークロードに耐えられるか 

24. © Voicy, Inc. ポータビリティ 
 • バックエンドAPIが問題なく動くか確認
 ◦ 週次で実施しているリグレッションテストと同じテストを実施 
 
 必要な機能や互換性が十分あるか 

25. © Voicy, Inc. ポータビリティ 
 必要な機能や互換性が十分あるか 
 • 結果
 ◦ 特別な対応なしでリグレッションテストを通過 
 → 強力なMySQLとの互換性 
 • 唯一起きたエラーとその対応
 ◦ 「デフォルトのSQL Modeが厳格だったので緩めた」 
 ▪ → MySQLの設定の話で、TiDB特有の問題ではない 
 • 補足
 ◦ Voicyでは特殊なSQLをあまり書いていないというのはあるかも 
 

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

27. © Voicy, Inc. むすび
 • Voicyではコスト面の負担/サービス成長からDBの改善を検討していた
 • MySQLと互換性のあるNewSQLデータベースであるTiDBに注目
 • 検証を経てTiDBの採用を決定
 ◦ コスト
 ◦ パフォーマンス
 ◦ ポータビリティ
 DB移行の背景から、行った検証までを紹介 

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

30. Appendix 

31. © Voicy, Inc. TiDBの利用形態 
 パターン
 1 TiDB Cloud (Serverless/Dedicated) - Webコンソールからデプロイ - Webコンソールから操作 - PingCAP管理VPCへ接続して利⽤ パターン
 2 オンプレ/VM パターン
 3 Kubernetes (EKS等含む） - Linuxにインストールしてデプロイ - tiupコマンドを通じて操作 ※クラスター作成/スケール etc... - コンテナとしてデプロイ - tidb Operatorを通じて操作 ※クラスター作成/スケール etc... Self-Hosted Fully managed
32. © Voicy, Inc. TiDB Cloudのラインナップ 
 Serverless Dedicated TiDB Serverless はクラウ ド型マルチテナントマネー ジドTiDBサービスです。 TiDBの主要機能を簡単に 利⽤でき、⾃動でスケール するため管理負担もありま せん。 真の従量課⾦型サービスで 利⽤していないときの課⾦ はありません。 TiDB Dedicated はお客様 毎の専⽤VPC内に構築する クラウド型マネージド TiDBサービスです。 お客様の利⽤規模に応じた TiDBクラスタを構成し、 制限のないTiDBの全機能 の他、データ移⾏やCDCな どの周辺機能もサービスと して利⽤可能です。
33. © Voicy, Inc. パフォーマンス 
 • その他の問題
 ◦ 負荷テストの際に共用していた他のコンポーネントがボトルネックになった 
 ▪ アプリケーション自体は本番同等スペックで専用に作成 
 ▪ DynamoDBなど一部共用してしまっていた 
 ▪ 負荷テスト用の独立した環境を持っておくべき 
 稼働中のサービスのワークロードに耐えられるか 
 バックエンドAPI
 TiDB
 その他のDB
 高速
 低速
 ボトルネック 

34. © Voicy, Inc. その他の要件 
 • 監査ログの対応状況
 • バックアップ機能の使い勝手
 • DatadogやTerraformなどとの連携
 • バージョンアップの対応方法
 • アラート設定
 • スケーリングの手段
 などを確認
 → やりたいことは大体できる 
 Should要件: 必須ではないがあると良い 
 検証時点でできないと確認されたことの例 
 • 時間ベースのスケールイン/スケールアウト 
 • Terraformでできることが限定的