カプコンが“AAAタイトル”を支える共通基盤に「TiDB」を選んだ理由　無停止基盤のつくりかたとは

「シャーディング」と「メンテナンスによる停止」からの脱却へ

　AAAタイトルを支える共通基盤は、ユーザー情報を扱う専用のサーバーを必要とするクロスプラットフォームやゲーム内通貨などの機能を提供している。このシステムでは個人情報が管理されており、24時間での監視も必要だという。

　この共通基盤を導入する目的は、各タイトルでクリエイティブなものづくりに専念できるようにするため、開発・運用を一元化することにある。共通基盤は、アカウント管理、プロフィール管理、同意規約管理、ゲーム内通貨・DLC管理、CAPCOM ID会員情報管理という、5つのサービスで構成されており、これまでに2つのシステムでTiDBへの移行が完了している。

　これまでの共通基盤には、Amazon Aurora MySQLを利用してきた。カプコンの福井勝貴氏は「この環境で大規模なユーザー数に対応するには、シャーディングを必要とし、パッチ適用やアップグレード、スペック変更のたびにサービス停止をともなうメンテナンスが必要だった」と説明する。

　そこで、新たにクロスプラットフォームの展開を検討する際、より拡張性があり、シャーディングを意識しないデータベースの導入が不可欠だと判断。このとき候補となったのが「TiDB」だ。柔軟な拡張性によるコストの最適化だけでなく、停止をともなうメンテナンス頻度の低下、シャーディングの排除といった効果も期待された。

　PingCAPが開発するオープンソースソフトウェアのTiDBは、MySQL互換の分散データベース（NewSQL）であり、ノードを増やすことで容量や性能を拡張できる。また、バージョンアップやテーブルのカラム追加などのメンテナンス作業においても、「ローリングアップグレード」が可能だとPingCAP Japanの林正記氏は話す。

　こうしたTiDBの特徴は、ゲーム業界だけでなく金融業界など、高い可用性が求められる分野で評価されている。このような実績からも、複数タイトルを支える共通基盤との親和性が高いと判断された。

MySQLとの「互換性の壁」を乗り越えた、数々のチューニング

　TiDBへの移行において、最も大きな課題となったのは“MySQLとの互換性”だった。特に「AUTO_INCREMENT」の仕様の違いが懸念されたと福井氏は語る。TiDBは、MySQLと100％の互換性があるわけではなく、ストアドプロシージャやトリガーなど、一部機能はサポートされていない。

　たとえば、AUTO_INCREMENTに関して、TiDBのデフォルト設定ではIDの発番が完全に昇順にならないため、MySQLと異なる挙動を示す。これは発番部分のボトルネックを避け、スケールさせるための設計であり、“MySQL互換モード”を採用すれば昇順となるが、ストレージへの書き込み時には、単一ポイントに負荷が集中する「ホットスポット」の可能性や、更新性能にも上限が発生する。

　そこでカプコンは、グローバル展開とクロスプラットフォーム対応を進める上で、「Auto_Random」というTiDBの独自機能をAuto_INCREMENTで採用した。これはIDをランダムに発番することで、データがTiKVノードに分散して保存されるというもの。これによりホットスポットの発生を抑制し、パフォーマンスとスケーラビリティを最大化できる。当初、MySQL互換モードやMySQL互換モードでのホットスポット回避も検討されたが、最終的にはパフォーマンスとスケーラビリティを重視し、Auto_Randomが最適と判断された。

　カプコンではTiDBへの移行検証の結果、アプリケーション側に致命的なエラーの発生はなく、RPS/QPSにおいても想定以上の性能がでることを確認している。クエリの応答時間はAurora MySQLと比較して若干遅いものの、許容範囲内に収まった。また、オンラインでのバージョンアップや構成変更、リプレースに向けたデータ移行も正常に実施できることを確認し、全体としてコストの最適化・削減が見込めることも判断できたという。

　さらに導入時には、さまざまな工夫と性能改善に取り組んでいる。アプリケーションのユニットテストでは、プライマリーキーが乱数になることにともない、リスト比較のクエリで順序違いが発生する。そのため、明示的に「ORDER BY」を使用するか、あるいは集合比較するように改修された。ローカル環境でのDDLがMySQL時と比較して遅い、という課題に対しては、TiDB v8.3.0へのバージョンアップと特定のパラメーター設定によるチューニングで、約105秒から約22秒へと大きく改善している。

　加えて、TiKVのI/Oの遅延やコミットの遅延がCPU使用率70％を超えたとき顕著になる問題に対しては、TiKVストレージのチューニングとして、非同期I/Oの有効化と同時処理数の増加を行った。これによりコミットの応答時間は20〜40％改善し、CPU使用率70％以下でのQPSは10〜15％向上。ただし、これらの設定変更は運用上の注意が必要だと福井氏は注意を促す。

