デジタルカードゲーム「Shadowverse: Worlds Beyond」が、TiDBでリリース時のアクセス急増をいかにしてノーメンテで乗り越えたか［PR］

Cygamesは、「最高のコンテンツを作る会社」というビジョンの下、スマートフォンゲーム、コンシューマーゲーム、アニメ、マンガ事業など多岐にわたるコンテンツ制作を手掛けている企業です。

今年（2025年）10月に開催されたNewSQLデータベースTiDBの最新動向やベストプラクティスを学ぶことができる「TiDB User Day」では、同社が展開する人気ゲームの1つ「Shadowverse: Worlds Beyond」（以下、シャドバWB）のTiDB導入事例が紹介されました。

シャドバWBは、2016年にリリースされたデジタルカードゲーム「Shadowverse」の後継作として今年6月に全世界に向けてリリースされ、約2週間で全世界累計100万ダウンロードを達成し、2025年10月時点で300万ダウンロードを突破しています。

イベントでは、同社のサーバーサイドを担当している青木淳氏が、同ゲームで採用された分散データベースであるTiDB（タイデービー）がもたらした効果について説明。

人気ゲームとなった同ゲームのバックエンドデータベースは、どのように選択され、設計と運用がなされたのか。講演内容のポイントを紹介しましょう。

従来のデータベースが抱えていた2つの課題

シャドバWBのバックエンドは、クラウドはAWS、コンテナはAmazon ECS（Elastic Container Service）で管理されています。

そして、ユーザーデータなどを管理するデータベースにTiDBが採用されています。

なぜTiDBが採用されたのか。従来のデータベースには主に2つの課題があると青木氏は指摘しました。

1つ目は負荷増加に対するジレンマです。システム負荷が許容範囲を超えたとき、サービス品質を維持するためにはシステムスケールが必要ですが、従来のデータベースではそのためにサービス停止を伴うメンテナンス時間が必要となってしまいます。

「最高のユーザー体験を提供する」という同社のミッションに対して、「メンテナンス時間によりユーザー体験を損ねる」というジレンマがありました。

2つ目は複雑化の悪循環です。ユーザーが増加することで単一データベースでの処理が限界になると、水平分割（シャーディング）という手法により、複数のデータベースに負荷を分散する必要があります。

しかしそれによりシステムが複雑化し、データリバランスが必要になるなど運用コストが上がっていく悪循環を招きます。

従来のデータベースが抱えていた課題を解決するため、Cygamesはシームレスなスケーリングを実現するデータベースの調査・検証を進めました。その結果、採用されたのが分散データベースの1つであるTiDBでした。

TiDBが選択された3つの理由

TiDBが選択された理由は大きく分けて3つ。

1つ目は、データの完全性を担保できることです。データベースをスケールする際、従来のデータベースではシャーディングがゲーム業界の一般的な手法です。

ただし、複数のシャードにまたがるトランザクションでデータの完全性を担保することが運用上の課題であり、これまではアプリケーションレイヤーの実装で補う必要がありました。

その点、分散データベースのTiDBであれば「性能のスケール」と「トランザクション機能」をより高いレベルで両立できます。

2つ目の理由。MySQL互換インターフェースを採用している点が挙げられます。

CygamesではこれまでMySQLを使用してきたため、インターフェースの知識と既存のエコシステムを活かしながら、TiDBの分散データベースとしての利点を享受できます。

3つ目は、サーバーリソースを効率的に活用できることです。TiDBはコンポーネントごとのCPU、ストレージなど必要なリソースを個別にスケールできるため、タイトルのライフサイクルに沿った合理的な運用が可能になります。

この合理的な運用は、ユーザーに長くゲームを楽しんでいただく上で、大きな利点になります。

MySQLとTiDBにどのような違いがあるか

TiDBはMySQL互換インタフェースを備えていますが、内部アーキテクチャは根本的に異なります。そのため、TiDBの性能と効率性をしっかりと活かすためには、開発メンバーがTiDBのアーキテクチャについて理解を深める必要がありました。

CygamesではそのためにTiDBの調査・検証を行った横断チームが社内勉強会を開催し、新規既存プロジェクト問わず多くのメンバーがそれに参加し、TiDBの理解を深めていきました。

では、MySQLとTiDBにはどのような違いがあり、どう実装を変える必要があったのでしょうか。

ホットスポットの違い
従来のデータベースでは、ホットスポットが発生した場合、運用側の手動操作によってシャード数を調整することで対応していました（メンテナンスを伴う高コストな作業です）。

一方、TiDBは自動でシャーディングを行う仕組みですが、特定ノードにアクセスが集中するとホットスポットが発生します。

そのためTiDBでは、特定ノードにアクセスが集中しないように、あらかじめワークロードに適した分散キー（Primary Key）を設計することが重要になります。

インデックス設計
ホットスポットを回避することが改善ポイントとなるのですが、あわせて、読み取り性能を追求するオンラインのゲーム処理においてデータが分散しすぎていると、複数回のリモートアクセスが必要となり性能が劣化する可能性があります。

そのため、シャドバWBのワークロードにおいて有効なのが、ユーザー単位でデータを集約することになります。

