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

サーバーサイドエンジニアの宮脇です。
2025 年5 月 30 日 (金) に開催された TiDB GAME DAY 2025 に、今年も Cygames が登壇させていただきました。
TiDB GAME DAY は PingCAP 社が主催するゲーム業界向けの招待制イベントで、当日は 140 名近くのゲーム業界の方が参加しました。

今回行った発表のタイトルは「Shadowverse: Worlds Beyond にみる TiDB 活用術」です。
本発表では、TiDB GAME DAY 2025 に参加したデータベースに関わるエンジニアに向けて、本番環境で TiDB を運用するにあたってどのような工夫を行っているかをお話ししました。

タイトルにもある通り、2025 年 6 月 17 日にリリースされた Shadowverse: Worlds Beyond では、データベースとして TiDB Cloud を採用しています。
Cygames では TiDB のゲーム本番環境への導入は、この Shadowverse: Worlds Beyond が初めての事例となります。
本記事では、発表の内容を簡単に振り返るとともに、発表では触れられなかった補足情報をお伝えします。

TiDB 採用の背景

Cygames ではゲームのデータベースとして MySQL を長年使用してきました。
ゲームを長期間運用する上では、コスト最適化のため、負荷に合わせて柔軟にサーバーのスケールを行うことが求められます。
しかし、MySQL においてはスケールイン・スケールアウトを行う際、準備に数ヶ月かかるなど、スケールの難しさが課題となっていました。
そんな中で見つけたのが高い MySQL 互換性やスケーラビリティ、弾力性を持つ TiDB です。

TiDB の導入可否の判断のため、2021 年頃から TiDB の検証に着手し、機能検証や性能検証を実施しました。
機能面では、 TiDB は MySQL との高い互換性を持っており、既存の実装はほぼそのまま動作しましたが、細かい挙動の違いもありました。

性能面では、 MySQL と同じ実装では期待するスループットが出ませんでしたが、 TiDB に適したテーブル・クエリ設計を行うことで MySQL を上回る性能を実現できることが分かりました。
しかし、クエリのレスポンスタイムでは TiDB は MySQL よりも遅い傾向があります。
こちらはテーブル設計による工夫では完全な対応は難しいですが、例えば、クライアントと協力し通信をゲームの演出の裏で行うなどの工夫をすることで、ゲームプレイの体験に影響を与えないようにすることが可能です。

このような検証を経て、工夫をすれば TiDB は Cygames の多くのゲームタイトルで利用できると判断し、 Shadowverse: Worlds Beyond での採用に至りました。

一方で、ゲームロジックがサーバーサイドにあり、かつ通信頻度が非常に高いブラウザゲームなどでは、レイテンシがゲームの体験に大きく影響します。
そのようなゲームにおいて、ユーザーの体験を犠牲にしてまで TiDB を導入すべきかというと、難しいものがあります。
TiDB を採用するかどうかはゲームの特性や要件に応じて慎重に判断する必要があります。

TiDB の検証の詳細については過去の発表資料をご覧ください。

Shadowverse: Worlds Beyond での TiDB の活用

発表では、 API サーバ実装、データ運用、データ分析の 3 つの観点から TiDB の活用についてお話ししました。

API サーバ実装

TiDB は MySQL との高い互換性がありますが、挙動が違う点もあります。
そのうちの 1 つがトランザクションの挙動です。

トランザクション分離レベルの REPEATABLE READ では、一貫性読み取りの実現のため、スナップショットを取得し、トランザクション中の SELECT はこのスナップショットを参照します。
MySQL ではトランザクション中最初に実行した SELECT のタイミングで取得されます。
一方、 TiDB では BEGIN によってトランザクションを開始したタイミングでスナップショットが取得されます。
このスナップショットを取得するタイミングの違いにより、 MySQL で行っていたような実装をそのまま TiDB で使用すると Lost Update が発生する可能性がありました。

検討を重ねた結果、 REPEATABLE READ を使う必要がそもそもないことが分かったため、 TiDB では READ COMMITTED を使用することで Lost Update の問題を回避しました。

余談ですが、 MySQL を使っているプロジェクトにおいて、 MySQL 8.0 にアップデートするにあたってそれまで使用していた設定が使えなくなることが分かり、その対応のためトランザクション分離レベルを READ COMMITTED に変更する方針を取りました。
図らずも Cygames においては今後トランザクション分離レベルは READ COMMITTED を採用することで統一されることになりました。

データ運用

データ運用における工夫でも TiDB におけるトランザクションの挙動に起因する問題を取り上げました。
TiDB では、トランザクション中に更新されるデータは一度バッファに書き込まれ、 COMMIT 時に TiKV に書き込みます。
そのため、トランザクション中に更新するデータの量が多いとバッファにデータが入りきらず、トランザクションが失敗してしまいます。
TiDB ではこの問題を回避するため、 Non-Transactional DML や Pipelined DML といった機能が提供されていますので、メンテナンスやローカル環境での作業などではこれらを利用します。
プレゼント付与やデータ修正といったバッチ処理を行う際には、クエリでまとめて更新するのではなく、スクリプトを書いて 1 行ずつ更新することを推奨しています。
これはトランザクションサイズによるエラーの回避のほか、更新処理の柔軟性や証跡を残すことを目的としています。

データ運用については、もう 1 つ、データ削除の方法についても取り上げました。
Cygames では論理削除を採用していますが、削除済みのデータはデータベースに残り続けるため、データベースの容量削減のために定期的にデータを削除する必要があります。
MySQL ではパーティションドロップによる削除を行っていましたが、 TiDB においても同じ方法で良いのか、あるいは他の方法があるのかを検証しました。
検証の結果、 TiDB でも MySQL と同様、パーティションドロップによる削除が高速かつ軽量であることが確認できたため、この方法を採用することとしました。
TiDB では TTL のような便利な機能も提供されていますが、それがどのように実現されているのか、仕組みを理解し、実際に検証することが重要です。

データ分析

TiDB には TiFlash という列指向ストレージがあり、 OLAP 用のクエリを高速に実行することができます。
しかし Cygames では既に分析基盤として Snowflake を利用しています。
また、容量削減のためログデータは S3 に保存しているため、そもそも TiDB クラスター上に分析に必要なデータが存在しません。
以上の理由から、現時点では TiFlash を利用した分析は行わず、既存の Snowflake による分析を行っています。
一方で、現在の分析基盤周りの構成が最善だとは考えておらず、今後もより良いものを目指して他部署とも連携しながら検討を続けていきます。

最後に

数年にわたる TiDB の検証により、 Cygames のサービスを支えるのに十分な性能やスケーラビリティを備えた有力なデータベースであることを確認しました。
Shadowverse: Worlds Beyond では TiDB Cloud を採用し、本番での運用開始後も TiDB は期待通りの活躍を見せています。
リリース後の様子や運用の詳細については、今後機会があれば共有したいと考えています。

Cygames は「最高のコンテンツを作る会社」というビジョンを掲げています。
我々サーバータスクチームとしては、使用するツールの性能を最大限に引き出すことが最高のコンテンツを作ることにつながると考えています。
そのため、新しい技術については時間をかけて検証し、仕組みを理解した上で活用することを重視しています。

私たちと一緒にツールや技術の検証を通して最高のコンテンツを作りませんか？
サーバーサイドエンジニアの採用情報はこちらをご覧ください。