Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

CEDEC 2019 「「リンクスリングス」でのPhoton採用事例および、Photon CTOによる最新サービスPhoton Quantumの紹介」のサムザップ発表部分の資料です。

CyberAgent SGE Engineer

September 04, 2019
Tweet

More Decks by CyberAgent SGE Engineer

Other Decks in Technology

Transcript

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  5. リンクスリングス

    View full-size slide

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

    View full-size slide

  7. Photonの関わる機能

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  11. Photonサーバ構成

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  19. 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の死活監視

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  23. 負荷試験

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    Photon Client
    Photon Server
    Compute Engine
    Master / Game
    Attack Server

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide