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
グラブルミュージアム蒼の追想 MX4Dシアターのサウンド制作事例〜ゲームの世界観とアトラクション体験の両立に必要なこと〜
cygames
0
960
AIによる自然言語処理・音声解析を用いたゲーム内会話パートの感情分析への取り組み
cygames
0
1.2k
最大100倍高速化!PHPからJavaへのFFIを実現する、JNIを用いた高速なサーバAPIの実装方法
cygames
0
220
AIによる自然言語処理を活用したゲームシナリオの誤字検出への取り組み
cygames
0
180
ツール保守コスト大幅削減!テクニカルアーティストによるツールログサービスの開発と運用事例
cygames
0
190
C#によるクライアント/サーバーの開発言語統一がもたらす高効率な開発体制 ~プリコネ!グランドマスターズ開発事例~
cygames
24
20k
「最高のコンテンツ」を支える、Cygamesのデータベース技術の今までとこれから 〜次世代データベース「TiDB」の検証を開始したCygamesの取り組み〜
cygames
0
5k
ウマ娘 プリティーダービーのコンテ制作事例 ~コンテ制作専任チームの誕生とキャラクターを輝かせるコンテ術~
cygames
2
8.4k
ウマ娘 プリティーダービーの大規模シナリオ制作を効率化するソリューション~社内Webアプリ開発運用事例~
cygames
1
4.8k
Other Decks in Technology
See All in Technology
サービス成長と共に肥大化するモノレポ、長くなるCI時間 / As services grow, monorepos get bigger and CI time gets longer
kohbis
5
2.1k
初心者が行く!サーバレスWebアプリ開発の道
nagaharutogawa
0
440
ビジネスロジックを「型」で表現するOOPのための関数型DDD / Functional And Type-Safe DDD for OOP
yuitosato
29
12k
TypeScript Quiz (Encraft #12 Frontend Quiz Night)
uhyo
5
540
中央集権体制からDataOpsへの転換 / centralized-to-dataops-transformation
pei0804
7
1.5k
中学生でもわかる深層学習
e869120
6
960
私のRSpecの書き方 / How I write RSpec
tmtms
4
830
Why do you get AWS certificates
hirosys
0
110
依存ライブラリはどこに?
takesection
0
110
生成AIサービスPanorama AIご説明資料
sdt
0
300
ハイパフォーマンスな組織をつくるための開発生産性の考え方 / developer-productivity-high-performer-link-and-motivation
lmi
3
260
Getting started with controlling LEGO using Swift
hcrane
0
130
Featured
See All Featured
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
272
12k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
319
20k
[RailsConf 2023] Rails as a piece of cake
palkan
21
3.8k
Agile that works and the tools we love
rasmusluckow
323
20k
Faster Mobile Websites
deanohume
296
30k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
14
1.3k
5 minutes of I Can Smell Your CMS
philhawksworth
199
19k
Unsuck your backbone
ammeep
661
56k
Code Review Best Practice
trishagee
54
15k
StorybookのUI Testing Handbookを読んだ
zakiyama
10
4.5k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
352
28k
Designing on Purpose - Digital PM Summit 2013
jponch
109
6.4k
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