つまり、無秩序にデータを分散するのではなく、以下を考慮する必要があります。

• トランザクションの参照/更新範囲のデータを集約する（ミクロで集約する）
• 多数の集約したデータをそれぞれのノードに分散し、全体的にはアクセスを分散する（マクロで分散する）

この考え方に則り、分散キー（Primary Key）を設計することで、ホットスポットの回避と読み取り性能を両立できます。

例えば下記のように、ユーザーが所持しているギフトデータを扱う「プレゼントBOX」のテーブルでは、user_idをPrimary Keyにすることで、ユーザー単位でデータを集約できます。その結果、同じユーザーIDのデータは同一ノードに集約されることが期待できます（そして、複合キーのULIDは、効率よく時系列順にデータを取得する工夫です）。

※詳しくは下記のCygames Engineers' Blogをご覧ください

参考：【TiDB GAME DAY 2024】TiDBにおけるテーブル設計と最適化の事例

トランザクション分離レベルの違い

もう1つ、MySQLとTiDBの注意すべき違いとして「トランザクション分離レベル」があります。

両者ともデフォルトは「REPEATABLE READ」ですが、スナップショットが取得されるタイミングが異なります。MySQLはSELECTの実行時、TiDBはトランザクションの開始時になります。

そのためTiDBでは、MySQLと同じ認識でアプリケーションを実装すると、他のコネクションで更新した値を上書きしてしまう可能性があります。

そこでシャドバWBでは、スナップショット取得タイミングの違いを解消するために、調査・検証した結果、最もパフォーマンスが良いトランザクション分離レベルを「READ COMMITTED」にする方法を選択しました。

※詳しくは下記のCygames Engineers' Blogをご覧ください

参考：【TiDB GAME DAY 2025】Shadowverse: Worlds Beyond にみる TiDB 活用術

リリース日の昼のピークをスケールアウトで対応

こうしてついにシャドバWBのリリース日を迎えることになります。リリース時のトラフィックを予測して備えるのはもちろんですが、万が一予測以上のシステム負荷が発生していても安定したサービスを提供する必要があります。

青木氏は、今回のリリースではサーバーリソースの最適活用を重視し、基本は調整しやすいスケールアウトを軸にしながら、状況に応じてスケールアップも取り入れる戦略で臨んだと説明しました。その結果、ノーメンテで安定したサーバー運用を実現できたと述べています。

下記はリリース日の昼のピークタイムにおけるAPI サーバーのCPU使用率を示しています。

12時過ぎに負荷が横長の赤い帯に示された領域にまで上昇したため、他のメトリクスの結果も考慮した上でAPIサーバの台数を1.5倍に増強。スケールアウトによって無事に負荷が低下し、ピークタイムを乗り切ったことが示されています。

下記は同時間帯におけるTiDBのCPU使用率です。

APIサーバーほど急激な負荷上昇はありませんが、それでも上昇が続いていました。そこでTiDBコンポーネントを1.2倍に増加させるスケールアウトを実行しています。

いずれのスケールアウトもエラーなどは発生せず、無事に昼のピークタイムを乗り越えました。

夜のピークタイムをスケールアップで無事に乗り切る

リリース日の夜にもピークタイムがやってきます。このときにはデータベースの負荷増大に備えて、TiDB内部のキーバリューストアであるTiKVの各ノード性能を強化するスケールアップを実行しています。

スケールアップを選択した理由は、ノードを追加するスケールアウトではデータの偏りが起きないようにノード間でのデータの再配置が発生し、ノード間のトラフィックやCPU負荷などの性能低下が発生することが予測されたためです。

下記のグラフは左右2つともTiKVのメトリクスです。左がCPU使用率、右がメモリの使用率になります。

右のグラフの赤い枠の部分でグラフが1本ずつ下に落ちてから右肩上がりになっています。これが、TiKVの各ノードがローリングアップデートによってスケールアップしていることを示しています。

この時間帯でQPS（Query Per Second）は40万ほど出ていましたが、これだけの処理をしつつエラーもなくスケールアップができました。

その後QPSは最大で50万ほどに到達しましたが、システムは安定したままリリース日を無事に乗り越えることができました。

後日談として、QPSの最高値はこの後60万、65万と更新されています。しかしリリース日も含めていずれの日もTiDB TiKVの負荷は特定のノードに集中することなく、バランスよく分散されていました。

これは前述したように、TiDBとMySQLの違いを意識したテーブル/インデックス設計がうまくいったからであると、青木氏は振り返ります。

データベースのスケールがすごく楽に

青木氏は続けて「これは個人的な感想なんですが、従来の形であればデータベースのスケールにはアプリケーション開発者による事前準備や分割した後のデータ確認など諸々作業が発生しました。

しかし、今回のシャドバWBのリリースでは、従来と比べるとデータベースのスケールがすごく楽になったなと感じました」と、シャドバWBにおけるTiDB採用は成功だったとして講演を終えました。

≫TiDB | MySQL互換の分散型データベース | PingCAP株式会社

（本記事はPingCAP Japan提供のタイアップ記事です）