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. SDKのLoadBalancingアプリケーションの場合 PhotonServerの基本構成 MasterServer GameServer 1 GameServer 2 GameServer N User

    ロビー機能の提供 GameServerの負荷分散 ゲームルーム機能の提供 サーバ間通信で ルーム・負荷状況を共有
  2. MasterServerのダウン • MasterServerを冗長化し、影響を最小限に抑える トラブルへの対応 1.各MasterServerの死活監視 MasterServer 2 Compute Engine Cloud

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

    Cloud Load Balancing GameServer 2 Compute Engine 2.死活監視結果を取得 3.NGだったGameServerの情報を削除 GameServer 1 Compute Engine
  4. 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の死活監視
  5. 構成 • クアッドコア(例:Intel Xeon E3-1270 v3、3.5GHz) • 8 GB RAM

    • 1 GBps NIC/アップリンクポート速度 GameServer 2000 ~ 3000 CCU MasterServer 約40000 CCU 一般的なPhotonServerの性能
  6. 負荷が変動する要因は様々 • ゲームルームごとのクライアント数 • メッセージ率(ルームごと、1秒あたりのメッセージ数の組み合わせ) • メッセージのサイズ • プロトコルの種類(高信頼性/低信頼性) •

    クライアントのプラットフォーム • サーバーハードウエアのスペック • etc 自分のサービスでも計測する必要がある なぜ負荷試験が必要?
  7. バトルを大量に行って負荷をかけたい 方針 • 大量のクライアントを用意 • 実際のバトルを模倣した通信シナリオを作成 • 正常に動作するかどうかを確認 課題 •

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

    大量のクライアントはどうする? • バトルを模倣した通信のシナリオはどう作る? • 正常な動作はどう確認する? 負荷試験の実施
  9. 専用のログ取得アプリを用意 • 送信データを全保存 • PUNのLoadBalancingPeer.OpCustomに入った全データ • サーバに変更を入れずに済む 結果 • 色々面倒だった

    • 専用ビルドを作ってテストプレイ • 8人分の端末からデータを抜き出す • 不採用 プレイログ取得 ~クライアント編~
  10. 正しく動作しているかどうか • MasterServerの応答時間が適正値 • 接続時間 • ルームへのJoin時間 • GameServerの応答時間が適正値 •

    陣取りの応答時間 • 負荷による不具合が起きていないかを確認 • バトル結果 • ログ ボトルネック調査/余裕の見積もり • CPU使用率 • メモリ使用量 • 通信データ量 正常な動作の確認方針
  11. 基本はPhotonカウンター • CCU/通信関連データ/etc. 足りないものは自作 • CPU使用率 • メモリ使用量 • 陣取りの応答時間

    • Photonへの接続~ルームへのJoinまでにかかる時間 etc. DataDogに全部投げる メトリクス
  12. バトルを大量に行って負荷をかけたい 課題 • 大量のクライアントはどうする? • アタック用サーバをいくつかたてて、独自クライアントを配置 • Locustによる一斉操作でバトル大量発生 • バトルを模倣した通信のシナリオはどう作る?

    • サーバで取得したプレイログを利用 • 正常な動作はどう確認する? • 接続時間や通信の応答時間を確認 • ボトルネックの特定や余裕の見積には様々なメトリクスが必要 • データはDataDogに貯めて、閲覧可能にしておくと良い 負荷試験の実施
  13. 結果データ 考察 • CCU 2000の場合、CPUが限界近い => CPU増強してみる?GCPインスタンス費、ライセンス費も考慮 • CCU 2800の場合、CPU使用率が低く通信待ちキューに溜まっている

    => 帯域ネック. このCCUは捌けない サーバのスペックを変えて実験を繰り返し、最適なスペックを算出 負荷試験の結果と考察の例
  14. 想定よりもCPU使用率が高かった 対処したこと • 独自実装した負荷クライアント側のバグ • 送信頻度が高くなりすぎていた • PhotonServerのバッファリングが効いていなかった • 設定ファイルを修正して再び有効化

    • ラグを吸収しようとして一部コマンドを遅延実行する処理が重かった • 重い処理は削除(ラグ吸収の効果も感じづらかった) • 到達保障設定の通信を厳選 ポイント • 送信頻度が高いとCPU使用率が上がる • PhotonServerの設定には気を付ける チューニング