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

510ec964f5d26c2724c883fd7b671e3d?s=47 Cygames
February 14, 2020

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

2020/02/14 Developers Summit 2020

510ec964f5d26c2724c883fd7b671e3d?s=128

Cygames

February 14, 2020
Tweet

Transcript

  1. None
  2. アジェンダ • はじめに • 『グランブルーファンタジー』 サーバーの現状 • 『決戦︕星の古戦場』の事例 – 古戦場を乗り切る運⽤体制

    – 古戦場の技術的改善 • むすび 2/72
  3. None
  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
  32. None
  33. 後半のはじめに • 『決戦︕星の古戦場』の事例 – 秒間28万リクエストとの戦い • 後半は技術的改善について 33/72

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

    チューニングの事例 34/72
  35. 2つの技術的改善 • 発⽣したトラブルを解消し ユーザーに迷惑をかけない – 主に即時的なトラブル対応を⽰す 短期的な 改善 中⻑期の 改善

    • その場かぎりではなく 未来を⾒据えた改善 – ユーザにより快適に遊んでもらう – 「最⾼のコンテンツ」を届けたい 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. 3.変化に追従する • ユーザー⾏動による変化 – 『決戦︕星の古戦場』中はバトル、 終了直後はアイテム/プレゼントに集中 バトル系DB群 アイテム系DB群 バトル終了 47/72

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

    チューニングの落とし⽳ 48/72
  49. 4.⼿段の選択 • ⽬的を踏まえて選択する – 基本はデータ構造とロジックの調整 – スケールアウトは選択肢の1つ • ⻑期運⽤のメリット –

    「性能を引き出すことができ」 「限界を知っている」から適切に選択が可能 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