10年間の運用で積み重なる課題
株式会社Cygamesが開発・運営する王道スマホRPG「グランブルーファンタジー（グラブル）」は、2024年3月10日でサービス開始より10周年を迎える人気ゲームで、2024年2月15日時点で登録者が3600万人を突破するなど今なお数多くのユーザーによってプレイされている。しかし、この人気の裏では長年に渡る運用の過程でさまざまな課題が積み重なっていた。
「グラブルはアプリ審査が不要なブラウザ向けゲームのため、機能追加やイベント、キャンペーンなどのアップデートを高頻度で行うことが可能となっています。そのため毎月10回以上、数万行に及ぶソースコードの変更を伴うアップデートを長年続けてきました。そのアップデート頻度を維持するため、本来は開発時に構造から修正すべき実装についても、追加開発では大きく構造を変えず、影響範囲を小さくするように開発を行ってきました。このような開発スキームの影響でコードの多重化や可読性の低下、技術負債の蓄積、属人性の増加といったさまざまな課題が蓄積されていました」（伊藤氏）
その結果、機能追加のたびに複雑な仕様やソースコードと格闘しなければならなくなっていた。さらにはソースコードの複雑化により、メンテナンスが初期実装者に偏ることで、属人化の問題も顕在化してきた。また、ソースコードのみならず機能追加によるデータアクセスも増加し、データベースやキャッシュサーバーに掛かる負荷も次第に高まっていた。
こうした運用面での課題に加え、技術面においてもさまざまな課題が持ち上がっていた。例えばコードは初期のアーキテクチャが手続き型で実装されていた事に加え、長年の運用により密結合な状態になっており、拡張性やメンテナンス性が低い状態になっていた。データについても一元的に管理できておらずデータアクセスも最適化されていなかった。データアクセスが増えデータベースやキャッシュサーバーの負荷も増加する一方で、WEBサーバーの負荷も増加を続けていた。
長年の運用の末にソースコードにして300万行、テーブル数が3万超、アクセス数が秒間28万という巨大サービスに成長した今、それらの課題に直面し、アーキテクチャの限界や老朽化を感じていた。その結果「度重なる拡張によって初期のシステムが老朽化していると考え、グラブルの次の10年を支えていくために、ゲーム業界でも最大規模の100万行を超えるシステムの再構築にチャレンジすることになりました」（伊藤氏）
100万行超の大規模リファクタリングの方針
設計思想や実装意図まで徹底的に読み解いた設計フェーズ
極めて大規模な再構築プロジェクトになるため、計画や準備にはエンジニアだけでなくプロジェクト全体として半年間かけてじっくり臨んだ。その後まずフェーズ1として「編成関連」の機能のリファクタリングを行い、次にフェーズ2として「クエスト関連」の機能、最後にサービス全体の機能を使用して動作する「バトル関連」のリファクタリングをフェーズ3として行う計画とした。なお本稿執筆時点（2024年2月）では既にフェーズ2までの作業を終えており、残るはフェーズ3のみとなっている。
リファクタリングの方針としては、アーキテクチャに至るまで刷新するため、関数単位の置き換えではなくAPI単位で移植を行い動作を保証する方針とした。そのためAPIのインタフェースは極力現状を維持することとし、これによりEtoEのテストを可能にした上でリリース後に万が一問題が発生してもAPI単位でリファクタリング前に容易に切り戻しできるようにした。また全体のアーキテクチャには「クリーンアーキテクチャ」を採用し、各コンポーネント間を疎結合で連携させることで変更や拡張に強いアーキテクチャを志向した。
さらにはシステム全体でデータアクセスを一元管理する「データマネージャー」の仕組みを新たに取り入れ、データアクセス処理をカプセル化することでデータアクセスの安全性を担保するとともに、キャッシュサーバーやデータベース負荷の画一的な最適化を図った。
一方、このリファクタリング作業を実際に行う主な人的リソースは伊藤氏を含むサーバーサイドエンジニア6名と、この規模の再構築プロジェクトとしてはかなり小規模の体制で臨むことになった。そこで少ない人数でも最大のパフォーマンスを発揮できるよう、開発効率を最大化するためにさまざまな工夫を凝らした。
「まず上流の設計工程でオリジナルのソースコードの仕様と実装を読み解くのですが、単に動作をなぞるだけではなく、本来の『設計思想』『実装意図』までをしっかり読み解いた上で再設計するようにしました。その上で設計品質の画一化のため設計のレビューを行い、調査不足を検知するだけでなく設計思想や実装方法などの理解に曖昧な点が残らないことを徹底しました」（伊藤氏）
設計にしっかり時間をかけることで設計工程における工数は増えるが、設計の品質を高める事で、下流の実装やコードレビューの手戻りを減らし、結果として全体の工数を大幅に削減した。
リファクタリング後にシステム性能が大幅向上
設計フェーズだけでなく実装フェーズにおいても、作業効率を最大化するためにさまざまな工夫を凝らした。ここでもアーキテクチャや設計思想に関する開発メンバーの理解を重視し、方針から逸脱した実装が行われないよう徹底した。プロジェクトに参画してまだ日が浅く、アーキテクチャや設計思想の理解が浅いメンバーは、必ず理解度の高いメンバーとともにペアプログラミングを行うことでメンバー全員への方針の浸透を図った。
「たとえ開発歴が長いメンバーであっても、今回のアーキテクチャや設計思想に対して共通認識を持ってもらうため、この点については決して聖域を作らず、すべてのメンバーに理解してもらいました」（伊藤氏）
また、たとえリファクタリングを既に実施したコードであっても、そこで問題が見付かれば決して妥協することなく再リファクタリングを行う事を徹底した。こうしてチーム内の意識や理解を統一することで、「チーム内で設計に関する議論が、共通認識の下で活発に行われ、それらがチームの設計やソースコードの品質を高め、開発速度の向上にも寄与しました。やはりチームで技術的な課題を共有して、オープンに議論できる文化を作ることが大事だとあらためて実感しました」と伊藤氏は振り返る。
こうした地道なリファクタリングを重ねた結果、システムに掛かる負荷は確実に軽減している。例えば、性能検証の結果としてレスポンスタイムがリファクタリング前の101ミリ秒に対して、リファクタリング後は61ミリ秒と40％短縮した。またスループットも、WEBサーバー1台辺りリファクタリング前は分間2万リクエストだったのがリファクタリング後は3万2000リクエストと、1.5倍のアクセスをさばけるようになった。
課題解決のためチームで設計思想を統一
伊藤氏とともにこのリファクタリング作業を担当した穴久保氏は、プロジェクトの過程で遭遇したさまざまな困難について次のように振り返る。
「設計思想や原理原則に対する各メンバーの理解や意識に差があると、成果物の品質に差が生まれてしまいますし、チーム内の議論も活発化しません。とは言えメンバーはそれぞれ異なるバックグラウンドを持っているため、やはり設計思想や原理原則の意識統一は一筋縄ではいきませんでした」
この課題は、設計レビューとペアプログラミングの取り組みを徹底し、チームで技術的な認識を共有して議論できる文化を作ることで乗り越えることができた。ただし設計思想や原理原則を重視した一方で、細かな設計ルールはほとんど設けなかった。
「ユースケースによって設計方針は変わるため、細かなルールを決めてしまうとそれを無理やり適用するあまり設計がねじ曲がってしまいルールが方法ではなく目的になることを危惧しました。そのため細かすぎるルールはあえて設けずに、適宜適切な設計・実装方針を議論しながら開発を進めていきました」（穴久保氏）
設計思想と原理原則の適用されたソースコードが浸透するにつれ劇的に開発工数が短縮された。変更容易性や再利用性が飛躍的に高まり、かつては1カ月かかっていた新規実装をわずか数日間で行えるようになった。
また長年の運用の過程で類似するサービス仕様の実装が重複している箇所が多数存在した。これらを本来あるべき形に修正するためにプランナーと検討しながら新たなサービス仕様をすり合わせていった。また膨大なデバッグ量をこなすために、グラブルチームに所属するデバッグメンバーだけでなく、チーム外のデバッグメンバーにも協力を仰ぎ、会社のデバッグ組織として取り組んだ。但し、全てをデバッグチームに丸投げするのではなく、エンジニアもテストの自動化を行うことで、協力して対応にあたった。
「このように自分たちエンジニアだけで解決にあたるのではなく、会社組織全体として課題解決にあたることが重要だとあらためて感じました。今後もこうした取り組みを続けて、ユーザーの皆様に『最高のコンテンツ』を末永く提供し続けていきたいと考えています」（穴久保氏）
株式会社Cygames
