グランブルーファンタジーを支えるサーバーサイドの技術

by Cygames, Inc.

Embed

Start on current slide

Slide 1

Slide 1 text

No content

Slide 2

Slide 2 text

アジェンダ • はじめに • 『グランブルーファンタジー』サーバーの現状 • 『決戦︕星の古戦場』の事例 – 古戦場を乗り切る運⽤体制 – 古戦場の技術的改善 • むすび 2/72

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

Cygamesとは • 最⾼のコンテンツをつくる会社 4/72

Slide 5

Slide 5 text

『グランブルーファンタジー』 • 王道スマホRPG • 2014年3⽉〜 – 今年3⽉で6周年 – ユーザー数2500万⼈ – 今なお拡⼤を続ける 5/72

Slide 6

Slide 6 text

『グランブルーファンタジー』 • ⾼いアップデート頻度 – 仲間キャラは590⼈以上 – 武器は2,000種以上 – 多くのイベントを開催 6/72

Slide 7

Slide 7 text

アジェンダ • はじめに • 『グランブルーファンタジー』サーバーの現状 • 『決戦︕星の古戦場』の事例 – 古戦場を乗り切る運⽤体制 – 古戦場の技術的改善 • むすび 7/72

Slide 8

Slide 8 text

サーバーの現状 #1 • LAMP環境で提供 – Linux / Apache / MySQL / PHP • 多くのアクセスを扱う – ユーザー数 2500万⼈突破 – リクエスト数 15億/⽇ 8/72

Slide 9

Slide 9 text

サーバーの現状 #2 • アクセスが多い理由 – たくさん遊んでいただいているから – ブラウザゲームだから =ユーザーの操作ごとに通信操作ごとに通信 9/72

Slide 10

Slide 10 text

サーバーの現状 #3 • アクセスが特に増える⽇があるー平常時 15億/⽇ー「古戦場」時 40億/⽇ • 更に「古戦場」のピークには 28万リクエスト/秒に達するそれでも安定してサービスを提供したい 10/72

Slide 11

Slide 11 text

アジェンダ • はじめに • 『グランブルーファンタジー』サーバーの現状 • 『決戦︕星の古戦場』の事例 – 古戦場を乗り切る運⽤体制 – 古戦場の技術的改善 • むすび 11/72

Slide 12

Slide 12 text

『決戦︕星の古戦場』とは • 定期開催のゲーム内イベント – 獲得した貢献度(ポイント)を競う 12/72

Slide 13

Slide 13 text

『決戦︕星の古戦場』とは • 開始後からリクエストが急増 – 時に秒間28万リクエストに達する 13/72

Slide 14

Slide 14 text

トラブル事例① • リクエストが多すぎて… ロードバランサーの CPU使⽤率が100%に到達 – 急遽L7→L4に切り戻して対応 – 後⽇スケールアウトを実施 14/72

Slide 15

Slide 15 text

トラブル事例② • 発⾏クエリが多すぎて… データベースサーバーのメモリが枯渇しそうになる危機 – メンテナンスでbuffer pool size を変更 • 思いもよらなかった問題が起こる – 「古戦場」と「ともに」成⻑してきた 15/72

Slide 16

Slide 16 text

「思いもよらない問題」に観測と予測をもって少しでも早く気がつきボトルネックを取り除くことが必要

Slide 17

Slide 17 text

アジェンダ • はじめに • 『グランブルーファンタジー』サーバーの現状 • 『決戦︕星の古戦場』の事例 – 古戦場を乗り切る運⽤体制 – 古戦場の技術的改善 • むすび 17/72

Slide 18

Slide 18 text

古戦場を乗り切る運⽤体制 • 古戦場サーバー運⽤の3本柱 • どこが⽋けてもいけない 1. 万全の準備 2. ⾒守り 3. トラブル対応 18/72

Slide 19

Slide 19 text

古戦場サーバー運⽤の3本柱 1. 万全の準備 2. ⾒守り 3. トラブル対応 19/72

Slide 20

Slide 20 text

1.万全の準備 • 変化を予想し備えることが⼤切前回の観測結果変化を予想修正計測・ユーザー数の変化・イベント更新による遊び⽅の変化過去6年間の傾向から… 20/72

