sponsored by PingCAP株式会社 | 制作：Publickey

日常的に多数の同時アクセスが発生し、大量のデータが蓄積されるオンラインゲームのバックエンドは、データベースにとってもっとも過酷な環境の1つだといえます。

このバックエンドデータベースとしてよく使われているのがMySQLデータベースです。しかしその使われ方は一般的なMySQLとは異なり、データベースを細かく分割して多数のサーバに負荷を分散するシャーディングと呼ばれる仕組みを構築するなど、複雑なシステム構築と運用が行われているのが現実です。

そこで急速に注目度を高めているのが、MySQL互換でありつつ分散データベースの機能を備え、シンプルなクラスタ構成で高い負荷に耐える、いわゆる「NewSQL」と呼ばれる分野の代表的なデータベースの1つである「TiDB」（タイデービー）です。

2023年7月7日に行われた「TiDB User Day」では、国内の主要なオンラインゲームの開発に関わる企業からエンジニアが集まり、現在のバックエンドの状況とTiDBの評価が本音で語られるパネルディスカッション「ゲーム業界のデータベースを覗いてみよう」が行われました。

そこでの議論の内容をダイジェストで紹介しましょう。

ゲーム業界のデータベースを覗いてみよう

林氏：本日最後のセッション「ゲーム業界のデータベースを覗いてみよう」というタイトルで、ゲーム業界の状況を知り、楽しんでいただくセッションです。

お招きしているのは、ワンダープラネット様、スクウェア・エニックス様、Cygames様でTiDBの検討や検証を開始されている方々です。まずは自己紹介をお願いします。

NewSQLに対する期待とは？

中山氏：ワンダープラネット中山です。エンジニアリング・デザインマネジメント室で全社的なサーバ、クラウドインフラ技術調査、選定をしていて、TiDB Cloudの調査選定、導入指導をしています。まだ運用には入っていませんが、開発で使おうとするところまで進みました。

弊社はスマートフォン向けゲームを開発しています。ゲーム業界ではパブリッシャーさんがゲームの販売やプロモーションを担当し、デベロッパーがゲームの開発・運用を担当します。弊社はデベロッパーにあたり、テーブルのクエリの開発、データ構造を考えたりします。

弊社のデータベース事情ですが、ゲームのデータはたまり続け、消えることがありません。古いデータでもアクセスがあり、数億、数十億レコードをさばくので負荷が高く、水平分割や垂直分割、シャーディングをリリース時から行い、負荷分散を考えて開発する必要があります。

運用が開始すると月に数回メンテナンスを入れて、そのタイミングでDDL実行、データベースのメンテナンスをします。こうしたデータベースのメンテナンスに縛られるのが課題でしたので、New SQLのTiDB Cloudを検証しました。

神津氏：スクウェア・エニックスの神津です。情報システム部 SocialGame Infrastructureチーム（通称SIG）に所属し、ソーシャルゲーム系のインフラを構築しています。弊社にはMMOもありますが別チームなので、ソーシャルゲーム周辺の話になります。

ゲームタイトルに応じてオンプレとクラウドを使い分けています。元々は国内系パブリッククラウドから使い始め、コロナ禍の少し前ごろからAWS、さらにGoogle Cloudを主要なクラウドとして使うようになりました。

昔はIaaSでMySQLのレプリケーションでシャーディングしていて、1プロジェクトで100台とかもありましたが、今はAWSのAmazon AuroraやGoogleのCloud Spannerにまとまってきています。

最近ではこれらのPaaS DBが増え、「PaaSなら我々でできます」というデベロッパーさんも増えてきて、お任せするケースが増えています。デベロッパーさんでインフラのエコシステムを全部作れるので、レビューして性能要件を詰めるところまで一緒にやりましょうとお任せするケースもだいぶ増えてきています。

内部的にはMySQLが本当に多く、一時はNoSQL、MongoDBも増えましたが、直近では大きな案件の成功事例もあり、NewSQLが増えています。

