mixi2のアーキテクチャとNewSQLを検討した理由
姜氏はMIXIのSREグループでサーバーサイドとインフラ開発を担当している。冒頭、mixi2の概要について「短文テキスト型のSNSで、2023年3月頃に4名の開発者で開発が始まり、2024年12月16日にリリースしました」と説明した。
mixi2では「フォロー」タイムラインのほか、日本におけるSNSの先駆けである初代 mixiにあったコミュニティ機能や、よりリアルタイムなコミュニケーション向けのイベント機能を提供。実装言語はサーバーサイドにGo、モバイルクライアントにFlutterを採用している。
システム構成は、モバイルクライアントとサーバー間の通信がgRPCで行われ、データベースにはTiDBクラスターを採用。キャッシュとタイムラインのデータを保持するためにRedisのクラスタ構成を使用し、Webブラウザ向けにはConnect RPC用サーバーを運用している。通知機能にはRedis Streamsを、検索機能にはOpenSearchを採用。また一部の非同期処理はAmazon SQSとAmazon ECSのワーカーで実装されている。
姜氏はSNSを開発するにあたって求めた要件として、「リクエスト、ユーザーの増加に対応できるスケーラビリティ」「障害発生時のフェイルオーバー」「サービスとして許容できるレイテンシー」「トランザクション」「メンテナンスオペレーションの容易さ」「コスト」を挙げた。MIXIでは従来、RDBのシャーディングを使った開発運用の経験があったが、今回はこれらの要件をより満たせるデータベースとしてNewSQLの導入を検討した。
姜氏は「NewSQLとは、SQLインターフェースを持ち、従来のリレーショナルデータベースが持つトランザクションと強い整合性を保証する分散データベースです」と説明。TiDB、Spanner、CockroachDB、YugabyteDBなどが該当する。
NewSQLとRDBシャーディングを比較すると、トランザクション機能はどちらもあるが、分散トランザクションはRDBシャーディングでは限定的。レイテンシーは分散している分、NewSQLの方が大きくなる傾向があるが、耐障害性はNewSQLの方が強い。開発コストや運用コストも含めると、RDBシャーディングの場合は実装側でシャーディングを考慮する必要があり、不利だと姜氏は指摘した。
「インフラ費用については、少ない台数で始められるのでRDBシャーディングの方が有利ですが、NewSQLの場合はストレージリソースと計算リソースを独立して調整できるので、場合によってはNewSQLの方が安くなることもあります」
