「リンクスリングス」でのPhoton採用事例

by CyberAgent SGE Engineer

Slide 1

Slide 1 text

「リンクスリングス」におけるサーバ構成と負荷試験 CEDEC 2019 株式会社サムザップ二宮章太石井岳

Slide 2

Slide 2 text

二宮章太 2015年 4月サイバーエージェント入社。サムザップに出向し、新規タイトルの開発に関わる。現在では、リンクスリングスのバトル機能を担当し、クライアントとPhotonServerのバトル機能の開発に携わる。自己紹介

Slide 3

Slide 3 text

会社概要株式会社サムザップ 2009年5月 CyberAgent 子会社として設立事業内容スマートフォン向けゲームアプリの企画・運営・配信

Slide 4

Slide 4 text

提供サービスリンクスリングス 2019年5月配信開始 4人対4人の陣取りアクションゲーム戦国炎舞 - KIZNA - 2013年4月配信開始戦国時代を舞台にしたカードバトルゲームこの素晴らしい世界に祝福を！ファンタスティックデイズ今冬配信予定

Slide 5

Slide 5 text

リンクスリングス

Slide 6

Slide 6 text

アジェンダ Photonサーバ構成 • 重視したポイント • 想定したトラブルとその対応負荷試験 • なぜ必要か • 準備すること • 結果に対する考察例

Slide 7

Slide 7 text

Photonの関わる機能

Slide 8

Slide 8 text

バトル回りの流れマッチングバトルリザルト

Slide 9

Slide 9 text

バトル回りの流れバトルリザルトマッチング Photon Server Web Serverからマッチングデータを取得 Web Serverに対戦データを送信

Slide 10

Slide 10 text

石井岳 2016年 4月サイバーエージェント入社。サムザップに出向し、新規タイトルの開発に関わる。 2018年10月よりPhotonServerへの移行を担当、 MasterServerの冗長化やログ・モニタリング等基盤の開発を行う。自己紹介

Slide 11

Slide 11 text

Photonサーバ構成

Slide 12

Slide 12 text

SDKのLoadBalancingアプリケーションの場合 PhotonServerの基本構成 MasterServer GameServer 1 GameServer 2 GameServer N User ロビー機能の提供 GameServerの負荷分散ゲームルーム機能の提供サーバ間通信でルーム・負荷状況を共有

Slide 13

Slide 13 text

• メインコンテンツであるバトルを途切れさせない高可用性 • 急な負荷の増大に迅速に対応できるオートスケールサーバ構成で重視したポイント

Slide 14

Slide 14 text

• MasterServerのダウン • GameServerのダウン • 急なユーザの増加想定される代表的なトラブル

Slide 15

Slide 15 text

MasterServerがダウンしたケーストラブルへの対応 MasterServer GameServer 1 GameServer 2 GameServer N User 新規ゲームが開始不能に

Slide 16

Slide 16 text

MasterServerのダウン • MasterServerを冗長化し、影響を最小限に抑えるトラブルへの対応 1.各MasterServerの死活監視 MasterServer 2 Compute Engine Cloud Load Balancing 2.NGだったMasterServerへの案内を停止 Cloud Memorystore 状態はデータストアで共有 MasterServer 1 Compute Engine User 接続先はロードバランサに一本化

Slide 17

Slide 17 text

GameServerのダウン • システムから切り離し、影響を最小限に抑えるトラブルへの対応 AdminServer Compute Engine 1.各GameServerの死活監視 Cloud Memorystore Cloud Load Balancing GameServer 2 Compute Engine 2.死活監視結果を取得 3.NGだったGameServerの情報を削除 GameServer 1 Compute Engine

Slide 18

Slide 18 text

急なユーザの増加 • CCU（同時接続数）を監視し、オートでGameServerの台数を増減トラブルへの対応 Cloud Memorystore 1.現在のCCUの書き込み 2.定期的なCCUのチェック 3.GameServerの増減 AdminServer Compute Engine GameServer Compute Engine

Slide 19

Slide 19 text

Cloud Load Balancing Data Store User リンクスリングスのPhotonServer構成 Cloud Memorystore Cloud Load Balancing AdminServer Compute Engine Developer 1 2 3 4 Photon Servers Multi Zone MasterServer Compute Engine GameServer Compute Engine GameServerやルーム・ユーザの情報を保持 MasterServerの死活監視・負荷分散ダウンしたMasterServerの切り離し GameServerの負荷分散全体の負荷に応じたGameServerの増減ダウンしたGameServerの切り離し GameServerの死活監視

