はじめに

本記事は Developers Summit 2025 Day2(2025/2/14)において MIXI の姜氏が講演された「”mixi2の舞台裏” TiDBで実現するSNSのスケーラビリティとパフォーマンス」のレポートです。

TiDBそのものの紹介や特徴の話もありましたが、このレポートでは省略しています。興味ある方は PingCAP社のサイト https://pingcap.co.jp/ や発表資料をご確認ください。

公式セッション紹介

本講演では、昨年末に新しくリリースしたSNSサービス「mixi2」のアーキテクチャを紹介します。
特に、DBとしてTiDBを採用しパフォーマンスとスケーラビリティをどのように実現したのかについて具体例も交えながら説明します。
開発時に直面した課題やトラブルの対処法、負荷テスト実施時のパフォーマンスチューニングの内容、SNS特有のデータモデリングについてもカバーするので、これから同様のシステム構築を考えている方についても役立つ内容です。

（引用：「mixi2の舞台裏」 TiDBで実現するSNSのスケーラビリティとパフォーマンス）

発表資料

「mixi2の舞台裏」TiDBで実現するSNSのスケーラビリティとパフォーマンス

概要／おすすめポイント

mixi2 を開発するにあたってDBに求められた要件から TiDB を選択し、その TiDB の利用に向けて実施したテストの内容などが説明されていたので、同じようにDB選定で悩むケースの参考になるかと思いました。

セッション内容の紹介

2023年の3月辺りから開始、当初は4名の体制だったが 2024年3月に7名体制となって本格的に開発を実施。

DBに対する要件

特に結果整合性ではなく、いわゆる ACID の整合性とライトスケール性を重視し、NewSQLを中心に選定。

NewSQLの選定

NewSQLは TiDB、Cloud Spanner、YugabyteDB、CockroachDB を机上で比較。
国内での実績、ドキュメントの充実度、（ダッシュボードなどの）監視ツールの充実さ、コストなどを総合的に判断し TiDB を採用、ただし Cloud Spanner の実績もあったので TiDB でテストを行って要件を満たせなければ変えることも想定。

全体アーキテクチャ

TiDB は EC2 で組んでいるが高可用性を確保すると最低 8 台構成。

TiKVノードを異なるラックに配置するため location labels を利用して Placement Group の制御を実施。
DumplogでS3にエクスポートし、（アーキテクチャ図には出ていないが）BigQueryに取り込んで分析を実施。
基本的にジョブは ECS のタスクにて実施。
監視は TiDBのダッシュボードのほか、Grafana・Prometheusを利用。

実施したテスト

主に負荷テスト・障害テストについての説明。

負荷テスト

負荷テスト用の環境を用意し、Locustで検証。
- 並列度を大きくするため go 製の worker 実装の boomerを使用
- 攻撃クライアントのスケールアウト・アップを頻繁に行うためk8s上で稼働
テストシナリオはユーザ作成から認証、フォロー、ポスト、ライクなどの基本動作を全て実施

(キャッシュされてしまわないのか、とAsk The Speakerで聞かれてましたが、システム全体としてはRedisのキャッシュも利用しているのでキャッシュ前提の動作で構わない、というようなお話をされていました)

負荷テスト結果

レイテンシは 100msec 程度を目標、write 10,000 req/sec 、Readはユーザのタイムライン表示のため 5～10 秒を目標に調整。
分散データベースで同じキーにロックを掛けるアーキテクチャとなるため、高負荷になるとレイテンシが伸び、レイテンシが伸びるとロック待機が伸び、タイムアウトが発生する、という状況が出たため、一部の処理を Redis へ移して回避。

障害テスト

それぞれコンポーネント障害を疑似的に発生させ、想定通りの動作を確認。

リリース

リリース日は想定以上の負荷となったが、スケールアウトで稼働継続。

一度TiDBのインスタンス障害が発生したが、サービス影響なく稼働を継続。

リリース後の課題

幾つかSlow Queryが発生。

Secondary Index 利用時の2番目のカラムでのソートで発生

現時点では IN句の中を一つに分割しているとのこと。

短期間でUpdateやDeleteが繰り返されるデータへのSelectで発生

MVCC(Multi Version Concurrent Control) なので、短期間に更新などが繰り返されると大量の過去バージョンが残ってしまいスキャン性能が落ちてしまうとのこと。

セッションまとめ

基本的にはTiUPなども活用しつつスケールアウトやバックアップについても無停止で運用ができており、且つ大きな性能影響も出ていないため満足している。
PingCAP社とも頻繁にコミュニケーションを取ることで、自社のチームと思うくらいのサポートを受けることができた。
今後は TiCDC などの機能も利用して SQS の代替や非同期ジョブなどを実装していきたい。

まとめ・感想

TiDBの選定に至った経緯とどのようなテストを行って評価したのか、という内容を主にレポートしてみました。
Ask The Speakerで少しだけお話しましたが、TiDBの選定理由として他だと良く聞く「MySQL互換」という点よりも実績やドキュメントの充実度をあげられていたのが興味深かったです。
2024年の DB Tech Showcase や Google Cloud Next でも幾つか事例・実績が紹介されており、3rd パーティの RDBMS としては頭一つ抜き出たような状態に見えますね。