【セッションレポート】 「mixi2の舞台裏」 TiDBで実現するSNSのスケーラビリティとパフォーマンス #devsumiE

ウィスキー、シガー、パイプをこよなく愛する大栗です。

先日 Developers Summit 2025 に参加してきました。印象が強かったセッションについてレポートします。mixi2 のスケーラビリティとパフォーマンスについてのセッションです。。

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

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

登壇資料

概要

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

登壇者

• 姜 明秀
  • 株式会社MIXI
  • 開発本部 CTO室 SREグループ　Software Engineer
  • Go、Elixirを使ったWebサービス、ゲームのバックエンド開発に従事。2018年1月より現職。

セッション

mixi2 は短文テキスト SNS で、タイムラインの他にコミュニティ機能やリアルタイムなコミュニケーション向けのイベント機能などがあります。サーバーは Go、モバイルクライアントは Flutter を採用して、開発当初は 4 人でリリース時は 7 人で開発を行っていました。

mixi2 では、主に gRPC で通信しており、キャッシュとタイムラインデータは Redis、コネクト RPC サーバ、検索用に OpenSearch、メッセージングサーバーに Redis Streams、非同期書き込みには SQS を経由して ECS Worker で処理しています。自社認証システムと解析データベースが別途存在しています。

DB の選定としては、SNS 開発として以下の要件を求めました。

• スケーラビリティ
• 障害発生時のフェイルオーバー
• レイテンシー
• トランザクション
• オペレーションの容易さ
• コスト

要件に合うデータベースとして NewSQL の導入を検討しました。

NewSQL とは、SQL インターフェースを持ち、従来のリレーショナルデータベースが持つトランザクションと強い整合性を保証する分散データベースです。例えば、TiDB、Spanner、CockroachDB、YugabyteDB などです。RDB のシャーディングなども検討しましたが、今回は TiDB を採用しました。比較表では NewSQL のインフラ費用を △ としましたが、コンピュートとストレージを別々にスケールできるので場合によっては安くなることがあると思います。

TiDB は TiDB（SQL レイヤー）、TiKV（行ベースのストレージエンジン）、PD（Placement Driver）のコンポーネントで実装された分散システムです。各コンポーネントで耐障害性を考慮すると全体で 8 台のサーバーが必要となります。

データのバックアップはサービス運用において必須の要件です。スナップショットと増分ログが取れますが、ゲームの場合には障害発生時に戻す場合があるのでポイントインタイム リカバリがあると良いと思います。解析用データの取得をする場合に、バックアップから新規クラスタの復元をサポートしているので、復元したクラスタからデータを取得できます。

TiDB で今回のサービス要件を満たせるため採用しました。開発フェースでは PingCAP 社と隔週でミーティングを実施していました。

mixi2 のタイムラインにはユーザータイムラインとホームタイムラインがあり、ホームタイムラインは POST した投稿を素早くフォロワーへ届ける必要があります。ユーザーのホームタイムラインは事前に Redis に作成しており、非同期で Redis へ書き込みしています。書き込みはパイプライン化して同時に 1,000 件書けるようにしています。

リリース前に負荷テストを実施し、API のレンテンシーを 100ms と厳しめの目標にしました。サービス名から一定以上のユーザーが来ることが想定されており Write 性能は代表的な RPC を 10,000 prs 出せるまで検証し、Read 性能はフォロワーのタイムラインへ 5 秒から 10 秒で表示されることを目標としました。負荷テストは Locust を使用して、ワーカーは並列度を上げるために boomer を使用しました。書き込み性能は TiDB、TiKV のスケールアウトにより、台数を増やして想定通りに向上しました。一部ロック待ちが発生しましたが、Redis 側へ書き込むことで解消しました。

障害テストではクラスタの台数を減らしても、問題無くリバランスすることを確認しています。

リリース日には想定を上回るリクエストが来たが各コンポーネントをスケールアウトで対応できました。正月など負荷の増大が見込まれる場合もスケールアウトで運用できており、今まで無停止でサービスを運用できています。一回 TiDB のにー度障害が発生しましたがサービスに影響しませんでした。

運用としては、in 句で複数要素を指定するとソートが効かないという問題が発生し、調査中ですが for 分を書いて実装側で回避しています。また、可用性向上のために、TiKV ノードを異なるラックへ配置しています。EC2 Placement Group で作成したパーティションを PD が理解できるように location-labels の設定をしています。

まとめは以下になります。

• 少ない人数の開発チームで、TiDB Cluster を使用したサービス開発と運用を行えている
  • 急激は負荷にもスケールアウトで対応できている
    • ドキュメントや監視ツールが揃っているため少人数チームでも対応できている
• 今後の展望
  • SQS と非同期ジョブを置き換えるため、TiCDC を使用してチェンジイベントをメッセージとして非同期処理したい

Ask the speaker

登壇者にセッションの内容について色々と伺いました。

導入した TiDB は TiDB Self-Managed で EC2 上に構築しているそうです。後で構成図を見返すと EC2 と記載があったり、レプリカ スケジュールで location-labels を設定していたりと、Self-Managed の機能を駆使していることが分かります。Self-Managed でも少人数のチームで運用できていることが驚きでした。

また負荷テストで、投稿がフォロワーのタイムラインに表示されるまでの時間が 5 秒から 10 秒であることを質問しましたが、同系の SNS など（X など）でも同レベルらしいと伺いました。UX とパフォーマンスを両立する目標値であり、得心しました。

さいごに

mixi2 というリリース時から注目度が高かったサービスを開発当初は 4 人（リリース時は 7 人）という少数精鋭で開発を行っておりサービスダウンもしていないという安定的な運用をしている事が分かり、かなりの驚きでした。また TiDB について細かい設定やコスト面で Self-Managed を少人数で安定して運用できているというのは、TiDB 自体のアーキテクチャやドキュメントの豊富さにあるのではないかなと思いました。