Slide 21

Slide 21 text

リクエスト数を予想する例 • ユーザー⾏動の変化を捉える前回開催のリクエスト数前回開催のユーザー数現在のユーザー数ボスの差異編成の差異ユーザー層の差異⽇程 etc. 21/72

Slide 22

Slide 22 text

古戦場サーバー運⽤の3本柱 1. 万全の準備 2. ⾒守り 3. トラブル対応 22/72

Slide 23

Slide 23 text

2. ⾒守り • 課題を⾒落とさないことが⼤切不具合の迅速な修正改善点の報告機能⾒守り負荷⾒守り瞬間的な事象の観測トレンドの観測不具合に気づく 23/72

Slide 24

Slide 24 text

課題を⾒落とさない為に • 複数のツールを活⽤ • Developers Summit 2017 「監視・解析ツールから読み解く︕ トラブル対応＆負荷対策」にて 24/72

Slide 25

Slide 25 text

実際に活躍しているツール • Mackerel • Kibana • New Relic • Percona Monitoring & Management • Xhprof • BigQuery • Datadog • ⾃動監視⽤途ごとに使い分けている 25/72

Slide 26

Slide 26 text

古戦場サーバー運⽤の3本柱 1. 万全の準備 2. ⾒守り 3. トラブル対応 26/72

Slide 27

Slide 27 text

3.トラブル対応 • Cygames では「CS最優先」 – ゲームを楽しく遊んでいただきたい – 障害発⽣時であってもユーザーへの影響を最⼩にしたい – 迅速に障害を取り除きたい 27/72

Slide 28

Slide 28 text

3.トラブル対応 • 迅速に障害を取り除く 1. 事象・ユーザー影響の把握 2. チーム内での情報の共有 3. 問題の切り分け 4. 作業の分担 28/72

Slide 29

Slide 29 text

古戦場を乗り切る運⽤体制 • サーバー運⽤の3本柱 • どこが⽋けてもいけない 1. 万全の準備 2. ⾒守り 3. トラブル対応 29/72

Slide 30

Slide 30 text

前半のむすび • 『決戦︕星の古戦場』の事例 – 秒間28万リクエストとの戦い • サーバー運⽤の3本柱 1. 万全の準備 2. ⾒守り 3. トラブル対応 30/72

Slide 31

Slide 31 text

アジェンダ • はじめに • 『グランブルーファンタジー』サーバーの現状 • 『決戦︕星の古戦場』の事例 – 古戦場を乗り切る運⽤体制 – 古戦場の技術的改善 • むすび 31/72

Slide 32

Slide 32 text

No content

Slide 33

Slide 33 text

後半のはじめに • 『決戦︕星の古戦場』の事例 – 秒間28万リクエストとの戦い • 後半は技術的改善について 33/72

Slide 34

Slide 34 text

古戦場の技術的改善 • 2つの技術的改善 • 中⻑期の改善を⼤切にする理由 • チューニングについて – チューニングの考え⽅ – チューニングの事例 34/72

Slide 35

Slide 35 text

２つの技術的改善 • 発⽣したトラブルを解消しユーザーに迷惑をかけない – 主に即時的なトラブル対応を⽰す短期的な改善中⻑期の改善 • その場かぎりではなく未来を⾒据えた改善 – ユーザにより快適に遊んでもらう – 「最⾼のコンテンツ」を届けたい 35/72

Slide 36

Slide 36 text

古戦場の技術的改善 • 2つの技術的改善 • 中⻑期の改善を⼤切にする理由 • チューニングについて – チューニングの考え⽅ – チューニングの事例 36/72

Slide 37

Slide 37 text

中⻑期の改善を⼤切にする理由 • より良いプレー環境の実現 – 軽快なレスポンスのために、継続的にチューニング • トラブルを未然に防ぐ – レスポンス悪化によって特にDBは障害リスクが⾼まるため、継続的にチューニング 37/72

Slide 38

Slide 38 text

古戦場の技術的改善 • 2つの技術的改善 • 中⻑期の改善を⼤切にする理由 • チューニングについて – チューニングの考え⽅ – チューニングの事例 38/72

Slide 39

Slide 39 text

