この界隈から大分離れてしまっているので、話を聞いてきました。
所感としては、徹底して計測からの改善をやっていて、当たり前のことを当たり前にやることを実行していて、素直に凄いと思いました。
登壇者
- 小松 美穂 氏
- Cygames サーバサイドエンジニア サブマネージャ
- 大橋 庸 氏
- Cygames サーバサイドエンジニア
グランブルーファンタジー
- 高いアップデート頻度が特長
- 仲間キャラは590人
- 武器は2000種以上
- 多くのイベント開催
サーバの現状
- LAMP環境
- Linux/Apache/MySQL/PHP
- ユーザ数2500万人突破
- リクエスト数15億/日
- Yahooのトップページ級のアクセス（そうでしたっけ・・・？）
- アクセスが多い理由
- ブラウザゲーム＝ユーザの操作ごとに通信している
- アクセスが特に増える日がある
- 平常時：15億/日
- 「古戦場」時：40億/日
- ピーク時は、28万リクエスト/秒
「決戦！星の古戦場」とは
- 定期開催のゲームイベント
- 開始後からリクエストが急増
- 秒間28万リクエストに達する
- トラブル事例
- LB(BIG-IP)のCPU使用率が100％に到達
- 急遽L7=>L4に切り戻し
- MyQLのbuffer poolが枯渇しそうになる
- メンテナンスでパラメータ変更
- LB(BIG-IP)のCPU使用率が100％に到達
少しでも早く気がつき、ボトルネックを取り除くことが必要
古戦場を乗り切る運用体制
サーバ運用の3本柱
- 1. 万全の準備
- 2. 見守り
- 3. トラブル対応
1. 万全の準備
- 変化を予想し備えることが大切
- 前回観測された各種情報（ユーザ数変化、遊び方変化など）から、必要な対応を決めていく
- 計測 <-> 修正を繰り返す
- 前回開催のリクエスト数・ユーザ数と比較し、現在のユーザ数・ユーザ層の差異・イベントの差異など
2. 見守り
- 機能の見守り
- 不具合に気づく
- 負荷の見守り
- 瞬間的な事象
- トレンド
- 課題を見落とさないために
- 複数のツールを活用
- デブサミ2017の発表資料を見ればわかるよ！
- 実際に活躍しているツール
- Mackrel
- kibana
- Newrelic
- Percona Management Monitor
- Xhprof
- BigQuery
- Datadog
- 自動監視
3. トラブル対応
- Cygamesでは「CS最優先」
- 障害発生時であっても、ユーザへの影響を最小にしたい
- 迅速に障害を取り除く
- 事象・ユーザ影響の把握
- チーム内での情報の共有
- 問題の切り分け
- 作業の分担
当たり前のことを当たり前に徹底的にやっていくのが大切
古戦場の2つの技術的改善
- 短期的
- 発生したトラブルを解消し、ユーザに迷惑をかけない
- 中長期の改善
- その場限りではなく未来を見せた改善
- ユーザに快適に遊んでもらい、最高のコンテンツを提供する
- 中長期の改善を大事にする
- よりよいプレー環境の実現
- 軽快なレスポンスのために継続的にチューニング
- トラブルを未然に防ぐ
- レスポンス悪化によって、DBは障害リスクが高まるため、継続的にチューニング
- よりよいプレー環境の実現
チューニングの考え方
チューニングはざっくり以下の種類がある
- DBクエリ
- 各種サーバ設定
- Webサーバ
- プログラム
今日はプログラムにフォーカスして話をする
その上で、5つのポイントを紹介
1. 聖域を作らない
- チューニング対象に壁を作らない
- フレームワークやライブラリも対象
- HWやMWも関係各所と連携
2. 現象と原因
- 発見した現象を深く追求し原因を特定する
- MWのソースコードまで必要であれば追求することも
3. 変化に追従する
- ユーザ行動による変化
- イベント中、バトル・終了直後にアイテム・プレゼントに負荷が集中
4. 手段の選択
- 目的を踏まえた上で選択
- 基本はデータ構造とロジックの調整
- スケールアウトは選択肢の1つ
- 長期運用のメリット
- 「性能を引き出すことができ」「限界を知っている」から、適切に選択することが可能
5. チューニングの落とし穴
- 銀の弾丸はない
- 新しい技術でも、その性能を引き出せなければ解決策にはならない
- チューニングしたら終わりではない
- 新たなボトルネックが出現し、新たな戦いが始まる
チューニングの事例
- フレームワークの変更
- ハイリスク：影響範囲が広い
- 改善の意識が希薄になり見落としがち
- ハイリターン：影響範囲が広い
- 古戦場系APIのフレームワークのwalltimeを観察すると、ORM参照で 84,713μsec
- ここが重いと判断（ただし重いという基準を作るのが難しい
- ORMクラスの生成処理では、オブジェクト関係マッピングも9,206μsec
- ORMまわり
- 厳密な型チェックと変換ロジック
- Compositeパターン（FK参照先まで）
- 上記を実現するための複雑なデータ構造
- それらが要因となり必須になっているメソッド呼び出し
- MySQLの性能を引き出すために以下を意識している
- 外部キーを利用しない
- サブクエリや結合を利用しない
- テーブル数（データ数）が非常に多い
- 参照回数が数百から数千に上ることも
- これらのグランブルファンタジーの特性に、ORMが適していない
- ORMのチューニング
- 目標を明確にする
- グラブル特性に最適なORMの作成
- 目標を明確にする
- 作りたいORMの要件定義
- 最速であること、シンプルであること
- ORMとしての扱いやすさを変えない
- ゲームプログラミングになるべく影響を出さない
- 内部構造は変えてもインターフェースは変えない
- 概要設計
- ORM内部データ構造の再設計
- 照をインスタンス変数アクセスに変更
- 利用しない機能を捨てる
- ORM Generator で実装社の負担低減
- ORM作ってみた
- walltimeの前後比較
- 前を100とすると、、、
- 後は、データ参照は0.3、オブジェクト関係マッピングは2.5
- かなりよくなった
- walltimeの前後比較
- 新しいORMの成果
- メリット
- データ参照が最速に
- オブジェクト関係マッピングも最速に
- 古戦場以外のAPIでも良い結果に
- デメリット
- カプセル化の観点でベストではない
- アプリケーションレイヤーでカバー
- カプセル化の観点でベストではない
- メリット
紹介したようなチューニングをイテレーションしているから成果が出る
皆様に「最高のコンテンツ」お届けするために...
- 怯まずにチューニングする
- コア技術は自分たちで実装する
参考: Developers Summit 2017 でのグランブルファンタジー関連の講演
あわせて読みたい
