記事公開日：2023年2月24日
Cygamesは全世界数千万人のユーザを抱えて数百万QPSにも上る処理を行っています。本レポートでは、Cygamesで行っているTiDBの検証と取り組みについて紹介します。
はじめに
2022年11月16日〜18日に開催された、国内最大規模のデータベースカンファレンスである「db tech showcase 2022 Tokyo」の中で、参加者からの注目度も高く、筆者自身も興味深く感じた、株式会社Cygamesによるセッションを紹介したいと思います。
db tech showcaseは、過去2回はともにコロナ禍の影響でオンラインのみの開催となりましたが、今回は最終日のみ対面とオンラインのハイブリッド開催ということもあり、DBエンジニアの方々の熱気が伝わってきたイベントになりました。
さて、その中で、最近話題の分散型データベース(NewSQL)の代表選手ともいえる「TiDB」の事例を紹介するセッションがありました。TiDBはCygamesをはじめゲーム業界で注目度が高まっていると聞いていましたが、実際にどのように検討されているのか、また、なぜ選択したのかというところに興味があったので、セッションを聴講することにしました。
『「最高のコンテンツ」を支える、
Cygamesのデータベース技術の今までとこれから』
本セッションは、株式会社Cygames サーバーサイド サブマネージャー 大橋 庸氏と、同社CTO室 シニアデータベースアドミニストレーター 浦谷 和茂氏のお2人がリレーで講演する形をとっており、大橋氏が「データベース技術の今とこれから」、浦谷氏が「TiDBへの取組み」についてお話をされました。
「データベース技術の今とこれから」
サーバーサイドのミッションとして、最高のユーザ体験を生み出すために安定・高速・スケーラブルなサーバーシステムの構築をする、そのときに聖域を設けずにモダンな技術の検証／導入することを挙げていました。これは、安定とモダンな技術の導入の両立にチャレンジするそのマインドこそが「最高のコンテンツ」を支える源であるということを信じていると言います。
その後、現行のアーキテクチャについて説明がありました。現行の基本アーキテクチャはMySQLを垂直方向にMHA(Master High Availability)によってクラスタ構成にしており、そのクラスタ構成を水平分割・シャーディングしています。この構成はゲーム業界では一般的なアーキテクチャとのことで、基本的に静的な構成と言えるそうです。さらにこのアーキテクチャの性能を引き出すために、さまざまなチャレンジやチューニングに取り組んでおり、そこでの目標はそれらのチューニング結果を共有し、体系化していくことで「安定」かつ「高速」なサーバーシステムを運用し、数百万QPSを達成すること、とのことです。
とは言え、まだ改善するべきポイントもあり、それが「スケーラブル」でした。現行アーキテクチャの限界と言えるかも知れませんが、「シームレスなスケーリング」と「リソースごとのスケーリング」に改善の余地がありました。
具体的に「シームレスなスケーリング」については、ローンチ後、サービスの予想以上の急成長により、「スケーリング」のためのメンテナンスのために想定外の長時間のサービス停止が必要になってしまいました。それはユーザー体験の阻害に他なりません。もし、オンラインでスケールができればサービスの停止を減らすことができ、より良いユーザ体験を生み出すことができます。
次に「リソースごとのスケーリング」ですが、これは計算資源とストレージそれぞれのリソースごとにスケールができないことを意味します。基本的に、計算資源の使用率はリアルタイム性が高いアクセスと比例し、ストレージの使用率は運用期間に比例します。つまり、現状では傾向の異なるピーク時に必要な計算資源と、不可逆な増加傾向を見せるストレージどちらか高い方を基準にサーバーを構成している状態になってしまいます。もし、リソースごとにスケールできるようになれば、最適化が期待できます。そして、その最適化できたコストを「楽しさ」の追求に還元できるのではと考えているようです。
これら2つのスケーリングの問題を解決することが大前提ですが、Cygamesが求めている要件は以下の4つでした。
- 既存システムでMySQLを活用しているためMySQL互換であること
- 多様な運用環境(オンプレ・クラウド)に対応していること
- エンジニアが本来のゲーム開発に集中できるようフルマネージドも選択できること
- ソースコードから研究できるオープンソースであること
これらの要件を満たすソリューションとして、TiDBを選択したということです。
「TiDBへの取り組み」
続いて、浦谷氏から「TiDBへの取組み」について説明がありました。本編に入る前にTiDBのアーキテクチャに関するチュートリアルがありましたが、ここでは割愛したいと思います。
●TiDBを選択した理由
TiDBを選択した理由については、まず「MySQL」を使用しているということを挙げていました。TiDBであれば、MySQLのインタフェースがそのまま使用でき、特にMySQL 5.7との互換性が高く、アプリケーション開発者はバックエンドの仕組みの変更を意識することなく、今まで通り使用できるということで、とても扱いやすいということでした。
2つ目は「サーバーリソースをより上手に活用したい」ということです。CPUリソースやストレージ容量だけが足りないサーバー等の偏りが発生することがあります。また、サーバーによってリソースの使われ方が異なるため、バランスよくリソースができません。下図にあるようにMySQLの場合はモノリスな構成になっているため、サーバーリソースが密結合でリソースをセットでスケール必要があります。それに引き換え、TiDBの場合はマイクロな構成をとっているため、コンピューティングノードとストレージノードが疎結合で独立したスケールが可能になり、それぞれ単独でスケールします。これにより、バランス良くリソースを使用できるようになります。
3つ目は「ユーザがより安心して遊べる環境を構築する」ことです。TiDBはクラスタ構成をとっており、各クラスタは独立しているため、必要に応じて柔軟にスケールします。また、メンテナンスのためにシステムを停止する必要がないため、エンドユーザーに24時間365日いつでもゲームを遊べる環境を提供できます。
最後は「チャレンジ」です。現在サービス提供に採用している技術は安定しており、信頼性も高いため既存技術で全く問題はありませんが、新しい技術の検証を行い、エンジニアの技術力向上と将来のゲームコンテンツへの導入を目指していきたいと考えているとのことです。そのような「チャレンジ」する気風があることで、エンジニアとしてはとても良い環境を提供してくれる会社だと思います。
●TiDBの検証について
検証については、実際に活用されている運用プロジェクトのQueryをサンプルにして行いました。CygamesのソーシャルゲームにおけるQueryの特徴として、テーブル結合やサブQueryなどを使用しないシンプルなQueryを実行することで、なおかつ、これらのQueryの発行数は数百QPSに上ります。特にイベントやアクティブな時間帯では、当然ながら、アクセス数もQueryの発行数も増加する傾向があります。
検証ツールには「vegeta-mysql」を使用しました。vegeta-mysqlはGoで実装されたツールで、ファイルに格納されたQueryを実行して指定したサーバーに負荷をかけ、レポートを出力するベンチマークツールです。このツールを活用した検証を行いました。検証の構成や詳細については、講演資料をご覧いただければと思いますが、下記の4種類の検証を行い、すべて期待通りの結果となりました。
- TiDB1台あたりの最適なQPSを見つけるための検証
- インスタンス最小要件の台数で構築して検証
- TiDBスケールアウト時に問題ないことを検証
- スケールアウト後の環境でQPSが上がることを検証
●TiDBにおけるその他の留意点
最後にCygamesでのTiDBに関する取り組みとして、同社の「カジュアル共有会」の紹介がありました。エンジニアの技術力向上のためにTiDBのアーキテクチャや検証内容などについてオンラインセッションで発表しているということで、全社でTiDBに関する知見の共有を目指しているそうです。
おわりに
ここまで紹介してきたように、Cygamesの現状のアーキテクチャの課題を明確にし、それを解決するために積極的に新しい技術を検証し、課題を克服していく姿勢はとても素晴らしいものでした。今後も発生する可能性のあるさまざまな課題にも、Cygamesであれば果敢に立ち向かい、解決していけるだろうと強く感じられました。
また、TiDBもユーザにとって、さまざまな課題を解決するための性能も含めて、今後も機能が追加されていくことを期待したいと思います。
出典：Think IT ー「最強のバックエンドで最高のゲームを!」 全世界数千万のユーザーを抱えるCygamesのTiDB活用のポイント」 2023年2月3日(金)
