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

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

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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