というのもIaaSでMySQL、PaaSでAuroraを使っていた時はトランザクションをこなすためにひたすらシャーディングしていましたが、つらくなってしまいました。そこで、NewSQLに魅力を感じて移行したいという話が出ています。

林氏：NewSQLへの期待感とはどんなところでしたか？ MySQLでできなかったことを代替するような？

神津氏：リリース直後だと非常に負荷が上がるのでMySQLだとひたすらシャードを増やさないといけない。けれど負荷が下がり、アクティブユーザーが定着してくれた時にベースラインの負荷が見えてくると「このシャードもいらないよね」となった時、どう扱うかは非常に面倒です。

NewSQLならそこは割と簡単にできるのかなと期待しています。

1秒間に300万クエリを頑張ってさばいている

宮脇氏：Cygames サーバサイドエンジニア 宮脇です。今までプロジェクトでサーバサイドの開発・運用に携わった後、サーバサイドの横断的なチームに移動して、現在は検証をやっています。

CygamesでもMySQLを採用していて、データベースの水平分割や垂直分割で多数のシャードに分割し、MySQLサーバをたくさん並べて負荷分散しています。

各シャードのデータベースはそれぞれマスター1台とレプリカ2台ぶら下がっています。サービスからはマスターしか参照していません。レプリカは冗長化のための待機系や、管理ツールからの参照、分析基盤へのデータ取り込みのためのETLソースとして使っています。

あるサービスでは多い時に300万QPSほどクエリが流れていたりします。

林氏：300万QPSだとシャードが何セットになりますか？

宮脇氏：プロジェクトごとに違うのですが、あるプロジェクトだと64分割したシャードとなっています。つまりマスターとレプリカを合わせて64×3台となります。MySQLサーバをたくさん並べて頑張ってさばいている状況です。

大規模分散データベースのコストをどう見る？

林氏：各社のシステムそれぞれに違いがあることが分かりましたが、その中でTiDBに注目いただいている状況も分かっていただけたかと思います。

あらためてTiDBを紹介すると、アプリケーションからはMySQLプロトコルで見えて、ACIDをサポートし、コンピュータとストレージのレイヤでオンラインでスケールアウトして、HAの機能もデフォルトで持っている、というデータベースです。

さて、大規模なデータベースを構築すると同時につきまとうのがコストです。

あるデータベース製品やサービスを使おうとする時に、判断すべき大きなファクターとして「コストメリットがあるか」が問われるかと思います。それぞれどのようにお考えでしょうか。

中山氏：ワンダープラネットでは、TiDBの導入を検討するに当たって単純にコストメリットがあるかよりも、データベースの水平分割や垂直分割によるシャーディングをしなくてもTiDBのクラスタを単純にスケールアウトすることで大量のライトをさばけるようになるため、管理コストでメリットがあると感じています。

シャーディングしても、サービスが続いていくとリソースが偏るとか、サービス自体の経済状況が変化するとか、イベントでユーザーさんがバーンと来たり、逆に下がったり。そうしたときに調整や管理が必要になるので、そうした管理面がTiDBだとスムーズにできると感じています。

分割数を調整する時、シャードをマージする時、ワンダープラネットではサーバエンジニアがインフラを見ています。サーバエンジニアの手で、いつデータベースをマージするか計画して、テストしてなどの作業が1カ月ぐらいかかります。その間サーバエンジニアの開発の手が止まるので、機能改善や開発が止まるところが課題でしたので、そこに関してはメリットがあるかと感じています。

そもそも、データベースをシャードに分割する時に、どう分割すれば最適なのか？ をいちいち開発者が考えるのは工数がかかりますし、分割時のミスや不具合が起る可能性もあります。

TiDBならクラスタをスケールするだけなので、そうした工数やミスが防げるところにかなりメリットを感じています。

金額的にも試算をしたところ、現行のAuroraを分割するのと、TiDBに全部まとめるのは同程度になるかなと見ています。

ただし先ほども申し上げたとおり、金額的には同程度でも開発や運用面でのコストメリットがあると感じています。

林氏： シャーディングはものすごいアクセスが来ることも予想してオーバースペックめにサイジングしなきゃいけないのかなとか想像します。

