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

2020/02/14 Developers Summit 2020

Transcript

2. アジェンダ • はじめに • 『グランブルーファンタジー』 サーバーの現状 • 『決戦︕星の古戦場』の事例 – 古戦場を乗り切る運⽤体制 – 古戦場の技術的改善 • むすび 2/72
4. Cygamesとは • 最⾼のコンテンツをつくる会社 4/72
5. 『グランブルーファンタジー』 • 王道スマホRPG • 2014年3⽉〜 – 今年3⽉で6周年 – ユーザー数2500万⼈ – 今なお拡⼤を続ける 5/72
6. 『グランブルーファンタジー』 • ⾼いアップデート頻度 – 仲間キャラは590⼈以上 – 武器は2,000種以上 – 多くのイベントを開催 6/72
7. アジェンダ • はじめに • 『グランブルーファンタジー』 サーバーの現状 • 『決戦︕星の古戦場』の事例 – 古戦場を乗り切る運⽤体制 – 古戦場の技術的改善 • むすび 7/72
8. サーバーの現状 #1 • LAMP環境で提供 – Linux / Apache / MySQL / PHP • 多くのアクセスを扱う – ユーザー数 2500万⼈突破 – リクエスト数 15億/⽇ 8/72
9. サーバーの現状 #2 • アクセスが多い理由 – たくさん遊んでいただいているから – ブラウザゲームだから =ユーザーの操作ごとに通信 操作ごとに 通信 9/72
10. サーバーの現状 #3 • アクセスが特に増える⽇がある ー 平常時 15億/⽇ ー「古戦場」時 40億/⽇ • 更に「古戦場」のピークには 28万リクエスト/秒 に達する それでも安定してサービスを提供したい 10/72
11. アジェンダ • はじめに • 『グランブルーファンタジー』 サーバーの現状 • 『決戦︕星の古戦場』の事例 – 古戦場を乗り切る運⽤体制 – 古戦場の技術的改善 • むすび 11/72
12. 『決戦︕星の古戦場』とは • 定期開催のゲーム内イベント – 獲得した貢献度(ポイント)を競う 12/72
13. 『決戦︕星の古戦場』とは • 開始後からリクエストが急増 – 時に秒間28万リクエストに達する 13/72
14. トラブル事例① • リクエストが多すぎて… ロードバランサーの CPU使⽤率が100%に到達 – 急遽L7→L4に切り戻して対応 – 後⽇スケールアウトを実施 14/72
15. トラブル事例② • 発⾏クエリが多すぎて… データベースサーバーのメモリが 枯渇しそうになる危機 – メンテナンスでbuffer pool size を変更 • 思いもよらなかった問題が起こる – 「古戦場」と「ともに」成⻑してきた 15/72
16. 「思いもよらない問題」に 観測と予測をもって 少しでも早く気がつき ボトルネックを取り除く ことが必要
17. アジェンダ • はじめに • 『グランブルーファンタジー』 サーバーの現状 • 『決戦︕星の古戦場』の事例 – 古戦場を乗り切る運⽤体制 – 古戦場の技術的改善 • むすび 17/72
18. 古戦場を乗り切る運⽤体制 • 古戦場サーバー運⽤の3本柱 • どこが⽋けてもいけない 1. 万全の 準備 2. ⾒守り 3. トラブル 対応 18/72
19. 古戦場サーバー運⽤の3本柱 1. 万全の 準備 2. ⾒守り 3. トラブル 対応 19/72
20. 1.万全の準備 • 変化を予想し備えることが⼤切 前回の 観測結果 変化を 予想 修正 計測 ・ユーザー数の変化 ・イベント更新による 遊び⽅の変化 過去6年間の傾向から… 20/72
21. リクエスト数を予想する例 • ユーザー⾏動の変化を捉える 前回開催の リクエスト数 前回開催の ユーザー数 現在の ユーザー数 ボスの差異 編成の差異 ユーザー 層の差異 ⽇程 etc. 21/72
22. 古戦場サーバー運⽤の3本柱 1. 万全の 準備 2. ⾒守り 3. トラブル 対応 22/72
23. 2. ⾒守り • 課題を⾒落とさないことが⼤切 不具合の 迅速な修正 改善点の 報告 機能⾒守り 負荷⾒守り 瞬間的な 事象の観測 トレンド の観測 不具合に 気づく 23/72
24. 課題を⾒落とさない為に • 複数のツールを活⽤ • Developers Summit 2017 「監視・解析ツールから読み解く︕ トラブル対応＆負荷対策」にて 24/72
25. 実際に活躍しているツール • Mackerel • Kibana • New Relic • Percona Monitoring & Management • Xhprof • BigQuery • Datadog • ⾃動監視 ⽤途ごとに 使い分けている 25/72
26. 古戦場サーバー運⽤の3本柱 1. 万全の 準備 2. ⾒守り 3. トラブル 対応 26/72
27. 3.トラブル対応 • Cygames では「CS最優先」 – ゲームを楽しく遊んでいただきたい – 障害発⽣時であっても ユーザーへの影響を最⼩にしたい – 迅速に障害を取り除きたい 27/72
28. 3.トラブル対応 • 迅速に障害を取り除く 1. 事象・ユーザー影響の把握 2. チーム内での情報の共有 3. 問題の切り分け 4. 作業の分担 28/72
29. 古戦場を乗り切る運⽤体制 • サーバー運⽤の3本柱 • どこが⽋けてもいけない 1. 万全の 準備 2. ⾒守り 3. トラブル 対応 29/72
30. 前半のむすび • 『決戦︕星の古戦場』の事例 – 秒間28万リクエストとの戦い • サーバー運⽤の3本柱 1. 万全の 準備 2. ⾒守り 3. トラブル 対応 30/72
31. アジェンダ • はじめに • 『グランブルーファンタジー』 サーバーの現状 • 『決戦︕星の古戦場』の事例 – 古戦場を乗り切る運⽤体制 – 古戦場の技術的改善 • むすび 31/72
33. 後半のはじめに • 『決戦︕星の古戦場』の事例 – 秒間28万リクエストとの戦い • 後半は技術的改善について 33/72
34. 古戦場の技術的改善 • 2つの技術的改善 • 中⻑期の改善を⼤切にする理由 • チューニングについて – チューニングの考え⽅ – チューニングの事例 34/72
35. ２つの技術的改善 • 発⽣したトラブルを解消し ユーザーに迷惑をかけない – 主に即時的なトラブル対応を⽰す 短期的な 改善 中⻑期の 改善 • その場かぎりではなく 未来を⾒据えた改善 – ユーザにより快適に遊んでもらう – 「最⾼のコンテンツ」を届けたい 35/72
36. 古戦場の技術的改善 • 2つの技術的改善 • 中⻑期の改善を⼤切にする理由 • チューニングについて – チューニングの考え⽅ – チューニングの事例 36/72
37. 中⻑期の改善を⼤切にする理由 • より良いプレー環境の実現 – 軽快なレスポンスのために、 継続的にチューニング • トラブルを未然に防ぐ – レスポンス悪化によって特にDBは 障害リスクが⾼まるため、 継続的にチューニング 37/72
38. 古戦場の技術的改善 • 2つの技術的改善 • 中⻑期の改善を⼤切にする理由 • チューニングについて – チューニングの考え⽅ – チューニングの事例 38/72
39. チューニングについて • Cygames のチューニング – DBクエリチューニング – 各種サーバー設定のチューニング – Webサーバーチューニング – プログラムチューニング – etc 39/72
40. 古戦場の技術的改善 • 2つの技術的改善 • 中⻑期の改善を⼤切にする理由 • チューニングについて – チューニングの考え⽅ – チューニングの事例 40/72
41. チューニングの考え⽅ • 5つのポイントを紹介 1. 聖域を作らない 2. 現象と原因 3. 変化に追従する 4. ⼿段の選択 5. チューニングの落とし⽳ 41/72
42. チューニングの考え⽅ 1. 聖域を作らない 2. 現象と原因 3. 変化に追従する 4. ⼿段の選択 5. チューニングの落とし⽳ 42/72
43. 1.聖域を作らない • チューニング対象に壁を作らない – ゲームプログラムのみならず フレームワークやライブラリも チューニング対象 – ハードやミドルウェアは 関係各所と連携 43/72
44. チューニングの考え⽅ 1. 聖域を作らない 2. 現象と原因 3. 変化に追従する 4. ⼿段の選択 5. チューニングの落とし⽳ 44/72
45. 2.現象と原因 • 発⾒した現象を 深く追求し原因を特定する – ミドルウェアのソースコードまで 必要であれば追求することも – Zend Engine 内部の挙動まで 45/72
46. チューニングの考え⽅ 1. 聖域を作らない 2. 現象と原因 3. 変化に追従する 4. ⼿段の選択 5. チューニングの落とし⽳ 46/72
47. ３.変化に追従する • ユーザー⾏動による変化 – 『決戦︕星の古戦場』中はバトル、 終了直後はアイテム／プレゼントに集中 バトル系DB群 アイテム系DB群 バトル終了 47/72
48. チューニングの考え⽅ 1. 聖域を作らない 2. 現象と原因 3. 変化に追従する 4. ⼿段の選択 5. チューニングの落とし⽳ 48/72
49. ４.⼿段の選択 • ⽬的を踏まえて選択する – 基本はデータ構造とロジックの調整 – スケールアウトは選択肢の１つ • ⻑期運⽤のメリット – 「性能を引き出すことができ」 「限界を知っている」から適切に選択が可能 49/72
50. チューニングの考え⽅ 1. 聖域を作らない 2. 現象と原因 3. 変化に追従する 4. ⼿段の選択 5. チューニングの落とし⽳ 50/72
51. 5.チューニングの落とし⽳ • 銀の弾丸はない – 新しい技術でも、その性能を 引き出せなければ解決策にならない • チューニングしたら終わりではない – 新たなボトルネックが出現 新たな戦いが始まる 51/72
52. チューニングの考え⽅ • 5つのポイントを紹介 1. 聖域を作らない 2. 現象を追求する 3. 変化に追従する 4. ⼿段の選択 5. チューニングの落とし⽳ 52/72
53. 古戦場の技術的改善 • 2つの技術的改善 • 中⻑期の改善を⼤切にする理由 • チューニングについて – チューニングの考え⽅ – チューニングの事例 53/72
54. チューニングの事例 #1 • シンプルに紹介できる事例として 上記3つの合わせ技を紹介 聖域を 作らない 現象と 原因 ⼿段と 選択 54/72
55. チューニングの事例 #1 • フレームワークの変更 – ハイリスク :影響範囲が広い – 改善の意識が希薄になり⾒落としがち – ハイリターン :影響範囲が広い フレームワークの改善事例を紹介します 聖域を作らない 55/72
56. チューニングの事例 #2 – 古戦場系APIにおける フレームワークのwalltimeを観察すると、 ORM参照で84,713μsec →現象 現象と原因 56/72
57. チューニングの事例 #3 – ORMクラスの⽣成処理も観察すると オブジェクト関係マッピングも 9,206μsec →現象 現象と原因 57/72
58. チューニングの事例 #4 1. 厳密な型チェックと変換ロジック 2. Compositeパターン(FKの参照先まで) 3. 上記を実現するための複雑なデータ構造 4. それらが要因となり必須になっている メソッド呼び出し 機能的には⼀般的なORMだが・・ 現象と原因 58/72
59. チューニングの事例 #5 • グランブルーファンタジー特性 – 外部キーを利⽤しない – サブクエリや結合を利⽤しない – テーブル数（データ数）が⾮常に多い – 参照回数が数百から数千にのぼることも この特性にORMが適してない →原因 現象と原因 59/72
60. ORMのチューニング #6 • ⽬標を明確にする – グランブルーファンタジーの 特性に最適なORMの作成 • 作りたいORMの要件定義 – 最速であること ­ シンプルであること – ORMとしての扱いやすさは変えない ⼿段の選択 60/72
61. ORMのチューニング #7 • 概要設計 – ORM内部データ構造の再設計 – 参照をインスタンス変数アクセスに変更 – 利⽤してない機能を捨てる – ORM Generatorで実装者の負担低減＋α ⼿段の選択 61/72
62. ORMのチューニング #8 新 Query 新ドメイン ORM Observer 廃⽌ Relation 廃⽌ ゲーム ロジック 新 ORM 廃止 廃止 • 改善箇所の概要 データ参照の ⾼速化 データ参照の ⾼速化 オブジェクト関係 マッピング⾼速化 62/72
63. ORMのチューニング #9 作ってみました 63/72
64. ORMのチューニング #10 2.5 100 0.3 100 0 10 20 30 40 50 60 70 80 90 100 改善後ORM 改善前ORM データ参照 オブジェクト関係マッピング • 前後⽐較 (walltimeの相対⽐較) 64/72
65. ORMのチューニング #11 • 新しいORMの成果 – メリット • データ参照が最速に • オブジェクト関係マッピングも⾼速に • 古戦場以外のAPIでも良い結果に – デメリット • カプセル化の観点でベストではない → アプリケーションレイヤーでカバー 65/72
66. チューニングのまとめ #1 • 5つのポイント+事例を紹介 1. 聖域を作らない 2. 現象を追求する 3. 変化に追従する 4. ⼿段の選択 5. チューニングの落とし⽳ 66/72
67. チューニングのまとめ #2 – ご紹介したようなチューニングを イテレーションしているから成果が出る – これまで748件のチューニングを実施 • PHP conference 2017で紹介した チューニングも機会があればご覧ください 現象発⾒ チューニング 効果測定 知⾒の 体系化 67/72
68. チューニングのまとめ #3 • 中⻑期的なチューニングの成果 レスポンスタイム推移（古戦場ごと） 平均response time 3 区間移動平均 (平均response time) 古戦場系APIの 平均レスポンスタイム推移 （開催ごと） 68/72
69. 「最⾼のコンテンツ」を みなさまにお届けするため 怯まずにチューニングする コア技術は⾃分たちで実装する
70. アジェンダ • はじめに • 『グランブルーファンタジー』 サーバーの現状 • 『決戦︕星の古戦場』の事例 – 古戦場を乗り切る運⽤体制 – 古戦場の技術的改善 • むすび 70/72
71. むすび #1 • 『グランブルーファンタジー』を ⽀えるサーバーサイドの技術 – サーバー運⽤の3本柱 – チューニングの考え⽅ →秒間28万リクエストを⽀えるため どの要素も⽋かすことができない 71/72
72. むすび #2 • 『グランブルーファンタジー』を ⽀えるサーバーサイドの技術 – 6年間の試⾏錯誤の積み重ね – ユーザーと「ともに」歩んだ歴史 – すべては「最⾼のコンテンツ」を みなさまにお届けするため 72/72