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

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

1. 「リンクスリングス」における サーバ構成と負荷試験 CEDEC 2019 株式会社サムザップ 二宮 章太 石井 岳
2. 二宮 章太 2015年 4月 サイバーエージェント入社。 サムザップに出向し、新規タイトルの開発 に関わる。 現在では、リンクスリングスのバトル機能を 担当し、クライアントとPhotonServerのバト ル機能の開発に携わる。 自己紹介
3. 会社概要 株式会社サムザップ 2009年5月 CyberAgent 子会社として設立 事業内容 スマートフォン向けゲームアプリの企画・運営・配信
4. 提供サービス リンクスリングス 2019年5月配信開始 4人対4人の陣取りアクションゲーム 戦国炎舞 - KIZNA - 2013年4月配信開始 戦国時代を舞台にしたカードバトルゲーム この素晴らしい世界に祝福を！ ファンタスティックデイズ 今冬配信予定
5. リンクスリングス
6. アジェンダ Photonサーバ構成 • 重視したポイント • 想定したトラブルとその対応 負荷試験 • なぜ必要か • 準備すること • 結果に対する考察例
7. Photonの関わる機能
8. バトル回りの流れ マッチング バトル リザルト
9. バトル回りの流れ バトル リザルト マッチング Photon Server Web Serverから マッチングデータを取得 Web Serverに 対戦データを送信
10. 石井 岳 2016年 4月 サイバーエージェント入社。 サムザップに出向し、新規タイトルの開発 に関わる。 2018年10月よりPhotonServerへの移行を担当、 MasterServerの冗長化やログ・モニタリング 等基盤の開発を行う。 自己紹介
11. Photonサーバ構成
12. SDKのLoadBalancingアプリケーションの場合 PhotonServerの基本構成 MasterServer GameServer 1 GameServer 2 GameServer N User ロビー機能の提供 GameServerの負荷分散 ゲームルーム機能の提供 サーバ間通信で ルーム・負荷状況を共有
13. • メインコンテンツであるバトルを途切れさせない高可用性 • 急な負荷の増大に迅速に対応できるオートスケール サーバ構成で重視したポイント
14. • MasterServerのダウン • GameServerのダウン • 急なユーザの増加 想定される代表的なトラブル
15. MasterServerがダウンしたケース トラブルへの対応 MasterServer GameServer 1 GameServer 2 GameServer N User 新規ゲームが開始不能に
16. MasterServerのダウン • MasterServerを冗長化し、影響を最小限に抑える トラブルへの対応 1.各MasterServerの死活監視 MasterServer 2 Compute Engine Cloud Load Balancing 2.NGだったMasterServerへの 案内を停止 Cloud Memorystore 状態はデータストアで共有 MasterServer 1 Compute Engine User 接続先はロードバランサに一本化
17. GameServerのダウン • システムから切り離し、影響を最小限に抑える トラブルへの対応 AdminServer Compute Engine 1.各GameServerの死活監視 Cloud Memorystore Cloud Load Balancing GameServer 2 Compute Engine 2.死活監視結果を取得 3.NGだったGameServerの情報を削除 GameServer 1 Compute Engine
18. 急なユーザの増加 • CCU（同時接続数）を監視し、オートでGameServerの台数を増減 トラブルへの対応 Cloud Memorystore 1.現在のCCUの書き込み 2.定期的なCCUのチェック 3.GameServerの増減 AdminServer Compute Engine GameServer Compute Engine
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の死活監視
20. MasterServerが一台ダウンしても影響が少ない • 状態はデータストアにあるので、 クライアントは別のMasterServerに再接続するだけで大丈夫 自然にスケールアウトできる • MasterServerもGameServerもサーバをただ増やすだけで大丈夫 本構成のメリット
21. システム構成要素の増加と複雑化 • 管理/運用コストが増加した • 状態の更新が非同期になり、データ整合性維持の難易度が上がった MasterServerのパフォーマンス低下 • メモリとネットワークのアクセス速度の差は大きい 本構成のデメリット
22. サーバ構成まとめ • メインコンテンツであるバトルを途切れさせない高可用性 • データストアをネットワーク上へ移し、MasterServerを冗長化 • 急な負荷の増大に迅速に対応できるオートスケール • 負荷の申告と監視で、人手を介さない最短でのGameServerの増減
23. 負荷試験
24. 構成 • クアッドコア（例：Intel Xeon E3-1270 v3、3.5GHz） • 8 GB RAM • 1 GBps NIC/アップリンクポート速度 GameServer 2000 ～ 3000 CCU MasterServer 約40000 CCU 一般的なPhotonServerの性能
25. 負荷が変動する要因は様々 • ゲームルームごとのクライアント数 • メッセージ率（ルームごと、1秒あたりのメッセージ数の組み合わせ） • メッセージのサイズ • プロトコルの種類（高信頼性/低信頼性） • クライアントのプラットフォーム • サーバーハードウエアのスペック • etc 自分のサービスでも計測する必要がある なぜ負荷試験が必要？
26. 正常に動作することの確認 • スケールアウト時にCCUがきちんと増えることの確認 • 長期間高負荷の環境における動作確認 効率よい構成の導出 • コスパの良いサーバの性能 • 必要なサーバの数 • = サーバ1台あたりの上限CCU 負荷試験によって得たい情報
27. バトルを大量に行って負荷をかけたい 方針 • 大量のクライアントを用意 • 実際のバトルを模倣した通信シナリオを作成 • 正常に動作するかどうかを確認 課題 • 大量のクライアントはどうする？ • バトルを模倣した通信のシナリオはどう作る？ • 正常な動作はどう確認する？ 負荷試験の実施
28. バトルを大量に行って負荷をかけたい 方針 • 大量のクライアントを用意 • 実際のバトルを模倣した通信シナリオを作成 • 正常に動作するかどうかを確認 課題 • 大量のクライアントはどうする？ • バトルを模倣した通信のシナリオはどう作る？ • 正常な動作はどう確認する？ 負荷試験の実施
29. 別サーバに軽量クライアントを大量配置 軽量のコンソール向けSDKで負荷試験用クライアントを自作 アタック用のサーバを用意して大量配置 大量のクライアントを用意 Container- Optimized OS Photon Client Photon Client … Photon Client Photon Server Compute Engine Master / Game Attack Server
30. 結果、負荷試験用クライアントは重い アタックサーバ1台で 400CCU 程度 サーバ台数を増やして対処 大量のクライアントを用意 Photon Server Compute Engine Master / Game Attack Server Container-Optimized OS
31. 大量クライアントの操作 Locust • 分散実行可能な負荷試験ツール アタックサーバの構成 Developer Attack Server Container-Optimized OS Locust Slave Attack Server Container-Optimized OS Locust Master Photon Server Compute Engine Master / Game
32. バトルを大量に行って負荷をかけたい 課題 • 大量のクライアントはどうする？ • アタック用サーバを複数たてて、独自クライアントを配置 • Locustによる一斉操作でバトル大量発生 • バトルを模倣した通信のシナリオはどう作る？ • 正常な動作はどう確認する？ 負荷試験の実施
33. バトルを大量に行って負荷をかけたい 課題 • 大量のクライアントはどうする？ • アタック用サーバを複数たてて、独自クライアントを配置 • Locustによる一斉操作でバトル大量発生 • バトルを模倣した通信のシナリオはどう作る？ • 正常な動作はどう確認する？ 負荷試験の実施
34. リンクスリングスの特徴 4 vs 4のリアルタイム陣取りバトル 陣地の状態や自分や敵のキャラ武器によって動きが変わる 最上位帯のユーザ間でも最適解の議論が繰り広げられる それっぽいシナリオデータが作りづらい シナリオデータの取得
35. プレイログを使おう 懸念点 • チューニング中に通信データが変化すると負荷が変わる • コンバータを作ってできるだけシナリオを変えない • 複数シナリオ使うことで負荷を平均化する シナリオデータの取得
36. 専用のログ取得アプリを用意 • 送信データを全保存 • PUNのLoadBalancingPeer.OpCustomに入った全データ • サーバに変更を入れずに済む 結果 • 色々面倒だった • 専用ビルドを作ってテストプレイ • 8人分の端末からデータを抜き出す • 不採用 プレイログ取得 ～クライアント編～
37. サーバにログ保存機構を用意 • サーバへの変更は、Configで処理の回避が可能な変更にとどめる • サーバで受信したデータを全保存 • サーバに入ってデータを抜き出す 結果 • 最新版の開発用ビルドを毎朝触る文化があり、手軽に取得できた • データは1台から取得すればよい • ものすごく楽になった • 採用 プレイログ取得 ～サーバ編～
38. バトルを大量に行って負荷をかけたい 課題 • 大量のクライアントはどうする？ • アタック用サーバをいくつかたてて、独自クライアントを配置 • Locustによる一斉操作でバトル大量発生 • バトルを模倣した通信のシナリオはどう作る？ • サーバで取得したプレイログを利用 • 正常な動作はどう確認する？ 負荷試験の実施
39. バトルを大量に行って負荷をかけたい 課題 • 大量のクライアントはどうする？ • アタック用サーバをいくつかたてて、独自クライアントを配置 • Locustによる一斉操作でバトル大量発生 • バトルを模倣した通信のシナリオはどう作る？ • サーバで取得したプレイログを利用 • 正常な動作はどう確認する？ 負荷試験の実施
40. 正しく動作しているかどうか • MasterServerの応答時間が適正値 • 接続時間 • ルームへのJoin時間 • GameServerの応答時間が適正値 • 陣取りの応答時間 • 負荷による不具合が起きていないかを確認 • バトル結果 • ログ ボトルネック調査/余裕の見積もり • CPU使用率 • メモリ使用量 • 通信データ量 正常な動作の確認方針
41. 基本はPhotonカウンター • CCU/通信関連データ/etc. 足りないものは自作 • CPU使用率 • メモリ使用量 • 陣取りの応答時間 • Photonへの接続～ルームへのJoinまでにかかる時間 etc. DataDogに全部投げる メトリクス
43. バトルを大量に行って負荷をかけたい 課題 • 大量のクライアントはどうする？ • アタック用サーバをいくつかたてて、独自クライアントを配置 • Locustによる一斉操作でバトル大量発生 • バトルを模倣した通信のシナリオはどう作る？ • サーバで取得したプレイログを利用 • 正常な動作はどう確認する？ • 接続時間や通信の応答時間を確認 • ボトルネックの特定や余裕の見積には様々なメトリクスが必要 • データはDataDogに貯めて、閲覧可能にしておくと良い 負荷試験の実施
44. ちゃんとうごくことの確認 • スケールアウト時にCCUがきちんと増えることの確認 • 長期間高負荷の環境における動作確認 効率よい構成を導き出す • コスパの良いサーバの性能を割り出す • 必要なサーバの数を割り出す • サーバ1台あたりの上限CCU 負荷試験によって得たい情報（再）
45. 性能を下げれば費用が安くなる CPU/メモリ/通信量などをギリギリまで使うのがよい • どれかが余裕すぎるのはもったいない コスパの良いサーバ
46. 結果データ 考察 • CCU 2000の場合、CPUが限界近い => CPU増強してみる？GCPインスタンス費、ライセンス費も考慮 • CCU 2800の場合、CPU使用率が低く通信待ちキューに溜まっている => 帯域ネック. このCCUは捌けない サーバのスペックを変えて実験を繰り返し、最適なスペックを算出 負荷試験の結果と考察の例
47. 想定よりもCPU使用率が高かった 対処したこと • 独自実装した負荷クライアント側のバグ • 送信頻度が高くなりすぎていた • PhotonServerのバッファリングが効いていなかった • 設定ファイルを修正して再び有効化 • ラグを吸収しようとして一部コマンドを遅延実行する処理が重かった • 重い処理は削除（ラグ吸収の効果も感じづらかった） • 到達保障設定の通信を厳選 ポイント • 送信頻度が高いとCPU使用率が上がる • PhotonServerの設定には気を付ける チューニング
48. サーバスペック • GCP n1-highcpu-8 • ８コア • メモリ 7.2GB CCU 2900 最終的な性能
49. 偽装クライアントを自作し、別サーバに大量配置 アタックサーバをスケールして想定CCUを担保する 作成の難しいシナリオは実データを使用 負荷試験のバグとサーバの設定は注意 負荷試験まとめ
50. Photonはフレームワークとして完成度が高いと思います。 PhotonServerの情報はまだまだ少ないですが、 リンクスリングスの事例が何かの助けになれば幸いです さいごに