チューニングについて • Cygames のチューニング – DBクエリチューニング – 各種サーバー設定のチューニング – Webサーバーチューニング – プログラムチューニング – etc 39/72

Slide 40

Slide 40 text

古戦場の技術的改善 • 2つの技術的改善 • 中⻑期の改善を⼤切にする理由 • チューニングについて – チューニングの考え⽅ – チューニングの事例 40/72

Slide 41

Slide 41 text

チューニングの考え⽅ • 5つのポイントを紹介 1. 聖域を作らない 2. 現象と原因 3. 変化に追従する 4. ⼿段の選択 5. チューニングの落とし⽳ 41/72

Slide 42

Slide 42 text

チューニングの考え⽅ 1. 聖域を作らない 2. 現象と原因 3. 変化に追従する 4. ⼿段の選択 5. チューニングの落とし⽳ 42/72

Slide 43

Slide 43 text

1.聖域を作らない • チューニング対象に壁を作らない – ゲームプログラムのみならずフレームワークやライブラリもチューニング対象 – ハードやミドルウェアは関係各所と連携 43/72

Slide 44

Slide 44 text

チューニングの考え⽅ 1. 聖域を作らない 2. 現象と原因 3. 変化に追従する 4. ⼿段の選択 5. チューニングの落とし⽳ 44/72

Slide 45

Slide 45 text

2.現象と原因 • 発⾒した現象を深く追求し原因を特定する – ミドルウェアのソースコードまで必要であれば追求することも – Zend Engine 内部の挙動まで 45/72

Slide 46

Slide 46 text

チューニングの考え⽅ 1. 聖域を作らない 2. 現象と原因 3. 変化に追従する 4. ⼿段の選択 5. チューニングの落とし⽳ 46/72

Slide 47

Slide 47 text

３.変化に追従する • ユーザー⾏動による変化 – 『決戦︕星の古戦場』中はバトル、終了直後はアイテム／プレゼントに集中バトル系DB群アイテム系DB群バトル終了 47/72

Slide 48

Slide 48 text

チューニングの考え⽅ 1. 聖域を作らない 2. 現象と原因 3. 変化に追従する 4. ⼿段の選択 5. チューニングの落とし⽳ 48/72

Slide 49

Slide 49 text

４.⼿段の選択 • ⽬的を踏まえて選択する – 基本はデータ構造とロジックの調整 – スケールアウトは選択肢の１つ • ⻑期運⽤のメリット – 「性能を引き出すことができ」「限界を知っている」から適切に選択が可能 49/72

Slide 50

Slide 50 text

チューニングの考え⽅ 1. 聖域を作らない 2. 現象と原因 3. 変化に追従する 4. ⼿段の選択 5. チューニングの落とし⽳ 50/72

Slide 51

Slide 51 text

5.チューニングの落とし⽳ • 銀の弾丸はない – 新しい技術でも、その性能を引き出せなければ解決策にならない • チューニングしたら終わりではない – 新たなボトルネックが出現新たな戦いが始まる 51/72

Slide 52

Slide 52 text

チューニングの考え⽅ • 5つのポイントを紹介 1. 聖域を作らない 2. 現象を追求する 3. 変化に追従する 4. ⼿段の選択 5. チューニングの落とし⽳ 52/72

Slide 53

Slide 53 text

古戦場の技術的改善 • 2つの技術的改善 • 中⻑期の改善を⼤切にする理由 • チューニングについて – チューニングの考え⽅ – チューニングの事例 53/72

Slide 54

Slide 54 text

チューニングの事例 #1 • シンプルに紹介できる事例として上記3つの合わせ技を紹介聖域を作らない現象と原因⼿段と選択 54/72

Slide 55

Slide 55 text

チューニングの事例 #1 • フレームワークの変更 – ハイリスク :影響範囲が広い – 改善の意識が希薄になり⾒落としがち – ハイリターン :影響範囲が広いフレームワークの改善事例を紹介します聖域を作らない 55/72

Slide 56

Slide 56 text

チューニングの事例 #2 – 古戦場系APIにおけるフレームワークのwalltimeを観察すると、 ORM参照で84,713μsec →現象現象と原因 56/72

Slide 57

Slide 57 text

チューニングの事例 #3 – ORMクラスの⽣成処理も観察するとオブジェクト関係マッピングも 9,206μsec →現象現象と原因 57/72

