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
27k
グランブルーファンタジーを支えるサーバーサイドの技術
2020/02/14 Developers Summit 2020
Cygames
February 14, 2020
Tweet
Share
More Decks by Cygames
See All by Cygames
TiDBにおけるテーブル設計と最適化の事例
cygames
2
1.6k
『グランブルーファンタジー』100万行を超える大規模なシステム再構築~10周年のその先へ~
cygames
10
31k
グラブルミュージアム蒼の追想 MX4Dシアターのサウンド制作事例〜ゲームの世界観とアトラクション体験の両立に必要なこと〜
cygames
0
1.1k
AIによる自然言語処理・音声解析を用いたゲーム内会話パートの感情分析への取り組み
cygames
0
1.8k
最大100倍高速化!PHPからJavaへのFFIを実現する、JNIを用いた高速なサーバAPIの実装方法
cygames
0
370
AIによる自然言語処理を活用したゲームシナリオの誤字検出への取り組み
cygames
0
260
ツール保守コスト大幅削減!テクニカルアーティストによるツールログサービスの開発と運用事例
cygames
0
300
C#によるクライアント/サーバーの開発言語統一がもたらす高効率な開発体制 ~プリコネ!グランドマスターズ開発事例~
cygames
25
20k
「最高のコンテンツ」を支える、Cygamesのデータベース技術の今までとこれから 〜次世代データベース「TiDB」の検証を開始したCygamesの取り組み〜
cygames
0
5.6k
Other Decks in Technology
See All in Technology
20240725 LLMによるDXのビジョンと、今何からやるべきか @Azure OpenAI Service Dev Day
nrryuya
3
1.2k
MySQLのロックの種類とその競合
yoku0825
6
1.6k
運用改善、不都合な真実 / 20240722-ssmjp-kaizen
opelab
17
8.4k
AWS IAMのアンチパターン/AWSが考える最低権限実現へのアプローチ概略(JAWS-UG朝会#59資料改修20分版)
htan
0
330
コンテナ・K8s研修 - 後半 Kubernetes 基礎&ハンズオン【MIXI 24新卒技術研修】
mixi_engineers
PRO
1
120
開発と事業を繋ぐ!SREのオブザーバビリティ戦略 ~ Developers Summit 2024 Summer ~
leveragestech
0
640
Android研修【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
100
Classmethod Odyssey 登壇資料
yamahiro
0
390
AOAI Dev Day - Opening Session
yoshidashingo
2
470
Git 研修 Basic【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
310
「単なる OAuth 2.0 を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる」のか検証してみた
terara
0
380
楽しくGoを学び合う、LayerXの勉強会文化 / LayerX's study culture of having fun and learning Go together
ar_tama
2
350
Featured
See All Featured
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
26
1.6k
Imperfection Machines: The Place of Print at Facebook
scottboms
262
13k
Debugging Ruby Performance
tmm1
71
11k
The Invisible Customer
myddelton
117
13k
Optimising Largest Contentful Paint
csswizardry
18
2.6k
Writing Fast Ruby
sferik
623
60k
BBQ
matthewcrist
82
9k
No one is an island. Learnings from fostering a developers community.
thoeni
17
2.8k
Building Effective Engineering Teams - LeadDev
addyosmani
47
2.2k
Code Review Best Practice
trishagee
58
16k
Building Better People: How to give real-time feedback that sticks.
wjessup
357
18k
Bash Introduction
62gerente
607
210k
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