中山氏：そうですね。メンテナンスのタイミングでしかシャーディングのスケールを変えられないので、基本的にはオーバースペック気味にしておく必要があります。ですので、結構大きめにしています。

分散型ならではの高い可用性。分析用データベースが不要になると期待

林氏：スクエニさんはいかがでしょうか。

神津氏：やはり運用コストは非常に気にしてまして、TCOの観点でTiDBが他のPaaS DBと比較してどうか。

Amazon Auroraは非常に便利に使わせてもらっているんですけれども、サービス更新でインパクトの大きいものだとデータベースの再起動が発生するケースがあります。

ワンダープラネットさんもメンテナンスの手配を1カ月前からするという話がありましたけれど弊社も似たような状況で、再起動するとなるとゲームのメンテナンスのサイクルに合わせてどこでやるかを盛り込んでいます。

Amazon Auroraに限らず、書き込み性能に余裕を見る必要があるため、シャード分割して、役割ごとにも分けているので、結果としてデータベースをいっぱい抱えてしまいます。

そうすると障害が起こるポイントを多く抱え込んでしまうことになってしまいます。

そのため、TiDBでは障害に対する耐久性とか対抗性の部分でTCOメリットが改善するところや、オペレーションコストが下がるところに非常に期待しています。

もう一点。例えば稼働中のデータベースに対してデータ分析をしたい場合には、影響が出ないようにクローンを作ってそちらで分析する、みたいことをやらざるを得なくなります。

しかしTiDBでは分析用のTiFlashがあり、かつヒント句でTiFlashだけ使うようにすれば本番データベースには負荷がかからないと聞いています。

そうすると分析用の余計なデータベースを抱え込む必要がなくなるので、そこでコストメリットが出るのではと非常に期待しております。

林氏：宮脇さんはいかがでしょうか。

宮脇氏：サービスを運用していて、たくさんのユーザーの方に遊んでいただくと、ストレージや計算リソースが逼迫してきます。そうするとスケールアウトしたくなる。

現状ではスケールアウトするにはメンテナンスが必要になり、Cygamesだとメンテナンスはプロジェクト側のサーバサイドエンジニアが担当します。

自分が担当した例だと、ここでエンジニア数人が準備に2～3カ月拘束されます。その間は新機能の開発が止まってしまいます。

そこでTiDBを使えば、柔軟で簡単にスケールアウトできるようになり、このメンテナンスの準備コストとか工数が浮くと期待しています。その分、エンジニアを新機能の開発に充てられる。そこが達成できると嬉しいと考えてます。

スケーラビリティや性能、互換性の評価は？

林氏：こうした期待をいただきつつ、各社様はすでに検証や実証フェーズに入っていただいてるかと思います。そこで、検証・実証実験を通じて分かったことを教えてください。

中山氏：ワンダープラネットとしては、シャーディングなしで高いスケーラビリティを実現できることを期待していたので、その辺の性能と運用コスト、学習コストが問題ないかと検証しました。

結論としては問題ありませんでした。性能からいきますと、Webにゲーム業界の事例が上がっており、この前Cygamesさんが講演されてた内容が記事で公開されていました。基本的な性能はそうした資料を参照するとつかめるかなと思います。

ワンダープラネットはSysbenchを使い、ライトがスケールするかを検証しました。Sysbenchをかけながらスケールアウトさせていくと基本的には線形にきれいにスケールしていて、問題ないところが確認できました。

弊社で採用するとなったら、インスタンスの面倒を見る人員がいないので、基本的にマネージドサービスのTiDB Cloudを利用させてもらうことになるので、その操作性を見ました。

画面でポチポチすればスケールアップ・ダウンできるので、慣れないエンジニアでもメンテナンスできそうだと。運用面で問題なさそうだと感じてます。

運用でよくあるのが突発的にユーザーさんが大量に来て、データペースが持たないかも、みたいな時があります。TiDBなら突発的にスケールアウトさせてもゲームのサービス的にエラーなくスケールアウトして、どんどん負荷をさばけることも分かりまして、安心して使えると思います。