Slide 58

Slide 58 text

チューニングの事例 #4 1. 厳密な型チェックと変換ロジック 2. Compositeパターン(FKの参照先まで) 3. 上記を実現するための複雑なデータ構造 4. それらが要因となり必須になっているメソッド呼び出し機能的には⼀般的なORMだが・・現象と原因 58/72

Slide 59

Slide 59 text

チューニングの事例 #5 • グランブルーファンタジー特性 – 外部キーを利⽤しない – サブクエリや結合を利⽤しない – テーブル数（データ数）が⾮常に多い – 参照回数が数百から数千にのぼることもこの特性にORMが適してない →原因現象と原因 59/72

Slide 60

Slide 60 text

ORMのチューニング #6 • ⽬標を明確にする – グランブルーファンタジーの特性に最適なORMの作成 • 作りたいORMの要件定義 – 最速であることシンプルであること – ORMとしての扱いやすさは変えない⼿段の選択 60/72

Slide 61

Slide 61 text

ORMのチューニング #7 • 概要設計 – ORM内部データ構造の再設計 – 参照をインスタンス変数アクセスに変更 – 利⽤してない機能を捨てる – ORM Generatorで実装者の負担低減＋α ⼿段の選択 61/72

Slide 62

Slide 62 text

ORMのチューニング #8 新 Query 新ドメイン ORM Observer 廃⽌ Relation 廃⽌ゲームロジック新 ORM 廃止廃止 • 改善箇所の概要データ参照の⾼速化データ参照の⾼速化オブジェクト関係マッピング⾼速化 62/72

Slide 63

Slide 63 text

ORMのチューニング #9 作ってみました 63/72

Slide 64

Slide 64 text

ORMのチューニング #10 2.5 100 0.3 100 0 10 20 30 40 50 60 70 80 90 100 改善後ORM 改善前ORM データ参照オブジェクト関係マッピング • 前後⽐較 (walltimeの相対⽐較) 64/72

Slide 65

Slide 65 text

ORMのチューニング #11 • 新しいORMの成果 – メリット • データ参照が最速に • オブジェクト関係マッピングも⾼速に • 古戦場以外のAPIでも良い結果に – デメリット • カプセル化の観点でベストではない → アプリケーションレイヤーでカバー 65/72

Slide 66

Slide 66 text

チューニングのまとめ #1 • 5つのポイント+事例を紹介 1. 聖域を作らない 2. 現象を追求する 3. 変化に追従する 4. ⼿段の選択 5. チューニングの落とし⽳ 66/72

Slide 67

Slide 67 text

チューニングのまとめ #2 – ご紹介したようなチューニングをイテレーションしているから成果が出る – これまで748件のチューニングを実施 • PHP conference 2017で紹介したチューニングも機会があればご覧ください現象発⾒チューニング効果測定知⾒の体系化 67/72

Slide 68

Slide 68 text

チューニングのまとめ #3 • 中⻑期的なチューニングの成果レスポンスタイム推移（古戦場ごと）平均response time 3 区間移動平均 (平均response time) 古戦場系APIの平均レスポンスタイム推移（開催ごと） 68/72

Slide 69

Slide 69 text

「最⾼のコンテンツ」をみなさまにお届けするため怯まずにチューニングするコア技術は⾃分たちで実装する

Slide 70

Slide 70 text

アジェンダ • はじめに • 『グランブルーファンタジー』サーバーの現状 • 『決戦︕星の古戦場』の事例 – 古戦場を乗り切る運⽤体制 – 古戦場の技術的改善 • むすび 70/72

Slide 71

Slide 71 text

むすび #1 • 『グランブルーファンタジー』を⽀えるサーバーサイドの技術 – サーバー運⽤の3本柱 – チューニングの考え⽅ →秒間28万リクエストを⽀えるためどの要素も⽋かすことができない 71/72

Slide 72

Slide 72 text

むすび #2 • 『グランブルーファンタジー』を⽀えるサーバーサイドの技術 – 6年間の試⾏錯誤の積み重ね – ユーザーと「ともに」歩んだ歴史 – すべては「最⾼のコンテンツ」をみなさまにお届けするため 72/72