継続的なチューニングにおいて重視すべき5つのポイント
後半は、サーバーサイド エンジニアの大橋氏に交代し、「古戦場」事例における技術的改善の考え方などについて紹介された。
「グラブル」では、発生したトラブルに対する短期的な改善はもとより、技術的改善について中長期の改善を大切にしているという。短期的な改善については、あくまで一時的にトラブルを解消し、ユーザーに迷惑をかけないことが目的だ。しかし、中長期の改善については、「その場かぎりではなく未来を見据えた改善」と位置づけ、ユーザーにより快適に遊んでもらうこと、「最高のコンテンツ」を届けることを最大の目標としている。
そのためには「より良いプレー環境」を実現することが重要であり、軽快なレスポンスのために、継続的にチューニングすることを意識しているという。そして、トラブルを未然に防ぐためにも、レスポンス改善は欠かせない。処理が不安定になることによって、通信先のデータベースなどでトラブルが発生しやすくなるからだ。
チューニングの対象として、DBクエリや各種サーバー設定、ミドルウェアなどがあるが、今回はサーバーサイドのプログラムチューニングの事例を紹介する。大橋氏は「大切にしているポリシー」として以下の5つのポイントを紹介した。
1つ目はチューニング対象に壁を作らない、すなわち「聖域を作らないこと」。ゲームプログラムだけでなく、システム全体を見て必要とあればフレームワークやライブラリもチューニング対象とし、ハードやミドルウェアについても関係各所と連携しながら改善を行っているという。
2つ目は、「現象と原因」を深く追求すること。どうしても忙しいと、つい「とりあえず解決」として終わらせてしまいがちだが、発見した現象を深く追求し、原因を特定することが大切だ。問題が自分の担当外にあることも少なくないが、周囲と協力しながら辛抱強く問題の原因を探るべきだという。
3つ目は「変化に追従すること」。例えば、イベントではユーザーの行動によって大きく負荷が変わる。例えばバトル期間が終了した直後、バトル処理の負荷が大きく下がり、代わってアイテム・プレゼントに負荷が集中することがある。ソーシャルゲームでのイベント実施は一般的なものであるが、「古戦場」イベントはその中でもピーキーなものだったといえるだろう。
4つ目に「手段の選択」として、「目的を踏まえて選択することが大事」と語った。スケールアウトも短期的な改善策の1つであるが、あくまで基本はデータ構造とロジックの調整であり、ボトルネックを改善することが大切。なお、性能を引き出すことができ、限界を知っているからこそ適切に選択ができることについて「長期運用のメリット」と評した。
5つ目として「チューニングの落とし穴」に注意することを強調した。なにか新しくするだけでは解決策にならず、現在の性能を十分に引き出すことが大切で、「銀の弾丸はない」と断言。現在その技術を使いこなせていなければ、新しいものを導入しても性能を引き出せない。さらにチューニングしても、次なるボトルネックとの新たな戦いが始まることを覚えておかなければならない。
聖域なきチューニングの反復の積み上げが着実な成果に
続いて、上記の「聖域を作らない」「現象と原因」「手段と選択」のポイントを押さえたチューニングの事例が紹介された。今回紹介されたのは「フレームワークの改善」の事例だ。
「グラブル」は現在6年目。こういった既に運用しているサービスにおいては、フレームワーク部分の処理変更の問題点として、影響範囲が広くハイリスクになりがちなこと、改善意識が希薄になり見落としがちなことが挙げられる。しかし、大橋氏は「影響範囲が広いということは、ハイリターンというメリットともいえる」とメリットを語る。
事例では、「現象把握」として、古戦場系APIにおけるフレームワークのwalltimeを観察してORM参照の状況、ORMクラスの生成処理でオブジェクト関係マッピングの状況などを把握するところから開始された。この時、評価はむずかしいが、基準を作って判断することが望ましいという。その上で「重い」と判断されたら「原因」を考察する。事例では、ORM参照のCallが3643回で84713μsec、オブジェクト関係マッピングが54回で9206μsecといった数字から「重い」と判断。原因を考察していった。
ORMの機能としては厳密な型チェックと変換ロジックが入っていること、Compositeパターンで外部キーの参照先までテーブルを持っていき、まとめて扱えることなどが挙げられ、これを実現するためリッチなデータ構造となっている。また、これらが要因になりメソッド呼び出しも必須になる。
機能的には一般的なORMではあるが、前述したように「グラブル」は秒間28万ものリクエストに応える必要があるいわば特殊ケースだ。MySQLの性能を引き出す必要があり、データベースを容易にスケールアウトできる構成にしておくことが重要だ。そのため、外部キーを利用しないこと、サブクエリや結合を利用しないこと、そして古戦場においてはテーブル数（データ数）が非常に多いことや、参照回数が数百から数千と多いことなどの特性がある。さらに、コンシューマ向けだからこそ、レスポンスを早く返さなくてはいけない。データが多いからといって、遅くていいわけではない。こうしたグラブルの特性に現状のORMが適していないことが原因である、といった判断に至ったという。
そして、改めて「グラブル」に最適なORMを作成するべく、目標を明確化して要件定義を行った。「最速であること」「シンプルであること」「ORMとしての扱いやすさは変えないこと」を目標とし、特に扱いやすさについては、ゲームプログラミングになるべく影響を与えないこと、内部構造は変えてもインターフェースは変えないなどを意識したという。
そして、概要設計としては「内部データ構造の再設計」が最も需要であり、「参照をインスタンス変数アクセスに変更すること」「利用してない機能を捨てること」「ORM Generatorで実装者の負担を低減すること」などが考慮された。
実際にORMを作ってみた結果、walltimeについて改善前を100とすると、データ参照で0.3、オブジェクト関係マッピングで2.5となり、それぞれ劇的な改善効果が得られた。メリットとして、データ参照、オブジェクト関係マッピングとも最速となり、古戦場以外のAPIでも良い結果が得られた。一方、デメリットとして「インスタンス変数へのアクセスはパブリックとしており、カプセル化の観点ではベストではないという議論はある。しかし運用が求める要求に従って技術が使われるとしたら、時にはセオリーを破っていくことは必要ではないか」と大橋氏は語る。
もちろん、将来的にはまた新しい課題が生じることは間違いない。しかし、「グラブル」ではこうしたチューニングを748件もイテレーション（反復）してきた実績がある。中長期的に取り組んできた結果、開催するごとにユーザー数が増加する中でも古戦場系APIの平均レスポンスは開催ごとに徐々に下がり、最も悪い時よりも45%も平均レスポンスタイムを削減することができたという。
大橋氏は「運用・開発の改善は『最高のコンテンツ』をユーザーに届けるために重要な活動だと思う。こうしたチューニングを継続することで成果が出る。考え方や技術はもちろん大切だが、ひるまずにチューニングすること、コア技術は自分たちで実装すること、そうしたエンジニアの意識や意地が根底にあり、原動力になっている」と語り、「DBはもっと過酷な戦いがあった。そちらもぜひ紹介したい」と語り、セッションを終了した。
株式会社Cygames
