1週間で120万人突破の「mixi2」──小規模チームで構築・運用を可能にしたNewSQL「TiDB」とは

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

　SNSサービスにおけるデータベース選定は、サービスの成長性と安定性を左右する重要な課題だ。2024年12月にリリースされた「mixi2」は、約1週間で120万人を超える登録者数を獲得。開発時からリリース直後の負荷を想定し、スケーラビリティと高可用性を実現するためNewSQLの「TiDB」を採用。本セッションでは、株式会社MIXIの姜明秀氏がmixi2のデータベース選定から運用に至るまでの舞台裏を詳細に解説。特に、SNSサービス特有のタイムライン実装の課題と、TiDBによる分散データベースの活用方法に焦点が当てられた。

mixi2のアーキテクチャとNewSQLを検討した理由

　姜氏はMIXIのSREグループでサーバーサイドとインフラ開発を担当している。冒頭、mixi2の概要について「短文テキスト型のSNSで、2023年3月頃に4名の開発者で開発が始まり、2024年12月16日にリリースしました」と説明した。

株式会社MIXI 開発本部 CTO室 SREグループ Software Engineer 姜 明秀氏

　mixi2では「フォロー」タイムラインのほか、日本におけるSNSの先駆けである初代 mixiにあったコミュニティ機能や、よりリアルタイムなコミュニケーション向けのイベント機能を提供。実装言語はサーバーサイドにGo、モバイルクライアントにFlutterを採用している。

　システム構成は、モバイルクライアントとサーバー間の通信がgRPCで行われ、データベースにはTiDBクラスターを採用。キャッシュとタイムラインのデータを保持するためにRedisのクラスタ構成を使用し、Webブラウザ向けにはConnect RPC用サーバーを運用している。通知機能にはRedis Streamsを、検索機能にはOpenSearchを採用。また一部の非同期処理はAmazon SQSとAmazon ECSのワーカーで実装されている。

mixi2のアーキテクチャ

　姜氏はSNSを開発するにあたって求めた要件として、「リクエスト、ユーザーの増加に対応できるスケーラビリティ」「障害発生時のフェイルオーバー」「サービスとして許容できるレイテンシー」「トランザクション」「メンテナンスオペレーションの容易さ」「コスト」を挙げた。MIXIでは従来、RDBのシャーディングを使った開発運用の経験があったが、今回はこれらの要件をより満たせるデータベースとしてNewSQLの導入を検討した。

　姜氏は「NewSQLとは、SQLインターフェースを持ち、従来のリレーショナルデータベースが持つトランザクションと強い整合性を保証する分散データベースです」と説明。TiDB、Spanner、CockroachDB、YugabyteDBなどが該当する。

　NewSQLとRDBシャーディングを比較すると、トランザクション機能はどちらもあるが、分散トランザクションはRDBシャーディングでは限定的。レイテンシーは分散している分、NewSQLの方が大きくなる傾向があるが、耐障害性はNewSQLの方が強い。開発コストや運用コストも含めると、RDBシャーディングの場合は実装側でシャーディングを考慮する必要があり、不利だと姜氏は指摘した。

RDBシャーディングとNewSQLの評価

　「インフラ費用については、少ない台数で始められるのでRDBシャーディングの方が有利ですが、NewSQLの場合はストレージリソースと計算リソースを独立して調整できるので、場合によってはNewSQLの方が安くなることもあります」