こんにちは、サーバーサイド エンジニアの伊藤と穴久保と申します。

Developers Summit 2024にて「『グランブルーファンタジー』100万行を超える大規模なシステム再構築～10周年のその先へ～」と題して発表致しました。ご聴講いただいた皆様・ご反響をくださった皆様、本当にありがとうございました。

大規模リファクタについて

このような中長期的な取り組みは、ユーザーの皆様が快適にプレイをお楽しみいただくだけでなく、今後も最高のコンテンツを提供するための取り組みとなります。
本稿では講演でお伝えしきれなかった事や、講演資料についてフォローアップしていきたいと思います。

既存システムの全体規模

既存システムの全体規模についてです。

ソースコードにおいては、フレームワーク等を除いたPHPのソースコードだけでも300万行を超える規模になっています。

またテーブル数においても水平分割を含まない形で9,000テーブルを超えており、水平分割を含めると3万テーブルを超えています。

ゲームにおいて重要なパラメーターを決めているパラメーターファイルおいては優に5万ファイル超え、ソースコード、テーブル、パラメーターファイルの数だけ見ても大規模で複雑なシステムとなっている事がご想像できるかと思います。

リファクタリング開発体制

次に開発体制についてです。グラブルは数十人規模のエンジニアが開発・運用にあたっていますが、その中でリファクタリングに関しては、6名のバックエンドエンジニアを中心に専任チームとして進めています。

この規模で運用しているサービスのリファクタリングでは、日々の運用・開発に追いつく必要がある為、通常は運用コンテンツを開発している人数より多くの人をリファクタリングに当てることが一般的な方法となるかと思います。

それらを工数で解決するのではなく、開発の効率化によって実現しています。

開発の効率化

開発効率を最大化するために設計思想や原理原則を徹底する方針で進めました。
しかし、この方針をチームの一部のメンバーのみが徹底しても効果は薄いです。

チームメンバー間で設計思想や原理原則に対する理解や意識に差があると、品質に差が生まれてしまいますし、チーム内での活発な議論もできなくなってしまいます。そのため、チーム全体で同じ意識を持って仕事に取り組めるように、意識の統一を目指しました。

しかし、同じチームのエンジニアであっても、各メンバーのバックグラウンドは様々なため思想や認識の統一は難しく課題となりました。

この課題を解決するために、２つの取組みを行い解決しました。徹底した設計レビューとペアプログラミングの実施です。

1つ目は徹底した設計レビューを意識統一のため行いました。

設計レビューを行うことで、曖昧な部分が残っていたり、本来あるべき設計ができていない場合に検出し、意識の共有を行えます。

そして設計レビューの場合は一度自分が設計した部分に対してコメントをもらうため、より具体的にアーキテクチャ等の思想の意図を認識することができます。

2つ目のペアプログラミングはリファクタリングの設計思想や原理原則を理解したメンバーと、参加して間もないメンバーなどがペアとなって行います。

実際に参加して間もないメンバーが担当するタスクを一緒にペアプロをしながら取り組むことで、設計レビューより詳細な思想を共有していきます。

この取り組みのメリットは、実際のタスクを一緒に取り組むことで、実際にぶつかる課題をアーキテクチャや原理原則でどのように解決していくのかを実際の事例で理解することができます。また、各メンバーのバックグラウンドは様々なため、ぶつかる問題や疑問に思う点というのも変わってきます。そういった各メンバーで異なる部分を吸収し、意識統一するためにもペアプロは適しています。

チームで技術的な認識を共有する事により議論が活発に行われ、共通認識のもと議論出来る文化を作る事が大事になります。

当たり前の内容になりますがリファクタリングは規模問わず当たり前の事を、個人だけでなくチーム全体として積み重ねて行く事が一番の近道になるかと思います。

アーキテクチャ

P.39でご紹介しているDB/Cache/DTOのデータマネージャーの簡易な概要図となります。
こちらはデータベース、キャッシュ、データトランスファーオブジェクトを組み合わせたデータマネージャーを導入しています。
データマネージャーは、それらの要素をカプセル化し、管理する仕組みを提供しています。
必要に応じてキャッシュやデータベースにアクセスを行い、DTOを用いてデータの最新状態を一元的に管理しています。
使用者はデータの状態やキャッシュやデータベースの負荷を気にすることなく、安全にデータを扱うことができます。
またデータ管理以外に排他制御を用いてレースコンディションにも対応しています。

性能検証

性能検証についてです。同時接続数を増やしていく検証をおこないましたが、特にボトルネックの原因だったRedisを赤く強調表示しています。

リファクタ前はパラメーターデータキャッシュの負荷が大きな原因となっていました。（スライドのP.23で触れております）

グラブルではパラメーターデータはRedisを使用して運用していますが、度重なる機能追加によりパラメーターデータが増加し、それに伴いRedisへのアクセスが増加し続けてきました。

例えになりますが、武器の能力が強化される機能が増えた場合、それに紐づくパラメーターデータが増えていく為、武器やキャラクターなどを取りまとめる編成情報を取得するだけでも数百回以上Redisへアクセスする必要が出ており、それらによるオーバーヘッドも大きく、負荷の増加や処理速度の低下を招いていました。

それらを解消する為、今回のリファクタリングでは、リレーションするパラメーターデータを纏めたキャッシュとして扱う仕組みを導入しました。これによりRedisへのアクセスが大幅に抑制されました。

全体的に改善が見られますが、スパイクの原因だったRedisが大きく改善した事により、リファクタ前は大きくばらつきがあったグラフが安定したレスポンスを達成することができました。

多重化した仕様・膨大な量のデバッグについて

グランブルーファンタジーは10周年を迎えるゲームになります。

その為、１つの機能にしても度重なる変更によって仕様とソースコード共にかなり煩雑になっている箇所がありました。

問題は実装だけで解決しようとするのではなく、本来の仕様の意図を読み解き、修正案はエンジニアの技術的視点とプランナーのプランニング視点を合わせて、ゲームをより良くする仕様を調整しながら、この先も無理なく運用できる仕様や実装を実現しました。

10年分の積み重ねもありそれらの量も膨大で、リリース時の仕様調整のお知らせはSNSで話題になるほどの量になっていました。

仕様調整だけでなく仕様の明確化まで合わせると、その対応数は数百にも及び、プランナーの協力の下、解決を行いました。

デバッグにおいてはテストパターンが多い物や確率のテスト等、手動でデバッグを行う事が困難な物はエンジニアが担当し、エンジニアとデバッグチームで連携して対応を進めました。

それでも不足するリソースについては、Cygamesは各プロジェクト毎にデバッグチームが存在しているのですが、プロジェクト外にも協力を要請して会社のデバッグ組織としてリソースの解決を行い、数千人日というデバッグ工数の解決を行いました。

多重化した仕様と膨大な量のデバッグの話を通してになりますが、こういった事はエンジニアだけで解決しようとせずに組織で解決することが大事になります。

最後に

今回の講演や本稿では、「『グランブルーファンタジー』100万行を超える大規模なシステム再構築～10周年のその先へ～」と題し、次の10年を支えていく取り組みについてご紹介させて頂きました。

おかげさまでグランブルーファンタジーは2024年3月10日に10周年を迎えました。
今回ご紹介させて頂いた以外にも長く続けていく為の取り組みをこれまで行ってまいりました。
これらの取り組みはユーザーの皆様に最高のコンテンツをお届けする為、エンジニアのみならずプロジェクト一丸となって取り組んでいます。

今後も次の10年に向け同じ気持ちでチーム一同励んでいきたいと思っております。
以上、伊藤・穴久保のフォローアップでした。