　コネクションプーリング・維持においては、ProxySQLの設定次第で、ノードの追加時やローリングアップデート後の再起動したTiDBノードへの接続がうまくいかない問題が発生した。これを解決するためにProxySQLやアプリケーション側でのコネクション維持のチューニングを行い、比較検証を実施、アプリケーション側でのコネクション維持は管理が難しいため、ProxySQLを利用している。コミュニケーションプーリングや維持を導入することで、TiDBノードのCPU使用率を25〜50％削減できることが確認でき、ノード台数削減によるコスト削減効果も期待できたという。

2時間で完了したデータ移行　46%のコスト削減効果

　データ移行とリプレースにおいて、当初はDM（Data Migration）機能がManagedサービスとしてリリースされていなかったため、DumplingとImportツールが利用された。データ移行方法としては、まずDumplingでAuroraからデータを取得してS3にアップロード、TiDB Cloud Dedicatedクラスターにスキーマを作成し、その後TiDB CloudのImport機能でTiDB Cloud Dedicatedに反映するという流れだ。

　移行検証では、スキーマの作成・更新の状況によってAuroraとTiDBでテーブルのカラムの並び順が異なり、プライマリーキーやユニークキーの重複エラーが発生する問題に直面。これはDumplingのデフォルト設定では、カラム名なしでデータが出力されるためであり、解決のためDumpling使用時に「--complete-insert」オプションを付与してカラム名を含めることで、この問題を回避している。

　実際のリプレース作業は、データ移行を含め約2時間で完了した。成功した最大の要因は、本番環境を想定したリプレース手順の作成、開発などの各環境での本番環境のリプレースを想定したリハーサルを繰り返し、さらに本番直前でのデータ移行テストによる最終確認と必要時間の算出にあった。

　運用面では、TiDBとTiKVのCPUが70％を超えると、パフォーマンスが劣化する傾向があることが性能試験で判明。TiKVでは、データリバランス時にコミットの遅延が発生することもあった。TiKVは、8コアよりも16コアのインスタンスのほうが性能は良かったとして、コスト効率の観点からは8コアが良いものの、カプコンでは16コアを優先して利用する方針とした。TiDBやTiKVのCPU使用率が70％を超えた場合には、TiDBはスケールアウト、TiKVはスケールアップするようにしているという。

　また、オペレーションの比較において、TiDBはオンラインでの変更をサポートしているものの、負荷が高い状況では構成変更にリスクがともなう可能性があり、メンテナンスによる停止が必要な場合もあるとカプコンは考察している。そのため、負荷が高くなる前に対応することや、監視体制の強化が重要だとした。特にバージョンアップに関しては、PingCAPへのサポート依頼が必要なため、早めの調整を推奨する。

　Aurora MySQL利用時は、スペック変更にともなうシステム停止を避けるため、一つ上のスペックを採用していたが、TiDBへの移行でスペック変更が容易になったことでコストの最適化と削減を実現。リプレース直後には、あるマイクロサービスで46％のコストカットを達成したという。

　さらに非本番環境では、ステージング環境のみ本番と同じDedicated構成を採用し、それ以外の開発・QA環境などではTiDB Cloud Stater（旧：TiDB Cloud Serverless）を活用することで、想定よりも安価な運用を実現。「TiDB Cloud Starterは5台まで無償枠があるため、これを活用することでさらに費用を抑えられる可能性もある」と福井氏は述べる。

「メンテナンスを意識しない環境」が最大の成果

　TiDBの導入は、メンテナンスを意識せず作業ができるようになった点が最大の成果だったと福井氏は振り返る。2024年9月から2025年5月までの間、本番環境で10回の構成変更やアップグレード作業があったが、これらはすべてメンテナンスを回避して“オンラインのまま”実施された。また、クエリによってプライマリとレプリカを切り替える必要がなくなったため、開発も簡素化されている。

　もちろん、今も模索している点もある。たとえば、TiDBノードが多い場合、スペック変更に時間がかかる（ローリングで1台ずつ変更されるため、3〜4時間待つ必要がある）ことも、その一つだ。回避策としてノードを1台に減らして変更する方法もあるが、これは負荷試験環境など限定的な状況でのみ可能だという。

　講演の最後には、福井氏からPingCAPに対して、TiDB Cloud DedicatedとTiDB Cloud Starterの中間的な製品の提供、Terraform APIの機能拡張（よりきめ細やかな権限設定、Starterインスタンス作成台数の上限撤廃、スペック変更対応）、サードパーティ製監視ツールとの連携強化、TiDB Cloud StarterへのDB監査ログ機能の追加、コンソール監査ログの自動アップロード機能などが要望として挙げられた。

　こうした要望を認識しているとして、林氏はPingCAPが今後も積極的に改善に取り組んでいくとして締めくくった。