Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
グランブルーファンタジーを支えるサーバーサイドの技術
Search
Cygames
February 14, 2020
Technology
2
28k
グランブルーファンタジーを支えるサーバーサイドの技術
2020/02/14 Developers Summit 2020
Cygames
February 14, 2020
Tweet
Share
More Decks by Cygames
See All by Cygames
最高のアートワークを発信する『Cygames展 Artworks』企画制作事例
cygames
0
51
社内にバーチャルスタッフ!?「スイちゃん」のキャラクターデザインと施策の広げ方の秘訣
cygames
1
130
全高3m超のバハムート像がスマホを通して躍動する! ~『Cygames展 Artworks』ARコンテンツの開発プロセスと実装~
cygames
0
44
最高の資料を目指すために!社内フリーイラスト制作チームの取り組みについて
cygames
1
140
「生きているモーション」を作り出すCygamesのモーションキャプチャー
cygames
0
99
『Cygames展 Artworks』におけるShadowverseデジタルサイネージ制作事例
cygames
0
42
『GRANBLUE FANTASY: Relink』 原作の世界観に没入するステージの絵作り
cygames
0
890
『GRANBLUE FANTASY: Relink』イラストを再現する為のキャラクターモデル制作事例
cygames
0
160
『GRANBLUE FANTASY: Relink』キャラクターの魅力を支えるリグ制作事例
cygames
0
97
Other Decks in Technology
See All in Technology
Fraxinus00tw assembly manual
fukumay
0
110
エンジニアリング価値を黒字化する バリューベース戦略を用いた 技術戦略策定の道のり
kzkmaeda
6
2.7k
分解して理解する Aspire
nenonaninu
2
1.1k
Snowflakeの開発・運用コストをApache Icebergで効率化しよう!~機能と活用例のご紹介~
sagara
1
460
Amazon Aurora のバージョンアップ手法について
smt7174
2
150
EMConf JP 2025 懇親会LT / EMConf JP 2025 social gathering
sugamasao
2
200
Snowflake ML モデルを dbt データパイプラインに組み込む
estie
0
100
IoTシステム開発の複雑さを低減するための統合的アーキテクチャ
kentaro
1
120
ESXi で仮想化した ARM 環境で LLM を動作させてみるぞ
unnowataru
0
180
Apache Iceberg Case Study in LY Corporation
lycorptech_jp
PRO
0
330
自分だけの仮想クラスタを高速かつ効率的に作る kubefork
donkomura
0
100
Amazon Q Developerの無料利用枠を使い倒してHello worldを表示させよう!
nrinetcom
PRO
2
120
Featured
See All Featured
Java REST API Framework Comparison - PWX 2021
mraible
29
8.4k
GraphQLの誤解/rethinking-graphql
sonatard
68
10k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
The Art of Programming - Codeland 2020
erikaheidi
53
13k
Building Your Own Lightsaber
phodgson
104
6.2k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3k
How GitHub (no longer) Works
holman
314
140k
Rebuilding a faster, lazier Slack
samanthasiow
80
8.9k
Making the Leap to Tech Lead
cromwellryan
133
9.1k
Designing for Performance
lara
604
68k
Art, The Web, and Tiny UX
lynnandtonic
298
20k
Testing 201, or: Great Expectations
jmmastey
42
7.2k
Transcript
None
アジェンダ • はじめに • 『グランブルーファンタジー』 サーバーの現状 • 『決戦︕星の古戦場』の事例 – 古戦場を乗り切る運⽤体制
– 古戦場の技術的改善 • むすび 2/72
None
Cygamesとは • 最⾼のコンテンツをつくる会社 4/72
『グランブルーファンタジー』 • 王道スマホRPG • 2014年3⽉〜 – 今年3⽉で6周年 – ユーザー数2500万⼈ –
今なお拡⼤を続ける 5/72
『グランブルーファンタジー』 • ⾼いアップデート頻度 – 仲間キャラは590⼈以上 – 武器は2,000種以上 – 多くのイベントを開催 6/72
アジェンダ • はじめに • 『グランブルーファンタジー』 サーバーの現状 • 『決戦︕星の古戦場』の事例 – 古戦場を乗り切る運⽤体制
– 古戦場の技術的改善 • むすび 7/72
サーバーの現状 #1 • LAMP環境で提供 – Linux / Apache / MySQL
/ PHP • 多くのアクセスを扱う – ユーザー数 2500万⼈突破 – リクエスト数 15億/⽇ 8/72
サーバーの現状 #2 • アクセスが多い理由 – たくさん遊んでいただいているから – ブラウザゲームだから =ユーザーの操作ごとに通信 操作ごとに
通信 9/72
サーバーの現状 #3 • アクセスが特に増える⽇がある ー 平常時 15億/⽇ ー「古戦場」時 40億/⽇ •
更に「古戦場」のピークには 28万リクエスト/秒 に達する それでも安定してサービスを提供したい 10/72
アジェンダ • はじめに • 『グランブルーファンタジー』 サーバーの現状 • 『決戦︕星の古戦場』の事例 – 古戦場を乗り切る運⽤体制
– 古戦場の技術的改善 • むすび 11/72
『決戦︕星の古戦場』とは • 定期開催のゲーム内イベント – 獲得した貢献度(ポイント)を競う 12/72
『決戦︕星の古戦場』とは • 開始後からリクエストが急増 – 時に秒間28万リクエストに達する 13/72
トラブル事例① • リクエストが多すぎて… ロードバランサーの CPU使⽤率が100%に到達 – 急遽L7→L4に切り戻して対応 – 後⽇スケールアウトを実施 14/72
トラブル事例② • 発⾏クエリが多すぎて… データベースサーバーのメモリが 枯渇しそうになる危機 – メンテナンスでbuffer pool size を変更
• 思いもよらなかった問題が起こる – 「古戦場」と「ともに」成⻑してきた 15/72
「思いもよらない問題」に 観測と予測をもって 少しでも早く気がつき ボトルネックを取り除く ことが必要
アジェンダ • はじめに • 『グランブルーファンタジー』 サーバーの現状 • 『決戦︕星の古戦場』の事例 – 古戦場を乗り切る運⽤体制
– 古戦場の技術的改善 • むすび 17/72
古戦場を乗り切る運⽤体制 • 古戦場サーバー運⽤の3本柱 • どこが⽋けてもいけない 1. 万全の 準備 2. ⾒守り
3. トラブル 対応 18/72
古戦場サーバー運⽤の3本柱 1. 万全の 準備 2. ⾒守り 3. トラブル 対応 19/72
1.万全の準備 • 変化を予想し備えることが⼤切 前回の 観測結果 変化を 予想 修正 計測 ・ユーザー数の変化
・イベント更新による 遊び⽅の変化 過去6年間の傾向から… 20/72
リクエスト数を予想する例 • ユーザー⾏動の変化を捉える 前回開催の リクエスト数 前回開催の ユーザー数 現在の ユーザー数 ボスの差異
編成の差異 ユーザー 層の差異 ⽇程 etc. 21/72
古戦場サーバー運⽤の3本柱 1. 万全の 準備 2. ⾒守り 3. トラブル 対応 22/72
2. ⾒守り • 課題を⾒落とさないことが⼤切 不具合の 迅速な修正 改善点の 報告 機能⾒守り 負荷⾒守り
瞬間的な 事象の観測 トレンド の観測 不具合に 気づく 23/72
課題を⾒落とさない為に • 複数のツールを活⽤ • Developers Summit 2017 「監視・解析ツールから読み解く︕ トラブル対応&負荷対策」にて 24/72
実際に活躍しているツール • Mackerel • Kibana • New Relic • Percona
Monitoring & Management • Xhprof • BigQuery • Datadog • ⾃動監視 ⽤途ごとに 使い分けている 25/72
古戦場サーバー運⽤の3本柱 1. 万全の 準備 2. ⾒守り 3. トラブル 対応 26/72
3.トラブル対応 • Cygames では「CS最優先」 – ゲームを楽しく遊んでいただきたい – 障害発⽣時であっても ユーザーへの影響を最⼩にしたい –
迅速に障害を取り除きたい 27/72
3.トラブル対応 • 迅速に障害を取り除く 1. 事象・ユーザー影響の把握 2. チーム内での情報の共有 3. 問題の切り分け 4.
作業の分担 28/72
古戦場を乗り切る運⽤体制 • サーバー運⽤の3本柱 • どこが⽋けてもいけない 1. 万全の 準備 2. ⾒守り
3. トラブル 対応 29/72
前半のむすび • 『決戦︕星の古戦場』の事例 – 秒間28万リクエストとの戦い • サーバー運⽤の3本柱 1. 万全の 準備
2. ⾒守り 3. トラブル 対応 30/72
アジェンダ • はじめに • 『グランブルーファンタジー』 サーバーの現状 • 『決戦︕星の古戦場』の事例 – 古戦場を乗り切る運⽤体制
– 古戦場の技術的改善 • むすび 31/72
None
後半のはじめに • 『決戦︕星の古戦場』の事例 – 秒間28万リクエストとの戦い • 後半は技術的改善について 33/72
古戦場の技術的改善 • 2つの技術的改善 • 中⻑期の改善を⼤切にする理由 • チューニングについて – チューニングの考え⽅ –
チューニングの事例 34/72
2つの技術的改善 • 発⽣したトラブルを解消し ユーザーに迷惑をかけない – 主に即時的なトラブル対応を⽰す 短期的な 改善 中⻑期の 改善
• その場かぎりではなく 未来を⾒据えた改善 – ユーザにより快適に遊んでもらう – 「最⾼のコンテンツ」を届けたい 35/72
古戦場の技術的改善 • 2つの技術的改善 • 中⻑期の改善を⼤切にする理由 • チューニングについて – チューニングの考え⽅ –
チューニングの事例 36/72
中⻑期の改善を⼤切にする理由 • より良いプレー環境の実現 – 軽快なレスポンスのために、 継続的にチューニング • トラブルを未然に防ぐ – レスポンス悪化によって特にDBは
障害リスクが⾼まるため、 継続的にチューニング 37/72
古戦場の技術的改善 • 2つの技術的改善 • 中⻑期の改善を⼤切にする理由 • チューニングについて – チューニングの考え⽅ –
チューニングの事例 38/72
チューニングについて • Cygames のチューニング – DBクエリチューニング – 各種サーバー設定のチューニング – Webサーバーチューニング
– プログラムチューニング – etc 39/72
古戦場の技術的改善 • 2つの技術的改善 • 中⻑期の改善を⼤切にする理由 • チューニングについて – チューニングの考え⽅ –
チューニングの事例 40/72
チューニングの考え⽅ • 5つのポイントを紹介 1. 聖域を作らない 2. 現象と原因 3. 変化に追従する 4.
⼿段の選択 5. チューニングの落とし⽳ 41/72
チューニングの考え⽅ 1. 聖域を作らない 2. 現象と原因 3. 変化に追従する 4. ⼿段の選択 5.
チューニングの落とし⽳ 42/72
1.聖域を作らない • チューニング対象に壁を作らない – ゲームプログラムのみならず フレームワークやライブラリも チューニング対象 – ハードやミドルウェアは 関係各所と連携
43/72
チューニングの考え⽅ 1. 聖域を作らない 2. 現象と原因 3. 変化に追従する 4. ⼿段の選択 5.
チューニングの落とし⽳ 44/72
2.現象と原因 • 発⾒した現象を 深く追求し原因を特定する – ミドルウェアのソースコードまで 必要であれば追求することも – Zend Engine
内部の挙動まで 45/72
チューニングの考え⽅ 1. 聖域を作らない 2. 現象と原因 3. 変化に追従する 4. ⼿段の選択 5.
チューニングの落とし⽳ 46/72
3.変化に追従する • ユーザー⾏動による変化 – 『決戦︕星の古戦場』中はバトル、 終了直後はアイテム/プレゼントに集中 バトル系DB群 アイテム系DB群 バトル終了 47/72
チューニングの考え⽅ 1. 聖域を作らない 2. 現象と原因 3. 変化に追従する 4. ⼿段の選択 5.
チューニングの落とし⽳ 48/72
4.⼿段の選択 • ⽬的を踏まえて選択する – 基本はデータ構造とロジックの調整 – スケールアウトは選択肢の1つ • ⻑期運⽤のメリット –
「性能を引き出すことができ」 「限界を知っている」から適切に選択が可能 49/72
チューニングの考え⽅ 1. 聖域を作らない 2. 現象と原因 3. 変化に追従する 4. ⼿段の選択 5.
チューニングの落とし⽳ 50/72
5.チューニングの落とし⽳ • 銀の弾丸はない – 新しい技術でも、その性能を 引き出せなければ解決策にならない • チューニングしたら終わりではない – 新たなボトルネックが出現
新たな戦いが始まる 51/72
チューニングの考え⽅ • 5つのポイントを紹介 1. 聖域を作らない 2. 現象を追求する 3. 変化に追従する 4.
⼿段の選択 5. チューニングの落とし⽳ 52/72
古戦場の技術的改善 • 2つの技術的改善 • 中⻑期の改善を⼤切にする理由 • チューニングについて – チューニングの考え⽅ –
チューニングの事例 53/72
チューニングの事例 #1 • シンプルに紹介できる事例として 上記3つの合わせ技を紹介 聖域を 作らない 現象と 原因 ⼿段と
選択 54/72
チューニングの事例 #1 • フレームワークの変更 – ハイリスク :影響範囲が広い – 改善の意識が希薄になり⾒落としがち –
ハイリターン :影響範囲が広い フレームワークの改善事例を紹介します 聖域を作らない 55/72
チューニングの事例 #2 – 古戦場系APIにおける フレームワークのwalltimeを観察すると、 ORM参照で84,713μsec →現象 現象と原因 56/72
チューニングの事例 #3 – ORMクラスの⽣成処理も観察すると オブジェクト関係マッピングも 9,206μsec →現象 現象と原因 57/72
チューニングの事例 #4 1. 厳密な型チェックと変換ロジック 2. Compositeパターン(FKの参照先まで) 3. 上記を実現するための複雑なデータ構造 4. それらが要因となり必須になっている
メソッド呼び出し 機能的には⼀般的なORMだが・・ 現象と原因 58/72
チューニングの事例 #5 • グランブルーファンタジー特性 – 外部キーを利⽤しない – サブクエリや結合を利⽤しない – テーブル数(データ数)が⾮常に多い
– 参照回数が数百から数千にのぼることも この特性にORMが適してない →原因 現象と原因 59/72
ORMのチューニング #6 • ⽬標を明確にする – グランブルーファンタジーの 特性に最適なORMの作成 • 作りたいORMの要件定義 –
最速であること シンプルであること – ORMとしての扱いやすさは変えない ⼿段の選択 60/72
ORMのチューニング #7 • 概要設計 – ORM内部データ構造の再設計 – 参照をインスタンス変数アクセスに変更 – 利⽤してない機能を捨てる
– ORM Generatorで実装者の負担低減+α ⼿段の選択 61/72
ORMのチューニング #8 新 Query 新ドメイン ORM Observer 廃⽌ Relation 廃⽌
ゲーム ロジック 新 ORM 廃止 廃止 • 改善箇所の概要 データ参照の ⾼速化 データ参照の ⾼速化 オブジェクト関係 マッピング⾼速化 62/72
ORMのチューニング #9 作ってみました 63/72
ORMのチューニング #10 2.5 100 0.3 100 0 10 20 30
40 50 60 70 80 90 100 改善後ORM 改善前ORM データ参照 オブジェクト関係マッピング • 前後⽐較 (walltimeの相対⽐較) 64/72
ORMのチューニング #11 • 新しいORMの成果 – メリット • データ参照が最速に • オブジェクト関係マッピングも⾼速に
• 古戦場以外のAPIでも良い結果に – デメリット • カプセル化の観点でベストではない → アプリケーションレイヤーでカバー 65/72
チューニングのまとめ #1 • 5つのポイント+事例を紹介 1. 聖域を作らない 2. 現象を追求する 3. 変化に追従する
4. ⼿段の選択 5. チューニングの落とし⽳ 66/72
チューニングのまとめ #2 – ご紹介したようなチューニングを イテレーションしているから成果が出る – これまで748件のチューニングを実施 • PHP conference
2017で紹介した チューニングも機会があればご覧ください 現象発⾒ チューニング 効果測定 知⾒の 体系化 67/72
チューニングのまとめ #3 • 中⻑期的なチューニングの成果 レスポンスタイム推移(古戦場ごと) 平均response time 3 区間移動平均 (平均response
time) 古戦場系APIの 平均レスポンスタイム推移 (開催ごと) 68/72
「最⾼のコンテンツ」を みなさまにお届けするため 怯まずにチューニングする コア技術は⾃分たちで実装する
アジェンダ • はじめに • 『グランブルーファンタジー』 サーバーの現状 • 『決戦︕星の古戦場』の事例 – 古戦場を乗り切る運⽤体制
– 古戦場の技術的改善 • むすび 70/72
むすび #1 • 『グランブルーファンタジー』を ⽀えるサーバーサイドの技術 – サーバー運⽤の3本柱 – チューニングの考え⽅ →秒間28万リクエストを⽀えるため
どの要素も⽋かすことができない 71/72
むすび #2 • 『グランブルーファンタジー』を ⽀えるサーバーサイドの技術 – 6年間の試⾏錯誤の積み重ね – ユーザーと「ともに」歩んだ歴史 –
すべては「最⾼のコンテンツ」を みなさまにお届けするため 72/72