Slide 20

Slide 20 text

MasterServerが一台ダウンしても影響が少ない • 状態はデータストアにあるので、クライアントは別のMasterServerに再接続するだけで大丈夫自然にスケールアウトできる • MasterServerもGameServerもサーバをただ増やすだけで大丈夫本構成のメリット

Slide 21

Slide 21 text

システム構成要素の増加と複雑化 • 管理/運用コストが増加した • 状態の更新が非同期になり、データ整合性維持の難易度が上がった MasterServerのパフォーマンス低下 • メモリとネットワークのアクセス速度の差は大きい本構成のデメリット

Slide 22

Slide 22 text

サーバ構成まとめ • メインコンテンツであるバトルを途切れさせない高可用性 • データストアをネットワーク上へ移し、MasterServerを冗長化 • 急な負荷の増大に迅速に対応できるオートスケール • 負荷の申告と監視で、人手を介さない最短でのGameServerの増減

Slide 23

Slide 23 text

負荷試験

Slide 24

Slide 24 text

構成 • クアッドコア（例：Intel Xeon E3-1270 v3、3.5GHz） • 8 GB RAM • 1 GBps NIC/アップリンクポート速度 GameServer 2000 ～ 3000 CCU MasterServer 約40000 CCU 一般的なPhotonServerの性能

Slide 25

Slide 25 text

負荷が変動する要因は様々 • ゲームルームごとのクライアント数 • メッセージ率（ルームごと、1秒あたりのメッセージ数の組み合わせ） • メッセージのサイズ • プロトコルの種類（高信頼性/低信頼性） • クライアントのプラットフォーム • サーバーハードウエアのスペック • etc 自分のサービスでも計測する必要があるなぜ負荷試験が必要？

Slide 26

Slide 26 text

正常に動作することの確認 • スケールアウト時にCCUがきちんと増えることの確認 • 長期間高負荷の環境における動作確認効率よい構成の導出 • コスパの良いサーバの性能 • 必要なサーバの数 • = サーバ1台あたりの上限CCU 負荷試験によって得たい情報

Slide 27

Slide 27 text

バトルを大量に行って負荷をかけたい方針 • 大量のクライアントを用意 • 実際のバトルを模倣した通信シナリオを作成 • 正常に動作するかどうかを確認課題 • 大量のクライアントはどうする？ • バトルを模倣した通信のシナリオはどう作る？ • 正常な動作はどう確認する？負荷試験の実施

Slide 28

Slide 28 text

Slide 29

Slide 29 text

別サーバに軽量クライアントを大量配置軽量のコンソール向けSDKで負荷試験用クライアントを自作アタック用のサーバを用意して大量配置大量のクライアントを用意 Container- Optimized OS Photon Client Photon Client … Photon Client Photon Server Compute Engine Master / Game Attack Server

Slide 30

Slide 30 text

結果、負荷試験用クライアントは重いアタックサーバ1台で 400CCU 程度サーバ台数を増やして対処大量のクライアントを用意 Photon Server Compute Engine Master / Game Attack Server Container-Optimized OS

Slide 31

Slide 31 text

大量クライアントの操作 Locust • 分散実行可能な負荷試験ツールアタックサーバの構成 Developer Attack Server Container-Optimized OS Locust Slave Attack Server Container-Optimized OS Locust Master Photon Server Compute Engine Master / Game

Slide 32

Slide 32 text

バトルを大量に行って負荷をかけたい課題 • 大量のクライアントはどうする？ • アタック用サーバを複数たてて、独自クライアントを配置 • Locustによる一斉操作でバトル大量発生 • バトルを模倣した通信のシナリオはどう作る？ • 正常な動作はどう確認する？負荷試験の実施

Slide 33

Slide 33 text

Slide 34

Slide 34 text

リンクスリングスの特徴 4 vs 4のリアルタイム陣取りバトル陣地の状態や自分や敵のキャラ武器によって動きが変わる最上位帯のユーザ間でも最適解の議論が繰り広げられるそれっぽいシナリオデータが作りづらいシナリオデータの取得

Slide 35

Slide 35 text

プレイログを使おう懸念点 • チューニング中に通信データが変化すると負荷が変わる • コンバータを作ってできるだけシナリオを変えない • 複数シナリオ使うことで負荷を平均化するシナリオデータの取得

Slide 36

Slide 36 text

専用のログ取得アプリを用意 • 送信データを全保存 • PUNのLoadBalancingPeer.OpCustomに入った全データ • サーバに変更を入れずに済む結果 • 色々面倒だった • 専用ビルドを作ってテストプレイ • 8人分の端末からデータを抜き出す • 不採用プレイログ取得～クライアント編～

