古戦場とともに成長してきた「グラブル」のシステム管理
「グラブル」の愛称で親しまれ、多くのファンを持つ「グランブルーファンタジー」。いわゆる「王道スマホ系RPG」として、2014年3月のローンチ以来、累計登録者数は2500万人を超え、成長し続けてきた。頻繁にアップデートが行われ、仲間のキャラクターは590人以上、武器は2000種類以上を実装し、イベントも定期的に開催している。イベントの中でも定番になっているのが「決戦！星の古戦場」と呼ばれるイベントで、このイベントは期間限定で登場する「イベントボス」を撃破して獲得した貢献度と呼ばれるポイントを競い合うもの。勝敗に応じて勲章などの報酬が与えられるため、集中してゲームを行う人も増える。
そんな人気ゲームのサーバーは一般的なLAMP環境で運用されており、１日15億ものリクエストに応え続けてきた。小松氏は「私たちは安定したサービス環境を提供するためにさまざまな工夫を行ってきた。それはユーザーに快適に楽しんでほしいとの一念によるもの」と語る。
ちなみに１日15億という数字が生み出されるのは、「グラブル」がユーザーの操作のたびに通信が発生する「ブラウザゲーム」であることも大きい。
とはいえ、１日15億リクエストという数字は、あくまで平常運転時のもの。先述した「決戦！星の古戦場」など人気の定期開催イベントでは、1日に40億リクエストを超えることも少なくなく、瞬間的には１秒間に28万リクエストに上ることもあるという。
この「決戦！星の古戦場」開催時の状況をサーバー側から見てみると、イベント開始直後からリクエストが急増し、イベントのピークタイムでは28万リクエスト/秒に達している。この時は想定以上のリクエストの集中で、ロードバランサーのCPU使用率が100%に到達し、急遽L7のロードバランサーからL4に切り戻して対応することとなった。また、発行クエリが多すぎて、MySQLのメモリが枯渇しそうになる危機にも陥るなど、さまざまな問題が次から次へと起きる状況下で「古戦場」とともに成長してきた。
小松氏は「思いも寄らない問題に対し、『観測と予測』によって少しでも早くトラブルに気づき、できるだけ早くボトルネックを取り除くことが大切」と運用のポイントについて語った。
想定以上を乗り切るための「サーバー運用の3本柱」とは
それでは具体的にどのような運用体制で、秒間28万リクエストにもなるイベントを乗り切るのか。小松氏は、「万全の準備」「見守り（モニタリング・挙動確認）」「トラブル対応」の3つを三本柱として挙げ、「どれが欠けても十分な対応ができない」と強調する。
まず「万全の準備」については、「変化を予想し、備えること」が大切だ。前回のイベントで乗り切ったとして、そのまま次を迎えてはならないという。つまり、前回観測された各種情報（ユーザー数の変化や遊び方の変化など）を見て、過去6年間の傾向から変化を予測し、必要な対応を決める。そして、その想定値に対し、計測を交えながら検証を繰り返し行っていく。
例えば、次のイベントの最大リクエスト数を予測するにあたっては、前回開催のリクエスト数とユーザー数と比較し、現在のユーザー数やユーザー層などの差異、日程・ゲーム編成の差異によるサーバーの負荷の変化などを加味して考えていく。
次に「見守り」については、開催中のモニタリングであり、挙動確認のことだ。ここで最も大切なのは「課題を見落とさないこと」だという。まず、機能面の見守りとしてサービスの不具合に気づくこと。そして、負荷の見守りとして、瞬間的な事象やトレンドの観測を行い、不具合の迅速な修正や改善点の報告へとつなげていく。
どのようにして課題を見落とさないようにするのかについては、長くなるため割愛するとして、参照記事として「Developers Summit 2017」の講演「監視・解析ツールから読み解く！トラブル対応＆負荷対策」のレポートが紹介された。
なお具体的には、下記のツールが実際に見守りに使われているという。
サーバー全体は「Mackerel」、エラーの傾向などは「Kibana」、APIごとのトレンドや詳細などは「New Relic」、データベースの瞬間的な動向は「Percona Management Monitor」を活用している。また、ある程度自動化し、課題を見落とさないようにしているという。
そして、3本目の柱「トラブル対応」について、小松氏は「どうしても予測できないトラブルはあるが、ユーザーさまにゲームを楽しく遊んでいただくことを重視し、たとえ障害発生時でもユーザーへの影響を最小にし、迅速に障害を取り除きたいと考えている」と語る。
そのために、「事象・ユーザー影響の把握」「チーム内での情報の共有」「問題の切り分け」「作業の分担」といった4つのステップをスムーズに行うことに心を砕いているという。「当たり前のことを徹底的に行うことが何より重要」と小松氏は力を込めて語った。
継続的なチューニングにおいて重視すべき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