最後の学習コストですけれど、ワンダープラネットで作成するクエリはシンプルにすることになっていて、外部キーとか、ストアドプロシージャとか、トリガーとか、データベース機能をあまり使っていないので問題ないと感じてます。

特に既存ゲームサービスのデータベースをそのままTiDBにダンプして、リストアしてみて、シナリオテストをかけました。

シナリオテストは、ゲームを開始し、チュートリアルをして、バトルが終わってアイテムを使って、みたいな、ユーザーさんの一連の行動をAPIで投げていくような負荷試験の一種です。

それがMySQLと同じような結果が得られまして、移植しただけで使えるみたいなところが分かりました。

またTiDBをダンプしたリストアができるところで、逆もできるところもありまして、採用するハードルが下がりました。

林氏：ありがとうございます。確かにTiDBは入りやすく逃げやすい。性能が必要なくなったフェーズでMySQLに戻られるお客様も、少しはいらっしゃいます。

神津氏：MySQLとの互換性のテストをしました。本番系のDB（Amazon Aurora）を丸ごとクローンして、そこに集計を投げるという実験をしました。

結論として、MySQLの互換性ではほぼ問題ないように見えました。リードオンリーでのテストでしたので、アプリケーションに組み込んでトランザクションがかかった時にどうなるかは追加検証しようと考えています。

そのままでも動くがチューニングの余地がある

林氏：最後にCygamesさん、お願いいたします。

宮脇氏：実際のサービスで使うガチャの実装を簡略化してテストシナリオとして実装し、それをAmazon AuroraやTiDBに投げて比較しようとしました。

ただしそのままですとTiDBでパフォーマンスが出なかったので試行錯誤しまして、最終的には「TiDBならこういう風に設計するといい」というテーブル設計ガイドラインを作ることを目指して進めていきました。

分かったのは、プライマリキーにオートインクリメントを設定して、検索用にユーザーIDやソート用のカラムをインデックスとして指定していたログテーブルを、そのままTiDBに持っていくと、動くのですが性能が出ない。

これらはオートインクリメントをオートランダムにすることや、プライマリキーを工夫することで解消しました。

TiDBはMySQL互換なので、MySQLの設計をそのまま移植しても動きますが、性能がそんなに出ないパターンがあることが分かりました。そこはTiDBのテーブル設計やチューニングの余地があると感じています。

各社からTiDBへの期待

林氏：時間が残り5分になりまして、最後のテーマは今後のTiDBへの期待です。こういうのがあったらいいな、などあれば教えてください。

中山氏：すでにPingCAPさんにリクエストを出させてもらったのが実現していて大きいものはないのですが、TiDB Cloudを使うときに、融通が利くような小さなノードがあるとうれしいです。

神津氏：ほとんど同じです。始める時は8CPUが選べて、でも大きくすると8CPUには戻れず一方通行でした。今後はサーバレスで便利になると聞いているので、解決することを期待します。

林氏：今日時点ではスケールダウンも含めてできるようになっています。

宮脇氏：TiDBそのものは機能面やバグ修正とか、よく対応してもらっているので心配や要望はありません。TiDB CloudだとCLIツールが用意されていますが、自動化周りで作り込もうとすると機能が足りない、APIも足りないと思うので、そうしたところが整備されるとうれしいです。

林氏：ありがとうございます。対応していこうと思います。今日のディスカッションで、皆様に少しでもゲーム業界とTiDBとの親和性などについてご理解いただけたらうれしいです。

ご登壇いただきました皆さま、どうもありがとうございました。

≫アーカイブ動画は下記のWebサイトからご覧いただけます。

≫TiDB User Day 2023

※記事中のパネルディスカッション登壇者の社名や肩書きは、イベント当時のものです。

※ この記事「ゲーム業界のデータベース事情。大量のシャーディングで複雑化する負荷分散、メンテナンスで止めないとスケールアップ・ダウンができないなどの課題。解決方法は？」は、Pubickeyの許可を得て転載しています