Slide 37

Slide 37 text

サーバにログ保存機構を用意 • サーバへの変更は、Configで処理の回避が可能な変更にとどめる • サーバで受信したデータを全保存 • サーバに入ってデータを抜き出す結果 • 最新版の開発用ビルドを毎朝触る文化があり、手軽に取得できた • データは1台から取得すればよい • ものすごく楽になった • 採用プレイログ取得～サーバ編～

Slide 38

Slide 38 text

バトルを大量に行って負荷をかけたい課題 • 大量のクライアントはどうする？ • アタック用サーバをいくつかたてて、独自クライアントを配置 • Locustによる一斉操作でバトル大量発生 • バトルを模倣した通信のシナリオはどう作る？ • サーバで取得したプレイログを利用 • 正常な動作はどう確認する？負荷試験の実施

Slide 39

Slide 39 text

Slide 40

Slide 40 text

正しく動作しているかどうか • MasterServerの応答時間が適正値 • 接続時間 • ルームへのJoin時間 • GameServerの応答時間が適正値 • 陣取りの応答時間 • 負荷による不具合が起きていないかを確認 • バトル結果 • ログボトルネック調査/余裕の見積もり • CPU使用率 • メモリ使用量 • 通信データ量正常な動作の確認方針

Slide 41

Slide 41 text

基本はPhotonカウンター • CCU/通信関連データ/etc. 足りないものは自作 • CPU使用率 • メモリ使用量 • 陣取りの応答時間 • Photonへの接続～ルームへのJoinまでにかかる時間 etc. DataDogに全部投げるメトリクス

Slide 42

Slide 42 text

No content

Slide 43

Slide 43 text

バトルを大量に行って負荷をかけたい課題 • 大量のクライアントはどうする？ • アタック用サーバをいくつかたてて、独自クライアントを配置 • Locustによる一斉操作でバトル大量発生 • バトルを模倣した通信のシナリオはどう作る？ • サーバで取得したプレイログを利用 • 正常な動作はどう確認する？ • 接続時間や通信の応答時間を確認 • ボトルネックの特定や余裕の見積には様々なメトリクスが必要 • データはDataDogに貯めて、閲覧可能にしておくと良い負荷試験の実施

Slide 44

Slide 44 text

ちゃんとうごくことの確認 • スケールアウト時にCCUがきちんと増えることの確認 • 長期間高負荷の環境における動作確認効率よい構成を導き出す • コスパの良いサーバの性能を割り出す • 必要なサーバの数を割り出す • サーバ1台あたりの上限CCU 負荷試験によって得たい情報（再）

Slide 45

Slide 45 text

性能を下げれば費用が安くなる CPU/メモリ/通信量などをギリギリまで使うのがよい • どれかが余裕すぎるのはもったいないコスパの良いサーバ

Slide 46

Slide 46 text

結果データ考察 • CCU 2000の場合、CPUが限界近い => CPU増強してみる？GCPインスタンス費、ライセンス費も考慮 • CCU 2800の場合、CPU使用率が低く通信待ちキューに溜まっている => 帯域ネック. このCCUは捌けないサーバのスペックを変えて実験を繰り返し、最適なスペックを算出負荷試験の結果と考察の例

Slide 47

Slide 47 text

想定よりもCPU使用率が高かった対処したこと • 独自実装した負荷クライアント側のバグ • 送信頻度が高くなりすぎていた • PhotonServerのバッファリングが効いていなかった • 設定ファイルを修正して再び有効化 • ラグを吸収しようとして一部コマンドを遅延実行する処理が重かった • 重い処理は削除（ラグ吸収の効果も感じづらかった） • 到達保障設定の通信を厳選ポイント • 送信頻度が高いとCPU使用率が上がる • PhotonServerの設定には気を付けるチューニング

Slide 48

Slide 48 text

サーバスペック • GCP n1-highcpu-8 • ８コア • メモリ 7.2GB CCU 2900 最終的な性能

Slide 49

Slide 49 text

偽装クライアントを自作し、別サーバに大量配置アタックサーバをスケールして想定CCUを担保する作成の難しいシナリオは実データを使用負荷試験のバグとサーバの設定は注意負荷試験まとめ

Slide 50

Slide 50 text

Photonはフレームワークとして完成度が高いと思います。 PhotonServerの情報はまだまだ少ないですが、リンクスリングスの事例が何かの助けになれば幸いですさいごに