【TiDB User Day2025フォローアップ】リリース時のアクセス急増をいかにしてノーメンテで乗り越えたか 〜『Shadowverse: Worlds Beyond』におけるTiDB採用のゲームサーバー設計〜


こんにちは、サーバーサイドの青木です。
TiDB User Day 2025で「リリース時のアクセス急増をいかにしてノーメンテで乗り越えたか 〜『Shadowverse: Worlds Beyond』におけるTiDB採用のゲームサーバー設計〜」 というタイトルで講演を行いました。
ご参加・ご視聴いただいた皆様、ありがとうございました。

当日の資料はこちらです。

この記事では当日講演した内容のフォローアップをお伝えします。

TiDBでデータの完全性を担保とは

データベースをスケールする際、従来のデータベースではシャーディングを行う形がゲーム業界の一般的な手法です。
ゲーム業界では、複数のシャードにまたがるトランザクションでデータの完全性を担保することがデータベース運用における1つのテーマでしたが、アプリケーションレイヤーの実装の工夫などで実現してきました。
そして分散型データベースのTiDBであれば「性能のスケール」と「トランザクション機能」をより高いレベルで両立することができると考え、選択しました。

TiKVのスケールアップ

TiKVを1段階上位のスペック(おおよそ2倍)にスケールアップしました。

左のグラフの赤枠部分は、スケールアップのオペレーション実施後にTiDBが管理しているメタデータが瞬時に変更されたことを示しています。しかしこの時点ではまだノードの性能は変更されていません。

右のグラフの赤枠部分が、実際にインスタンス性能が変更されているグラフでローリングアップデートされています。
アップデートしている時間帯では40万QPSほどありましたが、エラーなくスケールアップができました。

負荷分散

リリース日の50万QPS、以降も60万、65万と最高値は更新されていきました。
しかしいずれの日もTiDB、TiKVは1つのノードに集中することなく、バランスよく負荷が分散されていました。
これはP.31 テーブル設計例P.32 別途登壇資料にある、TiDBの特性を意識した設計の結果だと考えています。
今後の設計時に参考にしていただければ幸いです。

統計情報の履歴

統計情報はMySQLでもTiDBでも、テーブルごとにデータの追加・更新が閾値を超えると自動的に更新され、実行計画を立てる際に参照されるもので、ほぼ全てのデータベースで利用されている仕組みです。
TiDBは統計情報の「履歴」をもっており、これがメモリをひっ迫したので、「履歴」の保存はオフにしました。
※「統計情報の履歴」は過去統計情報とも言います。

TiDBを使ったプロダクトでリリースを迎える

『Shadowverse: Worlds Beyond』は、リリース日から期待以上の反響があり、プロダクトとしては大成功を収めました。しかし、その反面、システムは許容範囲を超えそうな状況となりました。

そこで、ECSとTiDBを活用した柔軟なスケーリングを実現したシステム構成を活かし、サービスを停止することなく、ノーメンテでスケール調整を実現して乗り越えました。

従来のデータベースでは、スケールする際にデータベース分割のためのさまざまな作業が発生していました。しかし、今回TiDBを採用したことで、シャーディングをアプリケーション層で管理する必要がなくなりました。その結果、アプリケーション開発者側での作業はほとんど不要となり、迅速かつ容易にデータベースのスケールが可能になりました。

また、リリース日に期待以上の反響があったプロダクトにおいて、サービスを停止することなくシステムを安定化できたことは、非常に大きな効果でした。

おわりに

本記事では、新たに『TiDB』を採用した結果、『Shadowverse: Worlds Beyond』にどのような効果をもたらしたかをご紹介いたしました。

『Shadowverse: Worlds Beyond』は、データベースにTiDBを採用したことをはじめ、新しい技術にチャレンジしたプロダクトでした。新しい技術に挑戦するにあたり、さまざまな検証・調査を重ね、万全の体制でリリースを迎えることができました。チーム・サイゲームスはこれからも挑戦を続け、最高のコンテンツをお届けします!

最後に、サーバーサイドセクションでは、ゲームの開発・運用を通じて「最高のコンテンツ」を実現する仲間を募集しています。
もし、ご興味をお持ちいただけましたらこちらの採用ページをご覧ください。