Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
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